Ethereum Developers Discuss Potential Ways to Avoid ETC’s Fate
After a string of 51% attacks on Ethereum Classic, developers from its core chain rival, Ethereum, discuss ways of avoiding the same fate.
In a Core Devs meeting on Friday, Ethereum (ETH) developers discussed potential measures that could be taken to prevent successful 51% attacks from occurring.
The discussion was inspired by this week’s 51% attacks on Ethereum Classic (ETC) — a network that represents the original state of Ethereum where the consequences of the DAO hack in 2016 were not reverted. The original attack, which occurred between July 31 and Aug. 1, was revealed to be a carefully orchestrated attempt at a double-spend that netted over $5 million in ETC to the attacker for a $200,000 investment in hashpower.
During the call, Ethereum client developers discussed if they should take additional measures against these attacks and how such measures should be implemented.
Lowering the reorg cap
A potential protection against chain reorganization is setting up checkpoints at a node level which would set the history of the blockchain in stone after that point. Any proposed blockchain changes beyond this checkpoint would thus be rejected by nodes.
Chain reorganizations rely on mining an alternative version of the blockchain with a higher amount of hashpower than the commonly-accepted version. Due to the rules of Nakamoto consensus, the chain with a higher accumulated proof-of-work would automatically replace the original when published to nodes.
Peter Szilagyi, developer of the Geth client, said that the software already rejects reorganizations deeper than 90,000 blocks, or two weeks. This is however much higher than the effective reorg that happened in ETC of about 4,000 blocks.
While lowering this threshold could help defend from similar attacks, Alexey Akhunov of OpenEthereum noted that caps set too low can have unforeseen consequences.
Measures may be ineffective
The depth of the ETC reorg was dictated in part by a history of earlier attacks. These led exchanges to massively raise the confirmation threshold to accept deposits.
Szilagyi said that for Ethereum, there is no need for thousands of blocks. Decentralized exchanges could be gamed by censoring transactions and maximizing the hacker’s trading gains with reorganizations of just a few blocks. Setting a checkpoint cap that low may result in significant usability issues. He added:
“I just wanted to highlight that once you accept that there are 51% attacks on the network, a lot of things start breaking, because a lot of things rely on the assumption that you cannot have deep reorgs.”
Tim Beiko, a developer at Ethereum development company PegaSys, noted that ETC’s case may be different. Due to it being a much smaller and less valuable chain, it is easy to gather the required hashpower to complete a 51% attack through something like Nicehash. This, to him, “is a bigger concern than whatever clients implement through checkpoints.”
In the end, developers agreed to discuss the issues more and think through potential improvements to Ethereum’s resilience.
