撤销名单的公共登记处：ERC-5539 吊销列表注册表

证书、会员资格、活动票根这类链上凭证都有同一个软肋：签发容易，作废难。把 NFT 烧掉是一种作废，但很多场景不想动代币本身——只想公开宣布“这枚凭证已失效”。ERC-5539 的思路是建一张全网共用的吊销注册表：谁签发的凭证，谁在自己的命名空间里维护名单，任何人来查。提案在 ercs 仓库的状态是 Stagnant（停滞），创建于 2022 年 8 月 26 日，依赖 ERC-712 做签名参数。停滞意味着它不再活跃推进，读它更多是理解一种设计，而非接入建议。

三层结构与必答题

注册表把撤销状态组织成三层：namespace（命名空间，就是一个以太坊地址，代表签发方）、revocation list（名单，一个 bytes32 键，同一签发方可开多张名单）、revocation key（被撤销对象的键，同样是 bytes32）。三者组合解析出一个布尔：撤销与否。合约必须实现两条主干函数：查询侧 isRevoked(namespace, list, key)，写入侧 changeStatus(revoked, namespace, revocationList, revocationKey)。查询函数还可以同时尊重名单整体的状态——整张名单被作废时，里面所有键的状态可被一并处理。

委托、签名与批量维护

围绕主干，规范给了一族可选项。委托机制：名单所有者可以 addListDelegate 把名单交给委托人维护，委托人必须可被对应名单的所有者移除；委托人通过 changeStatusDelegated 改单个键，changeStatusesInListDelegated 批量改。签名变体：主干与委托函数各配一个带签名参数的版本（如 changeStatusSigned），允许离线签好授权、由他人代发交易，省去维护者自己付 gas。名单侧还有所有权函数 changeListOwner 与名单自身开关 changeListStatus，事件 RevocationStatusChanged 等把每次变化记入日志。对签发方，这套组合解决的是运维现实：值班同事、第三方审计机构都可以是委托人，出了事批量吊销，不用转移名单所有权。

与可撤销 NFT 的配合

链上可撤销资产常用两种作废路线：代币侧内建（如 ERC-5484 的销毁凭证，或 ERC-6492 场景下的标志位），或者旁挂一张外部名单。ERC-5539 属于后者的通用件：NFT 合约验证时顺手调 isRevoked，被登记作废的凭证即使代币还在钱包里，也应被合规逻辑拒绝。读的一侧要点是口径：名单是注册表数据，代币是链上余额，两者可以不一致——“我钱包里还有这张票”与“这张票还有效”是两个问题，以验证方的名单查询为准。

名单数据的隐私边界

吊销名单天生是公开账本：任何人都能查某个键是否被撤销，这本身是信誉机制的要求——秘密作废等于没作废。但公开性也带来暴露面：bytes32 键如果直接取自用户地址、邮箱哈希这类可关联材料，等于把“谁被撤销”广播给了全网，敏感场景需要先把键做不可关联处理（例如随机盐与哈希组合），再公布盐的披露策略。规范把键抽象为 bytes32 而不规定来源，就是留给各方自己设计。核验方同样要注意查询成本：三参数查询一次只问一个键，批量核对要发多次调用或用批量查询变体；名单维护方是否开了委托与批量函数，直接决定事件里有没有 changes 这类批量日志可跟。把 ERC-5539 当阅读材料还有个额外收获：它展示了撤销类系统的三个永恒问题——谁有权改、改了什么能不能追溯、作废信息如何在不泄露身份的前提下公开——这三个问题在任何一套链上凭证设计里都值得再问一遍。

再给一个运维视角：委托授权是时间性的，机构改组或人员离职后名单权限要例行回收，定期审计委托关系比一次性设好更符合这张表的设计意图。

最后提醒：Stagnant 状态的作品在主流工具中支持有限，任何把它当作核验依据的系统都应清楚自己依赖的是一份未定稿设计，名单本身的中立性（谁部署注册表、是否可升级）也需要单独评估。本文为机制说明，不构成任何投资建议。