En février, le développeur Prysm Potuz a estimé qu’il existait un problème de confiance sur le réseau principal d’Éthereum, et a préconisé de reporter le fork Electra à 2025 pour améliorer la conception de l’ePBS lors de l’Interop event. Cependant, la communauté Ethereum a des avis divergents sur l’ePBS, certains développeurs et chercheurs craignant les risques potentiels. Les opinions sur l’ePBS sont variées, et aujourd’hui nous allons comprendre ce qu’est l’ePBS et en quoi il diffère du PBS.
Nous avons mentionné précédemment que le mécanisme PBS est mis en place pour garantir la sécurité des engagements des Proposers et l’interprétation de sécurité des Builders, en confiant ce pouvoir à des Relais de confiance. Les Relais sont responsables de la garde des Blocs pour s’assurer que les Proposers ont accès aux contenus des Blocs, mais ne peuvent pas facilement voler les contenus des Blocs des Builders. Cependant, si un Relais est malveillant, à la fois les Proposers et les Builders en pâtiront, et ils devront se tourner vers d’autres Relais en espérant qu’ils ne sont pas malveillants. Il y a donc un problème ici, nous devons trouver un tiers de confiance pour déléguer la confiance. Parce que le PBS est une solution en dehors du protocole. Le PBS dépend du consensus et du respect volontaire de la communauté, ce qui nécessite une coordination et une confiance supplémentaires.
PBS中必须有一个intermédiaire角色作为第三方授信方处理问题:
Enshrined Proposer-Builder Separation (ePBS) est une autre variante dérivée de PBS. ePBS est une proposition visant à intégrer directement PBS dans la couche de consensus ETH. Il est également appelé In-Protocol PBS. Sa création vise à faire face à d’éventuelles défaillances de Relais et à éliminer les points de défaillance uniques du système. En tant que nouveau Mécanisme de consensus, nous examinerons de plus près ePBS afin de clarifier ses principes fondamentaux, ses avantages et les différences par rapport à la séparation traditionnelle des proposants et des constructeurs (PBS).
ePBS, c’est-à-dire la séparation intégrée des proposants et des constructeurs, est un mécanisme intégré dans le protocole blockchain. Plutôt que de faire confiance à un rôle de relais, comme c’est le cas avec le protocole Ethereum, si l’un des deux, le Proposer ou le Builder, agit de manière malveillante, le protocole Ethereum lui-même peut infliger des sanctions (slashing), sans qu’il soit nécessaire de faire confiance à un quelconque rôle. C’est là la plus grande différence entre l’ensemble du protocole et le protocole PBS que nous avons mentionné précédemment.
Bien sûr, la séparation des rôles dans l’application ePBS reste basée sur le PBS d’origine, ce qui permet d’augmenter le degré de résistance à la censure et de décentralisation du réseau de la chaîne de blocs en contrôlant la capacité d’un seul entité Goutte sur le contenu du Bloc.
En observant le nom, on peut comprendre que Enshrined dans ePBS signifie que le protocole est intégré et qu’il applique des sanctions directes aux comportements malveillants, ce qui entraîne également un changement discret dans le centre de confiance.
Dans PBS, l’identification et la punition des comportements malveillants nécessitent l’intervention de tiers (validateurs, relais, etc.). Avec ePBS, en raison de sa conception dans le protocole, les comportements malveillants peuvent être directement identifiés et traités par le protocole lui-même.
PBS dépend en partie de la gouvernance externe ou des tiers, ce qui pose des problèmes de centralisation de confiance. En revanche, l’ePBS réduit la dépendance aux tiers externes en inscrivant les règles dans le protocole, ce qui permet d’améliorer le degré de décentralisation du système.
*Comparaison entre PBS traditionnel et ePBS
Dans le POS de l’ETH, le temps du slot est divisé en intervalles de 12 secondes. À chaque slot, un validateurs est choisi au hasard pour proposer un Bloc. En même temps, un comité est désigné pour valider la validité du Bloc. Si aucun Bloc n’est proposé dans un slot donné, les validateurs responsables de la preuve vérifieront le Bloc précédent après 4 secondes.
source: ethresearch, un emplacement ePBS sera traité par CL (couche de consensus) et EL (couche d’exécution). Les informations de Bloc sont diffusées dans la couche de consensus, puis le Bloc est soumis à la couche d’exécution pour validation.
Comité de l’Opportunité de la Charge (PTC), “Comité de l’Opportunité de la Charge”. Sa mission principale est de garantir que le contenu des transactions dans le nouveau Bloc soit ajouté en temps opportun et avec précision. Ce comité est composé de validateurs (dont 521 empruntés au comité de la chaîne de balises en tant que membre du comité), dont le travail consiste à vérifier si le Builder a terminé le remplissage des transactions du Bloc avant la fin de chaque cycle de création de Bloc et si ces transactions sont exécutées correctement selon les règles.
En un mot, le PTC est comme une équipe de surveillance, surveillant si le Builder a soumis son travail à temps et s’il contient le Bloc de transaction correct. Si le Builder fait bien son travail, soumettant à temps des Blocs conformes, le PTC le confirmera par un vote. De cette façon, le réseau peut savoir quels Blocs sont complets et valides, et lesquels pourraient poser problème ou être incomplets.
À travers le mécanisme de vote, PTC affecte l’état du Bloc en tant que “Bloc complet” ou “Bloc vide”. Si PTC valide l’opportunité et l’exactitude de la charge, ce Bloc peut être considéré comme étant dans l’état “Bloc complet” ; si aucune charge n’est présente ou si la soumission de la charge est en latence, alors le Bloc peut être étiqueté comme “Bloc vide”. Ensuite, en fonction des résultats du vote de PTC, le réseau récompense ou punit directement le Proposer et le Builder pour encourager la construction opportune et précise des Blocs.
Bien que le cœur de conception de ePBS soit centré sur la sécurité du Builder, il accorde au Builder un contrôle total sur les transactions de Bloc. Ainsi, sur cette base, l’utilisation de la Liste d’inclusion serait une combinaison parfaite pour réaliser une forme de résistance à la censure et de Décentralisation.
Dans nos articles précédents, nous avons mentionné CL et expliqué brièvement le processus (pour plus de détails, veuillez cliquer sur le lien: undefined). ** Fournissez cette liste à Builder et privilégiez ces transactions. Il devrait couvrir toutes les transactions actives actuelles, qu’elles soient dans le pool de transactions ou non. Tant qu’il reste de l’espace dans le bloc, les transactions de la liste doivent être incluses dans le bloc Builder. Si le bloc est plein, Builder doit le signaler clairement et confirmer qu’il a pris note de cette liste.
Lorsque le Builder tente de vérifier certaines transactions, la mise en œuvre de l’EIP-1559 entraînera une Hausse rapide des frais de base remplissant continuellement le Bloc avec des transactions. Si le Builder persiste à vérifier en ajoutant de fausses transactions dans le Bloc à ce stade, les frais croissants rendront ce comportement excessivement coûteux et finalement peu pratique.
ePBS sépare les rôles des initiateurs et des constructeurs grâce à un protocole intégré. PTC, en tant que sous-ensemble du comité de validation, est responsable de voter sur la validité et l’opportunité des charges utiles de l’Builder. Son avantage clé réside dans sa transformation du rôle traditionnel d’un tiers de confiance en une supervision et une sanction exécutées par le protocole Ethereum lui-même, réduisant ainsi la dépendance à l’égard d’une entité unique. Cela améliore non seulement la résistance à la censure du système, mais renforce également la protection des transactions grâce à des mécanismes tels que la liste d’inclusion, rendant ainsi le coût de la vérification des transactions élevé et peu pratique.
En outre, veuillez noter que ePBS offre simplement une option de séparation du proposant de bloc et du constructeur au niveau du protocole, ce n’est pas obligatoire. La plus grande différence entre eux réside dans le mécanisme de paiement et le modèle de confiance. Lorsque l’on considère la question de confiance de l’ensemble du protocole, il faut accepter le coût de s’engager à payer à l’avance. Comparé à ePBS, MEV-Boost peut décider du montant à payer au proposant de Beacon en fonction des revenus générés par la charge utile de l’exécution ordonnée par soi-même, offrant ainsi plus de profit et de flexibilité. Peut-être qu’un jour, lorsque le mécanisme ePBS sera mis en œuvre, il ne sera plus nécessaire de considérer les frais d’engagement préalable. J’ai un petit rêve et une petite attente !