EAS 链上记录存在却不获资格:核对schema、期限与撤销
链小知 · 进阶 · 核验 · 依官方文档整理
对照本人已有链上证明和schema记录,把UID存在、状态与应用资格分别判断,避免误读isAttestationValid。
开始前准备
- 准备原chain/EAS地址/部署版本、UID、getAttestation/schema记录及原交易/读取时间;不请求RPC或浏览器样本。
- 方法以SDK2.10.0固定源码和合约1.9.0固定读函数为边界,实际部署可能不同。
1. 锁定链、EAS地址与UID而非交易hash
用原chain/EAS合约地址/UID定位已有getAttestation记录;UID不是创建交易hash,schemaUID又是另一个标识。仅有链下文件不能按同名UID推链上已有完整data。
原交易或已存Attested记录还需与正确EAS地址/版本对应,不能拿另一链或另一合约的记录合并。读取失败、零UID和字段未取得分别保留。
检查结果:原记录绑定同一链/EAS/UID,标识与存储层不混用。
2. 把UID存在与状态有效性分开
所读固定合约1.9.0 isAttestationValid只判断_db[uid].uid非EMPTY_UID;返回true不能证明未过期、未撤销或应用允许。SDK方法转发给合约,所以实际部署版本需另核。
固定SDK依赖合约包1.7.1,与本次读取的repo1.9.0并不相同;不要将仓库当前版本当某地址已升级。零记录/错误无法充作有效证明,缺版本时只解释原字段不保证对应实现。
检查结果:存在标记、部署版本、状态和资格各自单列。
3. 用原registry记录核对schema和解码范围
原SchemaRecord包含uid、schema字符串、resolver和revocable;schemaUID取决于字符串、resolver地址和revocable,不能仅按相同字段名或名称替代。getSchema遇零UID会抛Schema not found,失败不是空schema。
按同一schema类型/顺序看已有SchemaEncoder.decodeData结果与原data。解码异常、缺schema和错误精度保留;成功解码只给结构,不验证发行方、内容真实性或resolver已经接受本次操作。
检查结果:schema身份、类型/顺序和原解码有对应,缺值没有补默认内容。
4. 按原时间与撤销字段判断状态
time和expirationTime是原Unix时间记录;expirationTime=0表示无到期,不是1970年即失效。非零期限与该次读取/判断时刻比较,毫秒日志不能不换单位直接比较。
revocationTime非零是已有撤销时间记录,revocable仅说明能否撤销。SDK isAttestationRevoked对零UID抛Invalid attestation;缺回执或查询失败不写未撤销,过去未撤销也不证明现在状态。
检查结果:原期限、参照时间及撤销结果有范围,缺状态明确。
5. 核对attester、recipient与应用规则
从原getAttestation取attester和recipient、schema/refUID/data,对照应用认可的发行者、接收对象与证明类型。任何人能对事实作声明不意味着某应用都接受;refUID的存在也不自动给被引用内容真实性。
timestamp、ABI解码和UID存在分别是证据层,不直接授予会员、领奖或治理权。若应用要求其他证明/日期/状态而资料不够,写规则或受信配置待核,不尝试claim或换issuer。
检查结果:应用为何认可该证明有独立依据,结构正确未被写成资格完成。
6. 形成有时点的证据表而非恢复动作
逐栏整理链/EAS/version、UID、schema/issuer/recipient、已观察期限/撤销与应用判断;结论可为记录存在但状态不合、schema/发行方不符或资料不足。
链下原文件、链上timestamp、撤销mapping及完整链上attestation各自保留。无链上读/执行验收时不承诺当前可用、恢复或零费用,也不发新attest/revoke来排错。
检查结果:结论对应原时点与具体字段,无动作验收范围清楚。
怎样确认完成
- 输出同链合约版本的UID/schema/状态/可信身份与资格对照。
- 未查RPC、部署、发行、撤销或领取,当前未知状态未补造。
常见错误与边界
- isAttestationValid在所读实现仅UID存在,不能当未过期/未撤销判断。
- revocable与revocationTime不同;0到期与缺到期不同。
- 解码成功、受信发行者和应用资格需要分别核证。