This case brings up interesting developer coordination issues and illustrates the importance of a well-defined testing process as client developers prepare to implement changes affecting mainnet.
In this planned activation of changes on Ropsten testnet, when the forking block was reached, there was not enough mining power from Ropsten clients implementing Constantinpole changes. This led to a disorderly forking in which the intended upgraded network failed to quickly materialize / become dominant.
Additionally, a consensus bug was found, leading to a secondary fork (a more dire state of affairs which must be avoided at all costs on mainnet).
The result is that the Ropsten network, for lack of a better word, is shattered.
The situation is currently being discussed, investigated, and resolved in the AllCoreDevs gitter channel.
Is there a reason we donāt have fork identifiers? I really dislike that we are beholden to miners to upgrade to a fork. As a user, if I want to participate in a hard fork I should be able to do so even with none of the miners switching their work over. I believe at the moment Ethereum clients are designed such that they will follow the heaviest chain of either the old code or the new code, which means miners must upgrade in order for me to upgrade. At some point, there may be a change that miners donāt voluntarily upgrade to but all economic participants do upgrade to. In this scenario the majority of miners should not be able to prevent my client from switching to the fork.
It sounds like this is effectively what happened with Ropsten, and it feels like can be simply fixed by including a fork identifier in the block headers such that my client will ignore any blocks that are not part of my desired fork.
Thatās exactly what we did, from what I understand, but people kept adding hashrate to the network and therefore the hardfork happened earlier than initially planned.
The underlying issue here: block numbers are unreliable and there is a two-in-seven chance that a block evetually appears on a weekend.
There are ideas discussed about using contracts to signal hard-forks (bad) or simply using timestamps (ugly), but I have not yet seen any solution that convinced me.
Why do you find using timestamps to hard fork as āuglyā? Is it just because the way the Parity codebase is currently designed makes using timestamps hard? If so, this is a reasonable argument for not doing it, but I think it is valuable to be clear that the problem isnāt with timestamps generally, it is with the way Geth/Parity/Harmony are currently authored.
That is, if one were to be authoring a blockchain from scratch today, using timestamps (IMO) for fork scheduling would be the right solution (no legacy baggage).
Because miners control timestamps and there is a variance allowed how to set them, so you can not for sure tell which miner at which point decides that Constantinople activates at a certain block.
Also, all clients are built around block numbers, so this is not only a Parity Ethereum thing: all clients would need some basic refactoring to allow for time stamps.
