Solana, en ce moment
Comment être plus rapide sur Solana ?
Si vous développez sur Solana, vous vous êtes forcément déjà fait l’une de ces réflexions.
Même stratégie que le desk voisin — mais mon bot est le seul à se faire exécuter en retard.
Le prix s’affiche. J’envoie. Et ma transaction ne passe pas.
J’ai testé tous les fournisseurs RPC — et rien n’y fait.
Ce que le réglage, même de pro,
Le code est optimisé. La machine est musclée. Aucun des deux n’est le vrai goulot — vous courez après un leader qui se déplace sans cesse, et de bien trop loin.
À eux seuls, le matériel et le code ne gagnent pas le slot. Ce qui le gagne, c’est le timing et l’emplacement.
La vitesse, ça s’achète. Comprendre, c’est ce qui fait la différence.
Voir comment arriver le premier
La cible mouvante
Le meilleur point d’où frapper ne reste jamais en place.
À chaque slot — les ~400 ms dont dispose Solana pour produire un block — c’est un autre validator qui devient leader, et c’est le plus proche qui l’emporte.
Près d’un point fixe, on peut s’installer une fois pour toutes. Sur Solana, le meilleur emplacement n’est jamais deux fois le même.
~400 ms · un nouveau leader à chaque slot
Le meilleur emplacement, slot après slot
Le leader fait le tour du monde, slot après slot. Vous en gagnez un, le suivant est déjà ailleurs.
Le voir se déplacer
Solana RPC amélioré, Geyser gRPC et Shredstream
Epoch —
— countries
Leader
—
Producteur de blocs en direct
La distance, c’est de la latence
Traversez un continent, et vous voilà avec 100–300 ms de retard.
La lumière dans la fibre et les routeurs qu’elle traverse fixent un plancher qu’aucun matériel ne franchira. Dans le même rack, comptez 0.1 ms. D’un océan à l’autre, c’est 100–300 ms — alors qu’un slot ne dure qu’environ 400 ms.
Quand le leader est à votre porte, vous êtes dans les temps ; quand il est à l’autre bout du globe, c’est déjà raté. Être rapide à chaque slot, c’est être proche partout où le leader se pose.
Plancher d’aller-retour selon la distance · de la physique, pas un benchmark
Ce que la distance coûte à un paquet
- Même réseau
- 0.1 ms
- Même datacenter
- 0.3 ms
- Même ville
- 1 ms
- Pays voisin
- 5–10 ms
- D’un continent à l’autre
- 100–300 ms
À un continent de distance, on paie des centaines de fois un saut dans le même rack — soit plus qu’un slot entier. La proximité, ce n’est pas un réglage : c’est le budget tout entier.
Couverture — pourquoi une seule ville ne suffit pas
Même la ville la plus dense ne pèse qu’environ un quart du réseau.
Francfort, c’est là que les opérateurs se concentrent — et pourtant, même la ville la plus dense ne réunit qu’environ un quart du réseau, en validators comme en stake. Pour la plupart des slots, le leader actif est ailleurs.
Tout couvrir, c’est l’idéal ; le budget impose un choix. La vraie question n’est donc pas seulement de savoir qui pèse le plus lourd, mais où s’entassent le moins de machines — l’endroit le moins saturé. Amsterdam affiche un stake comparable à celui de Francfort avec bien moins de validators entassés — souvent l’emplacement le plus calme, et le meilleur.
Où se trouvent les validators de Solana
Couverture — un nœud déjà aux côtés de chaque leader
Où que se pose le leader, un nœud puissant, en lien direct avec Solana est déjà sur place.
Le rôle de leader fait le tour du globe slot après slot — celui qui l’emporte, c’est le nœud déjà au plus près. Un nœud dans la même région évite le long trajet qui ajoute du délai.
Voilà pourquoi nous ne misons pas sur un seul endroit. Une vitesse régulière, c’est être proche à chaque slot — et comme le leader passe sans cesse d’une région à l’autre, cela exige une couverture région par région. Nous déployons des nœuds de niveau validator là où le stake de Solana se concentre, sur un même réseau à faible latence, et nous ajoutons des régions en continu — chaque nouvelle région, ce sont autant de slots de plus où vous êtes déjà aux côtés du leader.
Global Data Center Partner
La vitesse est déterminée par la distance jusqu'à Solana.
La région compte. Mais le nom d'une ville ne constitue pas à lui seul un chemin de réseau. Même dans la même ville, le transit externe et les sauts supplémentaires peuvent ajouter de la latence. ERPC sélectionne les centres de données proches des serveurs Solana, puis maintient des itinéraires courts, sans transit externe et avec une accélération soutenue.
Route premium ERPC
Pas de transit extérieur
minimum RTT
Choix basé sur le nom de la ville
transit externe / 7 sauts
70x plus lent
- 01Même centre de donnéesChoisissez d'abord la région, puis le centre de données le plus proche de Solana.
- 02Pas de transit extérieurÉvitez les chemins AS externes pour garder un RTT et un jitter serrés.
- 03Pleins gazERPC exclut les profils d'économie d'énergie et maintient les ressources en turbo boost durable.
Priorité pondérée par le stake (SWQoS)
Si vos transactions échouent encore et encore, c'est que vous êtes coincé dans la voie du spam.
Les leaders de Solana répartissent la bande passante prioritaire en deux. Les connexions adossées à du stake — du SOL engagé auprès d’un validator — en reçoivent 80%. Tous les autres se disputent les 20% restants — la voie engorgée de spam.
Foncer droit sur le leader semble le geste le plus rapide — mais sans stake, vous tombez dans la voie bondée des 20 %, et en pleine charge votre transaction n’est jamais incluse dans le block.
La vraie réponse est donc simple : un validator staké. Nous en opérons un de tout premier plan, raccordé à des lignes RPC de haute qualité — du matériel posté juste à côté de Solana — pour que vos transactions empruntent la voie large.
Un validator de premier plan dans notre Shinobi Performance Pool
Comment les leaders de Solana répartissent la bande passante prioritaire
Le stake file par la voie large des 80 % jusqu’au validator — avant même tout frais. Sans stake, vous êtes à l’étroit dans la voie du spam des 20 %.
Répartition 80 / 20 décidée par les leaders de Solana, pas par nous
Benchmark mesuré
Machine de même classe. Pas la même vitesse.
AMD Turin, 4 vCPU, Amsterdam, Ubuntu 24.04 — à l’identique sur les deux machines, celle d’un grand cloud et la nôtre. Sur le papier, elles se valent. Au banc d’essai, c’est une autre histoire.
Même silicium. Tout l’écart vient de notre réglage — une machine peaufinée dans le moindre détail et installée juste à côté de Solana.
node_bench · même run, même région
ERPC vs un grand cloud · spec identique
- Calcul CPUsysbench · 4 threads · plus c’est haut, mieux c’est
- de débit CPU en plus1.9×
- Bande passante mémoireSTREAM Triad · 4 GiB · plus c’est haut, mieux c’est
- de bande passante mémoire en plus3.2×
- IOPS disquefio · 4K randread · QD32 · plus c’est haut, mieux c’est
- d’IOPS disque en plus16.6×
- Latence disque · p99fio · 4K randread · QD32 · plus c’est bas, mieux c’est
- plus rapide sur les pics de latence25.7×
events/s
MB/s
IOPS
µs
Tout l’environnement, au plus haut niveau.
ERPC optimise chaque couche entre vous et le slot — RPC, streaming, validators, le bare metal en dessous — et installe l’ensemble à côté de Solana. Auparavant, c’était à vous de tout assembler. Désormais, il vous suffit de combiner nos produits — la ligne la plus directe vers Solana.