ERPC Breidt Solana Leader Slot API Uit met Pingmeting vanuit 7 Wereldwijde Regio’s — Validators Information API Ook Gelanceerd
ERPC Breidt Solana Leader Slot API Uit met Pingmeting vanuit 7 Wereldwijde Regio’s — Validators Information API Ook Gelanceerd
ELSOUL LABO B.V. (hoofdkantoor: Amsterdam, Nederland; CEO: Fumitake Kawasaki) en Validators DAO, de operators van ERPC, hebben de API’s voor het begrijpen van Solana-leaderinformatie, geschatte locaties en latency verbeterd, met ondersteuning voor referentie-RTT (pingmeting) vanuit 7 wereldwijde regio’s in de Leader Slot API en de lancering van de nieuwe Validators Information API.
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/en/doc/rpc/leader-slot-api/
- Validators Information API-documentatie: https://erpc.global/en/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 jouw 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.
Je moet eerst uit het leader schedule achterhalen wie de huidige en toekomstige leaders zijn. Vervolgens controleer je in welke regio of welk netwerk elke validator zich hoogstwaarschijnlijk bevindt en hoe groot de latency is vanaf elke verzendlocatie, voordat je 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.
Wat nodig is, is de volgende informatie continu verkrijgen en inbouwen in de beslissingslogica van je 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 je 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 API’s die zijn ontworpen om je deze beslissingen op basis van data te laten programmeren.
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 kun je nu referentie-RTT verkrijgen die is gemeten vanuit de volgende 7 regio’s.
frankfurtamsterdamnylondontokyosingaporesydney
Door voor elke leader de referentie-RTT vanuit de 7 observatieregio’s te vergelijken, kun je 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 je 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 services 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 entry bovendien niet overschreven met een ongemeten waarde — de laatste succesvol gemeten waarde en het bijbehorende meettijdstip blijven bewaard.
Validators Information API: Leaderinformatie van 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 aangeroepen, retourneert hij elke validator die in de huidige epoch minstens één slot als leader vervult — één rij per validator. Standaard worden de resultaten geretourneerd in aflopende volgorde van het aantal beheerde 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, houdt regelmatig aanroepen van de API je planningsdataset up-to-date.
Je 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 je 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.
Je kunt ook de leader-verdeling 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 veranderende leader continu te volgen en verzendroutes en infrastructuur dynamisch te kiezen op basis van diens locatie en netwerkomstandigheden.
Naar Solana-Infrastructuur Ontworpen voor Wereldwijde Operatie
ERPC is high-performance infrastructuur voor Solana, vanaf dag één ontworpen met wereldwijde operatie in gedachten.
Ons edge-netwerk, onze bare metal- en VPS-aanbiedingen, Direct Shreds, Geyser gRPC, SWQoS-endpoints en deze operational intelligence API’s worden allemaal geleverd vanuit een gemeenschappelijk doel.
Dat doel is om builders die lage-latency, efficiënte uitvoering vereisen — in een omgeving waar gebruikers en leaders over de hele wereld verspreid zijn — zowel data als infrastructuur te bieden.
Referentie-RTT vanuit 7 wereldwijde regio’s en epoch-brede validatorinformatie zijn nu verkrijgbaar via eenvoudige RPC-calls. Solana-applicaties kunnen nu verzendlocaties en netwerkroutes kiezen op basis van data, als reactie op de voortdurend veranderende leader.
Voor builders die op Solana lage-latency verzending, wereldwijde infrastructuurplaatsing en dynamische routing-optimalisatie nastreven, is dit beslissingsmateriaal dat direct aansluit bij de dagelijkse praktijk.
We hopen dat dit helpt bij het kiezen van verzendroutes met lage latency, het ontwerpen van infrastructuur die onnodige langeafstandstransfers beperkt en het plannen van wereldwijde capaciteitsplaatsing.
Zie de documentatie voor details.
- Leader Slot API: https://erpc.global/en/doc/rpc/leader-slot-api/
- Validators Information API: https://erpc.global/en/doc/rpc/validators-information-api/
- ERPC Web Dashboard: https://dashboard.erpc.global/en
Nieuws
