イーサリアムガバナンスの反省：なぜ皆がEIP-3074の事件に不満を感じているのか？

著者： imToken

この記事では、最近の EIP -3047 イベントに関する私の考えを述べます。内容のレビューを行ってくれた Vitalik と Yoav に感謝します。

このイベントについてよくわからない方のために、簡単に振り返ります：

最近、EIP -3074 提案がコア開発者の承認を得て、次回のイーサリアムのハードフォーク Pectra で実施される予定です。この提案の目的は、一般的なイーサリアムアカウント（EOA）ユーザーもアカウント抽象（Account Abstraction、一般的に AA と略される）の多くの利便性を享受できるようにすることです。

しかし、その後、ERC -4337 コミュニティ、特にこの提案の起草者たちは、EIP -3074 提案に対して強い反対を表明しました。その理由は、EIP -3047 が中央集権リスクを悪化させる可能性があり、イーサリアムのアカウント抽象のロードマップと一致しないためです。このロードマップの核心は EIP -4337 とその近親である EIP -7560（原生抽象アカウントとも呼ばれる）です。

先週、Vitalik は EIP -7702 を EIP -3074 の代替案として提案しました。これもまた 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 は数年かけてようやく承認を得ました。
• フィードバックの遅れ：コア開発者は、3074 が通過した後に初めて ERC -4337 コミュニティからの反対の声を広く聞くことになりました。
• 予警の無駄：4337 提案の著者は、3074 に対する懸念をコア開発者に何度も提起しましたが、効果は薄かったです。
• 改弦更張：現在、私たちは EIP -3074 を撤回し、EIP -7702 に取って代わる状況に直面しています。

客観的に見れば、上記の各段階は単独で見ても問題はありません：

• 長時間の議論は合理的です。
• 承認後に反対に直面するのも正常な現象です。
• 新たな問題が浮上した場合、調整や原決定の取り消しも論理的です。

しかし、私たちはおそらく、このプロセスがもっとスムーズに進むことができたことに同意するでしょう。もし事がこのように進展していたら、想像してみてください：

コア開発者が EIP -3074 を議論している間、ERC -4337 コミュニティが積極的に参加していたとしたら、結果は二つの可能性しかありません：

• あるいは、EIP -3074 が EIP -4337 コミュニティのフィードバックを考慮して承認され（修正が加えられる可能性もあります）、その場合、EIP -4337 コミュニティは EIP -3074 を支持し、3074 の決定を覆す必要はありません。
• あるいは、EIP -3074 は承認されなかったが、EIP -4337 コミュニティとコア開発者が協力して、皆が満足できる提案を進めることができたでしょう。まさに EIP -7702 のように。

すべての人の声が聞かれ、劇的な逆転もありませんでした。これは理想的な結末であるべきでしたが、なぜ実現しなかったのでしょうか？

問題はどこにあるのか？

全体のプロセスを振り返ると、双方が責任を指摘し合っています。

コア開発者（EIP -3074 の著者を含む）は、EIP -4337 チームがイーサリアムコア開発者会議（All Core Devs、一般的に ACD と略される）プロセスにもっと積極的に参加していれば、問題は発生しなかったと感じています。

このプロセスでは、提案は長時間議論され、最終的にクライアントチームによって受け入れられ、プロトコルに組み込まれます。彼らは、EIP -4337 チームがいつでも介入し、懸念を提起できたはずだと考えています。なぜなら、イーサリアムコア開発者会議のプロセスは公開されており、会議は外部に開かれているからです。Tim Beiko などの人々は、毎回の会議後に要約をツイートしています。もし EIP -4337 チームが本当に関心を持っていたのなら、なぜ時間をかけて参加しなかったのでしょうか？

逆に、アカウント抽象チーム（つまり EIP -4337 の著者たち）は、実際にはイーサリアムコア開発者会議に参加し、EIP -3074 に反対する機会を逃さなかったと強調していますが、コア開発者に採用されることはありませんでした。EIP -4337 コミュニティのメンバーは一般的に驚きを感じており、多くの人が EIP -3074 が放棄されたと思っていたり、EIP -3074 がまだ検討中であることすら知らなかったのです。

さらに、イーサリアムコア開発者会議のプロセスがあまりにも複雑で、フルタイムの仕事を持ち、すべての更新を追うことができない人々にとって参加が難しいとの意見もあります。また、重要な利害関係者（EIP -4337 コミュニティなど）の意見を積極的に求めることは、イーサリアムコア開発者会議の責任であるべきだと考える人もいます。

私の見解では、双方とも問題の核心を完全には把握していません。より深い問題が作用しており、これを解決するか、少なくとも直視しない限り、私たちはガバナンスの失敗を繰り返し、無意味な責任の押し付け合いに陥ることになります。

症結所在

ガバナンス失敗の真の症結は、皆がイーサリアムコア開発者会議を誤解していることにあります。イーサリアムコア開発者会議は、プロトコル更新の唯一の決定権を持つものではなく、このケースでは、別のガバナンス力が実際にイーサリアムコア開発者会議を超えて決定的な役割を果たしています。

問題は、この重要なガバナンス力が、アカウント抽象やスケーラビリティの問題など、イーサリアムの重要な事柄において大きな影響力を持っているにもかかわらず、正式に認識されることがほとんどないことです。

私はここでこの力を「ロードマップ」と呼びます。

簡単に言えば、EIP -3074 から EIP -7702 への一連の騒動は、「ロードマップ」の力がイーサリアムコア開発者会議の決定力を上回った典型的なケースです。

ガバナンスの観点から見ると、見えない力が見える力を覆い隠すとき、私たちは警戒すべきです。なぜなら、見えないということは監視されていないことを意味し、したがってこの見えない力を暴露し、検証する必要があるからです。

ロードマップとは何か？

イーサリアムのコミュニティでは、ロードマップという言葉はおそらく耳に馴染みがあるでしょう。たとえば、Rollup を中心としたロードマップ、ETH 2.0 ロードマップ、あるいは今回の議論の焦点であるアカウント抽象のロードマップなどです。

イーサリアムコア開発者会議で、皆がネットワークのスケールを拡大する方法について議論していると想像してみてください：

コア開発者の Bob が提案します：私は EIP -1234 を支持します。これはブロック時間を 10 倍に短縮し、ブロック容量を 10 倍に増やし、取引手数料を 100 倍に減らすことを主張しています。

他の開発者は答えます：あなたは本気ですか？

Bob の提案がすぐに否決される理由を考えてみてください。彼は確かに有効なスケーリングソリューションを提案しました。他のブロックチェーン、たとえば Solana などはこのように運用しており、効果を上げています。

その理由は、Bob の提案がイーサリアムが採用している Rollup を中心としたスケーリングロードマップに反しているからです。このロードマップは、ブロックチェーンの非中央集権的特性を維持するために、一般ユーザーがノードを簡単に運営できることが重要であると強調しています。したがって、Bob の提案はノードの運営難易度を大幅に引き上げるため、ロードマップに合致せず、当然排除されるのです。

この例を通じて示したいのは、イーサリアムコア開発者会議に参加し、プロトコル更新を担当するコア開発者たちは、実際には私が言うところのロードマップというより高い指導原則に従っているということです。ここにはさまざまなロードマップがあり、スケーリングロードマップ、アカウント抽象ロードマップ、MEV ロードマップなどがあり、これらはイーサリアムの全体的なロードマップを構成し、コア開発者が意思決定を行う際の根拠となっています。

コア開発者とロードマップが一致しない場合

ロードマップが正式なガバナンスの一部ではないため、コア開発者は常にそれに一致するとは限りません。特に、「ロードマップの承認」のような公式なプロセスがないため、すべてのロードマップが同じ認知度を持つわけではありません。これにより、ロードマップの背後にいる策定者がコア開発者や広範なコミュニティに積極的にプロモーションを行い、認知を得て、コア開発者の承認と支持を得る必要があります。

アカウント抽象の例を挙げると、Vitalik は EIP -4337 を中心としたロードマップを何度も称賛していますが、実際には主に EIP -4337 チーム、特に Yoav と Dror が、会議やオンラインフォーラム、イーサリアムコア開発者会議でこのロードマップを積極的に提唱しています。

しかし、それにもかかわらず、一部のコア開発者は EIP -4337 を中心としたロードマップに反対の意見を持っており、彼らは EIP -7560（EIP -4337 の原生バージョンで、将来的にクライアントが実装する必要がある）を過度に複雑であり、アカウント抽象の最終形態を実現する唯一の方法ではないと考えています。最終的に、EIP -4337 チームが EIP -3074 に反対したにもかかわらず、イーサリアムコア開発者会議は EIP -3074 を承認しました。

しかし、EIP -3074 が承認された後、EIP -4337 コミュニティの強い反対がコア開発者に EIP -3074 を再評価させました。双方は対立し続け、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 がビジョンを設定し、研究者がそれに基づいてロードマップを計画し、コア開発者がその後実施するなら、コミュニティはその中でどのような役割を果たすのでしょうか？確かに無視できるものではないでしょう？

実際、コミュニティは最も核心的な役割を果たしています。なぜなら、ビジョンが形成される前には、より基本的なものが存在するからです------価値観です。私たちは共通の価値観を共有することによってコミュニティを形成しており、これらの価値観は 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 s ウェブサイトに表示されている EIP の状態は、イーサリアムコア開発者会議の審議進捗と同期していないため、コア開発者が EIP -3074 に同意しても、その状態は「審査中」と表示され続けます。提案としては、イーサリアム財団のソーシャルメディアプラットフォームを通じて、コミュニティに採用される予定の EIP を事前に通知することが考えられます。

コミュニティの参加を強化する：コミュニティメンバーがイーサリアムコア開発者会議で EIP が下流プロジェクトに与える影響について議論する特定の時間を設けることで、EIP -3074 が EIP -4337 コミュニティに与えた予期しない影響を防ぐことができます。また、研究者がフィードバックがコア開発者に重視されていないと感じた場合（EIP -4337 チームが直面した困難のように）、コミュニティメンバーを議論に招待して自身の立場を強化することができます。

相互理解と継続的なコミュニケーション：コア開発者と研究者は相互に理解しなければなりません。彼らはガバナンスの重要な力であり、ただし焦点が異なります。コア開発者はクライアントを実装することで「実行権」を持ち、「投票権」を持つことに相当します。一方、研究者は自らのロードマップを積極的に共有し、議論することで、より広範なコミュニティの支持を得て「ロードマップの影響力」を形成します。

双方の意見が合わない場合、コア開発者は研究者の考えを直接覆す傾向があります。これは彼らが EIP -4337 チームに対して行ったことと同様です。しかし、こうした行動は反発を引き起こしやすく、双方の対立時に権力のバランスが崩れるため、EIP -3074 通過後に引き起こされた混乱がその例です。

逆に、研究者が抵抗に直面した場合、コア開発者との協力をやめることを選ぶかもしれません。これが RIP（Rollup Improvement Proposal）プロセスの誕生と、原生アカウント抽象（EIP -7560）が主に RIP として進められる理由の一つです。

RIP は L2 の実験において、L1 が直接採用しにくいプロトコル更新を助けることは有益ですが、EIP ガバナンスプロセスへの参加を代替するものではありません。研究者は、ロードマップが一致して認識されるまで、コア開発者とのコミュニケーションを続ける必要があります。

これらの措置を通じて、ガバナンスの透明性を高め、コミュニティの参加を強化し、コア開発者と研究者間の効果的な協力を促進し、将来のガバナンス問題の発生を減少させることができます。

まとめ

イーサリアムの EIP -3074/EIP -7702 イベントは、そのガバナンス構造の複雑性を明らかにしました。正式なガバナンスプロセス（コア開発者が EIP とイーサリアムコア開発者会議の提案に基づいて推進する）に加えて、研究者が提案する非公式なロードマップも大きな影響力を持っています。これら二つの力が調和しないと、決定の行き詰まりや突然の方向転換が生じる可能性があります。このとき、Vitalik の役割は特に重要であり、彼はイーサリアムのビジョンを把握することで各方面を調整することができます。これはプロジェクトの精神的なリーダーのような役割です。

私たちはイーサリアムのガバナンスを簡略化したモデルとして、コミュニティの価値観 → Vitalik のビジョン → 研究チームのロードマップ → コア開発者の実施（VVRC モデル）としました。この連鎖は、決定がどのように広範な理念から具体的な技術実現に細分化されるかを示しています。

ガバナンスの効率を改善するためには、実際の操作でこの理想モデルから逸脱する問題に対処する必要があります。良好なイーサリアムガバナンスはプロジェクトを前進させる核心的なメカニズムです。EIP -3074 の事件は一つの事例として、ガバナンスの弱点を暴露し、私たちに学びと改善の機会を提供しました。これにより、将来の類似の課題により良く対処し、イーサリアムの持続的な健康な発展を促進できるようにします。