让普通网页能指挥一笔 Cardano 交易：CIP-30 的钱包接口

在 Cardano 生态里，网页应用请求钱包签名与发送交易靠的是 CIP-30——dApp 与钱包的网页桥接标准，官方文件的定位很明确：规定一个注入到网页里的 javascript 对象应该提供哪些方法。Conway 时代之后它又有 CIP-95 这样的扩展版本给治理类操作加方法。把它和 EVM 世界的注入标准对照着读，能看清“网站连钱包”这件事在不同生态里的同一套骨架与同一类风险。

方法表：从启用、读取到签名提交

CIP-30 把一次连接拆成几个动作。网页先调用 cardano.{钱包名}.enable()，成功与否都取决于用户在钱包里的授权；启用之后返回一个接口对象，除签名外的只读方法不再逐次打扰用户——api.getUsedAddresses、api.getUnusedAddresses、api.getChangeAddress 给出地址，api.getUtxos 与 api.getBalance 给出余额视图，地址列表支持分页，官方文件同时写明超出分页上限的请求会被拒绝。签名入口有两个。api.signData(addr, payload) 按地址定位密钥，payload 是原始字节而不是任意 JSON，返回一个把签名与公钥打包在一起的结构；api.signTx(tx, partialSign) 接收 dApp 构造好的完整未签名交易，默认要求对钱包能签的全部输入签名，显式传部分签名标记时只签其中一部分。网页拿到已签名交易后调用 api.submitTx 交给网络，返回交易哈希。这条流程与 EVM 里“dApp 构造交易、钱包确认、广播”的分工同构，但 Cardano 的差异在数据格式：接口间流转的是 CBOR 编码的交易体，交易不是几条键值参数，而是一份带输入、输出、元数据与见证结构的复合文档。

这个格式差异直接决定了钱包确认界面的难度。EVM 交易里“你要转给谁、动哪个合约”相对好解析；Cardano 交易是一份可以直接反序列化成完整账目的文档，理论上钱包能把每张输入输出、每份元数据都还原给人看，但这份“能”取决于钱包实现。所以 CIP-30 生态里钱包质量的差距体现在签名单的可读性上：同一份 CBOR，有的钱包只问“确认签名？”，有的能逐项列出资产进出。选钱包时这是比界面漂亮更重要的能力。

注入模型的同一类攻击面

和 EVM 的 EIP-1193 一样，CIP-30 靠 window 对象注入，意味着网站看到的钱包是“页面上恰好存在的那个对象”。对应的风险也同构：假冒扩展、假钱包页面注入同名对象、钓鱼站诱导你在真实钱包的确认框里签下一份内容你没读懂的交易。对应防御也同构：从官方渠道安装钱包扩展、核对扩展发布者、签名前确认钱包弹层显示的是本地弹层而不是页面内嵌框架，以及对交易签名坚持要求钱包展示可读摘要。CIP-30 文件本身解决不了这些——它定义接口，不定义信任。

CIP-95 是这条接口线在 Conway 治理时代的延伸，为 DRep 委托、投票等动作补方法，并明确采取“扩展而非改造”的路线：不强迫已有 CIP-30 实现整体重写，新能力挂在新命名空间下。这个演进方式本身值得注意——一套成功的接口标准最大的资产是稳定性，宁可加命名空间也不破旧接口。对普通用户的实际影响是：治理类操作（比如给 DRep 委托选票）会经由新的接口触发，遇到这类签名请求时同样适用“要求可读摘要”的原则，委托对象与时长这类关键字段要在钱包弹层里看得见才对得上账户。本文为机制说明，不构成任何投资建议

一次标准调用长什么样

把上面的方法串起来，Cardano 上一个最普通的连接加转账请求是这样走完的：dApp 调用 enable() 获得授权；用 getUsedAddresses 或 getChangeAddress 取一个找零地址；用 getUtxos 拉回一批未花费输出挑出足够覆盖金额的输入；在本地把新交易的 CBOR 文档拼好，附上元数据；调用 signTx 让用户确认后取回见证；最后 submitTx 广播。注意整条链路里拼交易的是 dApp 而不是钱包——钱包看到的是成品，它的责任是把成品读给人看。这条责任线正是 CIP-30 与 EIP-1193 最大的共识：接口不裁定交易好坏，只保证“签之前有人能看懂它”。读得懂成品交易的能力，因此成为钱包实现之间的分水岭，也应当成为你选钱包时的第一标准。

本文为机制说明，不构成任何投资建议。