Ethereum Governance Reflection：なぜEIP-3074事件に不満を抱いているのですか？

出典：Buyuは言った

この記事では、コンテンツのレビューをしてくれたVitalikとYoavに感謝します。

この事件がわからない場合は、ここでレビューしましょう

少し前まで、EIP-3074の提案はコア開発者の青信号を取得し、イーサリアムの次のハードフォークペクトラに実装する予定です。この提案の目的は、通常のEthereumアカウント（EOA）ユーザーがアカウントの抽象化の多くの便利さ（一般にAAと呼ばれる）を享受できるようにすることです。

しかし、ERC-4337コミュニティ、特に提案の起草者は、EIP-3074の提案に強い反対を表明しました。 。

先週、VitalikはEIP-3074としてEIP-7702の代替案を提案しました。また、EOAユーザーにアカウントの抽象化をもたらすことを目的としていますが、設計は現在のEIP-4337標準により適しており、最終的なForm-EIP-7560にスムーズに移行できます。

翻訳者のメモ：ERC-4337およびERC-7560は、ユーザーアカウント管理方法と相互作用方法を改善し、ユーザーエクスペリエンスとセキュリティを改善することを目的とした、Ethereum Ecosystemのアカウントに関連する要約です。

ERC-4337を使用すると、ユーザーはプロキシ契約を通じてアカウントを管理し、ユーザーDAPP相互作用の複雑さとリスクを軽減できます。ERC-7560は、ERC-4337などの提案の概念をEthereumの基本層に直接統合することを目的としています。これにより、すべてのアカウントが自然にアカウントを抽象化する能力を持ち、それによってより深い統合と最適化を提供することを目的としています。

ERC-4337は、ERC-7560に移行するための重要なステップです。

現在、コア開発者チームは正しいですEIP-7702議論のために、いくつかの初期の兆候とコミュニティのフィードバックは、EIP-7702がペクトラハードフォークのEIP-3074を置き換える可能性が高いことを示しました。

その結果、私は個人的に非常に満足していると感じています。EOAユーザーは、ERC-4337向けに作成されたツールとインフラストラクチャを使用して、アカウントの抽象化によってもたらされる多数の利点を享受しようとしています。

しかし、この目標を達成するプロセスは、それをリリースするのが難しくなります。より完全なプロセスがあれば、もともと乱れを減らし、より速くコンセンサスに到達することができると確信しています。

この記事では、次のように計画しています。

• プロセスに存在する問題の分析

• イーサリアムガバナンスの思考フレームワークを提出します

• 将来同じ間違いを繰り返すことを改善し、避ける方法について話し合う

なぜ不満を感じるのですか？

事件全体では、多くの人々が不満を感じさせ、いくつかの理由があります。

• 承認への長い道：EIP-3074は最終的に青信号を得るのに数年かかりました。

• フィードバックLAG：コア開発者は、3074が通過した後にのみ合格し、ERC-4337コミュニティから野党の声を聞くだけです。

• 早期警告は機能しませんでした。4337提案の著者は、コア開発者に関する懸念を繰り返し提案していますが、それはほとんど効果がありません。

• 文字列の変更はさらに大きくなります。これで、EIP-3074の取り消しに直面し、EIP-7702に置き換えます。

客観的に言えば、各リンクのみを読むことは不適切ではありません。

• 長期的な議論は合理的です。

• 承認後に反対に遭遇するのは普通です。

• 新しい問題が発生した場合、元の決定の調整とキャンセルさえも論理的です。

ただし、このプロセスがよりスムーズになる可能性があることに全員が同意する場合があります。物事がこのように発展するかどうか想像してみてください：

コア開発者がEIP-3074期間について議論した間に、ERC-4337コミュニティが積極的に参加しました。このようにして、可能な結果は2つしかありません。

• EIP-3074は、EIP-4337コミュニティのフィードバックを検討した後に承認されています（おそらく変更される可能性があります）、EIP-4337コミュニティはEIP-3074をサポートし、3074の決定を転覆させる必要はありません。

• あるいは、EIP-3074は承認されたことはありませんが、EIP-4337コミュニティはコア開発者と協力して、EIP-7702のように誰もが満足しているという提案を共同で促進します。

みんなの声が聞こえ、劇的な逆転はありませんでした。これは理想的な結末であるはずですが、なぜ失敗したのですか？

問題はどこにありますか？

プロセス全体に戻ると、双方が告発しています。

コア開発者（EIP-3074の著者）は、EIP-4337チームがAll Core Devsプロセス（一般にACDと呼ばれる）プロセスに積極的に参加している場合、問題は発生しないと感じています。

このプロセスでは、提案は長い間議論する必要があり、クライアントチームは最終的に契約を受け入れて統合します。彼らは、EIP-4337チームがいつでも関与していた可能性があり、EIP-3074が承認されるのを待つ代わりに懸念を提案することができると考えています。結局のところ、Ethereum Core Developer Conferenceのプロセスはオープンで透明性があり、会議は外の世界にも開かれています。EIP-4337チームが本当にそんなに気にかけている場合、参加するために時間を投資してみませんか？

それどころか、アカウントの抽象チーム（EIP-4337の著者）は、彼らが実際にEthereum Core Developer Conferenceに参加したことを強調し、EIP-3074に反対する各機会を押収しましたが、コア開発者には採用されていませんでした。EIP-4337コミュニティのメンバーは、一般的に驚いています。

さらに、Ethereum Core Developer Conferenceのプロセスは複雑すぎるという意見もあります。また、フルタイムの仕事をしていて、各ステップに追いつくことができない人のために参加することは困難です。他の人たちは、重要な関心（EIP-4337コミュニティなど）を積極的に勧誘する人々の意見は、Ethereum Core Developer Conferenceの責任であるべきだと考えています。

私の意見では、問題の核心は両側で完全に押収されていません。私たちがそれを解決するか、少なくともそれに直面しない限り、より深い問題があります。

パラナー

ガバナンスの失敗の真の核心は、誰もが一般的にEthereum Core Developer Conferenceを誤解していることです。Ethereum Core Developer Conferenceは、この場合の唯一の決定の唯一の決定ではありません。

問題は、この重要なガバナンス部隊は、アカウントの抽象化やスケーラビリティなど、イーサリアムの主要な問題であるが、公式に認識されることはめったにないということです。

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

要するに、3074から7702全体の嵐は、Ethereum Core Developer Conferenceに対する「ロードマップ」力の典型的なケースです。

ガバナンスの観点から見ると、目に見えない力を通して目に見えない力が覆われている場合、目に見えないものが失敗しているため、私たちは注意する必要があります。

ロードマップとは何ですか？

Ethereum Circleでは、ロードマップという用語は、Coreとしてのロードマップ、ETH 2.0ロードマップ、またはアカウントの抽象化ロードマップがこの時間の焦点について説明しました。

Ethereum Core Developer Meetingで、誰もがネットワークスケールを拡大する方法について議論していると想像してください。

コア開発者BOBの提案：私はEIP-1234をサポートしています。ブロック時間は10倍であり、トランザクション料金は100倍になることを提唱しています。

他の開発者は答えました：あなたは本気ですか？

ボブの提案がすぐに拒否された理由について考えてみてください。彼は効果的な容量拡張ソリューションを提案しました、そして、ソラナなどの他の公共チェーンが操作され、その効果は重要でした。

その理由は、ボブの提案とイーサリアムが容量拡張ルート図のコアとしてロールアップを遵守しているからです。このルートマップは、ブロックチェーンの分散特性を維持するために、通常のユーザーがノードを簡単に実行できることを強調しています。したがって、BOBの提案は、ノードを実行することの難しさを大幅に増加させましたが、これはルート図と一致しておらず、自然に除外されています。

この例を通じて、私が見せたいのは、Ethereum Core Developer Conferenceに参加し、契約の更新を担当するコア開発者が、実際にはより高いガイダンスの原則、つまり私が呼ぶロードマップに従うことです。拡張ロードマップ、アカウントの抽象的なロードマップ、MEVロードマップなど、さまざまなロードマップがあります。これらは、コア開発者の意思決定の基礎であるイーサリアムの全体的なロードマップを構成します。

コア開発者がロードマップと矛盾している場合

ルートマップは正式なガバナンスの一部ではないため、コア開発者は常にそれと一致するとは限りません。特に、「承認ロードマップ」などの公式プロセスがないため、すべてのロードマップが同じ程度の認識を享受するわけではありません。これには、ロードマップの背後にあるプランナーがコア開発者と大多数のコミュニティを積極的に促進し、認識を獲得し、コア開発者の認識とサポートを得る必要があります。

例として、VitalikはEIP-4337を中心としたロードマップを繰り返し尊重していますが、実際にはEIP-4337チーム、特にYoavとDrorを積極的に提唱しています。

ただし、一部のコア開発者は、EIP-4337を中心としたルートマップ（つまり、EIP-4337のネイティブバージョンを実現する必要があると考えています最終フォームを抽象化する唯一の方法。最終的には、EIP-4337チームはEIP-3074に反対していますが、別の分散アカウントの抽象的なテクノロジースタックの導入により、抽象的なアカウントエコロジーが分割されます。

しかし、EIP-3074が承認された後、EIP-4337コミュニティ全体の強い反対により、コア開発者がEIP-3074を再検討するよう促しました。双方の間の紛争は、VitalikがEIP-3074としてEIP-7702の代替案を重要な瞬間に提案するまででした。抽象的なロードマップに従う。

Vitalikの役割

Vitalikは研究者と見なされていますが、この事件から、彼がイーサリアムのガバナンスでユニークな役割を果たしたことがわかります。これは質問につながります：イーサリアムのガバナンスでVitalikはどのような役割を果たしていますか？

Vitalikは大企業のCTOとして想像できます。

50人以上などの特定のスケールのテクノロジー企業で働いていた場合、CTOはすべての技術的決定に参加できないことを理解できます。会社の規模の成長に伴い、技術的な決定が自然に広がり、さまざまな製品分野のサブチームは一般に特定の実装の詳細を決定できます。

さらに、CTOは必ずしもすべての分野でトップの専門家ではありません。いくつかの面でCTOよりも強力なエンジニアがいるかもしれません。したがって、技術的な紛争では、多くの場合、エンジニアの最終決定です。

ただし、CTOは会社の技術的ビジョンを策定する責任がありますが、特定の実行は開発者に引き渡されます。

この比phorは完全ではありませんが、イーサリアムエコシステムにおけるVitalikの役割を非常に正確に描写しています。

Vitalikはすべての技術的決定に参加しません – 彼はこれを行うことができず、彼はすべての分野のトップマスターではありません。しかし、彼はイーサリアムのすべての重要な側面（拡張、アカウントの抽象化、権利、利益など）に大きな影響を与えます。エーテルエーテリーと一致しています。

成功した各製品の背後にある原動力はビジョンです

起業家として、私はすべての成功した製品がその背後に明確なビジョンを持っていると思います。そして、このようなビジョンには、通常は設立チーム、そして1人の重要な創設者のみが確立されている人が少数の人々を必要とします。

イーサリアムの魅力は、マルチレベルシステムを含むこのような複雑な構造が、毎日大きな価値を循環する分散型コンピューターになるために協力できることです。これは委員会スタイルの決定に到達するものではありませんが、Vitalikのビジョンのリーダーシップのおかげで、今日は調整された効率的なイーサリアムがあります。2015年の概念から、イーサリアムは常にVitalikの知恵の具体化でした。

これは他の研究者やエンジニアの貢献ではなく、イーサリアムの発展に貢献しています。しかし同時に、イーサリアムが他の個人の影響をはるかに超えて、ヴィタリックのビジョンの究極の表示であることは否定できません。

正直に言って、イーサリアム、反レビュー、革新的な活力の開放性に参加するとき、あなたはすべてがVitalikで生まれた元のアイデアを気にしますか？

たぶん私は前にそれについて考えていなかったかもしれませんが、あなたはこれを理解した後に本当に気にしますか？

イーサリアムは明確なビジョンから生まれ、このビジョンを実現し続ける過程で成長し続けました。これが魅力です。

地方分権はどうですか？

あなたは、人がイーサリアムにそのような大きな影響を与えている場合、それが分散化されているとどのように言うことができますか？

この質問に答えるために、Vitalikが書いた古典的な記事を参照できます。これは、分散化の複数の意味を説明しています。この記事の重要なポイントは、分散化には3つの側面が含まれていることです。

1. アーキテクチャの分散化：動作を停止するために、いくつのノードが無効になっていますか？

2. ロジック分散化：システム全体に影響を与えることなく、システムは独立して進化できますか？

3. 政治的分散：このシステムを制御する人または団体は何人いますか？

イーサリアムは、多くのノード間に分散できるため、アーキテクチャとロジックでは間違いなく分散されており、異なるコンポーネント（コンセンサスメカニズムや実行層など）は比較的独立して発達する可能性があります。

政治的分散化に関しては、良いニュースは、Vitalikを含む単一のエンティティを閉じることができないということです。しかし、イーサリアムのビジョンと道路図を設定する際のVitalikの重要な立場は、政治的分散化に妥協があるかもしれないことを意味することは否定できません。

私の意見では、イーサリアムを革新させ続けるためには、これがある程度政治的な分散化を減らしたとしても、Vitalikを実質的なCTOの役割として受け入れるべきだということです。イーサリアムは、ビットコインの安定性までまだ成熟していない前に、非常に尊敬される権威ある人を持つ必要があります。イーサリアム。

Vitalikのような役割がなければ、Ethereumは2つのシナリオに直面する可能性があります。

1. 決定の行き詰まり：すべての当事者は妥協したくないので、EIP-3074の議論がVitalikの介入までデッドロックを壊さなかったように、プロジェクトは停滞しています。

2. デザインカオス：EIP-3074とEIP-4337の無限で互換性のない状況のように、システムは協調していない迷信体になる可能性があります。

したがって、イーサリアムの急速な進化の段階では、ヴィタリクのリーダーシップは、集中化され、方向感覚を失わない生態系を維持するために不可欠です。

コミュニティの重要性

この時点で、私たちはイーサリアムガバナンスの包括的な理解をほぼ構築しましたが、コミュニティの役割について言及していない議論の別の重要な部分があります。

Vitalikがビジョンを設定し、研究者がこれに従ってロードマップを計画した場合、コア開発者がその後実装されます。コミュニティはどのような役割を果たしますか？不可能ではありませんか？

実際、コミュニティは最も核となる役割を果たしています。ビジョンが形成される前に、より基本的なもの – 価値があるからです。これらの価値を共有するため、私たちはコミュニティに集まります。

それは、成長の背景の影響、またはEthereumコミュニティのすべての人が、誰もが瞬間に分散化することができ、本当に分散化することができないことを実現します。毎日のイーサリアムに関する私たちの仕事は、これらの価値の実践と肯定です。

Ethereum Governance簡略モデル：VVRCフレームワーク

慎重に設計されたマシンのようなイーサリアムのガバナンスを想像してください。VVRCモデルと呼ばれる値（ビジョン）、ビジョン、ロードマップ（ロードマップ）およびクライアント（クライアント）エッセンス

1. 価値：すべては、イーサリアムコミュニティが共有する一連の基本原則と信念から始まります

2. ビジョン：創設者として、コミュニティの価値に基づいたVitalikは、イーサリアムの将来の発展のビジョンを描いています。

3. ロードマップ：明確なビジョンにより、研究チームはこれらの夢を実現するための特定の手順を策定し始めます。彼らは、ターゲットに段階的に進むための技術的なパスを設計しました。

4. クライアント（クライアント）：最後に、コア開発者チームはコードを書き、ロードマップに基づいてクライアントソフトウェアを維持し、すべての技術計画が現実になり、ユーザーと開発者を実際に使用できるようにします。

このプロセスはスムーズに聞こえますが、実際にはより複雑になります。たとえば、コア開発者は、実際のソフトウェアの実現に責任があるため、実際に最終的な意思決定力を持っています。Vitalikと他の研究者は、EIP-3074事件に示されているように、提案をより提供することがあります。

一般に、VVRCモデルは、理想的な状況の下でイーサリアムがガバナンスに促進される方法を理解するのに役立ちます。

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

イーサリアムのガバナンス構造を最適化し、EIP-3074/ EIP-7702インシデントが回避されるようにするため。

1. EIPの透明性の向上：EIPがコミュニティに対してよりオープンで透明であると見なされていることを確認してください。EIP-3074の状況と同様の状況を避けてください。実際、EIPS WebサイトでマークされたEIPステータスは、Ethereum Core Developer Conferenceのレビューと同期されていません。 Ethereum Foundationを通過することをお勧めします。

2. コミュニティへの参加の強化：Ethereum Core Developer Conference会議でのDownstreemプロジェクトに対するEIPの影響について議論するために、コミュニティメンバーの特定の期間を設定します。同時に、研究者がEIP-4337チームが遭遇したジレンマのように、彼らのフィードバックがコア開発者によって評価されていないことを発見した場合、コミュニティのメンバーは自分の立場について議論するよう招待されるかもしれません。

3. 相互理解と継続的なコミュニケーション：コア開発者と研究者はお互いを理解しなければなりませんが、彼らは異なります。コア開発者は、実装クライアントを通じて「実行権」を持っています。これは、「投票権」を持つことに相当します。ロードマップを積極的に共有し、議論することにより、研究者はより広いコミュニティのサポートを受け、「ロードマップの影響」を形成しました。

両当事者の意見が一貫していない場合、コア開発者は、EIP-4337チームのために行うことをするのと同じように、研究者のアイデアを直接転覆する傾向があります。ただし、EIP-3074によって引き起こされるカオスが壊れると、2つの当事者間のパワーバランスが壊れるため、リバウンドを引き起こすのは簡単です。

逆に、研究者が抵抗に遭遇すると、これはEIPの代わりにRIPの理由の1つとして、RIP（ロールアップ改善提案）プロセス（EIP-7560）の誕生でもありません。 。

RIPは、L2がL1で採用するのが難しいプロトコルの更新を実験するのに役立ちますが、EIPガバナンスプロセスの参加を置き換えることはできません。研究者は、ロードマップが全会一致で認識されるまで、コア開発者とのコミュニケーションを遵守する必要があります。

上記の措置により、ガバナンスの透明性を強化し、コミュニティ参加、コア開発者と研究者の間の効果的な協力を強化し、将来の可能なガバナンスの問題を軽減できます。

要約します

EthereumのEIP-3074/EIP-7702イベントは、ガバナンス構造の複雑さを明らかにしています。正式なガバナンスプロセス（EIPおよびEthereum Core Developer Conferenceの提案に従ってコア開発者によって推進された）に加えて、研究者によって提案された非公式のロードマップも大きな影響を与えますエッセンスこれらの2つの力が調整されていない場合、それは決定を引き起こす可能性があります – デッドロックを作成するか、突然回します現時点では、Vitalikの役割は特に重要ですエッセンス

Taifangのガバナンスをモデルに簡素化します。コミュニティの価値→Vitalikのビジョン→リサーチチームのロードマップの実装→コア開発者の実装（VVRCモデル）。このチェーンは、決定が幅広いアイデアから特定の技術的実装に徐々に洗練される方法を示しています。

ガバナンスの効率を改善するためには、実際の運用においてこの理想的なモデルから逸脱する問題を変更する必要があります。結局のところ、優れたイーサリアムガバナンスは、プロジェクトの進歩を促進するためのコアメカニズムです。例として、EIP-3074イベントはガバナンスの弱点を暴露し、学習と改善の機会を提供し、将来、同様の課題に対処し、イーサリアムの持続可能で健康的な発展を促進することを保証します。