イーサの検閲抵抗への道：BRAIDとFOCIL、どちらが優れているか？

著者：0xNatalie

イーサリアムのブロック生成・検証プロセスでは、ビルダーがトランザクションプールからトランザクションを選択・選別し、オークションメカニズムを通じて提案者にブロックを提出する役割を担っている。提案者は、提出された取引からブロックを選択し、署名してブロックチェーンに提案する。提案者は単一のエンティティとして最終的な選択を行うため、提案者と構築者が結託してトランザクションを検閲する危険性がある。

ブロックチェーンの中核的価値の1つは、検閲に強いこと、つまり中央当局の干渉を受けずに誰でも取引ができることです。提案者がどの取引をブロックに含めるかをコントロールできるようになると、この特徴が脅かされる。公平性と透明性が損なわれる。そしてこの権力は、さらなる金銭的利益を得るためにブロック内の取引の順序を操作するために使われる可能性があり、MEV問題を提起する。

既存の反検閲ソリューション

この課題に対処するため、コミュニティは強制包含リスト（FOCIL）など、さまざまな反検閲ソリューションを考え出しました。FOCILメカニズムでは、各スロットで検証者のグループが無作為に選ばれ、インクルージョン・リスト委員会を形成する。これらの委員会メンバーは、トランザクションプール（mempool）に対するそれぞれの主観的見解に基づいてローカル・インクルージョン・リストを作成し、それをブロードキャストする。プロポーザはその後、これらのローカルリストを集めて集約し、集約リストを形成してブロックに含める責任を負う。このメカニズムによってブロックの公平性が保証されます。バリデータは、事前にブロードキャストされたローカルリストに基づいて集約されたリストの正しさを検証し、コンセンサスルールに準拠したブロックのみが受け入れられ、ブロックチェーンに追加されます。

FOCILに加えて、コミュニティは複数同時提案者（MCP）オプションについても議論してきました。このコンセプトは Max Resnick によって Multiplicity メカニズムで最初に提案されたもので、権力を分散するために複数の並列ブロック提案者を導入することで、1つのノードが取引を精査する能力を減らすように設計されています。Multiplicityメカニズムでは、各バリデータが自身のトランザクションプールからトランザクションの一部を選択し、「トランザクションの特別パッケージ」を構成する。これらのバリデータは選択したパッケージに署名し、現在のラウンドの提案者に送信する。受け取った提案者は、提案したブロックにこれらのパケットの少なくとも2/3を含める必要がある。そうして初めて、そのブロックは有効とみなされる。このメカニズムにより、提案者はブロックの内容を単独で決定できないため、検閲の可能性を減らすことができる。提案者が公平にトランザクションを含めるようさらに動機付けるために、このメカニズムでは「条件付きチップ」ルールを実装しており、トランザクションを含めた提案者のみがトランザクションのチップの分け前を受け取れるようになっている。最初に取引を含めた提案者に自動的に取引全体のチップを渡す代わりに、一定の条件に基づいて実際に取引を含めた提案者全員に取引のチップを分配する。このため、審査にかかるコストが増大し、審査をしたければ、取引を含んだ提案者全員に賄賂を渡す必要がある。

BRAID：改良されたMCPの実装

Multiplicityをベースに、Max ResnickはさらにBRAIDを提案しました。MCPの実装です。BRAIDは、複数の提案者が異なる並列チェーン上でブロックを提案することを可能にし、チェーン間の一貫性を維持するために同期コンセンサスを使用することで、MCPを実装している。各チェーンはそれぞれの提案者を持ち、すべての提案者が同じスロット内で同時にブロックを公開する。イーサネットの実行レイヤーは、そのスロット内のすべてのサブチェーンによって生成されたブロックトランザクションを実行ブロックに集約し、事前に定義されたルールに従って、それらのトランザクションの重み付けを解除し、ソートし、実行する。

BRAIDの設計は追加の役割を導入しないため、インセンティブ/ディスインセンティブメカニズムの複雑さを回避できるが、その実装は比較的複雑で、複数のサブチェーンにわたる同期とデータ処理の調整が必要となる。

BRAIDメカニズムの問題点

ブロックチェーン・キャピタルのチーム Jonahb は、BRAIDメカニズムの問題点を指摘しました。条件付きチップ」モデルには、ユーザー・エクスペリエンスに影響を与える流動性要件があります。このモデルは動的な価格戦略であり、トランザクションが検閲に強いことを保証するために、ユーザーに一定量の流動性を確保することを要求する。ユーザーはトランザクションを送信する際に 2 つのチップ値（T と t）を設定する必要がある。最終的に支払われる実際のチップは、取引を含む提案者の数に依存する。

1. Higher tip T: 取引が検閲されないことを保証するために、ユーザーが支払っても構わない最高額を表します。その目的は、他の提案者がその取引を含めることを望んでいない場合、提案者にその取引を含めることを選択するインセンティブを与えることである。

2. Lower Tip T: これはユーザーによって設定される低い金額であり、同時に複数の提案者によって取引が含まれる限り、ユーザーはtを支払うだけである。の間で分割される。もしユーザが検閲を気にしないのであれば、T=tを設定し、1人の提案者のみに取引を送ることができる。

しかし、この追加流動性要件はブロックチェーン取引に参加する複雑さとコストを増加させ、ユーザーは検閲耐性を保つためだけに、取引の瞬間に余分な金額を確保しておく必要がある。これらの予約資金は、実際に使用されるまで凍結される。

これに対し、Jonahb氏は2つの解決策を提案しました：

• 国家後の流動性を証明する。証明）：ユーザーがトランザクションを送信する際、トランザクションが実行された後にTを支払うのに十分な流動性があるという証明を提供する（例えば、ユーザーはトランザクション後に$1Mの流動性を持つ）。こうすることで、取引前にTの支払いに十分な資金がなかったとしても、ユーザーは証明を通じて取引後にTの支払いができるようになる。このアプローチの課題は、提案者はトランザクションが実行される前にその最終的な状態を知らなければならな いが、ほとんどの金融トランザクションには共有状態（例えば、同じ口座残高を共有する複数のトランザクショ ン）が含まれるため、提案者はトランザクションの順序が決定されるまで、トランザクション後の状態を正確に判断で きないことである。これはトランザクションの種類ごとにカスタマイズされた証明を必要とし、実用的ではない。

• 検閲保険: 第三者の検閲保険プロバイダー（CIプロバイダー）を導入し、ユーザーのTを保証する。ユーザーはrTの保険料を支払うが、rはトランザクションがレビューされる可能性に基づいて計算される。この解決策は、利用者がすぐに利用可能な大量の流動性を持つ必要性を減らすだけでなく、Tが低すぎ、見直しのリスクが高いことをCIを通じて利用者に警告する。しかし、ユーザーとCIプロバイダーの間にマーケットプレイスを確立するには時間がかかる。

FOCIL vs. BRAIDに関するコミュニティーの意見

イーサリアムクライアントのPrysm開発者 は次のように考えています。terence は、BRAIDの大きな利点の1つは、追加の参加者を必要としないことだと考えています。FOCILを含むほとんどのインクルード・リスト（IL）設計では、追加の参加者が必要であり、ILを提出する時間、入札を更新する時間、バリデータがILをチェックする時間など、イーサネットのタイムスロットに時間的制約が加わる。しかし、FOCILスキームはBRAIDよりも実装がシンプルで柔軟性が高い。

パラダイム研究者のダン・ロビンソン（Dan Robinson）氏は、MEVを効果的に緩和するために、リーダー（単一の提案者）の裁量に任せるのではなく、トランザクションに優先順位をつけるBRAIDの設計を高く評価しています。のティッピング・メカニズムは、FOCILには反映されていない非検閲行動を奨励する。

開発者の Dev は、MCP よりもFOCIL を好んでおり、FOCILには強い抵抗力を提供し、実装を単純化するという利点があると考えています。彼はFOCILを実装しやすくするためのいくつかの改善点を提示しています。

Etherフェローの& barnabe.eth は、FOCILはかなり汎用的でスケーラブルなメカニズムだと考えており、BRAIDにはFOCILが提供する保証を改善する可能性があることを認めていますが、リーダーベースのモデルを完全に放棄することには慎重です。リーダー・ベース・モデルは慎重であり、現在のところコンセンサスには至っておらず、その実行可能性を実証するにはさらなる研究が必要であると主張している。