包装箱被拆掉之后：ERC-1123 智能合约包标准为何被 ERC-2678 取代

想在一个公开登记簿里存一份“软件说明书”时会遇到一个老问题：说明书越详细，登记簿越贵。ERC-1123 就是这份说明书的以太坊版本之一，创建于 2018 年 6 月 1 日，仓库当前状态是 Withdrawn，正文几乎被清空，只留下一句说明：本提案已经被 ERC-2678 所定义的 EthPM V3 智能合约打包标准取代。要理解撤回背后的判断，得把这两份文件对着读。

旧版把包体直接搬上链

ERC-1123 的思路很直接：既然信任来自链上，那就把包的内容也放到链上。文件里给“包”下的定义是一个内容映射，每个键对应一条资源记录，资源可以是源码、字节码、编译设置或接口文档。它甚至考虑到了链上空间放不下二进制的情形，允许用 link 类型外链或者用 Content-address 类型给出内容地址，并预留了压缩标记。听起来考虑周全，但代价被低估了：每次发布一个包版本，链上都要写入一整张内容映射表，而注册表合约要提供逐键查询的接口，读一次包结构就是若干次链上调用。

更麻烦的是版本演进。包的一个版本对应链上一份不可变记录，改一个字也要重新部署一条完整记录。对开发者来说，这是把 npm 发布流程的成本按字节定价到了 Gas 上。

V3 换的思路：链上只留指纹

ERC-2678 保留了“包应该有标准格式”的共识，但把载体换掉了：清单写成 JSON 文件，按 ERC-2678 规定的字段组织，包含包名、版本、源码仓库地址、依赖列表与各份合约的元数据；这份 JSON 可以放在 IPFS、Swarm、HTTP 服务器甚至打包进二进制里。链上注册表只需要记录两样东西：清单的内容哈希，以及一个指向存储位置的链接。原文强调清单必须能够被重建出一致的源码树，也就是说链上那份指纹是可验证的承诺，而不是一段自我宣称的描述。

把两版放一起，取舍就清楚了。链上放全量内容，换来的是无需信任存储层，代价是成本与僵化；链上只放内容哈希，换来的是轻与快，代价是数据可用性外包给了别处——如果那些 IPFS 节点哪天不再提供这份文件，你手里只剩一个无法还原的哈希。这恰好是 NFT 元数据领域反复上演的同一道题，解题方式也一致：先保证内容能被多方复刻保存，再谈链上指纹。

撤回之后剩下的三条经验

第一，登记簿该管“叫什么、指向哪”，不该管“内容是什么”。这条判断在 ERC-1319 注册表接口、ERC-2942 的定位语法里都成立，也和 NFT 里 tokenURI 与合约分工是同构的。第二，可重建性比可访问性更硬。ERC-2678 要求清单能重建源码树，意思是你拿到这份 JSON 之后，应当能独立复算出所有哈希，而不必相信发布者；这个标准动作与今天验证合约源码是否匹配字节码属于同一类核对。第三，被撤回不等于白做。ERC-1123 用一次完整起草把“链上存全量内容”这条路标明了成本上限，替后来者省掉了一段弯路，这份记录本身就是标准流程的价值。

读者真正能带走的具体动作是：如果某个项目的说明是“我们的合约包登记在某注册表”，先去要一份可下载的版本清单，看里面有没有源码仓库地址与内容哈希，然后自己核对哈希能不能对上那份字节码。只给一个注册表链接、拿不到可核验清单的说法，等价于把审计责任交给一个还没验证过的第三方。本文为机制说明，不构成任何投资建议

一个容易混淆的细节：撤回不等于失效

仓库里状态为 Withdrawn 的文件通常还保留摘要与取代说明，而不是像被删除一样查无此文。这个细节有实用价值：当你读到一份 2018 年前后的教程引用了旧编号的标准时，先查该编号现在的状态字段。如果写着 Withdrawn 并指向新编号，那么教程里的接口描述几乎可以肯定已经过时，按它操作会写出根本不被现有工具识别的代码。反之，状态是 Deprecated 或 Stagnant 的提案没有这种明确的替代指针，需要自己顺着被引用关系去找现役方案。把“有没有后继编号”当成第一道过滤器，比逐字对比文本快得多。

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