ERC-8109 钻石合约定义：一份 2025 年底被撤回的模块化规范

钻石合约是以太坊上一类知名的模块化代理：一个对外地址，背后把函数调用分发给多个实现合约，状态集中存在主约里。围绕它的事实标准是 ERC-2535，而 2025 年 12 月 21 日创建的 ERC-8109 试图给这套模式写一份正式定义。必须先把状态说清：仓库记录它的当前状态是 Withdrawn，作者主动撤回。一份晚来七年的定义稿为什么撤，文本里其实有线索——它与既成实践几乎一致，新增约束却没能带来增量价值。按原文读懂它，仍是理解钻石架构的最快路径之一。

定义先把术语钉死

标准开篇用定义条款固定三个概念。钻石是一个把外部调用路由到一个或多个实现合约的有状态合约，全部持久数据存在钻石自己的存储里；分面是独立部署、定义了一组外部函数的实现合约，一个分面的函数可以挂到多个钻石上；分面函数通过 delegatecall 在钻石上下文执行，读写都落在钻石存储，msg.sender 与 msg.value 不变。这个 delegatecall 语义是整套架构的承重墙：分面代码只是”借用”钻石的躯体执行，两条命脉——调用者与金额——保持原样。

强制条款里的工程底线

实现要求一节列了几条 MUST。钻石必须实现 fallback 函数承担路由；当某个选择器找不到对应分面、又没有默认函数兜底时，fallback 必须以 FunctionNotFound 错误携带该选择器回滚——把”没有这个函数”从含糊回滚变成带参数的明确错误，调试与前端集成的体验差别很大。对每个选择器的新增、替换、移除都必须发出对应事件，让路由表变化在链上可回放，这是持有人与审计者核对”函数去哪了”的依据。分面内部主动发起的 delegatecall 要发事件留痕，而 fallback 的路由转发本身不得重复发该事件，条款对”哪些跳转值得记日志”划了线。查询接口 facetAddress 按选择器返回分面地址，加上分面与函数配对关系枚举函数，构成外部工具读取路由表的入口。

与 ERC-2535 的关系和撤回的含义

钻石模式多年实践中最大的争议在存储布局：多个分面共享一块存储，变量顺序错一位就可能串写数据，社区为此发展出钻石存储等隔离约定。ERC-8109 沿用了事件与查询这套被广泛验证的接口，但要在它之上统一更多细节，既得项目没有配合动力——这正是它被撤回的处境：模式已经成熟到不需要新标准，细节又分歧到一份新标准无法强行收编。撤回不等于证伪，钻石架构仍在大项目里运行，只是其规范位置由实践维持。

给持有人的实用动作

必选函数清单里可以直接抄出一个实用细节：facetAddress 的完整签名以四字节选择器为参数、返回一个地址，任何外部工具拿它逐选择器扫描，就能拼出钻石当前的完整功能地图。把它与选择器变更事件组合使用，一静一动：查询函数给出此刻的路由快照，事件流给出快照之间的每次改动。钻石模式的透明度不靠承诺，靠的就是这两样东西是否被老实实现——工具能扫到地图、历史能回放改动，“模块化”才是可验证的工程事实。

评估任何模块化代理合约，这份标准的技术条款几乎可以直接抄成核对清单：路由事件历史是否完整可查，某个函数从哪个分面换到了哪个分面能否逐条回答；查询函数的返回是否一致；fallback 找不到函数时的报错是否可辨。钻石结构本身不是红旗，但”升级透明”要靠这些条款兑现——能查事件的模块化叫可审计，查不到事件记录的模块化只是借口。本文为机制说明，不构成任何投资建议。