链下发通行证，链上验签名：ERC-7272 Ethereum Access Token 流程

用 NFT 做门票的项目都会遇到同一道选择题：把资格写进链上登记册，就要永远维护它、并为每一次状态误配担责；写死白名单，又满足不了临时性与隐私性要求。ERC-7272 给出第三种：链下按需签发一份签名的“以太坊访问令牌”（EAT），用户带着它上链敲门的瞬间完成验证。2026 年 9 月 9 日在 ethereum/ERCs 仓库核对，该标准状态为 Draft，2023 年 7 月 3 日创建，依赖 EIP-712。

一张 EAT 的结构

EAT 本体只有四个字段：签名三元组 v、r、s 和一个 expiry。签名走 EIP-712 类型化数据哈希，签名内容为两个嵌套结构：AccessToken（有效期加一次 FunctionCall）与 FunctionCall（functionSignature 函数选择器、target 目标合约、caller 预期调用者、parameters 除签名字段外的 calldata）。有效期填 unix 时间戳，预期早于 block.timestamp。换句话说，通行证从签发那一刻就被焊死在“哪个账户、在哪个合约、调哪个函数、带哪些参数、什么期限内”这五要素上。

链上验证核对六件事

参考实现分两个合约：需要门控的合约继承 AccessTokenConsumer，把 EAT 转交 AccessTokenVerifier 复核。验证逻辑逐项展开：调用的函数是否预期（比对 msg.sig 与 functionSignature）、参数是否一致、调用者是否 msg.sender 与 caller 相符、时间窗是否在有效期内、目标合约是否预期合约、签发签名者是否列在受信发行人集合里——全部通过才放行。EIP-712 域分隔符保证签名绑定具体链，防止跨链重放；参考实现还承诺单次使用语义，其他实现可自行取舍。

它相对链上登记册换来了什么

标准文本把动机写得坦率。资格判定需要短期与灵活时，更新 EAT 的颁发条件不必动链上任何合约；链上登记册的模式把“保持永远正确”的运维重担压给登记方，一旦链下资质与链上状态脱节，错误窗口就可能被利用——EAT 反转为“用户来问”，发行人签发前先跑一遍最新检查。涉及敏感或个人身份的资格条件时，链上公开查询天然泄露信息，EAT 把 PII 留在链外。它也不与灵魂绑定代币语义混用：资格不必沉淀为一种可转让的资产。

把验证清单翻成用户语言

合约替用户做的六项核对，对应着用户自己也能问的六个问题：我要调的函数和通行证上写的是否同一个（functionSignature 对上函数选择器）；参数被中途换过没有；这张证是发给我的还是发给别人转手给我的；这张证的有效期是不是已经翻篇；目标合约地址和签发时写定的那家是否一字不差；签发者是不是项目受信列表里的那把钥匙。全部答案都编码在那对 AccessToken 与 FunctionCall 结构里，EIP-712 的哈希绑定让它们彼此锁死，改任何一项签名即废——这比普通“登录签名”只签一条文本消息要强得多，因为它签的是一次具体的执行意图。与 JWT 的相似性止步于“短期授权凭证”这个概念层：JWT 面向服务器验证，EAT 为链上 ecrecover 而生，标准文本把选型理由列了三条：免登记册的运维重负、隐私数据不上链、比零知识证明更简单可审计。风险也照例对称：私钥若从签发服务泄露，攻击者就能以“合法格式”签出任一时点的通行证，这类系统的强度上限等于签发方密钥管理的水准，签名格式本身不加分。落地观察同样简单：截至核验时，公开钱包对 EAT 的展示适配尚未成为标配，若项目号称“凭 EAT 通行”，用户仍应在授权前确认弹窗消息体里的 FunctionCall 四要素是否与自己此刻的操作意图一致，这条自查不依赖任何基础设施成熟度。

读者视角的核对清单：收到“凭签名通行”类流程时，先确认弹窗签的是 EIP-712 结构化消息、核对域内的 verifyingContract 与 chainId；使用期限一过，同一张 EAT 立即失效，无法续命；签发方私钥的保管水平决定整套模型的可信度——EAT 不会比发它的服务更安全。标准仍是 Draft，接口以仓库文本为准。本文为协议机制科普，不构成任何投资建议；标准内容以 ethereum/ERCs 仓库文本为准（核验时间 2026 年 9 月 9 日）。