status-im/EIPs
2
0
Fork 0
mirror of https://github.com/status-im/EIPs.git synced 2025-02-23 12:18:16 +00:00
Code Issues Projects Releases Wiki Activity

EIP-2930: Updates transaction format to match EIP-2718 (#3101)

Browse Source 
* EIP-2930: Updates transaction format to match EIP-2718

2718 has the first byte of every transaction be the transaction type, and the remaining bytes are interpreted however this EIP wants. This is the minimal change required to get it in line with 2718 so I think we should merge this ASAP and then continue discussion on whether we think this is the optimal format or not.

* Update EIPS/eip-2930.md

Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com>

* Changes same thing in more places.

Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com>
This commit is contained in:
Micah Zoltu 2020-11-19 16:19:39 +08:00 committed by GitHub
parent 13579d5ae5
commit 5d8bee5e12
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
EIPS/eip-2930.md
View File

@ -16,7 +16,7 @@ Adds a transaction type which contains an access list, a list of addresses and s
## Abstract
We introduce a new [EIP-2718](./eip-2718.md) transaction type, with the format `rlp([1, [chainId, nonce, gasPrice, gasLimit, to, value, data, access_list, senderV, senderR, senderS]])`.
We introduce a new [EIP-2718](./eip-2718.md) transaction type, with the format `1 || rlp([nonce, gasPrice, gasLimit, to, value, data, access_list, senderV, senderR, senderS])`.
The `access_list` specifies a list of addresses and storage keys; these addresses and storage keys are added into the `accessed_addresses` and `accessed_storage_keys` global sets (introduced in [EIP-2929](./eip-2929.md)). A gas cost is charged, though at a discount relative to the cost of accessing outside the list.
@ -37,7 +37,7 @@ This EIP serves two functions:
| `ACCESS_LIST_STORAGE_KEY_COST` | 1900 |
| `ACCESS_LIST_ADDRESS_COST` | 2400 |
As of `FORK_BLOCK_NUMBER`, we introduce a new transaction type, with the format `rlp([1, [chainId, nonce, gasPrice, gasLimit, to, value, data, access_list, senderV, senderR, senderS]])`. The signing hash would be the hash of the RLP of the entire data structure but popping the last three items representing the signature from the inner list: `rlp([1, [chainId, nonce, gasPrice, gasLimit, to, value, data, access_list]])`. `chainId` is defined to be an integer of arbitrary size. Since `chainId` no longer resides in the signature, `v` must be either 0 or 1 depending on recovery id.
As of `FORK_BLOCK_NUMBER`, we introduce a new transaction type, with the format `1 || rlp([chainId, nonce, gasPrice, gasLimit, to, value, data, access_list, senderV, senderR, senderS])`. The signing hash would be the hash of the RLP of the entire data structure but popping the last three items representing the signature, and prepending the transaction type: `rlp([1, chainId, nonce, gasPrice, gasLimit, to, value, data, access_list])`. `chainId` is defined to be an integer of arbitrary size. Since `chainId` no longer resides in the signature, `v` must be either 0 or 1 depending on recovery id.
For the transaction to be valid, `access_list` must be of type `[[{20 bytes}, [{32 bytes}...]]...]`, where `...` means "zero or more of the thing to the left". For example, the following is a valid access list (all hex strings would in reality be in byte representation):
@ -103,7 +103,7 @@ This is done to encourage transactions to use the access list as much as possibl
This is done because it maximizes simplicity, avoiding questions of what to prevent duplication against: just between two addresses/keys in the access list, between the access list and the tx sender/recipient/newly created contract, other restrictions? Because gas is charged per item, there is no gain and only cost in including a value in the access list twice, so this should not lead to extra chain bloat in practice.
### Signature signs over the entire envelope including the wrapper
### Signature signs over the transaction type as well as the transaction data
This is done to ensure that the transaction cannot be "re-interpreted" as a transaction of a different type.