Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Removes ORIGIN/CALLER stuff and adds rationale about why. #2735

Merged
merged 1 commit into from
Jun 17, 2020
Merged

Removes ORIGIN/CALLER stuff and adds rationale about why. #2735

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 2 additions & 6 deletions EIPS/eip-2718.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand All @@ -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.
Expand Down