深入 SSP 的账户抽象架构
SSP 是一款围绕 2-of-2 multisig 构建的自托管钱包。一把密钥存放在 SSP Wallet 浏览器扩展中，第二把存放在 SSP Key 手机应用中，任何交易都必须经过两台设备的批准才会结算。在 EVM 链上，SSP 通过 ERC-4337 account abstraction 来兑现这一保证：钱包是一个 smart account，其验证逻辑接受由两把密钥构建出的单一 Schnorr 聚合签名。本文将端到端地梳理这套架构——每个组件、确切的签名流程，以及它所带来的安全特性。
如果你对 account abstraction 还不熟悉，请先阅读从第一性原理理解账户抽象和专注于标准本身的 ERC-4337 讲解。这里我们假设你大致了解 smart account 和 UserOperation 是什么，并把重点放在 SSP 如何把它们连接起来。
SSP 依赖的各个部件
在梳理流程之前，先点名这些组件以及各自的职责会有帮助：
- smart account。 在 EVM 链上，你的 SSP 钱包不是由单把密钥控制的 EOA。它是一个 ERC-4337 smart account——一份持有你资金并包含自身验证逻辑的合约。这套逻辑是整个设计的核心：只有当所提供的签名与钱包预期的聚合密钥相匹配时，它才接受一笔交易。
- 两台设备。 密钥 1 存放在 SSP Wallet 浏览器扩展中。密钥 2 存放在 SSP Key 手机应用中。每台设备持有一份分片并产生一个部分签名。任何一份分片都无法单独授权任何操作。
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 产生它自己的部分签名。
- 两个部分签名被以 MuSig2 风格在 secp256k1 上聚合成一个 Schnorr 签名。
- 此时携带那个单一聚合签名的
UserOperation已准备好发送。 - 它前往一个 bundler，由其打包成一笔交易并支付 gas。
- bundler 把它提交给 EntryPoint 合约，合约再调用 SSP 的 smart account。该 account 针对钱包预期的聚合密钥验证这个单一聚合签名，若有效，便执行该调用。
要走到第 6 步需要两台设备，这正是它成为真正 2-of-2 的原因。去掉任意一个部分签名，聚合都无法产生合约会接受的签名。
为什么链上只看到一个签名
让 SSP 的设计显得优雅的细节在于第 6 步的聚合。扩展和手机并不是各自把一个独立签名附到操作上。它们的两个部分 Schnorr 签名会——以 MuSig2 风格，在 Ethereum 已经使用的同一条 secp256k1 曲线上——合并成一个 Schnorr 签名。smart account 针对一把预期的聚合密钥检查这一个签名。
这带来两个值得驻足的后果：
- 链上足迹保持很小。
UserOperation携带的是一个签名，而不是两个。没有需要存储或遍历的签名者列表，也没有逐签名者的验证循环。合约所做的验证工作量，与针对单一签名者时相同。 - 链无法分辨它是 multisig。 抵达 EntryPoint 的看起来就是一笔普通的已签名操作。2-of-2 的强制约束体现在签名是如何被产生的——跨两台设备——而不是体现在链上某种可见的多方结构里。在外部观察者看来，该钱包的行为与任何其他 smart account 无异。
这正是 SSP 的做法与那种发布 N 个独立签名并逐一验证的朴素 multisig 之间的区别。在 EVM 上以这种方式实现 multisig 的机制，在以账户抽象方式实现的 EVM 多签中有更详细的探讨。
每台设备实际保护的是什么
值得就这一安全特性把话说精确，因为它正是这套架构的全部意义所在。
- 任何单把密钥都无法转移资金。 扩展中的密钥 1 可以构建一个
UserOperation并签署其一半，但半个签名聚合出来的东西合约不会接受。手机上的密钥 2 可以批准并签署其一半，但它无法独自发起或完成一笔转账。 - 攻破一台设备并不足够。 即便攻击者完全控制了你的浏览器扩展，仍然无法花费，因为没有手机他无法产生密钥 2 的部分签名。反过来也成立。单把密钥的 EOA 无法承受的那种威胁模型——一把密钥泄露便全盘皆失——在这里并不适用。
- 批准是显式的，且在第二块屏幕上完成。 由于第 4 步把请求推送到 SSP Key 应用，你会在一台物理上独立的设备上看到并批准该操作，之后它才能被聚合并发送。
这与什么是 2-of-2 multisig？中描述的 2-of-2 特性相同，只是在 EVM 链上通过账户抽象而非原生 multisig 操作码来实现。
收益小结
把各条线索串起来，这套架构为 SSP 用户换来一组特定的、其他途径难以同时获得的好处：
- 在每一条受支持的 EVM 链上都有 multisig 安全性。 同一套 2-of-2 设计运行在 Ethereum、Polygon、Base、BNB Smart Chain 和 Avalanche 上，因为 ERC-4337 是合约层面的标准，而非某条链特有的功能。
- 小巧的链上足迹。 单一聚合签名意味着 smart account 像单一签名者那样验证，使验证保持精简。
- 类似单签名者的 UX。 从你这边看，它感觉像在两台设备上批准一笔交易，而不是组建一个委员会。没有需要管理的联署地址，也没有需要为每笔转账配置的独立 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 多签机制。
关于正式规范，参见 EIP-4337；关于更广泛的努力，Ethereum 的账户抽象路线图在跟踪它的走向。要点是：SSP 把可编程 account 这一抽象承诺，变成了一个具体的 2-of-2 钱包——两台设备产生一个签名，而链只看到一笔有效的操作。
