denysrodman
Member
 Offline
Activity: 224
Merit: 11
|
 |
November 24, 2017, 09:24:05 PM |
|
Detailed Analysis of Decred Fork Resistance
There have been several questions regarding how Decred makes minority forked coins, in the sense of Ethereum Classic and Bitcoin Gold, extremely difficult without majority stakeholder approval, and, for all intents and purposes, impossible without also destroying the hybrid nature of the system in the process.
In order to try and explain why this is the case, the following is an analysis that first describes the important aspects of the system as they relate to this topic and then walks through the process of what would happen in a fork attempt under the worst case scenario.
Preliminaries
The Proof-of-Stake (PoS) system works by locking up chunks of coins into what is called a ticket. These tickets function as the fundamental building block which allows stakeholders to participate in governance. Once acquired, all tickets are placed into a pool of live tickets after a maturity period. This pool is known as the live ticket pool and has a target size of 40960, but it can grow larger or shrink as tickets are added and removed throughout the course of operation, and the ticket price (stake difficulty) is adjusted, per supply and demand, to try to maintain that target pool size. This is covered more in depth in DCP0001 for readers who want a more thorough treatment.
The consensus rules enforce a ticket selection algorithm that works to ensure that ticket selection is both random and impossible for miners to manipulate. It achieves this by pseudorandomly selecting 5 tickets from the aforementioned live ticket pool which are eligible to vote on the previous block and that at least 3 of them must be included. The subsidy is reduced if only 3 or 4 votes are included, by 20% and 40%, respectively, in order to discourage miners from ignoring votes and otherwise attempting to game the system. A detailed treatment of the theory behind each of these parameters is beyond the scope of this post, however, it primarily has to do with protection against various adversarial situations.
Further, the pseudorandom ticket selection process is primarily based on seeding it with the hash of the block it's voting on. This implies that, if you're building, say block 100000, on top of block 99999 (hash 00000000000000dab92a8a0c0e706eb74115f0f373669c01ffb4882f9555f494), the chosen votes are known to every other full node on the network and can't be changed without going back to find a new solution to block 99999 such that it has a different hash (say 00000000000004289d9a7b0f7a332fb60a1c221faae89a107ce3abbd186c386c), which in turn will cause a new set of 5 tickets to be selected for voting eligibility.
Step-by-step Walkthrough
Scenario, Assumptions, and Methodology
With all of that in mind, let's walk through an attempt to create a minority fork that the majority stakeholders don't agree with. Let's also assume that both sides of the attempted fork have equal hash power (so 50% hash power on each fork). Given that a successful vote requires 75% stakeholder approval, in the worst case, 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 side of the fork are working on trying to find 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 and the rest are on the majority chain. In other words, ticket numbers 0, 4, 8, 12, 16, 20, 24, ..., 40956 are tickets in the live pool which represent stakeholders on the minority chain, while ticket numbers 1, 2, 3, 5, 6, 7, 9, 10, 11, 13, 14, 15, 17, 18, 19, 21, 22, 23, 25, ..., 40957, 40958, 40959, are tickets in the live pool which represent stakeholders on the majority chain.
Block 100000
The following is the sequence of events that will happen:
The hash power on both chains will try to build a new block on top of block 99999.
Per the above description, 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, which is based on 99999 are ticket numbers 17113, 17331, 21307, 21328, 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 provide 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 in order to cause a new set of tickets to be selected.
At this point, the chains now look as follows. The 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 still 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 block for 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 a new block 99999 (call it 99999a) on the minority chain will be found around the same time.
Block 100001
As the 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, 37775.
This time around 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, 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.
At this point, 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 a new block 99999 (call it 99999b) on the minority chain will be found around the same time.
Block 100002
As the 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, 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.
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, 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.
At this point, 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 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're never going to be able to become the majority chain and hence would be mining for free.
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 the miners would only be getting 1/10 of the subsidy as they would on the majority chain based on hash power alone, but it's reduced even further by being 1/10 of 60% of the subsidy due to only being able to acquire 3 votes on average. In other words, miners would only receive 6% of the rewards they would by mining the majority chain, or looking it from the other way, 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 subsidy per block, or 5% of ~13.89 ~= 0.6945 DCR at the current time. However, on the minority chain, first the subsidy 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. Thus, 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, especially those without huge advantages such as free electricity, have very thin margins and are often banking on future appreciation to pick up the slack. Miners would actually have to pay money to mine the minority chain due to the aforementioned effective 94% reduction in income.
Can't somebody just change the consensus rules to ignore the stakeholders?
Yes, it is theoretically possible to do this, but doing so would completely destroy the hybrid system and return the forked currency to effectively being a pure Proof-of-Work system thereby removing any value of the system. It would also undoubtedly no longer be Decred, since, unlike in a pure PoW coin where nobody can really say which chain is the "real" one and which isn't due to lack of a provable and formalized governance system, Decred has a very clear and well understood governance model where the majority of stakeholders make the decision which chain is the real Decred and they do so in an on-chain and cryptographically provable fashion.
Further, 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?
|
