The meeting focused on discussing potential gas limit increases for Ethereum and their impact on different node operators, as well as reviewing and deciding on various Ethereum Improvement Proposals (EIPs) for upcoming network upgrades. The team explored potential headliner proposals for the Amsterdam fork, including EVM64, Fossil, and Block Access Lists, and debated their implementation and interactions. Additionally, the group discussed versioning schemes for EIPs and agreed to continue exploring options for better tracking and management of proposals.
Click to expand detailed summary
The meeting focused on discussing gas limit increases for Ethereum, with Parithosh explaining that while client teams were asked about potential blockers for raising the gas limit to 60 million on Mainnet, the decision was deferred until after Berlin interop testing is complete. The team acknowledged that while intermediate steps could be taken, the main concern was coordination overhead rather than technical feasibility. Micah noted the testing team’s thorough investigation into potential issues with high gas limits for stakers.
The discussion focused on the impact of increasing gas limits on different types of Ethereum node operators, particularly those running nodes at home. Micah raised concerns about the lack of research into how gas limit changes affect home RPC clients and end users, contrasting with the focus on stakers and block builders. The group discussed the feasibility of running Ethereum nodes on consumer hardware, with some arguing that 60M gas limit is still manageable for home users, while others suggested that higher gas limits would require more expensive hardware. The conversation touched on the need to distinguish between different types of nodes in future discussions and decisions.
The team discussed increasing the mainnet gas limit to 60 million, with Tim suggesting a review of requirements for a potential one-time bump or gradual increase. Marcin highlighted the need to be aware of worst-case scenarios, such as blocks taking 3 seconds to process at high gas limits. The team also reviewed updates to EIP-7883, with Marcin explaining that one proposed change would be withdrawn, and they agreed to add a fourth tender to the code. Tim encouraged everyone to review the updated EIP asynchronously and make a decision within the next week.
The team discussed replacing EIP-7212 with EIP-7951, which has a simpler cryptographic interface and extensive tests, though gas cost benchmarking is still needed. They reviewed potential EIPs for Devnet 2, with general agreement on including EIP-7212 and EIP-7934, while EIP-7907 was conditionally supported pending further discussion. The team decided to postpone the pay opcode and meter contract size EIPs for later hardforks, with Ben suggesting a 50% contract size increase as an interim solution.
The team discussed implementing EIPs for the Fusaka devnet and Glamsterdam fork. They decided to tentatively include EIP-7907 in Devnet 2, despite potential database complexity issues, while keeping EIPs 7212, 7934, and 5920 in scope. They agreed to experiment with EIP-7907 implementation and test its performance, with the understanding that if issues arise, they may need to remove it from the fork. The team also decided to move EIP-5920 to DFI and potentially include the pay opcode in Glamsterdam, though final decisions on scope for Devnet 2 and the fork were left pending successful implementation of EIP-7907.
The meeting focused on discussing potential headliner proposals for the upcoming Ethereum fork in Amsterdam, including Fossil (FOCIL), EVM64, and Delayed Execution. Wei presented EVM64, which defines new opcodes for 64-bit operations, and discussed two implementation options: one built on legacy EVM and another on top of EOA. Thomas provided an overview of Fossil, highlighting its importance in improving censorship resistance by enabling multiple validators to enforce transaction inclusion. The group discussed the urgency of implementing Fossil, with some participants expressing concern about builder centralization and the need for censorship resistance. The conversation ended with a brief discussion of the interaction between Fossil, Delayed Execution, and Block Access Lists.
Tim led a discussion on two proposed headliners for the Amsterdam event. Mingfei presented a proposal (EIP-479) aimed at enhancing Ethereum’s proof-of-stake protocol’s resilience against reorganization attacks. Tim suggested that further discussion on Mingfei’s proposal be held on the CL call, as it seemed more relevant to that audience. The conversation ended with a reminder that additional proposals could be submitted via the Ethereum Magicians thread.
The discussion focuses on block-level access lists (BAL) as a potential feature for Ethereum. Toni explains that BAL aims to introduce parallelization for batch I/O and transaction execution, which could improve L1 scaling. The feature also has secondary benefits for state updates and syncing. There is debate about whether BAL should be considered a headline feature and how it might interact with other proposed changes like FOCIL and delayed execution. Ansgar suggests separating the read and write aspects of BAL for governance decisions. Guillaume expresses support for BAL but emphasizes the need to finalize the design before scheduling implementation. The group discusses the historical context of similar proposals and the current focus on L1 scaling. Client teams have shown interest in post-transaction state diffs as part of the BAL implementation.
The team discussed two main topics: block access lists (BALs) and the “pay” opcode. Regarding BALs, Toni explained they would add approximately 40 kB on average to block size, which while non-negligible, was deemed worthwhile after considering pros and cons. The team agreed to remove the “pay” opcode from Fusaka and reconsider it for Amsterdam, with concerns raised about potential implementation implications and testing challenges. Ahmad briefly mentioned a versioning scheme for EIPs (EIP-7577) but did not elaborate.
The team discussed implementing versioning schemes for Ethereum Improvement Proposals (EIPs), with Ahmad proposing a system to track changes and versions, while Tim expressed concerns about adding unnecessary friction to the process. The group debated using commit hashes versus semantic versioning, with Tim suggesting a more comprehensive approach that would include EIP state and hard fork status. Andrew proposed stricter enforcement of freezing EIP commits on the Devnet spec, and danceratopz suggested coupling EIPs more tightly with implementations in EELS. The team agreed to continue the discussion and trial something for the Amsterdam fork.