Mises à niveau du réseau Solana

Solana enregistre une forte croissance de ses utilisateurs et de son taux d’adoption, ce qui exige des améliorations stratégiques du réseau. L’équipe d’ingénierie de la Solana Foundation a conçu un ensemble complet de mises à niveau visant à renforcer l’infrastructure, améliorer les performances et optimiser l’expérience utilisateur. Ces mises à niveau ciblent les principaux points de congestion dans le traitement des transactions, la gestion de la bande passante et l’efficacité de la transmission des données, contribuant ainsi à l’état général du réseau Solana.

QUIC

Solana s’appuie actuellement sur un protocole personnalisé basé sur UDP brut pour transférer les transactions entre les nœuds Remote Procedure Call (RPC) et le leader en place. Si l’UDP offre une rapidité certaine, il s’agit d’un protocole sans connexion, dépourvu de contrôle de flux et d’accusé de réception, ce qui limite la capacité à dissuader ou à atténuer les comportements abusifs sur le réseau.

Pour remédier à ces limites, le protocole d’ingestion des transactions de Solana a été réimplémenté avec QUIC, un protocole développé à l’origine par Google. QUIC combine la rapidité de l’UDP avec la gestion de session et le contrôle de flux du TCP, permettant des communications asynchrones plus rapides et intégrant des mécanismes de gestion du trafic. Cette évolution permet aux opérateurs réseau d’adapter et d’optimiser plus efficacement l’ingestion des données.

Le protocole QUIC est désormais en production sur Mainnet-beta et adopté par la majorité des validateurs et opérateurs RPC. Après plusieurs versions successives, QUIC est devenu le protocole d’ingestion des transactions par défaut, remplaçant complètement UDP et s’imposant à l’échelle de l’écosystème Solana.

Stake-weighted QoS

La bande passante du leader est d’une capacité fixe, ce qui requiert des stratégies de gestion élaborées pour une utilisation optimale. Le précédent modèle d’acceptation des transactions fonctionnait selon le principe du premier arrivé, premier servi, sans tenir compte de la source, ce qui créait des inefficacités dans l’allocation de la bande passante.

Le Quality of Service (QoS) pondéré par la mise introduit l’équité selon la part de chaque nœud dans le réseau. Avec ce modèle, un nœud disposant de 0,5 % de la mise réseau est assuré de pouvoir transmettre au moins 0,5 % des paquets au leader, sans que les autres participants puissent collectivement supprimer ou outrepasser cette allocation. Cette approche s’appuie sur l’architecture proof-of-stake de Solana pour garantir des droits de transmission équitables.

Le Stake-weighted QoS a été développé en parallèle de QUIC et activé sur Mainnet-beta, assurant ainsi une répartition équitable de la bande passante sur l’ensemble du réseau et renforçant la robustesse du réseau Solana.

Fee markets

Après leur ingestion, les transactions continuent de rivaliser pour la modification de données de comptes partagées. Le système d’origine reposait sur une logique de premier arrivé, premier servi, sans permettre aux utilisateurs d’indiquer l’urgence ou la priorité par rapport à d’autres transactions visant les mêmes comptes.

Les fee markets introduisent une priorisation des transactions basée sur le marché, permettant aux utilisateurs d’ajouter des frais de priorité — paiements supplémentaires au coût de base — afin d’exprimer l’urgence de leur opération. Ces frais sont calculés selon les ressources de calcul nécessaires à l’exécution. Par exemple, un transfert de tokens simple entrainera des frais de priorité plus faibles que la création complexe d’un Non-Fungible Token (NFT) avec le même degré d’urgence.

La fonctionnalité fee markets est disponible sur Mainnet-beta, avec des travaux en cours pour renforcer les fonctionnalités RPC, l’intégration aux portefeuilles et des mécanismes avancés comme la tarification en paliers pour les comptes très sollicités ou l’optimisation des algorithmes de planification des blocs.

Augmentation de la taille des transactions

Les transactions Solana sont actuellement limitées à 1 232 octets, ce qui réduit la composabilité des programmes en limitant la quantité de données incluses dans une même transaction. Cette restriction devient problématique lors d’interactions entre programmes, lorsque des séquences complexes d’instructions excèdent l’espace disponible.

L’évolution du protocole QUIC permet désormais d’envisager une augmentation de la taille maximale des transactions. Les équipes d’ingénierie évaluent l’impact sur la performance réseau et définissent de nouveaux paramètres permettant d’équilibrer composabilité et efficacité, ce qui impacte directement l’état du réseau Solana.

Compact vote state

Les transactions de vote sont les plus fréquentes sur l’ensemble des nœuds du réseau. Le schéma de vote actuel exige une large allocation de bande passante et contribue fortement à la taille des blocs. Même une réduction modérée de la taille de l’état de vote peut améliorer significativement le réseau en diminuant le volume de données transmises et les besoins de stockage des validateurs.

L’optimisation compact vote state est en cours de test sur le Testnet de Solana. Cette évolution vise à réduire l’empreinte des transactions de vote tout en préservant l’intégralité du mécanisme de consensus.

Conclusion

L’initiative de mise à niveau du réseau Solana constitue une réponse globale aux défis de scalabilité et d’efficacité. Par des innovations dans la conception des protocoles (QUIC), l’allocation des ressources (Stake-weighted QoS), la tarification des transactions (fee markets), la capacité de données (taille des transactions) et l’optimisation du consensus (compact vote state), Solana consolide son infrastructure pour soutenir une croissance durable. Ces avancées permettent d’optimiser la bande passante, d’améliorer la priorisation des transactions et de réduire la charge globale du système, renforçant le réseau Solana pour accompagner l’adoption et la montée en charge tout en maintenant des niveaux élevés de performance et de sécurité.

FAQ

Le réseau Solana fonctionne-t-il actuellement ?

Oui, le réseau Solana est opérationnel et fonctionne normalement. Aucun incident ni interruption de service n’est signalé à ce jour.

Pourquoi le réseau Solana est-il congestionné ?

La congestion du réseau Solana s’explique par un volume élevé de transactions et des activités de bots spam qui saturent la blockchain. Avec l’augmentation de l’utilisation du réseau, les validateurs rencontrent des difficultés à traiter rapidement toutes les transactions, provoquant des délais. Les équipes de développement déploient des solutions afin d’accroître le débit et de réduire la congestion.

Pourquoi mon transfert Solana prend-il autant de temps ?

Les transferts Solana peuvent être ralentis par les délais de traitement des plateformes d’échange ou par la congestion du réseau. Les transactions directes sur la blockchain s’exécutent en général en quelques secondes. Si votre transfert implique une plateforme d’échange, ce sont le plus souvent leurs systèmes internes qui provoquent les retards, et non le réseau Solana.

Pourquoi le réseau Solana a-t-il subi une panne ?

Les pannes du réseau Solana résultent généralement d’une congestion extrême liée à un afflux massif de transactions. Le modèle de frais fixes peut provoquer une instabilité en cas de forte demande, induisant une dégradation temporaire des performances ou l’arrêt de validateurs.

Comment vérifier l’état du réseau Solana et ses indicateurs de fiabilité ?

Consultez status.solana.com pour suivre en temps réel la disponibilité et les performances du réseau. Utilisez les endpoints Solana RPC pour interroger l’état du réseau via les méthodes getHealth() ou getClusterNodes(). Surveillez le volume des transactions, les temps de slot et la participation des validateurs via les tableaux de bord et explorateurs officiels Solana.

Quelles sont les causes habituelles des ralentissements et pannes du réseau Solana ?

Les ralentissements et pannes du réseau Solana sont généralement dus à des bugs clients, à des inondations de transactions spam, à des arrêts de validateurs, à des partitions réseau ou à des blocages du consensus empêchant la production de blocs et la confirmation des transactions.