イーサリアムの検閲耐性への道：BRAIDとFOCIL、どちらが優れているか？
TechFlow厳選深潮セレクト
イーサリアムの検閲耐性への道：BRAIDとFOCIL、どちらが優れているか？
BRAIDは改良型のマルチコンカレントプロポーザ（MCP）方式である。FOCILは改良型のインクルージョンリスト（IL）方式である。
Web3業界の深掘り報道に専念し潮流を洞察執筆：0XNATALIE
イーサリアムのブロック生成および検証プロセスにおいて、ブロッカー（Builder）はトランザクションの順序付けを担当し、オークションメカニズムを通じてブロックをプロポーザー（Proposer）に提出します。一方、プロポーザーはその中から一つのブロックを選択し、署名してブロックチェーン上に提案します。プロポーザーが単一の実体として最終的な選択権を持つため、プロポーザーとブロッカーが結託してトランザクションを検閲するリスクが生じます。
ブロックチェーンの核心的価値の一つは、中央集権的な権威による干渉を受けずに誰もが取引できる「検閲耐性」です。しかし、プロポーザーがどのトランザクションをブロックに含めるかを制御できる場合、この特性は脅威にさらされ、公平性と透明性が損なわれます。さらに、彼らはこの権力を悪用してブロック内のトランザクション順序を操作し、追加的な経済的利益を得ることが可能となり、MEV（最大抽出可能な価値）の問題を引き起こします。
既存の検閲耐性ソリューション
この課題に対処するため、コミュニティは強制包含リスト（FOCIL）などの検閲耐性ソリューションを提案しています。FOCIL メカニズムでは、各スロット（時間枠）ごとにランダムに選ばれたバリデータのグループが「包含リスト委員会」を構成します。これらの委員会メンバーは、それぞれが持つトランザクションプール（mempool）に対する主観的なビューに基づき、ローカルな包含リストを作成し、それをブロードキャストします。プロポーザーはこれらのローカルリストを集約し、統合されたリストをブロックに含めます。この仕組みにより、バリデータは事前にブロードキャストされたローカルリストを基に、統合リストの正当性を検証でき、合意ルールに従ったブロックのみが受け入れられてブロックチェーンに追加されます。これによってブロックの公正性が保証されます。
FOCIL 以外にも、複数同時プロポーザー（MCP）のアプローチが議論されています。この概念は当初、Max Resnick が Multiplicity メカニズムの中で提唱したもので、複数の並列ブロックプロポーザーを導入することで権力を分散させ、単一ノードによるトランザクション検閲能力を低下させることを目指しています。Multiplicity メカニズムでは、各バリデータが自身のトランザクションプールから一部のトランザクションを選んで「特別トランザクションパケット」を構成し、署名して当該ラウンドのプロポーザーに送信します。プロポーザーは受信したパケットのうち少なくとも2/3を、自らが提案するブロックに含める必要があります。そうでなければ、そのブロックは有効とは見なされません。この仕組みにより、プロポーザーが単独でブロック内容を決定できなくなり、検閲の可能性が低減されます。さらに、プロポーザーが公正にトランザクションを含めるインセンティブを高めるために、「条件付き小費（conditional tip）」ルールが導入されています。つまり、あるトランザクションを実際に含めたプロポーザーだけが、その小費の一部を受け取れるのです。小費は自動的に最初に含めたプロポーザーに全額支払われるわけではなく、一定の条件に基づき、実際にそのトランザクションを含めたすべてのプロポーザー間で分配されます。これにより検閲コストが上昇し、検閲を行うにはすべての関与プロポーザーへの賄賂が必要になります。
BRAID：改善された MCP 実装方式
Multiplicity をベースに、Max Resnick はさらに進化した MCP 実装である BRAID を提案しました。Paradigm が主催した「DeFi in MEV Era」と題するシンポジウムにて、Max は BRAID について紹介しました。BRAID は、複数のプロポーザーが異なる並列チェーン上でブロックを提案することを許容し、同期型コンセンサス機構によりチェーン間の一貫性を維持することで MCP を実現します。各チェーンには独自のプロポーザーが存在し、すべてのプロポーザーが同一スロット内で同時にブロックを発行します。イーサリアムの実行レイヤーは、このスロット中にすべてのサブチェーンで生成されたブロックのトランザクションを統合し、一つの実行ブロックを形成します。その後、所定のルールに従って重複排除、並び替え、実行が行われ、これにより特定の単一実体がトランザクション記録を操作する能力が低減されます。
BRAID の設計は追加の役割を導入しないため、報酬／ペナルティメカニズムに起因する複雑性を回避できますが、その実装は比較的難しく、複数のサブチェーンの同期とデータ処理の調整が必要です。
BRAID メカニズムの課題
Blockchain Capital の Jonahb は、BRAID メカニズムにおける「条件付き小費」モデルが流動性を要求する点に着目し、それがユーザーエクスペリエンスに悪影響を及ぼすと指摘しています。このモデルは動的価格設定戦略であり、ユーザーはトランザクションの検閲耐性を確保するために、一定量の流動性を事前に準備する必要があります。ユーザーはトランザクションを提出する際、二つの小費額（T と t）を設定します。実際に支払う小費の額は、そのトランザクションを含んだプロポーザーの数に依存します。
-
高い小費 T：ユーザーが検閲を防ぐために支払える最高額を示します。他のプロポーザーがそのトランザクションを含まない場合でも、プロポーザーがそれを含むよう誘導することを目的としています。実際に一つのプロポーザーしか含まなかった場合、そのプロポーザーは T を受け取ります。
-
低い小費 t：ユーザーが設定する较低な金額で、複数のプロポーザーが同時にそのトランザクションを含んだ場合に適用されます。t は複数のプロポーザー間で分配されます。ユーザーが検閲耐性を気にしない場合は、T=t と設定し、トランザクションを単一のプロポーザーにのみ送信できます。
しかし、このような追加の流動性要件は、ブロックチェーン取引への参加に伴う複雑さとコストを増大させます。ユーザーは検閲耐性を保証するために、取引時に余分な資金を予備として保持する必要があり、それらの資金は実際に使用されるまで凍結状態となります。
これに対して、Jonahb は以下の二つの解決策を提示しています：
-
Post-State Liquidity Proof（後状態流動性証明）：ユーザーはトランザクション提出時に、取引実行後に T の支払いに十分な流動性を保有していることを証明します（例：取引後、ユーザーは $1M の流動性を持つことになる）。この方法により、取引前の時点では T を支払えるだけの資金がなくても、取引後の状態で支払い可能であることを証明できます。ただし、この方式の課題は、プロポーザーが取引実行前にその最終状態を把握する必要がある点にあります。しかし、ほとんどの金融取引は共有状態（例：複数の取引が同じ口座残高を共有）に関わるため、取引順序が確定する前には、プロポーザーは正確な後状態を判断できません。そのため、各取引タイプごとにカスタム証明を提供する必要があり、実用性は低いと考えられます。
-
検閲保険（Censorship Insurance）：第三者の検閲保険プロバイダー（CI プロバイダー）が、ユーザーの T 支払いを保証する仕組みです。ユーザーはその保証に対して rT の保険料を支払います。ここで r は、そのトランザクションが検閲される可能性に基づいて算出されます。この方式は、ユーザーが大量の流動性を即座に準備する必要を減らすだけでなく、CI プロバイダーがユーザーに「T が低すぎて検閲リスクが高い」と警告することも可能です。ただし、ユーザーと CI プロバイダー間の市場を構築するには時間がかかります。
コミュニティの FOCIL と BRAID に対する見解
イーサリアムクライアント Prysm の開発者 terence は、BRAID の顕著な利点として、追加の参加者を必要としない点を挙げています。FOCIL を含む多くの Inclusion List (IL) 設計では、追加の参加者が求められ、これによりイーサリアムのスロット内での時間制約（例：IL 提出時間、ビッド更新時間、バリデータによる IL 確認時間）が増大します。一方で、FOCIL 方式は BRAID よりも実装がシンプルで柔軟性が高いと評価しています。
Paradigm の研究員 Dan Robinson は、BRAID がトランザクションの優先順位付けをリーダー（単一プロポーザー）の裁量に任せず、MEV 問題の緩和に有効である点を称賛しています。また、BRAID の条件付き小費メカニズムが非検閲行動をインセンティブ化している点も高く評価しており、これは FOCIL にはない特徴だと指摘しています。
開発者の Dev は、MCP よりも FOCIL を好んでおり、FOCIL が強力な検閲耐性を提供しつつ実装を簡素化できる点に優位性があると述べています。また、FOCIL の実現を容易にするいくつかの改良案も提示しています。
イーサリアム研究員 barnabe.eth は、FOCIL が非常に汎用的で拡張性のあるメカニズムであると認識しています。彼は、BRAID が FOCIL が提供する保証を特定の面で改善する可能性はあるものの、リーダーモデル全体を放棄することについては慎重な姿勢を示しており、現時点ではそれがコミュニティの合意ではないとし、その実現可能性を証明するためにはさらなる研究が必要であると述べています。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@ChainFeedsxyz
