Such are the words of wisdom that have been taken to heart by ethereum core developers ever since a vulnerability in the network’s code was discovered just 48 hours before the code was set to be deployed.
The network upgrade dubbed Constantinople would have introduced a series of backward-incompatible changes – also known as a hard fork – to the world’s second largest cryptocurrency by market capitalization. Yet the bug discovered led to a delay, followed by a plan to try once again in late February.
With the code expected to activate sometime during the last week of February – specifically, at block number 7,280,000 – ethereum core developers are confident that Constantinople won’t fail this time around.
“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,” Hudson Jameson, who handles developer relations for the Ethereum Foundation, told CoinDesk.
Adding that “valuable lessons” are learned from every hard fork, Jameson said that one of the important takeaways from last January’s hard fork attempt was “better communication with miners to let them know about the upgrade.”
While the issue in the code wouldn’t have impacted miners directly, miners and other users who run complete copies of the ethereum blockchain called nodes needed to be swiftly notified about the cancellation of Constantinople to keep it from actually being deployed and creating possible disruptions.
On this front, the smart contract security audit firm ChainSecurity, which discovered the vulnerability, told CoinDesk the organization of ethereum developers was already quite impressive.
“I was just impressed by how quickly everyone reacted and how well organized everyone reacted,” said CTO Hubert Ritzdorf. “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.”
Called Ethereum Improvement Proposals (EIPs), four out of five EIPs will actually be activated on the main network, or mainnet. And for all technical purposes, the upgrade will be deployed in two parts – simultaneously.
Say hello to ‘Petersberg’
Developers proposed during a meeting late January to table the EIP temporarily and proceed with the rest of Constantinople as planned, determining that a fix to the buggy EIP – EIP 1283 – would delay activation of ethereum’s planned hard fork for too long.
However, given that several test networks on ethereum including Ropsten already activated Constantinople in its full glory before the security vulnerability was found, ethereum core developers also agreed that a second hard fork safely removing the EIP was needed.
Thus, “Petersberg” was born.
Already released on Ropsten, Petersberg is the informal name of the hard fork specifically designed to remove EIP 1283 from a live ethereum-like network. Later this month, the original Constantinople code will be activated on mainnet in conjunction with Petersberg.
“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,” ChainSecurity COO Matthias Egli explained. “One says Constantinople gets active at block number [blank] and at the same block number Petersberg gets activated, which takes precedence over Constantinople and immediate supersedes it.”
And in terms of what’s left to be done for Petersberg launch on mainnet, Jameson said that all of the testing for its release has been completed and major software clients including Geth and Parity are ready to deploy on the agreed-upon block number.
Now, as emphasized by ethereum security lead Martin Holst Swende, users of ethereum should be aware of important changes to the ethereum network as a result of Constantinople plus Petersberg.
The new ‘corner case’
Tweeting out a questionnaire for users last Thursday, Swende noted that after Constantinople, smart contracts on ethereum considered to be virtually immutable will be able to change code under certain conditions over the course of multiple transactions.
The new feature introduced through EIP 1014 – called “Skinny CREATE2” – is intended to better facilitate off-chain transactions on ethereum by allowing what Ritzdorf describes as “deterministic deployment.”
“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,” Ritzdorf told CoinDesk. “CREATE2 makes it easier to say, ‘We will deploy in the future a contract to this particular address.”
As a result of this, Ritzdorf explains smart contract developers could technically deploy contracts for “the second time” to the same address, noting:
“[After Constantinople] you can change code because you can first deploy to that address, destruct the code and then deploy again.”
Egli highlighted that this is “not a security bug” but rather “a corner case” that developers on ethereum should be wary of once the changes are going live. He added that continued education from auditors in advance of February’s hard fork is needed about the other four EIPs originally set for inclusion in Constantinople outside of EIP 1283.
Users anticipating the launch of Constantinople can either go to forkmon.ethdevops.io or Ethernodes to watch the release in real time. A number of other sites are also available for live metrics including mining hashrate and market prices.
According to one hard fork countdown timer created by Afri Schoedon, release manager for the Parity Ethereum client, Constantinople plus Petersberg is estimated as of press time to go live on Thursday, February 28.
