From 9b2251d97a8e1280c3804632f8f62b8eadf8104c Mon Sep 17 00:00:00 2001 From: lightclient <14004106+lightclient@users.noreply.github.com> Date: Mon, 22 Jun 2020 12:38:04 -0600 Subject: [PATCH] Initial draft of transaction package EIP (#2733) * initial draft of transaction package eip * added url for discussion thread * assigned to eip-2733 * fix typo and update to use return opcodes instead of call data * fix incorrect hex for returndatasize --- EIPS/eip-2733.md | 132 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 132 insertions(+) create mode 100644 EIPS/eip-2733.md diff --git a/EIPS/eip-2733.md b/EIPS/eip-2733.md new file mode 100644 index 00000000..2bad51d8 --- /dev/null +++ b/EIPS/eip-2733.md @@ -0,0 +1,132 @@ +--- +eip: 2733 +title: Transaction package +author: Matt Garnett (@lightclient) +discussions-to: https://ethereum-magicians.org/t/eip-transaction-package/4365 +status: Draft +type: Standards Track +category: Core +created: 2020-06-16 +requires: 2718 +--- + +## Simple Summary +Creates a new transaction type which executes a package of one or more +transactions. + +## Abstract +After `FORK_BLOCK`, a new [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) +transaction of type `N` is recognized. Transactions of type `N` will define a +list of transactions, which must be executed serially by clients. Execution +information (e.g. `success`, `gas_used`, etc.) will be propagated forward to +the next transaction. + +## Motivation +Meta-transaction relay contracts have historically been designed to catch +reversions in their inner transactions by only passing a portion of the +available gas to the subcall. This has been considered bad practice for a long +time, but in the case of untrust subcalls -- it is the only available solution. +Transaction packages are an alternative solution which allow multiple +transactions to be bundled into one package and executed atomically. + +## Specification + +### Definitions + +``` +N = TBD transaction type number +INTRINSIC_COST = TBD +TOTAL_COST = INTRINSIC_COST + inner_txs.reduce(|itx, acc| acc += itx.value + itx.gas_price * itx.gas_limit) +TOTAL_GAS_LIMIT = inner_txs.reduce(|itx, acc| acc += itx.gas_limit) +TX_HASH = hash of transaction as defined below +SENDER = ecrecover(hash, v, r, s) +RESULT = result as defined below for the previous transaction, empty if its the first tx in a package +``` + +### Serialization +After `FORK_BLOCK`, a new [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) +transaction type `N` will be interpreted as follows: + +`rlp([N, rlp([nonce, v, r, s, [inner_tx_0, ..., inner_tx_n]])` + +where `inner_tx_n` is defined as: + +`[chain_id, to, value, data, gas_limit, gas_price]` + +### Hashing +The hash of transaction type `N` is defined to be the Keccak-256 hash of the +rlp encoding of the entire transaction with `v`, `r`, and `s` values omitted. + +### Results +Subsequent transactions will be able to receive the result of the previous +transaction via `RETURNDATACOPY (0x3E)` in first frame of exeuction, before +making any subcalls. Each element except the last will be `0`-padded left to 32 +bytes. + +| Name | Type | Description | +|---|---|---| +| `success` | bool | Status of the previous transaction | +| `gas_used` | uint256 | Total gas used by the previous transaction | +| `cum_gas_used` | uint256 | Cumulative gas used by previous transactions | +| `return_size` | uint256 | The size of the return value | +| `return_value` | bytes | The return value of the previous transaction + +### Validation + +* (v, r, s) are a valid signature of the hash of the transaction +* The nonce is one greater than recovered address' current nonce +* The recovered address has a balance of at least `TOTAL_COST` +* The `TOTAL_GAS_LIMIT` is less than the current block's `gas_limit` + +### Execution + +Transaction packages should be executed as follows: + +1. Deduct `TOTAL_COST` from `SENDER`'s balance +2. Execute the first inner transaction in the list +3. Refund any unused `gas` +4. If there are no more transaction, stop +5. Compute `RESULT` for the previously executed transaction +6. Prepare `RESULT` to be available via return opcodes in the next + transaction's first frame +7. Execute the transaction +9. Goto `3` + + +## Rationale + +#### Non-recursive inner transactions +For simplicity, inner transactions are fully defined within this EIP. However, +there is value in supporting recursive transaction definitions. For example, +suppose there is a transaction type which can become invalid after a certain +block number. It would be beneficial to support those types of transactions +within a package, but the complexity of this EIP would dramatically increase. + + +#### Appending result data to transaction input data +An alternative to using return opcodes to propagate `RESULT` would be to append +the `RESULT` to the subsequent transaction's `data` field. Unfortunately, in +many cases contracts generated using Solidity [will +fail](https://solidity.readthedocs.io/en/v0.6.0/contracts.html#overload-resolution-and-argument-matching) +to resolve the intended function if additional data is present. Another +alternative is introducing new opcodes to expose the result data were not +proposed. + + +## Backwards Compatibility +Contracts which rely on `ORIGIN (0x32) == CALLER (0x33) && RETURNDATASIZE +(0x3D) == 0x00` will now always fail in transaction packages, unless they are +the first executed transaction. It's unknown if any contracts conduct this +check. + +## Test Cases +TBD + +## Implementation +TBD + +## Security Considerations +TBD + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).