Ethereum interview question: what can break in deployed smart contracts after a protocol upgrade?

Deployed smart contracts don’t get rewritten after a hard fork. The bytecode stays exactly the same.

But what changes is the execution environment. Protocol upgrades can change gas costs, opcode pricing, and sometimes edge-case EVM behavior. That’s where things break, not because the code changed, but because the assumptions the code relied on no longer hold.

A well-known example is the Istanbul upgrade with EIP-1884. It repriced opcodes like SLOAD, BALANCE, and EXTCODEHASH. Contracts that were already tight on gas or depended on fixed gas limits inside low-level calls suddenly started reverting. A lot of issues came from stipend-based patterns that developers assumed would always “just work.”

So the real takeaway is that immutability protects the bytecode, not the gas economics. In practice, teams track upcoming EIPs, run fork-based regression tests for critical paths, and specifically test anything that depends on gas-sensitive external calls. Upgradeable proxies help with patching logic, but they don’t eliminate the need to test against protocol changes.

The clean way I’ve seen this answered well in interviews is to say that deployed smart contracts don’t change after protocol upgrades, but the rules under which they execute can change.

Most real production issues fall into a few buckets. One is opcode repricing and gas schedule changes, like Istanbul’s EIP-1884, where contracts that were close to gas limits start reverting even though nothing changed in the code. 

Another is state access pricing changes, like Berlin’s warm and cold access model, which can increase gas costs in transactions that touch many storage slots or external contracts for the first time. And in rarer cases, you get semantic tightening, like how SELFDESTRUCT behaves differently than many developers originally assumed.

What teams usually do in practice is fairly boring but effective. They read the fork EIPs, run fork tests for the top user flows, stress test gas-sensitive calls, and set up monitoring around revert rates and gas usage when the upgrade goes live. If the system is upgradeable, they also keep a migration or patch path ready, but testing is still the main defense.

I’ve linked a few related EVM interview threads below for anyone who wants to go deeper into gas behavior and execution details.

One thing that often gets glossed over is that saying “deployed smart contracts keep running after Ethereum upgrades” is technically true but practically misleading.

Protocol upgrades don’t modify your bytecode, but they absolutely modify the EVM rules and gas economics. That’s why the protocol upgrade impact on deployed smart contracts usually shows up as subtle failures rather than obvious breakage. 

Transactions that used to pass start reverting, fallback paths behave differently, or certain calls become unexpectedly expensive.

Istanbul is the easiest example to explain in interviews. When opcode pricing changed, contracts that relied on tight gas margins or fixed gas assumptions started failing in places nobody expected. 

Berlin made the warm versus cold access distinction something developers had to actively think about, especially in complex DeFi flows. And more recent changes like tightening SELFDESTRUCT behavior show that even opcode semantics aren’t completely frozen.

The checklist I personally like before a mainnet hard fork is simple: fork-based testing for the most important flows, targeted stress tests for gas-sensitive external calls, monitoring during the upgrade window, and some kind of safety valve if things go wrong.

Curious if others here have actually seen production issues from warm/cold access gas changes, or if most of the real pain still comes from old-school opcode repricing and fixed gas patterns.