イーサネット・コンセンサス対MEVの現在のゲームは、PoWがPoSに切り替わった日から始まっている！

執筆：Techub News、Tia

MEV問題を解決するプロセスは、実はブロックスペースの割り当てルールを書き換えることです。皆さんはもうMEVには馴染みがないと思いますが、EtherのMEVガバナンス提案のいくつかが何を話しているのか知りたいのであれば、まだ背景情報が必要かもしれません。そこでこの記事では、EtherがPoSに移行してからのMEVガバナンスに関する一連の提案、例えばPBS、ePBS、PEPCなどを調べ上げ、皆さんに背景情報を提供できればと思います。

PBS (Proposer Builder Seperatioin) 

イーサが合併する前、MEVに対処する方法はFlashbotsが開発したMEV-Gethを使用することでした。MEV-Gethの仕組みはシンプルで、採掘者がブロックを梱包する際に提出するバンドル利益のサイズを選択できる市場ベースのソリューションです。MEV-Gethのメカニズムはシンプルな市場ベースのソリューションです。この巧妙な市場ベースのメカニズムにより、すべての関係者は利益を得ることができ、同時に一定の制約を形成することができます。サーチャーは利益の一部をマイナーと共有しなければならないが、その見返りとして、マイナーによる盗難に対してより安全な保証を得ることができる。サーチャーが主な利益源として捉えられると、採掘者は受動的にMEV-Gethを利用し始め、採掘者のホワイトリストを維持し、ホワイトリスト上の採掘者のみがサーチャーバンドルを受け取ることができるMEV-Gethのメカニズムによって、さらに制約を受けることになります。採掘者に評判制約を課し、検索者から結果を盗んだ採掘者をホワイトリストから除外することで、採掘者が検索者からMEVの利益を盗むことを防ぐことができる。

しかし合併後は、ブロックを提案するプロポーザとして検証者からランダムに選ばれるため、提案者がMEVを盗むのを防ぐための評判制約はもはや実現不可能である。 

可能な解決策は、ブロックの内容を検証者から見えないようにすることである。この線に沿ってさらに改良されたものがPBS (Proposer Builder Seperatioin)である。これは提案者としての検証者の職務をブロック構築とブロック提案にさらに分解し、利害の争いに関与する可能性のある複雑な構築権を構築者にアウトソーシングするもので、この場合提案者の仕事は非常に単純になり、提案者にはブロックの内容だけが見えるようになる。提案者の仕事は非常にシンプルになり、建設業者に従ってブロックを提出し、ブロックを提案する利益の大きさを選択するだけでよい。 

当初、イーサネットはPBSをプロトコルに組み込みたいと考えていましたが、複雑さが予想されたため、そのプロセスは保留となり、MEV-BoostがPBSを導入する機会を得ました。現在、PBSはFlashbots社が開発した MEV-Boost を通じて実装されている。ビルダーとプロポーザーのほかに、もうひとつ重要な役割がある--リレーだ。ビルダーはプロポーザーに直接ブロックを送るのではなく、第3の役割であるリレーを通してブロックを送る。https://img.jinse.cn/7266310_image3.png" alt="">

ビルダーが常に提案者に報酬を支払うようにする方法や、提案者が空白のブロックを提出するのを防ぐために最後に必ず提案者にブロックの内容を開示する方法など、解決しなければならない問題が他にもたくさんあるからです。例えば、ビルダーが提出したブロックがビーコンチェーンに含まれるようにする方法などである。ビルダーとプロポーザの権利と利益を保護するこれらの問題は、主にリレーによって達成される。

ビルダーはブロックをリレーに送信し、リレーは各ブロックに応じてブロックの並べ替えの利益を得ることができ、その後、ブロックの内容に関する提案者が見えないことを確実にするために、ブロックの毛の最高利益を持つブロックが提案者に送信されます。提案者が（ブロックヘッダに署名することによって）ブロックの提供にコミットした後にのみ、リレーは提案者にブロックの全容を開示する。提案者への支払いは提出されたブロックに含まれますが、提案者はブロックの内容を見ることができないので、リレーはまだそれを事前に確認する必要があります。

MEV-Boostが構築されているマーケットプレイスに参加するためには、バリデータはEtherコンセンサスクライアントと実行クライアントと一緒に、サードパーティの非Ether MEV-Boostプログラムを実行する必要があります。これは、現在運用されているPBSのマジックであり、プロトコルの外部にいるサードパーティがEtherのコンセンサス形成のルール設計に参加することを可能にしている。所有権の観点からすると、これは驚くべきことです。

これはまた、プロトコルのメカニズムの「信頼性」、その信頼性がどのように強化されるか、そして他のメカニズムによってどのように侵食されうるかについて考えることにつながります。MEV-Boostはこの良い例であり、外部プロトコルが既存のメカニズムに変更を加えるような状況が起こりうるからである。 外部メカニズムの芽は、現在の市場ニーズに適合していなければならないが、外部メカニズムが信頼できるかどうか、潜在的な問題を防ぐために慎重に設計されているかどうか、さらには外部メカニズムがプロトコルを弱体化させる可能性があるかどうかまでは、まだわかっていない。

集中型リレー

MEV-Boostで最も批判されている点は、集中型リレー市場である。建設者はリレーが自分のMEVを盗まないことを信頼する必要があり、提案者もリレーから受け取って署名したブロックヘッドが有効であることを信頼しなければならない。しかし、その重要な役割にもかかわらず、リレーには金銭的なインセンティブがなく、運営には大きなコストがかかる。昨年、イーサネット・ネットワークをサポートしていたリレーは11台でしたが、現在では9台しかありません。

リレーがアクセスニュートラルではないことは注目に値します。 Edenのようなリレーは自身のビルダーのみをリレーし、bloXrouteのようなリレーはロボコールやサンドイッチ攻撃に関するトランザクションをフィルタリングすると主張しています。ある意味、リレーはルール作りの力も持っている。

評価済みネットワークからのデータ

また、ライブ性の観点から見ると、中継が存在するため、建設者と提案者は、アトミックなデータを提供することができません。と提案者はアトミックレベルの確認を提供できない。提案者がブロックヘッダへのコミットメントに署名し、構築者がペイロードコンテンツを提供しても、リレーが（悪意があろうとなかろうと）ミスによって時間内にコンテンツをコミットできなかった場合、構築者と提案者の両方が損失を被ることになります。

ePBS: EtherでPBSをカプセル化する 

リレーの中心性の問題を解決するためであれ、プロトコルのプロトコル外の部分をプロトコルの中に移動させるためであれ、EtherのePBSでPBSをカプセル化することは必須であるように思われました。

ePBSは、提案者と構築者がブロックを構築する権利をアウトソースするための、信頼性のないインフラストラクチャを提供します。プロトコルの外部にあったビルダーの役割はプロトコルに組み込まれました。つまり、検証者から追加のビルダーの役割が分割され、検証者であるビルダーもイーサでの誓約を完了する必要があります。コンセンサスレイヤーにおける元々の提案者の役割が分割されたため、ePBSを完了させるためにはコンセンサスレイヤーの変更が必要となる。この場合、ビルダーは実行ペイロード（ブロック内で実行されるトランザクションの最終リスト）を構築する責任を負う。

1. プロポーザとして選ばれたことを知った後、インクルードリスト（IL、そのスロットに含まれなければならないトランザクション）を作成し、ブロードキャストする。

2. ビルダーはプロポーザに、実行ペイロードを含むブロックのハッシュと、実行ペイロードに対してプロポーザに料金を支払うことを約束する「SignedExecutionPayloadHeader」を送る（実行ペイロードはILを満たす必要がある）

3. 。ペイロードはILを満たす必要がある）

4. 提案者は、ビルダーから送信された"SignedExecutionPayloadHeader"の中から1つを選んで組み入れる（通常は提案者に最も高い料金を支払うもの）。そして提案されたビーコンブロック「SignedBeaconBlock」をブロードキャストする。

5. 立会人は立会いの義務を果たす

6. アグレゲータは認証アグリゲートを提出する。一方、ビルダーは実行ペイロードをブロードキャストする

7. PTC(li>

8. PTC（ペイロード適時性委員会、各スロットで512人のバリデータが選出される）は、ビルダーが期限内にペイロードを公開したかどうかをチェックし、その結果を放送する

ePBSの提案からEIP番号の取得までに多くの議論があった。その間に多くの議論がありました。当初、PBSは6月21日にVitalik によって提案され、4ヶ月後に2スロットPBSが完成し、さらに3ヶ月後に1スロットPBSが導入され、PTCのアイデアが正式に提案されたのは7月23日でした。

PEPC (Protocol-Enforced Proposer Commitments)

もちろん、ePBSに同意せず、別のスキームで置き換えたいという人もいます。ePBSは定義されたルールをプロトコルに埋め込むことですが、PEPCの場合、提案者はプログラム可能なブロックを構築する権利を売っているのです。 

PEPCは2022年10月にbarnabe氏によって提案されました。barnabe氏は、PBSメカニズムをプロトコル内に実装するのであれば、特定のトラステッド・シグナル（例えば、ブロックを構築させてくれたらxx ETHをお返しします）のメカニズムとしてではなく、トラステッド・シグナルの汎用メカニズムとして考えるべきだと主張しました。 

PEPC（Protocol-Enforced Proposer Commitments）という名前が示すように、構築者と提案者の権利と利益を保証するためのメカニズムの一部は、提案者がプロトコル内で提出するコミットメントによって達成され、オンチェーンで検証することができます。これらのコミットメントは、主にオペコード "BEACONROOT "によってチェーン上で検証される。これはより一般的なメカニズムであり、これによりコミットメントは、ブロック構築権のすべてをアウトソースすることも、ブロックの一部だけをアウトソースすることもできます。

概要 

以上、PBS、ePBS、PEPCについて簡単に紹介しました。プロトコル設計の観点からは、MEVを再分配する市場メカニズムを設計する必要があるだけでなく、検証者をどのように分散化するか、検閲耐性をどのように向上させるかも考慮する必要があります。さらに、プロトコルの設計には多くのトレードオフがある。例えば、すでにEIP番号を取得しているePBSを例にとると、ePBSの設計は中央集権的な中継の問題を解決しているとはいえ、中継というプロトコル外の第三者としての重要な役割は、本当にマイナスの影響しかないのだろうか。ePBSはプリペイドメカニズムであり、ビルダーが超高収益ブロックをパッケージ化した場合、プリペイドメカニズムでは提案者に高いリターンを提供できないため、ビルダーの支払いメカニズムという観点からは、ePBSメカニズムよりもリレーを使用する方が望ましい。