Solana vient de résoudre son plus grand problème de données, selon le PDG de Helius

Helius affirme avoir repensé la façon dont les données historiques de Solana sont stockées et récupérées, en introduisant un nouveau backend d'archivage et une méthode RPC qui transforme les flux de travail multi-appels actuels en une seule requête.

Le PDG Mert Mumtaz a présenté ce changement en termes radicaux : "aujourd'hui, Solana change pour toujours... nous avons résolu le plus grand problème de données/RPC existant", a-t-il écrit, soutenant que le statu quo—les requêtes historiques utilisant Google Bigtable—a été "lent", "coûteux" et "inflexible".

Ce que cela signifie pour Solana

Mumtaz a souligné le problème pratique que connaît chaque développeur d'indexeur ou de portefeuille Solana : obtenir la "première transaction pour une adresse Solana sans boucler indéfiniment" et extraire les "100 transactions les plus récentes pour une adresse" nécessitent tous deux un enchaînement d'appels et de traversées qui peuvent se multiplier en "milliers d'appels RPC". "Ce n'est plus le cas", a déclaré Mumtaz.

Au cœur de cette version se trouve une méthode RPC exclusive à Helius, getTransactionsForAddress, soutenue par une couche de stockage d'archives distribuée que l'entreprise affirme être "1 000 fois plus rapide, plus flexible et plus évolutive". Fonctionnellement, la méthode fusionne le modèle courant en deux étapes d'aujourd'hui—getSignaturesForAddress pour énumérer les signatures, puis getTransaction pour hydrater les détails—en un seul appel qui peut renvoyer des transactions entièrement décodées, avec un ordre temporel bidirectionnel et des filtres de plage par slot ou horodatage.

La documentation de Helius précise qu'elle permet une recherche inverse sans traversée arrière et prend en charge la pagination adaptée aux comptes actifs et volumineux. L'entreprise souligne également qu'il ne s'agit pas d'un ajout RPC central de Solana ; c'est une extension propriétaire disponible sur les nœuds Helius, au prix de 100 crédits par requête sur les plans Developer et supérieurs. Les affirmations de performance couvrent à la fois la nouvelle méthode et les points de terminaison existants, Helius affirmant que getBlock, getTransaction et getSignaturesForAddress sont maintenant "10 fois plus rapides", tandis que le système d'archivage sous-jacent offre les améliorations de débit annoncées pour les requêtes historiques.

Le cadrage vise clairement à éliminer les pics de latence liés à Bigtable et à réduire le nombre d'appels par "100x" avec "10x moins de latence" et "1000x moins de code". Ces affirmations correspondent aux plaintes courantes des développeurs documentées sur les forums Solana concernant l'hydratation historique lente sur les adresses occupées, mais les chiffres précis ici sont les propres références de Helius.

Le contexte stratégique est important. L'activité on-chain de Solana continue de s'orienter vers des cas d'utilisation de consommation et de paiements à haut débit, qui pénalisent les modèles d'accès aux données inefficaces.

Le lancement a eu lieu le même jour que le premier ETF spot Solana américain est devenu actif sur le NYSE—le BSOL de Bitwise. Selon l'analyste senior d'ETF de Bloomberg, Eric Balchunas, BSOL a enregistré un volume de 56 millions de dollars le premier jour. "Les 56 millions de dollars de BSOL représentent le PLUS important lancement de cette année... Plus que XRPR, SSK, Ives et $MNU. Et ce qui est étonnant, c'est qu'il a été amorcé avec 220 millions de dollars. Il aurait pu investir cette somme dès le premier jour, ce qui aurait donné environ 280 millions de dollars, ce qui serait encore plus que les débuts d'ETHA. Un démarrage solide dans tous les cas", a écrit Balchunas.

Autre élément de contexte macroéconomique : Western Union a annoncé son intention d'introduire un stablecoin adossé au dollar, USDPT, sur Solana, émis par Anchorage Digital Bank, avec une disponibilité prévue pour le premier semestre 2026.

Au moment de la publication, SOL s'échangeait à 195 $.