contenthash 用协议编码开头：ERC-1577 如何废掉 content 与 multihash 两个字段

名字服务给一个名字挂“内容地址”这件事，早期其实先后有两套写法：一个叫 content，一个叫 multihash。ERC-1577 用一条新字段把这两个都作废了，理由是用协议编码开头，允许清楚定义内容到底存在哪种网络、怎么解。这份提案的文件头记录创建于 2018 年 11 月 13 日，仓库记录状态为 Stagnant。

字段与接口标识：先有“必须支持则必须申报”

规范规定：支持 contenthash 字段的解析器，在被调用 supportsInterface 并以参数 0xbc1c58d1 查询时必须返回真。这个要求看似平淡，实际把“有没有这个能力”变成可以链上直接问出来的事实——客户端不用猜，也不用查文档。同时，content 与 multihash 两个字段被明文弃用。

字节串的构成

contenthash 的返回值必须是机器可读的 multicodec 形式，格式写为协议编码的 uvarint 加上内容地址字节数组。协议编码及其含义在 multicodec 仓库里维护，不在这份提案里发明。

对最常用的两种网络还有更细的规定：协议编码为 0xe3 的表示 IPFS 内容，0xe4 表示 Swarm 内容，这两类的值要求按不带基前缀的 v1 CID 编码，也就是在协议编码后面继续拼上 CID 版本、内容类型的 multicodec、以及 multihash 格式的内容地址。

规范给了两个可以逐段核对的例子。IPFS 那条，输入信息写明了存储系统 0xe3、CID 版本 1、内容类型 dag-pb 对应 0x70、哈希函数 sha2-256 对应 0x12、摘要长度三十二字节，二进制形式是 0xe3010170122029f2d17be6139079dc48696d1f582a8530eb9805b561eda517e22a892c7e3f1f，对应的文本形式是 ipfs:// 开头那串。Swarm 那条则用 0xe4 开头，内容类型是 swarm-manifest 对应 0xfa，哈希函数是 keccak256 对应 0x1b，文本形式是 bzz:// 开头。

对读的人来说，这两条例子把抽象格式变成了体检表：拿到一条 contenthash，头一个字节就知道是哪种网络，往下能逐步拆出版本、类型、函数、长度。规范对解析行为也定了硬要求：应用必须用协议编码判断里面装的是哪种地址，并按对应协议正确解析；不支持该协议就应该报错，而不是把整串当指针去猜。

宽限期条款与它的历史位置

规范末尾有一段“回退”条款：为照顾已经把 IPFS 或 Swarm 哈希写在 content 字段里的老名字，必须实施一段宽限期——解析器不支持 multihash 接口时，必须再检查其是否支持 content 接口，支持的话按上下文处理该字段的值，并且这一要求至少在 2019 年 3 月 31 日前必须执行。这是典型的规范过渡带设计：与其指望所有人同一天改，不如规定一个明确的共同截止线。

顺带一提，这份提案还列出了一种用命令行工具从 Swarm 哈希直接算出 contenthash 字节的做法，以及 JavaScript 与 Python 的编解码库。这些工具让“解码一条 contenthash”变成几行代码的事，也意味着任何声称忠实实现该标准的客户端都应该给出同样的解码结果。

三条常见误读

拿到一串 contenthash，容易犯的错有三类：只解开头协议码就断言内容可用，忽略了协议码之后的字节解到哪算哪、网关在不在；把 0xe3 一律当作今天常见的某种链接写法，而不核对协议码之后的 CID 版本与内容类型段；以及把链上字段的存在当成解析器能力的证明——规范用 supportsInterface 的申报要求回答的正是这一点，没申报能力的解析器即便字段值在也读不出来。三条都指向同一个动作：逐段解码、先问能力、再试访问。

与 NFT 元数据字段的接口分工

ERC-1577 的字段挂在名字解析器上，与 NFT 元数据里的存储指针解决的是同一类问题的不同层：元数据里的链接指向内容，contenthash 让“名字指向站点”变得自描述。两者都不是内容本身，也都不承诺可访问性。当有人把一枚 NFT 的“官网”做成一个 ENS 名字，真正需要核对的链条是：名字指向哪个解析器、解析器上挂的什么网络编码、那个网关现在还在不在。任何一环换掉，页面就换了，而名字看起来一模一样。这份标准在仓库中的状态是 Stagnant，说明它作为独立文档停滞，但它规定的编码思路被后来的实现沿用——读它时以“规定什么”为主，把“有没有人部署”留给链上查证。本文为机制说明，不构成任何投资建议。