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 (#2742)

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-18 15:22:10 +08:00 committed by GitHub
parent 30731c1067
commit 50c86e1607
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
EIPS/eip-2718.md
View File

@ -41,7 +41,7 @@ We could have chosen the format `rlp([TransactionType, ...])` where `...` repres
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.
## Backwards Compatibility
Clients can differentiate between the transaction types by noting that the RLP decoded transaction has 2 elements rather than 9 or by noting that the second element is a list rather than a value.
Clients can differentiate between the transaction types by noting that the RLP decoded transaction has 2 elements rather than 9.
## Test Cases
TBD
@ -50,7 +50,7 @@ TBD
TBD
## Security Considerations
Due to the way RLP encoding works, the risk of a new transaction being mis-interpreted as a legacy transaction is deemed low. The authors of this EIP consider it unlikely that there are any transaction decoders in production that will accept a transaction with not enough elements (perhaps reading off the end of the array), or read the second item as a value when it is encoded as an array.
Due to the way RLP encoding works, the risk of a new transaction being mis-interpreted as a legacy transaction is deemed low. The authors of this EIP consider it unlikely that there are any transaction decoders in production that will accept a transaction with not enough elements (perhaps reading off the end of the array).
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).