A Constantinople postponement postmortem

Quick Take

  • Ethereum’s Constantinople network upgrade has been postponed after a vulnerability was discovered relating to EIP-1283
  • More than 80% of nodes are now running a non-Constantinople client
  • Core developers will convene on Friday to decide what the course of action will be
  • The vulnerability raises interesting questions regarding the extent and definition of Ethereum’s immutability

What happened?

Just one day before Ethereum’s Constantinople network upgrade was set to take place, ChainSecurity, a smart contract auditing service, disclosed an unintended consequence related to EIP-1283’s introduction of cheaper gas costs for SSTORE operations, which could open up existing contracts to reentrancy attacks.

While actually successfully exploiting the vulnerability is considered highly implausible, and ChainSecurity was unable to find any existing contracts that would be at risk, core developers, client developers, and additional community stakeholders nevertheless decided that the upgrade should be postponed pending further testing and consideration.

That this vulnerability was not picked up during the testing phase speaks to the complexity of Ethereum’s protocol: as Vitalik Buterin commented, “if you have N protocol features, there are N^2 ways they could potentially break…my personal takeaway from this is to be much more explicit about writing down invariants (properties guaranteed by the protocol) that we rely on so we can check against them when changing things.”


Constantinople: who, what, where, how?

Read more
Call to action:

Any nodes that already updated their clients to the Constantinople version need to either upgrade to the patched version — for Geth 1.8.21, for Parity 2.2.7 — or downgrade to the pre-Constantinople version. Figures from Ethernodes suggest that 80.1% of clients are updated to the correct state. Any nodes that fail to update their clients will be unable to sync and take part in the consensus process on the ‘legitimate’ Ethereum chain.

No action is required from smart contract owners and users or token holders that do not run nodes.      

What’s next?

Core Devs will reconvene on Friday to discuss how to proceed and set a block time for reintroducing the Constantinople upgrade. It is expected that EIP-1283 will be omitted from the fork, although alternative proposals include adding a condition to SSTORE that causes it to revert should less than 2,300 gas remain. Preliminary discussion in the AllCoreDevs Gitter indicated that the delay may be on the order of several weeks: the earliest possible date would likely be Monday January 21 as an upgrade is unlikely to be pushed over a weekend.  

Meanwhile, Ethereum’s ‘difficulty bomb’, which increases mining difficulty exponentially, slowing down block times, and by extension, the issuance of block rewards, has already activated. However, at present, the difficulty increase is relatively negligible, with blocks continuing to be mined roughly every 15 seconds. In addition, the brief postponement of issuance reduction from 3 ETH to 2 ETH per block is unlikely to have any material effect on total outstanding supply.

Ethereum Average Block Time

Ethereum Supply Growth

Source: Etherscan

What does this mean for future upgrades?

The introduction, and swift elimination, of EIP-1283, has sparked a more general discussion regarding how to proceed with upgrades to EVM semantics that are not compatible with pre-existing smart contracts. This is especially relevant in the context of Ethereum 2.0’s plan to introduce storage rent, where every account would have to pay some small amount of ETH per block for every byte of storage it takes up.

The debate is rather philosophical in nature, focusing on the meaning of ‘immutability’ and the responsibility of core devs towards smart contract developers. On the one hand smart contract developers want assurances that their code will be immutable, as promised at Ethereum’s inception, and argue that changing the way code is interpreted through upgrades to operation codes stands to violate the sanctity of immutability. On the other hand, core developers want freedom to continue improving the protocol — after all, EIP-1283 was designed to reduce complexity of contract storage — and although they will not intentionally introduce behaviour that could break an invariant, they cannot wholly guarantee that changes will not introduce second order effects.

While we can expect the immediate course of action for EIP-1283 to be revealed on Friday’s call, this wider meta-discussion around the extent and precise definition of Ethereum’s immutability will likely proceed through the coming years as Ethereum 2.0 continues to take shape.