そのため、取引を開始できる能力は、単一の秘密鍵による署名と長期にわたって結びついたままだ。前提が変わらない限り、今日多くのユーザーが当然持っているべきだと感じている能力――例えば、署名ルールを柔軟に切り替えること、他者に Gas を代わりに支払わせること、秘密鍵を失った後にアカウントのコントロールを回復すること、あるいは将来、新しい暗号体系へスムーズに移行すること――は、どれもアカウントのデフォルト能力として本当の意味で実現するのが難しい。
imToken やその他の Web3 ウォレットを使ったことがあるなら、おそらくこれらの痛点にも遭遇しているはずだ。例えば、ウォレット内に USDC はあるが ETH がないため取引を送れない（Gas は ETH でしか支払えないからだ）。復元できない形でシードフレーズを失ってしまう。あるいは「承認 + 交換」という操作は、2回署名して、2回確認しないといけない、といったことだ。
なぜなら従来は、誰が取引を検証し、誰が Gas を支払い、誰が実際の操作を実行するのかが、基本的に同じアカウントアクションに束ねられていたからだ。しかし EIP-8141 の設計では、これらの事柄を別々のフレームに分け、プロトコルが明確な順序でそれらを順番に実行できる。そうであるがゆえに、アカウントはもはや単一の秘密鍵に「まとめて署名」するだけに頼らず、プログラマブルな実行主体により近い形を持ち始めるのだ。
ネイティブアカウント抽象化 + 量子耐性：なぜEIP-8141はまだイーサリアムのHegotáの看板になっていないのか？
先週、イーサリアムのコア開発者ミーティングで、EIP-8141 を Hegota アップグレードに組み込むかどうかが正式に議論された。その結果は意外なものだった。Vitalik 自らが推していたこの提案は、Hegota の「ヘッドライン機能」としては挙げられず、「考慮対象（CFI）」のステータスを獲得した。
そして今週、Google の量子 AI チームが最新のホワイトペーパーを公開し、与えられたハードウェアの仮定のもとで ECDLP-256 を解くのに必要な物理量子ビットの推定値は、それまでに比べて 20 倍も大幅に低下したと述べた。量子攻撃がすぐ目前というわけではないものの、将来、アカウント体系が検証ロジックを柔軟に切り替えられないなら、今日の多くのウォレット体験に関する議論は、最終的に安全性の問題へと姿を変えてしまう可能性があることを、確かな形で私たちに突きつけている。
プロトコルの推進という現実的な観点から見ると、EIP-8141 は現時点でもまだ重すぎる。特に、クライアント実装、トランザクションプールのセキュリティ、検証の複雑さにおいて、十分に盤石な合意がまだ形成されていない。
しかし、この時点に立ってみると、EIP-8141 を議論し、真剣に再検討する価値がある点は、どうやら本当にますます増えてきているようだ。
一、EIP-8141 は結局なにを解決しようとしているのか？
EIP-8141 は Vitalik Buterin と timbeiko などのコア貢献者によって推進され、正式名称は Frame Transactions（フレームトランザクション）だ。
理解しやすい一文でまとめるなら、これは実際には単に特定のウォレット機能を単体で追加しようとしているのではない。プロトコル層から、どんなアカウントでも、単一の ECDSA 署名パスに縛られる必要がなくなるようにして、より柔軟な検証と実行ロジックを持てるようにしようとする試みだ。
つまり、多署名、Gas スポンサー、鍵のローテーション、ソーシャルリカバリー、そして将来の耐量子署名方式への接続までもが、もはやウォレットの外側に“おまけ”として付く一層の能力ではなくなり、イーサリアムのアカウント体系における「原初の構成員」になる機会が生まれる、ということだ。
表面的に見ると、EIP-8141 が議論しているのは非常に具体的に見える一連の能力だ。**ステーブルコインで Gas を支払い、多段の操作を一つのトランザクションに合成し、より柔軟な署名方法をサポートし、さらには将来の耐量子署名に備える余地を用意する。**と言える。長年の ERC-4337 から EIP-7702 に至るまで、ウォレット体験に関する多くの改善は、本質的には、アカウントをただの秘密鍵ではなく、ルールを自分で定義できる入口にしていくことだった。
問題は、これらの改善によってウォレットはますますスマートアカウントのようになっている一方で、依然としてイーサリアムの最下層にあるデフォルトのアカウントモデルに実際に踏み込めていない点にある。
周知のとおり、現行の体系ではイーリアムのアカウントは大きく二種類に分かれる。1つは外部保有アカウント（EOA）で、私たちが最もよく知っているタイプであり、秘密鍵によって制御される。取引を自ら開始できるが、プログラマブルな能力は欠けている。もう1つはコントラクトアカウントで、スマートコントラクト本体であり、複雑なロジックを実行できるが、自分では取引を能動的に開始できない。
そのため、取引を開始できる能力は、単一の秘密鍵による署名と長期にわたって結びついたままだ。前提が変わらない限り、今日多くのユーザーが当然持っているべきだと感じている能力――例えば、署名ルールを柔軟に切り替えること、他者に Gas を代わりに支払わせること、秘密鍵を失った後にアカウントのコントロールを回復すること、あるいは将来、新しい暗号体系へスムーズに移行すること――は、どれもアカウントのデフォルト能力として本当の意味で実現するのが難しい。
imToken やその他の Web3 ウォレットを使ったことがあるなら、おそらくこれらの痛点にも遭遇しているはずだ。例えば、ウォレット内に USDC はあるが ETH がないため取引を送れない（Gas は ETH でしか支払えないからだ）。復元できない形でシードフレーズを失ってしまう。あるいは「承認 + 交換」という操作は、2回署名して、2回確認しないといけない、といったことだ。
これらの問題は、ウォレット製品が「十分に良くない」からではなく、イーサリアムのアカウントモデル自体が持つ設計上の結果なのだ。
この観点から見ると、過去2年の進化はすでにとても明確だ。ERC-4337 は、プロトコルを修正することなく、アカウント抽象をまずアプリケーション層で動かすことに成功した。EIP-7702 はさらに、EOA が完全に拡張できないわけではないこと、少なくとも一時的にスマートアカウントに近い能力の一部を獲得できることを、よりはっきりと証明した。
つまり、イーサリアムはアカウント抽象をしたくないのではなく、ずっとより穏健で保守的なやり方で、その実現に向けて段階的に近づいてきたのだ。そして EIP-8141 の登場は、この道が新しい地点に到達したことを意味する。既存体系の外側にさらにスマートアカウント機能の層を重ねるだけでは満足せず、アカウント抽象を取引モデルそのものに直接組み込み、アカウントがプロトコル層からプログラマブルな検証と実行ロジックを備えることを目指すからだ。
だからこそ、EIP-8141 は今日になって再び勢いを取り戻している。上位のウォレット体験はすでにネイティブのアカウント抽象にますます近づいており、プロトコル層も遅かれ早かれ追随が必要になる。一方で、量子計算がもたらす長期的な圧力もまた、「アカウントが署名方式を柔軟に切り替えられるか」という論点を、遠い技術的なテーマから前倒しで真剣に検討すべき現実の問題へと変えつつある。
二、EIP-8141 はどうやって動くのか？
結局のところ、EIP-8141 はまったく新しいトランザクション種別を導入する――フレームトランザクション（Frame Transaction）。トランザクション種別番号は 0x06。
従来のイーサリアムトランザクションの基本ロジックが「1つのトランザクションにつき1回の呼び出しに対応する」とするなら、EIP-8141 が目指すのは、トランザクションを、ルールに従って順序立てて実行できる一連の「フレーム」に分解することだ。これにより、元々一体として縛られていた検証・支払い・実行の3つを別々に扱えるようにする。
各「フレーム」には 3 つの実行モードがある：
この仕組みの意義は、取引がより複雑にできるということではない。初めて「検証、支払い、実行」という3つのことを、アカウントのアクションから分解し、プロトコルのネイティブなディスパッチに任せることにある。
なぜなら従来は、誰が取引を検証し、誰が Gas を支払い、誰が実際の操作を実行するのかが、基本的に同じアカウントアクションに束ねられていたからだ。しかし EIP-8141 の設計では、これらの事柄を別々のフレームに分け、プロトコルが明確な順序でそれらを順番に実行できる。そうであるがゆえに、アカウントはもはや単一の秘密鍵に「まとめて署名」するだけに頼らず、プログラマブルな実行主体により近い形を持ち始めるのだ。
具体例を挙げよう。あなたが USDC で Gas を支払って Swap を完了させたいとする。EIP-8141 の枠組みでは、このことは理論上、完全なフレーム手順として組み立てられる。まず、アカウントが署名と実行権限を検証する。次に、支払者または Paymaster が、自分が費用を負担することに同意できる条件を検証する。その後、対応する資産の費用支払いを行い、最後に本当の swap 操作を実行する。
こうすれば、Gas の支払いとメイントランザクションを同じアトミックなフローに含められる。つまり、全部が成功するか、全部がロールバックされるかのどちらかになる。
ユーザーにとって最も直感的な変化は、これまで必ず 2〜3 ステップに分けられ、途中に失敗リスクが存在していた多くの操作が、将来的には一度の完結したアクションのようにできることだ。したがって、このアトミック性こそが、EIP-8141 がユーザー体験の断片化問題を解決しようとしている重要なポイントの1つでもある。
ではこれはウォレットユーザーにとって何を意味するのか？結果として最も直感的な変化は少なくとも 4 層ある：
三、なぜ Hegotá の看板にならなかったのか？
見落とされがちだが、ウォレットユーザーにとって非常に重要な点がある。たとえ最終的に EIP-8141 が実装されたとしても、既存のアカウント体系はそれによって全体としては覆されない。
たとえ今 imToken などの既存の Web3 ウォレットを使っていても、移行は不要だ。後方互換性があるためで、既存の EOA アドレスはそのまま使い続けられる。必要に応じて「アップグレード」したアカウントの検証ロジックを選ぶだけでよい。
しかし逆に言えば、ちょうどそれだけ改変が深いからこそ、最新ラウンドの議論で Hegota の看板機能として直行しなかったのだ。もっとも、2026 年の EIP champion のプロセスに従えば、CFI（Considered for Inclusion）の意味は否定されたということではなく、真剣に検討している段階に入ったということであり、最終的な拍板で本番リリースに入るところまでではない。
言い換えれば、コア開発者は EIP-8141 の方向性を認めていないのではない。価値を認めつつも、現時点ではまだ「重すぎる」と考えているのだ。
なぜなら、ネイティブなアカウント抽象は ERC-4337 のように、少数のウォレット、インフラ、アプリが段階的に推進できるわけではない。一度プロトコル層に入ると、実行層クライアントすべてが真剣に実装し、テストし、協調する必要が出てくる。それは自然と推進のハードルを引き上げ、フォークの計画を立てる際にコア開発者がより慎重に寄る理由にもなる。
では、次に何が起きるのか？それは2本の線に分けて考えられる：
事実をありのままに言えば、EIP-8141 は唯一のネイティブなアカウント抽象提案ではないし、それ自体が既製の耐量子署名方式でもなく、量子計算問題を直接解決できるわけではない。しかしその重要性は、アカウントを ECDSA の単一路線から切り離す、プロトコル層としての出口を初めて与えることにある。
この観点から見れば、EIP-8141 の真の価値は、それが唯一の正解かどうかではない。「ネイティブなアカウント抽象の終局が結局どのような姿であるべきか」という問いを、初めて非常に完全な形でイーサリアムのプロトコル議論のテーブルに載せたことにある。
それは唯一の案ではない。しかし確かに、それは現在のところ最も野心的で、かつ「完全なネイティブ AA」の想像力の上限に最も近い案の1つだ。
EIP-8141 が最終的に Hegotá に間に合うかどうかにかかわらず、この議論自体が少なくとも次のことをすでに示している：
イーサリアムは問題がその場で膨らむのを待っていない。次世代のアカウント体系に向けて、日々少しずつ前もって道を敷いているのだ。