Les mécanismes de frais de transaction sont devenus les modèles de travail pour comprendre l'intermédiation des producteurs de blocs entre les utilisateurs souhaitant effectuer des transactions et « la chaîne » (ou « le protocole ») sur lesquels les utilisateurs effectuent des transactions. Étant donné la possibilité d'utiliser une partie de l'offre fournie par la chaîne, les producteurs de blocs doivent arbitrer quelles utilisateurs auront la capacité d'utiliser la ressource rare de l'exécution on-chain, et à quel coût. Sur Ethereum, pour la question du coût, les producteurs de blocs sont contraints par le mécanisme de frais EIP-1559, qui définit dynamiquement un prix de réserve bloc par bloc, appelé « frais de base ». Les frais de base sont un prix, exprimé en unités de gaz, que les utilisateurs doivent payer pour que leur transaction soit incluse et exécutée. L'utilisateur peut fournir des « frais prioritaires » au-delà des frais de base, pour inciter davantage les producteurs de blocs en cas de congestion.

Dans cette note, nous investiGate la question des marchés aux frais intégrés, c'est-à-dire des marchés aux frais qui "vivent" au sein d'autres marchés aux frais. Cette question a été discutée dans un contexte différent dans un article récent de Maryam Bahrani, Pranav Garimidi et Tim Roughgarden,Conception du mécanisme de frais de transaction dans un monde post-MEV 9Dans cet article, les auteurs modélisent l'utilisation des chercheurs, qui intermédient encore plus l'accès à la chaîne entre les utilisateurs et les producteurs de blocs. Les producteurs de blocs reçoivent des "indices" des chercheurs, représentés par des faisceaux atomiques de transactions à inclure dans la chaîne. Le marché des frais des chercheurs est stimulé par l'objectif de maximisation d'une quantité appelée MEV, ou valeur maximale extractible.

Dans notre configuration, les utilisateurs souhaitent accéder à la chaîne mais n'expriment pas leur demande en utilisant des transactions lisibles par le protocole. Au lieu de cela, les utilisateurs produisent des «opérations», qui doivent être regroupées par des entités connues sous le nom de «bundler», qui initient ensuite une transaction lisible par le protocole regroupant les opérations ensemble en vue de l'exécution. Ainsi, pour le mécanisme de frais EIP-1559, les bundlers sont les utilisateurs de la chaîne, mais les utilisateurs réels doivent d'abord obtenir l'inclusion dans le bundle d'un bundler avant de pouvoir être inclus dans la chaîne. En d'autres termes, nous pouvons voir cette configuration comme faisant partie de la question plus large de...co-création de blocs, qui apparaît avec (partiellement) les constructeurs/chercheurs ainsi que les listes d'inclusion.

Notre espoir est que ces dynamiques soient aussi transparentes que possible, de sorte qu'il n'y ait ni plus de surcharge cognitive ni d'opportunités pour l'utilisateur d'être exploités de manière indue par le bundler, par rapport à une utilisation directe de la chaîne. Nous espérons même obtenir de meilleurs résultats, des cas où les utilisateurs bénéficient effectivement de l'intermédiation du bundler, lorsque les coûts amortis permettent aux utilisateurs de profiter d'un plus grand bien-être.

Pour investiguer la distinction entre les marchés de frais directs et leurs mécanismes intégrés (sub-), nous devons préciser les contraintes économiques auxquelles un regroupeur se conforme. Dans la section suivante, nous proposons un modèle simple de la fonction de coût du regroupeur, motivé par la pratique, en particulier les regroupeurs participant au protocole ERC-4337, que nous récapitulons brièvement.

Modèle

Regroupement dans ERC-4337

Un utilisateur souhaitant effectuer une activité sur la chaîne via des bundlers émet une opération utilisateur (UserOp, ou opération). Ce UserOp est émis à partir du portefeuille de l’utilisateur, par exemple, après avoir interagi avec une DApp. Une fois que l’opération utilisateur est diffusée, un bundler recevant l’opération peut décider de l’inclure dans un bundle. Un bundle est une méta-transaction de type « compte détenu par un tiers » (EOA), qui écrit les données des UserOps inclus dans son champ bundle.calldata. Le bundler émet le bundle en vue de son inclusion dans un bloc par un producteur de blocs (nous discuterons de la relation entre le bundler et le producteur de blocs dans une prochaine note).

Une fois que le bundle est inclus dans le bloc et que le bloc parvient à la chaîne, le bundle est exécuté avec les autres transactions dans le bloc. Essentiellement, les étapes d'exécution du bundle sont les suivantes :

• Pré-vérification : La transaction EOA d'un assembleur consommera 21 000 gaz, et l'appel au contrat EntryPoint configurera des variables clés pour suivre l'exécution des opérations dans la boucle d'opération.
• Boucle d'opération 3: Pour chaque opération incluse dans le pack, les deux étapes suivantes ont lieu:
  • Étape de vérification : Les UserOps effectuent des opérations contenant une étape de vérification, qui est encodée dans un « portefeuille de contrats intelligents » déployé initialement par l’utilisateur (lors d’un UserOp initial). L’étape de vérification peut simplement vérifier une signature, ou effectuer des opérations plus complexes pour « accorder » le droit à l’UserOp de procéder à son exécution. L’étape de vérification est mesurée par op.verificationGasLimit.
  • Étape d’exécution : au cœur de l’opération UserOp, l’étape d’exécution effectue l’opération décrite dans op.callData. Cette étape est également mesurée, à l’aide de op.callGasLimit.

Comme le précise la décomposition précédente, l'étape de pré-vérification est exécutée une fois, offrant la possibilité d'amortir les coûts de pré-vérification pour tous les utilisateurs inclus. Lorsque le bundle est exécuté, tous les coûts (par exemple, block.basefee + frais de priorité payés par le regroupeur au producteur de bloc les incluant) sont facturés au regroupeur, qui doit s'assurer que les opérations des utilisateurs la compensent suffisamment pour les coûts engagés. Nous précisons ces affirmations dans la section suivante.

Modèle de marché des frais pour les lots

Nous nous efforçons de rester cohérents avec les modèles classiques des marchés des frais. Un utilisateur t qui souhaite émettre une opération a une certaine valeur vt pour l'exécution de l'opération. Nous supposons que toutes les opérations ont la même taille S (c'est-à-dire le même gaz utilisé pour les étapes de vérification et d'exécution), et nous exprimons donc toutes les quantités en prix par unité de gaz.

Les utilisateurs expriment leur souhait d'être inclus en émettant une offre bt avec leur opération. Pour l'instant, nous n'assumons pas de grammaire spécifique pour que l'utilisateur exprime son offre d'inclusion, par exemple, la capacité d'exprimer des frais maximaux et des frais prioritaires avec leur opération, comme ils le feraient avec EIP-1559. Les opérations des utilisateurs sont collectées dans un mempool M, représentant le statut en attente de ces opérations jusqu'à leur inclusion.

Le marché des frais EIP-1559 expose un prix de réserve r connu sous le nom de "frais de base", que les assembleurs doivent supporter lorsque leur ensemble est exécuté. Si l'ensemble contient n opérations, l'assembleur doit alors dépenser au moins n × S × r. De plus, étant donné que l'ensemble consomme du "gaz de pré-vérification", disons, une certaine quantité F, l'assembleur paiera également F × r

. Les opérations incluses dans le bundle sont données par l'ensemble B.

Fonctions de coût du regroupement

Nous examinons maintenant les coûts encourus par les bundlers pour l'inclusion de leurs bundles dans le bloc.

Fonction de coût on-chain : Un regroupeur émettant le regroupement B lorsque le frais de base est r dépense un coût :

Le problème du regroupeur reflète le problème du producteur de blocs exprimé dans[Roughgarden 2021] 3. Là, le producteur de blocs devait assurer la fourniture d'une certaine valeur μ qui la compensait pour le coût d'inclusion d'une transaction supplémentaire dans leur bloc (par exemple, μ peut compenser la charge supplémentaire du bloc, qui retarde sa propagation et augmente ainsi le risque de réorganisation). Le marché des frais au niveau du bloc doit alors garantir que le producteur de blocs est au moins compensé pour le coût total n × S × μ, si le producteur de blocs inclut n transactions dans leur bloc. Le marché des frais au niveau du bundle nécessitera de compenser au moins le bundleur pour les coûts exogènes.

Con-chain(B,r) qu'ils supportent du marché des frais plus élevés dans lequel ils sont intégrés.

L’ERC-4337 offre la possibilité d’amortir les coûts au-delà du partage des coûts de gaz avant vérification. Si toutes les opérations utilisent le même schéma de signature pour leur étape de vérification, les signatures de ces opérations peuvent être agrégé 2par le bundler, de sorte que au lieu de vérifier n signatures sur chaîne, une seule signature peut être vérifiée. Dans ce cas, la fonction de coût du bundler devra prendre en compte les coûts hors chaîne que le bundler supporte lors de l'agrégation. Dans ce qui suit, nous supposons que de tels coûts sont linéaires par rapport au nombre d'opérations, une hypothèse similaire à [Wang et al., 2024] 2, à un coût marginal ω.

Nous tenons également compte de la réduction de la consommation de gaz de chaque opération, en raison des économies réalisées grâce à l’agrégation. Lorsqu’elles sont aggreGated, les opérations ne sont pas tenues de publier leur signature, mais elles nécessitent une opération d’appariement supplémentaire. Sur les chaînes où le coût des données d’appel est élevé, mais où les opérations d’appariement et de calcul sont bon marché, l’agrégation permet donc de réaliser des économies par opération. Dans ce cas, nous désignons par S′ < S la taille réduite d’une transaction. Nous devons également tenir compte de l’augmentation de l’utilisation de gaz de pré-vérification F′ > F, qui contient désormais la publication et la vérification de la signature agrégée unique on-chain.

Fonction de coût agrégé : un groupeur qui émet un bundle B avec des signatures agrégées lorsque les frais de base sont r dépense un coût :

Dans cette note, nous n'irons pas plus loin, mais on peut également considérer les coûts de publication de données que un rassembleur peut devoir dépenser lorsque son bundle se règle sur un rollup. Nous suggérons deux façons de modéliser cela et laissons cette question pour un travail futur :

• Soit la plateforme elle-même est responsable de la publication des données (par exemple, en tant que séquenceur), et doit donc obtenir des utilisateurs le montant nécessaire de fonds pour couvrir les éventuels coûts de publication des données.
• Ou le marché des frais au niveau du bundle est intégré dans un marché des frais au niveau du lot plus important, par le biais duquel le rollup expose aux utilisateurs de rollup (y compris le bundler) le montant qu'ils doivent payer en raison de la congestion (par exemple, des frais de base) et des coûts ultérieurs de publication des données. Dans ce cas, le rollup est responsable d'équilibrer ses propres coûts futurs avec ses revenus actuels.

Réexamen des quantités du marché des frais

Nous pouvons maintenant exprimer formellement les concepts pertinents pour le marché des frais au niveau du bundle, en les dérivant simplement de la littérature précédente, tout en tenant compte de l'intégration.

Règle d'allocation au niveau du bundle: Une allocation x (au niveau du bundle) décide de l'ensemble des opérations utilisateur que le rassembleur inclut dans son bundle, compte tenu du mempool M actuel et du frais de base r.

Règle de paiement au niveau du bundle: Étant donné l'ensemble des opérations sélectionnées B, une règle de paiement attribue à chaque utilisateur inclus des frais:

Fonction d'utilité de l'utilisateur:

En principe, nous pourrions permettre l'existence d'une règle de combustion qt(B) exprimant le fait que le collecteur ne peut pas recevoir la totalité de tous les paiements des utilisateurs inclus. Cependant, nous ne le considérons pas dans cette note.

(Myope) fonction utilitaire du regroupeur :

Un TFM (x,p) au niveau du bundle est incitatif pour les assembleurs myopes (MBIC) si, pour chaque mempool M et frais de base r, un assembleur myope maximise son utilité en suivant la suggestion de la règle d'allocation x (c'est-à-dire en définissant B = x(M,r)).

Formation de plusieurs faisceaux

Dans la section précédente, nous n'avons considéré que la possibilité pour le bundleur de publier un seul bundle. Cependant, nous pourrions être intéressés par la possibilité pour le bundleur de créer plus d'un bundle à partir des opérations disponibles dans le mempool. Étant donné le mempool M, soit P(M) représente l'ensemble des partitions du mempool, attribuant chaque opération à un seul bundle (nous pouvons supposer que pour chaque partition, il existe un ensemble indexé 0 qui contient toutes les opérations non attribuées à un bundle pour inclusion). La règle d'allocation renvoie ensuite l'indice de l'ensemble dans la partition auquel l'opération est attribuée.

Nous pouvons écrire l'ensemble des paquets produits par la partition x(M,β) comme B(x(M,r)). Intuitivement, ces paquets sont composés des opérations qui n'appartiennent pas à l'ensemble indexé 0. Étant donné un ensemble de paquets B, la règle de paiement est alors :

La fonction d'utilité de l'utilisateur devient:

et la fonction utilitaire Bundler devient :

Le jeu de regroupement

L'inclusion des transactions dans les blocs doit rémunérer une certaine quantité μ aux producteurs de blocs, qui est supposée être linéaire par rapport à la taille de la transaction, par exemple,[Roughgarden, 2021] 3. Cette quantité indique le coût d’opportunité pour le producteur de blocs d’ajouter une transaction supplémentaire à son bloc, par exemple, en augmentant son délai de commérages et en augmentant ainsi ses chances que le bloc soit réorganisé. En Proof-of-Stake, même si le calendrier du protocole laisse suffisamment de temps pour propager un bloc complet, jeux de timingont induit des dynamiques de propagation «dernière seconde» qui rendent une fois de plus ce paramètre μ pertinent.

En tout état de cause, nous pouvons observer que le problème de partage des coûts au niveau du bloc et au niveau du paquet sont très différents. Au niveau du bloc, une transaction n'a pas besoin de savoir ce qui se passe d'autre à l'intérieur du bloc pour concevoir son offre d'inclusion selon l'EIP-1559 (elle peut vouloir savoir ce qui se passe en ce qui concerne le MEV [Bahrani et al., 2024] 9, mais nous considérerons cela comme une question distincte pour l’instant). Au niveau du forfait, les frais généraux du forfait ne sont plus linéaires en ce qui concerne le nombre de transactions, mais des frais généraux fixes peuvent être amortis par de nombreuses transactions. De plus, le coût d’agrégation des opérations de l’utilisateur devrait-il être non linéaire dans le nombre de transactions (par exemple, certaines preuves sont effectivement sous-linéaires dans la taille à prouver), offrant la possibilité d’amortir le coût total sur de nombreux utilisateurs.

Cela conduit au jeu suivant : le bundler souhaite que les utilisateurs placent leurs offres comme s'ils faisaient une offre pour le pire des cas, où l'utilisateur est seul dans le bundle et doit compenser par lui-même le plein frais de gaz F. En pratique, l'utilisateur serait confronté au problème de définir trois paramètres pertinents sur leur opération :

• op.maxPriorityFeePerGas et op.maxFeePerGas peuvent être définis en fonction de l’heuristique qu’un utilisateur utiliserait sous EIP-1559, c’est-à-dire qu’étant donné une certaine quantité estimée de gaz que son exploitation prévoit de consommer, l’utilisateur définirait ces attributs pour calibrer le montant qu’il est prêt à payer dans le pire des cas (maxFee) et le montant qu’il est prêt à recharger afin de payer le producteur de bloc éventuel (maxPriority). Mais comment l’utilisateur doit-il estimer le gaz ?
• op.preVerificationGas est un attribut de UserOperation qui doit être défini pour indiquer la quantité de « gaz supplémentaire » que l'opération de l'utilisateur prévoit de consommer. Dans notre modèle, nous laissons
• F désigne ce “surplomb de gaz fixe”. Si n utilisateurs étaient inclus dans le bundle, chaque utilisateur devrait définir preVerificationGas = F / n. Cependant, si l'utilisateur prépare son opération en gardant à l'esprit un scénario de pire des cas, il définirait preVerificationGas = F.

preVerificationGas est alors le principal vecteur par lequel les utilisateurs médiatisent leur offre et tentent de prendre en compte l'amortissement des coûts par le bundler. Supposons que n utilisateurs viennent sur le marché avec leurs opérations, et que tous soient convaincus par le bundler de faire une offre dans le pire des cas d'être seuls dans le bundle. Nous supposerons également que les utilisateurs fixent leur maxPriorityFeePerGas à zéro pour l'exemple. Alors ces n utilisateurs fixent tous preVerificationGas = F, et le bundler est capable de générer un bundle les rémunérant avec:

alors qu'ils doivent supporter un coût:

une fois qu'ils publient le paquet regroupant toutes les n opérations ensemble dans un bloc. Cela permet au regroupeur d'obtenir un profit π = (n−1)×F×r.

Cette situation peut être représentée par un jeu en deux étapes, où les utilisateurs produisent d’abord leurs opérations utilisateur, et le bundler décide ensuite de les regrouper. Nous partons du principe que les utilisateurs ne disposent pas d’informations sur le nombre actuel d’utilisateurs en attente et qu’ils ne sont donc pas en mesure d’estimer la capacité réelle du groupeur à amortir ses coûts fixes.

Dans la première étape, les utilisateurs envoient leurs opérations, qui s'engagent à leurs attributs tels que preVerificationGas. Dans la deuxième étape, le regroupeur, ayant reçu toutes les transactions des utilisateurs, décide de produire un ensemble de bundles. Fait intéressant, même si les utilisateurs savent combien d'autres utilisateurs joueront dans la première étape, c'est-à-dire même si n est une connaissance commune à tous les utilisateurs, le regroupeur peut contraindre les utilisateurs à définir preVerificationGas = F dans le pire des cas en menaçant de jouer.

, c'est-à-dire menaçant de garder chaque utilisateur dans son propre paquet séparé et de leur facturer le montant maximal de gaz F.

Notez que cette menace n’est peut-être pas crédible, car les utilisateurs s’attendraient à ce que le bundler préfère jouer

, c'est-à-dire, produire un seul bundle avec toutes les opérations incluses, réalisant π. Cependant, les utilisateurs peuvent ne pas avoir accès à la vraie valeur de n, et donc ils ne sont pas en mesure de définir leur preVerificationGas de manière à forcer le bundler à idéalement regrouper tous les opérations.

Cas idéal : les coûts sont répartis entre les utilisateurs du bundle. Cas pessimiste : les utilisateurs paient trop cher et les coûts ne sont pas répartis.731×755 77.6 KB

Une extension de ce modèle peut prendre en compte le cas bayésien, où les utilisateurs ont accès à une distribution sur n, c'est-à-dire qu'ils peuvent anticiper l'apparition de n utilisateurs à n'importe quel pas de temps, selon une certaine distribution (par exemple, des arrivées de Poisson), même s'ils ne connaissent pas à l'avance le résultat de la variable aléatoire. Cela peut conduire à des résultats inefficaces, comme le montre l'exemple suivant :

Alice s'attend à ce que 9 autres utilisateurs se présentent en plus d'elle-même, et elle fixe donc son preVerificationGas à 1 car elle sait que F = 10. La valeur d'Alice et la valeur de tous les autres utilisateurs sont compatibles avec le fait qu'ils fixent preVerificationGas = 3, mais elle tente de payer le moins possible pour être incluse. Il s'avère finalement que seuls 5 utilisateurs apparaissent sur le marché, ayant tous fixé leur preVerificationGas à 1 également. Le regroupeur ne sera pas compensé pour F = 10 unités de gaz, donc le regroupeur ne produit pas de bundle et les utilisateurs ne reçoivent aucune utilité. Cela est évidemment suboptimal, car les utilisateurs auraient pu tous fixer preVerificationGas = 2 par exemple et recevoir 1 utilité (le preVerificationGas maximum qu'ils étaient prêts à fixer moins le preVerificationGas réel qu'ils ont payé pour être inclus).

Travail futur

Comme le montre le jeu de regroupement, un problème d'allocation se pose pour l'utilisateur souhaitant être inclus par le regroupeur. Dans la prochaine note, nous aborderons différentes approches pour rétablir une « bonne expérience utilisateur » afin d'empêcher les utilisateurs de payer trop cher un regroupeur mieux informé de la demande de sa capacité de regroupement. La prochaine exploration nécessitera une compréhension de la structure du marché reliant les utilisateurs, les regroupeurs et les constructeurs/producteurs de blocs.

Démenti:

1. Cet article est repris de [Gateethresear], Tous les droits d'auteur appartiennent à l'auteur original [DavideRezzoli]. S'il y a des objections à cette réimpression, veuillez contacter le Porte Apprendreéquipe, et ils s'en occuperont 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, la copie, la distribution ou le plagiat des articles traduits est interdit.