Vitalikとさまざまなロードマップがイーサリアムのガバナンスに与える影響を深く探る

原文タイトル： 《 3074サーガに続くイーサリアムガバナンスに関する考察》

著者： デレク・チアン、ZeroDev創設者

編纂： ファウスト、ギークweb3

要約：この記事は、ZeroDevのCEOデレク・チアンが、V神がERC-4337とEIP-3074の矛盾を調整するためにEIP-7702を提案した後、この件についての見解を述べたものです。この記事は、AAエコシステム内のプロジェクト創設者の実体験を基に、イーサリアムの現在のガバナンスモデルとその痛点を客観的に指摘し、鋭く指摘しています：

イーサリアムのさまざまなガバナンスの矛盾の一つは、研究者が確定したロードマップとGethなどのクライアント開発チームの見解に相違があり、ビタリックがCTOのような役割を果たして最終的な決定を下すことです。

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

本文：もしあなたが以前にイーサリアムAA（アカウント抽象）の関連イベントについて知らなかった場合、ここに簡単な振り返りがあります：

数週間前、EIP-3074提案がイーサリアムのコア開発者によって承認され、次回のハードフォーク「Pectra」に組み込まれることになりました。この提案はEVMに2つの新しいオペコードをもたらし、イーサリアムのEOAアカウントにほぼネイティブなAA体験を提供します。

それ以来、ERC-4337コミュニティの多くの人々、特に4337の提案者たちはEIP-3074に強く反対しています。その理由は、この提案が多くのセキュリティリスクをもたらし、イーサリアムのAAロードマップと互換性がないことを懸念しているからです。イーサリアムの以前のロードマップでは、ERC-4337および類似の提案7560（別名「nativeAA」）を中心に明示されています。

5月初め、ビタリックはEIP-7702をEIP-3074の代替案として提案し、4337と3074の間でバランスを取ることに成功しました------EOAユーザーにAAの体験を提供しつつ、ある程度ERC-4337とより互換性があり、「AA最終案」7560とも互換性があります。

現在、イーサリアムのコア開発者たちは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の著者）は、「4337支持者」の責任だと考えています。なぜなら、彼らは全体のコア開発者（ACD）議論プロセスに積極的に参加しなかったからです。このプロセスでは、EIPは長時間の審議を経て、最終的にGethなどのイーサリアムクライアント開発チームに受け入れられ、実装されます。

3074提案が審議されている間、「4337支持者」は完全に参加し、自分たちの意見を表明することができたはずだと考える人もいます。3074が承認された後に後出しジャンケンをするのではなく。結局、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会議の場面を想像してみましょう。そこでコア開発者たちがイーサリアムのスケーラビリティについて議論しています：

· あるコア開発者のボブ：私はEIP-1234を支持します。この提案は、ブロック生成速度を10倍にし、ブロックサイズを10倍にし、手数料を100倍に下げることを提案しています。

· 他のコア開発者たち：……あなたは狂っていますか？

考えてみましょう。なぜイーサリアムのコアチームはボブの言っていることを拒否するのでしょうか？彼は非常に合理的に見えるスケーラビリティの方法を提案しただけであり、SolanaやAptos、Suiなど多くのパブリックチェーンがそうして高いTPSを達成しています。

理由は、この架空のEIP-1234がイーサリアムの「ロールアップ中心」のスケーラビリティロードマップに反しているからです。このロードマップは、分散化にとって、一般ユーザーが低コストでノードを運営できることが重要であると述べています。したがって、架空のEIP-1234は受け入れられることは不可能です。なぜなら、それはイーサリアムノードの運営コストを大幅に増加させるからです。

この例を用いて、ACDガバナンスプロセスに参加し、プロトコルの更新を決定するコア開発者は、より高次の力「ロードマップ」に導かれていることを示したいと思います。現在、イーサリアムのロードマップには「スケーラビリティロードマップ」、「AAロードマップ」、「MEVロードマップ」などがあり、これらはイーサリアムの全体的なロードマップを構成しており、コア開発者はこれに基づいて意思決定を行わなければなりません。

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

ロードマップはイーサリアムのガバナンスプロセスの正式な構成要素ではないため、コアチームがロードマップを遵守することが保証されるわけではありません。また、ロードマップを「承認」する正式なプロセスは存在せず、すべてのロードマップが同等の「正統性」を持つわけではありません。イーサリアムのロードマップの背後にいる研究者たちは、コア開発者やコミュニティに自分たちのロードマップを宣伝し、「正統性」を得るために努力しなければなりません。

AAとアカウント抽象に関しては、ビタリック自身が何度も4337を中心にしたAAロードマップを推進してきましたが、全体的には4337の背後にいるチーム、特にヨアブとドロールがフォーラムやACD会議で4337を中心にしたAAロードマップを提唱しています。

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

3074が承認された後、4337コミュニティ全体が強い反応を示し、イーサリアムのコア開発者は3074の議論に再び参加せざるを得なくなりました。議論はその後行き詰まり、4337の著者と3074の著者は互いに説得することができず、ビタリックは最後の瞬間にEIP-7702を3074の代替案として提案しました。この提案は、4337を中心にした「AAの最終形」と明確に互換性があり、対立を解消し、最終的な結果がAAロードマップに合致するようにしました。

ビタリックの役割：イーサリアムの実質的なCTO

ビタリックは研究者として自らを位置づけていますが、上記のストーリーは明確に示しています。ビタリックは他の研究者とは異なるガバナンス権限を持っています。では、ビタリックはイーサリアムのガバナンスにおいてどのような役割を果たしているのでしょうか？

私個人の見解としては、ビタリックを非常に大きな会社のCTOと見なすことは不適切ではないと思います（ちなみに、イーサリアムという「会社」にCEOがいないと仮定して、実際の状況に合わせています）。

もしあなたが50人以上の従業員を持つテクノロジー企業で働いたことがあるなら、CTOがすべての技術的な決定に関与することは不可能であることを知っているでしょう。会社の規模が一定のレベルに達すると、各技術的なソリューションの決定プロセスは必然的に分散化されます------通常、会社の製品/ビジネスの各分野には専属のチームがあり、そのチームは通常、ソリューションの詳細を自由に決定できます。

さらに、CTOがすべての（または任意の）トピックのトップエキスパートである必要はありません。会社の中には、特定の分野でCTOよりも優れたエンジニアがいるかもしれません。したがって、技術的な詳細のソリューションの議論において、最終的な決定を下すのは各エンジニアです。

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

これは完璧な類推ではありませんが、私はビタリックのイーサリアムエコシステムにおける役割を合理的に要約していると思います。ビタリックはすべての技術的な決定に関与することはありません------彼もそれに関与することはできません。また、彼はすべての分野のトップエキスパートではありません。しかし、彼はイーサリアムのすべての重要なソリューション（スケーラビリティ、AA、POSなど）のロードマップを策定する上で圧倒的な影響力を持っており、これは彼の技術的な専門知識だけでなく、「そのロードマップがイーサリアムのビジョン（彼のビジョン）に合致しているかどうか」を最終的に判断する者であるからです。

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

もし私がビタリックをイーサリアムのCTOと見なすことが不十分だと思うなら、最も論争の余地のある部分がやってきました：私たちはビタリックがCTOを務めることを受け入れるべきです。

スタートアップの創設者として、私はすべての成功した製品の背後には一貫した長期的なビジョンが必要だと考えています------そう、イーサリアムも「製品」であり、実際のユーザーの実際の問題を解決することができます。そして、一貫したビジョンは少数の人によって策定される必要があります。例えば、スタートアップの創設者によって、通常は一人の創設者によって。

イーサリアムの素晴らしさは、非常に複雑なシステムでありながら、これほど多くのコンポーネントが完璧に組み合わさり、数十億ドルの取引活動を毎日決済する良好に機能する分散型コンピュータを形成していることです。

私たちが今日に至るまでの道のりは、特定の委員会のソリューションデザインによってではなく、ビタリックがその先見の明を持って積極的なリーダーシップを発揮したからこそ、今日の一貫した美しいイーサリアムを構築できたのです。イーサリアムは2015年にビタリックが提案したアイデアであり、今もそうです。

もちろん、これは他の研究者やエンジニアの貢献を軽視するものではありません。彼らはイーサリアムの今日の成果に大部分を貢献しています。しかし、これは矛盾しません。なぜなら、イーサリアムはビタリックのビジョンの実現であり、他の誰のビジョンよりもはるかに大きな規模であるからです。

正直なところ、あなたはこれに不満を持つことができますか？あなたがイーサリアムエコシステムのオープン性、検閲耐性、革新のスピードに惹かれているとき、ビタリックのビジョンから始まったことに不満を持ったことはありますか？おそらく、あなたは不満を持っていないでしょう。なぜなら、あなたはそのことを考えたことがなかったからです------しかし、今あなたは考えましたが、本当にその問題を気にしますか？

去中心化はどう解決する？

しかし、あなたは言うでしょう、去中心化はどうなのか？もし一人の人間がイーサリアムに対して圧倒的な権力を持っているなら、どうしてそれが去中心化だと言えるのでしょうか？

この質問に答えるためには、ビタリックによる去中心化の意味に関する古典的な記事を振り返る必要があります。この記事の重要な洞察は、去中心化には3つのタイプがあるということです：

· アーキテクチャの去中心化：システムが停止するのは、いくつのノードが故障したときか？

· 論理的な去中心化：システムの各サブシステムは、システム全体が正常に機能するのと同時に独立して発展できるか？それとも密接に調整する必要があるのか？

· 政治的分権：最終的にこのシステムを制御するのは何人または何組織か？

これらの定義に基づくと、イーサリアムは明らかにアーキテクチャ的に去中心化されており、論理的にも去中心化されていると言えます。なぜなら、各コンポーネント間には強い結合がないからです（例えば、コンセンサス層と実行層）。

政治的な去中心化については、良いニュースは、誰もイーサリアムを閉鎖することができず、ビタリックでさえもできないということです。しかし、人々は、ビタリックがイーサリアムのビジョンとロードマップを策定する上で重要な役割を果たしているため、イーサリアムの政治的去中心化の程度は人々が想像するほど高くないかもしれないと考えるかもしれません。

しかし、私は、イーサリアムが引き続き革新を続けるためには、ビタリックが事実上のCTOを務めることを受け入れなければならないと考えています。たとえそれが政治的な去中心化のいくつかを犠牲にすることを意味する場合でも。

もしイーサリアムが本当にビットコインのように「硬直化」してほとんど変更不可能なブロックチェーンになった場合、ビタリックは直接引退するかもしれません。しかし、私たちがその最終的なステップに達する前に、すべての関係者が尊敬する権威を持つことが重要です。この権威は信頼でき、技術的な決定を判断することができる必要があります。これは、提案された技術的なソリューションが優れているかどうかだけでなく、これらの決定がイーサリアムのビジョンに合致しているかどうかに基づいています。

ビタリックのような人物がいなければ、2つの結果しか生じません。3074のストーリーはこれら2つの結果を生き生きと示しています：

· イーサリアムのガバナンスプロセスは無限の行き詰まりに陥る可能性があります。矛盾する両者は妥協することを望まず、誰も進展を得ることができません。これは、ビタリックが介入する前に3074の議論が行き詰まったことを示しています。

· または、イーサリアムは一貫性のない「フランケンシュタイン」（訳者注：SF小説『フランケンシュタイン』に描かれた怪物で、科学者が異なる死体の部分を組み合わせて「人」を作り出したもの）になる可能性があります。前述の3074と4337は互いに譲らず、最終的にAAエコシステムを完全に分断し、互換性のない2つの平行空間を生じさせるかもしれません。

コミュニティの役割

上記の考察を経て、私たちはイーサリアムガバナンスの思考モデルをほぼ描き出すことができましたが、これまでの議論には明らかな欠落があります------コミュニティです。

もしビタリックがイーサリアムのビジョンを定義し、研究者たちがロードマップを定義し、コア開発者がそのロードマップを実施するなら、コミュニティはどのような役割を果たしているのでしょうか？確かに何もしないわけではありませんよね？

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

イーサリアムコミュニティのすべての人々は、誰もがアクセスでき、検閲されず、信頼できる中立的な分散型コンピュータを持つことが世界にとって有益であると考えています。私たちは毎日イーサリアム上で行う作業を通じて、上記の価値観を維持し、確認し、ビタリック、研究者、コア開発者が策定したビジョン、ロードマップ、コードに正統性を提供しています。

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

したがって、ここにイーサリアムガバナンスの完全な思考モデルがあります。価値観⇒ビジョン⇒ロードマップ⇒クライアント、略してVVRC：

· V ==価値観==コミュニティ；

· V ==ビジョン==ビタリック；

· R ==ロードマップ==研究者；

· C ==クライアント==コア開発者；

これらは一緒に次のように機能します：

· コミュニティは特定の価値観の周りに団結します。

· ビタリックはこれらの価値観と一致するビジョンを表現します。

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

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

もちろん、現実はどんな単純なモデルが捉えることができるよりも複雑です。実際、イーサリアムのコア開発者は、クライアントコードの変更を通じて任意の提案に対して真に「投票」できる唯一の存在です。ビタリックや他の研究者はアドバイザーとしての役割を果たすだけであり、時には彼らの意見がコア開発者に受け入れられないこともあります。これがEIP-3074が承認された理由です。

とはいえ、私はVVRCモデルがイーサリアムのガバナンスモデルが通常どのように機能するかを合理的に捉えていると思います。そして、私たちはこのプロセスを「デバッグ」する必要があります。そうすれば、EIP-3074のような事故が再発しないようにできます。

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

今、私たちはイーサリアムのガバナンスプロセスがどのように機能するかについての心理モデルを持っています。ここにガバナンスプロセスを改善するためのいくつかのアイデアがあります。

審議中のEIPの議論の進捗の可視性を高める必要があります。コミュニティ全体がEIPが受け入れられることに「驚く」べきではありません。3074のような驚きを与える提案の承認方法は再発すべきではありません。

現在、EIPウェブサイト上のEIP「状態」は、ACDプロセスにおけるその状態を反映していません。これが、3074が「審査中」と表示され続ける理由です。コア開発者はすでにそれを承認する投票を行っており、最初から承認されることが考慮されていたという兆候すらありません。

理想的には、EIPが受け入れられそうなとき、イーサリアム財団はソーシャルメディアでその結果を明確に発表し、コミュニティの認識を高めるべきです。

時には、コア開発者が特定のEIPが下流のプロジェクトやユーザーに与える影響を過小評価することがあります。3074と4337コミュニティはその一例です。ACD会議の時間は限られており、時差を跨いで調整する必要があるため、会議では「関係者」だけが発言できることが多いです。

とはいえ、時折コミュニティメンバーに発言の時間を割り当て、特定のEIP提案が通過した後の下流への影響についてコメントすることも意義があります。

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

重要なのは、コア開発者と研究者が互いに認め合うことです。力は異なりますが、彼らはイーサリアムのガバナンス権力の一部です。コア開発者のイーサリアムクライアントの変更と更新の権限は、プロトコル自体に変更を加えることで「投票」する唯一の権限です。研究者のロードマップの変更と解釈の権限は、通常、より多くの公的支持を受けます。これは、研究者が自分たちの構想について積極的に話し、執筆することによるものです。

この2つの勢力が対立するとき、コア開発者は研究者の意見を直接覆す傾向があるかもしれません。例えば、コア開発者が4337チームの反対意見を覆したように。しかし、このような覆しは対立を引き起こす可能性があります。なぜなら、2つの勢力が対立すると不安定になるからです。3074が承認された後に起こった劇的な出来事がそのことを示しています。

同様に、抵抗に直面したとき、研究者はコア開発者との協力を放棄する傾向があるかもしれません。私の見解では、これがRIPプロセスを作成する理由の一つであり、ネイティブAA（7560）が現在主にRIPとしてではなくEIPとして推進されている理由でもあります。

L2でL1にとって議論の余地のあるプロトコル更新を試すことには確かに利点がありますが、私たちはRIPをEIPガバナンスプロセスへの参加の代替品と見なすべきではありません。研究者は、両者の価値観が完全に一致するまで、コア開発者と協力し続ける必要があります。

結論

3074/7702事件は、イーサリアムガバナンスの真の運営方法を明らかにしました------コア開発者が推進するEIP/ACDプロセスの顕在的なガバナンス権力の他に、研究者が推進するロードマップの潜在的なガバナンス権力が存在します。これらの権力が不一致になると、私たちは行き詰まりや圧力を目にし、別の力------ビタリック------が何らかの形でバランスを崩す必要があるかもしれません。

次に、私たちはビタリックがイーサリアムの「ビジョン」を代表する独特の力を持っていることを提案します。これは、あらゆるロードマップの正統性の基盤です。私たちはビタリックを大企業のCTOと比較し、彼が事実上のCTOとしての役割を果たすことがイーサリアムの革新のペースを維持するために必要であることを認めます。これにより、イーサリアムが「フランケンシュタイン」のような縫い合わせの怪物に退化するのを防ぐことができます。

最後に、私たちはイーサリアムガバナンスモデルを説明するVVRCモデルを提案しました：価値観（コミュニティ）⇒ビジョン（ビタリック）⇒ロードマップ（研究者）⇒クライアント（コア開発者）。次に、私たちはこのモデルの「エラー」を修正するためのさまざまな方法を提案しました。

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