Le jeu actuel entre le consensus Ethereum et MEV commence à partir du jour où PoW passe à PoS...

Écrit par Tia, Techub News

Le processus de résolution du problème MEV consiste en fait à reformuler les règles d'allocation de l'espace des blocs. Je pense que tout le monde n'est plus étranger à MEV, mais si vous voulez savoir de quoi parlent certaines propositions de gouvernance d'Ethereum MEV, vous aurez peut-être encore besoin d'informations générales supplémentaires. Par conséquent, cet article a résolu une série de questions sur la gouvernance de. MEV depuis qu'Ethereum est passé aux propositions PoS telles que PBS, ePBS et PEPC, j'espère vous fournir quelques informations générales.

PBS (Proposer Builder Seperatioin)

Avant la fusion Ethereum, la façon de résoudre MEV consistait à utiliser MEV-Geth développé par Flashbots, un client go-ethereum modifié. L'idée centrale est de permettre aux sociétés minières de se concentrer sur leur travail, à savoir l'exploitation minière, plutôt que de participer à la concurrence des MEV, évitant ainsi d'éventuels problèmes de restructuration qui pourraient survenir. Le mécanisme de MEV-Geth est très simple. Il s'agit d'une solution orientée marché, c'est-à-dire que lorsque les mineurs emballent des blocs, ils peuvent choisir en fonction du profit du bundle soumis par le chercheur. Grâce à cet ingénieux mécanisme axé sur le marché, toutes les parties peuvent en tirer des avantages tout en créant certaines contraintes. Bien que le chercheur doive partager une partie des bénéfices avec les mineurs, il obtient en échange une garantie plus sûre contre le vol par les mineurs. Lorsque les chercheurs, la principale source de profits, seront piégés, les mineurs commenceront également à utiliser passivement MEV-Geth et seront encore plus contraints par le mécanisme de MEV-Geth. MEV-Geth maintiendra une liste blanche de mineurs, et seuls les mineurs figurant sur la liste blanche pourront recevoir des packages de recherche. En imposant des contraintes de réputation aux mineurs et en supprimant de la liste blanche ceux qui volent les résultats des chercheurs, les mineurs peuvent être empêchés de voler les bénéfices MEV des chercheurs.

Mais après la fusion, puisque la méthode de génération de blocs change pour sélectionner aléatoirement les proposants parmi les validateurs pour proposer des blocs, la méthode de contrainte de réputation pour empêcher les proposants d'arracher le MEV n'est plus réalisable.

Une solution possible est de rendre le contenu du bloc invisible pour les validateurs. Une autre amélioration dans ce sens est le PBS (Proposer Builder Seperatioin, Proposer Builder Seperatioin). PBS décompose en outre les responsabilités du vérificateur du proposant en construction de blocs et propositions de blocs, et sous-traite au constructeur les droits de construction complexes qui peuvent impliquer une concurrence pour les intérêts. De cette manière, le travail du proposant devient très simple et il suffit de proposer des blocs. basé sur le bénéfice du constructeur provenant de la soumission du bloc.

Initialement, Ethereum souhaitait intégrer PBS dans le protocole lors de la fusion, mais en raison de la complexité potentielle, ce processus a été abandonné, donnant ainsi à MEV-Boost l'opportunité d'intervenir dans PBS. Actuellement, PBS est implémenté via MEV-Boost développé par Flashbots. Outre celui de constructeur et de proposant, il a également un rôle très important : celui de relais. Le constructeur n'envoie pas le bloc directement au proposant, mais via un relais tiers.

Parce qu'il y a d'autres problèmes qui doivent être résolus, comme comment s'assurer que le constructeur paiera définitivement le proposant et divulguera définitivement le contenu du bloc au proposant à la fin afin que le proposant ne soit pas pénalisé pour la soumission d'un bloc vierge ; par exemple, comment s'assurer que les blocs soumis par le constructeur seront inclus dans la chaîne de balises, etc. Ces enjeux de protection des droits et intérêts des constructeurs et des promoteurs se réalisent principalement par relais.

Builder enverra les blocs au relais, puis le relais triera les blocs en fonction du profit pouvant être obtenu de chaque bloc, puis enverra l'en-tête de bloc avec le profit le plus élevé au proposant pour s'assurer que le proposant comprend le contenu du bloc Invisible. Le relais ne divulguera pas le bloc complet au proposant jusqu'à ce que celui-ci s'engage sur la proposition de bloc (signe l'en-tête du bloc). Les honoraires payés par le constructeur au proposant nécessitent également l'aide d'un relais pour assurer la réalisation. La transaction payée au proposant est incluse dans le bloc soumis, mais comme le proposant ne peut pas voir le contenu du bloc, elle doit quand même être confirmée par le relais au préalable.

In protocol & out protocol

Afin de participer au marché construit par MEV-Boost, le vérificateur doit exécuter un client tiers non Ethereum tout en exécutant le client de consensus Ethereum et le client d'exécution MEV-Boost. programme. C’est la magie du PBS actuellement en cours, qui permet à des tiers extérieurs au protocole de participer à la conception des règles pour la formation consensuelle d’Ethereum. Du point de vue de la propriété, c’est incroyable.

Cela déclenche également une réflexion sur la « crédibilité » du mécanisme protocolaire, sur la manière dont la crédibilité est renforcée et sur la manière dont elle est érodée par d'autres mécanismes. MEV-Boost est un bon exemple, car il peut y avoir des situations dans lesquelles des protocoles externes modifient les mécanismes existants. Lorsque le protocole lui-même commence à prendre du retard, de tels changements peuvent commencer à germer de l’extérieur. L’émergence de mécanismes externes doit répondre à la demande actuelle du marché, mais il faut déterminer si le mécanisme externe est crédible et s’il est rigoureusement conçu pour empêcher l’émergence de potentiels. Les problèmes, ni même les mécanismes externes susceptibles de compromettre l’accord, ne sont pas encore connus.

Relais centralisé

MEV-Boost a été le plus critiqué pour son marché de relais centralisé. Mais cette configuration introduit des problèmes de confiance. Les constructeurs doivent faire confiance au relais pour ne pas voler leur MEV. Les proposants doivent également être sûrs que les en-têtes de bloc qu'ils reçoivent et signent du relais sont valides. Cependant, malgré leur rôle vital, il n’existe aucune incitation financière pour les relais et leur fonctionnement nécessite une dépense importante. L’année dernière, il y avait 11 relais prenant en charge le réseau Ethereum, mais aujourd’hui, seuls 9 relais fournissent encore des services.

Il est à noter que le relais ne nécessite pas d'autorisation. Les relais tels qu'Eden ne relaient que leurs propres constructeurs. Il existe également des relais tels que bloXroute qui prétendent filtrer les transactions liées aux attaques frontales et sandwich. Dans une certaine mesure, le relais dispose également de certains droits de réglementation.

数据来自Rated Network

Et, du point de vue de Liveness, en raison de l'existence du relais, une confirmation du niveau atomique ne peut pas être fournie entre le constructeur et le proposant. Si le proposant signe un engagement sur l'en-tête du bloc et que le constructeur fournit également le contenu de la charge utile, mais que le relais ne parvient pas à soumettre le contenu à temps (qu'il soit malveillant ou non), le constructeur et le proposant subiront des pertes.

ePBS : Encapsuler le PBS dans Ethereum

Que ce soit pour résoudre le problème de centralisation des relais ou pour déplacer des pièces hors protocole dans le protocole, encapsuler le PBS dans l’ePBS d’Ethereum semble être devenu un incontournable. Actuellement, ePBS n'est plus une proposition en discussion et l'éditeur d'Ethereum EIP lui a attribué un numéro - EIP-7732.

ePBS fournit une infrastructure sans confiance permettant aux proposants et aux constructeurs de finaliser l'externalisation des droits de construction en bloc. Le rôle de constructeur, qui était à l'origine en dehors du protocole, a été inclus dans le protocole, c'est-à-dire qu'un rôle supplémentaire de constructeur est réparti entre les validateurs. Le constructeur en tant que validateur doit également remplir l'engagement dans Ethereum. Étant donné que les responsabilités du proposant initial de la couche de consensus ont été divisées, la réalisation de l'ePBS nécessite des modifications de la couche de consensus. Parmi eux, le constructeur est responsable de la construction de la charge utile d'exécution (la liste finale des transactions à exécuter dans le bloc). La responsabilité du proposant est de proposer des blocs balises. Le processus spécifique est le suivant :

1. Après avoir su qu'il est sélectionné comme Proposant, réalisez et diffusez la Liste d'Inclusion (IL, c'est-à-dire les transactions qui doivent être incluses dans ce créneau).

2. les constructeurs enverront le hachage de bloc contenant la charge utile d'exécution et l'engagement de payer le proposant "SignedExecutionPayloadHeader" au proposant (la charge utile d'exécution doit répondre à l'IL)

3. proposant envoyé par les constructeurs Choisissez l'un des "SignedExecutionPayloadHeader" pour l'inclure (généralement celui avec le prix le plus élevé payé au proposant est sélectionné). Et diffusez le bloc balise proposé "SignedBeaconBlock".

4. Les témoins effectuent des tâches de témoignage

5. Les agrégateurs soumettent des agrégats d'attestation ; en même temps, le constructeur diffuse la charge utile d'exécution

6. PTC (Payload Timeliness Committee), dans chaque emplacement, 512 validateurs seront sélectionnés en tant que membres du PTC) vérifiez si le constructeur révèle la charge utile d'exécution à temps et diffuse les résultats

ePBS a également fait l'objet de nombreuses discussions depuis le moment où il a été proposé jusqu'au numéro EIP final. Initialement, le PBS a été proposé par Vitalik le 21 juin, et la solution à deux emplacements a été améliorée quatre mois plus tard. Trois mois plus tard, le PBS à un emplacement a été lancé. Ce n'est que le 23 juillet que l'idée du PTC a été officiellement proposée. .

PEPC (Protocol-Enforced Proposer Commitments)

Bien sûr, il y a aussi ceux qui ne sont pas d'accord avec ePBS et espèrent utiliser d'autres solutions à la place. PEPC est comme ça. ePBS intègre une certaine règle dans le protocole, mais ici, au PEPC, le proposant vend des droits de construction de blocs programmables.

PEPC a été proposé par barnabe en octobre 2022. barnabe estime que si le mécanisme PBS doit être implémenté dans le protocole, il devrait envisager d'implémenter un mécanisme général pour la transmission de signaux de confiance, plutôt que d'implémenter un mécanisme de signal de confiance spécifique (par exemple, si on me demande de construire un bloc), je le ferai vous renvoie xx ETH).

Tout comme le nom de PEPC (Protocol-Enforced Proposer Commitments), certains mécanismes visant à garantir les droits et intérêts des constructeurs et des proposants sont complétés à travers les engagements soumis par le proposant dans le cadre du protocole. Ces engagements peuvent être vérifiés sur la chaîne, principalement par le code d'opération "BEACONROOT" à réaliser. Il s'agit d'un mécanisme plus général. L'engagement peut externaliser tous les droits de construction de blocs, ou seulement une partie des blocs, c'est-à-dire que le proposant vend des droits de construction de blocs programmables.

Résumé

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!