给链上数据发身份证：ERC-1900 的类型注册表为什么没跑起来

两条链、两个合约，各自存了一个都叫余额的结构：一个字段顺序是名字、金额，另一个是金额、地址。字节层面它们毫无关系，谁也不敢替对方解读。ERC-1900 想根治这类鸡同鸭讲：建一个链上类型注册表，让每种数据结构先注册、后使用，名字叫做 dType 的这份标准把注册动作、类型定义、配套函数都定了规矩。它创建于 2019 年 3 月 28 日，仓库记录状态为 Stagnant。

一个类型等于一座库

按规范，一个类型的定义是一座类型库合约：名义上的 struct 之外，还必须带几类函数。isInstanceOf 判断某个变量是否属于该类型，还能给字段加规则，比如限定某个 uint16 金额字段的取值范围；map、filter、reduce 这类高阶函数让数据可以直接在类型层被操作；structureBytes 与 destructureBytes 负责结构体和字节串互转，供不导接口、直接写底层调用的场景使用，也可服务类型检查。注册表合约则负责登记这些类型的元数据，供链下工具按名取用。规范明确注册表的增删改权限与治理不在本提案范围内。

三步走的野心

标准的野心不止于类型对照表。它引用的同一路线图里，ERC-2158 要给类型配链上存储，ERC-1921 要给类型挂纯函数库——合起来是在 EVM 上搭一套带类型系统的通用函数式积木，文档甚至展望 IDE 透明集成、EVM 未来内置编译支持。动机部分列的受益方也很有画面：区块浏览器靠注册表读懂任意数据，开发工具让用户拖已有类型进新合约，链上信息在协议之间顺畅流动。

为什么停在原地

细节里还藏着一些容易读漏的设定。类型注册表管的不只是 struct，也允许登记合约事件定义；isInstanceOf 允许给字段挂约束，等于把一部分校验从事后审计挪到了类型定义里；高阶函数 map、filter、reduce 由每个类型库自己实现，意图是让数据操作跟着类型走，而不是每个应用各写一遍。这些功能单看都有价值，但把它们全放链上执行的成本同样不容回避：每注册一种类型要部署一座库合约，每次按类型做操作都要多付外部调用的开销。标准自己也承认注册表的治理与权限不在提案范围内，这实际上把最难的共识问题留在了门外——类型该由谁批准、冲突怎么办、废弃如何标记，一个都没有答案，而链上治理恰恰是所有注册表型系统的死穴。

对内容侧还有一个更接地气的启示：同名字段跨合约含义漂移的问题每天都在发生，属性叫 Rarity 的字段可能是 Rarity 算法的输入、可能是项目方手填的星标，也可能是某个游戏的战力值。ERC-1900 用链上注册表解决它的思路没有普及，但它证明了一个判断框架——遇到任何结构化链上数据，先问它的类型定义在哪里、由谁维护、和哪些合约共用定义，三个问题答得出的字段才值得进决策依据；答不出的，当作展示素材看待更稳妥。这正是这份停摆标准留给普通读者的唯一硬遗产。

把这份 2019 年的提案放回现实，问题不难找。其一，链上登记类型元数据意味着每次定义结构都多付部署和查询成本，而链下 ABI 加文档早已覆盖同类需求；其二，注册表自身要治理，而规范恰恰把权限与治理留白，先有鸡还是先有蛋；其三，生态演化出了更便宜的路径——ABI 编码本身、The Graph 一类链下索引、跨链消息协议各管一段，没人把互通押在类型系统上。对 NFT 读者的余味在于：同一段字节在不同合约里含义可以完全不同，读任何链上数据前先看它的 schema 出处，元数据字段名撞上不代表含义相同；这也正是 ERC-1900 当年要解决、最终却没解决的问题。本文为机制说明，不构成任何投资建议。