https://ethresear.ch/t/how-much-can-we-constrain-builders-without-bringing-back-heavy-burdens-to-proposers/13808
提案者に重い負担を戻さずに、ビルダーをどれだけ拘束できるか?
ビルダーの集中化のリスク (主に検閲ですが、さまざまな形態の経済的搾取も含まれます) に対する 1 つの自然な対応は、ビルダーが持つ力を制限しようとすることです。ビルダーが完全な手綱を持って構築するのではなく、全体 ブロックがオークションに勝った場合、ビルダーはより制限された量のパワーを持つことになります。このパワーは、捕捉できるほとんどすべての MEV を捕捉するのに十分なはずであり、理想的には PBS の他の利点を捕捉するのに十分なはずですが、乱用の機会を制限するために弱めるべきです.
このアイデアは、部分ブロック オークションと呼ばれることもあります。ブロック内のすべてを決定する権利をオークションにかけるのではなく、決定権をオークションにかけます。いくつかのこと 、これらの「いくつかのこと」は、例よりもはるかに微妙な場合があります。 「ビルダーはブロックの前半を選択し、後半は選択しない」: ビルダーに並べ替え、先頭に追加、追加する権利を与えることができ、プロポーザーを制約することさえできます。この投稿では、これを行うためのいくつかの可能な方法と、その結果生じるいくつかのトレードオフについて説明します。
包含リスト
包含リストパラダイムでは、提案者は包含リスト 、ビルダーがブロックを埋めることができない限り、彼らが要求するトランザクションのリストをブロックに含める必要があります完全に 他の取引と。
異常な外部インセンティブの影響を受けない利益を最大化するビルダーにとって、包含リストはまったく制約にはなりません。追加のトランザクションをブロックの最後に追加すると、常にそのトランザクションの優先料金が余分な利益としてビルダーに与えられます。
ブロックが完全なガス制限 (ターゲットの 2 倍) まで満たされている場合、ビルダーはそのトランザクションと他のトランザクションのどちらかを選択する必要があり、制約は無効になります。基本料金が指数関数的に上昇するため(6ブロックごとに約2.02倍)、完全なブロックの実行は短時間しか維持できないため、これは長期的な包含には影響しません。
ただし、ビルダーが承認しない、または除外するよう奨励されている特定のトランザクションを含めることを拒否したい場合、そのビルダーはオークションに参加しないことを余儀なくされます。
この設計はかなり単純ですが、いくつかの弱点を説明することが重要です。
- インセンティブの互換性の問題 : ビルダーは事前に包含リストを確認し、ビルドしたくない包含リストを含むブロックのビルドを拒否できます。これにより、ビルダーがブロックを構築する可能性を最大化するために、提案者が空の包含リストを持つ即時のインセンティブが作成されます。
- 提案者の余分な負担 : 提案者は、手数料を支払うトランザクションを識別できる必要があります。これには、(i) mempool へのアクセスと、(ii) 状態を読み取って手数料の支払い状況を判断する機能、またはトランザクションに関連付けられた証人が必要です。証人は、バリデーターがステートレス クライアントである可能性があるという PBS プロパティを保持するため、望ましいです。
- ビルダーはまだいくつかの悪用に関与することができます :特にサンドイッチ攻撃。ただし、高度な暗号化を使用して mempool を暗号化するなどの極端なアプローチなしに、この問題をどのように取り除くことができるかは明確ではありません。そうしないと、ビルダーからこの力を奪うことは提案者に権限を与えることを意味し、提案者がステークプールに参加する動機となるからです。
- アカウントの抽象化が機能するには、部分的な安置が必要です: 見るアカウントの抽象化への道 - HackMD
サフィックスを提案する
別の構成は、提案者がブロックのサフィックスを作成できるようにすることです。ビルダーは、ブロックを構築するときに提案者の意図に関する情報を確認できず、提案者は、ビルダーが見逃したトランザクションを最後に追加できます。
- インセンティブの互換性の問題を軽減 : ビルダーは、ビルダーが承認しないトランザクションを含むプロポーザーを遡及的に罰することができます (たとえば、将来のビルドを拒否することにより)、ルートをビルダーに送信します。これは避けられませんが、ビルダーがリアルタイムでブロックを構築することを拒否できるよりも、プロポーザーにとってははるかにフレンドリーです (特に、個々のプロポーザーはたまにしかプロポーズしないため、今日では 2 か月に 1 回)。
- 提案者のさらなる負担増 - プロポーザーは、状態後のルートを計算する必要があります。これは、プロポーザーが状態全体を保持する必要があることを意味します。したがって、提案者がこのタスクを外部委託しない限り、無国籍はあり得ません。別 仲介者。
- 提案者はいくつかの MEV 機会を得る ビルダーからの応答を取得してからブロックを公開する必要があるまでの間。これはおそらく0.5秒の価値しかありませんが、バリデーターが社内で最適化できるようにステークプールに参加するインセンティブをいくらか増加させます.
- ビルダーは、以前と同様に、いくつかの悪用を行うことができます
- アカウントの抽象化が機能するには、部分的な安置が必要です。 従来通り
提案者サフィックスの修正: pre-commitment
提案者は、マークル ツリーまたは KZG コミットメント、または含めたい tx のセットの他のアキュムレータに事前コミットします。ビルダーはブロックを作成します。次に、提案者は、ビルダーによってまだ含まれていないマークル ツリーのサブセットから正確に構成されるサフィックスを追加する必要があり、ガス制限により、txhash またはその他の標準化された順序で並べることができます (他のオプションを追加する場合)。接尾辞、それらはスラッシュされます)。
スラッシングを強制する詳細は、特に提案者の包含ツリーを平文に置きたくない場合は、多少複雑になります。 KZG コミットメントと専用の ZK-SNARK を使用すると、「コミットメント X のセットから開始し、Y にあるものをすべて削除すると、残りのセットは Z 」。
これにより、提案者の MEV の機会が失われます。これは、ビルダーが独自のブロック コンテンツを返信すると、提案者はどのブロックを公開するかについて自由度がゼロになるためです。ただし、他の問題は未解決のままです。
長期的なエンドゲーム: ビルダーをどのように制約するかと 提案者の責任を最小限に抑えますか?
提案者の役割は、理想的には最小限にとどめる必要があります。含めるに値するトランザクションを特定するだけです。提案者の役割を最小限に抑えることで、その役割が非常にアクセスしやすくなります。理想的には、ビルダーの役割は最小限に抑える必要があります。ビルダーは、mempool からのトランザクションを並べ替え、独自のトランザクションを挿入して MEV を収集する権利を持つ必要があります。ブロックに含まれるトランザクションに基づいてブロックを区別することはできません。
ただし、これにより、他の多くの重要なタスク、特に将来必要になるタスクが割り当てられないままになります。
- 状態後のルートを計算するタスク
- 証人の計算と発行のタスク
- ブロックの正しさを証明する ZK-SNARK を作成するタスク
これらのタスクがビルダーまたは提案者に渡されない場合、それらはいくつかに渡される必要があります。三番目 俳優。これを実装するには、いくつかの方法があります。
- 提案者が契約し、関数の出力 (ZK SNARK 生成、状態ルートの計算など) を計算する仕事を行う専門のクラウド コンピューティング プロバイダーであると見なす、ビルダーのような仲介者の別のクラスを作成します。ブロックの内容の選択には関与しません
- 私たちは、次 ブロックを変更して、前のブロックのこれらの値を含めます。これらの値を構築し、必要に応じてそれらを検証するための仲介者を見つけるのは、次のブロックの提案者次第です。
- 私たちはプロトコル内の仲介者の別のクラスを定め、プロトコル内のインセンティブを追加します
- これらの値を公開するのは、ネットワーク内の利他的なアクターに任せます (ブロックにハッシュされないようにします)。アテスターは、提供された正しい値を確認して初めてアテスターになります。
いずれにせよ、ビルダーが利用できる権限と情報、および提案者に課せられる負荷を最小限に抑える必要性は、ブロック生成パイプラインに第 3 のアクターが必要であることを明確に示しているようです (弾丸をかじって受け入れない限り)。そのビルダーは包含リストを見る権利を持っているため、同じスロットに含まれている特定のトランザクションを区別します)。これがどのように処理されるかについて、より深く考え始める必要があります。