Ethereum core developers have proposed activating Constantinople – a planned system-wide upgrade that was called off earlier this week – in late February.
Also called a hard fork, Constantinople is now estimated by developers to go live some time between Feb. 26 and Feb. 28, with a block number to be determined at a future date.
The proposal was made during a core developer phone call on Friday morning, and participants on the call included ethereum creator Vitalik Buterin and other developers, including Hudson Jameson, Lane Rettig, Afri Schoedon, Péter Szilágyi, Martin Holste Swende, Danny Ryan and Alexey Akhunov, among others.
The decision comes after smart contract audit firm ChainSecurity flagged on Tuesday a security vulnerability in one of five Ethereum Improvement Proposals (EIPs) set for inclusion in Constantinople relating to data storage costs on the blockchain.
As a result of the vulnerability, Constantinople, now set for activation next month, will not feature inclusion of the buggy EIP, which will be tested and refashioned for inclusion in a subsequent hard fork.
Instead, Constantinople will be issued in two parts simultaneously on the main network. The first upgrade will include all five original EIPs and a second upgrade will specifically remove EIP 1283.
This strategy – first suggested by Szilágyi during today’s call – is meant to ensure that test networks and private networks that have already implemented the full Constantinople upgrade can easily implement a fix without rolling back any blocks.
“My suggestions is to define two hard forks, Constantinople as it is currently and the Constantinople fix up which just disables this feature…By having two forks everyone who actually upgraded can have a second fork to actually downgrade so to speak,” explained Szilágyi.
The decision comes after smart contract audit firm ChainSecurity flagged on Tuesday a security vulnerability in one of five EIPs set for inclusion in Constantinople relating to data storage costs on the blockchain.
Speaking to CoinDesk on Tuesday, Matthias Egli – COO of ChainSecurity – highlighted that the issue was likely not picked up by core developers when running tests on the software given that the impact is rooted in smart contract development, not necessarily “[ethereum virtual machine] core” development.
A prompt decision to reactivate Constantinople sooner rather than later was needed in part due to prolonged activation of ethereum’s difficulty bomb – a piece of code embedded into the blockchain making block times increasingly longer over time.
Meant to encourage transition to a new consensus algorithm known as proof-of-stake (PoS), a delay of the bomb was suggested in EIP 1234 due to insufficient research at present for a transition to PoS.
Once activated on mainnet, Constantinople will include EIP 1234 and delay the difficulty bomb for a period of 12 months.
Editor’s Note: The article has been updated with additional information.
Binary code image via Shutterstock
Credit: Source link
