Understanding ‘Forking’ in Blockchain, its implications and why Algorand blockchain does not fork.
Most blockchain users do not have all the time in the world to dedicate for analyzing what a project (perhaps blockchain’s) entails. Mostly, they are concerned with end results. An exception to this is the case with the investors, who desire maximum security for their capitals. They would search for information about specific project of their interests particularly the underlying technology on which such projects survive. In this article, I will explain one of the key factors to consider in a blockchain project that will augment your list of tools for decision making. There are bound to be few technical terms but I will try to minimize suffice for your need.
In literal term “fork” according to the Merriam Webster’s dictionary, is a place where something divides into two parts. An example can be a road such as a “Y” junction or a river flowing in a direction and divide into two parts at some point. Taking it to blockchain, it is what is achieved as a result of split in a network where a blockchain splits into two concurrent chains. That is, when a blockchain diverges into two potential paths forward. Reason for forking could be any of the following:
- Intentional – e.g where there is a software upgrade in node (s).
- Unintentional – e.g a result of computation in a consensus algorithm i.e proof of work.
- Network/protocol changes – such as where two or more blocks have the same height.
- Community disagreement – where a community fails to agree to a certain rule. This leads to a hardfork such as in the case of EThereum vs Ethereum classic 2016.
Different types of forking
- Hard-fork: This is a result of network upgrade where the old chain is not compatible with the new one. The upgrade action causes the nodes in the new chain to reject the block generated by the old node client software due too incompatibility. However, for the old nodes to continue generating blocks on the new chain, they must simultaneously opt in to the new software. If this happens, there must exist a consensus among the different members of the networks hence it may pose a serious threat to the continuity of the project.
Note that in Hard-fork:
- The two chains never meet again.
- If a clear winner chain isn’t established, politics may set in and the economics can ruin the project.
- It is employed if a clear consensus method is devised to handle such change (s)
- Soft-fork: an event where is a new set of rules different from the existing rules, mostly used for smaller network change. Both rules set exist in the same change and such a change that is backward compatible with the original state of software before the fork was performed. This often give rise to voting-like mechanism where, if a 51% of the network participants agree to adopt the new rules, old ones will be discarded.
- Unintentional fork happens often in a proof of work consensus system where miners simultaneously discover a block consequentially resulting in what is called blockchain split. In the even of this occurrence, the longest chain is considered and added to the block when miners discovered a block at the same time, and each of them starts mining concurrently on the block they discovered. The potential rule sets in which states the longest chain is a valid chain. Sooner, one chain will get ahead of the other and one resorts to another chain again. It does resorted to a general rule of six block confirmation, hence chances are that your transaction is contained in the longest chain.
The Bitcoin Forking Saga
You probably might have come across several Bitcoin forks – Bitcoin unlimited, Bitcoin cash, Bitcoin private and so on, wondering why are there so many versions of seemingly the same coin? We need to know why this happens and the probable causes and/or consequences, perhaps re-acquaint ourselves to the scalability debate.
Bitcoin uses a proof of work consensus algorithm which requires that miners use computing power to create a block (adding transactions to a block). For a transaction to be valid, they must be added to a block in the chain. This is the source of the problem as a block in the chain has a size owing to 1 Megabyte. In the meantime, Bitcoin network became more popular and the amount of transaction in a month has grown tremendously that it becomes difficult for the chain to accommodate the outburst resulting to Bitcoin performing around 4.4 transactions/sec TPS. It resorted to Bitcoin adopting a method called “replacement-by-fee“. To fully understand it, let’s take a scenario where Bob initiates a transfer to Alice of 1 BTC and the transaction failed due to backlog in the network. The BTC spent is irrecoverable. However, in Rbf system, Bob is left with the option of initiating another transaction of the same amount and raising the fee to incentivize miners. When miners see the new transaction with a higher fee, they give more preference and approve it over others with lower fee. Adding it to the block replaces the existing hanging transaction and it is discarded. We would agree the system is primarily in favor of miner. In this case of users, it is not cheap, inconvenient and not viable for larger Bitcoin transaction. But if you pay lower fee, you would have to wait for at least 30 minutes for your transaction to go through and sometimes running to 24 hours for a transaction to go through. Ethereum has also recently be noted with this method.
Bitcoin forks happen as a result of introduction of new set of rules different entirely from the old ones. Miners however can still mine on the existing chain using the old rules. This is the case that birthed the different Bitcoin variations. Bitcoin Cash for instance has a block size of 8 megabyte with no replacement-by-fee method while Bitcoin still maintains a static size of 1 megabyte and operating on Rbf. The data on the old chain is duplicated to a new chain which connotes if a user owns 2 BTC on the old Bitcoin network before the hard-fork, ythe as well automatically own the corresponding amount on the new Bitcoin cash network. Consequentially, this arose as a result of scalability issue relative to the proof of work algorithm and it requires a higher computation power hence uneconomical.
Algorand blockchain does not fork. Why?
One notable attribute of Algorand is the probability that its transaction history will fork is very infinitesimal. The chance that this will happen is estimated at 1/1,000,000,000,000. This is absolutely negligible and the probability seems to be very insignificant. In comparison with other proof of work (POW) blockchain such as Bitcoin, Algorand uses a pure proof of stake mechanism to arrive at an irreversible agreement among the network participants since it is a truly distributive system. It is the first Blockchain protocol to have conveniently solved the Blockchain trilemma (scalability, security and decentralization issues) without compromise to any of them. In Algorand, there exists no exogenous entities (bodies which are technically external to the main system such as miners in the case of Bitcoin) to determine which transactions should be added to the block. The power is absolutely vested in the users who are participants in the network. Transaction approval time is approximately 5 seconds and users can rely on payment soon as transaction is added to a block. The action is final.
In section 1.3 of the Algorand’s whitepaper, the following is contained:
1.3 Closely Related work //Proof-of-work approaches (like the cited  and ) are quite orthogonal to our ours. So are the approaches based on message-passing Byzantine agreement or practical Byzantine fault tolerance (like the cited ). Indeed, these protocols cannot be run among the set of all users and cannot, in our model, be restricted to a suitably small set of users. In fact, our powerful adversary my immediately corrupt all the users involved in a small set charged to actually running a BA protocol. Our approach could be considered related to proof of stake , in the sense that users’ “power” in block building is proportional to the money they own in the system (as opposed to —say— to the money they have put in “escrow”). The paper closest to ours is the Sleepy Consensus Model of Pass and Shi . To avoid the heavy computation required in the proof-of-work approach, their paper relies upon (and kindly credits) Algorand’s secret cryptographic sortition. With this crucial aspect in common, several significant differences exist between our papers. In particular, (1) Their setting is only permissioned. By contrast, Algorand is also a permissionless system. (2) They use a Nakamoto-style protocol, and thus their blockchain forks frequently. Although dispensing with proof-of-work, in their protocol a secretly selected leader is asked to elongate the longest valid (in a richer sense) blockchain. Thus, forks are unavoidable and one has to wait that the block is sufficiently “deep” in the chain. Indeed, to achieve their goals with an adversary capable of adaptive corruptions, they require a block to be poly(N) deep, where N represents the total number of users in the system. Notice that, even assuming that a block could be produced in a minute, if there were N = 1M users, then one would have to wait for about 2M years for a block to become N2 -deep, and for about 2 years for a block to become N-deep. By contrast, Algorand’s blockchain forks only with negligible probability, even though the Adversary corrupt users immediately and adaptively, and its new blocks can immediately be relied upon. (3) They do not handle individual Byzantine agreements. In a sense, they only guarantee “eventual consensus on a growing sequence of values”. Theirs is a state replication protocol, rather than a BA one, and cannot be used to reach Byzantine agreement on an individual value of interest. By contrast, Algorand can also be used only once, if so wanted, to enable millions of users to quickly reach Byzantine agreement on a specific value of interest. (4) They require weakly synchronized clocks. That is, all users’ clocks are offset by a small time δ. By contrast, in Algorand, clocks need only have (essentially) the same “speed”. (5) Their protocol works with lazy-but-honest users or with honest majority of online users. They kindly credit Algorand for raising the issue of honest users going offline en masse, and for putting forward the lazy honesty model in response. Their protocol not only works in the lazy honesty model, but also in their adversarial sleepy model, where an adversary chooses which users are online and which are offline, provided that, at all times, the majority of online users are honest.2
Diving deeper into the WP satisfies why Algorand blockchain would not fork, analogous to a consistent blockchain network with reliable block finality.
In conclusion, taking a deeper look at Algorand says something good about the future of blockchain and digitization of money including tremendous financial growth in general if gone mainstream. Performing transactions on Algorand is very fast with a beyond-considerable low cost. Far from just sending and receiving monetary value, its scalability power makes it a fertile ground for decentralized applications (smart contracts) to grow.