ERC-7674: ERC-20 的临时授权扩展

短暂的 ERC-20 授权，仅持续单笔交易

摘要

此规范定义了在同一交易中临时批准 ERC-20 代币用于消费所需的最小接口。

动机

用户经常需要设置一个仅使用一次的代币授权。在这些交互之后，留下意想不到的授权是很常见的。EIP-1153 引入了 TSTORE，它可以用来有效地处理临时额度。

规范

本文档中的关键词“必须 (MUST)”，“禁止 (MUST NOT)”，“需要 (REQUIRED)”，“应该 (SHALL)”，“不应该 (SHALL NOT)”，“推荐 (RECOMMENDED)”，“不推荐 (NOT RECOMMENDED)”，“可以 (MAY)”和“可选 (OPTIONAL)”按照 RFC 2119 和 RFC 8174 中的描述进行解释。

除了 ERC-20 之外，符合标准的合约必须实现 1 个新函数：

function temporaryApprove(address spender, uint256 value) public returns (bool success)

调用 temporaryApprove(spender, value) 允许 spender 在同一交易中代表 msg.sender 多次提取，使得提取的总额小于或等于 value 金额。此临时授权应被视为对正常的（持久的）ERC-20 授权的补充。因此，spender 在交易期间能够花费的总价值受到临时授权和正常（持久的）授权之和的限制。虽然 transferFrom 操作应该可以消耗两种类型的授权，但临时授权的消耗应该优先于持久授权的消耗。因此，如果临时授权足以执行 transferFrom 操作，则不应从存储中加载/更新持久授权。只有在临时授权不足以执行正在执行的操作时，才应执行持久授权的消耗，这意味着需要访问存储。

每个临时授权必须持续到创建它的交易结束时（除非被另一次对 temporaryApprove 的调用覆盖或被对 transferFrom 的调用消耗）。每个临时授权必须在创建它的交易结束时被清除。有关示例，请参见使用瞬态存储。

当在 allowance 函数中返回允许花费的金额时，符合标准的合约必须将临时授权添加到永久授权中。如果临时授权和永久授权的总和溢出，则必须返回 type(uint256).max。

理由

决定进行最小的接口扩展，以允许将符合标准的合约更容易地集成到现有基础设施中。这会影响 allowance 函数的向后兼容性。但是，对 transferFrom 函数实现的所需更改满足了明确授权 spender 可以转移代币的要求。

向后兼容性

ERC-20 标准的所有功能都向后兼容，除了 allowance 函数。

参考实现

使用瞬态存储

临时授权的存储必须与常规授权的存储不同。符合标准的合约可以使用瞬态存储 EIP-1153 来保存临时授权。对于每个 owner 和 spender，必须唯一选择插槽，以避免插槽冲突。每个插槽索引应从临时授权的基本插槽索引、owner 和 spender 地址派生。插槽可以派生为 keccak256(spender . keccak256(owner . p))，其中 . 是连接，p 是来自字符串的 keccak256，该字符串唯一地定义了实现合约命名空间中的临时授权。

事件

即使在设置临时授权时不需要事件，符合标准的合约也可以发出 TransientApproval(address indexed owner, address indexed spender, uint256 value) 事件。

安全注意事项

派生插槽标识符以存储临时授权的方法必须避免与同一空间中的其他插槽（例如，瞬态存储）发生冲突。

版权

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

Citation

Please cite this document as:

Xenia Shape (@byshape), Mikhail Melnik (@ZumZoom), Hadrien Croubois (@Amxx), "ERC-7674: ERC-20 的临时授权扩展 [DRAFT]," Ethereum Improvement Proposals, no. 7674, April 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7674.