# イーサリアムガバナンスの論争：EIP3074とEIP7702の争いイーサリアム最近の重大アップグレードPectraで複雑なガバナンスの対立が発生しました。EIP3074がアップグレード計画に組み込まれた後、特にERC4337チームからの強い反対があり、大きな議論を引き起こしました。EIP3074は膠着状態に陥り、ガバナンスプロセスは続行できなくなった。VitalikがEIP7702を提案するまで、ERC4337チームのEIP3074に対する疑念は最終的に収束しなかった。この論争は、イーサリアムのガバナンスの深い問題を反映しています - 「コードは法律である」という前提の下で、具体的なコードの内容を決定する権限は誰にあるのか。EIP3074とEIP7702の争いは、イーサリアム内部の実際のガバナンスプロセスを観察する視点を提供してくれます。ZeroDevの分析によると、イーサリアムが実際に採用しているのはVVRCガバナンスモデルです。すべての提案はまずイーサリアムの価値観(Value)に適合する必要があり、その後Vitalikのビジョン(Vision)に反映され、次にロードマップ(Roadmap)に示され、最終的にコア開発者による議論の後、クライアント(Client)に実装されます。GCC Researchが以前に分析したEIP2537は、クライアントレベルでの実装問題が発生し、ハードフォークへの参加が遅れました。一方、EIP3074はビジョンとロードマップの問題により、最終的にハードフォークに組み込まれませんでした。イーサリアムのコア開発者は、最終的にVitalikが作成したEIP7702をアカウント抽象化の方案として選びました。! [イーサリアムガバナンス戦争:EIP3074、ERC4337、EIP7702](https://img-cdn.gateio.im/social/moments-c58ef9bbf5ae3b665e03f7456daa1e7c)## EIP3074、EIP7702、ERC4337の紹介EIP3074は実行層の提案であり、ノードソフトウェアのアップグレードが必要です。その核心的な目的は、ガス代の支払いとバッチトランザクション機能を実現することです。ユーザーは任意のトークンを使用してガス費を支払ったり、オフラインで支払ったりすることができます。しかし、EIP3074は署名検証アルゴリズムの変更を許可しておらず、これは批判の一因です。EIP3074はAUTHとAUTHCALLの2つのオペコードを導入しました。AUTHは署名を検証することでEVMコンテキスト内のauthorizedアドレスを設定します。AUTHCALLはauthorizedアドレスを取引の発起人として使用できます。これにより、ユーザーはアカウントを1つの取引でスマートコントラクトに委任することが可能になります。しかし、EIP3074にはいくつかの安全上の懸念があります。1. サインは繰り返し使用される可能性があり、ユーザーはリレーサービスプロバイダーを信頼する必要があります。2. commitフィールドの機能は完全に契約の定義に依存しており、標準化が欠けている。3. メモリプールに対するDoS攻撃を引き起こす可能性があるEIP7702はVitalikが提案した代替案です。これは、新しい取引タイプSET_CODE_TX_TYPEを導入し、EOAが基本機能を保持しながらスマートコントラクト機能を追加できるようにします。ユーザーは従来のウォレットを引き続き使用することも、スマートコントラクト方式でEOAアドレスを呼び出すこともできます。EIP7702の利点は次のとおりです。1. ERC4337などのアカウント抽象標準と互換性があり、既存のインフラを再利用できる2. 完全なアカウント抽象機能を実現しました3.地方分権化の程度はERC4337のそれに匹敵しますしかし、EIP7702もEIP3074のすべての問題を完全に解決することはできず、安全性が契約の実装に依存している。ERC4337はアカウント抽象化の標準であり、"完全なアカウント抽象化"が含むべき機能を定義しています。まさにERC4337チームはEIP3074に強く反対しました。## EIP3074とEIP7702のガバナンスプロセスEIP3074は2021年4月にコア開発者会議で議論が始まりましたが、安全性の問題からロンドンアップグレードには組み込まれませんでした。その後、何度も議論と改良を経て、2024年2月にはほとんどのクライアントがそれをペクトラアップグレードに組み込むことに同意しました。しかし、ERC4337チーム、特にその主要開発者であるYoavは、会議で反対意見を何度も表明しています。彼らはEIP3074に安全リスクが存在し、DoS攻撃を引き起こす可能性があり、中央集権的なリレーヤーが必要であると考えています。2024年5月、ヴィタリックはコア開発者会議の90分前にEIP7702提案を完了しました。続く会議では、開発者たちは一般的にEIP7702がEIP3074よりも優れていると考えました。最終的にEIP7702をPectraアップグレードのアカウント抽象化スキームとしてEIP3074の代わりに使用することが決定されました。## ガバナンスの争議に対する反省ZeroDevは、EIP7702が良い提案であると考えていますが、EIP3074を置き換えるプロセスには問題があります:1. EIP3074は長期にわたる議論の後、突然置き換えられました。2. ERC4337コミュニティはもっと早く議論に参加し、意見を表明すべきですEIP3074の開発者は、ERC4337コミュニティがガバナンスの失敗に責任があると考えています。なぜなら、彼らは以前にガバナンスプロセスに積極的に参加していたからです。ERC4337コミュニティは、EIP3074の開発者とコア開発者が彼らの意見を十分に聞いていないと考えています。実際、これはイーサリアムガバナンスの深いメカニズムを反映しています。イーサリアムはVVRC(Values-Vision-Roadmaps-Clients)モデルを採用しています:1. 価値: コミュニティの価値観2. ビジョン: ヴィタリックのビジョン3. ロードマップ: 研究者が作成したロードマップ4. クライアント: クライアント実装このモデルでは、ヴィタリックのビジョンが中心的な役割を果たしています。重大な意見の相違が発生した場合、ヴィタリックが最終的な決定権を持っています。EIP3074が置き換えられたのは、ヴィタリックのアカウント抽象に対するビジョンに合わなかったからであり、EIP7702はそれに一致しています。この論争は、イーサリアムのガバナンスの真の運用メカニズムと、その中でVitalikが果たす重要な役割を明らかにしました。また、イーサリアムのガバナンスモデルが十分に分散化されているかどうかについての考察も引き起こしました。
イーサリアム治理の争い：EIP3074がEIP7702に取って代わられた背後のVVRCモデル
イーサリアムガバナンスの論争：EIP3074とEIP7702の争い
イーサリアム最近の重大アップグレードPectraで複雑なガバナンスの対立が発生しました。EIP3074がアップグレード計画に組み込まれた後、特にERC4337チームからの強い反対があり、大きな議論を引き起こしました。
EIP3074は膠着状態に陥り、ガバナンスプロセスは続行できなくなった。VitalikがEIP7702を提案するまで、ERC4337チームのEIP3074に対する疑念は最終的に収束しなかった。
この論争は、イーサリアムのガバナンスの深い問題を反映しています - 「コードは法律である」という前提の下で、具体的なコードの内容を決定する権限は誰にあるのか。EIP3074とEIP7702の争いは、イーサリアム内部の実際のガバナンスプロセスを観察する視点を提供してくれます。
ZeroDevの分析によると、イーサリアムが実際に採用しているのはVVRCガバナンスモデルです。すべての提案はまずイーサリアムの価値観(Value)に適合する必要があり、その後Vitalikのビジョン(Vision)に反映され、次にロードマップ(Roadmap)に示され、最終的にコア開発者による議論の後、クライアント(Client)に実装されます。
GCC Researchが以前に分析したEIP2537は、クライアントレベルでの実装問題が発生し、ハードフォークへの参加が遅れました。一方、EIP3074はビジョンとロードマップの問題により、最終的にハードフォークに組み込まれませんでした。イーサリアムのコア開発者は、最終的にVitalikが作成したEIP7702をアカウント抽象化の方案として選びました。
! イーサリアムガバナンス戦争:EIP3074、ERC4337、EIP7702
EIP3074、EIP7702、ERC4337の紹介
EIP3074は実行層の提案であり、ノードソフトウェアのアップグレードが必要です。その核心的な目的は、ガス代の支払いとバッチトランザクション機能を実現することです。ユーザーは任意のトークンを使用してガス費を支払ったり、オフラインで支払ったりすることができます。しかし、EIP3074は署名検証アルゴリズムの変更を許可しておらず、これは批判の一因です。
EIP3074はAUTHとAUTHCALLの2つのオペコードを導入しました。AUTHは署名を検証することでEVMコンテキスト内のauthorizedアドレスを設定します。AUTHCALLはauthorizedアドレスを取引の発起人として使用できます。これにより、ユーザーはアカウントを1つの取引でスマートコントラクトに委任することが可能になります。
しかし、EIP3074にはいくつかの安全上の懸念があります。
EIP7702はVitalikが提案した代替案です。これは、新しい取引タイプSET_CODE_TX_TYPEを導入し、EOAが基本機能を保持しながらスマートコントラクト機能を追加できるようにします。ユーザーは従来のウォレットを引き続き使用することも、スマートコントラクト方式でEOAアドレスを呼び出すこともできます。
EIP7702の利点は次のとおりです。
しかし、EIP7702もEIP3074のすべての問題を完全に解決することはできず、安全性が契約の実装に依存している。
ERC4337はアカウント抽象化の標準であり、"完全なアカウント抽象化"が含むべき機能を定義しています。まさにERC4337チームはEIP3074に強く反対しました。
EIP3074とEIP7702のガバナンスプロセス
EIP3074は2021年4月にコア開発者会議で議論が始まりましたが、安全性の問題からロンドンアップグレードには組み込まれませんでした。その後、何度も議論と改良を経て、2024年2月にはほとんどのクライアントがそれをペクトラアップグレードに組み込むことに同意しました。
しかし、ERC4337チーム、特にその主要開発者であるYoavは、会議で反対意見を何度も表明しています。彼らはEIP3074に安全リスクが存在し、DoS攻撃を引き起こす可能性があり、中央集権的なリレーヤーが必要であると考えています。
2024年5月、ヴィタリックはコア開発者会議の90分前にEIP7702提案を完了しました。続く会議では、開発者たちは一般的にEIP7702がEIP3074よりも優れていると考えました。最終的にEIP7702をPectraアップグレードのアカウント抽象化スキームとしてEIP3074の代わりに使用することが決定されました。
ガバナンスの争議に対する反省
ZeroDevは、EIP7702が良い提案であると考えていますが、EIP3074を置き換えるプロセスには問題があります:
EIP3074の開発者は、ERC4337コミュニティがガバナンスの失敗に責任があると考えています。なぜなら、彼らは以前にガバナンスプロセスに積極的に参加していたからです。
ERC4337コミュニティは、EIP3074の開発者とコア開発者が彼らの意見を十分に聞いていないと考えています。
実際、これはイーサリアムガバナンスの深いメカニズムを反映しています。イーサリアムはVVRC(Values-Vision-Roadmaps-Clients)モデルを採用しています:
このモデルでは、ヴィタリックのビジョンが中心的な役割を果たしています。重大な意見の相違が発生した場合、ヴィタリックが最終的な決定権を持っています。EIP3074が置き換えられたのは、ヴィタリックのアカウント抽象に対するビジョンに合わなかったからであり、EIP7702はそれに一致しています。
この論争は、イーサリアムのガバナンスの真の運用メカニズムと、その中でVitalikが果たす重要な役割を明らかにしました。また、イーサリアムのガバナンスモデルが十分に分散化されているかどうかについての考察も引き起こしました。