Avantages et optimisation d’une infrastructure Solana multirégionale

Nous rappelons régulièrement combien il est important de rester physiquement proche du validateur leader du moment. Solana étant toutefois répartie dans le monde entier et les leaders changeant sans cesse, concentrer toute son infrastructure dans une seule ville ne correspond pas à cette réalité. Une approche multirégionale prend donc tout son sens. Dans cet article, nous partons des epochs et du leader schedule, puis expliquons comment évaluer concrètement la « proximité » et intégrer cette décision aux opérations.

Solana fait avancer le temps par slots. Un slot dure environ 400 ms, et les slots sont regroupés en epochs. Un epoch comprend 432 000 slots, soit approximativement deux jours. La méthode RPC getEpochInfo permet d’en suivre la progression. Pour comprendre le rythme de traitement actuel du réseau et la vitesse à laquelle les slots avancent, getRecentPerformanceSamples est également utile. Le leader schedule est fixé au début de chaque epoch et, à tout instant, un seul leader produit le bloc. Cette rotation rapide impose une approche qui suit l’évolution de la distance à mesure que les leaders changent.

Dans l’histoire des infrastructures de trading, la proximité physique avec les principaux serveurs d’une place boursière a toujours constitué un avantage. On dit même que le prix d’un serveur varie selon la longueur du câble. La lumière est rapide, mais sa vitesse n’est pas infinie : une distance plus courte accélère aussi bien la réception que l’envoi. Le même principe vaut pour une blockchain, à une différence près : le point de production des blocs de Solana se déplace dans le monde entier. Lorsque le leader se trouve à New York, être proche de New York est avantageux ; lorsque le leader suivant est à Francfort, la proximité avec Francfort l’est à son tour. C’est pourquoi il faut préparer plusieurs emplacements plutôt qu’un seul point central.

Données du réseau Solana : Validators Solutions

Maintenez plusieurs points de présence de petite taille dans les principales villes de validateurs et aux grands points d’échange, puis utilisez automatiquement celui qui se trouve le plus près du leader actif. Lorsqu’un slot est produit à New York, recevez et envoyez depuis New York. Lorsque le leader suivant passe à Francfort, basculez immédiatement vers Francfort et transmettez par le chemin le plus court. L’objectif n’est pas d’améliorer une moyenne, mais d’éviter de manquer les occasions qui se présentent continuellement.

Les réseaux et serveurs partagés subissent l’activité des autres utilisateurs et deviennent souvent plus irréguliers aux heures de pointe. Des endpoints et serveurs dédiés dans plusieurs régions permettent de contourner la congestion et de faire circuler les données comme sur une voie express privée. La réception des streams est particulièrement sensible à la distance : l’installer au plus près sur des ressources dédiées produit une différence perceptible au quotidien. L’envoi ne se comporte lui aussi comme prévu que s’il part d’un point de présence proche par une route dédiée ; en étant le seul utilisateur, vous subissez moins les limitations et files d’attente d’une infrastructure partagée.

La proximité se décide à partir de données, pas d’une intuition. Commencez par situer le réseau dans l’epoch en cours. Utilisez getEpochInfo pour récupérer les données de l’epoch ainsi que le nombre de slots écoulés et restants. Servez-vous ensuite de getRecentPerformanceSamples pour estimer la durée moyenne récente d’un slot. Multiplier le nombre de slots restants par cette durée fournit une estimation du nombre de secondes avant le changement, ce qui facilite la préparation et la planification des bascules entre emplacements.

À l’approche du changement, récupérez les leaders de la plage visée avec getSlotLeaders afin d’identifier les candidats à court terme. getClusterNodes permet de lister les nœuds du cluster. Recoupez l’identité du leader avec ces données, puis utilisez son adresse IP publique ou son adresse gossip pour estimer sa zone géographique.

Une précaution s’impose : la géolocalisation d’une adresse IP peut être erronée ou obsolète. Après avoir dressé une première carte, lancez donc des pings depuis chacun de vos points de présence afin de mesurer directement la latence aller-retour de référence. Un réseau ressemble à un trajet routier : la distance compte, mais l’itinéraire emprunté modifie l’heure d’arrivée. Le ping fournit un indicateur simple de l’encombrement actuel des « routes ». Ne vous fiez pas à une seule mesure ; effectuez plusieurs pings légers sur une courte période et retenez la médiane afin de réduire le bruit.

Conservez les résultats. Enregistrez dans votre propre base de données les mesures et correspondances de chaque point de présence, puis faites mettre à jour les écarts par un worker léger à chaque changement d’epoch. Les opérations quotidiennes deviennent ainsi plus stables et les décisions plus rapides.

Recalculer systématiquement toutes les données revient à consacrer sa vitesse à la mesure elle-même. En pratique, stockez dans votre base de données la correspondance entre leaders et régions, ainsi que la latence de chaque point de présence. Mettez ces informations à jour avec un worker à chaque limite d’epoch. L’application d’exécution peut alors lire cette base et choisir instantanément le point de présence approprié. Placez la réception près de la source du stream et préparez légèrement en avance l’envoi dans la région du prochain leader. Cette séparation des rôles réduit la latence totale.

Dans chaque point de présence, utilisez des processeurs à haute fréquence, de la mémoire DDR5 et des SSD NVMe récents, tout en maintenant une faible utilisation habituelle. Ces réglages locaux constituent le socle qui rend l’architecture multirégionale efficace. À l’échelle globale, placez les endpoints dédiés et les serveurs dans le même réseau afin de maximiser la « communication à distance nulle », sans passage par l’Internet public. Pour les relais entre points de présence, des liaisons dédiées réduisent souvent le temps de bascule par rapport à des routes génériques passant par un RPC public.

Recevez près du leader et envoyez près du leader. Puisque cette proximité change sans cesse, répartissez votre infrastructure entre plusieurs régions. Il suffit d’un mécanisme léger pour suivre le dernier leader schedule et d’une implantation judicieuse des points de présence. En tant que concepteurs, nous pouvons vous accompagner concrètement pour raccourcir les allers-retours des données : conception de la base et des workers, choix des emplacements, préparation d’endpoints dédiés et bascule entre les villes.

Pour suivre les nouveautés ou poser vos questions, rejoignez l’ERPC Web Dashboard. Des essais gratuits et des environnements de test sont disponibles. ERPC Web Dashboard : https://dashboard.erpc.global/fr

Merci, comme toujours, pour votre confiance. Nous poursuivons nos essais sur le terrain et nos améliorations avec transparence afin de contribuer à la réussite de votre projet.