It is not a secret anymore that pure PoW networks are vulnerable to forking. We have witnessed the creation of several minority forked coins, most notably Ethereum Classic, Bitcoin Gold, Bitcoin Cash, and Bitcoin SV.
This post explains how the Decred network prevents minority forks, based on an analysis originally posted on Reddit by davecgh. It describes important aspects of Decred’s hybrid Proof-of-Work (PoW) and Proof-of-Stake (PoS) consensus system and provides a detailed walkthrough of what would happen if any entity attempted to split the Decred blockchain.
If you need a reminder on why forks should be avoided, read this article:
Preliminary knowledge
The Decred network is secured by both PoW miners and PoS voters. The PoS voting system works by locking up chunks of coins into what is called a voting ticket. These tickets function as fundamental building blocks which allow stakeholders to participate in Decred’s governance.
Per block, maximum 20 new tickets are available. Once acquired, there is a 256-block maturity period after which the ticket is placed into the live ticket pool. This pool has a target size of 40960 tickets, but it can grow or shrink throughout the course of operation. PoS difficulty (ticket price) is adjusted via supply and demand to maintain the 40960 target size. The algorithm that controls the ticket price is described in DCP0001.
Live tickets are waiting in the pool to cast their vote and the selection process is impossible for PoW miners to manipulate. The algorithm that controls ticket selection is primarily based on the hash of the previous block, which means it is both pseudorandom and deterministic. If you are building block 100 on top of block 99, the tickets to be included in block 100 are known to every full node on the network. Ticket selection can only be changed by finding a new solution to block 99 with a different hash, which in turn would cause a new set of random tickets to be selected for voting eligibility.
Each block, 5 tickets are eligible to vote. At least 3 out of the 5 votes must be included in the block, otherwise it will not be accepted by the network. The reward for PoW miners is reduced if only 3 or 4 votes are included, by 40% and 20%, respectively, to discourage miners from ignoring votes and in that way attempting to game the system.
It is important to note that stakeholders must be present on a given chain fork when their tickets are selected. The act of acquiring a ticket does not mean it automatically votes, your wallet (or your Voting Service Provider) has to cast your vote when the ticket is selected. This distinction is key because it means that the live ticket pool on a minority fork is largely comprised of non-voting tickets, since its owners are on another chain.
A detailed treatment of the theory behind each of these aspects is beyond the scope of this post, however, it primarily has to do with protection against various adversarial situations.
Scenario, Assumptions, and Methodology
With all of this in mind, let’s imagine a scenario in which an entity attempts to create a fork that 75% of the stakeholders don’t agree with.
Let’s assume that both sides of the attempted fork have equal hash power (so 50% hash power on each fork). As stated, 75% of the stakeholders are on the majority chain, while 25% are on the minority chain.
Further, let’s assume the most recent block at the point of the fork is block 99999. Thus both sides of the fork are working on finding block 100000, one side on the minority rule set, the other side on the majority rule set.
Finally, in order to simplify the description and make it easier to follow the logic, since only 25% of the stakeholders are on the minority chain, let’s say that every 4th ticket in the live ticket pool is a stakeholder on the minority chain. In other words, ticket numbers 0, 4, 8, 12, 16, 20, …, 40956 are tickets in the live pool which represent stakeholders on the minority chain, while ticket numbers 1, 2, 3, 5, 6, 7, 9, …, 40957, 40958, 40959, are tickets in the live pool which represent stakeholders on the majority chain.
Remember: stakeholders must be present on a given chain fork when their tickets are selected to successfully cast their votes.
Step-by-step walkthrough
The following is a sequence of events that would happen in the scenario of a forking attempt, as described and illustrated above.
Block 100000
- The hash power on both chains will try to build a new block on top of block 99999.
- In order for this new block to be built on the minority chain, it needs to acquire at least 3 votes from the live ticket pool and the selected votes depend on block 99999.
- The tickets required to build block 100000, based on a block 99999 hash, are ticket numbers 17113, 17331, 21307, 21328, and 24903.
- As we can see, 4 out of those 5 tickets are stakeholders on the majority chain (ticket numbers 17113, 17331, 21307, and 24903), which means they are going to cast their votes for block 100000 on the majority chain.
- The minority chain is only able to acquire 1 vote (ticket number 21328), so it can’t build a block 100000. Instead, it must go back and find a new solution to block 99999 to cause a new set of tickets to be selected.
At this point, the chains look as follows. Parentheses with the * in this notation indicate blocks that are being worked on.
... -> [99999] -> (100000*)
majority stakeholders (75%) are on this chain\-> (99999a*)
minority stakeholders (25%) are on this chain
In other words, the majority chain is now working on block 100000, while the minority chain is stuck trying to find a new solution for block 99999 in order to get a new set of tickets hoping this time they’ll be able to get at least 3 votes. Since, per our thought experiment, both chains have equal hash power, we can safely assume that, on average, both block 100000 on the majority chain and new block 99999 (call it 99999a) on the minority chain will be found around the same time.
Block 100001
At this point, the following will happen:
- The hash power on the majority chain will try to build a new block on top of the majority chain’s block 100000. The votes required for this block are ticket numbers 563, 6766, 21009, 37394, and 37775.
- This time, all 5 out of those 5 tickets happen to be stakeholders on the majority chain, which means they are going to provide their votes for block 100000 on the majority chain which allows block 100001 to be built.
- The minority chain, now with a new version of block 99999 (99999a) has a new hash, so it ends up requiring ticket numbers 1069, 8007, 16413, 19172, and 31821.
- The minority chain is still only able to acquire 1 vote (ticket number 19172), so it must once again go back and find yet another new solution to block 99999 in order to cause a new set of tickets to be selected.
The chains now look as follows:
... -> [99999] -> [100000] -> (100001*)
majority stakeholders (75%) are on this chain\-> (99999b*)
minority stakeholders (25%) are still on this chain
In other words, the majority chain is now working on block 100001, while the minority chain is still stuck trying to find yet another new solution for block 99999 in order to get a new set of tickets hoping this time they’ll be able to get at least 3 votes. Since, per our thought experiment, both chains have equal hash power, we can again safely assume that, on average, both block 100001 on the majority chain and a new block 99999 (call it 99999b) on the minority chain will be found around the same time.
Block 100002
At this point, the following will happen:
- The hash power on the majority chain will try to build a new block on top of the majority chain’s block 100001. The votes required for this block are ticket numbers 174, 1999, 12808, 31928, and 38317.
- This time, 3 out of those 5 tickets are stakeholders on the majority chain (ticket numbers 174, 1999, 38317), which means they are going to provide their votes for block 100001 on the majority chain which allows block 100002 to be built.
- The minority chain, now with a new version of block 99999 (99999b) has a new hash, so it ends up requiring ticket numbers 4653, 15211, 29988, 35175, and 35665.
- The minority chain is still only able to acquire 1 vote (ticket number 29988), so it must once again go back and find yet another new solution to block 99999 in order to cause a new set of votes to be selected.
The chains now look as follows:
... -> [99999] -> [100000] -> [100001] -> (100002*)
majority stakeholders (75%) are on this chain\-> (99999c*)
minority stakeholders (25%) are still on this chain
In other words, the majority chain is now working on block 100002, while the minority chain is still stuck trying to find yet another new solution for block 99999 in order to get a new set of tickets hoping this time they’ll be able to get at least 3 votes.
Fast-forward to Block 100010
The process repeats until, eventually, some variant of block 99999 on the minority chain gets lucky and happens to select 3 tickets that are on the minority chain. This turns out to be roughly 1 in 10 tries. So, fast forwarding a bit to see the chain by the time this happens, the chains would look as follows:
... -> [99999] -> [100000] -> [100001] -> [100002] -> ... -> [100009] -> (100010*)
majority stakeholders (75%) are on this chain\-> [99999j] -> (100000a*)
minority stakeholders (25%) are still on this chain
It should be pretty clear, since both chains have equal hash power, there is no way the minority chain can now ever catch up to the majority chain. Furthermore, the same process is going to repeat for the minority chain’s block 100001 where it will have to go back and remine (find new solutions) for its block 100000 over and over until it gets a lucky draw again such that it gets the 3 votes it needs.
Consequently, miners are not going to stay on the minority chain because they are hardly getting any rewards. The minority chain will never be profitable and hence all mining power will eventually return to the majority chain.
Common objections
What if the minority chain gets more than 10x the hash power of the main chain?
Theoretically, if the minority chain with only 25% stakeholder approval had 10x the hash power of the main chain, yes, it could keep up with the majority chain. However, this is not a realistic scenario because of the economic incentives.
Mining the minority chain with 10x the hash power effectively means that the miners would only be getting 1/10 of the block reward as they would on the majority chain, based on hash power alone. In our scenario it’s reduced even further to 1/10 of 60% due to only being able to include 3 votes on average. In other words, miners would only receive 6% of the rewards they would by mining the majority chain. Looking at it from another angle, they would receive 94% less by mining the minority chain.
Putting that into numbers, if a miner had, say 5% of the total network hash power, they could expect to receive roughly 5% of the PoW reward per block, or 5% of ~13.89 ≈ 0.6945 DCR at the current time. However, on the minority chain, first the reward would be 60% of ~13.89 ≈ 8.334 DCR, and then that 5% hash power would only be 0.5% of the total hash power on the minority chain, thus 0.5% of ~8.334 ≈ 0.04167 DCR. Looking at the numbers, we can see that 0.04167 DCR is indeed 6% of 0.6945 DCR.
PoW mining is very competitive since it is a zero sum game. Most miners, even those with huge advantages such as free electricity, have thin margins and are often banking on future appreciation to pick up the slack. Given the 94% reduction in income, most miners would actually have to pay in order to mine on the minority chain.
Can’t somebody just change the consensus rules to ignore the stakeholders?
If the minority chain removed or disabled ticket voting for a certain period of time, it would be able to produce blocks and fork away from the majority chain. While it is theoretically possible, doing so would completely destroy the hybrid system and return the forked currency to effectively being a pure PoW network. It would undoubtedly no longer be Decred.
Unlike in pure PoW coins where nobody can say which chain is the “real” one due to the lack of a provable and formalized governance system, Decred has a very clear and well understood governance model. Decred stakeholders make the decision which chain is the real Decred and they do so in an on-chain and cryptographically provable fashion.
Stakeholders sign up for Decred with the expectation that major consensus decisions are made by the stakeholders themselves. Removing the authority of the stakeholders would be akin to removing Proof-of-Work from a pure PoW coin. In other words, it would completely destroy the security properties of the system. How much confidence are holders going to have in a coin that ignores one of the primary characteristics it claims to offer?
Conclusion
Decred’s hybrid PoW and PoS consensus system makes blockchain forks extremely difficult — if not impossible — without majority stakeholder approval. The walkthrough has demonstrated why a Classic, Gold, or Cash scenario is highly unlikely on the Decred network.
The costs to maintain a minority fork with even 10x of the hash power are substantial; miners can expect a severe reduction in income if they decide to participate. Alternatively, it is possible to remove or disable the PoS system and split the Decred chain like any other PoW network. However, this defeats the purpose of Decred and it is doubtful whether anyone would take such an attempt seriously.
Getting the fundamentals of fork resistance right is critical to longevity. The hybrid PoW and PoS system creates checks and balances to ensure that small groups cannot dominate the flow of transactions or make changes to Decred without agreement among stakeholders. It incentivizes coordination and collaboration, which turns Decred into an uncommonly strong network that is built to last for the long-term.
Further reading
This post has covered the important topic of fork resistance, but there is much more to discover. For example, the hybrid PoW and PoS system of Decred is also a superior deterrent to majority (51%) attacks. If you want to know how this works, read this post by Zubair Zia:
For more advanced topics, you could investigate how Decred can smoothly upgrade its network via voting on consensus rule changes, or how people can submit proposals to the off-chain governance system called Politeia.
If you prefer the basics, check out the Decred Documentation.
Pick one of the chat platforms listed here if you want to interact with the Decred community. We are a pragmatic bunch of people — come join us!
Credits
If it wasn’t for the original analysis by davecgh, this post would probably not exist. Furthermore, Artikozel’s review and the constructive comments in the writers room improved this post tremendously. The illustration of the scenario was created by Zubair Zia. Thank you, all!
