Ethereum (ETH), the first and largest blockchain platform for creating smart contract-enabled decentralized applications (dApps), was scheduled for an upgrade on January 16th, 2019. However, the hard fork update was aborted after a critical smart contract vulnerability was detected by cybersecurity firm, ChainSecurity.

The upgrade, referred to as Constantinople, consists of several Ethereum codebase modifications that have been specified in five different ethereum improvement proposals (EIPs). On January 19th, Ethereum’s developers announced that the Constantinople update has now been scheduled for late February.

The set of upgrades associated with Constantinople will reportedly be activated when block number 7,280,000 is mined on the Ethereum blockchain. This should occur sometime during the last week of February (based on the current rate of block production on Ethereum).

Expressing confidence that the planned upgrade to Ethereum will not fail this time, Hudson Jameson, manager of developer relations at the Ethereum Foundation, told Coindesk: 

I suspect it will go as planned. The block number has been set and [the upgrade] is hard coded in the clients now so it’s going along fine.

Acknowledging that “valuable lessons” were learned from previous hard forks (backwards incompatible upgrades), Jameson conceded that “better communication with miners” is required, so that they are well prepared to handle a planned upgrade to Ethereum’s network.

Although ETH miners would not have been directly affected by the smart contract vulnerability, critics might argue that their should have been a more effective way to inform (in a timely manner) the miners, or full-node operators, to not install upgrades that came with Constantinople.

In the hard fork attempt initiated last month, there had been some cases where miners had been running nodes that had downloaded and installed Constantinople’s software update. Because the update contained a critical bug, the miners could have potentially (and unknowingly) created a disruption on the Ethereum blockchain.

Commenting on how the Ethereum developers were able to quickly coordinate a response to the vulnerability detected by ChainSecurity, the cybersecurity firm’s chief technical officer, Hubert Ritzdorf, stated: 

I was just impressed by how quickly everyone reacted and how well organized everyone reacted. Many people had to update so they had to know what to update to. On many different levels it became clear even though there is no central command, the [ethereum] community collaborates very efficiently.

Critical Bug Found In EIP 1283

 The five different EIPs are as follows:

  • EIP 145 – more cost-effective and overall efficient approach to processing information (by adding bitwise shifting operators to the Ethereum Virtual Machine (EVM);
  • EIP 1014: better approach to accommodating network scaling solutions such as off-chain transactions;
  • EIP 1052 – an improvement on how contracts are processed;
  • EIP1234 – 12-month delay of difficulty bomb; reduce mining rewards from 3 ETH to 2 ETH per block;
  • EIP 1283 – a better way to monetize data storage changes (made by smart contract programmers)

Four out of five of the EIPs listed above will be activated on Ethereum’s mainnet. The Constantinople upgrade to Ethereum’s codebase will reportedly be deployed in two separate parts, or stages – but at the same time.

All planned EIPs will be initiated in the upcoming hard fork upgrade to Ethereum, with the exception of EIP 1283 as it contains the vulnerability detected by ChainSecurity. Although Ethereum’s development team is planning to activate EIP 1283 at some later point, it will take more time to fix the bug found in the proposal.

Notably, all five EIPs have been activated on various Ethereum testnets (test networks) including Ropsten. However, Ethereum’s developers are taking precautions as they’ve decided to conduct two hard forks (instead of one), in order to remove the vulnerability discovered in EIP 1283.

“Petersberg”, the hard fork specifically designed to remove the bug found in EIP 1283, has already been launched on Ethereum’s main testnet, Ropsten. During the last week of this month, both Constantinople and Petersburg will simultaneously be activated on Ethereum’s mainnet.

Technically Two Upgrades To Launch At End Of February

Matthias Egli, the COO at ChainSecurity, noted:

For all practical means for any developer out there on the mainnet, there will not have been Constantinople really, just Petersberg … Technically in the code, you have two conditions. One says Constantinople gets active at block number [7,280,000] and at the same block number Petersberg gets activated, which takes precedence over Constantinople and immediate supersedes it.

Notably, Ethereum security lead Martin Holst Swende has pointed out that EIP 1014, referred to as “Skinny CREATE2”, has been designed to improve how off-chain transactions on Ethereum are processed. The EIP will enable “deterministic deployment” which means (according to Ritzdorf):

[After Constantinople] you can change code because you can first deploy to that address, destruct the code and then deploy again.

Ritzdorf continued:

When you deploy a new smart contract on ethereum, what happens is that it computes the address to where the contract will be deployed. You know this ahead of time but it depends on a lot of variables. CREATE2 makes it easier to say, ‘We will deploy in the future a contract to this particular address.

Those looking to monitor Constantinople’s real time activation may visit forkmon.ethdevops.io or Ethernodes.