原題「Reflections on Ethereum Governance Following the 3074 Saga」を転送します。

概要:この記事は、ERC-4337とEIP-3074の矛盾のバランスをとるためにVが提案したEIP-7702に対するZeroDevのCEOであるDerek Chiang氏の声明である。AAエコシステム内のプロジェクト創設者の視点から書かれたこの本は、イーサリアムの現在のガバナンスモデルとその問題点を客観的に浮き彫りにしています。Derek氏は簡潔に指摘している。

イーサリアムのガバナンス上の対立の1つは、研究者が決定したロードマップと、ゲスのようなクライアント開発チームの視点との不一致にあります。ヴィタリックはCTOのような役割を担い、最終的に決定的な要因となる。

ヴィタリックの役割を確認した後、デレクはイーサリアムがガバナンスモデルに加えるべき改善を概説し、イーサリアムとビットコインの両方のコミュニティに貴重な洞察を提供します。

テキスト：

イーサリアムのアカウント抽象化(AA)をめぐる出来事を知らなかった方のために、簡単におさらいします。 数週間前、EIP-3074の提案がイーサリアムのコア開発者によって承認され、次のハードフォークである「Pectra」に含まれることになりました。この提案では、イーサリアム仮想マシン(EVM)に2つの新しいオペコードを導入し、イーサリアムの外部所有アカウント(EOA)がほぼネイティブなAA体験を行えるようにします。それ以来、ERC-4337コミュニティの多くのメンバー、特にその支持者は、潜在的なセキュリティリスクとイーサリアムのAAロードマップとの非互換性に関する懸念を理由に、EIP-3074に強く反対しています。イーサリアムの以前のロードマップでは、ERC-4337や7560(「nativeAA」とも呼ばれる)などの同様の提案が中心でした。5月初旬、ヴィタリックはEIP-3074の代替としてEIP-7702を提案し、4337と3074のバランスを取り、ERC-4337との互換性と「最終的なAAソリューション」である7560との互換性をある程度維持しながら、EOAユーザーにAA体験を提供した。現在、イーサリアムのコア開発者は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コミュニティはイーサリアムのコア開発者と積極的に関わったと想像してみましょう。この前提が成り立つ場合、考えられる結果は2つしかありません。

• 4337 コミュニティからのフィードバックを検討した後、3074 提案は承認されます (場合によっては変更されます)。この場合、4337コミュニティは3074を受け入れ、イーサリアムのコアチームは3074を取り消す必要はありません。
• あるいは、3074は決して承認されませんが、4337コミュニティとイーサリアムのコアチームは共同で、7702と同様に、誰もが満足するソリューションを提案しています。全員の声が届き、劇的な逆転はありません。これは理想的だったはずなのに、なぜ実現しなかったのでしょうか?

何がいけなかったのでしょうか?

全体を振り返ってみると、イベントの双方がお互いを非難し合っています。イーサリアムのコア開発者(およびEIP-3074の作者)は、All Core Developers(ACD)の議論プロセスに積極的に参加しなかったため、「4337人のサポーター」のせいだと考えています。このプロセスでは、EIPは長い審議を経て、最終的にGethのようなイーサリアムのクライアント開発チームによって承認され、実装される必要があります。EIP-3074が検討されていた時期には、「4337人の支持者」が参加し、すでに承認された後に批判するのではなく、意見を述べることができたと主張する人もいます。結局のところ、ACDプロセス全体が透明であり、会議は誰にでも開かれており、Tim Beikoのような個人は、各ACD会議の後に一貫して要約ツイートを公開しています。では、「4337人のサポーター」がこれほどこの話題に関心があるのなら、なぜ彼らは積極的かつ迅速に関連会議に参加しなかったのでしょうか?

一方、4337のコアメンバーはACDのミーティングに参加し、3074に可能な限り反対していることを示していますが、イーサリアムのコア開発者は耳を傾けていません。4337人のコミュニティメンバーに関しては、多くの人が不意打ちを食らったと感じていました - 多くの人は3074はすでに死んでいると考えており、中には3074が承認される可能性が高いことに気づいていない人もいました。ACDミーティングのプロセス全体が不透明で、イーサリアムコミュニティで「真剣」であるが、ACDの更新にリアルタイムで追いつくことができない人には友好的ではないと多くの人が指摘しています。また、ACDは利害関係者(ここでは4337コミュニティを参照)からのフィードバックを積極的に求めるべきだと考える人もいます。

しかし、どちらの側も頭に釘を打ったことはないと思います。その背後にはもっと深い問題があり、この問題に取り組むか、少なくとも認めない限り、ガバナンスの事故に陥り続け、その後、双方から矛盾した非難が続き、最終的には無意味になります。

ガバナンス事故の根本原因:ロードマップ

一般に信じられていることとは反対に、ガバナンス事故の根本的な原因は、ACDがイーサリアムプロトコルの更新に関する唯一のガバナンス機関ではないという事実にあります。これは、別のガバナンス機関に置き換えられました。ここで問題なのは、イーサリアムのコアな問題(AAやスケーラビリティなど)に対してACDよりも大きな影響力を持っているにもかかわらず、この他のガバナンス権限がほとんど認められていないことです。この記事では、このようなパワーを「ロードマップ」と呼ぶことにします。以下で指摘するように、「3074-4337-7702」ガバナンス障害イベント全体は、イーサリアムの既存のロードマップパワーがACDパワーを上回ったケースです。ガバナンスについて言えば、無形の力が有形の力を圧倒していることに気づいたとき、無形のものは説明が難しく、多くの人に簡単には気づかれないことが多いため、露出しなければならないため、非常に懸念する必要があります。

ロードマップとは?

イーサリアムコミュニティの人なら誰でも、「ETH2.0ロードマップ」やこのイベントに関連する「AAロードマップ」の文脈で、「ロードマップ」という言葉をよく耳にしたことがあるはずです。

私の言いたいことを説明するために、ACDミーティングでコア開発者がイーサリアムのスケーリング方法について話し合っているシーンを想像してみましょう。

• コア開発者のボブ:ブロック速度を10倍に、ブロックサイズを10倍に増やし、手数料を100倍に減らすことを提案するEIP-1234を支持します。
• その他のコア開発者:...気は確かですか。

これについて考えてみましょう。なぜイーサリアムのコアチームはボブの提案を拒否するのでしょうか?彼は、Solana、Aptos、Suiなどの多くのパブリックチェーンが行っているように、一見合理的なスケーリング方法を提案しているだけで、高いTPSを達成しています。その理由は、この架空のEIP-1234がイーサリアムの「ロールアップ中心」のスケーリングロードマップと矛盾しているためです。このロードマップでは、分散化のためには、一般ユーザーが低コストでノードを実行できなければならないことを強調しています。したがって、架空のEIP-1234は、イーサリアムノードの運用コストを大幅に増加させるため、受け入れられる可能性は低いです。この例を使って、ACDのガバナンスプロセスに参加し、プロトコルの更新を決定するコア開発者は、私が「ロードマップ」と呼ぶ高レベルの力によって導かれていることを説明しました。現在、イーサリアムのロードマップを中心に、「スケーリングロードマップ」「AAロードマップ」「MEVロードマップ」などがあります。これらが集合的にイーサリアムの全体的なロードマップを形成し、コア開発者はこの基盤に基づいて決定を下す必要があります。

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

ロードマップはイーサリアムのガバナンスプロセスの正式な部分ではないため、コアチームがロードマップを遵守するという保証がないことがよくあります。さらに、ロードマップを「承認」するための正式なプロセスがないため、すべてのロードマップが同じレベルの「正統性」を持っているわけではありません。イーサリアムのロードマップの背後にいる研究者は、イーサリアムのコア開発チームから「正統派」とサポートを得るために、コア開発者やコミュニティにロードマップを宣伝するために懸命に努力しなければなりません。AAとアカウントの抽象化に関して、Vitalik自身は4337中心のAAロードマップを繰り返し提唱してきましたが、全体としては、フォーラムやACD会議で4337中心のAAロードマップを提唱しているのは、主に4337の背後にあるチーム、特にYoavとDrorです。

しかし、これらの努力にもかかわらず、一部のイーサリアムコア開発者は、4337中心のAAロードマップに強く反対しています。彼らは、7560(将来イーサリアムクライアントによって実装されるネイティブ4337バージョン)は複雑すぎて、「AAエンドゲーム」の唯一の実行可能なソリューションではないと考えています。最終的に、ACDは、3074がAAエコシステム全体を崩壊させると信じていた4337チームの反対にもかかわらず、3074の提案を承認することを決定しました。3074が承認された後、4337コミュニティ全体が強く反応し、イーサリアムのコア開発者は3074に関する議論に再び参加することを余儀なくされました。その後、議論は膠着状態に陥り、4337と3074の著者はお互いを説得することができなかった。ヴィタリックは土壇場で3074の代替案としてEIP-7702を提案し、4337中心の「AAエンドゲーム」に明示的に対応することで、対立を解決し、最終的な結果をAAのロードマップに合わせました。

ヴィタリックの役割:イーサリアムの事実上のCTO

ヴィタリックは自らを研究者と名乗っているが、上記の話は、ヴィタリックが他の研究者とは異なる統治権を持っていることを明確に示している。そこで、ヴィタリックはイーサリアムのガバナンスにおいてどのような役割を果たしているのか、という疑問が湧いてきます。個人的には、ヴィタリック氏を大企業の事実上のCTOとみなすことは不適切ではないかと考えています(ちなみに、イーサリアムをCEOのいない「会社」と想定して、現実に合わせます)。従業員数が50人を超えるテクノロジー企業で働いたことがある人なら、CTOがすべての技術的な決定に関与できるわけではないことをご存知でしょう。会社が成長するにつれて、さまざまな技術ソリューションの意思決定プロセスは必然的に分散化されます。通常、会社の製品/ビジネスの各領域には専任のチームがあり、多くの場合、ソリューションの詳細を決定する自律性があります。さらに、CTOは、すべての(または任意の)トピックのトップエキスパートではない可能性があります。社内にはCTOよりも特定の分野に長けているエンジニアがいる場合もあるので、ソリューションの技術的な詳細についての議論では、最終的な決定を下すのは個々のエンジニアであることが多いです。ただし、CTOは会社の技術的ビジョンを設定します。ビジョンの実行は開発者に委ねられています。これは完璧な例えではありませんが、イーサリアムのエコシステムにおけるヴィタリックの役割を合理的に要約していると思います。ヴィタリックは、すべての技術的な決定に関与しているわけではありません。また、彼はすべての分野でトップの専門家というわけでもありません。しかし、彼はすべての重要なイーサリアムソリューション(スケーリング、AA、POSなど)のロードマップの設定において圧倒的な影響力を持っており、それは彼の技術的な専門知識だけでなく、ロードマップがイーサリアムのビジョン(彼のビジョン)と一致しているかどうかの最終的な判断者であるからです。

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

ヴィタリックをイーサリアムのCTOとして考えるだけでは物議を醸さないのであれば、最も物議を醸すのは、ヴィタリックをCTOとして受け入れるべきだということです。スタートアップの創業者として、私は成功するすべての製品には一貫した長期ビジョンが必要だと考えています - そう、イーサリアムは実際のユーザーの実際の問題を解決するので「製品」でもあります。首尾一貫したビジョンは、スタートアップの創業者など、数人の人間によって作られなければならず、通常、創業者は1人しかいません。イーサリアムの優れた点は、非常に多くのコンポーネントを持つ非常に複雑なシステムであるにもかかわらず、これらすべてのコンポーネントがシームレスに組み合わさって、適切に機能する分散型コンピューターを形成し、毎日数十億ドル相当のトランザクションを決済することです。私たちがここまで来られたのは、委員会の設計スキームではなく、ヴィタリックが先見の明と洞察力を持って積極的にリーダーシップを発揮し、今日の首尾一貫した優雅なイーサリアムを構築することができたからです。イーサリアムはヴィタリックが2015年に提案したアイデアであり、それは今も変わりません。もちろん、これは他の研究者やエンジニアの貢献を損なうものではなく、彼らは今日のイーサリアムの成果の大部分を占めています。しかし、イーサリアムはヴィタリックのビジョンの実現であり、他の誰のビジョンよりも桁違いに大きいため、これは矛盾していません。正直なところ、これについて文句を言えますか?イーサリアムエコシステムのオープン性、検閲への耐性、イノベーションのスピードに惹かれたとき、それがヴィタリックのビジョンに由来すると不満を言ったことはありませんか?もしかしたら、あなたはこのように考えていなかったので、文句を言わなかったかもしれませんが、今、あなたはこの問題を気にしますか?

地方分権化にどう取り組むか?

しかし、地方分権についてはどうでしょうか?一人の人間がイーサリアムに対してこれほど圧倒的な権力を握っているとしたら、どうしてそれが分散化されていると言えるのでしょうか?この疑問に答えるには、地方分権の意味に関するヴィタリックの古典的な記事を再検討する必要があります。この記事の重要な洞察は、分散化には3つのタイプがあるということです。

• アーキテクチャの分散化:システムの実行が停止するまでに障害が発生する可能性のあるノードの数はいくつですか?
• 論理的な分散化:システムのさまざまなサブシステムは、まとまりを持って連携しながら、独立して開発できますか?
• 政治的分権化:究極的には、何人の個人または組織がシステムを支配しているか?

これらの定義によると、イーサリアムは明らかにアーキテクチャ的に分散化されており、そのコンポーネントが強い結合(コンセンサス層と実行層の間など)を欠いているため、論理的に分散化されていると主張することができます。政治的な分散化に関しては、良いニュースは、個人や組織がイーサリアムをシャットダウンすることはできないということです。しかし、イーサリアムの政治的分散化のレベルは、イーサリアムのビジョンとロードマップの形成においてヴィタリックが重要な役割を果たしているため、想像されたほど高くないと主張する人もいるかもしれません。

しかし、イーサリアムに革新を続けてもらいたいのであれば、政治的な分散化を多少犠牲にすることになっても、ヴィタリックを事実上のCTOとして受け入れなければならないと私は考えています。イーサリアムがほぼ不変のブロックチェーンであるビットコインと同じくらい「停滞」した場合、ヴィタリックは引退したほうがよいでしょう。しかし、その最終段階に到達する前に、すべての関係者から尊敬される権威、提案された技術的解決策の優位性だけでなく、これらの決定がイーサリアムのビジョンと一致しているかどうかに基づいて技術的な決定を下す信頼できる人物を持つことが重要です。

ヴィタリックのような人物がいなければ、EIP-3074をめぐる話が鮮やかに示しているように、2つの結果しか起こりそうにありません。

イーサリアムのガバナンスプロセスは、ヴィタリックが介入する前の3074年の議論の行き詰まりが示すように、対立する当事者が妥協を望まず、誰も進歩しないという終わりのない行き詰まりに陥る可能性があります。

あるいは、イーサリアムは、3074と4337が互いに譲歩しないような、デザインに支離滅裂な「フランケンシュタイン」となり、最終的にはAAエコシステムが完全に崩壊し、互換性のない2つの並列空間になってしまう可能性があります。

コミュニティの役割

上記の考察を経て、イーサリアムのガバナンスに関する完全な考え方をほぼ概略化していますが、これまでの議論には明らかな抜け落ちがあります。ヴィタリックがイーサリアムのビジョンを定義し、研究者がロードマップを定義し、コア開発者がロードマップを実装するとしたら、コミュニティはどのような役割を果たすのでしょうか?確かに、ただ手をこまねいているわけではありませんよね?幸いなことに、コミュニティは最も重要な役割を果たしています。なぜかというと、ビジョンの前には価値観があるからです。私たちがコミュニティとして団結するのは、特定の価値観のもとに結集しているからであり、コミュニティの支持を維持するためには、ヴィタリックのビジョンが最終的にこれらの価値観と一致している必要があります。イーサリアムコミュニティの誰もが、誰もがアクセスでき、検閲がなく、信頼に中立な分散型コンピューターを持つことは、世界にとって有益であると信じています。私たちは、イーサリアム上での作業を通じて、これらの価値観を日々支持し、確認することで、ヴィタリック、研究者、コア開発者が提示したビジョン、ロードマップ、コードを正当化しています。

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

そこで、イーサリアムのガバナンス(VVRCと略される)の完全な考え方をご紹介します。

• V==値==コミュニティ;
• V==ビジョン==ヴィタリック;
• R==ロードマップ==研究者;
• C==Client==Core Developer;

これらが組み合わさって、次の役割を果たします。

• コミュニティは特定の価値観を中心に結集します。
• ヴィタリックは、これらの価値観に沿ったビジョンを明確に示しています。
• 研究者は、ビジョンに基づいてロードマップを策定します。
• コア開発者は、ロードマップに基づいてクライアントを実装します。

もちろん、現実は単純なモデルでは捉えられないほど複雑です。イーサリアムのコア開発者は、クライアントコードを変更することで、あらゆる提案に真に「投票」できる唯一の開発者です。ヴィタリック氏と他の研究者がアドバイザーを務めていますが、彼らの意見がコア開発者に受け入れられないこともあるため、EIP-3074が承認されたのです。それにもかかわらず、VVRCモデルは、通常の状況下でのイーサリアムガバナンスの運用モードを合理的に捉えていると信じており、EIP-3074のような事故が二度と起こらないように、このプロセスを「デバッグ」する必要があります。

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

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

レビュー中のEIPの議論の進捗状況の可視性を高める必要があります。コミュニティ全体がEIPの受理に「驚く」べきではなく、EIP-3074のような予期せぬ承認が繰り返されるべきではありません。EIP WebサイトのEIPの現在の「ステータス」は、ACDプロセスのステータスを反映していません。これが、EIP-3074が最初から承認のために検討されたことを示すことなく、コア開発者が承認に投票したにもかかわらず、EIP-3074が「レビュー中」であると述べている理由です。理想的には、EIPが受け入れられようとしているときに、イーサリアム財団はソーシャルメディアで決定的な公式発表を行い、コミュニティ内の意識を高める必要があります。

コア開発者は、3074 や 4337 のコミュニティのように、特定の EIP が下流のプロジェクトやユーザーに与える影響を過小評価することがあります。ACD会議の時間は限られており、タイムゾーンを越えた調整が必要なため、会議で発言できるのは「関係者」のみであることがよくあります。それにもかかわらず、承認後に特定のEIP提案が下流プロジェクトに与える影響についてコメントするために、コミュニティメンバーに発言時間を割り当てることは理にかなっています。4337 の場合のように、研究者が自分の意見がコア開発者に受け入れられていないと感じた場合、コミュニティのメンバーに議論を補強してもらうことができます。

コア開発者と研究者は、力の違いはあるものの、どちらもイーサリアムのガバナンス権限の一部であることを相互に認めることが重要です。コア開発者は、イーサリアムクライアントを変更・更新する権限を持っており、それがプロトコル自体に変更を加えて「投票」する唯一の方法です。研究者は通常、ロードマップの変更や解釈に対して、活発な議論やアイデアの執筆のおかげで、より多くの一般の支持を得ています。

この2つの力がぶつかり合うと、4337チームのように、コア開発者が研究者の意見を直接覆す傾向があります。しかし、EIP-3074の承認後の劇的な出来事が示すように、2つの勢力が衝突すると不安定が生じるため、そのような転覆は紛争につながる可能性があります。

同様に、抵抗に直面した場合、研究者はコア開発者とのコラボレーションをあきらめる傾向があります。私の見解では、これはRIPプロセスを作成する理由の1つでもあり、ネイティブAA(7560)がEIPではなくRIPとして主に推進されている理由でもあります。

L1 で物議を醸す L2 のプロトコル更新を実験することには利点がありますが、RIP を EIP ガバナンス プロセスへの参加に代わるものと見なすことはできません。研究者は、双方の価値観がロードマップと完全に一致するまで、コア開発者と協力し続ける必要があります。

結論

3074/7702のインシデントは、コア開発者のEIP/ACDプロセスによって駆動される明示的なガバナンス力とは別に、研究者が推進するロードマップによって駆動される暗黙のガバナンス力もあるという、イーサリアムガバナンスの真の運用を明らかにしました。これらの力がずれていると、行き詰まりや突っ込みが見られ、別の力であるヴィタリックが何らかの方法で介入してバランスを崩す必要があるかもしれません。

次に、ヴィタリックは、あらゆるロードマップの正当性の基礎を形成するイーサリアムの「ビジョン」というユニークな力を表していると提案します。ヴィタリックを大企業のCTOに例え、イーサリアムがイノベーションのペースを維持し、イーサリアムがつぎはぎの怪物のような「フランケンシュタイン」に陥るのを防ぐためには、疑似CTOとしての役割が必要であることを認めています。

最後に、イーサリアムのガバナンスモデルであるVVRCモデル(価値(コミュニティ)⇒ビジョン(Vitalik)⇒ロードマップ(研究者)⇒クライアント(コア開発者))を紹介します。そして、このモデルの「欠点」を「デバッグ」するための様々な方法を提案します。

イーサリアムのガバナンスは「機械を作る機械」であり、イーサリアムを正しく動作させるためには、適切に統治する必要があります。

免責事項：

1. この記事は【极客Web3】からの転載です。 原題は「Reflections on Ethereum Governance Following the 3074 Saga」。すべての著作権は原作者[ZeroDevのCEO、Derek Chiang]に帰属します。この転載に異議がある場合は、 Gate Learn チームに連絡していただければ、迅速に対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。