Ethereum's accidental hard fork: how Tezos' on-chain governance protocol prevents this from happening on Tezos

Ethereum's accidental hard fork: how Tezos' on-chain governance protocol prevents this from happening on Tezos

By Allen Walters | Publish0x posts | 19 Nov 2020


Last week, Ethereum developers inserted an update, which caused an unintentional hard fork, splitting the blockchain in two separate chains. Result: Metamask and several popular DeFi applications like MakerDAO, Uniswap, Compound and other applications shut down for several hours.
OroPocket, which had scheduled the listing of Uniswap, was forced to postpone the listing
0040ef5312647e10caabe2654827df8cf2e0353b6b235667b35b09622eebfb1a.png

Many see this incident as the most serious issue that struck Ethereum since the 2016 DAO hack.
The reason for the accidental hard fork was the fact that the protocol update contained a change to Ethereum's consensus redesign, while this was not clear to a large part of the validators.  Since these validators thought the update was a minor, non-critical update, they did not act fast enough upgrading their nodes and got stuck in a minority chain, splitting the network. This means that the blockchain, which exists of a continuous chain of data blocks, split into two chains, both going its own path and storing an increasingly different collection of data. 
4cea39483b036410fc7c433d6a03a739ffcd136f52c083ffbea17f1db519ebde.png
Transactions that users sent, were only stored on one of both chains. (Chain A or Chain B) The reason for this is the fact that transactions are being picked up by nodes that follow one of both chains. (Again: the chain is split due to the fact that two groups of nodes follow two separate chains.) You can imagine that a transaction which is sent by Alice and registered on chain A, but not on chain B, results in the fact that Alice has spent a certain amount of ETH on chain A, but still has that same amount registered to her name on chain B. She can now double spend, especially for as long as receivers don't know the chain has split. Soon, exchanges started noticing conflicting data from different endpoints sending transactions. This risk caused Binance to suspend trading Ethereum first, and other exchanges followed soon after.

A lot of DeFi applications got shut down due to another factor: one of the largest infrastructure providers went down. Metamask and several popular DeFi applications like MakerDAO, Uniswap, Compound and others, got shut down due to their dependence on Ethereum infrastructure provider Infura, which went down due to the unintended hard fork.

All in all a disaster which should not have happened. Biggest factor: flawed governance, one of the hardest problems in decentralized systems.

Tezos' on-chain governance solves this
Tezos has introduced a decentralized method of on-chain governance. This enables smooth and swift evolution, but it also avoids the risks and uncertainties that can be caused by forks as we have seen last week in Ethereum. Tezos' on-chain governance was designed to prevent any type of forks. Also the unintended forks. This means that a split like BTC-BCH is not going to happen. Very important if any type of Security Token is live on your platform. But also in the case of other high value smartcontracts are running on a platform. Any confusion of which is the main chain, can cause huge problems and risks. In the case of an unintentional fork, but especially in the case of an intentional fork where a dispute arises about the question which chain is the real, legit chain. An unintentional fork as we seen with Ethereum is solved within a day, but a dispute among PoW nodes can turn into a hashing war as we have seen in the case of BCH-BSV. A fork in a PoS blockchain could be even worse, since there is no outhashing and the circulating supply is copied in two identical amounts. None of that is an issue for Tezos. Due to on-chain governance, there will not be any confusion on what is the official Tezos chain. 

By design, Tezos doesn't need to fork where other blockchains do, all normal scheduled upgrades go through an on-chain governance process, which implements (or declines) upgrades in a decentralized and democratic manner. After the on-chain vote is concluded and the outcome is positive, all nodes receive this message and only the new protocol will produce blocks. It's been live for over two years and resulted in 4 upgrades. 

Upgrades are presented through a fixed amendment model. This all happens on the blockchain. The first phase is the proposal phase. Any baker can submit a proposal in this period. The proposal that gets the most votes, advances to the next second phase. The second phase is the exploration phase. In this phase the voting is focused on this single proposal. A supermajority needs to be reached for the proposal to advance to the third phase: the testing phase. In the third phase the proposal is tested on a testnet. Bakers can join and test the proposal on the testnet so they can decide whether or not they want to vote in favor of implementation in the main net. The final voting is done in phase four. Again a supermajority needs to be reached. After this the proposal is implemented in the main net and Tezos has evolved in a matter of 3 months. 

ff7c01c1e6d8918375e4156b788821dfa32a1ba2605b681a5d0ff8a9175d3638.png

The implementation of the upgraded protocol is automated. This means that after the final voting phase has finished and a supermajority is reached, the Tezos protocol calls for "activate". As a result, the nodes automatically download the code and they will start using the new protocol at the start of the next cycle. Bakers do need to recompile the new baker/endorser/accuser programs manually though. But failing to do so would not mean they continue the old chain, it would simply mean you would miss all baking/ endorsing opportunities and earn zero rewards. If someone who’s running a node wants to reject the amendment, he has to fork codebase and actively change it to remove the call to activate so they can ignore the amendment. This results in the fact that rejecting an amendment would effectively start a new chain, not a continuance of the original chain. So not a split chain, but an entire new chain with a genesis block marking the first block.

All the above is in the case of a long-term planned upgrade. Now what if a critical bug is discovered just like in the case of the latest Ethereum upgrade that caused the unintentional hard fork? In this case, there would be no time to follow Tezos' on-chain governance cycles. The big difference is this: if an unscheduled upgrade is introduced, then we all know what's up: a critical bug is found and the upgrade is an important upgrade. It's really that simple. The simple by-product of clear governance. This is the one reason for Tezos to actually hard-fork. And it won’t be an issue, since every validator will understand the importance of the unscheduled upgrade. There will be no confusion at all whether or not the update is minor or non-critical. Tezos governance is clear-cut. 

------------------

New to Tezos? Read this full introduction to Tezos.

Here you can read more about the Status of the Tezos ecosystem. (Latest news, developments and growth of the adoption rate and on-chain statistics)

New to Publish0x? Create an account here and you will be able to tip articles and earn some crypto rewards yourself while doing so. 


Allen Walters
Allen Walters

Fascinated by blockchain and future proofing cryptocurrency. Discover the tech before it gets relevant. Twitter: @IgnoranceIt


Publish0x posts
Publish0x posts

Posting my opinion and feedback on Publish0x here.

Send a $0.01 microtip in crypto to the author, and earn yourself as you read!

20% to author / 80% to me.
We pay the tips from our rewards pool.