🛑 Constantinople Stopped — Issue No. 34
/📰 News
Ethereum core developers were forced to delay this week's network upgrading hardfork, codenamed Constantinople, after a security vulnerability was discovered at the 11th hour. This marks the second time the Constantinople upgrade has been delayed. In October 2018, the deployment of the upgrade on the Ropsten testnet caused a chainsplit, delaying the mainnet rollout to this week. This time around, shortly before upgraded nodes were set to activate the fork, the core developers sent out the word to call it off and released new clients that cancelled it. While a small number of miners seemed to have missed the memo, and were mining on the upgraded chain, it seems any significant disruption was averted. Link.The issue that caused the cancellation is actually rather subtle. There wasn't a bug in the client code, per se. Rather, one of the upgrades reduced the fees, known as the "gas cost", required to execute a certain operation on the Ethereum Virtual Machine. Previously, that operation would have utilized the full gas limit for smart contract calls in particular contexts. After the upgrade, the limit would no longer be reached. Any existing contracts that were relying on that limit for security-- by assuming that no additional code would execute once that operation was called-- would have become vulnerable to reentracy attacks. The team at ChainSecurity, which discovered the bug, published a great write up explaining it in more detail with simplified code examples. Link.
With the fork successfully called off, the core developers met to discuss what would happen next. As it turns out, the change that caused this vulnerability, called EIP-1283, was the same one that caused the chainsplit back in October. The decision was made to remove EIP-1283 from the upgrade until a secure version of it could be conceived of, implemented, and tested. In the meantime, the remaining four changes will roll out in a rescheduled hardfork, which is now planned to occur at the end of February. Link.
I wrote about the first rescheduling of the Constantinople hardfork in issue number 29, where I said:
In comparison [to the plans for Eth 2.0], this hardfork is relatively minor-- which is why there is no room for error. Any issues with this upgrade would send a terrible signal (to an already skittish market) about the ability of the Ethereum core devs to execute on the grand vision.
So, how worried should we be that this upgrade has been delayed yet again?
On the one hand, the bug that was discovered is very much an edge case. To date, no contracts have been discovered on the mainnet that would have been impacted. It's actually quite impressive the team at ChainSecurity discovered it, and that the core devs were able to react in a timely manner to steer the ecosystem. The bug was discovered before it shipped, it will be fixed, and Ethereum avoided a security incident. This is the positive spin on the situation.
On the other hand, though, my analysis from December still holds up. The changes here are not trivial, but they're relatively simple in the grand scheme of things. Despite this, we see again how hard it's been to execute on them and get them deployed. This is due to the inherent complexity of hosting Turing complete smart contracts on an immutable blockchain. The insidious nature of this vulnerability is a perfect example of how even small changes have potentially important second and third order effects. And because there is no way for contracts to be updated once deployed, there is no room for error when it comes to backwards compatibility.
I've long been skeptical of the timelines being proposed for the so-called Ethereum 2.0 upgrades, which include sharding, Proof-of-Stake, and other major changes. The multiple delays of Constantinople reinforce my skepticism. Current plans call for the Ethereum 2.0 upgrades to begin shipping in 1-2 years, but I don't expect to see them for 3-5 years. I also expect the nature of the upgrades themselves to change significantly in the interim. I would love to proven wrong!