Recording :
https://www.youtube.com/live/i_29BU3J97M
Meeting summary for All Core Devs - Consensus (ACDC) (04/17/2025)
Quick recap
The meeting covered discussions on the upcoming mainnet launch, client releases, and testing progress. The team debated various technical aspects, including the implementation of Block Parameter Optimization, configuration formats, and the inclusion of specific EIPs in future hard forks. They also addressed concerns about API specifications, potential challenges with increased blob counts, and the need for faster forks while maintaining system stability.
Next steps
• stokes to update the Meta EIP to move EIP-7892 (BPO EIP) to SFI status.
• Client teams to add contact information to the Petra mainnet fork organization document.
• Client teams to implement and test the new BPO configuration format in YAML.
• stokes to update the Meta EIP to CFI EIP-7917 (Proposer Look-Ahead) and DFI other EIPs for Fusaka.
• stokes to continue gathering input from relays and builders regarding potential changes to the Builder API for Fusaka.
• Client teams to aim for Petra mainnet client releases by April 21st.
• Client teams to prepare for Fusaka Devnet 0, targeting around May 20th, including Perdos Devnet 6 and BPO EIP implementation.
Summary
Mainnet Launch and Client Releases
In the meeting, Stokes led the discussion, ensuring everyone could hear him. The team discussed the upcoming mainnet launch on May 7th and the planned client releases for Petra on April 21st. Mario reported positive progress on testing, with all clients showing good results. The team was reminded to add contacts to a document for instant response in case of any issues. Barnabas updated on the launch of Devnet 6, which had some problems, particularly with the Nimbus client. The team was asked to provide further updates on the issues.
Ethereum BPO Configuration and Emergency Overrides
The group discusses the implementation of Block Parameter Optimization (BPO) in the Ethereum network. They agree on using a YAML configuration format with a list of objects specifying epochs and corresponding maximum blobs per block. There is debate about whether to include this in the main config file or a separate file, with a preference for including it in the main config. The discussion then shifts to the possibility of emergency overrides for BPOs. Dustin argues against designing for emergency scenarios, stating that coordination for such rapid changes is unrealistic. Parithosh clarifies that the focus is on having the ability to cancel or adjust future scheduled BPOs based on performance data, rather than immediate emergency changes. The group leans towards using new config releases for such adjustments rather than implementing override flags.
Configuring BLOB Schedule and API Spec
The team discussed the configuration for the BLOB schedule and decided to use a specific format in the config Yaml file. They agreed not to include a command line override for now. Enrico raised a concern about the impact on the API spec, but the team felt that it should be okay. The team also discussed the potential issues with unexpected keys in the config file, but decided to proceed with the new format.
Electra and Deneb Implementation Discussion
In the meeting, Stokes and Justin discussed the implementation of Electra and Deneb limits. They agreed to include Electra in the Dpo schedule and to backfill it. They also discussed the possibility of including Deneb in the schedule, but decided to wait for further testing. Barnabas raised concerns about the potential for a mismatch in scheduling schemes, but Stokes reassured him that it should be fine as long as the configuration is correct. They also discussed the implementation of the BPO EIP for future hard forks. Stokes suggested that they should aim for the next devnet to focus on to be Posaka Devnet 0, with Reidos Devnet 6 and BPO. The team agreed to aim for a May 20th timeline for this.
Eip Status and Future Proposals
Stokes discussed the status of various eips, including the decision to move the Bpo eip to Sfi from Cfi, and the proposal to look ahead at Eip 7, 9, 1, 7. Ansgar expressed support for accepting Eip-7917 and rejecting others. Dmitry shared that he and the mixed bytes team are conducting a detailed research on the actual effects and impact of implementing Eip 7, 8, 8, and that it is crucial for app layer developers. The team agreed to move Eip 7, 9, 1, 7 to Dfi and Eip 7, 6, 8, 8 to Cfi.
CIP Inclusion in Upcoming Fork
The team discussed the inclusion of a specific CIP in their upcoming fork. Radek expressed concerns about including the CIP due to the agreed-upon process of scheduling forks and including certain items. Stokes suggested a cautious approach, focusing on due diligence before including any CIPs. The team agreed to prioritize pure DOS and EOF changes before considering the CIP. Sean and ethDreamer shared their views on the potential impact of the CIP on other teams. The team also discussed the implementation difficulty of the CIP and the importance of having a stable system before adding more features.
EIP-7917 Inclusion in Fusaka Hard Fork
The group discusses the inclusion of EIP-7917 in the upcoming Fusaka hard fork. While initially considering it as a “consider for inclusion” (CFI) item, concerns are raised about changing the beacon state. Potuz points out that this would be the only change affecting the beacon state in Fusaka. Lin explains the importance of the EIP for pre-confirmations, stating that without it, they would need to rely on a hacky oracle solution. The group considers postponing the EIP to a future hard fork, with Dmitry suggesting specifying it for the Glamsterdam fork instead.
Fusaka Fork EIPs: PeerDAS Focus
The group discusses the potential inclusion of EIP-7917 (proposer look-ahead) and EIP-7688 (stable containers) in the upcoming Fusaka fork. There is weak support for CFI (Considered for Inclusion) status for EIP-7917, with the understanding that it will be dropped at the first sign of complications. The group agrees to focus primarily on peerDAS and only consider additional EIPs if there is time. Regarding EIP-7688, opinions are mixed. Some suggest CFI-ing both EIPs or neither, while others prefer to only include EIP-7917. The main concerns are maintaining development velocity, avoiding scope creep, and ensuring smooth implementation. No final decision is made on EIP-7688, but there is a general inclination to be cautious about adding multiple EIPs to the fork.
Faster Forks and Stable Containers
In the meeting, the team discussed the need for faster forks and the potential challenges that could arise from including stable containers in the next hard fork. They considered the impact on proofs and the need for applications to update their proofs. The team also discussed the possibility of separating 7, 6, 8, 8 from other features and the potential for small forks. The importance of maintaining a fast iteration of forks was emphasized, and the team agreed to focus on the main eap and the eof. The conversation ended with a discussion on the scalability of the builder APIs and the potential challenges with high blob counts.
API Response Size for Proposers
In the meeting, Stokes raised concerns about the API’s response size for proposers, particularly in relation to the potential for increased blob count. The discussion centered around the possibility of changing the API to reduce the response size or even remove it entirely, with the relay being responsible for distributing the block and blobs. Terence suggested returning a positive response after the relay propagated the data. The team agreed to revisit the API for Fusaka and gather further input from different relays and builders. The consensus was to ensure that the builder API specs explicitly require builders/relays to propagate the data.
AI-generated content may be inaccurate or misleading. Always check for accuracy.