著者: ショー

概要

最も複雑なガバナンス紛争は、Pectra のアップグレード中に発生しました。 EIP3074 が Pectra アップグレードに含まれたとき、特に ERC4337 チームからの反対により、大きな論争が巻き起こりました。

EIP3074 に問題があり、ガバナンス プロセスを続行できません。 ERC4337 チームが EIP3074 に対する疑念を解消したのは、Vitalik が EIP7702 を提案してからでした。

GCCリサーチは、PectraアップグレードにおけるEIP3074とERC7702のガバナンス問題が中国世界ではほとんど議論されていないことを発見した。しかし、このガバナンスの問題は、コードが法律であるという前提の下で、誰がコードの具体的な内容を制御できるかという、イーサリアムガバナンスのより深い問題も反映しています。 EIP3074 と ERC7702 のガバナンスの問題は、Ethereum 内の実際のガバナンス プロセスを観察するための良い視点を与えてくれます。

この記事の最終的な結論は、Ethereum のガバナンス システムが VVRC モデルであることを指摘している ZeroDev が公開した解説記事を要約したものです。あらゆる提案を組み込むには、まずイーサリアムの価値観（Value）に準拠する必要があり、次に提案はVitalikが設計したビジョン（Vision）に反映され、最後に提案はロードマップ（Roadmap）に反映され、最終的にコア開発者が議論してクライアント（Client）の実装に組み込むことになります。

前の記事で GCC Research が紹介した EIP2537 は、クライアント レベルでの実装の問題によりハードフォークへの組み込みが遅れましたが、EIP3074 はビジョンとロードマップの問題によりハードフォークには組み込まれませんでした。 Ethereum コア開発者は、最終的なアカウント抽象化提案として、Vitalik によって書かれた EIP7702 を直接選択しました。

提案内容の概要

具体的なガバナンスプロセスを紹介する前に、まずこの記事で取り上げる EIP3074、EIP7702、ERC4337 の具体的な内容を簡単に紹介する必要があります。

EIP3074 は実行層の提案であり、その実行にはノード ソフトウェアのアップグレードが必要です。 EIP3074 の主な目的は、ガス スポンサーシップとバッチ トランザクションの機能を実装することです。いわゆるガススポンサーとは、ユーザーがガス料金を支払うために任意のトークンを使用できる、またはユーザーがオフラインでガス料金を支払うことができることを意味します。ただし、署名検証アルゴリズムの変更を許可する他のアカウント抽象化提案と比較すると、EIP3074 ではユーザーが secp256k1 以外の署名アルゴリズムを使用することができないことに注意してください。つまり、EIP3074 はすべてのアカウント抽象化機能を満たす提案ではありません。これは、EIP3074 が批判されている点でもあります。

意図した目標を達成するために、EIP3074 では AUTH と AUTHCALL という 2 つのオペコードが導入されています。 AUTH オペコードは署名を検証できます。署名検証に合格すると、オペコードは現在の EVM コンテキスト内の承認済みを署名者のアドレスとして設定します。コンテキストで authorized を構成すると、AUTHCALL は、呼び出しトランザクションの msg.sender として authorized アドレスを使用してトランザクションを開始できます。ユーザーは、署名することで、ある程度、自分のアカウントをスマート コントラクトに委託して取引に使用することができます。通常、ユーザーから委託されたこのスマート コントラクトを、呼び出し側コントラクトと呼びます。

ユーザーの署名の具体的な内容は何ですか?ユーザーは以下に署名する必要があります。

イーサリアムのガバナンス戦争：EIP3074、ERC4337、EIP7702

上記のコンテンツの呼び出し元アドレスは、ユーザーが委任したい呼び出し元コントラクト アドレスを指します。 EVM は、ユーザーの署名内容が実際に署名を検証する契約と一致しているかどうかを検証し、ユーザーの AUTH 署名内容が他の契約によって使用されるのを防ぎます。

nonce はトランザクションの再生を防ぐ識別子です。ただし、AUTH オペコードは、署名内の nonce が現在署名されている EOA の nonce と一致しているかどうかを検証することに注意してください。理論上、ユーザーが EOA アカウントを使用してトランザクションを開始し、ノンス値を増加させない限り、ユーザーが発行した AUTH 署名は常に呼び出し側コントラクトで使用できます。これは重大なセキュリティ上の脆弱性であり、EIP3074 を使用するユーザーは署名を取得したリレー サービス プロバイダーを信頼する必要があることを意味します。ユーザーの署名を取得したリレーサービスプロバイダーが悪意を持っている場合、サービスプロバイダーは特定の時間にユーザーの AUTH 署名を再生し、ユーザーの資産を盗む可能性があります。

もう 1 つのセキュリティ上の懸念は、コミット フィールドです。コミット フィールドは、特定の操作を保証するために使用されます。ユーザーは、コミットに何らかのコンテンツを書き込んで署名コンテンツが ETH 転送に使用されないようにするなど、コミット内の署名権限を細かく制御できます。 EIP3074 ドキュメントでは、提案者がコミット フィールドの使用例をいくつか示しました。しかし問題は、コミットの役割はスマート コントラクトの定義に完全に依存しており、本質的にオプションであるということです。スマート コントラクトによってコミットの内容の解釈がまったく異なる場合があり、一部のコントラクトではコミットの内容をまったく読み取らないこともあります。ユーザーが EIP3074 を安全に使用したい場合は、スマート コントラクトを自分で確認するだけです。

最後に、EIP3074 が現在の Ethereum トランザクション メモリ プールに与える影響を紹介します。 EIP3074 の導入後、メモリプールを攻撃する方法が登場する可能性があります。ハッカーは、多数のアカウントを使用してトランザクションを開始し、トランザクションがパッケージ化される直前に EIP3074 トランザクションを使用してこれらのアカウントの ETH を一度に排出し、以前に開始されたすべてのトランザクションを失敗させることができます。このタイプの攻撃は実行層ノードに大きな影響を与え、本質的には DoS 攻撃となります。ただし、EIP3074 の代替として使用される EIP7702 にもこの問題がありますが、EIP7702 ではこの問題を回避するためにいくつかの制限が導入されており、これについては後で説明します。

上で述べた EIP3074 自体の問題に加えて、ERC4337 の作者 Yova 氏は、「EIP-3074 の包含の影響」という記事でさらに多くの反論を紹介しています。簡単に言うと、これらの意見には主に次のようなものが含まれます。

  1. 集中化のリスク。 AUTH 署名の特殊な特性により、ユーザーは EIP3074 リレー サービス プロバイダーと基盤となるインフラストラクチャを完全に信頼する必要があります。同時に、ERC4337などのアカウント抽象化プロトコルによって構築されたインフラストラクチャは、EIP3074と完全に互換性がありません。
  2. ユーザーのセキュリティ。前述の通り、EIP3074 には統一された権限制御方式がなく、署名ノンスの設計にもセキュリティリスクがあり、深刻なセキュリティ問題につながる可能性があります。
  3. アカウント抽象化機能が不完全です。他のアカウント抽象化提案と比較すると、EIP3074 は完全ではなく、ユーザー署名アルゴリズムの変更などの機能を実装できません。
  4. ユーザーエクスペリエンスに問題があります。ユーザーが自分のアカウントをスマート コントラクトに委任する必要がある場合、ユーザーは AUTH 署名を実行し、AUTH 署名を含む呼び出しをチェーンに公開する必要があります。ユーザーは 2 回署名する必要があります。

EIP7702 は、EIP3074 を置き換えるための Vitalik による提案です。この提案では、新しい EVM オペコードを導入する代わりに、SET_CODE_TX_TYPE と呼ばれる新しいトランザクション タイプを導入します。ユーザーが EIP7702 タイプのトランザクションを開始すると、EOA の基本機能を維持しながら、EOA にスマート コントラクト機能を追加できます。簡単に言えば、ユーザーは引き続き MetaMask などのウォレットを使用してトランザクションを開始したり、他のユーザーがスマート コントラクトの形式で EOA アドレスを呼び出すことができます。

簡単なバッチ トランザクションの例を使用して、EIP7702 の機能を紹介します。ユーザーは EIP7702 を使用して、バッチ呼び出しを実行できるスマート コントラクトに EOA アドレスを委託し、その後、スマート コントラクトの形式で EOA アドレスを直接呼び出してバッチ トランザクションを開始できます。

技術的な実装の観点から見ると、EIP7702 で導入されたトランザクション タイプは、従来のトランザクションと比較して authorization_list リストを追加します。リストの具体的な内容は[[chain_id, address, nonce, y_parity, r, s], ...]です。ここで、address はユーザーが委任するスマート コントラクト アドレスであり、nonce はユーザーの現在の nonce 値です。残りの y_parity、r、s はユーザーの署名結果です。具体的な実行プロセスでは、まず authorization_list 内の各項目を走査して処理します。処理方法は、y_parityなどの署名パラメータを通じてEOAアドレスを復元し、アドレスaddressを持つスマートコントラクトにEOAアドレスをポイントすることです。その後、EOA アドレスは、契約の機能を実行するための呼び出しを受け入れることができます。

EIP7702 の利点は非常に明白ですが、最も核心的な利点は、EIP7702 によって EOA が本質的にスマート コントラクトの機能を持つことができることです。これは、ERC4337 などのアカウント抽象化の基本ルールと一致しており、EIP7702 はアカウント抽象化の分野における現在のすべての調査を活用し、既存のインフラストラクチャを再利用できることを意味します。たとえば、EIP7702 は ERC4337 のインフラストラクチャを直接使用できます。現在、ERC4337 は EIP7702 呼び出しをサポートする EntryPoint v0.8 をリリースしています。既存のインフラを再利用するという観点から見ると、EIP7702 と ERC4337 は同程度の分散化を備えています。

もちろん、EIP7702 は実際には EIP3074 で発生した問題を完全に修正するわけではありません。 EIP3074 の問題のほとんどは依然として存在しています。 EIP7702 では、アカウント コントラクトに安全な実装が求められますが、プロトコル自体はセキュリティを保証するものではありません。 EIP7702 の初期の頃、一部の開発者はリプレイ攻撃を回避するために署名 nonce を標準化することを提案しましたが、EIP7702 は最終的にこれらの提案を受け入れませんでした。したがって、EIP7702を安全に使用したい場合は、ユーザー自身が契約のセキュリティを確認する必要があります。

同時に、EIP7702 は実行層にも一連の問題をもたらします。上記では、EIP3074 を使用して実行層メモリ プールに対して DoS 攻撃を実行する可能性のある方法を紹介しました。このアプローチは EIP7702 でも有効です。したがって、EIP7702 では、大規模な DoS 攻撃を回避するために、EIP7702 を使用するすべての EOA アドレスがメモリ プール内に保留中のトランザクションを 1 つだけ持つことができるようにすることを推奨しています。

まとめると、EIP3074 の最大の問題は、EIP7702 が完全なアカウント抽象化機能を実装しているのに対し、EIP3074 では完全なアカウント抽象化機能が実装されていないことです。 「完全なアカウント抽象化」に何が含まれるかを定義するのは、ERC4337 の作成者です。これを読めば、なぜ EIP3074 が ERC4337 チームに反対され、最終的に EIP7702 に置き換えられたのかが理解できるはずです。全体的なガバナンスと議論のプロセス全体については後ほど紹介します。

EIP3074とEIP7702のガバナンスプロセス

EIP3074 は、Ethereum コア開発者会議の非常に早い段階で言及されました。 2021 年 4 月 2 日のミーティング #109 で、Ethereum コア開発者が EIP3074 について簡単に議論しました。議論は非常に単純なものとなりました。

  1. Alexey 氏は、EIP3074 署名コンテンツにはセキュリティ上のリスクがあり、ユーザーに重大なセキュリティ損失をもたらす可能性があると主張しました。彼は、EIP3074 が AUTH 署名の具体的な内容をさらに標準化することを提案しました。この提案はマーティンによって支持された。
  2. ジェームズは、EIP3074がDoS攻撃などの実行層の潜在的な脆弱性をもたらす可能性があると提案し、EIP3074が文書化された脅威分析を提供することを提案した。
  3. Alexey 氏と Martin 氏は、EIP3074 のドキュメントの品質が平均的で、読んで理解するのに多くの時間がかかると不満を述べました。
  4. マーティン氏は、EIP3074 の中核はアプリケーション、特にウォレット開発者との協力と実装にあると考えています。 EIP3074 の作者は、アプリケーション開発者と一連のやり取りを行ってきたと述べています。

さらに興味深いのは、この会議でヴィタリック氏が、イーサリアムには EOA 用に設計された 1 つのトランザクションに対して複数の呼び出しを生成する技術的ソリューションが必要であると信じていたことです。 EIP3074 にはセキュリティ上の問題がある可能性がありますが、EIP3074 は可能な技術的解決策を提供しており、開発者は EIP3074 に基づいて前進する必要があります。

どうやら、EIP3074 のセキュリティ上の問題により、この会議ではロンドン アップグレードに EIP3074 は含まれなかったようです。

2021年6月11日に開催された会議#115では、EIP3074の開発者がセキュリティ監査レポートを提出し、会議では主にEIP3074のセキュリティ問題について議論されました。簡単な結論としては、EIP3074 呼び出し元契約はシステムにおいて非常に重要であるため、呼び出し元契約を管理する必要があるかどうかが疑問であるということです。 EIP3074 開発者は、セキュリティを強化するために呼び出し側コントラクトを正式に証明したいと考えています。

もちろん、発信アドレスが EOA であるかどうかを判断するために msg.sender == tx.origin を使用する一部のコントラクトについても議論があります。 EIP3074 が導入されると、これらの判断は無効になりますが、この部分の判断が失敗しても重大なセキュリティ上の問題は発生しないという結論になります。つまり、この会議は主に EIP3074 の提案者が 3074 のセキュリティ監査結果をコア開発者に紹介するためのものでした。会議の最終結論は、3074 では依然としてインボーカー コントラクトの問題を考慮する必要があり、ロンドン ハードフォークにそれを含めないことが推奨されたというものでした。

2021年6月25日に開催されたミーティング#116において、ERC4337の中核著者であるYova氏は、「EIP 3074のよりシンプルな代替案の事例」と題する資料を提出しました。資料では、EIP3074には多くのセキュリティ上の問題があると指摘し、署名のコミットフィールドの内容を制限したり、コミットフィールドを{nonce、to、gas、calldata、value、chainid}の形式にすることを要求するなど、EIP3074の内容の一部を修正することが提案されました。この署名モードを使用した後は、トランザクションのセキュリティを確保するために、EIP3074 は特定のトランザクションを実行するためにのみ使用できるようになります。

EIP3074 の著者が Yova の提出物に応答した会議は次のとおりです。

  1. インボーカー コントラクト アドレスが EIP 仕様に含まれ、Ethereum コア開発者がセキュリティ問題を回避するために安全なインボーカー コントラクトを作成することが期待されます。
  2. 署名内のコミットの内容に関しては、EIP3074 開発者は、これは完全にユーザーとウォレット ソフトウェアの問題であり、EIP で規制する必要はないと考えています。

ヴィタリック氏はこの会議で次の3点を指摘しました。

  1. EIP3074 は依然として従来の secp256k1 署名方式を使用しており、量子耐性を実現できません。
  2. EIP3074には将来の互換性がなく、EIP3074を使用してEOAをスマートコントラクトアカウントに進化させることはできません。
  3. EIP3074 の寿命には限りがあります。 EIP 3074 では、 AUTH と AUTHCALL という 2 つの事前組み立てられたコードが導入されています。ただし、アカウント抽象化ロードマップによれば、将来的にはイーサリアムのすべてのウォレットがスマートコントラクトウォレットになる可能性があり、EIP 3074 の事前組み立てられたコードは将来的に廃止される予定です。

2022 年 2 月 4 日の会議 #131 では、開発者は上海アップグレードに含めるべき EIP の種類について議論しました。 EIP3074 も議論に含まれていましたが、開発者は単に EIP3074 の開発動向を同期させただけでした。注目すべきは、会議が始まる前に、nethermind が「Ethereum ウォレットの現在と未来 - EIP-3074 vs. ERC-4337」というタイトルの記事を書いたことです。この記事には EIP3074 に対する異論は一切含まれていませんでした。

2023 年 8 月 3 日の会議 #167 で、コア開発者は別の EIP5806 について議論しているときに EIP3074 に言及しました。 EIP5806 は、EOA がトランザクション中に委任呼び出しを使用して外部コントラクトを呼び出すことを可能にするプロトコルです。この方式は EIP7702 と多少似ています。しかし、コア開発者らもこの計画の安全性に疑問を呈している。アンスガー氏は、EIP3074はセキュリティ上の問題が発生する可能性があるため、これまでハードフォークには組み込まれていなかったが、EIP5806はより急進的な計画であると指摘した。

2024 年 2 月 29 日の会議 #182 では、開発者は EIP3074 を Pectra アップグレードに含めるべきかどうかについて詳細に議論しました。 Vitalik は、あらゆるアカウント抽象化標準には次の 3 つの機能が必要であると提案しました。

  1. キーローテーション
  2. キーの廃止
  3. 量子耐性署名と互換性あり

Vitalik 氏は、EIP5806 は EIP3074 よりも良い選択肢かもしれないと指摘しました。 Andrew は、EIP3074 は EIP5806 よりも汎用性が高いと考えており、EIP3074 の使用を推奨しています。ヴィタリック氏はアンドリュー氏に反論し、将来的にはすべてのウォレットがスマート コントラクト ウォレットになる可能性があると考えました。これが起こると、EIP3074 によって導入された事前組み立てられたオペコードは無効になります。 ERC4337の作者として、Yoav氏は会議で長いスピーチを行いました。主な内容は次のとおりです。

  1. EIP3074 は Ethereum メモリプールに対する DoS 攻撃につながる可能性があり、ERC4337 はこの部分について多くの研究を行い、攻撃を回避するためのいくつかのルールを提供しました。
  2. EIP3074では、バッチトランザクションを開始するときにユーザーが2回署名する必要があるが、これは不合理である。
  3. EIP3074では集中型リレーの使用が求められる

Yova は、アカウント抽象化ソリューションとして EIP5806 を使用することを好みます。

2024年3月14日のミーティング#183では、コア開発者がMetaMaskのDan Finlay氏を招待し、EIP3074に関するウォレットの見解について話し合いました。 Dan 氏は EIP3074 を支持しており、MetaMask も EIP3074 のテストに対するサポートを提供すると指摘しました。 MetaMask は、EIP3074 により EOA がアカウント抽象化の全機能を機能的に利用できるようになると考えます。セキュリティの面では、EIP3074 はウォレット サービス プロバイダーにホット キーとコールド キーの分離というソリューションを提供します。ウォレット サービス プロバイダーは、EOA の EIP3074 署名を保持してトランザクションを開始できます。ユーザーは通常の取引でホット秘密鍵を使用できますが、コールド秘密鍵はユーザーのハードウェア ウォレットに保存できます。緊急事態が発生した場合、ユーザーはコールドウォレット内のコールド秘密鍵を使用して、EIP3074 署名を取り消すトランザクションを開始できます。ホット秘密鍵とコールド秘密鍵を分離することで、ウォレットプロバイダーに柔軟性がもたらされます。

Vitalik 氏は、EIP3074 ではウォレット設計者がユーザーの EIP3074 署名が悪用されるのを防ぐために厳格な認証ロジックを設計する必要があると指摘しました。興味深いことに、MetaMask の EIP3074 機能追加サポートについて議論した際、Vitalik 氏は L2 は移行ソリューションとして使用できると指摘しました。つまり、L2 の資金は限られており、深刻な問題が発生すると深刻な損失が発生する可能性があるため、新しい実行レイヤーの変更はまず L2 内で実装する必要があります。

Dror Tiros氏は議論の中で、EIP3074のセキュリティを確保する最善の方法は、Ethereumの担当者が直接invoker契約を提供することだと指摘した。しかし、ダン・フィンレーは契約に関する公式見解に反対した。ダンは、インボーカー契約は完全にユーザーによって決定されるべきであり、最終的には市場が最も安全なインボーカー契約を選択するだろうと信じていました。

アンスガー氏は依然として、EIP3074 は一度に 1 つのトランザクションにのみ対応すべきであり、ウォレット サービス プロバイダーはトランザクションを開始するためにユーザーの署名を再利用すべきではないと主張しているが、ダン フィンレイ氏も反対を表明している。 Dan Finlay 氏は、EIP3074 はコールド ウォレットで署名する必要があり、ウォレット サービス プロバイダーはその署名を再利用して、ユーザーに代わって直接トランザクションを開始できると考えています。ユーザーが毎回再署名する必要がある場合、コールド秘密鍵は複数回使用される可能性があります。これは、ホット秘密鍵とコールド秘密鍵を分離するという考え方と矛盾しています。

この会議中にコア開発者が議論したもう 1 つの重要なトピックは、包含リストでした。インクルージョンリストは、イーサリアムの検閲耐性を高める手段です。簡単に言えば、包含リストを使用すると、一部のトランザクションを直接コミットして次のブロックに含めることができます。しかし、コア開発者は、EIP3074 が包含リストと矛盾していると指摘しました。

2024年4月11日の会議#185では、ほとんどのクライアント実装がEIP3074をPectraハードフォークに含めることに同意しましたが、GethはEIP3074がVerkleツリーに問題を引き起こす可能性があるため反対しました。 Danno 氏は、EIP3074 が署名の再利用につながる可能性があるため、依然として反対を表明しました。 Yoav 氏も反対を表明し、EIP3074 と Blob トランザクションを使用してメモリ プールを攻撃する解決策を提案しました。簡単に言うと、攻撃者は大量のデータを含む多数の Blob トランザクションを開始し、EIP3074 を使用してこれらのすべての Blob トランザクションを無効にすることができます。

つまり、この会議ですべてのクライアント開発者は、EIP3074 を最終アップグレードに含めることに同意しました。

2024 年 5 月 9 日の会議 #187 で、コア開発者は EIP3074 を置き換える EIP7702 の問題について初めて議論しました。 EIP7702 は、コア開発者会議が始まる前の最初の 90 分以内に Vitalik によって完成されました。会議中、コア開発者は、EIP7702 が EIP3074 よりも優れた標準であることを認識しました。この会議ではEIP7702に対する反対意見はなかったが、一部の研究者はEIP7702もEIP3074と同様の取り消し不能な特性を持ち、資金の安全性の問題につながる可能性があると考えていた。

2024 年 5 月 23 日の会議 #188 で、コア開発者は EIP3074 を EIP7702 に置き換える可能性について議論しました。この会議の最終結論は、Pectra ハードフォークのアカウント抽象化標準として、EIP3074 の代わりに EIP7702 を使用することでした。 Vitalik は、EIP7702 にも EIP3074 と一致する取り消し不能な特性がいくつかあり、EIP3074 について議論する際に広く議論されてきたと指摘しています。さらに興味深いのは、会議で多数の ERC4337 の代表者が講演していたことです。

実際、EIP3074 を EIP7702 に置き換えるという議論は、第 188 回コア開発者会議の前に広く議論されていました。当時の議論の結果、3074 を置き換えることになったので、コア開発者会議では大きな議論はありませんでした。

ロードマップと裁定

EIP3074 が置き換えられることを知った後、アカウント抽象化の中核インフラストラクチャである Zerodev は、「3074 サガ後の Ethereum ガバナンスに関する考察」と題した興味深い記事を公開しました。記事では、EIP7702 はすべてのユーザーに利益をもたらす優れた提案であると結論付けました。ただし、EIP3074 に代わる EIP7702 のガバナンス プロセスは、次の理由により最適ではありません。

  1. EIP3074 は長い議論のプロセスを経てきました。上記では、コア開発者会議におけるEIP3074の複数の議論を紹介しました。
  2. EIP3074 が Pectra アップグレードに含まれることが決定された後、ERC4337 コミュニティから多くの反対を受けました。もちろん、ERC4337のコア開発者であるYova氏は、コア開発者会議においてEIP3074への反対を繰り返し表明していることを上で指摘しました。

Zerodev は、ERC4337 コミュニティが EIP3074 の長期にわたるコア開発者の議論プロセスに幅広く参加し、意見を表明することが最善のガバナンス パスであるべきだと考えています。

EIP3074 の開発者は、ガバナンスの失敗については ERC4337 が責任を負うべきだと考えています。 EIP3074は過去数年間ガバナンスに積極的に参加しており、ERC4337コア開発者のyovaと何度もコミュニケーションをとってきたからです。

ERC4337 コミュニティは、ガバナンスの失敗に対する主な責任を負うのは EIP3074 であると考えています。 ERC4337コミュニティのメンバーは、YovaがERC4337のコア開発者として、複数のコア開発者会議でEIP3074に反対を表明したが、コア開発者は耳を傾けなかったようだと考えています。 ERC4337 のコミュニティ メンバーのほとんどは、EIP3074 のガバナンス ダイナミクスに注意を払っておらず、ほとんどのメンバーは EIP3074 は死んだ標準であると考えています。 ERC4337 コミュニティはまた、コア開発者が ERC4337 コミュニティと積極的にコミュニケーションを取っていないと考えています。

EIP3074 と ERC4337 はどちらも正しいガバナンス作業を実行したと信じており、ガバナンスの失敗については相手方が主な責任を負うべきです。明らかに、このガバナンス プロセスにはより深い理由が働いています。

簡単に言えば、より深い理由は、実は Ethereum のロードマップにあります。 Ethereum ロードマップはコア開発者会議よりも権限を持ちます。アカウント抽象化のロードマップは ERC4337 を中心に展開されます。 EIP7702 は ERC4337 標準と完全に互換性がありますが、EIP3074 は ERC4337 標準と完全に互換性がありません。したがって、Ethereum ロードマップの観点から見ると、EIP3074 の置き換えは必ず起こるはずです。

もちろん、イーサリアムのロードマップは、イーサリアムの将来に対するヴィタリック氏の個人的なビジョンです。イーサリアムのガバナンスプロセス中に深刻な紛争が発生した場合、ロードマップの定義者である Vitalik が最終決定権を持ちます。 EIP3074 の置き換えにつながったのは、Vitalik の判決でした。

イーサリアムのガバナンスモデルは、価値 ⇒ ビジョン ⇒ ロードマップ ⇒ クライアント モデル、略して VVRC モデルです。ガバナンス プロセスは次のとおりです。

  1. 価値観、特にコミュニティの価値観。イーサリアムコミュニティの価値観には、分散化、検閲反対などが含まれます。
  2. ビジョンは、実際にはヴィタリック氏のイーサリアムの将来に関する個人的な考えです。
  3. ロードマップ ロードマップでは、研究者がビジョンに基づいて技術的な詳細を提供し、より完全な実装ロードマップを提供します。
  4. クライアントは、クライアントのコア開発者によって実装されます。コア開発者会議などのツールを使用してロードマップについて議論し、ロードマップ内の要件を実装します。

上記のプロセスは、Ethereum の実際のガバナンス プロセスです。 Vitalik 氏の個人的なビジョンが Ethereum ガバナンス モデルの根底にあることがわかります。そのため、クライアント実装内で深刻な紛争が発生した場合、Vitalik 氏の個人的な意見が最終決定を下すことになります。

参考文献

ZeroDevの紹介

ヌル

https://docs.zerodev.app/blog/3074-governance

ZeroDevの紹介

ヌル

https://docs.zerodev.app/blog/4337-and-3074-disagreements

アカウント抽象化ロードマップに関するメモ - HackMD

# アカウント抽象化ロードマップに関する注記 *フィードバックを提供してくれたVitalikとAAチームに感謝します

https://notes.ethereum.org/@yoav/AA-roadmap-May-2024