ERC-927: 通用授权

摘要

本 EIP 规定了一种通用的授权机制，可以用于实现各种授权模式，取代 ERC20 中的 approvals、ERC777 中的 operators 以及各种其他类型合约中的定制授权模式。

动机

智能合约通常需要提供一个接口，允许第三方调用者代表用户执行操作。最常见的例子是 token 授权/operators，但类似的场景在整个生态系统中都存在，包括例如授权对 ENS 域名进行操作。通常，每个标准都会为自己重新设计这个系统，导致大量不兼容的同一种基本模式的实现。在这里，我们提出一种可供所有此类合约使用的通用方法。

这里实现的模式受到 ds-auth 和 OAuth 的启发。

规范

通用授权接口以元数据提供者的形式实现，如 EIP 926 中所述。实现了以下强制性函数：

function canCall(address owner, address caller, address callee, bytes4 func) view returns(bool);

其中：

• owner 是资源的拥有者。如果获得批准，该函数调用将被视为由此地址发出。
• caller 是发出当前调用的地址。
• callee 是被调用的合约的地址。
• func 是被调用函数的 4 字节签名。

例如，假设 Alice 授权 Bob 代表她转移 token 。当 Bob 这样做时，Alice 是 owner，Bob 是 caller，token 合约是 callee，转移函数的函数签名是 func。

由于此标准使用 EIP 926，因此授权流程如下：

1. callee 合约从位于众所周知地址的元数据注册表合约中获取 owner 地址的提供者。
2. callee 合约使用上述参数调用 canCall()。如果该函数返回 false，则 callee 会恢复执行。

通常，提供者希望为用户提供一个标准化的接口来设置和取消他们自己的授权。他们应该实现以下接口：

function authoriseCaller(address owner, address caller, address callee, bytes4 func);
function revokeCaller(address owner, address caller, address callee, bytes4 func);

参数的含义与 canCall 中的含义相同。实现合约必须确保 msg.sender 被授权代表 owner 调用 authoriseCaller 或 revokeCaller；如果 owner == msg.sender，则必须始终为真。实现合约应使用此处指定的标准来确定其他调用者是否也可以提供授权。

实现合约应将 func 为 0 视为授权调用 callee 上的所有函数。如果 authorised 为 false 且 func 为 0，则合约只需清除任何 blanket 授权；个别授权可能仍然有效。

向后兼容性

不存在向后兼容性问题。

实现

待定的示例实现。

版权

版权和相关权利通过 CC0 放弃。

Citation

Please cite this document as:

Nick Johnson <nick@ethereum.org>, "ERC-927: 通用授权 [DRAFT]," Ethereum Improvement Proposals, no. 927, March 2018. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-927.