EOAが時代遅れである理由：スマートアカウントが実際に果たす役割

2026年4月時点で、BundleBearによると、Ethereumと主要なL2全体で、ERC-4337のUserOperationは10.7億件を超え、少なくとも一度取引を行ったスマートアカウントは5,670万件に達しています。もはやニッチな存在ではありません。Ethereumが2015年に導入した、単一キーでsecp256k1のみを使うExternally Owned Account（EOA）は、大規模に迂回されつつあります。オンチェーンの数値も、プロトコル層では以前から知られていた事実に追いつき始めています。アカウント自体がプログラム可能になったのです。

これは、スマートアカウントを扱う全5回のシリーズの第1回です。ここでは範囲を絞り、基礎となる点を説明します。EOAとは何か、スマートアカウントとは何か、そして「スマートアカウントかEOAか」という選択が、もはやUXの好みではなく、セルフカストディをどのような仕組みで実現するかという構造上の選択である理由を解説します。

プロトコル上、EOAとは何か

EthereumのYellow Paperでは、アカウントをExternally Owned AccountとContract Accountの2種類に定義しています。状態レベルでの唯一の違いは、codeHashフィールドです。EOAの場合、codeHashは空文字列のハッシュです。コントラクトアカウントの場合は、実行可能なEVMバイトコードを指します。プロトコル層での違いはこれだけです。

したがって、EOAは実質的な意味での「ウォレット」ではありません。keccak256(public key)の末尾20バイトから導出されるアドレスであり、鍵ペアにはsecp256k1曲線が固定されています。MetaMask、Ledger、Zelcoreは鍵を保持するユーザーインターフェースであり、アカウントそのものではありません。この仕組みの詳細をまだご存じない場合は、公開鍵と秘密鍵、そしてアドレスの導出方法についての入門記事をご覧ください。

2023年にERC-4337が導入されるまで、Ethereum上のすべてのトランザクションはEOAから送信する必要があり、プロトコルが適用する検証ルールは1つだけでした。トランザクションハッシュに対する有効なsecp256k1署名です。残高を保有し、トランザクションごとにECDSA署名を1つ行い、同じアカウントからETHでガス代を支払う。それがEOAでできることのすべてです。それ以外の機能はありません。

ユーザーに影響する構造上の限界

これらは単なるUX上の小さな不便ではありません。2026年現在も続くセルフカストディの損失の大半を招く、構造上の要因です。

• 単一障害点。 1つの秘密鍵ですべてを管理します。鍵を失えば、アカウントも失います。鍵が漏えいすれば、資金を取り戻せない形で失います。プロトコルには復旧の仕組みがありません。だからこそ、単一のシードフレーズがセルフカストディにおける主要な単一障害点となっています。
• 単一の曲線。 secp256k1がハードコードされています。パスキー（P-256）、Ed25519鍵、BLS、ポスト量子方式は使用できません。
• ネイティブなマルチシグがない。 Ethereum上の「マルチシグ」は、初期のGnosis MultisigからSafeに至るまで、すべてEOAが呼び出すコントラクトです。EOA自体が2つの署名を必須にすることはできません。
• バッチ処理ができない。 EOAが1回のトランザクションで実行できる操作は1つです。トークンを承認してからスワップするには、署名済みトランザクションが2件、確認が2回、ガス代の支払いが2回必要です。
• 支出ポリシーがない。 プロトコルには「この鍵で使えるのは1日あたり最大500ドル」や「この鍵で呼び出せるのはUniswapのみ」といった概念がありません。
• 操作を行うアカウント自身がETHでガス代を支払う必要がある。 ネイティブな手数料代行の仕組みも、USDCでの支払い機能もありません。

これが、Ethereumのすべてのユーザーが10年間使わざるを得なかった枠組みです。

スマートアカウントとは何か

プロトコル上の文字どおりの意味では、スマートアカウントはコントラクトアカウントです。codeHashがバイトコードを指すアドレスです。そのバイトコードによって、どのような条件でアカウントが操作を受け入れるかが定義されます。

EOAの検証ルールは、固定されたsecp256k1のチェック1つです。一方、スマートアカウントの検証ルールは、コントラクトで定める内容にできます。たとえば、2-of-3のマルチシグ、secp256r1曲線で検証するパスキー署名、ハードウェアで認証された鍵、タイムロック、1日の上限額、許可リストに登録した呼び出し先、またはこれらの組み合わせを設定できます。スマートコントラクトアカウントは、固定されたプロトコル層のsecp256k1チェックではなく、EIP-1271標準に基づいて署名を検証します。これにより、そもそも別の署名方式を使えるようになります。

ルールはコードで定義されるため、更新、組み合わせ、取り消しが可能です。スマートアカウントは2018年からEthereum上に存在しており、代表例はSafeです。不足していたのは、スマートアカウントを標準にする方法と、EOAで先にガス代を支払わなくてもトランザクションを送れる方法でした。ERC-4337とEIP-7702によって、この課題が解決されました。

これまでの経緯：アカウント抽象化の歩み

EOAとコントラクトを統合する構想は、Ethereumそのものと同じくらい古くからあります。Vitalikが2016年に草案を作成したEIP-86が、最初の詳細な提案でした。そこから現在の実用化済み標準に至るまで、5回の試みがありました。

• **EIP-2938（2020年9月）**は、プロトコルレベルのアカウント抽象化を提案しました。変更の範囲が大きすぎたことに加え、Ethereumがプルーフ・オブ・ステークへの移行の最中だったため、取り下げられました。
• **EIP-3074（2020年10月）**はAUTHおよびAUTHCALLオペコードを導入し、EOAがInvokerコントラクトに処理を委任できるようにする提案でした。セキュリティ上の懸念から取り下げられ、別の提案に置き換えられました。
• ERC-4337は2023年3月1日にEthereumメインネットで稼働しました。ハードフォークを必要とせず、アプリケーション層だけで実装されています。UserOperationと呼ばれる疑似トランザクションを、専用のmempool、Bundler、シングルトンのEntryPointコントラクトを通じて処理します。
• EIP-7702は、2025年5月7日のPectraアップグレードで導入されました。トランザクションタイプ0x04を導入し、EOAが認可タプル(chain_id, address, nonce, y_parity, r, s)に署名して、0xef0100 || addressインジケーターを介してアカウントを委任先のコントラクトコードに紐付けます。資金を移行せずに、EOAを一時的にスマートアカウントとして動作させます。
• ERC-6900は、スマートアカウントで検証、実行、フックの各モジュールを組み合わせるための、モジュール型プラグインアーキテクチャを標準化しています。

要点は、アカウント抽象化がもはや実験ではないということです。すでに展開されている階層型の標準であり、新たにスマートアカウントを構築する場合の明確な経路としてERC-4337が、既存のEOAが利用を選択できる経路としてEIP-7702が用意されています。

スマートアカウントで可能になる5つの機能

EOAが「1つの鍵、1つの署名、1つのトランザクション」だとすれば、スマートアカウントはその機能をすべて含む上位の仕組みです。

• 検証ルールをプログラムで設定。 パスキー、P-256、ハードウェアHSMなどの署名方式、2-of-3や3-of-5などの承認数、ブロック高やオラクル価格などの条件を選べます。「認可済み」の意味をアカウント側で決められます。
• アトミックなバッチ処理。 承認、スワップ、預け入れを1回の署名操作にまとめられます。すべて実行されるか、何も実行されないかのどちらかです。これにより、ユーザーが手作業で対処してきた承認の負担や、Zelcoreにおけるマルチシグの回避策が不要になります。
• ペイマスターによるガス代の抽象化。 第三者のコントラクトがユーザーに代わってガス代を支払うか、ペイマスターが受け付けるUSDC、USDT、または任意のERC-20で支払えます。ガス代、承認、DeFiの仕組みがどのように関係するかを詳しく知るには、DeFiの基礎に関する記事が前提知識になります。
• セッションキー。 使用範囲と有効期間を限定し、特定のアプリ向けに設定する署名鍵です。「この鍵で、今後24時間、Uniswapで最大100 USDCを使える」といったルールを設定できます。セッションキーが侵害されても、被害はアカウント全体の規模ではなく、ポリシーで定めた範囲に限られます。
• 復旧。 ソーシャルリカバリー、ハードウェアによる復旧、タイムロック付きの復旧が可能です。元の署名鍵がなくてもアカウントを復旧できるため、シードフレーズを単一障害点とする仕組みをようやくなくせます。

セルフカストディを支える基盤となった理由

普及の勢いは、もはや議論の段階ではありません。EIP-7702はPectra後の最初の1週間で11,000件を超える認可を集め、その直後にはウォレット数が25,000を超えました。OKXとMetaMaskが先行しています。BundleBearの累計（UserOps 1.07B件、スマートアカウント5,670万件）が、状況の全体像を物語っています。

実際に変わるのは脅威モデルです。EOAの場合、ユーザーには「シードフレーズを永久に守り、悪意あるトランザクションに決して署名せず、フィッシングにも遭わず、誤ったデバイスを使い回さない」ことが求められます。これは、人間が実際に守りきれないと明らかになっている役目です。スマートアカウントの場合、ユーザーが担うのは「復旧に必要な承認者数と支出ポリシーを一度設定する」ことです。これはコードで強制できます。

スマートアカウントはハードウェアウォレットに取って代わるものではありません。ハードウェアウォレットでできることを広げ、実際には、スマートアカウントでハードウェアウォレットが担う役割を最も効果の高い用途に絞ります。つまり、価値が高く発生頻度の低いマスター操作への署名を担い、日常的な操作はセッションキーで処理します。

このシリーズの続き

ここでは全体の枠組みを示しました。シリーズの残りでは、実際の運用について掘り下げます。

• 第2部では、ERC-4337の仕組みを解説します。UserOperations、Bundlers、EntryPoint、Paymastersと、それぞれで起こりうる失敗を取り上げます。
• 第3部では、EIP-7702による委任を詳しく扱います。認可タプル、0xef0100インジケーター、そしてEOAの参照先を他者のコードにする際のセキュリティ上の考慮事項を取り上げます。
• 第4部では、主要なスマートアカウント実装（Coinbase Smart Wallet、Safe、Argent、Ambire）を比較し、それぞれのデフォルト設定を解説します。
• 第5部では、セルフカストディを維持しながら、実際のアカウントで復旧、セッションキー、支出ポリシーをどう設定するかを扱い、運用編を締めくくります。

第2部に引き継ぐ要点は、次の一文です。EOAはアドレスを持つ鍵であり、スマートアカウントは、その鍵に何を許可するかを決めるコントラクトです。