ERPC met en production le chemin rapide XDP et le zero-copy de Solana v4 pour les nœuds RPC et les nœuds Geyser gRPC dans toutes les régions — en étendant la preuve de NY à chaque région et en rehaussant à la fois la livraison du flux et la fraîcheur de l'état RPC

ELSOUL LABO B.V. (siège : Amsterdam, Pays-Bas ; CEO : Fumitake Kawasaki) et Validators DAO, qui exploitent ERPC, ont le plaisir d'annoncer qu'ERPC a mis en production le chemin rapide XDP et le zero-copy AF_XDP de Solana v4 (Agave 4.x) pour les nœuds RPC et les nœuds Solana Geyser gRPC dans toutes les régions. Cela étend l'optimisation d'abord éprouvée sur la source du Geyser gRPC de la région New York (NY) à l'infrastructure de production de chaque région.

Le chemin rapide XDP et le zero-copy AF_XDP sont des optimisations orientées Turbine devenues disponibles dans Solana v4 (Agave 4.x). En ce qui concerne les flags de lancement, la lignée Agave 4.1 a déprécié la famille --experimental-retransmit-xdp-* et les a organisés en --xdp-interface / --xdp-cpu-cores / --xdp-zero-copy. En s'appuyant sur ce chemin rapide XDP et ce zero-copy orientés Turbine, ERPC les a appliqués en production non seulement aux nœuds source qui alimentent le Geyser gRPC, mais aussi aux nœuds RPC. Les nœuds RPC comme les nœuds Geyser gRPC reçoivent via Turbine les shreds qui composent les blocs. En utilisant XDP et le zero-copy pour réduire la surcharge du noyau sur ce chemin de propagation et d'ingestion des shreds, le Geyser gRPC voit une latence de livraison du flux plus courte, tandis que le RPC voit une meilleure fraîcheur de l'état et une meilleure capacité à suivre l'état le plus récent. Cette évolution est déjà en service en production dans toutes les régions. Les clients qui privilégient la performance de first-arrival peuvent essayer dès maintenant le RPC et le Geyser gRPC toutes régions — via la facturation horaire (à l'heure) ou Crypto Pay (SOL / USDC / EURC).

Site officiel ERPC : https://erpc.global/fr Tableau de bord ERPC : https://dashboard.erpc.global/fr

Sur Solana, le leader chargé de la production des blocs change selon un cycle court, si bien que l'origine de la communication est toujours en mouvement. Dans cette structure, ce qui compte en pratique n'est pas d'être proche d'un point fixe unique, mais d'avoir une forte probabilité d'être proche du réseau où se concentrent les principaux nœuds et validateurs — et cela influe directement sur la latence, les taux de retransmission et les taux d'échec en exploitation réelle. C'est pourquoi ERPC estime qu'il est pertinent non pas de rendre rapide une seule machine, mais de hisser les nœuds de production de chaque région au même niveau.

La clé de ce déploiement réside dans le fait que la cible de l'optimisation est le « chemin de propagation et d'ingestion des shreds sur Turbine ». Pour le RPC comme pour le Geyser gRPC, la vitesse ultime repose sur « la rapidité avec laquelle un nœud peut saisir un bloc ». XDP et le zero-copy sont des optimisations qui réduisent la surcharge précisément à cette étape de saisie — la réception, le retransmit et la propagation des shreds via Turbine. En appliquant cela aux nœuds de production de chaque région, quel que soit le point de connexion régional qu'un client utilise, celui-ci peut recevoir des données sur un chemin optimisé.

XDP (eXpress Data Path) est une technologie du noyau Linux qui permet à du code réseau hautes performances de contourner une grande partie du chemin habituel de traitement des paquets du noyau. En réduisant les copies de données et les changements de contexte, il traite les paquets avec une surcharge bien moindre que la pile réseau standard.

Dans Agave (le client validateur de Solana), XDP est appliqué à Turbine, le protocole qui propage les blocs entre les nœuds validateurs. Les shreds reçus sont traités par un programme eBPF attaché au plus près de la carte d'interface réseau (NIC) et mappés dans des buffers de l'espace utilisateur via AF_XDP. Lorsque le mode zero-copy est utilisé, les données reçues sont transmises directement du noyau à l'espace utilisateur sans copie. Les shreds sortants tirent eux aussi parti du chemin d'envoi AF_XDP pour réduire les copies et la surcharge des appels système sur le chemin critique.

Anza a introduit XDP pour Turbine dans la lignée Agave 3.x (à partir de v3.0.9) et l'a transposé dans les fondations de Solana v4 (Agave 4.x). Les flags de lancement ont été organisés au fil des versions successives : la lignée Agave 4.1 a déprécié la famille --experimental-retransmit-xdp-* et les a organisés en --xdp-interface / --xdp-cpu-cores / --xdp-zero-copy. Selon le guide de configuration d'Anza, avec XDP, les grands validateurs peuvent approcher les 150 000 paquets sortants par seconde grâce au fanout de Turbine.

Anza Agave XDP Setup Guide : https://www.anza.xyz/blog/agave-xdp-setup-guide

Le Geyser gRPC est le chemin qui permet de recevoir les mises à jour de comptes, de slots, de blocs et de transactions sous forme de flux plutôt que par interrogation (polling). Ici, une différence d'une milliseconde est directement liée à la capture des opportunités d'exécution et à la vitesse perçue côté front-end. La latence de Geyser repose en fin de compte sur « la rapidité avec laquelle la source peut saisir un bloc ».

XDP et le zero-copy sont précisément les optimisations qui réduisent la surcharge de ce chemin de propagation et d'ingestion des shreds côté source. À mesure que la source peut recevoir et propager les shreds plus rapidement, elle peut observer et reconstruire les blocs à un stade plus précoce, ce qui raccourcit la latence avec laquelle ces mises à jour parviennent aux clients via le flux Geyser gRPC. Dans la région New York (NY), où nous l'avons appliqué en premier, nous avons confirmé, par une mesure open source, que cette optimisation est efficace dans la région de queue de la latence de livraison. Nous avons à présent étendu la même optimisation aux nœuds Geyser gRPC de chaque région.

Ce qui est nouveau dans ce déploiement, c'est que nous avons appliqué cette optimisation aux nœuds RPC également. Les nœuds RPC reçoivent eux aussi via Turbine les shreds qui composent les blocs et mettent à jour leur propre registre et leur propre état. Lorsque XDP et le zero-copy réduisent la surcharge de cette ingestion et de cette propagation des shreds via Turbine, les nœuds RPC peuvent ingérer plus tôt des blocs plus récents.

Pour les clients qui utilisent le RPC, il ne s'agit pas d'une accélération uniforme de toutes les méthodes RPC, mais cela se manifeste comme la fraîcheur de l'état que détient le nœud. Lorsque vous interrogez le slot ou le bloc le plus récent, ou l'état le plus récent d'un compte, le fait que les informations déjà ingérées par le nœud soient plus récentes est directement lié à la fraîcheur des données dans la réponse. De plus, une surcharge moindre sur le chemin de propagation et d'ingestion se traduit par une marge de manœuvre permettant au nœud de traiter les mises à jour sans en perdre sous forte charge. La même optimisation que celle de la livraison du flux Geyser gRPC sert aussi de fondation qui soutient la fraîcheur des données renvoyées par le RPC — telle est la raison pour laquelle nous avons cette fois étendu la portée aux nœuds RPC.

ERPC a migré les nœuds RPC et les nœuds Geyser gRPC de toutes les régions vers Solana v4 (Agave 4.x) et a mis en production le chemin rapide XDP orienté Turbine et le zero-copy AF_XDP. En s'appuyant sur le schéma de flags de lancement --xdp-interface / --xdp-cpu-cores / --xdp-zero-copy organisé dans la lignée Agave 4.1, nous l'activons selon la configuration propre à chaque région.

Activer XDP exige un réglage avancé et sujet à erreur : un noyau récent, un NIC compatible XDP, les bonnes capabilities systemd pour le processus validateur, des flags de lancement corrects et un épinglage (pinning) approprié des cœurs CPU. Déployer cela non pas sur un seul nœud mais sur les nœuds de production de chaque région — tout en vérifiant la configuration NIC, noyau et réseau différente de chaque région — accroît encore la difficulté opérationnelle. ERPC applique directement le savoir-faire opérationnel acquis en exploitant des validateurs au sommet du réseau à la construction et à l'exploitation des nœuds source et des nœuds RPC de chaque région.

Et le savoir-faire opérationnel relatif à cette optimisation est consolidé sous forme de recette dans SLV, l'outil open source d'exploitation Solana. SLV fournit l'ensemble, de l'activation de XDP (via des variables de configuration telles que xdp_enabled / xdp_zero_copy) à la mesure de la latence de livraison (slv check geyserbench), sous une forme que chacun peut reproduire au moyen de conversations avec un agent IA ou via la CLI. L'optimisation qu'ERPC a réalisée dans toutes les régions n'est pas une astuce ponctuelle pour une seule machine, mais repose sur une recette opérationnelle reproductible.

SLV GitHub : https://github.com/validatorsDAO/slv

L'ampleur de la différence que produit cette optimisation varie selon l'origine de la connexion, la route, l'heure de la journée et la répartition des leaders. C'est précisément pour cela qu'ERPC attache de l'importance à démontrer la qualité de livraison non pas par des affirmations subjectives ou des slogans marketing, mais par une mesure que chacun peut vérifier avec la même méthode. Ce que les clients peuvent vérifier n'est pas un chiffre figé, mais la méthode de mesure elle-même.

Pour le Geyser gRPC, l'outillage de benchmark d'ERPC est open source. Pour les comparaisons de first-arrival, vous pouvez utiliser slv check geyserbench --kind grpc, et pour les contrôles de connectivité et de latence d'un endpoint individuel, slv check grpc, en comparant dans des conditions proches de votre propre charge de travail. Pour le RPC également, l'approche la plus fiable consiste à mesurer et à observer la fraîcheur des données renvoyées et le comportement des réponses depuis votre propre point de connexion, en utilisant les requêtes que votre propre bot ou application envoie réellement.

Pouvoir prendre des décisions sur la base de chiffres que vous avez mesurés vous-même, plutôt que sur les affirmations d'un fournisseur, est le point de départ pour les clients qui privilégient la performance de first-arrival. Les étapes, de l'installation de SLV à l'exécution de la mesure, sont publiées dans le guide SLV Getting Started.

Site officiel SLV : https://slv.dev/fr SLV Getting Started : https://slv.dev/fr/doc/general/getting-started/ Comparaison de vitesse Solana Geyser gRPC : https://erpc.global/fr/doc/geyser-grpc/speed-comparison/

L'avantage de latence d'ERPC ne provient pas de la seule optimisation logicielle. En plaçant les nœuds source, les endpoints de réception et les nœuds de traitement au sein de centres de données premium où les validateurs Solana sont densément concentrés, ERPC supprime la latence due à la distance dès l'étape de conception.

ELSOUL LABO exploite un centre de données dédié Solana sous son propre ASN (AS200261), attribué par le RIPE NCC, dans le cadre de la plateforme ERPC. Les optimisations logicielles comme celles d'aujourd'hui, XDP et zero-copy, ne déploient leur effet maximal que sur la base de cette conception de proximité physique et réseau. Avec à la fois la proximité au niveau de la conception et l'optimisation logicielle côté nœud en place, on obtient la performance de first-arrival, une qualité de streaming à faible latence et des réponses RPC fraîches.

Ce déploiement sur toutes les régions s'inscrit dans la lignée de renforcement de l'infrastructure qu'ERPC poursuit en continu. Il s'agit de l'optimisation de dernière génération, faisant suite à la mise à niveau de l'infrastructure Geyser gRPC toutes régions en décembre 2025, au renforcement à grande échelle de la région Frankfurt (FRA) en janvier 2026, et à l'application antérieure de XDP et du zero-copy dans la région New York (NY) en juin 2026. L'optimisation éprouvée à NY a désormais été étendue — avec l'ajout des nœuds RPC à sa portée — à l'infrastructure de production de chaque région.

Plutôt que de répondre à une demande croissante par des limitations ou une dégradation, ERPC l'absorbe systématiquement en renforçant l'infrastructure elle-même. Nous continuons de répercuter les optimisations de dernière génération dans notre infrastructure de production tout en vérifiant à plusieurs reprises les NIC, noyaux et configurations réseau compatibles. Le RPC et le Geyser gRPC d'ERPC continueront d'évoluer.

Le RPC et le Geyser gRPC d'ERPC peuvent être essayés dès une seule heure via le plan de facturation horaire. Cela rend possible une boucle de vérification à faible risque : souscrire pour une seule heure, confirmer le comportement réel tel qu'il est observé depuis le point de connexion de votre propre bot ou application au cours de cette heure, et décider du passage à un plan mensuel ou annuel en fonction des résultats. Les mesures slv check décrites ci-dessus peuvent être exécutées telles quelles au sein de cet essai d'une heure.

Une fois votre configuration et votre usage clarifiés, passer à un plan mensuel ou annuel vous maintient sur le même tableau de bord et la même qualité d'endpoint.

Tableau de bord ERPC : https://dashboard.erpc.global/fr

ERPC propose Crypto Pay pour l'achat de crédits ERPC et pour le paiement de ses plans, et il est pris en charge pour le plan de facturation horaire également. Vous pouvez choisir SOL, ou les stablecoins USDC / EURC, comme actif de paiement. EURC peut être envoyé directement, tandis que USDC ou SOL est échangé en EURC via Orca, le transfert étant finalisé au sein du même flux.

Pour les équipes qui développent et exploitent sur Solana, pouvoir gérer les coûts d'infrastructure d'une manière proche de leur flux existant de gestion de fonds basé sur le portefeuille est une amélioration pratique qui réduit la friction pour démarrer la vérification. La vérification par facturation horaire décrite ci-dessus peut elle aussi être lancée directement à partir des actifs de votre portefeuille Solana.

ERPC vous permet de combiner Solana RPC, WebSocket, Solana Geyser gRPC, Solana Shredstream, Direct UDP Stream (Raw Shreds), VPS, serveurs bare-metal, RPC dédié, SWQoS, une Price API compatible Pyth, ainsi que Jet Analytics & Indexed RPC sur une seule plateforme.

Le tableau de bord ERPC prend en charge 16 langues, vous permettant de gérer la sélection du plan, le choix de la région, la vérification des stocks, l'ajout au panier, le rechargement de crédits, le paiement, la consultation des clés API et des endpoints, le suivi de l'usage et la création de tickets de support — le tout depuis le même écran.

Derrière ERPC se trouve la recherche et le développement de l'infrastructure dédiée Solana qu'ELSOUL LABO poursuit sans relâche. ELSOUL LABO a été approuvé cinq années consécutives depuis 2022 dans le cadre du WBSO, le programme gouvernemental néerlandais de soutien à la R&D. Il poursuit la R&D sur l'infrastructure Solana RPC, l'exploitation de validateurs, la livraison de données en temps réel et l'assistance à l'exploitation et au développement par agents IA, et ces résultats se reflètent dans l'ensemble des services, y compris ERPC, SLV, SLV AI et le centre de données dédié Solana AS200261.

La prise en charge de Solana v4 / XDP / zero-copy d'aujourd'hui dans toutes les régions a elle aussi pris forme à partir de l'exploitation de validateurs au sommet du réseau. ERPC continuera de fournir une infrastructure à faible latence proche du réseau Solana et de démontrer sa qualité par une mesure que chacun peut vérifier avec la même méthode.

Pour les configurations régionales optimales incluant le RPC et le Geyser gRPC toutes régions, le choix entre les plans gRPC autonomes et les plans gRPC Bundle, le choix entre la facturation horaire, mensuelle et annuelle, et la conception de la migration à partir d'une configuration existante, nous proposons une consultation individuelle sur le Discord officiel de Validators DAO.

Tableau de bord ERPC : https://dashboard.erpc.global/fr Site officiel ERPC : https://erpc.global/fr Discord officiel Validators DAO : https://discord.gg/C7ZQSrCkYR

Nous remercions sincèrement tous nos utilisateurs pour leur fidélité à ERPC.