Tuesday , September 27 2022

Constantinople postponement postmortem – The Block


Quick Take

  • Ethereum's Constantinople network upgrade has been postponed after a vulnerability was discovered related to EIP-1283
  • More than 80% of nodes are now running to a non-Constantinople client
  • Core developers will convene on Friday to decide what 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 audit 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 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 other stakeholders, however, decided that the upgrade should be postponed until 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 depend on so we can check against them when changing things. "

Call to action:

Any nodes that have 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 customers 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 reconnect 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, though 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 bomba', which increases expensively expense mining, slowing down block times, and by extension, the issuance of block rewards, has already been activated. However, at present, the difficulty increase is relatively insignificant, with blocks continuing to be mined roughly every 15 seconds. In addition, the short 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 about 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 unchangeable, as promised at Ethereum's inception, and argue that changing the way code is interpreted through upgrades to code operations 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 can not fully 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 broader 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 shape.

Source link