検閲耐性をプロトコルに組み込む：イーサリアムのトランザクションがオンチェーンになるかは誰が決めるのか？

執筆：imToken

ブロックチェーンの世界では、「検閲耐性」という言葉をよく耳にします。

多くの人が最初に聞くと、政治的な、あるいはある種の無政府主義的なスローガンに聞こえるかもしれません。しかし、イーサリアムのようにグローバルユーザーに開かれた決済ネットワークにとって、 検閲耐性はまず政治的立場ではなく、極めて具体的な技術的能力なのです。

想像してみてください。あなたがimTokenウォレットでトランザクションを開始したとします。

署名は正しく、アカウント残高も十分で、ガス代も決して低くないのに、トランザクションはなかなかブロックに取り込まれず、ウォレットの状態は「Pending」のまま。一方で、手数料が同程度かそれよりも低い他のトランザクションが次々とチェーンに取り込まれています。

このとき、問題は「いったい誰が、あるトランザクションをブロックに入れるかどうかを決める権限を持っているのか？」ということになります。何しろ、もしイーサリアムが最終的に、特定の中央集権的な参加者にどのトランザクションをチェーンに載せるかを委ねるのであれば、それは従来の金融システムと本質的に何ら変わらなくなってしまいます。

そのため、イーサリアムは近年、FOCILやFairFILといった一連の検閲耐性メカニズムを模索しています。それは、一見シンプルに思えるが実際には極めて重要な問いに答えようとするものです。すなわち、プロトコルのルールに適合するあらゆるトランザクションが、ブロックに入る公平な機会をどのように保証するか、という問題です。

一、「検閲」は一体どこから来るのか？

イーサリアムにこれらの仕組みが必要な理由を理解するには、まず、ウォレットから送信されたトランザクションが実際にどのようなプロセスを経るのかを把握する必要があります。

ユーザーがウォレットで署名しトランザクションを送信すると、そのトランザクションは通常、イーサリアムのパブリックトランザクションプール、すなわちメモリプール（Mempool）に入ります。ここはむしろ待機エリアのようなもので、まだブロックに書き込まれていない大量のトランザクションが保管されています。

しかし、待機エリアに入ったからといって、トランザクションがチェーンに取り込まれたわけではありません。誰かがトランザクションを選び、その順序を決め、完全なブロックを構成し、ネットワークに承認してもらう必要があるのです。

そして、問題はまさにこの段階で発生します。

イーサリアムがPoS（プルーフ・オブ・ステーク）にアップグレードした後、大規模なステーキングプールがMEV（最大抽出可能価値）を利用して経済的独占を形成するのを防ぐため、イーサリアムはPBS（Proposer-Builder Separation、提案者とビルダーの分離）という仕組みを導入しました。このアーキテクチャの下では、イーサリアム上の各トランザクションの処理プロセスは、実際には2つの役割に分割されています。

ビルダー（Builder）：トランザクションの収集、順序の決定、アービトラージや清算の機会の探索、そして可能な限り収益性の高いブロックの構築を担当します。
提案者（Proposer）：ビルダーから提出された候補ブロックの中から1つを選択し、ネットワークに提案する責任を負います。

この分業には非常に現実的なメリットがあります。

周知のとおり、近年MEV戦略はますます複雑化しています。もしすべての一般バリデータにトランザクションの並べ替えやブロックの最適化を独立して行わせると、資金、データ、技術力に優れた大規模ノードが有利になってしまうでしょう。

そこで、複雑なブロック構築作業を専門のビルダーに委ねることで、高度なアービトラージ能力を持たない一般のバリデーションノードでも、ブロック提案に参加し、それに応じた報酬を得ることが可能になります。これにより、MEVがステーキングの分散性に与える影響を緩和できます。

ただ、これが意図せずして別の副作用、すなわちブロック構築権の過度な集中をもたらしました。例えば、現在イーサリアムの全ブロックの90%以上は、ごく少数の専門ビルダーによって生産されています。そしてこれらのビルダーは通常、明確な法人としての背景を持っているため、特定の国や地域の法令遵守（例えばOFACの制裁リスト）といった外部からの圧力を非常に受けやすく、実際すでに中央集権的なリスクが生じています。

まさにこのため、これら少数の主要ビルダーが、特定のセンシティブなコントラクト（Tornado Cashなど）や特定アドレスのトランザクションを選択的にフィルタリングしてしまうと、それらのトランザクションは長時間ブロックに取り込まれず、さらには「見えない封殺」に遭うリスクに直面することになります。

つまり、一般ユーザーから見れば、イーサリアムは誰でも接続し、送金し、スマートコントラクトを呼び出せるオープンなネットワークです。しかし、プロトコルの動作から見ると、トランザクションを送信するのは第一歩に過ぎず、それが実際に有効になるかどうかは、いずれかのブロックビルダーに選択され、並べられ、ブロックに書き込まれるかどうかにかかっています。

したがって、イーサリアムで議論される「検閲耐性」は、単に政治や規制、制裁に関連する大きな概念ではなく、まずもって極めて具体的な技術的問題なのです。すなわち、

あるトランザクションがプロトコルのルールを満たしている場合、ネットワークはそのトランザクションが妥当な時間内にブロックに取り込まれる機会を保証できるのか、という問題です。

二、FOCILからFairFILへ：イーサリアムはいかにブロックビルダーを制限するか

ここまで来ると問題はかなりはっきりしています。ビルダーはブロック構築の効率を向上させられますが、トランザクションの取り込み権限が長期的に少数のビルダーに集中すれば、イーサリアムは再び新たな中央集権的な独占リスクを抱えることになります。

そのため、イーサリアムの研究者たちは Inclusion Lists（包含リスト）と呼ばれる仕組みを提唱しました。

この名称はやや抽象的ですが、その中核的なロジックはそれほど複雑ではありません。ビルダーは依然としてブロックの作成を担当しますが、すべてのトランザクションの取捨を単独で決定することはできません。イーサリアムのステーキングに通常どおり参加しているバリデーションノードも、必ず処理されるべきトランザクションのリストを作成できる一定の権限を保持する必要があるのです。

バス停を例に取ると、ブロックは座席数に限りがあるバスの便と考えることができます。

ビルダーは、ほとんどの乗客がどのように並び、どの座席に座るかを決めることで、より効率的な配置により便全体の収益を高めます。しかし、バリデーションノードも「必ず乗車させるべきリスト」を提出することができ、リストに載ったトランザクションが依然として有効で、妥当な手数料を支払う用意があり、ブロックに十分な空き容量がある限り、ビルダーは自らの好みだけでそれらをいつまでも締め出すことはできません。

ただし、包含リストをいったい誰が作成するのか、そして誰かが故意にトランザクションをリストから漏らした場合にどう対処すべきかという点は、依然として解決すべき2つの課題です。

FOCILとFairFILは、まさにこの2つの方向性に沿って発展したものです。

1. FOCIL：1つのProposerに単独で包含リストを作らせない

FOCIL（Fork-Choice Enforced Inclusion Lists）は、トランザクションを必ず含めるかどうかを決定する権限を、単一の提案者から複数の参加者で構成される「バリデータ委員会」に移します。

各ブロック生成サイクルにおいて、ネットワークはランダムにバリデータのグループを選出して臨時の委員会を編成し、委員の各メンバーはネットワークのメモリプールを独立して観察し、それぞれ自分自身の包含リストを提出します。

つまり、たとえネットワーク全体の99％のビルダーと提案者が特定のトランザクションを検閲しようとしても、委員会の中にそのトランザクションをリストに載せる誠実なノードが1つでも存在すれば、そのトランザクションにはプロトコルによる拘束を受けるチャンスが生まれます。検閲者がそのトランザクションを引き続き排除しようとすれば、もはや一人を黙らせるだけでは済まず、同時に複数の独立した参加者を迂回しなければならなくなります。

したがって、この仕組みの利点は、委員会の全員が中立であることを信頼する必要がない点にあります。

しかし、リストだけでは不十分です。ビルダーがリストを受け取った後も、それを実行しないと、包含リストは強制力のない単なる提案になってしまいます。

そこでFOCILは第二の層として、フォークチョイスルール（Fork-Choice Rule）を導入し、ハードな制約をかけました。ネットワーク全体で投票と検証を行うノードが、ビルダーから提出されたブロックを厳格にチェックし、ビルダーが委員会で統合された包含リストに違反した場合、ネットワーク全体がそのブロックへの投票を拒否します。

これは、ルールに違反したブロックは、プロトコルによって瞬時に無効と判定され、ビルダーはブロック生成の失敗という大きな代償を支払うことを意味します。

2. FairFIL：漏れを補うだけでなく、漏れが検証可能であることも求める

FOCILがコンセンサスルールによって検閲を強制的に禁止しようとするものであるとすれば、FairFIL（Fair Forward Inclusion Lists）と説明責任メカニズムは、経済学的な観点から、検閲行為を極めて高コストで持続不可能なものにします。

平たく言えば、FairFILはさらに踏み込んだ要求を行います。例えば、あるトランザクションがなぜブロックに入らなかったのか、可能な限り公開検証が可能な記録を残すべきだというものです。

実際のネットワーク運用において、ビルダーはトランザクションの並べ替えやMEVアービトラージを最適化するために、ごく短い猶予期間を必要とする場合があります。FairFILは、ビルダーが特定の制約下で柔軟に調整することを許可します。しかし、もしビルダーが何らかの検閲行為を次のブロックにまで持ち越そうとすれば、プロトコルは直ちに説明責任の手続きを開始します。

そのおおまかなロジックは、3つのステップに分けて理解できます。

まず、プロトコルは、公開され検証可能な参照ルールを定め、公共トランザクションプール内のどのトランザクションが、通常の状況で現在のブロックに含まれる資格を有するかを判断します。この参照ルールに従い本来ブロックに入る資格のあるトランザクションのうち、最終的に処理されなかったものがある場合、Builder はそれらを公開し FairFIL に含めなければなりません；
続いて、バリデーターはこのリストが完全かどうかを確認し、もし Builder が条件を満たすトランザクションを明らかに見落としながらリストに記載しなかった場合、その行為は検出される可能性があり、バリデーションノードが当該ブロックを支持するかどうかに影響を及ぼします；
最後に、FairFIL に入った有効なトランザクションは、後続のブロックで優先的に処理すべきタスクとなり、次の Builder はそれらをブロック内の具体的な位置に配置することはできても、引き続き見て見ぬふりをすることはできません；

もしある取引が連続して見落とされると、該当するブロックはバリデーターの支持を失い、ビルダーもブロック全体の収益を失う可能性がある。

つまり、FairFIL が強調する「説明責任」とは、段階的な経済ペナルティを導入することで、取引を継続的に検閲するビルダーが、ブロック報酬の剥奪や、さらにはステーキング保証金の没収というリスクに直面するという仕組みである。

これはイーサリアムの検閲耐性の仕組みが一歩ずつ深まっている方向性であり、ごく一部の参加者に検閲の意図があっても長期間にわたって取引の入り口を支配することが難しくなり、誰かが故意に取引を除外しても痕跡が残り、継続的な検閲にはますます高い代償を払わざるを得なくなる、という、より現実的な制約を築くことを目指している。

三、これは一般ユーザーにとって何を意味するのか？

日々ウォレットを通じて送金や交換、DeFi を利用している一般ユーザーにとって、こうしたプロトコル基盤の仕組みが将来実装されても、これまでの操作の習慣を変える必要はない。

ユーザーはこれまでどおり、ウォレットに金額を入力し、Gas を確認して署名を済ませ、取引がチェーンに取り込まれるのを待つ。しかし、目に見えないプロトコルのレイヤーでは、取引がブロックに含まれるかどうかのロジックに重要な変化が生じる可能性がある。

この仕組みが本当に改善するのは、取引がブロックに含まれるプロセスにおける確実性である。

第一に、ルールに適合した取引は、もはや特定のビルダーの選択に完全に依存しなくなる： たとえ現在のビルダーが処理を望まなくても、他のバリデーターが包含リストを通じて、その取引に対してプロトコルレベルでの包含義務を課すことができる；
第二に、取引の包含権と取引の順序付け権が徐々に分離される可能性がある： ビルダーは引き続き専門的なアルゴリズムによって取引の順序を調整してブロック収益を高めたり、アービトラージや清算をめぐって競争したりできるが、「誰が市場に参加する資格を持つか」を決定する権限は制限される；

さらに言えば、イーサリアムの信頼できる中立性も、参加者のコミットメントに依存する価値の表明から、クライアントが自動的に執行するプロトコルルールへと徐々に変わっていくかもしれない。

ユーザーは現在のブロックがどのビルダーによって構築されたかを知る必要もなければ、それらのビルダーが自発的に中立を保つと個別に信頼する必要もなく、バリデーターは同じルールに従ってブロックを検証し、包含義務に違反したブロックがネットワークの承認を得るのを難しくする。

将来的には、ウォレットやブロックエクスプローラーが、こうした仕組みをもとに、さらに詳細な取引ステータスを提供する可能性もある。

取引は単に「保留中」と大まかに表示されるだけでなく、すでに包含リストに入っているのか、将来のブロックで包含義務の対象となっているのか、待ち続けている原因が Gas 不足なのか、取引がすでに無効になっているのか、それともブロック構築段階で異常が生じているのか、といった情報をユーザーに伝えられるようになるかもしれない。

もっとも、検閲耐性の仕組みは、すべての取引が直ちに成功することを意味するわけではない。

残高不足や Nonce の衝突、Gas が低すぎる場合、あるいはコントラクトの実行条件がすでに失効している取引は、依然としてブロックに取り込まれない可能性がある。ネットワークが混雑していたりブロックの空き容量が不足している場合も、ユーザーは手数料の競争によって確認を待つ必要がある。

しかし、この仕組みが主に改善するのは、本来有効で、妥当な手数料が支払われ、パブリックなトランザクションプールに伝播している取引が、一部のブロック構築者の主観的な選択によって無期限に遅延させられるべきではない、という点である。

進捗状況として、2026 年 8 月時点で FOCIL に対応する EIP-7805 は依然として Draft の状態にあるが、すでにイーサリアムのコア開発者によって Hegotá アップグレードのコンセンサスレイヤーにおける Headliner に選ばれ、Scheduled for Inclusion の段階に入っている。これは、クライアントチームがその実装と開発ネットワークでのテストに向けて動くことに合意したことを意味するが、具体的なメインネットへのリリース時期はまだ最終決定されていない。

FairFIL はさらに初期段階にあり、現在は主に 2026 年 7 月に発表された研究提案であり、今後イーサリアムのロードマップに入るかどうかは、より広範な議論、実装、そして安全性の検証を経る必要がある。