# EOF Breakout :::info ### EOF Breakout Meeting 1 **Date**: Oct 04, 2022 **Agenda**: https://github.com/ethereum/pm/issues/653 **Recording**: https://youtu.be/3Nx0z0-bhsU **Attendees**  **Links shared in chat** * https://notes.ethereum.org/@timbeiko/eof-breakout * https://notes.ethereum.org/@ipsilon/evm-object-format-overview * https://notes.ethereum.org/@ralexstokes/SyDqVjr4i * https://github.com/ethereum/execution-spec-tests * https://github.com/ethereum/tests/pull/847 ::: :closed_book: Notes -- ### Key Highlights * What is the best path forward for EOF considering the conversations on the last AllCoreDevs? * **Alex B**: devnet would be a good place to test things discussed on ACD. Could first launch the two EIPs, then roll out static jumps, then roll out function selector, etc. and build up more confidence as we go. * **Alex B**: Optimal case is rolling out everything all at once. That said, discussed some potential improvements to function selection that needs to prototype & get feedback from Solidity on. * **Andrew**: Problem with EOF in Shanghai is that the two initial EIPs don't deliver much. Would like v1 to have at least some benefits. Wants to disable dynamic jumps (and verify we can compile solidity without it). If we don't disable dynamic jumps, not clear what the value of EOF is. No urgent need for a v1 without much benefit. * **Andrew**: Seems like trickiest bit is implementing in Solidity. If we have verified this, it's probably not that hard to add to clients. * **Marek**: Is there value for smart contract devs to have the two first EIPs? If so, can get feedback on Shandong. Can also add more EIPs to Shandong. * **Paweł**: Expected that EOF won't be in Shanghai at all. Glad that some people are interested on moving this forward :-) * Solidity seems "neutral" towards this. No killer feature in EOF they desparately need. * Alex B: full EOF set does bring benefits to solidity * Reduces pressure in code generator * Could help bring down gas costs (with function generators?) * Could lead to code size reduction * **Greg**: If gas prices are close to EIP-2315, should see substantial reductions in the cost of making function calls. So long as we have dynamic jumps, can't generate machine code from by code in linear time & space. * **Dragan**: Two things here: introducing new opcodes & the EOF format. Should introduce opcodes first so that solidity compiler can implement them. Maybe v1 introduces opcodes and v2 disables them (does the function selection already do this?) * **Greg**: this can't work, need to remove dynamic jumps to validate the safe use of new constructs. * Andrew: in terms of implementation, it's fine to move these things forward in parallel. Should not release this on mainnet until we have the last bits (disabling dynamic jumps). * Dragan: +1 * **Alex**: can't introduce the opcodes without the format, because they rely on "immediates". * **Bob**: does anyone disagree with the end goal of acheiving the full feature set? * **Tim**: seems people agree, but disagreement is "should we get anything in Shanghai no matter what" vs. "get it all together, regardless of Shanghai" * **Andrew**: What's the benefit of getting _something_ in Shanghai? * Matt: ideally, would rather be able to deprecate static jumps. That said, even having just a bit of EOF in Shanghai is good to show our commitment to improve the EVM. Unclear if 4844 will make it in Shanghai, and if not, then there isn't much to do in Shanghai. * **Andrew**: my preference is to have Shanghai small, with Withdrawals and solving the EL/CL forking coordination, and then have to streams of work in parallel on top: EOF and 4844. * **Tim**: should we just implement it "on top" of withdrawals like CLs are doing with 4844? * **Lukasz**: we have most of it implemented already in Nethermind, testing is the main concern. * **Ahmad**: A must for Devnet, if not for Shanghai. * **Tim**: we have 2/5 EOF EIPs implemented in Shandong already. What would we want in a next testnet? * EIP-3540 [in Shandong already] * EIP-3670 [in Shandong already] * EIP-4200 * EIP-4750 * Requires: EIP-3860 * Not in scope: EIP-5450 * **Danno**: still feel this is underspecified * **Paweł**: this is still a prototype, would want client teams to start looking at * **Andrew**: Erigon doesn't have any implementation of EOF, so would like to separate testnets between Shandhai Core and EOF. Doing a single testnet would slow down things for withdrawals for Erigon. * **Lukasz**: beyond testnets, what do we have in terms of testing? For clients, hive and ethereum/tests are very useful. Do we have those? * For 3540 & 3670, we have tests. Unsure about others. * **Paweł**: for 4200, we have tests. Still need to implement them for 4750. * **Marek** - for 2 Shandong EIPs, we have tests, not sure of other EIPs * **Pawel** - For other EIPs, Test repo has some test already available - Eth JS found some bugs, we need to fix - For EOF function, we have WIP - You can convert status to blockchain test, - Have some features, probably not fully integrated - Not sure how to bring it to Hive testing * **Lukasz** - It’s good enough for Neterhmind, we can bring it up from PRs. * **Tim** - For Besu, Geth, and Nethermind, is it easier to add 4200/4750 to Shandong, or is a separate testnet built on top of "shanghai core" better? How to implement, if EOF isn’t in Shanghai, will that be ton of work for client team? What do client team think of the most efficient way forward? - It is easier for Nethermind to extend Shandong or have a devnet with Shanghai EIPs only. - **Marek** - How we want to fork it will help us decide. - **Tim** - If we restart Shandong, do we want EOF to be a part of it or not (assuming, it will not be a part of Shanghai)? - **Ahmed** - no problem with all EIPs of EOF plus Shanghai testing with Withdrawal & 4844. Not a problem if have to take out before Shanghai - **Andrew** - Want to concentrate on Withdrawal testing. Preference is to decouple Shanghai Core & the EOF. - **Danno** - We can be open for both. Push 0 is going in with Shanghai. We may expect to have a few more EIPs to be on for Shanghai after next ACD. - **Tim** - It make sense to refactor Shandong, Shanghai Core. A bit more work on client team, but could be useful. - **Danno** disagrees thinks, Al-a-catre at the end may add bugs - **Lightclient** agrees with Danno. But, thinks that we should have everything for Shanghai in the devnet * **Alex Stokes** - We should add EIPs in CFI. * **Lightclient** - Shandong has all EIPs-Withdrawal. Interop is on (Geth & Prysm). * **Ahmad** - Why can’t we leave Shandong with EOF and for Withdrawal spin another devnet with other Shanghai EIPs? *General Agreement - EOF will be included as one package.* * **Tim** - Which is the best way having 7 added and remove 4 later? * **Danno** - Depends on the which features are being removed, it may or may not get harder. EFO is a group. Auth & Authcall is one group and so on so forth. * **Erigon** - It's a bad option. General understanding is Withdrawal & EOF will go in for Shanghai. If we have to join shandong for EOF, work on Withdrawal could be delayed. * **Tim** - I agree withdrawal should take priority. * **Andrew** - We need 2 testnets. 1 for Withdrawal and 1 for EOF (Probably 1 for 4844). * **Tim** - As it looks like Matt suggest more testnet will be complicated for Geth. <Tim Screen shares and discuss> ### Testnet Configuration options #### Activate EOF after 'Shanghai Core' * **Shanghai Core**: * EIP-3651: Warm COINBASE * EIP-3855: PUSH0 instruction * EIP-3860: Limit and meter initcode * EIP-4895: Beacon chain push withdrawals as operations * [Activate after Shanghai Core] **Shandong v2**: * EIP-3540 [in Shandong already] * EIP-3670 [in Shandong already] * EIP-4200 * EIP-4750 * [Activate after Shanghai Core] **4884**: * EIP-4844 Shanghai Core - shaghai-core block 0 Shangdong - shaghai-core block 0 - shangdong block 1 4844 - shaghai-core block 0 - 4844 block 1 * Shanghai Core: * EIP-3651: Warm COINBASE * EIP-3855: PUSH0 instruction * EIP-3860: Limit and meter initcode * EIP-4895: Beacon chain push withdrawals as operations * Shangdong v2: * EIP-3651: Warm COINBASE [in Shandong v1] * EIP-3855: PUSH0 instruction [in Shandong v1] * EIP-3860: Limit and meter initcode [in Shandong v1] * EIP-3540 [in Shandong v1] * EIP-3670 [in Shandong v1] * EIP-4200 * EIP-4750 * 4884: * EIP-3651: Warm COINBASE * EIP-3855: PUSH0 instruction * EIP-3860: Limit and meter initcode * EIP-4844