机构发行的代币经常遇到一个两难：ERC-20 要求转账无许可，合规要求却规定某些转账必须先有审批文件。ERC-7963 草案给出的折中是把”审批”搬到一个独立的预言机合约里，每次转账前先验证一张用零知识证明打包的”通行证”。这份 2025 年 5 月 13 日创建的草案目前状态仍是 Draft，作者团队来自蚂蚁集团，它的思路对”链上资产如何对接链下单据”这个问题有普遍的参考价值。
一张通行证的结构
草案定义的核心数据结构叫 TransferApproval，字段包括发送方地址、接收方地址、金额下限与上限（含边界）。要点在于它是一次性的：一次批准只对应一笔转账，代币合约在放行转账时原子地消耗这张批准。换句话说，这不是把额度长期授权给谁，而更像地铁单程票——进站刷一次就作废，补票要重新走验证。
两个关键接口
规范给出 ITransferOracle 最小接口，任何 ERC-20 兼容合约都可以咨询它。流程分两步：发行方调用 approveTransfer，把上面那张通行证存入预言机，同时提交一个零知识证明，证明这张通行证与一条标准化格式链下支付指令一致；持有人随后正常发起转账，代币合约调用 canTransfer，原子性地查询并消耗对应的批准，查不到通行证，转账就不成立。发行方之外，草案的通用数据结构、事件与钩子允许其他许可逻辑共用同一套管道，文档举的例子包括 KYC 名单、旅行规则证明与央行数字货币额度。
零知识证明在这里防什么
这是整套设计里最值得普通读者弄懂的部分。链下支付指令是 JSON 对象，字段包括消息编号、创建时间等。协议要求先对指令做规范化处理，再把字段装进默克尔树，把树根作为证明的公开输入之一。零知识证明验证的是：这张通行证里的发送方、接收方、金额区间，确实都来自同一条真实支付指令的字段，而不是有人把 A 单据的收款人和 B 单据的金额拼在一起。默克尔证明防的就是这种跨单据字段拼凑攻击——通行证合法不等于内容完整对应原始指令，这层绑定补上了这个缺口。
边界与代价
草案宣称发行方无关、证明系统无关、网络无关（一层二层皆可），支付指令格式与金融机构常用的 ISO 20022 pain.001 报文兼容但不强制要求访问该专有规范。参考实现给出了 Rust 编写的 RISC Zero 客端程序，用于指令校验与默克尔证明验证。代价也要摊开看：每笔转账多了一次预言机咨询与证明验证的开销；通行证由发行方预存，意味着转账自由度实质交给了发行方的单据流程；canTransfer 的消耗语义要求代币合约正确处理重入与失败回滚，集成方需要核对实现细节。
用之前的三查
第一查状态：这份标准还在 Draft 阶段，接口与结构可能变动，接入前以仓库最新版为准，不把草案当终稿。第二查证明系统：规范不绑定证明系统，意味着不同实现的证明体积、验证成本与信任假设不同，“用了零知识证明”本身不说明安全等级。第三查角色划分：谁预存通行证、谁运营预言机、出问题找谁，这些治理问题规范管不了，要看具体发行条款。机制讲到这里可以收束：它把”先有凭据、再放行”的传统金融流程压成了一个链上可验证的小闭环，值不值得为它付出每笔转账的复杂度，是每类资产自己权衡的事。
对以 NFT 为主要资产的读者，这份草案的意义更多在接口形态：它示范了”转账可行性”如何变成一个外部可验证属性——规则不写死在代币合约里，而是集中到一个可替换的预言机后面。将来任何需要”先审后转”的藏品类资产（限定持有人的纪念凭证、受许可约束的数字版权份额）都可能复用这套管道，届时普通用户面对的将不再是”这笔交易为什么被拒”的黑盒，而是一份可以要求出示的链上通行证记录。
本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。