Introduction

Dans ce post, nous introduisons les taxes MEV, un mécanisme que les applications arbitraires peuvent utiliser pour capturer leur propre MEV.

Ce mécanisme pourrait être utilisé aujourd'hui sur les L2 OP Stack comme OP Mainnet, Base et Blast, car les proposants de blocs sur ces chaînes suivent un ensemble de règles que nous appelons l'ordre de priorité compétitive.

Pour mettre en œuvre une taxe MEV sur l'une de ces chaînes, un contrat intelligent facture des frais qui sont une fonction des frais de priorité de la transaction. Nous montrons que si une application facture aux chercheurs une taxe MEV de (disons) 99 $ pour chaque 1 $ de frais de priorité, elle peut capturer 99% du MEV compétitif pour cette transaction.

Les taxes MEV sont une technique simple qui ouvre un vaste espace de conception. Vous pouvez les considérer comme permettant à n'importe quelle application sur la chaîne d'exécuter sa propre vente aux enchères MEV personnalisée, sans avoir besoin de son propre infrastructure hors chaîne, simplement en se connectant à une seule vente aux enchères partagée gérée par le proposant de bloc.

Nous montrons comment les taxes MEV pourraient être utilisées pour résoudre trois problèmes majeurs dans la recherche sur les MEV :

• Les routeurs d'échange décentralisés (DEX) qui optimisent le prix reçu par le swapper
• Les créateurs de marché automatisés (AMMs) qui minimisent la perte par rapport au rééquilibrage (LVR) subie par les fournisseurs de liquidité
• Portefeuilles permettant à leurs utilisateurs de capturer tout MEV de "backrunning" créé par leurs transactions

Mais il y a un hic. Les taxes sur la valeur extractible de la base (MEV) ne fonctionnent que si les proposants de bloc respectent strictement les règles de l'ordonnancement de priorité concurrentielle, qui consistent à trier les transactions par frais de priorité sans censure, sans regarder en cachette ni retarder aucune. Si les proposants de bloc s'écartent de ces règles, ils peuvent échapper aux taxes sur la MEV pour capturer la valeur pour eux-mêmes. Aujourd'hui, par conséquent, les taxes sur la MEV dépendent de la confiance accordée aux séquenceurs L2, et ne fonctionneraient probablement pas du tout sur Ethereum L1, où la construction de bloc est dominée par un...enchère de constructeur compétitifqui maximise les revenus pour le proposant.

Cependant, la puissance et la flexibilité des taxes MEV suggèrent que l'ordonnancement par priorité pourrait être le bon choix pour les plateformes qui peuvent le fournir aujourd'hui. Et la simplicité relative de l'ordonnancement par priorité concurrentiel suggère qu'il pourrait y avoir un moyen viable de l'appliquer de manière décentralisée, sans avoir à faire confiance à un séquenceur unique. Nous espérons que ce message incitera à travailler davantage sur ce problème.

Commande de priorité

Lorsqu'une personne envoie une transaction sur un Ethereum L1 ou L2, elle spécifie des frais de priorité qu'elle paie au proposant de blocs.1Vous pouvez imaginer que cela est spécifié comme priorityFeePerGas, un chiffre qui est multiplié par le gaz utilisé dans la transaction pour obtenir builderPriorityFee—le paiement total en ETH.2

Il n'y a pas de règle dans le protocole Ethereum selon laquelle les transactions dans un bloc doivent être ordonnées de manière cupide par prioritéFeePerGas décroissante. Cependant, c'est une façon populaire de construire des blocs - par exemple, c'est l'algorithme par défaut utilisé par les séquenceurs de Pile OPchaînes, ainsi que geth et reth. Non seulement l'ordre de priorité permet aux transactants d'exprimer efficacement l'urgence de leurs transactions, mais il canalise également naturellement certains types de MEV vers le proposant de bloc.

Cela se produit parce que l'ordonnancement par priorité transforme la concurrence pour le MEV en une vente aux enchères de gaz prioritaire. Lorsqu'il y a une opportunité de tirer un profit de l'interaction avec la chaîne, par exemple en arbitrant une AMM contre une bourse centralisée, les chercheurs se disputent pour revendiquer cette opportunité en premier. Si la chaîne utilise un ordre de priorité pour déterminer l'inclusion et l'ordre des transactions, les chercheurs se disputent en fixant des frais de priorité élevés sur leurs transactions.

Dans un scénario concurrentiel où les bénéfices sans risque sont réduits à zéro, le chercheur gagnant devrait finir par payer le montant total de MEV en frais de priorité.3Donc, s'il y a 100 ETH de profit à gagner en interagissant avec un contrat, la première transaction pour le réclamer fixera des frais de priorité de 100 ETH. (Nous discutons de certaines limitations à ce sujet dans la section Limitations).

taxes MEV

Suppose qu'un contrat intelligent souhaite capturer le MEV de n'importe quelle transaction qui interagit avec lui. Il existe une vaste bibliothèque de recherches sur les différentes façons d'application spécifiques que les contrats intelligents pourraient essayer de capturer leur propre MEV.

Mais en réalité, nous n'avons pas nécessairement besoin de connaître quoi que ce soit sur l'application. Si nous savons que le bloc est en cours de construction à travers un ordre de priorité compétitif, alors nous avons un signal universel pour la quantité de MEV dans la transaction : le frais de priorité.

Nous proposons que le contrat intelligent puisse consulter les frais de priorité de la transaction et facturer ses propres frais comme une fonction croissante de ceux-ci. Par exemple, le contrat pourrait exiger que quiconque l'appelle transfère applicationPriorityFee = 99 * proposerPriorityFee en ETH au contrat.4

Cette nouvelle commission est payée par le chercheur envoyant la transaction, ce qui affecte le comportement de ce chercheur. S'il y a 100 MEV dans une opportunité, la transaction gagnante ne fixera désormais qu'une commission prioritaire de 1 ETH, puisque cela entraînera un paiement total de 100 ETH (1 ETH au proposant de bloc et 99 ETH au contrat intelligent). Toute commission prioritaire plus élevée rendrait la transaction non rentable; toute commission prioritaire plus basse entraînerait une perte de l'opportunité au profit d'un concurrent ayant fixé une commission plus élevée. Cela signifie que le contrat intelligent a capturé 99 % des MEV dans la transaction.

Nous appelons cette taxe supplémentaire imposée par le contrat intelligent une taxe MEV. Les taxes MEV permettent à une application de détourner l'ordre de priorité à son avantage, lui permettant de récupérer le MEV pour ses utilisateurs plutôt que de le divulguer au proposant de bloc.

Si cette commission augmente suffisamment rapidement en fonction de priorityFeePerGas, alors une quantité négligeable de MEV ne reviendra au proposant. Étant donné que priorityFeePerGas est libellé en wei (un milliardième d'un milliardième d'un ETH), nous disposons de beaucoup de précision pour travailler. Par exemple, tant que la taxe MEV est suffisamment sensible pour qu'un priorityFeePerGas de 50 000 entraîne une taxe prohibitivement élevée, le paiement total au proposant serait inférieur à 0,01 $. 5

Cependant, il y a un important avertissement. Comme discuté dans la section des Limitations, les taxes MEV ne fonctionnent que si les proposants de blocs suivent certaines règles - ce que nous appelons "l'ordre de priorité concurrentiel" - plutôt que de s'écarter de ces règles afin de maximiser leurs propres revenus. Faire respecter ces règles de manière décentralisée est un problème ouvert.

Capture de MEV à application unique

Ici, nous esquissons comment, sur une chaîne garantie d'utiliser un ordre de priorité compétitif pour la construction de blocs, les taxes MEV pourraient être utilisées pour atténuer trois problèmes importants dans MEV: permettre aux interfaces DEX d'améliorer l'exécution des trades pour les swappers, permettre aux AMM de réduire les pertes d'arbitrage pour leurs LP, et permettre aux portefeuilles de réduire les fuites MEV pour leurs utilisateurs en vendant le droit de backrun l'utilisateur.

Routeurs DEX

Dans les protocoles de routage DEX basés sur l'intention comme UniswapXetFusion 1 pouce, un utilisateur (Alice) signe une intention d'échange, et des chercheurs se disputent pour acheminer ou remplir cette intention au meilleur prix possible pour Alice.

Les versions actuelles d'UniswapX utilisent deux mécanismes pour gérer cette compétition : une vente aux enchères hollandaise où le prix limite d'Alice change avec le temps jusqu'à ce qu'un chercheur la remplisse, et une première vente aux enchères hors chaîne de demandes de devis (RFQ) pour fixer le prix de départ de cette vente aux enchères hollandaise.

Sur une plateforme qui garantit un ordre de priorité compétitif, UniswapX pourrait remplacer ceux-ci par un mécanisme unique : une taxe MEV. Il pourrait mettre en œuvre cela en demandant à l'utilisateur de signer un ordre pouvant être exécuté immédiatement par n'importe qui, mais avec un prix d'exécution défini en fonction de la priorité de la transaction.

Par exemple, si Alice a un ordre UniswapX pour vendre 1 ETH, elle pourrait définir le prix d'exécution de l'ordre comme étant minimumPrice + ($0.01 * priorityFeePerGas). minimumPrice pourrait être une valeur fixe qu'elle s'attend à ce qu'elle soit significativement inférieure au prix actuel.

Les chercheurs se disputeraient pour remplir la commande d'Alice en soumettant des transactions. La transaction ayant les frais de priorité les plus élevés et ne se revert pas serait celle qui remplirait la commande, ce qui devrait garantir que le swapper obtient le meilleur prix que les chercheurs peuvent trouver. (Certaines exceptions à cela sont discutées dans la section Limitations).

Si le prix minimum d'Alice est de 3 000 $ et que le prix actuel de l'ETH est de 3 500 $, priorityFeePerGas dans la transaction gagnante serait d'environ 50 000. (Remarquez que dans une transaction qui coûte 200 000 gaz, cela se traduira par un paiement d'environ 10 milliards de wei, soit environ 0,000035 $, au proposant de bloc.)

Cela présente certains avantages potentiels par rapport aux mécanismes existants utilisés dans UniswapX.

Les ordres utilisant les taxes MEV pourraient être exécutés plus rapidement et à un meilleur prix que les ordres utilisant des enchères hollandaises. Comme discuté dans ce document, les enchères hollandaises onchain laissent fuir une certaine valeur vers MEV en raison des mouvements de prix entre les blocs, et peuvent prendre de nombreux blocs pour se terminer. En revanche, les ordres qui utilisent les taxes MEV pourraient généralement être exécutés dans le bloc suivant tout en capturant la grande majorité de leur MEV.

Contrairement à une RFQ hors-chaîne, l'enchère pour remplir un ordre qui utilise des taxes MEV se déroulerait de manière atomique avec l'exécution de la transaction sur la chaîne. Cela signifie qu'un enchérisseur gagnant pourrait être assuré qu'il n'est engagé à remplir l'ordre que si sa transaction onchain réussit. Cela pourrait faciliter la concurrence de la liquidité onchain comme les AMM avec la liquidité hors chaîne, ce qui signifie que UniswapX pourrait servir de routeur encore plus efficace pour les systèmes multi-pools comme Uniswap v4.

AMMs

Normalement, les AMM laissent échapper de la valeur aux arbitragistes qui échangent contre des prix obsolètes en haut du bloc, comme discuté dans le perte-vs-rééquilibragepapiers. Nous pouvons utiliser des taxes MEV pour que les AMM capturent ce MEV. Pour simplifier les choses, nous discuterons de la façon dont cela pourrait fonctionner sur un AMM sans liquidité concentrée. (Si vous êtes intéressé par la façon dont ce type de problème pourrait être résolu avec une liquidité concentrée, Sœurpubliera bientôt une solution.

Un AMM peut capturer le MEV en facturant des frais supplémentaires en fonction des frais de priorité sur la transaction, ce qui lui permet de mettre aux enchères le droit de trader en premier dans le bloc. Il existe de nombreuses façons de calculer et de désigner ces frais. Nous en discuterons une qui est peut-être neutre : en les désignant en unités de liquidité de pool, sqrt(xy). La transaction gagnante serait celle qui augmente le plus la liquidité du pool.

Lors de l'exécution de la première transaction sur un pool dans un bloc, au lieu d'imposer la condition x_endy_end > x_start y_start, le pool pourrait imposer la condition (avec a comme une constante):

x_end y_end > (sqrt(x_start y_start) + a*priorityFeePerGas)^2

Cette formule inciterait le trader d'arbitrage à trader au vrai prix, et après ce trade, le prix intermédiaire dans le pool devrait être le vrai prix.6

Après cette première transaction, les échanges pourraient fonctionner comme sur Uniswap v2, avec des frais de swap fixes. Les transactions non informées qui souhaitent échanger sur le pool sans payer de taxe MEV supplémentaire fixeraient des frais de priorité bas.

Il existe de nombreuses autres façons d'implémenter des taxes MEV sur un AMM qui auraient des effets différents. Par exemple, les taxes MEV pourraient être libellées dans le jeton d'entrée ou de sortie de l'échange, pourraient affecter le pourcentage de frais d'échange appliqué par le pool, ou pourraient déterminer le prix minimum de l'échange de l'utilisateur. Nous pensons que c'est un espace de conception intéressant à explorer.

Enchères de rétrocession

Les descriptions ci-dessus montrent comment certaines applications pourraient être conçues pour éviter les fuites de MEV. Cependant, que se passe-t-il si un portefeuille souhaite essayer d'aider ses utilisateurs à capturer le MEV qu'ils créent à partir de transactions arbitraires interagissant avec n'importe quelle application, même celles qui n'incorporent pas de taxes MEV ?

Par exemple, lorsque Alice effectue une grosse transaction sur une AMM, elle crée parfois une opportunité d'arbitrage pour les "backrunners" de faire revenir le prix. Cela est généralement divulgué à MEV, plutôt que d'aller à Alice.

MEV-ShareetMEVBlockersont deux protocoles permettant aux utilisateurs de capturer le MEV de leurs transactions, mais ils reposent sur un système d'enchères complexe hors chaîne.L'espace de conception des enchères de flux de commandesdécrit quelques autres solutions.

Les taxes MEV, combinées à un portefeuille de contrats intelligents basé sur l'intention, pourraient nous permettre de construire un système alternatif pour capturer le MEV de backrunning pour Alice. Supposons qu'au lieu de créer une transaction qui échange sur l'AMM, Alice signe une intention que quiconque peut soumettre au portefeuille de contrats intelligents d'Alice pour le pousser à prendre cette action. Le portefeuille de contrats intelligents d'Alice facture à quiconque soumet cette transaction une taxe MEV, qui est versée à Alice.

Le chercheur qui soumet l'intention d'Alice aura le droit exclusif de la suivre, car il peut le faire de manière atomique dans la même transaction. Par conséquent, si la recherche est compétitive, l'ensemble du profit de la poursuite d'Alice devrait revenir à Alice grâce à sa taxe MEV.

Notez que ce système ne protège pas nécessairement les utilisateurs contre les attaques impliquant le passage devant les transactions des utilisateurs, car une transaction qui passe devant un utilisateur peut être en mesure d'éviter de payer une taxe MEV à cet utilisateur. Ce problème (et certaines atténuations possibles) est discuté plus en détail dans la section Limitations ci-dessous. Néanmoins, cela pourrait au moins représenter une amélioration par rapport aux systèmes utilisant des mempools publics sans aucune atténuation.

Autres cas d'utilisation

En plus de ces exemples, d'autres utilisations potentielles des taxes MEV pourraient inclure presque tout ce qui utilise actuellement une vente aux enchères hors chaîne ou hollandaise, comme :

• Les protocoles pour les oracles afin de capturer la valeur extractible de l'oracle qu'ils créent, comme Ovale
• Les enchères de refinancement dans les protocoles de prêt garantis par NFT comme Mélange
• Liquidations de protocole de prêt qui moins de valeur de fuiteque les enchères hollandaises

Capture de MEV entre applications

Les solutions ci-dessus sont conçues pour capturer le MEV en interagissant avec une seule application. Mais parfois, il est possible qu'un chercheur puisse capturer encore plus de valeur en interagissant avec plusieurs applications dans la même transaction.

Si seulement l'une de ces applications a une taxe MEV, alors tout le MEV de la transaction devrait aller à l'application avec la taxe MEV, peu importe à quel point cette taxe MEV est élevée ou basse.

Mais que se passe-t-il si la transaction d'un chercheur interagit avec deux applications qui utilisent des taxes MEV ? Par exemple, que se passe-t-il s'il y a une certaine MEV qui ne peut être capturée qu'en remplissant l'un des ordres UniswapX taxés en MEV décrits ci-dessus contre un AMM taxé en MEV ?

Dans ce cas, la quantité relative d'excès de MEV capturée par chaque application est déterminée par la manière dont ces applications fixent leurs taxes MEV. Si la valeur app_i facture en tant que taxe MEV est donnée par la fonction tax_i(priority), alors la priorité de la transaction gagnante peut être déterminée en résolvant la priorité dans cette équation :

tax_1(priorityPerGas) + tax_2(priorityPerGas) = total MEV

(Techniquement, nous pourrions ajouter un troisième terme pour priorityPerGas * gasUsed afin de prendre en compte les frais de priorité payés au proposant de bloc, mais nous l'ignorerons car, comme discuté dans l'Annexe A, il sera probablement négligeable dans des conditions normales).

Dans le cas simple des taxes MEV qui sont linéaires par rapport à priorityPerGas (donc tax_1(priorityPerGas) = a_1 * priorityPerGas), vous pouvez résoudre la part de MEV reçue par chaque application :

a_1priorityPerGas + a_2priorityPerGas = MEV

priorityPerGas = MEV/(a_1 + a_2)

tax_1(priorityPerGas) = (a_1/(a_1+a_2))*MEV

tax_2(priorityPerGas) = (a_2/(a_1+a_2))*MEV

Lorsqu'une application définit sa propre taxe MEV, elle est confrontée à un compromis : des taxes plus élevées lui permettent de capturer une plus grande part du MEV inter-applications lorsqu'il se produit, mais signifient qu'elle pourrait passer à côté de certains MEV inter-applications s'il existe des moyens concurrents de l'extraire. Par exemple, s'il y a un AMM qui facture une taxe MEV à chaque échange, alors un ordre UniswapX avec taxe MEV pourrait être plus susceptible d'être exécuté par un autre AMM ou un exécuteur hors chaîne.

Dans de nombreux cas, il peut y avoir un équilibre dans lequel deux applications conçoivent leurs taxes MEV afin de partager les MEV de manière à maximiser le bien-être de chacune d'elles. Par exemple, un AMM taxé sur le MEV voudrait probablement capturer de la valeur auprès d'un seul trader informé près du sommet du bloc, mais voudrait ensuite fournir de la liquidité à d'autres traders et applications (y compris ceux qui utilisent des taxes MEV) avec des frais fixes bas. Dans ce cas, l'AMM est susceptible de fixer une taxe MEV relativement faible (disons, 0,00001 $priorityFeePerGas), de sorte que la transaction d'arbitrage (le cas échéant) se produise tôt dans le bloc, puis ne facturer aucune taxe MEV sur les transactions ultérieures dans le bloc. Les applications comme UniswapX qui souhaitent interagir avec l'AMM peuvent définir une taxe MEV beaucoup plus élevée (disons 0,01 $ priorityFeePerGas), pour s'assurer que leurs transactions sont incluses après que le pool a déjà été arbitrée. Avec ces taxes relatives, l'AMM se retrouverait arbitré en premier même s'il n'y avait que 1 $ de MEV dessus et 50 000 $ de MEV dans un ordre UniswapX.

Nous pensons que c'est un vaste espace de conception digne d'études futures.

Limitations

Les taxes MEV posent des complications et des inconvénients. Nous pensons que chacune d'entre elles est un domaine d'étude intéressant pour l'avenir.

Incentive incompatibilité

Les taxes MEV ne sont pas compatibles avec les incitations pour un proposeur de bloc monopolistique. Elles ne fonctionnent que s'il y a une concurrence équitable pour l'inclusion des transactions, ce qui ne peut se produire que si le proposeur de bloc suit des règles que nous appellerons "ordre de priorité compétitive", plutôt que de maximiser leurs propres revenus. De manière informelle et non exhaustive, nous suggérons que ces règles devraient inclure :

• Commande de priorité. Les transactions au sein d'un bloc doivent être ordonnées en ordre décroissant de prioritéFeePerGas.
• Résistance à la censure. Si le proposant de bloc reçoit une transaction t1 pendant le bloc, et que le bloc n'est pas complet ou inclut une transaction t2 telle que t2.priorityFeePerGas < t1.priorityFeePerGas, alors le bloc doit inclure la transaction t1.
• Confidentialité avant la transaction. Le proposant de bloc doit accepter les transactions via un point de terminaison privé et ne doit pas partager ces transactions avec qui que ce soit avant de s'engager sur le bloc, ou utiliser le contenu de ces transactions comme entrée pour construire ses propres transactions.
• Pas de dernier regard. Le proposant de bloc doit définir un temps défini blockTime avant lequel ils acceptent des transactions de quiconque, et après lequel ils n'acceptent pas de transactions de quiconque.

Si une ou plusieurs de ces propriétés sont violées, cela peut affaiblir l’efficacité des taxes sur les VEM. Un proposant de bloc qui viole la résistance à la censure peut éviter la plupart des taxes MEV en excluant les transactions concurrentes et en soumettant une transaction à priorité zéro qui saisit l’opportunité pour elle-même. Un proposant de bloc qui viole la vie privée avant la transaction pourrait voler des MEV à d’autres transactions ou jeter un coup d’œil à leurs frais prioritaires pour savoir exactement à quel niveau il doit fixer les siens, tandis qu’un proposant qui est en mesure de soumettre des transactions plus tard que quiconque aurait un « dernier coup d’œil » gratuit sur l’opportunité de surenchérir sur les autres. L’un ou l’autre de ces facteurs pourrait créer des problèmes d’antisélection qui, en fin de compte, décourageraient la concurrence.

Malheureusement, alors que la première propriété serait facile à appliquer au niveau du protocole, l'application des autres propriétés de manière fiable est un problème ouvert.

En l'absence d'application au niveau du protocole, un séquenceur unique qui s'engage à respecter ces règles doit être digne de confiance pour ne pas s'en écarter, et si les proposants externalisent la construction de blocs à une enchère compétitive visant à maximiser les revenus (comme celle d'Ethereum L1).MEV-Boost) , les blocs ne les suivront probablement pas.

Ces problèmes peuvent être "résolus" avec un seul séquenceur de confiance qui s'engage à utiliser un ordre de priorité compétitif pour la construction de blocs. Ils peuvent également être résolus avec un mécanisme décentralisé utilisant une combinaison de consensus, de cryptographie et/ou d'environnements d'exécution de confiance, tels que Angstrom de Sorella, SUAVE de Flashbots, Ventes sans leader, ou Multiplicité.

Blocs pleins

Une exception au fonctionnement normal des taxes MEV se produit lorsque les blocs sont complètement pleins. Dans ce cas, les proposeurs de blocs peuvent être obligés de laisser de côté des transactions de priorité inférieure, plutôt que de les inclure simplement tardivement dans le bloc. Étant donné que les transactions qui interagissent avec des applications taxées MEV ont probablement des frais de priorité extrêmement bas, ces applications ont tendance à être écartées par des applications qui n'utilisent pas de taxes MEV, ou celles qui ont des taxes MEV extrêmement faibles. Cependant, dans une chaîne qui utilise un mécanisme similaire à l'EIP-1559 pour définir un basefee séparé, il devrait être relativement rare que les blocs soient complètement pleins. De plus, étant donné que certaines transactions doivent être retardées lorsque les blocs sont pleins, retarder les transactions exprimant une urgence moindre en fixant des taxes MEV plus élevées peut être un résultat raisonnable.

Transactions annulées

Les taxes MEV reposent effectivement sur des enchères d'un seul bloc dans lesquelles chaque "offre" est une transaction. Un inconvénient de ces enchères est que les offres perdantes entraîneront généralement l'inclusion de transactions annulées onchain, payant des frais de base et engorgeant la chaîne.

Si un séquenceur peut exclure complètement les transactions échouées, cela pourrait atténuer ce problème, même si cela peut être difficile à mettre en œuvre même avec un séquenceur centralisé. (Cela ne respecterait pas strictement la propriété de résistance à la censure décrite ci-dessus, même si cette définition pourrait être ajustée.) Un séquenceur plus sophistiqué pourrait optimiser ce processus en permettant aux transactions de spécifier dans quelles enchères contestées elles participent, donnant ainsi au séquenceur suffisamment d'informations pour ignorer les transactions ultérieures qu'il sait qu'elles échoueraient.

Fuite des intentions des utilisateurs

Les taxes MEV ne fonctionnent que s'il y a une concurrence entre les chercheurs, ce qui signifie que l'opportunité doit être quelque peu largement connue. Pour des applications comme les AMM, où l'opportunité est visible onchain, cela devrait se produire naturellement. Mais pour des applications comme le routage basé sur l'intention ou les enchères de front-running, cela signifie que l'application peut avoir besoin de partager l'intention de l'utilisateur avec les chercheurs.

Dans certains cas, la perte temporaire de confidentialité due à la diffusion de l'intention de l'utilisateur avant qu'elle ne soit satisfaite peut divulguer de la valeur d'une manière qui ne peut être récupérée par une taxe MEV.

Par exemple, supposons qu'Alice souhaite acheter un jeton à faible liquidité en utilisant le protocole d'enchères de rétro-ingénierie décrit ci-dessus. Elle publie une intention signée pour son portefeuille de contrat intelligent afin d'acheter ce jeton sur un AMM, en définissant une certaine tolérance au glissement. Les chercheurs pourraient se précipiter pour pousser le prix de ce jeton jusqu'à sa tolérance au glissement dans une transaction de haute priorité, sans pour autant remplir la commande de l'utilisateur. Le gagnant, Bob, pourrait ensuite remplir non concurrentiellement l'intention d'Alice en l'incluant et en la rétro-ingénierie dans une transaction de faible priorité, ce qui permettrait de coincer l'échange d'Alice et de lui donner un prix moins favorable tout en évitant sa taxe de MEV. Un problème similaire pourrait survenir avec les achats de NFT.

Notez que une telle attaque serait risquée pour Bob, puisqu'il ne pourrait pas garantir l'atomicité entre l'achat du jeton et sa revente à Alice. Un Bob naïf pourrait tomber victime d'un piège de "déchirure de sandwich" dans lequel Alice publie une intention d'acheter un jeton sans valeur d'elle-même, amenant Bob à l'acheter en anticipant de l'intercaler dans son échange, mais Alice révoque son intention avant que Bob ne puisse compléter le sandwich.

Les applications peuvent également être en mesure d'atténuer cela en limitant l'ensemble des chercheurs avec lesquels elles partagent des intentions et en surveillant leur comportement, comme le font de nombreuses enchères de flux de commandes existantes.

Il pourrait également être possible de combiner les taxes MEV avec des fonctionnalités de constructeur sensibles à la confidentialité comme envisagé dans les conceptions de Flashbots pour ÉLÉGANT.

Enfin, dans les cas où Alice décide que les coûts de partager son intention l'emportent sur le bénéfice de la recherche concurrentielle, elle pourrait construire une transaction elle-même et la soumettre directement dans le bloc. Comme discuté précédemment, une implémentation idéale de l'ordonnancement de priorité compétitive fournirait une confidentialité pré-transactionnelle vis-à-vis du proposant de bloc.

Discussion et travaux antérieurs

Ventes aux enchères de gaz prioritaires. Certaines des dynamiques de l'ordonnancement prioritaire dans les blockchains décentralisées ont été étudiées dans le Flash Boys 2.0Le document, qui a inventé le terme "valeur extractible par les mineurs", a observé que les mineurs d'Ethereum (lorsque ce réseau utilisait la preuve de travail) ordonnaient déjà les transactions par priorité, et que les arbitragistes se fiaient à ce comportement pour participer aux "enchères de gaz prioritaires" dans lesquelles ils enchérissaient pour avoir le droit d'être inclus en premier dans un bloc, ce qui a conduit à ce que la majeure partie de la MEV provenant de l'arbitrage des échanges décentralisés revienne aux mineurs.

Les premiers arrivés seront les premiers servis. Certaines tentatives de réduction de l'impact de la valeur extractible de la mémoire via des règles d'ordonnancement des transactions, telles que Themisoule séquenceur actuel d'Arbitrum One,7ont mis l'accent sur l'application d'une règle de commande différente, premier arrivé, premier servi (parfois appelée "commande équitable") où les proposants de blocs doivent ordonner les transactions dans l'ordre dans lequel ils les voient.

La commande prioritaire adopte une approche différente en traitant de manière égale les transactions qui arrivent dans une période donnée, et en les classant plutôt par leur priorité déclarée.

La règle du premier arrivé, premier servi est difficile à appliquer ou même à définir dans un environnement réseau réel avec plus d'un validateur. Cela peut également entraîner des courses de latence inutiles et du spam même avec un seul séquenceur de confiance. Enfin, les taxes MEV peuvent être en mesure d'éliminer certains types de MEV que l'ordonnancement premier arrivé, premier servi ne peut pas, tels que les profits d'arbitrage résultant de « sauts » discontinus dans les prix des actifs. Les avantages potentiels de l'ordonnancement par priorité par rapport à l'ordonnancement premier arrivé, premier servi sont quelque peu liés aux avantages des échanges en temps discret par rapport aux échanges en temps continu discutés dans Budish, Cramton, Shim (2015).

Pendant ce temps, bien que la commande de priorité semble par défaut céder de la valeur à la MEV, ce post montre comment les applications peuvent être conçues pour la récupérer.

Partage des frais. Blast, un Ethereum L2,actionsune partie des frais prioritaires et de base avec les contrats intelligents accessibles dans une transaction.

Les taxes MEV permettent quelque chose de similaire (au moins pour les frais de priorité), mais peuvent être mises en œuvre au niveau de l'application sur n'importe quelle chaîne qui utilise un ordre de priorité compétitif, sans support spécial pour le partage des frais. Ils permettent également aux applications de définir leurs propres taxes en tant que fonctions personnalisées des frais de priorité, offrant ainsi plus de flexibilité et potentiellement une plus grande composition des applications conscientes de l'EMV.

Solutions sans confiance. Ce message met l'accent sur la motivation pour les plateformes d'utiliser un classement prioritaire concurrentiel - et les moyens de profiter des plateformes qui le font - plutôt que de discuter de la façon de l'appliquer sans confiance.

Il y a eu des discussions préalables importantes sur chacune des autres propriétés requises pour l'ordonnancement des priorités compétitives. Par exemple, dans Fox, Pai, Resnick (2023), les auteurs discutent des vulnérabilités dans les enchères onchain en l'absence de résistance à la censure, et décrivent un design pour une enchère résistante à la censure en utilisant plusieurs proposants concurrents. Cependant, ils ne suggèrent pas un ordre spécifique pour les transactions.

Il y a eu d'autres recherches sur la construction de mécanismes de construction de blocs à confiance minimisée, y compris Flashbots’sÉLÉGANT, SœurAngstrom de ‘s, Ventes sans leader, Espresso et Offchain Labs’ @espressosys/systèmes-de-café-et-offchain-labs-lancent-la-feuille-de-route-r-d-pour-le-temps-boost-décentralisé-5d0007dff66d">temps boost décentralisé, et inclusion obligatoire des transactions publiquespar Péter Szilági.

Conclusion

Nous espérons que ce message encouragera les L2 à envisager d'utiliser la commande de priorité (comme le supporte par défaut le OP Stack) et incitera les applications à essayer les taxes MEV là où elles sont prises en charge.

Nous espérons également qu'il stimulera de nouvelles recherches sur les protocoles d'ordonnancement prioritaire concurrentiels à faible confiance à la fois sur L1 et L2. Si vous êtes intéressé à collaborer sur ce problème et que vous lisez ceci avant le jeudi 6 juin, vous pouvez toujours postuler pour une bourse TLDR pour travailler surSéquenceurs L2 résistants à la MEV avec Dan. Ou n'hésitez pas à simplement contacter dan@paradigm.xyz et dave@paradigm.xyzavec des idées!

Notes de bas de page

1. Dans ce post, nous utilisons le terme "proposant" pour désigner l'acteur ou le processus qui détermine quelles transactions sont incluses dans un bloc particulier. Sur les L2 d'Ethereum, ce rôle est généralement rempli par un "séquenceur". Sur Ethereum L1, il est rempli par un validateur Ethereum spécifique appelé un proposant, bien que souvent le proposant sous-traite la tâche de construction du bloc à une enchère compétitive dans laquelle les "relayers" et les "constructeurs" participent. Les détails de la répartition de ces responsabilités ne sont pas abordés dans ce post.↩
2. La taxe de priorité par gaz n'est pas réellement spécifiée explicitement dans la transaction, mais peut être calculée en elle. La transaction spécifie un prix du gaz, mais Ethereum facture également des frais de base, qui sont déduits du prix du gaz et brûlés. Les frais de base doivent être ignorés aux fins des taxes MEV, car ils ne sont pas sous le contrôle du transacteur. La taxe de priorité par gaz - le prix de la partie des frais de transaction qui va au proposant de bloc - peut être calculée en Solidity comme suit : priorityGasPrice = tx.gasprice - block.basefee.↩
3. Alternativement, nous pourrions simplement définir "MEV" pour exclure tout profit du chercheur et ne se référer qu'à la valeur qui irait au validateur.↩
4. Notez que proposerPriorityFee — égal à priorityFeePerGas fois le total du gaz utilisé dans la transaction — ne peut pas être réellement calculé pendant le contrat, car il n'y a aucun moyen de savoir combien de gaz la transaction finira par utiliser. Cependant, cela n'a généralement pas d'importance, car tout ce dont nous avons besoin est une limite supérieure pour cela. Pour être prudent, vous pourriez multiplier priorityFeePerGas par 30 millions — le gaz maximum actuel dans un bloc Ethereum. Surestimer cette valeur signifiera simplement que la taxe MEV capture un pourcentage encore plus élevé de MEV.↩
5. En supposant qu'une transaction ne puisse pas dépasser 30 millions de gaz, un priorityFeePerGas de 50 000 entraînerait un paiement de gaz de 1 500 gwei, soit environ 0,006 $ à un prix de l'ETH de 4 000 $. ↩
6. Dans le cas où priorityFeePerGas est réglé de sorte que le profit de l'arbitragiste est nul, le commerce d'arbitrage visant à maximiser les profits devrait correspondre au même commerce sur le fonction maximisant AMM. Prouver cela est laissé en tant qu'exercice pour le lecteur. ↩
7. Arbitrum a discutéremplacer cela par une forme de classement par priorité appelée Timeboost, mais cela n'a pas été mis en production à l'heure actuelle.

Avertissement：

1. Cet article est repris de [Gateparadigme] Tous les droits d'auteur appartiennent à l'auteur original [Dan Robinson, Dave Blanc]. Si vous avez des objections à cette réimpression, veuillez contacter le Portail Apprendreéquipe, et ils s'en occuperont rapidement.
2. Responsabilité 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.