Le cœur de la conception de ePBS tourne autour du concept de sécurité du Builder, lui accordant un contrôle total sur les transactions des Blocs.
ePBS est une proposition visant à intégrer directement le PBS dans la couche de consensus de l'ETH, appelée In-Protocol PBS, dans le but de faire face aux éventuelles défaillances du relais et d'éliminer les points de défaillance du système.
ePBS continue à suivre la base originale de PBS, en renforçant la capacité de contrôle des contenus de Bloc par une seule entité Goutte, pour améliorer la résistance à la censure du réseau et la décentralisation.
Le comité de ponctualité de la charge utile (PTC) agit comme un organe de surveillance pour garantir la pertinence et l'efficacité du contenu des transactions dans les nouveaux blocs.
Préface
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角色作为第三方授信方处理问题：
Si le proposant souhaite vendre les droits de contenu Bloc, il doit faire confiance à l'intermédiaire.
Les constructeurs qui souhaitent acheter le droit de construire Bloc doivent faire confiance à l'intermédiaire.
Conception révolutionnaire d'ePBS
Séparation du constructeur intégré-proposant
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.
Proposer：Responsable de la proposition de Bloc, y compris les informations d'en-tête de Bloc
Builder：construire le contenu spécifique du Bloc
Deux grands avantages
Punir directement les comportements répréhensibles et ne pas avoir besoin d'un tiers de confiance
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.
Le protocole a la capacité de reconnaissance et de traitement, et peut punir directement
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.
Sans avoir besoin de faire confiance à un tiers, améliorer le niveau de Décentralisation
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
Conception ePBS
La danse de l'exécution et de la vérification
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.
Étape de BlocEnchères: Bulider commencera les Enchères et les enverra à Proposer.
Le diffuseur : le diffuseur choisit les enchères et décide s'il utilise la liste d'inclusion pour construire le contenu de son bloc. Ensuite, il diffuse le bloc.
Les validateurs votent : après avoir vu le bloc, ils votent en fonction de son résultat de validation.
Preuve d'agrégation (Aggregate attestation) : La preuve d'agrégation est créée par des agrégateurs, qui agrègent les preuves de plusieurs validateurs pour le même Bloc. Les validateurs valident à travers la preuve d'agrégation.
charge utile diffusion : Le constructeur doit diffuser publiquement la charge utile d'exécution complète dans le délai imparti.
Vote PTC : Comité spécial pour superviser et valider si la charge utile du Builder est opportune et efficace.
Le Proposer du prochain slot publie son Bloc, construit sur un Bloc vide ou un Bloc complet en fonction des résultats du vote du PTC et de la preuve d'agrégation. Lorsque le pourcentage de temps de publication des votes PT d'un Bloc est plus élevé, il est considéré comme un Bloc complet.
PTC, supervision de la chronologie et de l'efficacité des transactions dans les nouveaux blocs.
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.
Bloc complet（full block）：Bloc contenant un ensemble de charges utiles valides, pouvant également contenir plusieurs transactions, et l'état d'exécution des transactions sera mis à jour en temps opportun.
实现 ePBS 的résistance à la censure，结合 Inclusion List 的设计
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.
Résumé
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 !
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Crise de confiance实验 ePBS的protocole内置
TL;DR
Préface
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角色作为第三方授信方处理问题：
Conception révolutionnaire d'ePBS
Séparation du constructeur intégré-proposant
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.
Deux grands avantages
Punir directement les comportements répréhensibles et ne pas avoir besoin d'un tiers de confiance
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
Conception ePBS
La danse de l'exécution et de la vérification
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.
PTC, supervision de la chronologie et de l'efficacité des transactions dans les nouveaux blocs.
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.
实现 ePBS 的résistance à la censure，结合 Inclusion List 的设计
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.
Résumé
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 !