The Ethereum Berlin Upgrade

·

Ethereum’s evolution continues with the Berlin upgrade, marking a pivotal step in the network’s journey toward scalability, efficiency, and future readiness. After a nearly 16-month gap without major upgrades, Ethereum re-emerged with focused improvements designed to optimize gas usage, enhance transaction flexibility, and strengthen network security. This article explores the technical depth of the Berlin upgrade, its key components, and its significance in Ethereum’s broader roadmap.

Why “Berlin”? Understanding Ethereum’s Upgrade Naming Convention

Ethereum upgrades are named after cities to honor locations where significant Ethereum developer conferences—known as Devcons—have taken place. The Berlin upgrade pays tribute to “Devcon 0,” held in Berlin from December 2019 to January 2020. Following this tradition, the next upgrade was later named “London,” referencing the city that hosted Devcon 1.

This naming convention not only adds a cultural touch but also symbolizes community and collaboration—core values in Ethereum’s decentralized ethos.

👉 Discover how blockchain upgrades shape the future of decentralized networks.

Predecessor Upgrades: Istanbul and Muir Glacier

Before diving into Berlin, it's important to understand the immediate upgrades that paved the way.

The Istanbul Upgrade (December 2019)

Launched at block 9,069,000, the Istanbul upgrade introduced six key Ethereum Improvement Proposals (EIPs), including:

These changes laid foundational support for privacy-preserving technologies and cross-chain security.

The Muir Glacier Upgrade (December 2019)

At block 9,200,000, Ethereum implemented EIP-2384, which delayed the “Difficulty Bomb” by approximately 611 days (4 million blocks). The Difficulty Bomb is a mechanism that gradually increases mining difficulty to incentivize the transition from Proof-of-Work (PoW) to Proof-of-Stake (PoS). Without periodic delays, the bomb could trigger an “ice age,” slowing block production to a crawl.

Muir Glacier ensured network stability during Ethereum’s long-term shift toward Eth2.

Berlin Upgrade: Key Details and Timeline

The Berlin upgrade activated on the Ethereum mainnet at block 12,244,000, around April 14, 2021. While block times are variable, this date marked a coordinated effort across client teams and node operators.

Prior to mainnet deployment, Berlin was rolled out across major testnets:

Node operators were advised to upgrade their clients—such as Geth or OpenEthereum—before the activation block to remain synchronized with the network.

Core EIPs in the Berlin Upgrade

The Berlin upgrade incorporated four critical EIPs aimed at optimizing gas efficiency, enhancing transaction types, and improving state access security.

EIP-2565: Reduce ModExp Gas Cost

Modular exponentiation (ModExp) is a core operation in advanced cryptographic protocols like zk-SNARKs and verifiable delay functions (VDFs). Prior to EIP-2565, introduced in EIP-198, the gas cost for ModExp was prohibitively high, discouraging widespread use.

EIP-2565 recalibrates the gas pricing formula to better reflect computational effort. By reducing costs significantly—sometimes by over 90%—this change enables more efficient execution of privacy-preserving and scaling technologies.

For example, zkRollups and other layer-2 solutions relying on zero-knowledge proofs benefit directly from cheaper ModExp operations, accelerating adoption of scalable dApps.

👉 Learn how cutting-edge blockchain features power next-generation applications.

EIP-2718: Typed Transaction Envelope

Before EIP-2718, all Ethereum transactions followed a uniform structure defined by RLP encoding. This rigidity made it difficult to introduce new transaction types without risking backward incompatibility.

EIP-2718 introduces a typed transaction envelope, a wrapper format that allows future transaction types to coexist with legacy ones. Each transaction begins with a type byte:

This innovation paves the way for features like:

By decoupling transaction format from execution logic, EIP-2718 future-proofs Ethereum’s transaction layer.

EIP-2929: Increase Gas Costs for State Access Opcodes

State access operations—such as reading account balances or calling contracts—have historically been underpriced in terms of gas. This led to Denial-of-State (DoS) attacks, where attackers exploited cheap opcodes like SLOAD, BALANCE, and EXTCODESIZE to flood nodes with I/O-heavy transactions.

EIP-2929 addresses this by:

Specifically:

These adjustments better reflect real-world resource consumption and mitigate attack vectors targeting node performance.

EIP-2930: Optional Access Lists

Complementing EIP-2929, EIP-2930 introduces a new transaction type that includes an access list—a predefined list of addresses and storage keys a transaction intends to access.

Benefits include:

For example, a DeFi user swapping tokens through multiple contracts can pre-declare accessed addresses, avoiding high gas charges during first-time lookups.

While optional, access lists improve efficiency for complex transactions and serve as a stepping stone toward account abstraction.

Frequently Asked Questions (FAQ)

Q: What was the main goal of the Ethereum Berlin upgrade?
A: The primary goals were to optimize gas pricing, improve resistance to DoS attacks, and lay groundwork for future innovations like account abstraction and layer-2 scaling.

Q: Did the Berlin upgrade affect ETH price or mining rewards?
A: No. Unlike upgrades such as London (which introduced fee burning), Berlin did not alter issuance rates or block rewards. Its changes were primarily technical and backend-focused.

Q: How did EIP-2718 impact wallet developers?
A: Wallets needed updates to support typed transactions. However, backward compatibility ensured older wallets continued functioning without disruption.

Q: Was there a hard fork involved in the Berlin upgrade?
A: Yes. Berlin was a scheduled hard fork requiring all node operators to upgrade their software. Nodes that didn’t upgrade were left on an incompatible chain.

Q: How does Berlin relate to Ethereum 2.0?
A: While Berlin operates on the original PoW chain, its improvements—especially in efficiency and security—support smoother integration with Eth2’s eventual merge.

Q: Can I still use old transaction formats after Berlin?
A: Yes. Legacy transactions remain fully supported. EIPs like 2718 and 2930 are backward-compatible enhancements.

Looking Ahead: From Berlin to London and Beyond

The Berlin upgrade set the stage for subsequent milestones, most notably the London upgrade, which introduced EIP-1559 and base fee burning. Together, these upgrades reflect Ethereum’s strategy: iterative improvements that enhance security, usability, and scalability while preparing for full PoS transition.

As Ethereum moves toward sharding, rollups, and account abstraction, foundational upgrades like Berlin remain crucial infrastructure work—unseen by most users but essential for long-term success.

👉 Stay ahead of blockchain innovation with insights from leading crypto platforms.

Conclusion

The Ethereum Berlin upgrade may not have brought headline-grabbing changes like token burns or staking rewards, but its technical refinements are vital for network health. By optimizing gas costs, introducing flexible transaction formats, and strengthening defenses against abuse, Berlin reinforced Ethereum’s resilience and adaptability.

For developers, researchers, and long-term investors, understanding these under-the-hood upgrades provides deeper insight into Ethereum’s sustainable growth trajectory—one city-named fork at a time.

Core Keywords: Ethereum Berlin upgrade, EIP-2718, EIP-2930, ModExp gas cost, typed transaction envelope, access lists, state access opcodes, Ethereum roadmap