From 50c86e1607fff3965f1a83132f63c3bc78b806be Mon Sep 17 00:00:00 2001 From: Micah Zoltu Date: Thu, 18 Jun 2020 15:22:10 +0800 Subject: [PATCH] Automatically merged updates to draft EIP(s) 2718 (#2742) 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 --- EIPS/eip-2718.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-2718.md b/EIPS/eip-2718.md index 223295eb361a12..7e329984075f66 100644 --- a/EIPS/eip-2718.md +++ b/EIPS/eip-2718.md @@ -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/).