The Ethereum Berlin upgrade marks a pivotal step forward in the evolution of the Ethereum network. Designed to enhance efficiency, reduce transaction costs, and lay the groundwork for future scalability improvements, Berlin is more than just a routine update—it’s a strategic milestone in Ethereum’s long-term roadmap.
Scheduled for deployment across major testnets and eventually Ethereum mainnet, this upgrade brings a suite of Ethereum Improvement Proposals (EIPs) that refine how transactions are processed and how gas fees are calculated. Whether you're a developer, node operator, or casual user, understanding the implications of the Berlin upgrade is essential.
What Is the Berlin Upgrade?
The Berlin upgrade is a network-wide protocol update to the Ethereum blockchain. It follows previous upgrades like Istanbul and Muir Glacier and introduces critical optimizations focused on gas pricing, transaction structure, and smart contract execution.
Unlike hard forks that aim for dramatic shifts (such as the upcoming transition to proof-of-stake), Berlin focuses on incremental but impactful improvements. These changes are designed to smooth out inefficiencies and prepare the network for larger transformations down the line.
Key characteristics:
- Targets improved transaction efficiency
- Reduces costs for certain cryptographic operations
- Introduces flexible transaction formats
- Enhances security through adjusted gas costs
👉 Discover how blockchain upgrades shape the future of decentralized networks.
Berlin Upgrade Timeline
After months of coordination among client teams and community stakeholders, the Berlin upgrade was rolled out in stages across Ethereum’s testnet environments before reaching mainnet.
The activation schedule was based on specific block numbers to ensure synchronization across nodes:
- Ropsten: Block 9,812,189 — March 10, 2021
- Goerli: Block 4,460,644 — March 17, 2021
- Rinkeby: Block 8,290,928 — March 24, 2021
- Mainnet: Block 12,244,000 — April 14, 2021
Due to natural variability in block times, exact calendar dates could shift by a few hours. Node operators were strongly advised to upgrade their software at least several days before each target date to avoid disruptions.
This phased rollout allowed developers and validators to test compatibility, monitor performance, and address potential issues before the mainnet launch.
Required Client Versions
To remain synchronized with the upgraded network, all Ethereum node operators needed to update their client software to a Berlin-compatible version. Running outdated clients would result in chain divergence—meaning nodes would continue following obsolete rules and become incompatible with the rest of the network.
Supported client versions include:
- go-ethereum (Geth): v1.10.1
- OpenEthereum (formerly Parity): v3.2.0
- Nethermind: v1.10.31
- Besu: v21.1.1**
These updates support Berlin across both testnets and mainnet. Projects like TurboGeth and EthereumJS planned releases ahead of mainnet activation, while Trinity was officially deprecated and did not support the upgrade.
Staying current with client updates ensures participation in consensus and maintains the integrity of decentralized validation.
Core EIPs in the Berlin Upgrade
The Berlin upgrade implements four key Ethereum Improvement Proposals (EIPs), each addressing distinct aspects of network functionality:
EIP-2565: ModExp Gas Cost
This proposal reduces the gas cost of the ModExp precompile—a function used in certain zero-knowledge proof applications. By making complex cryptographic computations more affordable, EIP-2565 supports advanced privacy and scaling solutions built on Ethereum.
EIP-2929: Increased Gas Costs for State Access
To counter denial-of-service risks from excessive state access, this EIP raises gas costs for operations like SLOAD, *CALL, BALANCE, and others when used for the first time in a transaction. This discourages spam attacks while encouraging efficient contract design.
EIP-2718: Typed Transaction Envelope
A foundational change, EIP-2718 introduces a new transaction format that acts as a wrapper for different transaction types. This "envelope" structure makes it easier to introduce new transaction formats in future upgrades without breaking existing infrastructure.
EIP-2930: Optional Access Lists
Complementing EIP-2929, this feature allows transactions to specify an access list—a set of addresses and storage keys they intend to interact with. Pre-declaring these accesses mitigates the increased gas costs from EIP-2929 and enables smoother execution for contracts interacting with known addresses.
Together, these EIPs represent a balanced approach: improving security and flexibility without sacrificing backward compatibility.
Frequently Asked Questions (FAQ)
Why is it called “Berlin”?
Following Istanbul, Ethereum developers adopted a naming convention based on Devcon conference locations. Berlin hosted Devcon 0, making it the natural choice for this upgrade. The next major update was named London—location of Devcon 1—continuing the tradition.
Do regular users need to take any action?
Most users do not need to act. If you use a wallet service like MetaMask, Trust Wallet, or an exchange such as Coinbase or Binance, your provider handles protocol changes automatically. You’ll only need to act if your service explicitly notifies you of required steps.
What should node operators or miners do?
Node operators must upgrade their Ethereum client software to one of the approved versions listed above before the fork block on each network. Failure to upgrade results in being left behind on an obsolete chain, unable to validate or transact on the updated network.
What happens if I don’t upgrade my node?
An un-upgraded node will remain on the pre-fork chain, following old consensus rules. It will be isolated from the main network, unable to process new transactions or synchronize with updated peers. This can lead to incorrect balance displays and failed interactions.
How does a network upgrade work in Ethereum?
A network upgrade is a coordinated change to Ethereum’s protocol rules. Developers implement proposed changes in client software, and activation occurs at a predetermined block number. All participants must adopt the new rules for consensus to remain intact—otherwise, chain splits may occur.
Are there risks involved with protocol upgrades?
Yes. Despite extensive testing, unforeseen bugs or edge cases can emerge during deployment. While rare, such issues could temporarily affect transaction processing or node stability. The decentralized nature of Ethereum helps mitigate systemic risk through broad community oversight.
👉 Stay ahead of blockchain evolution with real-time crypto insights and tools.
Looking Ahead: From Berlin to London
With Berlin successfully implemented, attention turned quickly to London, the next major upgrade featuring EIP-1559—a revolutionary change to Ethereum’s fee market that introduced base fee burning and enhanced predictability for transaction costs.
Berlin laid essential groundwork for these future enhancements by modernizing transaction formats and refining gas mechanics. Each upgrade builds upon the last, moving Ethereum closer to its vision of scalability, sustainability, and security.
Final Thoughts
The Berlin upgrade exemplifies Ethereum’s commitment to continuous improvement through collaboration and technical rigor. By integrating targeted optimizations rather than sweeping overhauls, the network evolves steadily while maintaining reliability for millions of users worldwide.
Whether you're building decentralized applications, running infrastructure, or simply holding Ether, staying informed about protocol changes empowers you to navigate the ecosystem safely and effectively.
👉 Prepare for the next wave of blockchain innovation—explore tools built for tomorrow’s Web3 world.