Back to all stories
Upgrades to the Ethereum Network Could Break Existing Smart Contracts
Upgrades to the Ethereum Network Could Break Existing Smart Contracts

The Ethereum network is actively evolving, and developers are planning to introduce many changes in efforts to scale its current limit of around twenty transactions per second to over hundreds of thousands of transactions per second — a twenty-first-century quest for the Holy Grail of blockchain development.

As smart contract developers, this means there will be a need to continuously follow Ethereum updates and understand how the code might change. Fortunately, CertiK is here to help.

Istanbul V1: Next Wednesday!

Istanbul V1, the long-awaited Ethereum hard fork, is set to happen on October 16 — next Wednesday!~

Edit: Since the original posting of this article, the release date for the first phase of Istanbul has been tentatively "

scheduled for December 4th with January 8th as a backup

Istanbul v1 includes six changes to the EVM (Ethereum Virtual Machine) — most of which are slight optimizations that are highly technical and not of concern to the typical smart contract developer. Some operations will cost less gas to use, which is a good thing; however, some operations will cost more gas to use. This could be a problem for some because, in some scenarios, increasing the gas cost on some operations can break certain smart contracts that have already been deployed.

You're more likely at risk of having a broken contract if you use a fallback function to receive Ether and read from state in the function. If this does not apply to you, then you're likely fine! Feel free to skip the next two sections.

If this does affect you, keep reading.

Fallback Functions

Let's run through why our smart contracts may fail with this update.

A fallback function is something you can use to run certain logic whenever your smart contract receives Ether. It looks something like this:

For example, if another smart contract is sending Ether to your smart contract, it will likely use the .transfer or .send method to transfer the Ether. This will then call your fallback function if you have defined it.

However, by design, only 2300 gas will be “forwarded” to your fallback function. This is intended to be just enough to allow your contract to log an event and not much else. (If this limitation did not exist, you would be able to break other people’s smart contracts by making them pay for very “greedy” fallback functions!)

While this might have been a proper plan in the past, the current update puts this system into jeopardy.

Reading From State

A second problem emerges for operations that read from state. This is because those operations take more computing resources correlated to the size of the Ethereum state–the larger the state gets, the larger the amount of resources required.

Specifically, the SLOAD function, used to read from the state, will go from costing 200 gas to 800 gas! Here's a list of all the specific opcodes that will be affected and how gas costs will change.

What this means is that even a simple state read or two could push your function over the 2300 limit, and other smart contracts might not be able to make transfers to your contract. Checking some state in this fallback function might have been fine in the past — but this update risks breaking functionality.

If you believe that your smart contract might be affected, please reach out to us at CertiK and we can determine if you are indeed affected with potential upgrade and recovery solutions.

The Takeaway

The takeaway from this whole affair is that we should not write any code that expects gas costs to remain constant over time. It seems quite likely that Ethereum core developers are willing to change these variables as they see fit going into the future.

While this raises considerable concerns throughout the development community, it should be understood in the context of Ethereum at large. Blockchain technology is still young, and comparatively short of mass adoption. The changes factored in now may have considerable benefits in the long run.

Future Changes

You may be wondering what further upgrades we can expect from Ethereum’s roadmap and what developers will need to prepare. While the next Ethereum hard fork Istanbul v2 (aka Berlin) is in the pipeline, Ethereum 2.0 will be the next scheduled update for total network overhaul.

Istanbul v2

Istanbul v2 does not have a date yet but has eight more changes tentatively approved. Seven of these are further technical adjustments to the EVM —and fortunately, none of them involve raising gas costs or will break smart contracts outside of the extreme edge cases.

Even more promising, one of these proposals involves adding “version numbers” to smart contracts. This means that after a hard fork, smart contracts with an older version number can run using the old set of rules, while new smart contracts can run using new rules. With this innovation, problematic breaking changes can be avoided in the future!

The eighth change is both more serious and controversial. It entails changing the Ethereum mining algorithm from Ethhash to a new algorithm called the ProgPoW, created to prevent ASICs from being built and keep GPU mining viable.

While it is unclear at the current moment whether or not this change will pass, it already serves as a point of friction in the Ethereum community. Still, as it does not affect smart contract developers or network security, there is no reason we should lose sleep over it.

Ethereum 2.0

With Ethereum 2.0 looming on the horizon, smart contract developers might be worried about all the complex changes that can arise. The good news is that Ethereum core developers seem to be taking steps to make the change as seamless as possible.

At the time of this article's publication, Vitalik went to the forum to assure the community that losing data or functionality will not be an issue when the transition takes place. He stated that smart contracts will automatically be ported over, and many won’t notice that a change has even happened.

Vitalik offers a sample story below:

You have a CDP on MakerDAO. You go to sleep, and when you wake up the transition has happened. You are able to interact with and liquidate your CDP by sending transactions as before, except your client code would see that you are post-transition and add witness data to your transaction and send it to the eth2 network instead of the eth1 network.

However, there are a few considerations we can point out at this time that still needs to be addressed:

  1. The network will likely be down for one to two hours when the transition occurs. Plan for this accordingly!
  2. If you are using the block hash as a source of randomness, this will likely break once proof-of-stake happens. (This is bad practice regardless, and you shouldn’t be doing it in the first place!)

Additionally, you might want to think about taking advantage of Ethereum 2.0’s sharding capabilities once they go live; while this appears to be opt-in initially, you should be prepared to consider it seriously. Vitalik also outlined some suggestions on how that might work in another post. Again, while he stressed that the change will be relatively seamless, active planning will ensure your peace of mind and the security of your contracts.

We will keep you posted!

If any of this changes, we will let you know. Feel free to contact us with questions or concerns on the evolving state of blockchain security.