The call focused on finalizing Devnet 6, preparing for testnet forks in February, and a potential mainnet upgrade in March 2025. Key discussions covered Devnet 5 stability, system contract audits, and lessons from Pectra to improve the Fusaka fork with structured testing and scope freezing.

Other highlights included validator bandwidth requirements, the introduction of EIP-7823 for cryptographic precompiles, and new proposals like EIP-7793 (TX Index) and EIP-7843 (Slot Precompile). Governance improvements, including ACD meeting automation, were also discussed. Developers remain focused on stability, security, and scalability as Ethereum progresses toward smoother upgrades and testnet deployments.

Pectra Devnet 5 & 6 Updates

Pectra Devnet 5 has finally stabilized & is now finalizing after crucial bug fixes. However, a key issue was discovered during an execution spec test, which identified a consensus bug in the Nethermind client. The bug stemmed from BLS precompilation optimizations, causing Nethermind to fork at a specific block. The Nethermind team quickly identified & fixed the issue. Since the bug has been resolved, it is not expected to impact Devnet 6 or Holesky.

With Devnet 5 stable, attention has shifted toward Devnet 6, which is already set up within the testing environment (Hive).

Objectives for Devnet 6:

  1. Ensure execution & consensus tests pass successfully.
  2. Verify that system contract addresses are updated.
  3. Maintain stability & readiness for upcoming network upgrades.

A key discussion point involved updating system contract addresses to follow a new format:

  • Start with leading zeros for readability.
  • End with EIP numbers to align addresses with their corresponding Ethereum Improvement Proposal (EIP).

A PR was submitted to update addresses before the Prague fork. Most developers supported the change, agreeing that it improves clarity. The PR was merged immediately to avoid delays.

Pectra Mainnet Timeline

The discussion then moved to scheduling the upcoming Holesky & Sepolia testnet forks while also evaluating when to finalize the mainnet fork slot.

During a previous All Core Devs (ACD) call, the following dates were tentatively set:

Developers raised concerns about whether these deadlines were realistic due to Devnet 6 not yet launched, creating uncertainty in the timeline. Also, Devnet 5 participation is below 100%, indicating potential issues.

Core Developers wanted to Postpone testnet forks by one week to allow Devnet 6 to stabilize.

This adjustment ensures that developers have sufficient time to evaluate Devnet 6 performance before initiating major testnet upgrades. Readers can follow the Pectra Testnet & Mainnet Countdown at EIPs Insight.

Geth Bug & Fix

A critical bug was discovered in Geth's P2P networking layer, which affected Ethereum L2 solutions & could shut down nodes. Core Developers have advised everyone to upgrade immediately.

Pectra System Contract Audits

The Ethereum community places a strong emphasis on security, particularly when dealing with system contracts that are critical to the network’s execution layer. A comprehensive auditing process was conducted by four independent security firms: Blackthorn, Dedaub, Plainshift, and Sigma Prime.

Additionally, A16z Crypto contributed through formal verification using the Halmos framework. The audits were carried out in sequential order, meaning that each firm reviewed the contracts at different stages of development. This approach ensured that multiple experts reviewed the contracts at different refinement levels, with issues identified in earlier audits being resolved before being passed to the next auditor.

The primary focus was on EIP-7002 & EIP-7251, which deal with validator staking, withdrawals, & execution engine functionality. Following the audits, all security reports were made publicly available in an Ethereum GitHub repository.

Pectra Retrospective

With the Pectra upgrade nearing completion, the discussion transitioned into a retrospective analysis to assess what went well, what caused delays, and how future forks, particularly Fusaka, could be improved.

One of the major issues identified in Pectra was that too many unimplemented EIPs were added late, which significantly delayed the upgrade. Additionally, client teams worked independently on different features without proper coordination, leading to fragmented development efforts. Another key issue was testing delays, where multiple components were not adequately tested before being scheduled for inclusion. Lastly, decision-making inefficiencies slowed progress, as debates over which EIPs to prioritize extended for months.

From these challenges, key lessons were drawn for improving future forks. First, Ethereum developers emphasized the need to limit the number of EIPs per fork. Second, there was consensus on the importance of better testing & coordination. A rolling Devnet cycle was proposed to prevent bottlenecks, ensuring that features are tested in a structured environment before integration. Lastly, decision-making processes need to be more efficient, with a firm commitment to freezing the fork’s scope early in the process and avoiding unnecessary reopening of debates.

Fusaka Planning

With these lessons in mind, the conversation shifted to planning the Fusaka fork, which is set to follow Pectra. Developers agreed to take a more structured approach by prioritizing only two EIPs for Fusaka Devnet 1: EOF (EVM Object Format) and PeerDAS (Data Availability Sampling). No additional EIPs would be added until these two were fully implemented and stable. This approach aims to prevent the same delays that affected Pectra and ensure a manageable & predictable upgrade cycle.

Despite these improvements, some open questions remained. One ongoing debate was how to handle unfinished features—if an EIP isn’t ready for Fusaka, should it be removed entirely or postponed? Developers agreed that unfinished EIPs should not be included in Devnet 1 but could be reconsidered for later stages. Another major discussion point was the number of EIPs per fork—some felt limiting upgrades to just two EIPs per cycle might be too restrictive, while others argued that quality is more important than quantity.

Proposed EIPs for Fusaka

Two new EIPs were proposed: EIP-7793 (TX Index Precompile) and EIP-7843 (Slot Precompile). The TX Index Precompile introduces a precompiled contract that provides a transaction’s index within a block, helping encrypted mempools detect and prevent front-running attacks. MEV (Miner Extractable Value) exploits allow transaction order manipulation for profit, but this feature would enable smart contracts to enforce anti-front-running rules, enhancing security without off-chain solutions.

The Slot Precompile allows smart contracts to retrieve slot numbers dynamically, preventing issues when Ethereum’s slot timing changes. This removes the need for hardcoded slot lengths, improving contract adaptability and simplifying staking and governance updates. While both EIPs were well-received, some developers worried they could complicate testing alongside EOF and PeerDAS in Fusaka. Others saw them as minor improvements that wouldn’t disrupt development. The final decision remains open, pending further feedback from application developers.

Hardware & Bandwidth Requirements

As Ethereum continues to evolve, the demands on full nodes, block builders, and validators have increased. To maintain network efficiency while ensuring accessibility, developers discussed setting clear hardware and bandwidth benchmarks. The focus was on defining minimum RAM, CPU, and storage requirements, along with bandwidth thresholds needed for efficient block propagation. A key debate emerged around the proposed 50 Mbps upload speed requirement for block builders, with concerns that many node operators, particularly in regions with limited internet access, might struggle to meet this standard. Some developers suggested lowering the requirement to 25-30 Mbps to balance inclusivity with performance.

Another key discussion centered on local block building versus reliance on third-party builders. Many validators use MEV-Boost providers for block production, but in cases of network disruptions, they may need to fall back on local block building. To accommodate validators with limited bandwidth, developers considered introducing a "max blobs" flag, allowing smaller block production instead of exclusion. The staking community strongly pushed back on bandwidth requirements, pointing out that median internet speeds in many regions do not meet the proposed thresholds. In response, developers agreed to gather real-world data from existing validators to refine benchmarks and ensure a more practical and inclusive approach.

EIP 7823 - Mod EXP Precompile Boundaries

EIP-7823 improves the Modular Exponentiation (Mod EXP) precompile, a key function in cryptographic operations like RSA signature verification. The current version allows unbounded input sizes, causing consensus bugs, inefficiencies in ZK proofs, and unpredictable gas costs. Large inputs create inconsistencies between Ethereum clients, increasing the risk of network forks. ZK rollups also struggle with unbounded inputs, making gas estimation difficult.

To fix this, EIP-7823 proposes a 1028-byte limit per operand, supporting 8K RSA keys, the largest commonly used size. This ensures efficiency while preventing consensus issues. Historical data shows no past transactions used inputs over 512 bits, so existing contracts won’t be affected. Developers support the change, with the next step being a decision on its inclusion in Fusaka or a future fork.

Ethereum ACD Automation Bot

Given the increasing complexity of Ethereum’s development discussions, a new automation bot was introduced to streamline All Core Devs (ACD) meetings and governance processes. The growing number of EIPs, research threads, and testnet discussions has made it difficult for developers to track progress and maintain organized documentation.

The ACD automation bot is designed to record and transcribe ACD meetings, automatically post summaries to Ethereum Magicians and Discord, and tag relevant developers and contributors based on the topics discussed. One of its key features is the integration of AI-generated summaries, allowing developers and community members to quickly catch up on key discussions without watching full-length recordings.

In practice, the bot follows a structured workflow:

  1. When an ACD issue is created, the bot automatically schedules a meeting and posts relevant details.
  2. After the meeting, it records and transcribes discussions, ensuring that no important insights are lost.
  3. The bot automatically posts a structured summary in the appropriate Ethereum governance channels, making it easier to track decisions and ongoing proposals.
  4. Users can search past discussions using text-based queries, making it easier to find relevant information from previous meetings.

The benefits of automation include reducing manual work for Ethereum Core Devs, ensuring more transparency in governance, and minimizing documentation errors. The bot is currently in beta testing, with developers evaluating whether additional features—such as automated linking to pull requests or tracking EIP progress in real time—should be incorporated.

Readers can watch Ethereum's All Core Devs (ACDe) Meeting #204 here:

_____________________________________________________________________

Disclaimer: The information contained in this website is for general informational purposes only. The content provided on this website, including articles, blog posts, opinions, and analysis related to blockchain technology and cryptocurrencies, is not intended as financial or investment advice. The website and its content should not be relied upon for making financial decisions. Read full disclaimer and privacy Policy.

For Press Releases, project updates and guest posts publishing with us, email to contact@etherworld.co.

Subscribe to EtherWorld YouTube channel for ELI5 content.

Share if you like the content. Donate at avarch.eth or Gitcoin

You've something to share with the blockchain community, join us on Discord!

Follow us at Twitter, Facebook, LinkedIn, and Instagram.