Qualité de service pondérée par le stake : tout ce que vous devez savoir

Introduction

Solana est à l’avant-garde de la technologie blockchain avec un réseau à haut débit et faible latence, qui repousse les limites de ce qu’un réseau décentralisé peut accomplir. Cela pose toutefois des défis importants. L’un des moments charnières du développement de Solana a été sa panne du 30 avril 2022, qui a souligné la nécessité de mécanismes plus robustes pour gérer de grands volumes de transactions et maintenir les performances du réseau sous forte charge.

La qualité de service pondérée par le stake (Stake-Weighted Quality of Service, SWQoS) a été créée en réponse à cet événement. Ce mécanisme donne la priorité au trafic réseau en fonction du stake détenu par les validateurs, afin que ceux qui en détiennent davantage puissent envoyer des transactions avec une priorité supérieure. SWQoS a été conçue pour empêcher les validateurs disposant d’un faible stake de saturer le réseau, renforçant ainsi la résilience et l’efficacité de Solana.

Cet article présente SWQoS, le modèle de traitement des transactions de Solana et l’influence de SWQoS sur ce modèle. Il aborde également les connexions stakées, leur configuration et la différence entre SWQoS et les frais de priorité. Enfin, il examine les conséquences futures, notamment l’importance croissante des validateurs et des jetons de staking liquide (LST), les barrières à l’entrée et les hypothèses de confiance inhérentes à ce système.

Cet article suppose que vous connaissez le modèle de programmation de Solana et QUIC. Si ces sujets ne vous sont pas familiers, nous vous recommandons de lire d’abord les articles suivants avant de poursuivre :

• Le modèle de programmation de Solana : introduction au développement sur Solana
• Comment atténuer rapidement le spam : tout ce que vous devez savoir sur Solana et QUIC

Nous fournissons néanmoins le contexte nécessaire chaque fois que cela s’impose.

Qu’est-ce que la qualité de service pondérée par le stake ?

La qualité de service pondérée par le stake (Stake-Weighted Quality of Service, SWQoS) est un mécanisme qui donne la priorité au trafic réseau en fonction du stake détenu par les validateurs. Il permet aux validateurs disposant de davantage de stake d’envoyer des transactions plus efficacement, améliorant ainsi leur qualité de service.

Solana étant un réseau Proof of Stake, il est naturel d’étendre la pondération par le stake aux performances des transactions. Pour faire simple, Solana utilise le stake (c’est-à-dire les fonds verrouillés auprès d’un validateur pour sécuriser le réseau) comme indicateur de la fiabilité d’un validateur. Plus un validateur détient de stake, plus il a intérêt à préserver la sécurité et la fiabilité du réseau. Par ailleurs, la qualité de service est un concept réseau qui consiste à donner la priorité à certains paquets afin de leur assurer des performances plus fiables. Solana offre donc aux validateurs stakés des performances plus fiables pour l’envoi de transactions en les acheminant via des connexions prioritaires.

L’objectif principal de SWQoS est d’empêcher les validateurs disposant d’un faible stake de saturer le réseau avec des transactions qui évinceraient celles envoyées par des validateurs de meilleure qualité ou disposant de davantage de stake. Par exemple, si un validateur détient 5 % du stake total, il peut envoyer 5 % de l’ensemble des paquets au leader. SWQoS peut être considérée comme un mécanisme de résistance aux attaques Sybil, car elle complique la saturation du réseau par des acteurs malveillants au moyen de transactions de « faible qualité ».

Imaginez que vous assistiez à un événement populaire, comme un concert ou que vous vous rendiez dans un parc d’attractions, avec un nombre limité de billets. Tout le monde peut rejoindre les files d’attente ordinaires pour acheter des billets, mais celles-ci peuvent devenir longues et lentes. Il existe toutefois des files VIP réservées aux clients qui paient davantage. Elles sont bien plus courtes et rapides, car leur accès est limité aux personnes qui remplissent certains critères, comme la possession d’un abonnement spécifique, et un nombre défini d’entre elles est assuré de pouvoir entrer à chaque fois. Dans le contexte de Solana, SWQoS s’apparente à ces files VIP, dont l’accès dépend de la quantité de stake détenue par un validateur. Plus vous disposez de stake, plus vous obtenez d’accès VIP (c’est-à-dire de connexions prioritaires), ce qui garantit un traitement plus rapide et plus fiable des billets (transactions).

Comment cela fonctionne-t-il en pratique ? Il faut d’abord comprendre comment Solana traite les transactions.

Comment Solana traite les transactions

La Transaction Processing Unit (TPU) de Solana gère et exécute efficacement les transactions. Le traitement passe par plusieurs étapes distinctes afin que les transactions soient validées, exécutées et propagées sur le réseau. Il s’agit de la Fetch Stage, de la SigVerify Stage, de la Banking Stage, du service Proof of History (PoH) et de la Broadcast Stage.

La Fetch Stage

La Fetch Stage reçoit via le réseau les transactions entrantes provenant des clients. Elle regroupe les données reçues depuis un socket UDP et les classe dans trois sockets principaux :

• tpu : pour les transactions ordinaires telles que les transferts de jetons, la création de NFT et les interactions avec des programmes
• tpu_vote : pour les transactions de vote
• tpu_forwards : transmet les paquets non traités au leader suivant si le leader actuel ne peut pas traiter toutes les transactions.

Ces sockets sont créés dans Gossip et stockés dans la structure ContactInfo, identifiés par le socket correspondant.

La Fetch Stage utilise un mécanisme qui fusionne les paquets reçus simultanément. Cela réduit le nombre d’opérations de traitement individuelles tout en augmentant le débit. Lorsqu’elle reçoit des paquets transférés, elle leur attribue un indicateur FORWARDED afin qu’ils soient reconnus comme tels lors des étapes suivantes. Si le nœud n’est pas le leader actuel, ces paquets transférés sont abandonnés pour éviter tout traitement inutile. En revanche, si le nœud est le leader, ces paquets sont pris en compte et traités en conséquence.

La Fetch Stage crée des canaux sans limite (par exemple, packet_sender et packet_receiver) pour transmettre les transactions à l’étape suivante, la SigVerify Stage. Ces canaux découplent les étapes de la TPU, ce qui leur permet de fonctionner simultanément sans se bloquer mutuellement. La fonction unbounded crée un canal de capacité illimitée pour éviter que des paquets soient abandonnés en raison d’un débordement du canal. 

Les transactions sont regroupées par lots de 128 paquets avant d’être transmises à la SigVerify Stage. Ce regroupement permet de les traiter plus efficacement et réduit la surcharge liée au traitement de chaque paquet. 

Notez que la Fetch Stage fonctionne sur plusieurs threads afin de gérer un débit élevé. Chaque thread est chargé d’une tâche précise, comme la réception des paquets, le traitement des lots ou le transfert des transactions. Un thread est créé pour chaque type de socket (c’est-à-dire tpu, tpu_vote et tpu_forwards) à l’aide de la fonction streamer::receiver. Chaque thread écoute le socket qui lui est attribué, traite les paquets entrants et les envoie via le canal approprié.

En gérant efficacement la réception et la classification des transactions, la Fetch Stage pose les bases de toutes les étapes de traitement ultérieures de la TPU de Solana.

La SigVerify Stage

La SigVerify Stage constitue la deuxième étape du pipeline de traitement des transactions de Solana. Elle est essentielle pour garantir l’intégrité et l’authenticité des transactions. 

À cette étape, la TPU reçoit de la Fetch Stage des transactions regroupées par lots via des canaux sans limite. Sa tâche principale consiste à vérifier les signatures des transactions au moyen du schéma de signature Ed25519. Cette validation cryptographique confirme que le propriétaire légitime des comptes concernés a signé la transaction.

La SigVerify Stage est conçue pour offrir de très hautes performances. Elle exploite les capacités de traitement parallèle des CPU et GPU modernes pour vérifier les signatures. Par défaut, le CPU effectue l’intégralité du traitement. Toutefois, grâce au caractère parallélisé de cette opération, le déchargement vers le GPU accélère considérablement le processus lorsque des bibliothèques de performance sont disponibles.

Le processus commence par la fonction new, qui initialise la SigVerify Stage et configure les canaux de réception nécessaires pour recevoir les paquets de la Fetch Stage. La fonction verifier est chargée de recevoir les lots et de vérifier les signatures. Elle gère la déduplication, abandonne les paquets excédentaires et vérifie les paquets restants. La fonction utilise la méthode ed25519_verify de vérification des signatures. Pendant les périodes de fort volume de transactions, un délestage de charge se produit : la SigVerify Stage abandonne les paquets excédentaires. Pour ce faire, elle regroupe les paquets selon leur adresse IP source et définit un nombre maximal de paquets à traiter par adresse.

Les transactions dont la signature est invalide sont signalées et abandonnées. Ce processus garantit que seules les transactions valides poursuivent leur chemin et empêche les transactions frauduleuses ou incorrectes de passer à l’étape suivante.

Après vérification des signatures, les transactions valides sont transmises à l’étape suivante, la Banking Stage, via un autre ensemble de canaux sans limite. Les étapes restent ainsi découplées et peuvent fonctionner simultanément. Notez que cette étape s’exécute sur plusieurs threads. Chacun traite un sous-ensemble de transactions, vérifie les signatures, puis effectue la déduplication et le délestage.

La Banking Stage

La Banking Stage est la troisième étape du pipeline de traitement des transactions de Solana. Elle est essentielle, car c’est là que les transactions sont exécutées et appliquées à l’état actuel du registre. La Banking Stage exploite l’environnement d’exécution Sealevel propre à Solana pour assurer un traitement parallèle des transactions à haut débit.

La Banking Stage comporte six threads : deux sont consacrés au traitement des transactions de vote provenant de la TPU ou de Gossip, et quatre aux transactions hors vote. Chaque thread fonctionne de manière indépendante et reçoit les paquets depuis un canal partagé (notez que cela changera après la version 1.18), auquel SigVerify envoie les paquets par lots. Chaque thread récupère des transactions dans ce canal partagé et les stocke dans un tampon local. Celui-ci fait office de file de priorité et se met à jour dynamiquement pour refléter en temps réel l’évolution du statut des transactions et des besoins du réseau. 

La gestion de ces transactions dépend de la présence du validateur dans le calendrier des leaders. Si le validateur n’est pas sur le point de devenir leader, il transmet les paquets au prochain leader et les abandonne. À mesure que son tour approche (à environ ~20 slots), il continue de transmettre les paquets, mais les conserve au cas où les prochains leaders ne parviendraient pas à les traiter. Lorsqu’il ne reste plus que deux slots avant que le validateur devienne leader, celui-ci conserve les paquets afin de garantir leur traitement lorsqu’il prendra ce rôle.

Pendant la production du bloc, chaque thread traite les transactions en sélectionnant les 128 premières de sa file locale. Le processus comprend notamment le verrouillage, la vérification, le chargement, l’exécution, l’enregistrement, la validation et le déverrouillage. 

La Banking Stage utilise une approche à itérateurs multiples pour regrouper les transactions par lots. Celle-ci permet de parcourir simultanément un jeu de données afin de réunir les transactions en lots sans conflit. Les transactions sont d’abord sérialisées dans un vecteur ordonné par priorité. Les itérateurs multiples sont ensuite placés aux endroits où les transactions n’entrent pas en conflit, créant ainsi des lots de 128 transactions. Les transactions conflictuelles sont ignorées, puis intégrées aux lots suivants une fois le conflit résolu. Une fois le lot constitué, les transactions sont exécutées. Les transactions réussies sont enregistrées dans le service Proof of History et diffusées sur le réseau via Turbine.

Service Proof of History (PoH)

Le service Proof of History (PoH) est un composant fondamental du pipeline de traitement des transactions de Solana. Il offre un moyen vérifiable de suivre le temps et l’ordre des événements sur le réseau, garantissant ainsi un séquençage efficace et sécurisé des transactions. Il génère, par chaînage de hachages, une séquence cryptographique qui fait office d’horodatage pour les transactions. Cette chaîne continue de hachages crée un historique qui prouve l’écoulement du temps entre les événements.

Le service PoH permet à tous les participants du réseau de s’accorder sur l’ordre des transactions sans autorité centrale chargée de mesurer le temps. Il contribue également à synchroniser les validateurs sur l’ensemble du réseau. Il prend en charge le processus d’élection des leaders de Solana en fournissant un horodatage fiable pour déterminer quand un validateur doit devenir leader et produire le bloc suivant.

Le service PoH commence par initialiser une valeur de départ, qui génère une séquence de hachages. À mesure que les transactions arrivent, elles sont marquées avec le hachage actuel de la séquence PoH, ce qui leur fournit un horodatage unique. Les validateurs vérifient ensuite la séquence de hachages pour confirmer l’ordre et le moment des transactions.

Pour en savoir plus sur Proof of History, consultez notre article Proof of History, Proof of Stake, Proof of Work — Explications. Si la cryptographie vous paraît être une langue étrangère, nous vous recommandons également notre article Les outils cryptographiques pour débuter — Fonctions de hachage et arbres de Merkle expliqués.

La Broadcast Stage

La Broadcast Stage est la dernière étape du pipeline de traitement des transactions de Solana. Elle est chargée de distribuer les transactions validées et confirmées au reste du réseau.

Une fois traitées et validées pendant la Banking Stage, les transactions sont regroupées sous forme d’entrées. Ces entrées sont ensuite intégrées à des structures de données appelées shreds. La Broadcast Stage sérialise ces shreds, les signe et génère des codes d’effacement pour renforcer l’intégrité et la récupération des données. Les shreds sont envoyés aux pairs au moyen d’un processus structuré de diffusion arborescente appelé Turbine. Il s’agit d’un processus de distribution efficace et redondant, tandis que le codage d’effacement permet aux validateurs de reconstituer les données manquantes ou corrompues.

Pour une présentation plus complète de Turbine, consultez notre article Turbine : propagation des blocs sur Solana.

Le cycle de vie d’une transaction avec SWQoS

Contrairement à d’autres blockchains, Solana ne dispose pas d’une mempool dans laquelle les transactions attendent avant d’être traitées. Elles sont directement acheminées vers le leader actuel, puis traitées par sa TPU. Les utilisateurs créent des transactions, directement ou indirectement, avec un portefeuille ou une application, puis les soumettent à des nœuds RPC via l’API JSON RPC. Ces nœuds servent d’intermédiaires entre les utilisateurs et les validateurs de Solana. Point important : ils ne doivent détenir aucun stake sur le réseau. Autrement dit, les nœuds RPC ne sont pas stakés, ne votent pas et ne participent donc pas au consensus.

Les connexions à un leader s’effectuent désormais via QUIC. QUIC a été ajouté aux ports qui reçoivent les transactions des utilisateurs afin de remplacer UDP pour la TPU de Solana. Puisque QUIC nécessite une négociation de connexion, il est possible de limiter le trafic d’un acteur afin que le réseau se concentre sur le traitement des transactions authentiques tout en filtrant le spam. Bien entendu, c’était l’objectif de la mise en œuvre de QUIC, et cet article n’abordera pas son efficacité actuelle. L’essentiel à retenir est que les connexions à un leader s’effectuent via QUIC.

Il existe deux types de connexions :

• 500 connexions ouvertes accessibles à n’importe quel nœud RPC
• 2 000 connexions pondérées par le stake, accessibles uniquement aux validateurs stakés. Les validateurs reçoivent une part de ces connexions proportionnelle à leur stake

Pour relayer efficacement une transaction, un RPC doit être appairé à un validateur staké. Les RPC ne détenant aucun stake sur le réseau, les validateurs doivent leur étendre virtuellement leur stake. Ils peuvent utiliser l’indicateur --staked-nodes-overrides pour attribuer une partie de leurs connexions stakées à des nœuds RPC précis. 

Un validateur doit indiquer le chemin d’un fichier YAML à l’aide de --staked-nodes-overrides flag pour configurer ses connexions pondérées par le stake. Le fichier YAML contient des associations sous la forme suivante :

staked_map_id:
	<pubkey_of_RPC>: 80000000000000000

Chaque clé publique d’une identité RPC donnée nécessite une valeur en lamports. Cette valeur définit le poids de stake que vous souhaitez attribuer à l’identité RPC. Par exemple, si vous indiquez un million de SOL, vous lui attribuez un million de SOL divisé par le stake actif total. En substance, vous accordez au nœud RPC des connexions stakées comme s’il s’agissait d’un validateur détenant cette quantité de stake sur le réseau. Vous dites : « De mon point de vue local, traitez cette identité RPC comme si elle disposait d’une quantité x de stake lorsqu’elle communique avec mon validateur. » Notez que cette configuration ne nécessite pas le redémarrage du validateur : vous pouvez modifier le fichier et le recharger à la volée.

De plus, le relais Jito prend en charge l’indicateur de remplacement des nœuds stakés. Pour optimiser les performances, il est recommandé d’exécuter le relais sur la même machine que le nœud staké.

Pour utiliser ces connexions stakées, les opérateurs RPC doivent employer l’indicateur --rpc-send-transaction-tpu-peer, qui requiert l’adresse IP et le port de la TPU du validateur staké. Le port de la TPU correspond généralement au début de la plage de ports dynamiques plus trois, comme indiqué dans Gossip. Dans le cas de Jito, le trafic est dirigé vers le relais exécuté par l’opérateur, car les relais Jito publics ne peuvent pas être utilisés. Les opérateurs RPC doivent rechercher dans leurs journaux des entrées telles que solana_quic_client et warm afin de vérifier leur connexion. Notez que cette configuration nécessite l’exécution, sur le nœud RPC, d’un client Agave v1.17.28 ou ultérieur prenant en charge l’indicateur requis.

Dans l’ensemble, le cycle de vie d’une transaction avec SWQoS reste très proche de celui d’une transaction ordinaire. Les utilisateurs créent et soumettent des transactions via des nœuds RPC, qui les envoient ensuite au leader. Toutefois, les transactions passent par des connexions stakées lorsqu’un nœud RPC est appairé à un validateur staké et utilise l’indicateur --rpc-send-transaction-tpu-peer. En résumé :

• Création de la transaction : un utilisateur crée une transaction à l’aide de son portefeuille, d’une application ou par programmation 
• Soumission à un nœud RPC : la transaction est soumise à un nœud RPC via l’API JSON RPC
• Connexion QUIC : le nœud RPC établit une connexion QUIC avec le leader, en utilisant des connexions ouvertes ou pondérées par le stake selon sa configuration
• Qualité de service pondérée par le stake : si le nœud RPC est appairé à un validateur staké, il utilise les connexions stakées de ce dernier, ce qui améliore les performances de la transaction
• Transfert au leader : la transaction est envoyée au leader via ces connexions stakées, avec un risque moindre de retard ou d’abandon
• Traitement de la transaction : la transaction passe par la TPU, comme indiqué précédemment, puis est traitée par le leader

SWQoS améliore le cycle de vie des transactions en donnant aux validateurs stakés et aux nœuds RPC qui leur sont appairés un meilleur accès au leader, ce qui réduit le risque de retard lié à la congestion du réseau. Ce mécanisme fonctionne de concert avec les frais de priorité pour améliorer les performances des transactions.

SWQoS et frais de priorité : une distinction claire

En cas de congestion du réseau, SWQoS réduit le risque de retard ou d’abandon des transactions provenant des validateurs disposant d’un stake élevé. Ce système peut être, et est souvent, comparé à une route à péage sur laquelle les validateurs qui détiennent davantage de stake accèdent à des voies moins encombrées, comme s’ils disposaient de plus de voies sur une autoroute. Prenons la photo ci-dessus. Dans le Colorado, les conducteurs peuvent rester bloqués dans les embouteillages ou payer quelques dollars supplémentaires pour emprunter une voie à péage. Les voies express constituent le réseau de voies premium du Colorado, dont les tarifs sont constamment ajustés afin de rester suffisamment élevés pour fluidifier la circulation. Nous pouvons donc comparer les connexions stakées de Solana aux voies express du Colorado, car il s’agit dans les deux cas d’itinéraires prioritaires visant à réduire la congestion pour les utilisateurs premium.

Il est toutefois essentiel de distinguer SWQoS des frais de priorité, car l’analogie courante avec une route à péage peut brouiller la distinction entre ces deux concepts :

• Les frais de priorité interviennent pendant la Banking Stage, lorsque les leaders classent les transactions selon les frais payés. L’idée est que les transactions assorties de frais plus élevés sont traitées en premier, ce qui garantit une exécution plus rapide aux utilisateurs prêts à payer davantage.
• SWQoS améliore l’accès aux connexions et n’affecte pas la priorité des transactions dans la file du leader. SWQoS garantit aux validateurs stakés un meilleur accès au réseau, ce qui réduit le risque de retard ou d’abandon des transactions en raison de la congestion du réseau

Alors que les frais de priorité influencent l’ordre et le traitement des transactions une fois qu’elles se trouvent dans la file du leader, SWQoS garantit aux transactions envoyées par les validateurs stakés un itinéraire prioritaire jusqu’au leader. Ces deux mécanismes visent à améliorer les performances du réseau, mais interviennent à des étapes différentes du cycle de vie des transactions.

La guerre des SWQoS

SWQoS est appelée à devenir un élément fondamental de l’infrastructure réseau de Solana. Elle influencera considérablement l’écosystème en optimisant le traitement des transactions et en donnant la priorité aux connexions des validateurs stakés vers le leader. Je ne saurais trop insister sur ce point.

On pourrait soutenir que l’avantage d’utiliser des validateurs disposant d’un stake élevé commence à s’estomper lorsque le réseau n’est pas congestionné et que les transactions ne sont pas urgentes. Le réseau dispose alors d’une capacité suffisante pour traiter rapidement les transactions, quel que soit le poids de stake qui les soutient. Cependant, à mesure que la demande pour Solana augmente et que son adoption massive se profile, le réseau ne disposera peut-être pas toujours d’une capacité suffisante pour traiter chaque transaction sans retard ni abandon occasionnel. Cela ne signifie pas que Solana ne peut pas évoluer, car elle représente sans doute l’une des meilleures possibilités, sinon la meilleure, de créer une blockchain évolutive. L’essentiel est qu’à mesure que la demande augmentera, SWQoS restera indispensable à une excellente UX.

Le rôle des validateurs devient donc encore plus crucial, ce qui stimule la concurrence et l’innovation afin d’offrir le meilleur service possible. Cela ne signifie-t-il pas naturellement que tout le monde souhaitera lancer son propre validateur ?   

Validateurs et jetons de staking liquide (LST)

La tendance est claire : tout protocole Solana sérieux exploitera un validateur. Cela lui sera nécessaire pour prendre en charge son application. Si vous souhaitez exploiter votre propre validateur, consultez notre guide de démarrage sur le blog Helius.

Nous sommes à l’aube d’une immense explosion cambrienne des LST sur Solana, amplifiée par SWQoS. Rien que ce mois-ci, le stake total (c’est-à-dire natif + LST) a augmenté d’environ 3,2 millions. La valeur de marché des seuls LST se situe actuellement entre 6 et 9 milliards de dollars pour ce mois-ci. Des protocoles comme Sanctum se préparent à devenir des acteurs majeurs, car leur plateforme permet aux validateurs et aux applications de créer leurs propres LST. De plus, Picasso Network permet le restaking sur Solana et sert de plateforme centrale pour accroître l’utilité et le rendement des LST. Il est donc déjà pleinement possible de créer un LST doté d’une utilité supplémentaire.

Il faut toutefois tenir compte de quelques barrières potentielles à l’entrée.

Barrières à l’entrée

Malgré ses avantages potentiels, SWQoS introduit plusieurs barrières à l’entrée. Plus précisément, une exigence minimale de stake a été introduite dans la version v1.17.31 du client Agave afin de traiter les validateurs disposant d’un faible stake comme des pairs non stakés. Le problème venait du fait que les nœuds stakés avec un faible stake pouvaient abuser des connexions stakées en bénéficiant d’une bande passante disproportionnée. Désormais, les nœuds dont le ratio de stake est inférieur au résultat de la formule suivante sont considérés comme non stakés :

stake / total_stake < 1 / (max packet per 100ms)

Cela signifie que les clients disposant de moins d’environ 15 000 SOL stakés sont désormais classés comme validateurs non stakés. Cette exigence pourrait encore accroître les contraintes financières et techniques déjà élevées liées à l’exploitation d’un validateur Solana, et potentiellement exclure du réseau les petits acteurs et les validateurs indépendants. Elle représente environ 3 millions de dollars américains, ce qui paraît considérable à première vue. 

Toutefois, comme le souligne Austin Federa, le seuil ne correspond qu’à 1/25 000e du stake total, ce qui est sans doute faible. De plus, si la majorité des validateurs en concurrence pour obtenir du stake améliorent continuellement leurs performances afin de fournir le meilleur service possible et de maximiser leur propre rendement, l’ensemble du réseau en bénéficiera. C’est exactement ce que Toly décrit comme l’objectif global de SWQoS.

Chez Helius, nous réduisons la barrière à l’entrée pour tous les forfaits payants qui envoient des transactions avec les frais recommandés par Helius. Autrement dit, les transactions de tout utilisateur d’un forfait partagé payant seront désormais acheminées via nos connexions stakées si leurs frais sont égaux ou supérieurs à la valeur recommandée par notre API de frais de priorité. Nous avons également simplifié ce processus grâce à notre nouvelle fonctionnalité Smart Transactions, ajoutée à nos SDK Node.js et Rust. Dans sa forme la plus simple, quel que soit le SDK utilisé, les utilisateurs fournissent leur paire de clés et les instructions qu’ils souhaitent exécuter, et nous nous occupons du reste. Les utilisateurs peuvent désormais accéder à des connexions stakées partagées pour seulement 50 USD par mois avec un forfait Developer. Notez que nous proposons également des connexions stakées dédiées, qui garantissent la bande passante de la connexion stakée et sont recommandées aux entreprises, aux analystes quantitatifs et aux sociétés de trading. Si les connexions stakées dédiées vous intéressent, veuillez contacter notre équipe commerciale.

Il est important de noter que le stake commencera probablement à se concentrer entre les mains de validateurs exploités par de grands protocoles et fournisseurs RPC capables de facturer 0 % de commission. Prenons Helius : nous pouvons générer des revenus ailleurs afin de compenser les coûts d’exploitation d’un validateur. Nous procédons ainsi pour améliorer la décentralisation du réseau en faisant exploiter un validateur de premier plan par une équipe native de Solana, tout en bénéficiant d’un meilleur accès aux connexions stakées afin d’améliorer l’expérience de nos utilisateurs.

Hypothèses de confiance

Si le stake est susceptible de se concentrer entre les mains de validateurs exploités par de grands protocoles et fournisseurs RPC, il est important de staker auprès d’un validateur qui agit dans l’intérêt de Solana. SWQoS introduit plusieurs hypothèses de confiance.

L’une des principales hypothèses de confiance concerne la nécessité d’un haut niveau de confiance entre les validateurs et les nœuds RPC. Comme indiqué tout au long de cet article, SWQoS permet aux leaders d’identifier les transactions provenant de validateurs stakés et de leur donner la priorité. Les nœuds RPC n’étant pas stakés, ne votant pas et ne participant pas au consensus, ils ne peuvent pas bénéficier directement des transactions prioritaires de la même manière que les validateurs stakés. Une relation de confiance doit donc s’établir entre les validateurs et les nœuds RPC pour exploiter les avantages de SWQoS.

Cette relation de confiance est cruciale, car l’activation de SWQoS implique le partage de configurations réseau sensibles et permet aux nœuds RPC d’influencer la priorité des transactions. Les validateurs doivent s’assurer que les nœuds RPC auxquels ils s’appairent agiront dans l’intérêt du réseau et n’utiliseront pas le stake étendu à des fins malveillantes. Les validateurs et les nœuds RPC doivent convenir au préalable de la manière dont les connexions stakées seront utilisées et en avoir une compréhension commune. Idéalement, cette configuration doit relier des entités qui se font pleinement confiance, comme des partenaires de longue date, ou être mise en place au sein d’une même organisation.

À l’heure actuelle, ces relations sont souvent dissimulées. Et à l’avenir, je n’imagine pas un monde dans lequel les opérateurs RPC ne négocieraient pas avec les validateurs pour obtenir des remplacements de stake. Une plus grande transparence est nécessaire afin que l’utilisateur moyen sache quels RPC et validateurs il soutient. Cette demande ne fera qu’augmenter avec le temps.

Conclusion

SWQoS est sur le point de révolutionner l’infrastructure réseau de Solana. Si elle offre de nombreux avantages, dont de meilleures performances transactionnelles et une résistance accrue aux attaques Sybil, elle introduit également de nouveaux défis et de nouvelles hypothèses de confiance qu’il convient de gérer avec prudence. Bien que SWQoS soit conçue pour donner la priorité aux transactions envoyées par les validateurs stakés, rien n’impose actuellement cette priorité. Les validateurs sérieux remplacent souvent les paramètres par défaut et peuvent même bloquer certains acteurs. Cela souligne la nécessité d’instaurer confiance et transparence dans les relations entre les validateurs et les nœuds RPC afin de garantir une utilisation juste et efficace de SWQoS. Quoi qu’il en soit, sa mise en œuvre marque une étape importante dans l’évolution de Solana vers un réseau efficace et résilient.

Tout au long de cet article, nous avons présenté SWQoS et son influence sur le traitement des transactions. Nous avons également couvert des distinctions importantes, notamment la différence entre SWQoS et les frais de priorité. Enfin, nous avons abordé l’essor des validateurs et des LST, les barrières potentielles à l’entrée et les hypothèses de confiance associées, offrant ainsi un point de départ critique pour les discussions futures. Comprendre tous ces éléments est essentiel pour exploiter efficacement SWQoS et améliorer Solana dans son ensemble.

Si vous avez lu jusqu’ici, merci, anon ! Pensez à saisir votre adresse e-mail ci-dessous pour ne manquer aucune actualité sur Solana. Prêt à aller plus loin ? Découvrez les derniers articles du blog Helius et poursuivez dès aujourd’hui votre parcours sur Solana.

Ressources supplémentaires

• Rapport et mesures d’atténuation concernant la panne de Solana Mainnet Beta du 30 avril 2022
• Guide de la qualité de service pondérée par le stake sur Solana
• Comment configurer un validateur Solana
• Envoi de Smart Transactions
• Formation sur les validateurs Solana — Qualité de service pondérée par le stake