ネイティブアカウントの抽象化と量子脅威への耐性：なぜEIP-8141はイーサリアムの主要オプションにならないのか？

執筆者: imToken

先週、イーサリアムのコア開発者会議で、EIP-8141をHegotaアップグレードに含めるかどうかについて正式に議論されました。驚くべきことに、ヴィタリック・ブテリン氏が個人的に支持したこの提案は、Hegotaの「主要機能」としてリストアップされることなく、「含めることを検討中」（CFI）というステータスになりました。

今週、Googleの量子AIチームは新たなホワイトペーパーを発表し、既存のハードウェア要件に基づくと、ECDLP-256を解読するために必要な物理量子ビットの推定数が、以前の推定値と比べて20分の1に減少したと述べた。これは量子攻撃が差し迫っていることを意味するものではないが、アカウントシステムが将来的に検証ロジックを柔軟に変更できない場合、現在議論されているウォレット体験に関する多くの問題が、最終的にセキュリティ問題へと発展する可能性があることを強く示唆している。

プロトコルの進歩という実用的な観点から見ると、EIP-8141は依然として扱いにくく、特にクライアントの実装、トランザクションプールのセキュリティ、検証の複雑さといった点で、十分な確固たる合意がまだ得られていない。

しかしながら、現時点では、EIP-8141には議論と真剣な検討に値する側面がますます増えているように思われる。

I. EIP-8141は具体的に何を解決することを目的としているのか？

Vitalik Buterinやtimbeikoといった主要な貢献者によって推進されているEIP-8141は、正式にFrame Transactionsと命名された。

簡単に言うと、この技術の目的は単一のウォレット機能を追加することではなく、あらゆるアカウントが単一のECDSA署名パスに縛られることなく、プロトコル層においてより柔軟な検証および実行ロジックを利用できるようにすることである。

これはまた、マルチシグネチャ、ガススポンサーシップ、キーローテーション、ソーシャルリカバリ、さらには将来的な量子耐性署名ソリューションとの統合も、ウォレットの外部機能レイヤーにとどまらず、イーサリアムアカウントシステムの「ネイティブメンバー」となる可能性を秘めていることを意味します。

EIP-8141は、一見すると非常に具体的な機能群について論じているように見えます。例えば、ステーブルコインによるガス代の支払い、複数ステップの操作を単一のトランザクションにまとめること、より柔軟な署名方法のサポート、さらには将来の量子耐性署名のための領域の確保などです。ERC -4337からEIP-7702に至るまで、長年にわたってウォレットの使い勝手は大きく改善され、アカウントは単なる秘密鍵から、カスタマイズ可能なルールを備えたエントリーポイントへと本質的に変化したと言えるでしょう。

問題は、これらの改善によってウォレットがスマートアカウントに近づく一方で、イーサリアムの最下層にあるデフォルトのアカウントモデルには全く手が及ばないという点だ。

周知のとおり、現在のシステムでは、イーサリアムのアカウントは大きく2つのカテゴリに分けられます。1つは、最もよく知られている外部所有権アカウント（EOA）です。これは秘密鍵で管理され、トランザクションを積極的に開始できますが、プログラム性はありません。もう1つは、スマートコントラクトそのものであるコントラクトアカウントです。これは複雑なロジックを実行できますが、トランザクションを自ら積極的に開始することはできません。

これは、長期的にはトランザクションを開始する機能が単一の秘密鍵署名に結び付けられることを意味します。この前提が変わらない限り、署名ルールの柔軟な変更、他人にガス代を支払ってもらうこと、秘密鍵を紛失した後にアカウントの制御を取り戻すこと、将来的に新しい暗号システムへスムーズに移行することなど、ユーザーが今日当然のように享受している多くの機能は、アカウントのデフォルト機能となることはまずないでしょう。

imTokenやその他のWeb3ウォレットを使ったことがある方なら、おそらくこれらの問題点に遭遇したことがあるでしょう。例えば、ウォレットにUSDCはたくさんあってもETHがないため、トランザクションを送信できない（ガス代はETHでしか支払えないため）、ニーモニックフレーズを紛失すると全財産を失い、取り戻すことができない、そして「承認＋交換」操作1回に2つの署名と2つの確認が必要になる、といった具合です。

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

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

言い換えれば、イーサリアムはアカウント抽象化を実装したいという意欲を欠いているわけではなく、むしろ、より穏健かつ保守的な方法でこの目標に徐々に近づいてきたと言えるでしょう。EIP-8141の登場は、この取り組みが新たな節目を迎えたことを示しています。既存のシステムにスマートアカウント機能のレイヤーを追加するだけでは満足せず、アカウント抽象化をトランザクションモデル自体に直接組み込むことで、プロトコル層からアカウントがプログラム可能な検証および実行ロジックを持つことを可能にしようとしているのです。

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

II. EIP-8141はどのように動作するのか？

最終的に、EIP-8141は、トランザクションタイプ番号0x06を持つフレームトランザクションという、まったく新しいトランザクションタイプを導入しました。

従来のイーサリアムトランザクションの基本的なロジックが、1つのトランザクションが1つの呼び出しに対応するというものだとすれば、EIP-8141が目指すのは、トランザクションをルールに従って特定の順序で実行できる一連の「フレーム」に分解し、それによって元々一体化されていた検証、支払い、実行という3つの要素を分離することである。

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

VERIFY（検証フレーム）：トランザクションの正当性を検証する役割を担います。アカウント固有の検証ロジックを実行します。トランザクションが成功した場合、新たに導入されたAPPROVEオペコードを呼び出して実行を承認し、ガス制限を指定します。
送信者（送信フレーム）：資金の送金や契約の発動など、実際の操作を実行します。呼び出し元のアドレスがトランザクションの送信者となります。
デフォルト（エントリフレーム）：呼び出し元としてシステムエントリアドレスを使用し、契約の展開やペイマスターの検証などのシナリオで使用されます。

このメカニズムの重要な点は、トランザクションをより複雑にできることではなく、初めて「検証、支払い、実行」という3つの要素がアカウント操作から分離され、プロトコルのネイティブなスケジューリングに委ねられるようになったことである。

従来、トランザクションの検証、ガス料金の支払い、実際の操作の実行は、基本的にすべて同じアカウント操作に紐づいていました。しかし、EIP-8141の設計では、これらのタスクを異なるフレームに分割し、プロトコルによって明確な順序で順次実行することが可能になりました。その結果、アカウントはもはや単一の秘密鍵で「全体を署名する」必要がなくなり、プログラム可能な実行エンティティに近い形態をとるようになりました。

具体的な例として、USDCを使用してガス代を支払い、スワップ取引を完了させたいとします。EIP-8141フレームワークの下では、これは理論的には完全なフレームプロセスとして構成できます。まず、アカウントが署名と実行権限を検証します。次に、支払者またはペイマスターが手数料を負担する意思を検証します。その後、対応する資産手数料の支払いが完了し、最後に、実際のスワップ取引が実行されます。

このようにすることで、ガス料金の支払いとメインの取引を同一のアトミックプロセスに組み込むことができ、すべてが成功するか、すべてがロールバックされるかのいずれかになります。

ユーザーにとって最も直感的な変化は、これまで2つか3つのステップに分割する必要があり、失敗するリスクがあった多くの操作が、単一の完全なアクションのように実行できるようになったことです。したがって、このアトミック性は、断片化されたユーザーエクスペリエンスの問題に対するEIP-8141の解決策の重要な側面の1つです。

では、これはウォレットユーザーにとって何を意味するのでしょうか？結果を見ると、少なくとも4つの重要な変更点があります。

ガス代金の支払いは抽象化されつつあります。ウォレットにステーブルコインを入れておいても、取引のために別途ETHを用意する必要はなくなります。将来的には、ガス代金の支払いはDApps、Paymaster、その他のスポンサーによって処理され、よりネイティブな決済手段となるでしょう。
複数のステップからなる操作が統合されつつあります。 「承認＋スワップ」や「承認＋ステーキング」など、複数の署名を必要とするプロセスは、より完全な操作としてパッケージ化できます。
アカウントのセキュリティルールが緩和されました。マルチシグネチャ、ソーシャルリカバリー、日次制限、タイムロック、キーローテーションは、もはやウォレット製品が提供する高度な機能にとどまらず、よりネイティブなアカウントロジックに基づいて構築される機会が生まれました。
署名方式はもはや単一のECDSAパスに限定される必要がなくなった。これにより、プロトコルレベルで初めて、アカウントが将来的に、ポスト量子署名方式を含む様々な暗号システムへ移行することが可能になる。

3. なぜ彼女はヘゴタのトップスターになれなかったのか？

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

imTokenなどの既存のWeb3ウォレットを現在ご利用の場合でも、下位互換性があるため移行する必要はありません。既存のEOAアドレスは引き続きご利用いただけます。アカウント認証ロジックを「アップグレード」するタイミングが適切であれば、そのオプションを選択するだけで済みます。

逆に、変更内容があまりにも徹底的だったため、最新の議論ではHegotáの目玉機能にはならなかった。しかし、2026年のEIPチャンピオンプロセスによれば、CFI（採用検討中）とは、却下されたという意味ではなく、真剣な検討段階に入ったものの、最終決定にはまだ至っていないという意味である。

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

結局のところ、少数のウォレット、インフラストラクチャ、アプリケーションによって段階的に普及させることができるERC-4337とは異なり、ネイティブアカウントの抽象化は、プロトコル層に導入されると、すべての実行層クライアントが慎重に実装、テスト、調整を行う必要があることを意味します。これは必然的に普及のハードルを上げ、コア開発者がフォークを計画する際に、より慎重になることを意味します。

では、次に何が起こるのでしょうか？それを2つの線に分解してみましょう。

EIP-8141はCFIステータスにあるため、継続的な評価が継続中です。提案書の作成者は、トレーディングプールのセキュリティ、検証ルール、クライアント実装に関する重要な詳細情報を引き続き補足していきます。今後のACD会議では、EIP-8141がさらなる進展に向けて準備が整っているかどうかも再検討されます。
これらの不確実性を継続的に低減できれば、その後のアップグレードにおいてより本格的な組み込み段階に入る機会が得られる。そうでなければ、後のアップグレードサイクルに延期される可能性が高い。

現実的に言えば、EIP-8141は唯一のネイティブアカウント抽象化提案ではなく、量子コンピューティングの問題を直接解決できる既製のポスト量子署名方式でもありません。しかし、その重要性は、アカウントがECDSAの単一パスから抜け出すためのプロトコルレベルの出口を初めて提供するという点にあります。

この観点からすると、EIP-8141の真の価値は、それが唯一の正解であるかどうかではなく、「ネイティブアカウントの抽象化の最終結果がどのようなものであるべきか」という問題を、初めて非常に包括的な形でイーサリアムプロトコルの議論の場に持ち込んだという点にある。

これは唯一の解決策ではないが、現在利用可能な解決策の中で最も野心的なものの1つであり、「完全なネイティブAA」という構想の限界に最も近いものであることは間違いない。

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

イーサリアムは、問題が深刻化するのをただ待つのではなく、次世代のアカウントシステムへの道を段階的に切り開いていった。