第一原理から考えるアカウント抽象化
Ethereum で自己管理型ウォレットを使ったことがあるなら、意識していたかどうかにかかわらず、あなたは外部所有アカウント——EOA——を使っていたことになります。アカウント抽象化の議論は、EOA とは何か、その設計がなぜオンチェーンでできることのすべてを縛るのか、そして ERC-4337 アカウント抽象化がベースプロトコルに手を加えずにどうやってその制約を回避するのかを理解するところから始まります。本記事は、当初の制約から、SSP が EVM チェーン上で 2-of-2 multisig を動かすためにアカウント抽象化をどう使っているのかまでを案内するシリーズの入口です。
これは土台となる概念的な一編です。ERC-4337 という標準そのものに絞った解説が必要なら、本記事と併せてアカウント抽象化（ERC-4337）とは？をお読みください。ここでは、その標準がなぜ存在するのかという直感を組み立てます。
Ethereum があなたに与えたアカウント
Ethereum には 2 種類のアカウントがあります。コントラクトアカウントはコードによって統治されます。EOA——ほとんどの人が使う普通のウォレット——は 1 本の秘密鍵によって統治されます。その鍵を握る者はアカウントから任意のトランザクションを承認でき、プロトコルはたった一つのことだけを検証します。すなわち、トランザクションが、アドレスを制御する鍵によって生成された、secp256k1 曲線上の有効な ECDSA 署名を伴っていること、です。
その唯一のルールはエレガントであり、同時に以下で論じるあらゆる制約の源でもあります。トランザクションの有効性はプロトコルに作り込まれています。アカウント所有者であるあなたは、「有効」が何を意味するかを決められません。決めるのはプロトコルであり、それは 1 本の鍵による 1 つの署名方式しかチェックできません。
その設計が根本に埋め込むもの
4 つの制約が、1 鍵・1 署名のモデルから直接導かれます。
- 1 本の鍵は単一障害点です。 鍵をなくせば資金は失われます。漏らせば攻撃者がすべてを手にします。プロトコルレベルには第二要素も、共同署名者も、盗難を阻止しえたポリシーもありません。
- カスタム検証ロジックがありません。 EOA は「2 つの署名を要求せよ」とも、「この少額の支払いは自動で許可し、しきい値を超えたら追加の承認を要求せよ」とも、「この鍵は平日だけ使えるようにせよ」とも言えません。アカウントにはロジックがありません。あるのは署名チェックです。
- 送信者は gas のために ETH を保有していなければなりません。 すべての EOA トランザクションは自分の gas を ETH で支払います。ERC-20 トークンだけを持ち ETH を持たない新規ユーザーは、手数料を払えないため、そのトークンを動かせません。手数料の支払者とトランザクションの送信者は、同じアカウントであることを強制されます。
- シードフレーズの UX は容赦がありません。 鍵がすなわちアカウントであるため、利用開始とはシードフレーズを書き留めて永遠に守ることを意味します。そのフレーズを介さない復旧経路はなく、たった一度のミスが恒久的なものになります。
これらはバグではありません。検証がアカウントではなくプロトコルに宿っていることの帰結です。
中心となる発想：アカウントをプログラム可能にする
アカウント抽象化とは、その検証ロジックをプロトコルから取り出し、アカウント自身の中へ移す、という発想です。ネットワークが「正しい ECDSA 署名が 1 つあればトランザクションは有効」とハードコードするのではなく、あなたの資金を保持するコントラクトである smart account が、何を有効なトランザクションとみなすかを自ら決めます。
ひとたびアカウントがプログラム可能なコントラクトになると、4 つの制約は設計上の選択へと溶けていきます。
- 1 つではなく2 つの署名を要求できます。これこそ、プロトコルのネイティブ対応なしに multisig が可能になる仕組みそのものです。
- 復旧ルールを実装でき、失われた鍵がもはや話の終わりではなくなります。
- 誰か別の人に gas を払わせることができ、手数料の支払者を送信者から切り離します。
- 複数のアクション——たとえば承認とスワップ——を 1 つのアトミックな操作にバッチ化できます。
アカウントは受動的な鍵ペアであることをやめ、あなたが制御するプログラム可能なロジックになります。
ERC-4337 がハードフォークなしでこれを実現する仕組み
難しいのは、Ethereum がトランザクションを検証する方法を変えることが、通常はベースプロトコルを変えること——遅く、論争を呼び、ネットワーク全体に及ぶアップグレード——を意味する点です。ERC-4337 はそれをまるごと回避します。アカウント抽象化を、コンセンサスの変更を一切要さずに、既存ネットワークの上に乗る層として導入するのです。
その仕組みはいくつかの部品に支えられています。
- UserOperations。 smart account は通常のトランザクションを送る代わりに、意図を
UserOperation——アカウントが何をしたいか、どう検証されるべきかを記述する構造化されたオブジェクト——として表現します。 - 代替の mempool。 UserOperations は、通常のトランザクションとは分離された、独自の mempool に存在します。
- Bundlers。 bundler はその mempool から UserOperations を集め、まとめてパッケージ化し、ベースレイヤーの gas を支払いながら、実際のトランザクションとしてチェーンに送信します。
- EntryPoint コントラクト。 監査済みの単一の
EntryPointコントラクトが、オンチェーンの要所です。各 smart account を呼び出してそのアカウント自身の検証ロジックを走らせ、検証が通れば操作を実行します。 - Paymasters。 任意の
paymasterコントラクトが、ある UserOperation の gas を肩代わりすることに同意できます。これがガスレスやトークン払いのフローを可能にするものです。
これらを合わせると、根底にある Ethereum プロトコルをそのままに保ちながら、あらゆるコントラクトが、自分自身のルールで検証される、完全にプログラム可能なアカウントとして振る舞えるようになります。この標準は EIP-4337 に規定されており、Ethereum 自身のアカウント抽象化ロードマップが、より広範な取り組みの行き先を追っています。
なぜこれが自己管理ユーザーにとって重要なのか
自分の鍵を保持する人にとって、アカウント抽象化は抽象的なプロトコルの細部ではありません——ウォレットが安全にできることを変えます。
- ネイティブ対応なしの multisig。 smart account は複数の署名を要求できるため、ウォレットはすべての送金について 2 台の独立した端末の承認を要求できます。これは SSP が拠り所とする構成要素であり、アカウント抽象化のやり方による EVM Multisigでさらに詳しく説明しています。
- 復旧の選択肢。 プログラム可能な検証は、単一の脆いシードフレーズに崩れ落ちない復旧フローへの扉を開きます。
- Gas スポンサーシップ。 paymasters は、手数料を送信者から切り離せることを意味し、利用開始時の最悪の摩擦をならします。
- バッチ化。 複数のステップを 1 つの操作として決済でき、クリック数も途中失敗のリスクも減らします。
1 鍵の EOA とプログラム可能な smart account の実務上の違いは、独立した解説に値するほど大きなものです——EOA と smart account：本当に重要な違いを参照してください。
SSP の位置づけ
SSP は 2-of-2 multisig を中心に構築された自己管理型ウォレットです。1 本の鍵は SSP Wallet ブラウザ拡張に存在し、2 本目は SSP Key モ��イルアプリに存在します。すべてのトランザクションは拡張で構築され、スマートフォンで共同署名されるため、どちらの端末も単独では資金を動かせません。
EVM チェーンでは、SSP はその 2-of-2 を ERC-4337 を使って実現します。ウォレットは、検証ロジックが両方の鍵を要求する ERC-4337 smart account であり、2 つの部分署名は——secp256k1 上で MuSig2 方式により——コントラクトがオンチェーンで検証する単一の Schnorr 集約署名へと結合されます。SSP の smart contracts は 2025 年に Halborn による監査を受けました。完全な設計は SSP アカウント抽象化アーキテクチャの主題です。
言い換えれば、上で述べた抽象的な能力——自分自身の複数署名ルールを課すアカウント——こそ、SSP が Ethereum、Polygon、Base、そして他の対応 EVM チェーン上で、動くウォレットへと作り変えているものなのです。
このシリーズの残り
この一編は、問題と中心となる発想を組み立てました。シリーズはここから積み上げていきます。
- 第一原理から考えるアカウント抽象化 — 本記事：なぜ EOA は制約的なのか、そしてアカウント抽象化とは何を意味するのか。
- EOA と smart account：本当に重要な違い — 2 つのアカウントモデルの直接比較。
- SSP アカウント抽象化アーキテクチャ — SSP が ERC-4337 を 2-of-2 ウォレットへどう配線しているか。
- Gas スポンサーシップと paymasters の解説 — paymasters が「誰が払うか」を「誰が送るか」からどう切り離すか。
- Ethereum 以外のチェーンでのアカウント抽象化 — 同じ発想が Ethereum を越えてどう広がるか。
標準を単独で知りたいなら、まず ERC-4337 解説から始め、それから全体像を得るためにここへ戻ってきてください。そこから先、アカウントは制約であることをやめ、あなたが回り込んでプログラムできる何かになり始めます。
