Introduction: pourquoi mes transactions ne sont-elles pas incluses?

Une transaction SolanavoyageDe la soumission par l'utilisateur à l'inclusion dans le bloc peut être ardue. Même une fois que la transaction atteint le leader actuel, elle doit rivaliser avec d'autres transactions pour un espace limité dans le bloc. Inclure les transactions de manière purement premier arrivé, premier servi encourage le spam et peut bloquer les transactions de grande valeur des utilisateurs ordinaires. Pour résoudre ce problème, nous avons besoin d'un mécanisme de frais.

Frais prioritaires à la rescousse?​

Les frais de priorité résolvent-ils ce problème, n'est-ce pas? Malheureusement, pas pour la plupart des utilisateurs.

Imaginez ce scénario. Vous voulez aller au cinéma de votre ville qui a 100 places, mais le cinéma a un système de billetterie anormal : ils ne publient pas de prix de billet. Au lieu de cela, vous devez leur dire combien vous êtes prêt à payer. (Disons que c'est 50 $.) Si la demande est forte et que au moins 100 autres personnes ont soumis un prix plus élevé, tant pis. Si la demande est faible, c'est bon pour vous ! Le hic : vous payez 50 $ même si le cinéma est vide. Mais l'expérience de la billetterie ne s'arrête pas là. Ce système a une autre particularité : vous devez dire au cinéma votre volonté de payer avant de quitter votre domicile. De toute évidence, obtenir un billet de cinéma dans ce système est une expérience potentiellement difficile pour la personne moyenne. Les individus riches et sophistiqués, en revanche, peuvent estimer avec précision le prix du billet. Ils peuvent installer des caméras à côté du cinéma pour surveiller le trafic en temps réel. Ils peuvent utiliser ce trafic et les données historiques collectées pour estimer la demande d'un jour donné. Et ils peuvent même acheter un hélicoptère pour se rendre plus rapidement au cinéma après avoir dit au cinéma leur volonté de payer. Bien qu'il soit possible d'utiliser efficacement ce système de billetterie, l'expérience est horrible pour la plupart des gens qui veulent aller au cinéma. Lorsque le cinéma est bondé, beaucoup de ces personnes peuvent ne pas essayer d'y aller du tout.

De même, il est difficile d'estimer le montant de la commission de priorité "vraie" nécessaire pour une transaction Solana.Il fluctue beaucoup. Pendant les périodes de forte congestion, les portefeuilles utilisant des moyennes récentes vont probablement surestimer les frais nécessaires, ce qui amènera les utilisateurs à payer trop cher pour l'inclusion de la transaction. (Et même avec des frais de priorité élevés, une transaction peut encore ne pas être inclusen raison de la nature de la production continue multi-threaded des blocs.) En théorie, les frais de priorité peuvent allouer de manière optimale l'espace des blocs. En pratique, ils échouent totalement. Heureusement, il existe des moyens de résoudre ces problèmes, ce qui se traduit finalement par des transactions moins chères avec une meilleure chance d'inclusion pour la plupart des utilisateurs. Avant d'entrer dans la solution, examinons quelques propriétés de la ressource que nous essayons d'allouer : l'espace des blocs.

Espace de bloc : offre fixe, demande fluctuante de manière imprévisible​

Les transactions sur Solana sont vérifiées et exécutées de manière indépendante par un réseau décentralisé de validateurs. Étant donné que ces validateurs disposent de ressources informatiques limitées, Solana limite les ressources informatiques totales, mesurées en unités de calcul (CUs), qui peuvent être utilisées par bloc. Lorsque la demande d'espace de blocs dépasse l'offre limitée, cette ressource fixe doit être allouée entre les transactions concurrentes.

À certains égards, le marché peut gérer l'allocation de l'espace de blocs par le biais de la tarification ; les transactions offrant une plus grande utilité au soumetteur sont prêtes à payer un prix plus élevé. Cependant, ce mécanisme ne fonctionne pas lorsque les utilisateurs ne connaissent pas le prix de l'espace de blocs ! Comme discuté ci-dessus, des frais de priorité seuls entraînent des prix de transaction difficiles à estimer pour la plupart des utilisateurs et offrent de faibles garanties d'inclusion des transactions. D'autres blockchains ont abordé ce problème en mettant en œuvre un mécanisme de frais de transaction (par exemple, EIP-1559 dans Ethereum, et des frais multidimensionnels dans AvalancheetPénombreCes mécanismes de frais mettent en œuvre un frais de base facile à estimer qui fournit un "frais d'entrée" prévisible pour le réseau ; ce frais de base approxime le vrai prix pour l'inclusion de la transaction.

Critique : Frais Solana aujourd'hui​

Solana met actuellement en œuvre deux mécanismes de frais : un frais de base et un frais de priorité. Nous pouvons considérer le frais de base comme un "frais d'entrée" pour utiliser le réseau et le frais de priorité comme un pourboire supplémentaire pour inciter les validateurs à inclure une transaction plutôt qu'une autre. Le frais de base de Solana est de 5000 lamports fixes par signature (généralement une par transaction). Par conséquent, les utilisateurs soumettant des transferts simples paient le même frais de base que les utilisateurs jouant à des jeux lourds en calcul sur la chaîne et que les chercheurs tentant de capturer des opportunités MEV compliquées. Ainsi, le frais de base actuel facturé ne capture pas de manière précise l'utilisation des ressources d'une transaction (et l'"externalité," pour parler d'économie), ce qui pourrait potentiellementmal utilisé espace de bloc.

Dans notre exemple de théâtre, un frais de base fixe similaire facturerait le même prix à un cinéphile achetant 1 siège et à un achetant tous les 100 sièges.

Pourquoi un mécanisme de frais de base?​

Les frais de base devraient plutôt être une fonction des ressources utilisées. Cette consommation est actuellement mesurée en unités de calcul (UC), mais pourrait également inclure d'autres ressources telles que l'accès au compte. Nous voulons que l'utilisateur ait un coût de participation plus prévisible, donné par des frais de base dynamiques. Il est difficile de fixer correctement ces frais. (Il y a beaucoup de recherche académique, y compris le nôtreCependant, toute personne ayant souffert de transactions échouées en raison de la congestion du réseau sait que les frais sont également importants à régler si nous voulons que le réseau se développe.

En fin de compte, de nombreux utilisateurs qui souhaitent soumettre des transactions ne savent pas combien payer pour les frais de priorité. Surestimer ces frais entraîne un paiement bien trop élevé. Sous-estimer ces frais signifie que la transaction ne sera pas incluse. En revanche, pour les frais de base, les utilisateurs paient exactement le montant des frais publiés actuels. Nous aimerions que les frais de base capturent précisément le coût réel de l'inclusion des transactions. Ici, nous supposons que toutes les transactions parviennent à l'ordonnanceur mais concourent pour un espace de bloc limité, incluant le calcul et l'accès aux comptes. Pendant les périodes de forte demande, toutes les transactions ne peuvent pas être incluses. Dans ce billet, nous décrivons les étapes vers un mécanisme de frais de base dynamique qui peut aider à décongestionner le réseau et à fournir une inclusion de transaction plus prévisible.

En passant : Frais de priorité et MEV​

Les frais de priorité peuvent alternativement être considérés comme des paiements pour des opportunités particulières limitées par autre chose que la consommation de ressources. Par exemple, si deux chercheurs soumettent simultanément des transactions pour liquider un prêt particulier, seule l'une de ces transactions peut être exécutée avec succès ; seule la première transaction dans le bloc liquide avec succès le prêt. Les frais de priorité paient donc souvent pour l'ordonnancement des transactions plutôt que pour leur seule inclusion. Cette utilisation des frais de priorité pour capturer des opportunités de MEV est quelque peu orthogonale à ce post—voirMEV sur Solanapour plus de discussion. Dans ce post, nous nous concentrons sur les frais de base et l'inclusion des transactions.

Bloc optimal

Avant de discuter de la façon de définir les frais de base, nous considérerons un mécanisme fictif d'inclusion des blocs : un concepteur réseau omniscient choisit les transactions pour chaque bloc qui maximisent le bien-être des utilisateurs (l'utilité totale ou le 'bonheur' d'une transaction incluse), moins le coût de consommation des ressources du réseau, sous réserve de contraintes de transaction (par exemple, contraintes de contrat intelligent, limites de calcul, etc.). Bien sûr, le bien-être des utilisateurs est inconnu et non mesurable par le concepteur réseau en pratique, et le concepteur réseau ne construit pas les blocs. Cependant, nous pouvons utiliser ce problème comme une référence mentale pour un bloc 'optimal' construit à partir des transactions qui parviennent au planificateur. Notre objectif est de concevoir un mécanisme de frais qui se rapproche de cette référence.

Bien que ce mécanisme de construction de blocs fictif soit inextricable, il s'avère que nous pouvons mettre en place un mécanisme équivalent qui est réalisable en pratique. Ce mécanisme équivalent vise à trouver les prix des ressources qui minimisent l'écart entre le bien-être du réseau et celui de ses utilisateurs. Le fait de définir correctement les prix des ressources aligne les incitations de sorte que les coûts des ressources pour le réseau soient exactement équilibrés par l'utilité obtenue par les utilisateurs et les validateurs, même si le réseau n'a aucune idée de cette utilité et que les utilisateurs ne la spécifient jamais explicitement. Ces prix conduisent ensuite à des blocs qui sont “optimaux” en moyenne. Ainsi, nous pouvons nous concentrer uniquement sur la définition de ces prix. (Pour plus de détails techniques, consultezce document.)

Vers un mécanisme

Comment alors fixons-nous les prix pour inciter des blocs optimaux, comme discuté ci-dessus? Une première approche pourrait consister à facturer un montant fixe par unité de calcul utilisée par une transaction. Malheureusement, cette approche ne fonctionnera pas. Si la demande est faible, alors ce prix fixe par UC amènera les utilisateurs à ne pas soumettre de transactions, et les blocs peuvent être proches du vide. Si la demande est élevée, alors ce prix fixe peut être trop bas et, par conséquent, ne fera rien pour soulager la congestion du réseau ou approcher le coût réel de l'inclusion des transactions (notre objectif initial!). Ainsi, nous avons besoin d'un moyen d'augmenter et de diminuer les frais de base en fonction de la demande du réseau, ainsi que d'un moyen d'estimer cette demande.

Frais de base dynamiques​

L’étape suivante consiste à ajouter un contrôleur qui ajuste les frais par unité de calcul en fonction de l’utilisation passée. Par exemple, s’il existe un objectif d’utilisation par bloc (c’est-à-dire un objectif d’utilisation idéal « à l’état d’équilibre » pour la chaîne), nous pouvons augmenter ou diminuer les frais de base en fonction de l’utilisation ou de l’écart par rapport à cet objectif. De nombreux mécanismes, y compris ceux tels que EIP-1559, implémentez cette idée. Nous pourrions être tentés de mettre à jour dynamiquement les frais de base au sein d'un seul bloc en utilisant la demande en temps réel, ou d'encourager chaque leader à choisir ses propres règles de mise à jour des frais. Cependant, ces changements réduiraient la prévisibilité des frais de base, contrecarrant l'objectif initial de ce mécanisme de frais. Le choix du mécanisme détermine finalement l'expérience utilisateur.

Heureusement, les temps de bloc rapide de Solana permettent des algorithmes agressifs pour définir le frais de base. Par exemple, nous pouvons rapidement augmenter le prix pendant les périodes de forte demande (par exemple, doubler le prix pour chaque bloc complet), puis baisser plus lentement le prix lorsque la demande diminue. Le prix baissera toujours assez rapidement en raison des courts temps de bloc de Solana. Intuitivement, lorsqu'une ressource spécifique est "maxed out", le réseau facture significativement moins et obtient moins d'informations sur le prix optimal. Des types similaires d'algorithmes sont utilisés en pratique dans Contrôle de congestion TCP, la couche de liaison de données des communications sans fil, et optimisation du marché.

Frais multidimensionnels : marchés locaux des frais​

La discussion précédente a considéré une ressource commune partagée par toutes les transactions : les unités de calcul (globales). Cependant, l'accès à l'état sur Solana a également un impact significatif sur l'utilisation des ressources des transactions. Si de nombreuses transactions accèdent à la même partie de l'état, elles ne peuvent pas être exécutées en parallèle et, par conséquent, réduisent le débit du réseau. Naturellement, nous aimerions que ces transactions paient des frais de base plus élevés, ce qui motive des marchés de frais par compte (locaux). (La question de qui reçoit ces frais dépasse le cadre de cet article ; plus d'informations à ce sujet à l'avenir.)

À titre d'exemple concret, considérons une vente NFT populaire. Sans marchés de frais par compte, cette vente augmenterait considérablement les frais de base pour toutes les autres transactions. Avec des frais par compte, le coût de soumission des transactions pour réclamer un NFT (et accéder à cette partie de l'état) peut augmenter alors que les frais pour les autres transactions (comme le renforcement des garanties sur un prêt) restent largement inchangés. Ce type de conception de marché de frais local par compte est en cours de considération dans un brouillon du document d'amélioration de Solana.

Ces frais multidimensionnels peuvent également expliquer les corrélations entre les contrats. Par exemple, si deux plateformes d’échange de cNFT négocient un grand nombre des mêmes collections, leurs contrats nécessitent l’accès à un grand nombre des mêmes comptes. Si le volume des transactions augmente considérablement pour une collecte particulière sur l’une de ces bourses, les frais de base augmenteront pour cette collecte sur l’autre, car les frais pour le compte sous-jacent ont augmenté pour les deux. De cette façon, les frais « locaux » par compte sont correctement corrélés de manière « globale », et les frais multidimensionnels empêchent de jouer avec le système en libérant plusieurs contrats pour la même application.

D'autre part, si l'état de l'application elle-même est parallélisé, les frais seront plus bas. Cette propriété est souhaitée ; la parallélisation augmente le débit car elle permet à différentes transactions accédant à la même application d'être placées sur différents threads lorsque les comptes sous-jacents ne se chevauchent pas (voir Cycle de vie d'une transaction Solana).

Le contrôleur de prix pour ces marchés locaux de frais par compte peut être différent de celui utilisé pour les unités de calcul. Peut-être que pour les comptes, nous ne facturons aucun frais du tout jusqu'à ce que l'état soit significativement contesté, moment où les frais augmentent rapidement. L'analyse des périodes passées de congestion peut aider à éclairer ces décisions de conception.

Mécanismes alternatifs​

Les options discutées ci-dessus ne sont pas les seules façons de définir les frais. La plupart des mécanismes de frais de base suivent à peu près la même procédure itérative : à chaque bloc...

1. Regardez la consommation de ressources des blocs les plus récents (résultat des transactions incluses);
2. calculer une fonction de cette consommation (par exemple, l'écart par rapport à un objectif);
3. puis mettre à jour les prix des ressources en utilisant la sortie de l'étape 2 et une règle simple.

Dans les exemples discutés ci-dessus, nous avons utilisé des choix différents pour les ressources à l'étape 1 et le mécanisme de mise à jour aux étapes 2 et 3. Une méthode pour transformer les préférences d'utilisation des ressources en une règle de mise à jour des frais concrète est discutée dansce document.

Est-ce que ce truc multidimensionnel fonctionne?

Bien que notre travail académique soit principalement théorique, des exemples simples de jouets montrent que la tarification des ressources, comme les comptes, séparément peut augmenter l'efficacité du réseau et rendre le réseau plus robuste aux attaques par déni de service ou aux changements dans les types de transactions soumises. Dans cette section, nous mettons en lumière la différence entre un mécanisme de frais unidimensionnel et un mécanisme de frais multidimensionnel simple (voir la section 4 denotre papierpour plus de détails).

Comportement à l'état stable​

Nous simulons d'abord le comportement à l'état stable d'un mécanisme de frais multidimensionnel avec des transactions nécessitant approximativement des quantités égales de ressource 1 et de ressource 2. En régime permanent, la tarification uniforme entraîne une plus grande déviation par rapport aux cibles d'utilisation des ressources (gauche). Une utilisation moins efficace entraîne également une capacité de traitement plus faible (droite).

Déplacements de distribution​

Nous testons également le comportement du mécanisme sous un changement de distribution : nous ajoutons 150 transactions dans le bloc 10 qui nécessitent une quantité significative de ressources 2. Ce scénario peut apparaître dans une création d'art NFT, par exemple. La tarification multidimensionnelle conduit à un débit significativement plus élevé lorsque la distribution se déplace (à gauche) en ajustant les prix des ressources en conséquence (à droite).

En examinant l'utilisation individuelle des ressources, nous constatons que la tarification multidimensionnelle (à gauche) facilite la capacité de courte durée, tandis que la tarification uniforme (à droite) ne le fait pas.

Conclusion

Les blockchains disposent de ressources informatiques finies. Lorsque la demande des utilisateurs est élevée, cela nécessite d'allouer ces ressources limitées entre les transactions concurrentes des utilisateurs de manière prévisible. Cette allocation doit être réalisée implicitement via des frais de base de transaction dynamiques.

Nous proposons un mécanisme théoriquement fondé pour définir ce frais, qui non seulement peut augmenter le débit du réseau en période de forte demande, mais aussi améliorer l'expérience utilisateur en dissociant les transactions non liées et en offrant un coût prévisible de l'inclusion de la transaction. Pour plus de détails sur le mécanisme, consultezDiscours de Tarun à Breakpointetnotre papier!

Avis de non-responsabilité：

1. Cet article est repris de [umbraresearch] Forward the Original Title'Toward Multidimensional Solana Fees', All copyrights belong to the original author [@theo_diamandis、@tarunchitra、@0xShitTrader]. Si des objections sont soulevées concernant cette réimpression, veuillez contacter le Porte Apprendrel'équipe s'en chargera rapidement.

2. Clause de non-responsabilité: Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.

3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.