Smart contract developers have been told for a long time to avoid using the
ORIGIN opcode and static analysis tools tend to warn when it is used. Most uses of it are people attempting to author contracts that disallow contract callers, which goes against the ethos of Ethereum (IMO) and goes against the idea that contracts can own and manage money. Contracts that disallow contract callers discourage the usage of smart wallets, which tend to have enhanced security features for end users thus preventing their usage decreases end-user security.
With the introduction of multiple types of transactions, it is possible that the definition of
ORIGIN may change over time, or differ between transaction types. EIP-2711 for example will likely assert that
ORIGIN is the
GAS_PAYER, rather than the
SENDER. One can imagine a multisig transaction type where multiple signatures control the operation of a single account, or rich transactions where an account with a private key can have a contract gating its operations. In these cases, what
ORIGIN means may vary slightly, and currently the EVM doesn’t have insight into the type of transaction.
0x32 to be
TRANSACTION_DATA, where the first 32 bits are the transaction type, and the remaining 224 bits are defined per
0 (wrapped legacy transactions), this would be backward compatible since currently
TRANSACTION_DATA would be an address, which has 96 leading
0 bits. For
1 (EIP-2177), the value would be something like
0x000000010000000000000000cafebabecafebabecafebabecafebabecafebabecafebabe where the first 32-bits is the
1 in this case) and the remaining 224 bytes would be an Ethereum address representing
GAS_PAYER. This would allow the EVM to both identify what type of transaction is running, and also have a small amount of transaction-type specific data available to it. Some transaction types may have no data, in which case it would just be 32 high bits containing the transaction type and the rest of the bits would be
This does potentially have a backward compatibility issue with existing contracts that reference
tx.origin, but since the high bits are the transaction type we don’t have to worry about collisions with actual addresses for anything other than legacy transactions, which would retain the old semantics of
ORIGIN means transaction signer.
For new type transactions, they’ll just fail all comparisons of
tx.origin and any Ethereum address. There is potential that there are contracts which store
tx.origin of some original caller and then require the same
tx.origin later. If a non-0 type transaction was used for the first and a 0 type transaction was used for follow-ups this won’t match. Also, if you do something like an EIP 7211 transaction you may end up with different
GAS_PAYERs and would not match.
Personally, I have lobbied long and hard against contracts that use
tx.origin for basically anything, so I don’t have a problem finally breaking people who have failed repeatedly to heed the warnings. Also, such contracts CAN just tell their users to only use legacy type transactions and they will continue to work, so it isn’t like we would be sticking people’s funds in a way that was unpreventable for existing contracts.