ERPC modernise en profondeur son infrastructure réseau Solana et déploie sans interruption son proxy Rust dans toutes les régions
ERPC, exploité par ELSOUL LABO B.V. (siège : Amsterdam, Pays-Bas ; PDG : Fumitake Kawasaki) et Validators DAO, a achevé une modernisation majeure de son infrastructure réseau Solana.
Cette mise à niveau est déjà appliquée à toutes les régions et à tous les endpoints partagés d’ERPC — Solana RPC, Geyser gRPC et Shredstream. Nous avons traité comme un système intégré les comportements d’infrastructure qui influent directement sur les résultats réels : ouverture des connexions, traitement TLS, contrôle du cache, transports HTTP/1.1 et HTTP/2, connexions de longue durée, métriques d’observabilité et diagnostic.
Tout en préservant la réactivité au quotidien, nous avons réorganisé le comportement réseau sous-jacent afin de limiter les biais et l’instabilité dans les situations où les résultats se dégradent souvent : volatilité pendant les pics, instabilité sous exploitation prolongée, ou cascades déclenchées par les déconnexions et reconnexions. L’environnement est ainsi mieux structuré pour maintenir à la fois performances et stabilité dans l’exploitation réelle de Solana.
Nous sommes également passés à une architecture permettant d’appliquer les changements de configuration réseau et les mises à niveau de plateforme sans interruption. Les prix, spécifications, mécanismes d’authentification et limites de débit restent inchangés ; les clients ERPC bénéficient de la mise à niveau sans modifier leur configuration ni leurs opérations.
Historique
Dans l’exploitation réelle de Solana, le temps de réponse moyen et la latence en situation normale sont des exigences fondamentales. Mais lors des concentrations de charge, des connexions de longue durée ou des phases de déconnexion et de reconnexion, le comportement même de l’infrastructure réseau sous-jacente peut déterminer les résultats.
Les endpoints partagés doivent notamment absorber à la fois des rafales d’envoi de transactions sur de courtes périodes et des connexions permanentes WebSocket et gRPC. Ouverture des connexions, handshakes TLS, transport, gestion du cache et sortie des états inactifs se reflètent alors directement dans l’expérience utilisateur et les résultats d’exécution.
Même avec une bonne réactivité moyenne, d’autres facteurs peuvent déterminer les résultats pendant les pics ou l’exploitation prolongée. Il faut donc réunir facilité d’utilisation au quotidien et continuité dans les scénarios les plus exposés aux défaillances.
ERPC a conçu et exploite sa propre plateforme proxy haute performance en Rust comme socle des communications Solana. Son architecture applique la même approche dans toutes les régions tout en faisant évoluer continuellement la plateforme. Cette mise à niveau reprend comme un seul système les problèmes observés en exploitation, de l’ouverture des connexions au fonctionnement de longue durée, et réorganise en conséquence l’ensemble du socle réseau.
Ce qui change pour les clients d’ERPC
Cette mise à jour stabilise d’abord le comportement à l’ouverture des connexions. Pendant l’établissement de la connexion, y compris TLS, les incohérences et tentatives inutiles sont moins probables, ce qui permet aux transactions et aux flux d’entrer plus sûrement dans le traitement dès le départ.
Nous avons ensuite réorganisé les comportements susceptibles de devenir volatils sous forte charge. Le filtrage précoce des connexions inutiles s’accompagne d’une mise à jour cohérente des transports et délais HTTP/1.1 et HTTP/2, de l’état du pool de connexions, du cache en contention et des métriques d’observabilité et de diagnostic. L’ensemble limite les biais, même lorsque la charge se concentre.
La continuité s’améliore pour les flux WebSocket et gRPC de longue durée ainsi que pour les charges de supervision permanentes. Les déconnexions, reconnexions et resynchronisations sont moins fréquentes et moins susceptibles de se répercuter sur les résultats, ce qui facilite une exploitation fondée sur un fonctionnement continu.
L’amélioration du cache et du transport réduit également les nouvelles récupérations inutiles et le gaspillage de calcul en cas de congestion. La bande passante et la marge de traitement restent plus facilement disponibles et stables, tandis que l’enrichissement des métriques et de l’observabilité accélère l’identification des causes et le rétablissement.
La possibilité d’appliquer les changements de configuration et les mises à niveau sans interruption permet aussi d’améliorer plus fréquemment les performances, la stabilité et la qualité globale de la plateforme. Continuer à progresser sans arrêter le service renforce encore la continuité offerte aux clients.
Détails des améliorations
Cette mise à niveau n’est pas présentée comme une release articulée autour de noms de fonctionnalités ou de numéros de version. Elle décompose les scénarios qui déterminent souvent les résultats réels sur Solana — ouverture des connexions, TLS, frontière L4/HTTP, transports H1/H2, cache, observabilité, comportement en cas d’échec et prérequis d’exploitation prolongée — puis aligne ces couches sans contradiction.
Nous détaillons ci-dessous les améliorations intégrées sous l’angle de leur contribution à l’expérience client et aux résultats opérationnels.
Améliorations de l’ouverture des connexions et du traitement TLS
Nous avons enrichi le contexte TLS géré pendant l’établissement d’une connexion et adapté la structure afin de conserver et d’appliquer correctement l’état nécessaire. Le risque d’incohérence et de tentatives inutiles au démarrage s’en trouve réduit.
Nous avons également réorganisé le traitement TLS, y compris la vérification des certificats et des noms d’hôte, afin de satisfaire les exigences de sécurité tout en réduisant les échecs de handshake et les incohérences susceptibles de perturber l’ouverture des connexions. Cette amélioration contribue à stabiliser tout le parcours, de l’ouverture de la connexion au traitement des charges Solana.
Nous avons également renforcé l’observation et le diagnostic des comportements liés à TLS. Lorsque l’ouverture d’une connexion détermine le résultat, la qualité de l’expérience dépend de la capacité à reproduire un problème, à en identifier la cause et à appliquer rapidement un correctif.
Préserver la marge par le filtrage précoce des connexions inutiles
Nous avons introduit un filtrage précoce des connexions TCP afin que les connexions illégitimes ou inutiles pèsent moins sur le trafic légitime. Sur les endpoints partagés, les demandes de connexion peuvent bondir sous l’effet de facteurs extérieurs ou de déséquilibres temporaires.
Le filtrage précoce réduit le risque que les connexions légitimes restent bloquées au démarrage et aide à préserver une marge disponible pendant les pics. Il limite ainsi les déséquilibres lorsque la charge se concentre et favorise une distribution stable de la latence.
Clarifier le modèle de connexion en réorganisant la frontière L4/HTTP
L’infrastructure réseau ne s’arrête pas à HTTP. L’établissement et la continuité des connexions dépendent des conditions L4, dont la volatilité se propage à l’expérience des protocoles de niveau supérieur.
Nous avons abstrait le traitement des flux L4 et réorganisé la structure afin de gérer plus explicitement le modèle de connexion. La plateforme peut ainsi conserver un comportement régulier lorsque le nombre de connexions augmente, que les implémentations clientes diffèrent et que les longues durées d’exécution provoquent des transitions d’état.
Le comportement des nouvelles tentatives a lui aussi été revu pour éviter qu’une volatilité passagère se répercute sur l’expérience utilisateur. La stabilité réelle dépend moins de la suppression de toute panne isolée que de la prévention des cascades.
Amélioration des transports HTTP/1.1 et HTTP/2 et du comportement à long terme
Nous avons ajouté des mesures cohérentes du volume transféré sur HTTP/1.1 et HTTP/2. Elles facilitent la localisation des blocages et des goulets d’étranglement dans la chaîne de transport, ce qui accélère à la fois le diagnostic et l’application des correctifs.
Nous avons aussi revu les délais d’écriture du corps HTTP/2 afin de réduire les blocages anormaux sous charge concentrée ou pendant les flux de longue durée. Sur le long terme, l’essentiel n’est pas la performance de pointe dans un état idéal, mais la capacité à éviter l’effondrement du comportement pendant les transitions d’état.
Les délais d’inactivité et la gestion du pool de connexions ont également été revus afin d’éliminer les facteurs d’instabilité qui s’accumulent lors d’une exécution prolongée. Côté HTTP/1.1, nous avons réorganisé l’arrêt sûr des connexions contenant des requêtes incomplètes, ce qui réduit la volatilité de l’utilisation des ressources et du comportement.
Amélioration du contrôle des caches et de la qualité opérationnelle
Nous suivons mieux les raisons pour lesquelles un élément n’est pas mis en cache, ce qui rend le comportement du cache plus explicable. En pratique, l’enjeu n’est pas seulement l’existence du cache, mais les conditions dans lesquelles il s’applique ou cesse de s’appliquer.
Nous avons revu les verrous, la gestion des données périmées et la revalidation afin d’éviter qu’une contention pendant un pic ne provoque une cascade de dégradation. Les contrôles d’éviction lorsque le nombre d’éléments augmente et le traitement du contenu partiel, dont les requêtes Range, ont aussi été affinés pour limiter les récupérations inutiles et la latence sous charges réelles.
Ces améliorations limitent les comportements aberrants du cache et évitent davantage aux clients de devoir concevoir leur exploitation autour d’incertitudes liées à l’infrastructure.
Amélioration du comportement en cas d’échec, de la journalisation et de l’observabilité
Le comportement en cas d’échec et la journalisation ont été réorganisés pour faciliter la compréhension des incidents. Les cascades où une erreur en aval perturbe le cache ou le transport et dégrade l’expérience sont réduites, ce qui aide à circonscrire le périmètre d’impact.
Les améliorations d’observabilité et de diagnostic ne prétendent pas éliminer tout incident, mais en raccourcir le temps de rétablissement. Elles réduisent ainsi le risque pendant les pics et l’exploitation prolongée.
Mises à jour des dépendances et correctifs de sécurité comme prérequis d’exploitation à long terme
Nous avons intégré des mises à jour de dépendances et des correctifs de sécurité afin de préserver les prérequis d’une exploitation durable. Ces travaux comprennent l’évolution de la version minimale de Rust prise en charge (MSRV) et l’alignement de la CI, renforçant le socle nécessaire à l’évolution continue de la plateforme.
La capacité de se tenir à jour en toute sécurité est elle-même une exigence de qualité à long terme.
Passage à une exploitation sans interruption
Auparavant, les changements de configuration réseau et les mises à niveau de plateforme pouvaient occasionner une brève interruption. Cette mise à jour instaure une architecture qui permet de les appliquer sans aucune interruption.
Les endpoints partagés maintiennent des connexions permanentes et traversent continuellement des instants où le timing compte. Même une brève interruption peut déclencher des cascades de déconnexion, de reconnexion et de resynchronisation dont le coût se répercute sur les résultats. Les mises à jour sans interruption réduisent ce risque et évitent de fragmenter les opérations de longue durée.
ERPC dispose désormais de conditions opérationnelles permettant de transformer rapidement les problèmes observés en améliorations. Une fréquence d’itération plus élevée aide à éliminer en continu la volatilité et les cas limites en production.
Impact par service
Solana RPC (HTTP / WebSocket)
Les améliorations de l’ouverture des connexions, de TLS, du cache et du transport concernent à la fois la lecture des données et l’envoi des transactions. Tout en préservant l’usage quotidien, elles réduisent les facteurs qui biaisent les résultats pendant les pics et renforcent la marge disponible en cas de congestion.
Geyser gRPC
La continuité des connexions de streaming de longue durée a progressé. Transport HTTP/2, cohérence des délais, état du pool de connexions et mesures de transport étendues agissent ensemble pour limiter la propagation des coûts de reconnexion et de resynchronisation dans les résultats.
ShredStream (Direct Shreds)
La gestion des connexions et l’amélioration de leur ouverture, conçues pour une diffusion continue, réduisent le risque de données manquantes ou de hausse de latence en cas de congestion. Il devient ainsi plus facile de maintenir une détection et un suivi continus.
R-D et opérations de production
Le socle de systèmes distribués dont ERPC fait partie est reconnu comme projet de R&D dans le cadre du programme néerlandais WBSO. Les problèmes observés en exploitation peuvent ainsi devenir des sujets de recherche, puis donner lieu à des améliorations validées de façon itérative.
Cette mise à jour du socle réseau constitue l’une de ces itérations. Déployée dans toutes les régions, elle se traduit par des gains concrets de performance et de stabilité. Maintenir le lien entre exploitation et R&D permet de convertir continuellement les observations de production en nouvelles mises à jour au lieu de s’arrêter à une amélioration ponctuelle.
Dans ERPC, les usages réels, les variations de charge et le comportement lors des défaillances alimentent des cycles répétés de vérification et d’amélioration qui élèvent progressivement la qualité du socle réseau. Cette mise à jour a été menée dans ce cadre unifié de R&D et d’exploitation en production.
Informations pour les clients
Cette mise à jour est déjà appliquée à toutes les régions et à tous les endpoints partagés. Les clients existants d’ERPC n’ont rien à changer à leur configuration ou à leurs opérations. Tarifs, spécifications, authentification et limites de débit restent inchangés.
Les endpoints partagés devant absorber à la fois des pics brefs et des connexions de longue durée, leur comportement a été réorganisé pour rester régulier sous ces charges mixtes. Les changements de configuration et les mises à niveau sont appliqués sans interruption ; les clients n’ont donc pas à prévoir de fragmentation des connexions ni de resynchronisation imposée par l’architecture.
Pour toute question sur l’architecture, l’optimisation d’une charge particulière ou un retour d’exploitation, contactez le Discord officiel de Validators DAO.
En intégrant continuellement les observations de production et les retours aux améliorations, ERPC a progressivement renforcé la qualité de son socle. Nous continuerons à faire évoluer ce socle sans interruption et à fournir une infrastructure réseau qui soutient les résultats réels sur Solana.
Discord officiel de Validators DAO : https://discord.gg/C7ZQSrCkYR
Site officiel d’ERPC : https://erpc.global/fr
