イーサネット・ガバナンス再考：EIP-3074事件に憤るのはなぜか？

ソース: Bruh says

この記事は、最近のEIP-3047イベントについての私の考えをまとめたものです。

このイベントについてよくわからないという方のために、簡単にまとめてみました:

少し前に、EIP-3074の提案は、Etherの次のハードフォークであるPectraに実装されるよう、コア開発者たちによってGOサインが出されました。この提案の目的は、Account Abstraction（一般にAAと呼ばれる）の多くの利便性を、通常のEtherOne Account（EOA）ユーザーにも利用できるようにすることです。

しかしその後、ERC-4337コミュニティ、特にこの提案の起草者は、主にEIP-3047が中央集権化のリスクを悪化させる可能性があり、EIP-4337とその近縁のEIP-7560（ネイティブ・アブストラクション・アカウントとしても知られる）を中心とするEther Account Abstractionロードマップと矛盾しているという理由で、EIP-3074の提案に強い反対を表明しました。

先週、Vitalik氏はEIP-3074の代替としてEIP-7702を提案しました。これは、EOAユーザーにアカウント抽象化の利点をもたらすことも意図していますが、現在のEIP-4337標準により沿うように設計されており、最終形態であるEIP-7560へのスムーズな移行を提供します。

訳者注：ERC-4337とERC-7560は、どちらもイーサネットエコシステムにおけるアカウント抽象化関連の提案であり、ユーザーアカウントが管理され相互作用する方法を改善し、ユーザーエクスペリエンスとセキュリティを強化することを目的としています。

ERC-4337は、プロキシ契約を通じてユーザーがアカウントを管理できるようにし、ユーザーDAppとのやりとりの複雑さとリスクを軽減します。一方、ERC-7560は、ERC-4337などの提案のコンセプトをイーサネットの基礎レイヤーに直接組み込み、すべてのアカウントが自然に抽象化されるようにすることを目指しています。ERC-7560は、ERC-4337のような提案の概念をイーサネットの基礎レイヤーに直接組み込むことを目的としています。

ERC-4337は、ERC-7560への移行における重要なステップであり、両者を合わせて、イーサネットのアカウント抽象化ロードマップの中核を形成します。

現在、EIP-7702はコア開発者チームによって議論されており、いくつかの初期の兆候とコミュニティからのフィードバックは、EIP-7702がPectraハードフォークでEIP-3074に取って代わる可能性が高いことを示唆しています。

個人的には、この結果に非常に満足しています。EOAユーザーは、ERC-4337のために作成されたツールとインフラで、アカウント抽象化の利点のほとんどを享受しようとしています。

しかし、そこに至るプロセスは私にとっては困難であり、最善の道とは程遠かったと感じています。より良いプロセスがあれば、もっと早く、もっと大騒ぎせずに合意に達することができたと確信している。

この投稿では、

• プロセスの問題点を分析する

• イーサガバナンスを理解するための心構えを提案する

• どうすれば改善できるかを探り、将来この過ちを繰り返さないようにする。

なぜ人々は動揺しているのか？

• 承認までの長い道のり：EIP-3074は何年もかかってようやく承認された。

• 遅れたフィードバック: ERC-4337コミュニティからの反対は、3074が通過した後に初めてコア開発者から広く聞かれました。

• 警告なし: 4337提案の作者たちは、何度かコア開発者たちに3074についての懸念を伝えましたが、ほとんど効果はありませんでした。

• 方針転換: 今日、私たちはEIP-3074を撤回し、EIP-7702に置き換えることに直面しています。

 

• 長い議論は妥当だった。

• 承認後に反対意見が出るのは普通のことだ。

• また、新たな問題が浮上すれば、当初の決定を調整したり、取り消したりすることも論理的である。

 しかし、このプロセスがもっとスムーズであった可能性があることは、おそらく誰もが認めるところだろう。

 ERC-4337コミュニティは、EIP-3074に関するコア開発者の議論の間、積極的に関与していました。

• EIP-4337 コミュニティからのフィードバックを考慮した上で EIP-3074 が（可能な修正を加えて）承認されるか、EIP-4337 コミュニティが EIP-3074 を支持し、3074 の決定を覆す必要がなくなるかのどちらかです。決定を覆す必要はない。

• あるいは、EIP-3074は承認されないが、EIP-7702の場合のように、EIP-4337コミュニティはコア開発者と協力して、誰もが満足する提案を進める。

全員の声が届き、劇的な逆転はありませんでした。これは理想的な結末だったはずだが、なぜ実現しなかったのだろうか？

何が問題だったのか？

すべてのプロセスをさかのぼると、どちらの側にも非難がある。

コア開発者 (EIP-3074の作者を含む) は、EIP-4337チームがAll Core Devs (一般にACDと呼ばれる) プロセスにもっと積極的に関与していれば、問題は起こらなかっただろうと感じています。

このプロセスでは、提案は長時間議論され、最終的にはクライアントチームによって受け入れられ、契約に組み込まれる。彼らは、EIP-3074が承認されるまで待たずとも、EIP-4337チームはどの時点でも懸念を表明することができたと主張している。結局のところ、EtherCore開発者会議のプロセスはオープンで透明性が高く、セッションは一般に公開されており、ティム・ベイコのような人々は各セッションの後に要約をツイートしている。もしEIP-4337チームが本当にそんなに気にしていたのなら、なぜ時間を投資して参加しなかったのでしょうか？

その代わりに、Account Abstractionチーム（つまりEIP-4337の作者）は、実際にEtherCore開発者会議に出席し、EIP-3074に異議を唱えるためにあらゆる機会を利用したが、コア開発者に取り上げられなかっただけだと強調しています。そして、EIP-4337コミュニティのメンバーは、多くの人がEIP-3074が放棄されたと考え、EIP-3074がまだ検討中であることさえ知らなかったことに、一般的に驚いていました。

さらに、イーサネットコア開発者会議のプロセスは複雑すぎて、フルタイムの仕事を持ち、アップデートのすべてのステップについていけない人にとっては参加するのが難しいというコメントもありました。また、EIP-4337コミュニティのような主要な利害関係者から積極的に意見を求めることは、EtherCore開発者会議の責任であるとも感じられました。

私の意見では、どちらの側も問題の核心にはまったく触れていません。私たちがそれに対処しない限り、あるいは少なくともそれに立ち向かわない限り、私たちはガバナンスの失敗に繰り返し遭遇し、お互いに無意味な指弾をすることになるのです。

核心

ガバナンスの失敗の本当の核心は、EtherCore開発者会議に対する広範な誤解にあります。EtherCore開発者会議は、実際にはプロトコル更新のための唯一の意思決定力ではなく、今回のケースでは、実際には別のガバナンス力がEtherCore開発者会議を覆し、決定的な役割を果たしました。

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

私はここで、この力を「ロードマップ」と呼んでいる。 

要するに、3074から7702への大騒ぎは、「ロードマップ」の力がEtherCore開発者会議での意思決定の力を凌駕した典型的なケースです。

ガバナンスの観点からは、目に見えない力が目に見える力を凌駕するとき、私たちは警告を発するべきです。

ロードマップとは何か？

ロードマップという用語は、ロールアップ中心のロードマップ、ETH 2.0のロードマップ、またはこの議論の焦点であるアカウント抽象化のロードマップなど、イーサリアム界隈ではおなじみでしょう。 

イーサリアムのコア開発者ミーティングを想像してみてください。そこでは、ネットワークをスケールさせる方法について議論されています。

他の開発者はこう答えました。

ボブの提案がすぐに却下された理由を考えてみよう。彼は効果的なスケーリングスキームを提案しましたが、それはSolanaのような他のパブリックチェーンが行っていることであり、機能しています。 

その理由は、ボブの提案が、イーサリアムが遵守しているロールアップ中心のスケーリングロードマップに反しているからです。このロードマップは、ブロックチェーンの非中央集権的な性質を維持するためには、一般ユーザーが簡単にノードを実行できることが不可欠であることを強調しています。したがって、ボブの提案は、ノードの実行の難易度を著しく高めるものであるため、ロードマップに沿ったものではなく、当然除外される。 

この例で、EtherCore開発者会議の会議に参加し、プロトコルのアップデートを担当するコア開発者が、実際にはより高い指針、私がロードマップと呼ぶものに従っていることを示したいと思います。ここには、スケーリングロードマップ、アカウント抽象化ロードマップ、MEVロードマップなど、さまざまなロードマップがあり、それらが一体となってEtherCorpの全体的なロードマップを形成しており、コア開発者が意思決定を行う際の基礎となっています。

コア開発者がロードマップと連携していない場合

ロードマップは正式なガバナンスの一部ではないため、コア開発者が常に連携しているとは限りません。特に、「ロードマップを承認する」というような公式のプロセスがないため、すべてのロードマップが同じレベルの認識を享受できるわけではありません。そのため、ロードマップの立案者は、コア開発者やより広範なコミュニティにロードマップを積極的に宣伝し、認知を獲得し、ひいてはコア開発者からの賛同と支持を得る必要がある。 

アカウントの抽象化を例にとると、Vitalikは何度もEIP-4337中心のロードマップを推進してきましたが、実際には主にEIP-4337チーム、特にYoavとDrorがカンファレンスやオンラインフォーラム、EtherCore開発者カンファレンスでこのロードマップを積極的に提唱してきました。 

しかし、それでもコア開発者の一部はEIP-4337中心のロードマップに反対し続けました。EIP-7560（つまり、将来のクライアントによって実装される必要があるEIP-4337のネイティブバージョン）は複雑すぎて、アカウントの抽象化の最終形を達成する唯一の方法ではないと主張しました。最終的に、EtherCore開発者会議はEIP-3074を承認しましたが、EIP-4337チームは、EIP-3074は別の、より中央集権的なアカウント抽象化技術スタックを導入することで、抽象化エコシステムを分裂させるだろうと反対しました。

しかし、EIP-3074の承認後、EIP-4337コミュニティ全体からの強い反対により、コアはEIP-3074を再検討することになりました。この論争は、重大な局面でVitalik氏がEIP-3074の代替案としてEIP-7702を提案するまで続きました。EIP-7702はEIP-4337を中心としたアカウント抽象化スキームを明確にサポートしており、これにより状況はアカウント抽象化ロードマップに従う方向に進みました。

ヴィタリックの役割

ヴィタリックは自分自身を研究者だと考えていますが、この事件から、彼がイーサのガバナンスにおいて明確でユニークな役割を担っていることは明らかです。イーサのガバナンスにおけるヴィタリックの役割とは一体何なのでしょうか？ 

私たちは、ヴィタリック氏を大企業のCTOと考えることができます。 

ある程度の規模、例えば50人以上の技術系企業で働いたことがある人なら、CTOがすべての技術的決定に関与できるわけがないことを理解できるでしょう。企業が成長するにつれて、技術的な決定は自然に分散化され、各製品分野のサブチームは、一般的に実装の詳細について自律性を持つようになります。

また、CTOが必ずしもすべての分野のトップエキスパートであるとは限りません。ある分野ではCTOよりも優れたエンジニアが社内にいるかもしれません。そのため、技術的な議論で最終的な決定を下すのはエンジニアであることが多い。 

しかし、CTOは会社の技術ビジョンを策定する責任があり、実行は開発者に任されている。 

この例えは完璧ではありませんが、イーサリアムのエコシステムにおけるヴィタリック氏の役割をかなり正確に描写しています。 

ヴィタリックはすべての技術的な決定に関与しているわけではありません。しかし、彼はイーサのすべての重要な側面（スケーリング、アカウントの抽象化、株式証明など）のロードマップに大きな影響力を持っています。それは、彼の技術的な知識だけでなく、ロードマップがイーサのビジョン（これは彼自身のビジョンです）と互換性があるかどうかを最終的に判断することができるからです。- と一致する。

成功する製品の原動力はビジョン

起業家として、私は成功する製品には明確なビジョンがあると信じています。そして、そのようなビジョンを確立するためには、多くの場合、一握りの人々、通常は創業チーム、そして多くの場合、たった一人の重要な創業者が必要なのです。

イーサの素晴らしさは、このような複雑で多面的なシステムが協調して機能し、日々巨額の価値を生み出す分散型コンピューターになり得ることです。これは委員会スタイルの意思決定によって達成されたわけではありませんが、ヴィタリックが彼のビジョンで道を切り開いたおかげで、今日の協調的で効率的なイーサがあるのです。2015年の構想から今日まで、イーサはヴィタリックの知恵を体現してきた。

これは、イーサの実現に貢献した他の研究者やエンジニアの貢献を否定するものではありません。しかし同時に、イーサがヴィタリックのビジョンの究極の表現であり、他のいかなる個人の影響力もはるかに超えていることは否定できない。 

正直なところ、そのオープンさ、検閲への抵抗、創造的なエネルギーに惹かれてイーサに参加したとき、それがすべてヴィタリックのオリジナルのビジョンから始まったことを気にしていましたか？ 

もしかしたら、以前は気にしていなかったかもしれませんが、一度理解したら、本当に気になりましたか？

Etherは明確なビジョンから生まれ、そのビジョンを実現しながら成長し続けている。

分散化についてはどうですか？

一人の人間がイーサに対して大きな影響力を持っているのに、どうしてイーサが分散型だと言えるのかと聞かれるかもしれません。

この質問に答えるために、Vitalikが書いた分散化の複数の意味を示した古典的な記事を参照することができます。

1. Decentralisation in architecture: How many nodes fail before the system stops working?

2. 論理的分散化：全体的な機能に影響を与えることなく、システムの一部を独立して進化させることができるか？

3. 政治的な分散化：何人の人や団体がシステムをコントロールするか？ 

エーテルは、多数のノードに分散でき、異なるコンポーネント（コンセンサスメカニズムや実行レイヤーなど）が比較的独立して進化できるため、アーキテクチャ的にも論理的にも間違いなく分散化されています。 

政治的分散化に関しては、Vitalik氏を含め、単一の団体がEtherをシャットダウンすることはできないという良いニュースもありますが、Etherのビジョンとロードマップの設定においてVitalik氏が突出しているということは、政治的分散化に関して妥協がありそうだということは否定できません。 

私の考えでは、イーサがイノベーションを続けるためには、政治的分散化を多少減らしてでも、実質的にCTOとしてのヴィタリックの役割を受け入れるべきだと思います。EtherがBitcoinのように安定して不変であるという点まで成熟するまでは、技術的なメリットに基づいて決定を下すだけでなく、その決定がEtherの長期的なビジョンに沿ったものであることを保証する、広く尊敬される権威が必要なのです。

Vitalik氏がこの役割を果たさなければ、Etherは2つのシナリオに直面する可能性があります。

1. Decision-making stalemate（意思決定の行き詰まり）：すべての関係者が妥協しようとせず、プロジェクトは行き詰まりました。EIP-3074の議論のように、ヴィタリクが介入して行き詰まりを打破するまで。

3. 設計の混乱：EIP-3074がEIP-4337と並列で互換性がなかったときのように、システムは調整されていないパッチワークになりかねない。

ですから、イーサがまだ急速に進化している今、分散型で方向性のあるエコシステムを維持するためには、ヴィタリック氏のリーダーシップが不可欠なのです。

コミュニティの重要性

この時点で、私たちはイーサのガバナンスを理解するための包括的な枠組みをほぼ構築しましたが、これまでの議論から取り残されている重要な部分があります。

ヴィタリック氏がビジョンを設定し、研究者たちがそれに従ってロードマップを計画し、コア開発者たちがそれを実行するとしたら、コミュニティはどのような役割を果たすのでしょうか？きっと取るに足らないことではないのでしょうか？

実際、コミュニティは最も中心的な役割を果たしている。なぜなら、ビジョンが形になる前に、もっと根本的なもの、つまり価値観があるからです。私たちがコミュニティとして集まっているのは、ある価値観を共有しているからであり、その価値観こそがヴィタリックのビジョンの礎であり、一致しなければコミュニティは存在しないのだ。

おそらく育った環境の結果として、あるいは過去の経験に触発されて、イーサリアムコミュニティの誰もが、ある時点で、すべての人がアクセス可能で、検閲されていない、真に分散化されたコンピュータを構築することの世界にとっての価値に気づいています。私たちがイーサで毎日行っている作業は、これらの価値観の実践であり肯定であり、これらの行動を通じて、私たちはヴィタリックや研究者、コア開発者が考え出したビジョン、ロードマップ、コードに生命と正当性を与えているのです。

イーサネット ガバナンスの単純化モデル: VVRC フレームワーク

イーサネットのガバナンスを、よく設計された機械として想像してみてください。VVRCモデルです。

1. Values: すべてはイーサリアムコミュニティが共有する一連の基本原則と信念から始まります

2. Vision: 創始者であるVitalikは、コミュニティの価値観に基づいてイーサリアムの将来のビジョンを描きます。将来のビジョン。

3. ロードマップ: 明確なビジョンを持って、研究チームはその夢を実現するための具体的なステップの作成に着手します。目標に向かって一歩一歩進む技術的な道筋を考案するのです。

4. クライアント：最後に、開発者のコアチームがロードマップに取り組み、コードを書き、クライアントソフトウェアを保守して、すべての技術計画がユーザーと開発者が実際に使用できる現実になるようにします。

このプロセスはスムーズに聞こえますが、実際はもっと複雑です。たとえば、コア開発者は実際のソフトウェア実装に責任があるため、実際に最終的な決定を下し、Vitalikと他の仲間は提案をする可能性が高く、EIP-3074の事件が示すように、時には受け入れられないかもしれません。

全体として、VVRCモデルは、イーサネットが理想的な状況でどのようにガバナンスを進めることができるかを理解するのに役立ちますが、EIP-3074のような問題を二度と起こさないために、継続的にプロセスを微調整し、洗練させる必要があることも思い出させてくれます。

イーサネット ガバナンスを改善する方法

イーサネットのガバナンス構造を最適化し、EIP-3074/EIP-7702事件の再発を確実に回避するために、以下にいくつかの改善案を示します。

EIPの透明性を高める: EIP-3074の突然の受け入れのような驚きを避けるために、検討中のEIPがコミュニティに対してよりオープンで透明であるようにします。実際、EIPsウェブサイトに表示されるEIPのステータスはEtherCore開発者会議の進捗と同期していないため、コア開発者がEIP-3074に合意したにもかかわらず、そのステータスは「検討中」と表示されたままです。

両者の間に意見の相違がある場合、コア開発者は、EIP-4337チームに対して行ったように、研究者のアイデアを単に覆すことに傾くかもしれません。しかし、これは反発を招きやすい。EIP-3074の可決によって引き起こされた混乱に代表されるように、両者が衝突するとパワーバランスが崩れかねないからだ。

その代わりに、研究者は、抵抗に遭遇したときに、コア開発者との共同作業をやめることを選ぶかもしれません。これは、RIP (Rollup Improvement Proposal) プロセスが生まれ、Native Accounts Abstraction (EIP-7560) が主にEIPではなくRIPとして推進された理由の1つです。

RIPは、L1が直接採用することが難しいプロトコル更新をL2が実験するのに役立つ一方で、EIPガバナンスプロセスに参加する代わりにはなりません。研究者は、ロードマップが合意されるまで、コア開発者とコミュニケーションを取り続けなければなりません。

これらの手段を通じて、ガバナンスの透明性を向上させ、コミュニティへの参加を強化し、コア開発者と研究者間の効果的な協力を促進し、将来のガバナンス問題の可能性を減らすことが可能です。

サマリー

EthernetのEIP-3074/EIP-7702のイベントは、そのガバナンス構造の複雑さを明らかにしました。も大きな影響力を持っています。この2つの力が協調していない場合、行き詰まった意思決定や突然の逆転につながる可能性がありますEtherのビジョンを把握し、プロジェクトの精神的リーダーのようにすべての関係者を調整することができるVitalikの役割は特に重要です。

私たちはイーサのガバナンスを、コミュニティの価値観→ヴィタリックのビジョン→研究チームのロードマップ→コア開発者による実装（VVRCモデル）というモデルとして単純化しました。このチェーンは、意思決定が幅広いアイデアから具体的な技術的実装まで、どのように段階的に洗練されていくかを示しています。

ガバナンスの効率を向上させるためには、この理想的なモデルからの実際の逸脱を修正する必要があります。結局のところ、優れたイーサガバナンスはプロジェクトを前進させる核となるメカニズムであり、EIP-3074事件はガバナンスの弱点を露呈させる例として機能し、私たちに学習と改善の機会を提供することで、将来的に同様の課題にうまく対処できるようにし、イーサの継続的な健全な発展を促進します。