Paradigm a inventé un nouveau mécanisme, la taxe MEV, qui pourrait changer le paysage DeFi existant

Cet article est tiré de Priority Is All You Need

Auteur original : Dan Robinson, Dave White

Compilé par : Odaily Planet Daily Husband

Paradigm a publié le 4 juin l'article Priority Is All You Need, qui présente en détail le nouveau mécanisme de taxe MEV.

La taxe MEV est un nouveau mécanisme qui permet aux applications de capturer la MEV qu'elles génèrent elles-mêmes, plutôt que de la divulguer aux proposants de blocs (voir la note de bas de page à la fin de l'article pour plus d'informations sur les proposants de blocs). Ce mécanisme tire parti du tri par priorité concurrentielle lors de la construction des blocs. Dans cette méthode de tri, les transactions sont triées par ordre décroissant de frais de priorité, et les transactions ayant une priorité plus élevée sont d'abord regroupées dans des blocs. La taxe MEV est mise en œuvre en ajoutant des frais supplémentaires aux frais de priorité d'une transaction. Les applications peuvent définir leurs propres frais en fonction des frais de priorité d'une transaction, capturant ainsi la plupart, voire la totalité, de la MEV. Cela signifie que les applications peuvent exécuter leurs propres enchères MEV personnalisées en participant à une seule enchère partagée gérée par des proposants de blocs sans avoir besoin d'une infrastructure hors chaîne.

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

• Changer la façon dont le MEV traditionnel est distribué : Traditionnellement, la plupart des flux MEV sont dirigés vers les proposants de blocs, et la taxe MEV permet aux applications de capturer cette valeur et de la redistribuer à leurs utilisateurs ou de l'utiliser à d'autres fins.

• Amélioration des revenus des applications et de l'expérience utilisateur : les applications peuvent augmenter leurs revenus en mettant en œuvre des taxes MEV tout en offrant une meilleure expérience utilisateur, car les utilisateurs peuvent obtenir une meilleure efficacité d'exécution des transactions et de meilleurs prix de transaction.

• Résoudre certains problèmes dans DeFi: M tels que l'optimisation du routage DEX, la réduction des pertes AMM dues à l'arbitrage, la réduction des fuites MEV des utilisateurs de portefeuilles, etc. En introduisant la taxe MEV, les applications peuvent améliorer leurs produits et services, améliorant ainsi l'efficacité et la durabilité de l'écosystème DeFi.

Citations

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

Ce mécanisme peut être utilisé immédiatement sur les chaînes OP Stack L2 telles que OP Mainnet, Base et Blast, car les proposants de blocs sur ces chaînes suivent un ensemble de règles que nous appelons la priorisation des conflits.

Pour mettre en œuvre une taxe MEV sur ces chaînes, un contrat intelligent facture des frais basés sur les frais de priorité d'une transaction. Nous montrons que si une application facture une taxe MEV de $99 pour chaque $1 de frais de priorité payés par un chercheur, elle peut capturer 99% de la MEV concurrente pour cette transaction.

La taxe MEV est une technique simple qui ouvre un vaste espace de conception. Vous pouvez la considérer comme permettant à n'importe quelle application de la chaîne d'exécuter sa propre enchère MEV personnalisée sans nécessiter d'infrastructure hors chaîne propre, en se connectant simplement à une enchère partagée gérée par des proposants de blocs.

Nous montrons comment la taxe MEV peut être utilisée pour répondre à trois questions principales dans la recherche MEV :

Un routeur d'échange décentralisé (DEX) qui optimise les prix reçus par les échangeurs

Teneur de marché automatisé (AMM) qui minimise les pertes des fournisseurs de liquidité (LVR) dues au rééquilibrage

Un portefeuille qui permet aux utilisateurs de capturer tout MEV « de secours » généré par leurs transactions

Mais il y a un hic. La taxe MEV ne fonctionne que si les proposants de blocs suivent strictement les règles de priorisation concurrentielles, y compris le classement des transactions par frais de priorité sans censure, espionnage ou retard. Si les proposants de blocs s'écartent de ces règles, ils peuvent contourner la taxe MEV pour capturer de la valeur. En conséquence, la taxe MEV actuelle repose sur la confiance dans le séquenceur L2 et peut ne pas fonctionner du tout sur Ethereum L1, où la construction de blocs sur le réseau principal Ethereum est dominée par des enchères de constructeurs compétitives qui maximisent les revenus des proposants.

Néanmoins, la puissance et la flexibilité de la taxe MEV suggèrent que la priorisation pourrait être le bon choix pour les plateformes qui la proposent actuellement. Et la relative simplicité de la priorisation concurrentielle suggère qu'il pourrait y avoir un moyen viable de l'appliquer de manière décentralisée sans faire confiance à un seul séquenceur. Nous espérons que cet article inspirera de nouvelles recherches sur ce problème.

Commande prioritaire

Lorsqu'une personne envoie une transaction sur le réseau principal Ethereum ou L2, elle spécifie des frais de priorité qui sont payés au proposant du bloc. Vous pouvez imaginer que cela est spécifié via priorityFeePerGas, qui est un nombre multiplié par le gaz utilisé dans la transaction pour obtenir builderPriorityFee, le montant total du paiement en ETH.

Le protocole Ethereum n'exige pas que les transactions d'un bloc soient triées avec gourmandise dans l'ordre de priorité décroissante. Cependant, c'est une façon courante de construire des blocs. Par exemple, il s'agit de l'algorithme par défaut utilisé par le séquenceur de la chaîne OP Stack et geth et reth. Le tri par priorité permet non seulement aux opérateurs d'exprimer efficacement l'urgence de leurs transactions, mais dirige également naturellement certains types de MEV vers les proposants de blocs.

Cela se produit parce que le tri prioritaire transforme la compétition pour le MEV en une vente aux enchères de gaz prioritaire. Lorsqu'il existe une opportunité de tirer profit de l'interaction avec une chaîne, par exemple par arbitrage entre un AMM et une bourse centralisée, les chercheurs se font concurrence pour saisir cette opportunité en premier. Si la chaîne utilise le tri prioritaire pour déterminer le conditionnement et l'ordre des transactions, les chercheurs se feront concurrence en fixant des frais hautement prioritaires dans leurs transactions.

Dans un scénario concurrentiel où les profits sans risque sont réduits à zéro par la concurrence, le chercheur gagnant devrait finalement payer le montant total de MEV en guise de frais prioritaires. Ainsi, s'il y a un profit de 100 ETH à gagner en interagissant avec le contrat, la première transaction à saisir l'opportunité fixera des frais prioritaires de 100 ETH. (Nous discutons de certaines réserves à ce sujet dans la section Limitations).

Taxe MEV

Supposons qu'un contrat intelligent souhaite capturer la MEV de toute transaction avec laquelle il interagit. Il existe une abondante littérature de recherche sur les différentes manières spécifiques aux applications par lesquelles les contrats intelligents tentent de capturer leur propre MEV.

Mais en réalité, nous n'avons pas nécessairement besoin de connaître quoi que ce soit de spécifique sur l'application. Si nous savons que les blocs sont construits via une priorisation compétitive, nous disposons alors d'un signal unifié pour le montant de MEV dans une transaction : les frais de priorité.

Nous proposons que les contrats intelligents puissent examiner les frais de priorité d'une transaction et facturer leurs propres frais en fonction de ceux-ci, qui sont une fonction croissante des frais de priorité. Par exemple, un contrat peut exiger que la personne qui l'appelle transfère applicationPriorityFee = 99 * proposerPriorityFee ETH au contrat.

Ces nouveaux frais sont payés par le chercheur qui envoie la transaction, ils affectent donc le comportement de ce chercheur. S'il y a 100 ETH de MEV dans une opportunité, la transaction gagnante ne fixera désormais qu'un frais de priorité de 1 ETH, car cela entraînera un paiement total de 100 ETH (1 ETH au proposant du bloc, 99 ETH au contrat intelligent). Tout frais de priorité plus élevé rendra la transaction non rentable ; tout frais de priorité inférieur entraînera le retrait de l'opportunité par un concurrent qui fixe des frais plus élevés. Cela signifie que le contrat intelligent capture 99% du MEV dans la transaction.

Nous appelons ces frais supplémentaires imposés par les contrats intelligents la taxe MEV. La taxe MEV permet aux applications de détourner la priorisation à leur propre avantage, leur permettant de récupérer la MEV pour leurs utilisateurs plutôt que de la laisser fuir pour bloquer les proposants.

Si ces frais augmentent suffisamment vite en fonction de priorityFeePerGas , alors seul un MEV négligeable reviendra au proposant. Étant donné que priorityFeePerGas est libellé en wei (cent millionième d'ETH), nous avons beaucoup de précision à exploiter. Par exemple, tant que la sensibilité de la taxe MEV est suffisamment élevée pour qu'un priorityFeePerGas de 50 000 entraîne une taxe prohibitive, le montant total payé au proposant sera inférieur à $0.01 .

Il y a cependant une mise en garde importante. Comme nous l’avons vu dans la section « Limitations », la taxe MEV ne fonctionne que si les promoteurs de blocs suivent certaines règles (que nous appelons « priorisation concurrentielle ») et ne s’écartent pas de ces règles pour maximiser leurs propres revenus. Appliquer ces règles de manière non fiduciaire est un problème ouvert.

Capture MEV pour une seule application

Sur une chaîne qui garantit que les blocs sont construits à l'aide d'une priorisation compétitive, la taxe MEV peut être utilisée pour atténuer trois problèmes importants avec MEV : permettre aux interfaces DEX d'améliorer l'exécution des transactions pour les échangeurs ; permettre aux AMM de réduire les pertes d'arbitrage pour leurs LP ; et permettre aux portefeuilles de réduire les fuites MEV des utilisateurs en vendant le droit de courir aux utilisateurs.

Recherche de routeur DEX

Dans les protocoles de routage DEX basés sur l'intention tels que UniswapX et 1inch Fusion, un utilisateur (Alice) signe une intention d'échange et les chercheurs rivalisent pour acheminer ou remplir l'intention au meilleur prix.

La version actuelle d'UniswapX utilise deux mécanismes pour organiser cette compétition : une enchère hollandaise, où le prix limite d'Alice change au fil du temps jusqu'à ce qu'il soit rempli par le chercheur, et une enchère initiale de demande de devis (RFQ) hors chaîne pour définir le prix de départ de cette enchère hollandaise.

Sur les plateformes qui garantissent une priorité compétitive, UniswapX peut les remplacer par un mécanisme : la taxe MEV. Elle peut être mise en œuvre en faisant signer aux utilisateurs un ordre qui peut être exécuté 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 UniswapX de vendre 1 ETH, elle peut définir le prix d'exécution de l'ordre comme étant minimumPrice + ($ 0,01 * priorityFeePerGas). minimumPrice peut être une valeur fixe dont elle s'attend à ce qu'elle soit nettement inférieure au prix actuel.

Les chercheurs rivaliseront pour remplir la commande d'Alice en soumettant des transactions. Toute transaction avec les frais de priorité les plus élevés qui ne reculent pas remplira la commande, ce qui devrait garantir que le trader obtienne le meilleur prix que le chercheur puisse 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, la priorité FeePerGas dans la transaction gagnante est d'environ 50 000. (Notez que dans une transaction coûtant 200 000 gaz, cela n'entraînerait que le paiement d'environ 10 milliards de wei (environ $0,000035) au proposant du bloc.)

Cela présente certains 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 à de meilleurs prix que les commandes utilisant les enchères néerlandaises. Comme décrit dans l'article, les enchères néerlandaises sur la chaîne laissent échapper une certaine valeur vers MEV en raison des variations de prix entre les blocs et peuvent nécessiter plusieurs blocs pour être exécutées. En revanche, les commandes utilisant la taxe MEV peuvent souvent être exécutées dans le bloc suivant tout en capturant la grande majorité de leur MEV.

Contrairement aux demandes de devis hors chaîne, les enchères qui remplissent les commandes à l'aide des taxes MEV se dérouleront de manière atomique lors de l'exécution des transactions sur la chaîne. Cela signifie que l'enchérisseur gagnant peut garantir que l'ordre ne sera exécuté que si sa transaction sur la chaîne réussit. Cela peut rendre la liquidité sur la chaîne (comme les AMM) plus facilement compétitive par rapport à la liquidité hors chaîne, ce qui signifie qu'UniswapX peut servir de routeur plus efficace pour les sous-systèmes multi-pool (comme Uniswap v4).

Teneur de marché automatisé (AMM)

En règle générale, les AMM perdent de la valeur en raison des arbitragistes qui négocient à des prix périmés en haut des blocs, comme indiqué dans le perte-vs-rééquilibrage Nous pouvons utiliser une taxe MEV pour permettre aux AMM de capturer ces MEV. Pour plus de simplicité, nous verrons comment procéder sur un AMM sans liquidité centralisée. (Si vous souhaitez savoir comment résoudre ce problème lorsqu'il y a une liquidité centralisée, Sorella publiera bientôt une solution.)

Les AMM peuvent capturer la MEV en facturant des frais supplémentaires basés sur les frais de priorité d'une transaction, ce qui leur permet de vendre aux enchères le droit de prioriser les transactions dans un bloc. Il existe de nombreuses façons de calculer et de dénommer ces frais. Nous allons discuter d'une méthode sans doute neutre - l'exprimant en unités de liquidité du pool sqrt(xy). Les transactions gagnantes seront celles qui augmenteront le plus la liquidité du pool.

Lorsque la première transaction est exécutée sur le pool dans un bloc, le pool peut appliquer la condition x_end * y_end > x_start * y_start (comme une constante pour a) :

x_end * y_end > (sqrt(x_start * y_start) + a*priorityFeePerGas)^ 2 Cette formule incitera les traders d'arbitrage à négocier au prix réel, après quoi le prix médian du pool devrait être le prix réel.

Après cette première transaction, le trading peut fonctionner comme dans Uniswap v2, en utilisant des frais de swap fixes. Les traders non informés qui souhaitent trader sans payer la taxe MEV supplémentaire fixeront des frais préférentiels inférieurs.

Il existe de nombreuses autres façons d'implémenter une taxe MEV sur un AMM, avec des effets différents. Par exemple, la taxe MEV pourrait être exprimée en jetons d'entrée ou de sortie d'une bourse, pourrait affecter le pourcentage de frais d'échange appliqués par un pool ou pourrait déterminer le prix minimum auquel les utilisateurs peuvent effectuer des transactions. Nous pensons qu'il s'agit d'un espace de conception intéressant qui mérite d'être exploré.

Enchères en cours

La description ci-dessus montre comment certaines applications peuvent être conçues pour éviter la fuite de MEV. Mais que se passe-t-il si un portefeuille souhaite aider ses utilisateurs à capturer le MEV qu'ils génèrent lorsqu'ils interagissent avec une application via une transaction, même si ces applications n'incluent pas de taxe MEV ?

Par exemple, lorsqu'Alice réalise une transaction importante sur un AMM, elle crée parfois une opportunité d'arbitrage pour les « backrunners » afin de ramener le prix à la normale. Souvent, ces opportunités se répercutent sur le MEV, plutôt que sur Alice.

Partage MEV et Blocage MEVB il s'agit de deux protocoles qui permettent aux utilisateurs de capturer le MEV à partir de leurs transactions, mais ils reposent sur des systèmes d'enchères hors chaîne complexes. L'espace de conception des enchères Orderflow décrit quelques autres solutions.

Lorsque la taxe MEV est combinée à un portefeuille de contrats intelligents basé sur l'intention, nous pouvons créer un système alternatif pour capturer la MEV de suivi d'Alice. Supposons qu'Alice n'ait pas créé de transaction pour négocier sur l'AMM, mais qu'elle ait plutôt signé une intention que n'importe qui peut soumettre au portefeuille de contrats intelligents d'Alice pour qu'il effectue cette action. Le portefeuille de contrats intelligents d'Alice facture une taxe MEV à la personne qui a soumis cette transaction, qui est versée à Alice.

Le chercheur qui a soumis l'intention d'Alice a 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 concurrence dans la recherche est élevée, tous les bénéfices tirés du suivi d'Alice devraient lui revenir par le biais de sa taxe MEV.

Il est important de noter que ce système ne protège pas totalement les utilisateurs contre les attaques de type « front-runners », car ces derniers peuvent éviter de payer la taxe MEV aux utilisateurs. Ce problème (et certaines de ses éventuelles atténuations) est abordé en détail dans la section Limitations ci-dessous. Cependant, il s'agit au moins d'une amélioration par rapport à un système de pool de mémoire public sans aucune atténuation.

Autres cas d'utilisation

Outre ces exemples, d'autres utilisations potentielles de la taxe MEV incluent presque tous les scénarios qui utilisent actuellement des enchères hors chaîne ou néerlandaises, telles que :

• Des protocoles comme Oval fonctionnent en capturant la valeur extractible de l'oracle (OEV) qu'ils créent.

• Enchères de refinancement dans les protocoles de prêt garantis par NFT comme Blend.

• Les liquidations de protocoles de prêt génèrent moins de valeur que les enchères hollandaises.

Capture MEV inter-applications

Les solutions ci-dessus sont conçues pour capturer la valeur ajoutée générée lors de l'interaction avec une seule application. Cependant, un chercheur peut parfois capturer davantage de valeur en interagissant avec plusieurs applications dans la même transaction.

Si une seule de ces applications utilise une taxe MEV, alors toutes les MEV des transactions doivent être attribuées à l'application utilisant la taxe MEV, quelle que soit la valeur de cette taxe MEV.

Mais que se passe-t-il si les transactions du chercheur interagissent avec deux applications qui utilisent la taxe MEV ? Par exemple, si certains MEV ne peuvent être capturés qu'en remplissant un ordre UniswapX taxé MEV contre un AMM taxé MEV ?

Dans ce cas, le montant relatif de l'excédent de MEV capturé par chaque application est déterminé par la taxe MEV définie par ces applications. Si la valeur de app_i en tant que taxe MEV est donnée par la fonction tax_i(priority), la priorité de la transaction gagnante peut être déterminée en résolvant la priorité dans l'équation suivante : taxe_1(prioritéParGaz) + taxe_2(prioritéParGaz) = total MEV

(Techniquement, nous pourrions ajouter un troisième terme priorityPerGas * gasUsed pour tenir compte des frais de priorité payés au proposant du bloc, mais nous l'ignorerons car, comme indiqué dans l'annexe A, les frais de priorité sont susceptibles d'être négligeables dans des circonstances normales.)

Dans le cas simple d'une taxe MEV linéaire en priorityPerGas (donc tax_ 1(priorityPerGas) = a_ 1 * priorityPerGas ), vous pouvez résoudre la part de MEV que chaque application reçoit :

a_1 * prioritéParGaz + a_2 * prioritéParGaz = MEV

prioritéParGaz = MEV/(a_ 1 + a_ 2)

taxe_1(prioritéParGaz) =(a_1/(a_1+a_2))*MEV

taxe_2(prioritéParGaz) = (a_2/(a_1+a_2))*MEV

Une application doit faire un compromis lorsqu'elle définit sa propre taxe MEV : un taux de taxe plus élevé lui permet de capturer une plus grande part de la MEV inter-applications lorsqu'elle se produit, mais cela signifie qu'elle peut manquer une partie de la MEV inter-applications s'il existe des méthodes d'extraction concurrentes. Par exemple, s'il existe un AMM qui facture une taxe MEV sur chaque transaction, un carnet d'ordres UniswapX taxé MEV peut être rempli par un AMM différent ou un remplisseur hors chaîne.

Dans de nombreux cas, il peut y avoir un équilibre dans lequel deux applications conçoivent leurs taxes MEV pour partager la MEV d'une manière qui maximise leur bien-être respectif. Par exemple, un AMM taxant la MEV peut vouloir capturer la valeur d'un seul trader informé près du sommet d'un bloc, mais souhaite ensuite fournir de la liquidité à d'autres traders et applications (y compris ceux qui utilisent la taxe MEV) à un tarif fixe inférieur. Dans ce cas, l'AMM peut définir une taxe MEV relativement faible (par exemple, $0.00001 * priorityFeePerGas) afin que les transactions d'arbitrage (le cas échéant) se produisent au début du bloc, puis ne facturer aucune taxe MEV pour les transactions ultérieures dans le bloc. Les applications comme UniswapX qui souhaitent interagir avec l'AMM peuvent définir une taxe MEV plus élevée (comme $0.01 * priorityFeePerGas) pour s'assurer que leurs transactions sont incluses après que le pool a déjà arbitré. Avec ces taxes relatives, l'AMM sera finalement arbitré en premier même s'il n'y a que $1 de MEV et $50 000 de MEV dans le carnet d'ordres UniswapX.

Nous pensons qu’il s’agit d’un vaste espace de conception digne de recherches futures.

limitation

La taxe sur les véhicules électriques présente plusieurs complexités et défauts. Nous pensons qu’il s’agit de domaines intéressants pour des recherches futures.

Incompatibilité des incitations

Les taxes MEV sont incompatibles avec les incitations pour les proposants de blocs monopolistiques. Elles ne fonctionnent que s'il existe une concurrence loyale pour l'inclusion des transactions, ce qui ne se produit que si les proposants de blocs suivent des règles que nous appelons « priorisation concurrentielle » au lieu de maximiser leurs propres revenus. Nous recommandons que ces règles incluent :

• Tri prioritaire : les transactions d'un bloc doivent être triées par ordre décroissant de prioritéFeePerGas.

• Résistance à la censure : si le proposant du 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 t 2.priorityFeePerGas

• Confidentialité avant transaction : les proposants de blocs doivent accepter les transactions via un point de terminaison privé et ne peuvent pas partager ces transactions avec quiconque avant de soumettre un bloc, ni utiliser le contenu de ces transactions pour construire leurs propres transactions.

• Il n'y a pas de finalité. Les proposants en bloc doivent définir une durée définie (blockTime) avant laquelle ils acceptent les transactions de n'importe qui et après laquelle ils n'acceptent plus de transactions de n'importe qui.

Si une ou plusieurs de ces propriétés sont violées, cela pourrait affaiblir l'efficacité de la taxe MEV. Un proposant en bloc qui viole la résistance à la censure pourrait profiter de l'occasion en excluant les transactions concurrentes et en soumettant une transaction à priorité zéro pour éviter la plupart des taxes MEV. Un proposant en bloc qui viole la confidentialité avant transaction pourrait voler la MEV d'autres transactions, ou jeter un œil à leurs frais de priorité pour savoir à quel niveau ils doivent fixer pour surenchérir sur les autres, tandis qu'un proposant qui est en mesure de soumettre une transaction plus tard que les autres est libre de finaliser sa décision de surenchérir sur les autres, provoquant un problème de sélection adverse qui, en fin de compte, inhibe la concurrence.

Malheureusement, alors que la première propriété est facile à appliquer au niveau du protocole, appliquer les autres de manière non fiable est un problème ouvert.

En l'absence d'application au niveau du protocole, un séquenceur engagé à respecter ces règles doit être sûr de ne pas s'en écarter, et les blocs peuvent ne pas les suivre si les proposants sous-traitent la construction de blocs à des enchères compétitives maximisant les revenus (comme MEV-Boost sur le réseau principal Ethereum).

Ces problèmes pourraient être « résolus » par un seul ordonnateur de confiance qui s'engage à construire des blocs en utilisant une priorisation compétitive. Ou ils pourraient être résolus par des mécanismes décentralisés utilisant une combinaison de consensus, de cryptographie et/ou d'environnements d'exécution de confiance, tels qu'Angstrom de Sorella, SUAVE de Flashbots, Leaderless Auctions ou Multiplicity.

Blocage complet

Une exception au fonctionnement normal de la taxe MEV se produit lorsque les blocs sont complètement remplis. Dans ce cas, les proposants de blocs peuvent être amenés à exclure les transactions de faible priorité plutôt que de simplement les inclure plus tard dans le bloc. Étant donné que les transactions qui interagissent avec des applications utilisant la taxe MEV sont susceptibles d'avoir des frais de priorité extrêmement faibles, ces applications peuvent être évincées par des applications qui n'utilisent pas la taxe MEV ou des applications qui utilisent des taxes MEV extrêmement faibles. Cependant, sur les chaînes qui utilisent un mécanisme comme EIP-1559 pour définir des frais de base distincts, les blocs complètement remplis devraient être rares. 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 définissant une taxe MEV plus élevée peut être un résultat raisonnable.

Annuler une transaction

La taxe MEV repose essentiellement sur une vente aux enchères en bloc unique, où chaque offre est une transaction. L'inconvénient de telles enchères est que les offres infructueuses entraînent souvent l'inclusion d'une transaction de retour en arrière sur la chaîne, le paiement de frais de base et la congestion de la chaîne.

Si le séquenceur pouvait exclure entièrement les transactions échouées, cela atténuerait ce problème, bien que cela soit difficile à réaliser même avec un séquenceur centralisé. (Cela ne respecte pas non plus entièrement la propriété de résistance à la censure décrite ci-dessus, bien que cette définition puisse être ajustée.) Un séquenceur plus sophistiqué pourrait être en mesure d'optimiser ce processus en permettant aux transactions de spécifier les enchères de litiges auxquelles elles participent, ce qui permettrait au séquenceur d'ignorer les transactions suivantes dont il sait qu'elles échoueront.

Divulgation de l'intention de l'utilisateur

La taxe MEV ne fonctionne que lorsqu'il existe une concurrence entre les chercheurs, ce qui signifie que l'opportunité doit être connue dans une certaine mesure. Pour des applications comme les AMM, où l'opportunité est visible sur la chaîne, cela devrait se produire naturellement. Mais pour des applications comme le routage basé sur l'intention ou l'enchère de queue, cela signifie que l'application peut avoir besoin de partager l'intention de l'utilisateur avec le chercheur.

Dans certains cas, la confidentialité temporaire perdue par la diffusion de l'intention de l'utilisateur avant qu'elle ne soit satisfaite peut entraîner une perte de valeur que la taxe MEV ne peut pas récupérer.

Par exemple, supposons qu'Alice souhaite acheter un jeton à faible liquidité en utilisant le protocole d'enchères suiveuses décrit ci-dessus. Elle publie une intention signée pour son portefeuille de contrats intelligents pour acheter ce jeton sur l'AMM et définit une certaine tolérance au glissement. Les chercheurs peuvent se précipiter pour pousser le prix de ce jeton jusqu'à sa tolérance au glissement dans une transaction à haute priorité sans remplir la commande des utilisateurs. Le gagnant, Bob, peut alors satisfaire de manière non compétitive l'intention d'Alice en incluant et en rétrogradant l'intention d'Alice dans une transaction à faible priorité, prenant ainsi en sandwich la transaction d'Alice et lui donnant un prix plus bas tout en évitant sa taxe MEV. Des problèmes similaires peuvent survenir lors de l'achat de NFT.

Notez qu'une telle attaque est risquée pour Bob, car il ne peut pas garantir l'atomicité entre l'achat du jeton et sa vente à Alice. Un Bob naïf pourrait être victime d'un piège à sandwich déchiré, où Alice affiche une intention d'acheter un jeton sans valeur à elle-même, ce qui amène Bob à l'acheter dans l'espoir de le prendre en sandwich dans sa transaction, mais Alice révoque son intention avant que Bob ne puisse terminer le sandwich.

Les applications peuvent également atténuer ce problème en limitant l’ensemble des chercheurs qui partagent leur intention et en surveillant leur comportement, comme le font de nombreuses enchères de flux d’ordres existantes.

Il est également possible de combiner les taxes MEV avec des fonctionnalités de construction respectueuses de la vie privée, telles que celles envisagées dans la conception SUAVE de Flashbots.

Enfin, si Alice décide que le coût du partage de ses intentions dépasse les avantages de la recherche concurrentielle, elle peut construire elle-même une transaction et la soumettre directement au bloc. Comme décrit ci-dessus, une mise en œuvre idéale de la priorisation concurrentielle fournirait une confidentialité avant la transaction aux proposants du bloc.

Discussion et travaux préliminaires

Enchères de gaz prioritaires. Flash Boys 2.0 L’article, qui a inventé le terme « valeur extractible par les mineurs », a examiné certaines des dynamiques de priorisation dans les blockchains décentralisées. L’article a observé que les mineurs d’Ethereum (lorsque le réseau utilisait la preuve de travail) priorisaient déjà les transactions, et que les arbitragistes s’appuyaient sur ce comportement pour participer aux « enchères de gaz prioritaires », où ils enchérissaient pour avoir le droit d’être inclus en premier dans les blocs, ce qui a eu pour résultat que la majorité de la MEV issue de l’arbitrage des échanges décentralisés revenait aux mineurs.

Premier arrivé, premier servi. Grâce aux règles de séquencement des transactions (telles que Thémis ou Séquenceur actuel Arbitrum Ones Certaines tentatives visant à atténuer le MEV 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 en bloc doivent classer les transactions dans l’ordre dans lequel elles sont vues.

La priorisation adopte une approche différente : elle traite les transactions qui arrivent dans une période donnée de manière égale et les trie en fonction de leur priorité déclarée.

Le « classement équitable » est difficile à appliquer ou même à définir dans un environnement réseau réel avec plusieurs validateurs. Il peut également conduire à des courses de latence inutiles et à du spam, même avec un seul séquenceur de confiance. Enfin, une taxe MEV pourrait permettre d’éliminer certains MEV « premier arrivé, premier servi », tels que les profits d’arbitrage provenant de « sauts » discontinus dans les prix des actifs. L’avantage potentiel du classement prioritaire par rapport au classement premier arrivé, premier servi est quelque peu lié aux avantages de l’échange en temps discret par rapport à l’échange en temps continu évoqués dans Budish, Cramton et Shim (2015) .

Dans le même temps, alors que la priorisation semble par défaut faire perdre de la valeur à MEV, cet article montre comment les applications peuvent être conçues pour la récupérer.

Partage des frais. Blast est un Ethereum L2 qui partage une partie des frais de priorité et de base avec les contrats intelligents auxquels on accède lors de la transaction.

Les taxes MEV permettent quelque chose de similaire (au moins pour les frais de priorité), mais peuvent être implémentées au niveau de la couche applicative sur n'importe quelle chaîne qui utilise la priorisation concurrentielle, sans nécessiter de support spécial pour le partage des frais. Elles permettent également aux applications de définir leurs propres taxes en tant que fonctions personnalisées des frais de priorité, ce qui permet une plus grande flexibilité et une composabilité potentiellement accrue des applications compatibles MEV.

Solutions sans confiance. Cet article se concentre sur les incitations des plateformes à utiliser la priorisation concurrentielle et sur les méthodes permettant d'exploiter les plateformes de priorisation concurrentielle, plutôt que de discuter de la manière de l'exécuter sans confiance.

Chacune des autres propriétés requises pour la priorisation compétitive a déjà été largement discutée auparavant. Par exemple, dans Fox, Pai et Resnick (2023) Les auteurs discutent des vulnérabilités des enchères en chaîne sans résistance à la censure et décrivent une conception d'enchères résistantes à la censure utilisant plusieurs proposants simultanés. Cependant, ils ne recommandent pas un ordre spécifique des transactions.

Il existe d'autres recherches sur la création de mécanismes de construction de blocs minimisant la confiance, notamment SUAVE de Flashbots, Angstrom de Sorella, Leaderless Auctions, Timeboost décentralisé d'Espresso et d'Offchain Labs et le packaging des transactions publiques forcées de Péter Szilági.

en conclusion

Nous espérons que cet article encouragera L2 à envisager d’utiliser la priorisation (prise en charge par défaut dans la pile OP) et incitera les applications à essayer la taxe MEV là où elle est prise en charge.

Nous espérons également que cela inspirera de nouvelles recherches sur les protocoles de priorisation des conflits minimisant la confiance sur L1 et L2.

note de bas de page

1. Dans cet article, nous utilisons le terme « proposant » pour désigner le participant ou le processus qui détermine quelles transactions sont incluses dans un bloc particulier. Sur Ethereum L2, 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é proposant, bien que les proposants sous-traitent généralement la tâche de création de blocs à une enchère compétitive impliquant des « relais » et des « constructeurs ». Les détails de la répartition de ces responsabilités dépassent le cadre de cet article.

2. Les frais de priorité par gaz ne sont pas réellement spécifiés explicitement dans la transaction, mais ils peuvent être calculés dans la transaction. La transaction spécifie le prix du gaz, mais Ethereum facture également des frais de base, qui sont prélevés sur le prix du gaz et détruits. Aux fins de la taxe MEV, les frais de base doivent être ignorés car ils ne sont pas contrôlés par le commerçant. Les frais de priorité par gaz (c'est-à-dire le prix de la partie des frais de transaction qui revient au proposant du bloc) peuvent être calculés dans Solidity comme priorityGasPrice = tx.gasprice – block.basefee.

3. Nous pouvons simplement définir « MEV » pour exclure tout profit du chercheur et faire référence uniquement à la valeur qui sera transmise aux validateurs.

4. Notez que proposerPriorityFee ne peut pas réellement être calculé comme un multiple du montant priorityFeePerGas (égal au total de gaz utilisé dans la transaction) pendant le contrat, car il n'y a aucun moyen de savoir quelle quantité de gaz la transaction utilisera finalement. Cependant, cela n'a généralement pas d'importance, car tout ce dont nous avons besoin est une limite supérieure. Pour plus de sécurité, vous pouvez multiplier priorityFeePerGas par 30 millions, le maximum actuel de gaz dans un bloc Ethereum. Surestimer cette valeur signifiera seulement que la taxe MEV représente une plus grande proportion 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 ETH de $4 000.

6. Si priorityFeePerGas est défini de telle sorte que le profit de l'arbitragiste soit nul, alors la transaction d'arbitrage maximisant le profit doit correspondre à la même transaction sur l'AMM maximisant la fonction.

7. Arbitrum a discuté du remplacement de cette fonctionnalité par une forme de priorisation appelée Timeboost, mais au moment de la rédaction de cet article, elle n'est pas encore en production.

Cet article provient d'Internet : Paradigm a inventé un nouveau mécanisme, la taxe MEV, qui pourrait changer le paysage DeFi existant

En relation : Bitget Research Institute : Le secteur des mèmes a fortement chuté au cours du week-end, LayerZero et zkSync devraient émettre des jetons

Au cours des dernières 24 heures, de nombreuses nouvelles devises et sujets d'actualité sont apparus sur le marché, et il est très probable qu'ils seront la prochaine opportunité de gagner de l'argent. Les secteurs suivants doivent être pris en compte : Secteur des mèmes, secteur des jetons de fans Jetons et sujets recherchés par les utilisateurs : Scroll, Manta Network, BONK Les opportunités potentielles de largage aérien incluent : Scroll, Orbiter Finance Heure des statistiques des données : 20 mai 2024 4 : 00 (UTC + 0) 1. Environnement du marché La semaine dernière, l'ETF spot BTC a enregistré une entrée nette pendant 5 jours consécutifs. L'afflux de fonds au cours des deux dernières semaines a compensé toutes les sorties d'avril. Le BTC a augmenté de 9% en une semaine et le prix a fluctué autour de 67 000. Les données d'observation de la Réserve fédérale du CME montrent que la probabilité que la Réserve fédérale…