## TL; 博士---* ePBSの設計の中心は、Builderのセキュリティを重視した概念に基づいており、Builderにブロックトランザクションの完全な制御権を付与します。* ePBS は、PBS を直接ETH坊の共識層に組み込む提案であり、In-Protocol PBS と呼ばれ、潜在的なリレーの障害に対処し、システム内の単一障害を排除することを目的としています。* ePBS 依然、オリジナルのPBSの基盤を維持し、単一の実体によるブロック内容のコントロール能力をドロップし、ネットワークの検閲抵抗と分散化を向上させます。* ペイロードタイムリネス委員会（PTC）は、新しいブロック内の取引内容のタイムリネスと有効性を監督し、確保します。## イントロダクション2月、Prysmの開発者であるPotuzは、ETHメインネットワークに信頼性の問題があると考え、Electraフォークを2025年まで延期し、Interopイベントを利用してePBSデザインを改善することを提案しました。しかし、ETHコミュニティでは、一部の開発者や研究者がePBSがもたらす可能性のあるリスクに懸念を抱いています。ePBSについては、意見が分かれており、今日はePBSとPBSの違いについて理解していきます。以前に、私たちはPBSのメカニズムがProposerの約束の安全性とBuilderの解釈の安全性を確保するために、この権利を信頼されたリレーに委任することを述べました。リレーはブロックの内容を保管し、Proposerがブロックの内容を受け取ることを確認しますが、Builderのブロックの内容を簡単に盗むことはできません。しかし、リレーが悪意を持っている場合、ProposerとBuilderの両方が被害を受け、彼らは他のリレーと協力し、他のリレーが悪意を持っていないことを期待するしかありません。ここには1つの問題があります。信頼できる第三者を見つけて信頼を委任しなければなりません。なぜなら、PBSはプロトコル外の解決策です。PBSはコミュニティのコンセンサスと自発的な遵守に依存し、追加の調整と信頼が必要です。PBSには、問題を処理するための第三者信用提供者としての仲介者の役割が必要です:*提案者は、コンテンツをブロックする権利を販売する場合、仲介者を信頼する必要があります。* Builderがブロックを構築する権利を購入するには、仲介者を信頼する必要があります。### ePBS の革命的なデザイン### ビルトインプロポーザー-ビルダーセパレーションEnshrined Proposer-Builder Separation（ePBS）は、PBSの派生物の1つであり、内部提案者とビルダーの分離を実現するものです。ePBSは、ETHブロックチェーンのコンセンサスレイヤーにPBSを直接統合することを提案したものであり、In-Protocol PBSとも呼ばれています。ePBSの誕生は、中継障害やシステム内の単一障害点を排除するための需要に対応するためです。新興のコンセンサスメカニズムとして、ePBSの核心原理、メリット、および従来のProposer-Builder Separation（PBS）との違いについて詳しく説明します。ePBS、すなわち内蔵提案者-ビルダー分離、ブロックチェーンプロトコルに内蔵されたメカニズム。イーサリアムプロトコルによって、信頼されるリレーの役割を必要とする代わりに、提案者またはビルダーのいずれかが悪事を行った場合、イーサリアムプロトコル自体が罰則（スラッシング）を科すことができ、特定の役割に依存する必要がない。これがPBSプロトコル全体と以前に述べたPBSプロトコルとの最大の違いと異なる点でもあります。もちろん、ePBSの適用においては、角色の分離は元のPBSの基礎を踏襲しており、ブロックチェーンネットワークの検閲抵抗性と分散化の程度を向上させるために、ブロックの内容を単一の実体からドロップする能力を利用しています。* 提案者：ブロック提案者、ブロックヘッダー情報を含む* Builder: ブロックを構築する具体的な内容## 2つの素晴らしい点## 悪行を直接処罰し、第三者の信用を必要としない名前から見ると、ePBSのEnshrinedから、プロトコルを内蔵する作業が行われるため、悪質な行為に直接的な罰則が課され、信頼センターもこの設定下で静かに変化しています。1. プロトコルは識別および処理能力を持ち、直接罰するPBSでは、悪質な行為の特定と処罰にはサードパーティ（バリデータ、リレーなど）の介入が必要です。一方、ePBSでは、その設計上の理由から、悪質な行為はプロトコル自体によって直接特定および処理されます。1. 信用認証の第三者が必要なく、分散化のレベルを向上させますPBS はある程度、外部ガバナンスや第三者に依存しており、中央集権的な信頼問題が存在します。それに対して、ePBS はルールをプロトコルに書き込むことで、外部第三者への信頼要求を根源から減らし、システムの分散化を高めています。**\*従来のPBSとePBSの比較******### ePBS デザイン### 実行と検証のダンスETH坊 POSでは、slotの時間が12秒間隔に分割されています。各slotでは、ランダムに1つのバリデータがブロックを提案し、同時に委員会がブロックの有効性を検証します。指定されたslotでブロックが提案されなかった場合、4秒後に責任を持って証明するバリデータが前のブロックを検証します。source:ethresearchでは、ePBSスロットはCL(コンセンサス層)とEL(実行層)によって処理されます。 ブロック情報はコンセンサス層でブロードキャストされ、ブロックは検証のために実行層に送信されます。1. ブロック入札フェーズ:Buliderは入札を開始し、提案者に送信します。2. 提案者 ブロードキャスト：提案者が入札を選択し、Inclusion Listを使用して自分のブロックの内容を構築するかどうかを選択します。次にブロックをブロードキャストします。3. バリデーターの投票:ブロックが見られると、検証結果に基づいて投票します。4. 聚合证明（ Aggregate attestation）：聚合证明は、アグリゲータが作成し、複数のバリデータによる同じブロックの証明を集約するものです。バリデータは集約証明を使用して検証を行います。5. ペイロードブロードキャスト：ビルダーは所定の時間内に完全な実行ペイロードを公開する必要があります。6. PTC投票：特別委員会、監督および検証Builderのペイロードが適時かつ効果的であるかどうか。7. 次の slot の Proposer が彼らのブロックを公開し、PTC の投票結果と集約証明に基づいて完全なブロックまたは空のブロックに構築します。ブロックの PT 投票数がタイムリーに公開された割合が高いほど、それはフルブロックと見なされます。### PTC、新しいブロック内の取引の内容とタイムリーさ、有効性を監視しますPayload Timeliness Committee（PTC）、「有效なペイロードのタイムリネス委員会」です。主な役割は、新しいブロックにおけるトランザクションの内容が適切に追加されるようにすることです。この委員会はバリデータで構成されており（ビーコンチェーン委員会から借りてきた521人が委員会の一部として構成されています）、各ブロック作成サイクルの終了前に、Builderがブロックのトランザクションの充填作業を完了しているかどうか、およびこれらのトランザクションが規則に従って正しく実行されているかどうかを確認することです。簡単に言えば、PTCは監督チームのようなもので、Builderがタイムリーに彼らの作業を提出し、正しい取引のブロックを含んでいるかどうかを監督します。Builderがうまくやっていて、要件を満たすブロックをタイムリーに提出した場合、PTCは投票によってそれを確認します。これにより、ネットワークはどのブロックが完全で有効であり、どれが問題を抱えているか、あるいは不完全であるかを知ることができます。投票機構により、PTCはブロックが「完全なブロック」または「空のブロック」と見なされるかどうかに影響を与えます。PTCが負荷のタイムリネスと正確性を検証すると、そのブロックは「完全なブロック」と見なされます。負荷がないか、負荷の提出に遅延がある場合、ブロックは「空のブロック」とマークされる可能性があります。その後、PTCの投票結果に基づいて、ネットワークは直接プロポーザーとビルダーに報酬または罰則を科し、タイムリーかつ正確なブロック構築を促進します。*フルブロック:ブロックには有効なペイロードのセットが含まれ、複数のトランザクションを含めることもでき、トランザクションの実行ステータスはタイムリーに更新されます。* 空のブロック（empty block）：ブロックはほとんどトランザクションを含んでいないか、わずかなトランザクションのみを含んでいます。それはクロスリンクブロック（CL block）である場合もありますが、EL状態は更新されません。* 缺失块（missing block）：空のスロット。ブロックチェーン上で期待されているが作成されなかったり、正常にオンチェーンに追加されなかったブロック。ブロック、スロットのフォーク選択投票によって、欠落しているブロックはフルブロックまたは空のブロックに分類されることがあります。### 検閲に強いePBSの実装とインクルージョンリストの設計ePBSの設計コアは、ブロックトレードの完全な制御権をビルダーに与える概念に基づいています。したがって、インクルージョンリストを適用することは、検閲に対抗し分散化を実現する非常に完璧な組み合わせ形式となります。以前の記事でCLについて言及し、プロセスを大まかに説明しました（詳細についてはリンクをクリックしてください：undefined）。Builderにこのリストを提供する際には、これらのトランザクションを優先的に考慮する必要があります。これは、これらのトランザクションがトランザクションプールにあるかどうかに関係なく、現在アクティブなすべてのトランザクションをカバーする必要があります。ブロックに余裕がある場合、リスト内のトランザクションはBuilderのブロックに含める必要があります。ブロックがいっぱいの場合、Builderは明確に識別し、このリストに注意を払っていることを確認する必要があります。ビルダーが特定のトランザクションを確認しようとすると、EIP-1559の実装により、常にトランザクションで満たされているブロックにより、基本料金が急速に上昇します。 ビルダーがレビューのために偽のトランザクションをブロックに追加することを主張する場合、手数料の増加により、この動作は法外に高価で非現実的になります。## まとめePBS はプロトコル内蔵により、提案者と構築者の役割を分離します。PTC は証明委員会のサブセットとして、Builder が発行したution Payload の有効性とタイムリネスに投票する責任を持ちます。その中核的な利点は、従来の信頼第三者の役割を、イーサリアムプロトコル自体が監督と罰を実行するものに変え、単一の実体への信頼を減らすことです。これにより検閲抵抗が向上し、Inclusion List などのメカニズムを通じて取引の保護を強化し、検閲交易のコストを高くし、実現不可能にします。また、ePBSは、ブロックプロポーザーとビルダーを分離するプロトコル層のオプションを提供するだけであり、強制的ではありません。彼らの最大の違いは支払いメカニズムと信頼モデルです。プロトコル全体の信頼性の問題を考慮する際には、事前に費用を支払うことが必要です。ePBSと比較して、MEV-Boostは、自身のソートされたトランザクションペイロードで実現された収益に基づいてBeaconプロポーザーに支払う金額を決定することができ、より多くの利益と余地を持っています。もしかしたら、いつかePBSのメカニズムが事前に費用を払う必要がなくなるときには、少しの幻想と期待を抱くかもしれません！
信頼の危機 実験 ePBSのプロトコルが組み込まれている
TL; 博士
イントロダクション
2月、Prysmの開発者であるPotuzは、ETHメインネットワークに信頼性の問題があると考え、Electraフォークを2025年まで延期し、Interopイベントを利用してePBSデザインを改善することを提案しました。しかし、ETHコミュニティでは、一部の開発者や研究者がePBSがもたらす可能性のあるリスクに懸念を抱いています。ePBSについては、意見が分かれており、今日はePBSとPBSの違いについて理解していきます。
以前に、私たちはPBSのメカニズムがProposerの約束の安全性とBuilderの解釈の安全性を確保するために、この権利を信頼されたリレーに委任することを述べました。リレーはブロックの内容を保管し、Proposerがブロックの内容を受け取ることを確認しますが、Builderのブロックの内容を簡単に盗むことはできません。しかし、リレーが悪意を持っている場合、ProposerとBuilderの両方が被害を受け、彼らは他のリレーと協力し、他のリレーが悪意を持っていないことを期待するしかありません。ここには1つの問題があります。信頼できる第三者を見つけて信頼を委任しなければなりません。なぜなら、PBSはプロトコル外の解決策です。PBSはコミュニティのコンセンサスと自発的な遵守に依存し、追加の調整と信頼が必要です。
PBSには、問題を処理するための第三者信用提供者としての仲介者の役割が必要です:
*提案者は、コンテンツをブロックする権利を販売する場合、仲介者を信頼する必要があります。
ePBS の革命的なデザイン
ビルトインプロポーザー-ビルダーセパレーション
Enshrined Proposer-Builder Separation（ePBS）は、PBSの派生物の1つであり、内部提案者とビルダーの分離を実現するものです。ePBSは、ETHブロックチェーンのコンセンサスレイヤーにPBSを直接統合することを提案したものであり、In-Protocol PBSとも呼ばれています。ePBSの誕生は、中継障害やシステム内の単一障害点を排除するための需要に対応するためです。新興のコンセンサスメカニズムとして、ePBSの核心原理、メリット、および従来のProposer-Builder Separation（PBS）との違いについて詳しく説明します。
ePBS、すなわち内蔵提案者-ビルダー分離、ブロックチェーンプロトコルに内蔵されたメカニズム。イーサリアムプロトコルによって、信頼されるリレーの役割を必要とする代わりに、提案者またはビルダーのいずれかが悪事を行った場合、イーサリアムプロトコル自体が罰則（スラッシング）を科すことができ、特定の役割に依存する必要がない。これがPBSプロトコル全体と以前に述べたPBSプロトコルとの最大の違いと異なる点でもあります。
もちろん、ePBSの適用においては、角色の分離は元のPBSの基礎を踏襲しており、ブロックチェーンネットワークの検閲抵抗性と分散化の程度を向上させるために、ブロックの内容を単一の実体からドロップする能力を利用しています。
2つの素晴らしい点
悪行を直接処罰し、第三者の信用を必要としない
名前から見ると、ePBSのEnshrinedから、プロトコルを内蔵する作業が行われるため、悪質な行為に直接的な罰則が課され、信頼センターもこの設定下で静かに変化しています。
PBSでは、悪質な行為の特定と処罰にはサードパーティ（バリデータ、リレーなど）の介入が必要です。一方、ePBSでは、その設計上の理由から、悪質な行為はプロトコル自体によって直接特定および処理されます。
PBS はある程度、外部ガバナンスや第三者に依存しており、中央集権的な信頼問題が存在します。それに対して、ePBS はルールをプロトコルに書き込むことで、外部第三者への信頼要求を根源から減らし、システムの分散化を高めています。
*従来のPBSとePBSの比較
ePBS デザイン
実行と検証のダンス
ETH坊 POSでは、slotの時間が12秒間隔に分割されています。各slotでは、ランダムに1つのバリデータがブロックを提案し、同時に委員会がブロックの有効性を検証します。指定されたslotでブロックが提案されなかった場合、4秒後に責任を持って証明するバリデータが前のブロックを検証します。
source:ethresearchでは、ePBSスロットはCL(コンセンサス層)とEL(実行層)によって処理されます。 ブロック情報はコンセンサス層でブロードキャストされ、ブロックは検証のために実行層に送信されます。
PTC、新しいブロック内の取引の内容とタイムリーさ、有効性を監視します
Payload Timeliness Committee（PTC）、「有效なペイロードのタイムリネス委員会」です。主な役割は、新しいブロックにおけるトランザクションの内容が適切に追加されるようにすることです。この委員会はバリデータで構成されており（ビーコンチェーン委員会から借りてきた521人が委員会の一部として構成されています）、各ブロック作成サイクルの終了前に、Builderがブロックのトランザクションの充填作業を完了しているかどうか、およびこれらのトランザクションが規則に従って正しく実行されているかどうかを確認することです。
簡単に言えば、PTCは監督チームのようなもので、Builderがタイムリーに彼らの作業を提出し、正しい取引のブロックを含んでいるかどうかを監督します。Builderがうまくやっていて、要件を満たすブロックをタイムリーに提出した場合、PTCは投票によってそれを確認します。これにより、ネットワークはどのブロックが完全で有効であり、どれが問題を抱えているか、あるいは不完全であるかを知ることができます。
投票機構により、PTCはブロックが「完全なブロック」または「空のブロック」と見なされるかどうかに影響を与えます。PTCが負荷のタイムリネスと正確性を検証すると、そのブロックは「完全なブロック」と見なされます。負荷がないか、負荷の提出に遅延がある場合、ブロックは「空のブロック」とマークされる可能性があります。その後、PTCの投票結果に基づいて、ネットワークは直接プロポーザーとビルダーに報酬または罰則を科し、タイムリーかつ正確なブロック構築を促進します。
*フルブロック:ブロックには有効なペイロードのセットが含まれ、複数のトランザクションを含めることもでき、トランザクションの実行ステータスはタイムリーに更新されます。
検閲に強いePBSの実装とインクルージョンリストの設計
ePBSの設計コアは、ブロックトレードの完全な制御権をビルダーに与える概念に基づいています。したがって、インクルージョンリストを適用することは、検閲に対抗し分散化を実現する非常に完璧な組み合わせ形式となります。
以前の記事でCLについて言及し、プロセスを大まかに説明しました（詳細についてはリンクをクリックしてください：undefined）。Builderにこのリストを提供する際には、これらのトランザクションを優先的に考慮する必要があります。これは、これらのトランザクションがトランザクションプールにあるかどうかに関係なく、現在アクティブなすべてのトランザクションをカバーする必要があります。ブロックに余裕がある場合、リスト内のトランザクションはBuilderのブロックに含める必要があります。ブロックがいっぱいの場合、Builderは明確に識別し、このリストに注意を払っていることを確認する必要があります。
ビルダーが特定のトランザクションを確認しようとすると、EIP-1559の実装により、常にトランザクションで満たされているブロックにより、基本料金が急速に上昇します。 ビルダーがレビューのために偽のトランザクションをブロックに追加することを主張する場合、手数料の増加により、この動作は法外に高価で非現実的になります。
まとめ
ePBS はプロトコル内蔵により、提案者と構築者の役割を分離します。PTC は証明委員会のサブセットとして、Builder が発行したution Payload の有効性とタイムリネスに投票する責任を持ちます。その中核的な利点は、従来の信頼第三者の役割を、イーサリアムプロトコル自体が監督と罰を実行するものに変え、単一の実体への信頼を減らすことです。これにより検閲抵抗が向上し、Inclusion List などのメカニズムを通じて取引の保護を強化し、検閲交易のコストを高くし、実現不可能にします。
また、ePBSは、ブロックプロポーザーとビルダーを分離するプロトコル層のオプションを提供するだけであり、強制的ではありません。彼らの最大の違いは支払いメカニズムと信頼モデルです。プロトコル全体の信頼性の問題を考慮する際には、事前に費用を支払うことが必要です。ePBSと比較して、MEV-Boostは、自身のソートされたトランザクションペイロードで実現された収益に基づいてBeaconプロポーザーに支払う金額を決定することができ、より多くの利益と余地を持っています。もしかしたら、いつかePBSのメカニズムが事前に費用を払う必要がなくなるときには、少しの幻想と期待を抱くかもしれません！