Éclairer la forêt sombre : lever le voile sur le mystère de MEV
Avec l'augmentation des activités on-chain et l'évolution et l'enrichissement des infrastructures on-chain, l'MEV on-chain a toujours été considéré comme la partie la plus dangereuse de la forêt sombre d'Ethereum, entraînant des pertes de profits et une dégradation de l'expérience utilisateur dans les activités financières on-chain des utilisateurs. Cet article vise à analyser principalement les problèmes de centralisation et de confiance inhérents à ce mécanisme, qui contrastent radicalement avec les valeurs d'Ethereum, en se basant sur le mécanisme de génération de blocs d'Ethereum 2.0 et l'évolution technique de la séparation proposeur-constructeur (PBS).
L'escalade de l'MEV sur la chaîne est effectivement une arme à double tranchant, avec ses externalités positives et négatives. Les aspects positifs incluent la réduction des écarts de prix sur les DEX et l'aide à la liquidation des transactions ; les aspects négatifs incluent des dommages causés aux utilisateurs par des transactions sandwich. Par conséquent, les solutions MEV visent davantage à atténuer les externalités négatives, plutôt qu'à les éradiquer. Dans le cadre de l'exploration des mécanismes d'atténuation des externalités négatives de l'MEV et de résolution des problèmes liés au middleware de confiance tiers, le Relayer, trois catégories principales de mesures sont identifiées : amélioration des mécanismes d'enchères, amélioration de la couche de consensus, amélioration de la couche d'application. Ces trois types d'améliorations auront un impact différent sur le paysage moderne de l'MEV, mais certaines solutions ne parviennent pas à résoudre substantiellement le problème des attaques sandwich rencontré par les utilisateurs. Les transactions des utilisateurs restent dans le pool public, il est donc nécessaire d'introduire davantage de technologies de pool de confidentialité pour protéger la confidentialité optionnelle des transactions des utilisateurs. Ces solutions MEV valent la peine d'être combinées et essayées.
En outre, l'MEV, en tant que sous-produit de la conception de mécanismes inévitables, est susceptible de se complexifier encore davantage à l'avenir. Nous avons également exploré dans le texte les défis et opportunités techniques supplémentaires liés à l'MEV qui pourraient émerger sous l'implémentation de nouveaux types de transactions tels que l'architecture Layer2 et l'abstraction de compte EIP-4337.
Enfin, nous espérons explorer dans cet article les solutions potentielles pour atténuer le problème des externalités négatives du 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 recherche sur le MEV pour les chercheurs du secteur.
Ethereum 2.0
Depuis The Merge, Ethereum a adopté un mécanisme POS pour garantir la sécurité du réseau, tout en abandonnant la compétition gourmande en calculs en faveur de la preuve d'enjeu. Après la fusion, Ethereum est divisé en une couche d'exécution et une couche de consensus. L'ensemble de la production de blocs a également changé, chaque Epoch représentant un cycle POS, chaque Epoch étant divisé en 32 Slots, chaque Slot correspondant à une unité de temps de production de bloc, soit 12 secondes.
L'ensemble du réseau choisira à chaque Epoch un comité de manière aléatoire parmi les validateurs. La personne qui propose le bloc est choisie de manière aléatoire parmi les membres du comité. Ce proposeur de bloc doit regrouper et ordonner les transactions pour produire finalement un bloc. D'autres validateurs du comité superviseront ce processus, puis voteront pour le bloc. De plus, ce comité sera réévalué après chaque Epoch. Une certaine limite de temps d'opération est également imposée afin d'assurer l'efficacité de la génération de blocs et des votes. Ici, nous normalisons les termes pour les lecteurs, le Payload est la charge d'exécution, ce qui signifie un changement d'état des transactions, pouvant être considéré comme une partie de l'exécution du bloc. Le proposeur de bloc mettra en œuvre le Payload d'exécution (, c'est-à-dire l'état de changement de résultat de 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'origine, l'idée était que si nous choisissions par le biais d'un comité décentralisé, et si nous incluions l'exécution de la charge utile, alors le tri des transactions deviendrait une affaire décentralisée. Cependant, les validateurs semblent naturellement vouloir confier cette partie à des tiers, tandis qu'eux-mêmes, en tant que proposeurs, se concentrent sur la proposition de blocs. Cela a donc donné naissance au concept de PBS, qui sépare la proposition et la construction de blocs, les proposeurs n'étant responsables que de la validation des blocs, sans participer à la construction des blocs. La séparation entre les proposeurs et les 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 présentons brièvement le modèle d'enchères scellées de la première vente de PBS(Proposer Builder Seperate). Lorsque les utilisateurs soumettent des transactions via un proxy RPC, le RPC fonctionne comme un nœud, soumettant la transaction au Mempool public, où plusieurs Builders trouvent les transactions les plus appropriées pour les 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, où le Builder soumet des offres au Relayer, et le Relayer soumet plusieurs en-têtes de blocs et les offres correspondantes au Proposer. En général, le Proposer adopte l'en-tête de bloc avec l'offre la plus élevée. Dans ce cadre, le Relayer met en œuvre la norme MEVBboost, qui est une spécification technique proposée par Flashbot pour réguler l'interaction d'enchères entre Builders et Proposer. Dans ce processus, toutes les informations sont scellées, le Relayer ne soumettra que des en-têtes de blocs au Proposer, garantissant ainsi une résistance à la censure.
Types de participants et jeux dans PBS
Les principaux participants sont Builder, Relayer, Proposer, MEVbot( et 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 favorable lors des enchères, car il prend en charge non seulement les frais de gaz, mais aussi les revenus MEV. Le Builder peut examiner directement les transactions des utilisateurs et des Searchers, ce qui a toujours été un point de critique, surtout depuis que le gouvernement américain a publié l'OFAC. De nombreux Builders ont participé à la conformité avec l'OFAC. Comparé au début, bien que la proportion d'examen des blocs ait récemment diminué, nous pouvons voir que, dans le processus de construction des blocs, le Builder joue un rôle direct dans l'examen des transactions.
D'après la part de marché actuelle des Builders, des plateformes comme beaverbuild.org, qui fonctionnent sans aucun contrôle, sont en train d'élargir progressivement leur part de marché, tout cela étant axé sur le profit.
Searcher
En essence, le travail de maximisation des profits nécessite un effort conjoint entre les Searchers et les Builders. Les Searchers collaborent souvent avec des Builders spécifiques, ce qui donne lieu à un Dark Pool ou un Private Pool, où les transactions des Searchers ne sont visibles que par des Builders spécifiques. Certains Builders peuvent ainsi obtenir des transactions MEV maximisant les profits et enchérir pour l'espace de bloc. Théoriquement, si un Builder agit de manière malveillante ou pratique la censure, les Searchers peuvent choisir d'autres Builders, ce qui entraînera une diminution progressive de la part de marché du Builder. Ainsi, soumis aux Searchers, les Builders doivent souvent prendre en compte le coût caché de leurs actions malveillantes. L'image ci-dessus montre les bénéfices de l'MEV et du Gas quotidien, il est possible de voir que les bénéfices MEV contribuant par les Searchers peuvent, lors de fluctuations significatives du marché, atteindre même le double des bénéfices en Gas du jour.
Pour le Searcher, il se divise en arbitrage CEX-DEX( hors chaîne) et en deux grandes catégories : DEX, intermédiaire, et liquidation, qui sont entièrement sur chaîne(.
Actuellement, Wintermute détient la première part de marché en matière d'arbitrage entre CEX et DEX.
Pour les opportunités MEV purement sur chaîne, il y a une tendance à se structurer en studios, où jaredfromsubway.eth détient une part de marché impressionnante de 37,2 %. Il est spécialisé dans les 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 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 au moment de l'exécution de ces transactions. Étant donné que la connexion entre les Seacher et les Builder est étroite, en pratique, de nombreux Searchers envoient leur flux de commandes aux trois principaux Builders. En réalité, il aurait été possible de diffuser à tous les Builders, mais certains petits Builders peuvent fragmenter le flux de commandes des Searchers, entraînant l'inefficacité des stratégies MEV des Searchers et augmentant ainsi le risque de pertes. De plus, lier un Builder peut également maintenir son influence au sein de l'écosystème.
![Illuminer la forêt sombre : dévoiler le mystère de MEV])https://img-cdn.gateio.im/webp-social/moments-355138223027bf07ef01db141cec6d58.webp(
) Relayer
Le Relayer est responsable de la collecte des enchères, puis sert de station de transit pour soumettre l'en-tête de bloc et le prix de l'enchère 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 constatons que le Relayer agit comme un tiers sans incitation économique, obtenant une grande confiance. Le Builder dépend du Proposer pour la tarification, tandis que le Proposer s'appuie sur les cotations et le contenu du bloc du Relayer. Des problèmes similaires se sont également produits dans le passé, où l'Ultrasound Relayer avait une vulnérabilité potentielle, entraînant 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 du MEV.
L'image ci-dessus montre la part de marché des Relayers. Nous pouvons constater que la part de marché des Builders qui fonctionnent 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 le biais des Builders.
En même temps, Relayer est également confronté à un problème, à savoir l'absence d'incitations économiques. Par conséquent, Blocknative a également abandonné le développement dans la direction de Relayer. Actuellement, Relayer dépend des normes MEVBoost proposées par Flashbots pour se construire, Ethereum dépend de tiers pour fournir PBS, ce qui n'est pas une solution durable, c'est pourquoi la communauté Ethereum explore actuellement l'intégration de PBS au niveau du protocole.
![Éclairer la forêt sombre : lever le voile sur le mystère de MEV]###https://img-cdn.gateio.im/webp-social/moments-b41ea7fd71286916535ec0974e6261ec.webp(
) Proposer
Pour le Proposer, il s'agit de choisir aléatoirement un groupe de comités parmi tous les validateurs à l'aide d'un algorithme, puis de sélectionner un proposeur de bloc pour chaque slot. Le proposeur de bloc lui-même a la capacité d'exécuter la charge de travail, mais étant donné que le proposeur souhaite naturellement déléguer 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 d'intermédiation de ce type afin de réduire la collusion résultant de la communication directe entre les deux. Étant donné que nous sommes actuellement dans un environnement de pools de minage en tant que pools de validateurs, ces pools de minage et les pools de validateurs LSD présentent tous deux un fort effet de taille, en particulier avec l'émergence des LSD, qui libère le potentiel des tokens initialement stakés, améliorant ainsi l'efficacité du capital. De plus, l'influence des blocs DEFI qui les sous-tendent rend le pool de validateurs encore plus concentré.
Lido détient actuellement environ 28,7 % de parts de marché, Coinbase et Ether.fi se classant respectivement deuxième et troisième. Dans le passé, lorsque la solution MEV-BOOST PBS n'était pas mise en œuvre activement, le Proposer devait assumer la tâche du Builder, c'est-à-dire exécuter la charge ###Payload(, mais la plupart des Proposers ont renoncé à leur capacité d'exécuter le tri des transactions, car cela alourdissait considérablement le travail de calcul et affectait sérieusement les performances de validation, il est donc préférable d'externaliser la charge d'exécution et de laisser un tiers enchérir sur les blocs.
![Éclairer la forêt sombre : dévoiler le mystère du MEV])https://img-cdn.gateio.im/webp-social/moments-cde45fcc68b2217faa2920d7559fb1ce.webp(
) Utilisateur
Enfin, parlons de l'utilisateur. Les utilisateurs se trouvent souvent être la partie la plus faible dans la conception de l'architecture, car les transactions des utilisateurs sont toutes placées dans le Mempool, et divers MEVbots en tirent des profits MEV, mais ces profits ne reviennent pas aux utilisateurs. Cependant, ce n'est pas entièrement négatif. Par exemple, dans les DEX, lorsque la volatilité sur la chaîne est importante ou que le volume des transactions des utilisateurs dépasse la liquidité du DEX, les MEVbots peuvent utiliser des stratégies d'arbitrage pour réduire le slippage et les écarts de prix entre les différentes plateformes. Ainsi, l'existence du MEV a des externalités positives et négatives, qui doivent être discutées séparément, et c'est aussi ce qui rend la question complexe.
Pour éviter que les utilisateurs ne soient surveillés par des MEVbots, ce qui pourrait leur causer des dommages, de nombreux fournisseurs de nœuds RPC peuvent aider les utilisateurs à placer leurs transactions dans un Mempool non public, par exemple en interagissant directement avec le Builder via le RPC du Builder. Une méthode relativement innovante consiste à compenser les profits MEV pour les utilisateurs par le biais de l'OFA###Order Flow Auction(, où les opérateurs RPC OFA collaborent avec les Searchers.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
6 J'aime
Récompense
6
5
Partager
Commentaire
0/400
RugpullAlertOfficer
· Il y a 20h
MEV est naturellement défavorable aux investisseurs détaillants
Les difficultés MEV d'Ethereum : un aperçu de la forêt noire on-chain à partir de l'architecture PBS
Éclairer la forêt sombre : lever le voile sur le mystère de MEV
Avec l'augmentation des activités on-chain et l'évolution et l'enrichissement des infrastructures on-chain, l'MEV on-chain a toujours été considéré comme la partie la plus dangereuse de la forêt sombre d'Ethereum, entraînant des pertes de profits et une dégradation de l'expérience utilisateur dans les activités financières on-chain des utilisateurs. Cet article vise à analyser principalement les problèmes de centralisation et de confiance inhérents à ce mécanisme, qui contrastent radicalement avec les valeurs d'Ethereum, en se basant sur le mécanisme de génération de blocs d'Ethereum 2.0 et l'évolution technique de la séparation proposeur-constructeur (PBS).
L'escalade de l'MEV sur la chaîne est effectivement une arme à double tranchant, avec ses externalités positives et négatives. Les aspects positifs incluent la réduction des écarts de prix sur les DEX et l'aide à la liquidation des transactions ; les aspects négatifs incluent des dommages causés aux utilisateurs par des transactions sandwich. Par conséquent, les solutions MEV visent davantage à atténuer les externalités négatives, plutôt qu'à les éradiquer. Dans le cadre de l'exploration des mécanismes d'atténuation des externalités négatives de l'MEV et de résolution des problèmes liés au middleware de confiance tiers, le Relayer, trois catégories principales de mesures sont identifiées : amélioration des mécanismes d'enchères, amélioration de la couche de consensus, amélioration de la couche d'application. Ces trois types d'améliorations auront un impact différent sur le paysage moderne de l'MEV, mais certaines solutions ne parviennent pas à résoudre substantiellement le problème des attaques sandwich rencontré par les utilisateurs. Les transactions des utilisateurs restent dans le pool public, il est donc nécessaire d'introduire davantage de technologies de pool de confidentialité pour protéger la confidentialité optionnelle des transactions des utilisateurs. Ces solutions MEV valent la peine d'être combinées et essayées.
En outre, l'MEV, en tant que sous-produit de la conception de mécanismes inévitables, est susceptible de se complexifier encore davantage à l'avenir. Nous avons également exploré dans le texte les défis et opportunités techniques supplémentaires liés à l'MEV qui pourraient émerger sous l'implémentation de nouveaux types de transactions tels que l'architecture Layer2 et l'abstraction de compte EIP-4337.
Enfin, nous espérons explorer dans cet article les solutions potentielles pour atténuer le problème des externalités négatives du 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 recherche sur le MEV pour les chercheurs du secteur.
Ethereum 2.0
Depuis The Merge, Ethereum a adopté un mécanisme POS pour garantir la sécurité du réseau, tout en abandonnant la compétition gourmande en calculs en faveur de la preuve d'enjeu. Après la fusion, Ethereum est divisé en une couche d'exécution et une couche de consensus. L'ensemble de la production de blocs a également changé, chaque Epoch représentant un cycle POS, chaque Epoch étant divisé en 32 Slots, chaque Slot correspondant à une unité de temps de production de bloc, soit 12 secondes.
L'ensemble du réseau choisira à chaque Epoch un comité de manière aléatoire parmi les validateurs. La personne qui propose le bloc est choisie de manière aléatoire parmi les membres du comité. Ce proposeur de bloc doit regrouper et ordonner les transactions pour produire finalement un bloc. D'autres validateurs du comité superviseront ce processus, puis voteront pour le bloc. De plus, ce comité sera réévalué après chaque Epoch. Une certaine limite de temps d'opération est également imposée afin d'assurer l'efficacité de la génération de blocs et des votes. Ici, nous normalisons les termes pour les lecteurs, le Payload est la charge d'exécution, ce qui signifie un changement d'état des transactions, pouvant être considéré comme une partie de l'exécution du bloc. Le proposeur de bloc mettra en œuvre le Payload d'exécution (, c'est-à-dire l'état de changement de résultat de 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'origine, l'idée était que si nous choisissions par le biais d'un comité décentralisé, et si nous incluions l'exécution de la charge utile, alors le tri des transactions deviendrait une affaire décentralisée. Cependant, les validateurs semblent naturellement vouloir confier cette partie à des tiers, tandis qu'eux-mêmes, en tant que proposeurs, se concentrent sur la proposition de blocs. Cela a donc donné naissance au concept de PBS, qui sépare la proposition et la construction de blocs, les proposeurs n'étant responsables que de la validation des blocs, sans participer à la construction des blocs. La séparation entre les proposeurs et les 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 présentons brièvement le modèle d'enchères scellées de la première vente de PBS(Proposer Builder Seperate). Lorsque les utilisateurs soumettent des transactions via un proxy RPC, le RPC fonctionne comme un nœud, soumettant la transaction au Mempool public, où plusieurs Builders trouvent les transactions les plus appropriées pour les 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, où le Builder soumet des offres au Relayer, et le Relayer soumet plusieurs en-têtes de blocs et les offres correspondantes au Proposer. En général, le Proposer adopte l'en-tête de bloc avec l'offre la plus élevée. Dans ce cadre, le Relayer met en œuvre la norme MEVBboost, qui est une spécification technique proposée par Flashbot pour réguler l'interaction d'enchères entre Builders et Proposer. Dans ce processus, toutes les informations sont scellées, le Relayer ne soumettra que des en-têtes de blocs au Proposer, garantissant ainsi une résistance à la censure.
Types de participants et jeux dans PBS
Les principaux participants sont Builder, Relayer, Proposer, MEVbot( et 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 favorable lors des enchères, car il prend en charge non seulement les frais de gaz, mais aussi les revenus MEV. Le Builder peut examiner directement les transactions des utilisateurs et des Searchers, ce qui a toujours été un point de critique, surtout depuis que le gouvernement américain a publié l'OFAC. De nombreux Builders ont participé à la conformité avec l'OFAC. Comparé au début, bien que la proportion d'examen des blocs ait récemment diminué, nous pouvons voir que, dans le processus de construction des blocs, le Builder joue un rôle direct dans l'examen des transactions.
D'après la part de marché actuelle des Builders, des plateformes comme beaverbuild.org, qui fonctionnent sans aucun contrôle, sont en train d'élargir progressivement leur part de marché, tout cela étant axé sur le profit.
Searcher
En essence, le travail de maximisation des profits nécessite un effort conjoint entre les Searchers et les Builders. Les Searchers collaborent souvent avec des Builders spécifiques, ce qui donne lieu à un Dark Pool ou un Private Pool, où les transactions des Searchers ne sont visibles que par des Builders spécifiques. Certains Builders peuvent ainsi obtenir des transactions MEV maximisant les profits et enchérir pour l'espace de bloc. Théoriquement, si un Builder agit de manière malveillante ou pratique la censure, les Searchers peuvent choisir d'autres Builders, ce qui entraînera une diminution progressive de la part de marché du Builder. Ainsi, soumis aux Searchers, les Builders doivent souvent prendre en compte le coût caché de leurs actions malveillantes. L'image ci-dessus montre les bénéfices de l'MEV et du Gas quotidien, il est possible de voir que les bénéfices MEV contribuant par les Searchers peuvent, lors de fluctuations significatives du marché, atteindre même le double des bénéfices en Gas du jour.
Pour le Searcher, il se divise en arbitrage CEX-DEX( hors chaîne) et en deux grandes catégories : DEX, intermédiaire, et liquidation, qui sont entièrement sur chaîne(.
Actuellement, Wintermute détient la première part de marché en matière d'arbitrage entre CEX et DEX.
Pour les opportunités MEV purement sur chaîne, il y a une tendance à se structurer en studios, où jaredfromsubway.eth détient une part de marché impressionnante de 37,2 %. Il est spécialisé dans les 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 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 au moment de l'exécution de ces transactions. Étant donné que la connexion entre les Seacher et les Builder est étroite, en pratique, de nombreux Searchers envoient leur flux de commandes aux trois principaux Builders. En réalité, il aurait été possible de diffuser à tous les Builders, mais certains petits Builders peuvent fragmenter le flux de commandes des Searchers, entraînant l'inefficacité des stratégies MEV des Searchers et augmentant ainsi le risque de pertes. De plus, lier un Builder peut également maintenir son influence au sein de l'écosystème.
![Illuminer la forêt sombre : dévoiler le mystère de MEV])https://img-cdn.gateio.im/webp-social/moments-355138223027bf07ef01db141cec6d58.webp(
) Relayer
Le Relayer est responsable de la collecte des enchères, puis sert de station de transit pour soumettre l'en-tête de bloc et le prix de l'enchère 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 constatons que le Relayer agit comme un tiers sans incitation économique, obtenant une grande confiance. Le Builder dépend du Proposer pour la tarification, tandis que le Proposer s'appuie sur les cotations et le contenu du bloc du Relayer. Des problèmes similaires se sont également produits dans le passé, où l'Ultrasound Relayer avait une vulnérabilité potentielle, entraînant 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 du MEV.
L'image ci-dessus montre la part de marché des Relayers. Nous pouvons constater que la part de marché des Builders qui fonctionnent 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 le biais des Builders.
En même temps, Relayer est également confronté à un problème, à savoir l'absence d'incitations économiques. Par conséquent, Blocknative a également abandonné le développement dans la direction de Relayer. Actuellement, Relayer dépend des normes MEVBoost proposées par Flashbots pour se construire, Ethereum dépend de tiers pour fournir PBS, ce qui n'est pas une solution durable, c'est pourquoi la communauté Ethereum explore actuellement l'intégration de PBS au niveau du protocole.
![Éclairer la forêt sombre : lever le voile sur le mystère de MEV]###https://img-cdn.gateio.im/webp-social/moments-b41ea7fd71286916535ec0974e6261ec.webp(
) Proposer
Pour le Proposer, il s'agit de choisir aléatoirement un groupe de comités parmi tous les validateurs à l'aide d'un algorithme, puis de sélectionner un proposeur de bloc pour chaque slot. Le proposeur de bloc lui-même a la capacité d'exécuter la charge de travail, mais étant donné que le proposeur souhaite naturellement déléguer 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 d'intermédiation de ce type afin de réduire la collusion résultant de la communication directe entre les deux. Étant donné que nous sommes actuellement dans un environnement de pools de minage en tant que pools de validateurs, ces pools de minage et les pools de validateurs LSD présentent tous deux un fort effet de taille, en particulier avec l'émergence des LSD, qui libère le potentiel des tokens initialement stakés, améliorant ainsi l'efficacité du capital. De plus, l'influence des blocs DEFI qui les sous-tendent rend le pool de validateurs encore plus concentré.
Lido détient actuellement environ 28,7 % de parts de marché, Coinbase et Ether.fi se classant respectivement deuxième et troisième. Dans le passé, lorsque la solution MEV-BOOST PBS n'était pas mise en œuvre activement, le Proposer devait assumer la tâche du Builder, c'est-à-dire exécuter la charge ###Payload(, mais la plupart des Proposers ont renoncé à leur capacité d'exécuter le tri des transactions, car cela alourdissait considérablement le travail de calcul et affectait sérieusement les performances de validation, il est donc préférable d'externaliser la charge d'exécution et de laisser un tiers enchérir sur les blocs.
![Éclairer la forêt sombre : dévoiler le mystère du MEV])https://img-cdn.gateio.im/webp-social/moments-cde45fcc68b2217faa2920d7559fb1ce.webp(
) Utilisateur
Enfin, parlons de l'utilisateur. Les utilisateurs se trouvent souvent être la partie la plus faible dans la conception de l'architecture, car les transactions des utilisateurs sont toutes placées dans le Mempool, et divers MEVbots en tirent des profits MEV, mais ces profits ne reviennent pas aux utilisateurs. Cependant, ce n'est pas entièrement négatif. Par exemple, dans les DEX, lorsque la volatilité sur la chaîne est importante ou que le volume des transactions des utilisateurs dépasse la liquidité du DEX, les MEVbots peuvent utiliser des stratégies d'arbitrage pour réduire le slippage et les écarts de prix entre les différentes plateformes. Ainsi, l'existence du MEV a des externalités positives et négatives, qui doivent être discutées séparément, et c'est aussi ce qui rend la question complexe.
Pour éviter que les utilisateurs ne soient surveillés par des MEVbots, ce qui pourrait leur causer des dommages, de nombreux fournisseurs de nœuds RPC peuvent aider les utilisateurs à placer leurs transactions dans un Mempool non public, par exemple en interagissant directement avec le Builder via le RPC du Builder. Une méthode relativement innovante consiste à compenser les profits MEV pour les utilisateurs par le biais de l'OFA###Order Flow Auction(, où les opérateurs RPC OFA collaborent avec les Searchers.