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

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

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-07-01 10:59:09 +08:00 committed by GitHub
parent 2cec02faf3
commit 06e64e4141
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 11 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
EIPS/eip-2718.md
View File

@ -24,9 +24,13 @@ By introducing an envolope transaction type, we only need to ensure backward com
## Specification
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`, 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`. Transactions **SHOULD** include the `TransactionType` in any signatures they include to minimize the chance of unintentional replay attacks between different transaction types.
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`. Transactions **SHOULD** include the `TransactionType` in any signatures they include to minimize the chance of unintentional replay attacks between different transaction types. The transaction hash of all transactions **MUST** be `keccak256(rlp([TransactionType, Payload]))`
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.
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 signed/processed/handled exactly the same as legacy transactions were processed/handled.
Between `FORK_BLOCK_NUMBER - 1` and `FORK_BLOCK_NUMBER` clients **SHOULD** wrap all transactions in their local pending pool as type 0 transactions. Clients **MAY** choose to flush their pending pool instead, if it is not possible to do the wrapping in time for the next block, though this is discouraged.
As of `FORK_BLOCK_NUMBER`, clients **SHOULD** accept incoming transactions over user/application facing APIs such as JSON-RPC in both the new wrapped format and the legacy format. If a legacy format transaction is received, the client **MUST** wrap it in a type 0 envelope before sending it over devp2p or including it in a block.
## Rationale
### TransactionType high bit
@ -39,9 +43,13 @@ By having the second item of the array just be opaque bytes, rather than a list,
We could have chosen the format `rlp([TransactionType, ...])` where `...` represents whatever items the transaction wants. This format however would require us to remain vigilant in the future about using the shape of the transaction to identify its type, as it is possible that there could be an overlap between an EIP-2718 transaction type and a legacy transaction type with a nonce that matches the `TransactionType`. By having a strict 2-item array with the second item potentially being an encoded list, we avoid needing to worry about any conflict between TransactionTypes beyond choosing uinque numbers.
### ORIGIN and CALLER
There was discussion about having ORIGIN and CALLER opcodes be dependent on the transaction type, so that each transaction type could define what those opcodes returned. However, there is a desire to make transaction type opaque to the contracts to discourage contracts treating different different types of transactions differently and there also were concerns over backward compatibility with existing contracts which make assumptions about ORIGIN and CALLER opcodes. Going forward, we will assume that all transaction types will have an address that reasonably represents a `CALLER` of the first EVM frame and `ORIGIN` will be the same address in all cases. If a transaction type needs to supply additional information to contracts, they will need a new opcode.
### Hashing the outer transaction
If you submit a transaction prior to the fork block and it is mined after the fork block, the transaction hash of the mined transaction will not match the the transaction hash of the transaction you originally submitted. This is because the mined transaction will be a wrapped one, while the submitted transaction will be unwrapped. Applications that use the transaction hash to lookup the transaction result will fail to ever find it or see it ever mined. Clients can optionally choose to track type 0 transactions internally by both hashes for a period of time so that lookups of the old hash won't fail for the user, but this is not required for consensus.
### Signing the inner transaction for type 0
While this EIP recommends that the envelope be included in any signatures, it also specifies that for Transaction Type 0 the envelope is not included in the signature. This EIP disobayes its own recommendation because we don't want all signing tools to break on the fork block and require updates to start working again.
## Backwards Compatibility
Clients can differentiate between the transaction types by noting that the RLP decoded transaction has 2 elements rather than 9.
Clients can differentiate between the legacy transactions and typed transactions by noting that the RLP decoded transaction has 2 elements rather than 9.
## Test Cases
TBD