地址也能反过来问出名字：ERC-181 的 addr.reverse 与权威反向记录

钱包把 0x71C7... 显示成某个 .eth 名字，看起来像是“查了查这个人叫什么”，但正向解析有个天然的信任漏洞：任何人都可以在自己的解析器里把任意名字指向任意地址，包括把你的收款地址挂到名人名字下面。ERC-181 解决的就是这个方向问题。这份标准创建于 2016 年 12 月 1 日，仓库记录状态为 Final，摘要说得很直白：解析器可以确信反向记录是由该地址的所有者发布的。动机部分列的使用场景也很实在：监控账户的应用想把用户按地址加进来的账户显示成名字；给地址挂描述性元数据后，无论地址最初是怎么被发现的，信息都能取回；以及最核心的一条——任何人都能把名字指到别人地址，所以只有反向记录能让地址主人把一个名字声明为对己权威。

反向记录存在哪里

规范把反向记录存进和正向完全相同的层级结构，只是保留了一个专属顶级域 addr.reverse。生成某个账户的反向名字的方法是把地址转成小写十六进制再拼上这个后缀：原文举例，地址 0x112234455c3a32fd11230c42e7bccd4a84e02010 的反向记录存在 112234455c3a32fd11230c42e7bccd4a84e02010.addr.reverse 这个名字下。这个写法带来一个工程细节，规范特意提醒：想在合约里动态查询任意地址的反向记录，合约必须自己完成十六进制编码，把地址变成字符串再算节点，不能指望登记表替你转换。

谁能立这条记录

addr.reverse 域的所有者是一个注册方合约，它提供两个入口。claim(address owner) 由账户 x 自己调用，指示登记表把 hex(x) + '.addr.reverse' 这个名字的所有权转给指定地址，并返回 namehash。owner 参数允许指向别人，原文解释这是为合约准备的：一个合约账户可以在构造函数里写一行 reverseRegistrar.claim(msg.sender)，把自己的反向记录委托给创建者管理。claimWithResolver(address owner, address resolver) 则一次完成“设置解析器加转所有权”，比分开调用省一笔交易。

还有一个直接改名的入口 setName(string name)：由账户调用，把这个名字的反向解析结果直接设为给定字符串，并在需要时创建对应节点。附录里的参考实现补上了最后一块拼图——默认反向解析器的 setName 带 owner_only 修饰符，写这条记录的钥匙始终攥在节点所有者手里，注册方只是代管路由。

关键在调用者身份：只有地址本身（或其控制者）能触发这条记录的产生和转移。这就是“权威”的来源——正向记录是别人贴的名片，反向记录是自己签的收条。

解析器怎么回答问题

反向记录这边的解析器接口只有一条：function name(bytes32 node) 返回一个字符串，要求要么给出一个有效的 ENS 名字，要么在没有任何名字被定义时返回空字符串。规范给这个接口分配的标识是 0x691f3431，工具可以用 ERC-165 那套探测方式先问解析器“你支不支持反向答名”，而不是调一把碰运气。规范同时留出余地，未来可以为本提案补充更多适合反向记录的类型。

钱包显示名字时到底查了哪边

把两本账放在一起，能澄清几个高频误解。第一种误解：看到转账确认页显示对方是个 .eth 名字，就认为对方“拥有”这个地址对应的名字——如果这个展示走的是正向解析，它只证明有人把名字指过来，不证明地址主人认可。第二种误解：地址主人改了反向记录，别人存的联系人列表自动更新——反向记录同样是链上状态，受缓存和快照影响，工具读到的可能是旧值。第三种误解在合约里：规范明确动态反查要在合约里做十六进制编码，编码环节大小写或长度处理不一致，查的就是一条不存在的路径。

对普通用户，可靠的读法是两步都做：正向问“这个名字指向谁”，反向问“这个地址声称自己是谁”，两边一致才当作同一个身份。ERC-181 的存在就是让第二步有标准答案可查；它不保证名字本身是好名字，也不给任何地址赋予额外价值。本文为机制说明，不构成任何投资建议。