Add EIP: Alias ORIGIN to SENDER #8283
Conversation
github-actions
bot
added
c-new
|
✅ All reviewers have approved. |
eth-bot
added
e-consensus
eth-bot
changed the title
| @@ -0,0 +1,73 @@ | |||
| --- | |||
| eip: TBD | |||
There was a problem hiding this comment.
| eip: TBD | |
| eip: 7645 |
Assigning next sequential EIP/ERC/RIP number.
Numbering changed to sequential from 7500.
Please also update the filename.
|
The commit 9c861d5 (as a parent of e11aac3) contains errors. |
|
|
||
| ## Abstract | ||
|
|
||
| This EIP proposes aliasing the ORIGIN opcode to the SENDER opcode within the Ethereum Virtual Machine (EVM). The purpose of this change is to move Ethereum closer to enabling account abstraction by harmonizing the treatment of externally owned accounts (EOAs) and smart contracts and to address the security concerns associated with the use of ORIGIN that have and will continue to surface in all or most account abstraction proposals. |
There was a problem hiding this comment.
| This EIP proposes aliasing the ORIGIN opcode to the SENDER opcode within the Ethereum Virtual Machine (EVM). The purpose of this change is to move Ethereum closer to enabling account abstraction by harmonizing the treatment of externally owned accounts (EOAs) and smart contracts and to address the security concerns associated with the use of ORIGIN that have and will continue to surface in all or most account abstraction proposals. | |
| This EIP proposes aliasing the `ORIGIN` opcode to the `SENDER` opcode within the Ethereum Virtual Machine (EVM). The purpose of this change is to move Ethereum closer to enabling account abstraction by harmonizing the treatment of externally owned accounts (EOAs) and smart contracts and to address the security concerns associated with the use of `ORIGIN` that have and will continue to surface in all or most account abstraction proposals. |
Add backticks to the rest of your proposal too please.
|
|
||
| For instance, if an [ERC-4337](./eip-4337.md) bundler has tokens or other authority in a smart contract determined by ORIGIN, any of the transactions it bundles can hijack this authority since ORIGIN remains the bundler address throughout each child transaction. | ||
|
|
||
| More apropos in the current context of EVM evolution, the differentiation between the ORIGIN and SENDER opcodes presents a challenge for all account abstraction efforts, such as those outlined in [EIP-7377](./eip-7377.md) and [EIP-3074](./eip-3074.md), because any move towards account abstraction must address the ORIGIN opcode's role, either by modifying or completely bypassing it. Without addressing this, the ORIGIN opcode stands as a barrier to the evolution of Ethereum's account model towards greater flexibility and functionality. |
There was a problem hiding this comment.
Just a heads up, linking to non-final proposals will prevent yours from advancing.
There was a problem hiding this comment.
I'll remove the references to 7377 and 3074, but why is EIP-4337 still "draft" if it's in use today?
|
|
||
| Transaction Validation: Transactions MUST be validated as before, with no changes to the transaction structure or processing logic beyond the EVM opcode behavior specified above. | ||
|
|
||
| Compatibility: Smart contracts relying on the ORIGIN opcode for obtaining the transaction initiator's address MUST be reviewed to ensure they function correctly under the new definition and worked-around or avoided if this EIP introduces breaking changes. |
There was a problem hiding this comment.
Please move this section to the Backwards Compatibility section. This standard can't really change behaviour of already deployed contracts.
|
|
||
| Compatibility: Smart contracts relying on the ORIGIN opcode for obtaining the transaction initiator's address MUST be reviewed to ensure they function correctly under the new definition and worked-around or avoided if this EIP introduces breaking changes. | ||
|
|
||
| Implementers are encouraged to provide feedback on this specification and report any potential issues encountered during the implementation or testing phases. |
There was a problem hiding this comment.
Proposal should be written as if they are already final. Assuming this proposal is accepted, this line won't make sense 10 years from now.
| The rationale behind aliasing ORIGIN to SENDER is to: | ||
|
|
||
| Facilitate Account Abstraction: Elegantly nullify a universal barrier to account abstraction, enabling more flexible and powerful account models in Ethereum. | ||
|
|
||
| Enhance Security: Eliminate the security vulnerabilities associated with differentiating between the original transaction initiator and the immediate caller. | ||
|
|
||
| Clean up tech debt and simplify the EVM Model: Reduce the complexity of the EVM's transaction and execution model by removing an outdated and deprecated feature, making future changes easier and safer. | ||
|
|
There was a problem hiding this comment.
This reads as Motivation, not Rationale. The Rationale section should explain technical choices made in the EIP.
There was a problem hiding this comment.
If all the existing documentation around tx.origin is considered, I think it becomes quite clear that this change is not needed. I have yet to see a resource that does not explicitly state tx.origin should generally not be used.
We should not assume account abstraction ever goes to 100% usage (and it is far from it now). And since that's the case, tx.origin still does have niche use-cases, like checking which address paid for the transaction.
In other words, I think this change would cause more confusion than it solves.
|
@mattstam please leave technical comments like this one on the discussion thread. Pull request comments tend to get lost when the pull request gets merged. |
This has been part of the discussion around account abstraction.