web3 网址里的 ENS 名字：ERC-6821 怎么把域名换成合约

在支持 web3:// 协议的浏览器里，一个网址可以不指向服务器，而是直接指向某个合约的函数调用。网址里写合约地址太长太吓人，写 ENS 名字则好记得多——但”名字换成地址”这一步按什么规则来？ERC-6821（Support ENS Name for Web3 URL）就管这一件事，状态为 Draft（草案），创建于 2023 年 4 月 2 日，依赖 ERC-137、ERC-634、ERC-3770 与 ERC-4804。本文按标准讲解析规则，不构成任何投资建议。

三步解析顺序

按规范，给定 web3:// 网址里的合约名与链号后：第一步，在对应链的 ENS 解析器上查该名字的 contentcontract 文本记录，查到合法地址就用它；第二步，记录不存在时退回 ERC-137 的通用解析，取名字解析出的地址；第三步，解析结果是零地址则报”未找到地址”错误。补充规则：contentcontract 里也可以写一条 ERC-3770 链特定地址，此时网址声明的链号会被记录里的链号覆盖——域名持有人借此把访问者引到另一条链上的合约。

为什么值得做这件事

ERC-4804 的原始动机是”像访问网页一样调用合约”。名字到地址的映射如果每个客户端各猜各的，同一个 ENS 名字在不同钱包里可能解出不同合约，这正是仿冒页面最爱的缝。ERC-6821 把映射规则标准化：读一条写在 ENS 上的文本记录，公开、可改、带 TTL，谁都能复核。

对 NFT 用户的两面性

正面：一个项目可以在 ENS 的 contentcontract 上公示官方合约地址，用户解析一次即可长期校验网页里加载的合约是否同一枚地址，仿冒合约页面会当场对不上。反面：链号覆盖机制意味着”我点开的链”与”实际调用的链”可以不是一回事，跨链部署不熟练的用户可能被引到预期外的网络；同时标准状态是 Draft，浏览器与钱包的执行一致性没有承诺，不能把它当已生效的通用安全层。

实操要点

1. 遇到 web3:// 网址先核对 ENS 名字拼写——域名抢注的把戏在链上同样成立。
2. 对解析结果多做一步：拿解析出的合约地址与项目官网、官方公告公示的地址逐一比对。
3. 留意链提示：若记录带 ERC-3770 链前缀，确认自己当前所在网络与最终调用链是否一致。
4. 标准之外的展示文字（网页标题、图标）都不构成合约身份证明，认地址不认装修。

contentcontract 记录长什么样

这条文本记录有两种合法写法：直接写一枚带 0x 前缀的以太坊地址，或者写一条 ERC-3770 风格的链特定地址（形如”链前缀:地址”）。选后一种时，网址里原本声明的链号会被记录里的链号覆盖——设计理由是让人类可读：整个映射用文本记录而非二进制哈希表达，还能附带 TTL 之类的缓存字段。对运营方，这意味着”我们的官方合约在几条链上分别是哪枚地址”可以集中公示在一处 ENS 记录里，改地址只需更新记录；对普通用户，这条记录的修改历史（通过 ENS 事件）本身也是可审计的时间线。

与 ERC-4804 的分工

值得把两层标准分开看：ERC-4804 定义 web3:// 网址本身如何表达一次合约调用（路径里带函数与参数），ERC-6821 只负责其中”名字换地址”这一步。也就是说，即使浏览器完整支持前者，没有统一解析规则时名字型网址仍然各家自行解释；ERC-6821 补的正是这块引用缺口。同理，它也不保证网页渲染安全——web3:// 页面里的脚本、图片与文案照样可能撒谎，解析只回答”调用落在哪枚合约”这一个问题。

域名到合约的映射标准越统一，仿冒缝就越窄，但在解析实现普及之前，人工比对官方公示地址仍是底线动作；本文仅为机制科普，不构成投资建议。