With the launch of Fusaka Devnet 2 scheduled for June 23, Ethereum developers are set to begin coordinated testing of a tightly scoped package of Ethereum Improvement Proposals (EIPs).

The selected EIPs reflect a cohesive upgrade path for Ethereum’s near future roadmap. They touch on consensus roles, blob handling mechanics, opcode efficiency, and transaction level safeguards, all being tested in an integrated environment for the first time.

EIPs Included in Fusaka Devnet 2

Below is a summary of each proposal and its expected impact during Devnet 2:

  1. EIP-7607: Fusaka Meta EIP: This is a proposal for the Fulu/Osaka network upgrade, listing Ethereum Improvement Proposals (EIPs) for potential inclusion. It includes core EIPs related to gas limits, transaction fees, and code execution, and other EIPs for potential future upgrades. This Meta EIP provides an overview of proposed changes with links to detailed specifications, aiding in the Ethereum network's evolution.
  2. EIP-7594: PeerDAS – Peer Data Availability Sampling: This proposal helps in enabling beacon nodes to perform data availability sampling. PeerDAS utilizes gossip for distribution and discovery, allowing nodes to sample data subsets while ensuring data availability. This enhances scalability by alleviating the need for full data downloads on all nodes.
  3. EIP-7823: Set Upper Bounds for ModExp: This proposal introduces an upper limit on the inputs of the MODEXP precompile to reduce bugs and facilitate replacement with EVM code. The proposal specifies a maximum input length of 1024 bytes for each of the length_of_BASE, length_of_EXPONENT, and length_of_MODULUS fields. This limit is based on an analysis of past transactions and supports common use cases like RSA verification and elliptic curve operations.
  4. EIP-7825: Transaction Gas Limit Cap: This proposal proposes a 30 million gas cap per transaction. This limit mitigates state bloat, ensures fair gas allocation, and improves block validation. The cap is independent of the block gas limit, allowing complex transactions while maintaining network performance and security. Existing transactions below the cap remain unaffected, ensuring backward compatibility.
  5. EIP-7883: ModExp Gas Cost Increase: This EIP proposes modifications to the ModExp precompile pricing algorithm, increasing the minimum price from 200 to 500 and adjusting costs for larger exponent, base, and modulus lengths. These changes ensure the worst-case performance is no worse than the EcRecover precompile, addressing underpriced scenarios. The update is backward incompatible but follows precedented gas repricing.
  6. EIP-7892: Blob Parameter Only Forks (BPO): This EIP introduces Blob Parameter Only (BPO) hard forks, a mechanism to scale Ethereum's blob capacity. BPO forks modify blob-related parameters without changing the underlying code, allowing rapid and low-overhead scaling to meet L2 demand. This proposal reduces the complexity of upgrades and provides a predictable scaling path for builders and L2 solutions.
  7. EIP-7907: Meter Contract Code Size and Increase Limit: This EIP
    proposes increasing the hard contract code size limit to 256KB from 24KB, with a proportional gas cost increase for larger contracts to prevent DoS attacks. This change aims to improve developer flexibility and experience by reducing the need for complex workarounds, enhancing code readability, and making smart contract development more accessible.
  8. EIP-7917: Deterministic Proposer Lookahead: This EIP aims to enhance the Ethereum blockchain's security and performance by introducing a deterministic proposer schedule. It addresses a design oversight in the beacon chain by proposing a proposer_lookahead field, storing the next proposer schedule in the beacon_state. This change ensures the proposer schedule is predictable and accessible to the application layer, simplifying preconfirmation protocols and improving DDoS resistance. The update also prevents validators from manipulating the proposer schedule through effective balance grinding, enhancing the network's security and performance.
  9. EIP-7918: Blob Base Fee Bounded by Execution Cost: This EIP addresses an issue with the dynamic pricing auction used to set the blob base fee, which can fail when the fee is a small fraction of the total cost. A reserve price is introduced, linking the blob base fee to execution gas costs, ensuring the auction functions properly and users pay a fair price for compute resources. This prevents fee spikes and improves blobspace scaling.
  10. EIP-7934: RLP Execution Block Size Limit: This EIP proposes a 10 MiB cap on Ethereum's block size to prevent network instability and DoS attacks caused by large blocks. A 2 MiB margin accommodates beacon block sizes. This change enhances network security and performance, but it is not backward compatible with larger blocks.
  11. EIP-7939: Count Leading Zeros (CLZ) Opcode: This EIP introduces a new opcode, CLZ(x), which counts the leading zero bits in 'x' and pushes the result onto the stack. This basic computing block improves math operations, compression algorithms, and data structures, reducing compute and ZK proving costs.

What to Expect During Devnet 2?

The launch will test not just the correctness of these proposals, but also their interoperability across clients, impact on network throughput, and resource behavior under stress. Key areas of focus include:

  • Validator custody credential testing (0x02 format)
  • Blob pool reconstruction and inclusion
  • Performance of PeerDAS under real-time conditions
  • Transaction rejection for over-limit gas scenarios
  • RAM overhead post-fulu activation

Testing will also explore blob propagation timing, supernode behavior, and blob scheduling alignment in fork transitions. Assertoor, Spamoor, and Kurtosis configurations will simulate edge-case and attack scenarios.

Conclusion

With these EIPs under evaluation, developers aim to gather clear data and consensus before considering mainnet adoption later this year. If successful, these proposals will collectively enhance Ethereum’s scalability, validator safety, and upgrade agility.

If you find any issues in this blog or notice any missing information, please feel free to reach out at yash@etherworld.co for clarifications or updates.

Related Articles

  1. Ethereum Fusaka Devnet 0 Coming Soon
  2. Will Fusaka Be Ready in Time? Vitalik's 2025 Vision
  3. Glamsterdam: The Next Upgrade After Fusaka
  4. Ethereum Developers are Rethinking Transaction Signatures & Authority
  5. Censorship Resistance Vs Scalability
_____________________________________________________________________

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.

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

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