RollCall 8.1 Summary

# RollCall 8.1 Summary ## Details - Recording: https://www.youtube.com/watch?v=fDIiO63QJog - Agenda: https://github.com/ethereum/pm/issues/1171 - Moderated by: [Carl Beekhuizen](https://github.com/CarlBeek) ## EVM Equivalence on L2: Past, Present, Future - Presented by [Ansgar](https://github.com/adietrichs), [slides](https://docs.google.com/presentation/d/12t-7bG7bgOh02wQlmrcJrwkEuV5HI_CJux7bIepertE/edit#slide=id.g2e5d90eb79b_0_39) - **Announcement of Rollup-Geth** - A new team within Nethermind has been formed to maintain a fork of Geth focused on L2, called rollup-geth. This fork will prioritize L2-specific functionality, addressing L2-centric needs that traditional Geth has limited bandwidth to support. - Introducing rollup-geth post: https://ethereum-magicians.org/t/introducing-rollup-geth/21458 - **History of L1 EVM and L2 EVM equivalence** - L1 EVM become more static post-merge, with ambitious features like state expiry & native AA not adopted. - While L2 was initially expected to evolve with unique execution environments, network effects have largely kept L2s aligned with L1 compatibility. - Geth, primarily L1-focused, remains the dominant client among L2s, despite limited development bandwidth for L2-specific needs. - **Current Situation** - Currently, most L2 EVM equivalence is some what lock-in to L1 due to mismatch in performance target, feature needed, risk tolerance, etc. - While new L2-specific clients like reth are emerging, most L2s still rely on geth or prefer to keep geth for multi-client. - **Vision for the future** - **L2-native client**: rollup-geth is a fork of geth designed specifically for L2 environments, developed by Nethermind team in collaboration with RollCall. Although it doesn’t fully resolve L2’s dependency on L1 EVM equivalence, but it’s ideal for isolated, under-the-hood features that enhance L2 functionality without disrupting the broader L1 network. - **L2 EVM common core (more opt-in)**: It aims to break back EVM innovation on L2 through a shared set of RIPs, allowing L2s to remain equivalent to each other rather than strictly to L1. The common core could become the standard for L2 tooling, wallets, and Solidity support, and the shared approach to handle L1 changes eg. verkle. It will require governance and R&D efforts, covering both near-term innovation eg. basic repricing, 2nd tx type, delayed state root computation, etc. and long-term features eg. native aa, tx parallelization, statelessness / state expiry / state rent, multi-dimensional pricing, etc. - **RollCall “Season 2”**: Existing roles are focused on L2 coordination, creation of RIPs, and connecting L1 and L2. New roles will include responsibilities in L2 client coordination, governance of the L2 EVM common core and R&D, with the possibility of splitting into distinct processes for more targeted management. - **Next steps** - For rollup-geth - L2s currently using geth could decide whether to move to roll-geth, connect with the team, and figure out the migration process. Other clients could consider establishing collaboration mode. - For common core - Relevant parties can determine their interest / viability. Further exploration areas incl. governance, research process setup, initial common core scope, relationship with zk / op. - Discussion for next [Rollcall #9](https://github.com/ethereum/pm/issues/1172) will focus on common core research. ## Discussion - Initial reaction from different L2s teams - [Protolambda](https://github.com/protolambda) from OP labs think rollup-geth is still in fairly early stage and want to see some outputs from the team before committing to anything. - [DC builder](https://github.com/dcbuild3r) from Worldcoin has some concern on dependency tooling & downstream effects, and propose to have some sort of diff distributed to respective tooling. - [Roberto](https://github.com/roberto-bayardo) from Coinbase gave pretty positive impression on this initiative. - [Dereck](https://github.com/leeederek) from Offchain labs has raised some concern that L2s might want to prioritize different needs and have different paces. - In general, L2 teams still need to digest a bit the info and will discuss more under the [magician post](https://ethereum-magicians.org/t/introducing-rollup-geth/21458). - [Sam Battenally](https://github.com/SmoothBot) from RISE chain inquired about how to encourage building tools / libs to adopt the new features that make into rollup-geth. Ansgar noted the common core’s potential to promote adoption, and some tracking mechanism for RIPs to increase visibility. Yoav added that incentives, like reduced transaction costs through multi-dimensional gas, would motivate wallet adoption as L2s implement these features. - [Protolambda](https://github.com/protolambda) from OP labs raised the question whether the focus of rollup-geth would solely on new features of geth or also incl. core performance improvements. Ansgar responded that the overall goal is to ensure geth can remain a viable L2 client, while also build multi-client alternatives for L2 to choose in the future. - [Derek](https://github.com/leeederek) from Offchain labs asked whether there will be L2 hard forks to coordinate larger "common core" changes. Tim Beiko from EF responded that it would function more like "major releases" of dependencies, where L2s can agree on the scope of a release but are not required to adopt it simultaneously. Nicolas from Nethermind added that even within the common core, features could be optional, allowing L2s to choose a subset. - [Terence](https://github.com/terencechain) from Offchain labs inquired whether there would be execution specs equivalent for rollup-geth. Carl clarified that the current plan is to have the definition of the L2-common-core be L1 and a list of RIPs that serve as differences from L1, enabling both reth and rollup-geth to support multi-client development from the outset. ## Next step - Things that L2 teams could review regarding rollup-geth - Take a look at the [project repo](https://github.com/NethermindEth/rollup-geth) - If the team is from superchain, it can refer to op-geth and rollup-geth merge and spot if there is any potential challenges - L2s can give hint to rollup-geth team on relevant EIP / RIPs that they would want to implement on rollup-geth - Discussion for next [Rollcall #9](https://github.com/ethereum/pm/issues/1172) will focus on common core research.