Introduction

Dans cet article, nous présentons les taxes MEV, un mécanisme que les applications arbitraires peuvent utiliser pour capturer leurs propres MEV.

Ce mécanisme pourrait être utilisé aujourd’hui sur OP Stack L2 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é concurrentiel.

Pour mettre en œuvre une taxe MEV sur l’une de ces chaînes, un contrat intelligent facture des frais qui sont 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 prioritaires, elle peut capturer 99% du MEV concurrentiel 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 de la chaîne d’exécuter sa propre enchère MEV personnalisée, sans avoir besoin de sa propre infrastructure offchain, simplement en se connectant à une seule enchère 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 MEV :

• Routeurs de plateforme d’échange décentralisée (DEX) qui optimisent le prix reçu par l’échangeur
• Les teneurs de marché automatisés (AMM) qui minimisent les pertes et les rééquilibrages (LVR) subis par les fournisseurs de liquidités
• Des portefeuilles qui permettent à leurs utilisateurs de capturer tout MEV « backrunning » créé par leurs transactions

Mais il y a un hic. Les taxes MEV ne fonctionnent que si les soumissionnaires en bloc suivent strictement les règles de l’ordre prioritaire concurrentiel, qui incluent le tri des transactions par frais prioritaires sans censurer, jeter un coup d’œil ou retarder. Si les soumissionnaires de bloc s’écartent de ces règles, ils peuvent éluder les taxes MEV pour capturer la valeur pour eux-mêmes. Aujourd’hui, par conséquent, les taxes 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 blocs est dominée par une enchère de construction compétitive qui maximise les revenus du proposant.

Néanmoins, la puissance et la flexibilité des taxes MEV suggèrent que la commande prioritaire peut être le bon choix pour les plates-formes qui peuvent le fournir aujourd’hui. Et la relative simplicité de l’ordre de priorité concurrentiel suggère qu’il existe peut-être un moyen viable de l’appliquer de manière décentralisée, sans avoir à faire confiance à un seul séquenceur. Nous espérons que cet article motivera d’autres travaux sur ce problème.

Ordre prioritaire

Lorsque quelqu’un envoie une transaction sur un Ethereum L1 ou L2, il spécifie une commission de priorité, qu’il paie au proposant de bloc.1 Vous pouvez imaginer que cela est spécifié comme priorityFeePerGas, un nombre qui est multiplié par le gas utilisé dans la transaction pour obtenir builderPriorityFee, le paiement total en ETH. 2

Il n’y a pas de règle dans la Ethereum protocole selon laquelle les transactions d’un bloc doivent être ordonnées avec avidité en décroissant priorityFeePerGas. Cependant, il s’agit d’une façon populaire de construire des blocs - par exemple, c’est l’algorithme par défaut utilisé par les séquenceurs de OP chaînes de piles, ainsi que geth et reth. Non seulement l’ordre prioritaire permet aux transacteurs d’exprimer efficacement l’urgence de leurs transactions, mais il canalise aussi naturellement certains types de MEV vers le proposant de bloc.

Cela se produit parce que l’ordre de priorité transforme la concurrence pour MEV en une enchère gas prioritaire priority. Lorsqu’il y a une opportunité de tirer profit de l’interaction avec la chaîne, par exemple en arbitrant un AMM contre une plateforme d’échange centralisée, les chercheurs rivalisent pour revendiquer cette opportunité en premier. Si la chaîne utilise l’ordre de priorité pour déterminer l’inclusion et l’ordre des transactions, les chercheurs se font concurrence en fixant des frais de priorité élevés sur leurs transactions.

Dans un scénario concurrentiel où les profits sans risque sont réduits à zéro, le chercheur gagnant devrait finir par payer le montant total de MEV en frais prioritaires. 3 Ainsi, s’il y a 100 ETH de profit à tirer de l’interaction avec un contrat, la première transaction à le réclamer fixera des frais de priorité de 100 ETH. (Nous discutons de certaines mises en garde à ce sujet dans la section Limitations).

MEV taxes

Supposons qu’un contrat intelligent veuille capturer les MEV de toute transaction qui interagit avec lui. Il existe une vaste bibliothèque de recherches sur différentes façons spécifiques aux applications que les smart contracts pourraient essayer de capturer leur propre MEV.

Mais en fait, nous n’avons pas nécessairement besoin de savoir quoi que ce soit sur l’application. Si nous savons que le bloc est construit au moyen d’un ordre prioritaire concurrentiel, nous avons alors un signal universel pour le montant de MEV dans la transaction : les frais de priorité.

Nous proposons que le contrat intelligent puisse considérer les frais de priorité de la transaction et facturer ses propres frais comme une fonction croissante de celle-ci. Par exemple, le contrat peut exiger que celui qui l’appelle transfère applicationPriorityFee = 99 * proposerPriorityFee en ETH au contrat. 4

Ces nouveaux frais sont payés par l’internaute qui envoie la transaction, ce qui affecte le comportement de cet internaute. S’il y a 100 MEV dans une opportunité, la transaction gagnante ne fixera désormais que des frais de priorité de 1 ETH, car cela entraînera un paiement total de 100 ETH (1 ETH au proposant de bloc et 99 ETH au contrat intelligent). Des frais de priorité plus élevés rendraient la transaction non rentable ; Tout frais de priorité inférieure entraînerait la perte de l’opportunité au profit d’un concurrent qui fixerait des frais plus élevés. Cela signifie que le contrat intelligent a capturé 99% du MEV dans la transaction.

Nous appelons ces frais supplémentaires imposés par le contrat intelligent une taxe MEV. Les taxes MEV permettent à une application de détourner la commande prioritaire pour son propre bénéfice, ce qui lui permet de récupérer le MEV pour ses utilisateurs plutôt que de le divulguer au proposant de bloc.

Si ces frais augmentent suffisamment rapidement en fonction de priorityFeePerGas, seul un montant négligeable de MEV reviendra au soumissionnaire. Étant donné que priorityFeePerGas est libellé en wei (un milliardième de milliardième d’un ETH), nous avons beaucoup de précision avec laquelle travailler. Par exemple, aussi longue que la taxe MEV soit suffisamment sensible pour qu’un priorityFeePerGas de 50 000 entraîne une taxe prohibitive, le paiement total au proposant serait inférieur à 0,01 $. 5

Cependant, il y a une mise en garde importante. Comme nous l’avons vu dans la section Limitations, les taxes sur les MEV ne fonctionnent que si les soumissionnaires en bloc suivent certaines règles – ce que nous appelons « ordre de priorité concurrentiel » – plutôt que de s’écarter de ces règles dans l’ordre pour maximiser leurs propres revenus. L’application de ces règles sans confiance est un problème ouvert.

Capture de MEV d’application unique

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

DEX routeurs Dans

les protocoles de routage DEX basés sur l’intention comme UniswapX et 1inch Fusion, un utilisateur (Alice) signe une intention d’échanger, et les chercheurs sont en concurrence pour acheminer ou remplir cette intention au meilleur prix possible pour Alice.

Les versions actuelles d’UniswapX utilisent deux mécanismes pour organiser cette compétition : une enchère néerlandaise où le prix limite d’Alice change au fil du temps jusqu’à ce qu’un chercheur le remplisse, et une enchère initiale de demande de devis (RFQ) off-chain pour fixer le prix de départ de cette enchère néerlandaise.

Sur une plate-forme qui garantit des commandes prioritaires compétitives, UniswapX pourrait les remplacer par un seul mécanisme : une taxe MEV. Il pourrait mettre cela en œuvre en faisant signer à l’utilisateur un ordre qui peut être rempli immédiatement par n’importe qui, mais avec un prix d’exécution qui est fixé en fonction de la priorité de la transaction.

Par exemple, si Alice dispose d’une ordre UniswapX pour vendre 1 ETH, elle peut définir le prix d’exécution du ordre comme étant minimumPrice + (0,01 $ * priorityFeePerGas). minimumPrice peut être une valeur fixe qui, selon elle, sera nettement inférieure au prix actuel.

Les chercheurs seraient en concurrence pour remplir l’ordre d’Alice en soumettant des transactions. Quelle que soit la transaction ayant les frais de priorité les plus élevés et ne revenant pas en arrière, elle remplira l’ordre, ce qui devrait garantir que l’échangeur obtient le meilleur prix que les chercheurs peuvent trouver. (Certaines exceptions à cette règle sont abordé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. (Notez que dans une transaction qui coûte 200 000 gas, cela se traduira par un paiement d’environ 10 milliards de wei seulement – environ 0,000035 $ – au proposant de bloc.)

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

Les commandes qui utilisent les taxes MEV pourraient être exécutées plus rapidement et à un meilleur prix que les commandes qui utilisent des enchères néerlandaises. Comme indiqué dans cet article, les enchères néerlandaises onchain perdent de la valeur pour MEV en raison des mouvements de prix entre les blocs, et peuvent prendre de nombreux blocs pour être complétées. En revanche, les commandes qui utilisent les taxes MEV pourraient généralement être complétées dans le bloc suivant tout en capturant la grande majorité de leur MEV.

Contrairement à un appel d’offres hors chaîne, l’enchère pour remplir un ordre qui utilise les taxes MEV se produirait de manière atomique avec l’exécution de la transaction sur la chaîne. Cela signifie qu’un soumissionnaire gagnant pourrait avoir la garantie qu’il ne s’engage à remplir l’ordre que si sa transaction onchain réussit. Cela pourrait permettre à la liquidité onchain comme les AMM de rivaliser plus facilement avec la liquidité offchain, ce qui signifie qu’UniswapX pourrait servir de routeur encore plus efficace pour les systèmes multi-pools comme Uniswap v4.

AMMs Normalement, les AMMs

en haut du bloc, comme indiqué dans les documents loss-vs-rebalancing . Nous pouvons utiliser les 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 genre de problème pourrait être résolu avec une liquidité concentrée, Sorella publiera 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 négocier en premier dans le bloc. Il existe de nombreuses façons de calculer et de nommer ces frais. Nous discuterons de l’une d’entre elles, sans doute neutre, en la dénommant en unités de liquidité du pool, sqrt(xy). La transaction gagnante serait celle qui augmenterait 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’appliquer la condition x_end y_end > x_start y_start, le pool peut appliquer la condition (avec une constante comme constante) :

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

Cette formule inciterait le trader d’arbitrage à négocier au prix réel, et après cette transaction, le prix médian sur le pool devrait être le prix réel. 6

Après cette première transaction, les transactions pourraient fonctionner comme elles le font sur Uniswap v2, avec des frais de swap fixes. Les transactions non informées qui veulent négocier sur le pool sans payer une taxe MEV supplémentaire fixeraient des frais de priorité faibles.

Il existe de nombreuses autres façons de mettre en œuvre 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 du swap, pourraient affecter le pourcentage de frais de swap appliqué par le pool ou pourraient déterminer le prix minimum de la transaction de l’utilisateur. Nous pensons qu’il s’agit d’un espace de conception intéressant à explorer.

Enchères en cours d’exécution

Les descriptions ci-dessus montrent comment certaines applications peuvent être conçues pour éviter les fuites de MEV. Cependant, que se passe-t-il si un portefeuille veut 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’intègrent pas les taxes MEV

Par exemple, lorsqu’Alice effectue une transaction importante sur un AMM, elle crée parfois une opportunité d’arbitrage pour les « backrunners » afin de faire reculer le prix. Cela est normalement divulgué à MEV, plutôt que d’aller à Alice.

MEV-Share et MEVBlocker sont deux protocoles qui permettent aux utilisateurs de capturer MEV de leurs transactions, mais ils reposent sur un système complexe d’enchères offchain. L’espace de conception d’enchères Orderflow décrit d’autres solutions.

Les taxes MEV, lorsqu’elles sont combinées à un portefeuille de contrats intelligents basé sur l’intention, pourraient nous permettre de construire un système alternatif pour capturer les MEV en souffrance pour Alice. Supposons qu’au lieu de créer une transaction qui se négocie sur l’AMM, Alice signe une intention que n’importe qui peut soumettre au portefeuille de contrats intelligents d’Alice pour l’amener à effectuer cette action. Le portefeuille de contrats intelligents d’Alice facture à quiconque soumet cette transaction une taxe MEV, qui est payée à Alice.

Le chercheur qui soumet l’intention d’Alice aura le droit exclusif de la relancer, puisqu’il peut le faire atomiquement dans la même transaction. Par conséquent, si la recherche est concurrentielle, tous les bénéfices de la relance d’Alice devraient revenir à Alice par le biais de sa taxe MEV.

Notez que ce système ne protège pas nécessairement les utilisateurs contre les attaques qui impliquent des transactions d’utilisateur anticipées, car une transaction qui précède un utilisateur peut être en mesure d’éviter de payer une taxe MEV à cet utilisateur. Ce problème (et certaines mesures d’atténuation possibles) est abordé plus en détail dans la section Limitations ci-dessous. Néanmoins, cela pourrait au moins être une amélioration par rapport aux systèmes qui utilisent 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 enchère offchain ou néerlandaise, comme :

• Protocoles permettant aux oracles de capturer la valeur extractible de l’oracle qu’ils créent, comme Enchères
de refinancement ovale
• dans des protocoles de prêt garantis par NFT comme Blend
• Lending protocole liquidations qui fuite moins valeur supérieure à celle des ventes aux enchères néerlandaises

Capture de MEV inter-applications

Les solutions ci-dessus sont conçues pour capturer les MEV d’interaction avec une seule application. Mais parfois, il peut être possible pour un chercheur de capturer encore plus de valeur en interagissant avec plusieurs applications dans la même transaction.

Si une seule de ces applications a une taxe MEV, alors tout le MEV de la transaction devrait aller à l’application avec la taxe MEV, quel que soit le montant ou le bas de cette taxe MEV.

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

Dans ce cas, le montant relatif de l’excédent de MEV saisi par chaque demande est déterminé par la façon dont ces demandes établissent leurs taxes sur les MEV. Si la valeur que app_i facture en tant que taxe MEV est donnée par la fonction tax_i(priorité), 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 pour compte les frais de priorité payés au soumissionnaire en bloc, mais nous ne tiendrons pas compte de cela puisque, comme nous l’avons vu à l’annexe A, il sera probablement négligeable dans des conditions normales.)

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

a_1 priorityPerGas + a_2 priorityPerGas = MEV

priorityPerGas = MEV/(a_1 + a_2)

tax_1(prioritéPerGas) = (a_1/(a_1+a_2))*MEV

tax_2(prioritéPerGas) = (a_2/(a_1+a_2))*MEV

Lors de la définition de sa propre taxe MEV, une application est confrontée à un compromis : des taxes plus élevées lui permettent de capturer une plus grande part de MEV inter-applications lorsqu’elle se produit, mais signifient qu’elle pourrait manquer une partie de 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 sur chaque transaction, alors un ordre UniswapX de taxe MEV pourrait être plus susceptible d’être rempli par un AMM différent ou un remplissage offchain.

Dans de nombreux cas, il peut y avoir un équilibre dans lequel deux applications conçoivent leurs taxes MEV dans l’ordre pour partager MEV d’une manière qui maximise le bien-être de chacun. Par exemple, un AMM de taxe MEV voudrait probablement capturer la valeur d’un seul trader informé près du sommet du bloc, mais voudrait ensuite fournir des liquidités à d’autres traders et applications (y compris ceux qui utilisent des taxes MEV) avec des frais fixes peu élevés. Dans ce cas, l’AMM est susceptible de fixer une taxe MEV relativement faible (par exemple, 0,00001 $priorityFeePerGas), de sorte que la transaction d’arbitrage (le cas échéant) se produit tôt dans le bloc, puis ne facture 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 est déjà arbitré. Avec ces taxes relatives, le AMM finirait par être condamné en premier, même s’il n’y avait que 1 $ de MEV et 50 000 $ de MEV dans un ordre UniswapX.

Nous pensons qu’il s’agit d’un vaste espace de conception qui mérite d’être étudié à l’avenir.

Les limitations

MEV taxes présentent des complications et des inconvénients. Nous pensons que chacun d’entre eux est un domaine intéressant pour les recherches futures.

L’incompatibilité incitative

MEV les taxes ne sont pas compatibles avec les incitations pour un proposant de bloc monopolistique. Ils ne fonctionnent que s’il existe une concurrence loyale pour l’inclusion des transactions, ce qui ne peut se produire que si le proposant de blocs suit des règles que nous appellerons « ordre de priorité concurrentiel », plutôt que de maximiser ses propres revenus. De manière informelle et non exhaustive, nous suggérons que ces règles comprennent :

• Commande prioritaire. Les transactions au sein d’un bloc doivent être classées dans l’ordre décroissant de priorityFeePerGas.
• Résistance à la censure. Si le proposant de bloc reçoit une transaction t1 au cours du bloc, et que le bloc n’est pas plein ou comprend 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 par le biais d’un point de terminaison privé et ne doit pas partager ces transactions avec qui que ce soit d’autre avant de s’engager dans le bloc, ou utiliser le contenu de ces transactions comme entrée dans la construction de ses propres transactions.
• Pas de dernier regard. Le proposant de bloc doit définir un délai défini blockTime avant lequel il accepte les transactions de n’importe qui, et après quoi il n’accepte pas les transactions de quiconque.

Si une ou plusieurs de ces propriétés sont violées, cela peut affaiblir l’efficacité des taxes MEV. 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 de priorité zéro qui saisit l’opportunité pour elle-même. Un proposant de bloc qui viole la confidentialité avant la transaction pourrait voler des MEV d’autres transactions ou jeter un coup d’œil à leurs frais prioritaires pour savoir exactement combien il doit fixer les siens, tandis qu’un qui est capable de soumettre des transactions plus tard que quiconque aurait un « dernier regard » 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 de la protocol layer, l’application des autres propriétés sans confiance est un problème ouvert.

En l’absence d’application à la protocol layer, il faut faire confiance à un seul séquenceur qui s’engage à respecter ces règles pour ne pas s’en écarter, et si les proposants sous-traitent la construction de blocs à une enchère compétitive maximisant les revenus (comme 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 l’ordre de priorité concurrentiel pour la construction de blocs. Ils peuvent également être résolus à l’aide d’un mécanisme décentralisé utilisant une combinaison de consensus, de cryptographie et/ou d’environnements d’exécution fiables, tels que l’Angström de Sorella, le SUAVE de Flashbots, Leaderless Auctions, ou Multiplicité.

Blocs complets

Une exception au fonctionnement normal des taxes MEV se produit lorsque les blocs sont complètement pleins. Dans ce cas, les proposants de blocs devront peut-être laisser de côté les transactions moins prioritaires, plutôt que de simplement les inclure tard dans le bloc. Étant donné que les transactions qui interagissent avec les applications taxées MEV sont susceptibles d’avoir des frais de priorité extrêmement faibles, ces applications sont susceptibles d’être évincées par les applications qui n’utilisent pas les taxes MEV, ou celles qui ont des taxes MEV extrêmement faibles. Cependant, dans une chaîne qui utilise un mécanisme de type EIP-1559 pour fixer des frais de base distincts, 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 qui expriment une urgence moindre en fixant des taxes MEV plus élevées peut être un résultat raisonnable.

Les transactions MEV

taxes annulées reposent effectivement sur des enchères d’un seul bloc dans lesquelles chaque « offre » est une transaction. L’un des inconvénients de ces enchères est que les enchères perdantes entraîneront généralement l’inclusion de transactions annulées sur la chaîne, le paiement de certains frais de base et l’encombrement de la chaîne.

Si un séquenceur peut exclure complètement les transactions ayant échoué, cela atténuerait ce problème, bien que cela puisse être difficile à mettre en œuvre même avec un séquenceur centralisé. (Il n’obéirait pas non plus strictement à la propriété de censure-résistance décrite ci-dessus, bien que cette définition puisse être ajustée.) Un séquenceur plus sophistiqué peut être en mesure d’optimiser ce processus en permettant aux transactions de spécifier les enchères litigieuses auxquelles elles participent, ce qui donne au séquenceur suffisamment d’informations pour ignorer les transactions ultérieures dont il sait qu’elles échoueront.

La fuite des intentions de l’utilisateur

MEV des taxes ne fonctionne que s’il y a une concurrence entre les chercheurs, ce qui signifie que l’opportunité doit être assez largement connue. Pour des applications telles que les AMM, où l’opportunité est visible sur la chaîne, cela devrait se faire naturellement. Mais pour les applications telles que le routage basé sur l’intention ou les enchères en cours d’exécution, cela signifie que l’application peut avoir besoin de partager l’intention de l’utilisateur avec les chercheurs.

Dans certains cas, la confidentialité temporaire perdue par la diffusion de l’intention de l’utilisateur avant qu’elle ne soit remplie peut perdre de la valeur d’une manière qui ne peut pas être récupérée par une taxe MEV.

Par exemple, supposons qu’Alice souhaite acheter un jeton à faible liquidité à l’aide du protocole d’enchères en attente décrit ci-dessus. Elle publie une intention signée pour son portefeuille de contrat intelligent d’acheter ce jeton sur un AMM, définissant une certaine tolérance de glissement. Les chercheurs pourraient faire la course pour pousser le prix de ce jeton à sa tolérance de glissement dans une transaction hautement prioritaire, sans remplir l’ordre de l’utilisateur. Le gagnant, Bob, pourrait alors remplir l’intention non concurrentielle d’Alice en l’incluant et en la relançant dans une transaction de faible priorité, prenant ainsi en sandwich le commerce d’Alice et lui donnant un prix pire tout en éludant sa taxe MEV. Un problème similaire pourrait se produire avec les achats de NFT.

Notez qu’une telle attaque serait risquée pour Bob, puisqu’il ne serait pas en mesure de garantir l’atomicité entre l’achat du jeton et sa vente à Alice. Un Bob naïf pourrait être victime d’une chute d’un piège dans lequel Alice publie son intention d’acheter un jeton sans valeur à elle-même, ce qui amène Bob à l’acheter en prévision de son commerce, mais Alice révoque son intention avant que Bob ne soit en mesure de terminer le sandwich.

Les applications peuvent également être en mesure d’atténuer ce problème 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 d’ordres existantes.

Il peut également être possible de combiner MEV taxes avec des fonctionnalités de construction respectueuses de la vie privée, comme celles envisagées dans les conceptions de Flashbots pour SUAVE.

Enfin, dans les cas où Alice décide que les coûts de partage de son intention l’emportent sur les avantages de la recherche concurrentielle, elle pourrait construire elle-même une transaction et la soumettre directement dans le bloc. Comme nous l’avons vu plus haut, une mise en œuvre idéale de l’ordre prioritaire concurrentiel assurerait la confidentialité de l’auteur de la proposition de bloc avant la transaction.

Discussion et travaux antérieurs

Priorité gas enchères. Une partie de la dynamique de l’ordre des priorités dans les blockchains décentralisées a été étudiée dans l’article Flash Boys 2.0, qui a inventé le terme « valeur extractible du mineur ». Ce document 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 s’appuyaient sur ce comportement pour participer à des « enchères de gaz prioritaires » dans lesquelles ils soumissionnaient pour le droit d’être inclus en premier dans un bloc, ce qui a conduit à une grande partie du MEV de l’arbitrage de plateforme d’échange décentralisée revenant aux mineurs.

Premier arrivé, premier servi. Certaines tentatives d’atténuation de MEV par le biais de règles d’ordre des transactions, telles que Themis ou Arbitrum One’s current sequencer,7 se sont concentrées sur l’application d’une règle d’ordre différente, premier arrivé, premier servi (parfois appelée « ordre équitable ») où les proposants de blocs doivent ordre transactions dans l’ordre dans lequel ils les voient.

L’ordre prioritaire adopte une approche différente : traiter les transactions qui arrivent dans un délai donné de la même manière et les classer en fonction de leur priorité déclarée.

Le 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 sur les MEV peuvent être en mesure d’éliminer certains types de MEV que les commandes selon le principe du premier arrivé, premier servi ne peuvent pas éliminer, comme les bénéfices d’arbitrage provenant de « sauts » discontinus dans les prix des actifs. Les avantages potentiels de l’ordre prioritaire par rapport à l’ordre selon le principe du premier arrivé, premier servi sont quelque peu liés aux avantages de l’ordre en temps discret par rapport aux échanges en temps continu discutés dans Budish, Cramton, Shim (2015).

Pendant ce temps, alors que l’ordre de priorité semble perdre de la valeur vers MEV par défaut, cet article montre comment les applications peuvent être conçues pour la récupérer.

Partage des honoraires. Blast, un Ethereum L2, partage une partie des frais prioritaires et de base avec les smart contracts consultés dans une transaction.

Les taxes MEV permettent quelque chose de similaire (au moins pour les frais prioritaires), mais peuvent être mises en œuvre au niveau de la couche d’application sur n’importe quelle chaîne qui utilise la commande prioritaire concurrentielle, 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 de frais prioritaires, offrant plus de flexibilité et pouvant entraîner une plus grande composabilité des applications compatibles MEV.

Solutions Trustless. Cet article se concentre sur la motivation des plateformes à utiliser l’ordre de priorité concurrentiel – et sur les moyens de tirer parti des plateformes qui le font – plutôt que de discuter de la manière de l’appliquer sans confiance.

Il y a eu beaucoup de discussions préalables sur chacune des autres propriétés requises pour l’ordre prioritaire concurrentiel. 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 une conception pour une enchère résistante à la censure utilisant plusieurs proposants simultanés. Cependant, ils ne suggèrent pas d’ordre spécifique pour les transactions.

Il y a eu d’autres recherches sur la construction de mécanismes pour la construction de blocs minimisant la confiance, y compris SUAVE de Flashbots, Angström de Sorella, Leaderless Auctions, Espresso et Offchain Labs' @espressosys/espresso-systems-and-offchain-labs-release-r-d-roadmap-for-decentralized-timeboost-5d0007dff66d">Timeboost décentralisé, et inclusion des transactions publiques mandatée par Péter Szilági.

Conclusion

Nous espérons que cet article encouragera les L2 à envisager d’utiliser le tri prioritaire (tel qu’il est pris en charge par défaut dans la pile OP) et incitera les applications à essayer MEV taxes là où elles sont prises en charge.

Nous espérons également que cela motivera d’autres recherches sur les protocoles de commande prioritaire concurrentielle minimisée par la confiance sur les 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 sur des séquenceurs L2 résistants à < href="https://www.tldresear.ch/tldr/tldr-request-for-papers/mev-resistant-l2-sequencers">MEV avec Dan. Ou n’hésitez pas à contacter dan@paradigm.xyz et dave@paradigm.xyz avec des idées !

Notes de bas de

page
1. Dans cet article, 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 Ethereum L2s, 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 à laquelle participent les « relayeurs » et les « constructeurs ». Les détails de la répartition de ces responsabilités n’entrent pas dans le cadre de cet article. ↩
2. La redevance prioritaire par gas n’est pas spécifiée explicitement dans la transaction, mais peut y être calculée. 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 devraient être ignorés aux fins des taxes MEV, car ils ne sont pas sous le contrôle du transacteur. Les frais de priorité par gas (le prix de la partie des frais de transaction qui revient au proposant de bloc) peuvent être calculés dans Solidity comme priorityGasPrice = tx.gasprice - block.basefee. ↩
3. Alternativement, nous pourrions simplement définir « MEV » pour exclure tout profit du chercheur et ne faire référence qu’à la valeur qui irait au validateur. ↩
4. Notez que proposerPriorityFee, égal à priorityFeePerGas multiplié par le total de gas utilisé dans la transaction, ne peut pas être calculé pendant le contrat, car il n’y a aucun moyen de savoir combien de gas la transaction finira par utiliser. Cependant, cela n’aura généralement pas d’importance, car tout ce dont nous avons besoin est une limite supérieure pour cela. Pour être sûr, vous pouvez multiplier priorityFeePerGas par 30 millions, le gas maximal actuel dans un bloc Ethereum. La surestimation de cette valeur signifie simplement que la taxe sur les MEV capture un pourcentage encore plus élevé de MEV. ↩
5. En supposant qu’une transaction ne puisse pas dépasser 30 millions de gas, un priorityFeePerGas de 50 000 entraînerait un paiement de gas de 1500 gwei, soit environ 0,006 $ à un prix ETH de 4000 $. ↩
6. Dans le cas où priorityFeePerGas est défini de manière à ce que le profit de l’arbitrageur soit nul, la transaction d’arbitrage maximisant les profits doit correspondre à la même transaction sur la AMM maximisant la fonction. Prouver cela est laissé à l’appréciation du lecteur. ↩
7. Arbitrum a a discuté de le remplacer par une forme d’ordre de priorité appelée Timeboost, mais cela n’a pas été mis en production au moment d’écrire ces lignes. ↩

paradigme]. Tous les droits d’auteur appartiennent à l’auteur original [Dan Robinson & Dave White]. S’il y a des objections à cette réimpression, veuillez contacter l’équipe Gate Learn, et ils la traiteront rapidement.

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

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.