EthereumではAccount Abstractionをプロトコル側へ近づけるEIP-8141が議論されています。鍵のローテーション、柔軟な認証、ガス支払い、バッチ処理がウォレット設計をどう変えるのか、ハードウェアウォレットとの役割分担も含めて整理します。
背景と今回の論点
Web3ウォレットは、秘密鍵とシードフレーズを利用者自身が管理する従来型の構造から、認証や復旧方法をプログラムできるSmart Accountへと拡張されつつあります。EthereumではERC-4337によるAccount Abstractionがすでに実用化され、さらにプロトコルレベルの仕組みを目指すEIP-8141「Frame Transaction」が議論されています。
EIP-8141は2026年1月29日に作成された提案で、現時点では正式導入が確定した仕様ではありません。しかし、ウォレットの将来を考えるうえでは重要です。秘密鍵をなくすことではなく、鍵とアカウントの関係を柔軟にし、認証・実行・手数料支払いを分離できる方向を示しているからです。
従来型アカウントの制約
Ethereumで一般的に使われてきたEOAは、秘密鍵による署名を中心にアカウントを制御します。構造が比較的単純である一方、認証方法や復旧ルールを自由に追加することは困難です。
Account Abstractionでは、アカウント側に検証ロジックを持たせることで、この制約を緩和します。ERC-4337ではUserOperationと呼ばれる処理をBundlerがまとめ、EntryPointコントラクトを経由して実行する仕組みが採用されています。
これにより、複数操作の一括実行、第三者によるガス代のスポンサー、独自の認証方式などを実装しやすくなります。
Frame Transactionが目指す構造
EIP-8141では、トランザクションを複数の「Frame」に分解します。それぞれのFrameが検証、ガス支払い、ユーザー操作など異なる役割を担当できる設計です。
重要なのは、アカウントとECDSA鍵の結び付きを固定しない方向性です。提案では鍵のローテーション、Smart Accountによるバッチ処理、代替的な手数料支払い方式などが想定されています。
例えば鍵を変更できる構造であれば、一つの秘密鍵を永続的なアカウントそのものとして扱う必要性を減らせます。将来的に認証技術が変化した場合にも、アカウントを維持したまま検証方式を更新できる可能性があります。
Passkeyとの組み合わせ
Smart Accountでは、Passkeyのような認証技術も重要になります。Passkeyは公開鍵暗号を利用し、対応端末では生体認証や端末PINと組み合わせて署名操作を行えます。
ただし「Passkeyだから秘密鍵が存在しない」という理解は正確ではありません。ユーザーがシードフレーズを直接扱わなくても、裏側では署名用の暗号鍵と、その鍵を保護・復旧する仕組みが必要です。
つまりSeedless Walletで重要なのは、シードフレーズの有無そのものより、誰が署名権限を持ち、認証情報がどこに保存され、端末紛失時にどのような条件で復旧できるかです。
ハードウェア署名の役割は残る
Smart Walletが普及しても、ハードウェアウォレットの役割が直ちになくなるわけではありません。むしろ認証方式をプログラムできることで、ハードウェア署名を複数の認証要素の一つとして組み込む設計も考えられます。
例えば日常的な少額操作は別の認証方式で行い、大きな送金や重要な権限変更ではハードウェアデバイスによる追加署名を要求するといったポリシーです。法人管理では、担当者変更に合わせて署名権限を更新する仕組みとも相性があります。
一方でSmart Accountはスマートコントラクトの実装リスクを伴います。認証モジュールや復旧ロジックに欠陥があれば、秘密鍵を安全に保管していても問題が生じる可能性があります。EIP-8141自体も、検証ロジックが承認対象のトランザクション全体を適切に拘束しなければならない点などをSecurity Considerationsで扱っています。
セルフカストディの評価軸も変わる
これまでウォレットの安全性は「秘密鍵をオフラインで保管できるか」が大きな評価軸でした。今後はそれに加えて、認証方式、鍵更新、復旧ポリシー、Smart Accountのコード、外部インフラへの依存関係まで確認する必要があります。
シードフレーズを使わないこと自体が安全性を保証するわけではありません。PasskeyやMPC、Smart Accountでも、復旧経路やクラウドアカウント、署名ポリシーが新たな攻撃対象になる可能性があります。
まとめ
ウォレット技術は「一つの秘密鍵を守る」モデルから、「誰が、どの条件で、何を署名できるか」を設計するモデルへ移行しつつあります。EIP-8141はまだ提案段階ですが、鍵のローテーション、柔軟な検証、バッチ処理、手数料支払いなどをプロトコル側で扱う方向性を示しています。
将来のセルフカストディでは、ハードウェアウォレット、Passkey、Smart Accountのどれか一つを選ぶというより、それぞれをどの権限レイヤーに配置するかが重要になります。新しい認証方式を利用する場合も、署名権限と復旧経路を確認するという基本原則は変わりません。