Nouvel article de Paradigm : La taxe MEV et la priorisation
TechFlow SélectionTechFlow Sélection
Nouvel article de Paradigm : La taxe MEV et la priorisation
Un mécanisme de taxe MEV qui permet à n'importe quelle application de capturer son propre MEV tout en préservant la composable.
Dédié à des analyses Web3 approfondiesAuteurs : Dan Robinson, Dave White
Traduction : Joyce, BlockBeats
Introduction
Dans cet article, nous présentons la taxe MEV, un mécanisme que toute application peut utiliser pour capturer sa propre MEV. Ce mécanisme est désormais utilisable sur des L2 basées sur OP Stack comme OP Mainnet, Base et Blast, car les proposants de blocs sur ces chaînes suivent un ensemble de règles que nous appelons « tri par priorité concurrentiel ».
Pour imposer une taxe MEV sur l'une de ces chaînes, un contrat intelligent prélève des frais proportionnels aux frais prioritaires d'une transaction. Si une application perçoit 99 dollars de taxe MEV pour chaque dollar de frais prioritaire versé par un searcher, elle peut ainsi capter 99 % de la MEV concurrentielle générée par cette transaction.
La taxe MEV est une technique simple qui ouvre un vaste espace de conception. Vous pouvez la voir comme permettant à n'importe quelle application sur la chaîne d'exécuter sa propre enchère MEV personnalisée sans infrastructure hors chaîne, simplement en se connectant à une seule enchère partagée gérée par les proposants de blocs.
Nous expliquons comment utiliser les taxes MEV pour résoudre trois problèmes majeurs dans la recherche sur la MEV :
des routeurs de DEX (échange décentralisé) optimisant le prix reçu par les traders ;
des AMM (marchés automatisés de liquidités) minimisant les pertes subies par les fournisseurs de liquidités liées au rééquilibrage (LVR) ;
des portefeuilles permettant aux utilisateurs de capturer tout MEV de type « backrun » créé par leurs transactions ;
mais il y a un problème. Les taxes MEV ne fonctionnent que si les proposants de blocs respectent strictement les règles de tri par priorité concurrentiel, notamment en classant les transactions selon leurs frais prioritaires, sans censure, espionnage ni retardement. Si les proposants s'écartent de ces règles, ils peuvent contourner la taxe MEV et s'approprier la valeur. Ainsi, aujourd'hui, les taxes MEV reposent sur des ordonnanceurs (« sequencers ») L2 de confiance, et pourraient ne pas fonctionner du tout sur Ethereum L1, où la construction de blocs est dominée par des enchères concurrentielles entre bâtisseurs visant à maximiser les revenus des proposants.
Malgré cela, la puissance et la flexibilité des taxes MEV suggèrent que, pour les plateformes capables d'offrir ce service, le tri par priorité pourrait être le bon choix. La simplicité relative du tri par priorité concurrentiel indique qu'il pourrait exister une méthode viable pour l'appliquer de manière décentralisée, sans avoir à faire confiance à un seul ordonnanceur. Nous espérons que cet article stimulera davantage de recherches sur cette question.
Tri par priorité
Lorsqu'une personne envoie une transaction sur Ethereum L1 ou L2, elle spécifie des frais prioritaires, payés au proposant de bloc. On peut imaginer cela défini comme priorityFeePerGas (frais de priorité par unité de gaz), un nombre multiplié par le gaz utilisé dans la transaction pour obtenir builderPriorityFee — le paiement total en ETH.
Le protocole Ethereum ne stipule pas que les transactions d'un bloc doivent être triées par ordre décroissant de priorityFeePerGas. Cependant, c'est une méthode populaire pour construire des blocs — par exemple, c'est celle utilisée par défaut par les ordonnanceurs des chaînes OP Stack, ainsi que par geth et reth. Le tri par priorité permet non seulement aux traders d'exprimer efficacement l'urgence de leur transaction, mais transfère aussi naturellement certains types de MEV aux proposants de blocs.
Cela se produit parce que le tri par priorité transforme la compétition pour la MEV en une enchère de gas prioritaire. Quand une opportunité de profit sans risque apparaît via une interaction avec la chaîne, par exemple par arbitrage entre un AMM et une bourse centralisée, les searchers rivalisent pour l'exploiter. Si la chaîne utilise le tri par priorité pour déterminer l'inclusion et l'ordre des transactions, les searchers se font concurrence en fixant des frais prioritaires élevés.
Dans un scénario concurrentiel où les profits sans risque sont arbitrés à zéro, le searcher gagnant devrait finalement payer la totalité de la MEV sous forme de frais prioritaires. Ainsi, si une interaction avec un contrat permet de générer un profit de 100 ETH, la première transaction à revendiquer ce profit fixera des frais prioritaires de 100 ETH. (Nous discutons de certaines nuances dans la section Limitations.)
Taxe MEV
Supposons qu’un contrat intelligent souhaite capturer la MEV générée par toute transaction interagissant avec lui. Il existe de nombreuses recherches sur différentes façons spécifiques dont un contrat intelligent pourrait tenter de capter sa propre MEV.
Mais en réalité, nous n’avons pas besoin de connaître quoi que ce soit sur l’application. Si nous savons que le bloc est construit via un tri par priorité concurrentiel, alors nous avons un signal général sur la quantité de MEV dans une transaction : les frais prioritaires.
Nous proposons que le contrat intelligent puisse examiner les frais prioritaires de la transaction et prélever ses propres frais en tant que fonction croissante de ceux-ci. Par exemple, un contrat pourrait exiger que l’appelant transfère au contrat une somme égale à applicationPriorityFee = 99 * proposerPriorityFee en ETH.
Ce nouveau frais est payé par le searcher envoyant la transaction, modifiant ainsi son comportement. Si une opportunité offre 100 MEV, la transaction gagnante fixera désormais seulement 1 ETH de frais prioritaires, entraînant un paiement total de 100 ETH (1 ETH au proposant de bloc, 99 ETH au contrat intelligent). Tout frais plus élevé rendrait la transaction non rentable ; tout frais inférieur ferait perdre l’opportunité à un concurrent ayant fixé des frais plus élevés. Cela signifie que le contrat intelligent a capturé 99 % de la MEV de la transaction.
Nous appelons cette charge supplémentaire perçue par le contrat intelligent une « taxe MEV ». La taxe MEV permet à une application de s'approprier le tri par priorité à son avantage, lui permettant de recapturer la MEV pour ses utilisateurs au lieu de la laisser fuir vers les proposants de blocs.
Si cette taxe croît suffisamment vite en fonction de priorityFeePerGas, le proposant ne recevra qu'une fraction négligeable de la MEV. Comme priorityFeePerGas est exprimé en wei (un milliardième d'ETH), nous devons gérer une grande précision. Par exemple, tant que la taxe MEV est assez sensible, un priorityFeePerGas de 50 000 entraînera une taxe excessive, et le montant total versé au proposant sera inférieur à 0,01 dollar. (5)
Toutefois, une mise en garde importante : comme discuté dans la section « Limitations », la taxe MEV ne fonctionne que si les proposants de blocs suivent certaines règles (que nous appelons « tri par priorité concurrentiel »), et ne s'en écartent pas pour maximiser leurs propres revenus. Appliquer ces règles de manière non fiable reste un problème ouvert.
Capture de MEV par application unique
Ici, nous décrivons comment, sur une chaîne garantissant que la construction de bloc suit le tri par priorité concurrentiel, la taxe MEV peut aider à atténuer trois problèmes importants liés à la MEV : améliorer l’exécution des échanges par les interfaces de DEX, réduire les pertes d’arbitrage des LP sur les AMM, et permettre aux portefeuilles de réduire la fuite de MEV des utilisateurs en vendant leurs droits de « backrun ».
Routeurs de DEX décentralisés
Dans les protocoles de routage de DEX basés sur des intentions comme UniswapX et 1inch Fusion, un utilisateur (Alice) signe une intention d’échange, et des searchers rivalisent pour exécuter cette intention au meilleur prix possible.
La version actuelle d’UniswapX utilise deux mécanismes concurrentiels : une enchère hollandaise, où le prix limite d’Alice baisse progressivement jusqu’à ce qu’un searcher remplisse l’ordre ; et une enchère RFQ (requête de cotation) hors chaîne initiale pour fixer le prix de départ de l’enchère hollandaise.
Sur une plateforme garantissant le tri par priorité concurrentiel, UniswapX pourrait remplacer ces deux mécanismes par un seul : la taxe MEV. Cela pourrait se faire en permettant à Alice de signer un ordre que n’importe qui peut immédiatement exécuter, mais dont le prix d’exécution dépend des frais prioritaires 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 minimumPrice + ($0,01 * priorityFeePerGas). minimumPrice pourrait être une valeur fixe clairement inférieure au prix actuel.
Les searchers rivaliseront en soumettant des transactions pour exécuter l’ordre d’Alice. La transaction ayant les frais prioritaires les plus élevés et ne provoquant pas de réversion terminera l’ordre, ce qui devrait garantir à Alice le meilleur prix trouvable. (Des exceptions sont discutées dans la section Limitations.)
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 de la transaction gagnante sera d’environ 50 000. (Notez que dans une transaction consommant 200 000 gaz, cela conduirait à un paiement d’environ 10 milliards de wei au proposant de bloc, soit environ 0,000035 dollar.)
Comparé aux mécanismes existants dans UniswapX, cela présente plusieurs avantages potentiels.
Contrairement aux ordres utilisant une enchère hollandaise, les ordres avec taxe MEV peuvent être exécutés plus rapidement et à un meilleur prix. Comme discuté ici, les enchères hollandaises sur chaîne fuient de la valeur vers la MEV à cause des variations de prix entre blocs, et peuvent nécessiter plusieurs blocs pour aboutir. En revanche, les ordres avec taxe MEV sont généralement exécutés dans le prochain bloc, capturant la quasi-totalité de la MEV.
Contrairement aux RFQ hors chaîne, l’enchère avec taxe MEV se déroule automatiquement lors de l’exécution de la transaction. Cela garantit que le gagnant est engagé à exécuter l’ordre uniquement si la transaction réussit. Cela facilite la concurrence entre liquidités hors chaîne et sur chaîne, rendant UniswapX un routeur plus efficace pour des systèmes multicouches comme Uniswap v4.
AMM
En général, les AMM fuient de la valeur vers les arbitragistes, qui échangent selon des prix obsolètes au sommet du bloc, comme discuté dans le papier sur la perte versus rééquilibrage (LVR). Nous pouvons utiliser la taxe MEV pour permettre aux AMM de capturer cette MEV. Pour simplifier, nous discutons ici de son fonctionnement sur un AMM sans liquidité concentrée. (Si vous êtes intéressé par une solution avec liquidité concentrée, Sorella publiera bientôt une approche.)
Un AMM peut capturer la MEV en percevant des frais supplémentaires fonction des frais prioritaires de la transaction, autorisant ainsi une enchère pour le droit d’être première transaction du bloc. Plusieurs méthodes permettent de calculer et tarifer ces frais. Nous en examinons une relativement neutre — exprimée en unités de liquidité du pool, sqrt(xy). La transaction gagnante serait celle qui maximise l’augmentation de la liquidité du pool.
Lors de l’exécution de la première transaction sur le pool dans un bloc, le pool pourrait appliquer la condition (avec a une constante donnée), au lieu de x_end * y_end > x_start * y_start :
x_end * y_end > (sqrt(x_start * y_start) + a*priorityFeePerGas)^2
Cette formule incite les traders d’arbitrage à échanger au prix réel, après quoi le prix médian du pool devrait refléter le prix véritable.
Après cette première transaction, les autres échanges peuvent se dérouler comme sur Uniswap v2, avec des frais fixes. Les traders innocents souhaitant échanger sans payer la taxe MEV supplémentaire fixeront des frais prioritaires faibles.
De nombreuses autres méthodes existent pour appliquer une taxe MEV sur un AMM, produisant différents effets. Par exemple, la taxe MEV pourrait être exprimée en jeton d’entrée ou de sortie de l’échange, influencer le pourcentage de frais appliqué, ou déterminer le prix minimum d’exécution. Nous pensons que c’est un espace de conception intéressant à explorer.
Enchères de backrun
La description ci-dessus montre comment concevoir certaines applications pour éviter les fuites de MEV. Mais que faire si un portefeuille veut aider ses utilisateurs à capturer la MEV générée par n’importe quelle transaction, même avec des applications n’ayant pas de taxe MEV ?
Par exemple, quand Alice effectue un gros échange sur un AMM, elle crée parfois des opportunités d’arbitrage que des « backrunners » exploitent pour ramener le prix à l’équilibre. Cette valeur fuit habituellement vers la MEV, pas vers Alice.
MEV-Share et MEVBlocker sont deux protocoles permettant aux utilisateurs de capturer de la MEV, mais ils reposent sur des systèmes complexes d’enchères hors chaîne. L’espace de conception des enchères de flux d’ordres décrit d’autres solutions.
Combinée à un portefeuille intelligent basé sur des intentions, la taxe MEV permet de construire un système alternatif pour capturer la MEV de backrun d’Alice. Supposons qu’au lieu de créer une transaction directe sur un AMM, Alice signe une intention que n’importe qui peut soumettre via son portefeuille intelligent pour exécuter l’action. Ce portefeuille intelligent perçoit une taxe MEV sur toute soumission, reversée à Alice.
Le searcher soumettant l’intention d’Alice obtient le droit exclusif de la « backrunner », car il peut l’exécuter automatiquement dans la même transaction. Ainsi, si la concurrence est effective, tous les profits devraient revenir à Alice via la taxe MEV.
Notez que ce système ne protège pas nécessairement contre les attaques de type « frontrunning », car une transaction de frontrunning pourrait éviter de payer la taxe MEV à l’utilisateur. Ce problème (et des solutions potentielles) est discuté plus en détail dans la section Limitations. Néanmoins, c’est déjà une amélioration par rapport aux systèmes utilisant un mempool public sans aucune mesure d’atténuation.
Autres cas d’usage
Au-delà de ces exemples, d'autres usages potentiels de la taxe MEV incluent presque toutes les applications actuellement utilisant des enchères hors chaîne ou des enchères hollandaises, telles que :
des protocoles d’oracle capturant la valeur extractible d’oracle (OEV) qu’ils créent, comme Oval ;
des enchères de refinancement pour des protocoles de prêt NFT comme Blend ;
des protocoles de prêt avec moins de fuite de valeur lors des liquidations comparé aux enchères hollandaises ;
Capture de MEV inter-applications
Les solutions ci-dessus visent à capturer la MEV issue d’interactions avec une seule application. Mais parfois, un searcher peut extraire plus de valeur en interagissant avec plusieurs applications dans une même transaction.
Si une seule des applications applique une taxe MEV, alors toute la MEV de la transaction devrait aller à cette application, quel que soit le niveau de la taxe.
Mais que se passe-t-il si la transaction du searcher interagit avec deux applications appliquant chacune une taxe MEV ? Par exemple, si une MEV ne peut être capturée qu’en remplissant un ordre UniswapX avec taxe MEV sur un AMM qui applique aussi une taxe MEV ?
Dans ce cas, la répartition relative de la MEV excédentaire entre les applications dépend de la façon dont elles définissent leurs taxes MEV. Si la valeur perçue par l’application i est donnée par la fonction tax_i(priority), alors le niveau de priorité de la transaction gagnante peut être trouvé en résolvant :
tax_1(priorityPerGas) + tax_2(priorityPerGas) = MEV total
(Techniquement, on pourrait ajouter un terme priorityPerGas * gasUsed pour les frais prioritaires versés au proposant, mais nous l’ignorons ici, car il est négligeable dans des conditions normales.)
Dans le cas simple où la taxe MEV est linéaire en priorityPerGas (donc tax_1(priorityPerGas) = a_1 * priorityPerGas), on peut résoudre la part de MEV reçue par chaque application :
a_1 * priorityPerGas + a_2 * priorityPerGas = MEV
priorityPerGas = MEV/(a_1 + a_2)
tax_1(priorityPerGas) = (a_1/(a_1+a_2))*MEV
tax_2(priorityPerGas) = (a_2/(a_1+a_2))*MEV
En fixant leur taxe MEV, les applications font un compromis : une taxe plus élevée leur donne une plus grande part lors de MEV inter-applications, mais elles risquent de manquer certaines opportunités si d'autres moyens concurrents d'extraction existent. Par exemple, si un AMM impose une taxe MEV sur chaque transaction, un ordre UniswapX avec taxe MEV pourrait être plus facilement exécuté par un autre AMM ou un fill provider hors chaîne.
Dans bien des cas, un équilibre peut émerger où deux applications ajustent leurs taxes MEV pour partager la valeur de manière à maximiser leurs profits respectifs. Par exemple, un AMM avec taxe MEV pourrait vouloir extraire de la valeur d’un seul trader informé au sommet du bloc, puis offrir de la liquidité à taux fixe bas aux autres traders et applications (y compris celles avec taxe MEV). Dans ce cas, l’AMM pourrait fixer une taxe MEV relativement faible (ex. $0,00001 * priorityFeePerGas), permettant aux arbitrages d’avoir lieu tôt dans le bloc, puis n’appliquer aucune taxe MEV aux transactions suivantes. Une application comme UniswapX souhaitant interagir avec cet AMM pourrait fixer une taxe plus élevée (ex. $0,01 * priorityFeePerGas) pour garantir l’inclusion après que l’AMM ait été arbitrée. Avec ces niveaux relatifs, même si l’ordre UniswapX ne contient que 1 dollar de MEV contre 50 000 dollars sur l’AMM, ce dernier serait d’abord arbitrée.
Nous pensons que cet espace de conception mérite des recherches futures.
Limitations
Les taxes MEV présentent des complexités et inconvénients, que nous jugeons tous sujets à de futures recherches.
Incompatibilité d’incitations
Les taxes MEV ne sont pas compatibles avec les incitations d’un proposant de bloc monopolistique. Elles ne fonctionnent que si l’inclusion des transactions est concurrentielle, ce qui suppose que les proposants respectent les règles de « tri par priorité concurrentiel », sans chercher à maximiser leurs revenus. Voici quelques règles suggérées (non exhaustives) :
Tri par priorité : les transactions dans un bloc doivent être triées par ordre décroissant de priorityFeePerGas.
Anti-censure : si un proposant reçoit une transaction t1 durant la période de construction du bloc, et que le bloc n’est pas plein ou contient une transaction t2 avec t2.priorityFeePerGas < t1.priorityFeePerGas, alors t1 doit être incluse.
Confidentialité pré-bloc : les proposants doivent accepter les transactions via un point d’accès privé, sans les partager ni en tirer parti pour construire leurs propres transactions.
Pas de dernier regard : les proposants doivent fixer un délai clair pendant lequel ils acceptent les transactions, après quoi plus aucune ne sera prise en compte.
La violation d’une ou plusieurs de ces propriétés peut affaiblir l’efficacité des taxes MEV. Un proposant censeur pourrait éviter la plupart des taxes MEV en excluant les transactions concurrentes et en soumettant une transaction à frais nuls pour son propre profit. Un proposant violant la confidentialité pourrait voler de la MEV ou observer les frais pour savoir exactement combien proposer, tandis qu’un proposant pouvant soumettre plus tard bénéficierait d’un « dernier regard », créant un problème de sélection adverse nuisant à la concurrence.
Malheureusement, bien que la première règle puisse être facilement appliquée au niveau du protocole, imposer les autres de manière non fiable reste un problème ouvert.
Sans imposition protocolaire, il faut faire confiance à un seul ordonnanceur s’engageant à respecter ces règles. De plus, si les proposants externalisent la construction de blocs à une enchère concurrentielle maximisant les revenus (comme MEV-Boost sur Ethereum L1), les blocs pourraient ne pas les suivre.
Ces problèmes peuvent être « résolus » par un ordonnanceur de confiance s’engageant à utiliser le tri par priorité concurrentiel. Ils pourraient aussi être abordés par des mécanismes décentralisés combinant consensus, cryptographie ou environnements d’exécution fiables, comme Angstrom de Sorella, SUAVE de Flashbots, les enchères sans leader ou la multiplicité.
Blocs pleins
Une exception au bon fonctionnement de la taxe MEV survient lorsque les blocs sont pleins. Dans ce cas, le proposant peut devoir rejeter des transactions à faible priorité plutôt que de les inclure. Comme les transactions avec applications à taxe MEV ont souvent de très faibles frais, elles risquent d’être évincées par des applications sans taxe ou à taxe faible. Toutefois, sur des chaînes utilisant un mécanisme similaire à EIP-1559 pour fixer une base de frais séparée, les blocs pleins devraient être rares. En outre, retarder des transactions à faible urgence via une taxe MEV plus élevée pourrait être un résultat acceptable.
Transactions rejetées
La taxe MEV repose en pratique sur une enchère monocellulaire, où chaque « offre » est une transaction. Un inconvénient est que les offres perdantes entraînent souvent des transactions rejetées incluses sur la chaîne, payant des frais de base et causant de la congestion.
Un ordonnanceur capable d’exclure complètement les transactions perdantes atténuerait ce problème, bien que difficile à réaliser même avec un ordonnanceur centralisé. (Cela violerait aussi strictement la propriété anti-censure, bien que celle-ci puisse être ajustée.) Des ordonnanceurs plus sophistiqués pourraient optimiser en permettant aux transactions d’indiquer l’enchère concernée, donnant assez d’information pour sauter celles destinées à échouer.
Fuite d’intentions utilisateur
La taxe MEV ne fonctionne que s’il existe une concurrence entre searchers, donc l’opportunité doit être relativement connue. Pour des applications comme les AMM, visibles sur chaîne, cela se produit naturellement. Mais pour des applications basées sur des intentions ou des enchères de backrun, cela implique de partager les intentions des utilisateurs avec les searchers.
Dans certains cas, la perte de confidentialité temporaire due à la diffusion de l’intention avant exécution peut fuir de la valeur de manière irrécupérable par la taxe MEV.
Par exemple, supposons qu’Alice veuille acheter un jeton peu liquide via le protocole de backrun décrit. Elle publie une intention signée via son portefeuille intelligent, avec une tolérance au glissement donnée. Un searcher (Bob) peut pousser le prix du jeton à la limite de sa tolérance dans une transaction à haute priorité, sans exécuter l’ordre. Puis, dans une transaction à faible priorité, Bob peut exécuter l’intention d’Alice de manière non concurrentielle, la sandwichant et lui offrant un mauvais prix, tout en évitant la taxe MEV. Un problème similaire peut survenir avec l’achat de NFT.
Notez que cette attaque comporte un risque pour Bob, car rien ne garantit l’atomicité entre l’achat et la vente à Alice. Un Bob naïf pourrait tomber dans un piège de « sandwich tear » : Alice publie une intention d’acheter un jeton sans valeur, Bob l’achète pour le sandwich, mais Alice retire son intention avant que Bob ne termine.
Les applications peuvent atténuer cela en limitant le groupe de searchers avec qui elles partagent les intentions, et en surveillant leur comportement, comme le font nombre d’enchères de flux d’ordres.
On peut aussi combiner la taxe MEV avec des fonctionnalités de builders respectueuses de la vie privée, comme envisagé par Flashbots pour SUAVE.
Enfin, si Alice juge que le coût de partager son intention dépasse les bénéfices de la concurrence, elle peut construire elle-même la transaction et la soumettre directement. Comme mentionné, une implémentation idéale du tri par priorité concurrentiel garantirait la confidentialité pré-bloc aux proposants.
Discussions connexes
Enchères de gas prioritaire. Le papier Flash Boys 2.0 étudie la dynamique du tri par priorité dans les blockchains décentralisées, introduisant le terme « miner extractable value » (MEV). Il montre que les mineurs Ethereum (sous preuve de travail) triaient déjà les transactions par priorité, et que les arbitragistes comptaient sur ce comportement via des « enchères de gas prioritaire », faisant revenir la majorité de la MEV des arbitrages DEX aux mineurs.
Premier arrivé, premier servi. Certaines tentatives d’atténuer la MEV par le tri des transactions, comme Themis ou l’ordonnanceur actuel d’Arbitrum One (7), se concentrent sur une règle différente : le traitement par ordre d’arrivée (« fair ordering »), où le proposant doit trier les transactions selon leur heure de réception.
Le tri par priorité adopte une approche différente : traiter équitablement les transactions arrivées dans un même laps de temps, en les triant selon leur niveau de priorité déclaré.
Le traitement « premier arrivé, premier servi » est difficile à définir ou appliquer dans un réseau réel à validateurs multiples. Même avec un seul ordonnanceur de confiance, cela peut mener à des courses aux délais inefficaces et à du spam. Enfin, la taxe MEV pourrait éliminer certains types de MEV que le tri chronologique ne peut pas, comme les profits d’arbitrage liés aux sauts discontinus de prix. L’avantage potentiel du tri par priorité par rapport au traitement chronologique est lié, en partie, à l’avantage du temps discret sur le temps continu discuté par Budish, Cramton, Shim (2015).
Pendant ce temps, bien que le tri par priorité semble par défaut fuir de la valeur vers la MEV, cet article montre comment concevoir des applications pour la récupérer.
Partage de frais. Blast est une L2 Ethereum qui partage une partie des frais prioritaires et de base avec les contrats intelligents accédés dans la transaction.
La taxe MEV permet une chose similaire (au moins pour les frais prioritaires), mais peut être implémentée au niveau applicatif sur toute chaîne utilisant le tri par priorité concurrentiel, sans support spécifique. Elle offre aussi plus de flexibilité, permettant aux applications de définir leurs propres fonctions de taxation, augmentant potentiellement la composable des applications sensibles à la MEV.
Solutions sans confiance. Cet article se concentre sur les motivations des plateformes à utiliser le tri par priorité concurrentiel et sur la manière de les exploiter, pas sur la façon de l’imposer sans confiance.
Des discussions importantes ont déjà eu lieu sur chacune des autres propriétés requises. Par exemple, dans Fox, Pai, Resnick (2023), les auteurs analysent les vulnérabilités des enchères sur chaîne en l’absence de résistance à la censure, et proposent un design d’enchère anticine avec plusieurs proposants concurrents. Toutefois, ils ne suggèrent pas un ordre particulier des transactions.
D’autres recherches existent sur des mécanismes de construction de blocs minimisant la confiance, incluant SUAVE de Flashbots, Angstrom de Sorella, Leaderless Auctions, Espresso, Timeboost décentralisé d’Offchain Labs, et l’inclusion forcée de transactions publiques de Péter Szilági.
Nous espérons que cet article encouragera les L2 à envisager le tri par priorité (supporté par défaut par OP Stack), et les applications à expérimenter la taxe MEV là où c’est supporté. Nous espérons aussi qu’il stimulera davantage de recherches sur des protocoles de tri par priorité concurrentiel à confiance minimale, sur L1 comme sur L2.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
Paradigm
