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 che forniscono informazioni sui leader Solana, sulle loro posizioni stimate e sulla latenza. La Leader Slot API supporta ora l’RTT di riferimento (misurazione del ping) da 7 regioni del mondo ed è stata lanciata 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). Con una sola chiamata, questa API elenca tutti i validator a cui è assegnato almeno uno slot da leader nell’epoca corrente. Oltre al numero di 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.
- Documentazione della Leader Slot API: https://erpc.global/it/doc/rpc/leader-slot-api/
- Documentazione della Validators Information API: https://erpc.global/it/doc/rpc/validators-information-api/
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.
Occorre prima identificare i leader attuali e futuri dalla relativa programmazione. Successivamente si verifica in quale regione o rete è più probabile che si trovi ciascun validator e quale sia la latenza da ogni sede di invio, prima di scegliere la rotta.
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 usate per decidere, nel medio e lungo periodo, dove collocare infrastruttura e capacità. L’RTT di riferimento da ciascuna regione fornisce invece un dato utile per valutare quale sede abbia, in un determinato momento, maggiori probabilità di offrire un percorso di rete breve.
La vicinanza fisica o geografica non garantisce sempre il percorso di rete più breve. È quindi importante decidere combinando la posizione stimata con i valori osservati effettivi.
La Leader Slot API e la Validators Information API di ERPC sono progettate per automatizzare 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 slot da leader insieme all’identità del validator, allo stake attivo, agli endpoint di rete, alla posizione stimata, all’RTT di riferimento e ad altre informazioni.
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.
frankfurtamsterdamnylondontokyosingaporesydney
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.
Questi dati orientano non soltanto il routing delle transazioni, ma anche la scelta delle regioni in cui collocare capacità per RPC, gRPC, Direct Shreds, server di invio delle transazioni e altri servizi.
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) è stata creata per rispondere a queste domande.Chiamata senza parametri, restituisce tutti i validator che fungono da leader per almeno uno slot nell’epoca corrente, una riga per validator. Per impostazione predefinita, i risultati sono ordinati in modo decrescente per numero di slot da leader assegnati.
Ogni riga include le seguenti informazioni.
slotCountstakeWeight(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 periodicamente l’API mantiene aggiornato il dataset usato per la pianificazione.
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 da un’epoca all’altra; nell’esempio disponibile al momento della stesura, recuperare tutti i 673 validator richiede 6.800 token API (crediti di utilizzo delle API ERPC), mentre recuperarne fino a 10 richiede 100 token API.
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 è permettere di integrare la programmazione dei leader, le posizioni stimate dei validator e l’RTT di riferimento da ciascuna regione di osservazione nella logica decisionale delle applicazioni.
Ad esempio, un’applicazione può recuperare la programmazione dei prossimi leader, confrontare per ciascuno l’RTT di riferimento dalle 7 regioni di osservazione e quindi selezionare l’RPC o la rotta da usare per l’invio delle transazioni.
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 seguire continuamente il susseguirsi dei leader e selezionare in modo dinamico rotte di invio e infrastruttura in base alla posizione del leader corrente 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, queste informazioni supportano decisioni direttamente collegate 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.
- Leader Slot API: https://erpc.global/it/doc/rpc/leader-slot-api/
- Validators Information API: https://erpc.global/it/doc/rpc/validators-information-api/
- ERPC Web Dashboard: https://dashboard.erpc.global/it
