ERC-8143 智能凭证解析：一个地址怎么像查网址一样查自己的 KYC 和信誉

验证服务接了一百个合作方，每个的凭证查询格式都不一样：这家要调专用函数带地址参数，那家要访问带签名的私有接口。ERC-8143（Smart Credential Resolution Interface）想把查询动作统一到一个函数上：getCredential(key)，键描述你要什么凭证、关于谁，返回一段字节。按以太坊 ercs 仓库的记录，这份提案状态为 Draft，创建于 2025 年 12 月 15 日，接口标识为 0xd091187f。

一个函数与一类重要区分

接口小得反常：一个 view 函数 getCredential，加一个在设置或更新凭证时广播的 CredentialSet(key) 事件。事件的价值在发现性——包括 AI 代理在内的客户端无需预知键的存在，监听事件就能知道”这位发行方新挂了什么凭证”。标准举的键写法借鉴了 ERC-8119 参数化键格式：kyc:0x76F1Ff… 表示关于该地址的 KYC 凭证，pop:0x76F1Ff… 是 Proof of Personhood，reputation:0x76F1Ff… 是信誉记录，键格式本身不作强制。

定义处有一句容易被略过、却决定这套东西性质的话：凭证是”关于”用户的记录，由发行方控制——区别于用户直接掌控的记录。KYC、KYA、人格证明、信誉分，都是第三方对某个主体的陈述。所以 8143 标准化的是查询管道，不是所有权模型：它不承诺你能导出、修改或撤销发行方写下的凭证，那些能力取决于发行方合约自己的实现。

链上存还是链下存，同一接口两种身体

返回值是不定形 bytes，发行方应文档化自己的格式——可验证凭证、ABI 编码、JSON 都可能；客户端没有已知格式时按原始 UTF-8 兜底解析。更有意思的是存储位置的选择权：凭证可以整段进链，也可以整段放链下、由合约指路。当 getCredential 判断数据在链下时，合约按 ERC-3668 协议回滚一个 OffchainLookup，带回收取地址，合规客户端自动发起网关查询——相当于 URL 重定向的链上版本。标准同时提醒：某些库默认不处理 ERC-3668 回滚，集成方要显式启用，否则一次正常的”指路”会被误报成调用失败。

给三类读者的使用姿势

网关回滚的完整一跳

ERC-3668 那半个协议值得单独走一遍，因为它是”链下数据、链上验证”体验的关键一跳。客户端调用 getCredential("kyc:0x76F1…")，合约发现凭证不在链上存储，于是 revert 一段 OffchainLookup 错误，错误数据里编码着网关 URL 模板和调用方自己的 calldata；合规客户端把原 calldata 拼进 URL 模板发一次 HTTP 请求，网关返回 ABI 编码的结果——按协议这结果要么就是凭证字节本身，要么是另一段 calldata 让客户端回链上再调一次指定合约；客户端拿返回的字节重放验证，确认解码结果与 revert 时承诺的回调哈希一致，才算完成解析。这条链路的安全性质要讲透：网关回答快且省 gas，但网关是你新引入的链下信任点，它作恶可以返回与登记不符的内容——所以标准才把凭证内容格式的定义与签发责任压回发行方合约的哈希与签名上，链上哈希始终是裁判。对不想折腾网关的集成方，退路是用支持 ERC-3668 的 RPC 或显式开启该特性的调用库，把整套流程当成一次带自动重试的调用；若你的库根本不处理这种 revert，第一次集成十有八九把正常指路误报成合约故障，这一步的排查成本比想象中高。

对钱包和 dApp 开发者：先用 ERC-165 探测 0xd091187f 确认对方真按标准实现；解析流程固定为带 ERC-3668 处理地调用 getCredential，再按发行方公布该键的格式解码——格式没公布就把返回当原始字节，等于没读懂凭证。对普通用户：链上出现一条关于你地址的凭证，不等于授权发生，凭证是”别人对你的描述”，读它无需签名，任何声称”收到凭证就代表你同意了什么”的界面话术都值得警惕。对代理系统运营者：CredentialSet 提供的发现机制让代理能自动跟进新凭证，但也意味着监听者会持续追踪发行方的键名变化——把键当稳定 API 设计的项目才配得上自动集成。本文为机制说明，不构成任何投资建议。