Highlights of Ethereum's All Core Devs Meeting (ACDC) #150

The Consensus Layer Meeting 150, held on February 6, 2025, focused on Pectra, PeerDAS, Testnet and Mainnet timelines, and security measures. The packed agenda included Devnet 6 updates, EIP-7702 implementation, testnet fork scheduling, PeerDAS scaling, and a $2 million bug bounty program. Developers also reflected on past hard forks and discussed future fork planning to improve efficiency.

• Pectra Devnet 6 Updates
• EIP-7702 Discussion
• Pectra Testnet Fork Timing & Mainnet Schedule
• PeerDAS Scaling & Blobs
• EIP for Hardware & Bandwidth Requirements
• Ethereum Future Forks Planning
• Pectra Bug Bounty Program

Pectra Devnet 6 Updates

One of the first updates provided in the meeting was that Devnet 6 had been successfully launched. The general sentiment from the developers was that it was performing significantly better than Devnet 5, which was a major positive outcome. Devnet 6 was observed to be more stable and required fewer fixes compared to the previous iteration. The testing teams noted that the network’s response time had improved, and no significant failures had been recorded during initial trials.

However, there were still a few outstanding concerns that needed to be addressed before progressing further. Developers identified minor but crucial aspects that required refinement to ensure the upgrade’s seamless deployment.

One of the primary issues discussed was the Flashbots relay integration, which had yet to be fully set up. This relay system plays a vital role in Ethereum’s block-building process, ensuring efficient propagation and execution of transactions. The team working on the integration indicated that progress was being made, and additional information regarding its deployment was expected after the call or early the next day.

Additionally, local testing using Kurtosis also provided positive results, confirming that clients were behaving as expected under controlled conditions.

Despite these successes, a pending concern was highlighted regarding execution requests in map-produced blocks. These execution requests are fundamental for ensuring that transactions are properly included and finalized in the consensus process. Since this aspect had not yet been thoroughly tested, the development team agreed that further verification was required to prevent potential execution failures on the Consensus Layer (CL) side.

Another issue brought up during the discussion was an API non-conformance issue with the Lighthouse client. The problem stemmed from Lighthouse not fully conforming to a specific Beacon API specification, which is essential for seamless interaction between clients.

Although this was not a critical failure, developers acknowledged that even minor API inconsistencies could lead to broader network instability. The team working on Lighthouse noted that the fix was relatively straightforward, and it would be applied in the coming updates.

EIP-7702 Discussion

Core developers discussed EIP-7702, which aims at refining the transaction handling mechanism within the Execution Layer (EL). The conversation primarily revolved around defining clear behavior for Ethereum clients when processing EIP-7702 transactions, challenges in writing effective test cases, and assessing client readiness for its implementation. The lack of explicit specifications for transaction interactions led to ambiguity in testing and concerns about potential inconsistencies among EL clients. Additionally, the meeting focused on whether EIP-7702 should be included in the upcoming testnet release or delayed for further refinement.

One of the main concerns was the lack of a well-defined specification dictating how EIP-7702 transactions should behave when interacting with other transaction types. Unlike existing transaction models, EIP-7702 introduces new rules that determine how transactions are validated and executed. The absence of clear guidelines made it difficult to develop effective test cases, particularly in scenarios where Type-4 transactions (introduced by EIP-7702) coexist with non-Type 4 transactions. Developers debated whether EL clients should be required to reject conflicting transactions or allow them to coexist under certain conditions. The Ethereum spec did not explicitly address this issue, leaving room for inconsistent implementations across different clients. Since defining transaction handling logic is crucial for network stability, participants agreed that more clarity was needed before finalizing the implementation.

Ethereum's EL clients exhibited varying levels of support for EIP-7702, raising concerns about its readiness for deployment. Geth developers reported an ongoing PR aimed at integrating EIP-7702, but it was unclear whether it would be merged in time for the testnet release. Other EL clients had not yet completed their implementations, further complicating the timeline. The uncertainty surrounding client readiness led to a debate on whether rushing EIP-7702 into testnets without full support could introduce inconsistencies and potential failures. Developers were particularly concerned about the impact on transaction reordering, validation, and execution logic, which varied across clients. Given that EL clients play a critical role in transaction processing, ensuring uniform behavior across implementations was seen as essential before proceeding with deployment.

A compromise approach was suggested: proceed with the testnet release while closely monitoring EIP-7702’s behavior. This would allow developers to assess its performance in real-world conditions and make necessary refinements before mainnet deployment. Establishing a working group to address edge cases and define standardized validation rules was also proposed to ensure a smoother transition.

Pectra Testnet Fork Timing & Mainnet Schedule

The Ethereum developers initially considered February 10, 2025, as the target date for rolling out client releases for the testnets. However, multiple teams indicated that this timeline was too aggressive and would not allow sufficient time to implement and verify last-minute changes. After further discussions, a revised date of February 13, 2025, was proposed as a more feasible alternative.

Client teams, particularly Lighthouse, expressed concerns that pushing for an earlier testnet fork could lead to unnecessary complications. They needed additional time to finalize an API fix and implement a performance-related enhancement. Since testnet stability is crucial for ensuring a smooth transition to mainnet, most participants favored waiting until February 13 to allow adequate testing and debugging.

Another factor influencing the scheduling decision was feedback from staking pools, Layer 2 rollups, and other Ethereum ecosystem participants. Many of these stakeholders emphasized the importance of having a predictable and well-communicated testnet rollout to ensure their infrastructure and applications could be updated in sync with the changes.

Based on the discussions, the following tentative timeline was proposed:

• February 13, 2025 → Client releases for testnets.
• March 5, 2025 → Sepolia testnet fork.
• March 6, 2025 → All Core Developers (ACD) call to confirm mainnet slot.
• April 8, 2025 → Targeted mainnet fork date (if no major testnet issues arise).

PeerDAS Scaling & Blobs

Developers reviewed the progress of PeerDAS Devnet 4, assessed potential changes for Devnet 5, and debated modifications to the proof-building process to enhance computational efficiency. A key challenge in scaling blob transactions is managing KZG proof computations efficiently. Developers explored shifting some of the proof generation workload from the Consensus Layer (CL) to the Execution Layer (EL), which could significantly reduce bottlenecks during block proposal.

Ethereum’s latest PeerDAS Devnet 4 had been running tests primarily in local environments and on Kurtosis, a testing framework for Ethereum clients. Initial feedback was positive, with multiple-day test runs demonstrating network stability and minimal unexpected failures. Encouraged by this success, developers began preparing to launch the public DevNet to expand testing efforts. While Devnet 4 was performing well, developers remained cautious about potential edge cases. The primary focus was on ensuring validator custody mechanisms were functioning as expected and addressing any potential computational inefficiencies before moving to Devnet 5.

As discussions moved toward Devnet 5, developers debated what major changes should be introduced. One of the most significant proposals was modifying who is responsible for proof-building computations. By offloading proof computations, the time required for block proposal could be reduced, leading to more efficient blob scaling. This change would allow Ethereum to increase the number of blobs per block beyond the current limits, improving scalability.

Another key discussion centered around introducing Blob Parameter-Only (BPO) forks. This proposal aimed to enable dynamic adjustments to the maximum number of blobs per block without requiring a full network hard fork. While most developers agreed that BPO forks could be a useful tool, the discussion emphasized that further testing was needed before making a final decision.

EIP for Hardware & Bandwidth Requirements

As the network scales, ensuring that validators and node operators can meet the required infrastructure demands is essential. One of the core debates revolved around whether the network should prioritize high-performance nodes at the expense of solo stakers and homestakers. Some developers argued that increasing hardware requirements would favor large staking pools and centralized entities, while others believed that higher efficiency was necessary for Ethereum’s long-term scalability.

A new EIP was introduced, outlining recommended hardware and bandwidth specifications for node operators. The proposal aimed to standardize minimum system requirements to ensure that all nodes could handle upcoming network upgrades efficiently. Since this EIP was categorized as an informational proposal, it would not introduce protocol-level changes but instead serve as official guidance for node operators. Developers agreed that having a well-documented specification would help prevent unexpected performance bottlenecks, particularly as blob transactions increase with upcoming upgrades.

One key aspect of the proposal was the Max Blobs Flag, which allows node operators to specify the maximum number of blobs they are willing to handle. This feature is intended to prevent bandwidth overload and enable solo stakers to participate without exceeding their network limits. However, concerns were raised about whether Ethereum’s increasing hardware requirements would harm decentralization.

Some participants worried that as hardware and bandwidth demands rise, solo stakers could be excluded from the network. A proposed solution was to introduce configurable parameters, allowing node operators to adjust their resource allocation. However, there was disagreement over whether this approach would be effective or if it would introduce security risks by allowing nodes to opt out of certain transaction types. Ultimately, the group agreed that maintaining a balance between scalability and accessibility was critical—while network performance must improve, it should not come at the cost of decentralization.

Ethereum Future Forks Planning

With the upcoming Pectra upgrade, developers reflected on past Ethereum hard forks to identify lessons learned and improve future fork planning. A major takeaway was the need for better scope definition to prevent unnecessary changes from being introduced late in the development cycle. By establishing clearer boundaries early, developers could avoid last-minute modifications that often lead to delays and increased complexity.

One of the key challenges in Ethereum’s upgrade process has been the lack of clearly defined boundaries for each hard fork. New features and EIPs are often proposed midway through development, causing compatibility issues and making it difficult for client teams to maintain stability. To address this, developers discussed implementing a structured timeline where, by the time Fork N is deployed, the scope of Fork N+1 is already fixed. This approach would allow client teams to focus on implementation rather than decision-making and prevent disruptive changes late in the process.

While most developers supported this structured approach, some expressed concerns about flexibility. If unforeseen issues arise, a rigidly defined scope might limit Ethereum’s ability to address urgent protocol improvements. Despite these concerns, there was broad agreement that early fork scoping would lead to smoother Ethereum upgrades by reducing uncertainty, improving coordination among teams, and allowing more thorough testing before mainnet deployment.

Pectra Bug Bounty Program

To ensure that Pectra is thoroughly tested before mainnet deployment, developers announced a $2 million bug bounty competition. The Attackathon aims to incentivize security researchers to find and report vulnerabilities before they impact the live network.

This initiative represents a shift from the traditional 2x multiplier for bug bounties during hard fork releases. Instead of simply increasing the payout, Ethereum’s security team decided to organize a dedicated security event to attract more participants. The Attackathon will focus on identifying vulnerabilities specific to Pectra. Client teams were asked to prepare one-page documents outlining the changes introduced in their implementation to help security researchers target their efforts.

To ensure maximum participation, the bug bounty program will be promoted through the Ethereum Foundation Blog, the bounty.ethereum.org website, and social media announcements, including Twitter and Discord. Developers emphasized that client teams should support the effort by publicizing the competition and assisting security researchers in understanding which parts of the codebase have changed.

As the meeting concluded, developers summarized key takeaways and outlined the next steps for Ethereum’s upcoming upgrades. With Pectra’s client releases scheduled within a week, the focus shifted toward final testing, security reviews, and refining the testnet rollout strategy.

Readers can watch Ethereum's All Core Devs (ACDC) Meeting #150 here: