链上的 npm registry：ERC-1319 合约包注册表的编号与翻页接口

ERC-190 定义了合约包的格式，但格式解决不了“去哪里找包”。ERC-1319 创建于 2018 年 8 月 13 日，仓库记录状态为 Stagnant，它把答案放在链上：写一个注册表合约，包发布人往里登记，消费方直接从合约里读目录。它是包格式标准 ERC-1123 的配套件，两者一起构成一条“链上包管理”的完整设想。

写入侧：一次发布一条事件

写入接口只有一个函数：release，参数是包名、版本号和清单文件的 URI，返回登记产生的发布编号。调用成功的同时合约发出 VersionRelease 事件，把包名、版本和清单地址完整重述一遍。这个事件设计有现实考量：链下索引器不需要状态读取就能重建整本目录，事件即账本。

读取侧：编号折叠与分页

读取接口分三层。第一层处理身份：generateReleaseId 是纯函数性质的视图函数，把包名和版本确定性地折叠成一个 bytes32 编号，任何客户端不用查链就能算出某个版本对应的编号；getReleaseId 和 getPackageName 处理编号与名称之间的双向查询。第二层处理目录：getAllPackageIds 和 getAllReleaseIds 带偏移量和数量两个参数，返回切片后的编号数组，配合 numPackageIds 与 numReleaseIds 先数数再翻页，避免一次拉爆返回数据。第三层处理内容：getReleaseData 按发布编号返回登记时存入的清单 URI。整套接口的风格是典型的以太坊式键值仓库：链上只存编号和短字符串指针，正文留在链下。

事件驱动的索引方案

链上注册表的读取还有第二条通道：日志。每次 release 调用发出的 VersionRelease 事件把包名、版本和清单地址完整写进交易收据，索引器沿着事件序列顺序回放，不需要任何状态查询就能重建整本发布目录，还能天然获得时间顺序。函数式读取接口反而更像补充手段：用于核对某个编号是否仍然在册，或者拉取事件索引滞后时的最新状态。设计上的分工是：链上存事实和指针，链下算目录和排序，这与今天区块浏览器处理转账事件的套路完全一致。

名字空间与信任空位

标准没有处理注册表的准入，任何地址都能调用 release 登记任意包名，先到先得。设想中的消费场景里，包管理软件会在解析依赖时自动拉取登记内容，一个抢注的相似包名就是一条供应链注入通道。这条空缺后来分别由三样东西填补：ENS 用出价与租期给名字定价，代码托管平台把仓库名与组织所有权绑定，包管理器用签名和双因素要求收紧发布权限。ERC-1319 的价值因此更像一份反面教材加设计词典：链上登记适合做不可篡改的时间戳目录，名字归属、发布者信誉和内容完整性必须回到链下机制解决，注册表函数解决不了“该信谁”。

与 ERC-190 的关系

回到分发链条的全景：包格式解决单个包的自描述，注册表接口解决多包共存时的发现与检索，两者配套才构成完整的链上分发闭环。设想中的用户旅程是这样的：开发者按 1123 或 190 的格式准备好包，调用 release 登记，索引器从 VersionRelease 事件重建目录，钱包按包名取最新版本，读出清单里的合约字节码与地址表，最后为已部署合约生成界面。旅程里每一环都有标准对应，唯一没有标准的是环与环之间的信任传递——这正是整条路线最终停在标准文件里、而不是停在生产环境里的原因。

为什么这条路线没有走下去

链上注册表的问题和 2018 年的存储与检索现实有关。第一，包正文必须在链下托管，注册表只能保证登记动作不可篡改，保证不了清单地址指向的文件十年后还打得开；第二，npm 与 GitHub Releases 在链下已经把版本、签名、镜像和权限管理做熟，链上登记只增加Gas成本不增加保证；第三，恶意登记的治理缺位——任何人都能调用 release抢占包名发布记录，标准没有给出命名空间归属或审核层。今天它的思想在别处复活：包名解析回到 ENS，完整性校验回到内容哈希，恶意包对抗回到供应链签名。读 ERC-1319 的当下价值，是把它当作一份设计样本：链上目录适合存指针和事件，不适合存信任裁定本身。

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