ネイティブ・アカウント抽象化＋耐量子攻撃性：EIP-8141 はなぜ、まだ以太坊のヘゴタ（Hegotá）アップグレードにおける主力機能になっていないのか？
TechFlow厳選深潮セレクト
ネイティブ・アカウント抽象化＋耐量子攻撃性：EIP-8141 はなぜ、まだ以太坊のヘゴタ（Hegotá）アップグレードにおける主力機能になっていないのか？
EIP-8141は、アカウント抽象化、ガス支払い、および署名の柔軟性をプロトコル層に直接組み込むことを目指す試みである。
Web3業界の深掘り報道に専念し潮流を洞察執筆：imToken
先週、イーサリアムのコア開発者会議では、EIP-8141がHegotáアップグレードに採用されるかが正式に議論されたが、その結果は予想外のものとなった。この提案はヴィタリク・ブテリン氏が直接支援するものでありながら、Hegotáの「注目機能（headline feature）」には選ばれず、「検討対象（Considered for Inclusion：CFI）」というステータスが与えられた。
一方、今週Googleの量子AIチームが最新のホワイトペーパーを公開し、同チームが仮定したハードウェア条件下において、ECDLP-256を解読するために必要な物理量子ビット数の見積もりが、従来比で約20倍も減少したと報告した。これは直ちに量子攻撃が現実に迫っていることを意味するものではないが、確かに私たちにこうした警告を発している——もし将来的にアカウント体系が検証ロジックを柔軟に変更できないようであれば、今日多くのウォレット体験に関する議論は、最終的にはすべてセキュリティ問題へと転化してしまう可能性がある。
現実的なプロトコル推進の観点から見れば、EIP-8141は現時点でも依然として「重すぎる」状態にある。特にクライアント実装、トランザクションプールのセキュリティ、および検証の複雑さといった面で、十分に固まった合意がまだ形成されていない。
しかし、現在のこのタイミングにおいて、EIP-8141が議論され、真剣に検討されるべき価値を持つポイントは、確実に増えてきているように思われる。
一、EIP-8141が解決しようとしている課題とは何か？
EIP-8141は、ヴィタリク・ブテリン氏とtimbeiko氏などのコア貢献者により推進されており、正式名称は「Frame Transactions（フレームトランザクション）」である。
より分かりやすい一言でまとめると、この提案が目指すのは、特定のウォレット機能を単独で追加することではなく、プロトコル層からあらゆるアカウントをECDSA署名パスという単一の制約から解放し、より柔軟な検証および実行ロジックを可能にすることである。
つまり、マルチシグ、Gasスポンサーシップ、鍵ローテーション、ソーシャルリカバリー、さらには将来の耐量子署名スキームへの接続なども、もはやウォレット外部に付加された機能ではなく、イーサリアムのアカウント体系に組み込まれた「ネイティブな構成要素」として実現可能になるということである。
表面的に見れば、EIP-8141は一見非常に具体的な機能群について議論している：安定コインによるGas支払い、複数の操作を1つのトランザクションに統合、より柔軟な署名方式のサポート、さらには将来の耐量子署名への対応準備まで含む。言い換えれば、ERC-4337からEIP-7702に至るまで、長年にわたりウォレット体験の向上を目指して行われてきた多くの改善策は、本質的に「アカウント＝単一の秘密鍵」という概念から脱却し、独自のルールを定義可能なエントリポイントへと進化させようとする試みであった。
問題は、こうした改善によってウォレットがますます「スマートアカウント」に近づいてきたにもかかわらず、イーサリアムの最も基本的なデフォルトアカウントモデルそのものには、いまだに本質的な手が加えられていない点にある。
ご存知の通り、現行のイーサリアムではアカウントは大きく二種類に分けられる。一つは外部所有アカウント（EOA）であり、最も一般的なタイプで、秘密鍵によって制御され、自発的にトランザクションを開始できるが、プログラマブル性を持たない。もう一つはコントラクトアカウント、すなわちスマートコントラクトそのものであり、複雑なロジックを実行できるものの、自発的にトランザクションを開始することはできない。
このため、「トランザクションを開始する能力」と「単一の秘密鍵による署名」が長期間にわたって密接に結びついたままになっている。この前提が変わらない限り、ユーザーが今日当然のように享受すべきだと考える多くの機能——例えば、署名ルールの柔軟な変更、他者によるGas代行支払い、秘密鍵紛失後のアカウント制御権の回復、あるいは将来における新しい暗号体系へのスムーズな移行——は、アカウントのデフォルト機能として真に実現することが極めて困難となる。
imTokenや他のWeb3ウォレットをご利用になったことがある方であれば、以下のような課題を経験したことがあるだろう。たとえば、ウォレット内に多数のUSDCが保有されているにもかかわらず、ETHが不足しているためにトランザクションを送信できない（GasはETHでのみ支払えるため）；助記詞を紛失すると資金を完全に失ってしまう（復元不可）；また、「承認＋交換」といった操作を実行する際に、2回の署名と2回の確認が必要になるなどである。
これらの問題は、決してウォレット製品が「不十分」だから生じるものではなく、イーサリアムのアカウントモデルそのものの設計に起因するものである。
この観点から見れば、過去2年間の進化はすでに非常に明瞭である。ERC-4337はプロトコルを変更せずに、アプリケーション層でまずアカウント抽象化（Account Abstraction：AA）を実現した。さらにEIP-7702は、EOAが完全に拡張不能であるわけではないことを示しており、少なくとも一時的にスマートアカウントに近い機能を獲得できることを証明した。
つまり、イーサリアムはアカウント抽象化を望んでいないわけではなく、むしろより穏やかで慎重な方法で、これを段階的に実現しようとしてきたのである。そしてEIP-8141の登場は、まさにこの道筋が新たな節目を迎えたことを意味している。それは、既存の枠組みの周辺にさらに一層のスマートアカウント機能を重ねるのではなく、アカウント抽象化をトランザクションモデルそのものに直接埋め込み、アカウントをプロトコル層からして検証・実行ロジックをプログラマブルに持つ存在にしようとする試みなのである。
これが、EIP-8141が今日再び注目を集める理由である。一方では、上位レイヤーにおけるウォレット体験がすでにネイティブなアカウント抽象化に非常に近づいているため、プロトコル層もいずれはそれに追随せざるを得なくなる。他方では、量子計算がもたらす長期的な圧力が、「アカウントが署名方式を柔軟に変更できるかどうか」という課題を、かつては遠い将来の技術的議題と見なされていたものが、いまや真剣に検討しなければならない現実的な問題へと前倒しさせているのである。
二、EIP-8141はどのように動作するのか？
要するに、EIP-8141は一種類の全く新しいトランザクションタイプ——「フレームトランザクション（Frame Transaction）」を導入するものであり、そのトランザクションタイプ番号は0x06である。
従来のイーサリアムトランザクションが「1トランザクション＝1回の呼び出し」という基本ロジックに基づいているのに対し、EIP-8141は、1つのトランザクションを、所定のルールに従って順次実行可能な複数の「フレーム」に分解することで、「検証」「支払い」「実行」という三つの処理を分離して扱おうとするものである。
各「フレーム」には以下の三種類の実行モードがある：
- VERIFY（検証フレーム）：トランザクションの正当性を検証するフレーム。アカウントが独自に定義した検証ロジックを実行し、それが成功すれば、新しく導入されるAPPROVEオペコードを呼び出して実行を承認し、Gas上限を指定する。
- SENDER（送信フレーム）：実際に転送やコントラクト呼び出し等の操作を実行するフレーム。呼び出し元アドレスはトランザクション送信者本人である。
- DEFAULT（エントリーフレーム）：システムのエントリーアドレスを呼び出し元として使用し、コントラクトのデプロイやPaymasterの検証などの用途に使われる。
この仕組みの意義は、単にトランザクションをより複雑なものにするという点にはなく、初めて「検証」「支払い」「実行」という三つの処理を、アカウントのアクションから分離し、プロトコルがネイティブにスケジューリングすることを可能にする点にある。
これまで、「誰が検証を行うか」「誰がGasを支払うか」「誰が実際の操作を実行するか」という三つの役割は、基本的に同一のアカウントアクションに束縛されていた。ところが、EIP-8141の設計では、これら三つの処理が異なるフレームとして分割され、プロトコルが明確な順序で逐次実行されるようになる。それゆえ、アカウントはもはや単一の秘密鍵による「全体署名」に依存する必要がなくなり、むしろプログラマブルな実行主体に近い形態へと進化を始めるのである。
具体例を挙げよう。あなたがUSDCでGasを支払い、Swap操作を完了したいと仮定する。EIP-8141の枠組みでは、この一連の処理は理論上、完全なフレームフローとして構成可能である。すなわち、まずアカウントが署名および実行権限を検証し、次に支払者またはPaymasterが自身が費用負担を引き受ける条件を検証し、その後対応する資産による費用支払いを行い、最後に実際のSwap操作を実行する、という流れである。
これにより、Gas支払いと主トランザクションが、単一の原子的フローに統合される。つまり、すべてが成功するか、すべてがロールバックされるかのどちらかになる。
ユーザーにとって最も直感的な変化は、従来2～3ステップに分かれ、途中で失敗リスクを伴っていた操作が、今後はまるで1つの完結した動作のように扱えるようになる点である。この「原子性」こそが、EIP-8141がユーザー体験の断片化という課題を解決しようとする核心的な要素の一つである。
では、これはウォレットユーザーにとって何を意味するのか？結果として、最も直感的に感じられる変化は少なくとも以下の4点に集約される：
- Gas支払いの抽象化：ウォレット内に安定コインがあれば、もはや操作のために別途ETHを準備する必要がなくなる。今後はDAppやPaymaster、あるいは他のスポンサーがGasを代行支払うことが、よりネイティブな形で実現可能になる。
- 複数ステップ操作の統合：現状では頻繁に複数回の署名を必要とする「承認＋Swap」や「承認＋ステーキング」などのフローが、1つのより包括的な操作としてパッケージ化される可能性がある。
- アカウントセキュリティルールの開放：マルチシグ、ソーシャルリカバリー、日次限度額、タイムロック、鍵ローテーションなどは、もはや特定のウォレット製品が提供する高度な付加機能ではなく、よりネイティブなアカウントロジックの基盤の上に構築されるようになる。
- 署名スキームがECDSA単一パスに拘束されなくなる：これにより、アカウントが将来異なる暗号体系、すなわち耐量子署名スキームへと移行することが、プロトコルレベルで初めて可能になる。
三、なぜHegotáの「頭牌」にならなかったのか？
ウォレットユーザーにとって非常に重要だが、しばしば見落とされがちな点は：たとえEIP-8141が最終的に実装されたとしても、既存のアカウント体系が全面的に破棄されることはない。
たとえば、現在imTokenなどの既存Web3ウォレットをお使いの方でも、アカウントを移行する必要は一切ない。なぜなら、EIP-8141は後方互換性を備えており、既存のEOAアドレスはそのまま使用可能であるからだ。必要に応じて、適切なタイミングでアカウントの検証ロジックを「アップグレード」するだけである。
逆に言えば、この提案が変えようとしているのはあまりにも根本的な部分であるため、最新の議論で即座にHegotáの「頭牌」機能とならなかったのである。ただし、2026年のEIPチャンピオンプロセスによれば、「CFI（Considered for Inclusion）」とは、否認されたという意味ではなく、真剣な検討段階に入ったが、まだ最終決定・実装時期が確定していないという意味である。
言い換えれば、コア開発者はEIP-8141の方向性を否定しているわけではなく、その価値を認めつつも、現時点ではまだ「重すぎる」と判断しているのである。
というのも、ネイティブなアカウント抽象化は、ERC-4337のように少数のウォレット・インフラ・アプリケーションが徐々に推進できるものとは異なり、一度プロトコル層に取り込まれれば、すべての実行層クライアントが真剣に実装・テスト・調整を行わなければならない。これは必然的に導入のハードルを高め、フォーク計画においてもコア開発者がより慎重な姿勢を取ることにつながる。
では、今後どのような展開が予想されるのか？二つの軸で整理できる：
- EIP-8141がCFIステータスにある以上、引き続き継続的な評価が行われる。提案者は、トランザクションプールのセキュリティ、検証ルール、クライアント実装に関する重要な詳細をさらに補足し、今後のACD（All Core Devs）会議で、さらに前進するための条件が整ったかどうかが再検討される。
- これらの不確実性が継続的に縮小できれば、次のアップグレードでより実質的な採用段階へと進む可能性がある。逆に、それが達成されなければ、より遅いアップグレード周期へと順延される可能性もある。
率直に言って、EIP-8141は唯一のネイティブアカウント抽象化提案でもなければ、既存の耐量子署名スキームを直接提供するものでもない。それゆえ、量子計算の脅威を即座に解決するものではない。しかし、その重要性は、アカウントがECDSA単一パスから脱却するための、プロトコルレベルにおける最初の「出口」を提示した点にある。
この観点から見れば、EIP-8141の真の価値は、「これが唯一の正解であるかどうか」にはなく、むしろ「ネイティブなアカウント抽象化の最終形は一体どのようなものか？」という問いを、イーサリアムプロトコルの議論のテーブルの上に、初めて完全な形で載せたという点にある。
それは唯一の解決策ではないが、現時点で最も野心的であり、また「完全なネイティブAA」という想像の上限に最も近い提案の一つである。
EIP-8141が最終的にHegotáに間に合うかどうかはさておき、この議論そのものが少なくとも一つの事実を明らかにしている：
イーサリアムは問題が深刻化するのをただ待っているわけではなく、日々着実に、次世代アカウント体系のための土台を築き始めている。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@imTokenOfficial
