普通钱包连 dApp，靠的是 把 DNS 记录放进名字服务时要放弃什么：ERC-1185 的按记录集存取：网站请求授权、拿地址、把构建好的交易丢回来签个字，一步到位。可如果钱包的地址由原生脚本控制——比如一个两三人共用的多签地址——这套流程就转不动了：网页拿不到脚本长什么样，也凑不齐签名。CIP-106 想补的正是这个缺口。截至撰稿时它在 CIPs 仓库里的状态是 Proposed（提案中），由开发者 Leo 起草、BroClan 钱包在推进实现，尚未成为已验收的规范。
为什么多签地址接不进 CIP-30
Cardano 的多签地址背后是一段原生脚本，花掉这个地址里的 UTxO，必须满足脚本条件。这里有三类信息是 dApp 构建交易时绕不开、又没法凭空猜的：其一，消费脚本地址的 UTxO 必须在交易里附上对应的脚本本体；其二，验证需要哪些签名、受哪些时间槽约束（规范把这组要求写成 ScriptRequirement，代码位取 Signer、Before、After 三种，值分别装密钥哈希或槽号，并且允许多种合法组合、以数组形式给出）；其三，Plutus V2 及更早形态下，找零输出必须携带 datum，否则钱找回去反而花不掉。普通钱包的 signTx() 一步签名解决不了这些问题，因为多签的签名者可能有好几个人、各自用各自的应用。
把签名变成异步的交钥匙工程
签名凑齐可能要几小时甚至几天，所以 CIP-106 把签名改成异步：dApp 调用 submitUnsignedTx() 把未签名交易交给钱包，先拿回一个交易哈希；钱包负责校验交易、收集签名、组装完整交易。交易没凑齐时，getCompletedTx() 会抛 CompletedTxError，取 NotFound（查无此交易）或 NotReady（还没齐）两个错误码之一；凑齐了才把 CBOR 编码的完整交易与见证一并交还给 dApp。如果交易无效或钱包根本签不了，submitUnsignedTx() 抛 TxError，并且不应把无效的签名请求广播上链。
脚本、签名清单与抵押品怎么交给网页
扩展在 api.cip106 命名空间下加了取数接口：getScript() 返回控制该钱包的原生脚本的 CBOR 编码；getScriptRequirements() 返回上面那组签名与时间要求清单。抵押品方面，getCollateralAddress() 返回一个可用于挂抵押的地址（Plutus V2 起支持部分抵押），该地址必须由签名清单中的某位签名者持有；原来 CIP-30 的 getCollateral() 在这里被改写——脚本地址自身通常提供不了抵押品，dApp 通过它向钱包请求由签名者持有的纯 ADA UTxO。规范同时提醒：若 dApp 选用这个抵押地址，就要专号专用，别拿它干别的事，以免和钱包自己的抵押跟踪打架。
signTx 与 signData 被直接关掉
接入这套扩展时，signTx() 和 signData() 两个端点应当返回错误、视为禁用：原生脚本地址与它们不兼容。换句话说，dApp 不能再用「把交易丢回来签一下」的老路子，必须改走异步提交、轮询完成的工作流；对用户来说，对应的体验是点完连接后交易进入「等待凑签」状态，而不是立刻弹出签名确认。
和以太坊 Safe 的分工差异
以太坊上的多签（比如 Safe）通常是交易先上链挂起、各签署人链上逐笔确认；Cardano 多签钱包的排号规矩：CIP-1854 让所有共同签署人共用同一个派生索引解决的是共同签署人如何共用同一索引生成地址。CIP-106 处理的则是链下协作的另一半：分歧消化在签名组装阶段，交易要么凑齐后一次成型，要么停留在钱包里不广播。两种设计各有代价，前者链上可见度高，后者链上只看到最后一笔完整交易。
提案状态决定你现在能看到什么
CIP-106 的验收标准写着两条：接口被多家钱包支持、被多家 dApp 实际使用，目前都还没勾选，参考实现也只有 BroClan 钱包一个仓库。所以对普通用户，现阶段更实际的问题是「我的钱包接不接这个 dApp」，而不是「我怎么配置它」。连接失败时，先确认双方对原生脚本地址的支持程度，再谈按钮和弹窗。多签协作涉及钥匙与权限的分配，任何钱包接口都不能替你确认转账金额与地址，动手前逐项核对，涉及资产的操作请自行评估风险，本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。