Faire suivre le titre original：Solana & Mécanismes de frais de transaction Ethereum : des propositions visant à améliorer le TFM de Solana

Merci à Andrew Fitzgerald, Harsh Patel, Jon Charbonneau, Kevin Galler, Lanre Ige, Mert Mumtaz, Pranav Garimidi, Ryan Chern, Tao Zhu et Tarun Chitra pour leurs commentaires et leurs critiques.

Introduction

Eclipse est la première SVM L2 d'Ethereum. Nous sommes très enthousiastes à l'idée de mettre la puissance de la SVM existante à un plus grand nombre d'utilisateurs, mais nous sommes également déterminés à faire avancer la R & D autour de la SVM elle-même. Nous mettons tout en œuvre pour que le développement d'Eclipse redonne indéniablement de la valeur à toutes les chaînes SVM, en particulier à Solana.

En guise de précurseur des prochains articles sur notre réflexion sur les marchés des frais, cet article analysera le marché des frais existant de Solana et les propositions associées pour l'améliorer. Nous formulons ces propositions en fonction des principaux objectifs théoriques de tout mécanisme de frais de transaction (TFM), en nous inspirant largement des travaux de Tim Roughgarden, Maryam Bahrani, Pranav Garimidi, Hao Chung, Elaine Shi et d'autres. Nous indiquerons les définitions de base partout par **.

En général, un TFM détermine :

1. Quelles transactions sont incluses dans un bloc donné,
2. Les frais payés par une transaction donnée, et
3. Comment (et à qui) les frais de transaction cumulés sont répartis.

En fin de compte, cet article vise à associer la richesse des recherches sur la TFM centrées sur Ethereum à l'ingénierie innovante de Solana.

Vue d'ensemble des TFM actuels de Solana & Ethereum

Solana contre Ethereum Basics

Nous allons commencer par un aperçu du TFM de Solana et le comparer à celui d'Ethereum. Cela permettra de mieux contextualiser les propositions pertinentes afin que nous puissions travailler à modifier et à améliorer le TFM. Pour commencer :

Les frais de base de Solana sont fixes de 5 000 lamports (0,000005 SOL) par signature, et la plupart des transactions ne comportent qu'une seule signature. Cela ne tient pas compte des ressources de calcul générales d'une transaction (mesurées en unités de paiement).

Frais de base de Solana Tx = (5 000 lamports) x (nombre de signatures au Texas)

Le mécanisme de frais de base d'Ethereum diffère de deux manières principales :

1. Dynamique - Les frais de base d'Ethereum (mesurés en gwei par unité de gaz) varient en fonction de la demande du marché.
2. Des frais plus précis par unité de calcul - Les frais de base par transaction d'Ethereum sont linéaires en ce qui concerne la quantité de gaz consommée.

Les frais de base par transaction d'Ethereum sont donc de :

Frais de base Ethereum Tx = (Prix actuel du gaz en gwei) x (gaz utilisé au Texas)

Les utilisateurs de Solana peuvent également ajouter des frais de priorité facultatifs pour améliorer leur probabilité d'inclusion. Contrairement aux frais de base, les frais de priorité sont facturés par unité monétaire demandée pour une transaction. Les transactions Solana peuvent inclure les instructions suivantes sur le budget de calcul:

1. SetComputeUnitLimit - Les transactions peuvent définir la quantité maximale d'UC qu'elles sont autorisées à consommer (avec un maximum de 1,4 million d'unités par transaction). Une fois exécutée, la transaction peut utiliser jusqu'à la limite d'UC demandée. Si aucune instruction SetComputeUnitLimit n'est fournie, la limite de CU de la transaction est calculée comme suit : (nombre d'instructions dans la transaction) x (200 000 UC).
2. SetComputeUnitPrice - Nombre de micro-lampes par unité centrale ont demandé à ce que la transaction propose de payer ses frais de priorité.

Les assembler :

Tax Priority Fee = (Tx CU Limite) x (Prix CU)

Notez que ces frais de priorité sont payés sur la totalité des UC demandées (que la transaction utilise le montant total demandé ou non), contrairement à Ethereum, où les frais dépendent de la quantité de gaz réellement consommée par la transaction.

Fee Burn contre Validator Rewards

Bien que l'incitation des validateurs à donner la priorité aux transactions onéreuses ne soit pas consensuelle, elle est imposée par consensus selon laquelle les frais de base et les frais de priorité sont brûlés à 50/50 et envoyés au leader (actuel producteur de blocs) de Solana :

1. Tarif de base — Obligatoire pour l'inclusion d'un bloc. Les transactions ne respectant pas les frais de base requis seront rejetées.
2. Frais de priorité — Ce n'est pas obligatoire pour l'inclusion dans un bloc. Utilisé pour donner la priorité aux transactions qui souhaitent augmenter leurs chances d'inclusion rapide.

Un utilisateur ne peut pas éviter de payer les frais de base, mais il peut éviter les frais de priorité et faire part de son désir d'être prioritaire d'une autre manière. Nous le constatons déjà dans la pratique : les ventes aux enchères Jito-Solana versent 100 % (moins les frais) au leader hors bande. La carte SIMD-0096 propose une solution simple à ce problème en attribuant 100 % des frais de priorité au validateur.

Transfert direct* : coordonné via les ventes aux enchères MEV-Boost/Jito-Solana

Il est important de noter que les validateurs Solana votent pour chaque bloc contenant des transactions en chaîne. Ils paient les frais de base pour chacune de ces transactions.

Solana a atteint son plus haut niveau historique en termes de frais de réseau ces derniers temps, grâce à une forte hausse des frais de priorité. Les derniers barèmes de frais sont indiqués ci-dessous :

Source : Solana Compass

Ethereum Block Builder contre Solana Scheduler

La production de blocs d'Ethereum est généralement plus facile à comprendre, nous allons donc commencer par là. Presque tous les validateurs (alias proposants) externalisent la production de blocs à des constructeurs hors protocole via MEV-Boost. Les constructeurs créent des blocs toutes les 12 secondes (heure d'Ethereum) et transmettent ces blocs entiers au proposant (via un relais), qui sélectionne le bloc le plus élevé.

Dans Ethereum comme dans Solana, les producteurs de blocs ont le pouvoir d'ordonner des transactions de manière arbitraire au sein d'un bloc. Ils sont incités à le faire de manière à maximiser leurs profits. Par exemple, différents constructeurs d'Ethereum peuvent s'affronter en utilisant des algorithmes propriétaires qui maximisent les profits de manière plus efficace par rapport à leurs concurrents.

Cela signifie que même dans Ethereum, l'envoi de frais hautement prioritaires ne garantit pas de manière déterministe intégrée au protocole l'inclusion ou la commande des blocs. Cependant, il est fort probable que le résultat escompté soit obtenu en raison de la nature du processus actuel de création de blocs d'Ethereum, dans le cadre duquel le constructeur crée un bloc complet pour maximiser les profits à la fin de chaque créneau.

Par exemple, un chercheur peut envoyer une transaction d'arbitrage avec des frais de priorité incroyablement élevés (par exemple, plus élevés que toutes les autres transactions éligibles combinées) au constructeur, en demandant son inclusion en haut du bloc et en excluant complètement la transaction du bloc si elle n'arrive pas en tête du bloc. Dans ce cas, un constructeur rationnel qui maximise ses profits inclura cette transaction en haut du bloc, même s'il ne l'a reçue que vers la fin de son créneau de 12 secondes.

Vous remarquerez que les frais essaient d'obtenir deux garanties différentes ici :

1. Inclusion - Un utilisateur souhaite que sa transaction soit incluse dans ce bloc, peu lui importe où elle se trouve dans le bloc.
2. Commande - Un utilisateur ne veut pas simplement être inclus dans le bloc n'importe où ; il souhaite accéder en priorité à un état précis à un moment donné.

Le mécanisme EIP-1559 d'Ethereum s'est révélé très efficace pour permettre aux utilisateurs d'enchérir facilement pour l'inclusion de blocs avec de fortes chances de succès. Il existe un prix de réserve mondial que tout le monde sait qu'il faut payer, et le payer (généralement en plus de frais de priorité minimes) devrait permettre d'inclure rapidement la transaction de l'utilisateur. Cependant, le mécanisme ne cherche pas à fournir de garanties concernant les commandes (c'est-à-dire un accès prioritaire à l'État), alors que les mécanismes hors protocole sont fiables pour les utilisateurs qui recherchent de telles garanties (directement auprès des constructeurs, par exemple).

Le processus de création de blocs de Solana fonctionne très différemment. Les validateurs n'externalisent pas la production de blocs complets sur des créneaux horaires distincts à des créateurs hors protocole. Le « planificateur » est l'algorithme par défaut inclus dans le client de validation de Solana Labs, qui planifie l'exécution des transactions et crée des blocs en continu.

De plus, les transactions Solana précisent quels comptes doivent être verrouillés en lecture et en écriture pour être exécutés. Cela permet au planificateur de trier de manière itérative les transactions qui peuvent être exécutées simultanément, car les transactions qui n'ont pas le même état peuvent être exécutées en parallèle.

Au sein d'un bloc, un maximum de 12 000 000 UC peuvent être utilisés pour des écritures séquentielles sur un seul compte (« élément d'état »). C'est à peu près le nombre de CU qui peuvent être traitées par un seul thread par créneau de 400 ms avec des exigences raisonnables en matière de nœuds. La limite par bloc de Solana est alors de 48 000 000 UC. L'implémentation actuelle du planificateur utilise quatre fils de discussion pour les transactions sans droit de vote, et 12 millions x 4 = 48 millions. En théorie, cela signifie utiliser plus de cœurs = augmenter les limites de CU. Mise à l'échelle grâce au matériel.

Le planificateur donne la priorité aux transactions dont les frais de priorité sont plus élevés de manière non déterministe. Cependant, cela fournit généralement des garanties de priorisation moins fiables que les mécanismes tels que ceux décrits dans le cas d'Ethereum aujourd'hui.

Dans Solana, les validateurs qui exécutent le planificateur par défaut créent des blocs en continu, de sorte que les transactions peuvent être ajoutées à un bloc en cours et exécutées avant la fin du créneau, afin de les organiser uniquement par priorité. L'intention est que le planificateur maximise ses profits en donnant la priorité aux transactions en fonction de leur prix total en espèces.

Le planificateur multithread par défaut de Solana ajoute également de la « nervosité ». Les transactions sont attribuées de manière aléatoire à l'un des quatre fils de discussion, chaque thread gérant sa propre file de transactions en attente d'exécution. Les frais de priorité sont ensuite utilisés pour hiérarchiser les transactions intra-thread. Cependant, ils ne permettent pas de hiérarchiser les transactions entre les fils de discussion.

Par exemple, deux chercheurs peuvent envoyer une transaction simultanément pour saisir la même opportunité d'arbitrage, et celui qui envoie des frais de priorité moins élevés peut même gagner car il se retrouve dans une file d'attente moins encombrée par hasard. Cela réduit l'efficacité des frais de priorité et incite au spam par rapport à Ethereum, d'autant plus que l'inclusion des transactions dépend également du moment où, dans un créneau donné, une transaction parvient au producteur de blocs actuel.

Notez que des modifications sont prévues au planificateur par défaut de Solana, dans le but de résoudre certains problèmes liés à l'implémentation actuelle en s'appuyant sur un graphique des dépendances des transactions et en planifiant les transactions débloquées (non bloquées en écriture) les plus prioritaires dans le graphique. Nous y reviendrons plus loin dans l'article.

Bien que cela n'entre pas dans le cadre de cet article, le client Jito-Solana permet aux chercheurs de saisir plus efficacement la valeur extractible mineur/maximale (MEV) de manière à minimiser les externalités négatives sur Solana. Jito-Solana s'écarte du planificateur par défaut de Solana en introduisant des enchères de lots discrètes hors protocole de 200 millisecondes, à la manière des Flashbots, qui sont organisées en parallèle à la production de blocs en continu par défaut et à un mempool privé (qui s'écarte encore une fois du TFM par défaut de Solana). L'adoption du client Jito-Solana par les validateurs Solana (> 50 % des validateurs l'utilisent aujourd'hui) a permis de résoudre certains problèmes liés au TFM existant de Solana, à savoir la prévalence du spam généré par MEV.

Les défauts du TFM actuel de Solana

Bien que le TFM de Solana soit très prometteur, il présente également quelques lacunes potentielles pour le moment :

Incitation au spam

Comme indiqué plus haut, les transactions sont classées selon le principe du premier entré, premier sorti (FIFO) dès qu'elles parviennent au producteur du bloc. De plus, ils ne sont pas déterminés à la fois en raison de la gigue du réseau et de l'allocation aléatoire des threads par le planificateur par défaut. Bien que les frais de priorité puissent améliorer la probabilité d'inclusion dans certaines circonstances, il existe toujours une forte incitation à spammer les transactions afin de maximiser la probabilité d'inclusion le plus rapidement possible (par exemple, un chercheur fait la course pour liquider une position en défaut sur un marché du crédit). L'image ci-dessous, prise par Jito Labs, montre à quel point les transactions de spam ne sont pas optimales.

Source : Fondation Jito

Enchère au premier prix

Lors d'une vente aux enchères naïve au premier prix (FPA), les utilisateurs soumettent simplement des offres, la plus élevée étant incluse dans le bloc. L'un des problèmes avec les FPA, c'est qu'ils ne sont pas très conviviaux. Les utilisateurs doivent deviner quelles sont les offres des autres utilisateurs, réfléchir à ce qu'ils sont prêts à enchérir, éventuellement en abaissant leur enchère pour ne pas payer trop cher en fonction de ce qu'ils pensent que les autres enchérissent, par exemple.

Plus formellement, le modèle FPA n'est pas un modèle DSIC :

**Compatible avec les incitations à la stratégie dominante (DSIC) : en supposant que le producteur de blocs mette en œuvre le TFM honnêtement, la stratégie d'enchères prescrite devrait être la stratégie dominante pour les utilisateurs. Cela signifie que les utilisateurs enchériront (en frais de transaction) à la valeur exacte qu'ils attribuent à l'inclusion des transactions [Chu22].

Le DSIC est l'une des principales propriétés que les créateurs de l'EIP-1559 souhaitaient introduire dans le TFM d'Ethereum lors de sa mise en œuvre, et comme nous l'avons décrit précédemment, elle peut être considérée comme un succès. Les utilisateurs connaissent plus facilement le prix de réserve public à inclure dans le bloc à un moment donné (via les frais de base dynamiques). Le payer (plus les frais de priorité nominaux) permettra presque toujours d'inclure votre transaction rapidement.

À l'inverse, le TFM de Solana est un FPA naïf. Il ne dispose pas d'un mécanisme fiable permettant aux utilisateurs d'exprimer avec précision leurs préférences en matière d'inclusion de blocs et il ne s'agit pas d'un système DSIC. Dans la pratique, il est extrêmement difficile d'essayer de fixer exactement le bon tarif de priorité au bon moment. Cela favorise de manière disproportionnée les participants avertis qui sont plus à même de contourner les perturbations du réseau et du planificateur (par exemple, par le biais de transactions de colocation ou de spamming).

Paiement 50/50 Burn/Validator

Comme indiqué précédemment, Ethereum brûle 100 % des frais de base tout en envoyant 100 % des frais de priorité au producteur de blocs, tandis que pour Solana, les frais de base et les frais de priorité sont brûlés/payés à 50/50 au producteur de blocs. De ce fait, le Solana TFM n'est pas résistant à l'OCA :

**Proofness des accords hors chaîne (OCA-proofness ou SCP) : aucun accord hors chaîne entre les utilisateurs et le producteur de blocs ne peut améliorer le résultat du TFM pour un bloc donné [Rou21]. Un protocole c-SCP résiste à ce qu'une coalition entre le producteur de blocs et un maximum de c utilisateurs puissent tirer profit en s'écartant de l'obligation de publier des informations véridiques.

Nous en voyons un exemple clair : les ventes aux enchères hors protocole de Jito-Solana versent 100 % des offres (moins la part de Jito) aux producteurs de blocs, au lieu d'en brûler 50 %. Jito-Solana est un exemple d'accord hors chaîne utilisé par les producteurs de blocs. Nous remarquons toutefois que les pourboires Jito-Solana ne sont pas équivalents à des frais de priorité, car les premiers ne sont payés que si la transaction (et le bundle) associés sont exécutés avec succès.

Le SIMD-0109 récemment proposé introduirait un mécanisme de basculement (similaire à celui utilisé par les enchères hors protocole de Jito-Solana) dans le protocole en tant qu'instruction native.

Absence de types de transactions privilégiées

Les transactions de vote Solana sont publiées en chaîne et doivent être incluses dans des blocs, mais chaque validateur doit payer le coût de ces transactions. Cela représente un coût fixe important (payé en privé par les validateurs) malgré l'externalité positive liée à l'inclusion des transactions de vote. Ce coût est aggravé par le fait que les transactions de vote sont surfacturées par rapport aux UC consommées (c'est-à-dire qu'elles utilisent relativement peu d'UC par rapport à la moyenne des transactions). L'économie a un effet centralisateur, car le coût total des votes est à peu près constant pour tous les validateurs, tandis que les récompenses gagnées sont proportionnelles au poids de la mise.

Source : Ceteris, Solana le monolithe

Soit dit en passant, une logique similaire pourrait être étendue pour inclure des mises à jour fiables d'Oracle, que les réseaux facturent généralement malgré l'externalité positive liée à la précision des flux de prix en chaîne. Une chaîne plus opiniâtre qui tire une grande valeur d'un oracle particulièrement robuste peut choisir d'intégrer un mécanisme qui subventionne ses coûts.

Le marché local de Solana

L'approximation de Solana d'un mécanisme de frais local existe parce qu'aucun compte ne peut écrire plus de 12 millions de CU par limite de 48 millions de blocs. Ceci, ajouté à la nature multithread du planificateur par défaut de Solana, signifie qu'un maximum de 25 % des transactions d'un bloc peuvent correspondre à un seul état de demande. En théorie, les utilisateurs d'un État moins demandé ne devraient pas avoir à augmenter leurs frais de priorité pour obtenir de solides garanties d'inclusion par rapport aux utilisateurs d'un État où la demande est faible.

Il ne s'agit sans doute pas d'un véritable mécanisme de tarification local. Le mécanisme n'est pas appliqué par consensus (il ne concerne que le planificateur), et la relation entre les frais de priorité et l'inclusion de blocs n'est pas déterministe (comme indiqué précédemment). Il n'y a pas non plus de notion d' « élasticité » en ce qui concerne les limites de ressources cibles et maximales.

Utilisation inefficace de la CPU : requêtes &

Comme les frais de base de Solana ne tiennent pas compte des UC, ils n'incitent pas les transactions à :

1. Utilisez efficacement les UC — Une transaction avec 1,4 million d'UC entraîne les mêmes frais de base qu'une transaction avec 100 000 UC, toutes choses égales par ailleurs.
2. Demandez des UC de manière efficace — Même si une transaction utilise 50 000 UC, les frais de base sont les mêmes, qu'elle demande 100 000 UC ou 1 million de CU.

Cela peut entraîner une surestimation du calcul nécessaire au sein d'un bloc donné par le planificateur et une perte d'efficacité par rapport aux ressources requises par le producteur de blocs sur un créneau donné. Un TFM DSIC résoudrait ce problème, car la stratégie dominante de l'utilisateur serait la stratégie d'enchères prescrite, en l'occurrence, une représentation précise de l'utilisation attendue des UC.

Write Lock Accounts est gratuit

Comme indiqué précédemment, les transactions Solana indiquent à l'avance tous les comptes sur lesquels elles peuvent lire ou écrire pendant l'exécution. Cependant, ce mécanisme peut être utilisé à mauvais escient aujourd'hui pour verrouiller n'importe quel compte dans le monde entier, sans frais. Par exemple :

1. J'envoie Tx_A qui précise qu'il sera écrit sur le compte_A.
2. Le leader reçoit la taxe_A, la planifie et commence à l'exécuter. Le compte_A est désormais bloqué. Aucune autre transaction concernant le compte_A ne peut être exécutée tant que Tx_A n'a pas terminé son exécution.

Le problème vient du fait que n'importe qui peut effectuer des transactions bloquant les comptes de son choix. Le verrouillage des comptes est gratuit, et les transactions peuvent même bloquer des comptes qu'ils n'utilisent pas, ce qui constitue clairement un vecteur d'attaque de spam. De plus, les propriétaires de comptes ne peuvent pas décider qui peut bloquer leur propre compte.

Propositions TFM & Frameworks

Chaque blockchain doit décider en fin de compte de la manière dont elle répartira les rares ressources de son espace de blocs limité entre les utilisateurs, ce qu'elle fait via son TFM. Ci-dessous, nous aborderons plusieurs propositions et frameworks TFM pertinents qui pourraient être utiles pour Solana.

Marchés payants multidimensionnels de la blockchain

La plupart des marchés de frais existants sont unidimensionnels, construits autour d'une seule unité de compte fongible (par exemple, le gaz dans Ethereum). Cependant, cette ressource unique achetée est un proxy pour de nombreuses ressources sous-jacentes non fongibles (par exemple, la bande passante, le calcul et le stockage).

Par exemple, chaque opcode Ethereum contient une certaine quantité fixe de gaz qu'il consomme (par exemple, ADD en utilise 3 et MUL en utilise 5). Le prix du gaz pour chaque opcode a été fixé comme une approximation approximative des ressources sous-jacentes qu'ils utilisent et de leur coût estimé pour les nœuds du réseau. Par exemple, cette mesure implicite du coût d'une opération peut être déterminée en effectuant des tests sur du matériel réel.

Cependant, il est également possible de créer des marchés de frais multidimensionnels qui fixent individuellement le prix de ces différentes ressources non fongibles au lieu de les combiner en une seule unité. L'EIP-4844 est un marché de frais bidimensionnel simple, car les blobs de données ont leur propre marché de frais, indépendant du gaz d'exécution d'Ethereum.

Cet article de 2022 de Diamandis, Evans, Chitra et Angeris analyse comment créer des marchés de frais multidimensionnels comme celui-ci. Leurs travaux présentent le problème de construction de la TFM du point de vue d'un concepteur de réseau dans le but de maximiser le bien-être (ou l'utilité totale) des utilisateurs de la blockchain, sans tenir compte de leur consommation de ressources, sous réserve des contraintes de transactions et de blocs de la chaîne (par exemple, les limites des contrats intelligents ou les limites de cu/gaz). Le principal résultat de cet article est que, bien que le bien-être soit inconnu, l'entreprise conçoit un mécanisme qui le maximise et montre comment le construire explicitement.

**Optimisation du bien-être : Les règles d'allocation et de paiement prévues impliquent que la somme des excédents des consommateurs et des mineurs est (approximativement) maximisée.

Leur principale conclusion est qu'un TFM équivalent est implémentable, c'est-à-dire un TFM dans lequel le prix de la ressource est fixé de manière à minimiser la différence entre le bien-être des validateurs et celui de ses utilisateurs. Un tel prix devrait donner lieu à des blocs qui, en théorie, sont optimaux du point de vue de l'optimisation du bien-être. Bien que ce travail puisse être considéré davantage comme un cadre académique pour concevoir des TFM optimaux, il permet de montrer que la tarification séparée des ressources peut rendre une blockchain plus efficace et plus résistante aux périodes de forte congestion ou de spam. Les mécanismes de frais de base basés sur les contrôleurs, tels que l'EIP-1559, sont considérés comme une approche potentielle qui pourrait fonctionner exceptionnellement bien sur les chaînes Solana et SVM, compte tenu des temps de blocage courts, permettant à la redevance de base de s'adapter rapidement à l'évolution de la demande des utilisateurs et de la disponibilité des ressources.

Comme indiqué précédemment, l'une des conclusions de l'article est qu'il est possible de concevoir des moyens systématiques et efficaces sur le plan informatique pour aider à définir et à mettre à jour la tarification des ressources multidimensionnelles pour les blockchains. Cependant, la question qui se pose naturellement est la suivante : quelles ressources seraient judicieuses pour fixer des prix distincts ? Certains travaux pratiques ont été réalisés dans d'autres contextes de blockchain pour prendre de telles décisions. Par exemple, Penumbra a mis en place une forme de tarification multidimensionnelle des ressources afin de fixer le prix des ressources utilisées par les nœuds complets et les appareils des utilisateurs finaux séparément sur sa blockchain axée sur la confidentialité.

Alors que l'article de 2022 traite généralement de la tarification multidimensionnelle des ressources de base (par exemple, le calcul, la bande passante, le stockage), il est également possible de mettre en œuvre une tarification multidimensionnelle des ressources par compte (c'est-à-dire par « élément d'état »). Chaque compte est traité comme une ressource différente. Cela est abordé dans cet article récent, qui s'appuie sur l'article original. La tarification individuelle des comptes (plutôt que du calcul, du stockage, de la bande passante, etc.) en tant que ressource sous-jacente peut également être plus simple à mettre en œuvre avec un risque réduit d'attaques par épuisement des ressources.

Frais exponentiels pour les comptes Write Lock

Suite au récent billet d' Anatoly sur SVM Execution Economics, Tao Zhu, en collaboration avec Anatoly, a proposé le SIMD-0110. Sa principale motivation est de décourager le spam en exerçant une pression économique (c'est-à-dire en augmentant les frais de manière ciblée au fil du temps afin de réduire l'incitation au spam), afin d'utiliser plus efficacement les ressources du réseau. Les transactions d'arbitrage qui ont échoué continuent de remplir environ la moitié (ou plus) de l'espace de blocage de Solana parce que c'est rationnel et incroyablement bon marché de spammer.

La proposition recommande de suivre la moyenne mobile exponentielle (EMA) de l'utilisation des unités de traitement par bloc de chaque compte pour y parvenir. Le coût du blocage en écriture d'un compte augmenterait de façon exponentielle en fonction de son utilisation de la dernière unité de traitement, afin de dissuader le spam. La logique de base est similaire à la manière dont l'EIP-1559 fixe les frais de base mondiaux d'Ethereum en fonction de la consommation de gaz dans les derniers blocs. Cependant, ce SIMD est beaucoup plus précis lorsqu'il s'agit de définir les marchés de frais de base locaux par compte.

L'idée de base de la mise en œuvre des frais de blocage d'écriture variables en fonction des comptes serait la suivante :

1. Suivez l'utilisation des unités de calcul EMA de chaque compte litigieux au cours des 150 dernières machines à sous.
2. Le nombre maximum de comptes qui seront suivis est de 2 048, seuls les comptes les plus litigieux présentant le taux de blocage des écritures le plus élevé étant suivis.
3. Si le taux d'utilisation des unités de calcul EMA d'un compte est de > à 50 % de sa limite maximale d'unités de traitement, son taux de blocage des écritures augmentera de X %. Si c'est < à 50 % de sa limite, le taux de coût diminuera de X %.
4. La V0 recommande un taux de coût initial de blocage d'écriture de 1 000 micro-lamports/cu et un taux d'ajustement des coûts de 1 % par emplacement (notez que les pourcentages exacts sont tous sujets à modification étant donné le caractère précoce de la proposition).
5. Les frais de blocage d'écriture pour un compte appartenant à un bloc donné sont calculés en multipliant le taux de blocage d'écriture par les UC demandées pour la transaction.
6. Les transactions continuent de payer des frais de signature, et les frais de priorité facultatifs sont également maintenus.
7. Les frais de blocage des écritures collectés sont brûlés à 100 %.
8. Les frais prioritaires collectés sont récompensés à 100 %.
9. Les frais de signature collectés sont brûlés à 50 % et récompensés à 50 %.

Cette proposition rendrait la fonction de verrouillage en écriture de Solana (généralement) similaire à la façon dont EIP-1559 a créé le DSIC et le MMIC [Rou23] du TFM d'Ethereum (généralement), sauf en cas de pics de frais soudains.

Nous pouvons définir la propriété MMIC comme suit :

**Myopic Miner Incentive Compatibility (MMIC) : Le producteur de blocs maximise son utilité en ne créant aucune fausse transaction et en suivant les règles énoncées par le TFM. Myope signifie que cet objectif ne concerne que le bloc actuel pour juger de la maximisation de l'utilité [Rou21].

Tout mécanisme de suivi est imparfait dans la mesure où il peut ne pas représenter exactement l'état actuel de la demande. Par exemple, la demande peut être faible pendant une longue période (et donc, les frais de base dynamiques sont faibles), puis augmenter soudainement pour un NFT mint. Cela peut être le cas au niveau mondial (comme dans le TFM d'Ethereum) et peut être encore plus volatil au niveau local par compte (comme le montre SIMD-0110).

Cependant, Solana bénéficie également de ses temps de blocage incroyablement bas. Cela peut permettre au tarif de base de s'adapter plus rapidement à un choc soudain de la demande, en fonction de l'agressivité de la courbe. La forme du contrôleur des frais est extrêmement importante.

Le fait que ces frais de blocage d'écriture soient facturés sur les UC demandées incite également les utilisateurs et les développeurs à estimer avec précision l'utilisation des UC d'une transaction. Cela permet d'éviter le problème dont nous avons parlé tout à l'heure, selon lequel la base de signature plate actuelle n'entraîne aucune pénalité si vous demandez beaucoup plus de CU que nécessaire (même jusqu'à 1,4 mm au maximum). Sinon, seuls les frais de priorité sont assortis de cette incitation aujourd'hui (car ils sont également facturés par les UC demandées).

L'une des critiques potentielles est que les marchés payants locaux basés sur les comptes (en particulier cette proposition, qui oblige à calculer une EMA permanente pour chaque compte) peuvent être coûteux en termes de calcul. Ce type de frais multidimensionnels est illimité, étant donné que n'importe quel compte peut être encombré, ce qui poserait probablement des difficultés pour un tel TFM. Cependant, dans le cas de SIMD-0110, cela est évité en fixant une limite supérieure au nombre de comptes dont l'utilisation du CU par EMA peut être suivie à un moment donné.

**Calculable efficacement : Le mécanisme d'enchère par blocs doit être conçu de manière à pouvoir être calculé efficacement pour un producteur (ou un constructeur) de blocs donné. Les machines à sous d'Eclipse et Solana mesurent moins de 400 ms, ce qui limite fortement le temps de calcul maximum pour un bloc donné.

Étant donné que l'inclusion des blocs Solana ne serait toujours pas déterministe même avec la mise en œuvre de cette proposition, il peut toujours y avoir des problèmes avec les utilisateurs qui mettent à jour leurs offres avec précision et en temps réel pour s'assurer que leurs transactions sont incluses dans les blocs. Pour résoudre ce problème, il faut modifier le planificateur, comme nous le verrons dans la section suivante.

Modifications apportées au planificateur par défaut de Solana

Comme indiqué précédemment, le « planificateur » est l'algorithme par défaut inclus dans le client de validation de Solana Labs, qui planifie l'exécution des transactions et crée des blocs en continu. Il joue un rôle extrêmement important sur le marché des frais de Solana, même si son comportement par défaut n'est pas appliqué dans le protocole, car les validateurs peuvent choisir d'exécuter d'autres algorithmes. Nous allons nous concentrer ici sur le calendrier actuel et les modifications proposées à venir, sur lesquelles travaille Andrew Fitzgerald.

Le planificateur actuel de Solana apporte de la « nervosité » dans la gestion des transactions des utilisateurs en les affectant de manière aléatoire à l'un des quatre fils de discussion sans droit de vote (deux fils supplémentaires sont réservés au traitement des transactions de vote) avant d'essayer de trier les transactions en cours par priorité et de vérifier les verrous correspondants (« lock grab »), comme le montre le schéma ci-dessous. Plusieurs lots de transactions sont extraits pour être attribués à des fils de discussion pendant la « phase bancaire », le processus géré par un validateur Solana au cours duquel les transactions sont traitées et dans le cadre duquel le processus de planification a lieu.

Source : Andrew Fitzgerald, Solana Banking Stage and Scheduler

L'un des problèmes majeurs liés au planificateur par défaut est qu'en période d'activité intense sur le réseau, la file d'attente de chaque fil de discussion est souvent remplie de transactions contradictoires (par exemple avant un NFT ou un événement de génération de jetons très attendu). Chaque fil de discussion peut contenir des transactions dont les verrous de lecture ou d'écriture sont identiques ou qui se chevauchent, ce qui signifie que ces transactions doivent être reprogrammées pour une exécution ultérieure. Il en résulte que, dans le pire des cas, seul l'un des quatre threads du planificateur par défaut pourrait exécuter des transactions à la fois.

L'essentiel de la mise à niveau du planificateur par défaut de Solana réside dans le passage de l'ancienne approche (appelée mode ThreadLocalMultiIterator) à la nouvelle approche de planification, appelée mode CentralScheduler. Cet article ne fournira qu'un aperçu et une analyse des changements. Vous trouverez toutefois de plus amples informations dans l'article d'Andrew Fitzgerald et dans le résumé < a href= " https://medium.com/@harshpatel_36138/whats-new-with-solana-s-transaction-scheduler-bcf79a7d33f7 " >, résumé du billet de blog écrit par Harsh Patel de l'équipe Tiny Dancer. Vous trouverez ci-dessous un aperçu du nouveau processus de planification.

Source : Andrew Fitzgerald, Solana Banking Stage and Scheduler

Le nouveau planificateur implique un planificateur unique central qui reçoit les transactions du canal avant de vérifier les verrous correspondants. Ensuite, les transactions sont attribuées à des threads de travail parallèles spécifiques pour être exécutées. Le planificateur central affiche les différents verrous de lecture et d'écriture utilisés par un thread de travail donné, ce qui lui permet de déterminer le meilleur thread pour une nouvelle transaction. Au fur et à mesure que les transactions sont exécutées et traitées par un thread de travail donné, un message est renvoyé au planificateur central afin que celui-ci puisse réévaluer quelles parties de l'état de Solana sont considérées comme bloquées.

Le planificateur utilise un algorithme appelé « prio-graphe », qui est un graphique acrylique direct qui commence par les transactions les plus prioritaires (frais) et des lignes (ou, plus précisément, des bords) entre les transactions les plus prioritaires et les transactions les plus prioritaires suivantes, qui entrent en conflit avec celui-ci en raison de verrous qui se chevauchent. C'est fait (provisoirement) pour une fenêtre « prospective » d'une taille préconfigurée de 2 048 transactions (sous réserve de modification), qui peut être ajoutée au graphique. Les graphiques suivants montrent que le priographe fonctionne pour un ensemble donné de transactions où les arêtes entre elles représentent des verrous contradictoires.

Outre l'adoption du planificateur prio-graphique, cette version apporte des gains d'efficacité supplémentaires afin de réduire les frais de traitement, comme la suppression des éléments redondants de la phase bancaire. Le nouveau planificateur devrait s'améliorer en réduisant de manière significative la probabilité d'échecs d'écriture et de blocage de la lecture pendant les périodes de forte activité sur Solana. Nous pouvons nous attendre à une réduction de la gigue grâce au nouveau planificateur par défaut. Néanmoins, étant donné la nature continue du processus de création de blocs, l'inclusion de blocs continuera de faire preuve de non-déterminisme.

Frais de rédaction de comptes remboursables (PRAW) dans le cadre du programme

Rédigé par Godmode Galactus et Max Schneider, le SIMD-0016 propose des frais d'écriture de compte remboursables par programme (PRAW). Ils donneraient un contrôle important aux développeurs d'applications, car ils pourraient définir les critères de paiement et de réduction de ces frais, leur permettant ainsi d'inciter et de décourager le comportement des utilisateurs comme bon leur semble.

Actuellement, les programmes Solana ne sont pas en mesure de pénaliser les transactions liées à l'acquisition de verrous d'écriture sur leur État. Les frais de la PRAW permettraient aux titulaires de comptes Solana de facturer les transactions échouées qui bloquent leur état. Ces frais seraient transférés sur le compte inscriptible qu'ils bloquent. Cependant, les titulaires de comptes peuvent fixer ces frais de manière à ce qu'ils soient remboursés à l'utilisateur à la fin de la transaction si celle-ci répond aux critères spécifiés.

Cela peut notamment dissuader les utilisateurs de bloquer l'écriture de comptes qu'ils n'utilisent pas réellement pour exécuter la transaction. C'est actuellement possible étant donné que Solana n'a mis en place aucune vérification pour savoir si un compte donné serait utilisé, a priori, par une transaction donnée bloquée. Les PRAW proposent aux programmes un moyen de décourager les transactions qui bloquent l'état du programme dans le but d'identifier une opportunité avec l'intention de revenir en arrière si elle n'est plus valide au moment de son exécution. Ces frais seraient appliqués même en cas d'échec de la transaction lors de son exécution.

À l'inverse, les utilisateurs peuvent spécifier le montant maximum des frais PRAW qu'ils sont prêts à payer lors d'une transaction. Tous les frais spécifiés dans la transaction supérieurs aux frais PRAW actuels pour un compte bloqué seraient remboursés.

Des membres de la communauté Solana ont signalé des problèmes liés à cette proposition : la capacité des différents programmes à fonctionner de manière totalement autonome ne semble pas optimale, et il serait difficile d'estimer les frais avec précision. De plus, il existe des moyens potentiellement plus simples et plus uniformes de résoudre ces problèmes difficiles liés aux comptes bloqués, comme le SIMD-0110.

**Griefing Resistance : un sous-ensemble du DSIC dans lequel les utilisateurs ne sont pas incités à déformer leurs listes d'accès, en indiquant de manière erronée les ressources nécessaires à leur transaction [Gar23].

La proposition de la PRAW pourrait ne pas empêcher le spam car elle repose suffisamment sur les développeurs d'applications : 1) être capables de distinguer le spam du « comportement normal » et 2) choisir volontairement de facturer plus cher pour une externalité négative dont ils sont partiellement responsables lorsqu'il n'est pas dans leur intérêt de le faire, et ils peuvent simplement choisir de ne pas le faire.

En revanche, alors que les membres de la communauté de recherche Solana sont indéniablement divisés quant à l'introduction des frais de base de l'EMA, ils sont généralement d'accord sur l'ajout d'une partie des frais de base qui varie en fonction des UC. Cela peut favoriser une estimation précise des UC et une utilisation efficace des UC par les développeurs.

Réflexions d'adieu

Les objectifs uniques d'ingénierie et de performance de Solana nécessitent des considérations TFM uniques. Le simple transfert du marché des frais existant d'Ethereum vers Solana n'est évidemment pas la solution, mais il y a de précieuses leçons à en tirer. C'est très pertinent pour les mécanismes qui sont à la fois :

1. Protocole intégré : TFM imposé par consensus (par exemple, EIP-1559 et SIMD-0110)
2. Hors protocole : PBS via MEV-Boost, améliorations du planificateur Solana et ventes aux enchères Jito

Pour Solana et Ethereum, les mécanismes intégrés et hors protocole semblent susceptibles de coexister et d'évoluer ensemble à l'avenir. L'équilibre entre les deux est l'une des questions fondamentales lors de la conception de ces systèmes. Le débat autour de la SIMD-0110 est souvent centré sur deux points de vue opposés :

1. Les améliorations apportées au planificateur et au réseau pour réduire la gigue suffiront à résoudre les problèmes décrits ici. Il n'est donc pas nécessaire d'apporter des modifications majeures au TFM intégré au protocole.
2. Bien que des améliorations de la planification hors protocole et du réseau soient nécessaires, elles sont fondamentalement insuffisantes. Une contre-pression économique est requise dans le protocole.

La tarification multidimensionnelle des ressources, sous une forme ou une autre, est clairement intéressante dans les deux cas également. Ethereum commence à rechercher un tel TFM au niveau des ressources de base, l'EIP-4844 séparant les données blob du marché de l'exécution. À l'inverse, Solana propose une tarification multidimensionnelle des ressources au niveau des comptes individuels afin d'être la pionnière des « marchés payants locaux ».

Les recherches menées sur la TFM sont de pointe et les chercheurs trouvent constamment de nouveaux moyens innovants d'améliorer le fonctionnement des frais sur Solana et sur d'autres chaînes. Nous sommes optimistes quant au fait que les propositions discutées ici continueront toutes à rendre Solana encore plus efficace, évolutif, convivial et économiquement durable.

À l'approche du lancement d'Eclipse sur le réseau principal, nous sommes également ravis de vous en dire plus sur la manière dont nous allons appliquer ce travail existant à notre propre TFM, qui continuera certainement d'évoluer dans les années à venir. Nous avons l'intention d'expérimenter et de développer des mécanismes dans ce domaine. L'un des avantages essentiels du paradigme modulaire est qu'il permet de faciliter la pollinisation croisée entre la recherche et l'ingénierie issues de différents écosystèmes. Ce rythme d'expérimentation ne fera que continuer à augmenter, au profit de tous ceux qui construisent ici sur le long terme.

Avertissement：

1. Cet article est repris de [Eclipse], Forward the Original Title« Solana & Ethereum Transaction Fee Mechanisms : Proposals to Improve Solana's TFM ». Tous les droits d'auteur appartiennent à l'auteur original [Eclipse]. En cas d'objection à cette réimpression, contactez l'équipe de Gate Learn, elle s'en occupera rapidement.
2. Avertissement en matière de responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent en aucun cas un conseil d'investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, de distribuer ou de plagier les articles traduits.