ERC-6315 命名空间账户：每个转发器给你一个独立身份

元交易（用户不亲自发交易、由转发器代付Gas提交）是账户抽象的早期形态，ERC-2771 用可信转发器解决了一切：合约把 calldata 末尾附带的真实签名者地址当作 msg.sender。但它有个粗糙之处：不管哪家转发器送来的操作，都落到同一个你头上。2023 年 1 月 11 日创建、状态为 Review 的 ERC-6315 想把这件事做细：为每一个转发器派生一个独立的命名空间地址，转发器之间互相隔离。本文按原文拆这个设计。

一次静态调用，分辨两种身份

规范的核心动作发生在接收合约处理调用的瞬间。标准要求接收方对调用者执行一次 STATICCALL，调用其 isNamespacedTransaction 方法。如果这个调用回退或者返回假，就按 ERC-2771 的老规矩处理：普通交易进来，发送者就是 msg.sender，转发器视为零地址。如果返回真，说明这是一笔命名空间交易：真实的签名者仍按 ERC-2771 的抽取方法从 calldata 尾部读出，但转发器身份被认定为那个直接调用合约的 caller。换句话说，接收合约此刻同时知道两个人——替你办事的转发器，和你本人。同一份存储布局可以把余额记在转发器与你的组合键上，于是不同转发器送来的你，是两个互不相干的账户。

三个带命名空间后缀的函数

与这套身份识别配套，标准给出三个操作函数：transferNamespaced 指定目标侧的转发器和地址转出一笔 ERC-20；approveNamespaced 给另一个命名空间下的收款方设授权；transferFromNamespaced 则是跨命名空间的代扣，四个参数把转出侧与转入侧的转发器、地址全部写全。这些函数的存在意味着两个格子之间的资金调动要走显式通道，而不是默认同库。规范还有一条接口卫生条款：当其他标准引用命名空间功能时，应当同时提供原版与命名空间版两个接口标识，但接口定义里不得混入命名空间化的函数版本——识别归 ERC-165，业务函数保持原样。

一行静态检测的读法

规范里最有工程味的是那句 STATICCALL。静态调用不改状态，检测动作没有给调用方留下夹带副作用的机会；检测到回退或假值就回落到 ERC-2771 的默认解释——发送者是 msg.sender、转发器为零地址——保证不认识命名空间的存量合约照常工作，升级是无感的。业务侧三个 transferNamespaced 类函数不进 ERC-165 接口清单，规范要求同时提供原版与命名空间两个接口标识、接口定义不得混入命名空间化函数版本：识别归识别，能力归能力，两层声明互不污染。索引器与钱包因此能用极低成本探测支持度：一次合约查询问出“认不认识命名空间”，再决定按格子还是按整户展示余额。标准没有强制存储结构怎么切分，但把身份解释的一致性钉死在了检测规程里，这正是它比自由发挥的元交易方案多出的一块地基。

Review 状态与现实张力

按 ercs 仓库记录，ERC-6315 处于 Review 阶段。这份标准的动机部分把安全论点讲得很清楚： ERC-2771 时代所有转发器共享一个身份，一家转发器被攻破或作恶，等于替所有用户签名，风险高度中心化；拆成命名空间后，某个转发器的事故被圈死在它自己的格子里。代价同样明确：用户资产被切成互不相通的碎块，跨格子迁移必须依赖专门函数或迁移工具，钱包要为每个转发器显示一个独立余额面板。读这份标准时值得带一个视角：账户抽象领域反复在同一条边界上做取舍——便利的共享身份和隔离的分裂身份，ERC-4337 用EntryPoint统一入口、聚合器角色分化走了另一条解法。评估任何一个代付Gas服务时，先问一句它能否被隔离出局，比问它便不便宜更能预测你出事时的损失半径。

本文为机制说明，不构成任何投资建议。