La vérité sur les marchés de frais locaux de Solana

Enseignements pratiques

• Les marchés de frais locaux (LFM) permettent à Solana de définir des frais granulaires pour chaque élément d’état selon son niveau de contention. Les transactions paient des frais en fonction de l’état précis qu’elles modifient, ce qui évite que des points chauds localisés n’augmentent les frais sur l’ensemble de la blockchain. 
• Les LFM sont essentiels pour concrétiser la vision de Solana : une couche de base unifiée et évolutive où toutes les applications coexistent sans friction. Sans LFM, les pics de frais dans une partie de la chaîne augmentent les frais de toutes les transactions, un problème courant sur les autres réseaux qui reposent uniquement sur des marchés de frais globaux pour tarifer l’espace de bloc.
• Lorsque l’activité économique sur Solana a commencé à s’accélérer fin 2023, plusieurs défauts critiques de l’implémentation initiale des LFM sont devenus évidents. Le plus notable concernait la priorisation non déterministe de l’ordonnanceur. Les transactions étaient principalement classées selon leur heure d’arrivée chez le producteur de bloc, les frais de priorité n’étant qu’un critère secondaire.
• La mise à jour v1.18 du client Agave, publiée en mai 2024, a introduit un nouvel ordonnanceur de transactions et une formule affinée de priorité des transactions. L’ordonnanceur construit un graphe de dépendances afin de mieux gérer le traitement et la priorisation des transactions conflictuelles entre les threads. Cette mise à jour majeure a considérablement amélioré la capacité du protocole à ordonner les transactions de manière déterministe.
• Comparer la médiane et la moyenne des frais de priorité des transactions constitue une mesure utile de l’efficacité des LFM. Les frais associés à un état non disputé (médiane au 50e percentile) devraient rester faibles. Ceux associés à un état disputé devraient bondir avec la demande et tirer la moyenne vers le haut. Les données récentes confirment ce schéma. En novembre 2024, les frais moyens des transactions hors vote ont atteint un record de plus de 0,0003 SOL. Les frais médians sont toutefois restés stables à 0,00000861 SOL, soit environ 35 fois moins.
• Aujourd’hui, les LFM de Solana fonctionnent, mais leur potentiel d’amélioration reste considérable. Une analyse de la charge des threads de la phase bancaire menée par des ingénieurs d’Anza indique qu’un bug de l’ordonnanceur empêche le client du validateur d’exploiter toute sa capacité. Le client Agave ne fonctionne donc qu’à une fraction de son potentiel. De plus, aucune spécification formelle ne définit l’ordre des transactions.
• Les API actuelles de frais de priorité ne sont pas assez sophistiquées pour fournir des résultats déterministes aux développeurs. Chaque grand fournisseur RPC propose sa propre API personnalisée de frais de priorité, ce qui pourrait créer une forme subtile de dépendance envers un fournisseur. L’implémentation principale de l’API RPC open source ne tient pas compte de dynamiques réseau essentielles, comme l’influence de Jito, et produit donc des estimations de frais inexactes.
• Sans méthode déterministe de calcul des frais de priorité, les développeurs adoptent souvent une approche prudente et paient trop pour garantir le traitement de leurs transactions. Ils peuvent aussi recourir excessivement aux pourboires Jito comme mécanisme de substitution, même pour les transactions qui n’ont pas besoin d’être placées en tête de bloc.
• Différentes stratégies ont été proposées pour améliorer encore la structure des frais de Solana. Elles comprennent les frais exponentiels de verrouillage en écriture et les frais de base dynamiques. Le réseau doit encore déterminer comment exercer une pression économique dissuasive contre le spam tout en maintenant des frais faibles pour les véritables utilisateurs humains.

Introduction

Les marchés de frais sont des mécanismes économiques conçus pour attribuer efficacement l’espace de bloc limité aux transactions ayant le plus de valeur grâce à un ajustement dynamique des frais de transaction. Le montant qu’une transaction est disposée à payer sert d’indicateur de sa valeur. Les LFM affinent ce concept général en définissant des frais granulaires pour chaque élément d’état selon son niveau de contention. Deux transactions sont considérées comme conflictuelles lorsqu’elles accèdent au même état : soit deux écritures, soit une lecture et une écriture sur le même compte.

Avec les LFM, les transactions paient des frais en fonction de l’état précis qu’elles modifient, ce qui évite que des points chauds localisés n’augmentent les frais sur l’ensemble de la blockchain. Les transactions qui accèdent à des états très demandés ou disputés paient des frais plus élevés, tandis que celles qui interagissent avec des états moins demandés paient moins. Ce point est important, car Solana traite plus efficacement les transactions non conflictuelles grâce à l’exécution parallèle.

À l’inverse, les marchés de frais globaux appliquent un coût universel à l’accès à l’état du réseau. Toutes les transactions sont donc en concurrence sur un pied d’égalité pour être incluses, quels que soient les comptes avec lesquels elles interagissent. Le modèle de frais d’Ethereum, implémenté dans EIP-1559, constitue un exemple pertinent de marché de frais global. EIP-1559 ajuste des frais de base dynamiques selon la demande du réseau afin de maintenir une utilisation optimale du calcul (gas) par bloc. Lorsque la capacité du bloc se remplit, les frais augmentent pour toutes les transactions. Les portefeuilles calculent les frais en fonction des frais de base actuels et de la limite de gas de la transaction. Cette approche est imposée par le protocole et permet de calculer les frais de façon prévisible. Elle ne parvient toutefois pas à isoler les points chauds très demandés du reste du réseau. Lorsque les frais bondissent, ils augmentent pour toutes les transactions.

La forte demande pour des éléments d’état précis n’est pas un problème propre aux blockchains. Ce défi rappelle le problème des clés fortement sollicitées, souvent appelé « problème des célébrités », fréquemment rencontré dans les applications sociales Web2.

Dans cet article, nous souhaitons proposer une analyse accessible des LFM de Solana. Ce travail est divisé en plusieurs sections :

• Principes de base des frais sur Solana : présente aux lecteurs les notions fondamentales du traitement actuel des transactions sur Solana.
• Premiers problèmes des marchés de frais locaux : étudie les problèmes initiaux et les limites des premières implémentations des LFM.
• Mise à jour v1.18 de l’ordonnanceur central : présente une mise à jour majeure de 2024 qui a considérablement amélioré le fonctionnement des LFM.
• Mesure de l’efficacité des marchés de frais locaux : fournit des données utiles pour comprendre l’état actuel des LFM sur Solana.
• Problèmes persistants et axes d’amélioration : aborde les problèmes non résolus et les aspects à traiter pour que les LFM atteignent leur plein potentiel.
• Solutions proposées : examine les solutions proposées pour affiner les LFM et créer de meilleures incitations économiques afin de tarifer l’espace de bloc avec plus de précision.

Les lecteurs qui connaissent déjà les structures des frais de transaction de Solana peuvent passer la section suivante consacrée aux principes de base.

Principes de base des frais sur Solana

Les transactions Solana comprennent deux types de frais : les frais de base et les frais de priorité. Les frais de base sont actuellement fixés à 5 000 lamports par signature. La plupart des transactions Solana comportent une seule signature. Les frais de priorité sont exprimés en microlamports (soit un millionième de lamport) par unité de calcul (CU) demandée. Les frais sont débités du compte qui les paie, c’est-à-dire le signataire. La transaction est abandonnée si le payeur ne dispose pas d’assez de lamports pour la régler. À l’heure où nous écrivons ces lignes, 50 % des frais de base et de priorité sont conservés par le producteur de bloc afin de l’inciter à inclure la transaction dans le bloc. Les 50 % restants sont brûlés. À la suite du vote de gouvernance favorable sur la proposition SIMD-096 en mai dernier, le producteur de bloc conservera désormais 100 % des frais de priorité. Par exemple : 

Une transaction comporte une signature et demande 500 000 CU. L’expéditeur définit des frais de priorité de 50 000 microlamports par CU demandée. Les frais totaux de la transaction s’élèvent à 5 000 lamports + (500 000 CU demandées * 50 000 microlamports par CU demandée) = 25 000 lamports, soit 0,000025 SOL.

Les validateurs disposent de ressources de calcul limitées, et le protocole limite à 48 millions de CU les ressources de calcul totales par bloc. Ce chiffre a été choisi empiriquement en fonction de la quantité de données que les validateurs peuvent raisonnablement traiter pour atteindre des temps de bloc de 400 millisecondes. Le nombre maximal de CU par compte et par bloc est limité à 12 millions, et le calcul maximal par transaction est fixé à 1,4 million de CU. La taille des messages de transaction est également limitée à 1 232 octets, soit l’unité de transmission minimale d’IPv6 (1 280 octets) moins les en-têtes.

Pour éviter une mauvaise utilisation des ressources de calcul, chaque transaction sur Solana reçoit un budget de calcul. Par défaut, le réseau fixe une limite maximale de 200 000 unités de calcul (CU) par instruction. Les transactions peuvent toutefois définir une limite personnalisée d’unités de calcul en incluant une instruction `SetComputeUnitLimit`, ce qui permet d’allouer les ressources plus efficacement. Le code source du client Agave répertorie le coût en CU de différentes opérations.

Solana exige que toutes les transactions indiquent la liste complète des adresses de comptes qui seront lues ou modifiées pendant leur exécution. Cette liste est limitée à 35 adresses, mais peut être étendue grâce aux tables de recherche d’adresses on-chain. La création de listes d’adresses ajoute une charge de travail pour les développeurs, mais elle permet de débloquer de nombreuses optimisations de Solana, notamment l’exécution parallèle des transactions et les marchés de frais locaux.

Premiers problèmes des marchés de frais locaux de Solana

Lorsque l’activité économique sur Solana a commencé à s’accélérer fin 2023, plusieurs défauts critiques de l’implémentation initiale des LFM sont devenus évidents. À cette époque, Eugene Chen d’Ellipsis Labs a proposé une analyse complète de ces difficultés dans l’article d’Umbra Research, Solana Fees, Part 1. Vous trouverez ci-dessous un résumé des principaux points soulevés par Chen.

Manque d’incitations à demander précisément les CU nécessaires

La structure de frais de Solana facture des frais de base par signature sans tenir compte des unités de calcul (CU) utilisées ou demandées. En parallèle, les frais de priorité n’incitent que faiblement à réduire l’utilisation des CU pendant les périodes de congestion. Cette conception ne motive guère les expéditeurs de transactions à optimiser leur utilisation du calcul ou à aligner leurs demandes de CU sur leurs besoins réels. Les transactions demandent donc fréquemment trop de CU, ce qui réduit l’efficacité du processus d’ordonnancement du réseau.

Incitations à utiliser des mécanismes de priorité hors protocole

Le fait de brûler 50 % des frais de priorité incite les expéditeurs de transactions à contourner le protocole en s’entendant avec les producteurs de blocs et en organisant des paiements off-chain pour obtenir un accès prioritaire. Ce comportement apparaît clairement dans l’utilisation croissante des enchères Jito. Les validateurs qui exécutent le client Jito-Agave bénéficient de revenus plus élevés issus des frais et peuvent distribuer efficacement ces profits aux délégateurs grâce aux récompenses de commission Jito MEV. À mesure que l’adoption des clients Jito-Agave a progressé, les bundles Jito se sont imposés comme un meilleur service d’acheminement des transactions dans de nombreux scénarios. 

Priorisation non déterministe de l’ordonnanceur

Ni le consensus de Solana ni l’ordonnanceur n’imposent un ordre strict des transactions fondé sur les frais de priorité. Les transactions sont principalement classées selon leur heure d’arrivée chez le producteur de bloc, les frais de priorité n’étant qu’un critère secondaire. Des frais de priorité plus élevés peuvent augmenter les chances d’inclusion en présence d’états disputés, mais le processus d’ordonnancement reste non déterministe. La gigue du réseau avant l’arrivée dans l’unité de traitement des transactions (TPU), ainsi que la gigue interne de l’ordonnanceur, rendent le résultat encore plus imprévisible.

Ce manque de déterminisme réduit la prévisibilité et la fiabilité de l’exécution des transactions. Il pousse les utilisateurs à inonder le réseau de transactions indésirables pour augmenter leurs chances d’être inclus plus rapidement. Toutefois, au-delà d’un certain seuil, l’augmentation des frais de priorité produit des rendements décroissants, ce qui limite leur efficacité comme mécanisme d’amélioration du placement des transactions. L’espace de bloc partagé de Solana a finalement été victime d’une classique « tragédie des biens communs ». En agissant dans leur propre intérêt, les différents acteurs ont contribué à la surexploitation et au manque d’efficacité de cette ressource publique.

Mise à jour v1.18 de l’ordonnanceur central

L’implémentation initiale de l’ordonnanceur du client Agave garantissait seulement, de manière approximative, que les transactions assorties de frais de priorité élevés auraient plus de chances d’être incluses dans un bloc donné. L’unité de traitement des transactions (TPU) du leader utilise six threads parallèles : quatre traitent les transactions hors vote et deux sont réservés aux transactions de vote. Chacun des quatre threads dédiés aux transactions hors vote maintient sa propre file d’attente, dans laquelle les transactions entrantes attendent d’être regroupées en entrées avant leur exécution. Auparavant, les transactions étaient affectées aléatoirement à ces threads, et les files d’attente classaient les paquets indépendamment, sans connaître ceux traités par les autres threads.

Dans ce système, chaque thread parcourt sa file d’attente et tente de verrouiller puis d’exécuter les transactions. Lorsqu’un thread termine son cycle en cours, il collecte des paquets supplémentaires et recommence le processus. Cette structure complique l’utilisation efficace des frais de priorité. Par exemple, une transaction hautement prioritaire peut se trouver en tête de la file d’un thread tandis qu’un autre thread traite simultanément, depuis la fin de sa propre file, une transaction assortie de frais de priorité moins élevés et impliquant le même compte. Les frais de priorité influençaient uniquement l’ordre des transactions au sein de chaque thread, et non entre tous les threads. Chaque file d’attente appliquait donc un mécanisme hybride combinant le traitement premier entré, premier sorti (FIFO) et la prise en compte des frais de priorité. Aucun ordre global n’était toutefois imposé entre les threads.

Lorsqu’un thread se prépare à exécuter une transaction, il doit d’abord obtenir les verrous de comptes nécessaires. Si les verrous en écriture requis ne sont pas disponibles, la transaction est replacée dans la file d’attente. L’affectation aléatoire des transactions aux threads aggrave ce problème, car un même type de transaction peut se retrouver à différentes positions dans le système d’ordonnancement multithread. Cette nature stochastique de l’ordonnanceur introduit de la gigue et fait varier la position d’une transaction dans un bloc.

La mise à jour v1.18 du client Agave, publiée en mai 2024, a introduit un nouvel ordonnanceur de transactions, également appelé ordonnanceur central. Dans cette nouvelle structure, l’ordonnanceur central construit un graphe de dépendances appelé prio-graph afin de mieux gérer le traitement et la priorisation des transactions conflictuelles sur l’ensemble des threads. Cette mise à jour majeure a considérablement amélioré la capacité de Solana à ordonner les transactions de manière déterministe : les transactions assorties de frais de priorité plus élevés ont davantage de chances d’être incluses dans les blocs.

Le prio-graph est un graphe orienté acyclique (DAG) mis à jour dynamiquement à mesure que de nouvelles transactions sont ajoutées. Les transactions sont organisées dans le graphe afin de former des chaînes d’exécution traitées par ordre de priorité temporelle. Pour les transactions conflictuelles, les frais de priorité déterminent l’ordre d’insertion. Cette approche minimise les conflits de verrouillage, permet l’exécution fluide de lots de transactions et réduit les retards provoqués par les conflits de ressources. La vérification de précompilation des transactions a été déléguée aux threads de travail afin d’améliorer les performances et l’efficacité du traitement. 

La nouvelle conception de l’ordonnanceur améliore considérablement l’évolutivité et la flexibilité. Elle permet d’envisager une augmentation du nombre de threads sans risquer d’accroître les conflits de verrouillage. En outre, l’approche d’ordonnancement centralisé a amélioré la production de récompenses et augmenté les revenus de nombreux opérateurs de validateurs.

Pour une présentation plus détaillée de l’ordonnanceur central, consultez notre précédent article du blog Helius consacré à la mise à jour Agave 1.18.

Calcul plus efficace de la priorité

Parallèlement à la mise à jour de l’ordonnanceur, la formule de priorité des transactions a été affinée pour avantager les transactions nécessitant moins de calcul, au bénéfice des développeurs et des transactions qui consomment peu de ressources. 

La formule révisée est la suivante :

Priorité = (Frais de priorité * Unités de calcul demandées) + Frais de base / 

(1 + CU d’exécution demandées + CU de signature + CU de verrouillage en écriture)

Ce nouveau calcul tient compte de tous les coûts de calcul et d’exploitation liés à une transaction, afin que les niveaux de priorité représentent précisément la consommation réelle des ressources. Les simples transferts de tokens ou les transactions SOL natives sans frais de priorité supplémentaires bénéficient ainsi d’un niveau de priorité minimal garanti dans la file d’attente. Pour les transactions plus complexes, les développeurs qui omettent de définir une limite de CU personnalisée avec l’instruction `SetComputeUnitLimit` sont désavantagés lors de la priorisation par rapport à ceux qui le font.

Mesure de l’efficacité des marchés de frais locaux

Cette section examine les données pertinentes concernant les LFM de Solana. 

Frais de transaction médians et moyens

Lorsque les LFM fonctionnent efficacement, les frais des transactions qui impliquent des états non disputés, comme de simples transferts de stablecoins, devraient rester faibles. En parallèle, les frais des transactions qui accèdent à des états disputés, comme des tokens spéculatifs peu liquides, devraient bondir avec la demande. Comparer la médiane et la moyenne des frais de priorité des transactions permet d’évaluer cette dynamique. Les frais médians représentent les frais payés par l’utilisateur du 50e percentile et reflètent donc les coûts habituels. Les frais moyens correspondent à la somme de tous les frais divisée par le nombre total de transactions et mettent en évidence les tendances générales.

Les données récentes confirment le schéma attendu. En novembre 2024, l’activité économique sur Solana a atteint son plus haut niveau historique, avec des frais moyens pour les transactions hors vote qui ont dépassé le record de 0,0003 SOL. Malgré cela, les frais médians sont restés stables à 0,00000861 SOL, soit environ 35 fois moins. La situation contraste avec celle d’avril 2024, lorsqu’un pic similaire d’activité économique avait fait grimper les frais moyens au-dessus de 0,0002 SOL et les frais médians à 0,00001862 SOL, soit environ 10 fois moins. Cet écart souligne l’efficacité de l’isolation des frais : elle protège les utilisateurs habituels contre les pics de coûts pendant les périodes de forte demande et préserve l’expérience utilisateur des cas d’utilisation non spéculatifs.

L’analyse de données similaires provenant d’un réseau fondé sur l’EVM sans LFM, comme le L2 Ethereum Base exploité par Coinbase, révèle une forte corrélation entre les frais de transaction médians et moyens. Les frais moyens et médians évoluent relativement à l’unisson, car les frais de base globaux augmentent avec la demande. De plus, l’écart entre les frais de transaction médians et moyens est nettement plus faible. Le 5 décembre 2024, par exemple, les frais de transaction moyens sur Base ont bondi à 0,1115 $, tandis que les frais médians ont également augmenté pour atteindre 0,0228 $, soit environ cinq fois moins.

Taux de transactions annulées

Le taux de transactions annulées constitue une autre tendance utile à examiner. Pendant les périodes de forte activité économique d’avril et mai 2024, les utilisateurs de Solana ont largement signalé une dégradation de l’expérience utilisateur, la chaîne croulant sous un spam massif. Le manque de déterminisme a réduit la prévisibilité et la fiabilité de l’exécution des transactions, poussant les utilisateurs à inonder le réseau de transactions indésirables afin d’augmenter leurs chances d’être inclus plus rapidement. 

Les chercheurs soumettent fréquemment des transactions pour réaliser des opérations opportunistes sans tenir compte de leurs chances de réussite. Les transactions d’arbitrage assorties de frais de priorité trop faibles restent valides. Le protocole les traite après les autres transactions aux frais de priorité plus élevés, et elles sont alors susceptibles d’être annulées par la logique de slippage. 

Les transactions annulées ont atteint un pic en avril 2024, représentant 75,7 % de toutes les transactions hors vote. Ce pourcentage a fortement diminué après le déploiement de mises à jour essentielles, notamment l’ordonnanceur central d’Agave 1.18.

Une analyse par cohorte de Blockworks Research portant sur les sept derniers jours (du 6 au 13 janvier 2024) révèle des taux d’annulation variables selon les niveaux d’activité. Les adresses qui effectuent entre 1 et 5 transactions quotidiennes, principalement des particuliers, enregistrent un taux d’annulation de 1,4 %, qui passe à 4,6 % pour celles effectuant entre 6 et 50 transactions par jour. Les adresses qui réalisent plus de 10 000 transactions quotidiennes affichent un taux d’annulation de 66,7 %. De plus, les adresses à très forte activité qui dépassent 100 000 transactions quotidiennes, c’est-à-dire les bots, sont responsables de 95,2 % de toutes les transactions annulées. En décembre 2024, le taux d’annulation global de toutes les transactions hors vote atteignait 41,2 %, ce qui indique qu’une grande partie des ressources de calcul du réseau sert à traiter des arbitrages ayant échoué.

Problèmes persistants et axes d’amélioration

Malgré des avancées notables, l’ordonnanceur du client de validation Agave reste confronté à plusieurs difficultés. L’analyse suivante de la charge des threads de la phase bancaire, menée par Alessandro Decina, ingénieur chez Anza, met en évidence les inefficacités existantes et les axes d’amélioration.

Thread de l’ordonnanceur : il s’agit du thread le plus important pour produire des blocs. L’ordonnanceur reçoit toutes les transactions entrantes, puis les trie et planifie leur exécution. 

Threads des transactions de vote : deux threads dédiés gèrent les transactions de vote afin de les traiter séparément des transactions des utilisateurs.

Threads des transactions hors vote : quatre threads reçoivent les transactions selon la planification de l’ordonnanceur et traitent celles des utilisateurs.

Threads d’ingestion QUIC : les threads Tokio gèrent l’ingestion des transactions via le protocole QUIC lorsque le validateur est le leader. Pendant la période de congestion du début de l’année 2024, ces threads ont constitué un important goulot d’étranglement.

La visualisation ci-dessus montre que tous les threads de travail exécutent d’abord les transactions en parallèle au début du premier bloc du leader, mais que ce parallélisme se dégrade rapidement en exécution séquentielle. Plus précisément, un seul thread de transactions hors vote, le troisième, continue à traiter les transactions, tandis que les autres restent inactifs.

Ce comportement laisse penser qu’un bug de l’ordonnanceur empêche le client du validateur d’exploiter toute sa capacité. Le système ne fonctionne donc qu’à une fraction de son potentiel. Si ce problème était résolu, le validateur pourrait traiter jusqu’à quatre fois la charge actuelle.

Observabilité

Les API de frais actuelles permettant d’estimer l’arrivée prévisible d’une transaction ne sont pas assez sophistiquées pour fournir des résultats déterministes. Chaque grand fournisseur RPC propose sa propre API personnalisée de frais de priorité, tandis que l’implémentation principale de l’API RPC open source reste sous-optimale. Elle ne tient pas compte de dynamiques réseau essentielles, comme l’influence de Jito, et produit donc des estimations de frais moins précises. 

Helius propose la méthode RPC `getPriorityFeeEstimate`, qui fournit des recommandations de frais fondées sur les données historiques des marchés globaux et des LFM. Les développeurs peuvent transmettre une transaction signée et sérialisée ou une liste des clés de comptes impliquées dans la transaction. La méthode prend en charge des niveaux personnalisés de frais de priorité, répartis en six percentiles : minimum, faible, moyen, élevé, très élevé et maximum risqué. Le niveau moyen, soit le 50e percentile, est la recommandation par défaut. Les frais sont calculés à partir des données des 50 slots les plus récents.

{
 "jsonrpc": "2.0",
 "id": "helius-example",
 "method": "getPriorityFeeEstimate",
 "params": [
   {
     "transaction": "LxzhDW7T...", // Base58 encoded serialized transaction
     "options": {
       "recommended": true
     }
   }
 ]
}

Ci-dessus : exemple de payload pour getPriorityFeeEstimate utilisant une transaction sérialisée encodée en base58.

Sans méthode déterministe de calcul des frais de priorité, les développeurs adoptent souvent une approche prudente et paient trop pour garantir le traitement de leurs transactions. Ils peuvent aussi recourir excessivement aux pourboires Jito, même pour les transactions qui n’ont pas besoin d’être placées en tête de bloc. Ces pourboires servent fréquemment de substitut aux frais de priorité. Fait notable, la plupart des pourboires observés en 2024 ne sont pas liés aux activités MEV traditionnelles, comme l’arbitrage ou le sandwiching, mais visent à accélérer l’inclusion des transactions. Les validateurs profitent de cette inefficacité en percevant des récompenses de bloc et des commissions MEV plus élevées.

Un autre problème apparaît lorsque les développeurs n’implémentent aucune logique pour ajuster dynamiquement leurs frais de priorité en fonction des fluctuations des conditions on-chain. Lors d’événements majeurs, comme des mouvements importants du marché, les frais d’accès à certains comptes d’état peuvent augmenter considérablement. Les applications dépourvues de mécanismes de frais dynamiques rencontrent alors des difficultés, car leurs frais statiques ne suffisent pas à garantir une exécution rapide.

Solutions proposées

Différentes stratégies ont été proposées pour améliorer encore la structure de frais de Solana. Elles visent à optimiser l’allocation des ressources du réseau et à réduire les incitations au spam.

Frais exponentiels de verrouillage en écriture

Proposée en janvier 2023 par Tao Zhu (Anza) et Anatoly Yakavenko, la SIMD-0110 présente un nouveau mécanisme de gestion de la congestion qui impose des frais dynamiques aux comptes disputés. Ce mécanisme suit la moyenne mobile exponentielle (EMA) de l’utilisation des unités de calcul (CU) pour les comptes verrouillés en écriture et augmente le coût du verrouillage en écriture des comptes dont l’utilisation reste élevée.

Pour mettre en œuvre ce système, l’environnement d’exécution de Solana maintient un cache LRU (Least Recently Used) des clés publiques associées aux comptes disputés et de leurs tarificateurs d’unités de calcul (CUP) correspondants. Les CUP surveillent la moyenne mobile exponentielle de l’utilisation des CU d’un compte et fournissent un tarif actualisé lorsqu’ils sont interrogés.

Le mécanisme ajuste dynamiquement les frais de verrouillage en écriture. Le tarif de verrouillage en écriture augmente si la moyenne mobile exponentielle de l’utilisation des CU d’un compte dépasse un seuil cible. À l’inverse, si l’utilisation passe sous cette cible, le tarif diminue. Les paramètres initiaux comprennent :

• Une utilisation cible de 25 % de la limite maximale de CU du compte.
• Un tarif initial de verrouillage en écriture de 1 000 microlamports par CU.
• Un taux d’ajustement des coûts de 1 % par bloc.

Les frais de verrouillage en écriture d’un compte sont calculés en multipliant son tarif par le nombre de CU demandé par la transaction. Dans ce système, les frais totaux de transaction correspondent à la somme de trois composantes : les frais de signature de base, les frais de priorité et les frais de verrouillage en écriture. Les frais de verrouillage en écriture sont brûlés à 100 %.

Lors de sa publication, la SIMD-0110 a suscité un débat animé au sein de la communauté. La proposition est toutefois désormais inactive et a depuis été marquée comme clôturée.

Frais de base dynamiques

Une autre solution à plus long terme pour améliorer les LFM de Solana consisterait à introduire des frais de base dynamiques (DBF) globaux et par compte. Jarry Xiao et Eugene Chen d’Ellipsis Labs comptent parmi les principaux défenseurs de cette approche.

Les frais de priorité sont facultatifs, mais les frais de base sont obligatoires. Les frais de base de Solana sont actuellement fixés à 5000 lamports par signature. Les utilisateurs qui soumettent de simples transferts de tokens paient les mêmes frais de base que ceux qui effectuent des swaps complexes sur plusieurs plateformes ou que les chercheurs qui tentent d’exécuter des arbitrages MEV sophistiqués. Les frais de base ne reflètent pas précisément l’utilisation du calcul par une transaction.

Avec des frais de base dynamiques, une transaction d’arbitrage assortie de frais de base inadaptés peut être considérée comme non valide et abandonnée avant d’atteindre l’ordonnanceur. L’augmentation des frais de base incite les spammeurs à envoyer moins de transactions.

Les frais de base finissent par atteindre un équilibre, et le prix des transactions dépend alors de la valeur du marché de l’espace de bloc. À mesure que les frais de base augmentent, ils finissent par atteindre le coût marginal auquel l’envoi de la transaction ne justifie plus le coût d’opportunité de l’opération. Les frais ne peuvent pas devenir trop élevés, faute de quoi l’activité des utilisateurs serait affectée. L’idéal est un maximum trop élevé pour les bots, mais généralement acceptable pour les utilisateurs. Dans un tel système, les comptes qui envoient en masse des transactions pour obtenir leur inclusion finissent par brûler tous leurs SOL.

La rapidité des blocs de Solana permet d’utiliser des algorithmes agressifs pour définir les frais de base. Pendant les périodes de forte demande, les frais peuvent être ajustés rapidement, et potentiellement doubler à chaque bloc, afin de refléter la congestion du réseau. À l’inverse, lorsque la demande diminue, ils peuvent être réduits plus progressivement. Grâce aux courts temps de bloc de Solana, cette baisse reste relativement rapide et permet au réseau de s’adapter vite à l’évolution des conditions.

Le programme Metaplex Candy Machine constitue un exemple de pression économique dissuasive similaire. En 2022, il a instauré une taxe sur les bots comme mécanisme anti-spam. Cette taxe est facultative et s’applique aux transactions non valides. Son montant est généralement assez faible pour ne pas pénaliser les véritables utilisateurs qui ont commis une erreur de bonne foi. Cette taxe s’est révélée efficace : les bots spécialisés dans le mint ont rapidement épuisé leurs fonds et le spam a cessé.

Conclusion

Les LFM de Solana fonctionnent, mais leur potentiel d’amélioration reste considérable :

• Améliorer les mécanismes de frais de priorité : les appels RPC relatifs aux frais de priorité doivent être améliorés. Dans l’idéal, les développeurs devraient disposer d’un moyen simple et déterministe de définir des frais garantissant l’inclusion d’une transaction dans les quelques blocs suivants.
• Décourager économiquement le spam : le réseau doit trouver comment exercer une pression économique dissuasive contre les bots pendant les périodes de forte activité, tout en maintenant des frais faibles pour les véritables utilisateurs humains.
• Former les développeurs : les développeurs doivent cesser de définir des frais de transaction statiques dans leurs applications et moins dépendre de mécanismes hors protocole comme Jito pour les transactions courantes.
• Poursuivre l’optimisation de l’ordonnanceur : l’ordonnanceur de transactions doit encore être optimisé afin que tous les threads de travail soient utilisés pendant les périodes de forte demande.

Comme le souligne Anatoly Yakovenko, cofondateur de Solana, ces difficultés ne sont principalement « que des problèmes d’ingénierie » et peuvent être résolues avec l’attention technique appropriée.

Ressources supplémentaires

• Frais Solana, partie 1 - Umbra Research
• Vers des frais Solana multidimensionnels - Umbra Research
• Les marchés de frais locaux sont indispensables à la mise à l’échelle d’Ethereum - Eclipse Labs
• Les marchés de frais locaux de Solana ne sont pas réels | Eugene Chen - Lightspeed Podcast
• Phase bancaire et ordonnanceur de Solana - A.Fitzgerald