EOF Implementers Call #60

[poojaranjan]

Meeting Info

Oct 16, 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
• EVM (EOF) Taxonomy
• 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
  • Implementation Matrix
• Solidity + EOF POC summary
• Matrix on evmobjectformat.org
• Prev meeting notes

Agenda

• Testing updates
  • Osaka-0 in two weeks: Pectra-devnet-4 + EOF as it stands now
  • All clients need to be able to activate Osaka in 2 weeks
• Client updates
• Compiler updates
• spec for OSAKA-devnet-1 (target 2025 launch)
  • EIP-721 compatability - EXTCODE / HASCODE EIP-7761
  • ship as spec
  • Maybe just expose EXTCODE
  • Maybe change retrun from 0-no / 1-yes to opode= ACCOUNTTYPE 0 - EOA, 1 - Legacy Contract, 2 - EOF (3 - 7702 delegate?)
  • EXT*CALL return codes
  • change to 0 success, 1 - REVERT opcode called, 2 - Error in call sequence, 3 - some other HALT (OOG, Static, etc)
  • EOFCREATE hashing
  • remove hash over subcontainer for address
• Spec updates
• Other items
  • Standard Trace EIP-7756
    • Change PC to be zero based from container, not codesection 0
    • rename function depth
    • have immediate contain full RJUMPV table
  • EXTDELEGATECALL allowed to call Legacy
  • Add EXTDATACOPY and EXTDATASIZE

Please add other agenda items or links to discuss.

Next call on Oct 30, 2024

[frangio]

Other potential things to reconsider for Osaka:

• Enabling EXTCODE* instead of adding HASCODE
• Allowing EXTDELEGATECALL from EOF to non-EOF
• Adding EXTDATACOPY (and EXTDATASIZE?)

[shemnon]

Can we move testing to the top of the agenda?

testing

• Osaka-0 in two weeks: Pectra-devnet-4 + EOF as it stands now
• All clients need to be able to activate Osaka in 2 weeks

client updates compiler updates

spec for OSAKA-devnet-1 (target 2025 launch)

• EIP-721 compatability - EXTCODE / HASCODE EIP-7761
  • ship as spec
  • Maybe just expose EXTCODE
  • Maybe change retrun from 0-no / 1-yes to opode= ACCOUNTTYPE 0 - EOA, 1 - Legacy Contract, 2 - EOF (3 - 7702 delegate?)
• EXT*CALL return codes
  • change to 0 success, 1 - REVERT opcode called, 2 - Error in call sequence, 3 - some other HALT (OOG, Static, etc)
• EOFCREATE hashing
  • remove hash over subcontainer for address

Other

• Standard Trace EIP-7756
  • Change PC to be zero based from container, not codesection 0
  • rename function depth
  • have immediate contain full RJUMPV table
• EXTDELEGATECALL allowed to call Legacy
• Add EXTDATACOPY and EXTDATASIZE

[MariusVanDerWijden]

I won't be able to make the call, but from my pov I don't think we should compromise on the spec to support HASCODE/Other types of checks to know whether something is an eoa or not. There is no real reason to differentiate between EOAs and Contracts imo, especially now with 7702

[danceratopz]

• Latest EOF fixture release on Osaka (including Prague at devnet-3): https://github.com/ethereum/execution-spec-tests/releases/tag/eip7692%40v2.0.0
• Online docs for Osaka Tests (versioned at main): https://ethereum.github.io/execution-spec-tests/main/tests/osaka/

[shemnon]

Testing

• Pectra-devnet-4 is occuping most of the test teams time
• Will merge new test, EOF WRap tool
• Client need to start activating on osaka
• Osaka fixture are published
• 7702 coverage needs delegation testing, should be in fixtures. Will add more as needed

Clients & Compilers

• Nethermind passing Up to v1.1.0 tests
• revm - need to propagate osaka fork and release
• Geth - RSVPed abent
• evmone - no updates - need to add osaka fork
• Besu - oska is published in main, fixed callf bug found checking traces

Spec updates

• EIP-721 - HASCODE / EXTCODESIZE
  • Frangio wants to re-enable EXTCODE opcodes to avoid risk, opcodes will happen via legacy contacts if not added, so we may as well add it.
  • Marius doesn't want to compromise on removing introspection, 7702 and migration may make EOAs irrelevant
  • Separate from 721 the inability to determine if code lis legacy will break proxyies.
  • Danno - We can still jumper out to legacy contracts to use EXTCODE* to get the answers we want from HASCODE
  • Frangio would want EXTCODE brought in as-is, this still preserves opaqueness for EOF code
  • Charles - EOAs can never revert and return data, that is how it is detected.
  • ipsilon - agrees with Marius on keeping removing introspection in, but if not an option HASCODE is preferable to EXTCODE*
  • Frangio - without this we will never be able to migrate legacy without some facility like EXTCODE
  • ben - HASCODE is just checking a code attribute like we already do when executing EOF vs. non-EOF code. These are not deep introspections, doesn't violate the code/memory barrier. Current handling of EXTCODE doesn't violate the introspection for EOF code, and can be circumvented via legacny contract calls.
  • frangio - understands ZK motivation, but needs more clarification on how HASCODE/EXTCODE breaks the ZK motivations.
  • charles HASCODE does not preculed AA future, just all accoutns will return true

EXT*CALL return codes

• add new return code to clarify when a failure occured
• Pawel - motivation was that solidity wanted to know when a user caused a REVERT, and to behave differently. In process of implementing light errors were joined in with revert (to prevent some info leaks relating to gas introspection? i.e. failures relating to reserved gas returning a 2 could be used to divine gas levels)
• Charles - reverts can be detected with exiting return buffer,
• We should confirm with solidity this is useful.
• Charles - also, this allows for callstack introspection to determine that failure is callstack related.,
• danno/pitor - but 63/64ths rule would require billions of gas to reach the callstack limit.
• Current spec is 1 - not all gas consumed 2 - all call gas was consumed.

EOFCREATE hashing

• Goal is to reduce number of hashing calls needed, right now there is a double hashing per call.
• Discussions are ongoing on discord.
• Will come back in two weeks.
• Wants to be able to predict addresses from physical code
• Want collision-free addresses
• container path may be the solution instead of simple container offset for current container.

Other

• Tracing
  • Danno wants PC=0 is start of container
  • evmone - starts from pc=0, it's easier for a global pc counter. PC=0 is section 0 byte 0. It's a pointer in evmone, so it's all math in the trace anyway
  • dragan - can work either way
  • Ben - makes sense
  • Pitor - container = 0 allows for impossible PCs to exist. Code section 0 prevents impossible PC indexes from showing up in traces.
  • PC=0 at section 0 also helps indicating where a new call starts, apart from depth increasing.
  • More consistent with legacy
  • evmone - pc=0 at section 0, section 1 offset
  • reth pc=0 at section 0, section 1 is zeroed
  • nethermind pc=o at section 0, section 1 is zered.
  • continuous PC (section1 bytes 0 != 0) is needed for fuzzing.

EOF quality of life list from ipsilon https://github.com/ipsilon/eof/issues/165

[poojaranjan]

Closing in favor of #1184

[poojaranjan]

Recording: https://youtu.be/FLtlemN2W8w

[frangio]

I won't be able to make the call, but from my pov I don't think we should compromise on the spec to support HASCODE/

@MariusVanDerWijden We discussed this quite a bit in the call (https://youtu.be/FLtlemN2W8w?t=715). It's not clear in what way having HASCODE is compromising on the spec. It'd be great to hear more from your take on this.