Click to expand detailed summary
Tim announces that the Petra client releases were published on the Ethereum Foundation blog, with the Mainnet fork scheduled for May 7th at 10:05 UTC. He urges those who haven’t updated their clients to do so. Barnabas reports successful testing of the MEV workflow for Petra, with recent bug fixes and improvements. Parithosh mentions ongoing client release testing, with plans for a shadow fork early the following week.
The group discusses the configuration format for the BPO (Blob Post-Cancun Upgrades) forks on the execution layer (EL). Marius suggests treating these as normal hard forks on the EL side to avoid potential bugs and complications. Alex proposes a configuration structure, which is generally well-received. The group agrees to remove timestamps from the blob schedule, as they are already present in the normal fork schedule. Tim suggests verifying client parameterization for different forks to ensure consistency across EL clients. Ahmad raises concerns about client-specific activation methods. The group decides to specify the configuration in the EIP (7892) directly, using generic names like “BPO1” and “BPO2” instead of timestamps to avoid potential issues. They plan to update the EIP with these changes.
Tim explains the concept of bundling multiple Beacon-chain Protocol Upgrades (BPOs) into a single client release, with the ability to activate them at different times. This approach reduces the operational overhead of frequent hard forks while maintaining flexibility. The consensus layer would have less frequent but more complex hard forks, while the execution layer could have more frequent but simpler upgrades. Tim also mentions the possibility of delaying or removing future BPOs if issues arise, though the term “emergency hard fork” is deemed inaccurate. The group discusses renaming the BPOs and the potential for intervention if needed.
The group discusses challenges with compiling legacy contracts to the new EOF format. Ben Adams explains that many popular libraries like OpenZeppelin would not compile due to use of deprecated opcodes. This creates a poor developer experience, as most existing contracts would break. Danno proposes revisiting “Option D”, which would re-enable certain introspection opcodes within EOF contracts while still preventing introspection of EOF contracts themselves. This could allow existing libraries to compile without major rewrites. There is debate about whether to reconsider the previously decided EOF scope, with some arguing it’s too late to change course while others feel the implications weren’t fully understood before.
The discussion focuses on the proposed changes to the Ethereum Object Format (EOF) for the upcoming Fusaka upgrade. Ahmad expresses a different perspective, suggesting that disabling certain features only for EOF contracts is not problematic as legacy contracts can still be used. Dan and Tim emphasize the importance of sticking to the frozen set of features and only making subtractive changes at this point to avoid extending timelines. Ansgar argues for a high bar to changes, noting the asymmetric risk of adding features that can’t be removed later versus the ability to add missing features in future upgrades. Gakonst stresses that the top priority for Fusaka should be scaling with PeerDAS, and any compromises to that goal would be a significant failure.
The discussion focuses on the implications of shipping EOF (EVM Object Format) without code introspection. Tim questions the value of this approach, while gakonst emphasizes that the main issue is contract compatibility and the widespread use of assembly in existing code. Alex from Epsilon reports that they have successfully rewritten parts of their codebase to work with EOF, but notes that assembly code cannot be automatically translated. Charles raises concerns about the need to maintain two different codebases for L2s without EOF and EOF-enabled mainnet. The group also discusses the potential impact on developer experience and the timeline for full ecosystem support.
The group discusses the implications of implementing EOF (EVM Object Format) and its impact on developer experience. They consider two main options: implementing EOF without introspection bans or adopting EIP-7907. Concerns are raised about potential delays in ecosystem adoption and the need to maintain separate codebases for legacy and EOF contracts. The team agrees to review the proposed changes and make a final decision by Monday, aiming to minimize delays in the testing cycle. They also briefly touch on the differences between EOF and raw EVM changes, noting that EOF contracts would fail to deploy on L2s that haven’t adopted it, while raw EVM changes might deploy but fail at runtime.
The discussion focuses on the potential adoption of RISC-V as a future execution environment for Ethereum and its implications for the current EOF (EVM Object Format) implementation. Lightclient expresses concerns about investing in EOF when RISC-V might be adopted in the future, potentially making EOF obsolete. Others argue that RISC-V is a long-term consideration (2-5 years away) and shouldn’t prevent the implementation of EOF. The group discusses the trade-offs between improving the current EVM with EOF and waiting for a potential RISC-V implementation, considering factors such as proving costs, tooling development, and maintenance burdens. They also touch on the need to support multiple versions of the EVM indefinitely, regardless of which path is chosen.
The discussion focuses on the potential switch from EVM to RISC-V or another traditional architecture. Vitalik argues that this change could bring benefits such as improved efficiency, better alignment with ZK-proofs, and attracting developers who want to use the same language on-chain and off-chain. The group debates how this potential switch affects the decision on EOF (Ethereum Object Format) and whether to proceed with EOF or wait for further research on RISC-V. They also consider the implications for future-proofing Ethereum and the need to reevaluate short-term benefits of EOF in light of a possible different end-game for Ethereum.
The group discusses the potential impact of RISC-V on the decision to implement EOF (EVM Object Format) in the upcoming Fusaka upgrade. They consider two main options: making a decision about EOF on Monday based on current information, or delaying the decision for 4 weeks to conduct a “research sprint” on RISC-V. The consensus is that 4 weeks is likely not enough time to gain significant insights, and that EOF should be evaluated on its own merits. Tim suggests making a final decision about EOF’s scope in Fusaka during Monday’s testing call, considering the uncertainty of future execution environment changes but not over-indexing on RISC-V specifically. The group acknowledges that if EOF is not included in Fusaka, it may not be implemented for several years.
The meeting discusses prioritizing an increase in the gas limit for the upcoming Fusaka upgrade. Tim proposes merging an EIP that would set a new default gas limit, serving as a reminder to focus on this work. The group generally supports this approach, seeing value in coordinating efforts to safely scale the gas limit. Ben Adams notes that many nodes have not updated to higher limits, so having clients commit to new defaults is important. A related proposal to add a cap on block size at the RLP level is also discussed, which could allow for higher gas limits. The meeting concludes with updates on history expiry, with Piper noting that Sepolia activation is set for May 1st and urging client teams to document any changes in their behavior.
