Title: EOF_Implementers_call__60__October_16_2024
Category: Protocol_Calls___happenings

Author: abcoathup
Date: 2024-10-09T01:52:08.682Z

Agenda
EOF Implementers Call #60 · Issue #1167 · ethereum/pm · GitHub
Notes
Notes by @shemnon (Copied from ethereum/pm)
Testing

Pectra-devnet-4 is occupying 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 absent
evmone - no updates - need to add Osaka fork
Besu - Osaka 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
ipsilon/eof#165
Recording