The 152nd All Core Developers Execution (ACDE) call brought together key contributors to Ethereum’s execution layer to discuss critical upgrades, technical challenges, and strategic decisions shaping the network’s future. With the Shanghai upgrade on the horizon, developers focused on stabilizing timelines, refining EIPs, and ensuring backward compatibility while laying the groundwork for long-term scalability.
This article compiles detailed insights from the meeting, covering progress on the Shanghai upgrade, the removal of EOF-related changes, and discussions around EVM enhancements and serialization alignment between layers.
🔧 Shanghai Upgrade: Progress and Stability
The Shanghai upgrade remains a top priority for the Ethereum development community. The primary goal is to enable withdrawals of staked ETH, a highly anticipated feature that will unlock liquidity for validators and enhance network participation.
A developer-centric testnet has already been deployed, allowing all client implementations—Geth, Nethermind, Besu, and Erigon—to run in various combinations. While some integration issues were identified, teams are actively resolving them ahead of the next testnet rollout.
👉 Discover how Ethereum upgrades are tested and secured before mainnet deployment.
Key Adjustments to EIP-3860
One notable refinement discussed was a small but significant change to EIP-3860 — Limit and meter initcode. This EIP introduces gas metering for contract initialization code (initcode) and enforces size limits to prevent abuse.
Currently, exceeding the initcode size limit results in a return of the zero address, which can lead to ambiguous behavior across clients. Marius van der Wijden from the Geth team proposed modifying this so that violations trigger an Out-of-Gas (OOG) error instead, halting execution cleanly.
This adjustment aims to:
- Reduce implementation discrepancies
- Prevent potential vulnerabilities
- Improve error handling predictability
While client teams support the change, developers acknowledged that strong feedback from smart contract builders could influence the final decision—ensuring real-world usability isn't compromised.
🚫 EOF-Related Changes Removed from Shanghai Upgrade
A major decision during the call was the removal of EOF (EVM Object Format) modifications from the Shanghai upgrade. This move prioritizes timeline stability over feature expansion.
What Is EOF?
EOF, or EVM Object Format, is a proposed binary format designed to improve code clarity and future-proofing within the Ethereum Virtual Machine. It introduces structural separation between code and data in smart contracts and lays the foundation for more efficient execution and future EVM upgrades.
Despite promising progress—Geth and Besu have near-complete implementations, while Nethermind and Erigon are advancing—developers agreed that including EOF in Shanghai posed scheduling risks.
Why Was EOF Removed?
Several factors influenced this decision:
- Testing Complexity: Mario Vega from the Ethereum Foundation noted that EOF’s complexity makes static testing difficult. Bugs may surface unpredictably due to layered interactions.
- Implementation Risks: Fuzz testing by @mhswende revealed bugs across multiple clients, indicating that full stability is still underway.
- Timeline Pressure: Adding EOF could delay the public testnet launch by ~one month—threatening the planned March 2023 mainnet deployment.
- Irreversibility: EVM changes are permanent once deployed; rushing increases long-term technical debt.
As stated in the meeting: "We cannot afford to get EVM changes wrong."
🔄 Vitalik’s Proposal: Restricting Code Introspection in EOF
Vitalik Buterin introduced a forward-looking proposal to ban code introspection in EOF accounts, aiming to simplify future EVM evolution.
The Challenge of EVM Upgrades
Unlike consensus-layer changes (like moving from PoW to PoS), EVM modifications must maintain backward compatibility. Smart contracts rely on specific behavioral assumptions; altering them risks breaking existing applications.
Buterin emphasized that:
“Removing a feature in EVM is harder than removing proof-of-work because apps depend on EVM semantics.”
This means new versions like EOF may need to coexist indefinitely with legacy formats—making simplicity crucial.
His proposal suggests limiting self-inspection capabilities (e.g., CODECOPY, EXTCODESIZE) in EOF v1 contracts. This would reduce dependency risks and make future upgrades safer.
While authors of EOF had previously considered such restrictions, they opted for simplicity in v1. Alex Beregszaszi (@alexberegszaszi) suggested deferring this enhancement to EOF v2, allowing v1 to ship sooner while preserving upgrade paths.
👉 Learn how next-gen EVM designs could transform dApp development efficiency.
🔗 Serialization Mismatch: Bridging Execution and Consensus Layers
Developers discussed a growing pain point: inconsistent serialization formats between Ethereum’s execution and consensus layers.
Etan Kissling from Nimbus proposed adding a hexary tree root to the ExecutionPayloadHeader transaction list. Currently:
- Execution layer uses RLP encoding
- Consensus layer uses SSZ (Simple Serialize)
This mismatch creates overhead for wallets and light clients, which must decode both formats when verifying transactions or blocks.
Two potential solutions are under review:
- Introduce SSZ into the execution layer
- Enable consensus clients to support RLP parsing
Though not part of Shanghai, resolving this soon will improve interoperability and client efficiency. A follow-up discussion is scheduled for the upcoming Consensus Layer meeting (ACDC).
⚙️ Exploring Future EVM Enhancements
Two additional EIPs were briefly discussed:
EIP-5843: Modular Arithmetic Extensions
Aims to optimize mathematical operations in the EVM, particularly useful for zk-SNARKs and other cryptographic computations. Due to the author’s absence, discussion was postponed.
EIP-5988: Poseidon Hash Precompile
Proposed by StarkWare, this EIP introduces Poseidon, a cryptographic hash function optimized for zero-knowledge proofs. By implementing it as a precompiled contract, ZK-rollups could achieve faster proof generation on-chain.
However, concerns remain:
- Potential attack vectors
- Increased complexity in EVM security models
- Long-term maintenance burden
Further analysis is required before integration.
✅ FAQ: Common Questions About Ethereum’s Roadmap
Q: When is the Shanghai upgrade expected to go live?
A: The target is March 2023, following a public testnet rollout in February. Final timelines depend on successful testing across all client implementations.
Q: Why were EOF changes removed from Shanghai?
A: To avoid delays and ensure staking withdrawals launch on schedule. EOF remains on track for inclusion in the subsequent Cancun upgrade, likely alongside EIP-4844 (proto-danksharding).
Q: Will EOF break existing smart contracts?
A: No. EOF is designed to be backward compatible. Legacy contracts will continue functioning normally alongside new EOF-formatted ones.
Q: What are the benefits of enabling staked ETH withdrawals?
A: Validators will be able to exit and withdraw their staked ETH and rewards, increasing liquidity and trust in the network’s decentralization and flexibility.
Q: How does restricting code introspection help future upgrades?
A: Limiting introspection reduces dependencies on low-level contract behaviors, making it safer to modify or deprecate features in future EVM versions without breaking existing apps.
Q: Is Ethereum moving toward an "EVM 2.0"?
A: Not exactly. Instead of a hard break, Ethereum is evolving through incremental improvements like EOF and modular precompiles—ensuring continuity while enabling innovation.
Final Thoughts
The 152nd core developers meeting underscored Ethereum’s disciplined approach to protocol evolution: prioritizing stability, security, and long-term maintainability over rapid feature delivery.
By deferring complex changes like EOF and focusing on critical functionality such as staking withdrawals, the team reinforces confidence in Ethereum's upgrade process.
Looking ahead, Cancun will likely become the next major milestone—potentially combining EOF with data sharding via EIP-4844—to further scale rollups and reduce transaction costs.
As always, coordination across client teams, rigorous testing, and community transparency remain central to Ethereum’s success.
👉 Stay updated on Ethereum’s latest upgrades and developer milestones.