その結果、取引を開始する能力が、単一の秘密鍵による署名と長期にわたって結び付けられてしまっています。この前提が変わらない限り、柔軟に署名ルールを差し替えること、他人に Gas を代わりに支払わせること、秘密鍵を失った後にアカウントの制御権を回復すること、あるいは将来新しいパスワード体系へスムーズに移行することなど、今日多くのユーザーが当然持つべきだと感じている能力が、アカウントのデフォルト能力として本当に実現するのは難しいままです。
もしあなたが imToken や他の Web3 ウォレットを使ったことがあるなら、たいていこれらの痛点にも遭遇しているはずです。たとえば、ウォレット内に USDC はたくさんあるのに ETH がなくて取引を出せない（Gas は ETH でしか支払えないため）。また、シードフレーズを失うと完全にお金を失い、復元できない。「認可 + 交換」のような操作は、署名を 2 回、確認を 2 回といった形になってしまう、などです。
なぜなら、これまで誰が取引を検証し、誰が Gas を支払い、誰が実際の操作を実行するかは、基本的に同じアカウント動作に結び付けられていましたが、EIP-8141 の設計の下では、これらは異なるフレームに分解でき、プロトコルが明確な順序に従ってそれらを順番に実行できるようになるからです。だからこそ、アカウントは単一の秘密鍵に頼って「全体に署名する」だけではなく、よりプログラマブルな実行主体に近い形を持ち始めます。
ネイティブアカウント抽象化 + 量子耐性：なぜEIP-8141はまだイーサリアムのHegotáの看板になっていないのか？
EIP-8141 は、アカウント抽象化、Gas の支払い、署名の柔軟性をプロトコル層に直接下ろそうとする試みです。
執筆：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 へと、ウォレット体験の多くの改善が本質的に行ってきたのは、アカウントを「単なる秘密鍵」ではなく「自分でルールを定義できる入口」にしていくことです。
問題は、これらの改善が確かにウォレットをますますスマートアカウントのようにしている一方で、イーサリアムの最底層にあるデフォルトのアカウントモデルに本質的にはまだ触れていないことです。
周知のとおり、現行の体系ではイーサリアムのアカウントは大きく 2 種類に分かれます。1 つは外部所有アカウント、つまり皆が最もよく知っている EOA で、秘密鍵によって制御され、取引を自ら開始できますが、プログラマブル性は欠けています。もう 1 つはコントラクトアカウント、つまりスマートコントラクトそのもので、複雑なロジックを実行できますが、自ら取引を開始することはできません。
その結果、取引を開始する能力が、単一の秘密鍵による署名と長期にわたって結び付けられてしまっています。この前提が変わらない限り、柔軟に署名ルールを差し替えること、他人に Gas を代わりに支払わせること、秘密鍵を失った後にアカウントの制御権を回復すること、あるいは将来新しいパスワード体系へスムーズに移行することなど、今日多くのユーザーが当然持つべきだと感じている能力が、アカウントのデフォルト能力として本当に実現するのは難しいままです。
もしあなたが imToken や他の Web3 ウォレットを使ったことがあるなら、たいていこれらの痛点にも遭遇しているはずです。たとえば、ウォレット内に USDC はたくさんあるのに ETH がなくて取引を出せない（Gas は ETH でしか支払えないため）。また、シードフレーズを失うと完全にお金を失い、復元できない。「認可 + 交換」のような操作は、署名を 2 回、確認を 2 回といった形になってしまう、などです。
これらの問題は、ウォレット製品が「十分に良くない」からではなく、イーサリアムのアカウントモデルそのものの設計結果です。
この観点から見ると、過去 2 年の進化はすでに非常に明確です。ERC-4337 はプロトコルを変更せずに、アカウント抽象化をまずアプリケーション層で動かす形にしました。さらに EIP-7702 は、EOA は完全に拡張できないわけではなく、少なくとも一時的にスマートアカウントに近い能力を得られることを示しているのです。
つまり、イーサリアムはアカウント抽象化をやりたくないのではなく、より温和で、より保守的なやり方で、段階的にその実現へと近づけてきた、ということです。そして EIP-8141 の登場は、この道が新しい節目に到達したことを意味します。現行体系の外側にもう 1 層スマートアカウント能力を重ねることに満足せず、アカウント抽象化を取引モデル自体に直接組み込み、アカウントがプロトコル層の段階からプログラマブルな検証と実行ロジックを備えることを試みるからです。
そのため、なぜ EIP-8141 が今日になって再び熱を帯びているのかが分かります。ひとつには、上層のウォレット体験が、ネイティブなアカウント抽象にますます近づいてきており、プロトコル層も遅かれ早かれ追いつく必要があるからです。もうひとつには、量子計算がもたらす長期的な圧力が、「アカウントが署名方式を柔軟に差し替えられるか」という論点を、遠い技術課題から、早い段階で真剣に考慮すべき現実の問題へと前倒ししているからでもあります。
二、EIP-8141 はどのように動作する？
結局のところ、EIP-8141 はまったく新しい取引タイプを導入します――フレーム取引（Frame Transaction）。取引タイプ番号は 0x06 です。
従来のイーサリアム取引の基本ロジックが「1 つの取引＝1 回の呼び出し」に対応しているとすれば、EIP-8141 がやろうとしているのは、「1 つの取引」を、ルールに従って順序どおりに実行できる一連の「フレーム」に分解し、その結果として、もともとひとまとめにされていた検証、支払い、実行の 3 つの事柄を切り離して処理することです。
各「フレーム」には 3 つの実行モードがあります：
この仕組みの意義は、取引をより複雑にできることではありません。初めて「検証、支払い、実行」の 3 つの事柄を、アカウントの動作から切り離し、プロトコルネイティブの調停によって取り扱うことです。
なぜなら、これまで誰が取引を検証し、誰が Gas を支払い、誰が実際の操作を実行するかは、基本的に同じアカウント動作に結び付けられていましたが、EIP-8141 の設計の下では、これらは異なるフレームに分解でき、プロトコルが明確な順序に従ってそれらを順番に実行できるようになるからです。だからこそ、アカウントは単一の秘密鍵に頼って「全体に署名する」だけではなく、よりプログラマブルな実行主体に近い形を持ち始めます。
具体的な例を挙げると、あなたが USDC で Gas を支払って Swap を完了したいとします。EIP-8141 の枠組みでは、理論上このことは、ひと続きのフレーム手順として編成できます。まずアカウントが署名と実行権限を検証し、次に支払い側または Paymaster が、費用負担を引き受けることに同意する条件を検証します。その後、対応する資産の費用支払いを完了し、最後に本当の swap 操作を実行します。
これにより、Gas の支払いとメイン取引は同じ原子的なフローに取り込むことができ、すべて成功するか、すべてロールバックされるかのどちらかになります。
ユーザーにとって最も直感的な変化は、これまで多くが 2〜3 ステップに分解され、中間に失敗リスクが存在していた操作が、将来的には 1 回の完全なアクションのように振る舞えるようになることです。したがって、この原子性こそが、EIP-8141 がユーザー体験の断片化問題を解決したいと考える鍵の一つでもあります。
では、これはウォレットユーザーにとって何を意味するのでしょうか。結果から見ると、少なくとも 4 層の直感的な変化があります：
三、なぜ Hegotá の看板にならなかった？
見落とされやすいものの、ウォレットユーザーにとって非常に重要な点があります。それは、たとえ EIP-8141 が最終的に実現したとしても、現行のアカウント体系がそのまま丸ごと覆されるわけではないということです。
仮にあなたが現時点で imToken などの既存の Web3 ウォレットを使っていたとしても、移行は不要です。後方互換があるためです。既存の EOA アドレスは引き続き使えますし、適切なタイミングで「アップグレードされた」アカウントの検証ロジックを選ぶだけで済みます。
しかし逆に言えば、十分に深く変えているからこそ、最新ラウンドの議論で Hegotá の看板機能として直接は選ばれなかったのです。もちろん、2026 年の EIP champion プロセスに従えば、CFI（Considered for Inclusion）の意味は「否定」ではありません。とはいえ、それは最終的な板決めと実装の段階にあるのではなく、真剣に検討し始めた段階である、ということです。
言い換えれば、コア開発者は EIP-8141 の方向性を認めていないわけではなく、その価値を認めつつも、現時点ではまだ「重すぎる」と見ているのです。
なぜなら、ネイティブのアカウント抽象化は ERC-4337 のように、一部のウォレットやインフラ、アプリによって段階的に推し進められるものではありません。いったんプロトコル層に入ると、すべての実行層クライアントが真剣に対応し、テストし、協調する必要が出てくるため、推進のハードルが自ずと上がります。それゆえ、コア開発者は fork の計画を立てる際、より慎重に寄りがちになるのです。
では次に何が起こるのでしょうか。2 つの流れに分けて考えられます：
率直に言えば、EIP-8141 は唯一のネイティブ・アカウント抽象化提案ではありません。そもそも、特定の既成の耐量子署名方式のようなもので、量子計算問題を直接解決できるわけでもありません。ただし、その重要性は、初めてアカウントを ECDSA の単一パスから解放する、プロトコル層の意味での出口を提示した点にあります。
この観点から見ると、EIP-8141 の真の価値は、それが唯一の正解かどうかにはありません。むしろ「ネイティブ・アカウント抽象の終着点が最終的にどのような姿であるべきか」という問いを、初めてイーサリアムのプロトコル議論のテーブルの上に、非常に完成度高く据えたところにあります。
唯一の案ではありませんが、それでも確かに、今ある中では最も野心的で、かつ「完全なネイティブ AA」の想像力の上限に最も近い案の一つです。
EIP-8141 が最終的に Hegotá に間に合うかどうかにかかわらず、この議論それ自体は少なくとも一つのことを示しています：
イーサリアムは問題がその場で発酵するのを待っているのではなく、次世代のアカウント体系に向けて、ひとつずつ着実に先回りして道を開いているのです。