以账户抽象方式实现的 EVM multisig
multisig 描述起来很简单——要求多于一个签名才能转移资金——但它在不同区块链上的构建方式却大相径庭。在 Bitcoin 上，multisig 内置于协议本身。而在 Ethereum 和其他 EVM 链上则并非如此，正是这一点决定了 Ethereum 上每一款认真的 multisig 钱包（包括 SSP）的工作方式。本文将解释为什么 EVM 上的 multisig 有所不同，用通俗的语言介绍使其成为可能的 account abstraction 工具，并展示 SSP 究竟如何在 Ethereum 上实现真正的 2-of-2。
如果你是从 EVM 系列的开头来到这里，SSP 中的 Ethereum 奠定了基础；本文则是对其底层安全机制的深入剖析。这里的阅读门槛要高一些——属于进阶级别——因为要把这个主题讲透，就意味着要诚实地触及 ERC-4337 和签名聚合，而不是含糊带过。
为什么 EVM 的 multisig 不同于 Bitcoin 的 multisig
理解 SSP 在 Ethereum 上工作方式的最清晰途径，是先弄明白为什么 Bitcoin 的做法不能简单照搬过来。
Bitcoin 拥有原生的脚本 multisig。协议中包含一个操作码，允许你用类似"这三把公钥中任意两把必须签名"的规则来锁定资金。Bitcoin 上的 multisig 地址只是一个附带了该花费规则的地址，网络会直接强制执行它。SSP 在 Bitcoin 和其他 UTXO 链上通过 BIP-48 脚本 multisig 来实现这一点：两把密钥、一段脚本、需要两个签名。如果这个基础模型对你来说是新的，什么是 2-of-2 multisig 是入门的地方。
Ethereum 没有对等的机制。在 EVM 链上只存在两种账户。第一种是 EOA——外部拥有账户，由且仅由一把私钥控制。一把密钥、一个签名者，仅此而已；EOA 上没有任何原生操作码可以要求两个签名。第二种是智能合约账户，它拥有代码而非单一的控制密钥，并按照代码所写的内容行事。
因此在 Ethereum 上，"multisig"一直意味着一个智能合约钱包：一份被编程为只有在满足其多重签名规则时才释放资金的合约。这正是 Gnosis Safe / Safe 等钱包所开创的模型，而且运行良好。其代价在于，经典的链上 multisig 合约通常会存储每位拥有者的签名并在链上逐一验证，这会消耗 gas 且随签名者数量增长而增加。account abstraction 提供了一条更简洁的路径，而这正是 SSP 所采用的路径。
一份简短而诚实的 ERC-4337 入门
account abstraction 的理念是：你的钱包应当是一个智能合约——一个可编程的账户——而不是一对普通的密钥。ERC-4337 是在不改动基础协议的前提下，于 Ethereum 上实现这一点的标准。你无需精通它即可使用 SSP，但有几个术语能让本文其余部分豁然开朗。如需完整论述，请阅读什么是 account abstraction（ERC-4337）；这里是面向用户层面的概览。
- smart account。 你的资金存放在一个 smart account 中，其代码定义了什么才算是一笔有效的交易。由于它是代码，该账户可以强制执行自定义规则——包括"要求一个有效的 2-of-2 签名"。
- UserOperation。 smart account 不会提交一笔普通交易，而是将其意图表达为一个 UserOperation：一份结构化的请求，说明它想做什么，并携带授权该操作的签名数据。
- bundler。 bundler 是一项服务，它收集 UserOperations，将其打包进一笔真正的链上交易并提交。它预先支付 gas 并获得偿付；它绝不会获得移动你资金的能力。
- EntryPoint。 一份经过审计的单一 EntryPoint 合约是链上受信任的协调者。它接收打包后的 UserOperations，并调用每个 smart account 进行验证，然后执行其操作。
- paymaster。 一份可选的 paymaster 合约可以赞助 gas，或允许用某种 token 而非原生币来支付手续费。它是可选的，且与 multisig 本身彼此独立。
关键洞见在于：有了 smart account，"谁可以授权一笔交易"的规则就是由你掌控的软件，而非协议的固定行为。这正是在一条没有原生 multisig 的链上，multisig 所需要的那种自由。
SSP 如何在 EVM 上实现 2-of-2
SSP 在它所支持的每一条链上都坚守同一个承诺：两台设备上的两把密钥，任何单独一把都无法移动你的资金。密钥 1 存放在 SSP Wallet 浏览器扩展中；密钥 2 存放在 SSP Key 移动应用中。你在扩展中构建并签署一笔交易，然后通过 push 在手机上批准它——两个签名缺一不可。
在 Bitcoin 上，这一保证来自 BIP-48 脚本 multisig。在 EVM 链上，SSP 将其重建为一个 ERC-4337 smart account，用于验证一个 Schnorr 聚合的 2-of-2 签名。下面是该思路的高层概述，在合约的具体内部细节并非重点之处，保持笼统。
你的两把密钥各自针对该交易生成一个部分签名。两台设备不会将两个签名分别发送到链上，而是将它们合并——采用 MuSig2 风格的签名聚合——成为一个单一、紧凑的签名。该 smart account 被编程为：只有当这个聚合签名针对钱包预期的密钥验证通过时，才接受一个 UserOperation。因此链上看到的是一个看起来普普通通的签名，然而从数学上讲，若没有两把密钥共同参与，这个签名根本不可能被生成出来。
相比在链上存储和检查 N 个独立的签名，这种设计具有实实在在的优势：
- 更小的链上占用。 一个聚合签名比两个独立签名验证和存储起来都更便宜，这往往意味着以更少的 gas 换取同等的安全性。
- 与单签名者钱包完全一致的 UX。 由于链上验证的是单个签名，从网络的角度看，你的 smart account 表现得就像任何普通账户。发送 ETH、转移 ERC-20 token 或与 DeFi 交互的感受都一样——第二个签名在你的两台设备之间悄然完成。
- 处处通用的同一模型。 Schnorr 以及这种聚合方法建立在 secp256k1 之上经过充分研究的密码学之上，而同一套 smart account 设计可沿用到 SSP 所支持的各条 EVM 链，包括 Ethereum、Polygon、Base、BNB Smart Chain 和 Avalanche。
SSP 背后实现这一切的智能合约已于 2025 年由 Halborn 审计。至于更深入的 account abstraction 机制——EntryPoint、bundler 与验证步骤如何彼此衔接——请参阅account abstraction（ERC-4337）的讲解，而不要把这里任何一处孤立的合约细节当作权威定论。
这对作为用户的你意味着什么
密码学很有意思，但日常真正重要的是它所换来的保护。
- 移动资金需要两台设备。 一笔交易只有在扩展和 SSP Key 各自贡献了它们的那一部分之后才有效。仅仅持有一台设备——或一把密钥——是不够的。
- 丢失一台设备并不等于丢失你的资金。 由于没有任何单一设备能够独自签名，一部丢失或被擦除的手机，或一个被重新安装的浏览器，都不会把你资金的控制权交给任何人。恢复访问权限是另一个有其自身保障措施的话题；恢复在它自己的指南中介绍，不在此处。
- 单把密钥被攻破并不构成单点故障。 即便恶意软件或 phishing 窃取了一台设备上的内容，它仍然无法生成 smart account 所要求的那个聚合的 2-of-2 签名。攻击者需要同时攻破你的两台设备——这比掏空一个单密钥钱包的门槛要高得多。
这些是一般性的保护，而非绝对的保证；良好的助记词卫生习惯和设备安全仍然重要。但结构性的要点依然成立：在价值发生转移之前，两个独立的因素必须达成一致。
与单密钥 EOA 钱包的中立对比
大多数 Ethereum 钱包都是单密钥 EOA。它们简单且被广泛支持，对许多用户而言已经足够。其代价在于，一把私钥就是全部：谁持有它谁就能转移一切，因此一句泄露的助记词或一台被攻破的机器都可能是致命的。
智能合约 multisig 通过要求两把密钥之间达成一致、而非信任单独一把，改变了这一风险格局。还存在其他智能合约 multisig 钱包——Safe 就是一个广为人知的例子——它们以各自的方式解决同一个核心问题。SSP 的独特选择是通过 ERC-4337 配合一个聚合的 Schnorr 签名来交付 2-of-2，于是你既获得了 multisig 的安全性，又拥有单签名者账户那样的链上占用和日常使用感受。
接下来去哪里
如果你想要概念上的根基，请阅读什么是 account abstraction（ERC-4337）以及作为基础的什么是 2-of-2 multisig。要了解这一切如何融入 SSP 中更宏观的 Ethereum 图景，请回到SSP 中的 Ethereum。至于标准本身，权威来源是 ERC-4337 规范以及 Ethereum Foundation 的 account abstraction 概览。贯穿其中的主线，与贯穿 SSP 所支持的每一条链的主线如出一辙：两把密钥、两台设备、一个签名——而你，掌控一切。
