その結果、取引を開始する能力は、単一の秘密鍵による署名と長い間ひとつに結び付けられたままです。この前提が変わらない限り、今日多くのユーザーが当然備わっていてほしいと感じている能力、たとえば署名ルールを柔軟に変更すること、他人に Gas を代わりに支払わせること、秘密鍵の紛失後にアカウントのコントロールを復元すること、あるいは将来、新しいパスワード体系へスムーズに移行することなどが、アカウントのデフォルト能力として本当に定着するのは難しいままです。
もしあなたが imToken やその他の Web3 ウォレットを使ったことがあるなら、たいていこれらの痛点にも直面したはずです。たとえばウォレットの中に USDC がたくさんあるのに ETH がないため取引を送れない（Gas は ETH でしか支払えないため）；リカバリーフレーズを失うとお金が完全に失われ、復元できない；「承認 + 交換」の操作は 2 回署名し、2 回確認が必要だといった具合です。
なぜなら過去には、「誰がトランザクションを検証するのか」「誰が Gas を支払うのか」「誰が実際の操作を実行するのか」が、基本的に同一のアカウント動作に結び付けられていました。しかし EIP-8141 の設計下では、これらを異なるフレームに分解し、プロトコルが明確な順序で、次々と実行できます。だからこそ、アカウントはもはや単一の秘密鍵に「まとめて署名」するだけではなく、よりプログラマブルな実行主体に近い形を持てるようになり始めるのです。
ネイティブアカウント抽象化 + 量子耐性：なぜEIP-8141はまだイーサリアムのHegotáの看板になっていないのか？
著：imToken
先週、イーサリアムのコア開発者会議で、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 を支払い、多段の操作を 1 回のトランザクションに合成し、より柔軟な署名方式をサポートし、さらには将来の抗量子署名のための余地を確保すること。長年の ERC-4337 から EIP-7702 まで、ウォレット体験をめぐる多くの改善は、本質的には、アカウントをただの 1 本の秘密鍵ではなく、カスタム可能なルールの入口にしていくことでした。
問題は、これらの改善がウォレットをますますスマートアカウントに近づける一方で、イーサリアムの最も底層にあるデフォルトのアカウントモデルそのものに、ついに本質的に触れられていないことです。
周知のとおり、現行の体系ではイーサリアムのアカウントは大きく 2 種類に分かれます。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 がやろうとしているのは、1 回のトランザクションを、ルールに従って順序立てて実行できる「フレーム」の集合へと分解し、もともと一体化されていた検証・支払い・実行の 3 つを切り離して処理できるようにすることです。
各「フレーム」には 3 種類の実行モードがあります。
VERIFY（検証フレーム）：トランザクションが正当かどうかを検証する役割です。アカウントがカスタムした検証ロジックを実行し、通過すれば、新しく導入される APPROVE オペコードを呼び出して実行を許可し、さらに Gas 上限を指定します。
SENDER（送信フレーム）：実際の操作を実行します。送金、コントラクト呼び出しなどです。呼び出し元アドレスは取引送信者本人です。
DEFAULT（入口フレーム）：システムの入口アドレスを呼び出し元として用い、コントラクトのデプロイ、Paymaster の検証などのシーンで使用します。
この仕組みの意義は、トランザクションをより複雑にできることではありません。初めて「検証、支払い、実行」の 3 つを、アカウント動作から切り出し、プロトコル本来のネイティブなスケジューリングに委ねるのです。
なぜなら過去には、「誰がトランザクションを検証するのか」「誰が Gas を支払うのか」「誰が実際の操作を実行するのか」が、基本的に同一のアカウント動作に結び付けられていました。しかし EIP-8141 の設計下では、これらを異なるフレームに分解し、プロトコルが明確な順序で、次々と実行できます。だからこそ、アカウントはもはや単一の秘密鍵に「まとめて署名」するだけではなく、よりプログラマブルな実行主体に近い形を持てるようになり始めるのです。
具体例を挙げましょう。仮にあなたが USDC で Gas を支払って Swap を完了させたいとします。EIP-8141 の枠組みでは、理論上これは一連の完全なフレーム手順として組織できます。まずアカウントが署名と実行権限を検証し、次に支払者または Paymaster が、自分が費用を負担する意思があることを示す条件を検証します。その後、対応する資産の費用支払いを完了し、最後に本来の swap 操作を実行します。
こうすることで、Gas 支払いとメイントランザクションを同一の原子的なフローに取り込めます。つまり、すべて成功するか、すべてロールバックされます。
ユーザーにとって最も直感的な変化は、これまで多くの操作が 2〜3 ステップに分かれていて、途中に失敗リスクが存在していたのに対し、将来的にはそれがより 1 回の完全なアクションのようにできることです。そのため、この原子性も EIP-8141 がユーザー体験の断片化問題を解決したいと考える重要なポイントの 1 つです。
では、それはウォレット利用者にとって何を意味するのでしょうか。結果として最も直感的な変化は、少なくとも 4 層あります。
Gas 支払いが抽象化される：ウォレット内にステーブルコインがあることは、もはや操作するために追加で ETH を用意する必要がないことを意味します。将来的には DApp、Paymaster、またはその他のスポンサーが Gas を代わりに支払うことが、よりネイティブに行えるようになります。
多段操作が統合される：「承認 + Swap」「承認 + 仕入れ（質押）」のように現在しばしば複数回の署名が必要な手順は、より完全な 1 つの操作としてパッケージ化される機会があります。
アカウントの安全ルールが開かれる：多署名、ソーシャルリカバリー、日次限度額、タイムロック、鍵のローテーション。これらはもはや、ある特定のウォレット製品が追加で提供する高度な機能であるだけでなく、よりネイティブなアカウントロジックの上に構築される機会が生まれます。
署名方式が ECDSA の単一ルートに必ずしも固定されなくなる：これにより、アカウントが将来、異なるパスワード体系、後量子署名方式を含む体系へ移行する際に、初めてプロトコル層としての意味での可能性が生まれます。
三、なぜ Hegota のヘッドライナーにならなかったのか？
見落とされやすいものの、ウォレット利用者にとって非常に重要な点があります。仮に EIP-8141 が最終的に実装されたとしても、現行のアカウント体系がそれによって丸ごとひっくり返るわけではない、ということです。
たとえ今あなたが imToken などの既存の Web3 ウォレットを利用していても、移行は必要ありません。後方互換性があるため、既存の EOA アドレスは引き続き使えます。適切なタイミングで「アカウントの検証ロジックをアップグレード」を選ぶだけで済みます。
しかし逆に言えば、それが十分に深い変更だからこそ、最新ラウンドの議論の中で Hegota のヘッドライン機能としてそのまま採用されなかったのも事実です。もっとも、2026 年の EIP champion のプロセスに従えば、CFI（Considered for Inclusion）の意味は否定されたわけではなく、真剣に検討される段階には入ったが、最終決定して本番投入される段階にはまだ至っていない、ということです。
言い換えると、コア開発者は EIP-8141 の方向性を認めていないのではありません。その価値は認めつつも、現時点ではなお「重い」と考えているのです。
なぜなら、ネイティブなアカウント抽象は ERC-4337 のように、少数のウォレット、基盤インフラ、アプリが段階的に押し進められる性質ではありません。いったんプロトコル層に入ると、すべての実行層クライアントが真剣に実装し、テストし、協調する必要が生じ、その結果、推進のハードルが自然に上がります。そしてコア開発者は、fork の計画を立てる際に、より慎重に傾きやすくなります。
では、次に何が起きるのでしょうか。次の 2 本の流れに分けて考えられます。
EIP-8141 が CFI の状態にあることは、それが引き続き継続的に評価されていることを意味します。提案者は、トランザクションプールの安全性、検証ルール、クライアント実装に関する重要な詳細を補い続けます。その後の ACD 会議でも、さらに前進させる条件があるかどうかを改めて見直すでしょう。
これらの不確実性を継続的に圧縮できれば、次のアップグレードで、より実質的な取り込み段階へ進む機会があります。圧縮できなければ、それはより後のアップグレード周期へ先送りされる可能性も十分あります。
率直に言えば、EIP-8141 は唯一のネイティブなアカウント抽象の提案ではありませんし、そもそも既成の後量子署名ソリューションでもないため、量子計算の問題を直接解決するものではありません。しかしその重要性は、アカウントを初めて ECDSA の単一ルートから解放する、プロトコル層としての「出口」を初めて提供した点にあります。
この観点から見ると、EIP-8141 の真の価値は、それが唯一の正解かどうかではありません。「ネイティブなアカウント抽象の終着点が結局どのような姿であるべきか」という問いを、初めてイーサリアムのプロトコル議論のテーブルに、非常に完璧な形で持ち込んだことにあります。
それは唯一の案ではありません。しかし現時点で、最も野心的であり、かつ「完全なネイティブ AA（アカウント抽象）」という想像力の上限に最も近い案の 1 つであるのは確かです。
EIP-8141 が最終的に Hegota に追いつけるかどうかにかかわらず、この議論自体が少なくとも次のことを示しています。
イーサリアムは問題がその場で発酵していくのを待ってはいません。次世代のアカウント体系に向けて、日々少しずつ着実に前もって道を敷いているのです。