ERC-6315: ERC-2771 命名空间账户抽象

引入每个转发器的命名空间地址，以方便在命名空间框架下的元交易

摘要

ERC-2771 是通过受信任的转发器处理元交易的普遍标准。本 EIP 建议扩展 ERC-2771，引入命名空间机制，通过每个转发器的命名空间地址促进无需信任的账户抽象。

规范

本文档中的关键词“必须”、“禁止”、“必需”、“应”、“不应”、“应该”、“不应该”、“推荐”、“不推荐”、“可以”和“可选”应按照 RFC 2119 和 RFC 8174 中的描述进行解释。

本文档中的关键词“转发器”和“接收者”应按照 ERC-2771 中的描述进行解释。

命名空间转发器接口

pragma solidity ^0.8.0;

interface INamespacedForwarder {
    function isNamespacedTransaction() external view returns (bool);
}

确定发送者和转发器

在接收者上调用函数时，接收者必须对调用者的 isNamespacedTransaction() 方法执行 STATICCALL。如果此操作还原或返回布尔值 false，则事务必须正常进行，将调用者识别为发送者，并将转发器识别为零地址。但是，如果返回布尔值 true，则事务被确认为命名空间事务，发送者使用 ERC-2771 中概述的程序进行识别，转发器被识别为调用者。

接收者扩展

每当接收者合约具有一个或多个 address 类型的函数参数的函数时，它还必须提供一个新函数，镜像原始函数的名称，但在末尾附加 Namespaced，它接受两个地址。初始地址表示转发器，而后者表示由该转发器管理的地址。如果一个函数接受多个地址参数（例如，ERC-20 的 transferFrom），则必须提供一个函数版本，该函数接受每个原始地址参数的两个地址。当转发器地址为零地址时，原始函数必须表现出与新函数相同的行为。

例如，ERC-20 将通过以下函数进行扩展：

function transferNamespaced(address toForwarder, address toAddress, uint256 amount);
function approveNamespaced(address spenderForwarder, address spenderAddress, uint256 amount);
function transferFromNamespaced(address fromForwarder, address fromAddress, address toForwarder, address toAddress, uint256 amount);

ERC-165

接收者合约必须实现 ERC-165。当注册 ERC-165 接口 ID 时，还必须注册与原始接口的命名空间函数选择器的 XOR 对应的第二个接口 ID。

理由

采用简单地用新的 address 参数增强现有 EIP 函数的方法，而不是为最常用的 EIP 制作新的接口，是为了确保此命名空间提议的更广泛适用性。

向后兼容性

已经部署的合约无法从此命名空间提议中受益。此限制也扩展到 ERC-2771。

在标准中使用此 EIP

在另一个标准中使用此 EIP 时，应同时提供原始接口 ID 和命名空间接口 ID。接口不得在其接口中包含函数的命名空间版本。

安全注意事项

该提案改变了信任关系：转发器不再需要接收者的信任，而是需要其用户的信任。

版权

在 CC0 下放弃版权及相关权利。

Citation

Please cite this document as:

Gavin John (@Pandapip1), "ERC-6315: ERC-2771 命名空间账户抽象 [DRAFT]," Ethereum Improvement Proposals, no. 6315, January 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-6315.