The proposed Constantinople upgrade was put to hold on January 15 as the Ethereum developers cited security reasons. However, necessary changes required were not followed by all and at present, there has been a parallel universe of mining Ethereum. Few miners are mining unauthorized Constantinople chain which is not in accordance to a large part of the network and eventually causing a “chain split.”
The idea to suspend was confirmed after a possible security lapse was exposed in one of the recently developed upgrades. The statement suspending the fork confirmed that work was in progress to expose any potential danger and any news regarding the probe would be updated in blog posts and at various social media channels.
The statement issued earlier on January 16 to put the upgrade on hold said: “We are investigating any potential vulnerabilities and will follow with updates in this blog post and across social media channels. Out of an abundance of caution, key stakeholders around the Ethereum community have determined that the best course of action will be to delay the planned Constantinople fork that would have occurred at block 7,080,000.“
Miners are required to install an updated version in order to stay away from and ultimately comply with a majority in the network.
It appears that all have not followed the instructions as mentioned. At the time of writing near about 10TH/s value of mining capacity continued the process of mining the unauthorized chain as maintained by fork monitor possessed by Ethdevops.io. As a matter of fact, the upgraded forked version of Ethereum had more hashrate as compared to Ethereum Classic.
The security reason citied enables scams, operating which requires an excellent understanding as it is complicated. The fundamental concept is that a difference in the manner Ethereum charges for storage could allow an attack that could cost a lot of money to many dApps. Smart contracts have to deal with “reentrancy attack”. It’s not similar to a double spend or a replay attack. It is one-off an issue. ChainSecurity, who was responsible for exposing the defective code has tried to explain it. It is to be noted that there are few requirements to be dealt with to make a contract vulnerable.
The ChainSecurity explains the pre-requirements stating: “Certain preconditions have to be met to make a contract vulnerable:
1. There must be a function A, in which a transfer/send is followed by a state-changing operation. This can sometimes be non-obvious, e.g. a second transfer or an interaction with another smart contract.
2. There has to be a function B accessible from the attacker which (a) changes state and (b) whose state changes conflict with those of function A.
3. Function B needs to be executable with less than 1600 gas (2300 gas stipend – 700 gas for the CALL).”
Though the Ethereum blog confirmed that there is no vulnerability on the original blockchain, it is always better to take precautionary measure. Security researchers like ChainSecurity and Trail of Bits surveyed the entire blockchain. Though they did not come across any case of vulnerability but still some contracts being affected is not ruled out.
The blog said: “Security researchers like ChainSecurity and TrailOfBits ran (and are still running) analysis across the entire blockchain. They did not find any cases of this vulnerability in the wild. However, there is still a non-zero risk that some contracts could be affected.”
No doubt, with a massive decentralized channel, it is extremely difficult to upgrade a network through to everyone within a stipulated time frame. Bitcoin node map clearly displays that many different versions are active at any given point in time. Few mining nodes are presently mining the Constantinople fork assuming that it had taken place, unfortunately not gaining any genuine Ethereum in the process.
