Les validateurs Ethereum sont sur le point d'assumer de nouveaux rôles avec l'introduction de l'EIP-7732, la proposition de séparation Enshrined Proposer-Builder.
Cette proposition change fondamentalement la façon dont les blocs Ethereum sont validés en séparant la validation d'exécution de la validation par consensus à la fois logiquement et temporellement.
Les validateurs sont examinés
Les validateurs ont désormais de nouvelles responsabilités, notamment la possibilité de devenir constructeur et l'obligation de soumettre des attestations de ponctualité des charges utiles.
L’EIP aborde plusieurs problèmes clés du système actuel. La plupart des partisans des blocs balises sous-traitent la construction de la charge utile d’exécution à un tiers, appelé constructeur.
Ils demandent la racine de l'arbre de hachage (HTR) d'une charge utile d'exécution promise et envoient un SignedBlindedBeaconBlock à une partie de confiance. Cette pièce remplace ensuite le HTR par la charge utile d'exécution complète du fabricant avant la transmission.
L'EIP garantit un commerce équitable entre le promoteur du bloc balise et le constructeur. Cela garantit qu'un proposant honnête d'un bloc balise est payé par le constructeur et que la charge utile d'un constructeur honnête devient la tête canonique de la chaîne.
Actuellement, les validateurs disposent d'une courte fenêtre pour effectuer des transitions d'état de consensus et d'exécution, vérifier la disponibilité des données blob et évaluer le nouveau responsable de la blockchain.
Cet EIP change cela en séparant l'exécution du consensus et la validation, permettant aux validateurs de se concentrer sur la transition vers l'état de consensus avant de l'attester.
La validation de l'exécution et de la disponibilité des données est reportée, permettant aux validateurs d'effectuer ces tâches dans le créneau horaire restant.
Justification derrière EIP-7732
La suppression de l’intégralité de la charge utile d’exécution du bloc de consensus permet une propagation plus rapide du réseau. Réduit la probabilité de réorganisation lors de l’inclusion de transactions blob en raison de délais plus longs pour les contrôles de disponibilité des données.
Les validateurs ne perdent plus les réclamations, renforçant ainsi les propriétés de choix des forks lorsque les constructeurs produisent des charges utiles invalides. EIP élimine également le besoin d’un middleware fiable pour déléguer la construction de blocs.
L'EIP ne nécessite pas de modification du niveau d'exécution. Cependant, le niveau de consensus subit plusieurs changements, détaillés dans le référentiel GitHub des spécifications de consensus.
Ceux-ci incluent des modifications apportées à la Beacon Chain, au choix du fork, aux protocoles P2P, aux guides de validation et à l'introduction d'un nouveau guide de construction.
Les modifications apportées à Beacon Chain impliquent des constantes, des préréglages et diverses classes de conteneurs pour gérer les nouvelles revendications de charge utile et les en-têtes de charge utile d'exécution signés.
Le conteneur BeaconState est modifié pour garder une trace du dernier hachage du bloc, du dernier emplacement avec une charge utile d'exécution et de la dernière racine des retraits.
BeaconBlockBody inclut désormais un en-tête de charge utile d'exécution signé et une liste de revendications de charge utile. ExecutionPayloadHeader est simplifié pour suivre les informations minimales pour les engagements de charge utile du constructeur.
Les modifications apportées à la logique de transition d'état incluent de nouvelles fonctions pour le traitement des réclamations de charge utile, des en-têtes de charge utile d'exécution et des demandes de retrait.
Les changements de choix de fork signifient de nouvelles constantes et classes de conteneurs pour gérer les nœuds enfants, les derniers messages et stocker les modifications. De nouveaux gestionnaires pour les messages d'attestation de charge utile et les enveloppes de charge utile d'exécution signées sont introduits.
Reportage de Jai Hamid