Native Account Abstraction + Quantum-Resistant Threat: Why Hasn't EIP-8141 Become Ethereum Hegotá's Headliner?

先週、イーサリアムのコア開発者会議で、EIP-8141をHegotaアップグレードに含めるかどうかが正式に議論され、結果は予想外でした。Vitalik自らが支持するこの提案は、Hegotaの「ヘッドライン機能」としてリストされることはなく、「考慮対象」（CFI）のステータスを獲得しました。

そして今週、Google Quantum AIチームは最新のホワイトペーパーを発表し、彼らの与えられたハードウェア仮定の下で、ECDSA-256を破るのに必要な物理量子ビットの推定値が、以前と比べて大幅に20倍減少したと述べました。量子攻撃が目前に迫っているわけではありませんが、これは私たちに現実的な警告を与えています。もしアカウントシステムが将来、検証ロジックを柔軟に変更できないなら、今日の多くのウォレット体験に関する議論は、最終的にセキュリティ問題に発展する可能性があります。

プロトコル推進の現実的な観点から見ると、EIP-8141は現在まだ重すぎます。特にクライアント実装、トランザクションプールの安全性、検証の複雑さにおいて、十分に確固たるコンセンサスが形成されていません。

しかし、現在の時点において、EIP-8141が議論され、真剣に検討されるべき点は、本当にますます増えているようです。

一、EIP-8141は結局何を解決しようとしているのか？

EIP-8141は、Vitalik Buterinとtimbeikoなどのコア貢献者によって推進され、正式名称はFrame Transactions（フレームトランザクション）です。

より理解しやすい言葉で要約すると、それが目指しているのは単に特定のウォレット機能を追加することではなく、プロトコル層から、どのアカウントも単一のECDSA署名パスに縛られることなく、より柔軟な検証と実行ロジックを持つことができるようにすることです。 

これはまた、マルチシグ、Gasスポンサーシップ、キーローテーション、ソーシャルリカバリー、さらには将来の耐量子署名スキームへの統合さえも、ウォレット外部に付加された一層の能力にとどまらず、イーサリアムのアカウントシステム内の「ネイティブメンバー」となる可能性があることを意味します。

表面上だけ見れば、EIP-8141が議論しているのは、ステーブルコインでGasを支払う、複数ステップの操作を一つのトランザクションに合成する、より柔軟な署名方式をサポートする、さらには将来の耐量子署名のための余地を残すという、非常に具体的な能力のセットのように見えます。言えることは、ERC-4337からEIP-7702に至るまでの長年にわたるウォレット体験の多くの改善は、本質的に、アカウントを単なる一つの秘密鍵ではなく、カスタマイズ可能なルールを持つエントリーポイントにしようとしていることです。

問題は、これらの改善は確かにウォレットをスマートアカウントに近づけていますが、イーサリアムの最も根本的なデフォルトのアカウントモデルには、本当に触れていないことです。

周知の通り、現行システムでは、イーサリアムアカウントは大きく二つに分類されます。一つは外部所有アカウント（EOA）で、秘密鍵によって制御され、能動的にトランザクションを開始できますが、プログラマブルな能力に欠けます。もう一つはコントラクトアカウント、つまりスマートコントラクトそのもので、複雑なロジックを実行できますが、自ら能動的にトランザクションを開始することはできません。

これにより、トランザクションを開始する能力と、単一の秘密鍵による署名が長期的に結びつけられています。この前提が変わらない限り、多くのユーザーが今日当然持つべきだと考えている能力、例えば署名ルールの柔軟な変更、他者によるGasの支払い、秘密鍵紛失後のアカウント制御権の回復、または将来の新しい暗号システムへのスムーズな移行などは、本当にアカウントのデフォルト能力となることは難しいのです。

もしあなたがimTokenや他のWeb3ウォレットを使用したことがあれば、おそらくこれらの課題にも遭遇したことがあるでしょう。例えば、ウォレットに大量のUSDCがあっても、ETHがなければトランザクションを送信できない（GasはETHでしか支払えないため）、シードフレーズを失うと完全にお金を失い、回復できない、「承認＋交換」という操作に二回署名し、二回確認する必要がある、などです。

これらの問題は、ウォレット製品が「十分に良くない」からではなく、イーサリアムのアカウントモデル自体の設計結果なのです。

この観点から見ると、過去2年間の進化は実に明確です。ERC-4337はプロトコルを変更することなく、アカウント抽象化をまずアプリケーション層で動かし始めました。EIP-7702はさらに、EOAが完全に拡張できないわけではなく、少なくともスマートアカウントに近い能力を一時的に獲得できることを証明しました。

つまり、イーサリアムはアカウント抽象化を行いたくないのではなく、より穏健で保守的な方法を用いて、この目標に徐々に近づいているのです。そしてEIP-8141の出現は、この道筋が新たな段階に到達したことを意味します。それは既存システムの周辺にスマートアカウント能力をもう一層重ねることに満足せず、アカウント抽象化をトランザクションモデル自体に直接組み込み、アカウントがプロトコル層からプログラマブルな検証と実行ロジックを備えるようにしようとしています。

これが、EIP-8141が今日再び注目を集めている理由です。一方では、上位層のウォレット体験はすでにネイティブなアカウント抽象化にますます近づいており、プロトコル層は遅かれ早かれ追いつく必要があります。他方では、量子コンピューティングがもたらす長期的な圧力が、「アカウントが署名方式を柔軟に変更できるかどうか」という遠い技術的課題を、真剣に考慮しなければならない現実的な問題へと前倒ししているのです。

二、EIP-8141はどのように機能するのか？

結局のところ、EIP-8141は全く新しいタイプのトランザクション——フレームトランザクション（Frame Transaction）を導入し、トランザクションタイプ番号は0x06です。

従来のイーサリアムトランザクションの基本ロジックが「一つのトランザクションが一回の呼び出しに対応する」ものであるならば、EIP-8141が目指すのは、一つのトランザクションをルールに従って順次実行できる「フレーム」のセットに分解し、本来結びついていた検証、支払い、実行の三つの事柄を分離して処理することです。

各「フレーム」には三つの実行モードがあります：

• VERIFY（検証フレーム）：トランザクションが合法かどうかを検証し、アカウントがカスタマイズした検証ロジックを実行します。通過した場合、新たに導入されるAPPROVEオペコードを呼び出して実行を承認し、Gas上限を指定します。
• SENDER（送信フレーム）：実際の操作、例えば送金、コントラクト呼び出しなどを実行します。呼び出し元アドレスはトランザクション送信者本人です。
• DEFAULT（エントリーフレーム）：システムエントリーアドレスを呼び出し元として、コントラクトのデプロイ、Paymasterの検証などのシナリオで使用されます。

このメカニズムの意義は、トランザクションをより複雑にできることではなく、「検証、支払い、実行」という三つの事柄を、アカウントの動作から初めて分解し、プロトコルがネイティブにスケジューリングすることにあります。

結局のところ、過去においては、誰がトランザクションを検証し、誰がGasを支払い、誰が実際の操作を実行するかは、基本的に同じアカウント動作に縛られていました。EIP-8141の設計では、これらの事柄は異なるフレームに分解され、プロトコルが明確な順序で順次実行することができます。まさにこのため、アカウントはもはや単一の秘密鍵に依存して「全体に署名」するしかなく、プログラマブルな実行主体に近い形態を備え始めるのです。

具体的な例を挙げると、あなたがUSDCでGasを支払ってSwapを完了したい場合、EIP-8141のフレームワークでは、理論的にはこれは完全なフレームプロセスとして構成できます：まずアカウントが署名と実行権限を検証し、次に支払い者またはPaymasterが自身が費用を負担する条件を検証し、その後に対応する資産の費用支払いを完了し、最後に実際のswap操作を実行します。

このようにして、Gas支払いとメイントランザクションは同じアトミックなプロセスに組み込まれ、すべて成功するか、すべてロールバックするかのどちらかになります。

ユーザーにとって最も直感的な変化は、以前は二、三つのステップに分割され、中間に失敗リスクがあった多くの操作が、将来はより一つの完全な動作のようになる可能性があることです。したがって、このアトミック性も、EIP-8141がユーザー体験の断片化問題を解決しようとする鍵の一つです。

では、これはウォレットユーザーにとって何を意味するのでしょうか？結果から見ると、最も直感的な変化は少なくとも四層あります：

• Gas支払いの抽象化：ウォレットにステーブルコインがあるからといって、操作するために追加で少しのETHを準備しなければならないということはなくなり、将来、DApp、Paymaster、または他のスポンサーがGasを代わりに支払うことが、よりネイティブになります。
• 複数ステップ操作の統合：「承認＋Swap」「承認＋ステーキング」といった、現在頻繁に複数回の署名を必要とするプロセスは、より完全な一つの操作にパッケージ化される可能性があります。
• アカウントセキュリティルールの開放：マルチシグ、ソーシャルリカバリー、日次制限、タイムロック、キーローテーションなどは、もはや特定のウォレット製品が追加で提供する高度な機能ではなく、よりネイティブなアカウントロジックの上に構築される可能性が出てきます。
• 署名スキームがECDSA単一路径に縛られなくなる：これにより、アカウントが将来、異なる暗号システム、ポスト量子署名スキームを含むものに移行することが、初めてプロトコル層の意味で可能性を持つようになります。

三、なぜHegotáの看板機能にならなかったのか？

見落とされがちですが、ウォレットユーザーにとって非常に重要な点は、たとえEIP-8141が最終的に実装されたとしても、既存のアカウントシステムが全体として覆されるわけではないということです。

たとえあなたが現在imTokenなどの既存のWeb3ウォレットを使用していても、移行する必要はありません。なぜなら後方互換性があり、既存のEOAアドレスは引き続き使用でき、適切な時期にアカウントの検証ロジックを「アップグレード」することを選択するだけで良いからです。

しかし逆に言えば、まさにそれが十分に深い変更であるがゆえに、最新の議論で直接Hegotáの看板機能にはならなかったのです。ただし、2026年のEIP championプロセスによれば、CFI（Considered for Inclusion）の意味は否定されたわけではなく、真剣に考慮される段階に入ったが、最終的に実装が決定する段階にはまだ至っていないということです。

言い換えれば、コア開発者はEIP-8141の方向性を認めていないのではなく、その価値を認めつつも、現在まだ「重すぎる」と考えているのです。

結局のところ、ネイティブなアカウント抽象化は、ERC-4337のように少数のウォレット、インフラストラクチャ、アプリケーションが徐々に推進できるものではありません。一度プロトコル層に入れば、すべての実行層クライアントが真剣に実装、テスト、調整を行う必要があり、これは必然的に推進のハードルを高め、コア開発者がフォーク計画を立てる際により慎重な姿勢を取らせることになります。

では、次に何が起こるのでしょうか？二つの線で見ることができます：

• EIP-8141がCFIステータスにあるということは、継続的に評価されていることを意味し、提案者はトランザクションプールの安全性、検証ルール、クライアント実装に関する重要な詳細を引き続き補足し、その後のACD会議でも、さらに前進する条件を備えているかどうかが再検討されます。
• これらの不確実性が継続的に圧縮されれば、その後のアップグレードでより実質的な採用段階に入る可能性があります。もしできなければ、より後のアップグレードサイクルに順延される可能性もあります。

事実に基づいて言えば、EIP-8141も唯一のネイティブアカウント抽象化提案ではなく、それ自体が既成のポスト量子署名スキームでもなく、量子コンピューティング問題を直接解決することはできません。しかし、その重要性は、アカウントがECDSA単一路径から脱却するためのプロトコル層としての出口を初めて提供した点にあります。 

この観点から見ると、EIP-8141の真の価値は、それが唯一の正解であるかどうかではなく、「ネイティブアカウント抽象化の最終形は結局どのようなものになるべきか」という問題を、初めて非常に完全な形でイーサリアムプロトコルの議論のテーブルに載せた点にあります。

それは唯一の解決策ではありませんが、確かに現在最も野心的で、「完全なネイティブAA」の想像力の上限に最も近い解決策の一つです。

EIP-8141が最終的にHegotáに間に合うかどうかに関わらず、この議論自体が少なくとも一つのことを示しています：

イーサリアムは問題が醸成されるのを待っているのではなく、日々一歩ずつ前進する方法で、次世代のアカウントシステムへの道を事前に敷設しているのです。