在 tezos 上给受限资产做转账限制——合规证券、邀请制藏品、白名单空投——2020 年出现过一份专门的标准提案 TZIP-015，名叫 A2 代币传输名单接口。它由 Michael J. Klein 在 2020 年 5 月 14 日创建，但必须先讲清结局：这份提案的当前状态是撤回（Withdrawn）。它设计得相当完整，最后仍被生态放弃，这个案例比它的任何接口都更有信息量。
先说它当年想解决什么。代币合约经常需要控制谁能发起、接收转账，尤其在代表受限资产（比如数字证券）时。链上的常见做法是维护”传输名单”——记录哪些用户允许作为转账的发送方或接收方。TZIP-015 想把这些各自为政的名单实现标准化：一套轻量的授权模型，既能嵌在代币合约内部，也能拆成独立合约按需查询，两种挂法共用同一套接口约定。
机制围绕三个数据概念加一组入口。用户与传输名单各有一个 16 位无符号整数编号，转账时合约查两类表：用户到名单的映射，决定”他属于哪些组”；名单到名单的映射，决定”这个组能转给哪些组”。接口分三类断言入口——断言转账 assertTransfer、断言接收 assertReceiver、以及批量检查的断言传输名单 assertTransferList；配合一个发行者账户概念：发行者有权把资产发给任何”可接收”的用户，把发行者设为一个空合约就等于关掉特权，换成多签或代理合约就是拆分特权。一次普通转账的时序被画得很清楚：用户调转账，代币合约带着参数去问传输名单合约”这人能转出吗、那人能收吗”，得到应答后要么提交要么报传输名单违规。
标准甚至照顾到了升级体验。它专门讨论过迁移：合约元数据里的更新入口（TZIP-016 的 update_metadata）可以让部署方在不改字节码的前提下声明新的 TZIP 接口符合性，“只要不破坏合约逻辑、不带来不可恢复的风险，合约可以声明新增接口”——这是把”我支持了传输名单”这种事实登记在可查询的元数据里，而不是发一篇公告。
那为什么撤回？把提案文本与生态走向放在一起看得更清楚：它诞生的 2020 年上半年，“资产上链要带许可”被普遍预期，tezos 又恰好因证券型代币发行（STO）活跃而需求现成。但随后的演进把限制做回了资产合约内部——FA2 各实现直接把权限逻辑写进 transfer 入口，TZIP-021 元数据与 FA2.1 的修订吸收了对”额外接口”的大部分需求；一个”查询式”的名单合约每次转账多一跳调用、多一分 gas 与故障面，市场最终没有形成对独立名单接口的公共依赖。提案页头部的 Withdrawn 状态就是这段历史的盖章：不是设计错了，是需求改道了。
给今天的读者留几条可迁移的判断。其一，评估任何”标准提案”时先读状态字段——Final、Draft、Withdrawn 三种状态的信息量比正文还大，拿草案当成熟方案是跨生态踩坑的常客。其二，链上访问控制的性能形态是”逻辑内置于资产合约”，“可组合的独立权限合约”更多是理论优雅；写合规资产时把限制实现在合约内部、用 TZIP-016 元数据登记事实，才是主流路径。其三，若今天有人向你兜售”兼容 TZIP-015”的服务，第一句该问的就是：该提案 2020 年创建、最终撤回，你在撤回标准上建了什么、怎么维护。
把机制再往收藏场景推一步，能看到限制接口的普遍形态其实没有消失，只是换了住处。白名单空投合约里的 merkle 证明校验、邀请制藏品的授权名单、合规转让的许可注册表，都是”断言式检查”的近亲：转账入口先问一个只读的判定逻辑”此人此刻可不可以”，可以才提交状态。TZIP-015 的断言-名单-补丁三件套（每次转账带断言、状态用增删编号的补丁批量更新、更新操作可交换以便并行提交）在概念上仍值得借用——学的是它的接口品味，而不是照搬它的部署拓扑。读旧提案的正确姿势大抵如此：状态行告诉你别用它，设计细节告诉你这类问题被怎样认真思考过。
本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。