EIP-5920 - PAY opcode

Abstract

This EIP introduces a new opcode, PAY, taking two stack parameters, addr and val, that transfers val wei to the address addr without calling any of its functions.

Motivation

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.
• The EXTCALL opcode does not provide a way to restrict gas.
• 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

Constants

Behavior

A new opcode is introduced: PAY (0xfc), which:

• Pops two values from the stack: addr then val.
• Charges the gas cost detailed below.
• Exceptionally halts if addr has any of the high 12 bytes set to a non-zero value (i.e. it does not contain a 20-byte address).
• Transfers val wei from the current target address to the address addr.
• Marks addr as warm (adding addr to accessed_addresses).

Gas Cost

The gas cost for PAY is the sum of the following:

• Is addr in accessed_addresses?
  • If yes, WARM_STORAGE_READ_COST;
  • Otherwise, COLD_ACCOUNT_ACCESS_COST.
• Does addr exist or is val zero?
  • If yes to either, zero;
  • Otherwise, GAS_NEW_ACCOUNT.
• Is val zero?
  • If yes, zero;
  • Otherwise, GAS_CALL_VALUE.

PAY cannot be implemented on networks with empty accounts (see EIP-7523).

Rationale

Argument order

The order of arguments mimics that of CALL, which pops addr before val. Beyond consistency, though, this ordering aids validators pattern-matching MEV opportunities, so PAY always appears immediately after COINBASE.

Halting for invalid address

The halting behavior is designed to allow for Address Space Extension. If the high bytes were truncated, as in CALL, contracts could depend on the truncating behavior. If the address space were extended beyond 20 bytes, PAY would either not be able to target those accounts, or code expecting truncation could send ether to the wrong address.

Because this behavior may be changed, contracts should not rely on this halting behavior and use other methods to intentionally halt (like the cheaper INVALID opcode).

Backwards Compatibility

This change requires a hard fork.

Security Considerations

Existing contracts should not rely on their balance being under their control, since it is already possible to send ether to an address without calling it, by creating a temporary contract and immediately SELFDESTRUCTing it, sending the ether to an arbitrary address. It is also possible to involuntarily fund an account using priority fees. However, this opcode does make this process cheaper and easier for already-vulnerable contracts.

Copyright

Copyright and related rights waived via CC0.