EIP-5920: PAY opcode

jochem-brouwer · April 20, 2025, 4:20pm

Could someone review my two open PRs?

github.com/ethereum/EIPs

Update EIP-5920: add clarification to ban opcode in STATIC mode

master ← jochem-brouwer:pay-static

opened 05:22AM - 03 Apr 25 UTC

jochem-brouwer

+1 -0

This PR updates the PAY opcode PR such that it is self-consistent: currently, th…ere is no rule about what happens in a `STATIC` context (`STATIC` context/flag: https://eips.ethereum.org/EIPS/eip-214#specification). It is clear that using PAY in a `STATIC` context is usually not allowed (it changes state), but what about the case if the value sent is 0? I have followed the way that CALL handles this: if the value is zero, it is fine: if the value is nonzero and we are in a `STATIC` context then exceptionally abort.

github.com/ethereum/EIPs

Update EIP-5920: change to call-like functionality

master ← jochem-brouwer:pay-returnvalue

opened 05:28AM - 03 Apr 25 UTC

jochem-brouwer

+10 -3

This PR changes EIP-5920: - Mimics the behavior of CALL in terms of pushing i…tems to the stack - Changes the order of the semantics of the opcode a bit, and this matters, because if a transfer would not succeed before these changes, then the target address stays cold. This is not the case for CALL (it will warm). Please verify that: - [ ] When using the CALL opcode and it is tried to send more value than the current account, then the just-created call frame exceptionally aborts and 0 is pushed to the stack - [ ] When using CALL (the target address is cold) and the inner frame throws (for instance sending more value than in current account), the address-to-be-called is still in warm afterwards.