GCC Researchは、PectraのアップグレードにおけるEIP3074とERC7702のガバナンスの問題が中国語圏であまり議論されていないことを発見しました。しかし、このガバナンスの問題は、Ethereumのガバナンスの根深い問題、すなわち「code is law」の前提の下で、誰がコードの具体的な内容を制御できるかを反映しています。EIP3074とERC7702のガバナンスの問題は、Ethereum内部の真のガバナンスプロセスを観察するための良い視点を提供してくれます。
2022年2月4日のMeeting #131では、開発者がShangHaiアップグレードに含まれるべきEIPのタイプについて議論しました。EIP3074は議論の範囲に含まれましたが、開発者はEIP3074の開発動向を簡単に同期しただけでした。注目すべきは、会議が始まる前にnethermindが「Ethereum wallets today and tomorrow — EIP-3074 vs. ERC-4337」という記事を執筆し、その中にはEIP3074に対する反対意見が含まれていなかったことです。
アカウント抽象化のコアインフラストラクチャであるZerodevは、EIP3074が置き換えられることを知った後、「Reflections on Ethereum Governance Following the 3074 Saga」というタイトルの興味深い記事を公開し、EIP7702はすべてのユーザーに利益をもたらす優れた提案であると結論付けました。 ただし、EIP3074を置き換えるEIP7702のガバナンス プロセスは、次のような多くの理由で最適ではありません。
イーサリアムガバナンス戦争：EIP3074、ERC4337とEIP7702
著者: シュー
###の概要
Pectraのアップグレードでは、最も複雑なガバナンスの対立問題が発生しました。EIP3074がPectraのアップグレードに組み込まれたことで、大きな議論が巻き起こり、特にERC4337のチームからの反対がありました。
EIP3074 は困難に直面し、ガバナンスプロセスは続行できませんでした。Vitalik が EIP7702 を提案するまで、ERC4337 チームは EIP3074 に対する疑問を持ち続けていました。
GCC Researchは、PectraのアップグレードにおけるEIP3074とERC7702のガバナンスの問題が中国語圏であまり議論されていないことを発見しました。しかし、このガバナンスの問題は、Ethereumのガバナンスの根深い問題、すなわち「code is law」の前提の下で、誰がコードの具体的な内容を制御できるかを反映しています。EIP3074とERC7702のガバナンスの問題は、Ethereum内部の真のガバナンスプロセスを観察するための良い視点を提供してくれます。
この記事の最終的な結論は、ZeroDevによって発表された評論記事からの引用であり、その記事では、イーサリアムのガバナンスシステムがVVRCモデルであることが指摘されています。提案が採用されるためには、まずイーサリアムの価値観(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を署名者のアドレスに設定します。コンテキストのauthorizedが設定されると、AUTHCALLはauthorizedのアドレスを呼び出しトランザクションのmsg.senderとして使用してトランザクションを発起することができます。ある意味で、ユーザーは署名を通じて自分のアカウントを1つのトランザクションでスマートコントラクトに委任することができます。このようにユーザーに委任されたスマートコントラクトを一般的にinvokerコントラクトと呼びます。
そのユーザーの具体的な署名内容は何ですか？ユーザーは以下の内容に署名する必要があります:
! イーサリアムガバナンス戦争:EIP3074、ERC4337、EIP7702
上記の内容における invoker address は、ユーザーが委任したい invoker コントラクトのアドレスを指します。EVM は、ユーザーの署名内容と実際に署名を検証するコントラクトが一致しているかを検証し、ユーザーの AUTH 署名内容が他のコントラクトに使用されることを防ぎます。
nonceは取引の再生を防ぐための識別子です。しかし注意すべき点は、AUTHオペコードが署名中のnonceと現在の署名のEOAのnonceが一致するかどうかを検証することです。理論的には、ユーザーがEOAアカウントを使用して取引を開始してnonceの値を増加させない限り、ユーザーが発行したAUTH署名はinvokerコントラクトによって常に使用されることができます。これは巨大なセキュリティホールであり、EIP3074を使用するユーザーは署名を取得するリレーサービスプロバイダーを信頼しなければなりません。もし署名を取得したリレーサービスプロバイダーが悪意を持っている場合、そのプロバイダーはある時点でユーザーのAUTH署名を再生してユーザーの資産を盗む可能性があります。
もう一つのセキュリティ上の問題は、コミットフィールドです。 コミットフィールドは、特定の操作を保証するために使用され、ユーザーは、署名コンテンツがETH転送に使用されないようにコミットにコンテンツを書き込むなど、コミットでの署名権限を微調整できます。 EIP3074文書では、提案者はコミットフィールドを使用する一連の例を示しています。 しかし、問題は、コミットの役割がスマートコントラクトの定義に完全に依存し、本質的にオプションの内容であることです。 異なるスマートコントラクトは、コミットの内容を完全に一貫性なく解析する可能性があり、一部のコントラクトはコミットの内容をまったく読み取らないことさえあります。 EIP3074安全に使用したい場合は、スマートコントラクトを自分で確認する必要があります。
最後に、EIP3074が現在のイーサリアムトランザクションmempoolに与える影響を見てみましょう。 EIP3074の導入により、ハッカーは多数のアカウントを使用してトランザクションを開始し、トランザクションがパッケージ化されようとしているときにEIP3074トランザクションを使用してそれらのアカウントのETHを一度に排出し、以前に開始されたすべてのトランザクションを失敗させることができます。 このタイプの攻撃は、実行レイヤーノードに大きな影響を与える可能性があり、本質的にはDoS攻撃です。 ただし、EIP3074を置き換えるために使用されるEIP7702にもこの問題がありますが、EIP7702この問題を回避するためにいくつかの制限が導入されていることに注意してください。
上記で紹介されたEIP3074自体の問題に加えて、ERC4337の著者Yovaは「EIP-3074の含有の影響」という文の中で、さらに多くの反対意見を紹介しました。簡単に言えば、これらの意見は主に次のようなものです:
EIP7702 は、Vitalik によって提案された EIP3074 を置き換えるための提案です。この提案は新しい EVM オペコードを導入するのではなく、SET_CODE_TX_TYPE と呼ばれる新しいトランザクションタイプを導入しました。ユーザーが EIP7702 タイプのトランザクションを開始すると、ユーザーは 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アドレスを復元し、そのEOAアドレスをaddressに指定されたスマートコントラクトに指し示します。その後、EOAアドレスは呼び出しを受けてコントラクトの機能を発揮することができます。
EIP7702の利点は明らかであり、EIP7702の核となる利点は、基本的にEOAがスマートコントラクトの機能を持てるようにすることです。 これは、ERC4337などのアカウント抽象化の基本ルールと一致しており、EIP7702は、現在のアカウント抽象化ドメインの既存のインフラストラクチャをすべて活用して、ERC4337インフラストラクチャを直接使用できるEIP7702など、既存のインフラストラクチャを探索して再利用できます。 EIP7702 呼び出しをサポートする EntryPoint v0.8 が ERC4337 で利用可能になりました。 既存のインフラを再利用するという観点では、EIP7702はERC4337と同程度のデプレイフルさを持っています。
もちろん、EIP7702は実際にはEIP3074で発生した問題を完全には修正していません。EIP3074に存在する問題の大部分は依然として存在します。EIP7702はアカウントコントラクトが安全に実装されることを要求しますが、プロトコル自体は安全性を保証しません。EIP7702が提案された初期には、一部の開発者が署名ノンスを標準化して可能なリプレイ攻撃を回避することを提案しましたが、最終的にEIP7702はこれらの提案を受け入れませんでした。したがって、ユーザーがEIP7702を安全に使用したい場合、ユーザーは自分でコントラクトの安全性を監査する必要があります。
同時に、EIP7702 は実行層にも一連の問題をもたらします。前述の通り、EIP3074 を利用して実行層のメモリプールに対して DoS 攻撃を行う可能性のある方法を紹介しました。この方法は EIP7702 においても有効です。したがって、EIP7702 は EIP7702 を使用する全ての EOA アドレスがメモリプール内に処理待ちの取引を一件のみ存在させることを推奨し、大規模な DoS 攻撃の発生を避けるようにしています。
以上のことから、EIP3074の最大の問題は、EIP3074が完全なアカウント抽象機能を実現していないことであり、EIP7702は完全なアカウント抽象機能を実現しています。「完全なアカウント抽象」が何を含むかを定義しているのは、まさにERC4337の作者です。ここまで読んだ読者は、なぜEIP3074がERC4337チームに反対され、最終的にEIP7702に置き換えられたのかを理解できるはずです。後の文で、全体のガバナンスと議論のプロセスについて紹介します。
EIP3074 と EIP7702 のガバナンスプロセス
EIP3074は、イーサリアムのコア開発者会議で非常に早く言及されました。2021年4月2日のMeeting #109で、イーサリアムのコア開発者はEIP3074について簡単に議論しました。議論の結果は非常にシンプルでした:
興味深いことに、Vitalik はこの会議で、いずれにせよ、Ethereum には EOA 用に設計されたトランザクションが複数のコールを生成する技術的なソリューションが必要だと考えています。EIP3074 には潜在的なセキュリティ問題があるものの、EIP3074 は技術的なソリューションの可能性を示しており、開発者は EIP3074 に基づいて前進する必要があります。
明らかに、EIP3074に安全上の問題があるため、この会議ではEIP3074をロンドンアップグレードに含めることはありませんでした。
2021年6月11日のMeeting #115において、EIP3074の開発者はセキュリティ監査に関する報告を提出し、会議では主にEIP3074のセキュリティ問題について議論されました。簡単な結論として、EIP3074のinvokerコントラクトはシステム内で非常に重要であるため、invokerコントラクトを管理する必要があるかどうかが問題です。EIP3074の開発者は、invokerコントラクトの形式的証明を行い、セキュリティを高めたいと考えています。
もちろん、一部の議論では、いくつかのコントラクトが msg.sender == tx.origin を使用して、呼び出し元アドレスが EOA かどうかを判断していることがありましたが、EIP3074 が導入されると、これらの判断は無効になります。ただし、結論として、これらの判断が無効になることは深刻なセキュリティ問題を引き起こすことはありません。要するに、この会議は主に EIP3074 の提案者がコア開発者に3074のセキュリティ監査結果を紹介するものでした。会議の最終的な結論は、3074 では invoker コントラクトの問題を考慮する必要があり、London ハードフォークに追加しないことを推奨するものでした。
2021年6月25日のMeeting #116において、ERC4337の主要著者Yovaは「EIP 3074に対するよりシンプルな代替案の提案」という資料を提出しました。この資料では、EIP3074に多くのセキュリティ問題が存在することが指摘され、いくつかの内容の修正が提案されています。例えば、署名内のcommitフィールドの内容を制限し、commitフィールドを{nonce,to,gas,calldata,value,chainid}の形式とすることが求められています。この署名方式を使用することで、EIP3074は特定の取引の実行にのみ使用され、取引の安全性が保証されることになります。
ここでの会議で、EIP3074の作者はYovaが提出した資料に対して回答しました:
ヴィタリックはこの会議で以下の3点を提案しました:
2022年2月4日のMeeting #131では、開発者がShangHaiアップグレードに含まれるべきEIPのタイプについて議論しました。EIP3074は議論の範囲に含まれましたが、開発者はEIP3074の開発動向を簡単に同期しただけでした。注目すべきは、会議が始まる前にnethermindが「Ethereum wallets today and tomorrow — EIP-3074 vs. ERC-4337」という記事を執筆し、その中にはEIP3074に対する反対意見が含まれていなかったことです。
2023年8月3日のMeeting #167で、コア開発者たちは別のEIP5806について議論する際にEIP3074に言及しました。EIP5806は、EOAがトランザクション中にdeleGate.io callの方法を使用して外部コントラクトを呼び出すことを可能にするものです。この方案は、ある程度EIP7702に似ています。しかし、コア開発者はこの方案の安全性について疑問を呈し、Ansgarは過去にEIP3074が存在する可能性のある安全問題のためにハードフォークに組み込まれなかったことを指摘しました。そして、EIP5806はより攻撃的な方案です。
2024年2月29日のMeeting #182で、開発者たちはEIP3074がPectraアップグレードに含まれるべきかどうかを詳細に議論しました。Vitalikは、すべてのアカウント抽象標準は以下の3つの機能を備える必要があると提案しました:
VitalikはEIP5806がEIP3074よりも優れた選択肢である可能性があることを指摘しました。AndrewはEIP3074がEIP5806に比べてより汎用的であると考え、EIP3074の使用を提案しました。VitalikはAndrewに反論し、将来的にはすべてのウォレットがスマートコントラクトウォレットになる可能性があり、この状況が発生すればEIP3074が導入したプリビルドオペコードは無効になると考えています。ERC4337の著者であるYoavは、今回の会議で比較的長い発言を行い、その内容は主に次のようなものでした:
Yovaは、アカウント抽象化のスキームとしてEIP5806をより好む傾向があります。
2024年3月14日に開催されたInside Meeting #183では、コア開発者がMetaMaskのDan Finlay氏を招き、ウォレットがEIP3074どう考えているかについて話し合いました。 Dan氏はEIP3074に賛成しており、MetaMaskはEIP3074のテストもサポートすると述べている。 MetaMaskはEIP3074 EOAがアカウント抽象化の全機能を機能的に享受できるようにすることができると考えています。 セキュリティの面では、EIP3074はウォレットサービスプロバイダーにソリューション、つまりホットキーとコールドキーの分離を提供します。 ウォレットサービスプロバイダーはEOAのEIP3074署名を保持してトランザクションを開始でき、ユーザーは通常のトランザクションでホット秘密鍵を使用できますが、コールド秘密鍵はユーザーのハードウェアウォレットに保持でき、緊急事態が見つかった場合、ユーザーはコールドウォレット内のコールド秘密鍵を使用してトランザクションを開始し、EIP3074の署名を取り消すことができます。 ホット秘密鍵とコールド秘密鍵を分離するこのソリューションは、ウォレットプロバイダーに柔軟性を提供します。
ヴィタリックは、EIP3074内では、ウォレットの設計者は、ユーザーのEIP3074署名の誤用を避けるために、厳格な承認ロジックを設計する必要があると指摘しています。 興味深いことに、MetaMaskがEIP3074機能を追加する機能について議論した際、Vitalik氏は、L2は資金が限られており、何か問題が発生した場合でも深刻な損失を引き起こす可能性があるため、L2は過渡的なソリューションとして使用できる、つまり、新しい実行レイヤーの変更は最初にL2内で実装する必要があると指摘しました。
Dror Tirosは議論の中で、EIP3074の安全性を確保する最良の方法は、Ethereumの公式が直接invokerコントラクトを提供することであると指摘しました。しかし、Dan Finlayは公式によるコントラクトの提供に反対し、invokerコントラクトは完全にユーザーが決定すべきであり、市場が最終的に最も安全なinvokerコントラクトを選ぶと考えています。
Ansgar は EIP3074 において、一度の署名は一つの取引にのみ対応すべきであり、ウォレットサービスプロバイダーはユーザーの署名を再利用して取引を開始すべきではないと主張していますが、Dan Finlay も反対意見を表明しました。Dan Finlay は EIP3074 はコールドウォレットによる署名を行い、その後ウォレットサービスプロバイダーがその署名を再利用してユーザーの取引を直接開始できるべきだと考えています。毎回ユーザーに再署名を求めることは、コールドプライベートキーが何度も使用される可能性があるためです。これはホットキーとコールドキーを分離するという考えに反しています。
今回の会議では、コア開発者たちがもう一つの重要なトピックである含有リストについて議論しました。含有リストは、イーサリアムの検閲耐性を高める手段の一つです。簡単に言えば、含有リストは特定の取引を次のブロックに直接含めることを約束することを可能にします。しかし、コア開発者たちはEIP3074が含有リストと矛盾していることを指摘しました。
2024 年 4 月 11 日のミーティング #185 では、ほとんどのクライアント実装が Pectra ハードフォークにEIP3074参加することに同意しましたが、Geth は Verkle ツリーに問題を引き起こす可能性があるという理由で反対EIP3074。 Dannoは、EIP3074署名に再利用できるため、まだ反対しています。 Yoav氏もこれに異議を唱え、EIP3074とBLOBトランザクションを使ってmempoolを攻撃する方法を提案しました。 簡単に言うと、攻撃者は大量のデータを含む多数の BLOB トランザクションを開始し、EIP3074 を使用してそれらすべてを無効にすることができます。
簡単に言うと、この会議では、すべてのクライアント開発者がEIP3074を最終的なアップグレードに組み込むことに同意しました。
2024年5月9日のMeeting #187において、コア開発者たちは初めてEIP7702がEIP3074の代替となる問題について議論しました。EIP7702は、Vitalikがコア開発者会議の90分前に完成させたものです。会議では、コア開発者たちはEIP7702がEIP3074よりも優れた標準であると認めました。この会議ではEIP7702に対する反対意見は出なかったものの、一部の研究者はEIP7702にもEIP3074と同様の不可逆性があり、資金の安全問題を引き起こす可能性があると考えています。
2024年5月23日のMeeting #188会議では、コア開発者たちがEIP7702がEIP3074の代替としての可能性について議論しました。この会議の最終結論は、PectraのハードフォークにおいてEIP3074の代わりにEIP7702を使用するというものでした。Vitalikは、EIP7702にもEIP3074と一致するいくつかの取り消し不可能な特性があることを指摘しました。これらの特性はEIP3074の議論の際に多くの議論がなされました。興味深いことに、この会議にはERC4337の代表者が多く参加して発言しました。
実際、EIP3074がEIP7702に置き換えられる議論は188回のコア開発者会議の前に広く議論されており、その時の議論の結果は3074が置き換えられるというものでしたので、コア開発者会議では大きな対立はありませんでした。
ロードマップと判決
アカウント抽象化のコアインフラストラクチャであるZerodevは、EIP3074が置き換えられることを知った後、「Reflections on Ethereum Governance Following the 3074 Saga」というタイトルの興味深い記事を公開し、EIP7702はすべてのユーザーに利益をもたらす優れた提案であると結論付けました。 ただし、EIP3074を置き換えるEIP7702のガバナンス プロセスは、次のような多くの理由で最適ではありません。
Zerodevは、最良のガバナンスの道はEIP3074の長いコア開発者の議論の過程において、ERC4337コミュニティが広く参加し自分の意見を表明すべきだと考えています。
EIP3074 の開発者は、ERC4337 がガバナンスの失敗に対して責任を負うべきだと考えています。なぜなら、EIP3074 は過去数年間にわたりガバナンスに積極的に関与しており、ERC4337 のコア開発者である yova と何度も交流してきたからです。
ERC4337コミュニティは、EIP3074がガバナンスの失敗に対して主な責任を負うべきだと考えています。ERC4337コミュニティのメンバーは、YovaがERC4337の主要な開発者として、複数回の主要開発者会議でEIP3074に対して反対意見を表明したが、主要な開発者は意見を聞かなかったようだと考えています。ERC4337のほとんどのコミュニティメンバーは、EIP3074のガバナンスの動向に関心を持っておらず、大部分のメンバーはEIP3074が死んだ標準だと考えています。ERC4337コミュニティは、主要な開発者がERC4337コミュニティと積極的にコミュニケーションを取っていないと考えています。
EIP3074とERC4337は、自分たちが正しいガバナンスを行ったと考えており、相手がガバナンスの失敗に対して主な責任を負うべきだと主張しています。明らかに、このガバナンスプロセスには、より深い原因が作用しています。
簡単に言えば、このより深い理由は実はイーサリアムのロードマップにあります。イーサリアムのロードマップはコア開発者会議の権限を超えています。アカウント抽象化のロードマップはERC4337を中心にしています。EIP7702はERC4337標準と完全に互換性がありますが、EIP3074はERC4337標準と十分に互換性がありません。したがって、イーサリアムのロードマップの観点から見ると、EIP3074が置き換えられることは必然的に起こるでしょう。
もちろん、イーサリアムのロードマップは、ヴィタリック個人のイーサリアムの未来に対するビジョンの表れです。イーサリアムのガバナンスプロセスで重大な議論が発生した場合、ロードマップの定義者であるヴィタリックが最終的な裁定権を持っています。そして、まさにヴィタリックの裁定によってEIP3074が置き換えられました。
イーサリアムのガバナンスモデルは、values ⇒ vision ⇒ roadmaps ⇒ clients モデル、または略して VVRC モデルです。ガバナンスプロセスは次のとおりです:
上記のプロセスがイーサリアムの真のガバナンスプロセスです。私たちは、ビタリックの個人的なビジョンがイーサリアムのガバナンスモデルの基盤に位置していることがわかります。したがって、一旦クライアントの実装内で深刻な論争が発生すると、ビタリックの個人的な意見が最終的な裁定を行います。