Le protocole Ethereum et l'écosystème plus large visent continuellement à améliorer la valeur que peut fournir Ethereum. Un goulot d'étranglement clé à l'échelle de l'écosystème pour améliorer Ethereum a été la Valeur Maximale Extractible (MEV) MEV fait référence à la valeur maximale que l'agent de protocole responsable de l'inclusion, de l'ordonnancement et de l'exclusion des transactions dans un bloc peut extraire du système. Ce post résume les méthodes proposées pour atténuer les effets négatifs de MEV sur les applications et le protocole, et examine les futures orientations de recherche.

Ce post est organisé comme suit:

La première section propose une catégorisation bidimensionnelle des techniques de mitigation MEV hors protocole. Un exemple de chaque catégorie est exploré.

La section suivante explore pourquoi le protocole Ethereum ne peut pas fonctionner comme l'infrastructure qui empêche ou rembourse MEV.

Troisièmement, nous explorons ce que fait le protocole Ethereum pour prévenir les externalités négatives de MEV.

Enfin, nous soutenons que aucune des techniques de mitigation de MEV discutées, qu'elles soient dans le protocole ou en dehors du protocole, ne peut résoudre simultanément tous les problèmes causés par MEV.

Le début de cet article fonctionne comme une systématisation partielle des connaissances sur l’atténuation des VEM. Pourtant, la quatrième section présente un argument relativement nouveau selon lequel l’atténuation des MEV hors protocole ne résout pas les problèmes de MEV dans le protocole. Cet argument se fonde sur un papierparDavide Crapiset moi.

Ce post fait référence aux techniques d'atténuation à l'intérieur et à l'extérieur du protocole. Par techniques d'atténuation à l'intérieur du protocole MEV, nous entendons des mécanismes qui font partie des règles du protocole Ethereum ou qui nécessiteraient de modifier les règles du protocole Ethereum. Les techniques d'atténuation en dehors du protocole sont tous les mécanismes qui ne sont pas dans le protocole.

Mitigation de l'impact MEV hors protocole

MEV impose des loyers sur les utilisateurs qui interagissent avec une blockchain. Pour augmenter la valeur qu'Ethereum facilite, il est intuitif de réduire le loyer que représente MEV. Le mandat des techniques de réduction de MEV hors protocole est de diminuer l'effet inhibiteur de valeur que MEV pose sans modifier les règles du protocole Ethereum.

Nous utiliserons comment MEV est extrait sur les Automated Market Makers (AMM) et, par conséquent, comment il peut être atténué comme exemple. De nombreux AMM fonctionnent comme suit:

Les fournisseurs de liquidité (LP) fournissent plusieurs jetons différents à un AMM et laissent l'AMM fixer les prix auxquels les utilisateurs peuvent échanger les jetons des LP.

Un AMM ajuste ses prix uniquement en réponse aux transactions incluses dans les nouveaux blocs. Cette adaptation discrète contraste avec les fluctuations de prix continues des jetons sous-jacents sur les marchés externes.

Lorsqu'un bloc doit être proposé, le producteur de bloc peut inclure des transactions qui utilisent le prix du marché externe publiquement observable pour arbitrer les citations périmées sur un AMM, permettant ainsi d'extraire la MEV.

Cette forme de MEV, connue sous le nom de Loss-Versus-Rebalancing (LVR), est un coût pour les fournisseurs de liquidité. En maintenant les frais qui reviennent aux fournisseurs de liquidité constants, le montant de liquidité fournie diminue avec le montant de LVR extrait de l'AMM. Moins de liquidité signifie que les échanges des utilisateurs ont un impact de prix plus élevé, ce qui rend plus cher pour les utilisateurs de trader sur l'AMM. Un objectif de la conception de l'AMM est de réduire le coût que LVR impose à l'AMM. De même, un objectif de la conception d'application, en général, est de réduire le coût de MEV pour les utilisateurs.

Il existe de nombreuses façons de réduire le coût du MEV. Grosso modo, les techniques d’atténuation des VEM hors protocole sont divisées selon deux axes :

• Techniques de mitigation MEV spécifiques à l'application ou partagées.
• Prévenir MEV ou rembourser MEV.

Le premier axe consiste à savoir si une application atténue MEV elle-même ou s'appuie sur une infrastructure partagée. Le deuxième axe est plus compliqué. Une application pourrait soit être conçue pour empêcher l'exposition de MEV en premier lieu, soit vendre le droit d'extraire MEV et de rembourser les revenus de vente à ceux extraits de MEV. Le remboursement de MEV utilise légèrement la définition de MEV, qui est la valeur que l'acteur responsable de l'inclusion, de l'ordonnancement et de l'exclusion des transactions peut extraire du système. MEV qui est remboursé n'est pas extrait du système et ne correspond donc pas strictement à la définition de MEV. Néanmoins, l'utilisation du terme MEV peut être utile car tous les concepts liés à MEV s'appliquent à la valeur qui est remboursée, à l'exception de l'endroit où vont les revenus. Nous verrons des exemples de toutes les quatre possibilités et discuterons de leurs avantages relatifs.

Figure 1: Catégorisation bidimensionnelle des techniques de mitigation MEV hors protocole avec des exemples pour chaque catégorie.

Application-Specific and Preventing MEV: La Fonction Maximisant l'AMM.

La technique de mitigation de l'EMV qui est généralement la plus intuitive conceptuellement pour ceux qui entendent parler de l'EMV pour la première fois est une application qui empêche l'exposition à l'EMV. Un exemple excitant est le fonction maximisant AMM proposé par Andrea CanidioetRobin Fritsch. Il regroupe les transactions collectées sur une période de temps et les exécute à un prix de compensation uniforme. Les auteurs montrent qu’il élimine le LVR et le sandwich, une autre forme de MEV. L’intuition est que tous les participants négocient au prix marginal du pool après le lot et que les arbitragistes sont incités à négocier jusqu’au point où ce prix est égal au prix du marché externe. Ce système s’apparente à une vente aux enchères fréquente par lots proposée par Budish, Cramton et Shim (2015) dans la littérature financière traditionnelle. Soit dit en passant, il s’agit donc d’un excellent exemple de synergies entre la finance décentralisée et la finance traditionnelle. Les idées de la finance traditionnelle peuvent être mises en œuvre dans la finance décentralisée ; le enseignements de la mise en œuvrepeut ensuite être utilisé pour informer la finance traditionnelle.

MEV spécifique à l'application et rabais: la capture de MEV AMM.

Le MEV capturant l’AMM (McAMM) est un exemple de mitigation MEV spécifique à une application qui repose sur le remboursement. Les enchères McAMM permettent de vendre le droit d'être le premier trader à interagir avec l'AMM dans un bloc, permettant ainsi à ce trader d'extraire un arbitrage possible. Les recettes de l'enchère sont ensuite réparties entre les fournisseurs de liquidité arbitragée. Si l'enchère est efficace, les recettes devraient être égales à la valeur de l'arbitrage extrait des fournisseurs de liquidité. Ce design pourrait conduire à la même élimination de LVR que la fonction qui maximise AMM discutée ci-dessus, même si l'approche est radicalement différente. Que cela soit le cas dans la pratique dépend fortement des implémentations spécifiques de l'enchère.

Infrastructure et Rebating MEV: MEV-Share.

Le rabais n'a pas besoin d'être spécifique à une application. Flashbots, une entreprise opérant dans l'espace de construction de blocs, a développé MEV-Share (en anglais seulement). Il permet aux utilisateurs de choisir les données de transaction à partager lors d'une vente aux enchères privée. Les enchérisseurs enchérissent pour le droit de placer cette transaction dans un bundle et ainsi extraire des MEV. L'utilisateur peut recevoir les recettes de la vente aux enchères. Cette infrastructure n'est pas spécifique à une application, car les transactions peuvent interagir avec n'importe quelle application.

Infrastructure et prévention du MEV : Flux d'ordres protégé dans un monde en quête de profits.

Enfin, il existe des mécanismes infrastructurels qui visent à prévenir l'extraction de MEV. Un exemple est Flux de commandes protégé dans un monde en quête de profits (PROF).PROF repose sur un producteur de blocs au sein d'un environnement d'exécution de confiance (TEE) qui s'engage de manière crédible à respecter une règle d'ordonnancement, par exemple, premier arrivé, premier servi. Les TEE présentent deux propriétés essentielles qui rendent cet engagement crédible, à savoir :

• [ ] Intégrité : le code et les données à l'intérieur du TEE ne peuvent pas être modifiés ou altérés, que ce soit pendant l'exécution ou lorsqu'ils sont stockés, par des entités externes telles que le système d'exploitation, l'hyperviseur ou des acteurs malveillants.
• [ ] Confidentialité : les données et les calculs à l'intérieur du TEE restent privés et inaccessibles aux entités non autorisées, y compris le système hôte, d'autres applications ou des attaquants.

Tout utilisateur qui envoie sa transaction à un producteur de bloc qui s'engage à exécuter une règle d'ordonnancement sait que le producteur de bloc dans le TEE le fera. Par conséquent, PROF peut empêcher certains types d'extraction MEV, comme le front-running pour n'importe quelle application, sans modifier les règles du protocole Ethereum.

Différentes techniques de mitigation du MEV ont des avantages et des inconvénients différents. Les techniques de prévention du MEV spécifiques à une application sont difficiles à trouver car elles nécessitent beaucoup de recherche et de travail de mise en œuvre par application. La prévention du MEV infrastructurel, en revanche, nécessite beaucoup de frais généraux. Par exemple, certaines techniques de prévention du MEV infrastructurel nécessitent l'utilisation d'un matériel coûteux et beaucoup de développement commercial. L'efficacité du remboursement dépend fortement de la compétitivité de l'enchère, qui dépend des spécificités de l'enchère telles que son format et son moment de déroulement.

Ces quatre techniques de mitigation du MEV peuvent ne pas être collectivement exhaustives ni totalement mutuellement exclusives. Notez également que les dimensions ressemblent davantage à des spectres qu'à des binaires, comme le montre la figure 1. Par exemple, certaines techniques de mitigation du MEV peuvent être plus infrastructurelles que d'autres. Le domaine évolue très rapidement, ce qui rend toute catégorisation difficile. Enfin, l'espace semble optimiste, et beaucoup peuvent partager l'opinion que le MEV en pourcentage de la valeur totale facilitéese réduira rapidement.

Le manque de mitigation MEV dans le protocole

Ces techniques de réduction de la MEV peuvent sembler insatisfaisantes pour certains. Pourquoi Ethereum ne peut-il pas être l'infrastructure du protocole qui résout de manière holistique la MEV ? Certains lecteurs pourraient suggérer d'utiliser une règle d'ordonnancement spécifique. Des propositions pour imposer une règle d'ordonnancement particulière dans Ethereum, comme premier arrivé, premier servi, n'a pas reçu un soutien généralisé. Je crois qu'il y a deux raisons fondamentales pour lesquelles le protocole n'a pas été en mesure de résoudre de manière holistique le fardeau que MEV impose aux utilisateurs finaux et aux applications - les deux sont liées à la contrainte de neutralité crédible d'Ethereum.

Tout d’abord, Ethereum ne peut pas obtenir un ordre global transitif satisfaisant à l'« équité ». Ethereum héberge une variété d’applications qui peuvent chacune bénéficier de différents types de règles de commande. Bien que la commande selon le principe du premier arrivé, premier servi puisse aider certaines demandes, elle peut inhiber la croissance des autresPar conséquent, il est difficile pour l'écosystème de s'accorder sur ce qui est juste. De plus, même si l'écosystème parvenait à s'accorder sur une règle d'ordonnancement équitable, il est difficile d'obtenir une règle d'ordonnancement globalement transitive car une transaction peut arriver à différents nœuds à des moments différents.

Ces incohérences posent des problèmes dans les protocoles d'ordonnancement premier arrivé, premier servi. En particulier, même si l'ordre dans lequel les nœuds individuels reçoivent les transactions est transitive, cela ne signifie pas que l'ordre global est également transitive. Les règles d'ordonnancement premier arrivé, premier servi peuvent se bloquer dans des cycles pour restaurer la transitivité, et parfois, ces cycles doivent être résolus par une règle arbitraire, comme choisir un ordre total alphabétiquement. Cela peut signifier que les transactions pour lesquelles l'ordonnancement premier arrivé, premier servi est le plus important, comme les transactions d'arbitrage sensibles au temps, ne sont pas ordonnées de cette manière mais de manière arbitraire.

Figure 2: Diapositive montrant les cycles de Condorcet dans lesquels les règles d'ordre premier arrivé, premier servi peuvent se bloquer. Diapositive tirée d'une présentation sur Themis par Mahimna Kelkar.

En plus du fait que les règles de commande de premier arrivé, premier servi posent des problèmes théoriques, il n'est pas clair qu'ils soient souhaitablesen premier lieu. Cette règle de commande profite à ceux qui ont des connexions plus rapides. Si les connexions rapides sont suffisamment précieuses, cela pourrait entraîner une course à la latence, comme on peut le voir dansfinance traditionnelleavec de gros investissements dans la technologie de vitesse. La technologie de vitesse pourrait nuire à la neutralité crédible des blockchains car elle incite à la centralisation géographique.

Les vues incohérentes sur le moment où les transactions arrivent posent des problèmes pour la règle d'ordonnancement premier arrivé, premier servi ainsi que pour chaque règle d'ordonnancement. Les règles d'ordonnancement visent généralement à atteindre certaines propriétés économiques. Par exemple, l'ordonnancement des gaz prioritaires vise à inclure ces transactions dans l'ordre de leur valeur d'inclusion en premier. Habituellement, ces désidératas économiques ne sont satisfaits que s'il existe une vue globale des transactions devant être ordonnancées. Étant donné qu'il est difficile d'obtenir une vue globale transitive à partir de vues locales transitives, il est difficile d'obtenir une telle vue globale. En d'autres termes, certains validateurs estimeront qu'une transaction devrait être ordonnancée dans une plage horaire donnée, tandis que d'autres penseront qu'elle devrait être ordonnancée dans une autre plage horaire, ce qui dégrade les propriétés économiques que l'écosystème pourrait attendre d'une règle d'ordonnancement fixe.

Deuxièmement, le protocole de consensus ignore les jeux MEV joués sur la couche d'exécution. Il serait donc difficile de concevoir un schéma de remise en protocole car le protocole ne comprendrait pas actuellement quelle est la valeur du MEV et à qui il devrait être remboursé. Enfin, le protocole doit rester neutre de manière crédible. Il ne devrait pas être dans une position où il devrait faire un choix partial quant à qui il devrait rembourser le MEV, même s'il le pouvait, ni choisir des techniques de prévention du MEV qui favorisent certaines applications par rapport à d'autres.

Un exemple intéressant qui se rapproche d'une technique de remise MEV dans le protocole est Taxes MEV, proposé par Dan RobinsonetDave White. Il permet à n'importe quelle application de surcharger les frais de priorité en protocole en définissant un paramètre, disons $k$. Tout utilisateur interagissant avec l'application doit alors payer $k$ fois les frais de priorité payés au validateur du consensus à l'application. Vous pouvez voir comment ce système pourrait rembourser les revenus MEV aux applications de manière généralisée. Par exemple, s'il y avait 10 ETH de MEV à extraire d'une application, avec $k = 9$, en étant le premier à interagir avec elle, un utilisateur peut payer des frais de priorité de 1 ETH au validateur et 9 ETH à l'application, en supposant que les transactions sont classées par frais de priorité.

Les taxes MEV sont une direction prometteuse, mais comme indiqué par ses auteurs, elles doivent être davantage explorées pour comprendre comment elles fonctionneraient sur Ethereum. Un aspect difficile pourrait être que les taxes MEV supposent que les frais de priorité sont un signal universel pour la quantité de MEV. Bien que cela puisse être vrai si un ordre de priorité est appliqué, l'ordonnancement lui-même peut diminuer le montant total de MEV, de la même manière qu'une enchère au premier prix multi-unitaire peut avoir des revenus inférieurs à une enchère combinatoire. Flashbots’ RAFFINÉsemble aller dans la direction opposée, ce qui permet des préférences plus expressives. SUAVE n'est actuellement pas en direct mais vise à construire un constructeur de blocs décentralisé qui fusionne de manière optimale les bundles sans règle d'ordonnancement spécifique.

Les frais de priorité peuvent ne pas bien représenter le MEV lorsque les chercheurs souhaitent exprimer leurs préférences pour être inclus de manière plus complexe que les frais de priorité unidimensionnels. Peut-être qu'un chercheur souhaite être inclus dans le bloc avant les autres bundles de chercheurs concurrents mais ne se soucie pas de la position absolue dans le bloc. L'utilisation des frais de priorité signifierait que le chercheur rivalise pour une position avec tous les utilisateurs, indépendamment de leur pertinence pour ce chercheur.

Il existe d'autres moyens de réduire l' MEV extrait des utilisateurs en dehors des règles de commande. Une direction de recherche estmempools cryptésCela signifie que les utilisateurs diffusent les transactions sous forme chiffrée. Ce n'est qu'après l'inclusion que la transaction est déchiffrée. Le producteur de blocs ne connaît donc pas le contenu de la transaction, ce qui rend impossible la réalisation de transactions de front-running basées sur les données désormais protégées.

Les pools de mémoires chiffrées sont en direct sur Gnosis Chain, une blockchain qui a une architecture similaire à Ethereum. Les participants de l'écosystème, notamment Réseau Shutter, vise à apporter des mempools cryptés sur Ethereum mainnet. Certains facteurs limitants actuels sont les hypothèses de confiance nécessaires avec les techniques de cryptographie basées sur le seuil, l'état des fonctions de retard vérifiableset laproblèmes de disponibilité des données gratuitesliés aux mempools cryptés.

En résumé, Ethereum ne peut pas être l'infrastructure qui empêche MEV car l'écosystème n'a pas été capable de s'entendre sur une règle d'ordonnancement équitable et car il est difficile d'obtenir un ordonnancement global transitif compte tenu de toute règle d'ordonnancement. Certaines propositions de règles d'ordonnancement, comme l'exemple des taxes MEV donné ci-dessus et les mises à niveau de protocole, ont été discutées, ce qui pourrait faciliter un ordonnancement global transitif satisfaisant à la "justice". Cependant, il n'y a actuellement aucun consensus approximatif sur le fait que cela est souhaitable. Ethereum ne peut pas être l'infrastructure qui rembourse MEV car la couche de consensus est inconsciente de ce qui se passe sur la couche d'exécution et Ethereum ne peut pas choisir entre les applications car elle doit rester neutre.

Que fait le protocole?

Le paragraphe précédent montre à quel point il est difficile pour le protocole d'éliminer la charge que MEV impose aux utilisateurs. Cependant, de nombreux mécanismes de protocole gèrent MEV, et un section de la feuille de route de Vitalikest dédié à cela. Que font ces mécanismes ?

Ces mécanismes in-protocole visent à résoudre un problème différent des techniques d'atténuation précédemment discutées. Au lieu de maximiser la valeur facilitée par Ethereum en minimisant la MEV extraite des utilisateurs, les mécanismes in-protocole visent à maximiser la neutralité crédible d'Ethereum en minimisant les externalités négatives de la MEV. La MEV diminue non seulement l'utilité de ceux qui en sont extraits, mais elle distorsionne également considérablement le comportement de l'extracteur, par exemple, elle incite à la centralisation grâce aux économies d'échelle et provoque instabilité du consensus.

Les forces économiques sont un risque majeur de centralisation pour le consensus d'Ethereum et, par extension, pour sa neutralité crédible. Si des économies d'échelle existent, il est prévisible que de petits agents de consensus se regroupent avec de grands agents pour en bénéficier. Si des rendements à la sophistication existent, les validateurs rationnels peuvent se comporter différemment par rapport aux spécifications honnêtes. Les économies d'échelle ou les rendements à la sophistication pour les agents de consensus sont des externalités négatives de la MEV.

Le protocole vise à prévenir les externalités négatives en dégroupant les rôles des agents de consensus dans Ethereum et en les isolant les uns des autres. Actuellement, Ethereum attribue à un seul agent tous les rôles suivants, mais en principe, il s'agit de rôles séparés. Les trois rôles identifiés jusqu'à présent sont les suivants :

• Attester aux informations nécessaires pour le consensus et créer des blocs de consensus est le rôle le plus critique dans le système de consensus de Preuve d'Enjeu d'Ethereum. Des exemples sont l'attestation de la tête de la chaîne, l'attestation de la ponctualitédes messages et la création de blocs de consensus lorsque nécessaire. Les récompenses pour ces rôles sont assez homogènes pour tous les participants.
• [ ] Proposition du bloc d'exécution. Ce rôle garantit la vivacité de la couche d'exécution. Il peut consister en une soumission en temps opportun de la charge d'exécution et une allocation efficace des droits de construction de la charge d'exécution. Les récompenses pour ce rôle dépendent de la tolérance au risque et de la vitesse du participant.
• [ ] Construction du bloc d'exécution. Ce rôle décide de l'ordre des transactions dans une charge d'exécution. Il a le plus grand potentiel pour extraire MEV du système, et des économies d'échelle claires, des barrières à l'entrée élevées et de la sophistication sont associées à ce rôle. Les récompenses sont donc très hétérogènes parmi les participants.

L'écosystème Ethereum vise à isoler ces trois rôles de sorte que les incitations provenant d'un rôle n'affectent pas les incitations de ceux qui remplissent un autre rôle. Certains rôles, comme l'ordonnancement des transactions, peuvent être plus centralisés tant que la validation des blocs est sans confiance et hautement décentralisée, et qu'un ensemble décentralisé de participants peut garantir la résistance à la censure, comme l'a déclaré Vitalik dans son influentPublication de fin de partie.

Séparation du Proposant-Constructeur (PBS)vise à séparer les rôles de proposition et de construction de la charge d'exécution. Il s'agit d'une philosophie de conception qui reconnaît les différents rôles et facilite l'externalisation du devoir de construction de bloc du proposant à une partie spécialisée. MEV-Boost est l'instance actuelle hors protocole de PBS. Il permet à tous les proposants, quelle que soit leur sophistication, d'accéder aux mêmes marchés MEV. Concrètement, il impose que le constructeur reçoive le droit de construire le bloc et que le proposant reçoive son paiement pour la vente de ce droit. Avec MEV-Boost, un proposant n'est pas mieux loti en investissant dans des techniques sophistiquées d'extraction de MEV, mais peut rester relativement peu sophistiqué dans ce domaine et profiter des mêmes récompenses que des proposants plus sophistiqués.

Séparation Attester-Proposer (APS) est conceptuellement similaire à PBS. Il reconnaît également la différence entre deux rôles : l'attestation et la proposition de blocs de consensus et la proposition de blocs d'exécution. APS est actuellement en phase de recherche et aucune version hors protocole n'est en direct. Les proposants peut vouloir être rapidecar cela leur permet de soumettre leur bloc plus tard, ce qui signifie qu'ils peuvent inclure plus de transactions. Il est essentiel que le protocole de consensus n'incite pas à la latence car cela conduit à une centralisation géographique. APS est parfois considéré comme la dernière ligne de défense du protocole Ethereum.

PBS et APS montrent comment ces trois rôles peuvent être isolés. Cependant, la mise en œuvre de ces deux mises à niveau de protocole signifie également que les participants créant des blocs seraient très centralisés, ce qui est terrible pour la résistance à la censure. Ethereum vise à surmonter ces problèmes en construisant des vannes à sens unique entre ces rôles. Le protocole peut surcharger le rôle de l'attestation des blocs en attestant des transactions en attente dans le mempool. Un comité d'attestants serait alors responsable de la création d'une liste de transactions que le producteur de blocs doit inclure, sinon leur bloc serait ignoré par les attestants. Ces types de mécanismes sont appelés listes d'inclusion.

Ces vannes remettent en question la séparation des rôles. C'est très difficile à concevoirdes vannes qui utilisent de manière significative les propriétés d'un ensemble de participants, par exemple, en contraignant un autre ensemble de participants, tout en veillant également à ce que ces participants à l'autre extrémité de la vanne n'affectent pas les participants qui les affectent. Par exemple, l'ensemble décentralisé de validateurs serait responsable de la création d'une liste d'inclusion. Nous ne voulons pas que le producteur de blocs ni les incitations à la centralisation liées à la production de blocs affectent les validateurs.

Figure 3: Division du travail par séparation de l'attestant-proposant (APS) et séparation du proposant-constructeur (PBS) avec des listes d'inclusion et la vente des droits de construction en tant que vannes unidirectionnelles entre les rôles.

Pas de solution unique à deux problèmes distincts

L'objectif principal des mécanismes MEV en protocole diffère fondamentalement des techniques de mitigation de MEV en application et infrastructure. Les techniques de mitigation hors protocole visent généralement à réduire le MEV par unité de valeur facilitée. En revanche, les techniques de mitigation en protocole visent à prévenir les externalités négatives du MEV qui centralisent les agents de consensus d'Ethereum. Des techniques de mitigation spécifiques de MEV peuvent contribuer aux deux objectifs. MEV-Boost, par exemple, est techniquement hors protocole, mais son seul objectif est de prévenir les externalités négatives du MEV.

De plus, les contraintes dans les deux problèmes sont différentes. Les mécanismes en protocole doivent être conçus en tenant compte des exigences matérielles et d'un protocole neutre. En revanche, les contraintes des techniques de mitigation MEV hors protocole dépendent des désidératas des concepteurs d'applications ou d'infrastructures, ce qui peut convenir à un cas d'utilisation particulier.

Étant donné que ces problèmes ont des objectifs et des contraintes différents, il est intuitif qu'aucune solution unique ne puisse répondre aux deux. De plus, il peut y avoir une dichotomie plus fondamentale entre les deux problèmes. Cette section esquisse un argument en faveur de cette dichotomie, également présentée dans un article de Davide Crapis et moi-même.

Les concepteurs d'applications veulent réduire le MEV par unité de valeur car cela attirerait plus d'utilisateurs et augmenterait ainsi la valeur totale que ces applications facilitent. Si le MEV par unité de valeur diminue mais que la valeur totale facilitée augmente, le montant total de MEV pourrait diminuer mais aussi augmenter. Les mécanismes MEV en protocole se soucient du montant total de MEV que les agents de consensus peuvent extraire. Même si le montant total de MEV est une fraction négligeable de la valeur que facilite Ethereum, il n'est pas clair que le protocole n'ait toujours pas besoin de cloisonner les différents rôles de consensus nécessaires pour empêcher la centralisation des participants au consensus d'Ethereum.

À titre d'exemple de cet argument, considérez le cas de Rééquilibrage des pertes(LVR), introduit précédemment comme les pertes d'arbitrage de latence auxquelles les fournisseurs de liquidité dans les AMM font face parce que leurs devis en chaîne restent obsolètes entre les blocs par rapport au marché externe en constante évolution. Dans leur travail, Milionis et al. constatent que la LVR cumulative sur une période est proportionnelle à la durée de la période à la puissance de 3/2.

À première vue, cela suggérerait que la diminution du temps de slot diminue également MEV. LVR, cependant, représente les pertes d'arbitrage par unité de liquidité. De plus, Joel Hasbrouck, Thomas Rivera et Fahad Saleh montréles positions LP individuelles peuvent être considérées comme des actifs investissables. Les rendements attendus des actifs sont généralement basés sur leur risque. Il n'est pas clair comment le risque d'une position LP changerait à mesure que les temps de slot diminuent, mais pour l'argument, supposons qu'il reste constant. Ensuite, les rendements d'une position LP devraient rester constants indépendamment des temps de slot; par conséquent, si les coûts par unité de liquidité diminuent, les revenus par unité de liquidité doivent également diminuer. Dans les AMM, les revenus diminueraient car plus de liquidité afflue dans l'AMM. Plus de liquidité signifie que plus d'unités de liquidité sont confrontées à LVR. Par conséquent, l'effet global est ambigu. Ainsi, il n'est pas clair comment le montant total de MEV découlant de LVR changerait si les temps de slot changent, même si le MEV par unité de valeur peut diminuer.

De plus, une diminution du LVR rendrait les AMM plus attractives pour le trading car il y a plus de liquidité, ce qui signifie que davantage de traders payants utilisent les AMM, entraînant encore plus de liquidité. De plus, l'expérience utilisateur bénéficie de délais de slot plus courts, et le montant total de MEV découlant du LVR peut augmenter avec les délais de slot. Cela pose problème pour le protocole, même si les utilisateurs apprécient des transactions plus efficaces.

Tableau 1: Impact des délais de slot sur le LVR, le montant de liquidité et le montant total de MEV. Ce tableau montre comment le délai de slot affecte le LVR par slot et le facteur par lequel la liquidité est multipliée. Il suppose que les revenus des frais restent constants et que le coût d'opportunité par slot est nul. Les résultats sont normalisés avec les valeurs correspondant au délai de slot de 12 secondes utilisé comme référence.

Le tableau 1 montre que le montant total de MEV provenant de LVR peut rester le même même si le temps d'emplacement diminue. Les valeurs de ce tableau sont générées en supposant que les frais sont la seule source de revenus, l'arbitrage de latence est le seul coût pour les fournisseurs de liquidité et le coût d'opportunité par emplacement reste constant à zéro. Ces hypothèses sont trop simplistes. Par conséquent, ces chiffres peuvent représenter des limites supérieures de la liquidité accrue par emplacement et, par conséquent, du montant total de MEV.

Il est difficile de dire si ces prédictions se réaliseront. L'écosystème sait peu de choses sur les motivations des fournisseurs de liquidités et les compromis entre risques et récompenses.encore moins sur le comportement des traders en matière de liquidité. Peut-être que les fournisseurs de liquidité considèrent le risque des positions de liquidité différemment en fonction des horaires des créneaux, ce qui pourrait aider à prédire ce qui se passe avec le montant total de MEV à mesure que les horaires des créneaux diminuent.

Potentiellement, cet exemple peut être généralisé. Les techniques de mitigation de MEV en dehors du protocole qui visent à minimiser le MEV par unité de valeur induisent simultanément plus de valeur qui circule à travers le système ; par conséquent, l'impact de la mitigation de MEV sur la quantité totale de MEV est ambiguë. Par conséquent, je crois qu'Ethereum ne peut pas compter sur la mitigation de MEV en dehors du protocole pour prévenir les externalités négatives de MEV sur les agents du consensus.

Avertissement :

1. Cet article est repris de [ Julian Ma], Tous les droits d'auteur appartiennent à l'auteur original [Julian Ma]. Si vous avez des objections à cette réimpression, veuillez contacter le Gate Learnéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.