手机浏览器里的 dApp 想连钱包，没有桌面端那一套注入式扩展，CIP-30 网页桥也跨不出应用边界。常见解法要么扫码、要么内嵌 WebView、要么起一个中转服务器。CIP-186 提出第四条路：让操作系统的链接分发机制直接干活——dApp 把签名请求打包成一条深链丢给钱包 App，签完再把结果原路送回来，全程没有中继服务器、没有二维码、没有内嵌页面、没有 WebSocket。它目前是 Proposed 状态，名字里的 dl 就是 deep link。
请求发到什么地址
协议在 https://钱包域名/cip30dl/v1/... 这个前缀下排布请求与回调端点：iOS 优先走 Universal Links，退回自定义 scheme；安卓走 App Links，遇到多个钱包注册同一域名时，由系统的 Intent 选择器让用户决定交给谁。没有注册域名的钱包可以退回 cip30dl: 开头的自定义协议作平台兜底。链路分层清清楚楚：系统负责搬运链接，密码学负责其余的一切。
配对与接口面
dApp 与钱包之间用一次 X25519 临时密钥交换建立会话，两端各自生成临时密钥、拼出共享秘密，后续消息在这个基础上加密绑定。暴露给 dApp 的方法面刻意收窄：它是 CIP-30 方法集的严格子集，核心就是 signTx 与 signData 两个签名操作加账户读取——钱包不需要为新通道重写风控界面，复用既有的 CIP-30 签名 UI 即可承接深链请求，这也是该提案对实现方最友好的一点。
最要紧的一环：签名承诺回执
深链通道有一个桌面端没有的疑点：结果回来时，dApp 怎么证明钱包签的就是我发出去的那笔交易？CIP-186 的做法是给每笔待签交易的规范序列化交易体算一个 BLAKE2b-256 承诺（commitment），随请求一起走；钱包返回见证集时附上它实际签下的交易体的承诺，dApp 比对即可确认「签的就是这笔」。盲签争议的很大一部分，正是发起方无法确认签了什么、接收方无法自证签对了对应关系；把这一环写进协议层，是这份提案最有含金量的设计。见证集最后通过通用链接回调送回 dApp，闭环完成。
用户视角的核对清单
对普通用户，深链不改变安全纪律：弹进钱包 App 后，金额、收款地址首尾、网络前缀仍然以钱包自己的屏幕为准；链接来源可疑（弹窗推销、陌生短信）时不要点开；同一域名被多个钱包注册时，系统选择器里认错的那个 App 正是假钱包最惯用的入口，识别手册见 弹窗不是凭空出现的：深链与协议唤起连接钱包的识别手册。签名前为什么不能一路「确认」到底，盲签是什么？钱包确认页怎么看 讲了盲签的代价；而网页桥方法层的治理扩展另见 网页里指挥钱包的规范层：CIP-95 给 Cardano 钱包桥补上的治理扩展。
四条连法，四种信任面
把深链与常见方案摆在一起：扫码通道最怕「换码」，收款二维码被换成攻击者的，肉眼难辨；内嵌 WebView 让钱包装进 dApp 的地盘，假界面可以仿到像素级；中转服务器方案里，服务器运维方看得见会话元数据，也多出一个可用性单点。深链把「该交给哪个 App」的裁决权交回操作系统：iOS 依赖域名归属校验的 Universal Links，安卓依赖系统级 Intent 选择器，仿冒应用至少在域名与安装签名这一关要付额外成本；会话再叠一层 X25519 临时密钥，链接被第三方截读也不裸奔。当然，域名注册在谁手里、选择器里图标认不认识，仍然是最终要人来确认的两件事。
状态与预期
Proposed 意味着尚无实现义务：钱包是否注册了这些域名、系统层是否配置 Universal Links 与 App Links，都要按产品逐个核验，没铺开之前扫码与网页桥仍是主流通道；对钱包厂商，域名侧的 Universal Links 与 App Links 配置、回调白名单管理是这份协议落地的全部工程门槛，门槛不在密码学而在移动端发布流程。深链降低的是连接摩擦，不降低签名决策本身的风险，涉及资产的操作请始终在钱包端完成最终核对；本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。