ブロックチェーンの世界では、私たちはよく「検閲耐性」という言葉を耳にします。
多くの人々の第一の反応は、これが政治的であり、あるいは某种の無政府主義的なスローガンのように聞こえるかもしれないが、グローバルなユーザーに開放されたイーサリアムという決済ネットワークにとって、検閲耐性はまず政治的立場ではなく、非常に具体的な技術的能力である。
imTokenウォレットで取引を開始したことを想像してみてください。
署名は正しい、アカウント残高は十分であり、ガス料金も低くないが、トランザクションがブロックに記録されず、ウォレットの状態は常に「保留中」のままです。一方で、より低い料金または同程度の料金の他のトランザクションは次々とチェーンに記録されています。
このとき、問題は一体誰が取引がブロックに含まれるかどうかを決定する権限を持つのかという点に変わる。結局のところ、イーサリアムが依然として特定の数人の中央集権的な参加者がどの取引をチェーンに含めるかを決定する必要があるならば、それは従来の金融システムと本質的な違いがなくなる。
そのため、イーサリアムは近年、FOCIL、FairFIL などの一連の検閲耐性メカニズムを探索しており、これは一見単純だが実際には非常に重要な問いに答えようとしています：プロトコルルールに準拠したすべてのトランザクションが、公平にブロックに取り込まれる機会をどのように保証するか？
一、「監査」はいったいどこから来たのか？
イーサリアムがこれらのメカニズムを必要とする理由を理解するには、まず取引がウォレットから送信された後、どのようなプロセスを経るのかを理解する必要があります。
ユーザーがウォレットで署名し、トランザクションを送信すると、そのトランザクションは通常、イーサリアムのパブリックトランザクションプール、すなわちメムプール（Mempool）にまず入ります。これは、ブロックに書き込まれるのを待っている多数のトランザクションが保管される待機エリアのようなものです。
ただし、待機エリアに入ることをもって取引がブロックチェーンに記録されたわけではなく、誰かが取引を選択し、その順序を決定して完全なブロックを構成し、ネットワークに確認を依頼する必要があります。
問題はまさにこの段階で発生します。
イーサリアムがPoS（ステーク証明）メカニズムにアップグレードされた後、大規模なステーキングプールがMEV（最大抽出可能価値）を悪用して経済的独占を形成するのを防ぐため、イーサリアムはPBS（Proposer-Builder Separation、提案者とビルダーの分離）アーキテクチャを導入しました。このアーキテクチャでは、イーサリアムの各トランザクションの処理プロセスが、2つの役割に分割されます：
- ビルダー（Builder）：取引を収集し、取引の順序を決定し、アービトラージや清算の機会を探して、利益を最大化するブロックを構築する役割を担う；
- プロポーザー：ビルダーが提出した候補ブロックから1つを選択し、ネットワークに提出する役割を担う；
この分担には現実的な利点があります。
近年、MEV戦略はますます複雑化しており、すべての一般バリデーターに取引の並べ替えとブロックの最適化を個別に実行させると、資金・データ・技術力がより豊富な大規模ノードが優位性を獲得することになる。
したがって、複雑なブロック構築作業を専門のビルダーに任せることで、高度なアービトラージ能力を持たない通常の検証ノードでもブロック提案に参加し、それに見合った収益を得ることができ、MEVがステーキングの分散化に与える影響を軽減できます。
しかし、それは意図せずして別の副作用ももたらしました。それは、ブロック構築権の過度な集中です。たとえば、現在、ネットワーク全体の90％以上のイーサリアムブロックは、わずか数社の専門的なビルダーによってのみ生成されており、これらのビルダーは通常明確な実体ビジネス背景を持っているため、特定の国や地域の法的規制（たとえばOFAC制裁リスト）による外部的な圧力を受けやすくなっています。そのため、実質的に中心化のリスクを構成しています。
そのため、これらの主要なBuilderが特定のセンシティブな契約（例：Tornado Cash）や特定のアドレスの取引を選択的にフィルタリングすると、これらの取引は長時間ブロックされず、場合によっては「隠蔽されたブロック」のリスクにさらされます。
要するに、一般ユーザーにとっては、イーサリアムは誰でも接続し、送金し、スマートコントラクトを呼び出せるオープンなネットワークですが、プロトコルの動作の観点から見れば、トランザクションを送信することは最初のステップに過ぎず、そのトランザクションが実際に有効になるかどうかは、特定のブロックビルダーに選ばれ、並べ替えられ、ブロックに記録されるかどうかにかかっています。
したがって、イーサリアムで議論される「検閲耐性」は、政治や規制、制裁に関連する壮大な概念にとどまらず、まず非常に具体的な技術的問題である：
取引がプロトコルのルールを満たした場合、ネットワークはその取引が合理的な時間内にブロックに追加される機会を保証できますか？
二、FOCILからFairFILへ：イーサリアムはどのようにブロックビルダーを制限するか
ここで話が進んだ時点で、問題は明確です。Builderはブロック構築の効率を向上させることができますが、取引含意権が長期的に少数のBuilderに集中し続けると、イーサリアムは新たな中心化独占のリスクに直面します。
これにより、イーサリアム研究者はインクルージョンリスト、通称「包含リスト」を提案しました。
この名前はやや抽象的に聞こえるかもしれませんが、その核心的なロジックは複雑ではありません。Builderは依然としてブロックの作成を担当しますが、すべての取引の可否を独断で決定することはできません。通常のイーサリアムステーキングに参加するバリデーターノードにも、処理を必須とする取引をリストアップするための一部の権限を残す必要があります。
バス停を例に取ると、ブロックは座席に限りのある1便と理解できます。
Builderは、大部分の乗客がどのように並び、どの席に座るかを決定することで、より効率的な配置により列車全体の収益を向上させる；しかし、検証ノードは「必ず乗車させるリスト」を提出することもでき、リスト内の取引が有効であり、適切な手数料を支払う意思があり、ブロックに十分な空きがある限り、Builderは自身の好みだけでそれらを拒否することはできない。
しかし、リストを作成するのは誰なのか、そして誰かが意図的に取引を省略した場合どうするべきかという2つの課題は、引き続き解決が必要です。
FOCILとFairFILは、まさにこの二つの方向性に沿って展開されています。
1. FOCIL：プロポーザーが単独でコンテントリストを生成しないように
FOCIL（Fork-Choice Enforced Inclusion Lists）は、取引の必須包含を決定する権限を、単一のプロポーザーから複数の参加者からなる「バリデーターコミッティ」に移譲します。
各ブロック生成周期ごとに、ネットワークはランダムに一組のバリデーターノードを選出し、一時的な委員会を構成します。委員会の各メンバーは、ネットワークのメモリープールを独立して監視し、それぞれローカルの含むリストを提出します。
これは、ネットワーク全体の99%のビルダーとプロポーザーが特定のトランザクションを検閲しようとしても、委員会内に1人の誠実なノードがそのトランザクションをリストに追加すれば、そのトランザクションはプロトコルの制約に組み込まれる可能性があることを意味します。検閲者がそのトランザクションを排除し続けようとする場合、もはや1人だけを回避するのではなく、複数の独立した参加者を同時に回避しなければならなくなります。
そのため、委員会の全員が中立であることを信じる必要はありません。
しかし、リストだけでは不十分です。ビルダーがリストを受け取った後も実行を選択しない場合、リストは拘束力のない提案に過ぎなくなります。
そのため、FOCILは第二層の設計を追加し、フォーク選択ルールを導入して厳格な制約を設け、ネットワーク全体の投票検証ノードがBuilderが提出したブロックを厳密にチェックするようにしました。Builderが委員会が統合した包括リストに反する行為をした場合、ネットワーク全体はそのブロックへの投票を直ちに拒否します。
これにより、違反したブロックはプロトコルによって即座に無効と判定され、ビルダーは大きなブロック生成失敗の代償を支払うことになります。
2. FairFIL：欠損を補うだけでなく、欠損を検証可能にすること
FOCILが合意ルールに基づいて検閲を厳格に禁止するのに対し、FairFIL（Fair Forward Inclusion Lists）と説明責任メカニズムは、経済的観点から検閲行為を極めて高額で持続不可能にします。
言い換えれば、それはより一歩進んだ要件を提起しており、たとえば、ある取引がブロックに含まれなかった理由について、公開して確認できる記録を可能な限り残すべきである。
実際のネットワーク運用において、Builder は取引の並び替えと MEV アービトラージを最適化するために極めて短いバッファ期間を必要とする可能性があります。FairFIL は、特定の制約のもとで Builder が柔軟性を調整することを許可しますが、Builder が某种の検閲行為を次のブロックに継続しようとした場合、プロトコルは直ちにアカウンタビリティプロセスを起動します。
その大まかなロジックは、3つのステップで理解できます。
- まず、プロトコルは、公開され、検証可能な基準ルールを設定し、公共トランザクションプール内のどのトランザクションが通常条件下で現在のブロックに含める資格があるかを判断します。基準ルールに基づけばブロックに含める資格があるにもかかわらず、最終的に処理されなかったトランザクションについては、BuilderはそれらをFairFILに公開してリストアップする必要があります。
- その後、バリデータはこのリストが完全であるかを確認します。ビルダーが条件に合致する取引を漏らしていたにもかかわらず、それをリストに含めなかった場合、その行為は発見され、バリデータがそのブロックを支持するかどうかに影響を与える可能性があります。
- 最後に、FairFILの有効な取引は、後続のブロックで優先的に処理されるタスクとなり、次のBuilderはそれらをブロック内の具体的な位置に配置することはできるが、無視したふりを続けることはできない；
取引が連続して見過ごされた場合、関連するブロックはバリデーターのサポートを失う可能性があり、ビルダーはそのブロック全体の収益を損失する可能性があります。
言い換えれば、FairFILが強調する「説明責任」は、段階的な経済的罰則を導入することで、取引のBuilderが継続的に監査され、ブロック全体の報酬を剥奪されたり、ステーキングデポジットが没収されるリスクに直面することを意味します。
これはイーサリアムの検閲耐性メカニズムが徐々に深まる方向であり、少数の参加者が検閲を意図しても、取引の入口を長期的に制御することは困難になるように、より現実的な制約を構築することを目的としています。たとえ誰かが意図的に取引を省略したとしても、その痕跡は残り、継続的な検閲にはますます高い代償が求められます。
三、これは一般ユーザーにとって何を意味しますか？
毎日ウォレット送金、交換、またはDeFiを利用する一般ユーザーにとって、これらの基盤メカニズムは、将来的に実装されても、現在の操作習慣を変更する必要はありません。
ユーザーは依然としてウォレットで金額を入力し、ガスを確認して署名を完了した後、トランザクションがブロックチェーンに記録されるのを待つが、見えないプロトコルの下層では、トランザクションがブロックに含まれるかどうかのロジックに重要な変化が生じる可能性がある。
実際に改善されたのは、取引の包含プロセスの確定性です。
- まず、ルールに準拠した取引は、特定のビルダーの選択に完全に依存しなくなります。たとえ現在のビルダーが処理を拒否しても、他の検証者は含めるリストを通じて、プロトコルレベルでの含める要件を設定できます。
- 次に、取引の優先権と取引の並び替え権は徐々に分離される可能性があります。ビルダーは依然として専門的なアルゴリズムを用いて取引の順序を決定し、ブロック収益を向上させることができ、アービトラージや清算を巡って競争し続けることができますが、「誰が市場に参入する資格を持つのか」を決定する権限は制限されます。
さらに踏み込むと、イーサリアムの信頼できる中立性は、参加者の約束に依存する価値主張から、クライアントによって自動的に実行されるプロトコルルールへと徐々に変化する可能性がある。
ユーザーは現在のブロックがどのビルダーによって構築されたかを知る必要はなく、これらのビルダーが積極的に中立性を維持すると逐一信頼する必要もありません。検証ノードは同じルールに従ってブロックをチェックし、包含義務に違反したブロックがネットワークから承認されにくくします。
今後、ウォレットやブロックブラウザーは、これに基づいてより詳細なトランザクション状態を提供する可能性があります。
一笔取引は、単に「処理中」と表示されるだけでなく、その取引が含めるリストに追加されたかどうか、後続のブロックに含める義務が発生したかどうか、そして引き続き待機している理由がガス不足であるか、取引が無効になったか、ブロック構築プロセスに異常が発生したかをユーザーに詳細に通知する可能性があります。
ただし、検閲耐性メカニズムは、すべての取引が即座に成功することを意味するわけではありません。
残高不足、Nonceの衝突、ガス料金が低すぎる、またはスマートコントラクトの実行条件が無効となった取引は、依然としてブロックに含まれない可能性があります。ネットワークが混雑し、ブロックの空き容量が不足している場合、ユーザーは依然として手数料の競争を通じて確認を待つ必要があります。
しかし、これは本来有効で手数料が適正であり、既にパブリックトランザクションプールに広がったトランザクションを主に改善するものであり、少数のブロック構築者の主観的な選択によって無期限に遅延されるべきではありません。
進捗状況によると、2026年8月現在、FOCILに対応するEIP-7805はDraft状態ですが、イーサリアムコア開発者によってHegotáアップグレードのコンセンサス層ヘッドライナーに選ばれ、Scheduled for Inclusion段階に入っています。これはクライアントチームがその実装とネットワークテストの推進に合意したことを意味しますが、メインネットへの正式なリリース日はまだ確定していません。
FairFILはより早期の段階にあり、現在は2026年7月に公開される予定の研究案として主に扱われており、今後イーサリアムのロードマップに組み込まれるかどうかは、さらに広範な議論、実装、およびセキュリティ検証を経て決定されます。
最後に
客観的に言えば、イーサリアムはあらゆるビルダー、バリデーター、インフラ運用者を永遠に中立に保つことを保証することはできません。
参加者は規制の圧力を受けたり、自らの利益を追求したり、外部のインセンティブを受け入れたりする可能性がある。真にレジリエントな分散型ネットワークは、「すべての人が正しい行動を取る」という理想化された仮定に基づいて構築されてはならない。
真の検閲耐性とは、一部の参加者が取引を妨害しようとしても、他の参加者がその制御を破ることができるということであり、誰かが中立性の原則から逸脱しようとしても、プロトコルがその行為を可視化し、高コストで持続不可能にすることである。
最初の含むリストから、分散型委員会がビルダーを共同で制約するFOCILへ、そして漏れ行為が公開的に検証可能であることを要求するFairFILへ。誰でも取引を送信できることから、誰の取引も見られる機会が保証されるように。
この観点から見ると、イーサリアムは確かに、この約束を価値の宣言から、段階的にプロトコルそのものに書き込もうとしています。
楽しみにしています。