ERPC

Documentation de l'API d'information sur les validateurs

Qu'est-ce que l'API Validators Information (getValidatorsInformation)?

getValidatorsInformation est une méthode Solana RPC étendue qui renvoie les validateurs qui dirigent au moins un slot dans l'époque courante, avec le poids de stake, les métadonnées d'endpoint réseau, l'emplacement estimé du leader et les mesures de latence de référence regroupés en une ligne par validateur. Elle ne renvoie pas la liste de tous les nœuds du réseau et ne renvoie pas non plus les nœuds RPC. Si vous disposez de crédits d'utilisation ERPC (tokens API), vous pouvez l'appeler au même format qu'une méthode Solana RPC standard.
Cette API fournit:
  • Une ligne par validateur qui dirige un slot dans l'époque courante, avec slotCount indiquant combien de slots il dirige — contrairement à getLeaderSlots, qui renvoie une ligne par slot
  • stakeWeight pour chaque validateur leader
  • Région, ville, pays, coordonnées, organisation ASN et fuseau horaire estimés du leader
  • Mesures de ping de référence depuis les régions d'observation ERPC via pingToLeaders

Exemple d'endpoint et de corps de requête

text
https://edge.erpc.global?api-key=<YOUR_API_KEY>
Tous les paramètres sont facultatifs; omettre params, ou envoyer params: [], renvoie tous les validateurs qui dirigent un slot dans l'époque courante.
json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getValidatorsInformation",
  "params": []
}
Pour restreindre le résultat, envoyez un objet avec limit, country et region. Cet exemple demande jusqu'à 5 validateurs en Allemagne, ce qui coûte aussi moins cher que la requête sans filtre ci-dessus.
json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getValidatorsInformation",
  "params": [{ "limit": 5, "country": "DE" }]
}
Les trois paramètres sont facultatifs. country est comparé à leaderCountry à l'aide des codes ISO 3166-1 alpha-2, sans tenir compte de la casse. region est comparé à leaderRegion de manière exacte et sensible à la casse: lisez leaderRegion dans une réponse sans filtre pour connaître les valeurs valides des validateurs qui vous intéressent. limit accepte de 1 à 2000 et est ramené au nombre réel de validateurs de l'époque, de sorte qu'un limit supérieur au nombre réel ne provoque jamais d'erreur.

Exemple (HTTP)

bash
curl 'https://edge.erpc.global?api-key=<YOUR_API_KEY>' \
  --header 'Content-Type: application/json' \
  --data '{
    "jsonrpc":"2.0",
    "id":1,
    "method":"getValidatorsInformation",
    "params":[]
  }'

Exemple de réponse (JSON)

result.total indique combien de validateurs ont été renvoyés par cette requête. Le tableau data[] ci-dessous est abrégé à trois des 670 entrées de cette époque, et le pingToLeaders de chaque entrée est réduit à une seule région d'observation pour faciliter la lecture.
json
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "success": true,
    "message": "Validator information retrieved successfully",
    "epoch": 1010,
    "total": 670,
    "totalValidators": 670,
    "data": [
      {
        "identity": "JupmVLmA8RoyTUbTMMuTtoPWHEiNQobxgTeGTrPNkzT",
        "gossipNodeId": 2233,
        "slotCount": 13232,
        "stakeWeight": 12254651.761860535,
        "ipAddress": "64.130.41.46",
        "gossipPort": 8000,
        "tpuPort": 9001,
        "tpuQuicPort": 9007,
        "rpcAddress": null,
        "version": "3.1.13",
        "featureSet": "534737035",
        "leaderRegion": "frankfurt",
        "leaderCity": "Frankfurt am Main",
        "leaderCountry": "DE",
        "leaderLat": 50.1924,
        "leaderLon": 8.6753,
        "leaderOrg": "AS20326 TeraSwitch Networks Inc.",
        "leaderTimezone": "Europe/Berlin",
        "pingToLeaders": [
          {
            "city": "Frankfurt am Main",
            "region": "frankfurt",
            "ms": 0.974,
            "icmpReplied": true,
            "fromIp": "185.191.118.11",
            "country": "DE",
            "lat": 50.139,
            "lon": 8.6725,
            "org": "AS213896 UAB Cherry Servers",
            "postal": "60320",
            "timezone": "Europe/Berlin",
            "measuredAt": "2026-08-01T06:02:18.000Z"
          }
        ]
      },
      {
        "identity": "BSVckjdW2f8kcXPGcrPPtV9kUDBZ8w8PjrrGVnxgEdwq",
        "gossipNodeId": 1487,
        "slotCount": 2704,
        "stakeWeight": 2502391.138720913,
        "ipAddress": "5.199.172.175",
        "gossipPort": 12000,
        "tpuPort": 12003,
        "tpuQuicPort": 12009,
        "rpcAddress": null,
        "version": "3.1.13",
        "featureSet": "534737035",
        "leaderRegion": "stockholm",
        "leaderCity": "Šiauliai",
        "leaderCountry": "LT",
        "leaderLat": 55.93333,
        "leaderLon": 23.31667,
        "leaderOrg": "AS16125 UAB Cherry Servers",
        "leaderTimezone": "Europe/Vilnius",
        "pingToLeaders": [
          {
            "city": "Frankfurt am Main",
            "region": "frankfurt",
            "ms": 27.742,
            "icmpReplied": true,
            "fromIp": "185.191.118.11",
            "country": "DE",
            "lat": 50.139,
            "lon": 8.6725,
            "org": "AS213896 UAB Cherry Servers",
            "postal": "60320",
            "timezone": "Europe/Berlin",
            "measuredAt": "2026-08-01T06:02:53.000Z"
          }
        ]
      },
      {
        "identity": "2oHUYyW2PU9VJh4XBs5TbGgzdernunvGqyKth3kxW4ns",
        "gossipNodeId": 902,
        "slotCount": 304,
        "stakeWeight": 280745.689124988,
        "ipAddress": "64.130.43.229",
        "gossipPort": 8001,
        "tpuPort": 5004,
        "tpuQuicPort": 5010,
        "rpcAddress": null,
        "version": "3.1.13",
        "featureSet": "534737035",
        "leaderRegion": "amsterdam",
        "leaderCity": "Amsterdam",
        "leaderCountry": "NL",
        "leaderLat": 52.37403,
        "leaderLon": 4.88969,
        "leaderOrg": "AS20326 TeraSwitch Networks Inc.",
        "leaderTimezone": "Europe/Amsterdam",
        "pingToLeaders": [
          {
            "city": "Frankfurt am Main",
            "region": "frankfurt",
            "ms": 16.835,
            "icmpReplied": true,
            "fromIp": "185.191.118.11",
            "country": "DE",
            "lat": 50.139,
            "lon": 8.6725,
            "org": "AS213896 UAB Cherry Servers",
            "postal": "60320",
            "timezone": "Europe/Berlin",
            "measuredAt": "2026-08-01T06:03:07.000Z"
          }
        ]
      }
    ]
  }
}

Champs de réponse

ChampSignification
result.successIndique si la requête a réussi.
result.messageMessage de statut lisible par un humain.
result.epochÉpoque à laquelle appartient l'ensemble de leaders renvoyé. Il s'agit de l'époque la plus récente présente dans le calendrier des leaders.
result.totalNombre de validateurs dans data. C'est la quantité sur laquelle l'appel est facturé.
result.totalValidatorsNombre de validateurs leaders de cette époque avant l'application de country, region ou limit. Comparez-le à result.total pour voir dans quelle mesure un filtre a restreint l'ensemble.
result.data[]Une entrée par validateur, triée par slotCount décroissant puis par identity, de sorte qu'un limit renvoie les validateurs qui dirigent le plus de slots.
identityClé publique d'identité du validateur.
gossipNodeIdIdentifiant de l'enregistrement du nœud gossip lié à ce validateur. Il vaut null lorsqu'aucun nœud gossip n'est lié, auquel cas les champs d'emplacement, de ports et de ping sont également vides. Les validateurs sans nœud gossip lié sont renvoyés dans une requête sans filtre, mais ne peuvent pas correspondre à un filtre country ou region.
slotCountNombre de slots que ce validateur dirige dans l'époque indiquée. Chaque entrée couvre un validateur, pas un slot.
stakeWeightStake activé de l'identité du validateur, en SOL. Les validateurs sans nœud gossip lié rapportent 0.
ipAddress, gossipPort, tpuPort, tpuQuicPort, rpcAddressMétadonnées d'endpoint du réseau gossip du validateur.
version, featureSetVersion du client Solana et feature set rapportés par le validateur.
leaderRegionLibellé de région opérationnelle normalisé, utilisé pour le routage et l'analyse. Il peut regrouper des villes proches ou des emplacements de fournisseurs, et c'est la valeur à laquelle correspond le paramètre de requête region.
leaderCity, leaderCountry, leaderLat, leaderLon, leaderOrg, leaderTimezoneGéolocalisation et organisation réseau estimées du validateur.
pingToLeaders[]Latence de référence vers ce validateur depuis chaque région d'observation ERPC, avec région, ville, ms, icmpReplied, fromIp, pays, coordonnées, organisation ASN, code postal, fuseau horaire et measuredAt.
pingToLeaders[].icmpRepliedIndique si le validateur a répondu à la mesure. Lorsqu'il vaut false, ms contient une valeur sentinelle stockée et non une latence, et ne doit pas être lu comme telle.
pingToLeaders[].measuredAtDate de la dernière mesure de latence, au format ISO-8601 UTC. Utilisez-la pour juger de la fraîcheur d'un relevé.

Visualisation de la couverture des validateurs

La même réponse peut être lue comme une carte de couverture à l'échelle de l'époque plutôt que comme une consultation slot par slot. Cet exemple utilise Francfort comme point d'observation.
Région du validateurLieuSlots dans l'époquePoids de stakePing de FrancfortLecture opérationnelle
frankfurtFrankfurt am Main, DE13,23212,254,651.760.974 ms13,232 des quelque 432,000 slots de l'époque, dans la même métropole. La capacité de Francfort sert ce validateur pendant toute l'époque, et pas seulement pendant une fenêtre de slot.
stockholmŠiauliai, LT2,7042,502,391.1427.742 msUne part récurrente de l'époque, à une latence qu'un autre emplacement européen desservirait mieux.
amsterdamAmsterdam, NL304280,745.6916.835 msPeu de slots par époque. Le chemin est court, mais cela seul ne justifie pas d'y placer de la capacité.
getLeaderSlots répond à la question de savoir quels validateurs dirigent les prochains slots, ce qui convient pour router une transaction maintenant; cette méthode répond à la question de savoir quels validateurs dirigent l'époque dans son ensemble et à quelle fréquence, ce qui convient pour décider où placer la capacité pour l'époque.

Site Web des données du réseau Solana

Validators Solutions - Solana network data
Pour la vue publique de la distribution du réseau, utilisez Validators Solutions, puis getValidatorsInformation pour le nombre de slots par validateur, le stake, l'emplacement et la latence mesurée.

Utilisation des jetons

Cette méthode est facturée selon le nombre de validateurs qu'elle renvoie, par tranches de 10: chaque tranche de 10 validateurs coûte 100 jetons, et une tranche partielle compte pour une tranche entière. Une réponse de 95 validateurs est donc facturée comme 10 tranches, soit 1 000 jetons.
Comme la facturation suit ce qui est renvoyé plutôt que ce qui est demandé, restreindre l'ensemble avec country ou region coûte proportionnellement moins cher, et une requête qui ne correspond à aucun validateur ne coûte rien. Un limit supérieur au nombre de validateurs de l'époque est ramené au nombre réel, de sorte qu'une requête ne paie jamais pour des validateurs qui n'existent pas.
La taille de l'ensemble des leaders change d'une époque à l'autre. Dans l'époque présentée ci-dessus, elle était de 670 validateurs, ce qui situe une lecture complète à environ 6 700 jetons.

Pourquoi l'information sur les validateurs compte-t-elle?

  • Une ligne par validateur indique qui dirige cette époque et dans quelle mesure, sans agréger côté client des centaines de milliers de lignes de slots.
  • slotCount montre à quelle fréquence un validateur est leader dans cette époque: un chemin court vers un validateur à slotCount élevé est donc rentabilisé de façon répétée.
  • country et region montrent où se situe réellement la capacité des leaders de l'époque.
  • Le ping combiné à measuredAt distingue un chemin lent d'un relevé périmé.

Historique

Une époque Solana comprend environ 432 000 slots. Une fois les attributions de leader de ces slots regroupées par identité de validateur, elles se réduisent à environ 670 lignes de validateurs. ERPC maintient le calendrier des leaders, les métadonnées des validateurs, la géolocalisation et la collecte des latences, et expose le résultat via l'interface RPC.

Cas d'utilisation stratégique

  • Planification de capacité à l'échelle de l'époque: dimensionner l'infrastructure face à l'ensemble complet des validateurs qui dirigent l'époque courante, et non face à une fenêtre de slots glissante.
  • Listes restreintes régionales: utiliser country et region pour extraire les validateurs qui dirigent des slots dans un emplacement cible.
  • Priorisation fondée sur le nombre de slots et le stake: combiner slotCount et stakeWeight pour classer les validateurs au sein d'une liste restreinte.
  • Suivi entre époques: comparer la répartition de leaderRegion d'une époque à l'autre pour voir comment évolue la géographie des leaders.

Disponibilité

getValidatorsInformation est disponible pour tous les utilisateurs ERPC. Les tokens API et les crédits d'utilisation peuvent être émis ou vérifiés depuis le tableau de bord Web ERPC.

Taux de réussite des transactions et endpoint SWQoS

Pour améliorer encore le taux de réussite des transactions et la vitesse d'exécution, nous recommandons d'utiliser le SWQoS Endpoint. SWQoS (Stake-weighted Quality of Service) donne la priorité aux validateurs disposant de connexions pondérées par le stake. Les leaders attribuent environ 80 % de la bande passante au trafic prioritaire et 20 % au trafic non prioritaire, la voie prioritaire offrant un débit d'environ 5x. Cette allocation intervient avant l'évaluation des frais de priorité: l'accès à la voie prioritaire SWQoS est donc une condition préalable pour obtenir de vraies performances à faible latence.

Précédent

Documentation de l'API d'information sur les slots leaders

Suivant

Solana SWQoS Endpoint Documentation