SSP のアカウント抽象アーキテクチャの内側
SSP は 2-of-2 multisig を中心に構築された自己管理型ウォレットです。1 本目の鍵は SSP Wallet ブラウザ拡張に、2 本目は SSP Key モバイルアプリに置かれ、両方のデバイスが承認しない限りどの取引も確定しません。EVM チェーンでは、SSP はその保証を ERC-4337 の account abstraction で実現します。ウォレットは smart account であり、その検証ロジックは 2 本の鍵から構築された単一の Schnorr 集約署名を受け入れます。本記事では、そのアーキテクチャを端から端まで——各コンポーネント、正確な署名フロー、そしてそれが生み出すセキュリティ特性を——たどります。
account abstraction が初めてなら、まず第一原理から見るアカウント抽象と、標準そのものに絞った ERC-4337 解説から始めてください。ここでは smart account や UserOperation がおおよそ何かを知っていることを前提とし、SSP がそれらをどう結び付けるかに焦点を当てます。
SSP が依拠する各部品
フローをたどる前に、コンポーネントとそれぞれの役割を挙げておくと役立ちます。
- smart account。 EVM チェーンでは、あなたの SSP ウォレットは単一の鍵で制御される EOA ではありません。ERC-4337 の smart account——資金を保持し、それ自身の検証ロジックを内包する契約です。このロジックこそ設計の核心であり、提供された署名がウォレットの期待する集約鍵に一致したときにのみ取引を受け入れます。
- 2 つのデバイス。 鍵 1 は SSP Wallet ブラウザ拡張に置かれます。鍵 2 は SSP Key モバイルアプリに置かれます。各デバイスは 1 つの分割片を保持し、1 つの部分署名を生成します。どの分割片も単独では何も承認できません。
UserOperation。 拡張は通常の取引の代わりに、あなたの意図をUserOperationとして表現します——account が何をすべきか、そしてそれを承認する署名を記述した構造化オブジェクトです。- bundler。 bundler は専用の mempool から
UserOperationを取り出し、実際のオンチェーン取引にまとめ、それを送信するためにベースレイヤーの gas を支払います。 - EntryPoint。 監査済みの単一の EntryPoint 契約が、あらゆる ERC-4337 操作のオンチェーンの入口です。あなたの smart account を呼び出してその account 自身の検証ロジックを実行し、検証が通れば実行を起動します。
paymaster は任意で UserOperation の gas を肩代わりできます。それはそれ自体が一つの話題であり、Gas スポンサーシップと paymaster の解説で扱います。
正確な署名フロー
EVM チェーンで SSP から取引を送るとき、段階ごとに起きることは次のとおりです。
SSP Wallet extension (key 1) SSP Key mobile app (key 2)
| |
| 1. initiate tx |
| 2. build UserOperation |
| 3. partial Schnorr sig --- push -->| 4. approve
| | 5. partial Schnorr sig
| |
| 6. aggregate (MuSig2 / secp256k1)
| v
| ONE Schnorr signature
| |
v v
7. UserOperation --> 8. bundler --> 9. EntryPoint --> smart account
|
validate aggregate sig
|
valid? --> execute call
文章として読むと:
- 鍵 1 を保持する SSP Wallet ブラウザ拡張で取引を開始します。
- 拡張は、その動作を記述した ERC-4337 の
UserOperationを構築します。 - 鍵 1 がその操作に対して部分 Schnorr 署名を生成します。
- 要求は承認のために SSP Key モバイルアプリへプッシュされます（鍵 2）。
- 鍵 2 が自身の部分署名を生成します。
- 2 つの部分署名は、secp256k1 上で MuSig2 方式により、1 つの Schnorr 署名に集約されます。
- その単一の集約署名を帯びた
UserOperationは、送信の準備が整います。 - それは bundler へ送られ、bundler がそれを取引にまとめて gas を支払います。
- bundler はそれを EntryPoint 契約へ提出し、契約は SSP の smart account を呼び出します。account はその単一の集約署名をウォレットの期待する集約鍵に対して検証し、有効であれば呼び出しを実行します。
第 6 段階に到達するには両方のデバイスが必要であり、それがこれを真の 2-of-2 たらしめます。いずれかの部分署名を取り除けば、集約は契約が受け入れる署名を生成できません。
なぜチェーンには署名が 1 つしか見えないのか
SSP の設計を洗練させている要点は、第 6 段階の集約です。拡張と電話は、操作にそれぞれ別個の署名を付けるのではありません。それらの 2 つの部分 Schnorr 署名が——MuSig2 方式で、Ethereum が既に用いているのと同じ secp256k1 曲線上で——単一の Schnorr 署名へと結合します。smart account はその 1 つの署名を、期待される 1 つの集約鍵に対して照合します。
これには立ち止まる価値のある 2 つの帰結があります。
- オンチェーンの痕跡は小さいまま。
UserOperationが運ぶ署名は 2 つではなく 1 つです。保存したり走査したりする署名者リストもなく、署名者ごとの検証ループもありません。契約は、単一の署名者に対して行うのと同じ量の検証作業を行います。 - チェーンはそれが multisig だと判別できません。 EntryPoint に届くものは、ごく普通の署名済み操作に見えます。2-of-2 の強制は、署名が——2 つのデバイスにまたがって——どう生成されたかに宿るのであって、オンチェーン上に見える何らかの多者構造に宿るのではありません。外部の観測者にとって、ウォレットは他のどの smart account とも同じように振る舞います。
これが、SSP のやり方と、N 個の別個の署名を投稿してそれぞれを検証する素朴な multisig との違いです。EVM 上でこの方式の multisig を行う仕組みは、アカウント抽象方式の EVM マルチシグでさらに詳しく掘り下げます。
各デバイスが実際に守るもの
セキュリティ特性については正確である価値があります。それこそがアーキテクチャの全目的だからです。
- どの鍵も単独では資金を動かせません。 拡張の鍵 1 は
UserOperationを構築し自分の半分を署名できますが、半分の署名は契約が受け入れない何かへと集約されます。電話の鍵 2 は承認し自分の半分を署名できますが、単独で送金を起こすことも完了することもできません。 - 1 つのデバイスの侵害では足りません。 あなたのブラウザ拡張を完全に掌握した攻撃者でも、なお支払いはできません。電話なしには鍵 2 の部分署名を生成できないからです。逆も成り立ちます。単一鍵の EOA が乗り越えられない脅威モデル——1 本の鍵が漏れれば全損——は、ここには当てはまりません。
- 承認は明示的で、2 つ目の画面の上で行われます。 第 4 段階が要求を SSP Key アプリへプッシュするため、操作が集約され送信され得る前に、あなたは物理的に分離されたデバイス上でそれを見て承認します。
これは2-of-2 multisig とは何か？で説明されているのと同じ 2-of-2 特性であり、ネイティブの multisig オペコードではなくアカウント抽象を通じて EVM チェーン上で実現されています。
利点のまとめ
糸を一つにまとめると、このアーキテクチャは SSP ユーザーに、他の方法では得難い特定の組み合わせをもたらします。
- サポートされるすべての EVM チェーンでの multisig セキュリティ。 同じ 2-of-2 設計が Ethereum、Polygon、Base、BNB Smart Chain、Avalanche 上で動きます。ERC-4337 がチェーン固有の機能ではなく契約レベルの標準だからです。
- 小さなオンチェーンの痕跡。 単一の集約署名は、smart account が単一の署名者のように検証することを意味し、検証を軽量に保ちます。
- 単一署名者に近い UX。 あなたの側からは、委員会を組成するのではなく、2 つのデバイスで取引を承認するように感じられます。管理すべき共同署名者アドレスも、送金ごとに設定すべき別個の multisig 契約もありません。
- プロトコル変更は不要。 すべてが ERC-4337 の上で動くため、SSP はベースレイヤーのアカウント抽象が出荷されるのを待たずに、これらすべてを手にします。
監査についての一言
セキュリティアーキテクチャは、その精査の度合いの分だけ信頼に値します。SSP の smart contracts は 2025 年に Halborn によって監査されました。外部監査はどんなシステムも完璧にはしませんが、上で述べた 2-of-2 ルールを強制する契約ロジックにとって、意味のある信頼のシグナルです。
次に向かう先
本記事は SSP のアカウント抽象を端から端までたどりました。周辺の標準と概念をさらに深く知るには:
- 第一原理から見るアカウント抽象——なぜ EOA は制約的なのか、そしてアカウント抽象とは何を意味するのか。
- アカウント抽象（ERC-4337）とは何か？——
UserOperation、bundler、EntryPoint の役割を含め、標準を単体で見る。 - Gas スポンサーシップと paymaster の解説——
paymasterがUserOperationの gas をどう肩代わりできるか。 - アカウント抽象方式の EVM マルチシグ——EVM 上の multisig の仕組みをより詳しく。
正式な仕様は EIP-4337 を、より広い取り組みについては Ethereum のアカウント抽象ロードマップがその行き先を追っています。要点はこうです。SSP は、プログラム可能な account という抽象的な約束を、具体的な 2-of-2 ウォレットへと変えます。そこでは 2 つのデバイスが 1 つの署名を生成し、チェーンには有効な操作が見えるだけなのです。
