ERC-2157 类型存储扩展：dType 把数据表搬上链的第二块积木

dType 去中心化类型系统有一组配套标准：ERC-1900 管类型注册，ERC-1921 管函数登记，本篇的 ERC-2157 管数据放哪。它创建于 2019 年 6 月 28 日，状态 Stagnant，任务是规定一种通用存储合约接口，让注册过的类型拥有标准化的数据表——记录能按键寻址、按序遍历、整体计数。标准全文不长，八类函数的分工却很清晰，读它能看清”链上全局数据库”这个想法当年的完整拼图里，存储这一块的形状。

记录住在哪儿

接口挂在一个叫 TypeRootContract 的入口合约上：类型注册表里每个类型的元数据中，原本记录库地址的字段被复用为这个根合约地址，根合约再指向真正的存储合约，留出未来换实现的余地。存储合约要满足三条硬性能力：每条记录能通过主标识符寻址、能取回全部记录、能数出总数。

函数表因此分成三组。写入组是 insert 与 insertBytes，前者按类型结构插记录，后者直接收字节流；维护组是 update 与 remove，改与删。读取组最见设计：getByHash 按记录的哈希直接取回，getByIndex 按序号遍历，isStored 回答某哈希是否存在，count 返回总条数。哈希寻址加索引遍历，等于同时给了随机访问和分页扫描两种能力，这正是任何数据服务都需要的两种读法。

与类型注册表的配合

这套存储接口自己不定义任何数据结构。记录长什么样，由 ERC-1900 注册的类型决定；存储合约只保证”按类型定义摆放、按标准函数读出”。标准论证里给出了愿景：市场对市场的、身份对身份的数据各归各的类型存储，工具只要认识类型，就能跨项目读数据——区块浏览器、分析软件、IDE 不再为每个项目单独写解析器，存储接口与类型定义合起来足以重建出调用所需的 ABI。

设计里可预见的阻力

从今天回看，阻力有三层。写权限问题：接口定义了谁能调，没有定义谁能改，一条公开可写的类型表会被垃圾记录淹没，标准的后续提案路线里承认访问控制要留待将来。gas 成本问题：把所有项目的公共数据都塞进共享合约的存储，每次写入都要为全局状态付租金。最关键的还是启动问题：注册表、函数登记、存储这层协议要同时有人用才有价值，三者都停在 Stagnant 是联动结果。

它留下的影子

入口层的 TypeRootContract 结构很小：两个公开地址字段，一个指向类型库，一个指向存储合约，构造时一次写定。标准解释过为什么不直接把存储地址塞进注册表——中间垫一层根合约，未来换实现或升级接口时只需更新这一处指向，注册表不必动。函数表再对照一遍：写入组、维护组、读取组各司其职，insertBytes 与 insert 分开是因为有些调用方手里只有序列化好的字节，不必先还原成类型对象。整个设计透露出一种洁癖：存储合约不该知道任何业务规则，它只是类型的容器，规则住在类型定义和使用它的合约里。

这套设计里还藏着一个超前判断：标准把”存储接口统一”看得比”类型定义统一”更重。理由是 ABI 可以推断——只要存储合约的读写形状一致，再配上注册表里的类型元信息，工具就能自行重建数据访问层，无需每个项目自报文档。这个判断与后来数据索引生态的演化方向暗合：谁也没等来全局类型注册表，但标准化的存储与事件模式确实成了可组合性的地基，多协议共用的事件碎片拼装、统一的子图模板，都是”接口统一优于数据统一”思路的当代回响。

dType 没有作为协议活下来，但它的问题一直活着。后来的可组合数据标准里，“全局可读的类型化数据”以另一副面孔出现：标准化注册表、按类型查询的索引器、跨协议的分析层。这份标准留给读者的提醒在评估数据型项目时很实用：任何宣称”链上开放数据生态”的系统，都该能回答写入权归谁、清理机制是什么、类型定义变更怎么兼容历史数据三个问题。接口解决结构，结构解决不了治理，这是 dType 全系列用停止前进换来的教训。本文为机制说明，不构成任何投资建议。