Leader Slot Informatie API-documentatie
Wat is de Leader Slot Informatie (getLeaderSlots) API?
getLeaderSlots is een uitgebreide Solana RPC-methode die komende leader slot-records retourneert met de validator-identity, stake weight, netwerkmetadata van het endpoint, geschatte leader-locatie en referentiemetingen van de latentie. Als u ERPC-gebruikstegoed (API-tokens) heeft, kunt u deze methode aanroepen in hetzelfde formaat als een standaard Solana RPC-methode.Deze API biedt:
- Schema van leader-validators vanaf het opgegeven slot
stakeWeightvoor elke leader-validator- Geschatte leader-regio, stad, land, coördinaten, ASN-organisatie en tijdzone
- Referentie-pingmetingen vanuit ERPC-observatieregio's via
pingToLeaders
Endpoint en voorbeeld van de request body
endpoint
Geef het startslot op in
params.json
Voorbeeld (HTTP)
bash
Voorbeeldresponse (JSON)
De huidige response plaatst records in
result.data[]. result.total toont hoeveel records zijn teruggegeven. De data[]-array hieronder is ingekort tot drie van de 100 records van dit verzoek. Het eerste item toont pingToLeaders vanuit alle zeven ERPC-observatieregio's; de overige items zijn voor de leesbaarheid teruggebracht tot één regio.json
Responsevelden
Leader Slots visualiseren
Dezelfde response kan worden gelezen als een operationele tijdlijn per slot. Dit voorbeeld gebruikt Frankfurt als observatiepunt.
Deze weergave is nuttig omdat Solana wereldwijd is. Anders dan bij traditionele HFT, waar het doel vaak is om dicht bij één matching engine te staan, rouleren Solana-leaders over validators over de hele wereld. De snelste regio verandert mee met het leader schedule.
Website met Solana-netwerkdata
Gebruik Validators Solutions voor een publieke weergave van de verdeling van validators en het netwerk. Gebruik het om het bredere Solana-netwerk te begrijpen en gebruik daarna
getLeaderSlots voor het schema per slot, stake weight, validatorlocatie en gemeten latentie die nodig zijn voor operationele routing.Tokengebruik
De API haalt 100 leader slot-records op vanaf het opgegeven slot. Elk request verbruikt 420 tokens.
Heeft u voor de hele epoch één item per validator nodig in plaats van één item per slot, gebruik dan de Validators Informatie API, die wordt afgerekend op het aantal validators dat wordt geretourneerd.
Waarom Leader Slot-informatie belangrijk is
- Als de leader geografisch of qua netwerkpad ver weg is, wordt het direct afleveren van transacties inefficiënt.
- Stake weight helpt in te schatten hoe vaak een validator na verloop van tijd waarschijnlijk in het leader schedule verschijnt.
- Bij wereldwijde leaderwisselingen zijn regionale wisselstrategieën belangrijker dan één wereldwijd gemiddelde latentie.
- De combinatie van slotschema, stake weight, leader-locatie en gemeten pingdata maakt geoptimaliseerde routing en plaatsing van validators mogelijk.
Achtergrond
Een Solana-epoch bestaat uit ongeveer 432.000 slots. Het continu verzamelen van leader schedules, validatormetadata, geolocatie en latentiemetingen vereist een speciale datapipeline. ERPC onderhoudt deze gegevens en biedt ze via de RPC-interface aan als direct bruikbare leader slot map.
Strategische use cases
- Detectieoptimalisatie: geef prioriteit aan nabije leadervensters met lage latentie.
- Multiregio-deployment: deploy in FRA, AMS, NY, TY, SGP en andere strategische regio's om overgangsgaten te verkleinen.
- Planning op basis van stake: gebruik
stakeWeightom te begrijpen welke leaders over langere vensters vaker van belang zijn. - Visualisatie en analytics: monitor leaderverhoudingen, stakeverdeling en latentieverdeling per regio.
Beschikbaarheid
getLeaderSlots is beschikbaar voor alle ERPC-gebruikers. API-tokens en gebruikstegoed kunnen worden uitgegeven of gecontroleerd via het ERPC Web Dashboard.- ERPC Web Dashboard: ERPC Web Dashboard
Slagingspercentage van transacties en SWQoS Endpoint
Voor een hogere transactiesucceskans en snellere uitvoering raden we het SWQoS Endpoint aan. SWQoS (Stake-weighted Quality of Service) geeft prioriteit aan validators met stakeverbindingen. Leaders reserveren ongeveer 80% van de bandbreedte voor prioriteitsverkeer en 20% voor niet-prioritair verkeer; de prioriteitsbaan biedt ongeveer 5x zoveel throughput. Deze scheduling vindt plaats vóór de evaluatie van de Priority fee, waardoor toegang tot de SWQoS-prioriteitsbaan de voorwaarde is voor echte prestaties met lage latentie.







