EOF Implementers Call #61

[poojaranjan]

Meeting Info

Oct 30, 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

• Client updates

• Compiler updates

• Spec Updates (cover items not addressed in EOF Implementers Call #60 #1167)

  • EXT*CALL return codes
  • EOFCREATE Hashing: EOFCREATE: Don't hash the init-container ipsilon/eof#162
  • Modify max_stack_height of type section ipsilon/eof#134
  • Align EOFCREATE stack args with EXTCALL ipsilon/eof#156
  • Update eof.md - rename RETURNCONTRACT to RETURNCODE ipsilon/eof#164 rename RETURNCONTRACT
  • EXTDATACOPY
  • Don't forget last weeks discussion, but we won't be moving on those until after devcon
    • HASCODE/EXTCODESIZE

• Other

  • Tracing
    • PC for Code Sections

Please add other agenda items or links to discuss.

Next call on Nov 13, 2024 ??

[shemnon]

• Testing
• Client and Compiler updates
• Spec Updates (cover items not addressed in EOF Implementers Call #60 #1167)
  • EXT*CALL return codes
  • EOFCREATE Hashing: EOFCREATE: Don't hash the init-container ipsilon/eof#162
  • Modify max_stack_height of type section ipsilon/eof#134
  • Align EOFCREATE stack args with EXTCALL ipsilon/eof#156
  • Update eof.md - rename RETURNCONTRACT to RETURNCODE ipsilon/eof#164 rename RETURNCONTRACT
  • Don't forget last weeks discussion, but we won't be moving on those until after devcon
    • HASCODE/EXTCODESIZE
• Other
  • Tracing
    • PC for Code Sections

[frangio]

Perhaps we should at least briefly touch on EXTDATACOPY.

[shemnon]

• Testing

• Clients

  • Nethermind -
    • merged osaka fixes,
    • based off of prague / main
  • reth
    • has osaka wired in,
    • Fixed one bug with precompiles and EXTDELEGAGECALL
  • evmone transition to osaka is larger than expected
    • Migrated all ethereum/tests state tests over to EEST
    • EOF validation tests are not moved over yet
    • Some evmone tests are not ported yet - EVMONE v13 tests
  • Besu
    • osaka ready in main
    • prague-3/4 - based on where main besu gets to

• Spec Changes

  • EXT*CALL
    • discuss after devcon
  • EOFCREATE hashing
    • multiple initcode contexts are creaed
    • Using container address only works for first level, not nested creates
    • create transaction - sender has no code so container address won't work
    • Not always possible to point to a "physical address" of the container holding the initcode
    • Maybe omit address, and still hash subcontainer when it cannot be proved, but computation time is different in two scenarios
    • Goal is to reduce extra hashing
    • Useful property is to prove code came from a specific code (not just address)
    • Is it possible to defeat polymorphic code?
    • Should auxdata be included?
  • Change max stack height - to be stack needed in addition to inputs
    • makes the two fields (inputs / max stack) unrelated, rather than max >= inputs
    • rename the field from max_stack_height to... max_stack_increase
    • EEST has some auto-calculations we could leverage, client unit tests would incur ~4h work
    • Quality of Life fix, can miss if we are shipping Q1, but if we had 6 more months would be worth looking into for devnet-1
  • Re-order EOFCREATE to match EVMCALL
    • same QoL level of effort. Can miss, but if we have time worth adding.
    • Feels "small"
    • Valuable for tooling and developers manually debugging code, to not have to swap elements
  • Rename RETURNCONTRACT to RETURNCODE
  • Zero client impact, opcode stays the same
  • Documentation changes only
  • QoL for devnet-1
  • Please comment on EXTCODE* after devcon (//TODO add link)
  • EXTDATACOPY and EXTDATASIZE (//TODO add bug link)
    • Target memory? SSTORE2 will use return buffer
    • When SSTORE2 is used in this context really we are talking about just the read side, not write
    • Question now is smart contract read methods equivelantly good.
    • How does it handle legacy and delegate contracts? Read like EXTCODECOPY? Zeros? fault?
    • Would EXTDATALOAD be needed too? (no EXTCODELOAD...)
  • DELEGATECALL to legacy
    • If we fail we need to be able to detect legacy contracts safely and easily
    • Could we further tweak SELFDESTRUCT to behave differently when a delegate of EOF?

[shemnon]

Cancel the call on the 13th, next call 27 Nov at 1500 GMT

[poojaranjan]

Closing in favor of #1192