feat(tests): eip-5920 pay opcode cases

[spencer-tb]

🗒️ Description

Assumes that EIP-5920 will be in Osaka.

Uses a temp EELS resolution to fill:

• https://github.com/spencer-tb/execution-specs/tree/spec/eip-5920

Still a WIP.

Rebased on #1507 hence requires it.

🔗 Related Issues

N/A

✅ Checklist

• All: Set appropriate labels for the changes.
• All: Considered squashing commits to improve commit history.
• All: Added an entry to CHANGELOG.md.
• All: Considered updating the online docs in the ./docs/ directory.

[jochem-brouwer]

Linking for completeness: ethereum/EIPs#9590

[gurukamath]

Just want to highlight the following

• A new EELS PR with EIP-5920 implementation for Osaka is up

• I would like to add the following to the list of relevant test cases

  • Trying to transfer non-zero value in static context
  • Trying to transfer zero value in static context
  • Trying to transfer zero value to a non-existent account
  • Trying to transfer higher value than the balance to a non-existent account

[jochem-brouwer]

Wanted to drop a quick note here from the EIP (this has been in there for a long time):

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

This is nice, because it means we don't have to deal with "touched" accounts and cleaning up the whole mess a la EIP-161. And this thus saves us rather big and nasty test situations.

The only thing we should strictly check though (in a simple test) is that if you PAY with 0 that if this gets used on a non-existing account, it will also leave it as non-existing account (and thus not leave an empty account in the trie).

[spencer-tb]

Closing. Can come back to this if PAY gets CFI'd.