Comment EIP-7732 (ePBS) optimise-t-il le processus de vérification des blocs ?

Contexte et motivation de l'EIP-7732

Étant donné que le problème du MEV est difficile à résoudre à la racine, prendre des mesures de concurrence loyale est le seul moyen d'éviter les risques de sécurité. Après la fusion d'Ethereum, afin de maintenir l'équité et de réduire l'effet d'échelle des grands pools de promesses de don sur l'extraction de MEV, Flashbots a lancé MEV-Boost, qui utilise le mécanisme PBS (Proposer-Builder Separation) pour réduire les opportunités pour les validateurs de participer directement. dans les activités MEV et convertir la diversité des parties prenantes de MEV. À l'heure actuelle, la proportion de blocs MEV-Boost dépasse 90 %.

Avec l'adoption généralisée de MEV-Boost, la communauté Ethereum a commencé à s'inquiéter des risques de sécurité pouvant découler du recours à ce service tiers. C'est pourquoi l'idée d'implémenter PBS dans le protocole Ethereum est née, appelée. ePBS (Séparation Enshrined Proposer-Builder). Récemment, ePBS s'est vu attribuer un numéro EIP officiel : EIP-7732. EIP-7732 est une modification de la couche consensus sans nécessiter de modification de la couche d'exécution. L'essentiel est de séparer logiquement et temporellement la vérification de l'exécution de la vérification du consensus, et de reporter la vérification de l'exécution jusqu'à ce que la vérification du consensus soit terminée.

EIP-7732 est proposé, en plus de résoudre le problème des vérificateurs s'appuyant sur des tiers (tels que MEV-Boost) pour créer des charges utiles d'exécution, il vise également à optimiser l'efficacité du processus de vérification. Les validateurs actuels doivent parvenir à un consensus et exécuter des fonctions de transition d'état dans un délai très court (dans les 4 secondes), ce qui nécessite des ressources informatiques et une bande passante réseau extrêmement élevées. Pendant cette période fenêtre, les validateurs doivent vérifier et confirmer une grande quantité d'informations sur les transactions et mettre à jour l'état de la blockchain, ce qui non seulement augmente la charge de calcul d'un seul nœud, mais augmente également le risque d'erreurs. En séparant la vérification de l'exécution et la vérification du consensus, il est garanti que les nœuds n'ont besoin d'accomplir que relativement peu de tâches dans la fenêtre critique de 4 secondes, réduisant ainsi la charge de calcul et accélérant la propagation du réseau.

Le contenu principal de l'EIP-7732

EIP-7732 crée un nouveau rôle "Constructeur", qui est une nouvelle responsabilité facultative du validateur Toute personne disposant de suffisamment de fonds pour miser sur la chaîne de balises et ayant la capacité de tout validateur qui. effectue des tâches de construction de blocs et peut devenir constructeur. Le constructeur est responsable de la construction et de la soumission des promesses d'exécution de la charge utile. Les validateurs peuvent désormais sous-traiter l’exécution des charges utiles aux constructeurs, tout en se concentrant davantage sur les tâches consensuelles.

La charge utile d'exécution est la partie centrale du bloc et contient toutes les informations sur les transactions et les changements de statut. Le processus de création d'une charge utile d'exécution comprend la sélection de transactions dans le pool de mémoire, le tri des transactions, l'exécution des transactions en séquence et le regroupement de toutes les informations pour former une charge utile d'exécution.

Pour réaliser cette séparation, EIP-7732 supprime le champ ExecutionPayload, qui contient toutes les données liées à l'exécution des transactions, telles que la liste des transactions et les résultats de transition d'état. En supprimant ce champ, la création et la vérification du contenu d'exécution sont séparées de la création et de la vérification du bloc balise. Comme alternative, EIP-7732 introduit une nouvelle structure de données, SignedExecutionPayloadHeader, qui inclut la promesse du constructeur d'une charge utile d'exécution qui sera révélée dans le futur.

Processus global

Tâches du constructeur : le constructeur est responsable de la création de la charge utile d'exécution et de la génération d'une promesse qui exposera la charge utile d'exécution. La promesse est encapsulée dans une structure de données SignedExecutionPayloadHeader, qui comprend un hachage de la charge utile d'exécution et une signature numérique de ce hachage pour garantir l'immuabilité des données et la vérification de l'origine. Cette promesse indique que le constructeur exposera la charge utile d'exécution complète à un moment déterminé dans le futur et spécifie un montant à payer au proposant du bloc de balise pour inciter le proposant du bloc de balise à inclure cette promesse.

Les tâches du proposant du bloc balise : Le proposant du bloc balise (validateur) coopère avec le constructeur et n'a pas besoin de gérer directement les détails d'exécution de la transaction lors de la création d'un nouveau bloc balise, mais inclut l'engagement fourni par le constructeur, puis diffusez l'intégralité du bloc de balise sur le réseau Ethereum pour parvenir à un consensus. L’inclusion uniquement d’engagements réduit la charge sur le réseau et accélère la propagation des blocs balises et le processus de vérification du consensus. Une fois l'engagement du constructeur traité, le pourboire de l'engagement est déduit du solde de la chaîne de balise du constructeur et crédité au proposant du bloc de balise. Une fois qu'un proposant de bloc de balise a diffusé avec succès un bloc de balise avec un engagement, le constructeur est tenu d'exposer la charge utile d'exécution complète dans une fenêtre de temps spécifiée.

Vérification PTC : pour vérifier si les constructeurs exécutent publiquement les charges utiles en temps opportun, un groupe de validateurs sélectionnés au hasard par le réseau Beacon Chain forme le Payload Timeliness Committee (PTC). Le PTC est chargé de vérifier si le constructeur a exposé une charge utile d'exécution qui correspond à la promesse dans la fenêtre de temps spécifiée. Si le constructeur ne divulgue pas ses informations en temps opportun et de manière correcte, PTC diffusera un résultat négatif et le constructeur s'exposera à une pénalité de réduction de mise. Si la vérification PTC réussit, la vérification complète de la charge utile d'exécution est différée pour être traitée séparément lors du prochain bloc de balise, c'est-à-dire une vérification différée.

En outre, la proposition introduit également des règles réglementaires et un nouveau mécanisme de pénalité pour PTC afin de garantir la rigueur et l'équité de l'ensemble du processus de vérification. Dans le même temps, en raison de la séparation des charges utiles d'exécution et des blocs balises, la logique de sélection des forks a également été ajustée pour s'adapter au nouveau processus de vérification. Ces changements devraient améliorer considérablement la sécurité et l'efficacité du réseau. Grâce à une série de conceptions, l'EIP-7732 améliore l'efficacité du traitement d'Ethereum et réduit la latence du réseau.

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!