Paradigm introduce un nouveau mécanisme de taxe MEV qui changera le paysage actuel de la DeFi

Ce texte provient de “Priority Is All You Need”

Auteur original: Dan Robinson, Dave White

Compilation: Odaily Planet Daily How to Husband

Le 4 juin, Paradigm a publié un article intitulé « La priorité est tout ce dont vous avez besoin », dans lequel nous avons détaillé la nouvelle taxe MEV.

La taxe MEV est un mécanisme novateur qui permet aux applications de capturer leur propre MEV généré, au lieu de le divulguer aux proposeurs de blocs (voir les notes de bas de page à la fin de l’article pour plus d’informations sur les proposeurs de blocs). Ce mécanisme tire parti du processus concurrentiel de priorisation lors de la construction des blocs. Dans ce mode de priorisation, les transactions sont classées par ordre décroissant en fonction des frais de priorité, et les transactions à haute priorité sont traitées en priorité dans les blocs. La taxe MEV est mise en œuvre en ajoutant des frais supplémentaires aux frais de priorité des transactions. Les applications peuvent définir leurs propres frais en fonction des frais de priorité des transactions afin de capturer la plupart, voire la totalité, du MEV. Cela signifie que les applications peuvent exécuter leurs propres enchères MEV personnalisées sans avoir besoin d’infrastructures externes, en participant à une seule enchère partagée gérée par les proposeurs de blocs.

La naissance du mécanisme fiscal MEV pourrait avoir un impact sur l’écosystème DeFi existant :

• Changer la façon dont la valeur d’extrémité maximale (MEV) est traditionnellement répartie : traditionnellement, la plupart de la MEV est allouée aux proposeurs de blocs, tandis que la taxe MEV permet aux applications de capturer cette valeur et de la redistribuer à leurs utilisateurs ou de l’utiliser à d’autres fins.
• Améliore les revenus et l’expérience utilisateur de l’application : Les applications peuvent augmenter leurs revenus en mettant en œuvre une taxe MEV, tout en offrant une meilleure expérience utilisateur, car les utilisateurs peuvent bénéficier d’une efficacité d’exécution des transactions plus élevée et de meilleurs prix de transaction.
• Résout certains problèmes dans DeFi: tels que l’optimisation de l’itinéraire DEX, la réduction des pertes d’arbitrage AMM, la réduction de la fuite de MEV des utilisateurs de portefeuille, etc. En introduisant une taxe MEV, les applications peuvent améliorer leurs produits et services, améliorant ainsi l’efficacité et la durabilité de l’écosystème DeFi.

Citation

Dans cet article, nous avons présenté la taxe MEV, un mécanisme qui permet à n’importe quelle application de capturer sa propre MEV (valeur extractible maximale).

Ce mécanisme peut être utilisé immédiatement sur les chaînes L2 de la pile OP (comme OP Mainnet, Base et Blast) car les proposants de blocs sur ces chaînes suivent un ensemble de règles que nous appelons ordre de priorité concurrentielle.

Pour implémenter une taxe MEV sur ces chaînes, un contrat intelligent collecte des frais en fonction des frais de priorité de la transaction. Nous montrons que si une application prélève une taxe MEV de 99 $ sur une transaction pour chaque dollar de frais de priorité payé par le chercheur, elle peut capturer 99% de la MEV compétitive de cette transaction.

La taxe MEV est une technologie simple qui ouvre un vaste espace de conception. Vous pouvez le considérer comme permettant à n’importe quelle application de la chaîne de lancer sa propre vente aux enchères MEV personnalisée, sans avoir besoin de son infrastructure hors chaîne, simplement en se connectant à une vente aux enchères partagée gérée par les proposants de blocs.

Nous avons montré comment la taxe MEV résout trois problèmes majeurs dans la recherche sur le MEV :

Optimiseur du routeur DEX de la plateforme d’échange décentralisée (DEX) pour les prix reçus par les échangeurs

Les pertes subies par les fournisseurs de liquidité en raison de la rééquilibrage automatique (LVR) des AMM

Permettre aux utilisateurs de capturer tout MEV de “retour” généré par leur portefeuille d’échange

Mais il y a un problème. La taxe MEV ne fonctionne que si les proposants de bloc respectent strictement les règles de priorité de concurrence, notamment en triant les transactions par frais de priorité sans examen, espionnage ou retard. Si les proposants de bloc s’écartent de ces règles, ils peuvent contourner la taxe MEV pour capturer de la valeur. Ainsi, la taxe MEV d’aujourd’hui dépend de la confiance dans les séquenceurs L2 et peut ne pas fonctionner du tout sur Ethereum L1 car sur le réseau principal d’Ethereum, la construction de blocs est principalement dominée par des enchères de constructeurs compétitifs, maximisant ainsi les revenus des proposants.

Cependant, la capacité et la flexibilité de la taxe MEV indiquent que l’ordre de priorité peut être un choix judicieux pour les plateformes actuellement capables de fournir des commandes prioritaires. La simplicité relative de la compétition pour l’ordre de priorité indique qu’il pourrait exister une méthode viable pour appliquer de manière décentralisée sans faire confiance à un seul séquenceur. Nous espérons que cet article inspirera des recherches plus approfondies sur cette question.

Tri prioritaire

Lorsque quelqu’un envoie une transaction sur le réseau principal ou L2 d’Ethereum, il spécifie des frais prioritaires qui sont payés aux proposants de blocs. Vous pouvez le voir comme étant spécifié par priorityFeePerGas, ce nombre multiplié par le gas utilisé dans la transaction donne builderPriorityFee, c’est-à-dire le montant total payé en ETH.

Dans le protocole Ethereum, il n’est pas spécifié que les transactions dans un bloc doivent être triées de manière cupide selon priorityFeePerGas. Cependant, c’est une méthode populaire pour construire un bloc. Par exemple, c’est l’algorithme par défaut utilisé par le sérialiseur OP Stack et par geth et reth. Le tri prioritaire permet non seulement aux traders d’exprimer efficacement l’urgence de leurs transactions, mais dirige également naturellement certaines formes de MEV vers les proposants de blocs.

Cette situation se produit car le tri prioritaire transforme la concurrence pour le MEV en une vente aux enchères de gaz prioritaire. Lorsqu’il y a une opportunité de réaliser des profits en interagissant avec la chaîne, par exemple en arbitrant entre les AMM et les plateformes d’échange centralisées, le chercheur va rivaliser pour être le premier à saisir cette opportunité. Si la chaîne utilise un tri prioritaire pour décider de l’emballage et du tri des transactions, le chercheur va rivaliser en fixant des frais de priorité élevés dans ses transactions.

Dans un scénario de concurrence où les bénéfices sans risque sont comprimés à zéro, le chercheur gagnant devrait finalement payer intégralement le MEV comme frais prioritaire. Ainsi, si un profit de 100 ETH peut être réalisé en interagissant avec le contrat, la première transaction qui saisit l’opportunité fixera des frais prioritaires de 100 ETH. (Nous discutons de certaines considérations à ce sujet dans la section “Limitation”).

Taxe MEV

Supposons que les smart contracts veuillent capturer tout MEV impliqué dans les transactions avec lesquelles ils interagissent. Il existe une abondance de littérature sur les différentes façons spécifiques dont les smart contracts tentent de capturer leur propre MEV.

Mais en réalité, nous n’avons pas nécessairement besoin de connaître les détails spécifiques de l’application. Si nous savons que les blocs sont construits en utilisant un ordre de priorité concurrentielle, alors nous avons un signal unifié pour représenter la quantité de MEV dans les transactions : les frais de priorité.

Nous suggérons que les smart contracts puissent afficher les frais de priorité pour une transaction et facturer leurs propres frais en fonction de ceux-ci, ce qui est une fonction incrémentielle des frais de priorité. Par exemple, un contrat peut exiger que la personne qui l’appelle transfère des ETH vers le contrat applicationPriorityFee = 99 * proposerPriorityFee.

Ce nouveau frais est payé par le chercheur qui envoie la transaction, ce qui affecte son comportement. Si une opportunité a une MEV de 100 ETH, la transaction gagnante ne définira désormais qu’un frais prioritaire de 1 ETH, car cela entraînerait un total de paiement de 100 ETH (1 ETH pour le proposant du bloc, 99 ETH pour les smart contracts). Tout frais prioritaire plus élevé rendra la transaction non rentable ; tout frais prioritaire plus bas entraînera la perte de l’opportunité au profit d’un concurrent proposant des frais plus élevés. Cela signifie que les smart contracts capturent 99 % de la MEV dans la transaction.

Nous appelons cette taxe supplémentaire imposée par les contrats intelligents la taxe MEV. La taxe MEV permet aux applications de s’approprier la priorisation des transactions pour leur propre intérêt, leur permettant de capturer à nouveau la valeur d’extraction de la valeur de l’utilisateur plutôt que de la laisser échapper aux proposants de blocs.

Si le priorityFeePerGas augmente assez rapidement, seule une quantité négligeable de MEV s’accumulera chez le proposant. Comme le priorityFeePerGas est évalué en wei (un milliardième d’ETH), nous disposons de beaucoup de précision à utiliser. Par exemple, tant que la sensibilité à la taxe MEV est suffisamment élevée, de sorte que le priorityFeePerGas de 50 000 entraîne une taxe élevée, le montant total payé au proposant sera inférieur à 0,01 $.

Cependant, il y a une remarque importante. Comme discuté dans la section “Restrictions”, la taxe MEV n’est efficace que si les proposants de blocs suivent certaines règles (que nous appelons “ordre de priorité de la concurrence”) plutôt que de s’en écarter pour maximiser leurs revenus. Faire respecter ces règles de manière décentralisée est une question en suspens.

Capture de la valeur des extractions de la mémoire vive (MEV) d’une application unique

Sur une chaîne hors chaîne construite avec garantie de priorisation de la concurrence, la taxe MEV peut être utilisée pour atténuer les trois principaux problèmes du MEV : améliorer l’exécution des échanges pour les interfaces DEX ; réduire les pertes d’arbitrage des LP pour les AMM ; et réduire les fuites de MEV des utilisateurs par la vente de leurs droits de rejeu par les portefeuilles.

Rechercheur de routeur DEX

Dans les protocoles de routage DEX basés sur l’intention (comme UniswapX et 1inch Fusion), les utilisateurs (Alice) signent une intention d’échange, et les chercheurs rivalisent pour router ou remplir cette intention au meilleur prix.

La version actuelle d’UniswapX utilise deux mécanismes pour faire fonctionner cette compétition : une enchère hollandaise où le prix limite d’Alice change avec le temps jusqu’à ce qu’il soit rempli par le chercheur, ainsi qu’une enchère initiale de demande de devis hors chaîne (RFQ) pour fixer le prix de départ de cette enchère hollandaise.

Sur une plateforme qui garantit le classement prioritaire des concurrents, UniswapX peut utiliser un mécanisme pour cela : la taxe MEV. Cela peut être réalisé en permettant aux utilisateurs de signer une commande qui peut être remplie immédiatement par n’importe qui, mais le prix d’exécution est fonction des frais de priorité de transaction.

Par exemple, si Alice a un ordre de vente de 1 ETH sur UniswapX, elle peut définir le prix d’exécution de l’ordre comme minimumPrice + ($ 0.01 * priorityFeePerGas).minimumPrice peut être une valeur fixe qu’elle prévoit être nettement inférieure au prix actuel.

Le chercheur compétitionnera pour remplir les commandes d’Alice en soumettant des transactions. Toute transaction avec des frais de priorité les plus élevés et non remboursables remplira la commande, ce qui devrait garantir aux commerçants le meilleur prix que le chercheur peut trouver. (Certains cas exceptionnels sont discutés dans la section “Restrictions”).

Si le prix minimum d’Alice est de 3 000 dollars et que le prix actuel de l’ETH est de 3 500 dollars, le priorityFeePerGas dans la transaction gagnante est d’environ 50 000. (Notez que dans une transaction de 200 000 gas, cela entraînerait le paiement d’environ 10 milliards de wei (environ 0,000035 dollars) uniquement au proposant de bloc).

Cela présente quelques avantages potentiels par rapport au mécanisme existant utilisé dans UniswapX.

Les commandes utilisant la taxe MEV peuvent être exécutées plus rapidement et à des prix plus avantageux que les commandes utilisant des enchères hollandaises. Comme indiqué dans cet article, les enchères hollandaises sur chaîne peuvent divulguer de la valeur à MEV en raison des variations de prix entre les blocs et peuvent nécessiter plusieurs blocs pour être complétées. En revanche, les commandes utilisant la taxe MEV peuvent généralement être complétées dans le bloc suivant, capturant ainsi la majeure partie de leur MEV.

Contrairement au RFQ hors chaîne, les enchères utilisant la taxe MEV pour remplir les commandes seront exécutées de manière atomique lors des transactions sur chaîne. Cela signifie que le soumissionnaire gagnant peut garantir que la commande ne sera remplie que si sa transaction sur chaîne réussit. Cela peut faciliter la concurrence entre la liquidité sur chaîne (comme les AMM) et la liquidité hors chaîne, ce qui signifie que UniswapX peut fonctionner comme un routeur plus efficace pour les systèmes multi-pools (comme Uniswap v4).

Fournisseur de liquidité automatique (AMM)

Généralement, les AMM perdent de la valeur en raison des transactions effectuées par les arbitrageurs au sommet du bloc à des prix obsolètes, comme discuté dans le document “perte-vs-rééquilibrage”. Nous pouvons utiliser une taxe MEV pour que les AMM capturent ces MEV. Pour simplifier, nous discuterons de la façon de le faire sur une AMM sans liquidité centralisée. (Si vous êtes intéressé par la résolution de ce problème dans le cas de liquidités centralisées, Sorella publiera bientôt une solution.)

AMM peut capturer MEV en facturant des frais supplémentaires en fonction des frais de priorité de transaction, ce qui lui permet de mettre aux enchères le droit de priorité des transactions dans un bloc. Il existe de nombreuses méthodes pour calculer et évaluer ces frais. Nous discuterons d’une méthode neutre, qui est l’unité de liquidité de pool sqrt(xy). Les transactions gagnantes seront celles qui augmentent le plus la liquidité du pool.

Lors de la première transaction sur un pool dans un bloc, si x_end * y_end > x_start * y_start, le pool peut forcer l’exécution des conditions (en tant que constantes a).

x_end * y_end > (sqrt(x_start * y_start) + a*priorityFeePerGas)^ 2 Cette formule encourage les arbitragistes à négocier au prix réel, après cette transaction, le prix médian du pool devrait être le prix réel.

Après cette première transaction, les transactions peuvent fonctionner comme sur Uniswap v2, avec des frais d’échange fixes. Les utilisateurs qui souhaitent effectuer des transactions sans payer de taxe MEV supplémentaire définiront des frais de priorité plus bas.

Il existe de nombreuses autres méthodes de taxation MEV mises en œuvre sur l’AMM, qui produisent des effets différents. Par exemple, la taxe MEV peut être exprimée en jetons d’entrée ou de sortie d’échange, peut affecter le pourcentage des frais d’échange de l’application de pool, ou peut déterminer le prix minimum des transactions des utilisateurs. Nous pensons que c’est un espace de conception intéressant qui mérite d’être exploré.

尾随拍卖（Backrunning auctions）

La description ci-dessus montre comment concevoir certaines applications pour éviter les MEV. Cependant, que faire si un portefeuille souhaite aider ses utilisateurs à capturer les MEV générés lorsqu’ils interagissent avec n’importe quelle application via des transactions arbitraires, même si ces applications ne sont pas soumises à une taxe MEV ?

Par exemple, lorsque Alice effectue une transaction importante sur AMM, elle crée parfois une opportunité d’arbitrage pour les “backrunners” afin de ramener les prix à la normale. Habituellement, ces opportunités sont divulguées à la MEV plutôt que de revenir à Alice.

MEV-Share et MEVBlocker sont deux protocoles permettant aux utilisateurs de capturer MEV à partir de leurs transactions, mais ils dépendent d’un système d’enchères hors-chaîne complexe. “The Orderflow Auction Design Space” décrit quelques autres solutions.

Lorsque la taxe MEV est associée à un portefeuille de contrats intelligents basé sur l’intention, nous pouvons construire un système de remplacement pour capturer les MEV en retard d’Alice. Supposons qu’Alice n’ait pas créé de transaction sur l’AMM, mais a plutôt signé une intention que n’importe qui peut soumettre au portefeuille de contrats intelligents d’Alice pour exécution. Le portefeuille de contrats intelligents d’Alice facture une taxe MEV à la personne soumettant la transaction, qui sera payée à Alice.

Le chercheur qui soumet l’intention d’Alice a le droit exclusif de la suivre car ils peuvent effectuer cette opération atomiquement dans la même transaction. Par conséquent, si la concurrence pour la recherche est intense, tous les bénéfices provenant de la suite d’Alice doivent être attribués à Alice par le biais de sa taxe MEV.

Il convient de noter que ce système ne peut pas nécessairement protéger complètement les utilisateurs contre les attaques de front running, car celles-ci peuvent contourner la taxe MEV payée aux utilisateurs. Ce problème (et certaines mesures d’atténuation possibles) seront discutés en détail dans la section “Limitations” ci-dessous. Cependant, cela représente au moins une amélioration par rapport aux systèmes de pool de mémoire publics sans aucune mesure d’atténuation.

Autres cas d’utilisation

Outre ces exemples, d’autres utilisations potentielles de la taxe MEV comprennent pratiquement tous les scénarios actuellement utilisant des mécanismes hors-chaîne ou des ventes aux enchères hollandaises, tels que :

Les protocoles tels qu’Oval peuvent extraire de la valeur (OEV) en capturant les oracles qu’ils créent.

• Dans une enchère de refinancement dans un protocole de prêt NFT comme Blend.
• La liquidation du protocole de prêt est moins précieuse que la valeur divulguée lors d’une vente aux enchères aux Pays-Bas.

Capture de MEV entre applications

Les solutions mentionnées ci-dessus visent à capturer les MEV générés lors de l’interaction avec une seule application. Cependant, parfois, le chercheur peut capturer une valeur supplémentaire en interagissant avec plusieurs applications dans la même transaction.

Si seulement une de ces applications utilise la taxe MEV, alors tout le MEV provenant des transactions devrait être attribué à l’application utilisant la taxe MEV, quel que soit le montant de la taxe MEV.

Mais que se passe-t-il si la transaction du chercheur interagit avec deux applications qui utilisent des taxes MEV ? Par exemple, si certaines taxes MEV ne peuvent être capturées qu’en remplissant une commande UniswapX avec une taxe MEV pour contrer une AMM avec une taxe MEV.

Dans ce cas, la quantité relative de MEV excédentaire capturée par chaque application est déterminée par la taxe MEV fixée par ces applications. Si la valeur de app_i en tant que taxe MEV est donnée par la fonction tax_i(priority), alors la priorité des transactions gagnantes peut être déterminée en résolvant l’équation suivante : tax_1(priorityPerGas) + tax_2(priorityPerGas) = MEV total.

(Techniquement, nous pourrions ajouter un troisième terme priorityPerGas * gasUsed pour expliquer les frais de priorité payés au proposant de bloc, mais nous allons ignorer ce point, car comme discuté dans l’annexe A, dans des circonstances normales, les frais de priorité pourraient être négligeables.)

Dans le cas simple de la taxe MEV linéaire dans priorityPerGas (donc taxe_1(priorityPerGas) = a_1 * priorityPerGas), vous pouvez calculer la part de MEV reçue par chaque application :

a_ 1 * priorityPerGas + a_ 2 * priorityPerGas = MEV

priorityPerGas = MEV/(a_ 1 + a_ 2)

taxe_ 1(priorityPerGas) =(a_ 1/(a_ 1+a_ 2))*MEV

tax_ 2(priorityPerGas) = (a_ 2/(a_ 1+a_ 2))*MEV

Lors de la configuration de sa propre taxe MEV, l’application est confrontée à un compromis - un taux plus élevé lui permet de capturer une part plus importante de MEV inter-applications lorsqu’il se produit, mais cela signifie qu’elle pourrait manquer certains MEV inter-applications en cas de méthodes d’extraction concurrentes. Par exemple, s’il y a un AMM qui facture une taxe MEV pour chaque transaction, alors une commande UniswapX avec une taxe MEV pourrait être remplie par un AMM différent ou hors chaîne.

Dans de nombreux cas, il peut exister un équilibre dans lequel deux applications conçoivent leur taxe MEV de manière à partager d’une certaine manière le MEV, afin de maximiser leur propre bénéfice. Par exemple, une AMM avec une taxe MEV pourrait souhaiter obtenir de la valeur auprès d’un seul trader informé près du sommet du bloc, mais souhaiter ensuite fournir de la liquidité à d’autres traders et applications (y compris ceux utilisant la taxe MEV) à un coût fixe inférieur. Dans ce cas, l’AMM pourrait fixer une taxe MEV relativement basse (par exemple, $0.00001 * priorityFeePerGas) afin que les opérations d’arbitrage (le cas échéant) se produisent tôt dans le bloc, puis ne facture pas de taxe MEV pour les transactions ultérieures dans le bloc. Des applications telles que UniswapX, qui souhaitent interagir avec l’AMM, pourraient fixer une taxe MEV plus élevée (par exemple, $0.01 * priorityFeePerGas) pour s’assurer que leurs transactions sont incluses après que le pool ait été arbitrée. Avec ces taxes relatives, même si les ordres d’UniswapX ne contiennent que 1 dollar de MEV ou 50 000 dollars de MEV, l’AMM sera finalement arbitrée en premier.

Nous pensons que c’est un espace de conception vaste qui mérite d’être exploré dans le futur.

Limitations

La taxe MEV présente certaines complexités et défauts. Nous pensons que ce sont des domaines intéressants pour la recherche future.

Incompatibilité des incitations

La taxe MEV est incompatible avec l’incitation pour les proposants de blocs monopolistiques. Elle ne fonctionne que dans le cadre d’une concurrence équitable dans les transactions, ce qui se produit uniquement lorsque les proposants de blocs suivent ce que nous appelons des règles de priorité compétitive, plutôt que de maximiser leurs propres revenus. Nous suggérons que ces règles devraient inclure :

• Priorité de tri: Les transactions dans un bloc doivent être triées en ordre décroissant de priorityFeePerGas.
• Résistance à la censure : si le proposant de bloc reçoit la transaction t 1 lors de la construction d’un bloc, et que le bloc n’est pas plein ou contient la transaction t 2 , et que t 2.priorityFeePerGas < t 1.priorityFeePerGas, alors le bloc doit inclure la transaction t 1 .
• Avant la transaction, la confidentialité : les proposeurs de blocs doivent accepter les transactions via des points de terminaison privés et ne doivent pas partager ces transactions avec quiconque avant de soumettre le bloc, ni utiliser le contenu de ces transactions pour construire leurs propres transactions.
• Pas de timing final défini. Les proposants de bloc doivent définir un temps (blockTime) clair, avant lequel ils acceptent les transactions de quiconque, et après lequel ils n’acceptent plus aucune transaction.

Si l’un ou le plus long de ces attributs est violé, cela peut affaiblir l’efficacité de la taxe MEV. Les proposants de blocs qui enfreignent la censure peuvent contourner les taxes MEV les plus longues en excluant les transactions concurrentes et en soumettant une transaction à priorité zéro, gagnant ainsi des opportunités pour eux-mêmes. Un proposant de blocs qui viole la confidentialité avant négociation peut voler le MEV d’autres transactions, ou jeter un coup d’œil à leurs frais prioritaires, sachant qu’il doit fixer des frais de priorité élevée longues pour surpasser les autres, tandis qu’un proposant qui est en mesure de soumettre un accord plus tard que les autres est libre de « finaliser » s’il doit ou non surenchérir sur les autres, créant ainsi un problème de sélection adverse qui inhibe finalement la concurrence.

Malheureusement, bien que la première propriété soit facile à appliquer au niveau du protocole, l’application des autres propriétés de manière non fiable reste un problème en suspens.

En l’absence d’application coercitive au niveau du protocole, il est nécessaire de faire confiance à un séquenceur qui s’engage à respecter ces règles, sinon les blocs pourraient ne pas les suivre s’ils sont soumis à un processus d’enchères compétitif visant à maximiser les revenus (comme le MEV-Boost sur la chaîne principale d’Ethereum).

Ces problèmes peuvent être “résolus” en utilisant un seul ordonnanceur de confiance qui construit des blocs en utilisant un ordre de priorité compétitif, ou en utilisant une combinaison de consensus, de cryptographie et/ou d’environnement d’exécution de confiance pour résoudre le mécanisme décentralisé, tel que Angstrom de Sorella, SUAVE de Flashbots, Leaderless Auctions ou Multiplicity.

Bloc complet

Lorsque le bloc est complètement rempli, le fonctionnement normal de la taxe MEV peut être exceptionnel. Dans ce cas, le proposant de bloc peut être obligé d’exclure les transactions à faible priorité plutôt que de les inclure simplement à l’arrière du bloc. Étant donné que les transactions qui interagissent avec les applications utilisant la taxe MEV ont probablement des frais de priorité très bas, ces applications peuvent être évincées par des applications qui n’utilisent pas la taxe MEV ou qui utilisent une taxe MEV très faible. Cependant, sur la chaîne qui utilise un mécanisme similaire à EIP-1559 pour définir des frais de base distincts, la situation de blocage complet devrait être assez rare. De plus, étant donné que certains échanges doivent être retardés lorsque le bloc est plein, il peut être raisonnable de retarder les transactions qui expriment une urgence moindre en définissant une taxe MEV plus élevée.

Rollback de la transaction

La taxe MEV dépend essentiellement des enchères à un seul bloc, où chaque “offre” est une transaction. Un inconvénient de ce type d’enchère est que les offres non réussies entraînent généralement le rollback des transactions incluses hors-chaîne, ce qui entraîne le paiement de certains frais de base et la congestion de la chaîne.

Si le séquenceur peut exclure complètement les transactions échouées, cela atténuera ce problème, même s’il est difficile à réaliser même avec un séquenceur centralisé. (Cela ne respecte pas complètement les propriétés de résistance à la censure décrites ci-dessus, bien que cette définition puisse être ajustée.) Un séquenceur plus complexe pourrait optimiser ce processus en permettant aux transactions de spécifier les enchères litigieuses auxquelles elles participent, permettant ainsi au séquenceur de sauter les transactions ultérieures qu’il sait qu’elles échoueront.

Divulgation de l’intention de l’utilisateur

La taxe MEV n’est effective que lorsqu’il y a une concurrence entre les chercheurs, ce qui signifie que les opportunités doivent être largement connues dans une certaine mesure. Pour des applications telles que les AMM, les opportunités sont visibles hors chaîne, ce qui devrait se produire naturellement. Cependant, pour des applications telles que le routage basé sur l’intention ou les enchères à la traîne, cela signifie que l’application peut avoir besoin de partager l’intention de l’utilisateur avec les chercheurs.

Dans certains cas, la divulgation temporaire de la vie privée avant la réalisation de l’intention de l’utilisateur peut entraîner une perte de valeur de la taxe MEV qui ne peut être récupérée.

Par exemple, supposons qu’Alice souhaite acheter des jetons de liquidité faible en utilisant le protocole d’enchères décalées mentionné ci-dessus. Elle a publié une intention de signature dans son portefeuille de contrats intelligents pour acheter ce jeton sur l’AMM et a défini une limite de slippage. Le chercheur peut faire monter le prix de ce jeton dans des transactions à haute priorité jusqu’à la limite de slippage d’Alice, sans avoir à remplir la commande de l’utilisateur. Ensuite, le gagnant, Bob, peut satisfaire l’intention d’Alice de manière non concurrentielle en incluant et en reprenant l’intention d’Alice dans des transactions à basse priorité, se glissant ainsi dans la transaction d’Alice et lui offrant un prix encore plus mauvais, tout en évitant sa taxe MEV. Des problèmes similaires peuvent survenir lors de l’achat de jetons non fongibles (NFT).

Veuillez noter que cette attaque présente un risque pour Bob, car il ne peut pas garantir l’atomicité entre l’achat et la vente de jetons à Alice. Bob, naïf, pourrait être victime d’un piège appelé “déchirure de sandwich”, dans lequel Alice publie une intention d’acheter un jeton sans valeur de sa part, incitant Bob à l’acheter dans l’espoir de s’insérer dans ses transactions, mais Alice révoque son intention avant que Bob ne puisse terminer le sandwich.

L’application peut également atténuer cette situation en limitant l’ensemble des chercheurs partageant son intention et en surveillant leur comportement, tout comme de nombreuses enchères de flux de commandes existantes.

MEV 税也可以与具有隐私意识的构建者功能相结合，例如 Flashbots 的 SUAVE 设计中设想的功能。

Enfin, si Alice estime que le coût de partager son intention est supérieur aux avantages de la recherche concurrentielle, elle peut construire elle-même une transaction et la soumettre directement à un bloc. Comme mentionné ci-dessus, une mise en œuvre idéale de la priorité concurrentielle de classement fournira la confidentialité des transactions des proposants de blocs.

Discussion and preliminary work

Enchères de gaz prioritaires. Le document “Flash Boys 2.0” étudie la dynamique du classement des priorités dans les blockchains décentralisées et introduit le concept de “valeur extractible par les mineurs”. Le document observe que les mineurs d’Ethereum (lorsque le réseau utilise la preuve de travail) ont déjà classé les transactions par priorité, et les arbitragistes se basent sur ce comportement pour participer aux “enchères de gaz prioritaires” où ils font des offres pour avoir le privilège d’être inclus en priorité dans les blocs, ce qui entraîne une accumulation de la majorité des MEV provenant de l’arbitrage sur les plateformes d’échange décentralisées sur les mineurs.

Premier arrivé, premier servi. Pour atténuer certaines tentatives de MEV, qui visent à mettre en œuvre différentes règles de tri (comme Themis ou le séquenceur actuel d’Arbitrum One), il est préférable de se concentrer sur le tri équitable, où les proposants de blocs doivent trier les transactions dans l’ordre où ils les voient.

La priorité de tri utilise des méthodes différentes - traiter de manière égale les transactions arrivées pendant une période donnée et les trier selon leur priorité déclarée.

« L’ordre équitable » est difficile à appliquer ou même à définir dans un environnement réseau réel avec les validateurs les plus longs. 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 MEV « premier arrivé, premier servi », tels que les bénéfices d’arbitrage où les prix des actifs ne « bondissent » pas consécutivement. Les avantages potentiels de la préférence par rapport à la commande selon le principe du premier arrivé, premier servi sont en partie liés aux avantages du temps discret par rapport à la plateforme d’échange en temps continu discutés dans Budish, Cramton, Shim (2015).

En même temps, bien que le tri prioritaire semble par défaut révéler de la valeur à MEV, cet article montre comment concevoir une application pour la recapturer.

Répartition des frais. Blast est un L2 Ethereum, partageant une partie des priorités et des frais de base des contrats intelligents accessibles dans les transactions.

MEV tax allows for similar things (at least for priority fees), but can be implemented at the application layer off-chain on any chain using competitive priority ordering, without the need for special support for fee sharing. They also allow applications to define their own tax as a custom function of priority fees, providing greater flexibility and potentially increasing the composability of MEV-aware applications.

Une solution sans confiance. Cet article se concentre sur la motivation de l’utilisation de la priorité concurrentielle sur la plateforme et sur la façon d’utiliser la plateforme à priorité concurrentielle plutôt que de discuter de son exécution sans confiance.

De nombreux autres attributs nécessaires pour le classement de priorité compétitive ont déjà été largement discutés. Par exemple, dans Fox, Pai, Resnick (2023), les auteurs discutent des vulnérabilités des enchères hors-chaîne sans résistance à l’examen et décrivent la conception d’enchères résistantes à l’examen en utilisant plusieurs proposants simultanés. Cependant, ils ne recommandent pas d’ordre spécifique pour les transactions.

Il existe d’autres recherches sur la construction de mécanismes de construction de blocs à confiance minimale, notamment SUAVE de Flashbots, Angstrom de Sorella, Leaderless Auctions, Espresso et Timeboost décentralisé d’Offchain Labs, ainsi que l’emballage forcé des transactions publiques de Péter Szilági.

Conclusion

Nous espérons que cet article encouragera L2 à envisager l’utilisation de l’ordonnancement de priorité (OP stack pris en charge par défaut) et encouragera les applications à essayer la taxe MEV lorsqu’elle est prise en charge.

Nous espérons également qu’il pourra stimuler des recherches supplémentaires sur les protocoles de priorisation de la concurrence minimale de confiance sur L1 et L2.

Notes de bas de page

1. Dans cet article, nous utilisons le terme “proposant” pour désigner les participants ou le processus qui déterminent quelles transactions sont incluses dans un bloc spécifique. Sur Ethereum L2, ce rôle est généralement assuré par un “séquenceur”. Sur Ethereum L1, il est rempli par un validateur Ethereum spécifique appelé proposant, bien que le proposant externalise généralement la tâche de construction du bloc aux “relais” et aux “constructeurs” qui participent à une enchère compétitive. Les détails de la répartition de ces responsabilités dépassent le cadre de cet article.
2. Le coût prioritaire de chaque Gas n’est pas spécifié explicitement dans la transaction, mais peut être calculé dans la transaction. La transaction spécifie le prix du Gas, mais Ethereum prélève également des frais de base, qui sont retirés du prix du Gas et détruits. En ce qui concerne la taxe MEV, les frais de base doivent être ignorés car ils ne sont pas sous le contrôle du commerçant. Le coût prioritaire de chaque Gas (c’est-à-dire la partie du prix de la transaction qui va au proposant du bloc) peut être calculé en Solidity comme suit : priorityGasPrice = tx.gasprice - block.basefee.
3. Nous pouvons définir simplement le “MEV” pour exclure tout profit du chercheur et ne se référer qu’à la valeur qui va aux validateurs.
4. Veuillez noter que proposerPriorityFee ne peut pas réellement calculer le multiple du total du gas priorityFeePerGas utilisé dans la transaction pendant le contrat (égal au total du Gas utilisé dans la transaction), car on ne sait pas combien de Gas la transaction utilisera finalement. Cependant, cela est généralement sans importance car nous n’avons besoin que de sa limite supérieure. Par mesure de sécurité, vous pouvez multiplier priorityFeePerGas par 30 millions, ce qui est le maximum actuel du Gas dans le bloc Ethereum. Surestimer cette valeur signifierait simplement que la taxe MEV représente une plus grande proportion du MEV.
5. Supposons qu’une transaction ne peut pas dépasser 30 millions de Gas, un priorityFeePerGas de 50 000 entraînera un paiement de gaz de 1500 gwei - calculé sur la base du prix ETH de 4000 $, environ 0,006 $.
6. Si priorityFeePerGas est réglé de sorte que le profit arbitraire soit nul, alors le commerce d’arbitrage de maximisation des bénéfices devrait correspondre à la même transaction sur la fonction AMM de maximisation.
7. Arbitrum a discuté de l’utilisation d’une forme de classement de priorité appelée Timeboost pour le remplacer, mais à l’heure de la rédaction de cet article, cette forme n’a pas encore été mise en production.