Éclairer la forêt sombre : lever le voile sur le MEV

Avec l'augmentation des activités sur la chaîne et l'évolution et la richesse des infrastructures sur la chaîne, le MEV sur la chaîne a toujours été considéré comme la partie la plus dangereuse de la forêt noire d'Ethereum, ce qui entraîne directement des pertes de profits et une dégradation de l'expérience utilisateur dans les activités financières sur la chaîne. L'objectif de cet article "Éclairer la forêt noire" est d'analyser en profondeur les problèmes naturels de centralisation et de confiance apportés par ce mécanisme, basé sur le mécanisme de génération de blocs d'Ethereum 2.0 et l'évolution technologique de la séparation des proposeurs et des constructeurs (PBS), qui est en totale opposition avec les valeurs d'Ethereum.

L'intensification de l'MEV sur la chaîne est effectivement une épée à double tranchant, avec des externalités à la fois positives et négatives. Les externalités positives incluent la réduction des écarts de prix DEX et l'aide à la liquidation des transactions ; les externalités négatives incluent les dommages causés aux utilisateurs par les transactions sandwich. Ainsi, les solutions à l'MEV visent davantage à atténuer les externalités négatives qu'à les éradiquer. Dans notre exploration des mécanismes pour atténuer les externalités négatives de l'MEV et résoudre les problèmes liés aux intermédiaires de confiance tiers Relayer, nous avons principalement identifié trois types de mesures : l'amélioration des mécanismes d'enchères, l'amélioration du niveau de consensus et l'amélioration du niveau d'application. Ces trois types d'améliorations auront un impact différent sur le paysage moderne de l'MEV, mais certaines solutions ne résolvent pas vraiment le problème des attaques sandwich rencontrées par les utilisateurs. Les transactions des utilisateurs restent dans une piscine publique, d'où la nécessité d'introduire davantage de technologies de piscine de confidentialité pour protéger la confidentialité optionnelle des transactions des utilisateurs. Ces solutions de l'MEV méritent d'être combinées et testées.

En outre, en tant que sous-produit inévitable de la conception mécaniste, le MEV deviendra à l'avenir encore plus complexe. Nous avons également exploré dans le texte les défis techniques et les opportunités supplémentaires du MEV qui pourraient surgir avec la mise en œuvre de nouveaux types de transactions dans les architectures Layer2 et l'abstraction de compte EIP-4337.

Enfin, nous espérons qu'avec cet article, nous pourrons explorer les solutions potentielles pour atténuer les problèmes d'externalités négatives liés au MEV, et avoir une compréhension complète des avantages et des inconvénients des solutions MEV actuelles, non seulement pour éclairer l'obscur forêt dans laquelle se trouvent les utilisateurs à l'avenir, mais aussi pour éclairer l'obscur forêt de la recherche sur le MEV pour les chercheurs de l'industrie.

Ethereum 2.0

Depuis The Merge, Ethereum a adopté un mécanisme de POS pour garantir la sécurité du réseau, tout en abandonnant la compétition intensément computationnelle dans la production de blocs, en faveur de la preuve de participation. Après la fusion, Ethereum a été divisé en couche d'exécution et en couche de consensus. La production de blocs a également changé, chaque Epoch représentant un cycle de POS, chaque Epoch étant subdivisé en 32 Slots, chaque Slot équivalant à une unité de temps pour la production de blocs, soit 12 secondes.

Le réseau sélectionnera au hasard un comité parmi les validateurs à chaque Epoch. La personne proposant le bloc est choisie au hasard parmi les membres du comité. Ce proposeur de bloc doit empaqueter les transactions et les exécuter dans un certain ordre pour produire finalement un bloc. Les autres validateurs du comité superviseront ce processus, puis voteront pour le bloc. De plus, ce comité sera réévalué après chaque Epoch. Un certain délai d'exécution est également imposé pour garantir l'efficacité de la génération de blocs et du vote. Ici, nous normalisons les termes pour le lecteur. Le Payload est la charge d'exécution, ce qui signifie un changement d'état des transactions, et peut être considéré comme une partie de l'exécution du bloc. Le proposeur de bloc mettra en œuvre la charge d'exécution (, c'est-à-dire le changement d'état du résultat de la transaction ) et la proposition de bloc.

Architecture PBS

En fait, lorsque les validateurs sont sélectionnés pour devenir des proposeurs de blocs, il arrive souvent que les proposeurs n'aient pas d'incitation à exécuter le Payload, c'est-à-dire à trier et exécuter les transactions, car cela nécessite une grande puissance de calcul pour effectuer des modifications d'état. L'idée initiale était que si nous élisions un comité décentralisé, et si l'exécution de la charge était incluse, alors le tri des transactions et autres deviendrait une affaire décentralisée. Cependant, il semble que les validateurs veuillent naturellement confier cette partie à des tiers, tandis qu'eux-mêmes, en tant que proposeurs, se concentrent sur la proposition de blocs. C'est ainsi qu'est née l'idée de PBS, qui consiste à séparer la proposition et la construction de blocs, où le proposeur de blocs est uniquement responsable de la validation des blocs, sans participer à la construction des blocs. La séparation entre proposeurs et constructeurs favorise un marché ouvert, dans lequel les proposeurs de blocs peuvent obtenir des blocs des constructeurs. Ces constructeurs rivalisent pour construire des blocs et offrent aux proposeurs les frais les plus élevés, que nous appelons "enchères de blocs".

Nous allons brièvement présenter l'ensemble du modèle d'enchères scellées PBS(Proposer Builder Seperate). Lorsque les utilisateurs soumettent des transactions, plusieurs Builders trouvent les transactions les plus appropriées à trier afin de générer un bloc maximisant le profit(, le profit maximal étant défini par les frais de transaction Base+Priority+MEV). Ensuite, plusieurs Builders interagissent avec le Proposer via le Relayer MEV-Boost. Le Relayer est le pont d'interaction entre plusieurs Builders et le Proposer. Les Builders soumettent leurs offres au Relayer, qui soumet plusieurs en-têtes de blocs ainsi que les offres correspondantes au Proposer. Le Proposer adopte généralement l'en-tête de bloc avec l'offre la plus élevée. Dans ce processus, toutes les informations sont fermées, le Relayer ne soumettra que les en-têtes de blocs au Proposer, ce qui confère au Proposer une résistance à la censure.

Types de participants et jeux sous PBS

Ses principaux participants sont Builder, Relayer, Proposer, MEVbot(Searcher).

Builder

Le Builder est principalement responsable de la construction du contenu des blocs. Avec l'utilisation de la technologie MEV-Boost, il se trouve dans une position plus avantageuse lors des enchères, car il ne supporte pas seulement les frais de Gas, mais également les revenus MEV. Le Builder peut directement examiner les transactions des utilisateurs et des Searchers, ce qui a toujours été un point critiqué, surtout depuis que le gouvernement américain a publié l'OFAC. Un grand nombre de Builders ont participé à la conformité avec l'OFAC. Comparé au début, bien que le ratio d'examen des blocs ait récemment diminué, nous pouvons voir que, dans le processus de construction des blocs, les Builders ont un impact direct sur l'examen des transactions.

D'après la part de marché actuelle des Builders, le Build sans examen est en train d'élargir progressivement sa part de marché, tout cela étant orienté vers le profit.

Chercheur

En essence, le travail de maximisation des profits nécessite la collaboration entre le Searcher et le Builder. Le Searcher collaborera souvent avec un Builder spécifique, ce qui forme un Dark Pool ou un Private Pool, où les transactions du Searcher ne seront visibles que par ce Builder spécifique. Certains Builders obtiendront ainsi des transactions MEV maximisant les profits et en viendront à enchérir pour l'espace de bloc. Théoriquement, si le Builder agit de manière malveillante ou fait de la censure, le Searcher peut choisir d'autres Builders, ce qui entraînera une diminution progressive de la part de marché du Builder. Par conséquent, soumis au Searcher, les Builders prendront souvent en compte le coût caché de la malveillance.

Pour Searcher, il se divise en arbitrage CEX-DEX( hors chaîne) et en deux grandes catégories : DEX, mezzanine, liquidation, et ( purement sur chaîne).

Actuellement, Wintermute détient la première part de marché dans le trading d'arbitrage CEX - DEX.

Pour les opportunités MEV purement sur chaîne, il y a une tendance à la formation progressive d'ateliers, dont jaredfromsubway.eth détient une part de marché impressionnante de 37,2 %. Il excelle dans l'exécution d'attaques sandwich contre les utilisateurs de la chaîne Ethereum, devenant un moment l'utilisateur avec la consommation de gaz la plus élevée sur la chaîne, représentant environ 1,5 % de la consommation totale de gaz d'une journée entière. De février 2023 à juin 2024, ce robot a dépensé un total de 76,916 ETH, ce qui équivaut à environ 175 millions de dollars en fonction de la valeur lors de l'exécution de ces transactions. Étant donné que les liens entre les Searchers et les Builders sont étroits, dans la pratique, de nombreux Searchers envoient leur flux de commandes aux trois premiers Builders. En réalité, ils pourraient diffuser à tous les Builders, mais certains petits Builders peuvent diviser le flux de commandes des Searchers, entraînant l'échec de la stratégie MEV des Searchers et augmentant le risque de pertes. De plus, lier un Builder peut également lui permettre de maintenir son influence au sein de l'écosystème.

Relayer

Le Relayer est responsable de la collecte des enchères, puis agit comme un point de transit pour soumettre l'en-tête de bloc et le prix des enchères au Proposer, à ce moment-là le Proposer ne connaît pas les détails des transactions dans le bloc. Une fois que le Proposer a choisi et signé l'en-tête de bloc, le Relayer libérera tout le contenu des transactions au Proposer. Nous constaterons que le Relayer agit en tant que tiers sans incitation économique, obtenant une grande confiance, le Builder s'appuie sur le Proposer pour les offres, tandis que le Proposer s'appuie sur les offres du Relayer et le contenu du bloc. Des problèmes similaires se sont également produits dans le passé, avec une vulnérabilité potentielle qui a conduit le Proposer à extraire plus de 20 millions de dollars de MEV. Bien que ces vulnérabilités puissent être corrigées, le Relayer lui-même peut toujours choisir d'agir de manière malveillante et de voler le MEV.

L'image ci-dessus montre la part de marché des Relayers. Nous constatons que la part de marché des Builders fonctionnant uniquement avec le MAX Profit s'est progressivement élargie depuis le Merge. Par conséquent, dans un marché libre, il est impossible de contrôler artificiellement le MEV par les Builders.

En même temps, les Relayer font face à un problème, à savoir l'absence d'incitations économiques. Par conséquent, certaines entreprises ont également abandonné le développement dans la direction des Relayer. Actuellement, les Relayer dépendent de la norme MEVBoost proposée par Flashbots pour se construire, Ethereum dépendant de tiers pour fournir PBS, ce qui n'est pas une solution durable. Ainsi, la communauté Ethereum explore actuellement l'intégration de PBS au niveau du protocole.

Proposer

Pour le Proposer, il s'agit de sélectionner aléatoirement un groupe de comités parmi tous les validateurs à l'aide d'un algorithme, puis de choisir un proposeur de bloc pour chaque slot. Le proposeur de bloc a lui-même la capacité d'exécuter une charge, mais en raison de la tendance naturelle des proposeurs à vouloir externaliser cette partie, cela peut facilement entraîner une coopération verticale entre le Builder et le Proposer. Le Relayer de MEV-boost souhaite agir comme un point intermédiaire dans cette relation afin de réduire la collusion due à la communication directe entre les deux. Actuellement, étant donné que nous sommes tous dans des pools de minage en tant que pools de validateurs, ces pools de minage et les pools de validateurs LSD présentent de forts effets d'échelle, en particulier avec l'apparition de la LSD, qui libère le potentiel des tokens initialement stakés, améliorant ainsi l'efficacité du capital, et l'influence des blocs DEFI derrière cela, le pool de validateurs tend donc vers une concentration accrue.

Un certain projet LSD occupe actuellement environ 28,7 % de part de marché, et une certaine plateforme d'échange ainsi qu'un certain projet se classent respectivement deuxième et troisième. Dans le passé, lorsque la solution MEV-BOOST PBS n'était pas activement mise en œuvre, le Proposer devait assumer la tâche de Builder, c'est-à-dire exécuter la charge (Payload), mais la plupart des Proposer ont abandonné leur capacité à exécuter le tri des transactions, car cela alourdissait considérablement le travail de calcul et dégradait les performances de validation ; il était donc préférable de sous-traiter la charge d'exécution et de laisser un tiers enchérir pour le bloc.

Utilisateur

Enfin, parlons des utilisateurs. Les utilisateurs sont souvent la partie la plus faible dans l'ensemble de la conception de l'architecture, car leurs transactions sont placées dans le Mempool et peuvent être exploitées par divers MEVbots pour réaliser des profits MEV, mais ces profits ne vont pas aux utilisateurs. Cependant, ce n'est pas toujours un inconvénient. Par exemple, dans les DEX, lorsque les fluctuations des prix sur la chaîne sont importantes ou que le volume des transactions des utilisateurs dépasse la liquidité du DEX, les MEVbots peuvent utiliser l'arbitrage pour atténuer le glissement et les écarts de prix entre les différentes plateformes. Par conséquent, l'existence du MEV a des externalités positives et négatives, qui doivent être discutées séparément, et c'est là toute sa complexité.

Afin d'empêcher les utilisateurs d'être surveillés par les MEVbots, ce qui pourrait leur causer des dommages, de nombreux fournisseurs de services peuvent aider les utilisateurs à placer leurs transactions dans un Mempool non public. Par exemple, cela peut se faire en interagissant directement avec le Builder via ses services. Une méthode relativement nouvelle consiste à compenser les bénéfices MEV des utilisateurs grâce à l'OFA(Order Flow Auction). Les opérateurs OFA établissent des partenariats avec les Searchers et, en mettant aux enchères les commandes des utilisateurs auprès des Searchers, ces derniers peuvent maximiser le MEV, ce qui permet à l'ensemble.