标准多签钱包有个不太被讨论的副作用:协作各方要互交扩展公钥(xpub 或描述符),而扩展公钥=公钥+链码,链码在手,对方就能像你自己一样沿任何路径推导全部地址,顺手扫出整条余额与资金流水。对个人对个人多签这无伤大雅,对”用户+托管商”式的协作托管却意味着你把全部账本摊给了服务方。BIP-89《链码委托》(作者 Jesse Posner 等,状态 Deployed)要修的就是这个错位:让签名能力照旧分发,把账本可见性收回。
它的核心概念是把”链码”定义为被委托之物,而不是签名权本身。钱包里的参与者分两类:委托方(delegator)只保留一对普通密钥——没有链码的裸密钥;受托方(delegatee)持有委托方的链码,替它保管派生能力。任何参与者仍然可以共同签署钱包里的 UTXO,区别在于委托方每次签名前,要向受托方领一份该笔输入的标量调整值(tweak),用它把裸密钥按路径修正成那把真正对应的密钥,验签与签名都能完成,但委托方永远无法自己算出”下一个地址在哪”。派生规则限定在非硬化路径(索引小于 2 的 31 次方)——这正是让”仅凭公钥就能算调整值”成立的数学前提。
一笔典型的签名流程是这样走的:钱包要花费某个输入,委托方先要这笔输入(以及找零输出)对应的调整值;受托方沿”BIP32 未硬化路径”把逐层调整值累加成单个标量发过来;委托方在裸密钥上应用标量,得到该笔交易的临时密钥,参与聚合或分别签名;整个过程结束,委托方的知识库只多了”这一笔的 tweaks”,没有多任何地址树。验证一方(比如另一位参与者)可以离线核对 tweaks 与钱包策略一致,而委托方自己不再具备扫描链上余额的能力——它连地址都枚举不出来。
这套设计的价值在角色关系里最清楚。协作托管的经典矛盾是:托管商需要能核对客户资产以便服务,客户不想让托管商随时看得见自己全部身家。CCD 让托管商作为委托方时,它依然参与签名、依然能验证钱包执行了约定的策略,但拿不到全景账本;客户作为受托方保管链码,掌握”哪把钥匙对应哪个地址”的完整地图。反过来的部署(客户委托、机构受托)也成立,取舍点从”能不能防对方”变成”是否信任对方诚实提供调整值”——CCD 的信任模型是明确的:受托方在 tweaks 上造假会直接导致签名验证失败,属于可即时发现的故障,而不是无声的窃取。
工程边界要老实交代。第一,它 Requires 32、340、341,建立在 BIP32 派生与 Taproot 签名框架上,主要面向 MuSig2 类聚合多签的部署形态。第二,不硬化派生是硬约束,涉及硬化的钱包结构不适用。第三,状态 Deployed 说的是有生产环境部署,不等于全网钱包默认提供这个选项;评估某个具体托管方案时,仍然要看产品文档里 CCD 覆盖到哪条流程。
常见误区有三。其一,以为 CCD 加密了什么:没有,链上数据一字未改,它锁的是链码这个”可扫描性放大器”。其二,以为委托方失去签名能力:签名能力完好,缺的只是自主派生。其三,以为受托方能偷币:受托方拿的是”保管链码+算调整值”的职能,没有委托方私钥它照样动不了资金。
快速问答。问:它和 watch-only 是相反方向的同一件事吗?答:方向相反——watch-only 是”给账本不给你私钥”,CCD 是”给你私钥不给你账本”。问:调整值交换泄露了什么?答:只泄露”这一笔”的存在与派生位置信息,历史全貌仍在受托方手里。问:为什么 2025 年才立项?答:MuSig2 与 Taproot 的聚合签名实践成熟后,“公钥可加调整值”这条路才在多签产品里变得日常,需求是新近长出来的。
风险提示:本文是钱包机制科普,不构成投资建议;任何多签或托管安排落地前,请核对具体产品对该提案的覆盖范围。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。