ERC-8349 索引式分面路由：钻石合约换一种查表方式的草案

钻石合约把函数调用分发给多个分面，路由靠一张”选择器到分面”的映射表。2026 年 7 月 25 日创建的 ERC-8349 向这张表开刀：草案认为以四字节选择器为中心的路由在超大规模系统里代价偏高，提出改用紧凑的索引槽位定位分面，同时保留选择器用于对外兼容。必须先说状态：仓库记录为 Draft，这是一份仍在演进的草案，接口细节以标准文本最新版本为准。它的价值不在”能用”，在于把模块化代理的一个底层权衡摆上了台面。

草案对选择器模式的批评

ERC-2535 时代的路由逻辑以选择器为主键：每个选择器映射到一个分面，新增替换函数就是改映射。草案的批评集中在两点：其一，路由元数据的规模随函数数量线性膨胀，大型系统的表很大；其二，映射语义隐含着分面身份的推断——工具想知道”这个函数住在哪个分面”，得从选择器倒推，分面自身没有稳定的身份标识。草案的目标表述是减少路由元数据、消除选择器管理开销、规避选择器碰撞风险，同时用保留的选择器维持与常规工具的兼容。

槽位表与三个视图函数

草案的接口围绕一张路由槽表展开，每个条目同时携带路由索引与分面地址。三个只读函数构成管理面：getFacetAt 按槽位序号取分面地址，供链上路由与巡检使用；getFacetCount 返回已占用槽数；getFirstFreeSlot 给出第一个空闲槽，全部占满时回滚。写入侧的关键词是 atomicUpdate 所标示的原子性：替换一个分面只需改动恰好一个路由条目，不需要逐选择器迁移。这个特性的卖点是治理效率——换一整个分面从几十次表操作压缩为一次存储写。

选择器本身没有消失。草案明确保留常规选择器用于兼容性，改变的是”以什么为主键”：索引在前、选择器在后，分面获得了一个直接可寻址的槽位身份，而外部调用方看到的 ABI 和函数签名照旧。

草案阶段该保留哪些判断

作为一份不到一个月大的草案，它的未定部分比已定部分多：槽位容量上限、索引与选择器的同步策略、与既有钻石存储约定的配合方式，文本仍在讨论中，本文不对此下任何结论。草案状态本身也是一种风险提示——接口签名、函数名都可能改动，任何”已按 ERC-8349 实现”的宣传都值得先核对它对应草案的哪一个版本。

三个视图函数的类型细节比简介更值得记录：getFacetAt 的参数是单字节无符号整数，意味着草案设想的槽位寻址空间很紧凑；getFacetCount 返回十六位整数，getFirstFreeSlot 返回单字节并在全满时回滚。接口对原子性的定义也是一句话式的：替换一个分面要求恰好更新一个路由条目——不多不少，一次存储写完成换代。草案还把 Router 定义为协议入口组件，把路由从”地址背后的映射”提升为一个可以被单独审计、单独升级的架构件，这种身份认定比参数表更能说明它想改变的不是实现细节，而是模块化代理的分层观念。

草案对 ERC-2535 的措辞也需要精确转述：它没有宣称分面模式本身有缺陷，而是针对”以选择器为唯一路由键”这一实现惯例提出问题——函数选择器存在的意义是兼容，却被顺带当成了身份，两者混用的代价在超大规模系统里被放大。槽位方案本质上是一次键权回收：分面身份交给位置，兼容职责交回选择器。这个议题离普通用户很远，但它决定了模块化协议升级时审计者的工作量，而审计成本最终都会折算成用户的风险溢价，值得持续跟踪它的走向。

对读者的意义落在观察视角上：如果索引路由路线成立，分面代理的事件流与巡检工具要换一套读法——从查映射表变成扫槽位表，历史升级记录里每一次”移动哪个槽”成为审计锚点。模块化代理的路线争论从未结束，这份草案是最新一个愿意把架构假设写成文本的样本，值得放进收藏列表观察它走向定稿还是沉寂。本文为机制说明，不构成任何投资建议。