While blockchain technology has grown its significance in our daily lives, with expanding NFT trends to volatile trading markets, the better part of this movement is backed by strong communities of developers and enthusiasts who see decentralization as the need of the hour. Since blockchains are in-fact specimens of decentralized services, providing little to no control to a single party, how does one resolve conflicts in a community, with no leader to make decisions. This is where chain-selection protocols step in.
Forks in blockchain
While user-specific changes only add to the chain using a block, this may not suffice for a large change in the network. For instance, important updates concerning security or dependencies cannot be resolved on block level and therefore need changes that expand the entire network. This does not mean that we change blocks that already exist on the network (i.e., they have already been mined) but it does involve setting precedence for all future blocks and thereby the entirety of the network.
Since the core purpose of blockchain serves decentralization, any proposal pertaining to social or engineering issues must be favored by the majority and therefore is only passed through a consensus mechanism. By consensus, we mean that a general agreement has been reached. If there is not a disagreement on a proposed choice, then a consensus is achieved. In the extreme case the group will eventually split. In regards to blockchain, the process is formalized, and reaching consensus refers to reaching a minimum majority, a standard set by the blockchain. When a consensus is reached, we say that a new fork has been initiated for the blockchain.
Hard and Soft forks
Forks are broadly divided into 2 types. The decisive aspect that differentiates them is “backward-compatibility” i.e., the ability of the older protocol to recognise newer blocks as valid. Let’s dive a little deeper here:
Soft forks: Soft forks usually reflect upgrades in the network. These will not affect third party softwares that depend on the blockchain, and will mostly add extra features or remove bugs that improve the overall performance of the network. Since there is no split in the main chain, we have backward compatibility i.e., pre-fork blocks reside with the new and future blocks.
A point to take note, however, is that the functionality of a non-upgraded network participant is affected. An example of a soft fork is when the new rule states that the block size will be reduced. Non-upgraded participants will still continue to see that the incoming new transactions are valid. The issue is when non-upgraded miners try to mine new blocks, their blocks (and thus, efforts) will be rejected by the network. Hence, soft forks represent a gradual upgrading mechanism as those who have yet to upgrade their software are incentivized to do so, or risk having reduced functionalities.
Hard forks: Hard forks represent actual “forks” in the main chain. They reflect changes that cannot be shared with older versions of the blockchain and therefore, will probably split the main chain if part of the community decided to not adopt these.
- The most well-known instance of a hard fork is probably the creation of Ethereum Classic. Back in 2016, Ethereum had a hard fork to reverse the effects of a hack that occurred in one of their applications (called the Decentralized Autonomous Organization or simply, DAO). However, a minority portion of the community was philosophically opposed to changing the Blockchain at any costs, to preserve its nature of immutability.
- As Ethereum’s core developers and the majority of its community went ahead with the hard fork, the minority that stayed behind and didn’t upgrade their software continued to mine what is now known as Ethereum Classic (ETC). It’s important to note that since the majority transitioned to the new chain, they still retained the original ETH symbol, while the minority supporting the old chain were given the term Ethereum Classic or ETC.
Self-Amendment Protocols
While criticism for proposals and difference of opinions in a community are common and in fact, important to bring in improvements, the system of maintaining forks can be expensive and as seen above, lead to more than a single main chain - thereby creating newer blockchains. This goes deeper since each hard fork can potentially spit out a new blockchain and takes with it, a part of the community which dedicates itself to the older chain’s maintenance and development.
An immediate thought that comes to mind is to reduce complexity by maintaining only one main chain and therefore avoiding a split. However, we then struggle with the idea of taking everyone’s opinion into account. This is solved by self-amendment protocols that allow blockchains to upgrade themselves without having to split (“fork”) the network into two different blockchains. Specifically, there is an on-chain mechanism to propose changes to the protocol, to vote for-or-against these proposed changes, and, depending on the result of the vote, to activate these changes or not.
Tezos is one of the most popular self-amending blockchains. Let’s take a look at how self-amendment is used to make changes to Tezos’ core economic protocol.
Tezos’ Self-Amendment Protocol
Tezos’ economic protocol is self-amending which implies that it goes through various periods of on-chain proposals and votes before actionable change. Note that the proposal, voting and activation processes are part of the economic protocol itself. Consequently the amendment rules themselves are subject to amendments. The self-amendment protocol can be divided into 5 broad phases:
The amendment process begins with the Proposal Period, during which bakers can submit proposals on-chain. In each Proposal Period, bakers can submit up to 20 proposals. Other delegates can then vote on the submission up to 20 times i.e., each baker may vote once on up to 20 proposals. The network proposals are counted and the most upvoted submission makes it to the next vote period. If the quorum (~tezos standard of majority) is not met, no proposals have been submitted, or there is a tie between proposals, the amendment process resets to a new Proposal Period.
In the Exploration Vote Period, delegates may vote for the top-ranked proposal from the previous Proposal Period. Delegates get to vote either Yea, Nay or Pass on a specific submission. While a Yea and Nay refer to with and against the motion, a Pass refers to a no-opinion vote. One of the significant aspects of this period is that the failure does not fallback to the beginning of the period and rather reverses the entire amendment process. This means that a lack of sufficient votes would lead to a rerun of the Proposal Period.
If a proposal is approved in the Exploration Vote Period, the Cooldown Period begins. The only purpose of this period is to let some time elapse before the promotion period. This period replaces the previous Testing period that was underused since most of the testing happens on a dedicated testnest.
At the end of the Cooldown Period, the Promotion Vote Period begins. The network decides whether to adopt the amendment based on off-chain discussion and performance on the testnets. This mimics the Exploration Vote Period in terms of voting as well as conflicts. A lack of resolution to adopt the amendment leads to full reversal beginning with the Proposal period
Adoption period provides enough time to enable the ecosystem and update the dev tooling. After this phase, the mainnet activation is complete. Following the adoption period the protocol is activated. After this step the blocks added to the chain are interpreted in the newly activated protocol. As a result gas costs (and other such details of operation inclusion) may differ.
Each of the above periods lasts five baking cycles (which is ~14 days when broken to the real time) thereby leading to an entire span of roughly 2 months. As discussed before, this not only allows each participant to voice their concerns with the proposed changes, but also facilitates keeping a single blockchain and avoiding continuous forks.
Top comments (0)