Understanding Ethereum Virtual Machine Upgrades: A Practical Overview

Introduction

The Ethereum Virtual Machine (EVM) is the decentralized computation engine that powers the Ethereum blockchain. It executes smart contracts in a deterministic, sandboxed environment, ensuring that code runs identically across all nodes in the network. Over the past decade, the EVM has undergone multiple upgrades—from the Byzantium and Constantinople hard forks to the more recent Shanghai and Cancun-Deneb (Dencun) upgrades. Each upgrade introduces changes that affect opcode costs, storage semantics, and state access patterns, directly impacting dApp developers, protocol engineers, and DeFi strategists. Understanding these changes is not merely academic; it determines transaction profitability, contract security, and system design choices.

This article provides a practical, methodical breakdown of how EVM upgrades work, what they mean for execution logic, and how to reason about their tradeoffs. We will focus on concrete opcode cost changes, gas metering revisions, and the introduction of new precompiles. By the end, you will have a framework for evaluating future upgrades and adapting your contracts accordingly.

How EVM Upgrades Are Enacted: Fork Mechanics and Timeline

EVM upgrades are coordinated through Ethereum Improvement Proposals (EIPs) that reach rough consensus via the all-core-dev calls and are bundled into network upgrades (hard forks). Each fork activates at a specific block number or timestamp, after which all nodes must comply with the new rules. Nodes running legacy software will fork off unless they upgrade—this is the mechanism of a hard fork.

Key historical milestones include:

• Byzantium (2017): Introduced the REVERT opcode, precompiled contracts for elliptic curve operations, and reduced the gas cost of the EXP opcode for certain exponents.
• Constantinople (2019): Lowered gas costs for SSTORE from 20,000 to 5,000 in the "warm" path, reducing the cost of storage writes for frequently updated storage slots.
• Berlin (2021): Raised gas costs for state access opcodes (SLOAD from 200 to 2,100) to mitigate state explosion risks and increased the cost of the CALL opcode to account for value transfers.
• Shanghai (2023): Enabled withdrawal of staked ETH from the Beacon Chain and introduced the PUSH0 opcode (EIP-3855) which pushes zero onto the stack at a cost of 2 gas—useful for initializing local variables.
• Dencun (2024): The Cancun-Deneb upgrade introduced proto-danksharding (EIP-4844) with data blobs for L2 scaling and new transient storage opcodes TLOAD/TSTORE (EIP-1153).

Each upgrade is specified by a set of EIPs; the EVM specification itself is frozen at each fork point. Upgrades are backward incompatible for the execution layer—old contracts continue to run but under new cost schedules and opcode semantics. This backward incompatibility is why every upgrade requires careful analysis by infrastructure providers, wallet developers, and DeFi protocols.

Gas Cost Adjustments: The Core Practical Impact

Gas cost changes are the most immediately felt consequence of EVM upgrades. An opcode that previously cost 200 gas might now cost 2,100 gas (as SLOAD did in Berlin), which can break profitability assumptions in high-frequency trading strategies or make certain contract patterns uneconomical. Conversely, gas reductions like the SSTORE drop in Constantinople can make state-heavy contracts cheaper.

Consider the following concrete breakdown:

1. SSTORE gas cost evolution: Originally 20,000 gas per write (dirty), reduced to 5,000 in Constantinople, then further refined with EIP-2200 (net gas metering) that uses a refund mechanism for storage clear operations. This makes storage recycling viable.
2. SLOAD gas cost jump: In Berlin, SLOAD went from 200 to 2,100 gas for cold slots (first access in a transaction). This drastically increased the cost of reading state from smart contracts, pushing developers to cache storage reads in memory when possible.
3. Transient storage (EIP-1153): TLOAD and TSTORE cost 100 gas and 200 gas respectively, compared to regular storage which can cost 2,100+ gas per access. These are temporary per-transaction slots that reset after the transaction ends—ideal for reentrancy locks and internal accounting.
4. Data blobs (EIP-4844): Blob data is charged at a separate fee market with a target of 3 blobs per block. The data is not accessible to the EVM directly but is available to L2s for verification. This decouples L2 transaction cost from L1 base fee for calldata.

These changes have direct implications for DeFi protocols. For example, a liquidity pool that performs multiple storage writes per swap may see its gas cost double after a fork. Developers must monitor EIP proposals and estimate cost deltas using reference implementations or gas profiling tools like Hardhat or Foundry's gas reporter. Ignoring gas cost adjustments can lead to transaction failures or profit erosion in automated strategies.

New Opcodes and Precompiles: Expanding the Instruction Set

EVM upgrades frequently add new opcodes or precompiled contracts to enable efficient cryptographic operations or new data structures. Precompiles are fixed-gas-cost contracts at specific addresses (e.g., 0x01 for SHA256, 0x02 for RIPEMD160, 0x07 for BLS12-381 operations added in the 2022 Shanghai upgrade). Opcodes are added to the EVM bytecode interpreter itself.

Notable recent additions:

• PUSH0 (EIP-3855, Shanghai): Pushes the constant 0 onto the stack at 2 gas. Previously, developers had to use PUSH1 0x00 (cost 3 gas) or other tricks. PUSH0 saves 1 gas per zero push and makes bytecode smaller in many common patterns (e.g., zero initialization for loops).
• TLOAD/TSTORE (EIP-1153, Dencun): These allow data written during a transaction to be read later in the same transaction at a cost of 100/200 gas, compared to 2,100+ for cold SLOAD or 20,000 for SSTORE. This is a game-changer for complex multi-call patterns: you can now write intermediate state to transient storage instead of permanent storage, reducing costs and avoiding state bloat.
• BLS12-381 precompiles (EIP-2537, Shanghai): Added at addresses 0x0A to 0x0F, these precompiles enable efficient BLS signature aggregation (used by ETH2 staking) at approximately 50,000 gas per operation. Without these, verifying a BLS signature would require thousands of field operations and be prohibitively expensive.

When evaluating a new opcode or precompile, consider three criteria: 1) Does it reduce gas costs for a common operation? 2) Does it enable new functionality that was previously impossible or too expensive? 3) Does it introduce new security risks (e.g., reentrancy via transient storage)? The answers determine whether you should adopt it immediately or wait for ecosystem hardening.

Breaking Changes and Migration Strategies

Some EVM upgrades modify existing opcode behavior in non-backward-compatible ways. The most famous example is the SELFDESTRUCT opcode, which was partially disabled in the Dencun upgrade (EIP-6780). Previously, SELFDESTRUCT would delete a contract's code and storage and send any remaining ETH to a target address. The new behavior limits SELFDESTRUCT to only work if the contract was created in the same transaction—otherwise it behaves as a simple SEND. This removes a key mechanism for contract self-destruction outside of factory patterns.

Consequences for existing contracts:

1. Any contract that relied on SELFDESTRUCT for storage clearance or ETH recovery must be redesigned. The recommended alternative is to set a storage flag or use the new transient storage for one-time operations.
2. Storage refunds for SELFDESTRUCT have also been removed, affecting profitability calculations for contracts that self-destructed to reclaim gas. Protocols like Tornado Cash used this pattern, and its removal increases costs for similar privacy mechanisms.
3. The CREATE2 opcode remains unaffected, so deterministic contract deployment still works. However, contracts created via CREATE2 that later attempted SELFDESTRUCT will see their behavior change.

Migration requires auditing every SELFDESTRUCT call site in your codebase and replacing it with explicit state cleanup or using transient storage for temporary data. Testing on a fork of the upgraded network (e.g., via Hardhat's fork feature pointing to a post-upgrade archive node) is essential before deployment.

Practical Implications for DeFi and Liquidity Providers

EVM upgrades have outsized impact on DeFi protocols due to their reliance on state-heavy operations: storage reads for pricing, storage writes for order books, and complex multi-step transactions. A single upgrade can shift the optimal strategy for providing liquidity or executing arbitrage.

For liquidity providers, the most relevant change is the cost of storage reads and writes. After Berlin, every SLOAD costs 2,100 gas (cold) vs. 100 gas (warm in same transaction). This means a swap that reads the pool state twice now costs 4,200 gas just for state access—before any computation. Some protocols have responded by caching storage variables in memory at the start of execution, but this is only possible when the state is known to be constant within a transaction.

Another practical area is impermanent loss hedging. Many LPs use protocols like Arrakis or Gamma to manage concentrated positions. EVM upgrades that alter opcode costs for multiple token transfers or price feed updates directly affect the gas overhead of these strategies. For a detailed analysis of gas costs in concentrated liquidity, see our Impermanent Loss Calculation guide, which models how storage access patterns under Dencun affect rebalancing profitability.

Furthermore, the introduction of transient storage enables new patterns for aggregating state changes without touching permanent storage. For example, a multi-hop swap can now write intermediate token balances to transient storage, significantly reducing gas costs compared to writing to storage after each hop. This is particularly relevant for protocols that chain together multiple swaps in a single transaction, as the cost savings can exceed 30% for a three-hop route.

Conclusion

Ethereum Virtual Machine upgrades are not abstract academic exercises—they have concrete, measurable effects on every transaction on the network. From the gas cost of a simple storage read to the availability of new opcodes like TLOAD, each fork changes the economics of smart contract execution. Developers and protocol engineers must maintain a systematic approach: monitor EIPs, simulate gas costs using state-of-the-art profiling tools, and test on fork networks before mainnet upgrades.

Understanding the Ethereum Virtual Machine as a living specification means accepting that opcode semantics and cost schedules will evolve. The practical takeaway is to design contracts with upgrade-awareness: use transient storage for temporary data, anticipate SELFDESTRUCT removal, and cache state reads aggressively. By internalizing these patterns, you can build protocols that remain efficient and secure across future hard forks.

For practitioners, the key is to stay ahead of the upgrade cycle. Bookmark EIP resources, join the Ethereum Magicians forum, and run your test suites against every new fork configuration. The EVM will continue to change; your contracts should change with it—but only after careful, data-driven analysis.