IPFS 指纹怎么塞进名字记录：ERC-1062 的 Base58 与十六进制互转

想把一个去中心化网页的入口做成一个好记的名字，需要两样东西：内容自己的指纹，以及一个能查指纹的名字。ERC-1062 是较早尝试把这两样拼起来的一份提案，文件头记录创建于 2018 年 5 月 2 日，仓库记录状态为 Stagnant。它做的事说起来只有一句话：把 IPFS 的文件指纹登记到名字服务的公共解析器里，让名字可以解析出内容地址。

问题的实质是两种编码对不上

这份规范的正文相当短，核心矛盾摆得很直白：IPFS 的文件指纹用 Base58 字符串表示，而以太坊在接口里用十六进制表示二进制数据。要让 IPFS 指纹进链，得先把 Base58 解成二进制缓冲，再把缓冲写成十六进制存进合约；反过来读的时候，把十六进制抽出还原成二进制缓冲，再转回 Base58 字符串。二进制缓冲是中间那座桥。

落到合约层，它要求公共解析器提供两个函数：setMultihash(bytes32 node, bytes hash) 用于写入，转换好的十六进制形式从这里进链；multihash(bytes32 node) 静态查询，把链上的十六进制取出来，由调用方转回 Base58 再取内容。两个函数都以名字服务里的节点为键。

换算交给库，不交给想象力

规范没有要求各家自己写 Base58 算法，而是指向 multihashes 这个库，并给出两段示例：正向从 IPFS 哈希字符串出发，先解成缓冲再写成带前缀的十六进制；反向把十六进制串去掉前缀后解回缓冲，再输出 Base58。规范测试部分的重点也在这对互转的正确性上——它整篇的“测试用例”其实就是这条转换链。

这里有一个容易被跳过的概念：multihash 不是单纯的哈希值，而是一个自带元信息的编码结构，里面标着用了哪种哈希函数、摘要多长。也就是说链上存的那串字节理论上是可自解释的。这份提案没有展开 multihash 结构本身，只是借用它作为承载格式。

被后来者取代的原因，在另一份标准里写得很清楚

单看 ERC-1062 会好奇：为什么今天谈名字服务内容记录时提到的是 contenthash 而不是 multihash？答案在 ERC-1577 里。那份提案引入了 contenthash 字段，并明确把 content 和 multihash 两个字段列为弃用——理由是各类应用对“内容和网络地址”的表示需要一个更清楚定义的方案，而 contenthash 用协议编码开头，允许一条记录同时说清楚“内容存在哪种网络、按什么格式解”。

把这层演进关系理清，能避免两个常见误读。第一，链上历史数据里确实存在用 multihash 槽位写的旧记录，遇到解析器不支持新字段时，工具需要按另一份提案说的宽限逻辑去读旧字段，而不是直接报“没有内容”。第二，一份名字的内容记录“能解析出来”不等于“能打开”——网关是否在线、内容是否还被节点保留，都不在名字层保证范围内。

这套机制与 NFT 元数据的关系

NFT 的 metadata 常写成指向 IPFS 的链接，而名字服务的内容记录解决的是“名字到站点”的映射。两者共享同一套底层问题：指针与内容的可靠性分离。链上部分只保证“这个节点当前登记的字节是什么”，不保证那些字节能被取回、被取回的内容与当年一致。用这类名字入口访问页面时，把“解析成功”与“内容可信且仍在”当成两个独立判断，比看链接顺不顺眼更可靠。

也要说明适用面：这份提案从未成为主流路径，它更像一份编码换算的实现笔记，接口面只有两个函数，没有事件约定、没有接口探测要求。读它的价值在于理解那类早期“把 web3 拼起来”的尝试各自卡在哪一环，而不是把它当作当前部署的推荐依据。本文为机制说明，不构成任何投资建议。