本内容由德语机器翻译而成，尚未经母语人士审校。技术和监管术语以德语或英语版本为准。
法律结构与运营风险
哪一层有责任对象，哪一层没有——以及为什么 3-of-5 多签尚不能说明密钥管理的任何情况。
本课未经专业审阅。它是为本平台撰写的，并依据所列证据写成；未进行过独立的专业审阅。
学习目标
- 您能够区分机构链上头寸的三个层次，并为每一层确定其责任对象。
- 您能够指明多签阈值未说明的信息。
- 即使技术风险和市场风险在同一天发生，您也能够将两者区分开来。
检查预备知识
请在继续阅读之前，先自行回答这些问题。您犹豫的地方，正是本课的价值所在。
- 贵机构的哪个法人会持有该头寸？
- 目前在您的指令与执行之间有哪些服务提供方？
- 在贵机构，谁有权撤销授权，速度有多快？
核心概念
三个层次，两个责任对象
机构链上头寸有三个层次：持有它的载体（一个具有章程、治理机构和监管的法人）、中间的服务提供方（托管方、签名硬件、RPC 和索引提供方——各自有合同约束），以及协议本身。前两层有责任对象：有人承担义务。第三层通常没有。混淆这些层次的人，会在没有合同相对方的地方寻找合同义务。
阈值还不等于密钥管理
“3-of-5”描述的是合约中的一个条件，仅此而已。仍未明确的是：五把密钥在物理上存放在哪里？它们是否都来自同一硬件厂商？是否有两名持有人在同一房间？当持有人离开机构时，如何撤销其密钥，需要多长时间？这些问题决定阈值在紧急情况下是否守得住——而合约对其中任何一个都没有回答。
外包意味着转移，而不是消除
在决策与链之间，存在一些很少出现在风险登记册中的提供方：用于读取和发送的 RPC 端点、报告所依据的索引器、签名硬件。服务合同通常规定的是可用性，而不是正确性：一个提供过时数据的端点仍然是可用的。这种情况是否在合同中有所涵盖，必须去查阅——不能假定。
两个原因，同一天
如果一个头寸在索引器也发生故障的那一天出现亏损，就有两个原因在起作用，它们应当分开：即使没有故障，市场损失也会发生；故障造成的代价是未能及时看到这一损失。只有分开归因，才能得出可用的措施——一个要求调整头寸规模，另一个要求建立第二条数据路径。
术语
模型
载体——法人、治理机构、监管：存在责任对象
服务提供方——托管、签名、数据：依合同存在责任对象
协议——机制加治理：通常没有责任对象
结果：索赔止于第二层
公式
m-of-n 阈值说明了什么
handlungsfaehig 当 erreichbare_schluessel >= m ; fremdgesteuert 当 kontrollierte_schluessel >= m- m
- 合约要求的签名数量
- n
- 已发放的密钥总数
- erreichbare_schluessel
- 其持有人确实能够及时签名的密钥
- kontrollierte_schluessel
- 可能被同一方控制的密钥
局限: 该公式计算的是密钥数量，而不是它们的独立性。如果全部 n 把密钥来自同一厂商、位于同一建筑或由同一服务提供方保管，独立持有人的实际数量可能远低于 n——而阈值在形式上保持不变。
计算示例
一个实际承载力低于表面的阈值
- 阈值
- 3-of-5
- 硬件
- 全部五台设备来自同一厂商，固件版本相同
- 地点
- 三名持有人位于同一地点
- 撤销流程
- 已有文档，最近一次演练在 14 个月前
形式上 m = 3，n = 5。按独立故障源衡量：一个固件缺陷会同时影响全部五台设备，一个地点故障会同时影响三名持有人——恰好达到阈值。
该阈值对单个不诚实的持有人有效，对共同的厂商缺陷则无效。
解读: “3-of-5”这个数字是正确的，但只要五把密钥的独立性未一并记录，它仍具有误导性。措施由此直接得出：第二家厂商、第二个地点、经过演练的撤销——而不是更高的阈值。
提取练习
基于真实数据的练习
阅读指导问题，并标出其中哪些可以由服务合同回答，哪些只能由协议本身回答。
维度 3：技术 →应用
为运营手册撰写托管控制这一行，使审计人员无需追问即可理解。
相关案例研究
机构视角解读
- 银行
- 目前 RPC 提供方的故障记录在哪个风险登记册中？
- 保险
- 因厂商缺陷导致的密钥丢失，是承保事件还是除外事件？
- 咨询
- 这些信息中，哪些您会以书面形式向客户保证？
要点
- 载体和服务提供方有责任对象，协议通常没有。
- m-of-n 阈值计算的是密钥数量，而不是它们的独立性。
- 可用性承诺并不涵盖正确性——要么写在合同里，要么哪里都没有。