ERC-7574：登录成功发一枚不可转让的 SBT

钱包登录网站靠签一条消息，这叫“证明你控制这个地址”，不叫“证明你是谁”。把后者也搬上链的一条路线，是 ERC-7574（2023 年 11 月 2 日创建的 Draft 提案）描述的机制：用户先以去中心化身份（DID）完成认证，合约用零知识证明验证“此人持有某项可验证凭证”而无须知道凭证内容，验证通过后向该地址发放一枚不可转让的灵魂绑定代币，后续服务把读取这枚 SBT 当作访问控制的钥匙。

认证、验证、发证三步

标准把链路拆成三段。认证段发生在链下：身份提供方按 W3C 的 DID 与可验证凭证体系向用户签发凭证，比如某个资质、会员资格或实名断言，凭证本身存在用户端。验证段在链上：合约按 verify 逻辑核对用户提交的零知识证明——证明只回答“我持有的凭证满足条件吗”，不泄露颁发者、编号或个人字段；接口还定义 issueSBT 完成签发、updateTokenURI 处理凭证元数据变化。发证段就是那枚 SBT：不可转让保证它无法被卖号者打包带走，服务方检查 ownerOf 一类的持有关系即可放行，把反复的认证成本摊薄成一次性的链上记录。

和 SIWE、EAS 们的分工

别把这条路线和邻近方案混起来。ERC-4361 的 SIWE 只做会话登录，签完即弃，链上什么都不留；ERC-8063 用一张 ERC-20 表达群组资格，判定靠阈值聚合；链下声明服务如 EAS 把断言登记在注册表里，读取方仍要多方询问。ERC-7574 的差异是把“登录态”铸成资产级的对象：资格有地址锚点、可被任何接入合约复用，同时靠零知识证明确保发证时不留隐私脚印。代价也在这里——证明系统可信设置、验证合约的漏洞风险、以及 SBT 一经发放即长期存在的暴露面：一枚地址上的 SBT 本身就在向链上观察者宣布“这个地址通过了某种认证”。

落地时的核验与风险点

如果某个服务用 ERC-7574 式 SBT 做门禁，用户可以检查三处：发证合约里的验证器指向哪个证明系统、由谁部署与升级；你的 DID 凭证的颁发者是谁——SBT 上链不会给劣质凭证镀金，垃圾进垃圾出；撤权机制在哪——标准允许撤销或到期，但真实实现可能只留 updateTokenURI 的壳，没有失效通道的认证代币等于把旧资格永久刻进链。服务方则要注意反面的指纹问题：发证合约若记录用户提交的证明原文或公开输入，同一凭证在不同地址的重复出现会形成可关联信号。链上登录体验确实顺滑，但顺滑不降低合规与隐私评估的必要性。本文只做协议机制科普，不构成投资建议。

撤权通道如何设计才算数

SBT 式登录凭证最棘手的问题不是发证而是收证。理想的失效链路有三层。链上层给合约留撤销函数或到期时间，标准示例的 updateTokenURI 只能改展示元数据，权限撤销需要显式状态位或依赖标准外的销毁路径，实现文档必须交代清楚。登记层处理 DID 与凭证：凭证状态列表或撤销注册表被更新后，SBT 不会自动消失，服务方要么每次读取登记状态，要么接受缓存带来的失效延迟，两种选择都有成本。最后是行为层：地址把带 SBT 的私钥丢了或被盗，上述机制都帮不上，用户可主动 unequip 或调用项目方自设的作废接口自保。评估一个认证 SBT 系统时，依次问“撤销走哪条链上路径”“登记层延迟多久”“用户自救入口在哪”，三问都有明确答案的系统才算闭环；只答得出前两问的，本质上把注销权寄存在了运营后台。

一次登录链路的完整时序

把整条链路过一遍：用户先完成 DID 认证拿到链下凭证，登录时生成零知识证明，调用合约 verify，通过后 issueSBT 铸币上链，此后访问任何接入合约只需检查持有关系。值得玩味的是费用结构——首次登录承担认证与铸币双重成本，后续访问降级为一次只读查询，体验的顺滑完全建立在前期把身份固化为资产的前提上。这也解释了为何该路线更适合长周期、多服务的资格场景；一次性活动若照搬，用户付了铸币成本却只用一次，反而不如传统会话方案经济。