SSP 与 Squads V4：两种 Solana 多签设计
多签钱包是一种在资金转移前需要不止一个批准的钱包。在 Solana 上，多个团队构建了多签系统，而它们的底层运作方式并不相同。本文比较其中两个——Squads V4 与 SSP 自己的多签程序——目的不是评出一个赢家，而是展示两种诚实且经过深思熟虑的设计理念，以及各自适合谁。
如果这是你阅读本系列的第一站，配套文章自启动的 Solana 多签完整解释了 SSP 的设计如何运作。在这里，我们将它与网络上最成熟的方案并列对比。
首先肯定 Squads V4
Squads V4 是 Solana 上占主导地位的多签。它成熟，保护着数十亿美元的价值，并且经过了一份格外长的安全公司名单的审查——OtterSec、Neodyme、Trail of Bits 和 Certora，其中 Certora 还应用了形式化验证（用数学证明代码的行为符合规范）。Fuse 等钱包就构建在它之上。任何诚实的比较都必须从这里开始：Squads 是一个严肃且久经实战检验的平台，下文的任何内容都不是对它的批评。
SSP 的 Solana 多签程序采取了不同的形态，因为它为不同的目标而构建。两者并非争夺同一份工作，本文余下部分讲的是什么不同以及为什么不同。
一个关于成熟度的提醒，明确说清
有一个差异比任何设计选择都更重要，所以先说它。Squads V4 运行在 Solana 主网（mainnet）上——即真实资金流动的实时网络——并已通过上述审计。SSP 的 Solana 多签程序在撰写本文时仅限于 devnet（Solana 的测试网络，其上代币没有货币价值），并且正在等待一次外部安全审计。它还不是你应该用来托管主网资金的东西。下面的比较关乎设计取舍；它不是在主网上使用未经审计软件的建议。
钱包如何被创建
最明显的差异在于多签如何诞生。
Squads V4 用一条名为 multisig_create_v2 的链上指令来创建多签。该指令需要两样东西：创建钱包的人（即创建者），以及一把全新的、随机的、一次性的密钥，称为 create_key。钱包的链上地址由这把随机的 create_key 派生而来——因此在创建交易运行之前，该地址根本不存在，也无法被知晓或注资。在那一刻还有一个创建者在场：一个独自完成钱包设置的单一方。
SSP 的程序在这个意义上没有创建步骤。它的多签地址直接从成员集合本身派生——具体来说，源自经过排序的成员列表连同批准阈值的一个指纹。由于输入只是"成员是谁"和"需要多少人批准"，任何知道这些事实的人都可以在链下、在链上发生任何事情之前计算出地址。注册钱包是无需许可的：程序只是检查你提交的成员确实哈希成所声称的地址，因此规范地址只能持有规范的成员集合。这里没有创建者，也没有随机密钥。
你能在它存在之前为它注资吗？
这直接源自上一点。
对于 Squads V4，地址取决于创建时选定的一把随机密钥，所以你无法预先注资——你先创建钱包，再发送资金。对于 SSP 的设计，由于地址是成员与阈值的纯函数，你可以计算出存款地址并在钱包于链上注册之前向它发送资金。这与 Bitcoin 的运作方式一致：一个 Bitcoin P2WSH 地址是花费规则的哈希，任何人都可以在链下为它注资，完全不需要"创建"交易。与 Squads 这样占主导地位的 Solana 多签不同，SSP 的程序把"地址即规则"这一特性带到了 Solana。
特权角色与管理权限
Squads V4 是一个治理平台，并提供与之匹配的治理功能。每个成员都可以被分配一个权限位掩码——三种权利的组合：发起（提议一笔交易）、投票（批准一笔）和执行（执行一笔已批准的交易）。在此之上，一个 Squads 多签可以选择性地拥有一个 config_authority：一把能够独自更改成员列表或阈值的密钥。"受控"多签保留该权限；"自治"多签将其设为空值，使每一次配置更改都必须改为通过成员投票。对于想要指定管理员的组织而言，这些是真实而有用的功能。
SSP 的程序刻意没有任何这些。每个成员都是平等的——没有按成员划分的权限层级。没有管理员密钥，也没有 config_authority。成员集合与阈值在注册时固定，此后不可变；"轮换一把密钥"意味着把资金转移到一个拥有新成员集合的新多签。阈值只在花费资金时检查，从不在注册时检查。取舍很清楚：Squads 给你管理上的灵活性；SSP 给你更小的攻击面，因为一个不存在的特权角色无法被钓鱼、被窃取或被滥用。
创建它的成本
创建一个 Squads V4 多签会产生一笔有据可查的协议费用，约 0.1 SOL，支付给 Squads 金库，此外还有少量的 Solana 租金（每个账户为保持存活而必须持有的可退还押金）。SSP 的程序不收取任何协议费用：注册一个多签只需支付底层的 Solana 租金。这并非价值评判：协议费用为一个大型平台的持续开发提供资金。它只是两种设计差异的又一个维度。
两种理念，两类受众
退一步看，模式就很清晰了。Squads V4 是一个功能丰富的治理平台：按成员划分的角色、可选的管理员、成熟且经过审计的代码库，以及组织管理一个有众多利益相关者的金库所需的工具。SSP 的程序是一个极简的确定性原语：地址即成员集合，注册无需许可，没有特权角色，并且在你与你的资金之间尽可能少地放置机制。
各自适合不同的需求。一个想要指定管理员、精细权限和经过验证的主网记录的 DAO 或公司，由 Squads 来服务很合适。SSP 的设计瞄准的是一个不同的模型——一个 2-of-2 的消费者钱包，以及面向企业的 M-of-N 配置——其中的优先事项是钱包地址可预测、可预先注资，并且不带任何可能成为单点故障的角色。SSP 有意省略了 Squads 的治理功能：对于 SSP 的使用场景，可被攻陷的东西就是更少。
要看 SSP 的选择在真实攻击场景下如何表现，学院文章多签的失败模式以及 SSP 如何缓解它们直接梳理了这些威胁模型。如果你想要 SSP 派生的技术细节，自启动的 Solana 多签一文是规范参考。至于另一方，Squads V4 的源代码与文档是公开可得的。
诚实的总结
这里没有"更好"的多签，只有更合适的匹配。Squads V4 是成熟、经过大量审计、功能丰富的选择，适合想要内建治理的组织。SSP 的程序是一个更小的、以地址为先的设计——目前仅限于 devnet 并在等待审计——其构建目标是让一个多签钱包感觉像 Bitcoin 地址一样可预测。两种诚实的理念，各自解决其创建者着手解决的问题。
