储备金在侧链上被盗：跨层信任的三张核查表｜洹拓科技
一、被打破的不是密码学，是一份没人核查过的信任假设
先把本篇的立场说清楚：不讨论资产价格，不评论任何一方的对错，也不推测手法与漏洞，公开报道没有给出根因，我们就不去补。要看的是另一件对所有系统都成立的事：一套密钥治理和门限设置，能够安全承载的资产规模是有上限的，而这个上限通常从来没有人算过。据公开报道，这次被搬走的部分占到该层总储备的九成以上；这个比例不作为本篇的判断依据，它只说明承载超限这件事确实发生了，而真正可迁移的是那三张核查表。
这类系统对外表述的结构是一句话：我继承上游账本的结论，但我的锁在我手里。前半句是信任的来源，后半句是风险的归属，两句话一起说、一起被相信，上线之前没有人把它们分开验证过。所谓跨层信任，缺的就是这一步分开验证。更麻烦的是，把绝大部分储备放在这一层，本身就默认了后半句的强度不低于前半句，而这个默认从来没有对应的证据。
二、第一张核查表：三层假设，逐层问“可复核证据是什么”
一句声明能不能被信任，取决于它能不能被复查。下面这张表是洹拓做供应商尽调和内部架构评审时按层要问的，右两列比左两列重要。
| 层 | 这一层被默认为真的假设 | 可复核证据 | 最常见缺口 |
|---|---|---|---|
| 共识与账本层 | 本层结论真的继承上游，而不是靠少数节点见证 | 参与验证的节点集合规模与分布、历史上新旧结论冲突与重组的记录、上游对本层状态是否有任何否决路径 | 把“接了上游的数据结构”讲成“继承上游的安全性”，两者差着一个验证者集合 |
| 资产托管层 | 锁由多个互不相关的主体共同掌握 | 公开的签名者集合与其主体归属、门限数值、末次轮换的记录与时间、密钥生成过程留下了什么形式的凭证 | 签名者名单公开，但归属主体全部来自同一组织的同一套云环境 |
| 运维层 | 签名动作受策略约束，不是随时可用的能力 | 签名策略文档、白名单还是人工审批、审批链路的日志形态、热签名服务在网络上的可达范围 | 策略写在文档里，实际执行靠一个能随时手工放行的脚本 |
三层里最常被跳过的是第三层，因为它不好看也不性感。可正是这一层决定了损失展开的速度：一个联网可达、靠人工审批放行的签名服务，只要有一次放行被突破，它承载的那一整域储备就同时在射程之内。
三、逻辑上等价，不等于风险上等价
这是这类事故对普通系统最有价值的一句迁移：资产或数据可以跨层搬动，锁与治理却不一定跟着搬。在同一层里，一单位资产“逻辑上等价于”原来那一单位，不意味着它“风险上等价”。
把这句话翻译成我们能用的四条检查。第一问谁能否决一次写入：原层的写入要经过多方独立同意，新层是不是只需要本层的门限凑够。第二问失陷后的爆炸半径：新层的锁一旦被解开，损失范围是这一层的全部还是按域切开的局部。第三问可撤销的速度：从发现异常到让某一把钥匙失效，需要几天、几个人、几次会议。第四问可审计的深度：事后能不能还原某一次签名是由哪几把钥匙、在哪套策略下完成的。这四条在原来的层里往往有清晰答案，搬完一层之后，四条全都变成“据对方说”。客户把核心数据从自管库迁到某个托管层、把发布签名从自建基础设施迁到第三方流水线，遇到的正是同一件事。
四、第二张核查表：密钥治理五问
不管对方声明的是多签、门限签名还是某种托管，尽调时都换成这五个问题，而且要拿到书面回答。
- 有几个签名者：给出数量，不是“多家机构共同守护”。
- 他们代表几个独立主体：这是最容易露馅的一问。签名者的法律主体、办公地点、云租户、凭据管理体系如果同源，数量再多也是同一个故障域。
- 门限是多少：除了写出 t 与 n，还要追问在任意一个签名者失陷之后，剩余集合是否仍能守住门限，或者反过来是否仍能阻止一次未经同意的动作。
- 密钥如何产生与存放：是硬件隔离设备内生成且私钥部分从不外出，还是在某台通用机器上生成后以配置项、环境变量或明文文件的形式分发保存。这两种存放方式对应完全不同的事故概率。
- 单一主体失陷后门限是否还守得住：要求对方给出“任意一个签名者集合被完整攻陷”这一前提下的最坏结果，而不是平均情况下的健壮性说明。
五问里只要第二问和第四问的答案不理想，前面所有关于“多重签名”的描述都应降级为“多份钥匙”，因为多份钥匙与多重保护的区别在于钥匙之间的独立性。
五、第三张核查表：变更与撤销这条链，加上集中度这个字段
第一缺，签名者轮换频率没有定义。没有轮换周期，签名者名单就从治理对象退化成人事记录，人事一动就变成风险。第二缺，失陷签名者的移除程序没有演练过。真出事时的移除要走几步、需要谁同意、能不能在门限内完成，这些只能靠预先定义，临时讨论的结果通常是移不掉。第三缺，历史门限变更不可审计。如果查不到某段时间的门限是多少、签名者是谁，事后连“当时那一次签名是否合规”都无法判定，更无法向客户或监管解释。
三条里缺任何一条，本质上都是把长期持有的资产放在短期有效的凭证上，凭证的寿命由人维持，而人不会永远在场。
另一个更该被当作风险字段登记的东西是集中度。据公开报道给出的那个占比之所以值得单独写一段，不在于数额，而在于结构：高集中度加上单一地址或单套门限，等于把整个系统的风险写进了一个字段。对应的治理动作很具体——按冷热与用途把储备分域存放，每一域单独设门限、单独出五问的答案；在台账里增加“单套门限承载的价值占比”这一列，给一个明确上限，超出的部分要么拆域，要么升格审批。把风险写成可查询字段，是它进入日常管理唯一的路。
六、迁回自己的交付：三条做法与一个尽调问法
第一条，把跨层、跨链、跨云的资产依赖当成第三方依赖来管理：进依赖清单、进故障演练、进熔断设计。多数团队的依赖清单只登记软件包与接口，不登记“哪一块结论其实由另一层的治理决定”，于是这层依赖从来不出现在评审里。
第二条，对高价值操作强制独立通道二次确认：签名策略与业务策略由两套系统控制，任何一方被单方面突破不足以放行一笔动作。这里的关键词是“独立”，如果两套系统同属一个管理员、同一目录服务、同一套堡垒机，那只是把一次确认做成了两次点击。
第三条，任何“我们用了多签”的声明，尽调时一律换成上面五问来问，并要求把回答附在方案里。回答不出的，按“单点持有”来评估风险预算。
最后一条观察：这类事件里，真正说明治理水平的不是损失数额，而是损失占储备的比例与集中度。所以我们给供应商尽调定的问法，是问比例、问单套门限承载占比、问末次轮换时间，不问总额。总额只能说明这次亏了多少，前三项才说明下一次会不会再亏一遍。