Cabinet
テクノロジーインサイト一覧へ戻る
2026.09.14

【続報】Ethereum と Base のネイティブ・アカウント抽象化の統一協議が決裂：EIP-8141 と EIP-8130 は別々の規格として進み、ウォレットは二系統の実装を迫られる

【続報】Ethereum と Base のネイティブ・アカウント抽象化の統一協議が決裂：EIP-8141 と EIP-8130 は別々の規格として進み、ウォレットは二系統の実装を迫られる

何が起きたか

The Block の報道によれば、Ethlabs の開発者 Derek Chiang 氏は9月14日（月）に X へ投稿し、EIP-8130 と EIP-8141 の著者らが続けていた調整作業が前週に終了したと明らかにした。両陣営は、Ethereum L1 と Base L2 の双方で使える共通規格を定義しようとしていた。Chiang 氏は「いくつかの技術的解決策は見つかったが、いずれもどちらか一方が自らの中核目標を少なくとも少しは妥協する必要があった。そこで別々の道を進むことにし、その結果生じる分断への対処はウォレットに委ねられた」と述べている。

EIP-8141 は、トランザクションを複数の「フレーム」の列として扱う提案である。フレームごとに、送信者の検証、ガスの支払者の承認、利用者の操作の実行を分けて記述する。提案文は「アカウントは単にコードを持つアドレスになる」と説明している。Ethereum Foundation の Protocol クラスタが9月7日に公開した Hegotá 向けのティアリストで、EIP-8141 は「must-ship」とされた。共著者の Vitalik Buterin 氏は9月5日、この数か月で重要な進展があり、提案は「最適に近い」と述べている。9月第3週の技術ニュースレターによれば、テスト仕様は v0.3.0 に達し、3つのクライアントが frames-devnet-0 の準備を終えている。

EIP-8130 は Base が主導する提案で、新しいトランザクション型とオンチェーンの「Keystore」を組み合わせる。Keystore には各アカウントが承認した署名者と認証方式が記録され、独自の認証、呼び出しのバッチ化、ガス代の肩代わりを提供する。

解こうとしている問題は同じ、選んだ最適化が違う

両提案が解こうとしている問題は共通である。ETH を持たずに手数料を払うこと、パスキーなど任意の署名方式を使うこと、複数の操作を一つのトランザクションにまとめることだ。これらは現在、ERC-4337（コントラクトレベルの AA）と EIP-7702（EOA へのコード委任）で部分的に実現されている。しかし、別経路のメンプールやバンドラー、ガスのオーバーヘッドといった制約が残るため、プロトコルに組み込む「ネイティブ AA」が求められてきた。

違いは、検証ロジックをどこまで自由にするかにあると考えられる。EIP-8141 は、検証そのものを EVM コードとして記述できる汎用性を重視している。その汎用性は、署名方式を後から差し替えられることを意味し、Ethereum が掲げる耐量子化への移行経路にもなる。一方、EIP-8130 は、承認済みの署名者と認証方式を Keystore に宣言的に登録する構造を取る。検証の範囲があらかじめ限定されるため、ノードやシーケンサが処理の重さを見積もりやすく、大量のトランザクションをさばく L2 の要件に合う設計と読める。ただし、この対比は提案文の構造から読み取った筆者の解釈であり、両陣営の公式な説明ではない。

Chiang 氏が挙げた優先順位の違いは、この構造の違いと対応している。任意コードによる検証は、メンプールでの検証コストや DoS 耐性の設計を難しくする。ERC-4337 が検証フェーズに厳しい制約を設けたのもこのためだった。逆に、検証を宣言的な登録に限定すれば運用は予測しやすくなるが、新しい認証方式の追加は Keystore の仕様変更を待つことになる。どちらの負担を誰が引き受けるかという選択であり、L1 と L2 で答えが分かれたことになる。

既存の AA 資産と他の L2 への波及

決裂の影響は、将来の二つの形式にとどまらない。現在すでに運用されている ERC-4337 のスマートアカウントと、EIP-7702 で委任を設定した EOA が、どの形式へ、どう移行するのかという問題がある。EIP-8141 が掲げる「アカウントはコードを持つアドレス」という整理は、既存のスマートアカウントを自然に取り込める方向にある。一方、EIP-8130 の Keystore 方式では、アカウントの署名者情報をオンチェーンの登録簿に置くため、既存アカウントの認証設定を登録し直す手順が必要になると考えられる。どちらの提案も、既存アカウントの移行手順を最終的な形では示していない。現時点で確実なのは、移行経路がチェーンごとに異なりうるということである。

もう一つは、Base 以外の L2 の選択である。OP Stack や Arbitrum Orbit のチェーンは、L1 と同じ形式を採るか、Base と同じ形式を採るか、独自に拡張するかを判断しなければならない。現時点で、他の主要 L2 が態度を表明したという公式発表は確認できていない。ロールアップ固有の改善提案（RIP）の枠組みで L2 間の共通化を図る道はある。しかし今回の件は、L1 と最大級の L2 の間ですら目的関数の違いから統一できなかった事例であり、共通化が容易でないことを示している。

実装までの距離

EIP-8141 は Hegotá で「must-ship」とされたが、Hegotá 自体は Glamsterdam の後のアップグレードであり、公開情報では2027年が目標とされている。Glamsterdam のメインネット日すら未確定の現状では、L1 でネイティブ AA が使えるのはまだ先である。EIP-8130 が Base でいつ有効になるかについて、今回の報道は新しい日程を示していない。当面、実運用の AA は ERC-4337 と EIP-7702 が担い続ける。言い換えれば、今後少なくとも1年程度は、バンドラーとペイマスターの基盤、EIP-7702 の委任先コントラクトの安全性審査が、AA を実装する組織の主要な作業であり続ける。ネイティブ AA の登場で、これらへの投資が無駄になるわけではない。二つのネイティブ形式が並立すれば、それらを束ねる中間層として、既存の 4337 系インフラの役割はむしろ長く残る可能性がある。

想定される落とし穴

第一に、「EIP 番号が付いている」ことを「Ethereum 全体の標準」と読まないことである。EIP-8130 は EIP 番号を持つが、その主な適用先は Base である。L1 で採用される見込みは、今回の決裂で遠のいたと考えられる。

第二に、Chiang 氏も認めているとおり、分断の負担はウォレットにかかる。署名要求の形式、ガス支払者の指定方法、セッションキーの表現がチェーンごとに異なれば、同じ UX を提供するための分岐がウォレットと SDK に積み上がる。

第三に、Hegotá の仕様はまだ固まっていない。「must-ship」も SFI（スケジュール済み）も、フレームの詳細仕様を凍結するものではない。今の仕様に合わせて作り込むと、手戻りが発生しうる。

【技術インサイトとアクション】

  1. ネイティブ AA の設計は、検証の自由度（L1 の耐量子移行）と検証コストの予測可能性（L2 のスループット）のどちらを優先するかで分かれた。L1 と L2 で目的関数が異なる限り、この種の分岐は AA に限らず今後も起きる。 ［プロダクト側・アーキテクト］ 次の技術ロードマップ策定時に、自社が対応するチェーンごとに「L1 標準に追随するか、L2 独自の拡張を使うか」を機能単位で判断し、その根拠を記録する。
  2. 署名とガス支払いの形式が複数並立すると、ウォレットと SDK の分岐が積み上がる。ERC-4337、EIP-7702、EIP-8141、EIP-8130 の四経路を個別に作り込むと、保守コストが線形に増える。 ［ウォレット・SDK 開発者］ 半年以内に、「利用者の意図（操作・支払者・認証）」を表す内部表現を定義し、各形式への変換を別レイヤーに分ける抽象化を設計する。まずは既存の ERC-4337／EIP-7702 の二経路で検証する。
  3. 仕様の状態（Draft、SFI、must-ship）と、実際にメインネットで有効になる時期は別物である。Hegotá は Glamsterdam の後段にあり、その Glamsterdam のメインネット日も未定である。 ［コントラクト開発者］ Hegotá の仕様が凍結されるまでは、EIP-8141 前提の実装を本番コードに入れず、frames-devnet でのプロトタイプに留める。本番の AA 対応は ERC-4337／EIP-7702 で継続する。

【引用：出典】

本記事は公開情報に基づく技術解説であり、投資助言を目的としたものではありません。

前の記事【続報】Glamsterdam の Sepolia フォークが10月6日 13:53:36 UTC（エポック353024）で確定：Devnet-11 で初の安定移行、「エポック351232」の食い違いも解消次の記事 ether.fi LiquidのAtomicQueue.solve()が呼び出し元指定のsolverを検証せず、既存approve経由で資金が引き抜かれる