Principe fondamental d’Internet : plus c’est proche, plus c’est rapide. Toujours, y compris sur Solana.
De nombreux traders et projets à la recherche de « l’environnement le plus rapide » commencent par examiner la latence moyenne.
Cette mesure peut servir de repère, mais si votre objectif est le trading zero-slot, c’est-à-dire une fenêtre de 200 à 400 ms, vous ne l’atteindrez jamais en vous fondant sur une moyenne.
Solana est répartie dans le monde entier et les communications intercontinentales ajoutent inévitablement des centaines de millisecondes.
Tant que vous vous concentrez sur une moyenne qui englobe ces délais, la vitesse dont vous avez réellement besoin restera hors de portée.
En pratique, le résultat se décide en gagnant quelques millisecondes dans votre propre région, là où les communications s’effectuent à courte distance.
Retrouver une intuition concrète de la vitesse
Pour comprendre un réseau, imaginez un trajet en voiture entre votre domicile et votre bureau. Un trajet court est simple et rapide, avec peu de risques d’accident ou d’embouteillage.
Un long parcours, à l’inverse, traverse des carrefours, autoroutes et tunnels ; sur l’aller-retour, un point d’encombrement est probable.
Internet fonctionne de la même manière. Plus le serveur est éloigné, plus le nombre de sauts augmente et plus le temps aller-retour varie. Rapprocher la destination constitue le chemin le plus direct vers la vitesse et la stabilité maximales.
Pourquoi une moyenne ne permet pas de gagner
Données du réseau Solana : Validators Solutions
Sur Solana, les leaders changent pour produire les blocs ; la proximité physique avec le leader actif détermine donc le résultat. Les leaders sont répartis dans le monde entier et se trouvent souvent sur des continents différents.
Le ping intercontinental dépasse 100 ms et la latence des streams atteint plusieurs centaines de millisecondes.
Vous aurez beau optimiser une moyenne qui inclut ces délais, elle ne reflétera pas les performances réelles. Lors des slots intercontinentaux, il est tout simplement impossible de rattraper ce retard.
Il ne faut donc pas poursuivre une moyenne, mais se concentrer sur sa propre région et y réduire les allers-retours. Se disputer quelques millisecondes à courte distance constitue la seule approche concrète qui procure un véritable avantage.
À titre de repère, voici quelques temps aller-retour indicatifs selon la distance :
| Distance | Ping aller-retour approximatif |
|---|---|
| Même réseau | ~0,1 ms |
| Connexion privée | ~0,2 ms |
| Même centre de données | ~0,3 ms |
| Même ville | ~1 ms |
| Pays voisin | ~5–10 ms |
| Intercontinental | ~100–300 ms |
La latence effective augmente encore selon la méthode de communication, en raison de la surcharge du protocole et des coûts de gestion :
| Méthode | Multiplicateur de latence | Remarques |
|---|---|---|
| Ping idéal | 1× | Limite basse de référence uniquement |
| POST, envoi unique | ~2–3× | Contrôle aller-retour, nouvelles tentatives, TLS |
| Stream | ~5× | Connexion persistante, contrôle de congestion, tampons |
Mesurer la « proximité »
La proximité se mesure avec des données, pas avec une intuition. Commencez par vérifier la position dans l’epoch en cours. La méthode RPC getEpochInfo fournit les dernières données de l’epoch ainsi que le nombre de slots écoulés et restants.
Utilisez ensuite getRecentPerformanceSamples pour estimer la durée moyenne récente d’un slot. Multiplier cette durée par le nombre de slots restants donne une estimation du nombre de secondes avant la transition, utile pour préparer les bascules.
À l’approche de la transition, préparez la récupération des leaders visés avec getSlotLeaders.
La liste des nœuds du cluster est disponible avec getClusterNodes. Vous pouvez donc recouper les leaders et les informations des nœuds, puis utiliser les adresses IP publiques ou gossip afin d’estimer leur localisation.
Attention : la géolocalisation IP présente des erreurs et du retard, et les estimations peuvent être fausses. Après avoir cartographié les emplacements, effectuez toujours des pings depuis chaque site pour mesurer directement les temps aller-retour de référence.
Un réseau ressemble à un trajet routier : la distance compte, mais l’itinéraire choisi modifie aussi l’heure d’arrivée. Le ping montre simplement le niveau d’encombrement actuel des « routes ».
Ne vous fiez pas à une seule mesure. Prenez plusieurs échantillons à intervalles courts et utilisez la médiane afin de réduire le bruit.
Conservez ensuite ces résultats. Accumulez dans votre propre base de données les mesures aller-retour et les correspondances de chaque site, puis mettez-les à jour progressivement avec des workers légers à chaque transition d’epoch. Les opérations deviennent plus stables et les décisions plus rapides.
L’emplacement de l’application détermine la latence
Les spécifications du serveur ne suffisent pas à déterminer la vitesse. L’emplacement de l’application compte tout autant.
À titre d’exemple extrême, surveiller depuis Tokyo ce qui se passe à Francfort est désavantageux. La seule latence aller-retour crée un retard cumulé qui place constamment l’application en retrait.
Déployez des ressources dans chaque site et effectuez localement la réception et le traitement, ou relayez vers le site suivant par le chemin le plus court. Cette architecture améliore la couverture et la réactivité.
Des VPS déployés sur le même réseau
Dans chaque région, nos instances VPS sont installées sur le même réseau que les endpoints dédiés à Solana. Elles réduisent les communications externes et obtiennent les allers-retours les plus courts.
Elles peuvent être déployées rapidement, à petite échelle. Même répartir des workers de 1 ou 2 cœurs entre les régions réduit la latence effective et limite les occasions manquées.
Lancement en septembre 2025 : SUPER EPYC VPS
À partir de ce mois-ci, en commençant par Francfort, la région la plus demandée, nous prévoyons de lancer SUPER EPYC VPS. Il utilise des processeurs de centre de données atteignant une fréquence de pointe sur le marché de 5,7 GHz.
Il est encore rare d’adopter les processeurs de dernière génération dans un produit VPS, ce qui limitera la disponibilité. Pour ceux qui recherchent le VPS le plus rapide, ce sera une option solide.
Pour la meilleure qualité et la plus grande vitesse : le bare metal
Un VPS divise un serveur physique en parties virtualisées. Un serveur bare metal vous réserve l’intégralité du processeur, de la mémoire, des disques et de la bande passante réseau.
Il maintient donc plus facilement des performances élevées et stables aux heures de pointe et convient aux applications Solana qui exigent une faible latence constante.
Pour les usages Solana, les processeurs Ryzen sont particulièrement demandés et atteignent, dans la catégorie grand public, jusqu’à 5,7 GHz. EPYC est conçu pour réduire la surcharge de virtualisation, tandis que Ryzen vise les meilleures performances sur une machine unique sans virtualisation. Choisissez selon votre usage.
Les défis auxquels ERPC répond
- Les échecs de transactions et les variations de latence courantes dans les environnements RPC standards
- Les limites de performances imposées par de nombreux fournisseurs d’infrastructure
- L’incidence importante de la distance réseau sur la qualité des communications
- L’accès limité des petits projets à une infrastructure de qualité
Les informations sur les produits, essais gratuits, étapes de démarrage, configurations dédiées, stocks et listes d’attente sont disponibles depuis l’ERPC Web Dashboard :
- Site officiel d’ERPC : https://erpc.global/fr
- ERPC Web Dashboard : https://dashboard.erpc.global/fr
Nous poursuivrons nos travaux de R&D, la stabilisation de l’approvisionnement et l’extension de la gamme afin d’apporter cette valeur à davantage de projets dans le monde.
Merci pour votre soutien continu.
