One of Tezos' qualities is on-chain governance. This enables smooth and swift evolution, but it also avoids certain risks and uncertainties that can be caused by forks. By design, Tezos doesn't need to fork where other blockchains do. To avoid confusion: Tezos can be forked. But the design of Tezos' upgrading process avoids any issues while maintaining swift evolution:
Upgrading (on-chain governance):
First, it is important to understand how Tezos' on-chain governance works. In Tezos, upgrades are presented through a fixed amendment model. This whole process is automated on the blockchain, while the community stays in control of what eventually gets implemented. Just like other decentralized blockchains, the process is decentralized and democratic. The fact that it is on-chain just makes it way more efficient and avoids any confusion during the whole process.
In fixed cycles, the blockchain will start the process. Bakers (people who run a Tezos node) can propose upgrades (amendments). This process consists of four phases. These four phases are completed in a fixed period of three months. The first phase is the proposal phase. Any baker can submit a proposal in this period. This means that several upgrades can be proposed in this first phase. Bakers can vote to advance 1 project to the next round. People delegating to bakers can voice their preference towards their baker. The proposal that gets the most votes, advances to the second phase. This ensures that the best and most solid proposal will advance to the exploration phase by majority vote. The second phase is the exploration phase. In this phase the voting is focused on this single proposal. The fact that it was voted to be the best out of all submitted proposals, doesn't mean it is good enough by definition. So in the second phase, 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. The final voting is done in phase four. Again a supermajority needs to be reached. After this last voting round, the proposal is implemented in the mainnet and Tezos has evolved in a matter of three months.
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.
"Automatic upgrade [...] starts when the protocol decides to call activate. In the current protocol of mainnet, this activate function is called only on a protocol that passed a successful voting procedure"
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.
This on-chain governance model to implement upgrades, has two very important advantages: Smooth evolution and it eliminates certain risks and uncertainties that can be caused by forks.
Blockchain technology evolves. Privacy features, scaling features, smart contract languages, and other functionalities are developed in different variations. This means that existing blockchains need to be able to add or improve features to keep up with the competition and the demands of the market. But decentralization in blockchain has a crucial downside: if there is no central power, there is no central leadership. Decentralization is crucial for public blockchains though. If not truly decentralized, a blockchain is just another database, nothing close to the revolution that Bitcoin started. But if decentralized, who initiates upgrades? Who calls for deadlines? In decentralized environments anyone can, but that doesn't mean that upgrades are implemented by majority or that deadlines are met. Will everyone, or at least a majority agree? But most importantly: what process is followed to discuss, test and vote? Past and recent events have shown that politics, conflicting interests and ego's can be a major obstacle that slows this process down. Blockchain history has shown that these issues exist and make evolution to be labor intensive and lengthy.
Tezos solved this issue by designing the blockchain itself to be the automated authority in this process. As explained above, in a set timetable, all necessary phases are completed. No single entity can slow the process down. It's either a clear yes or no. The process brings absolute clarity. Everyone involved in Tezos can follow the process and everyone knows what one can expect in all phases. This process doesn't only makes it smooth and swift. It also lowers the bar for people to get involved in the development process, the discussions, testnet and to be involved in the voting phases. Participation rates show this process is a success so far. Since mainnet started, six proposal phases have started, resulting in three upgrades. The seventh proposal phase has just started at this time of writing.
With this method, Tezos is expected to evolve faster than any other chain, without the need to give up decentralization.
Another issue besides the lengthy, slow and uncertain process in traditional blockchain governance models, is the following: due to the fact that a hard fork splits the chain, both chains can maintain support from part of the community. This means that after a fork, both chains can continue to exist.
Part of the nodes could continue to run the old chain, while another part of the nodes continues to run the upgraded chain. In the case of Bicoin Cash and BSV, both parties even started a hashingwar, where both chains tried to gather enough computational power to become the dominant chain and claim the title of the "official" chain.
Here's the issue after a chain split: If both chains are continuances of the old chain while there is no clear and definite verdict on the question which is the official chain, then hard forks have the potential to become a serious risk. Because anything build on the original chain continues to run on both the original chain, and the new chain. (The first blocks of both chains originate from the same block of the original chain, continuing everything that was part of the original chain.) This becomes an issue if these tokens or contracts should not be duplicated. (Due to regulations or due to the fact certain tokens are supposed to be backed by real world value.) The question becomes: which token is the real one, and which one should be considered a negligible copy? If we look at stablecoins and Security Tokens:
- Stablecoins are backed by actual dollar value. You can't have them continuing on both chains after a split. Because if they run on both chains, the amount of tokens doubles, while the amount of dollars that back the value of the stablecoin stay the same.
- As for securitytokens that are registered on a blockchain: These are heavily regulated. A split chain, would mean that also security tokens, that are supposed to have fixed circulating supplies, would continue to exist on both chains and double in numbers. Very uncomfortable choices would needed to be made by the issuers of these tokens with the SEC watching their every move. Which chain do they chose? And will they choose the most successful chain? Do holders of the coins have a say in the matter? Do they feel comfortable holding if they don't agree with the choice made by the issuer? These events would cause unnecessary turmoil for certain assets and in short term a possible regulatory risk for the issuers.
A recent example that emphasizes the real threat that hard forks could cause for DeFi and stablecoins is the possible upcoming ProgPoW fork for Ethereum. MakerDAO has a decision to make: will they stay with the original chain, or run on the ProgPoW chain? MakerDAO founder Rune Christensen confirmed that choosing the wrong chain, could collapse the DAI stablecoin if they end up choosing the chain which ends up with the lowest ETH price.
There are no hard forks needed in Tezos. As explained in the first part of this article, upgrades in the Tezos protocol are implemented automatically. Where classical decentralized blockchains would need to soft- or hard-fork the chain for certain upgrades, Tezos does not fork, it auto-upgrades the chain without the possibility of the old chain to continue, since all nodes only work with the new protocol. So because the old chain does not continue, even in the case where part of the community would like to continue, there will not be a split chain. That is what fork-resistance means for Tezos.
As a result, 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.
Tezos makes any discussion on this topic unnecessary. After the on-chain voting has concluded in a positive result, automatic upgrading is activated, which leaves no room for discussion.
Even if there would be a minority in the community that wants to push through a controversial upgrade that didn't make it through the voting phase (or continue the original chain without the implementation of the upgrade), then they need to fork the codebase and actively change it to remove the call to activate so their nodes ignore the amendment. This means that forcing an amendment through (or rejecting an accepted amendment) would result in a new chain, not a continuance of the original chain. Yes, they could copy the chain with everything that is stored on that chain, but it would be clear that it is not the official chain and any form of discussion would be purposeless. Whatever is registered on that chain is known to be a counterfeit. The voting mechanism has already proven what the main chain will be and the protocol itself has upgrades all true Tezos nodes.
There is one reason for Tezos to actually hard-fork, but this will not cause any of the issues discussed above: when a critical bug is found and needs to be corrected fast. Then a full amendment cycle of 3 months is not an option. This won’t be any issue, since consensus is reached fast due to this bug being a risk of some level. No one will wan to continue the old chain after the hard fork, since that chain contains a critical bug. Every validator will understand the importance of the unscheduled upgrade, because the only reason for this kind of upgrades is the discovery of a critical bug of some level. For a more detailed article on that subject, please read the article by Arthur Breitman: “There is no need for hard forks” But there will be hard-forks nonetheless”
Tezos' on-chain governance creates a smooth and swift upgrade process, and legitimacy for upgrades and protocol changes. The way Tezos is build, forks don't need to cause a split chain. And in any case, the on-chain governance system eliminates the risk of confusion and discussions about what Tezos is. In the case of DeFi and Security Token Offerings (STO's): there will be no confusion which chain carries the registration of anything build on Tezos in particular official dollar backed stable coins, NFT's, or Security Tokens.
For the full introduction on Tezos, read this article.
Appreciate this info?
Tezos address for motivational tips: tz1RTdcgzedPYthw1GHnDKHx2WCWZefZovjD