Auteur : Dan Robinson,Dave White
Compilé par : Joyce BlockBeats
Dans cet article, nous présenterons la taxe MEV, qui est un mécanisme que toute application peut utiliser pour capturer son propre MEV. Ce mécanisme est désormais disponible sur OP Stack L2 tel que OP Mainnet, Base et Blast, car les proposants de blocs sur ces chaînes suivent un ensemble de règles que nous appelons priorisation compétitive.
Afin d'imposer une taxe MEV sur l'une des chaînes, le contrat intelligent facture des frais qui sont fonction des frais de priorité de transaction. Si une application facture une taxe MEV de 99 $ pour chaque dollar de frais de priorité du chercheur, elle capture 99 % du MEV concurrentiel pour cette transaction.
La taxe MEV est 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 aucune de sa propre infrastructure hors chaîne, en se connectant simplement à une seule enchère partagée gérée par le proposant du bloc.
Nous illustrons comment les taxes MEV peuvent être utilisées pour résoudre trois problèmes majeurs dans la recherche MEV :
Les routeurs d'échange décentralisés (DEX) qui optimisent le prix reçu par les échangeurs
Le font automatiquement Market Maker (AMM) ; , minimisant les pertes et le rééquilibrage (LVR) subis par les fournisseurs de liquidité ;
Des portefeuilles qui permettent aux utilisateurs de capturer tout MEV « en arrière-plan » créé par leurs transactions
Mais il y a une question. La taxe MEV ne fonctionne que si les proposants de blocs adhèrent strictement aux règles de priorisation compétitives, qui incluent le classement des transactions par frais de priorité sans censure, surveillance ou retard des transactions. Si les proposants de blocs s'écartent de ces règles, ils peuvent échapper à la taxe MEV et capturer de la valeur pour eux-mêmes. Ainsi, aujourd’hui, les taxes MEV reposent sur des commanditaires L2 de confiance et peuvent ne pas fonctionner du tout sur Ethereum L1, où la construction de blocs est dominée par des enchères de constructeurs compétitives qui maximisent les propositions sur le revenu de la personne.
Néanmoins, la puissance et la flexibilité de la taxation MEV suggèrent que la priorisation peut être le bon choix pour les plateformes actuellement en mesure d'offrir ce service. La relative simplicité de la priorisation concurrentielle suggère qu’il existe peut-être un moyen réalisable de l’appliquer de manière décentralisée sans avoir à faire confiance à un seul séquenceur. Nous espérons que cet article stimulera de nouvelles recherches sur cette question.
Lorsque quelqu'un envoie une transaction sur Ethereum L1 ou L2, il attribue des frais de priorité et les paie au proposant du bloc. Vous pouvez imaginer que cela soit spécifié comme prioritéFeePerGas, un nombre multiplié par le gaz utilisé dans la transaction pour obtenir le builderPriorityFee – le paiement total en ETH.
Il n'y a aucune disposition dans le protocole Ethereum selon laquelle les transactions dans un bloc doivent être triées avidement par prioritéFeePerGas dans l'ordre décroissant. Cependant, il s'agit d'un moyen populaire de créer des blocs - par exemple, il s'agit de l'ordonnateur de la chaîne OP Stack et de l'algorithme par défaut utilisé par geth et reth. La priorisation permet non seulement aux traders d'exprimer efficacement l'urgence de leurs transactions, mais transmet également naturellement certains types de MEV pour bloquer les proposants.
Cela se produit parce que la priorisation transforme la concurrence pour le MEV en une vente aux enchères de gaz prioritaire. Lorsque des opportunités se présentent pour tirer profit des interactions avec une chaîne, comme par exemple un arbitrage avec des échanges centralisés via des AMM, les chercheurs se précipitent pour être les premiers à le faire. Si la chaîne utilise la priorisation pour déterminer l'inclusion et l'ordre des transactions, les chercheurs se font concurrence en fixant des frais hautement prioritaires pour leurs transactions.
Dans un scénario concurrentiel avec une concurrence sans profit sans risque, le chercheur gagnant devrait en fin de compte payer l'intégralité des frais de priorité MEV. Ainsi, si un bénéfice de 100 ETH est disponible en interagissant avec le contrat, la première transaction réclamant ce profit aura des frais prioritaires de 100 ETH. (Nous discutons de quelques mises en garde dans la section Limitations).
Supposons qu'un contrat intelligent veuille capturer le MEV de toute transaction avec laquelle il interagit. Il existe de nombreuses recherches sur les différentes manières spécifiques aux applications par lesquelles les contrats intelligents peuvent tenter de capturer leur propre MEV.
Mais en fait, on n’a pas forcément besoin de savoir quoi que ce soit sur l’application. Si nous savons que le bloc a été construit via une priorisation compétitive, nous disposons alors d’un signal universel sur le montant de MEV dans la transaction : les frais de priorité.
Nous proposons qu'un contrat intelligent examine les frais prioritaires d'une transaction et facture ses propres frais en fonction de celle-ci. Par exemple, le contrat peut exiger que l'appelant transfère applicationPriorityFee = 99 * proposerPriorityFee en ETH au contrat.
Ces nouveaux frais sont payés par le chercheur qui a envoyé la transaction, ils affectent donc le comportement de ce chercheur. S'il y a 100 MEV dans l'opportunité, la transaction gagnante ne fixera désormais que des frais prioritaires de 1 ETH, car cela entraînera un paiement total de 100 ETH (1 ETH au proposant du bloc et 99 ETH au contrat intelligent). Tout frais de priorité plus élevée rendra la transaction non rentable ; tout frais de priorité inférieure entraînera des opportunités perdues pour les concurrents qui fixent des frais plus élevés. Cela signifie que le contrat intelligent a capturé 99 % du MEV de la transaction.
Nous appelons ce supplément imposé par le contrat intelligent la taxe MEV. La taxe MEV permet à une application de détourner la priorisation à son propre bénéfice, lui permettant ainsi de récupérer le MEV pour ses utilisateurs plutôt que de le divulguer pour bloquer les proposants.
Si les frais augmentent assez rapidement en fonction de la prioritéFeePerGas, le proposant n'obtiendra qu'un MEV négligeable. Puisque PriorityFeePerGas est libellé en wei (milliardièmes de 1 ETH), nous devons faire preuve de beaucoup de précision. Par exemple, tant que la taxe MEV est suffisamment sensible pour qu'un PriorityFeePerGas de 50 000 entraîne une taxe excessive, le montant total payé au proposant serait inférieur à 0,01 $. (5)
Cependant, il y a une mise en garde importante. Comme indiqué dans la section « Limites », les taxes MEV ne fonctionnent que si les proposants de bloc suivent certaines règles (ce que nous appelons « priorisation compétitive ») et ne s'écartent pas de ces règles afin de maximiser leurs propres revenus. L’application de ces règles sans confiance est une question ouverte.
Nous décrivons ici comment les taxes MEV peuvent être utilisées pour atténuer trois problèmes importants dans MEV sur les chaînes qui garantissent la construction de blocs en utilisant des priorités concurrentes : Laissez les interfaces DEX améliorer l'exécution des transactions par les échangeurs, permettant aux AMM pour réduire les pertes d'arbitrage sur leur LP et permettre aux portefeuilles de réduire les fuites MEV des utilisateurs en vendant leurs droits d'exécution inversée.
Dans les protocoles de routage DEX basés sur l'intention comme UniswapX et 1inch Fusion, un utilisateur (Alice) signe une intention d'échange et les chercheurs se font concurrence pour acheminer Alice au meilleur prix ou remplir cette intention.
La version actuelle d'UniswapX utilise deux mécanismes pour rivaliser : une enchère néerlandaise, où le prix limite d'Alice change au fil du temps jusqu'à ce que les chercheurs le remplissent, et une enchère initiale de demande de devis (RFQ) hors chaîne, où est utilisé pour définir ; le prix de départ pour une vente aux enchères aux Pays-Bas.
Sur une plateforme garantissant une priorisation compétitive, UniswapX peut remplacer ces mécanismes par un mécanisme unique : la taxe MEV. Pour ce faire, il permet aux utilisateurs de signer des ordres que n’importe qui peut exécuter immédiatement, mais avec un prix d’exécution fixé en fonction de la priorité de la transaction.
Par exemple, si Alice a un ordre UniswapX pour vendre 1 ETH, elle peut définir le prix d'exécution de l'ordre comme prix minimum + ($0,01 * prioritéFeePerGas). minimumPrice est probablement une valeur fixe dont elle s'attend à ce qu'elle soit nettement inférieure au prix actuel.
Les chercheurs s'affronteront pour remplir la commande d'Alice en soumettant des transactions. L'ordre sera exécuté quelle que soit la transaction ayant les frais de priorité la plus élevée et qui n'est pas restaurée, ce qui devrait garantir à l'échangeur d'obtenir le meilleur prix que le chercheur puisse trouver. (Certaines exceptions 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 Gas, cela entraînerait le paiement de seulement ~ 10 milliards de wei (~ 0,000035 $) au proposant du bloc.)
Par rapport au mécanisme existant utilisé dans UniswapX, cela présente certains avantages potentiels.
Les commandes utilisant la taxe MEV peuvent être exécutées plus rapidement et à un meilleur prix que les commandes utilisant Dutch Auction. Comme indiqué dans cet article, les enchères néerlandaises en chaîne perdent une certaine valeur au MEV en raison des changements de prix entre les blocs, et peuvent prendre plusieurs blocs pour être complétées. En revanche, les commandes utilisant les taxes MEV peuvent souvent être exécutées dans le bloc suivant tout en capturant la grande majorité du MEV.
Contrairement aux appels d'offres hors chaîne, les enchères pour les commandes utilisant la taxe MEV seront effectuées automatiquement lorsque les transactions en chaîne sont exécutées. Cela signifie que l'enchérisseur retenu est assuré de s'engager à exécuter la commande uniquement si la transaction en chaîne réussit. Cela peut permettre à la liquidité en chaîne comme les AMM de rivaliser plus facilement avec la liquidité hors chaîne, ce qui signifie qu'UniswapX peut servir de routeur plus efficace pour les systèmes multi-pools comme Uniswap v4.
En règle générale, les AMM divulguent de la valeur aux arbitragistes qui négocient sur la base de prix obsolètes au sommet des blocs, comme indiqué dans le document sur les pertes et le rééquilibrage. Nous pouvons utiliser la taxe MEV pour permettre à AMM de capturer le MEV. Par souci de simplicité, nous verrons comment fonctionner sur AMM sans liquidité centralisée. (Si vous souhaitez savoir comment résoudre ce type de problème en mutualisant les liquidités, Sorella publiera bientôt une solution.)
AMM peut capturer le MEV en facturant des frais supplémentaires en fonction des frais de priorité de transaction, lui permettant de mettre aux enchères le MEV. le droit d’être le premier à échanger un bloc. Il existe plusieurs façons de calculer et de valoriser ces frais. Nous en discuterons un qui est sans doute neutre – en unités de liquidité du pool, sqrt(xy). La transaction gagnante sera celle qui augmentera 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 (a comme une constante), au lieu d'appliquer la condition x_end * y_end > y_end > (sqrt(x_start * y_start) + a*priorityFeePerGas)^2
Cette formule incitera les traders d'arbitrage à négocier au prix réel, et après cette transaction, le prix médian dans le pool devrait être le prix réel.
Après la première transaction, la négociation peut se dérouler comme sur Uniswap v2 avec des frais de swap fixes. Les traders non informés qui souhaitent négocier dans le pool sans payer la taxe MEV supplémentaire se verront appliquer des frais de priorité inférieure.
Il existe de nombreuses autres façons de mettre en place une taxe MEV sur les AMM, qui auront des effets différents. Par exemple, une taxe MEV pourrait être libellée dans les jetons d'entrée ou de sortie d'un swap, pourrait affecter le pourcentage des frais de swap appliqués par un pool ou pourrait déterminer le prix minimum pour les transactions des utilisateurs. Nous pensons qu’il s’agit d’un espace de conception intéressant qui mérite d’être exploré.
Enchères rétrogrades
Par exemple, lorsqu'Alice effectue des transactions importantes sur AMM, elle crée parfois des opportunités d'arbitrage pour les « backrunners » afin de faire baisser le prix. Cela serait normalement divulgué à MEV, pas à Alice.
MEV-Share et MEVBlocker sont deux protocoles qui permettent aux utilisateurs de capturer le MEV à partir des transactions, mais ils s'appuient sur des systèmes d'enchères hors chaîne complexes. L’espace de conception des enchères de flux de commandes décrit d’autres solutions.
La taxe MEV combinée à un portefeuille de contrats intelligents basé sur l'intention nous permet de créer un système alternatif pour capturer le MEV exécuté en arrière-plan pour Alice. Supposons qu'Alice ne crée pas de transaction à effectuer sur l'AMM, mais signe plutôt une intention que n'importe qui peut soumettre au portefeuille de contrat intelligent d'Alice pour qu'elle effectue cette action. Le portefeuille de contrats intelligents d'Alice facture une taxe MEV à toute personne soumettant la transaction, et la taxe est payée à Alice.
Les chercheurs qui soumettent l'intention d'Alice auront le droit exclusif de la supprimer, car ils peuvent le faire automatiquement au cours de la même transaction. Par conséquent, si la recherche est compétitive, tous les bénéfices d'Alice devraient revenir à Alice via la taxe MEV.
Veuillez noter que ce système ne protège pas nécessairement les utilisateurs contre les attaques impliquant des transactions effectuées par des utilisateurs front-running, car les transactions effectuées par des utilisateurs front-running peuvent éviter de payer la taxe MEV à cet utilisateur. Ce problème (et certaines atténuations possibles) est abordé plus en détail dans la section Limitations ci-dessous. Néanmoins, cela pourrait au moins constituer une amélioration par rapport aux systèmes qui utilisent un pool de mémoire commun sans aucune atténuation.
En plus de ces exemples, d'autres utilisations potentielles de la taxe MEV pourraient inclure presque tout ce qui utilise actuellement des enchères hors chaîne ou néerlandaises, telles que :
Oracles capturant les oracles qu'ils créer des protocoles avec une valeur extractible par machine, tels que Oval ;
Enchères de refinancement pour les protocoles hypothécaires NFT tels que Blend ;
Liquidations de protocoles de prêt avec une valeur de fuite inférieure à celle des enchères néerlandaises
La solution ci-dessus est conçue pour capturer les interactions MEV avec une seule application. Mais parfois, les chercheurs peuvent obtenir plus de valeur en interagissant avec plusieurs applications au cours de la même transaction.
Si une seule de ces applications a une taxe MEV, tous les MEV de la transaction doivent aller à l'application avec une taxe MEV, quel que soit le niveau élevé ou bas de la taxe MEV.
Mais que se passe-t-il si la transaction du chercheur interagit avec deux applications qui utilisent la taxe MEV ? Par exemple, que se passe-t-il s'il existe un MEV qui ne peut être capturé qu'en exécutant l'une des commandes UniswapX MEV payantes ci-dessus contre un AMM payant la taxe MEV ?
Dans ce cas, le montant relatif de l'excédent de MEV capturé par chaque application dépend de la manière dont ces applications fixent leurs taxes MEV. Si la valeur app_i collectée en tant que taxe MEV est donnée par la fonction tax_i(priority), alors la priorité de la transaction gagnante peut être déterminée en résolvant la priorité dans l'équation suivante :
tax_1(priorityPerGas) + tax_2(priorityPerGas) = MEV total
(techniquement, nous pourrions ajouter un troisième élément à prioritéPerGas * gazUtilisé pour tenir compte des frais de priorité payés au proposant du bloc, mais nous l'ignorerons, dans des circonstances normales, cela fonctionne probablement Négligé)
Dans le cas simple où la taxe MEV est liée linéairement à prioritéPerGas (donc tax_1(priorityPerGas) = a_1 * prioritéPerGas), vous pouvez résoudre la part MEV reçue par chaque application :
a_1 * prioritéPerGas + a_2 * prioritéPerGas = MEV
prioritéPerGas = MEV/(a_1 + a_2)
tax_1(priorityPerGas) = (a_1/(a_1+a_2))*MEV
tax_2(priorityPerGas) = (a_2/(a_1+a_2))*MEV
Les applications sont confrontées à un compromis lors de la définition de leur propre taxe MEV : une taxe plus élevée lui confère une part plus importante du MEV inter-applications lorsqu'elle se produit, mais cela signifie que s'il existe un moyen concurrent de l'extraire, il pourrait manquer une partie du MEV inter-applications. . Par exemple, s'il existe un AMM qui facture la taxe MEV sur chaque transaction, alors la commande UniswapX de taxe MEV peut être plus susceptible d'être exécutée par un autre AMM 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 de manière à partager la MEV de manière à maximiser leurs profits respectifs. Par exemple, un AMM à taxe MEV pourrait vouloir capturer la valeur d'un seul trader informé situé en haut du bloc, mais vouloir ensuite fournir des liquidités à un taux fixe inférieur à d'autres traders et applications (y compris les applications utilisant la taxe MEV). coût. Dans ce cas, l'AMM pourrait fixer une taxe MEV relativement faible (par exemple 0,00001 $ * prioritéFeePerGas) afin que l'opération d'arbitrage (le cas échéant) ait lieu au début du bloc, puis n'imposer aucune taxe MEV sur les transactions ultérieures dans le bloc. Les applications comme UniswapX qui souhaitent interagir avec les AMM peuvent définir une taxe MEV plus élevée (par exemple 0,01 $ * prioritéFeePerGas) pour garantir que leurs transactions sont incluses une fois que le pool a déjà arbitré. Compte tenu de ces taxes relatives, même s'il n'y avait que 1 $ MEV et 50 000 $ MEV dans la commande UniswapX, l'AMM finirait par être arbitré en premier.
Nous pensons qu’il s’agit d’un vaste espace de conception digne de recherches futures.
La taxe MEV présente certaines complexités et inconvénients, qui, selon nous, constituent des domaines intéressants pour des recherches futures.
La taxe MEV n'est pas compatible avec les incitations pour les proposants de blocs monopolistiques. Ils ne fonctionnent que s'il existe des règles du jeu équitables pour l'inclusion des transactions, ce qui n'est le cas que si les proposants de blocs suivent ce que nous appelons les règles de « priorisation compétitive » plutôt que de maximiser leurs propres revenus. Une liste informelle de règles suggérées, comprenant, mais sans s'y limiter, les suivantes :
Prioriser. Les transactions au sein du bloc doivent être classées par prioritéFeePerGas dans l'ordre décroissant.
Résistez à la censure. Si le proposant du bloc reçoit la transaction t1 pendant le bloc et que le bloc n'est pas plein ou contient une transaction t2, telle que t2.priorityFeePerGas < t1.priorityFeePerGas, alors le bloc doit contenir la transaction t1.
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 quelqu'un d'autre avant de les soumettre à un bloc, ni utiliser le contenu de ces transactions comme entrée pour créer leurs propres transactions.
Pas d'avis final. Les proposants de blocs doivent définir une heure de blocage claire. Avant cette heure, ils accepteront les demandes de transaction de n'importe qui ; après cette heure, ils n'accepteront plus les demandes de transaction de qui que ce soit.
La violation d'une ou plusieurs de ces propriétés peut nuire à l'efficacité de la taxe MEV. Les proposants de bloc qui violent la censure peuvent éviter la plupart des taxes MEV en excluant les transactions concurrentes et en soumettant des transactions de priorité zéro qui profitent d'elles-mêmes. Les proposants de blocage qui violent la confidentialité avant la transaction peuvent voler le MEV d'autres transactions ou consulter leurs frais prioritaires pour savoir exactement à quel niveau ils doivent fixer leurs frais, tandis que les proposants de blocage qui sont en mesure de soumettre des transactions plus tard que les autres bénéficieront de Free'Enfin voir. si vous souhaitez obtenir l'opportunité à un prix plus élevé que d'autres, ces deux éléments peuvent créer des problèmes de sélection adverse qui en fin de compte entravent la concurrence
Malheureusement, alors que le premier attribut est facilement disponible dans l'application de la couche d'accord, mais applique d'autres propriétés. de manière sans confiance est une question ouverte
En l'absence d'application au niveau du protocole, il faut faire confiance à un seul séquenceur qui s'engage à respecter ces règles pour ne pas s'écarter de ces règles et si le proposant sous-traite la construction des blocs à un concurrent. aux enchères maximisant les revenus (comme le MEV-Boost d'Ethereum L1), les blocs peuvent ne pas les suivre
Ces problèmes peuvent être résolus par un seul ordonnateur de confiance », ce séquenceur promet d'utiliser un ordre prioritaire compétitif pour la construction de blocs. Ils peuvent également être résolus par des mécanismes décentralisés utilisant une combinaison de consensus, de cryptographie et/ou d’un environnement d’exécution fiable, comme Angstrom de Sorella, SUAVE de Flashbots, des enchères sans leader ou la multiplicité.
Une exception au fonctionnement normal de la taxe MEV se produit lorsqu'un bloc est complètement plein. Dans ce cas, le proposant du bloc devra peut-être abandonner les transactions de moindre priorité au lieu de simplement les inclure dans le bloc. Étant donné que les transactions qui interagissent avec les applications fiscales MEV peuvent avoir des frais de priorité très faibles, ces applications peuvent être évincées par des applications qui n'utilisent pas les taxes MEV ou qui ont des taxes MEV très faibles. Cependant, dans une chaîne qui utilise un mécanisme comme EIP-1559 pour fixer des frais de base distincts, il devrait être relativement rare que les blocs soient complètement remplis. De plus, étant donné que certaines transactions doivent être retardées lorsqu’un bloc est plein, retarder les transactions moins urgentes en fixant une taxe MEV plus élevée pourrait être une solution raisonnable.
La taxe MEV repose en réalité sur des enchères en bloc unique où chaque « offre » est une transaction. L'un des inconvénients de ces enchères est que les offres échouées entraînent souvent l'inclusion des transactions restaurées dans la chaîne, le paiement de certains frais de base et la congestion de la chaîne.
Si le trieur pouvait exclure complètement les transactions ayant échoué, cela atténuerait ce problème, bien que cela soit difficile à réaliser même avec un trieur centralisé. (Il ne respecterait pas non plus strictement les propriétés de résistance à la censure mentionnées ci-dessus, bien que cette définition puisse être modifiée.) Des séquenceurs plus sophistiqués pourraient optimiser ce processus en permettant aux transactions de spécifier à quelles enchères contestées elles participent, permettant ainsi au séquenceur d'obtenir suffisamment d'informations. pour ignorer les transactions ultérieures dont il sait qu'elles échoueront. La taxe MEV ne fonctionne que s'il existe une concurrence entre les chercheurs, ce qui signifie que l'opportunité doit être connue dans une certaine mesure. Pour des applications comme AMM, où les opportunités sont visibles en chaîne, cela devrait se produire naturellement. Mais pour des applications telles que le routage basé sur l'intention ou les enchères en arrière-plan, cela signifie que l'application devra peut-être partager l'intention de l'utilisateur avec le chercheur.
Par exemple, supposons qu'Alice souhaite acheter des jetons à faible liquidité en utilisant le protocole d'enchères back-end décrit ci-dessus. Elle publie l'intention signée du portefeuille de contrat intelligent d'acheter le jeton sur l'AMM et définit une certaine tolérance de glissement. Un chercheur peut participer à une transaction hautement prioritaire pour pousser le prix de ce jeton jusqu'à sa tolérance de glissement sans exécuter la commande de l'utilisateur. Le gagnant Bob peut alors satisfaire les intentions d'Alice de manière non compétitive en l'incluant dans une transaction de faible priorité et en l'exécutant à l'envers, prenant ainsi en sandwich la transaction d'Alice et lui donnant un prix moins bon tout en échappant à sa taxe MEV. Des problèmes similaires peuvent survenir lors de l’achat de NFT.
Il est à noter qu'une telle attaque est risquée pour Bob car il ne peut garantir l'atomicité entre l'achat du token et sa vente à Alice. Un Bob naïf peut tomber dans le piège du « serrage et du déchirement » : Alice annonce d'abord son intention de s'acheter un jeton sans valeur, et Bob achète le jeton afin de contourner sa transaction, mais avant que Bob ne termine le contournement, Alice retire son intention. .
Les applications peuvent également atténuer ce problème en limitant l'ensemble des chercheurs avec lesquels ils partagent leur intention et en surveillant leur comportement, comme le font de nombreuses enchères de flux de commandes existantes.
Il est également possible de combiner la taxe MEV avec des fonctionnalités de création respectueuses de la confidentialité, comme ce que Flashbots a envisagé pour la conception SUAVE.
Enfin, si Alice décide que le coût du partage de l'intention dépasse les avantages de la recherche concurrentielle, elle peut construire elle-même la transaction et la soumettre directement au bloc. Comme mentionné ci-dessus, une mise en œuvre idéale d’une priorisation compétitive fournirait aux proposants de bloc une confidentialité avant la transaction.
Enchères prioritaires pour le gaz. L'article Flash Boys 2.0, qui a inventé le terme « valeur extractible par les mineurs », examine certaines des dynamiques de priorisation dans les blockchains décentralisées. Le document indique que les mineurs d'Ethereum (lorsque le réseau utilisait une preuve de travail) donnaient déjà la priorité aux transactions, 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 dans la première zone. blocs, ce qui fait que la majorité des MEV arbitrés par des bourses décentralisées appartiennent aux mineurs.
Premier arrivé, premier servi. Certaines tentatives visant à atténuer le MEV au moyen de règles d'ordre des transactions, telles que l'ordonnateur actuel de Themis ou d'Arbitrum One (7), se concentrent 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 trier les transactions dans le ordonne qu'ils les voient.
La priorisation adopte une approche différente : traiter les transactions arrivant dans un délai donné de manière égale et les trier selon leur priorité déclarée.
Le premier arrivé, premier servi est difficile à mettre en œuvre ou même à définir dans un environnement réseau réel avec plusieurs validateurs. Même avec un seul séquenceur fiable, cela peut entraîner des conflits de latence inutiles et du spam. Enfin, une taxe MEV pourrait permettre d’éliminer certains types de MEV que le premier arrivé, premier servi ne peut pas éliminer, comme les bénéfices d’arbitrage résultant de « sauts » discrets des prix des actifs. Les avantages potentiels de l'ordre prioritaire par rapport à l'ordre premier arrivé, premier servi sont liés dans une certaine mesure aux avantages de l'échange en temps discret par rapport à l'échange en temps continu discutés dans Budish, Cramton, Shim (2015).
Pendant ce temps, alors que la priorisation semble perdre de la valeur vers MEV par défaut, cet article montre comment concevoir votre application pour la retrouver.
Partage des coûts. Blast est Ethereum L2 et partage une partie de la priorité et des frais de base avec les contrats intelligents accessibles dans les transactions.
La taxe MEV permet quelque chose de similaire (au moins pour les frais de priorité) mais peut être implémentée au niveau de l'application sur n'importe quelle chaîne en utilisant une priorisation compétitive sans nécessiter de support spécial pour le partage des frais. Ils permettent également aux applications de définir leur propre taxe en tant que fonction personnalisée des frais de priorité, offrant ainsi une plus grande flexibilité et améliorant potentiellement la composabilité des applications compatibles MEV.
Solution sans confiance. Cet article se concentre sur les motivations des plateformes à utiliser la priorisation compétitive et les moyens d’exploiter la plateforme, plutôt que sur la manière de l’appliquer de manière sans confiance.
Chacune des autres propriétés requises pour une priorisation compétitive a déjà été discutée de manière significative. Par exemple, dans Fox, Pai, Resnick (2023), les auteurs discutent des vulnérabilités des enchères en chaîne en l'absence de résistance à la censure et décrivent la conception d'enchères résistantes à la censure utilisant plusieurs proposants simultanés. Cependant, ils n’ont pas suggéré une séquence spécifique de transactions.
Il existe d'autres recherches sur la création de mécanismes de création de blocs minimisant la confiance, notamment SUAVE de Flashbots, Angstrom de Sorella, Leaderless Auctions, Timeboost décentralisé d'Espresso et Offchain Labs et l'inclusion forcée des transactions publiques de Péter Szilági.
Nous espérons que cet article encouragera L2 à envisager d'utiliser la priorisation (prise en charge par défaut par la pile OP) et encouragera les applications à essayer les taxes MEV lorsqu'elles sont prises en charge. Nous espérons également que cela inspirera de nouvelles recherches sur les protocoles de priorisation compétitifs minimisant la confiance sur L1 et L2.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
