イーサリアムガバナンスへの反省：なぜ人々はEIP-3074事件に不満を抱いているのか？
TechFlow厳選深潮セレクト
イーサリアムガバナンスへの反省：なぜ人々はEIP-3074事件に不満を抱いているのか？
イーサリアムのEIP-3074／EIP-7702を巡る出来事は、そのガバナンス構造の複雑さを浮き彫りにした。正式なガバナンスプロセスに加えて、研究者らが提示する非公式なロードマップも大きな影響力を持っているのである。
Web3業界の深掘り報道に専念し潮流を洞察執筆：ブール説
本稿では、最近のEIP-3047事件に関する私の考察を述べます。内容のレビューをVitalikおよびYoavにご協力いただき感謝申し上げます。
この出来事についてご存じない方に向けて、簡単に振り返ります：
少し前のことですが、EIP-3074提案がコア開発者から承認され、次回のイーサリアムのハードフォーク「Pectra」で実施される運びとなりました。この提案は、通常のイーサリアムアカウント（EOA）ユーザーにも、アカウント抽象（Account Abstraction、略してAA）の利便性を享受できるようにすることを目的としています。
しかし直後、ERC-4337コミュニティ、特に同提案の起草者たちから強い反対意見が出ました。主な理由として、EIP-3074は中央集権化リスクを高める可能性があり、またイーサリアムのアカウント抽象ロードマップと整合しないという点が挙げられました。そのロードマップの中心はEIP-4337およびその近縁であるEIP-7560（いわゆるネイティブアカウント抽象）です。
先週、VitalikはEIP-3074の代替案としてEIP-7702を提案しました。これもEOAユーザーにアカウント抽象の恩恵をもたらすことを目指していますが、設計面では現在のEIP-4337標準により適合しており、最終形態であるEIP-7560へのスムーズな移行も可能になります。
訳者注：ERC-4337およびERC-7560は、いずれもイーサリアムエコシステムにおけるアカウント抽象に関連するプロポーザルであり、ユーザーのアカウント管理やインタラクション方法の改善を通じて、ユーザーエクスペリエンスとセキュリティの向上を目指しています。
ERC-4337は、ユーザーがプロキシコントラクト（Proxy Contract）を通じてアカウントを管理できるようにすることで、DAppとのやり取りにおける複雑さやリスクを低減します。一方、ERC-7560は、ERC-4337などのアイデアをイーサリアムの基礎層に直接組み込み、すべてのアカウントが自然にアカウント抽象の機能を持つようにすることを目指し、より深い統合と最適化を実現します。
ERC-4337はERC-7560へ至る重要な中間ステップであり、両者は合わせてイーサリアムのアカウント抽象ロードマップの中核を成しています。
現在、コア開発者チームはEIP-7702について議論を進めています。初期の兆候やコミュニティからのフィードバックから、EIP-7702がPectraハードフォークにおいてEIP-3074に代わって採用される可能性が高いと考えられます。
この結果については個人的に非常に満足しています。EOAユーザーは、ERC-4337向けに構築されたツールやインフラストラクチャを通じて、アカウント抽象による多くの利点を享受できるようになるのです。
しかし、その到達過程には不満を覚える部分があります。これは決して最良の道筋とは言えず、最近多くの人々が共有している感覚でもあります。私は、より整備されたプロセスがあれば、混乱を避け、より迅速に合意に達できたはずだと確信しています。
本稿では以下のことを試みます：
-
問題点の分析
-
イーサリアムガバナンスを理解するための思考フレームワークの提示
-
今後同様の失敗を回避するための改善策の探求
なぜ人々が不満を感じるのか？
この一連の出来事は多くの人々にとって不満を引き起こしました。理由はいくつかあります：
-
長い審査プロセス：EIP-3074は数年をかけてようやく承認された。
-
フィードバックの遅れ：コア開発者はEIP-3074の承認後に初めて、ERC-4337コミュニティからの広範な反対意見を聞いた。
-
警告の無視：4337プロポーザルの著者は繰り返しコア開発者にEIP-3074への懸念を伝えたが、ほとんど効果がなかった。
-
方針転換：我々は現在、EIP-3074を取り下げ、EIP-7702に置き換える局面にある。
客観的に見れば、上記の各要素は単体ではどれも不当ではありません：
-
長期的な議論は当然のプロセスである。
-
承認後の反対も正常な現象である。
-
新たな問題が浮上した場合、意思決定を見直し、取り消すことも理にかなっている。
しかし、おそらく誰もがこう考えるでしょう。もっとスムーズに進むべきだったと。もし以下のように事態が展開していたらどうでしょうか：
コア開発者がEIP-3074を議論している間に、ERC-4337コミュニティが積極的に関与していたとしたら、次の二つの結果のいずれかになります：
-
EIP-4337コミュニティのフィードバックを踏まえてEIP-3074が承認された（修正を加えた可能性あり）なら、ERC-4337コミュニティもそれを支持し、EIP-3074の撤回は不要となる。
-
あるいは、EIP-3074はそもそも承認されず、代わりにERC-4337コミュニティとコア開発者が協力して、全員が納得できる新しい提案（例えばEIP-7702のような）を推進できた。
誰もが声を聞かれ、劇的な反転も起きなかった。理想的な結末のはずですが、なぜそれは実現しなかったのでしょうか？
問題の所在
このプロセスを振り返ると、双方に非があると批判されています。
コア開発者（EIP-3074の作者を含む）側は、EIP-4337チームがAll Core Devs（ACD）プロセスに積極的に参加していれば、このような問題は起きなかったと感じています。
このプロセスでは、プロポーザルは長期間にわたって議論され、最終的にクライアント開発チームが受け入れてプロトコルに統合されます。彼らは、EIP-4337チームがいつでも介入し、懸念を表明できたはずであり、EIP-3074が承認された後に反対するのは遅すぎたと考えています。確かにACDプロセスは公開透明であり、会議は誰でも参加可能で、Tim Beikoなどのメンバーが毎回の会議後に要約をツイートしています。EIP-4337チームが本当に気にかけていたなら、時間を割いて参加すべきだったのではないでしょうか。
一方、アカウント抽象チーム（EIP-4337の作者）は、実際にACD会議に参加し、EIP-3074に反対する機会を逃さず主張してきたが、コア開発者に受け入れられなかったと強調しています。また、多くのERC-4337コミュニティのメンバーは驚きを隠せず、EIP-3074はすでに放棄されたものだと誤解していたほどでした。
さらに、ACDプロセスはあまりに複雑で、フルタイムの仕事を持ちながら最新の動向を追うのは困難だという意見もあります。また、主要な利害関係者（例：EIP-4337コミュニティ）に対して能動的に意見を求める責任は、ACD側にあるべきだという主張もあります。
私の見解では、どちらの立場も根本的な問題を捉えきれていないと思います。ここにはもっと深い問題があり、これを解決または少なくとも認識しない限り、ガバナンスの失敗と意味のない相互非難が繰り返されるでしょう。
真の原因
ガバナンスの失敗の真の原因は、All Core Devs（ACD）の役割に対する一般的な誤解にあります。ACDはプロトコル更新の唯一の決定機関ではなく、このケースではそれ以上の力を有する別のガバナンス勢力が存在し、決定的な影響を及ぼしていました。
問題は、この極めて重要なガバナンス勢力が、アカウント抽象やスケーラビリティといった重大案件で大きな影響力を持っているにもかかわらず、公式に認められることがほとんどない点にあります。
私はこの力を「ロードマップ」と呼ぶことにします。
要するに、EIP-3074からEIP-7702への移行騒動は、「ロードマップ」という見えざる力がACDの意思決定を覆した典型例なのです。
ガバナンスの観点から言えば、目に見える力を超える見えない力が支配するとき、警戒すべきです。なぜなら見えない力は監視されないからです。そのため、このような隠れた力を明らかにし、検証する必要があります。
ロードマップとは何か？
イーサリアム界隈では「ロードマップ」という言葉は聞き慣れているでしょう。例えば、Rollup中心のロードマップ、ETH 2.0ロードマップ、あるいは今回の焦点であるアカウント抽象ロードマップなどです。
想像してみてください。あるAll Core Devs会議で、ネットワークのスケーリングについて議論が始まっています：
コア開発者のBobが提唱します。「私はEIP-1234を支持します。ブロック生成時間を10倍速くし、ブロック容量を10倍に拡大し、取引手数料を100倍安価にするものです」
他の開発者たちは答えます。「本気ですか？」
なぜBobの提案は即座に却下されるのでしょうか？彼は確かに有効なスケーリングソリューションを提示しており、Solanaなどの他のチェーンでは同様のアプローチが成功しています。
その理由は、Bobの提案が「Rollup中心のスケーリングロードマップ」と矛盾するからです。このロードマップは、ブロックチェーンの分散性を維持するために、一般ユーザーが容易にノードを運用できることを重視しています。したがって、ノードの運用負荷を大幅に増加させるBobの提案は、ロードマップに反するため排除されるのです。
この例を通して示したいのは、ACD会議に出席し、プロトコルの更新を担当するコア開発者たちが、実は私が言うところの「ロードマップ」というより高いガイドラインに従っているということです。ここにはスケーリングロードマップ、アカウント抽象ロードマップ、MEVロードマップなどさまざまなものが存在し、これらが総合されてイーサリアム全体のロードマップを形成し、コア開発者の意思決定の根拠となっているのです。
コア開発者とロードマップが一致しないとき
ロードマップは正式なガバナンスの一部ではないため、コア開発者が常にそれに沿っているとは限りません。特に、「ロードマップの承認」のような公式プロセスがないため、すべてのロードマップが同じレベルの認知を得ているわけではありません。そのため、ロードマップの背後にある企画者は、コア開発者や広いコミュニティに積極的に訴えかけ、支持を得て、最終的にコア開発者の同意を勝ち取る必要があります。
アカウント抽象の場合、Vitalikは繰り返しEIP-4337を中心とするロードマップを推奨してきましたが、実際には主にEIP-4337チーム、特にYoavとDrorが、会議やオンラインフォーラム、ACDの場でそのロードマップを熱心に推進してきました。
しかしながら、それでも一部のコア開発者はEIP-4337中心のロードマップに反対し、EIP-7560（EIP-4337のネイティブ版で、将来のクライアント実装が必要）は過度に複雑であり、アカウント抽象の最終形を実現する唯一の道ではないと主張しました。最終的に、EIP-4337チームがEIP-3074に反対しても（EIP-3074がより中央集権的なアカウント抽象技術スタックを導入することで、抽象アカウントエコシステムを分裂させると懸念）、ACDはEIP-3074を承認したのです。
しかし、EIP-3074が承認された後、EIP-4337コミュニティ全体の強い反発を受け、コア開発者は再考を余儀なくされました。双方の対立が続く中、VitalikがEIP-7702をEIP-3074の代替案として提出したことで、状況はアカウント抽象ロードマップに沿った方向へと動き始めました。
Vitalikの役割
Vitalik自身は研究者と位置づけていますが、今回の出来事から明らかになったのは、彼がイーサリアムガバナンスにおいて独特かつ特別な役割を果たしていることです。ここで問われるのは、Vitalikがイーサリアムガバナンスでどのような位置を占めているのか、ということです。
Vitalikを大規模企業のCTOに例えることができます。
50人以上の規模のテック企業で働いた経験があるなら、CTOがすべての技術的意思決定に関与できないことは理解できるでしょう。企業が成長するにつれ、技術的意思決定は自然に分散し、各製品領域のサブチームが実装の詳細を自主的に決定するようになります。
また、CTOがすべての分野で最高の専門家である必要はありません。会社には特定の分野でCTOよりも優れたエンジニアがいるかもしれません。したがって、技術的論争では、しばしばエンジニアたちが最終的な判断を下します。
ただし、CTOは企業の技術的ビジョンを定め、具体的な実行は開発者に委ねます。
この比喩は完璧ではありませんが、Vitalikがイーサリアムエコシステムで果たす役割を非常に正確に描写しています。
Vitalikはすべての技術的意思決定に関与しません。そんなことは不可能ですし、すべての分野で最高の専門家でもありません。しかし、スケーリング、アカウント抽象、プルーフ・オブ・ステークなど、イーサリアムのすべての重要な側面におけるロードマップに対して巨大な影響力を持っています。これは単に技術的知識によるだけでなく、あるロードマップがイーサリアムのビジョン――言い換えれば、彼自身のビジョン――と一致しているかどうかを最終的に判断できるからです。
成功した製品の背後にあるのはビジョン
起業家として、私はすべての成功した製品の背後には明確なビジョンがあると思っています。そしてそのビジョンは、少数の人々、通常は創業チーム、あるいはしばしば一人のキーファウンダーによって確立されるものです。
イーサリアムの魅力は、そのような複雑で多層的なシステムが調和して動作し、毎日巨額の価値を処理する分散型コンピュータとなっている点にあります。これは委員会的な意思決定では達成できません。Vitalikのビジョンによるリードがあってこそ、今日の調整が取れた効率的なイーサリアムが存在するのです。2015年の構想から今日まで、イーサリアムは一貫してVitalikの知性の結晶です。
もちろん、他の研究者やエンジニアの貢献を貶めるつもりはありません。彼らはイーサリアムの発展に大きく貢献してきました。しかし同時に、イーサリアムはVitalikのビジョンの極致であり、他のいかなる個人の影響もはるかに凌駕していることは否定できません。
正直に問いかけてみてください。あなたがイーサリアムの開放性、検閲耐性、革新の活力に惹かれて参加したとき、それらすべてがVitalikの初期の構想から始まったことに、本当に気を留めましたか？
以前は深く考えなかったかもしれませんが、それを理解した今、本当にそれが気になるでしょうか？
イーサリアムは明確なビジョンによって生み出され、そのビジョンの実現に向けて継続的に成長してきた。それがまさにその魅力なのです。
では、分散化はどうなのか？
ここで疑問が湧くかもしれません。もし一人の人物がイーサリアムにこれほど大きな影響力を持っているなら、それをどうして分散化されたシステムと言えるのでしょうか？
この問いに答えるために、Vitalikが書いた古典的な記事を参照できます。そこでは分散化には複数の意味があると説明されています。要点は、分散化には三つの側面があるということです：
アーキテクチャ的分散化：システムが停止する前に、いくつのノードがダウンすればよいのか？
論理的分散化：システムの各部品は、全体の機能に影響を与えずに独立して進化できるか？
政治的分散化：何人の人物または組織がこのシステムを支配しているか？
イーサリアムはアーキテクチャ的・論理的には間違いなく分散化されています。多数のノードに分散でき、コンセンサスメカニズムと実行レイヤーなどの異なるコンポーネントが比較的独立して進化できるからです。
政治的分散化に関しては、良いニュースとして、Vitalikを含め、誰もがイーサリアムを停止させることはできません。しかし、Vitalikがイーサリアムのビジョンとロードマップを設定する上で重要な地位にある以上、政治的分散化には妥協があることは否めません。
私の見解では、イーサリアムが持続的に革新を続けるためには、Vitalikを事実上のCTOとして受け入れるべきです。たとえそれが政治的分散化の程度を若干低下させるとしてもです。イーサリアムがBitcoinのように成熟して変化が止まるまでの間は、技術的優劣だけでなく、長期的ビジョンに合致するかどうかも判断できる、尊敬される権威的人物が必要です。
Vitalikのような存在がいなければ、イーサリアムは二つのシナリオに陥る可能性があります。今回のEIP-3074事件がまさにその例です：
-
意思決定の行き詰まり：各方面が譲歩を拒み、プロジェクトが停滞する。EIP-3074の議論がVitalikの介入でようやく打破されたように。
-
設計の混乱：システムが不協和な寄せ集めになってしまう。EIP-3074とEIP-4337が互換性なく並行する危機がまさにそうだった。
したがって、イーサリアムが急速に進化している段階では、Vitalikのリーダーシップが、分散化されつつも方向性を失わないエコシステムを維持するために不可欠です。
コミュニティの重要性
ここまでで、イーサリアムガバナンスの包括的理解フレームワークがほぼ完成しましたが、まだ一つ重要な要素が抜けています――コミュニティの役割です。
もしVitalikがビジョンを定め、研究者がそれに基づいてロードマップを描き、コア開発者がそれを実装するなら、コミュニティはどこに位置するのでしょうか？まさか無関係なのでしょうか？
実際、コミュニティは最も中心的な役割を果たしています。なぜなら、ビジョンが形成される以前に、それよりも根源的なもの――価値観（Values）――が存在するからです。私たちは共通の価値観を共有することでコミュニティを形成し、その価値観がVitalikのビジョンの土台となります。ビジョンが価値観と一致しなければ、コミュニティは崩壊するでしょう。
成長環境や過去の経験の影響かもしれませんが、イーサリアムコミュニティの一人ひとりが、誰もがアクセスでき、検閲不可能で、真に分散されたコンピュータの構築が世界にもたらす価値に気づいた瞬間があります。私たちが日々イーサリアムで行う作業は、その価値観の実践と確認であり、その行動を通じて、Vitalik、研究者、コア開発者が掲げるビジョン、ロードマップ、コードに命と正当性を与えるのです。
イーサリアムガバナンス簡易モデル：VVRCフレームワーク
イーサリアムのガバナンスを、精巧に設計された機械に例えてみましょう。それを四つのキーコンポーネントに簡略化します：価値観（Values）、ビジョン（Vision）、ロードマップ（Roadmaps）、クライアント（Clients）。これをVVRCモデルと呼びます。
-
価値観（Values）：すべては、イーサリアムコミュニティが共有する基本原則と信念から始まる。
-
ビジョン（Vision）：創設者であるVitalikが、コミュニティの価値観に基づき、イーサリアムの将来像を描く。
-
ロードマップ（Roadmaps）：明確なビジョンのもと、研究チームがその夢を実現するための具体的なステップを立案する。目標に至る技術的パスを設計する。
-
クライアント（Clients）：最後に、コア開発者チームがロードマップに従ってコードを書き、クライアントソフトウェアを保守することで、すべての技術的計画を現実のものとし、ユーザーと開発者が実際に利用できるようにする。
このプロセスはスムーズに思えますが、現実にはより複雑です。例えば、実際のソフトウェア実装を担当するコア開発者が最終的な決定権を握っている点です。Vitalikや他の研究者はあくまで助言を行う立場であり、時にはその提案が受け入れられないこともあります。EIP-3074事件がまさにその例です。
総じて、VVRCモデルは理想状態でのイーサリアムガバナンスの推進を理解するのに役立ちます。同時に、EIP-3074のような問題が再発しないよう、プロセスの調整と改善が必要であることを思い出させてくれます。
イーサリアムガバナンスの改善策
イーサリアムのガバナンス構造を最適化し、EIP-3074／EIP-7702事件の再発を防ぐため、以下の改善策を提案します：
EIPの透明性向上：検討中のEIPがコミュニティに対してよりオープンになり、EIP-3074が突然承認されたように皆が驚くような事態を避ける。実際、EIPサイトに掲載されるEIPのステータスはACDの審議進捗と同期していないため、たとえコア開発者がEIP-3074に同意しても、「レビュー中」と表示されたままです。イーサリアム財団のSNSプラットフォームなどを通じて、承認が近いEIPを事前にコミュニティに通知すべきです。
コミュニティ参加の促進：ACD会議中に、EIPが下流プロジェクトに与える影響をコミュニティメンバーが議論できる特別枠を設ける。これにより、EIP-3074がEIP-4337コミュニティに与えた予期せぬ影響を防げる。また、研究者が自分のフィードバックがコア開発者に無視されていると感じたら（EIP-4337チームが直面したように）、コミュニティメンバーを議論に巻き込んで立場を強化できるようにすべきです。
相互理解と継続的対話：コア開発者と研究者は、それぞれがガバナンスの鍵を握る存在であることを理解し、その重点が異なることを認識すべきです。コア開発者はクライアント実装を通じて「執行権」を持ち、いわば「投票権」を有しています。一方、研究者はロードマップを積極的に共有・議論することで、広範なコミュニティの支持を得て「ロードマップ的影響力」を獲得します。
両者の意見が合わない場合、コア開発者は研究者のアイデアを無視して押し切ろうとする傾向があります。EIP-4337チームに対してもそうしました。しかし、これでは反発を招きやすく、両者の力関係が崩れたときに混乱が生じます。EIP-3074承認後の混乱がその証左です。
逆に、研究者が抵抗に遭うと、コア開発者との協力をやめてしまう可能性があります。これがRIP（Rollup Improvement Proposal）プロセスが生まれ、ネイティブアカウント抽象（EIP-7560）がEIPではなくRIPとして推進されている理由の一つでもあります。
RIPはL2がL1では直接採用されにくいプロトコル更新を実験する上で有益ですが、EIPガバナンスプロセスへの参加を代替することはできません。研究者は、ロードマップが一致するまで、コア開発者との対話を続ける必要があります。
これらの措置により、ガバナンスの透明性が向上し、コミュニティ参加が促進され、コア開発者と研究者の間の効果的な協力が促進され、将来のガバナンス問題を減らすことができるでしょう。
まとめ
イーサリアムのEIP-3074／EIP-7702事件は、そのガバナンス構造の複雑さを浮き彫りにしました。正式なガバナンスプロセス（コア開発者がEIPおよびACDの提案に基づいて推進するもの）に加えて、研究者が提唱する非公式なロードマップも巨大な影響力を持っているのです。両者の力が不一致になると、意思決定の行き詰まりや急激な方向転換が起きかねず、その際にVitalikの役割が特に重要になります。彼はイーサリアムのビジョンを掌握することで諸勢力を調整でき、ある意味プロジェクトの精神的指導者のような存在です。
我々はイーサリアムのガバナンスを、コミュニティの価値観 → Vitalikのビジョン → 研究チームのロードマップ → コア開発者の実装（VVRCモデル）というモデルに簡略化しました。この流れは、広範な理念から具体的な技術実装へと意思決定がどのように細分化されていくかを示しています。
ガバナンスの効率を改善するには、この理想モデルから逸脱する実際の問題に対処する必要があります。優れたイーサリアムガバナンスこそがプロジェクトを前進させる核となるメカニズムだからです。EIP-3074事件は一例として、ガバナンスの弱点を露呈し、学びと改善の機会を提供してくれました。今後同様の課題にうまく対処し、イーサリアムの持続的かつ健全な発展を確かなものにしていくために。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@imTokenOfficial
