The ethereum 2.0 testnet is going through a stress test after the finding of a clever bug that may have crypto political dimensions.
The initial report by the team that there was a malfunction in servers’ time sync from cloudflare makes it somewhat clear what bitcoiners’ point may be.
Prysm devs say roughtime was meant to be decentralized, but it wasn’t, with a greater point potentially makable here.
That being a little bug can bring down the whole network, and therefore ethereum 2.0 is not as secure as bitcoin, with it currently going through four forks.
The big question is of course whether it can get back to one chain and keep on running. If it does, then this was a nice test. If it doesn’t, then there’s a very big problem.
As you may know bitcoiners don’t like Proof of Stake because of the nothing at stake problem in as far as there is nothing preventing you from signaling for two chains at the same time, except in eth there’s slashing, while in Proof of Work (PoW), hash obviously can be allocated to only one chain.
If thus we have a situation as currently and we have all these forks, in bitcoiners’ view the network can’t quite reconcile at least without much of a mess.
It’s been two days now and the network is still not up and running, but more nodes are finally syncing fully, yet it is still currently at just 16 out of 140 for Prysm.
Nonetheless the fact more nodes are coming on means the inbuilt mechanisms are working as those nodes should now be able to bootstrap other nodes to eventually finally finalize a block.
Yet you can imagine if all of this happened live, all of defi would straight out stop, with no code related fix here to this requirement that 34% of validators should not go off at the same time as otherwise the whole thing stops.
It’s probably a matter of preference however whether it’s better the network keeps running with reorgs, or just stops, with both probably as bad for defi.
Yet regardless of whether this was an accidental bug or bitcoin maxis, it has just revealed the biggest weakness of ethereum 2.0.
And therefore like maxis go apoplectic when a mining pool gains more than 50%, so ethereans should go apoplectic when a client gains more than 34%.
You need stake here for the client by depositing eth, so you can’t just fake them, meaning we should be able to see the true picture of the network.
But there can be non client specific bugs with the old SSL one a good example as although it didn’t bring down bitcoin nodes, it illustrates just how many ‘obscure’ components there are that can affect all clients.
Then there’s what operating system is being used and other non client specific bugs which could create a live situation like the one currently unfolding.
So it’s important to heed the crypto-economics here of diversifying in all ways to below 34% of validators on the same setup.
