EIP-5920: PAY opcode

[Pandapip1]

EIP-5920: PAY opcode

Although I am an EIP editor, I do not specialize in core EIPs, and this is my first core EIP. Any feedback is appreciated!

[axic]

There are a number of such proposals, the latest one being

EIP-5065 Instruction for transferring ether

Abstract Add a new instruction that transfers ether to a destination address without handing over the flow of execution to it. It should work similarly to how SELFDESTRUCT transfers ether to the destination without making a call to it. Motivation From an architectural point of view, execution flow should never be handed over to an untrusted contract. Ethereum currently does not have any ideal way to transfer ether without transferring the flow of execution. People have come up with reentrancy…

[Pandapip1]

EIP-5065 is Stagnant (and should have been stagnant when you sent that message - it wasn’t due to an EIP-bot bug). In addition, there are quite a few issues with the linked EIP, such as the hexadecimal being invalid. I’ll ping @maxsam4, and move this EIP to review if there isn’t a response in two weeks.

[Pandapip1]

There has not been a response in >14 days. @axic would you mind taking a closer look before I move this to review?

[Pandapip1]

Adding the cancun-candidate tag.

[mikebolt]

Could we throw in a burn opcode too? There is an actual benefit to having one because you could leave the address out and it would shorten the contract bytecode.

If you search on solidity forum I suggested send and burn keywords. These could be the opcodes generated by those keywords.

[Pandapip1]

According to the current spec, sending ether to address(0) is currently allowed. How about we make that a special case that burns ether?

EDIT: Done

[mikebolt]

I think the EVM implementations could subtract the amount from the balance of the burner without adding it to the balance of the 0 address (or other burn address), which would be very slightly more efficient.

[Pandapip1]

That’s what I just added:

• Transfers val wei from the executing address to the address addr. If addr is the zero address, instead, val wei is burned from the executing address.

[horsefacts]

I’m a big fan of this idea and the earlier EIP-5065. Any insight as to why these earlier proposals stagnated?

[Pandapip1]

The author went AWOL, and the proposal also had some issues, such as assigning the opcode to the “hexadecimal” value 0xFG. Ceci n’est pas hexadecimal.

[Tointer]

I support this EIP because:

1. Reentrancy attacks are very frequent and dangerous, reducing attack surface for them is great
2. It is consistent with ERC20 tokens, most of which not providing any ability to react to balance changes. It’s common (and costly) practice to wrap ether into WETH and transfer it this way.
3. Gas optimizations are nice, especially for smart contract wallets. This would also stack nicely with eip-3651
4. I don’t see that much use cases in having contracts being able to fully control their ETH balance in post-SELFDESTRUCT EVM
5. Creating opcode that would guarantee succesfull transfer through all hardforks would resolve confusion about different ways to send ether that exist today

[shemnon]

I’d like to raise a concern for this OPCODE, and ask the authors solicit the advice of Solidity devs and some sampling of security auditors before this proceeds to be eligible for inclusion in Cancun.

Using the PAY opcode would enable bypassing the fallback functions of smart contracts, and the default coding of non-payable functions is to revert on function calls unexpectedly sending Ether to a smart contract. This subverts that protection. It is possible for a smart contract to configure itself so that no valid invocation results in Ether being deposited in the account. The motivation section of the EIP speaks to stoping reentrancy attacks, but a smart contract could configure their fallback function to accept payment and exit if they desired that ability. Enabling the PAY opcode prevents contracts from rejecting all payments.

One alternative to preserve this behavior would be to allow PAY to only work when sending value to accounts with no code in their account, but that isn’t much different from the existing CALL mechanisms.

Another concern is the gas schedule, it is not in harmony with the warm account/cold account pattern established in EIP-2929 (which it cites) and instead proposes a different handling. If it proceeds I would ask the gas be set up as a premium (100 gas or so) on top of the warm/cold cost, and that it interacts with the warm/cold lists like the CALL and SSTORE series opcodes do. Specifically, i think adopting the gas pattern used in CALL would be the best pricing strategy and present the most maintainable code for clients.

[Pandapip1]

@shemnon

Using the PAY opcode would enable bypassing the fallback functions of smart contracts, and the default coding of non-payable functions is to revert on function calls unexpectedly sending Ether to a smart contract. This subverts that protection.

It’s already possible to do this with SELFDESTRUCT and coinbase payments, as mentioned in the motivation. This introduces no new security concerns.

See SWC-132 - Smart Contract Weakness Classification (SWC)

@shemnon

Another concern is the gas schedule, it is not in harmony with the warm account/cold account pattern established in EIP-2929 (which it cites) and instead proposes a different handling. If it proceeds I would ask the gas be set up as a premium (100 gas or so) on top of the warm/cold cost, and that it interacts with the warm/cold lists like the CALL and SSTORE series opcodes do. Specifically, i think adopting the gas pattern used in CALL would be the best pricing strategy and present the most maintainable code for clients.

As mentioned in the specification, the EIP-2929 costs are applied.

[shemnon]

As mentioned in the specification, the EIP-2929 costs are applied.

New account costs are not being applied (25K when paying to an address with an empty account)

[Pandapip1]

@shemnon

New account costs are not being applied (25K when paying to an empty address)

Are they not? Oops then, I’ll fix that.

[mikebolt]

This is a good point but I would argue that fallbacks are potentially dangerous and should be deprecated. However, this should definitely be noted as a big caveat in the documentation for the new PAY opcode.

[asdnlasdlkj]

What reason would someone have to burn ETH?

[Pandapip1]

Beats me. Now that I think about it, it would probably make more sense for the call to fail, to avoid potential bug-related losses.

[asdnlasdlkj]

It’s probably best not to make any kind of special exemption for the zero address, that’s how all the call opcodes already operate