As Ethereum’s Fusaka upgrade advances through its release cycle, the focus is now shifting toward the next critical milestone: Devnet 3. While Devnet 2 concentrated on initial client readiness and inclusion of baseline EIPs, Devnet 3 has been formally planned to refine, benchmark, and finalize proposals that require more careful tuning before mainnet deployment.
This stage will not introduce major new features. Instead, it will optimize and finalize several important elements from Devnet 2, ensuring gas pricing, performance constraints, and consensus parameters are correctly calibrated.
1. EIP-7907: Meter Contract Code Size And Increase Limit
EIP-7907, which was included in Devnet 2, introduces dynamic gas metering for contracts exceeding 24KB in size.
However, due to concerns about implementation complexity and performance profiling, a more conservative version with a 48KB maximum code size has been proposed for Devnet 3.
2. EIP- 7951: Precompile for secp256r1 Curve Support
EIP-7951 introduces a native precompile for the secp256r1 (R1) elliptic curve, widely used across various cryptographic systems.
While Devnet 2 included this feature with temporary placeholder gas pricing, Devnet 3 will focus on benchmarking and updating the gas costs to ensure they are fairly aligned with computational effort.
3. EIP-7918: Blob base fee bounded by execution cost
EIP-7918 proposes linking blob base fees to actual execution gas costs to ensure that blob transactions contribute proportionally to block usage.
The current static base fee model has been criticized for allowing blobs to become underpriced relative to the execution layer, which could negatively impact fee market efficiency and validator incentives.
4. EIP-7892: Blob Parameter Only Hardforks
EIP-7892, allows incremental scaling of Ethereum's blob capacity. BPO forks modify blob-related parameters without requiring extensive coordination or introducing broader protocol changes.
This approach enables rapid and low-overhead scaling to meet L2 DA demand and reduce operational overhead. BPO forks enhance stability, provide predictable upgrades for builders, and are implemented through configuration changes without client-side code modifications.
5. EIP-7975: ETH/70 - Partial Block Receipt Lists
EIP-7975 is a client-side change designed to address a sync scalability limitation in block receipt handling.
This fix will be rolled out alongside Fusaka client releases and validated in Devnet 3 for performance and correctness, particularly under high-throughput scenarios.
Conclusion
Fusaka Devnet 3 will serve as the final checkpoint before Ethereum’s next hard fork enters a freeze phase. Rather than pushing new features, its goal is precision: benchmarking, repricing, and refining proposals that have already passed conceptual review.
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
- EIPs Included in Fusaka Devnet 2: What to Expect?
- Ethereum Prepares Validator Custody Rollout with Fusaka Devnet 2
- Ethereum Considers 45 Million Gas Limit for Fusaka Upgrade
- History Expiry Moves Forward in Ethereum’s Fusaka Upgrade
- A Closer Look at What’s Coming in Fusaka Devnet 2
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!