How will Cardano enter the Shelley era
In today’s article, we will dive into technical details related to the transition of the Cardano protocol to the Shelley era. You can read about hard forks and hard fork combinator that allows smooth switching between two versions of the protocol.
Very short upgrade of wheels in the box.
The work on a project never ends
In the world of software development, there is nearly no point in time in which the team could say that the work is complete and it there will be no need to work on the same part of the project again. Fixing new bugs, implementing improvements, or adding new features takes place for the whole life of a project. Cardano is a project that will be continuously improved over time to offer more and more functionalities. It is necessary to build the project with upcoming changes in mind. To design a project properly and make it modular can significantly help in the future.
Every blockchain project consists of a few key components. The most important ones are a networking layer, consensus mechanism, and a ledger. There is a dependency between the components from the bottom up. So it means that firstly a block must be received by a node via the network layer to make a decision whether to accept it or not. The decision is made by the consensus mechanism in order to update the ledger. If a block is accepted then it can be added to the blockchain.
Digging a bit deeper, the networking layer is responsible for interconnecting nodes, peer selection, and transferring data over the internet. Blocks and transactions are distributed over the internet from node to node. Nodes maintain a mem-pool to store transactions that have not been inserted into a block yet. When a node gets the right to create a block then it selects transactions for the mem-pool and inserts them into a new block. Blocks received by the network layer are used by the consensus mechanism that is in charge of transaction validation, adoption of blocks, and mainly selects a chain that is considered valid. There might be more competing chains available in a given moment and the consensus mechanism has to pick one. The consensus mechanism is also responsible for making a decision about producing a block. The consensus mechanism makes decisions based on the current state of the ledger. It is necessary to maintain a state that helps to decide about a block adoption or refusal. The adoption of a new block changes the ledger state and influences the adoption of the next block. It is important to make the components as abstract and independent as much as possible. It facilitates making changes in the components. It is also helpful for testing. For example, it is possible to test the consensus mechanism with many different ledgers. Or vice versa, it enables testing the same ledger with different consensus mechanisms.
Forking a blockchain
Blockchains are usually upgraded via soft-forks and hard-forks. A team delivers a new version of a client with new features and announces it publicly. Node operators, including pool operators, can decide whether they are interested in upgrading. The question always is whether the changes in the new client are backward compatible. Let’s assume that a new client is able to produce a new version of blocks. If an old version of the client is able to work with the new version of blocks then it is just a soft-work. We can say that the change is backward compatible. Node operators might not upgrade to the new version of the client and both old and new clients will maintain the same ledger.
A change in the client can be so fundamental that old clients are not able to accept a block that is created by the new client. In this case, we are talking about hard-fork. Making a hard-fork means that after the creation of a certain block the blockchain gets split. Imagine it as a fork or a one-way rail that is split into the two-way rails. New clients will maintain one chain and the old clients will do the same with the latter chain. Once a hard-fork is triggered, new clients will ignore blocks that are created by old clients, and vice versa, old clients will ignore blocks that are created by new clients. Thus, each group maintains its own chain.
In the case, new clients maintain the longer chain and old clients maintain the shorter one, measured from the point of the hard-fork, the operators of old clients are forced to upgrade in order to participate in maintaining the winning chain. Notice that the absolute number of old or new clients do not determine the longer chain. The network consensus dominance actually determines the winning chain. If a group with the newer version of the client holds a higher stake then it will win and will maintain the longer chain despite the fact that the absolute number of nodes is smaller than the number of nodes with the old clients.
The team naturally hopes that most node operators update their nodes to a newer version of the client and a chain consisting of a new version of blocks will win soon after the hard-fork. The chain maintained by old clients will most probably disappear because no one is interested in maintaining it. We can say that operators accepted changes made by the team.
Hard-fork can be quite dangerous because of the existence of two separate chains after the activation. In some cases, however, this is the intention. If a new project is to be created by the hard-fork, then both chains are maintained. Forking is a mechanism of how to update clients to newer versions. However, a hard-fork can also create a new project that rises from the old one. In this case, both chains are maintained after the hard-fork. One chain by the old clients and the second by new clients. In both cases, new blocks have to be continuously added. For example, it was the case for Ethereum Classic that was created on the blockchain history of Ethereum. Exchanges have to accept the chain and a new ticker has to be chosen for a new coin. If a new project is created, anyone who had any coins in the original blockchain will also have those coins in the new one. After the hard-fork, both chains have the same past, it means the same blocks, and transactions. It changes at the point of the hard fork and the future begins to be different for both chains.
Hard-fork combinator
The design described in the first chapter is very helpful when an upgrade of the project is to take place. An upgrade of blockchain is difficult and it is often said that it is similar to an attempt to replace a motor of a car when you drive 300 Km/h. Blockchain is global by nature so there is always a prime time on someplace on the planet. Blockchain cannot be stopped for a while just because of the upgrade of the protocol. Users should care only about the upgrade of a wallet and in an ideal case, they should not notice anything.
Everybody in the Cardano ecosystem has to download Shelley-compatible software before the hard-fork. Stakepool operators will have to download a new version of clients. Users will have to download a new Daedalus wallet. The new version of the client will contain the code necessary for the change. It means that the client is able to work with both Byron and Shelley blocks and ledgers. Currently, before the transition to the Shelley era, the main-net uses the Ouroboros Byzantine Fault Tolerance consensus mechanism (OBFT) and Byron’s ledger. Once the Shelley hard-fork is triggered, nodes will start to produce and accept exclusively Shelley blocks and only Shelley blocks will be added to the ledger. The Ouroboros Praos consensus will replace OBFT consensus. Notice that there is also the staking logic implemented in the Ouroboros Praos consensus. Nothing related to staking was in the code of Byron client.
There will be selected a block that will trigger the change and move the protocol from the Byron era to the Shelley era. The IOHK team created a hard fork combinator for that purpose and it will be included in the new version of the client. The hard fork combinator will allow a node to transit from one version of the blockchain protocol to another. The combinator is able to combine two protocols in a way that users will not notice a protocol switch. The combinator is able to let the node operate the first protocol up to the moment of switching to the second one. It will happen instantly right away after the triggering of the hard fork. If you remember our analogy with the car, the hard fork combinator will allow changing the motor during the ride in a reliable way.
Switching between protocols without interruption is a difficult task for the hard fork combinator. The time is split into epochs in the Cardano protocol and each epoch contains a given number of slots. The number of slots will change by the activation of the chard-fork. To make it more complex, the length of slots will also change from 20 seconds to 2 seconds or perhaps even to 1 second. At a single moment, the protocol must transit to a new consensus mechanism and ledger. It must happen on all nodes in the world. The Cardano must just continue with making the network consensus and adding blocks into the blockchain without interruption.
You can read more about the hard fork combinator on the IOHK blog:
Summary
We can expect more changes in the Cardano protocol in the future for which the hard fork combinator will be reuse. After the Shelley era, there will be Goguen, Basho, and Voltaire eras and for each of them, the combinator will be used. The combinator will facilitate a smooth transition from one version of the protocol to another. It is an invisible but very important and complex piece of software. Cardano is made to allow extending a feature set and for that, there is a mechanism that allows it.
Can any of you help me out, I’m so sick I can’t figure it out