Vitalik とイーサリアムのガバナンス プロセスに対するさまざまなロードマップの影響について
原作者: Derek Chiang、ZeroDev CEO
オリジナル編集: ファウスト、オタク web3
要約: この記事は、Buterin が ERC-4337 と EIP-3074 の間の矛盾のバランスをとるために EIP-7702 を提案した後の、この問題に関する ZeroDev CEO の Derek Chiang の見解です。この記事は、AA エコシステムにおけるプロジェクト創設者の個人的な経験に基づいて、イーサリアムの現在のガバナンス モデルとその問題点を客観的に指摘し、次の点を指摘しました。
イーサリアムにおけるさまざまなガバナンス上の矛盾の 1 つは、研究者によって決定されたロードマップと、ゲスなどのクライアント開発チームの見解との相違にあり、ヴィタリック氏は CTO に似た立場の最後の言葉となっています。
デレク氏はヴィタリック氏の役割を肯定的に評価した後、イーサリアムがガバナンスモデルにどのような改善を加えるべきかを指摘し、これはイーサリアムコミュニティとビットコインコミュニティの両方にとって良い参考になると述べた。
テキスト: これまでイーサリアム AA (アカウントの抽象化) に関連するイベントを理解していない場合は、ここで簡単に復習してください。
数週間前、EIP-3074提案はイーサリアムコア開発者によって承認され、次のハードフォーク「Pectra」に含まれる予定です。この提案により、EVM に 2 つの新しいオペコードが導入され、イーサリアム EOA アカウントにネイティブに近い AA エクスペリエンスが提供されます。
それ以来、ERC-4337 コミュニティの多く、特に 4337 の提案者は、この提案が多くのセキュリティ リスクをもたらし、イーサリアムの AA ロードマップと矛盾するという懸念を理由に、EIP-3074 に強く反対してきました。イーサリアムの以前のロードマップでは、ERC-4337と同様の提案7560（「nativeAA」としても知られる）を中心にしていることが明確に述べられていました。
5 月初旬、Vitalik は、4337 と 3074 の間でバランスをとる、EIP-3074 の代替品として EIP-7702 を提案しました。これは、EOA ユーザーに AA エクスペリエンスをもたらすことができますが、ある程度は ERC-4337 に似ており、互換性があり、互換性があります。 「AAファイナルソリューション」7560。
現在、イーサリアムコア開発者は EIP-7702 を検討しています。現在の予備的な議論の結果とコミュニティの意見は、EIP-7702 が上記の EIP-3074 に代わる可能性が高いことを示しています。
個人的には、この結果に非常に満足しています。EOA ユーザーは間もなく ERC-4337 エコシステム内のさまざまな製品を体験し、AA によってもたらされる利点のほとんどを享受できるようになります。しかし、ここ数週間多くの人が指摘してきたように、上記の結果を達成するにはもっと良い方法があると感じずにはいられません。より良いガバナンスプロセスがあれば、多くの労力を節約し、より早く望ましい結果を達成できたはずだと私は感じています。
この記事では次のことを行いたいと思います。
ガバナンスプロセスの何が間違っていたのかを特定する
イーサリアムのガバナンスを考えるためのメンタルモデルを提案する
将来同様のガバナンスインシデントが発生するのを避けるため、改善を提案します。
EIP-3074 インシデントの概要と考察
上記の話は多くの人を動揺させましたが、その理由は次のとおりです。
EIP-3074 は承認されるまでに数年かかりました。イーサリアムコア開発者が 4337 コミュニティからの反発に直面したのは、3074 が最終的に承認された後でした。
一方で、ERC-4337の作成者はイーサリアムコアチームに対してEIP-3074に対する懸念を繰り返し表明しましたが、無駄でした。現在、イーサリアムは 3074 の承認を取り消し、別の EIP (7702) に置き換えることを計画しています。
上記のプロセスには本質的に何も問題はありません。
EIP に関する議論には数年かかるのが通常です。
EIP が承認後に拒否されるのは通常のことです。
EIP 承認後に新たな問題が発見された場合、承認を取り消すことができます。
ただし、物事はもっとスムーズに進む可能性がありました。状況が次のようになった場合を想像してみましょう。
3074 について議論している間、4337 コミュニティはイーサリアムのコア開発者と積極的に関わりました。この前提が正しい場合、結果は 2 つだけになります。
提案 3074 は、コミュニティからのフィードバックを考慮した後に承認 (および変更される可能性があります) されます。その場合、コミュニティはそれを受け入れ、イーサリアムコアチームは提案を取り消す必要はありません。
あるいは、3074 は承認されませんでしたが、4337 コミュニティとイーサリアムコアチームが協力して、7702 と同様に全員が満足する提案を作成しました。
全員の声が届くが、劇的な逆転はない。これは素晴らしいことだったでしょうが、なぜそうではなかったのでしょうか?
何が悪かったのか？
一連の過程を振り返ると、事件の双方が互いに非難し合っている。
イーサリアムコア開発者（およびEIP-3074の作成者）は、これは「4337バッカー」のせいだと信じています。彼らは、EIPがその後長いプロセスを経たオールコア開発者（ACD）の議論プロセスに積極的に参加しなかったためです。熟慮の結果、最終的には Geth および他のイーサリアム クライアント開発チームによって受け入れられ、実装されることになります。
一部の人々は、提案3074が検討されている間、「4337人の支持者」は、提案3074が承認されるまで待って後で反応するのではなく、全面的に参加して意見を表明できると信じています。結局のところ、ACD プロセス全体は十分に文書化されており、会議は誰にでも公開されており、TimBeiko のような人々は、ACD 会議のたびに要約ツイートを積極的に投稿しています。それでは、4337 人のサポーターがこのテーマにそれほど関心があるのであれば、なぜ関連する会議に積極的かつ迅速に参加しないのでしょうか?
一方、4337のコアメンバーはACDの会合に出席し、3074に可能な限り反対していると指摘したが、イーサリアムのコア開発者らは耳を貸さなかった。 4337 人のコミュニティ メンバーに関しては、そのほとんどが予想外だったと感じました。多くの人は、3074 はすでに冷めたと考えており、3074 が承認される可能性が高いことさえ知りませんでした。
多くの人が、ACD 会議のプロセス全体が非常に不透明で、イーサリアム コミュニティで「真剣に」活動しているにもかかわらず、ACD の更新の進捗状況をタイムリーにフォローできない人々にとって不親切であると指摘しました。また、ACD は利害関係者 (この場合は 4337 コミュニティ) からのフィードバックを積極的に求めるべきだと考える人もいます。
しかし、私はどちらの側も要点を見逃していると思います。この背後にはさらに深い問題があり、それに対処するか、少なくともそれを認めない限り、私たちは双方が互いに非難し合うガバナンスの失敗から抜け出せないことになりますが、それは意味がありません。
インシデントの根本原因への対処: ロードマップ
一般的な考えに反して、ガバナンス事故の根本原因は、ACD がイーサリアム プロトコル更新のガバナンス権の唯一のソースではなく、別のガバナンス権のソースに置き換えられたことです。ここでの問題は、AA やスケーラビリティなどのイーサリアムの中核問題に対して、別の統治権力が ACD よりも大きな影響力を持っているにもかかわらず、それがほとんど認められていないことです。
この記事では、この力を「ロードマップ」と呼んでいます。
以下で指摘するように、「3074-4337-7702」ガバナンス失敗事件全体は、イーサリアムの既存のロードマップの力がACDの力を圧倒するケースです。ガバナンスについて話している場合、目に見える力を圧倒する目に見えない力があることに気づいたとき、私たちはこれについて非常に心配する必要があります。なぜなら、目に見えないものは説明が難しく、あまりにも多くの人が気づくことができないからです。暴露されなければならない。
ロードマップとは何ですか?
イーサリアムコミュニティの誰もが、たとえば「ロールアップ中心のロードマップ」、「ETH 2.0 ロードマップ」、この場合は「AA ロードマップ」などで、「ロードマップ」という言葉を頻繁に目にしたことがあるはずです。
私の主張を説明するために、コア開発者がイーサリアムを拡張する方法について議論している ACD ミーティングを想像してみましょう。
コア開発者のボブ: 私は EIP-1234 を支持します。この提案は、ブロック生成を 10 倍高速化し、ブロック サイズを 10 倍増加し、料金を 100 倍削減することを提案しています。
他のコア開発者: ...あなたは頭がおかしいのですか?
考えてみましょう。なぜイーサリアムコアチームはボブの発言を拒否したのでしょうか?彼は、Solana、Aptos、Sui および他の多くのパブリック チェーンがこれを実行し、非常に高い TPS を達成していると思われるスケーリング方法を提案しました。
その理由は、この架空の EIP-1234 がイーサリアムの「ロールアップ中心」の拡張ロードマップに違反しているためであり、分散化のためには一般のユーザーが低コストでノードを実行できることが重要であると指摘しており、したがって架空の EIP-1234 はありそうもありません。イーサリアムノードの実行コストが大幅に増加するため、受け入れられません。
この例を使用して、ACD ガバナンス プロセスに参加し、プロトコルの更新を決定するコア開発者が、私が「ロードマップ」と呼ぶ上位レベルの力によって導かれていることを説明したいと思います。現在、イーサリアムのロードマップには「拡張ロードマップ」、「AAロードマップ」、「MEVロードマップ」などがあり、これらがまとめてイーサリアム全体のロードマップを構成しており、コア開発者はこれに基づいて意思決定を行う必要があります。
コア開発者の意見がロードマップと一致しない場合
ロードマップはイーサリアム ガバナンス プロセスの正式な部分ではないため、多くの場合、コア チームがロードマップを順守するという保証はありません。さらに、ロードマップを「承認」するための正式なプロセスがないため、すべてのロードマップが同様に「正統」であるわけではありません。イーサリアムのロードマップを支える研究者は、「正当性」を獲得し、それによってイーサリアムのコア開発チームからのサポートを得るために、コア開発者やコミュニティにロードマップを宣伝するために懸命に努力する必要があります。
AA とアカウントの抽象化に関する限り、Vitalik 氏自身は何度か 4337 を中心とした AA ロードマップを推進してきましたが、一般に、それは主に 4337 の背後にいるチーム、特にフォーラムや ACD で 4337 を提唱した Yoav と Dror です。ミーティングを中心とした AA ロードマップ。
しかし、これらの努力にもかかわらず、一部のイーサリアムコア開発者は依然として4337中心のAAロードマップに強く反対しています。彼らは、7560 (将来イーサリアムクライアントによって実装される予定の 4337 のネイティブバージョン) は複雑すぎるため、「AA エンディング」の唯一の実現可能な解決策ではないと考えています。最終的に、ACD は提案 3074 を承認することを決定しましたが、これには 3074 が AA エコシステム全体を断片化すると考えた 4337 チームによって反対されました。
3074 が承認された後、4337 コミュニティ全体が強く反応し、イーサリアムのコア開発者は 3074 の議論に再び参加することを余儀なくされました。その後、議論は行き詰まり、4337 の作者も 3074 の作者も相手を説得できませんでした。最後の瞬間、Vitalik は 3074 の代替案として、明らかに「AA エンディング」を中心とした EIP-7702 を提案しました。 4337 で競合を解決し、最終結果は AA ロードマップに適合します。
Vitalik の役割: イーサリアムの事実上の CTO
ヴィタリックは自分自身を研究者であると名乗っていますが、上記の話から、ヴィタリックが他の研究者とは異なる統治権限を持っていることが明らかです。そこで疑問が生じます: Vitalik はイーサリアムのガバナンスにおいてどのような役割を果たしているのでしょうか?
個人的には、Vitalik を非常に大きな会社の CTO と考えるのはおそらく不適切ではないと思います (ちなみに、現実のために、イーサリアムの「会社」には CEO がいないと仮定しましょう)
従業員数 50 名を超えるテクノロジー企業で働いたことがある人なら、CTO がテクノロジーに関するすべての意思決定に関与できるわけではないことをご存知でしょう。企業がある程度の規模に達すると、さまざまな技術的ソリューションの意思決定プロセスは必然的に分散化されます。通常、企業の製品/ビジネスの各分野には専任のチームがあり、このチームは通常、ソリューションの詳細を自由に決定できます。解決。
さらに、CTO は必ずしもすべて (または任意の) トピックのトップの専門家であるとは限りません。社内には特定の分野で CTO よりも優れたエンジニアがいる可能性があるため、ソリューションの技術的な詳細について議論する場合、最終的な決定を下すのは個々のエンジニアであることがよくあります。
ただし、CTO は会社のテクノロジー ビジョンを設定します。ビジョンの実行は開発者に任されています。
これは完璧な例えではありませんが、イーサリアム エコシステムにおける Vitalik の役割を合理的に要約していると思います。ヴィタリックはすべての技術的な決定に関与するわけではないし、関与することもできない。また、彼はあらゆる分野の一流の専門家でもありません。しかし、彼はすべての主要なイーサリアム ソリューション (スケーリング、AA、POS など) のロードマップの策定に圧倒的な影響力を持っています。その理由は、彼の技術的専門知識だけでなく、「ロードマップがイーサリアムのビジョンと一致しているかどうか」という理由でもあります。彼のビジョンの最終的な判断者）。
成功する製品はすべてビジョンから始まります
Vitalik がイーサリアムの CTO であることが十分に物議を醸すものではないと私が思うなら、ここが最も物議を醸す部分です。それは、Vitalik を CTO として受け入れるべきであるということです。
スタートアップの創設者として、私はすべての成功した製品の背後に一貫した長期的なビジョンがあるはずだと信じています。そうです、イーサリアムは実際のユーザーの疑問を解決するため、「製品」でもあります。一貫したビジョンは、スタートアップの創業者などの少数の人々によって策定される必要があり、多くの場合、創業者は 1 人だけです。
イーサリアムの利点は、非常に多くのコンポーネントを備えた非常に複雑なシステムであるにもかかわらず、それらのコンポーネントが完璧に組み合わされて、毎日数十億ドルもの価値のある取引活動を決済する十分な分散型コンピューターを形成していることです。
私たちが今日の地位に到達したのは、何らかの委員会の設計があったからではありません。私たちが今日のような一貫した美しいイーサリアムを構築できたのは、ヴィタリックのビジョンに基づく積極的なリーダーシップのおかげです。イーサリアムは 2015 年に Vitalik が考案したものであり、それは現在も変わりません。
もちろん、これはイーサリアムを今日の姿にしている要因の多くを担っている他の研究者やエンジニアの貢献を軽視するものではありません。ただし、イーサリアムは他の誰よりも桁違いに優れたヴィタリック氏のビジョンを実現したものであるため、これは矛盾ではありません。
正直に言って、それについて文句を言うことはできますか？イーサリアム エコシステムのオープン性、検閲への耐性、イノベーションのスピードに魅力を感じていましたが、それが Vitalik のビジョンから始まったことに不満を抱いたことはありますか?もしかしたら、あなたはそのように考えていなかったので文句を言わなかったのかもしれませんが、今はそう思っていますが、本当に気にしていますか？
分散化をどう解決するか?
しかし、分散化についてはどうでしょうか?一人の人間がイーサリアムに対してこれほど圧倒的な権力を持っているとしたら、どうしてそれが分散化されていると言えるでしょうか?
この質問に答えるには、ヴィタリックによる分散化の意味に関するこの古典的な記事を再検討する必要があります。この記事の重要な洞察は、分散化には 3 つのタイプがあるということです。
アーキテクチャの分散化: ノード障害が発生するとシステムの機能が停止しますか?
論理的な分散化: システム全体を正常に機能させながら、システムの各サブシステムを独立して開発できますか?それとも綿密に調整する必要があるのでしょうか？
政治的分散化: 最終的にシステムをコントロールするのは何人の人または組織ですか?
これらの定義によれば、イーサリアムは明らかにアーキテクチャ的に分散化されており、そのさまざまなコンポーネント (コンセンサス層と実行層など) の間に強い結合がないため、論理的にも分散化されていると主張できます。
政治的分散化の観点から言えば、良いニュースは、たとえヴィタリックであっても、イーサリアムを閉鎖できる個人や組織は存在しないということです。ただし、Vitalik がイーサリアムのビジョンとロードマップの開発に重要な役割を果たしたため、イーサリアムは考えられているほど政治的に分散化されていないと主張する人もいるかもしれません。
しかし、イーサリアムに革新を続けてもらいたいのであれば、たとえ政治的な分散化をある程度犠牲にすることになっても、ヴィタリクを事実上のCTOとして受け入れる必要があると私は信じています。
イーサリアムがビットコインのようなほぼ不変のブロックチェーンに本当に「固定」されているのであれば、ヴィタリック氏は直接引退するかもしれない。しかし、その最終段階に進む前に、すべての関係者から尊敬され、提案された技術的解決策が優れているかどうかだけでなく、それらの決定は、それがイーサリアムのビジョンと一致しているかどうかです。
ヴィタリックのような人々がいないと、起こり得る結末は 2 つだけですが、どちらも 3074 を取り巻く物語で鮮やかに示されています。
ヴィタリック氏が介入する前に3074年の議論が行き詰まり、イーサリアムのガバナンスプロセスは、どちらの側も妥協する気はなく、誰も前進することができず、終わりのない行き詰まりに陥る可能性がある。
あるいは、イーサリアムは、一貫性のない「人々」の設計を持つフランケンシュタインになる可能性があります。前述の 3074 と 4337 は互いに譲歩することができず、最終的に AA エコシステムは 2 つの相容れない並行空間に完全に分離されます。
コミュニティの役割
上記の検討を経て、私たちはイーサリアムのガバナンスの完全な思考モデルの概要をほぼ概説していますが、これまでのところ、私たちの議論には明らかな省略、つまりコミュニティがあります。
Vitalik がイーサリアムのビジョンを定義し、研究者がロードマップを定義し、コア開発者がロードマップを実装する場合、コミュニティはどのような役割を果たすのでしょうか?確かに何もしないのとは違いますよね？
幸いなことに、実際にはコミュニティが最も重要な役割を果たしています。その理由は、ビジョンがある前に価値観があるからです。私たちがコミュニティとして団結するのは、特定の価値観を中心に団結するためであり、ヴィタリックのビジョンは最終的にそれらの価値観と一致する必要があり、そうでないとコミュニティの支持を失うことになります。
イーサリアムコミュニティの誰もが、誰もがアクセスでき、検閲を受けず、信頼でき、中立的な分散型コンピューターがあれば世界にとって良いことだと信じています。私たちは、イーサリアムで日々行っている作業を通じて上記の価値観を支持および確認しており、そうすることで、Vitalik、研究者、およびコア開発者によって開発されたビジョン、ロードマップ、およびコードに正当性を提供します。
イーサリアムガバナンスの VVRC モデル
ここでは、イーサリアム ガバナンスの完全なメンタル モデル、価値観 ⇒ ビジョン ⇒ ロードマップ ⇒ クライアント、または略して VVRC を示します。
V==価値観==コミュニティ;
V==ビジョン==ヴィタリック;
R==ロードマップ==研究者;
C==クライアント==コア開発者;
これらは一緒に次の役割を果たします。
コミュニティは特定の価値観を中心に団結します。
Vitalik は、これらの価値観と一致するビジョンを表現しています。
研究者はビジョンに基づいてロードマップを作成します。
コア開発者はロードマップに従ってクライアントを実装します。
もちろん、現実は単純なモデルで捉えることができるよりもはるかに複雑です。実際、クライアント コードの変更を通じて提案に実際に「投票」できるのは、イーサリアム コア開発者だけです。 Vitalik と他の研究者は助言的な役割を果たしているだけであり、彼らの意見がコア開発者に受け入れられない場合があるため、EIP-3074 が承認されました。
そうは言っても、VVRC モデルはイーサリアムのガバナンス モデルが通常の状況でどのように機能するかを合理的に捉えていると思います。EIP-3074 のようなことが再び起こらないようにプロセスを「デバッグ」する必要があります。
イーサリアムのガバナンスモデルを改善する方法
イーサリアムのガバナンスプロセスがどのように機能するかについてのメンタルモデルができたので、それを改善するためのアイデアをいくつか紹介します。
検討中の EIP に関する議論の進捗状況の可視性を高める必要があります。コミュニティ全体が EIP が受け入れられたことに「驚いて」はなりませんし、3074 のような驚くべき提案承認方法が再び現れるべきではありません。
EIP Web サイト上の EIP の現在の「ステータス」は、ACD プロセスにおけるステータスを反映しません。コア開発者が承認に投票したにもかかわらず、3074 が依然として「審査中」であると述べているのはそのためであり、そもそも承認が検討されていた形跡すらありません。
理想的には、EIP が承認されそうになったら、イーサリアム財団がその結果をソーシャル メディアで大声で明確に発表し、コミュニティの認識を高めることです。
3074 コミュニティや 4337 コミュニティの場合のように、コア開発者は、下流のプロジェクトやユーザーに対する特定の EIP の影響を過小評価することがあります。 ACD の会議は時間が限られており、タイムゾーンを越えて調整する必要があるため、多くの場合、「関係者」のみが会議で発言できます。
そうは言っても、特定の EIP 提案が可決された場合に、コミュニティ メンバーがその下流への影響についてコメントできるよう、時折講演時間を割り当てることは理にかなっています。
4337 の場合のように、研究者が自分の意見がコア開発者に受け入れられていないと感じた場合は、自分たちの主張を強化するためにコミュニティのメンバーに意見を求めることができます。
コアの開発者と研究者が、強みの違いにもかかわらず、すべてがイーサリアムのガバナンス力の一部であることをお互いに認識することが重要です。 Ethereum クライアントを変更および更新するコア開発者の権利は、プロトコル自体に変更を加えて「投票」する唯一の権利です。ロードマップを変更および解釈する研究者の権利は、一般に、研究者が自分のアイデアについて積極的に話したり書いたりするおかげで、より大きな国民の支持を得ています。
これら 2 つの力が矛盾する場合、コア開発者は研究者の意見を直接覆す傾向にある可能性があります。たとえば、コア開発者は 4337 チームの反対を覆しました。しかし、3074号承認後の劇的な出来事が示したように、2つの大国が衝突すると不安定になる可能性があるため、そのような打倒は紛争を引き起こす可能性がある。
同様に、抵抗に直面すると、研究者はコア開発者との協力を放棄したくなるかもしれません。これが、RIP プロセスが作成された理由の 1 つであり、ネイティブ AA (7560) が現在では主に RIP として実行されている理由の 1 つであると私は考えています。 EIP 昇進の理由。
L1 に対して物議を醸しているプロトコルの更新を L2 が実験することには実際の利点がありますが、RIP を EIP ガバナンス プロセスへの参加の代替として見ることはできません。研究者は、双方の価値観がロードマップと完全に一致するまで、コア開発者と協力し続ける必要があります。
結論は
3074/7702 インシデントは、イーサリアムのガバナンスが実際にどのように機能するかを明らかにしました。コア開発者によって推進される EIP/ACD プロセスの明示的なガバナンス力に加えて、研究者によって推進されるロードマップの暗黙的なガバナンス力もあります。これらの力のバランスが崩れると、行き詰まりやむち打ちが発生し、何らかの方法でバランスを崩すために別の力、ヴィタリックが必要になる可能性があります。
次に私たちは、Vitalik がイーサリアムの独自の力、つまりあらゆるロードマップの正当性の基礎となる「ビジョン」を表していると提案します。私たちはヴィタリック氏を大企業の CTO に例え、イーサリアムがイノベーションのペースを維持するためには疑似 CTO としての彼の役割が必要であり、それによってイーサリアムが「フランケンシュタイン」風のスティッチ モンスターに変質するのを防ぐことができると認識しています。
最後に、イーサリアムのガバナンス モデルを記述する VVRC モデルを提案します: 価値観 (コミュニティ) ⇒ ビジョン (Vitalik) ⇒ ロードマップ (研究者) ⇒ クライアント (コア開発者)。次に、このモデルの「バグ」を修正するさまざまな方法を提案します。
イーサリアムのガバナンスは「機械を作る機械」です。イーサリアムが正しく動作するには、合理的なガバナンスが必要です。したがって、3074 はガバナンス インシデントの貴重な例を提供しており、イーサリアム コミュニティが将来のイーサリアム ガバナンス プロセスを改善するために、そこからいくつかの有益な教訓を学ぶことができることを願っています。
