多签钱包的隐藏配置题：签名人、模块与权限地图审计

多签的强度不写在「几个签名」里

人们选择多签时关注的通常是阈值——三把钥匙里两把签字才能动钱。但实际决定这个系统安全高度的，是一组更少被翻看的配置：三把钥匙分别握在什么设备与什么地点；谁能修改签名规则；有没有第四种力量被授权绕过签名流程。多签合约在结构上是一个小型治理系统，阈值只是它的表面参数。攻击者很少去破解「二 of 三」的数学，他们做的工作是：找到其中一把管理松散的设备、钓出其中一个签名人的一次失误签名、或者发现系统里有一个比所有签名人都权限更大的东西。把多签当成系统来审计，才是它正确的主人姿态。

第一层：签名人拓扑

三件要核对的事。物理拓扑：三把钥匙是否分别存放在三种不同性质的环境——例如一台硬件设备加另一台不同型号的硬件加一个异地设备，三种环境同时失守的难度远高于同型号同批次；「三把钥匙都在同一个抽屉」的三 of 五，安全性接近一 of 一。地理拓扑：备份与设备是否同城同建筑——火灾与入室同时击穿所有点。人的拓扑：签名人名单里有没有「实际是同一人的两个身份」，有没有已离职、失联、关系变化却未退出名单的人——多签事故里高频出现的不是黑客，是一份过期的名单。名单管理本身就是安全机制，需要一年至少一次的正式确认：每位签名人确认职责、确认设备可用、确认愿意继续。

第二层：扩展模块——那扇侧门

主流多签实现支持模块扩展：自动订阅支付、恢复方案、策略引擎都以「模块」形式挂接。模块的权限本质通常是「可以在满足某些条件时替多签执行交易」——它们是功能，同时也构成签名人之外的另一条资金路径。审计动作很具体：打开模块清单，逐个确认名称、地址与你当初添加它的意图是否对应；模块现在仍在被使用吗；这个模块的实现属于谁、有没有审计与事故史；它有没有被限制在特定功能与额度里。清单里出现你叫不出用途的模块，按安全事件处理流程对待：先移除或禁用，再研究它是什么——顺序不能反。模块与 owner 权限的边界也要确认：模块能不能改自身配置、能不能安装更多模块，这两个能力叠加时，一个被攻陷的模块就从侧门变成了后门。

第三层：治理参数与升级路径

多签合约自身的可变参数常被忽略：修改阈值与更换签名人的权限在谁手里（理想答案是多签自己，且大额变更附加等待期）；合约可升级性——若这套实现带有实现升级机制，谁触发、要不要时间锁。再有一项最容易被漏掉的：fallback handler 类配置，它决定了「有人向这个地址转入某些类型的资产时会发生什么」，配置错误会造成「转账进来但看起来像失败」的复杂事故；普通托管多签如果不需要这类高级功能，保持默认最安全。参数审计的产出物是一份一页纸配置快照——阈值、签名人、模块、时间锁、权限边界——存档并附核验日期，下次体检时逐行对比变化。

应急通道与演练

最后一组问题在纸面上：一位签名人的设备突然故障，资金操作还能完成吗（阈值余量与备用签名人机制）；一位签名人私钥暴露，撤换流程需要几步、多久、要不要一次「先止血后换人」的临时阈值下调；一笔交易卡在半签状态没人收尾，谁知道去哪里撤销。这三题没有答案的多签，在平静期看不出区别，在事故第一周就会现出原形。演练方法：每年做一次「模拟换人」——把一个真实签名人临时移出再移回，完整走一遍流程并计时。多签的全部价值在于它假设每个人都会犯错；而审计的全部意义，是确保这份假设本身没有错——系统里最危险的配置，往往是那个从没被人打开看过的配置页。