EIP-2803: 富交易
通过允许外部拥有账户直接执行字节码来支持“富交易”。
| Authors | Micah Zoltu (@MicahZoltu) |
|---|---|
| Created | 2020-07-18 |
| Discussion Link | https://ethereum-magicians.org/t/rich-transactions-via-evm-bytecode-execution-from-externally-owned-accounts/4025 |
摘要
如果交易的 to 地址为 x，则交易的 data 将被视为 EVM 字节码，并将从交易的 CALLER（又名：交易签名者）的上下文中执行。
动机
许多以太坊 DApp 目前需要用户批准多笔交易才能产生一种效果 - 例如，常见的模式是首先批准一个合约来花费代币，然后调用该合约。这导致了糟糕的用户体验，并使与 DApp 交互的体验变得复杂。
使外部拥有的帐户可以直接执行 EVM 字节码，从而允许单个交易执行多个合约调用，从而使 DApp 可以提供简化的体验，其中每次交互最多只产生一笔交易。
虽然原则上今天可以使用合约钱包来实现这一点，但其他 UX 问题，例如需要用 gas 费资助发送帐户、浏览器集成中缺少对合约钱包的支持以及缺少用于合约钱包的一致 API 导致了这些钱包的采用率不佳。这个 EIP 是一种增强现有 EOA 实用性的方法，本着“不要让完美成为优秀的敌人”的精神。
规范
在 x 处指定一个新的保留地址，范围用于预编译。当从外部拥有的帐户向此地址发送交易时，该交易的有效负载被视为 EVM 字节码，并以交易的签名者作为当前帐户执行。为了清楚起见：
ADDRESS操作码返回签署交易的 EOA 的地址。BALANCE操作码返回签署交易的 EOA 的余额。- 任何发送 value 的
CALL操作都从签署交易的 EOA 中获取其 value。 CALL会将CALLER设置为 EOA（而不是x）。DELEGATECALL保留 EOA 作为所有者帐户。CALLER和ORIGIN操作码都返回签署交易的 EOA 的地址。- 没有与预编译地址相关的代码。
CODE*和EXTCODE*操作码的行为与它们对任何空地址的行为方式相同。 CALLDATA*操作码按预期对交易有效负载进行操作。SLOAD和SSTORE在 EOA 的存储上运行。因此，EOA 可以在存储中拥有数据，该数据在交易之间持续存在。SELFDESTRUCT操作码不执行任何操作。- 所有其他操作码的行为与调用合约地址的预期行为相同。
- 如果附加了任何 value，则交易无效。
- 从合约调用预编译地址没有特殊效果，相当于调用不存在的预编译或空地址。
理由
此 EIP 的目的是让新的预编译在所有可能的方式上都像来自外部拥有的帐户的 DELEGATECALL 一样运行。需要进行一些更改以反映正在执行的代码未存储在链上的事实，以及对于 SELFDESTRUCT 等特殊情况，以防止引入新的边缘情况，例如能够将 EOA 的 nonce 归零。
使用预编译而不是新的 EIP-2718 交易类型，因为预编译允许我们拥有任何类型的 EIP-2718 交易的富交易。
向后兼容性
这个 EIP 引入了一项新功能，需要在未来的硬分叉中实现。预计不会出现与现有代码的向后兼容性问题。
假设 EOA 无法原子地执行多个操作的合约或 DApp 可能会受到此更改的影响，因为这现在使 EOA 可以一起执行多个原子操作。作者认为这不是一个重要的用例，因为这种“保护”已经被矿工轻易击败。
版权
在 CC0 下放弃版权和相关权利。
Citation
Please cite this document as:
Micah Zoltu (@MicahZoltu), "EIP-2803: 富交易 [DRAFT]," Ethereum Improvement Proposals, no. 2803, July 2020. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-2803.