EOF Implementers Call #48

[poojaranjan]

Meeting Info

May 29, 2024 , 15:00 UTC

Duration: 60 minutes

Zoom: https://us02web.zoom.us/j/88940506383?pwd=aTdsbHVyMTNDSUFHYmhTWlI2ZEVldz09

📅 Subscribe to the Ethereum Protocol Call calendar for calendar invites

Resources

• Current specs
  • EIP-7692: EVM Object Format (EOFv1) Meta
  • EIPs Included
    
    EIP-3540: EOF - EVM Object Format v1
    EIP-3670: EOF - Code Validation
    EIP-4200: EOF - Static relative jumps
    EIP-4750: EOF - Functions
    EIP-5450: EOF - Stack Validation
    EIP-6206: EOF - JUMPF and non-returning functions
    EIP-7480: EOF - Data section access instructions
    EIP-663: SWAPN, DUPN and EXCHANGE instructions
    EIP-7069: Revamped CALL instructions
    EIP-7620: EOF Contract Creation
    EIP-7698: EOF - Creation transaction
• EOF Meeting Playlist
• EOF explainers on PEEPanEIP
  
  EVM Object Format (EOF) with Danno Ferrin
  EVM Object Format (EIP-3540 & EIP-3670) with Andrei Maiboroda, Axic & Pawel
• EOF Testing Coverage Tracker
• [Prev meeting notes]

Agenda

• Client updates
• Compiler updates
• Spec updates
  • collect objections to / make final call on the RETURNDATACOPY modification (using same opcode) feat: change oob behavior of RETURNDATALOAD and RETURNDATACOPY ipsilon/eof#90
  • final call on whether we make changes to the creation tx being validated in initcode mode or not Allow RETURN/STOP in EOF creation tx code ipsilon/eof#119 / Have creation transactions run in runtime mode ipsilon/eof#118
  • Extended EXT*CALL return codes: detect account without code: Extended EXT*CALL return codes: detect account without code ipsilon/eof#117 (requrested by the Solidity team)
• Testing updates
• Other items

Please add other agenda items or links to discuss.

[pdobacz]

Some items to add to the agenda. Spec updates:

• collect objections to / make final call on the RETURNDATACOPY modification (using same opcode) feat: change oob behavior of RETURNDATALOAD and RETURNDATACOPY ipsilon/eof#90
• final call on whether we make changes to the creation tx being validated in initcode mode or not Allow RETURN/STOP in EOF creation tx code ipsilon/eof#119 / Have creation transactions run in runtime mode ipsilon/eof#118
• Extended EXT*CALL return codes: detect account without code: Extended EXT*CALL return codes: detect account without code ipsilon/eof#117 (requrested by the Solidity team) (notes from the call in the issue 117)

[marioevz]

Testing:

We want to create custom pre-releases and versioning for features such as EOF and Verkle, which are actively being worked on, but have not been signaled to be included in a Prague devnet.

• We want to create a custom tag to be able to automatically package the tests and make a pre-release in a more automated fashion, and it will be like "[email protected]"
• We also want to create a custom changelog (CHANGELOG_EOF.md) for all things included in this prerelease, once the feature makes it into the devnet schedule, we can point to the custom changelog to show all previous changes and history
• We want to create a custom fork, for example EOF, and this fork will appear as "prague" the transition tool (or any fork name it's given), but it's important to be able to not fail filling if something like the "requests_hash" is not present in the information returned from the transition tool.

[shemnon]

Decision on EOF testing

• EOF Code is presumed to be in runtime mode
• If a flag (TBD) is present in the EOF tests, then the code is in initcode mode
  This allows for testing to make intelligent use of the valid EOF containers in blockchain tests.

[shemnon]

Call was generally favorable to Mario's testing suggestions without any notable objection.

One request is to have the naming FORK+EIP - such as Cancun+7692
Multiples would be EIP/RIP numbers, in order. Cancun+615+1057+7692

[shemnon]

We will revisit ipsilon/eof#118 in next weeks agenda.

[shemnon]

Danno's take on #118 - It causes problems with (a) storage and (b) nonce-based addresses.

For storage, the runtime could read/write storage from an EOA, which is an ongoing issue with EIP-7702. We don't want to be mis-alighed with their decisions.

For nonce-based addresses, the returned contract address from the create tx call will not have a contract at it, as the EOFCREATE call would create a different contract ad a salt based address. This for sure broke older dev tooling that assumed the contract address was nonce based from the account and never checked the transaction receipt, some may still do that when polling the address for info from RPC. It also makes repeated deployements difficult as we would have to chagne the salt on each call.

We would either introduce inconsistencies with legacy without need or we would need to re-work some assumptions, such as allowing EOFCREATE to inherit the calling address if it is a create transactions, which feels just as hacky as it sounds.

[diega]

@poojaranjan Hi, is there a recording for this one?

[poojaranjan]

@diega
https://youtu.be/zteyvDI_BHc

[poojaranjan]

Closing in favor of #1055