钻石合约的抽屉要分域：ERC-8110 给模块化存储划地界

钻石模式把一个合约的逻辑拆成许多分面，各自负责一块功能，共享同一份存储。这个架构最古老的事故类型不是分面崩溃，而是分面打架：新加的分面开发者凭直觉选了一个存储位置，恰好和老分面重名，两边写的其实是同一格槽位，账本在无人察觉时互相覆盖。ERC-8110 针对的就是这类碰撞，文件头记录创建于 2025 年 12 月 20 日，仓库记录状态为 Draft，声明依赖 ERC-2535 与 ERC-8042。

站在 ERC-8042 的肩膀上

它不重新发明存储位置的算法。ERC-8042 已经给出了命名空间存储的做法：给每个逻辑模块一个可读标识符，对它做哈希算出一个几乎不可能撞车的存储槽，模块的所有数据都挂在这个槽派生出来的子空间里。ERC-8110 在这层机制之上做的是组织学：把系统状态按域与子域分格，每个域声明自己的布局与标识，形成一份可枚举的目录。原文的示例场景来自链游：角色装备一个域、角色属性一个域、玩法定价一个域——每个域在源码里用带标识符的命名空间结构声明，工具据此能读出“这个槽属于哪个域、里面是什么布局”，审计时按域对账，而不是面对一张巨大的槽位平面图靠猜。

图纸管什么、不管什么

规范的自我定位很清楚：只定义存储怎么组织，不指定执行模型、升级模型或分面路由怎么实现。也就是说，它既不管 ERC-2535 的分面登记表，也不管某次升级要不要重新部署——同一套域架构可以配任意钻石实现。它强制的核心只有一条纪律：每个域的命名空间标识必须稳定且可发现，标识一变，哈希出的槽位就变，读到的就是另一间空屋；因此域的标识符进了代码评审清单，和 ABI 变更同级。

什么时候值得用

存储碰撞的具体形状

没有域纪律时事故如何发生，原文的场景可以还原成一个最小例子：一位开发者为角色装备系统写了命名空间，标识符取了一个自然语言短语；半年后另一人为公会系统写了同样的短语，哈希出来的基槽完全相同，两套结构体从同一格开始向两侧铺开，字段互相覆写却没有任何一笔交易会报错——读双方各自读得通，写双方轮流写坏对方。ERC-8110 的解法是把标识从个人品味变成登记事项：每个域一个规范标识，写进合约的注释与源码结构声明，工具链与审计流程据此查重；它甚至建议同一套游戏参数类配置按用途分域——装备、角色、设定各归各屋——哪怕同一个作者自己维护也不许挤一间。原文同时提醒纪律的代价：命名空间里的值不支持原生的整体读写，跨域操作要么显式调用要么各自维护镜像字段，gas 与心智负担都实打实。值得强调它的诚实定位：这份图纸不承诺自动防碰撞，它承诺的是碰撞变得可发现——标识可枚举、布局可导出之后，审计里问一句“给我看全部域清单及其哈希”就有了标准答案，这在多分面工程里已经比口头约定强出一个数量级。

域架构的收益随系统规模增长。单分面的小合约不需要它——一间房不用划房间。当一个钻石合约积累了十几个分面、多任作者跨年份接力、审计方需要逐模块出报告时，域目录把“这块状态归谁管”从口口相传的部落知识变成合约自己可读的元数据。反过来也要看清成本：命名空间之间不共享结构，跨域读状态要靠显式调用对方的视图函数，架构上等于用一点 gas 换隔离度。Draft 状态表明它还在演化，落地前先确认依赖的 ERC-8042 哈希口径是否与实现一致，再核对每个分面的存储声明是否标注了域标识——没有标注的“域架构”只是文档里的一句话。本文为机制说明，不构成任何投资建议。