Much like a cell undergoing mitosis, the recent hard fork has created two chains where once there was one: the majority chain, which we continue to call Ethereum (hereafter ETH), and a minority chain, dubbed Ethereum Classic (hereafter ETC). The split — and activity and trading on both sides of the fork — raises interesting questions about how the two can coexist.

A primer on block number, difficulty, total difficulty, and chain length

Because of the increase in hash rate on ETC, and the subsequent difficulty adjustments, the gap between ETC’s block number and ETH’s, which grew rapidly during the hard fork, has narrowed. What implication, if any, does this have for each fork? Are reorganisations possible? To answer this, a short primer on the underlying blockchain concepts is useful.

The block number is probably the easiest to understand, and it’s the number that gets referred to the most in reference to where the Ethereum network is “at”. Block number is simply the number of sequential blocks — not counting uncles — that have been created since the network started with the genesis block.

Ethereum has an ‘ideal’ interval between blocks of about 14 seconds. In practice, and as you can see on fork.ethstats.net, discovery of new blocks is a random process, meaning blocks are sometimes discovered in quick succession, and at other times a long time can pass before a new block is found. The ideal block interval is thus a moving average over a fairly long period of time.

In order to attain this ‘ideal’ block time, Ethereum has a built in mechanism to adjust how hard it is to find a valid block. This is called difficulty, and is the second metric we’re concerned with. The network measures the average interval between blocks, and dynamically adjusts the difficulty to try and maintain a 14 second average interval between blocks.

Difficulty can be thought of as the average number of attempts a miner will have to make in order to find a valid block. By dividing the difficulty by the interval between blocks, we can estimate the total hashing power of the network. For instance, as of writing, difficulty on the mainnet is approximately 58 terahashes, and the block interval is 15 seconds, making the hash rate about 3.9 terahashes/second.

Finally, there’s the total difficulty. Total difficulty is simply the sum of the difficulty values for every block since the chain began. Total difficulty serves as a reasonable estimate of the total number of hashing operations the entire network has performed since its inception. Usual human units get a bit meaningless here, but as of this writing, the total difficulty is approximately 41 exahashes.

Given all of this, what is meant when someone talks about the “longest chain”? It’s not block number, because that measures only how many blocks were found, regardless of difficulty, and will tend to be similar for different networks that started at the same time, regardless of the collective compute power. Instead, the longest chain is measured by total difficulty — the sum of all computational effort that has been put into the chain over its lifetime. By this metric, ETC is a long way from ETH: since the fork it’s done about 2% as much work as the main chain, and it’s currently at about 6% of the hash rate, so it won’t be catching up any time soon.

Why none of this matters

Having bored you with a long digression about hash rates and difficulties, however, none of that actually matters, because even if ETC’s total difficulty passed ETH’s, a reorganization is impossible anyway. A reorganization can only happen when the nodes processing the chain see the blocks on the new longest chain as valid blocks. In a common hard fork — such as a network upgrade — that introduces new valid transactions, that would be the case, but in the case of the Ethereum hard fork, it’s not.

The reason for this is simple: the hard fork introduced an ‘irregular state transition’: a modification to the state database at the beginning of block 1,920,000, that altered several account balances. Since every block contains the the root of the merkle tree of the state database containing those balances, those blocks are no longer seen as valid by legacy and no-fork clients, and vice versa.

In short, a blockchain’s difficulty is not measured by block count, but rather by total difficulty, a metric that puts ETC well behind ETH. Even if ETC’s total difficulty did exceed ETH’s, the hard fork cannot be ‘reorged away’, as some have suggested.

The problem with coexistence

Active use of both chains leads to a significant concern: replay attacks. There was plenty of awareness of this issue before the fork, but replay attacks only become a significant issue if people are transacting actively on both sides of the fork, which now seems like a significant possibility. Aiding this is the fact that nearly all transactions are being replayed — when valid — on both sides of the network nearly immediately, likely due to nodes that are able to maintain connections to both sides of the split and are innocently relaying transactions as programmed.

The obvious consequence of replay attacks relates to value transfers; anyone who wants to move value on one chain but not the other needs some way to separate the two, creating a transaction that is valid on one fork, but is not — or has a different outcome — on the other. There are a number of contracts available that perform this task, as well as other methods, such as transferring funds to an exchange that supports deposits in both currencies, and withdrawing each to a separate address, relying on the exchange’s replay protection.

There are other, less obvious consequences, however. Suppose you have an account which you created and funded on ETC post-fork, and you deploy a contract with it. All is well, you may think, since this account only exists on ETC, so no replay is possible. However, the only thing preventing the replay taking place on ETH is lack of funds. As soon as someone transfers sufficient funds to that same account on the ETH fork, the transaction can be replayed, creating the same contract — with the same address — on ETH.

This is a significant problem for a network that’s designed to support applications with far more complex semantics than simple value transfer. The consequences of replaying a financial transaction are usually fairly obvious, while the consequences of replaying any or all interactions with turing-complete contracts are significantly more complex. Things only get more complex when you consider that a transaction that can’t be replayed will cause a ‘nonce gap’, preventing all future replays — until such point as the blocking transaction becomes possible, causing a rush of replayed transactions all at once.

It’s difficult to immediately conceive of practical attacks that result from this (edit: see this article by Peter Vessenes), but I always like to observe the maxim that “attacks only ever get better with time, never worse”. I consider it highly likely that replays will bite someone in the ass — if they haven’t already — sooner, rather than later.

Replay attacks disproportionately affect anyone who wants to actively interact with both chains, especially DApp developers, who will have to watch out for the possibility of replays being used maliciously against their contracts if they’re deployed on both chains. For this reason, if Ethereum Classic is to continue forward, remain viable, and persuade developers to deploy across both chains, I think anyone actively working on it should seriously consider implementing Vitalik’s proposal, which would eliminate replay attacks as an issue for users of Classic.