DAOrayaki: 「提案者と構築者」の分離の本質的価値の詳細な説明
DAOrayaki
2022-12-04 08:25
本文约3391字,阅读全文需要约14分钟
提案者と構築者の分離は活発に議論されているトピックであり、ブロックチェーンを維持および運用するためのプロトコル主体と非プロトコル主体の関係を強調する広範な設計概念であり

Robust Incentives Group @ethereum による元の投稿 -- Barnabé Monnot

オリジナル編集者: DAOctor@DAOrayaki.org

元のタイトル: 提案者と構築者の分離に関するメモ (PBS)

提案者と構築者の分離 (PBS) は、活発に議論されているトピックであり、ブロックチェーンを維持および運用するためのプロトコル アクターと非プロトコル アクターの関係を強調する広範な設計概念です。議論は 1 年以上続いてきましたが、最初に Merge が、2 番目に Devcon が PBS により多くのリソースと注目をもたらしました。この記事では、PBS の現状、本質的な価値、課題に焦点を当てます。

PBSとは何ですか?

PBS は、単一のメカニズムの仕様や実装を超えて、何よりもまず、プロトコル参加者がコンセンサス責任の過程でサードパーティからサービスを呼び出す可能性があることを認識する設計哲学です。 「プロトコル参加者」とは、ブロックの提案、プルーフの作成、現在の同期委員会への参加など、さまざまな任務を実行することが期待される、イーサリアム プルーフ オブ ステークにおける制約付きのアクティブなバリデータです。

マージ前: バンドルサーチャーと mev-geth

ある意味、PBSは合併前に始まり、イーサリアムはプルーフ・オブ・ステークに移行しました。 「デフォルトの動作」は、単にトランザクション プールから一連のトランザクションを取得し、それらを可能な限り効率的にブロックにパックするブロック プロデューサーの動作であると考えられます。このデフォルトの動作からの最初の逸脱は、一部のマイナーが、トランザクションが含まれる条件についてオフチェーンで合意するトランザクションの発信者との直接のプライベート通信回線を開設したことによるものでした。

このような契約は非公開で構築されましたが、Flashbots によって開発された mev-geth は、ブロックプロデューサーとトランザクションオリジネーターの間に市場をすぐに開設しました。マーケットプレイスは、マイナー (PoW ではマイニング プールとして組織される) とシーカーと呼ばれるエンティティ間の信頼関係に依存しています。通常、シーカーはパブリック トランザクション プールまたは運営するプライベート サービスからユーザー トランザクションを調達します。ユーザー トランザクションは、たとえば裁定取引を通じてユーザー トランザクションを追跡したり、清算プロセスを通じてオラクルの更新を追跡したりするなど、ユーザー トランザクションから価値を抽出するために検索者自身のトランザクションとバンドルされます。

バンドルは、バンドルが含まれている場合、シーカーがブロックプロデューサーに支払うという約束で、明確な方法で市場参加者に伝達されます。ただし、市場は既知のブロックプロデューサー、つまりバンドルの盗難を防ぐための主要なマイニングプールのホワイトリストに限定されています。シーカー戦略を複製し、シーカーの支払いを自身の全額支払いに置き換えるブロックプロデューサーは検出され、その後市場から排除され、将来的に多額の支払いを失う可能性があります。ここでは、PBS は、ブロックの先頭に含めるためにシーカーからバンドルを受け取るブロックプロデューサーとして表されます。

マージ後: ブロック ビルダーと mev-boost

合併後、ステーキングプールに参加しない独立したバリデーターの導入により、市場のホワイトリストを維持することが不可能であることが判明しました。独立したバリデーターがブロックを提案する頻度は低く、プロトコルにバインドされているバリデーターの現在の数では、2 か月に 1 回であると推定されています。これにより、ゲームの性質が、逸脱に対するペナルティの脅威を伴う反復的なインタラクションのゲームから、より「単発」であることが多いプレイヤーとのゲームに変わります。

この制約に対する解決策は、バリデーターがコンテンツが何であるかを知る必要なく、バリデーターから特定のブロックのコンテンツに対するコミットメントを取得することです。このマーケットは現在 mev-boost と呼ばれており、ブロックビルダーによって作成されたブロックのヘッダーとビルダーの入札をブロック提案者に転送し、提案者が作成したブロックを選択するための金額を支払うことを約束します。市場の中心となるのは中継者であり、構築者によって構築されたブロックの有効性、つまり、ブロックが EVM 有効であるかどうか、提案者に提案金額を実際に支払ったかどうかをチェックする責任があります。

画像の説明

Devcon デモからのマージされたブロックのビルド

「プロトコル内」PBS に向けて

検証障害や活性障害などのリレー障害の可能性と、システムから新しい単一障害点 (本質的に集中化要因) を除去する機会に直面して、Vitalik は「プロトコル内」PBS 設計を導入しました。これらの設計では、バリデーターは再び、ビルダーから提供されたブロックの使用を盲目的にコミットします。ただし、プロキシ プロトコルの中継ではなく、プロトコル自体が 2 つの保証を提供します。

ビルダーの場合、提案者はコミットメントを行っており、そのコミットメントはコンセンサスの失敗 (例: 単一スロットのファイナリティでの再編成または安全性の失敗) を通じてのみ回復できます。

提案者にとって、最終的にブロック コンテンツのリリースに失敗したり、無効なブロックをリリースしたりするなど、ビルダーが何をしても、ビルダーの支払い約束は履行されます。

プロトコルの 2 つのラウンドを備えたプロトコル内 PBS の可能な設計: 1 つは提案者のコミットメントを確保し、もう 1 つは作成者の開示を確保する

PBS とプリンシパルエージェント問題

AltLayer の Yaoqi Jia との最近のポッドキャストで、私は、PBS は私たちが必要とするものというよりも、プロトコルが対応しなければならない制約であると主張しました。合併の前後に、ブロック生産者はプロトコルの外でブロックの一部を調達することをいとわないため、プロトコルの目標が覆される可能性があります。

歴史的に見て、これは初めてではありません。プロトコルの重要な目標は、報酬の公平性、つまりプロトコル参加者全員がその規模に応じて同じ量の報酬を受け取ることが期待されることです。これは、報酬がネットワークにもたらされるハッシュレートに比例する Proof of Work の場合にも当てはまりますが、報酬は、すべてではないにしてもほとんどのマイナーがマイニング プールに参加し、メンバーと利益を共有する動機となるほど十分に大きく異なります。ただし、ブロックの構築がプール メンバー間で分散されない限り、マイニング プールによって生成されたブロックがプール メンバーの優先順位を尊重するという保証はありません。ファンドプールの行動がメンバーの意向に反する場合でも、ファンドプールから撤退する権利はあり、これも離脱の重要な理由となります。

プロトコル参加者がブロック構築の制御の一部を外部委託するたびに、プリンシパルとエージェントの問題の新たなインスタンスが発生します。このような枠組みでは、プリンシパルはエージェントに何らかのアクションを実行するように要求しますが、プリンシパルとエージェントの動機は完全には一致しない可能性があります。雇用主は従業員にできる限り多くの仕事をしてもらいたいと考えていますが、従業員は労力を最小限に抑えたいと考えているため、適切な報酬体系はインセンティブを再調整するのに役立ちます。ブロック提案者はトランザクションを含めることを望んでいますが、ビルダーはそれらのトランザクションを検閲したい場合があるため、提案者の設定を強制するメカニズムはインセンティブを再調整するのに役立ちます。

市場構造と配分メカニズム

私の意見では、PBS の設計空間をよりよく理解するには、モジュール式の方法で PBS を考えることが理にかなっています。このアプローチにより、プリンシパルとエージェントの問題の構造と、それを解決するためにプロトコルがどの程度介入するかをより明確に検討できるようになります。

市場構造/法制度としての PBS。このプロトコルは、ブロックの構築中に提案者がサードパーティと対話できる条件を定義します。たとえば、プロトコルは、提案者または第三者による支払い約束を強制するなど、契約の強制力を提供します。このプロトコルは、第三者が提案者によるコミットメントを特定するためのツールも提供します。この機能は、取り消しを防ぐ安全なコミットメントを行うプロトコルのコンセンサス メカニズムから来ています。

配布メカニズム/ビジネス ロジックとしての PBS。このプロトコルは、提案者と第三者が締結できる契約の範囲を定義します。たとえば、この契約では、ブロックを生成する完全な権利のみを販売できることを決定し、これらの権利を分配するためにオークションを開催します。

mev-boost では、プロトコルはプリンシパルとエージェントの問題を妨げません。提案者と対話するエンティティとしての構築者の役割を認識していません。せいぜい、コンセンサス層クライアントはステーカーにブロック ヘッダーに盲目的に署名する機能と、おそらくローカル利益変換などの他のサービスを提供しますが、これらはプロトコルの一部ではありません (自分を納得させるために「ビルダー」という単語のみが表示されます)コンセンサス仕様リポジトリの予備的な「シャーディング」セクション)。

この非介入は、市場の相手側が合意を遵守しない場合に提案者が補償を受けることができる、信頼を最小限に抑えるプロトコル内の方法がないことを意味します。これが協定の責任であるかどうかは完全に議論の余地がある。これに関する私の意見はまちまちです。

一方で、利益の最大化を追求する提案者は、ブロックの公開を遅らせたり、ブロックの作成を支援するために外部団体を呼んだりするなど、危険な行為に及ぶ可能性があります。プロトコルはそのような活動を支援することを軽視し、実際にはモラルハザードを可能な限り防止したいと考えるかもしれません。

一方で、ブロック構築とブロック検証の間の非対称性 (Vitalik の Endgame 投稿で説明) は、外部エンティティを呼び出さなければ実装できなかった設計の可能性を実際に開きます。強力なビルダーに Danksharding ブロックの製造を要求するなど、PBS の設計理念に完全に近づけるつもりの場合、そのようなサードパーティとのインターフェース要件がプロトコルによって提案者に課せられます。一部の提案者がプロトコルで要求される義務を実行できない場合 (特にリソースが制約された環境の提案者)、これに基づいて、これらの提案者が必然的に第三者に代わって義務を実行するよう依頼する場合、これは問題になります。取引。

建設業者がその約束を履行することに関してあまり信頼されていない場合、提案者がその義務の履行に全面的に参加するプロトコルよりも社会的利益が小さいプロトコルになる可能性があります。この部分については心配していません。第一に、たとえ競争市場であっても、建設業者は収益性の高い存在です。彼らは、特に支払いがコミットされ、パフォーマンスに関係なく発生する場合、プロトコルに参加するためのブロックを気にします。第 2 に、ビルダーの障害によるブロックの欠落はプロトコルにとって損失ですが、現実世界の遅延が長いという理由だけであれば、常に起こり得ることです。"補う"たとえば、累積的な時間ベースの EIP-1559 による損失。

いずれにせよ、これらの質問に答えることで、イーサリアムとは何か、またはプロトコルとしてどうあるべきかがわかります。俳優に求められるものは何でしょうか?議定書の使命を中心とした経済組織の世界観はどのようなものですか?その懸念の境界線は何でしょうか?

シリーズ 2 では、イーサリアムの最終形態を探す際に考慮される可能性のあるメカニズムのいくつかについて説明します。

DAOrayaki
作者文库