信頼危機実験：Enshrined Proposer-Builder Separation (ePBS) プロトコル 統合

TL;DR

• ePBSは、ビルダーのセキュリティに焦点を当てて設計されており、ビルダーにはブロックトランザクションの完全な制御権が与えられます。
• EthereumのコンセンサスレイヤーにProposer-Builder Separation (PBS)を直接統合し、In-Protocol PBSとして言及され、潜在的なリレーの失敗を解決し、システムの単一障害点を排除します。
• ePBSは、ブロックコンテンツに対する単一のエンティティの制御を減らし、ネットワーク検閲への耐性と分散化を強化することで、PBSの基盤を継続します。
• ペイロードタイムリネス委員会（PTC）は、新しいブロックの取引のタイムリネスと有効性を確保します。

導入

2月に、Prysmの開発者であるPotuzがEthereumのメインネットでの信頼性の問題について懸念を表明し、Electraフォークを2025年まで延期し、相互運用性イベントを使用してePBSの設計を洗練することを提案しました。しかし、Ethereumコミュニティ内では意見が分かれ、一部の開発者や研究者が潜在的なリスクを心配しています。ePBSについての意見は分かれており、今日はePBSとPBSの違いについて探っていきます。

以前、PBSメカニズムが、この責任を信頼された中継に割り当てることで、提案者のコミットメントとビルダーの説明のセキュリティを確保することを述べました。中継はブロックのコンテンツを保存し、提案者がブロックのコンテンツを受け取ることを確認しますが、ビルダーのコンテンツを簡単に盗むことはできません。ただし、中継が悪意を持っている場合、提案者とビルダーの両方に損害を与えることができ、彼らは別の中継に切り替えて悪意を持っていないことを願うしかありません。これは問題を提起しています。委任のために信頼された第三者を見つけなければなりません。PBSは、コミュニティの合意と自発的なコンプライアンスに依存するオフチェーンソリューションであり、追加の調整と信頼が必要です。

PBSでは、第三者信頼ハンドラーとして機能する中間役割が必要です:

• ブロックのコンテンツ権利を売りたい場合、提案者は中間者を信頼する必要があります。
• ビルダーは、ブロック構築権を購入したい場合、中間者を信頼する必要があります。

ePBSの革命的なデザイン

ビルトインプロポーザービルダーセパレーション

Enshrined Proposer-Builder Separation（ePBS）は、PBSのバリアントであり、直接Ethereumのコンセンサスレイヤーに統合されています。これは、リレーの障害やシステムの単一障害点を排除するために設計されました。新興のコンセンサスメカニズムとして、ePBSについて、その核心原則、利点、および伝統的なProposer-Builder Separation（PBS）との違いについて説明します。

PBSは、イーサリアムのプロトコル自体を使用することで、信頼されるリレーロールの必要性を排除します。提案者またはビルダーのいずれかが悪意を持って行動した場合、イーサリアムのプロトコルは罰則（没収など）を科すことができ、第三者のロールへの信頼を排除します。これは、信頼が外部にあるPBSとの主な違いです。

それにもかかわらず、ePBSにおける役割分担は依然として元のPBS構造に従っており、1つのエンティティがブロック内容をコントロールすることを減らし、ブロックチェーンネットワークの検閲耐性と分散化を高めています。

• 提案者: ブロックを提案する責任があり、ブロックヘッダー情報を含みます。
• Builder: ブロックのコンテンツを構築する責任があります。

2つの主要な利点

悪意のある行為に対する直接的な罰則と第三者の信頼は必要ありません。

その名前から、ePBSの「Enshrined」という用語は、そのプロトコルに統合された設計を反映しており、悪意のある行動に対する直接の処罰を可能にしています。 この統合により、システム内の信頼モデルが微妙に変化します。

1. 検出および強制のための組み込み機能

   PBSでは、悪意のある行動の特定と処罰は、検証者やリレーなどの第三者の介入に依存しています。これに対して、プロトコルネイティブであるePBSでは、外部の介入を必要とせずにプロトコル自体が直接違反行為を検出し処理することができます。

2. 第三者への依存を減らし、分散化を高めることによる改善

   PBSは本質的に外部ガバナンスや第三者に依存しており、これにより信頼の中心集中要素が導入されています。一方、ePBSはプロトコル内にルールを埋め込むことで、外部信頼への依存を根本的に減らしています。このシフトにより、システムの分散化が向上し、より堅牢で操作に対して抵抗力のあるものとなります。

*伝統的なPBSとePBSの比較👇

ePBSデザイン

実行と検証のダンス

EthereumのProof of Stake（PoS）システムでは、各スロットの時間は12秒の間隔に分割されます。各スロットでは、ランダムにバリデータがブロックを提案し、委員会がブロックの妥当性を検証するように割り当てられます。指定されたスロットでブロックが提案されない場合、担当のバリデータは4秒後に前のブロックを検証します。

ソース：ethresearch、1つのePBSスロットはコンセンサスレイヤー（CL）と実行レイヤー（EL）によって処理されます。ブロック情報はコンセンサスレイヤーで放送され、その後ブロックは実行レイヤーに送信されて検証されます。

1. ブロック入札フェーズ：ビルダーは入札を開始し、入札を提案者に送信します。
2. 提案者のブロードキャスト: 提案者は落札者を選択し、インクルージョンリストを使用してブロックコンテンツを作成するかどうかを決定し、ブロックをブロードキャストします。
3. バリデータの投票：ブロックを見た後、バリデータは自分の検証結果に基づいて投票します。
4. アグリゲートアテステーション：アグリゲーターによって作成されます。アグリゲーターは、同じブロックの複数のバリデーターの証明を結合します。バリデーターは、集計されたアテステーションを使用してブロックを検証します。
5. ペイロードブロードキャスト：ビルダーは指定された時間内に完全な実行ペイロードを公開する必要があります。
6. PTC 投票：ペイロードタイムリネス委員会（PTC）は、ビルダーのペイロードがタイムリーかつ有効であるかを監督および検証します。
7. 次のスロットの提案者はブロックを公開し、PTC の投票結果と集計された証明に基づいて、完全なブロックまたは空のブロックに基づいてブロックを構築します。タイムリーなPT投票の割合が高いブロックは、フルブロックと見なされます。

PTC - 新しいブロックでのトランザクションのタイムリーさと有効性を確保します \ペイロード適時性委員会(PTC)は、新しいブロックのトランザクションがタイムリーかつ正確に追加されることを保証します。この委員会はバリデーター(ビーコンチェーン委員会から借りた521人のメンバー)で構成されており、ビルダーがブロックのトランザクションの充填を完了しているかどうか、およびこれらのトランザクションが各ブロック作成サイクルの終了前にルールに従って正しく実行されているかどうかをチェックします。

簡単に言えば、PTCは監督チームのような役割を果たし、ビルダーが作業を時間通りに提出し、ブロックに正しいトランザクションを含めることを確認します。ビルダーがうまくやっていて、要求されたブロックを時間通りに提出すると、PTCは投票を通じてそれを確認します。このようにして、ネットワークはどのブロックが完全で有効であり、どのブロックに問題があるかまたは不完全かを特定することができます。

投票メカニズムを通じて、PTCはブロックを「フルブロック」とみなすか「空のブロック」とみなすかに影響を与えます。PTC がペイロードの適時性と正確性を検証すると、ブロックは「フルブロック」として認識されます。ペイロードがない場合、またはペイロードが遅延している場合、ブロックは「空のブロック」としてマークされる場合があります。PTCの投票に基づいて、ネットワークは提案者とビルダーに直接報酬を与えたり罰したりして、タイムリーで正確なブロック構築を奨励します。

• フルブロック：ブロックには、複数のトランザクションを含む可能性がある完全な有効なペイロードのセットが含まれており、トランザクションの実行状態は適時に更新されます。
• 空のブロック: ブロックには、トランザクションがほとんど含まれていないか、まったく含まれていません。CL ブロックである可能性がありますが、EL 状態は更新されません。
• Missing Block: スロットが空です。これは、予期されていたが、作成されなかったか、チェーンに正常に追加されなかったブロックを指します。不足しているブロックは、(ブロック、スロット)フォーク選択投票に基づいて、フルまたは空として分類できます。

ePBSの検閲耐性は、インクルージョンリストの設計と組み合わせています

ePBSのコアデザインはビルダーのセキュリティを中心に展開し、ビルダーがブロックトランザクションを完全に制御できるようにしますが、インクルージョンリストを実装することで、検閲耐性と分散化を実現するための完璧な組み合わせになります。

以前の記事で、私たちはCLプロセス（詳細はこちらをご覧ください：https://mp.weixin.qq.com/s/EBzr0ttBLosYnRBNVKF6rg). 手続きを簡単に説明すると、提案者はビルダーに優先順位付けすべきトランザクションのリストを提供します。このリストには、トランザクションプールにあるかどうかに関係なく、すべての現在アクティブなトランザクションが含まれるべきです。ブロックにまだ空きがある限り、ビルダーのブロックにはリストからのトランザクションが含まれるべきです。ブロックがいっぱいの場合、ビルダーは明確に示し、リストを認識したことを確認しなければなりません。

ビルダーが特定の取引を検閲しようとすると、EIP-1559の実装によりベース手数料が急速に上昇し、ブロックが連続して取引で埋め尽くされるためです。ビルダーがブロックに偽の取引を追加し、検閲を行おうとする場合、上昇する手数料によりそのような行動は費用対効果が悪く、実用的ではありません。

概要

ePBSは、プロトコルの統合により、提案者とビルダーの役割を分離しています。検証委員会の一部として、PTCはビルダーによってリリースされた実行ペイロードの妥当性とタイムリネスについて投票する責任を負っています。ePBSの中核的な利点は、信頼できる第三者に依存する代わりに、イーサリアムプロトコル自体によって直接監視され、罰せられることにあります。これにより、システムの検閲耐性が向上するだけでなく、インクルージョンリストなどのメカニズムを通じてトランザクションの保護も強化され、トランザクションの検閲コストが非常に高く、実用的ではありません。

ePBSは、ブロックの提案者とビルダーをプロトコルレベルで分離するオプションを提供するだけでなく、必須であることに注意することが重要です。ePBSと他のモデルの主な違いは、支払いメカニズムと信頼モデルにあります。プロトコル全体の信頼性の問題を考えると、支払うべきコストは、料金を前払いすることを約束する必要があることです。対照的に、MEV-Boostでは、シーケンスされた実行ペイロードから得られた利益に基づいてビーコン提案者への支払いが可能であり、収益性の余地が広がります。もしかしたら、いつの日か、ePBSは、前払い料金のコミットメントが不要になるところまで進化するかもしれません。

リファレンス

@ttsao/epbs-faq0"">https://hackmd.io/@ttsao/epbs-faq0

@potuz/rJ9GCnT1C"">https://hackmd.io/@potuz/rJ9GCnT1C

https://mirror.xyz/ohotties.eth/kw_7qbkOl4NV1pmpRgVwtsS-7TZff_zTmmNEOm2BbmU

https://mirror.xyz/barnabe.eth/LJUb_TpANS0VWi3TOwGx_fgomBvqPaQ39anVj3mnCOg

https://ethresear.ch/t/epbs-design-constraints/18728?u=barnabe

@potuz/ry9NirU2p"">https://hackmd.io/@potuz/ry9NirU2p

https://vitalik.eth.limo/general/2023/09/30/enshrinement.html

https://ethresear.ch/t/three-dichotomies-in-epbs/16267

https://ethresear.ch/t/the-contention-between-preconfs-and-epbs/19770?utm_source=substack&utm_medium=email

免責事項：

1. この記事は[アンコモン]、すべての著作権は元の著者に帰属します[Jocelyn]. If there are objections to this reprint, please contact the Gate Learn(ゲート・ラーン)チームはそれに迅速に対処します。
2. 責任の免除：この記事で表現されている見解や意見はすべて著者個人のものであり、投資アドバイスを提供するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。特に明記されていない限り、翻訳された記事のコピー、配布、盗用は禁止されています。