Le jeu actuel entre Ethereum et le MEV commence avec le passage du PoW au PoS...

Écrit par : TIA, Techub News

Le processus de résolution du problème MEV consiste en réalité à redéfinir les règles d’allocation de l’espace Bloc. Pour MEV, je pense que tout le monde est déjà familier, mais si vous voulez savoir de quoi parlent certaines propositions de gouvernance MEV d’ETH, vous aurez peut-être besoin de quelques informations complémentaires sur le contexte. Par conséquent, cet article examine les propositions de gouvernance MEV après le passage à PoS d’ETH, telles que PBS, ePBS, PEPC, dans l’espoir de fournir quelques informations de contexte.

PBS（Proposer Builder Seperatioin）

Avant la fusion d’ETH, la façon de résoudre le MEV était de développer le MEV-Geth à l’aide de Flashbots, qui est une version modifiée du client go-ethereum. Le concept central est de permettre aux Mineurs de se concentrer sur leur travail principal - le minage, plutôt que de participer à la lutte pour le MEV, afin d’éviter les éventuels problèmes de restructuration. Le mécanisme de MEV-Geth est assez simple, c’est une solution de marché, c’est-à-dire que les Mineurs peuvent choisir lors de l’emballage du Bloc en fonction de la taille des bénéfices soumis par le chercheur. Grâce à ce mécanisme de marché ingénieux, toutes les parties tirent des bénéfices tout en formant également une certaine contrainte. Bien que le chercheur doive partager une partie des bénéfices avec le Mineur, il obtient une garantie plus sûre de ne pas être volé par le Mineur. Lorsque le chercheur est la principale source de profit, le Mineur commencera également à utiliser MEV-Geth de manière passive, et sera en outre contraint par le mécanisme de MEV-Geth. MEV-Geth maintiendra une Allowlist des Mineurs, seuls les Mineurs sur l’Allowlist peuvent recevoir le bundle du chercheur. En contrôlant la réputation des Mineurs, en éliminant de l’Allowlist les Mineurs qui volent les résultats du chercheur, on peut empêcher les Mineurs de s’emparer des bénéfices du MEV du chercheur.

Cependant, après la fusion, la méthode de génération de blocs a changé pour sélectionner au hasard un validateur comme proposant un Bloc, de sorte que la méthode de contrainte de crédibilité pour empêcher les proposants de saisir le MEV n’est plus viable.

Une solution possible consiste à rendre le contenu de Bloc invisible pour les validateurs. Dans cette optique, la solution PBS (Proposer Builder Séparation, séparation des constructeurs de propositions) est développée prochainement. PBS décompose davantage les responsabilités des validateurs en tant que proposants pour construire et proposer des Blocs, externalisant le pouvoir de construction complexe et potentiellement compétitif aux constructeurs. Ainsi, le travail du proposant est simplifié, il ne lui reste plus qu’à choisir les Blocs à proposer en fonction du profit soumis par le constructeur.

Au début, Ethereum voulait incorporer le PBS dans le protocole lors de la fusion, mais en raison de sa complexité potentielle, ce processus a été mis en attente, ce qui a donné l’occasion à MEV-Boost de s’impliquer dans le PBS. Actuellement, le PBS est implémenté via MEV-Boost développé par Flashbots. En plus du constructeur et du proposant, il y a un rôle très important - le relais. Le constructeur n’envoie pas directement le Bloc au proposant, mais passe par un troisième rôle, le relais.

Parce qu’il reste à résoudre d’autres problèmes, tels que comment garantir que le constructeur paiera certainement les frais au proposant et divulguera certainement le contenu de Bloc à la fin pour éviter que le proposant ne soit pas slashing pour soumettre un Bloc vide; comment garantir que le Bloc soumis par le constructeur sera certainement inclus dans la chaîne de balises, etc. Ces questions qui protègent les droits et les intérêts du constructeur et du proposant sont principalement mises en œuvre via relais.

Le constructeur enverra le Bloc au relais, puis le relais classera le Bloc en fonction des bénéfices qu’il peut obtenir pour chaque Bloc, et enverra ensuite la tête du Bloc avec le plus haut bénéfice au proposant afin de garantir que le proposant ne puisse pas voir le contenu du Bloc. Une fois que le proposant s’est engagé à proposer une proposition pour le Bloc (en signant la tête du Bloc), le relais divulguera le Bloc complet au proposant. Les frais payés par le constructeur au proposant doivent également être confirmés à l’avance par le relais pour garantir leur réalisation. Les transactions payées au proposant sont incluses dans le Bloc soumis, mais comme le proposant ne peut pas voir le contenu du Bloc, elles doivent toujours être confirmées à l’avance par le relais.

Dans le protocole et le protocole de sortie

Pour participer au marché construit par MEV-Boost, les validateurs doivent exécuter un client Consensus pour Ethereum (ETH) et simultanément exécuter un programme MEV-Boost tiers non lié à Ethereum. C’est là que réside la magie de PBS, qui permet à des tiers en dehors du protocole de participer à la conception des règles de consensus d’Ethereum. D’un point de vue de la propriété, c’est vraiment surprenant.

Cela a également suscité une réflexion sur la “crédibilité” du protocole, comment la crédibilité est renforcée et comment elle peut être sapée par d’autres mécanismes. MEV-Boost en est un bon exemple, car il est possible qu’un protocole externe modifie les mécanismes existants. Lorsque le protocole lui-même commence à prendre du retard, de tels changements peuvent commencer à émerger de l’extérieur, et l’émergence de mécanismes externes doit certainement correspondre aux besoins actuels du marché. Cependant, il est encore inconnu si les mécanismes externes sont fiables, s’ils ont été conçus de manière rigoureuse pour prévenir l’apparition de problèmes potentiels, voire s’ils peuvent compromettre le protocole.

Relais centralisé

Le MEV-Boost est le plus critiqué pour son marché de relais centralisé. Cependant, cette configuration introduit un problème de confiance. Les constructeurs doivent avoir confiance que le relais ne volera pas leur MEV. Le proposant doit également avoir confiance que les Blocs-headers qu’il reçoit et signe du relais sont valides. Cependant, bien qu’il joue un rôle crucial, le Relais n’a aucun incitatif économique et son exploitation nécessite des dépenses considérables. L’année dernière, il y avait encore 11 relais qui fournissaient un soutien au réseau Ethereum, mais aujourd’hui, seuls 9 relais sont toujours en service.

Il est à noter que le relais n’est pas sans autorisation, comme EDEN, un relais tel que Relais son propre constructeur. Certains relais, tels que bloXroute, prétendent filtrer les transactions liées à la front-running et aux attaques sandwich. Dans une certaine mesure, le relais a également le pouvoir d’établir des règles.

Les données proviennent du réseau Rated

De plus, du point de vue de la Liveness, en raison de la présence du relais, le constructeur et le proposant ne peuvent pas fournir une confirmation atomique. Par exemple, lorsque le proposant signe l’engagement de l’en-tête du bloc et que le constructeur fournit également le contenu de la charge utile, toute erreur du relais (qu’elle soit malveillante ou non) empêchera la soumission rapide de ce contenu, ce qui entraînera des pertes pour le constructeur et le proposant.

ePBS：将 PBS 封装进以太坊

Que ce soit pour résoudre le problème de la centralisation de relay ou pour déplacer une partie en dehors du protocole vers le protocole, l’encapsulation de PBS dans ePBS d’ETH semble être incontournable. Actuellement, ePBS n’est plus une simple proposition de discussion, mais a déjà été attribué d’un numéro dans l’éditeur EIP d’ETH - EIP-7732.

ePBS provides an infrastructure for proposers and builders that does not require trust, to complete the outsourcing of Bloc construction rights. The role of the builder, which was originally outside the protocol, is included in the protocol and the role of the builder is split from the long in validateurs. The builder of validateurs also needs to complete the stake in the ETH Bloc. As the responsibility of the proposer in the Consensus layer is split, modifying the Consensus layer is necessary to complete ePBS. The builder is responsible for constructing the execution payload (the final list of transactions to be executed in the Bloc). The proposer’s responsibility is to propose the beacon Bloc. The specific process is as follows:

1. Une fois sélectionné en tant que Proposer, créez et diffusez la liste d’inclusion (IL), c’est-à-dire les transactions qui doivent être incluses dans ce slot.
2. Les constructeurs enverront le bloc, qui contient le hachage de la charge utile et l’engagement à payer des frais au proposant, ‘SignedutionPayloadHeader’, au proposant (la charge utile doit satisfaire IL)
3. Le proposant sélectionne celui de la « * SignedutionPayloadHeader * » envoyé par les constructeurs pour l’inclure (généralement celui avec le prix le plus élevé pour le proposant). Et diffuse le bloc de balise proposé « * SignedBeaconBlock * ».
4. Les témoins remplissent leurs fonctions de témoignage
5. les agrégateurs soumettent des agrégats d’attestation; en même temps, le constructeur diffuse la charge utile ution
6. PTC（Comité de ponctualité de la charge utile, 512 validateurs sont sélectionnés comme membres du PTC dans chaque slot）vérifie si le constructeur révèle la charge utile ution en temps opportun et diffuse les résultats

ePBS a subi plusieurs discussions depuis sa proposition jusqu’à l’obtention du numéro d’EIP. Au départ, PBS a été proposé par Vitalik en juin 21, puis le schéma Two-slot a été amélioré quatre mois plus tard, suivi de la sortie de PBS Single-slot trois mois plus tard. Ce n’est qu’en juillet 23 que l’idée de PTC a été officiellement proposée.

PEPC（Protocol-Enforced Proposer Commitments）

Bien sûr, il y a aussi des désaccords avec ePBS, et l’espoir de le remplacer par une autre solution. C’est le cas de PEPC. Alors que ePBS intègre des règles spécifiques dans le protocole, dans le cas de PEPC, le proposant vend le droit de construire des Blocs de Programmabilité.

PEPC a été proposé par barnabe en octobre 2022. barnabe estime que si le mécanisme PBS doit être intégré dans le protocole, il convient de mettre en place un mécanisme général pour la transmission de signaux de confiance, plutôt que de mettre en place un mécanisme spécifique pour un signal de confiance particulier (par exemple, si on me demande de construire un Bloc, je vous rendrai xx ETH).

Tout comme son nom l’indique, certains mécanismes garantissant les droits des constructeurs et des proposants sont réalisés par les engagements soumis par le proposant dans le protocole, qui peuvent être vérifiés hors chaîne, principalement grâce au Code d’opération ‘BEACONROOT’. Il s’agit d’un mécanisme plus général, les engagements peuvent externaliser complètement les droits de construction de blocs, ou ne externaliser qu’une partie, c’est-à-dire que le proposant vend des droits de construction de blocs programmables.

Conclusion

Voici une brève introduction à PBS, ePBS et PEPC. Du point de vue de la conception du protocole, il est nécessaire de concevoir non seulement un mécanisme de marché pour la réattribution de MEV, mais également de considérer comment rendre les validateurs plus décentralisés et comment améliorer la résistance à la censure. De plus, il y a beaucoup de compromis dans la conception du protocole. Prenons l’exemple d’ePBS, qui a déjà obtenu un numéro EIP. Bien que la conception d’ePBS résolve le problème de relay centralisé, est-ce que le rôle clé des relais tiers en dehors du protocole n’a vraiment que des impacts négatifs ? En ce qui concerne le mécanisme de paiement des builders, l’utilisation de relais est en fait plus avantageuse que le mécanisme ePBS, car ePBS est un mécanisme de prépaiement. Si un builder paie un bloc avec un profit extrêmement élevé, il ne pourra pas offrir de retour sur investissement élevé au proposant dans le cadre du mécanisme de prépaiement.