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

Update EIP-5920: expand the motivation a bit #7072

Merged
merged 2 commits into from
Sep 19, 2023
+5 −1
Merged

Update EIP-5920: expand the motivation a bit #7072

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
34a9fe0
expand the motivation a bit
charles-cooper May 25, 2023
23b35fb
fix lint
charles-cooper May 25, 2023
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
6 changes: 5 additions & 1 deletion EIPS/eip-5920.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,11 @@ This EIP introduces a new opcode, `PAY`, taking two stack parameters, `addr` and

## Motivation

Currently, to send ether to an address requires you to call a function of that address, which has a few issues. First of all, it opens a reentrancy attack vector, as the recipient can call back into the sender. Secondly, it opens a DoS vector, so parent functions must be cognizant of the possibility that the recipient will run out of gas or revert. Finally, the `CALL` opcode is needlessly expensive for simple ether transfers, as it requires the memory and stack to be expanded, the recipient's full data including code and memory to be loaded, and finally needs to execute a call, which might do other unintentional operations. Having a dedicated opcode for ether transfers solves all of these issues, and would be a useful addition to the EVM.
Currently, to send ether to an address requires you to call into that address, which transfers execution context to that address, which creates several issues:

- First of all, it opens a reentrancy attack vector, as the recipient can call back into the sender. More generally, the recipient can unilaterally execute arbitrary state changes, limited only by the gas stipend, which is not desirable from the point of view of the sender.
- Secondly, it opens a DoS vector. Contracts which want to send ether must be cognizant of the possibility that the recipient will run out of gas or revert.
- Finally, the `CALL` opcode is needlessly expensive for simple ether transfers, as it requires the memory and stack to be expanded, the recipient's full data including code and memory to be loaded, and finally needs to execute a call, which might do other unintentional operations. Having a dedicated opcode for ether transfers solves all of these issues, and would be a useful addition to the EVM.

## Specification

Expand Down