EOF Implementers Call #49

[poojaranjan]

Meeting Info

June 05, 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
• Decision on EOF testing from last meeting
• Solidity + EOF POC summary

Agenda

• Client updates
• Compiler updates
• Spec updates
  • final call on whether we make changes to the creation tx being validated in initcode mode or not https://github.com/ipsilon/eof/pull/119 / https://github.com/ipsilon/eof/pull/118 Danno's take
  • https://github.com/ipsilon/eof/pull/124 - EXTDELEGATECALL clarified to fail when calling non-eof, (as opposed to actual legacy contracts)
• Testing updates
• Other items

Please add other agenda items or links to discuss.

[chfast]

Code size limits for tests: are we forcing current limit of 24k/48k? Some tests already exercise the 64k limit.

[shemnon]

Add to spec updates - https://github.com/ipsilon/eof/pull/124 - EXTDELEGATECALL clarified to fail when calling non-eof, (as opposed to actual legacy contracts)

[shemnon]

Re 24k/48k/64k it's a question of where we enforce it.

For returncontract do we enforce it in the opcode or let the storage system tell us no-bueno?

For EOFCREATE in theory the Create Transaction should have filtered it pre-execution, and factory contracts are already size limited to runtime sizes. A TXCREATE opcode would need to check, but again the transaction processor should have filtered it out?

[gumb0]

Proposal to ban subcontainers that only REVERT/INVALID and can be referenced by both EOFCREATE and RETURNCONTRACT. Two options:

1. Require each subcontainer to have STOP or RETURN or RETURNCONTRACT.
2. Disallow EOFCREATE and RETURNCONTRACT referencing the same container.

(option 2 would still allow containers that only have REVERT)

[poojaranjan]

Notes (by @pdobacz )

client updates:

geth

• ~60/1000 tests failing, making progress

evmone

• merged RETURNDATACOPY oob, Creation TX, ASE EXT*CALL, initcode mode validation in progress

besu

• progress on testing support

compiler updates

None

spec updates:

• https://github.com/ipsilon/eof/issues/118 / https://github.com/ipsilon/eof/issues/119:
• ended up not discussing these again, not in favor of either option, both have problems as documented in the issues.
• https://github.com/ipsilon/eof/issues/117
• no action to be taken for the reasons noted therein. If necessary, Solidity to make a stronger request for it.
• code size limiting in eof validation (to MAX_INITCODE_SIZE)
• Ipsilon to write down a PR, solidity testing might be a practical problem, could be solved by having the limit at 2xMAX_INITCODE_SIZE
• ban subcontainers with only revert/invalid (https://github.com/ethereum/pm/issues/1055#issuecomment-2150340561)
• Option 2 more favorable, vyper mentions signaling contracts are legit use case

testing updates:

• EIP versioning:
  • Generally in favor of changelog stopgap solution to version EIPs and check their versions in testing
  • EIPIP also in favor, possibly a preamble entry in the future.
• feature-forks:
  • Testing team shows off support in EEST for feature-forks (CancunEIP7692 for example) to fill&release only tests related to a feature (EOF in this case)

[poojaranjan]

EIP-7577: Versioning Scheme for EIPs was also discussed in the following EIPIP meeting today.

The proposal is merged as Draft however a few editors had concerns related to the adoption of the EIP.

Adding comments to proposal discussion will be helpful to move the proposal to the next status.

[poojaranjan]

Closing in favor of #1063

[Parasos]

bb