在 tezos 上点开一个 NFT 铸造页，页面弹出来的那个”请求连接账户”的窗口，背后走的是一套比多数人以为的更规整的协议。TZIP-010 钱包交互标准定义了去中心化应用与钱包之间该说哪几种消息、按什么顺序说、被拒绝时应用该收到什么。它由两家机构在 2019 年 9 月提出，状态为 Final，是 tezos 生态里 dApp 与钱包（浏览器扩展或内置钱包）能互相替换使用的底层约定，也解释了”为什么有的操作根本不需要先连接账户”。
协议把双方的通信抽象成四个方向明确的请求：PermissionRequest 请求账户权限、SignPayloadRequest 请求对一段数据签名、OperationRequest 请求签署一笔操作、BroadcastRequest 请求广播一笔已签好的操作；钱包对应回 PermissionResponse、SignPayloadResponse、OperationResponse 和 BroadcastResponse。每种请求和响应都是带指定标签的结构体，网页与钱包靠标签路由消息，而不是靠 DOM 弹窗或者约定俗成的全局变量。规范同时规定了错误标签，例如用户拒绝会回 NO_PERMISSION、NETWORK、ABORT 这一族明确代码，应用据此区分”你拒绝了”和”钱包坏了”。
顺序约束是这份标准最实用的部分。OperationRequest 与 SignPayloadRequest 必须指向某个具体账户，而指向账户的前提是先成功发出过 PermissionRequest；换句话说，没有拿到授权之前，这两类请求根本发不出去，硬发的结果是 NO_PERMISSION。相反，BroadcastRequest 与某笔已构造好的操作绑定、不直接关联某个账户，因此允许在未请求权限时发出。这个差异解释了日常体验里的一个细节：有些”广播已签交易”的流程看起来没弹授权框，并不是绕过钱包，而是协议本来就允许。
授权本身还带范围。权限请求里可以申请若干作用域（scope），比如只读取地址、允许请求操作、允许签名负载等，钱包可以把不同作用域分开批准或分开拒绝；用户在钱包里看到的”允许签名”与”允许发起交易”是两条独立开关，来源就在这里。响应会带回账户地址、链标识和网络信息，应用拿到后缓存，之后每个请求都可以带上这组上下文。链字段尤其重要：测试网与主网的响应分开，一个应用如果在错误的网络上被查询，应当能从返回的链标识里发现不一致。
传输层上，TZIP-010 早期版本定义了网页与扩展之间的消息封装，并允许应用以 URL 重定向的方式唤起钱包——把请求序列化进一个跳转链接，用户在钱包页面里看完确认后跳回应用。这套离线桥接让”不装扩展也能完成签名”成为可能，也是很多 tezos 钱包登录页看起来像普通网页跳转的原因。规范同时强调请求里要有可辨认的来源信息，避免多个页面争抢同一响应通道时张冠李戴。
从使用者角度，这份标准给了几条可操作的核验习惯。第一，看钱包弹窗标题里的域名与请求类型：请求签名消息与请求支付一笔操作，风险等级完全不同，前者一般不花钱、后者会花 gas 并可能转走资产。第二，如果网页声称”已经连接”但从未弹过权限窗，可以怀疑它要么只用 Broadcast 类操作、要么根本是假壳子。第三，同一个域名反复请求不同作用域时，应在钱包的授权管理里查看此前批准过哪些范围并撤销多余的。tezos 钱包普遍把按站点管理的授权列表放在设置里，正是配合这套按作用域拆分的授权模型。
也要说清楚边界：TZIP-010 规范的是”应用怎么问、钱包怎么答”，不保证问你的内容是善意的。签名请求里的数据可以是任意字节，恶意页面完全可以在合规协议外壳下请求你签一笔授权。协议层面给的答案是”每类请求都明确标注类型、来源和账户”，用户层面的答案是”把每次弹窗当成一次独立审批”。
作为对照，以太坊生态里类似的通信由提供方各自约定，没有一份同样地位的统一消息协议；tezos 因为钱包交互标准起步早，扩展与应用互换性普遍更好。理解这一点后，再遇到”换个钱包就不能用”的情况，多半问题不在协议，而在那只钱包对旧版消息格式的支持范围。
本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。