Frais de Solana, partie 1

Introduction

Les mécanismes de frais sont une caractéristique importante des blockchains. Les responsables de la maintenance du réseau, comme les validateurs, disposent de ressources limitées. Il est donc important de facturer ces ressources rares d'une manière qui reflète le coût pour le réseau. Les redevances créent également des incitations pour les participants au réseau, tels que les utilisateurs, les développeurs d'applications et les validateurs.

Dans cette série, nous explorerons le mécanisme de redevance actuel de Solana, nous formaliserons l'espace de conception d'un mécanisme de redevance et nous analyserons certaines propositions de modification du mécanisme de redevance de Solana.

Cette pièce est la première de la série. Nous vous expliquons ici comment les frais de Solana fonctionnent aujourd'hui, en nous concentrant sur les frais basés sur les transactions.

Définitions

Il s'agit de définitions spécifiques à Solana, nécessaires pour comprendre le mécanisme de la redevance.

Signature : au moins une, et généralement exactement une, incluse par transaction.

Lamport : la plus petite unité atomique de SOL. 1 SOL est égal à un milliard (10^9) de lamports.

Unité de calcul (UC) : une unité de calcul, par instruction Solana-BPF, destinée à approximer le coût d'exécution de l'instruction. Similaire aux unités de gaz sur Ethereum.

CU used : le nombre d'unités de calcul utilisées pour exécuter une transaction. Connu seulement après l'exécution.

CU demandé : spécifié par la transaction ; si la transaction dépasse ce budget de calcul pendant l'exécution, l'exécution s'arrête et la transaction échoue. Le nombre maximum d'unités de compte demandées (et utilisées) par transaction est de 1 400 000 unités de compte.

Compte : un seul élément d'état sur la blockchain Solana.

Scheduler : le mécanisme de construction de blocs en continu, inclus par défaut dans le client Solana construit par Solana Labs.

Honoraires de Solana

Frais de transaction

Aujourd'hui, une transaction Solana comprend deux frais : un frais de base et un frais de priorité.

La redevance de base est fixée à 5000 lamports (0,000005 SOL, 0,0003 $ à 60 $/SOL) par signature ; la grande majorité des transactions de Solana ne comportent qu'une seule signature.

La commission de priorité optionnelle est spécifiée dans la transaction et est libellée en microlamports par UC demandée. Notez qu'il ne s'agit pas d'une unité de compte utilisée, car les unités de compte utilisées ne sont pas connues tant qu'une transaction n'a pas été exécutée. Les transactions ayant une priorité plus élevée sont hiérarchisées de manière non déterministe par l'ordonnanceur. Le mécanisme spécifique est décrit dans Lifecycle of a Solana Transaction (cycle de vie d'une transaction Solana).

Les redevances sont débitées au payeur au début de l'exécution de la transaction. Si le payeur ne peut pas payer la redevance requise, l'exécution est sautée, l'opération est considérée comme non valide et n'est pas incluse.

Pour la taxe de base et la taxe de priorité, 50 % sont conservés par le chef de file pour l'inciter à inclure des transactions dans les blocs, et 50 % sont brûlés.

Dans cet exemple, la transaction demande 600 000 unités de calcul et fixe un droit de priorité de 2 500 microlamports par unité de calcul demandée. Comme la transaction ne comporte qu'une seule signature, la taxe totale pour la transaction est de 5000 lamports + 600 000 UC demandées * 2500 microlamports / UC demandées = 6500 lamports, soit 0,0000065 SOL.

Redevances d'État

Solana facture en outre une redevance pour la création d'un nouvel état appelé exemption de loyer (terme hérité du passé). Le coût actuel de l'exemption de loyer est de 6,96 SOL par MB. Lorsqu'un nouveau compte est créé, la redevance est affectée au compte ; lorsque le compte est supprimé, la redevance d'exemption de loyer peut être recouvrée.

Commentaire

Incitations à l'efficacité

Comme la redevance de base n'est pas sensible aux unités de calcul utilisées ou demandées, elle n'incite pas à optimiser l'utilisation des ordinateurs, ni à demander des unités de calcul proches du nombre d'unités réellement utilisées. Dans la pratique, de nombreuses transactions sur Solana demandent beaucoup plus d'UC qu'elles n'en utilisent. Cela crée des inefficacités dans le planificateur.

Dans l'exemple ci-dessus, la transaction demande 600 000 UC mais en utilise moins de 250 000.

Bien que la redevance de priorité comporte une incitation à réduire le nombre d'UC demandées et donc d'UC utilisées, cette incitation est faible la plupart du temps et n'intervient qu'en période de congestion. Une modification simple consisterait à étendre la redevance de base pour exiger également une redevance par UC demandée. Cela inciterait les développeurs et les expéditeurs de transactions à réduire leur utilisation de l'informatique et à ne demander que les ressources nécessaires.

Compatibilité des incitations

Un mécanisme est compatible avec les incitations si tous les participants au mécanisme obtiennent le meilleur résultat possible en agissant selon leurs véritables préférences. Dans le contexte d'un mécanisme de redevance, cela signifie en gros que le validateur maximise les redevances en exécutant l'algorithme de construction de blocs par défaut, et que les émetteurs de transactions maximisent le bien-être en soumettant des transactions avec des redevances prioritaires en fonction de leur véritable volonté de payer.

Le mécanisme de redevance de Solana n'est pas incitatif pour les validateurs et les émetteurs de transactions actuels. Comme indiqué ci-dessus, 50 % des frais de transaction sont conservés par le chef de file et 50 % sont brûlés. Comme la totalité de la redevance n'est pas versée au chef de file, l'expéditeur d'une transaction est incité à s'entendre avec le chef de file : au lieu de spécifier une redevance de priorité pour obtenir l'inclusion prioritaire, l'expéditeur peut conclure un accord parallèle avec le chef de file pour payer la redevance de priorité en dehors du réseau, ce qui lui permet de ne pas avoir à payer la redevance tout en continuant à bénéficier de la priorité.

Les validateurs qui gèrent un tel mécanisme reçoivent en théorie plus de frais et peuvent donc offrir des récompenses plus élevées à leurs délégués, créant ainsi une force de centralisation.

Outre l'intégration verticale directe, la principale façon de voir ce marché parallèle sur le marché aujourd'hui est la vente aux enchères de Jito. Les validateurs utilisant Jito-Solana (une modification du client de Solana Labs) enfreignent le mécanisme de construction continue de blocs, en organisant une vente aux enchères d'espaces de blocs dans la première moitié de leurs créneaux.

Nous n'avons pas observé d'autres accords parallèles de ce type sur le marché aujourd'hui. En effet :

• Le client validateur et son planificateur sont difficiles à modifier, de sorte que le coût de la création d'un tel arrangement nécessite un coût fixe élevé. Les logiciels hors protocole comme Jito-Solana et les dispositifs de construction de blocs délégués comme PBS sur Ethereum amortissent le coût fixe sur l'ensemble des validateurs participants.
• La grande majorité des revenus des validateurs provient des récompenses inflationnistes, et non des frais de transaction, de sorte que l'avantage est relativement faible.

Marchés locaux de redevances

Contrairement à la plupart des autres blockchains, Solana demande aux expéditeurs de transactions de spécifier les éléments d'état nécessaires à l'exécution de la transaction. Cela permet d'exécuter des transactions en parallèle et de créer des marchés de redevances localisés, où les redevances varient en fonction du degré de litige entre les différentes parties de l'État. Un hotspot d'État localisé n'a pas besoin d'augmenter la contention ou les frais sur l'ensemble de la blockchain.

L'une des idées fausses les plus répandues à propos de Solana est qu'il s'agit aujourd'hui d'un marché de droits locaux. S'il est vrai qu'une transaction qui paie des frais de priorité plus élevés a plus de chances d'être incluse plus haut dans le bloc, et qu'un état contesté est susceptible de nécessiter une priorité plus élevée, ce comportement n'est pas déterministe et résulte de la mise en œuvre de l'algorithme d'ordonnancement par défaut de Solana. Nous approfondissons cette question dans le chapitre Cycle de vie d'une transaction Solana.

En particulier, ce comportement n'est pas appliqué par consensus, et l'ordre déterministe des droits de priorité n'est pas garanti, que ce soit par consensus ou par l'implémentation de l'ordonnanceur. La construction et la propagation continues des blocs de Solana empêchent l'établissement d'un ordre déterministe, à moins que des changements importants (par ex. l'ordre déterministe et l'exécution asynchrone) sont mis en œuvre.

Une redevance de base prévisible et imposée par consensus pour l'accès à l'État, basée sur la contestation historique, pourrait améliorer l'efficacité et l'expérience utilisateur pour l'accès à un État très contesté. Cela augmenterait le coût du spam, tout en incitant les expéditeurs de transactions à verrouiller la quantité minimale d'état dont ils ont réellement besoin. Elle ne s'attaquerait pas à la cause première du spam, qui provient de la construction continue de blocs (la latence est donc importante) et de la gigue. Nous étudierons cette conception plus loin dans cette série.

Externalités

Étant donné que les transactions sont principalement ordonnées en fonction de la date à laquelle elles atteignent le leader (ordonnanceur), et que cet ordre est soumis à la fois à la gigue du réseau et à la gigue due à la mise en œuvre de l'ordonnanceur parallélisé, il y a une incitation à spammer les transactions lorsque l'expéditeur souhaite qu'une transaction soit incluse le plus rapidement possible. Ces transactions entraînent une externalité négative sur le réseau sous la forme de spams qui atterrissent sur la chaîne (en janvier 2023, 58 % des calculs de Solana sur la chaîne sont utilisés pour des transactions de retour) et de spams qui atteignent le leader.

De Jito Labs

Conclusion

Dans cet article, nous avons décrit le fonctionnement actuel du mécanisme de redevance de Solana et ses implications pour le réseau. Nous avons fait allusion à certaines propriétés qu'un mécanisme de redevance idéal devrait satisfaire, telles que des indications précises au planificateur (CU demandé), la compatibilité des incitations et de véritables marchés de redevance localisés. Dans la prochaine partie, nous définirons un formalisme pour les objectifs que le mécanisme de redevance devrait optimiser. Cela permettra d'analyser le mécanisme de redevance actuel, ainsi que les modifications proposées, avec plus de rigueur que ce qui a été exprimé ici.

Clause de non-responsabilité：

1. Cet article est repris de[Umbra Research]. Tous les droits d'auteur appartiennent à l'auteur original[@0xShitTrader]. Si vous avez des objections à cette réimpression, veuillez contacter l'équipe de Gate Learn, qui s'en chargera rapidement.
2. Clause de non-responsabilité : Les points de vue et les opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas un conseil en 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, distribuer ou plagier les articles traduits.