執筆：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署名パスに縛られず、より柔軟な検証と実行ロジックを持てるようにすることです。
これは、マルチシグ、ガススポンサー、キーのローテーション、ソーシャルリカバリー、さらには将来的な量子耐性署名方式への対応が、ウォレットの外部に追加される機能ではなく、イーサリアムアカウントシステムの「原生メンバー」として実現される可能性があることを意味します。
表面だけ見ると、EIP-8141 では、ステーブルコインでのガス代支払い、複数のステップを1つのトランザクションに統合する、より柔軟な署名方式のサポート、さらには将来的な耐量子署名への対応を確保するといった、非常に具体的な機能が議論されています。ERC-4337 から EIP-7702 に至るまで、長年にわたりウォレット体験の改善が行われてきましたが、これらは本質的にアカウントを単なる秘密鍵ではなく、カスタムルールを定義できるエントリーポイントにするためのものでした。
問題は、これらの改善によりウォレットがますますスマートアカウントに似てきている一方で、イーサリアムの最下層のデフォルトアカウントモデルには真正に触れられていないことです。
既存のシステムにおいて、イーサリアムアカウントは大きく二つのタイプに分けられます。一つは外部所有アカウント（EOA）で、最もよく知られており、秘密鍵によって制御され、取引を自発的に発信できますが、プログラミング機能は備えていません。もう一つはコントラクトアカウント、すなわちスマートコントラクトそのもので、複雑なロジックを実行できますが、自発的に取引を発信することはできません。
このため、取引を発行する能力は、単一の秘密鍵署名と長く結びついてきました。この前提が変わらない限り、ユーザーが今日当然のように持つべきだと感じる多くの機能、たとえば署名ルールの柔軟な変更、他者によるガス代の支払い、秘密鍵紛失後のアカウント制御権の回復、または将来のスムーズな暗号システムへの移行などは、アカウントのデフォルト機能として実現することが難しくなります。
imTokenやその他のWeb3ウォレットを使用したことがある場合、次のような課題に直面したことがあるでしょう。たとえば、ウォレットにUSDCがたくさんあるが、ETHが不足しているため取引を送信できない（ガス料金はETHでのみ支払えるため）；メンションフレーズを紛失すると資金を完全に失い、復元できない；「承認＋交換」の操作を2回署名し、2回確認しなければならないなど。
これらの問題は、ウォレット製品が「十分ではない」ためではなく、イーサリアムのアカウントモデル自体の設計によるものです。
この観点から見ると、過去2年間の進化はすでに非常に明確です。ERC-4337はプロトコルを変更せずに、アカウント抽象化をアプリケーション層で実現しました。また、EIP-7702は、EOAが完全に拡張できないわけではなく、少なくとも一時的にスマートアカウントに近い一部の機能を獲得できることをさらに証明しました。
つまり、イーサリアムはアカウント抽象を実現したくないのではなく、より穏やかで保守的な方法で着実にその実現に近づけてきたのです。EIP-8141の登場は、この道筋が新たな節目を迎えたことを意味します。従来のシステムの外側にスマートアカウント機能を重ねるだけではなく、アカウント抽象をトランザクションモデルそのものに直接組み込み、アカウントがプロトコル層からプログラム可能な検証と実行ロジックを備えるようにしようとしています。
これがEIP-8141が今日再び注目を集める理由です。一方で、上位ウォレット体験は既にネイティブアカウント抽象に近づいており、プロトコル層もいずれ追いつかなければなりません。他方で、量子コンピューティングによる長期的な圧力により、「アカウントが署名方式を柔軟に変更できるかどうか」という遠い技術的課題が、真剣に検討すべき現実の問題として前倒しされています。
二、EIP-8141はどのように機能しますか？
結局のところ、EIP-8141は、交易タイプ番号0x06として、フレーム交易（Frame Transaction）という新しい交易タイプを導入しました。
従来のイーサリアム取引の基本的なロジックが、1つの取引に対して1回の呼び出しに対応するものであるとすれば、EIP-8141は、1つの取引をルールに従って順次実行される「フレーム」のセットに分解し、従来束ねられていた検証、支払い、実行の3つの処理を分離して処理することを目指しています。
各「フレーム」には3つの実行モードがあります：
- VERIFY（検証フレーム）：取引の正当性を検証し、アカウントのカスタム検証ロジックを実行します。検証が成功した場合、新しく導入されたAPPROVEオペコードを呼び出して実行を承認し、ガス上限を指定します。
- SENDER（送信フレーム）：送金やコントラクトの呼び出しなどの実際の操作を実行します。呼び出し元アドレスは、トランザクションの送信者自身です。
- DEFAULT（入口フレーム）：システム入口アドレスを呼び出し元として使用し、コントラクトのデプロイやPaymasterの検証などのシナリオに使用します；
このメカニズムの意義は、取引をより複雑にすることではなく、初めて「検証、支払い、実行」の3つのプロセスをアカウント操作から分離し、プロトコルのネイティブなスケジューリングに委ねることです。
過去は、誰が取引を検証し、誰がガスを支払い、誰が実際の操作を実行するかが、基本的に同じアカウントのアクションに束縛されていましたが、EIP-8141の設計では、これらの処理が異なるフレームに分割され、プロトコルが明確な順序で順次実行できるようになります。そのため、アカウントはもはや単一の秘密鍵に依存して「全体に署名」する必要がなくなり、よりプログラマブルな実行主体に近い形態を備えるようになります。
具体的例として、USDCを使ってGasを支払い、Swapを実行すると仮定します。EIP-8141のフレームワーク下では、このプロセスは一連のフレームワークとして構成できます：まずアカウントが署名と実行権限を検証し、次に支払者またはPaymasterが自ら費用を負担することを条件付きで確認し、その後対応する資産による費用支払いが行われ、最後に真正的なSwap操作が実行されます。
これにより、ガス支払いとメインの取引が同じ原子的なプロセスに統合され、すべてが成功するか、すべてがロールバックされます。
ユーザーにとって最も直観的な変化は、これまで複数のステップに分割され、途中で失敗するリスクがあった操作が、今後は単一の完全なアクションのように実行できるようになる点です。この原子性は、EIP-8141がユーザー体験の断片化を解決しようとする鍵の一つでもあります。
これはウォレットユーザーにとって何を意味するのでしょうか？結果として、最も直観的な変化は少なくとも4つあります：
- ガス料金の支払いが抽象化：ウォレットに安定通貨が入っていれば、操作のために追加でETHを用意する必要がなくなり、今後はDApp、Paymaster、またはその他のスポンサーがガス料金を代行支払うことがよりネイティブになる。
- 複数のステップが統合されました：「承認 + スワップ」や「承認 + 質入れ」などの、これまで複数回の署名を必要としていたプロセスが、より包括的な1つの操作としてパッケージ化される機会があります。
- アカウントセキュリティルールが有効化されました：マルチシグ、ソーシャルリカバリー、日次限度額、タイムロック、キーのローテーションは、もはや特定のウォレット製品に付加される高度な機能ではなく、よりネイティブなアカウントロジック上に構築される機会を得始めています；
- 署名方式がもはやECDSAの単一パスに固定される必要はなく、これによりアカウントが今後、後量子署名方式を含む異なる暗号体系へ移行することが、プロトコル層での可能性として初めて実現した。
三、なぜヘゴタのトップにはなれなかったのか？
EIP-8141が最終的に実装されたとしても、既存のアカウントシステムが全体的に廃止されることはないという点は、ウォレットユーザーにとって非常に重要だが、見過ごされがちである。
現在imTokenなどの既存のWeb3ウォレットをご利用の場合、移行は必要ありません。バックワード互換性があるため、既存のEOAアドレスを引き続き使用でき、適切なタイミングでアカウントの認証ロジックを「アップグレード」するだけです。
しかし逆に言えば、その変更が十分に深かったため、最新の議論で直接Hegotáの主要機能とはならなかったのです。ただし、2026年のEIP championプロセスによれば、CFI（Considered for Inclusion）は否定を意味するのではなく、本格的な検討段階に入ったことを示しており、まだ最終的な採用とリリースには至っていない段階です。
言い換えれば、コア開発者はEIP-8141の方向性を否定しているのではなく、その価値を認めつつ、現在依然としてあまりに「重い」と考えています。
結局、ネイティブアカウント抽象はERC-4337のように少数のウォレット、インフラ、アプリケーションによって段階的に推進できるものではなく、プロトコル層に導入されると、すべての実行層クライアントが本格的に実装、テスト、協調する必要があり、これは自然に推進のハードルを高め、コア開発者がフォーク計画を立てる際により慎重な方向に傾くことになる。
それでは、次に何が起こるのでしょうか？これは2つの軸に分けて考えられます：
- EIP-8141はCFI状態であるため、現在も継続的に評価が行われており、提案者はトランザクションプールのセキュリティ、検証ルール、クライアント実装に関する重要な詳細を引き続き補完します。今後のACD会議では、この提案がさらに進展する条件を満たしているか再検討されます。
- これらの不確実性が継続的に圧縮されれば、後続のアップグレードでより本質的な採用段階に進む機会がある。そうでなければ、より遅いアップグレードサイクルに延期される可能性も十分にある。
正直に言えば、EIP-8141は唯一のネイティブアカウント抽象化提案ではなく、既存の後量子署名方式でもなく、量子計算の問題を直接解決することはできませんが、その重要性は、アカウントがECDSAの単一パスから脱却するためのプロトコル層での出口を初めて提供した点にあります。
この観点から見ると、EIP-8141の真の価値は、それが唯一の正解であるかどうかではなく、その提案が「ネイティブなアカウント抽象化の最終形態はどのようなものであるべきか」という問いを、初めて完全な形でイーサリアムプロトコルの議論のテーブルに載せた点にあります。
それは唯一の解決策ではありませんが、現在最も野心的で、「完全なネイティブAA」の想像の限界に最も近い解決策の一つです。
EIP-8141がHegotáに間に合うかどうかに関わらず、この議論自体は少なくとも一つのことを示している：
イーサリアムは問題が悪化するのを待つのではなく、次世代アカウント体制のために着実に道を切り開いています。