• Fusaka Devnet 3 & 4 Testing Update

• Blob Throughput Schedule for Post-Fusaka

• Glamsterdam Upgrade Headliners Announced

The latest Fusaka test network (Devnet 3) has been running smoothly, with almost perfect validator participation. Developers have been stress-testing the network by taking large portions of validators offline (both regular and “super” nodes) to see how quickly it recovers—sometimes healing in under a minute.
Next up is Devnet 4.

Why it matters:
These tests help ensure Ethereum’s next upgrade can handle failures, malicious behavior, and scaling to higher throughput without breaking consensus.

Next Steps:

• Finish current recovery and malicious-action tests on Devnet 3.

• Launch Devnet 4

• Present results in ~2 weeks.

Timeline:

• Devnet 4 Genesis: tomorrow morning.

• Results review: ~2 weeks.

Ethereum’s upcoming data-availability scaling uses “blob” transactions. The team is deciding how quickly to raise the per-block blob limit after Fusaka ships. The current proposal: three blob-limit increases, about one month apart, targeting 21 blobs per block (max 32). Future phases in 2026 could push that toward 48 blobs if testing looks good.

Why it matters:
More blobs mean cheaper and more plentiful Layer-2 data, unlocking growth for rollups, and other high-data apps.

Next Steps:

• Use Devnet 4 results to confirm safe target limits.

• Finalize a blob-increase schedule balancing speed with security.

Timeline:

• Fusaka upgrade: late Oct–early Nov 2025.

• Blob Phase 1: Dec 2025 – Feb 2026.

• Larger scaling phase: early/mid-2026.

Client teams (Lodestar, Prism, Nimbus) requested four extra weeks before cutting final Fusaka releases, citing the need to:

• Merge all changes into main branches (“trunk”), not just feature branches.

• Run a stable Devnet with no spec changes and fully merged code.

• Test without crutches like get_blobs_v2 to ensure private mempool robustness.

Why it matters:
Rushing could risk mainnet instability—past upgrades have shown small overlooked issues can cause big headaches.

Next Steps:

• Target Holesky testnet in September 2025.

• Run at least one “trunk-only” Devnet before mainnet.

• Keep Fusaka mainnet date flexible depending on results.

Timeline:

• Holesky testnet: Sept 2025.

• Mainnet launch: Nov 2025 (still target, but could change).

Discussion on simplifying the Beacon API so Layer-2s and other consumers can just request the blob data directly—without extra consensus metadata they don’t need.

Why it matters:
Cleaner APIs make it easier for rollups to integrate and reduce unnecessary data transfer.

Next Steps:

• Gather Layer-2 feedback on proposed API changes.

• Finalize the PR in the Beacon API repo.

Timeline:

• Async feedback: Aug–Sept 2025.

• Implementation: Likely in a post-Fusaka update.

On the call, Core Developers agreed to select ePBS (Enshrined Proposer-Builder Separation) as the consensus headliner and BALs (Block-level Access Lists) as the execution headliner in the Glamsterdam upgrade, which will be the next hard fork after Fusaka goes live on mainnet in November. Additionally, Core Devs agreed to add FOCIL (EIP-7785) as a CFI (Candidate for Inclusion). FOCIL has strong community and client support but will only be elevated if ready without delaying the fork.

Why it matters:
ePBS improves fairness and efficiency in block building. FOCIL strengthens block inclusion rules to make Ethereum more censorship resistant..

Next Steps:

• Prioritize ePBS spec & testing.

• Continue FOCIL development in parallel

• Decide on FOCIL's inclusion after more testing is conducted and timelines are identified.

This working group focuses on making different Ethereum Layer-2 networks work together seamlessly. On the latest call, they discussed:

• Updates from The Signal: Ethereum, Boundless, and OIF (Open Intents Framework) projects.

• Work on permissionless, asynchronous composability—making apps across L2s interact without direct coordination.

• Progress on ENS integration so names work seamlessly across L2s.

Why it matters:

• Better L2 interoperability means a smoother user experience.

• Unlocks more complex, cross-chain applications.

Next Steps:

• Implement ENS resolver upgrades in test environments.

• Keep refining L2-to-L2 transaction standards.

Client teams reviewed progress on Devnet 3, with most nodes stable except for ongoing sync and crash issues in Lodestar and Nimbus. MEV and builder testing continues, with fixes in progress for a private mempool bug. Developers agreed to keep the per-transaction gas limit at 16M while running stateful and “bloatnet” tests before considering larger blocks. Other discussions covered slot-timing config cleanup, deferring the custody-group change (EIP-4477), and improving “perfect-peers” syncing so nodes can reconstruct data without relying on special super-nodes. Work also advances on backfilling historical blob data.

Why it matters

• Improves reliability and sync performance ahead of future upgrades.

Client teams are working on integrating the “3SF mini” consensus feature into their software. One team found they needed to make changes to match Ethereum’s serialization format (SSZ), such as removing optional fields and switching string-based hashes to fixed 32-byte formats. Other teams prefer keeping optional fields, noting they’re not hard to implement. There’s also interest in unifying “Ethereum types” across both the consensus and execution layers for consistency.

Why it matters:

• Aligning formats now prevents future incompatibility headaches.

• Using the same types across layers could simplify Ethereum development long-term.

Next Steps:

• Review and comment on the pull request with these changes.

• Explore adding missing types to the Ethereum types library.

• Connect with Sam Wilson (maintainer) for guidance.

Since this post-quantum devnet doesn’t use execution clients, normal peer discovery won’t work. The current idea is to hardcode a fixed list of participating peers into the genesis configuration, keeping the setup simple.

Why it matters:

• A stable peer list avoids extra moving parts in an early-stage test network.

Next Steps:

• Finalize peer list for Devnet Zero.

• Decide if adding peers later should be supported or locked.

The devnet needs a way to simulate certain cryptographic proofs without the real computation. The group discussed using placeholder SNARK data as a stand-in. Some developers have different opinions on the approach, but there’s agreement to move forward with a placeholder solution for now.

Why it matters:

• Lets the network run tests before the full cryptography is ready.

Next Steps:

• Define a placeholder SNARK data format.

• Implement it in participating clients.

Progress on the spec repository is going smoothly. The Poseidon 2 sub-spec (a hashing function used in zk-proof systems) has been merged and is ready for further testing.

Why it matters:

• Finalizing cryptographic components early helps avoid major design changes later.

Next Steps:

• Begin implementing Poseidon 2 in test code.

• Continue refining the post-quantum specs in the repo.

Author: Vitalik Buterin

Ethereum’s consensus—the way the network agrees on the “official” chain—currently links two parts tightly: the fork-choice rule (LMD-GHOST) and the “finality gadget” that locks in decisions. Vitalik suggests loosening this link so each can run with different numbers of validators. This could make Ethereum more responsive and secure when blocks are finalized in just 3 slots (~18 seconds), even with network delays.

Why it matters:

• Faster finality means users can trust their transactions sooner.

• Reducing validator load for some tasks can improve performance without sacrificing security.

Author: Anders Elowsson

Right now, Ethereum has different fee systems for different “resources” (like gas for computation and calldata for transaction size). EIP-7999 proposes a single, unified fee so users just set one maximum and it covers all resources.

Why it matters:

• Makes fees simpler for wallets and users.

• Improves capital efficiency for traders and apps.

• Reduces friction for developers adding new transaction types.

Author: Toni Wahrstatter

Ethereum sometimes gives “gas refunds” if you clean up blockchain storage, making your transaction cheaper. But these refunds also make it look like a block used less gas than it actually did, allowing more to fit—like a speedometer that underreports your speed. This post suggests keeping the incentive but not letting refunds distort block size accounting.

Why it matters:

• Keeps incentives for cleaning up data.

• Prevents overloaded blocks that slow the network.

Contributors: Benedict Wagner, Thomas Coratger, Ignacio Hagopian, Ma-Julian, Kevaundray, Cody Gunton

A new online resource (book) explains how zkEVMs work—these are special versions of Ethereum that use zero-knowledge proofs to verify transactions more efficiently. They’re a key part of scaling Ethereum to handle more users at lower cost. The book covers core concepts, design trade-offs, and real-world implementation details.

Why it matters:

• Helps developers understand and build zkEVM-based apps.

• Bridges the gap between theoretical cryptography and practical Ethereum use.

• Composable Token Policies – Flexible token rules for RWAs, gaming, DAOs.

• ERC-7943 (uRWA) – Standard interface for tokenized real-world assets.

• ERC-20 Pre-init Extension – Gas savings for first-time token receivers.

• Confidential Fungible Token – Privacy-preserving fungible tokens.

• ERC-7811 – Wallet auto-discovers all linked assets.

• EIP-7503 – ZK Wormholes for private proof-of-burn.

• ERC-7995 – Encrypted on-chain data.

• EIP-5630 – Native EVM encryption/decryption opcodes.

• ERC-8001 – Secure intent coordination for autonomous agents.

• EIP-7999 – Unified multidimensional fee market.

• EIP-7928 – Block-level access lists.

• EIP-7979 – Call/Return opcodes for efficient execution.

• EVM64 – 64-bit EVM upgrade.

• EIP-7939 – Count-leading-zeros opcode.

• CREATE2 Factory Precompile / Deterministic Bytecode Deploy – Consistent deployment across networks.

• EIP-7495 – SSZ ProgressiveContainer upgrades.

• Safe, Version-Agnostic Deployment – Same contract address across EVMs.

• EIP-7892 – Blob-only hardforks.

• EIP-7947 – Account recovery for smart accounts.

• ERC-4337 – Entry Point-based account abstraction.

• ERC-8000 – Operator contracts for EOAs.

• Metamask Snap Integration – Easy custom wallet installs.

• ERC-8002 – Simplified payment verification gateway.

• Ethereum 1.x Ring – Linking old and new Ethereum designs.

• 32-Byte Addresses – Future-proof address format.

• ERC-7985 – Metadata for message gateways.

• ERC-8001 Draft – Secure multi-agent coordination.

• Modular zk-WASM – WASM + zero-knowledge execution.

• Node Hardware/Bandwidth Guide – Updated validator specs.

• Glamsterdam Headliners – Feedback on next upgrade features.

For more updates like these subscribe to Ethereum Daily and follow us on the social media platforms below.

Disclosures: Ethereum Daily is an independent publication and does not offer financial or investment advice. Content may include opinions, affiliate links, or references to projects in which contributors have a financial interest. Always do your own research.