ERPC

ERPC amplia la Solana Leader Slot API con la misurazione del ping da 7 regioni globali — Lanciata anche la Validators Information API

ERPC amplia la Solana Leader Slot API con la misurazione del ping da 7 regioni globali — Lanciata anche la Validators Information API

ERPC amplia la Solana Leader Slot API con la misurazione del ping da 7 regioni globali — Lanciata anche la Validators Information API
ELSOUL LABO B.V. (sede: Amsterdam, Paesi Bassi; CEO: Fumitake Kawasaki) e Validators DAO, gli operatori di ERPC, hanno potenziato le API per comprendere informazioni sui leader, posizioni stimate e latenza di Solana, aggiungendo alla Leader Slot API il supporto dell’RTT di riferimento (misurazione del ping) da 7 regioni globali e lanciando la nuova Validators Information API.
In primo luogo, abbiamo ampliato la Leader Slot API (getLeaderSlots) in modo da poter ottenere l’RTT di riferimento da 7 regioni di osservazione ERPC in tutto il mondo (Francoforte, Amsterdam, New York, Londra, Tokyo, Singapore e Sydney). In precedenza, le misurazioni venivano effettuate solo da Francoforte.
Contemporaneamente, abbiamo lanciato la nuova Validators Information API (getValidatorsInformation). Questa API elenca, in una singola chiamata, ogni validator che detiene almeno un leader slot nell’epoca corrente. Oltre al conteggio degli slot e allo stake attivo, restituisce anche, dove disponibili, la posizione stimata, gli endpoint di rete, la versione del client e l’RTT di riferimento dalle 7 regioni.
Entrambe le API sono disponibili per tutti gli utenti ERPC tramite l’interfaccia JSON-RPC standard.

La differenza rispetto all’infrastruttura di trading tradizionale: su Solana la destinazione delle comunicazioni cambia dinamicamente

Nelle borse e nei sistemi finanziari tradizionali, le destinazioni a cui vengono inviati gli ordini — borse, gateway, motori di matching — sono tipicamente fissate a data center o reti specifici.
Di conseguenza, una volta nota la destinazione della connessione, gli utenti possono ottimizzare continuamente il percorso di rete verso di essa. Poiché le posizioni dei server di destinazione non cambiano frequentemente, il posizionamento dell’infrastruttura e le rotte di comunicazione possono essere progettati in modo relativamente statico.
Su Solana, al contrario, il leader — il validator responsabile della produzione dei blocchi — ruota ogni pochi slot secondo lo schedule dei leader. Poiché i validator che fungono da leader sono distribuiti in tutto il mondo, sia la destinazione che le tue transazioni devono raggiungere sia il percorso di rete più vicino a quella destinazione cambiano continuamente.
In altre parole, su Solana la destinazione delle comunicazioni da ottimizzare non può essere trattata come un punto di connessione unico e fisso.
Devi prima identificare i leader attuali e futuri dallo schedule dei leader. Inoltre, verifichi in quale regione o rete è più probabile che si trovi ciascun validator e quanta latenza c’è da ciascuna sede di invio, prima di decidere una rotta di invio.
Comprendere correttamente questa struttura è il punto di partenza per la consegna di transazioni a bassa latenza e per la progettazione di infrastrutture globali su Solana.

Trattare lo schedule dei leader e le posizioni di rete come dati

In un ambiente in cui la destinazione cambia dinamicamente, non è pratico che una persona controlli di volta in volta il leader e la sede di invio e cambi rotta manualmente.
Ciò che serve è ottenere continuamente le seguenti informazioni e integrarle nella logica decisionale delle tue applicazioni e della tua infrastruttura.
  • I leader responsabili degli slot attuali e futuri
  • Il numero di slot di cui è responsabile ciascun validator
  • Il paese, la città e la regione stimati di ciascun validator
  • Endpoint di rete come TPU e QUIC
  • L’RTT di riferimento raccolto da ciascuna regione di osservazione
  • L’orario di ciascuna misurazione e il suo stato di risposta
La posizione stimata e la latenza misurata svolgono ruoli diversi.
Le informazioni sulla posizione possono essere utilizzate per decisioni a medio-lungo termine su dove posizionare infrastruttura e capacità. L’RTT di riferimento da ciascuna regione, invece, fornisce un elemento per valutare quale sede attualmente abbia maggiori probabilità di offrire un percorso breve.
Una posizione fisicamente o geograficamente vicina non è sempre la più breve sulla rete. Per questo motivo, è importante prendere decisioni combinando la posizione stimata con i valori osservati effettivi.
La Leader Slot API e la Validators Information API di ERPC sono API pensate per permetterti di programmare queste decisioni sulla base dei dati.

Leader Slot API: misurazione dell’RTT di riferimento da 7 regioni globali

La Leader Slot API restituisce i prossimi leader slot insieme a identità del validator, stake attivo, endpoint di rete, posizione stimata, RTT di riferimento e altro.
Fino a oggi, le misurazioni pingToLeaders venivano raccolte solo dall’origine di Francoforte — un unico punto di osservazione su una rete Solana distribuita globalmente.
Con questo aggiornamento, ora puoi ottenere l’RTT di riferimento misurato dalle seguenti 7 regioni.
  • frankfurt
  • amsterdam
  • ny
  • london
  • tokyo
  • singapore
  • sydney
Confrontando l’RTT di riferimento dalle 7 regioni di osservazione per ciascun leader, puoi valutare quale sede di invio abbia maggiori probabilità di offrire un percorso di rete breve.
Questo costituisce un elemento decisionale non solo per il routing delle transazioni, ma anche per decidere in quali regioni posizionare capacità per RPC, gRPC, Direct Shreds, server di invio delle transazioni e altro.
I risultati delle misurazioni includono icmpReplied, che indica se il validator ha risposto all’ICMP, e measuredAt, che indica l’orario in cui è stata ottenuta l’ultima misurazione riuscita.
Un validator che non risponde all’ICMP potrebbe comunque gestire normalmente servizi come TPU e QUIC. Per questo motivo, quando icmpReplied è false, va trattato non come «distante», ma come «non misurabile via ICMP».
Inoltre, quando al momento dell’aggiornamento non è possibile ottenere una misurazione riuscita, la voce non viene sovrascritta con un valore non misurato: vengono conservati l’ultimo valore misurato con successo e il suo orario di misurazione.

Validators Information API: l’elenco delle informazioni sui leader dell’intera epoca

La Leader Slot API è adatta a decisioni a livello di slot — «chi è il leader responsabile dei prossimi slot?»
Il posizionamento dell’infrastruttura e la pianificazione della capacità, invece, richiedono una visione più ampia.
  • Quali validator fungono da leader nell’epoca corrente
  • Di quanti slot è responsabile ciascuno
  • In quali paesi e regioni sono distribuiti
  • Dove posizionare l’infrastruttura per avvicinarsi a più leader
La nuova Validators Information API (getValidatorsInformation) è l’API costruita per rispondere a queste domande.
Chiamata senza parametri, restituisce ogni validator che funge da leader per almeno uno slot nell’epoca corrente, una riga per validator. Per impostazione predefinita, i risultati sono restituiti in ordine decrescente per numero di leader slot detenuti.
Ogni riga include le seguenti informazioni.
  • slotCount
  • stakeWeight (stake attivo in SOL)
  • Identità del validator
Dove disponibili, vengono restituite anche le seguenti informazioni.
  • Regione, città e paese stimati
  • Endpoint di rete
  • Versione del client
  • RTT di riferimento dalle 7 regioni
Poiché i dati vengono aggiornati regolarmente, chiamare l’API con regolarità mantiene il tuo dataset di pianificazione sempre aggiornato.
Puoi anche restringere i risultati usando i parametri opzionali limit (1–2000), country e region.
La fatturazione si basa sul numero di validator restituiti. Il numero di validator leader varia di epoca in epoca; nell’esempio al momento della stesura, recuperare tutti i 673 validator utilizza 6,800 API token (crediti di utilizzo delle API ERPC), mentre recuperarne fino a 10 utilizza 100 API token.

Verso un routing programmabile e basato sui dati

Queste API non servono semplicemente a mostrare un elenco di validator o l’RTT di riferimento.
L’obiettivo finale è permetterti di integrare lo schedule dei leader, le posizioni stimate dei validator e l’RTT di riferimento da ciascuna regione di osservazione nella logica decisionale delle tue applicazioni.
Ad esempio, un’applicazione può recuperare lo schedule dei leader imminente, confrontare l’RTT di riferimento dalle 7 regioni di osservazione per ciascun leader e poi selezionare l’RPC o la rotta di invio delle transazioni da utilizzare.
Puoi anche analizzare la distribuzione dei leader sull’intera epoca e posizionare in anticipo l’infrastruttura in regioni vicine ai validator con un numero elevato di slot.
Gli usi principali sono i seguenti.
  • Selezione delle rotte di invio a livello di slot
  • Pianificazione della capacità a livello di epoca
  • Analisi dei validator leader per regione
  • Prioritizzazione che tiene conto di stake attivo e numero di slot
  • Monitoraggio dei cambiamenti nella distribuzione geografica e di rete tra epoche
  • Selezione automatica tra RPC e server di invio distribuiti su più regioni
Su Solana, dove la destinazione cambia dinamicamente, la sola ottimizzazione statica della rete non è sufficiente.
Diventa importante tracciare continuamente il leader che cambia e selezionare dinamicamente rotte di invio e infrastruttura in base alla sua posizione e alle condizioni della rete.

Verso un’infrastruttura Solana progettata per l’operatività globale

ERPC è un’infrastruttura ad alte prestazioni per Solana, progettata fin dal primo giorno pensando all’operatività globale.
La nostra edge network, il bare metal e i VPS, Direct Shreds, Geyser gRPC, gli endpoint SWQoS e queste API di intelligence operativa sono tutti forniti al servizio di uno scopo comune.
Quello scopo è fornire sia dati sia infrastruttura ai builder che richiedono un’esecuzione efficiente e a bassa latenza in un ambiente in cui utenti e leader sono distribuiti in tutto il mondo.
L’RTT di riferimento da 7 regioni globali e le informazioni sui validator dell’intera epoca sono ora ottenibili tramite semplici chiamate RPC. Le applicazioni Solana possono ora selezionare sedi di invio e rotte di rete sulla base dei dati, in risposta al leader in continuo cambiamento.
Per i builder che cercano consegna a bassa latenza, posizionamento globale dell’infrastruttura e ottimizzazione dinamica del routing su Solana, questo è un elemento decisionale direttamente collegato alle operazioni reali.
Ci auguriamo che sia utile per scegliere rotte di invio a bassa latenza, progettare infrastrutture che riducano i trasferimenti non necessari su lunghe distanze e pianificare il posizionamento globale della capacità.
Per i dettagli, consulta la documentazione.

Novità