Pour gagner ne serait-ce que 20 ms sur une application Solana, les endpoints RPC dédiés associés à SWQoS sont essentiels
Dans le trading haute fréquence et les applications Solana critiques, même 20 ms peuvent faire une différence décisive. La conception des endpoints RPC dédiés diffère fondamentalement de celle des endpoints RPC partagés, et cet écart de 20 ms ne pourra jamais être comblé. Cet article en explique les raisons et montre comment ERPC résout le problème de bout en bout.
Gagner 20 ms en utilisant HTTP au lieu de HTTPS
Vous avez sans doute remarqué que les URL des endpoints RPC commencent généralement par https. Le « s » correspond au chiffrement TLS/SSL, qui sécurise les communications. Ce chiffrement nécessite cependant une négociation initiale ainsi que des opérations permanentes de chiffrement et de déchiffrement, ce qui ajoute environ 20 ms de latence à chaque requête.
Autrement dit, effectuer les communications RPC en http plutôt qu’en https permet de supprimer ces 20 ms à la source. Sur Solana, où les enchères de blocs se règlent en environ 50 ms, cette différence est déterminante.
Pourquoi HTTP ne peut pas être utilisé sur les endpoints partagés
On pourrait alors se demander pourquoi ne pas autoriser HTTP sur les endpoints partagés. La réponse est simple : ce n’est pas possible.
Autoriser HTTP dans un environnement partagé reviendrait à transmettre les données sans chiffrement, exposant les transactions aux attaques de l’homme du milieu, à l’interception de paquets, voire au vol de transactions signées. Un attaquant utilisant le même endpoint partagé pourrait réellement altérer ou rejouer vos transactions.
C’est pourquoi les endpoints partagés doivent toujours imposer TLS/SSL. Nos endpoints RPC partagés sont conçus pour être aussi rapides que possible dans cette contrainte, mais le surcoût de 20 ms lié à TLS ne peut pas être supprimé par conception.
Comment un RPC dédié élimine ces 20 ms
Les endpoints RPC dédiés limitent l’accès à des clients de confiance précis. Nous pouvons donc supprimer l’obligation d’utiliser TLS et autoriser des communications HTTP directes.
Le résultat est une réduction garantie de 20 ms. Quels que soient la charge des utilisateurs ou les risques d’attaque, cette différence structurelle garantit que l’écart de 20 ms entre endpoints partagés et dédiés ne disparaîtra jamais.
L’autre enjeu : SWQoS
La vitesse ne suffit pas. Solana applique la qualité de service pondérée par le stake (SWQoS), selon laquelle les nœuds qui ne bénéficient pas d’une confiance fondée sur le stake sont limités à seulement 20 % des voies de transactions disponibles.
Les architectures Lite-RPC qui envoient les transactions directement au validateur leader actif peuvent, par exemple, sembler rapides. Sans SWQoS, elles restent toutefois limitées à cette voie de 20 %. Même si le paquet arrive rapidement, son taux d’inclusion sera donc sensiblement inférieur.
Utiliser un RPC dédié pour gagner 20 ms est essentiel, mais l’associer à SWQoS l’est tout autant pour obtenir à la fois rapidité et réussite des transactions.
ERPC propose une option permettant d’activer SWQoS sur les endpoints RPC dédiés.
Vous pouvez ainsi associer RPC dédié + SWQoS pour réduire la latence tout en augmentant le taux de réussite.
En savoir plus sur SWQoS : https://solana.com/developers/guides/advanced/stake-weighted-qos
Les problèmes auxquels Validators DAO et ERPC répondent
ERPC répond aux problèmes suivants :
- Les échecs de transactions et les variations de latence dans les environnements RPC
- Les limitations de performances imposées par de nombreux fournisseurs d’infrastructure
- La forte incidence de la distance réseau sur la qualité des communications
- L’accès limité à une infrastructure de qualité pour les petits projets
En développant Epics DAO, un projet open source de contribution à Solana, nous avons mesuré la difficulté de construire un environnement de développement Solana réellement performant et à faible latence. Cette difficulté nous a conduits à concevoir notre propre plateforme, qui sert aujourd’hui de base à ERPC comme à SLV.
Les applications financières et autres applications critiques sont particulièrement sensibles à la latence et aux erreurs, car celles-ci influent directement sur l’expérience utilisateur. Les environnements Solana sont très complexes et, contrairement aux systèmes financiers traditionnels sur Internet, leurs validateurs sont répartis dans le monde entier. Cette organisation, ajoutée aux connaissances propres au Web3, rend difficile pour les développeurs d’appréhender l’ensemble du système et a ralenti les progrès de l’optimisation.
En proposant une infrastructure Solana performante, nous souhaitons lever ces obstacles et améliorer l’expérience utilisateur dans tout l’écosystème. ERPC et notre projet open source SLV font tous deux partie intégrante de cette mission.
- Site officiel d’ERPC : https://erpc.global/fr
- Site officiel de SLV : https://slv.dev/fr
- Site officiel d’Epics DAO : https://epics.dev/fr
- Discord officiel de Validators DAO : https://discord.gg/C7ZQSrCkYR
