Vitalikとさまざまなロードマップがイーサリアムのガバナンスプロセスに与える影響について

オリジナル記事：ZeroDev CEO デレク・チャン

原文翻訳: Faust、Geekweb3

概要: この記事は、ヴィタリック・ブテリンが ERC-4337 と EIP-3074 の矛盾を解消するために EIP-7702 を提案したことを受けて、ZeroDev の CEO デレク・チャン氏がこの件について述べたものです。AA エコシステムのプロジェクト創設者の個人的な経験に基づいて、この記事では、イーサリアムの現在のガバナンス モデルと問題点を客観的に指摘し、次の点を指摘しています。

イーサリアムにおけるさまざまなガバナンス上の対立の 1 つは、研究者によって決定されたロードマップが Geth などのクライアント開発チームの見解と矛盾し、Vitalik が CTO と同様の立場で最終意思決定者になっていることです。

デレク氏はヴィタリック氏の役割を肯定的に評価した後、イーサリアムがガバナンスモデルにどのような改善を加えるべきかを指摘しました。これはイーサリアムコミュニティとビットコインコミュニティの両方にとって非常に参考になるものです。

内容: これまで Ethereum AA (アカウント抽象化) について知らなかった方のために、簡単に説明します。

数週間前、EIP-3074 提案が Ethereum コア開発者によって承認され、次のハードフォーク Pectra に含まれる予定です。この提案により、EVM に 2 つの新しいオペコードが導入され、Ethereum EOA アカウントにネイティブに近い AA エクスペリエンスが提供されます。

それ以来、ERC-4337 コミュニティの多くの人々、特に 4337 の提案者は、この提案が多くのセキュリティ リスクをもたらし、Ethereum AA ロードマップと互換性がないことを懸念し、EIP-3074 に強く反対してきました。Ethereum の以前のロードマップでは、ERC-4337 と類似の提案 7560 (nativeAA とも呼ばれる) が中心であると明確に述べられていました。

5 月初旬、Vitalik は EIP-3074 の代替として EIP-7702 を提案しました。これは 4337 と 3074 のバランスをとったもので、EOA ユーザーに AA エクスペリエンスを提供できる一方で、ERC-4337 との互換性が高く、AA Final Solution 7560 との互換性も高くなります。

現在、Ethereum コア開発者は EIP-7702 を検討しています。現在の予備的な議論の結果とコミュニティの感情から、EIP-7702 が上記の EIP-3074 に取って代わる可能性が高いことが示されています。

個人的には、この結果に非常に満足しています。EOA ユーザーは、まもなく ERC-4337 エコシステム内のさまざまな製品を体験し、AA のメリットのほとんどを享受できるようになります。しかし、過去数週間に多くの人が指摘したように、上記の結果を達成するにはもっと良い方法があると感じずにはいられません。より優れたガバナンス プロセスがあれば、多くのエネルギーを節約し、より早く望ましい結果を達成できたのではないかと思います。

この記事では、次のことをお伝えしたいと思います。

• ガバナンスプロセスで何が間違っていたのかを特定する

• イーサリアムのガバナンスを考えるためのメンタルモデルの提案

• 将来同様のガバナンスインシデントを回避するための改善提案を提供する

EIP-3074事件の要約と考察

上記の話は、以下の理由で多くの人を不幸にします。

EIP-3074 が承認されるまでには何年もかかりました。3074 が最終的に承認された後、Ethereum コア開発者は 4337 コミュニティからの強い反対に直面しました。

一方、ERC-4337の作者は、EIP-3074に対する懸念をイーサリアムコアチームに繰り返し表明してきましたが、効果はありませんでした。現在、イーサリアムは3074の承認を取り消し、別のEIP（7702）に置き換えることを計画しています。

上記のプロセスには、本質的に問題はありません。

• EIP に関する議論には数年かかる場合がありますが、これは正常なことです。

• EIP が承認された後に拒否されるのは普通のことです。

• EIP が承認された後でも、新たな問題が発見された場合は承認を取り消すことができます。

しかし、物事はもっとスムーズに進む可能性もありました。物事がこのように進んだと想像してみましょう。

3074 について議論する際、4337 コミュニティは Ethereum コア開発者と積極的に交流しました。この前提が正しい場合、考えられる結果は 2 つしかありません。

• 4337 コミュニティのフィードバックを考慮した後、提案 3074 は承認されます (変更される可能性もあります)。その場合、4337 コミュニティは 3074 を受け入れ、Ethereum コア チームは 3074 を撤回する必要がなくなります。

• あるいは、3074 が承認されることはなくても、4337 コミュニティと Ethereum コア チームが協力して、7702 と同じように、全員が満足できる提案を出すかもしれません。

全員の意見が聞き入れられ、劇的な逆転もありませんでした。それが良かったのですが、なぜそうしなかったのでしょうか?

何が悪かったのでしょうか?

全体のプロセスを振り返ってみると、両者は互いに非難し合っていた。

Ethereum コア開発者 (および EIP-3074 の作成者) は、これは 4337 人の支持者が、EIP が Geth などの Ethereum クライアント開発チームによって承認され実装される前に長い審議を経る All Core Developers (ACD) の議論プロセスに積極的に参加しなかったためであると考えています。

4337 の支持者は、3074 が承認されるまで待つのではなく、3074 の提案の検討中に意見を表明できたはずだと考える人もいます。結局のところ、ACD プロセス全体は十分に文書化されており、会議はすべての人に公開されており、Tim Beiko のような人々は各 ACD 会議の後に要約ツイートを積極的に投稿しています。では、4337 の支持者がこのトピックを非常に気にしているのであれば、なぜ関連する会議に積極的かつ迅速に参加しないのでしょうか。

一方、4337のコアメンバーは、ACD会議に出席し、3074にできる限り反対してきたが、イーサリアムコア開発者は耳を傾けなかったと指摘しました。4337コミュニティメンバーのほとんどは突然の出来事だと感じました。多くの人は3074はすでに死んでいると考えており、3074が承認される可能性があることさえ知りませんでした。

ACD 会議のプロセス全体が透明性に欠けており、イーサリアム コミュニティに真剣に取り組んでいるが、ACD アップデートの進捗状況をタイムリーに把握できない人々にとって不親切であると指摘する声が多くありました。また、ACD は積極的にステークホルダー (ここでは 4337 コミュニティを指します) からのフィードバックを求めるべきだと考える人もいます。

しかし、私はどちらの側も要点を理解していないと思います。この背後にはより深い問題があり、私たちがそれに対処するか、少なくとも認めない限り、双方がお互いを非難し合うという無意味な統治事故が今後も続くでしょう。

インシデントの根本原因への対処：ロードマップ

一般に信じられていることとは反対に、ガバナンス インシデントの根本的な原因は、ACD がイーサリアム プロトコル更新のガバナンス パワーの唯一のソースではなく、別のガバナンス パワー ソースに置き換えられていることにあります。ここでの問題は、他のガバナンス パワーがイーサリアムのコア問題 (AA やスケーラビリティなど) に対して ACD よりも大きな影響力を持っているにもかかわらず、それがほとんど認識されていないことです。

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

以下に指摘するように、3074-4337-7702 ガバナンス失敗事件全体は、Ethereum の既存のロードマップの力が ACD の力を上書きした事例です。ガバナンスについて話しているのであれば、目に見えない力が目に見える力を上書きしていることに気づいたとき、私たちはこれを非常に心配する必要があります。目に見えないものは説明が難しいことが多く、多くの人に気づかれないため、明らかにする必要があります。

ロードマップとは何ですか?

Ethereum コミュニティの誰もが、「ロードマップ」という用語を頻繁に目にしたことがあるはずです。たとえば、「ロールアップ中心のロードマップ」、「ETH 2.0 ロードマップ」、またはこの場合の「AA ロードマップ」などです。

私の主張を説明するために、コア開発者が Ethereum をスケーリングする方法を議論している ACD 会議のシーンを想像してみましょう。

• コア開発者のボブ: 私は、ブロック生成速度を 10 倍、ブロック サイズを 10 倍、手数料を 100 分の 1 に削減することを提案する EIP-1234 を支持します。

• 他のコア開発者: …あなたは頭がおかしいのですか?

考えてみましょう。なぜイーサリアムコアチームはボブの発言を拒否したのでしょうか? 彼は容量を拡張するための非常に合理的な方法を提案しただけです。Solana、Aptos、Sui、その他多くのパブリックチェーンはそれを実行し、高い TPS を達成しました。

その理由は、この架空のEIP-1234が、分散化のためには一般ユーザーが低コストでノードを実行できることが重要であると指摘しているイーサリアムのロールアップ中心の拡張ロードマップに違反しているためです。したがって、架空のEIP-1234はイーサリアムノードの実行コストを大幅に増加させるため、受け入れられません。

この例を使って、ACD ガバナンス プロセスに参加し、プロトコルの更新を決定するコア開発者は、私がロードマップと呼ぶ上位レベルの力によって導かれていることを説明したいと思います。現在、スケーリング ロードマップ、AA ロードマップ、MEV ロードマップなどがあり、これらが Ethereum の全体的なロードマップを構成しており、コア開発者はこれに基づいて決定を下す必要があります。

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

ロードマップはイーサリアムのガバナンス プロセスの正式な一部ではないため、コア チームがロードマップを順守する保証はほとんどありません。さらに、ロードマップを承認するための正式なプロセスがないため、すべてのロードマップが同じ正当性を持つわけではありません。イーサリアム ロードマップの背後にいる研究者は、正当性を獲得し、イーサリアム コア開発チームからのサポートを得るために、コア開発者とコミュニティにロードマップを宣伝するために懸命に努力する必要があります。

AA とアカウントの抽象化に関しては、Vitalik 自身が何度か 4337 中心の AA ロードマップを推進してきましたが、全体的には主に 4337 の背後にあるチーム、特に Yoav と Dror が、フォーラムや ACD 会議で 4337 中心の AA ロードマップを提唱してきました。

しかし、こうした努力にもかかわらず、一部のイーサリアムコア開発者は依然として4337を中心としたAAロードマップに強く反対していました。彼らは、7560（将来イーサリアムクライアントによって実装される4337のネイティブバージョン）は複雑すぎて、AAファイナリティの唯一の実行可能なソリューションではないと考えていました。最終的に、ACDは3074の提案を承認することを決定しましたが、4337チームは3074がAAエコシステム全体を分割すると信じていました。

3074 が承認された後、4337 コミュニティ全体が強く反応し、Ethereum コア開発者は 3074 の議論に再び取り組むことを余儀なくされました。その後、議論は膠着状態に陥り、4337 の作者も 3074 の作者もお互いを納得させることができず、Vitalik は土壇場で 3074 の代替として EIP-7702 を提案しました。これは 4337 を中心とした AA エンドゲームと明確に互換性があり、対立を解決して最終結果を AA ロードマップに適合させました。

Vitalik の役割: イーサリアムの事実上の CTO

Vitalik 氏は自身を研究者と称していますが、上記の話から、Vitalik 氏が他の研究者とはまったく異なる統治力を持っていることがはっきりとわかります。そこで疑問なのは、Vitalik 氏が Ethereum の統治においてどのような役割を果たしているかということです。

個人的には、ヴィタリックを非常に大きな会社のCTOと考えてもいいのではないかと思います（ちなみに、文脈上、イーサリアムの「会社」にはCEOがいないと仮定します）。

従業員が 50 人以上いるテクノロジー企業で働いたことがある人なら、CTO がすべての技術的決定に関与するのは不可能だということをご存知でしょう。企業が一定の規模に達すると、さまざまな技術的ソリューションの意思決定プロセスは分散化する必要があります。通常、企業の製品/ビジネスの各領域には専任チームがあり、このチームがソリューションの詳細を自由に決定できます。

さらに、CTO は必ずしもすべての（またはいずれかの）トピックの第一人者であるわけではありません。社内には特定の分野で CTO よりも優れたエンジニアがいる場合もあり、技術的な詳細を議論する際には、個々のエンジニアが最終決定を下すことがよくあります。

ただし、CTO は会社の技術的ビジョンを設定します。ビジョンの実行は開発者に委ねられます。

これは完璧な例えではありませんが、イーサリアム エコシステムにおける Vitalik の役割をうまく要約していると思います。Vitalik はすべての技術的決定に参加しているわけではありませんし、参加することもできません。彼はすべての分野のトップ エキスパートではありません。しかし、彼はイーサリアムのすべての主要ソリューション (スケーリング、AA、POS など) のロードマップに圧倒的な影響力を持っています。それは彼の技術的な専門知識だけでなく、ロードマップがイーサリアムのビジョン (彼のビジョン) と一致しているかどうかを最終的に判断する人物だからです。

成功する製品はすべてビジョンから始まります

Vitalik が Ethereum の CTO であるという私の意見が十分に物議を醸さなかったとしたら、最も物議を醸す部分は次のようになります。私たちは Vitalik を CTO として受け入れるべきです。

スタートアップの創業者として、私は成功する製品には必ず一貫した長期ビジョンが背景にあると信じています。そうです、Ethereum は実際のユーザーの実際の問題を解決する製品です。そして、一貫したビジョンは、スタートアップの創業者など、通常は 1 人の創業者など、少数の人々によって開発されなければなりません。

Ethereum の優れた点は、非常に多くのコンポーネントを持つ非常に複雑なシステムであるにもかかわらず、コンポーネントが完璧に組み合わさって、毎日数十億ドル相当の取引を決済する、円滑に機能する分散型コンピューターを形成していることです。

私たちが今日ここにいるのは、何らかの委員会の計画のおかげではなく、Vitalik の先見性のあるリーダーシップのおかげで、今日のような一貫性のある美しい Ethereum を構築できたからです。Ethereum は 2015 年に Vitalik が考案したもので、現在もその考えは変わりません。

もちろん、これは、イーサリアムを今日の姿にするのに大きく貢献した他の研究者やエンジニアの貢献を軽視するものではありません。しかし、これは矛盾ではありません。イーサリアムは、他の誰よりも桁違いに偉大なヴィタリックのビジョンの実現なのです。

正直、これについて文句を言うことができますか? イーサリアム エコシステムのオープン性、検閲耐性、イノベーションのスピードに惹かれていた一方で、Vitalik のビジョンから不満を言っていましたか? おそらく、そのように考えていなかったので文句を言わなかったのでしょうが、今はそう思っています。しかし、本当にその問題を気にしていますか?

分散化をどう解決するか?

しかし、分散化はどうなのかと疑問に思うかもしれません。1 人の人間が Ethereum に対して圧倒的な力を持っている場合、分散化されていると言えるのでしょうか。

この質問に答えるには、Vitalik が書いた分散化の意味に関するこの古典的な記事に戻る必要があります。この記事の重要な洞察は、分散化には 3 つのタイプがあるということです。

• アーキテクチャの分散化: システムが機能しなくなるまでに、いくつのノードが故障する必要があるでしょうか?

• 論理的な分散化: システムのさまざまなサブシステムは、システム全体が適切に機能しながら独立して進化できますか、それとも緊密に調整する必要がありますか?

• 政治的地方分権: 最終的に何人または何組織がシステムを管理するのか?

これらの定義に基づくと、Ethereum は明らかにアーキテクチャ的に分散化されており、そのコンポーネント (コンセンサス層と実行層など) 間の強い結合がないため、論理的にも分散化されていると言えます。

政治的分散化の点では、良いニュースは、Vitalik 氏でさえ、個人や組織が Ethereum を閉鎖することはできないということです。しかし、Vitalik 氏は Ethereum のビジョンとロードマップの開発に大きな役割を果たしたため、Ethereum は人々が考えるほど政治的に分散化されていないと主張する人もいるかもしれません。

しかし、イーサリアムが革新を続けていくためには、たとえ政治的な分散化を犠牲にすることになったとしても、ヴィタリック氏を事実上のCTOとして受け入れる必要があると私は思います。

もしイーサリアムが本当にビットコインのようなほぼ不変のブロックチェーンに固まれば、ヴィタリックは引退するかもしれない。しかし、その最終段階に到達する前に、すべての関係者が尊敬し、信頼でき、提案された技術的ソリューションが優れているかどうかだけでなく、これらの決定がイーサリアムのビジョンと一致しているかどうかに基づいて技術的な決定について判断できる権威を持つことが重要だ。

ヴィタリックがいなければ、起こり得る結果は 2 つしかなく、3074 にまつわる物語は、この 2 つの結果を鮮明に示しています。

• イーサリアムのガバナンスプロセスは、どちらの側も妥協する意思がなく、誰も前進できず、終わりのない膠着状態に陥る可能性がある。これは、ヴィタリック氏が介入する前に行き詰まりに陥った 3074 年の議論で実証されている。

• あるいは、イーサリアムは一貫性のない設計のフランケンシュタインになるかもしれません。前述の 3074 と 4337 は互いに譲歩せず、最終的に AA エコシステムは完全に 2 つの互換性のない並列空間に分割される可能性があります。

コミュニティの役割

上記の検討を経て、私たちは完全な Ethereum ガバナンス思考モデルの概要をほぼまとめましたが、これまでのところ、私たちの議論にはコミュニティという明らかな欠落があります。

Vitalik が Ethereum のビジョンを定義し、研究者がロードマップを定義し、コア開発者がロードマップを実装する場合、コミュニティの役割は何でしょうか? 何もないわけではないですよね?

幸いなことに、コミュニティは実際に最も重要な役割を果たしています。その理由は、ビジョンが存在する前に価値観があるからです。私たちがコミュニティとして団結するのは、特定の価値観を中心に団結しているからです。そして、Vitalik のビジョンは最終的にそれらの価値観と一致していなければなりません。そうでなければ、コミュニティの支持を失ってしまいます。

イーサリアム コミュニティの私たち全員は、誰もがアクセスでき、検閲に耐性があり、信頼できる分散型コンピューターを持つことが世界にとって良いことだと信じています。私たちはイーサリアムでの作業を通じてこれらの価値を日々支持し、肯定しており、そうすることで、Vitalik、研究者、コア開発者によって設定されたビジョン、ロードマップ、コードに正当性を与えています。

イーサリアムガバナンスのVVRCモデル

これがイーサリアムガバナンスの完全なメンタルモデルです。価値 ⇒ ビジョン ⇒ ロードマップ ⇒ クライアント、略して VVRC です。

• V==価値観==コミュニティ;

• V==ビジョン==ヴィタリック;

• R==ロードマップ==研究者;

• C==クライアント==コア開発者;

これらは一緒に次の機能を実行します。

• コミュニティは特定の価値観を中心に形成されます。

• ヴィタリックはこれらの価値観と一致するビジョンを表明しました。

• 研究者はビジョンに基づいてロードマップを作成します。

• コア開発者はロードマップに従ってクライアントを実装します。

もちろん、現実はどんな単純なモデルでも捉えられるよりもはるかに複雑です。実際、クライアント コードの変更を通じてあらゆる提案に実際に投票できるのは、Ethereum コア開発者だけです。Vitalik 氏や他の研究者はアドバイザーとしての役割しか果たしておらず、彼らの意見がコア開発者に受け入れられないこともあります。そのため、EIP-3074 は承認されました。

そうは言っても、VVRC モデルは、通常の状況下での Ethereum のガバナンス モデルの動作を適切に捉えており、EIP-3074 のようなことが再び発生しないようにプロセスを「デバッグ」する必要があると思います。

イーサリアムのガバナンスモデルを改善する方法

Ethereum のガバナンス プロセスがどのように機能するかについてのメンタル モデルができたので、これを改善するためのアイデアをいくつか紹介します。

• 検討中の EIP の議論の進捗状況の可視性を向上させる必要があります。コミュニティ全体が EIP が承認されたことに驚いてはいけませんし、3074 のような提案が突然承認されることも二度とあってはなりません。

EIP ウェブサイト上の現在の EIP ステータスは、ACD プロセスにおけるステータスを反映していません。コア開発者が承認に投票し、そもそも承認対象として検討されたという兆候がないにもかかわらず、3074 がまだレビュー中ステータスになっているのはそのためです。

理想的には、EIP が承認されそうになったら、Ethereum Foundation がソーシャル メディアで明確に発表し、コミュニティ内での認知度を高めます。

• コア開発者は、特定の EIP が下流のプロジェクトやユーザーに与える影響を過小評価することがあります。これは、コミュニティ 3074 と 4337 の場合に当てはまりました。ACD 会議は時間が限られており、タイム ゾーンを越えて調整する必要があるため、会議では「関係者」のみが発言できる場合が多くあります。

そうは言っても、特定の EIP 提案が可決された場合に、その下流への影響についてコミュニティのメンバーがコメントするための発言時間を時々割り当てることは理にかなっているでしょう。

研究者は、4337 の場合のように、自分の意見がコア開発者に受け入れられていないと感じた場合は、コミュニティのメンバーを巻き込んで主張を強化することができます。

• コア開発者と研究者は、権限レベルが異なっていても、お互いを Ethereum のガバナンス権限の一部として認識することが重要です。Ethereum クライアントに変更や更新を加えるコア開発者の権限は、プロトコル自体に変更を加えるための「投票」を行える唯一の権限です。研究者がロードマップの変更や解釈を行う権限は、研究者が積極的に自分のアイデアについて話したり書いたりすることで、より多くの一般の支持を得ることがよくあります。

これら 2 つの力が衝突すると、コア開発者は研究者の意見を単純に却下する傾向があるかもしれません。これは、コア開発者がチーム 4337 の異議を却下したときのケースと同じです。ただし、3074 が承認された後に発生した劇的な出来事が示すように、2 つの力が衝突すると不安定になるため、このような却下は衝突につながる可能性があります。

同様に、抵抗に直面すると、研究者はコア開発者とのコラボレーションを放棄したくなるかもしれません。これは、RIP プロセスが作成された理由の 1 つであり、ネイティブ AA (7560) が現在、EIP ではなく主に RIP として推進されている理由の 1 つであると私は考えています。

L1 では議論の的となっているプロトコル更新を L2 で実験することには実際的なメリットがありますが、RIP を EIP ガバナンス プロセスへの参加の代替として考えることはできません。研究者は、両者の価値観がロードマップと完全に一致するまで、コア開発者と協力し続けなければなりません。

結論は

3074/7702 の事件は、イーサリアムのガバナンスが実際にどのように機能するかを明らかにしました。コア開発者が主導する EIP/ACD プロセスの明示的なガバナンス力に加えて、研究者が主導するロードマップの暗黙的なガバナンス力もあります。これらの力が誤って配置されると、行き詰まりやむち打ちが発生し、何らかの方法でバランスを崩すために別の力、つまり Vitalik が必要になる場合があります。

次に、ヴィタリックは、あらゆるロードマップの正当性の基礎となる、イーサリアムの「ビジョン」というユニークな力を代表していると提案します。私たちはヴィタリックを大企業の CTO と比較し、イーサリアムがイノベーションのペースを維持するためには、疑似 CTO としての彼の役割が必要であり、それがイーサリアムが「フランケンシュタイン」のようなパッチワークの怪物に堕落するのを防ぐことができると認識しています。

最後に、私たちは、Ethereum ガバナンス モデルを記述する VVRC モデルを提案しました: 価値 (コミュニティ) ⇒ ビジョン (Vitalik) ⇒ ロードマップ (研究者) ⇒ クライアント (コア開発者)。そして、このモデルのバグを修正するさまざまな方法を提案しました。

イーサリアムのガバナンスは、マシンを作るマシンです。イーサリアムが適切に機能するには、合理的なガバナンスが必要です。したがって、3074 はガバナンス事故の貴重な事例を提供しており、イーサリアム コミュニティがそこからいくつかの有用な教訓を学び、将来のイーサリアムのガバナンス プロセスを改善できることを願っています。

オリジナルリンク

この記事はインターネットから引用したものです: Vitalik とさまざまなロードマップが Ethereum のガバナンス プロセスに与える影響について

関連：シグナルプラスマクロ分析（20240506）：リスク資産は再びゆっくりと上昇し始める可能性がある

今年初めて、雇用データは予想を下回り（予想外の増加はなく）、雇用者総数は+175,000人（前回の平均増加は約275,000人）となり、失業率も予想外に3.83%から3.87%に上昇しました。その他の高頻度雇用市場指標も減速の兆しを見せ始めており、最近のJOLTSレポートでは、失業者に対する求人数の比率が低下し、民間部門の雇用と退職は数年ぶりの低水準となっています。さらに、中小企業の雇用動向は大幅に弱まり、ISMとPMIの雇用構成はともに弱まり、雇用しているサービス企業と製造企業のシェアは景気後退期によく見られるレベルまで低下しています。先週の金曜日、非農業部門雇用者数は…