ERC-2520：一个域名只想存一个内容哈希，够吗

用 ENS 名字访问分布式网页时，浏览器或钱包要先问一句“这个域名的 contenthash 是什么”，再决定去 IPFS 还是别处取内容。麻烦在于，经典规范里一个名字只有一个 contenthash 记录——站主被迫在托管系统之间二选一。ERC-2520 在 2020 年 2 月 18 日提出把单选改成多选：同一个 ENS 名字可以按协议类型各存一份哈希。按 ercs 仓库记录，这份提案状态为 Stagnant，它建立在 ERC-1577 之上，属于典型的“兼容优先”小改。

加一个参数，改两个函数

规范用强烈的 MUST 措辞规定：设置和获取 contenthash 的函数必须保留 ERC-1577 的原接口，同时必须新增带 proto 参数的重载。setContenthash(node, proto, hash) 把哈希按协议类型归档，不提供 proto 时存为默认记录；contenthash(node, proto) 按类型取值，不指定时返回默认记录。支持多记录的解析器必须在 ERC-165 的 supportsInterface 里对接口 ID 0x6de03e07 返回 true。实现骨架也简单：一个从节点到协议再到哈希的双层映射，加一次事件发出。

两类应用各查各的

标准给应用划了行为建议。只支持单一托管系统的应用——比如直接走 IPFS 网关的——应当带具体 proto 查询，拿到的必然是自己能处理的格式；同时支持多系统的应用（标准原文点名了钱包类工具）应当像 ERC-1577 时代一样不带类型查询，拿默认记录。这套双轨设计的重点在向后兼容：老应用不改一行代码，继续读到默认哈希；新应用先探测接口，再决定按类型取数。一个协议类型对应一个哈希，同一类型多份记录和优先级排序被明确排除在外，理由是实现收益小、复杂度高。

值得停下来想的一层

这份提案表面在解决“一个域名挂几份内容”，实际上暴露了命名系统与托管生态的关系问题。内容哈希指向的是内容本身的可寻址指纹，同一份网站内容在 IPFS、Swarm 等系统里可能各有表达；多记录等于给名字买了一份“不把鸡蛋放一个篮子”的保险，也顺手记录了站主认可的托管优先级之外的现实：多个入口。但要多想一步：各入口的内容是否同步更新、会不会出现一侧被改了另一侧没改的裂缝，标准并不保证——它只管“怎么取”，不管“取得到的是同一份”。这恰是所有多入口设计的共同软肋，和跨链资产映射的口径问题同构。

检查你的域名时用得上什么

普通用户层面，这份提案可以变成几条具体动作。给自己 ENS 名字做过分布式托管的读者，值得去解析器管理页确认默认记录与按类型记录是否一致，改内容时别只更新一个槽位，否则带类型查询的新应用与只读默认值的老应用会看到两个版本的“你的网站”。读取别人名字的读者，如果同一个 ENS 名在不同工具里打开是不同页面，第一反应应是检查 proto 口径差异而不是立刻判定被劫持。提案状态虽是 Stagnant，ENS 生态对多托管的讨论并未消失，把它当作理解 contenthash 记录结构的切片读物仍然合格。

与相邻标准的边界感

这份提案只动 contenthash 一个维度，读的时候值得把它在 ENS 族谱里的位置标清楚：contenthash 的记录格式与编码由 ERC-1577 定义，接口探测规则由 ERC-165 提供，而 ERC-2390 这类地理扩展走的是另一条路线。多内容哈希、多文本记录、多资源类型这些想法彼此正交，理论上可以叠加，实际演化里 ENS 团队自己的实现选择才是主线，提案状态与落地程度应当分开核验。这也提醒所有读标准的人：一个名字能挂多少种记录，取决于解析器合约实现了哪些接口，而不是提案列表有多长。给自己域名配置前，用 supportsInterface 逐一探测比读十篇攻略可靠；访问别人的名字时，理解工具与解析器之间是接口对话关系，遇到显示差异先想口径，再想安全。

本文为机制说明，不构成任何投资建议。