ERPC breidt Solana Leader Slot API uit met pingmetingen vanuit 7 wereldwijde regio’s — ook Validators Information API gelanceerd
ELSOUL LABO B.V. (hoofdkantoor: Amsterdam, Nederland; CEO: Fumitake Kawasaki) en Validators DAO, de beheerders van ERPC, hebben de API’s voor inzicht in Solana-leaders, geschatte locaties en latency uitgebreid. De Leader Slot API ondersteunt nu referentie-RTT (pingmetingen) vanuit 7 wereldwijde regio’s en daarnaast is de nieuwe Validators Information API gelanceerd.
Ten eerste hebben we de Leader Slot API (
getLeaderSlots) uitgebreid, zodat referentie-RTT kan worden verkregen vanuit 7 ERPC-observatieregio’s over de hele wereld (Frankfurt, Amsterdam, New York, Londen, Tokio, Singapore en Sydney). Voorheen werd er alleen vanuit Frankfurt gemeten.Daarnaast hebben we de nieuwe Validators Information API (
getValidatorsInformation) gelanceerd. Deze API retourneert in één call een overzicht van alle validators die in de huidige epoch minstens één leader slot bekleden. Naast het aantal slots en de actieve stake retourneert hij — waar beschikbaar — ook de geschatte locatie, netwerk-endpoints, clientversie en referentie-RTT vanuit de 7 regio’s.Beide API’s zijn beschikbaar voor alle ERPC-gebruikers via de standaard JSON-RPC-interface.
- Leader Slot API-documentatie: https://erpc.global/nl/doc/rpc/leader-slot-api/
- Validators Information API-documentatie: https://erpc.global/nl/doc/rpc/validators-information-api/
Het verschil met traditionele handelsinfrastructuur: op Solana verandert de bestemming dynamisch
In traditionele exchanges en financiële systemen zijn de bestemmingen waarnaar orders worden verstuurd — exchanges, gateways, matching engines — doorgaans vast gekoppeld aan specifieke datacenters of netwerken.
Zodra gebruikers de verbindingsbestemming kennen, kunnen ze hun netwerkpad ernaartoe continu optimaliseren. Omdat de locaties van de doelservers niet vaak veranderen, kunnen infrastructuurplaatsing en communicatieroutes relatief statisch worden ontworpen.
Op Solana daarentegen rouleert de leader — de validator die verantwoordelijk is voor het produceren van blocks — elke paar slots volgens het leader schedule. Omdat de validators die als leader optreden over de hele wereld verspreid zijn, veranderen zowel de bestemming die uw transacties moeten bereiken als het netwerkpad dat het dichtst bij die bestemming ligt continu.
Met andere woorden: op Solana kan de te optimaliseren communicatiebestemming niet als een vaste, enkele verbindingsplek worden behandeld.
U moet eerst uit het leader schedule achterhalen wie de huidige en toekomstige leaders zijn. Vervolgens controleert u in welke regio of welk netwerk elke validator zich hoogstwaarschijnlijk bevindt en hoe groot de latency is vanaf elke verzendlocatie, voordat u een verzendroute bepaalt.
Deze structuur correct begrijpen is het startpunt voor transactieverzending met lage latency en voor wereldwijd infrastructuurontwerp op Solana.
Het leader schedule en netwerklocaties als data behandelen
In een omgeving waar de bestemming dynamisch verandert, is het niet praktisch dat een mens elke keer de leader en de verzendlocatie controleert en handmatig van route wisselt.
Daarvoor moet de volgende informatie voortdurend beschikbaar zijn en worden opgenomen in de beslissingslogica van uw applicaties en infrastructuur.
- De leaders die verantwoordelijk zijn voor huidige en aankomende slots
- Het aantal slots waarvoor elke validator verantwoordelijk is
- Het geschatte land, de stad en de regio van elke validator
- Netwerk-endpoints zoals TPU en QUIC
- Referentie-RTT verzameld vanuit elke observatieregio
- Het tijdstip waarop elke meting is verkregen en de responsstatus
Geschatte locatie en gemeten latency spelen elk een andere rol.
Locatie-informatie kan worden gebruikt voor middellange- en langetermijnbeslissingen over waar u infrastructuur en capaciteit plaatst. Referentie-RTT vanuit elke regio daarentegen vormt input om te beoordelen vanaf welke locatie momenteel hoogstwaarschijnlijk een kort pad beschikbaar is.
Een fysiek of geografisch nabije locatie is niet altijd ook het kortste pad op het netwerk. Daarom is het belangrijk om beslissingen te nemen door de geschatte locatie te combineren met daadwerkelijk waargenomen waarden.
De Leader Slot API en Validators Information API van ERPC zijn ontworpen om deze datagestuurde beslissingen in programmatuur vast te leggen.
Leader Slot API: referentie-RTT meten vanuit 7 wereldwijde regio’s
De Leader Slot API retourneert aankomende leader slots samen met validator-identiteit, actieve stake, netwerk-endpoints, geschatte locatie, referentie-RTT en meer.
Tot nu toe werden
pingToLeaders-metingen alleen verzameld vanuit de Frankfurt-origin — een enkel observatiepunt op een wereldwijd verdeeld Solana-netwerk.Met deze update kunt u referentie-RTT-metingen vanuit de volgende 7 regio’s opvragen.
frankfurtamsterdamnylondontokyosingaporesydney
Door voor elke leader de referentie-RTT vanuit de 7 observatieregio’s te vergelijken, kunt u beoordelen vanaf welke verzendlocatie hoogstwaarschijnlijk een kort netwerkpad beschikbaar is.
Dit dient als input voor besluitvorming, niet alleen voor transactierouting, maar ook om te bepalen in welke regio’s u capaciteit plaatst voor RPC, gRPC, Direct Shreds, transactieverzendservers en meer.
De meetresultaten bevatten
icmpReplied, dat aangeeft of de validator op ICMP heeft gereageerd, en measuredAt, dat aangeeft wanneer de laatste succesvolle meting is verkregen.Een validator die niet op ICMP reageert, kan diensten zoals TPU en QUIC toch normaal draaien. Daarom moet een
icmpReplied van false worden behandeld als “niet meetbaar via ICMP”, niet als “ver weg”.Wanneer bij een update geen succesvolle meting kan worden verkregen, wordt de vermelding bovendien niet overschreven met een ongemeten waarde — de laatste succesvol gemeten waarde en het bijbehorende meettijdstip blijven bewaard.
Validators Information API: leaderinformatie voor de hele epoch in één overzicht
De Leader Slot API is geschikt voor beslissingen op slotniveau — “wie is de leader voor de komende slots?”
Voor infrastructuurplaatsing en capaciteitsplanning is daarentegen een breder perspectief nodig.
- Welke validators treden in de huidige epoch als leader op
- Voor hoeveel slots is elk van hen verantwoordelijk
- Over welke landen en regio’s zijn ze verdeeld
- Waar moet infrastructuur worden geplaatst om dichter bij meer leaders te komen
De nieuwe Validators Information API (
getValidatorsInformation) is de API die op deze vragen antwoord geeft.Zonder parameters retourneert de API iedere validator die in de huidige epoch voor minstens één slot als leader optreedt — één rij per validator. Standaard staan de resultaten in aflopende volgorde van het aantal toegewezen leader slots.
Elke rij bevat de volgende informatie.
slotCountstakeWeight(actieve stake in SOL)- Validator-identiteit
Waar beschikbaar wordt ook de volgende informatie geretourneerd.
- Geschatte regio, stad en land
- Netwerk-endpoints
- Clientversie
- Referentie-RTT vanuit de 7 regio’s
Omdat de data regelmatig wordt ververst, blijft uw planningsdataset actueel wanneer u de API regelmatig aanroept.
U kunt de resultaten ook verfijnen met de optionele parameters
limit (1–2000), country en region.De facturatie is gebaseerd op het aantal geretourneerde validators. Het aantal leader-validators verschilt per epoch; in het voorbeeld op het moment van schrijven kost het ophalen van alle 673 validators 6.800 API-tokens (API-gebruikscredits van ERPC) en het ophalen van maximaal 10 validators 100 API-tokens.
Naar programmeerbare, datagestuurde routing
Deze API’s zijn niet bedoeld om simpelweg een lijst met validators of referentie-RTT weer te geven.
Het uiteindelijke doel is om het leader schedule, de geschatte locaties van validators en de referentie-RTT vanuit elke observatieregio in te bouwen in de beslissingslogica van uw applicaties.
Een applicatie kan bijvoorbeeld het aankomende leader schedule ophalen, de referentie-RTT vanuit de 7 observatieregio’s per leader vergelijken en vervolgens de te gebruiken RPC- of transactieverzendroute selecteren.
U kunt ook de leaderverdeling over de hele epoch analyseren en vooraf infrastructuur plaatsen in regio’s dicht bij validators met een hoog aantal slots.
Typische toepassingen zijn onder andere de volgende.
- Het selecteren van verzendroutes op slotniveau
- Capaciteitsplanning op epoch-niveau
- Analyse van leader-validators per regio
- Prioritering die rekening houdt met actieve stake en aantal slots
- Monitoring van veranderingen in geografische en netwerkverdeling over epochs heen
- Automatische selectie tussen RPC- en verzendservers die over meerdere regio’s zijn geïmplementeerd
Op Solana, waar de bestemming dynamisch verandert, is statische netwerkoptimalisatie alleen niet genoeg.
Het wordt belangrijk om de wisselende leader continu te volgen en verzendroutes en infrastructuur dynamisch te kiezen op basis van diens locatie en netwerkomstandigheden.
Naar Solana-infrastructuur voor wereldwijd gebruik
ERPC is krachtige infrastructuur voor Solana die vanaf dag één is ontworpen voor wereldwijd gebruik.
Ons edgenetwerk, onze bare-metal- en VPS-diensten, Direct Shreds, Geyser gRPC, SWQoS-endpoints en deze API’s voor operationele informatie dienen allemaal hetzelfde doel.
Dat doel is om ontwikkelaars die in een wereldwijd verspreid landschap van gebruikers en leaders lage latency en efficiënte uitvoering vereisen, zowel data als infrastructuur te bieden.
Referentie-RTT vanuit 7 wereldwijde regio’s en validatorinformatie voor een volledige epoch zijn nu met eenvoudige RPC-aanroepen op te vragen. Solana-applicaties kunnen daardoor op basis van data verzendlocaties en netwerkroutes kiezen die aansluiten op de steeds wisselende leader.
Voor ontwikkelaars die op Solana verzending met lage latency, wereldwijde infrastructuurplaatsing en dynamische routeoptimalisatie nastreven, biedt dit rechtstreeks bruikbare beslisinformatie.
We hopen dat dit helpt bij het kiezen van verzendroutes met lage latency, het ontwerpen van infrastructuur die onnodige overdracht over lange afstanden beperkt en het plannen van wereldwijde capaciteitsplaatsing.
Zie de documentatie voor details.
- Leader Slot API: https://erpc.global/nl/doc/rpc/leader-slot-api/
- Validators Information API: https://erpc.global/nl/doc/rpc/validators-information-api/
- ERPC Web Dashboard: https://dashboard.erpc.global/nl
