A Tale of Two Forks: Ethereum Classic and Ethereum Address Security Vulnerabilities

Since the great attack on the DAO, Ethereum has evolved into two separate ecosystems with their own fortifying communities.

When the Ethereum Foundation decided to hard fork their protocol after the major attack in order to retrieve stolen funds, it resulted in the birth of two separate Ethereum chains with two separate communities known as Ethereum Classic (ETC) and Ethereum (ETH). These communities both share the ideology of a decentralized and immutable system, therefore are working towards the same goal with constant updates to their technology.

In mid-September this year, as developers and Ethereum enthusiasts geared up for an exciting week in Shanghai for Devcon2, they had no idea a threat to the network would occur. The protocol suffered a DOS attack that caused an out of memory error to occur within Go-based Ethereum 1.4.11 clients, (known as Geth), halting the mining of further blocks. This attack also contained a message in German which translates to “Go Home.” The Foundation gathered and countered the attack with their own message, “From Shanghai, with love (1.4.12).”

While the Foundation countered this attack, subsequent attacks started barraging the network with even more small attacks. Some of them affecting the Ethereum Classic chain. After dealing with these multiple denial-of-service attacks, Vitalik Buterin suggested that an EIP150 hard fork will likely be needed to repair the network, with a second fork after to shrink the size of the blockchain state. Just before 6:30 a.m. PST on Oct. 18, 2016, the network reached block 2463000, executing the first of two hard forks successfully.

Thursday, October 20, 2016, at 5:44 pm PST, Vitalik Buterin released an update to the Ethereum community about the upcoming second hard fork and client optimizations.

Vitalik Buterin:

  • Geth developers are working on an optimization that will store a direct on-disk table representing account storage, allowing accounts to be accessed in O(1) leveldb reads instead of O(log(n)) leveldb reads as is the case now. Preliminary tests suggest a 5x speedup in processing account reads if this is done. This is a fairly large change to the client (not quite but almost as complex as journaling) so don't expect it out tomorrow, but it will make a large difference.
  • Simpler optimizations on the in-memory trie cache are achieving ~30% speedups.
  • We're looking at simple forms of state tree pruning to allow nodes to reduce their storage size without having to delete the DB and fast sync from scratch. This should increase processing time indirectly.
  • The main debate in the hard fork discussions is whether to implement EIP 158 with section 2 or with (1c) (there is little value in doing both). The two carry different risks; section 2 is more complex from an in-EVM consensus standpoint, whereas (1c) requires more substantial re-architectures in other areas of geth to implement, as iterating through all accounts is not a use case that needed to be supported in all nodes before.
  • We are considering adding replay protection, likely either EIP 155 or a simpler trick involving using the upper bits of the tx nonce as a chain ID, but nothing is yet finalized.

However, Ethereum is not the only one under attack. Ethereum Classic announced they were also suffering from DOS attacks, which has caused the value of ETC to drop more than 10 percent. On October 25, 2016, they plan to enact their own hard fork at block 2500000.

The Foundation has not yet released a date or block for when they plan to execute the second hard fork on the ETH chain. Stay tuned for more updates.