EOF Implementers Call #62

[poojaranjan]

Meeting Info

Nov 27, 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
• Other
  • Separate contract metadata data section Ref: here
  • alternative proposed EOFCREATE hashing scheme EOFCREATE: Don't hash the init-container ipsilon/eof#162 (comment)

Please add other agenda items or links to discuss.

Next call on Dec 11, 2024

[kuzdogan]

Proposing the agenda item "separate contract metadata data section"

TLDR: We believe it'd make sense to have a data section for contract metadata: data that won't be used by and is unreachable to the contract's code.

Our main use case is the Solidity's contract metadata hash + the Solidity version, which are appended to the bytecode in CBOR encoding (See it in action at playground.sourcify.dev). This wouldn't be the only use case as other languages and tools might want to add various metadata to the contract's bytecode.

With its current form putting any metadata in the data section would cause changes in the contract's code because of shifting offsets. Any change in the contract metadata should not cause changes in the code. This is particularly important for source code verification, which is sensitive to changes in the bytecode. Having a designated place for the metadata would also make things a lot easier for verifiers, as this data has to be omitted during verification and it's difficult to find where it is in the bytecode (See the blog post for more info)

cc: @cameel @ekpyron

[pdobacz]

I'd like to discuss an alternative proposed EOFCREATE hashing scheme ipsilon/eof#162 (comment)

Also pls reopen, this call is scheduled for today

[frangio]

I'd also like to discuss generic factory contracts.

[shemnon]

Here's the list of potential Pectra-0 upgrades, for reference. I don't think we need to re-hash any of it until osaka-0 launces

• 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

[shemnon]

One idea for a tempurature check: change the data section number to something higher like 0x7f or 0xff, so it will always sort near or at the end of section numbers.

[shemnon]

Also, state tests with invalid EOF, what to do?

[shemnon]

Testing Update

• How to handle State tests with invalid EOF?
  • state tests - reject test if any EOF is invalid
  • Block tests - only an issue in genesis? Abort if EOF in genesis is invalid.
  • Imported blocks - presume valid as create TXes are how they are added, so invalid EOF should result in an failed transactions.
  • Extends to 7702 - 0xEF01 validation?
• EOFWrap Tests
  • ports over legacy tests into EOF if it ports, stopgap for full testing
  • feat(tests): port ethereum/tests test cases (tracking issue) execution-spec-tests#972 will ultimately port all old tests

Client and Compiler Updates

• No client Updates, mostly focused on petctra
• Solidity working on EOF as an experimental feature
  • eof: Support functions (CALLF, RETF, JUMPF) solidity#15550
  • eof: Implement stack height calculation solidity#15555
  • EOF: Implement ext*calls solidity#15559

Spec Updates

• Compiler Metadata Section
  • Kaan from Sourcify Team
  • Current practice is to just append
  • would want a separate metadata section in EOF.
    • Unreachable by code (a good thing)
    • contains the CBOR data solidity produces
  • Current status of appended to data and behind constructor fields makes it hard to find
  • Experimental Solidity EOF handling is to put CBOR metadata at the beginning of the data section.
  • Would insulate code/data indexes from variable CBOR sizes, such as if experimental flags are logged.
  • Next step is an EIP

Brief discussion on header section numbers

EOFCREATE hash - ipsilon/eof#162 (comment)

• danno wants a "0xef01" hash added
• Solidity has concerns about the genericness, would prefer container index
• Bad salt management could prohibit multiple deployments
• Should hash include auxdata, not just code data?
• possible issues with cross-chain deployment. The more mandatory data makes same address contracts difficult.
• note: some people don't like metadata has in CREATE2, would compiler metadata be excluded from address derivation?
• Are there security implications? Would the "code hash" guarantees be forgotten about? Could compilers compensate?
• Please add comments to the thread.

[poojaranjan]

Recording: https://youtu.be/yzYUWpa-1QM

[poojaranjan]

Closed in favor of #1205