Le réseau RPC d'Ankr dépasse 1 trillion de demandes mensuelles sur plus de 80 chaînes

Ankr, un fournisseur majeur d'infrastructure Web3, a annoncé cette semaine que sa plateforme RPC traite désormais plus de 1 trillion de requêtes par mois, une étape qui souligne à quel point une grande partie de l'activité blockchain passe par des infrastructures centralisées même si les applications essaient de se décentraliser. L'entreprise a présenté cette étape non pas comme un argument marketing, mais comme un instantané du trafic quotidien : tout, des vérifications de solde aux appels de rollup et aux extractions de bots MEV.

Les appels de procédure à distance (RPCs) sont les éléments essentiels de lecture/écriture des blockchains, la couche API entre les portefeuilles, les dApps et les flottes de nœuds qui détiennent réellement l'état. Selon Ankr, les plus grandes parts de ce gâteau de trillion de requêtes proviennent des portefeuilles et des interfaces, des indexeurs et des services d'analyse, des bots et des systèmes MEV, des rollups/L2 et des ponts (qui génèrent de nombreux appels inter-chaînes), et une longue traîne de dApps plus petites à travers plus de 80 réseaux.

Ces appels quotidiens comprennent des méthodes de lecture fréquentes, comme eth_call, eth_getBalance et eth_getBlockByNumber, avec des requêtes plus lourdes en plage et en journaux (eth_getLogs), des appels de traçage/débogage, des abonnements websocket pour les nouveaux blocs et les transactions en attente, et un volume d'écritures plus petit mais essentiel, comme eth_sendRawTransaction.

Que signifie-t-il ?

Atteindre un trillion de requêtes mensuelles impose des compromis : la fiabilité, la latence et le coût comptent tous lorsque les applications dépendent des données on-chain. Ankr affirme qu'il répond à ces pressions avec un mélange de réseau et d'ingénierie logicielle : anycast global et routage régional pour réduire la latence, équilibrage de charge conscient de la blockchain, flottes spécialisées ( séparant les lectures chaudes des chemins d'archive et de trace/debug/écriture ), modelage de taux et logique de basculement pondérée par méthode, plus une infrastructure sur mesure pour les clients d'entreprise avec un très haut débit. Le résultat, soutient l'entreprise, est une couche RPC capable de gérer à la fois le routinier, un portefeuille vérifiant un solde de compte, et le bursty, un système de rollup ou MEV martelant les points de terminaison.

Pour les développeurs, le message d'Ankr est pratique : vous verrez les meilleures performances si vous concevez vos applications pour être polies envers les RPC. Cela signifie utiliser la mise en cache, regrouper les appels, diriger le trafic vers des régions, respecter les poids des méthodes et surveiller l'utilisation par chaîne et par méthode. En résumé, optimisez la façon dont vous demandez des données autant que l'endroit où vous les obtenez.

Pourquoi cela importe-t-il ? Les RPC sont les points de blocage invisibles qui peuvent rendre ou briser l'expérience utilisateur. Pas de lectures de solde, pas d'échanges ; pas d'abonnements fiables, pas d'expérience utilisateur en temps réel. À mesure que de plus en plus d'utilisateurs et de services affluent vers les L2, les ponts et les portefeuilles multi-chaînes, le volume et la complexité du trafic RPC augmentent, tout comme le besoin d'une infrastructure évolutive et résiliente. La revendication d'Ankr d'un trillion de requêtes est donc moins un trophée qu'une métrique de la dépendance actuelle du Web3 à l'égard d'un petit nombre de fournisseurs d'infrastructure.

Le fil complet d'Ankr et l'analyse des types de trafic sont disponibles sur leur publication officielle. Les développeurs construisant sur Web3 feraient bien de considérer les RPC comme une partie essentielle de la planification de l'architecture, et non comme une réflexion tardive, car derrière chaque vérification de solde fluide ou chaque échange instantané se cachent des milliers de petits appels API qui doivent arriver et revenir en millisecondes.