EIP-7645 Aliasing ORIGIN to SENDER (Alias ORIGIN to SENDER)
Hegota Declined for Inclusion · EVM & execution · EIP status Stagnant · created 2024-03-03
A proposal to change the EVM ORIGIN instruction so that, instead of the account that originally started the transaction, it returns the address of the immediate caller, that is, the same value as SENDER.
Why it is needed
The ORIGIN instruction returns the address of the account that originally started the transaction, while the SENDER (CALLER) instruction returns the address of the immediate caller. Distinguishing between the two can cause security problems such as phishing attacks, and its use has been discouraged since mid-2016. For example, if a contract that checks permissions with ORIGIN holds tokens or privileges, any transaction an ERC-4337 bundler (the entity that batches multiple user operations and submits them) processes in a bundle could hijack those privileges. This is because ORIGIN remains the bundler's address in sub-calls. Also, account abstraction attempts such as EIP-7377 and EIP-3074 must all first solve the problem of changing or working around ORIGIN. The source therefore regards ORIGIN as an obstacle to making Ethereum's account model more flexible.
What changes
Today
- ORIGIN (0x32) returns the address of the account that originally started the transaction
- Even in calls that pass through multiple steps, ORIGIN stays fixed to the original sender's address
- Logic that distinguishes the original sender from the direct caller can be abused for privilege theft such as phishing
After EIP-7645
- ORIGIN returns the same value as SENDER (0x33) in every execution context
- At each call step, ORIGIN changes to the address of the immediate caller
- The security hole that came from distinguishing the two values disappears, and a common obstacle to account abstraction is removed
Who is affected
- Contract developer: Contracts that used ORIGIN to get the transaction's starting address must be checked to confirm they still behave correctly under the new definition, and code that breaks must be worked around or avoided.
- Client teams: All clients must change the EVM so that, when ORIGIN is called, it pushes the current call's sender address onto the stack as if SENDER had been executed.
- Account abstraction ecosystem: The ORIGIN handling problem that every account abstraction proposal runs into disappears, which simplifies the design.
- Users: Legacy code that misuses ORIGIN may be affected by this change, so guidance to avoid such code may be needed.
In depth
Definition change: 0x32 returns the same value as 0x33
Currently the ORIGIN opcode returns the address that originally started the transaction. Under this EIP, the ORIGIN opcode (0x32) MUST return the same value that the SENDER (also called CALLER) opcode (0x33) returns in every execution context. In other words, it does not remove the ability to track the original sender itself; rather, it makes ORIGIN an alias of SENDER so that the two opcodes always produce the same value. In a simple transaction with no hops the two values are already the same today, so what actually changes is the multi-hop case where a contract calls another contract in turn.
EVM implementation and transaction validation
All Ethereum clients MUST change the EVM so that, when the ORIGIN opcode is called, it pushes the current call's sender address onto the stack as if the SENDER opcode had been executed. Transaction validation works exactly as it does now, and apart from the opcode behavior defined above, nothing changes in transaction structure or processing logic. The design confines the change to a single opcode inside the EVM. The source asks implementers to give feedback on this specification and to report problems found during implementation or testing.
Three rationales: account abstraction, security, technical debt
The source gives three rationales. First, it promotes account abstraction. It cleanly removes a barrier that every account abstraction attempt runs into, enabling a more flexible account model. Second, it strengthens security. It removes vulnerabilities that arise from distinguishing the original sender from the direct caller. Third, it cleans up technical debt. By removing a feature that has long been discouraged, it simplifies the EVM's transaction and execution model and makes future changes easier and safer.
Backwards compatibility: not complete
This change is not fully backwards compatible. Contracts that rely on the distinction between ORIGIN and SENDER for logic or security are affected. The specification therefore requires (MUST) that contracts using ORIGIN to get the transaction's starting address be checked to confirm they still behave correctly under the new definition, and that those that break be worked around or avoided. The source regards this incompatibility as necessary progress, citing that ORIGIN use has long been discouraged, that the impact is small, and that any account abstraction solution must eventually deal with ORIGIN.
Test cases: direct and multi-hop checks for four call types
For each of CALL, STATICCALL, DELEGATECALL, and CALLCODE, two things are checked. In a direct call (Direct), the check is that ORIGIN and SENDER produce the same value in the target contract. In a simple transaction with no hops they are already the same today. In a multi-hop call (Multi-hop), the check is that ORIGIN and SENDER produce the same value in every call frame of a transaction that passes through multiple steps.
Security considerations: possible blanket ban on ORIGIN
Aliasing resolves the specific security vulnerabilities associated with the ORIGIN opcode. The source adds, as a matter outside the scope of this EIP, that banning the use of ORIGIN altogether may be wise to further reduce misunderstanding and misuse. It names changes to tooling outside the EVM, or reverting deployments of contracts that use ORIGIN inside the EVM, as possible methods. It notes that no clear example of existing misuse made worse by aliasing has been identified yet, but that users may need to be educated to avoid such legacy code.
Current status: Stagnant, also dropped from the fork
The source status is Stagnant. Progress has been stalled for a long time and discussion has stopped, and unless it is reactivated it may not be adopted as is. In the core developer calls as well, ACDE #245 on 09.10 dropped EIP-7645 from the Hegota fork scope along with EIP-2488, EIP-8219, and EIP-8182. All four received unanimous low ratings (0.0 to 0.8) from every client.