Les frais sur Solana en théorie et en pratique

Introduction

La structure des frais de Solana est conçue pour préserver les performances du réseau tout en compensant les chocs asymétriques de l’offre et de la demande. Sur toute blockchain, les frais servent à prévenir le spam et à inciter les validateurs. Sur Solana, certains de ces frais sont ajustés dynamiquement selon l’état du réseau, ce qui permet de mieux valoriser la demande à un moment donné.

Les frais sur Solana sont un sujet brûlant, notamment avec les « marchés de frais locaux », qui permettent à Solana de valoriser plus précisément l’espace de bloc et certains comptes. L’implémentation actuelle est loin d’être parfaite, mais elle fournit de faibles garanties d’ordonnancement pour chaque compte. Solana n’en est encore qu’à ses débuts, mais l’augmentation du stake et de l’activité sur le réseau nécessite une analyse approfondie des effets directs et indirects de toute modification du protocole, notamment du modèle de frais.

Dans cet article, nous examinerons les frais en théorie ainsi que leur manifestation on-chain. Certains ont critiqué Solana pour sa centralisation et les forces centralisatrices liées à la pondération par le stake de la QoS et de Turbine. Pourtant, même après plusieurs années, un écart manifeste subsiste entre ces critiques et la réalité. De même, nous cherchons à analyser en détail la manière dont les frais se manifestent dans les comportements on-chain.

Les frais en théorie

Le système de frais de Solana comporte deux composantes : les frais de base et les frais de priorité. Dans l’ensemble, chaque composante devrait idéalement remplir la fonction suivante :

• Frais de base : droit d’utiliser les ressources du réseau
• Frais de priorité : déterminent l’ordre dans la file de transactions d’un leader

Frais de base

Les frais de base, actuellement fixés à 0,000005 SOL (5 000 lamports) par signature, constituent le socle du coût d’une transaction. Une adresse paie ces frais pour obtenir le droit d’utiliser les ressources du réseau. Il s’agit d’un paiement forfaitaire unique versé d’avance au réseau, indépendamment des ressources réellement utilisées pour exécuter la transaction, voire de son exécution effective. Les transactions Solana demandent à l’avance un nombre précis d’unités de calcul (CU). Si ce nombre est dépassé, la transaction échoue. Les développeurs ont donc actuellement peu, voire pas, d’incitation financière à réduire leurs demandes d’unités de calcul.

Frais de priorité

Les utilisateurs peuvent également payer des frais de priorité pour accélérer leurs transactions et augmenter leurs chances d’inclusion dans un bloc. Ils paient ainsi pour une priorité sans garantie déterministe. Des travaux sont en cours pour améliorer le déterminisme des transactions, avec d’importantes modifications du planificateur attendues dans la version 1.18.

À noter que les transactions de vote n’ont pas de frais de priorité associés et sont traitées différemment des transactions standard.

L’incitation des validateurs à inclure des transactions assorties de frais de priorité existe en dehors du runtime. Les leaders perçoivent 50 % des frais de priorité lorsqu’ils incluent la transaction dans leur bloc, tandis que les 50 % restants sont brûlés.

Aujourd’hui, la plupart des validateurs (plus de 80 %) exécutent des versions non modifiées du client Solana Labs ou Jito-Solana. Ils délèguent donc la « production de blocs » au planificateur par défaut. Sur Solana, certaines personnes parlent de « production de blocs » pour désigner l’« ordonnancement des blocs », alors que ce terme signifie quelque chose de totalement différent sur Ethereum. Certaines équipes ont modifié le code du client et implémenté un planificateur plus complexe offrant davantage de contrôle sur le flux d’ordonnancement. Elles peuvent ainsi extraire du MEV en réordonnant les transactions ou en réalisant des attaques sandwich.

Indéterminisme des frais de priorité

L’implémentation actuelle du planificateur ne garantit pas que les transactions assorties de frais de priorité plus élevés seront incluses dans un bloc donné. Elle garantit seulement, de manière approximative, que les transactions avec des frais de priorité ont plus de chances d’y être incluses. L’implémentation actuelle du planificateur utilise 4 cœurs d’exécution, tandis que 2 cœurs supplémentaires sont réservés aux transactions de vote.

Chaque thread gère sa propre file et classe les paquets de manière indépendante, sans connaître ceux traités par les autres threads. Chaque thread parcourt continuellement sa file du début à la fin pour tenter de verrouiller et d’exécuter les transactions. Lorsqu’un thread termine son cycle en cours, il collecte d’autres paquets et recommence le cycle.

Ainsi, une transaction hautement prioritaire peut se trouver en tête de la file d’un thread tandis qu’un autre thread termine simultanément sa propre file en traitant une transaction impliquant le même compte.

Les détails précis des implémentations actuelle et future du planificateur seront examinés dans un autre article. Il suffit de comprendre que les frais de priorité ne fonctionnent qu’au niveau intra-thread (dans leur propre voie), et non inter-thread (entre plusieurs voies), pour constater que le planificateur est loin d’être parfait et présente de la « gigue ».

Les frais en pratique

Confirmation des transactions

Bien que les frais jouent un rôle majeur dans la confirmation d’une transaction, ils ne sont pas le seul facteur déterminant. Par exemple, une transaction peut ne pas être confirmée simplement à cause de la perte d’un paquet réseau UDP. Pendant les périodes de forte activité du réseau, les validateurs peuvent recevoir plus de transactions qu’ils ne sont capables d’en gérer. Ils peuvent transmettre les transactions excédentaires grâce au mécanisme tpu_forwards, mais ne peuvent traiter qu’un volume limité de données. De plus, chaque transaction ne peut être relayée qu’un nombre limité de fois, jusqu’à l’expiration du blockhash. La qualité de service pondérée par le stake atténue certains de ces problèmes pour les adresses associées à un stake plus élevé, en leur réservant de la bande passante et en augmentant leurs chances d’inclusion.

Il existe également deux causes moins souvent évoquées de l’abandon des transactions. La première concerne les incohérences au sein d’un pool RPC. Une partie du pool RPC peut avancer plus vite que les autres, ce qui crée des problèmes de coordination. Par exemple, si le recentBlockhash d’une transaction est récupéré auprès d’une partie plus à jour, puis envoyé à une partie plus lente, cette dernière peut ne pas reconnaître le blockhash actualisé et rejeter la transaction. Les développeurs peuvent détecter ces problèmes au moment de l’envoi si les vérifications préalables sont activées dans la fonction sendTransaction.

Un autre problème est lié aux forks temporaires du réseau. Si un validateur prend du retard dans le traitement de ses blocs, des transactions peuvent se retrouver sur un fork minoritaire qui ne devient pas canonique. Lorsqu’un client référence dans sa transaction un recentBlockhash qui n’existe que sur ce fork minoritaire et que le réseau abandonne ce fork avant de traiter la transaction, celle-ci est rejetée, car le blockhash est devenu introuvable.

Frais de priorité

En pratique, les données montrent que, malgré leurs imperfections, les frais de priorité fonctionnent à l’échelle macro. Les transactions qui incluent des frais de priorité ont davantage de chances d’être intégrées aux blocs, et celles qui fixent des frais plus élevés bénéficient d’une probabilité d’inclusion encore supérieure.

D’après les données RPC de Helius, les transactions assorties de frais de priorité ont plus de chances d’être confirmées et, lorsqu’elles le sont, leur confirmation est globalement plus rapide :

Le 21 janvier, les frais de priorité moyens ont fortement augmenté en raison de l’airdrop mockJUP, en préparation de l’airdrop JUP prévu la semaine suivante. Malgré d’importantes variations de la demande d’espace de bloc, les utilisateurs ont constaté relativement peu de changements dans le taux et le délai de confirmation des transactions.

Cette UX repose principalement sur la méthode RPC de Solana getRecentPrioritizationFees, qui permet aux développeurs de déterminer précisément les frais de priorité à ajouter à une transaction. L’endpoint renvoie une liste des frais de priorité appliqués au cours des 150 derniers blocs et ayant permis de confirmer au moins une transaction avec l’adresse et les paramètres d’entrée concernés. Il fournit ainsi un aperçu de la valeur minimale à définir pour les frais de priorité, mais son utilité reste relativement limitée. Helius propose également une API de frais de priorité, qui effectue des calculs supplémentaires afin de fournir une meilleure estimation.

Même si les frais de priorité fonctionnent en théorie à peu près comme prévu, les prochaines modifications du planificateur dans la version 1.18 amélioreront le déterminisme de l’inclusion des transactions. Cela devrait réduire le volume de spam confirmé on-chain, car la stratégie dominante ne nécessitera plus de saturer la blockchain pour obtenir l’inclusion d’une transaction.

Frais de base

Les frais de base sur Solana sont clairement trop faibles. Les blocs sont saturés et les frais ne sont pas dynamiques, ce qui les empêche d’atteindre un prix d’équilibre pour l’espace de bloc. Sur Ethereum, les frais de base dynamiques reposent sur le mécanisme de contrôle d’EIP-1559, qui examine les blocs récents et vise un taux d’utilisation de 50 %.

Solana fixe statiquement le prix à 5 000 lamports par signature, avec généralement une signature par transaction. Ces frais sont donc inefficaces, car les frais de base ne reflètent aucune variation de la demande d’espace de bloc ni de l’utilisation des ressources des validateurs. Dans les faits, cela reporte la tarification par le marché sur les frais de priorité et engorge davantage le réseau, car les validateurs traitent des transactions supplémentaires qui n’avaient probablement aucune chance d’être incluses. De plus, la stratégie dominante consiste à envoyer un grand nombre de transactions assorties de frais de priorité minimaux. Cela entraîne d’importantes externalités qui dégradent l’UX de tous les participants au réseau.

Incitations

Les RPC sont incités à relayer les bonnes informations en aval afin d’offrir le meilleur taux d’inclusion des transactions au coût le plus faible. L’intégration avec les validateurs disposant du plus grand stake permet aux RPC d’obtenir une vision plus précise de l’état actuel du réseau, car de nombreux mécanismes de Solana sont pondérés par le stake. Une relation symbiotique apparaît : les validateurs disposant d’un stake important et les RPC intégrés peuvent améliorer l’efficacité et la fiabilité du traitement des transactions. Cela risque toutefois de créer une boucle de rétroaction qui consoliderait davantage la position des validateurs détenant le plus grand stake.

En outre, les RPC, actuellement traités comme des validateurs sans stake, seront eux-mêmes pondérés par le stake. Ils pourront chercher à attirer du stake sans s’associer à un validateur. Il n’est pas rare que les applications exploitent leurs propres validateurs afin de renforcer leur intégration verticale. Elles disposent ainsi d’un contrôle accru sur l’expérience utilisateur finale et sur la chaîne d’approvisionnement des transactions et du MEV.

Malgré l’incitation économique qui laisse présager une centralisation du stake, Solana n’a pas connu d’importante concentration de capitaux visant à profiter de la pondération par le stake. Plusieurs raisons peuvent l’expliquer :

• Les individus peuvent considérer que maximiser la décentralisation à l’échelle locale constitue la stratégie dominante pour favoriser les gains à long terme du réseau, principalement sous l’effet de la culture et de la couche sociale de Solana.
• Les participants à Solana sont principalement des particuliers et des prosommateurs, moins sensibles aux rendements que les entreprises professionnelles. À mesure que le niveau d’activité et les rendements absolus augmentent, cela pourrait modifier la démographie des participants et leur sensibilité aux taux.
• Les individus coordonnent mal la promotion de leurs produits différenciés.

Conclusion

Dans cet article, nous avons présenté en détail la théorie générale du mécanisme de frais de Solana et son impact on-chain sur le réseau. Les frais déterminent les incitations, lesquelles entraînent d’importantes externalités et influencent le comportement de tous les participants à Solana.

Dans leur implémentation actuelle, les mécanismes tels que les frais de base et les frais de priorité de Solana ne sont pas parfaits. Les frais de base ne peuvent pas être ajustés et ne reflètent pas l’équilibre actuel entre l’offre et la demande. Cela entraîne des problèmes tels que la congestion du réseau et l’allocation inefficace des ressources. Les frais de priorité présentent un certain degré d’indéterminisme en raison de l’implémentation actuelle du planificateur. Les futures mises à jour, notamment les modifications prévues du planificateur, devraient améliorer le déterminisme et l’efficacité du traitement des transactions, ce qui pourrait transformer les comportements on-chain observés aujourd’hui.

De nouvelles propositions se profilent, notamment les frais exponentiels pour les comptes verrouillés en écriture, qui visent à tarifer plus précisément le coût des transactions en verrouillant arbitrairement l’accès aux comptes. D’autres discussions portent sur un mécanisme dynamique de frais de base permettant de tarifer plus précisément l’accès à l’état.

L’interaction entre les frais, les validateurs et les RPC forme un réseau complexe d’incitations. En théorie, les validateurs et les RPC sont incités à s’intégrer et à augmenter leur poids en stake, ce qui peut susciter des inquiétudes quant à la centralisation. Dans les faits, Solana a toutefois réussi à conserver un ensemble décentralisé d’opérateurs et de stakes, probablement grâce à sa gouvernance pilotée par la communauté, aux barrières techniques, aux contre-incitations économiques et aux fonctions d’optimisation qui, actuellement, ne sont pas principalement déterminées par les rendements.