Ethereum を超えたアカウント抽象化

アカウント抽象化はしばしば Ethereum の物語として紹介されます——ERC-4337 を使って単一鍵のウォレットをプログラム可能な smart account に変える方法として。しかしこのアイデアは Ethereum L1 で止まりません。それは大きく異なる二つの道で広がります。すなわち、外向きには Ethereum の実行モデルを共有する各 EVM チェーンへ、そしてネイティブには、初日からアカウント抽象化がプロトコルに組み込まれて設計されたチェーンの中へ。本稿はこのより広い地図を描き、ネイティブなアカウント抽象化が Ethereum の上に重ねられた ERC-4337 標準とどう異なるかを説明し、とりわけ一つの境界について慎重を期します。すなわち、一般的なエコシステムがどこで終わり、SSP が実際に対応している範囲がどこから始まるのか、です。

これはアカウント抽象化シリーズの最終回です。基礎概念が初めてなら、まず第一原理から学ぶアカウント抽象化から始め、次にEOA と smart account：重要な違いで二つのアカウントモデルを比較してください。ここでは smart account がおおよそ何であるかをご存じである前提で、視野をクリプト全体へと広げます。

EVM が動くところならどこでも、同じ標準

アカウント抽象化が広がる第一の道は最も単純です。それは EVM とともに移動します。ERC-4337 はベースプロトコルの変更ではありません。それは EntryPoint コントラクト、UserOperation オブジェクト、bundler、そして任意の paymaster の上に構築されたコントラクトレベルの標準であり、そのいずれもコンセンサスの変更を必要としません。この設計上の選択には強力な帰結があります。Ethereum Virtual Machine を実行するあらゆるチェーンが、同じ EntryPoint、同じ bundler インフラ、そして同じ smart account コントラクトをホストできるのです。

主要な EVM L2 やサイドチェーンが、Ethereum と同じように ERC-4337 に対応しているのは、まさにこのためです。

Polygon は EVM を実行するため、同じ smart account コントラクトと同じ EntryPoint が変更なしでデプロイされます。
Base は EVM L2 であり、ERC-4337 のアカウント抽象化が L1 と同じように機能します。
BNB Smart Chain は EVM 互換であり、同じ標準をホストします。
Avalanche C-Chain は EVM を実行し、同じコントラクトレベルのアカウント抽象化に対応します。

標準が移植可能であるため、Ethereum 向けに書かれたウォレットの smart account ロジックは、ほぼそのまま変更なくこれらのチェーンへ引き継がれます。この移植性こそが、SSP が対応する各 EVM チェーンでその設計を動かせる理由そのものです——同じ 2-of-2 コントラクトは、Ethereum、Polygon、Base、BNB Smart Chain、Avalanche のいずれにデプロイされても同一に振る舞います。これらのネットワークで SSP を使う実践的なチェーン別の解説は、Polygon、Base、その他の EVM チェーンで SSP を使うをご覧ください。

ネイティブなアカウント抽象化：それが層ではなくプロトコルそのものであるとき

アカウント抽象化が広がる第二の道は、根本的に異なります。一部のチェーンはオプトイン型の標準を待ちませんでした——アカウント抽象化をプロトコルに直接組み込んだのです。その結果、「EOA か smart account か」という区別そのものが存在しません。すべてのアカウントがデフォルトで smart account です。

Starknet：すべてのアカウントがコントラクト

Starknet は初日からアカウント抽象化を備えています。Starknet には Ethereum の意味での外部所有アカウントは存在せず、すべてのアカウントが Cairo 言語で書かれたコントラクトアカウントであるのです。アカウントの挙動がプロトコルレベルでコントラクトコードによって定義されるため、署名スキーム、検証ルール、multisig、手数料ロジックは、後から付け足された機能ではなく、アカウント自身の性質です。

Ethereum との対比は示唆に富みます。Ethereum ではデフォルトのアカウントは一つのハードコードされた ECDSA チェックを持つ EOA であり、ERC-4337 は、ハードフォークなしでプログラム可能なアカウントをその上に重ねるために存在します。Starknet では重ねるべきものがありません——プログラム可能なアカウントが土台なのです。採用すべき別個の EntryPoint 標準もありません。なぜならアカウント抽象化は任意ではないからです。docs.starknet.io にある Starknet のドキュメントが、このアカウントモデルを詳しく説明しています。

zkSync Era：組み込み paymaster を備えたネイティブ AA

zkSync Era も同様にプロトコルネイティブなアプローチを取ります。アカウント抽象化はアドオンではなくプロトコルの一部であり、システムはプロトコルレベルで組み込みの paymaster サポートを含みます。Ethereum では paymaster は ERC-4337 標準で定義され EntryPoint を経由してルーティングされるコントラクトですが、zkSync Era では paymaster の機能はチェーン自体の一級の機能であり、したがって手数料を肩代わりしたり gas を別の token で支払ったりすることは、このネットワークが動くよう設計された仕組みの一部です。zkSync のドキュメントが、そのネイティブなアカウント抽象化と paymaster モデルを取り上げています。

ネイティブ AA と ERC-4337：核心的な違い

この区別ははっきり述べておく価値があります。それが本稿の概念的な核心だからです。

ERC-4337 は、変更されていないプロトコルの上に重ねられたオプトイン型の標準です。 Ethereum のベース層は、依然として EOA とその単一の ECDSA 署名しかネイティブには理解しません。smart account が存在するのは、開発者たちが共通の on-chain・off-chain コンポーネント群——EntryPoint、代替 mempool、bundler——について合意したからこそであり、これらがコンセンサスの変更なしにプロトコルレベルのアカウント抽象化を模倣します。ハードフォークを一切必要としなかったからこそ見事であり、同じ理由であらゆる EVM チェーンへ移植可能なのです。
ネイティブなアカウント抽象化はプロトコルに組み込まれています。 Starknet と zkSync Era では、チェーン自体がすべてのアカウントをプログラム可能なものとして扱います。オプトインも、採用すべき別個の標準も、「通常の」アカウントとスマートなアカウントの区別もありません——smart account がアカウントそのものなのです。

どちらもエンドユーザーに同じ恩恵をもたらします。複数の署名者、カスタム検証、リカバリーロジック、柔軟な gas です。両者は単に正反対の方向から到達するにすぎません——一方は入念に設計された層として、他方は土台となるプロトコルの決定として。層状アプローチの正式な仕様が必要なら、EIP-4337 が正典となる参照先です。

SSP がどこに位置するか——そしてどこに位置しないか

ここが正確を期すべき境界です。SSP は 2-of-2 multisig を中核に据えた自己管理型ウォレットです。一方の鍵は SSP Wallet ブラウザ拡張に、もう一方は SSP Key モバイルアプリにあり、どちらの端末も単独では資金を動かせません。EVM チェーンでは、SSP はこれを、両方の鍵から構築された単一の Schnorr 集約署名を検証ロジックが検証する ERC-4337 smart account として実装しています。SSP の smart contracts は 2025 年に Halborn の監査を受けました。

ERC-4337 は EVM 全体で移植可能であるため、SSP のアプローチは対応する EVM チェーンへ引き継がれます。すなわち Ethereum、Polygon、Base、BNB Smart Chain、Avalanche C-Chain です。同じ 2-of-2 smart account コントラクトが、それらすべての上で動きます。

Starknet と zkSync Era は、本稿ではより広いエコシステムとして登場します——アカウント抽象化がプロトコルにネイティブなチェーンの例として、です。これらは SSP が対応するチェーン群の一部ではありません。SSP は上に挙げた EVM チェーンに ERC-4337 のアカウント抽象化をもたら��ますが、Starknet、zkSync Era、その他の非 EVM チェーンでは動作しません。クリプトの他の場所でネイティブ AA について読むときは、それを smart account モデルがどれほど普及したかを示す文脈として捉え、SSP がどこで稼働するかについての主張としては受け取らないでください。

なぜこれが重要なのか

一歩引いて見れば、パターンは明らかです。smart account の体験は、上級ユーザー向けのニッチな機能ではなく、クリプトの大部分でデフォルトになりつつあります。

EVM では、 ERC-4337 がハードフォークなしにプログラム可能なアカウントを Ethereum とあらゆる互換チェーンへもたらします。これこそが、SSP のようなウォレットが Polygon、Base、BNB Smart Chain、Avalanche において、Ethereum で提供するのと同じ 2-of-2 セキュリティを提供できる理由です。
ネイティブに抽象化されたチェーンでは、「これは EOA か、それとも smart account か」という問いはそもそも生じません。アカウントは一種類しかなく、それがプログラム可能だからです。

自己管理のユーザーにとっての要点は、硬直した単一鍵モデルがもはや唯一の選択肢ではなく、ますますデフォルトの選択肢でもなくなっているということです。アカウント抽象化が層状の標準として到来しようと、ネイティブなプロトコル機能として到来しようと、行き着く先は同じです。すなわち、あなたがプログラムできるアカウント、そして単一の秘密鍵だけでは決して強制できないセキュリティルール——SSP の二端末 multisig のような——を備えたアカウントです。このモデルが元来の Ethereum アカウントとどう比較されるかを再確認するにはEOA と smart account：重要な違いを、標準そのものについてはアカウント抽象化（ERC-4337）とは？をご覧ください。