What Caused Ethereum to Delay Their Much-Awaited Hard Fork?

Ethereum Core developers announced on Tuesday that they would postpone their much-awaited Constantinople hard fork.

The team, which has previously settled January 16 as the official date for the Ethereum blockchain upgrade, decided to delay it after ChainSecurity found potential vulnerabilities in the code. The Switzerland-based blockchain audit firm said that Constantinople would enable “reentrancy attack,” whereby a pair of hackers can use the code to simulate a secure treasury sharing service.

Cheaper Gas Cost Could Cause Security Issues

In retrospect, a reentrancy attack takes place when a smart contract communicates with an external Smart Contract by calling it. If the foreign entity turns out to be malicious, it may take advantage of the call function and take control of the first smart contract. The vulnerability could allow the external Smart Contract to make unexpected modifications in the host’s code. For instance, such an attacker may repeatedly withdraw Ether funds by “re-entering” at a particular line in the Code.

In the case of Constantinople, ChainSecurity blamed cheaper gas costs for fueling the possibilities of a reentrancy attack. According to the firm, two parties can jointly receive funds, decide on how to split them, and receive a payout if they agree by merely exploiting the “PaymentSharer contract” mentioned in the hard fork code.

“Before Constantinople, every storage operation would cost at least 5000 gas,” wrote Constantinople. “This far exceeded the gas stipend of 2300 sent along when calling a contract using ‘transfer’ or ‘send.'”

The firm added that changing dirty storage slots after Constantinople would cost only 200 gas. An attacker could manipulate the victim contract code to be transformed into a dirty one: with support from a public function that changes the required variable.

“Afterward, by causing the vulnerable contract to call the attacker contract e.g.with themsg.sender.transfer(...) attacker contract can use the 2300 gas stipend to manipulate the vulnerable contract’s variable successfully,” speculated ChainSecurity.

No Vulnerable Contracts So Far

ChainSecurity did a chain-wide audit of Ethereum and found that the reentrancy bug didn’t impact any smart contract yet. The Core also added that their decision to postpone the hard fork was reached following a detailed discussion with security researchers, Ethereum stakeholders, developers, node operators and other similarly essential parties of the community.

Vitalik Buterin, the co-founder of Ethereum, stressed that a little security vulnerability does not necessarily mean that the underlying code is flawed.

“If you have N protocol features, there are N² ways they could potentially break,” he wrote on Reddit. “I would say [that] my personal takeaway from this is to be much more explicit about writing down invariants (properties guaranteed by the protocol) that we rely on so we can check against them when changing things.”

MyCrypto.com, an open-source blockchain interface, also backed Buterin’s opinion.

“The implementation of EIP1283 was sound,” the company wrote in one of its tweets. “The code is fine. The idea behind it is fine. There is not a “bug” in the code of this EIP. It does what is intended. The potential vulnerability lies at the contract level—not the EVM/opcode/EIP level.”