一个地址能有一串名字吗：ERC-4834 层级域名接口怎么逐段解析

提到链上名字，多数人先想到 ENS。但 2022 年 2 月 22 日创建的 ERC-4834 层级域名（Hierarchical Domains）想做的是另一件事：不规定谁拥有 .eth，也不规定名字长什么样，只规定“任何一层名字系统都应该能被问两个问题”。该标准状态为 Final，思路接近 DNS 的树状委托：名字是一棵树，每个节点本身可以是一个合约。

两个函数的分工与解析方向

核心接口叫 IDomain，只有两个视图函数。hasDomain(string[] name) 问：当前这一层域名下，存不存在某个子域名？getDomain(string[] name) 答：把那个子域名的合约地址给我，如果 hasDomain 为假就应当直接回退。注意参数是一个字符串数组而不是一个整串，因为解析本来就是分段进行的。

解析规则是理解这个标准的关键，而且方向容易记反：对 a.b.c 这样的名字，解析器先拿到根合约，把最右边的段 c 放进路径，问根合约 hasDomain 只含 c 的数组；存在就 getDomain 得到下一层合约，再把 b 添进路径继续问，如此往复直到所有段用完，最后落到的地址就是名字指向。文档原话是“从右到左”（right to left order），和 DNS 查询把域名倒着写的习惯一致。嵌套层数没有上限，文档给了一个二十多层的名字作为合法示例。

可选扩展：注册、枚举与访问控制

基础接口只读，标准另列了三个扩展。可注册扩展 IDomainRegisterable 加 createDomain、setDomain、deleteDomain 三个动作，分别发出 SubdomainCreate、SubdomainUpdate、SubdomainDelete 事件，并配一组 canCreateDomain、canSetDomain、canDeleteDomain 之类的权限查询，说明“谁能动这一层的哪个名字”；可枚举扩展让合约能列出自己的子域名；访问控制扩展把“父域名决定子域名谁能改”的规则接口化。这套分工解释了它与 ENS 的定位差别：ENS 是一整套跑了很多年、带治理与续费的注册服务；ERC-4834 只把“树状解析与登记的接口形状”抽出来，任何人都能拿它搭自己的一小棵树。

安全考量：文档点名的两个坑

标准的安全章节值得普通用户也读一遍。第一个叫“黑洞子域名”：setDomain 把一个子域指向某个新合约后，如果那个合约的 canMoveSubdomain 实现恶意返回假值，原主人就再也移不动、删不掉这个子域——文档建议客户端在发现 canMoveSubdomain 或 canDeleteDomain 从真变假时发出警告，并且强调在给子域名换父级之前永远先审计对方合约源码。第二个叫“父域名解析”问题：合约在解析“我爹是谁”时可能拿到与直觉不同的结果，依赖父子关系做逻辑的合约需要显式核对。这两条的共性是：在树状名字系统里，转移指针的动作比创建指针更危险——名字还在那儿，控制权却可能已经回不来。

它和 NFT 有什么关系

标准本身不针对 NFT，但两类场景让它经常同框。一是账号与支付的命名路由：有实验用层级名字代替长地址做转账目标，逐层解析到钱包合约。二是域名与 NFT 的组合玩法——把域名铸成 NFT 的项目，底层往往需要一个可编程的名字系统；有了 hasDomain/getDomain 的统一问法，市场、钱包、索引器不必为每个命名项目单独写适配。要划清的边界是：接口统一不等于名字有权威。同一棵树之外的解析器根本不认识这些名字；把 ERC-4834 名字当收款凭据前，必须确认你和对方引用的是同一棵树的根合约地址。操作习惯上老规矩仍然有效：凡用名字发起转账，多复制一次解析结果、核对最终地址的十六进制，是零成本的保护。

接入前自查三问

接入任何基于 4834 的名字系统前，先问三件事：根合约地址由谁公布、会不会与仿冒树混淆；这一层的 canMoveSubdomain 实现是否经过审计、有没有黑洞风险；解析失败时前端如何提示。三问都有明确答案的名字系统，才值得写进钱包书签长期使用。 最后提醒：本文介绍协议接口，不构成投资建议；名字解析结果由对应合约决定，操作资产前请核对合约地址与项目身份。