著者：デレク、ゼロデブCEO 出典：ゼロデブ公式サイト 翻訳者：グッド・オバ、ゴールデンファイナンス

AA案の大失敗を見逃しましたか？

• 数週間前、コア開発者はEOAユーザーにAAの多くの利点をもたらし、イーサの次のハードフォークに移行する提案であるEIP-3074を承認しました。フォーク「ペクトラ」。

• それ以来、ERC-4337コミュニティの多く、特に4337の作者自身は、4337とその従兄弟である7560（「ローカルAA」）を中心とするEtherのAAロードマップとの中心性と非互換性を理由に、3074に強く反対してきました。別名「ローカルAA」）。

• 先週、Vitalikは3074の代替としてEIP-7702を提案しました。これは本質的に同じ目標を達成するもので、AAの利点の多くをEOAユーザーにもたらすものですが、今日の4337との互換性がいくらか高く、「AAの残骸」との前方互換性があります。

• EIP-7702は現在コア開発者によって検討されていますが、初期の議論とコミュニティの感情では、EIP-7702はPectraのEIP-3074を置き換える可能性が高いようです。

• EIP-7702は現在コア開発者によって検討されていますが、初期の議論とコミュニティの感情では、EIP-7702はPectraのEIP-3074を置き換える可能性が高いようです。EIP-3074 in Pectra.

個人的には、この結果にとても満足しています。EOAユーザーは、ERC-4337のために構築されたツールとインフラを使用して、AAのほとんどの利点をすぐに享受できるようになります。

しかし、この結果を達成した方法は最適とは言い難いと感じざるを得ません。より良いプロセスがあれば、私たちは一丸となって多くのエネルギーと頭痛の種を節約し、望ましい結果をより早く達成することができると感じている。

このブログ記事で、私は次のことをしたいと思います：

• プロセスで何が間違っているのかを明らかにする。

• イーサネット・ガバナンスについて考えるためのメンタルモデルを提案する。

• 今後同様のガバナンスの失敗を避けるための改善策を提案する。

以下の理由で、全体が多くの人々を動揺させました:

• 一方で、4337 の authors 自身は、何度かコア コミュニティに対して 3074 に対する懸念を表明しています。

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

• 何年も時間をかけて議論することは許容されます。時間をかけて議論することは許される。

• EIPが承認後に遅延を受けることは容認される。

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

しかし、物事がもっとスムーズに進んだかもしれないという点では、おそらく同意できるでしょう。

• 4337コミュニティは、3074に関するコア開発者の議論に積極的に参加していました。

• 3074に関するコア開発者の議論に4337コミュニティが積極的に参加しました。その場合、4337コミュニティは3074をサポートし、私たちは3074を取り消しません。

• あるいは、3074は承認されませんでしたが、4337コミュニティとコア開発者が協力して、3074をサポートする提案を作成しました。開発者が協力して、7702のように誰もが満足する提案を作成しました。

全員の声が届き、劇的な逆転はありません。それは素晴らしいことだが、なぜそうならなかったのか？

何がいけなかったのか？

全過程を振り返ってみると、賛否両論がお互いを非難し合っている。

コア開発者たち（およびEIP-3074の著者たち）は、全コア開発者（ACD）プロセスに積極的に関与しなかった「4337人」のせいであり、EIPはリリースされるずっと前にレビューされていたと主張しました。EIPは発表される前に長い間検討された。EIPは最終的に顧客チームに受け入れられ、契約に実装されました。

「4337」は、3074がすでに承認されるまで待つのではなく、審議中のどの時点でも懸念を表明することができたと主張することができる。結局のところ、ACDのプロセスは十分に文書化されており、会議は誰にでも開かれている。もし4,337人がこの問題をとても気にかけているのなら、なぜ時間を割いて参加しないのだろうか？

一方、AAチーム（4337の作者）は、ACDミーティングに出席し、3074を延期するためにあらゆる機会をとらえているが、コア開発者は耳を傾けていないと指摘している。4337 コミュニティに関しては、彼らはほとんど油断していました - ほとんどの人は 3074 が死んだと思っていて、3074 が含まれるように積極的に検討されていることさえ知りませんでした。

また、多くの人が、ACDプロセスはあまりにも不透明で、「本当の仕事」を持ち、すべてのACDアップデートについていけない人たちの参加には不親切だと感じていました。また、関連する利害関係者（この場合は4337コミュニティ）からのフィードバックを積極的に求めるのはACDの責任であるべきだと考える人もいた。

しかし、私はどちらの意見も的外れだと思います。私たちがそれに対処するか、少なくともそれを認めるまでは、私たちは絶えずガバナンスの失敗に遭遇し、その後に無益な指弾を受けることになるでしょう。

根本的な原因

ガバナンスの失敗の本当の理由は、一般に信じられていることに反して、ACDがプロトコル更新の唯一のガバナンス権限ではないということです。その場合、ACDは別の統治権によって上書きされる。

問題は、ACDよりもイーサの最も重要な事項（AAやスケーリングなど）に影響力があるにもかかわらず、他の統治権がほとんど認識されていないことです。

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

これから論じるように、3074/7702の一連の騒動は、ACDの力に対するロードマップの力の一例に過ぎない。もし私たちがガバナンスについて話しているのであれば、目に見えない力が目に見える力を圧倒していることに気づくたびに、私たちはとても心配しなければならない。

ロードマップとは何か？

イーサリアムコミュニティにいる人なら誰でも、"ロードマップ "という言葉をよく目にしたことがあるでしょう。"Rollup-centric roadmap", "EtherCentric roadmap", "EtherCentric roadmap", "EtherCentric roadmap", "EtherCentric roadmap", "EtherCentric roadmap", "EtherCentric roadmap", "EtherCentric roadmap", "EtherCentric roadmap", "EtherCentric roadmap"."、"ETH2.0ロードマップ"、またはこの場合は" AAロードマップ "です。



私の主張を説明するために、コア開発者がイーサをスケールする方法について議論しているACDミーティングを想像してみましょう:

• コア開発者Bob: 私はEIP 1234に賛成です。これは、ブロック時間を10倍高速化し、ブロックサイズを10倍大きくし、手数料を100倍削減することを提案しています。

• 他のコア開発者：......正気ですか？

少し考えてみましょう。なぜコア開発者たちは、ボブが言ったことに真っ向から拒否権を発動したのでしょうか？solanaや他の多くのL1がこれを行い、素晴らしいスケーリングを実現しています。

その理由はもちろん、この架空のEIPがイーサ自身の「ロールアップ中心」のスケーリングロードマップに反するからです。したがって、架空のEIPは、ノードを実行するための障壁を大幅に増やすことになるため、不可能です。

この例で説明したいのは、ACDプロセスに関与し、プロトコルの更新を決定するコア開発者は、私がロードマップと呼ぶ、より高い力によって導かれているということです。拡張のロードマップ、AAのロードマップ、MEVのロードマップ、思いつくものは何でもありますが、それらが一緒になって、コア開発者の決定のためのEtherロードマップを形成します。

コア開発者がロードマップに沿わない場合

ロードマップは正式にガバナンスの一部ではないので、コア開発者がロードマップに沿うという保証はありません。ロードマップと一致しているという保証はありません。特に、ロードマップを「承認」するための正式なプロセスがないため、すべてのロードマップが同じように正当なものとみなされるわけではない。ロードマップの背後にいる研究者は、コア開発者やより広いコミュニティに自分のロードマップを宣伝し、コア開発者からの支持と正当性を得るために努力する必要があります。

AAの場合、Vitalik自身は何度か4337を中心としたAAロードマップを推していますが、一般的には4337チーム、特にYoavとDrorがカンファレンスやオンラインフォーラム、ACDミーティングに参加しています。

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

しかし、3074が承認された後、4337コミュニティ全体から強い反発があり、コア開発者は3074の議論に再び参加することを余儀なくされました。その後、議論は膠着状態に陥り、4337の作者も3074の作者も相手を説得することができなかった。最後の最後でVitalikが介入し、3074の代替案としてEIP-7702を提案した。これは、AAロードマップに有利に紛争を押し進めた。

ヴィタリックの役割

ヴィタリックは自らを研究者と位置づけていたが、この武勇伝は、ヴィタリックが他の研究者とは異なる何かをもたらしたことを明らかにしている。ヴィタリクは、他の研究者とはまったく異なる統治力をもたらしている。イーサのガバナンスにおけるヴィタリックの役割とは何なのか？

個人的には、ヴィタリックを超大企業のCTOと考えると役に立つと思います。

（ちなみに、この例えの目的上、この会社にはCEOはいません。）

従業員50人以上のハイテク企業で働いたことがある人なら、CTOがすべての技術的決定に関与できないことを知っているでしょう。ある程度の規模になると、技術的な決定は必然的に分散化されます。通常、会社の製品の各領域にはサブチームがあり、サブチームは実装の詳細について基本的に自由に決定することができます。

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

しかし、CTOは会社の技術ビジョンを設定する。ビジョンの実行は開発者に任される。

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

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

ヴィタリックがイーサのCTOであるという私の意見が、あなたにとって十分に物議を醸すものでなかったとしたら、ここにそれがあります。

スタートアップの創業者として、私は成功した製品の背後には-そう、イーサは「製品」なのだ。

スタートアップの創業者として、私は、成功する製品の背後には--そう、Etherは現実の人々の現実の問題を解決するのだから「製品」なのだ--首尾一貫したビジョンがなければならないと思う。首尾一貫したビジョンは、スタートアップの創業者のような少数の人々、通常はたった一人の創業者によって開発されなければなりません。

イーサの素晴らしさは、非常に多くの可動部分がある複雑なシステムであるにもかかわらず、それらの部分が完璧に組み合わさって、毎日何十億ドルもの価値を動かす完全に機能する分散型コンピューターになっていることです。私たちは、委員会の設計によってここまで来たわけではありません。ヴィタリックのビジョンによる積極的なリーダーシップのおかげで、今日のイーサという首尾一貫した美しい製品を実現することができたのです。イーサは2015年のヴィタリックの発案であり、現在もそうである。

もちろん、これは他の研究者やエンジニアの貢献を軽視するものではありません。しかし、これはイーサがヴィタリックのビジョンの実現であり、他の誰のビジョンよりも桁違いに実現されているという事実と矛盾するものではない。

正直に言って、あなたは文句を言えますか？あなたはイーサリアムのエコシステムにおける開放性、検閲への耐性、革新のペースに魅力を感じていますが、それがヴィタリックのビジョンから始まったことに文句を言うのでしょうか？もしかしたら、あなたはそう思っていなかったからそうしなかったのかもしれません - しかし今、そう思うようになった今、あなたは本当に気にしますか？

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

しかし、しかし、しかし、あなたはこう言う。一人の人間がイーサに対して圧倒的な力を持っているのであれば、分散化されていると言えるのでしょうか？

その疑問に答えるには、咳嗽ヴィタリックによる分散化の意味に関するこの古典的な記事に戻る必要があります。

• アーキテクチャの分散化：システムが機能しなくなる前に、いくつのノードが危険にさらされるか？

• 論理的分散化：システムを稼働させながら、システムのサブシステムは独立して進化できますか？それとも密接に連携しなければならないのか？

• 政治的分散：最終的に何人の人々や組織がシステムをコントロールするのか？

これらの定義を踏まえると、イーサは明らかにアーキテクチャ的に分散化されており、そのコンポーネント間の強い結合がない（例えば、コンセンサス対実行）ことを考えると、論理的にも分散化されていると言えるでしょう。

政治的な非中央集権に関しては、良いニュースは、個人も組織もイーサをシャットダウンできないということです。しかし、Etherのビジョンを設定し、そのロードマップを定義するVitalikの役割を考えると、Etherは思ったほど政治的に非中央集権的ではないと主張する人もいるかもしれない。

しかし、イーサが革新を続けることを望むのであれば、政治的な非中央集権をいくらか犠牲にすることを意味するとしても、事実上のCTOとしてヴィタリックを受け入れなければならないと思います。

イーサが「骨化」してビットコインのような事実上不変のブロックチェーンになれば、おそらくヴィタリックは引退するだろう。しかし、その最終段階に至る前に、技術的な決定をそのメリットだけでなく、Etherのビジョンに合致しているかどうかを人々が信頼する、尊敬される権威を持つことが重要だ。

ヴィタリックのような人物がいなければ、2つの結果しかありえません。

• エーテル・ガバナンスは、ヴィタリックが介入するまで3074年の議論が袋小路にあったように、どちらの側も妥協する気がなく、誰も進展させることができないまま、延々と袋小路にある可能性があります。

• あるいは、3074 と 4337 を 2 つのほとんど互換性のない並列 AA スタックとして扱うことで、私たちが実証する寸前まで行ったように、Ether は、支離滅裂な設計のフランケンシュタインの怪物になってしまうかもしれません。

コミュニティの役割

イーサリアムのガバナンスの完全なメンタルモデルを持つまであと少しです。には、コミュニティという欠落があります。

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

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

もしかしたら、これはあなたの生い立ちかもしれない。もしかしたら、これはあなたの前の職場で起こったことかもしれない。しかしある時点で、イーサリアムコミュニティの誰もが、誰もがアクセスでき、検閲されておらず、信頼できる中立的な分散型コンピュータを持つことは、世界にとって良いことであるということに同意しました。私たちはイーサで行う仕事を通じて日々これらの価値観を支持し、確認し、そうすることでヴィタリックや研究者、コア開発者によって生み出されたビジョン、ロードマップ、コードに正当性を提供しています。

イーサ・ガバナンスのVVRCモデル

それではここに、イーサ・ガバナンスの完全なメンタルモデルを示します。

• V == Values == Community

• V == Vision == Vitalik

• R == Roadmap == Researchers

• C == Clients == Core Developers

• コミュニティは特定の価値観のもとに集まります。

• ヴィタリックは、これらの価値観に沿ったビジョンを明確にしています。

• 研究者は、ビジョンに基づいてロードマップを開発した。

• コア開発者はロードマップに基づいてクライアントを実装しました。

もちろん、現実はどんな単純なモデルでもとらえることができるよりもはるかに厄介です。たとえば、現実には、実装クライアントを通じてどのような決定に対しても「投票」できるのはコア開発者だけであり、Vitalikや他の研究者は助言的な役割しか持っておらず、時には彼らの意見がコア開発者に受け入れられないこともあり、それが3074が承認された理由です。

つまり、VVRCモデルは、イーサネットガバナンスが良い状況下でどのように機能するかを捕捉する合理的な仕事をしていると思います。

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

イーサガバナンスがどのように機能すべきかのメンタルモデルができたので、3074のように失敗しないようにガバナンスプロセスを改善するためのアイデアをいくつか紹介します。3074/7702で経験したようなむち打ちを回避できるよう、ガバナンス・プロセスを改善するためのアイデアをいくつか紹介します。

• 積極的に参加を検討されているEIPは、より多くの可視性を持たなければなりません。コミュニティ全体は、3074の場合のように、EIPが受け入れられることに「驚くべきではない」。

• あなたの期待に反して、EIPサイトにおけるEIPの「ステータス」は、あなたが期待するようなものではありません。EIPサイトの "ステータス "はACDプロセスのステータスを反映していません。それが、コア開発者がそれを承認することに投票し、それが含まれるために検討された形跡がほとんどないにもかかわらず、3074がまだ「検討中」と書かれている理由です。

• 理想的には、EIPが受け入れられそうになったとき、EFはコミュニティーの意識を高めるために、メッセージをはっきりとソーシャルメディアに投稿したことでしょう。

• コア開発者は、3074および4337コミュニティの場合のように、特定のEIPが下流のプロジェクトやユーザーに与える影響を過小評価することがあります。ACDミーティングは時間が限られており、タイムゾーンをまたいで調整しなければならないため、ミーティングで発言すべきは「利害関係者」のみであることを強調するのは理解できる。とはいえ、コミュニティメンバーが特定のEIP提案の下流への影響についてコメントできるよう、たびたび時間を割くことは意味のあることかもしれない。

• 研究者たちが、中核となる開発者たちが自分たちの意見を受け入れてくれないと感じた場合（4337の場合がそうでした）。がそうであったように）、コミュニティのメンバーを巻き込んで、自分たちの視点を強化することができます。

• コア開発者と研究者が、異なる強みを持つとはいえ、お互いを統治力として認識することは非常に重要です。コア開発者の「クライアント側の力」は、クライアントを実装することで真に「投票」できる唯一の力です。研究者の「ロードマップの力」は、研究者が積極的にロードマップについて話したり書いたりしているため、通常はより多くの公的な支持を得ている。

• 2つの権力が衝突するとき、コア開発者が研究者を単に覆すことは簡単です。例えば、コア開発者が4337チームの反対意見を覆すような場合です。しかし、3074が承認された後に起こったドラマが示しているように、権力は対立すると不安定になるため、そのような上書きは権力の衝突につながる可能性があります。

• 同様に、抵抗に直面したとき、研究者がコア開発者と関わることをあきらめるのは簡単です。これは、RIP プロセスが作成された理由の 1 つであり、ネイティブ AA (7560) が現在、RIP ではなく、主に RIP としてプッシュされている理由の 1 つであると私は考えています。EIP. L2がプロトコルのアップデートを試すのを支援することには実際の利点がありますが、RIPをEIPガバナンス・プロセスに参加することの代替とみなすことはできません。研究者は、ロードマップに完全に準拠するまで、コア開発者と協力し続けなければなりません。

結論

3074/7702の武勇伝は、イーサガバナンスの本当の仕組みを明らかにしました。コア開発者によって推進される EIP/ACD プロセスの明確な統治力に加え、研究者によって推進されるロードマップの暗黙の統治力があります。これらの力のバランスが崩れたとき、私たちは膠着状態とむち打ちを見ることになる。

そこで私たちは、ヴィタリックがイーサの「ビジョン」というユニークな力を代表しており、それがあらゆるロードマップの正当性を支えていることを示します。私たちはヴィタリックを大企業のCTOと比較し、疑似CTOとしての彼の役割は、イーサが支離滅裂なフランケンシュタイン・システムの設計に陥ることなくイノベーションのペースを維持するために必要であることを認めます。

最後に、私たちはイーサのガバナンスをVVRCとして考えるモデルを提案します：価値観（コミュニティ）⇒ビジョン（ヴィタリック）⇒ロードマップ（研究者）⇒顧客（コア開発者）。そして、実際にプロセスがこのモデルから逸脱する原因となる「間違い」を修正する方法を提案します。

イーサのガバナンスは「マシンを構築するマシン」であり、イーサを正しく理解するためには、ガバナンスを正しく理解しなければなりません。このように、3074はガバナンスがうまくいかないとどうなるかという貴重なケーススタディを提供しており、私はそこから有益な教訓を引き出すことができたと思います。