ERPC étend l’API Solana Leader Slot avec la mesure du ping depuis 7 régions du monde — l’API Validators Information est également lancée
ERPC étend l’API Solana Leader Slot avec la mesure du ping depuis 7 régions du monde — l’API Validators Information est également lancée
ELSOUL LABO B.V. (Siège : Amsterdam, Pays-Bas ; PDG : Fumitake Kawasaki) et Validators DAO, les opérateurs d’ERPC, ont renforcé les API permettant de connaître les informations des leaders de Solana, leurs localisations estimées et la latence : l’API Leader Slot prend désormais en charge le RTT de référence (mesure du ping) depuis 7 régions du monde, et la nouvelle API Validators Information est lancée.
Tout d’abord, nous avons étendu l’API Leader Slot (
getLeaderSlots) afin de pouvoir obtenir le RTT de référence depuis 7 régions d’observation ERPC à travers le monde (Frankfurt, Amsterdam, New York, Londres, Tokyo, Singapour et Sydney). Auparavant, les mesures étaient effectuées depuis Frankfurt uniquement.Parallèlement, nous avons lancé la nouvelle API Validators Information (
getValidatorsInformation). Cette API liste, en un seul appel, tous les validateurs détenant au moins un leader slot dans l’epoch en cours. Outre le nombre de slots et le stake actif, elle retourne, lorsque ces informations sont disponibles, la localisation estimée, les endpoints réseau, la version du client et le RTT de référence des 7 régions.Ces deux API sont disponibles pour tous les utilisateurs d’ERPC via l’interface JSON-RPC standard.
- Documentation de l’API Leader Slot : https://erpc.global/en/doc/rpc/leader-slot-api/
- Documentation de l’API Validators Information : https://erpc.global/en/doc/rpc/validators-information-api/
La différence avec l’infrastructure de trading traditionnelle : dans Solana, la destination des communications change dynamiquement
Dans les bourses et systèmes financiers traditionnels, les destinations auxquelles les ordres sont envoyés — la bourse, la passerelle, le moteur de matching — sont généralement fixées à des centres de données ou des réseaux spécifiques.
Par conséquent, une fois la destination de connexion connue, l’utilisateur peut optimiser en continu son chemin réseau vers elle. Comme les emplacements des serveurs cibles ne changent pas fréquemment, le placement de l’infrastructure et les routes de communication peuvent être conçus de manière relativement statique.
Dans Solana, en revanche, le leader — le validateur responsable de la production des blocs — tourne tous les quelques slots selon le calendrier des leaders. Les validateurs servant de leaders étant répartis dans le monde entier, la destination que vos transactions doivent atteindre et le chemin réseau le plus proche de cette destination changent continuellement.
Autrement dit, dans Solana, la destination de communication à optimiser ne peut pas être traitée comme un point de connexion unique et fixe.
Il faut d’abord identifier les leaders actuels et futurs à partir du calendrier des leaders. Ensuite, il faut vérifier dans quelle région ou quel réseau chaque validateur est le plus susceptible de se trouver, et quelle est la latence depuis chaque point d’envoi, avant de décider de la route d’envoi.
Comprendre correctement cette structure est le point de départ de l’envoi de transactions à faible latence et de la conception d’une infrastructure mondiale sur Solana.
Traiter le calendrier des leaders et les positions réseau comme des données
Dans un environnement où la destination change dynamiquement, il n’est pas pratique qu’une personne vérifie le leader et le point d’envoi à chaque fois et change les routes manuellement.
Ce qu’il faut, c’est obtenir en continu les informations suivantes et les intégrer dans la logique de décision des applications et de l’infrastructure.
- Les leaders responsables des slots actuels et à venir
- Le nombre de slots dont chaque validateur est responsable
- Le pays, la ville et la région estimés de chaque validateur
- Les endpoints réseau tels que TPU et QUIC
- Le RTT de référence collecté depuis chaque région d’observation
- L’heure de chaque mesure et son état de réponse
La localisation estimée et la latence mesurée jouent chacune un rôle différent.
Les informations de localisation peuvent servir à des décisions à moyen et long terme sur l’emplacement de l’infrastructure et de la capacité. Le RTT de référence de chaque région, quant à lui, permet de juger quel point est actuellement le plus susceptible d’offrir un chemin court.
Un lieu physiquement ou géographiquement proche n’est pas toujours le plus court sur le réseau. C’est pourquoi il est important de décider en combinant la localisation estimée et les valeurs réellement observées.
L’API Leader Slot et l’API Validators Information d’ERPC sont des API conçues pour vous permettre de programmer ces décisions sur la base des données.
API Leader Slot : mesure du RTT de référence depuis 7 régions du monde
L’API Leader Slot retourne les prochains leader slots avec l’identité du validateur, le stake actif, les endpoints réseau, la localisation estimée, le RTT de référence, etc.
Jusqu’à présent, les mesures
pingToLeaders étaient collectées uniquement depuis l’origine de Frankfurt — un point d’observation unique face à un réseau Solana distribué à l’échelle mondiale.Avec cette mise à jour, vous pouvez désormais obtenir le RTT de référence mesuré depuis les 7 régions suivantes.
frankfurtamsterdamnylondontokyosingaporesydney
En comparant le RTT de référence des 7 régions d’observation pour chaque leader, vous pouvez juger quel point d’envoi est le plus susceptible d’offrir un chemin réseau court.
Cela sert de base de décision non seulement pour le routage des transactions, mais aussi pour décider dans quelles régions placer de la capacité pour les RPC, gRPC, Direct Shreds, les serveurs d’envoi de transactions, etc.
Les résultats de mesure incluent
icmpReplied, qui indique si le validateur a répondu à l’ICMP, et measuredAt, qui indique l’heure de la dernière mesure réussie.Un validateur qui ne répond pas à l’ICMP peut néanmoins faire fonctionner normalement des services tels que TPU et QUIC. C’est pourquoi, lorsque
icmpReplied vaut false, il faut le traiter non comme « distant » mais comme « non mesurable par ICMP ».De plus, lorsqu’une mesure réussie ne peut pas être obtenue au moment de l’actualisation, l’entrée n’est pas écrasée par une valeur non mesurée — la dernière valeur mesurée avec succès et son heure de mesure sont conservées.
API Validators Information : liste des informations des leaders sur l’ensemble de l’epoch
L’API Leader Slot convient aux décisions au niveau du slot — « qui est le leader responsable des prochains slots ? »
Le placement de l’infrastructure et la planification de capacité exigent, eux, une vue plus large.
- Quels validateurs servent de leaders dans l’epoch en cours
- De combien de slots chacun est responsable
- Dans quels pays et régions ils sont répartis
- Où placer l’infrastructure pour se rapprocher d’un plus grand nombre de leaders
La nouvelle API Validators Information (
getValidatorsInformation) est l’API conçue pour répondre à ces questions.Appelée sans paramètres, elle retourne tous les validateurs servant de leader pour au moins un slot dans l’epoch en cours, une ligne par validateur. Par défaut, les résultats sont retournés par ordre décroissant du nombre de leader slots détenus.
Chaque ligne comprend les informations suivantes.
slotCountstakeWeight(stake actif en SOL)- Identité du validateur
Lorsque ces informations sont disponibles, les éléments suivants sont également retournés.
- Région, ville et pays estimés
- Endpoints réseau
- Version du client
- RTT de référence des 7 régions
Les données étant actualisées régulièrement, appeler l’API périodiquement maintient votre ensemble de données de planification à jour.
Vous pouvez également restreindre les résultats avec les paramètres optionnels
limit (1–2000), country et region.La facturation est calculée en fonction du nombre de validateurs retournés. Le nombre de validateurs leaders varie d’une epoch à l’autre ; dans l’exemple au moment de la rédaction, la récupération des 673 validateurs consomme 6,800 tokens d’API (crédits d’utilisation de l’API ERPC), et la récupération de jusqu’à 10 validateurs consomme 100 tokens d’API.
Vers un routage programmable fondé sur les données
Ces API ne sont pas simplement destinées à afficher une liste de validateurs ou le RTT de référence.
L’objectif final est de vous permettre d’intégrer le calendrier des leaders, les localisations estimées des validateurs et le RTT de référence de chaque région d’observation dans la logique de décision de vos applications.
Par exemple, une application peut récupérer le prochain calendrier des leaders, comparer le RTT de référence des 7 régions d’observation pour chaque leader, puis sélectionner le RPC ou la route d’envoi de transactions à utiliser.
Vous pouvez également analyser la répartition des leaders sur l’ensemble de l’epoch et placer l’infrastructure à l’avance dans des régions proches des validateurs à fort nombre de slots.
Les principaux cas d’usage sont les suivants.
- Sélection de routes d’envoi au niveau du slot
- Planification de capacité au niveau de l’epoch
- Analyse des validateurs leaders par région
- Priorisation tenant compte du stake actif et du nombre de slots
- Surveillance des changements de répartition géographique et réseau d’une epoch à l’autre
- Sélection automatique parmi des serveurs RPC et d’envoi déployés dans plusieurs régions
Dans Solana, où la destination change dynamiquement, l’optimisation statique du réseau ne suffit pas à elle seule.
Il devient important de suivre en continu le leader changeant et de sélectionner dynamiquement les routes d’envoi et l’infrastructure en fonction de sa localisation et des conditions du réseau.
Vers une infrastructure Solana conçue pour l’exploitation mondiale
ERPC est une infrastructure haute performance pour Solana, conçue dès le premier jour pour l’exploitation mondiale.
Notre réseau edge, nos offres bare metal et VPS, Direct Shreds, Geyser gRPC, les endpoints SWQoS et ces API d’intelligence opérationnelle sont tous fournis au service d’un objectif commun.
Cet objectif est de fournir à la fois données et infrastructure aux développeurs qui exigent une exécution à faible latence et efficace dans un environnement où utilisateurs et leaders sont répartis dans le monde entier.
Le RTT de référence depuis 7 régions du monde et les informations des validateurs sur l’ensemble de l’epoch sont désormais accessibles via de simples appels RPC. Les applications Solana peuvent maintenant sélectionner points d’envoi et routes réseau sur la base des données, en réponse au leader en constante évolution.
Pour les développeurs qui recherchent un envoi à faible latence, un placement d’infrastructure mondial et une optimisation dynamique du routage sur Solana, il s’agit d’une base de décision directement liée à l’exploitation réelle.
Nous espérons que cela vous aidera à sélectionner des routes d’envoi à faible latence, à concevoir une infrastructure réduisant les transferts inutiles sur de longues distances et à planifier le placement mondial de la capacité.
Pour plus de détails, consultez la documentation.
- API Leader Slot : https://erpc.global/en/doc/rpc/leader-slot-api/
- API Validators Information : https://erpc.global/en/doc/rpc/validators-information-api/
- Tableau de bord Web ERPC : https://dashboard.erpc.global/en
Actualités
