合约的出厂包装箱：ERC-190 智能合约包标准为什么停在 2017 年

一个 ERC-721 项目要在多个链上部署一批合约，普通用户和审计者面对的实际问题是：链上那串字节码，到底是不是公开源码编译出来的？同一份包发到了主网和测试网，两边的地址分别是哪些？ERC-190 在 2017 年 1 月 10 日给出的答案是：像 npm 发包一样，把合约连同源码、字节码和说明一起打包发布。标准文本记录状态为 Final，但这条路线后来没有成为主流，读它的好处是能把今天构建工具链解决的问题倒推一遍。

包里装什么

标准规定的包以一个发布清单为中心，围绕它组织四类内容：包名与版本号、清单本身列出的合约文件、编译产物，以及依赖说明。清单要写清楚包里每个合约的名字和它在包内的位置，让消费工具不需要猜。规范专门设计了发布锁文件，面向包管理软件消费：源码和依赖都用内容寻址的方式引用，指向的资源不会被悄悄替换，同一份锁文件总能解析出同一组源码和依赖。这套设计的野心不止于存档：它希望钱包软件直接消费发布包，为包内已部署的合约自动生成操作界面，配合 ENS 名字，用户输入一个好读的名字就能打开对应应用。把这几层拆开看，清单回答“包里有什么”，锁文件回答“源码与依赖能否复现”，部署地址表回答“哪条链上哪个地址是它”，三者共同把源码、字节码和链上地址钉成同一条证据链，任何一环缺失都会让验证结论降级。

两条验证链路

包结构支撑两件事。第一件是可复现构建：验证方按包里的源码和依赖版本重新编译、链接，把得到的字节码和链上部署的字节码逐字对比，一致才承认源码真实。第二件是多链部署记录：一个包可以声明同一份代码在不同链上的部署地址，主网和测试网写在同一个包里，避免同一个项目发两份互相矛盾的地址清单。标准还留了 Trusted packages 的口子：允许发布不含源码的极简包，代价是包管理器放弃字节码验证，只适用于明知不需要验证的特殊场景。这个口子本身就是在提醒读者：没有源码的包，验证链条是断的。

为什么它没跑起来

ERC-190 的设想是链上分发时代的基础设施，但它赌错了演进方向。后来行业的答案是把验证做进区块浏览器和开发框架：源码在代码托管平台上公开，浏览器负责重新编译比对，Hardhat 和 Foundry 这类工具把编译、部署记录、验证提交收进本地流水线，用户不需要理解一个链上包格式。包格式方案则被 npm 加构建插件的组合覆盖。标准文本里那句钱包从包自动生成界面的愿景，今天由另一种形式实现：前端应用直接打包 ABI。对普通用户来说，判断一个项目愿不愿意接受可验证分发，有个粗筛方法：看它公开的是地址列表还是完整的构建说明。只给一串地址的项目，源码与链上字节码的对应关系要靠区块浏览器的单边声明；给了仓库、版本标签、编译器版本与优化参数的项目，任何人都能本地重编译做交叉核对。ERC-190 当年想把这类信息统一装进一个标准包，让核对不再依赖某个特定浏览器，这个诉求本身没有过时，只是实现载体换成了代码仓库加验证流水线的组合。读 ERC-190 的现实价值是核对清单：一个项目如果向你提供发布包，检查它有没有锁文件、源码是否内容寻址、部署地址是否声明了网络，三样都缺的包只能当作说明文档，不能当作验证材料。

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