Vitalikおよび各種ロードマップがイーサリアムのガバナンスプロセスに与える影響について
TechFlow厳選深潮セレクト
Vitalikおよび各種ロードマップがイーサリアムのガバナンスプロセスに与える影響について
技術ロードマップは、イーサリアムのガバナンスにおいて見過ごされがちな中核的な力であり、ビタリックの役割はCTOにこそ相応しい。
Web3業界の深掘り報道に専念し潮流を洞察執筆：Derek Chiang、ZeroDev CEO
翻訳：Faust、Geek web3
概要：本文是AAエコシステム内プロジェクトの創業者が、V神（Vitalik Buterin）がERC-4337とEIP-3074の矛盾を調整するためEIP-7702を提唱した後、その出来事について述べた見解である。著者は自身の体験を通じて、イーサリアムの現在のガバナンス体制とその課題を客観的に指摘し、鋭く次のように喝破している。
イーサリアムのガバナンスにおける問題の一つは、リサーチャーによって策定されたロードマップと、Gethなどのクライアント開発チームの見解との間に乖離があることであり、V神がCTOのような存在として最終的な裁定者となっている点にある。
DerekはV神の役割を肯定しつつも、イーサリアムがガバナンスモデルにおいてどのように改善すべきかを示しており、これはイーサリアムコミュニティのみならずビットコインコミュニティにも有意義な示唆を与えるものである。
本文：もし以前にイーサリアムのAA（アカウント抽象化）に関する出来事をご存知ない場合、以下に簡単な振り返りを記す。
数週間前、EIP-3074がイーサリアムのコア開発者から承認され、「Pectra」と呼ばれる次のハードフォークに組み込まれることが決定した。この提案はEVMに2つの新しいオペコードを追加し、EOAアカウントにほぼネイティブレベルのAA体験を提供するものである。
それ以来、ERC-4337コミュニティ、特に4337の提唱者たちはEIP-3074に対して強く反対しており、その理由はセキュリティ上のリスクへの懸念と、イーサリアムのAAロードマップとの不整合にある。イーサリアムのこれまでのロードマップでは、ERC-4337および類似の提案である7560（通称「nativeAA」）を中心に据えていた。
5月初め、V神はEIP-3074の代替案としてEIP-7702を提案し、4337と3074の間でバランスを取った。これによりEOAユーザーにもAA体験が提供されるが、ERC-4337や「AAの究極形態」とされる7560とも互換性を持つ。
現在、イーサリアムのコア開発チームはEIP-7702を検討中であり、初期の議論やコミュニティの反応を見る限り、EIP-7702が前述のEIP-3074に代わる可能性が高い。
個人的には、この結果には非常に満足している。EOAユーザーはすぐにERC-4337エコシステムのさまざまな製品を体験でき、AAによる多くの利点を享受できるようになる。しかし一方で、このような結果を得るにはより良い方法があったはずだ。過去数週間、多くの人々がそう感じており、より良いガバナンスプロセスがあれば、莫大な労力を節約し、より迅速に目的を達成できたはずだと私は思う。
本稿では以下のことを試みたい。
-
ガバナンスプロセスのどこに問題があったかを特定する
-
イーサリアムガバナンスを考えるための思考モデルを提示する
-
将来同様のガバナンス事故を回避するための改善策を提案する
EIP-3074事件のまとめと省察
上記のストーリーは多くの人々を不快にさせた。その理由は以下の通り。
EIP-3074は数年かけてようやく承認された。3074が最終的に承認された後になって、イーサリアムのコア開発チームは4337コミュニティからの強い反発を受けた。
一方で、ERC-4337の作者たちは繰り返し、イーサリアムのコアチームに対しEIP-3074への懸念を伝えてきたが、耳を貸してもらえなかった。今やイーサリアムは3074の承認を取り消し、別のEIP（7702）で置き換える計画を進めている。
上述のプロセス自体に根本的な誤りはない。
-
あるEIPの議論に数年を要するのは当然のことである。
-
承認後にEIPが拒否されるのも正常なことである。
-
新たな問題が発覚すれば、承認済みのEIPを取り下げるのも可能である。
しかし、本来もっとスムーズに解決できたはずだ。仮にこうなっていたらどうだろう。
3074の議論の中で、4337コミュニティがイーサリアムのコア開発チームと積極的に対話していたとしよう。この前提が成立すれば、次のいずれかの結果になったはずだ。
-
4337コミュニティのフィードバックを踏まえた上で3074が承認（あるいは修正）され、4337コミュニティもそれを受け入れ、コアチームが3074を取り下げる必要もなくなる。
-
あるいは、3074がそもそも承認されず、代わりに4337コミュニティとコアチームが共に満足する提案（例：7702）を共同で生み出す。
誰もが声を聞き入れられ、劇的な逆転もなく済んだはずだ。それは理想的だった――なぜ現実にはそうならなかったのか？
どこが間違っていたのか？
全体を振り返ると、両陣営は互いに非難し合っている。
イーサリアムのコア開発者（およびEIP-3074の作者）は、「4337支持者」が全体会議（ACD）の議論プロセスに十分参加しなかったことが原因だと主張する。このプロセスでは、EIPがGethなどのクライアント開発チームに受け入れ・実装されるまで、長期間の審議が必要となる。
つまり、3074の審議中に「4337支持者」は完全に参加可能であり、意見を表明できたはずなのに、承認されてから後出しジャンケンのように反対してきた。ACDの議論はすべて記録され、誰でも参加可能であり、TimBeikoなどは毎回の会議後に要約ツイートを積極的に投稿している。ならば、4337支持者がこれほど関心を持っているのであれば、なぜ適切かつタイムリーに会議に参加しなかったのか？
一方で、4337の核心メンバーは、自分たちは常にACD会議に出席し、可能な限り3074に反対してきたが、コア開発者たちが耳を傾けなかったと指摘する。また4337コミュニティの多くは突然の出来事に驚いた――多くの人が3074は既に頓挫したと思っていたし、承認されようとしていることすら知らなかった。
多くの人々が、ACD会議のプロセスは極めて透明性が低く、イーサリアムコミュニティ内で真剣に活動していても、ACDの進捗をリアルタイムで追うのは困難だと訴えている。また、ACD側が利害関係者（ここでは4337コミュニティ）に能動的にフィードバックを求めることも必要だと考える人もいる。
しかし、私の考えでは、双方とも本質を突いていない。この背景にはより深い問題があり、これを解決あるいは少なくとも認識しない限り、私たちは繰り返しガバナンス事故を起こし、相互に非難し合うだけになってしまう。
ガバナンス事故の根本原因：ロードマップ
一般的な見方とは異なり、ガバナンス事故の根源は、ACDがプロトコル更新の唯一のガバナンス権限ではないことにある。むしろ、別のガバナンス権力に覆されているのだ。問題は、この別種の権力がAAやスケーラビリティといったコアテーマにおいてACDよりも大きな影響力を持ちながら、ほとんど公に認められていない点にある。
本稿では、この力を「ロードマップ」と呼ぶことにする。
以下で述べるように、「3074-4337-7702」の一連のガバナンス失敗は、既存のロードマップという権力がACDの権力を凌駕した一例である。ガバナンスについて語るのであれば、目に見える力が目に見えない力に圧倒される状況には警戒すべきだ。目に見えないものは説明が難しく、多くの人に気づかれにくいからこそ、可視化する必要がある。
ロードマップとは何か？
イーサリアムコミュニティの誰もが、「ロードマップ」という言葉をよく耳にするだろう。「ロールアップ中心のロードマップ」「ETH2.0ロードマップ」、あるいは今回の件に関連する「AAロードマップ」など。
私の主張を説明するために、ACD会議中のシナリオを想像してみよう。ここでコア開発者たちがイーサリアムのスケーリングについて議論しているとする。
-
コア開発者Bob：私はEIP-1234を支持する。ブロック生成速度を10倍、ブロックサイズを10倍にし、手数料を100分の1にする提案だ。
-
他のコア開発者たち：…馬鹿じゃないのか？
考えてみよう。なぜイーサリアムのコアチームはBobの提案を拒否するのか？彼が提唱するスケーリング手法は一見合理的に見えるし、SolanaやAptos、Suiなど多くのブロックチェーンで成功しており、高いTPSを達成している。
その理由は、この架空のEIP-1234が「ロールアップ中心」のスケーリングロードマップに反するからだ。このロードマップでは、去中心化のために、一般ユーザーが低コストでノードを運営できることが極めて重要とされており、従ってこのEIP-1234は受け入れられない。なぜなら、イーサリアムノードの運営コストを大幅に増加させるからだ。
この例を通して言いたいのは、ACDでのガバナンスプロセスに参加し、プロトコル更新を決定するコア開発者たちは、より上位の指導原理――私が「ロードマップ」と呼ぶもの――に従っているということだ。現在、イーサリアム周辺には「スケーリングロードマップ」「AAロードマップ」「MEVロードマップ」などがあり、これらが総体となってイーサリアムの全体像を形成しており、コア開発者はそれに基づいて意思決定を行っている。
コア開発者の見解がロードマップと一致しないとき
ただし、ロードマップはガバナンスプロセスの正式な一部ではないため、コアチームが必ずしもそれに従う保証はない。また、ロードマップを「承認」する正式なプロセスもないため、すべてのロードマップが同等の「正統性」を持つわけではない。イーサリアムのロードマップを掲げる研究者たちは、コア開発者やコミュニティに自らのロードマップを宣伝し、支持を得ることで「正統性」を獲得しなければならない。
AAおよびアカウント抽象化に関して言えば、V神自身が繰り返し、4337を中心としたAAロードマップを推進してきた。とはいえ、全体としてはYoavとDrorをはじめとする4337背後のチームが、フォーラムやACD会議で4337中心のAAロードマップを主張してきた。
しかし、これらの努力にもかかわらず、いくつかのイーサリアムコア開発者は4337中心のAAロードマップに強く反対している。彼らは7560（将来的にクライアントが実装する4337のネイティブ版）が過度に複雑だと考え、AAの「究極解」として唯一の選択肢とは見なしていない。結果としてACDは3074の承認を決定した。4337チームはこれに反対し、3074がAAエコシステムを分裂させると警告していた。
3074が承認された後、4337コミュニティ全体が強烈な反応を見せ、イーサリアムのコア開発者を再び議論に引き戻した。その後、議論は膠着状態に陥り、4337の作者と3074の作者は互いを説得できず、V神が最後の瞬間にEIP-7702を3074の代替案として提案した。この提案は4337中心の「AA究極解」と明確に互換性を持ち、衝突を解消し、結果をAAロードマップに一致させた。
V神の役割：イーサリアムの事実上のCTO
V神は自らをリサーチャーと位置づけてはいるが、上記のストーリーは明らかに、V神が他のリサーチャーとは異なるガバナンス的権力を有していることを示している。そこで問われるのは、V神はイーサリアムガバナンスにおいてどのような役割を果たしているのか？
個人的には、V神を極めて巨大な企業のCTOと見なしても差し支えないと思う（ちなみに、正確さのために補足すると、イーサリアムという「企業」にはCEOがいないと仮定する）。
50人以上の従業員を抱えるテック企業で働いた経験があれば、CTOがすべての技術的意思決定に携われるわけがないことを知っているはずだ。企業の規模が一定以上になると、技術的決定プロセスは必然的に分散化する。通常、各製品／事業領域に専任チームが存在し、細部の決定はそのチームに委ねられる。
さらに、CTOがすべて（あるいはどの）分野でもトップクラスの専門家であるとは限らない。特定の分野ではCTOよりも優れたエンジニアが社内にいるかもしれない。そのため、技術的詳細に関する決定は、しばしば現場のエンジニアが下すことになる。
しかし、CTOが企業の技術的ビジョンを定める。そのビジョンの実行は開発者に任される。
完璧な比喩ではないが、これはV神がイーサリアムエコシステムで果たす役割を適切に要約していると思う。V神はすべての技術的意思決定に参加しないし、参加できない。彼がすべての分野の専門家でもない。しかし、スケーリング、AA、PoSなど、すべての主要な戦略的ロードマップの策定に圧倒的な影響力を持ち、それは単に技術的専門性だけでなく、彼自身の「イーサリアムビジョン」に沿っているかどうかの最終判断者だからである。
すべての成功した製品はビジョンから始まる
V神をイーサリアムのCTOと見なすのがまだ物議を醸すなら、最も議論を呼ぶ主張はこれからだ：我々はV神のCTOとしての役割を歓迎すべきである。
起業家の創業者として、すべての成功した製品には一貫した長期ビジョンが必要だと信じている。そう、イーサリアムも「製品」なのだ。なぜなら、実際に存在するユーザーの本当に重要な問題を解決しているからだ。そして一貫したビジョンは少数の人間、例えばスタートアップの創業者によって作られ、普通は一人の創業者によって作られる。
イーサリアムの素晴らしい点は、非常に複雑なシステムでありながら、多数のコンポーネントが完璧に組み合わさり、数十億ドル規模の取引を毎日処理する動作のよい分散型コンピュータを形成していることだ。
我々がここまで来たのは、ある委員会の設計によるのではない。V神がその卓越したビジョンによって能動的にリードしたおかげで、今日の整合的で美しいイーサリアムが生まれたのだ。イーサリアムは2015年にV神が提唱したアイデアであり、今も変わらずそうだ。
もちろん、他のリサーチャーやエンジニアの貢献を軽視するわけではない。彼らがイーサリアムの今日の成果の大部分を築いたのは事実だ。しかし、それは矛盾しない。なぜなら、イーサリアムはV神のビジョンの実現であり、その規模は他の誰のビジョンよりも何桁も大きいからだ。
正直に言って、文句を言う余地はあるか？イーサリアムエコシステムの開放性、検閲耐性、革新スピードに惹かれたときに、それがV神のビジョンから始まったことに文句を言ったことがあるか？おそらくないだろう。そんな風に考えたこともなかったかもしれない。だが今ならわかる。それでも、本当に気にするか？
去中心化はどうなるのか？
しかし、あなたはこう言うだろう。「それでは去中心化はどうなるのか？一個人がイーサリアムに対してこれほど大きな権力を有しているなら、どうやって去中心化と言えるのか？」
この問いに答えるには、V神自身が書いた「分散化の意味」に関する古典的文章を思い出す必要がある。この文章の重要な洞察は、分散化には三種類あるということだ。
-
構造的分散化：いくつのノードが故障したらシステムが停止するか？
-
論理的分散化：サブシステムは独立して発展できるか？それとも密接に調整が必要か？
-
政治的分散化：最終的に何人の個人または組織がシステムを支配しているか？
これらの定義に基づけば、イーサリアムは明らかに構造的に分散化されており、論理的にも分散化されていると考えられる。なぜなら、コンセンサス層と実行層など、各コンポーネント間に強い結合がないからだ。
政治的分散化に関しては、幸いなことに、いかなる個人や組織もイーサリアムを停止させることはできない。V神でさえもだ。しかし、政治的分散化の程度は、人々が思っているほど高くなく、V神がイーサリアムのビジョンとロードマップの策定に大きな役割を果たしているため、疑問視される余地はある。
しかし私の考えでは、イーサリアムが継続的に革新していくためには、V神が事実上のCTOとしての役割を担うことを受け入れるべきであり、それがいくらかの政治的分散化の犠牲を伴うとしてもだ。
もしイーサリアムがビットコインのように「硬直化」し、ほとんど変更不可能なブロックチェーンになってしまえば、V神はそのまま引退してもいいかもしれない。しかし、その最終段階に至るまでの間、すべての関係者が尊重する権威が存在することは極めて重要である。その権威は信頼され、技術的意思決定を下すことができなければならない。その判断は、提示された技術案が優れているかどうかだけでなく、それがイーサリアムのビジョンに合致しているかどうかも基準に含めるべきだ。
V神のような人物がいなければ、次の二つの結果しかありえない。3074を巡る出来事は、まさにこの二つの結果を生き生きと描いている。
-
イーサリアムのガバナンスプロセスは無限の膠着状態に陥る。対立する双方が妥協せず、誰も前進できなくなる。これは3074の議論がV神が介入するまで停滞していたことから明らかだ。
-
あるいは、イーサリアムは設計が不統一な「フランケンシュタイン」になってしまう。前述の3074と4337が譲らず、AAエコシステムが互換性のない二つの平行世界に分裂してしまう。
コミュニティの役割
以上の考察を経て、ほぼ完全なイーサリアムガバナンスの思考モデルが浮かびつつあるが、これまでの議論には明らかな欠落がある――コミュニティだ。
V神がビジョンを定義し、研究者がロードマップを定義し、コア開発者がそれを実装するなら、コミュニティは何をすればいいのか？何もしないわけにはいかないだろう？
幸いなことに、コミュニティは実際には最も重要な役割を果たしている。なぜなら、ビジョンの前に価値観があるからだ。我々は特定の価値観の周りに団結することでコミュニティを形成している。そしてV神のビジョンは最終的にこれらの価値観と一致していなければならない。そうでなければ、コミュニティの支持を失う。
イーサリアムコミュニティの全員が、誰でもアクセスでき、検閲されず、信頼できる中立性を持つ分散型コンピュータが世界にとって有益だと信じている。我々は日々イーサリアム上で働くことで、これらの価値観を維持・肯定し、その行動を通じてV神、研究者、コア開発者が策定するビジョン、ロードマップ、コードに正統性を与えている。
イーサリアムガバナンスのVVRCモデル
以上を踏まえて、イーサリアムガバナンスの完全な思考モデルを提示する。価値観 ⇒ ビジョン ⇒ ロードマップ ⇒ クライアント、略してVVRCである。
-
V == 価値観 == コミュニティ；
-
V == ビジョン == Vitalik；
-
R == ロードマップ == 研究者；
-
C == クライアント == コア開発者；
これらは以下のように機能する。
-
コミュニティが特定の価値観に集結する。
-
Vitalikがその価値観と一致するビジョンを表明する。
-
研究者がビジョンに基づいてロードマップを策定する。
-
コア開発者がロードマップに基づいてクライアントを実装する。
もちろん、現実はどんなシンプルなモデルよりも複雑だ。実際、クライアントコードへの変更を通じて任意の提案に真正面から「投票」できるのは、コア開発者だけである。Vitalikや他の研究者はあくまで助言者に過ぎず、時にその意見はコア開発者に受け入れられない。これがまさにEIP-3074が承認された理由である。
とはいえ、私はVVRCモデルが通常の状況下でのイーサリアムガバナンスの運営方法を適切に捉えており、EIP-3074のような事故が再発しないよう、このプロセスを「デバッグ」すべきだと考える。
イーサリアムガバナンスモデルの改善策
以上により、イーサリアムのガバナンスプロセスの仕組みについて心理モデルができた。以下に、ガバナンスプロセスを改善するためのいくつかのアイデアを提示する。
-
審議中のEIPに関する議論の進捗可視性を高める必要がある。コミュニティ全体がEIPの承認に「驚く」ようなことはあってはならない。3074のような予期せぬ承認は二度と起こるべきではない。
現在のEIPサイトでのEIP「ステータス」は、ACDプロセス内での実際のステータスを反映していない。そのため、3074はすでにコア開発者によって承認されたにもかかわらず、「レビュー待ち」のままになっている。そもそも承認が検討されていたことすら示唆していない。
理想は、EIPが承認されようとしている時点で、イーサリアム財団がソーシャルメディアで明確に発表し、コミュニティの認知度を高めることだ。
-
コア開発者が特定のEIPが下流のプロジェクトやユーザーに与える影響を過小評価することがある。3074と4337コミュニティがまさにそのケースだ。ACD会議の時間は限られており、タイムゾーンを越えて調整が必要なため、発言できるのはしばしば「関係者」に限られる。
そのため、特定のEIPが通過した後の下流への影響について、コミュニティメンバーに発言時間を割くのも意義がある。
研究者が自分の意見がコア開発者に届かないと思えば、4337の場合のように、コミュニティメンバーに参加を呼びかけることで主張を強化できる。
-
極めて重要なのは、コア開発者と研究者が互いに、力の差はあれど、両者ともイーサリアムガバナンスの一部であることを認識することだ。コア開発者はプロトコルそのものを変更する唯一の「投票」権を、クライアントコードの変更と更新を通じて持つ。一方、研究者はロードマップの変更と解釈に関する権限を持ち、研究者が積極的に構想を語り、書き記すことで、より広い公的支持を得ている。
この二大勢力が衝突したとき、コア開発者は研究者の意見を直接覆そうとする傾向がある。例えば、コア開発者が4337チームの反対を無視したように。しかし、このような「覆し」は衝突を招く可能性があり、3074の承認後に起きたドラマチックな出来事がそれを示している。
同様に、抵抗に遭ったとき、研究者はコア開発者との協力を放棄しようとする傾向がある。私の見解では、それがRIPプロセスが生まれた理由の一つであり、ネイティブAA（7560）が現在EIPではなくRIPとして推進されている理由でもある。
L2でL1では論争的なプロトコル更新を試すのは確かにメリットがあるが、RIPをEIPガバナンスプロセスへの代替と見なしてはならない。研究者は、双方の価値観がロードマップで完全に一致するまで、コア開発者との協力を続ける必要がある。
結論
3074/7702の出来事は、イーサリアムガバナンスの真の運営方式を明らかにした――コア開発者が推進するEIP／ACDプロセスという明示的なガバナンス権力の他に、研究者が推進するロードマップという隠れたガバナンス権力がある。これらの力がずれると、膠着と混乱が生じ、別の力――V神――が何らかの形で均衡を破らざるを得なくなる。
続いて、V神は「ビジョン」という独自の力を代表しており、これはあらゆるロードマップの正統性の基盤となる。V神を大企業のCTOに例え、彼の偽CTOとしての役割がイーサリアムの革新スピードを維持するために不可欠であり、イーサリアムが「フランケンシュタイン」的な縫い合わせ怪物に退化するのを防ぐと認めた。
最後に、イーサリアムガバナンスモデルを描写するVVRCモデルを提示した：価値観（コミュニティ）⇒ ビジョン（Vitalik）⇒ ロードマップ（研究者）⇒ クライアント（コア開発者）。そして、このモデルの「バグ」を修正するための様々な方法を提案した。
イーサリアムガバナンスは「機械を作る機械」である。イーサリアムを正しく機能させるためには、ガバナンスを適切に行わなければならない。3074のガバナンス事故は貴重なケーススタディを提供した。イーサリアムコミュニティがそこから有用な教訓を学び、将来のガバナンスプロセスを改善してくれることを願っている。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@godrealmx
