diff --git a/EIPS/eip-2718.md b/EIPS/eip-2718.md index e9bde56a7afab5..223295eb361a12 100644 --- a/EIPS/eip-2718.md +++ b/EIPS/eip-2718.md @@ -28,10 +28,6 @@ As of `FORK_BLOCK_NUMBER`, all transactions sent over devp2p or included in a bl 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`, the EVM opcode `0x32` (aka: `ORIGIN`, aka: `tx.origin`) will be colloquially renamed to `TRANSACTION_DATA`. The high 32-bits of the value will be the `TransactionType`, and the low 224-bits will be transaction type dependent. For `TransactionType` `0`, the low 224-bits will be the address recovered from the signature represented by `v, r, s`. - -As of `FORK_BLOCK_NUMBER`, the EVM opcode `0x33` (aka: `CALLER`, aka: `msg.sender`) will have its value for the initial call frame be determined by the transaction type. The high 32-bits of the value will be the `TransactionType`, and the low 224-bits will be transaction type dependent. For `TransactionType` `0`, the low 224-bits will be the address recovered from the signature represented by `v, r, s`. - ## Rationale ### TransactionType high bit Setting the high bit of the `TransactionType` so that a decoder could identify transaction type early on in the decoding process was discussed, but decided against. The problem with this solution is that due to the way RLP encoding works, this would result in the `TransactionType` being 5 bytes long rather than 1 byte long. RLP decoders also do not need to know the shape of the result before decoding, and thus in most (possibly all) clients it will be just be a matter of first decoding the RLP transaction, and then checking to see if the decoded result is a 2 item array or a 9 item array, which is likely simpler than checking the high bit of the first item. @@ -41,8 +37,8 @@ There was discussion about defining the `TransactionType` identifier assignment/ By having the second item of the array just be opaque bytes, rather than a list, we can support different encoding formats for the transaction payload in the future, such as SSZ or a fixed width format. ### `n`-item list instead of 2-item 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 Change -With the advent of multiple transaction types, it is possible that future transactions will not have an origin or caller that aligns well with the current concept of ORIGIN and CALLER. For example, a multisig transaction may have two recovered addresses or a sponsored transaction may have a separate caller and a gas payer. By having the high 32 bits be the transaction type, we can ensure backward compatibility with legacy transactions which use only the low 160-bits of the `ORIGIN` and `CALLER` by having the high bits be `0` for that transaction type. At the same time, we open the doors for future transaction types to define what `CALLER` and `ORIGIN` should be set to in ways that make sense for each transaction type. +### 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. ## 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.