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

Automatically merged updates to draft EIP(s) 2718 (#2727)

Browse Source 
Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing
This commit is contained in:
Micah Zoltu 2020-06-16 10:51:57 +08:00 committed by GitHub
parent 3bcf64d779
commit b6c0299bb5
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
EIPS/eip-2718.md
View File

@ -14,7 +14,7 @@ requires (*optional): 155
Defines a new transaction type that is an envelope for future transaction types.
## Abstract
As of `FORK_BLOCK_NUMBER`, `rlp([TransactionType, payload])` will be a valid transaction where `TransactionType` is a number identifying the format of the transaction and `payload` is the transaction, whose definition is defined in future EIPs. The first new transaction type will be just a wrapped legacy transaction with the format `rlp([0, rlp([nonce, gasPrice, gasLimit, to, value, data, senderV, senderR, senderS])])`.
As of `FORK_BLOCK_NUMBER`, `rlp([TransactionType, Payload])` will be a valid transaction where `TransactionType` is a number identifying the format of the transaction and `payload` is the transaction, whose definition is defined in future EIPs. The first new transaction type will be a wrapped legacy transaction with the format `rlp([0, rlp([nonce, gasPrice, gasLimit, to, value, data, v, r, s])])`.
## Motivation
In the past, when we have wanted to add new transaction types we have had to ensure they were backward compatible with all other transactions, meaning that you could differentiate them based only on the encoded payload, and it was not possible to have a transaction that matched both types. This was seen in [EIP-155](./eip-155.md) where the new value was bit-packed into one of the encoded fields. There are multiple proposals in discussion that define new transaction types such as one that allows EOA accounts to execute code directly within their context, one that enables someone besides `msg.sender` to pay for gas, and proposals related to layer 0 multi-sig transactions. These all need to be defined in a way that is mutually compatible, which quickly becomes burdensome to EIP authors and to clients who now have to follow complex rules for differentiating transaction type.
@ -22,11 +22,11 @@ In the past, when we have wanted to add new transaction types we have had to ens
By introducing an envolope transaction type, we only need to ensure backward compatibility with existing transactions and from then on we just need to solve the much simpler problem of ensuring there is no numbering conflict between `TransactionType`s.
## Specification
As of `FORK_BLOCK_NUMBER`, `rlp([nonce, gasPrice, gasLimit, to, value, data, senderV, senderR, senderS])` will no longer be a valid Ethereum transaction over the devp2p protocol.
As of `FORK_BLOCK_NUMBER`, `rlp([nonce, gasPrice, gasLimit, to, value, data, v, r, s])` (legacy transaction) will no longer be a valid Ethereum transaction over the devp2p protocol or in a block.
As of `FORK_BLOCK_NUMBER`, `rlp([0, rlp([nonce, gasPrice, gasLimit, to, value, data, senderV, senderR, senderS])])` will be a valid transaction over the devp2p protocol where the second item of the outer array will be processed/handled exactly the same as a pre `FORK_BLOCK_NUMBER` transaction was processed/handled.
As of `FORK_BLOCK_NUMBER`, all transactions sent over devp2p or included in a block **MUST** be of the form `rlp([TransactionType, Payload])` where `TransactionType` is a number that represents the type of the transcation and `Payload` is an opaque value (byte array) whose interpretation is dependent on the `TransactionType`.
Future EIPs **MAY** define new transaction types by choosing an unused `TransactionType` number. This number will be the first item of the RLP encoded array. The second item of the RLP encoded array will be interpreted based on the EIP that defines the new transaction type.
As of `FORK_BLOCK_NUMBER`, `rlp([0, rlp([nonce, gasPrice, gasLimit, to, value, data, v, r, s])])` will be a valid transaction where the `Payload` will be processed/handled exactly the same as legacy transactions were processed/handled.
## Rationale
### TransactionType high bit