Vitalik と Yoav がこの記事を親切にレビューしてくれましたが、意見は私自身のものです。

AAドラマをまだ見ていない方のために、簡単におさらい

• 数週間前、AAのメリットの多くをEOAユーザーにもたらす提案であるEIP-3074が、イーサリアムの次のハードフォークである「ペクトラ」に入るためにコア開発者によって承認されました。
• それ以来、ERC-4337コミュニティの多くの人、特に4337の著者自身は、https://docs.zerodev.app/blog/4337-and-3074-disagreements<<a href="https://notes.ethereum.org/@yoav/3074-implications">中央集権化の懸念とイーサリアムの@yoav/AA-roadmap-May-2024">AAロードマップで、4337とそのいとこである7560(別名「ネイティブAA」)を中心としています。
• 先週、Vitalik は 3074 の代替として EIP-7702 を提案しました。EOAユーザーにAAの多くの利点をもたらすというほぼ同じ目標を達成しますが、現在の4337との互換性が高く、7560である「AAエンドゲーム」との上位互換性があります。
• 現時点では、コア開発者はEIP-7702について審議していますが、予備的な議論とコミュニティの感情は、EIP-7702がペクトラのEIP-3074に取って代わる可能性が高いことを示唆しています。

EOAユーザーは、ERC-4337用に構築されたツールとインフラを使用して、AAのほとんどのメリットをすぐに享受できるようになります。

しかし、この結果を達成した方法は、過去数週間に多くの人が表明した見解である、最適とはほど遠いと感じざるを得ません。より良いプロセスがあれば、膨大な量のエネルギーと頭痛の種を節約し、望ましい結果にもっと早く到達できたと感じています。

このブログ記事では、次のことを行いたいと思います。

• プロセスで何が問題だったのかを特定します。
• イーサリアムのガバナンスについて考えるためのメンタルモデルを提案します。
• 今後、同様のガバナンスの失敗を回避するための改善を提案します。

なぜプロセスが人々を不幸にしたのか

この物語全体が、いくつかの理由で多くの人々を不幸にしました。

• 3074が承認されるまでに何年もかかりました。
• 3074が最終的に承認された後、コア開発者は4337コミュニティから大量の反発を受けました。
  • 一方、4337の作者自身は、3074に対する懸念をコア開発者に繰り返し表明していましたが、無駄でした。
• 現在、3074の承認を解除し、別のEIP(7702)に置き換える予定です。

さて、上記のいずれにも本質的に問題はありません。

• 議論に何年もかかっても構いません。
• EIP が承認された後にプッシュバックを受け取ることは問題ありません。
• 新しい問題が特定された場合は、承認後に EIP の承認を取り消すことができます。

しかし、物事がもっとスムーズに進んだ可能性があることには同意できるでしょう。もし、こんな感じだったら想像してみてください。

• 4337コミュニティは、3074について議論しているコア開発者と積極的に関わりました。現在、次の 2 つの結果のうち 1 つしか考えられません。
  • 4337コミュニティのフィードバックをアカウントに取り込んだ後、3074が承認(およびおそらく変更)された場合、4337コミュニティは3074に参加し、3074を元に戻すことはありません。
  • また、3074 は承認されませんでしたが、4337 のコミュニティとコア開発者が協力して、誰もが満足できる 7702 の提案に取り組みました。

全員の声が届き、劇的な逆転はありません。それは良かったのですが、なぜそうしなかったのでしょうか?

何が悪かったのか?

その過程を振り返ってみると、議論の両陣営は互いに非難し合っている。

コア開発者(およびEIP-3074の作者)は、EIPが最終的にクライアントチームに受け入れられるまでにロング時間審議され、それによってプロトコルに実装されるAll Core Devs(ACD)プロセスに積極的に関与しなかったのは「4337人」のせいだと感じました。

この審議のどの時点でも、3074が承認されるまで待つのではなく、「4337人」がやってきて懸念を表明することができたはずだ。結局のところ、ACDプロセスは十分に文書化されており、会議は誰でも参加でき、Tim Beikoのように、ACD会議のたびに要約を積極的にツイートする人もいます。では、4337人がこの問題をそれほど気にかけているのなら、なぜ時間を割いて取り組まなかったのでしょうか?

一方、AAチーム(4337人の著者)は、ACDミーティングに出席していたことを指摘し、可能な限り3074を延期しましたが、コア開発者は耳を傾けませんでした。4337コミュニティに関しては、彼らはほとんどが不意打ちを食らったと感じていました — ほとんどの人は3074が死んだという印象を受けており、3074が積極的に参加が検討されていることにさえ気づいていませんでした。

また、多くの人々は、ACDのプロセスがあまりにも不透明で、「実際の仕事」を持っていて、すべてのACDの更新に追いつく余裕がない人々からの参加には友好的ではないと感じていました。また、関連する利害関係者(この場合は4337コミュニティ)からのフィードバックを積極的に求めるのはACDの責任であるべきだと感じる人もいました。

しかし、私の意見では、双方とも的外れでした。職場にはもっと根深い問題があり、問題を修正するか、少なくとも問題を認識するまでは、ガバナンスの失敗とそれに続く非生産的な非難にぶつかり続けるでしょう。

根本原因

ガバナンスの失敗の本当の原因は、一般的な信念に反して、ACDがプロトコル更新の唯一のガバナンス権限ではなく、このインスタンスでは別のガバナンス権限によって上書きされたことでした。

問題なのは、AAやスケーリングなど、イーサリアムの最も重要な事項についてACDよりもさらに大きな影響力を持っているという事実にもかかわらず、他のガバナンス力がほとんど認められていないことです。

この記事では、このパワーを「ロードマップ」と呼ぶことにします。

この3074/7702の物語全体は、私が主張するように、ロードマップの力がACDの力を圧倒する例に他なりません。そして、もし私たちが統治について話しているのなら、目に見えない力が目に見える力を圧倒しているのに気づくときはいつでも、目に見えないものは説明がつかないので、明るみに出さなければならないので、私たちは非常に心配すべきです。

ロードマップとは?

イーサリアムコミュニティの誰もが、「ロールアップ中心のロードマップ」や「ETH 2.0ロードマップ」、あるいはこの議論における「@yoav/AA-roadmap-May-2024">AAロードマップ」など、「ロードマップ」という言葉によく出くわしたことがあるはずです。

イーサリアムマジシャンの「ロードマップ」の検索

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

• Core Dev Bob: 私は1234サポート EIP、10倍に高速化し、ブロックサイズを10倍に増やし、手数料100Xドロップすることを提案しています。
• その他のコア開発者:...あなたはあなたの*心から外れていますか?

ここで少し考えてみましょう。なぜコア開発者はボブが言ったことを撃墜したのですか?彼はただ、非常に合法的なスケーリングの形を提案しただけです。ソラナや他の多くのL1は、素晴らしいスケーリング効果をもたらします。

その理由は、もちろん、この架空のEIPが、イーサリアム自身の"rollup-centric"スケーリングロードマップに反しているからです>したがって、架空のEIPは、ノードを実行する際の障壁を大幅に増やすため、問題外です。

AA の場合、Vitalik 自身は @vbuterin/アカウント_abstraction_roadmap">multiple で 4337 中心の AA ロードマップを推進してきましたが、全体としては、カンファレンス、オンラインフォーラム、ACD ミーティングで 4337 中心の AA ロードマップを擁護しているのは、主に 4337 チーム、特に Yoav と Dror でした。

しかし、これらの努力にもかかわらず、4337中心のAAロードマップに対して、一部のコア開発者から強い反対がありました。彼らは、クライアントが最終的に実装しなければならない4337のネイティブバージョンである7560は、過度に複雑であり、「AAエンドゲーム」の唯一の実行可能な候補ではないと感じました。最終的にACDは、4337チームの反対にもかかわらず、代替案と@yoav/3074-implications">非分散型AA技術スタックを作成することでAAエコシステムを断片化するという4337チームの反対にもかかわらず、3074を承認することを決定しました。

しかし、3074が承認されると、4337コミュニティ全体から強い反応があり、コア開発者は3074の議論に再び参加することを余儀なくされました。その後、の議論は膠着状態となり、4337人の著者も3074人の著者もお互いを納得させることができず、11時間目にVitalikがやってきて、4337中心の「AAエンドゲーム」と明確に互換性のある3074の代替案としてEIP-7702を提案し、それによってAAロードマップを支持するように対立を推し進めた。

ヴィタリックの役割

ヴィタリックは自らを研究者として扱っているが、この物語は、ヴィタリックが他の研究者とは質的に異なる統治力をもたらしていることを明確に示している。そこで、ヴィタリックはイーサリアムのガバナンスにおいてどのような役割を果たしているのかという疑問

個人的には、ヴィタリックを非常に大きな会社のCTOと考えるとわかりやすいと思います。

(ちなみに、この例えでは、この会社にはCEOはいません。

たとえば、50人以上の従業員を抱えるテクノロジー企業で働いたことがある場合は、CTOがすべての技術的決定に関与することはできないことをご存知でしょう。一定の規模になると、技術的な意思決定は必然的に分散化されます — 通常、会社の製品の各領域にはサブチームがあり、サブチームは特定の実装の詳細に関して独自の決定を下すことができます。

さらに、CTOは必ずしもすべての(または任意の)主題の第一人者であるとは限りません。特定の分野でCTOよりも優れたエンジニアが会社にいる可能性が非常に高いです。したがって、技術的な議論では、最終的な決定を下すのはエンジニアであることがよくあります。

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

これは完璧な例えではありませんが、エコシステムにおけるヴィタリックの役割を合理的に捉えていると思います。ヴィタリックは、すべての技術的な決定に関与しているわけではありません。また、彼はすべての分野でトップの専門家でもありません。しかし、彼はイーサリアムのすべての重要な側面(スケーリング、AA、プルーフオブステークなど)のロードマップの設定に圧倒的な影響力を持っており、それは彼の技術的な専門知識だけでなく、ロードマップがイーサリアムのビジョン、つまり彼のビジョンと一致しているかどうかの最終的な判断者でもあるからです。

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

ヴィタリックがイーサリアムのCTOであるという私の見解があなたにとって十分に議論の余地がないなら、ここに最も物議を醸す部分があります:私たちはヴィタリックをCTOとして受け入れるべきです。

スタートアップの創業者としての私の意見では、成功するすべての製品の背後には、イーサリアムは実際の人々の実際の問題を解決するという意味で「製品」であり、首尾一貫したビジョンが必要です。そして、首尾一貫したビジョンは、スタートアップの創業者など、必然的に少数の人々によって設定されなければならず、多くの場合、たった一人の創業者によって設定されなければなりません。

イーサリアムの美しさは、非常に多くの可動部品を持つ非常に複雑なシステムであるにもかかわらず、部品が毎日数十億ドル相当の価値を動かしている機能する分散型コンピューターに見事に適合していることです。そして、私たちがここまでたどり着いたのは、委員会による設計によるものではありませんでした。ヴィタリックのビジョンを通じた積極的なリーダーシップのおかげで、今日のイーサリアムという首尾一貫した美しい製品にたどり着くことができました。イーサリアムは2015年にヴィタリックの発案によるもので、今日もそうです。

もちろん、これは、イーサリアムを今日の場所に導いた功績のほとんどに値する他の研究者やエンジニアの貢献を軽視するものではありません。しかし、それはイーサリアムがヴィタリックのビジョンの実現であり、他の誰よりも桁違いであるという事実と相容れないものではありません。

そして正直なところ、あなたは文句を言うことができますか?イーサリアムのエコシステムのオープン性、検閲への抵抗、イノベーションのペースに惹かれたとき、それがヴィタリックのビジョンから始まったと不満を漏らしましたか?そう思っていなかったからそうしなかったのかもしれませんが、今はそう思っていて、本当に気にしていますか?

地方分権はどうですか?

しかし、しかし、あなたが言うように、地方分権はどうですか?一人の人がイーサリアムに対してそのような圧倒的な力を持っている場合、それが分散化されているとどのように主張できますか?

この質問に答えるには、@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274"> Vitalikによって書かれた、分散化の意味に関するこの古典的な記事に戻る必要があります。この記事の重要な洞察は、分散化には3つのタイプがあるということです。

• アーキテクチャの分散化:システムが機能しなくなるまでに、いくつのノードが侵害される可能性がありますか?
• 論理的分散化:システムのサブシステムは、システムの機能を維持しながら独立して進化できますか?それとも、緊密に連携する必要がありますか?
• 政治的地方分権化:最終的にこのシステムをコントロールする人や組織は何人いるのか?

これらの定義を考えると、イーサリアムは明らかにアーキテクチャ的に分散化されており、さまざまなコンポーネント(コンセンサスと実行など)間の強力な結合がないことを考えると、論理的にも分散化されていると言っても過言ではありません。

政治的分散化の観点から、良いニュースは、個人や組織がイーサリアムをシャットダウンすることはできないということです。しかし、イーサリアムは、ヴィタリックがビジョンを設定し、それによってロードマップを定義する上で果たす重要な役割を考えると、思ったほど政治的に分散化されていないと主張することができます。

しかし、イーサリアムに革新を続けさせたいのであれば、たとえそれが政治的分散化を犠牲にすることを意味するとしても、ヴィタリックを事実上のCTOとして受け入れなければならないというのが私の意見です。

イーサリアムがビットコインのようなほとんど不変のブロックチェーンに「骨化」した場合、ヴィタリックは引退する可能性があります。しかし、その終盤に到達する前に、技術的なメリットだけでなく、イーサリアムのビジョンと一致しているかどうかに基づいて技術的な決定を判断する信頼できる、すべての関係者が尊重する権威があることが重要です。

ヴィタリックのような人物がいなければ、2つの結果しか得られず、どちらもこの3074の物語で鮮やかに描かれています。

• イーサリアムのガバナンスは、ヴィタリックが入ってくるまで3074の議論が膠着状態にあったことからわかるように、どちらの側も妥協することをいとわず、誰も進歩できない無限の行き詰まりに溶ける可能性があります。
• あるいは、イーサリアムは、3074と4337がほとんど互換性のない2つの並列AAスタックとして機能することにどれだけ近づいたかが示すように、一貫性のない設計のフランケンシュタインモンスターになる可能性があります。

コミュニティの役割

私たちは、イーサリアムガバナンスの完全なメンタルモデルを持つことに非常に近づいていますが、これまでの議論から明らかな欠落が1つあります。

ヴィタリックがビジョンを定義し、その後に研究者が定義したロードマップが続き、コア開発者によって実装されるとしたら、コミュニティはどのような役割を果たすのでしょうか?確かに何もないのではないでしょうか?

幸いなことに、コミュニティは実際には最も重要な役割を果たしています。その理由は、ビジョンがある前に、価値があるからです。私たちは皆、特定の価値観のもとに結集したからこそ、コミュニティとして団結したのであり、最終的にはヴィタリックのビジョンと一致していなければ、コミュニティを失うことになるのです。

もしかしたら、それはあなたの生い立ちのせいかもしれません。もしかしたら、前職で起こったことかもしれません。しかし、ある時点で、イーサリアムコミュニティの私たち全員が、すべての人がアクセスでき、検閲されず、信頼できる中立的な分散型コンピューターを持つことが世界にとって良いことだと判断しました。私たちは日々、イーサリアム上での作業を通じてこれらの価値を主張し、肯定し、そうすることで、Vitalik、研究者、コア開発者が作成したビジョン、ロードマップ、コードに正当性を提供します。

• 積極的に採用が検討されているEIPの可視性を高める必要があります。コミュニティ全体は、3074の場合のように、EIPが受け入れられることに「驚かされる」べきではありません。
  • 予想に反して、EIPサイトののEIPの「ステータス」は、ACDプロセスのステータスを反映していません。そのため、コア開発者がすでに承認に投票しているにもかかわらず、3074は「レビュー中」であり、そもそも含めることが検討されているという兆候はさらに少なくなっています。
  • 理想的には、EFは、EIPが受け入れられようとしているときにソーシャルメディアで大声で明確にし、コミュニティの意識を高めることです。
• コア開発者は、特定のEIPが下流のプロジェクトとユーザーに与える影響を過小評価することがあり、これは3074と4337コミュニティの場合です。ACD会議は時間が限られており、タイムゾーンをまたいで調整する必要があるため、当然のことながら、「関係者」のみが会議で発言する必要があることが強調されています。そうは言っても、コミュニティメンバーが特定のEIP提案の下流への影響についてコメントするために、時々時間を割り当てることは理にかなっているかもしれません。
  • 4337チームの場合のように、研究者が自分の意見がコア開発者に受け入れられていないと感じた場合、コミュニティメンバーを呼びかけに巻き込んで主張を強化することができます。
• 重要なことは、コア開発者と研究者の間で、強みは異なるものの、どちらもガバナンスの力であるという相互認識が必要です。コア開発者の「クライアントパワー」は、クライアントを実装することで実際に「投票」できる唯一のパワーです。研究者の「ロードマップパワー」は、通常、研究者がロードマップについて積極的に話したり書いたりしたおかげで、より多くの公的なサポートを享受しています。
  • この2つの力が対立している場合、コア開発者が4337チームからの反対意見を覆す場合など、コア開発者は単に研究者を上書きしたくなることがあります。しかし、そのようなオーバーライドは、3074が承認された後のその後のドラマからわかるように、権力が対立しているときに不安定になるため、むち打ち症になる可能性があります。
  • 同様に、抵抗に直面すると、研究者はコア開発者との関わりをあきらめたくなることがありますが、IMOは、RIPプロセスが作成された理由の1つであり、ネイティブAA(7560)が現在、EIPではなくRIPとして主にプッシュされている理由の1つです。L2がL1にとって物議を醸しているプロトコルの更新を試すのを支援することには本当の利点がありますが、RIPをEIPガバナンスプロセスへの関与に代わるものと見なすことはできません。研究者は、コア開発者がロードマップと完全に一致するまで、彼らと関わり続けなければなりません。

結論

3074/7702の物語は、イーサリアムガバナンスが実際にどのように機能するかに光を当てています — コア開発者によって推進されるEIP/ACDプロセスである明示的なガバナンス力に加えて、研究者によって推進されるロードマップの暗黙のガバナンス力もあります。これらの力がずれてしまうと、行き詰まりやむち打ち症が起こり、別の力であるヴィタリックがバランスを崩す可能性があります。

次に、ヴィタリックはイーサリアムの「ビジョン」である明確な力を表しており、ロードマップの正当性の基礎であると主張します。ヴィタリックを大企業のCTOと比較し、イーサリアムが一貫性のない設計のフランケンシュタインシステムに退化することなく、イノベーションのペースを維持するためには、疑似CTOとしての彼の役割が必要であることを認めます。

最後に、VVRCとしてのイーサリアムガバナンスについて考えるためのメンタルモデル、つまり、価値(コミュニティ)⇒ビジョン(Vitalik)⇒ロードマップ(研究者)⇒クライアント(コア開発者)を提示します。次に、プロセスが実際にこのモデルから逸脱する原因となる「バグ」を修正するためのさまざまな方法を提案します。

イーサリアムガバナンスは「マシンを構築するマシン」であり、イーサリアム正しく行うには、ガバナンスを正しく行う必要があります。このように、3074はガバナンスがうまくいかなかったときの非常に貴重なケーススタディを提供し、将来のイーサリアムガバナンスを改善するために、そこからいくつかの有用な教訓を引き出すことができたことを願っています。

免責事項:

1. この記事は [zerodev] からの転載です。すべての著作権は原著作者に帰属します [derek]。この転載に異議がある場合は、Gate Learnチームまでご連絡いただければ、迅速に対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。特に明記されていない限り、翻訳された記事のコピー、配布、盗用は禁止されています。