Consensus with Proof of Stake
The technology at the core of Bitcoin was a means to reach decentralized consensus on the state of transaction ledger. Bitcoin defined one simple metric by which the best transaction ledger could be identified: the longest ledger.
On average every ten minutes someone on the Bitcoin network would win a block as a result of their computational effort. If blocks are found more frequently than every ten minutes the network would automatically adjust the difficulty of winning a block to maintain the desired rate. As the number of people competing grows the difficulty becomes so high that no one individual (in theory) can produce blocks as fast as everyone working together.
Bitcoin uses the policy ‘one-hash, one-vote’ for deciding which transaction ledger is the best ledger. The more votes that are behind a particular blockchain, the more people support that chain. That is the theory anyway. In practice a small number of individuals control the vast majority of the votes.
With Proof of Stake systems each shareholder gets one vote per block. As owners of the chain and parties interested in the outcome this process is also an effective means of reaching consensus if it can be implemented efficiently. When ever there is a disagreement about which change should be applied to the ledger then the dispute must be resolved by shareholder votes.
Every time a transaction is made by the network, the individual making the transaction simultaneously cast one vote per share transacted for every block produced since the last time they voted. Every users is required to transact at least once per year or face a 5% inactivity fee and a loss of their opportunity to vote.
The result of this process is that after 12 months every block in the block chain has been either voted for (or against) by almost every. It can therefore be proven beyond a doubt which block had the majority of shareholder consensus.
Ideally everyone would vote on every block so that immutable consensus could be reached as quickly as possible. In practice, this would be expensive and overkill as everyone would have to sign every block. To resolve this process voting is done on a continual basis as users make transactions. This means that for recent blocks there are not enough votes cast to be considered irreversible.
Bitcoin considers transactions to be irreversible after 6 blocks; however, this is only true if you assume the network is able to maintain its hash power and that the attacker’s hash power is only 49% of then network hash power.
Under proof-of-stake, a transaction is considered irreversible when it becomes highly unlikely that other shareholders could achieve 51% of the votes for an alternative chain. There are generally three cases where shareholders would end up voting for an alternative chain:
1) The network has split at an infrastructure level and causes entire continents to start producing their own alternative chains. When network connectivity is restored many transactions will have to migrate from one chain to another and in many cases a lot of transactions will become invalid in the process. Because no one wants their transactions to become invalid, everyone competes to resolve the fork by casting votes (making transactions) on one chain or the other. Eventually the block at which the chains diverged will accumulate 51% of the votes and the fork will be resolved.
2) The network has split because an attacker is attempting to double spend. In this case, the attacker is attempting to take advantage of the fact that only a small percentage of shareholders are voting every block. The attacker users all of their votes in one go in an attempt to hijack the network with an alternative chain that no one but the attacker was aware of.
To resolve such an attack nodes on the network simply ignore all alternative chains that fork more than 6 blocks ago, unless said alternative chain has at least 25% of the shareholders voting for it and it has at least 10% more votes than the chain the node is currently on, or 51% of all shareholders.
3) Latency can also cause forks in the short-term. These forks are caused when propagation delay and randomness associated with the time between finding consecutive blocks causes part of the network to see 2 or 3 blocks before the rest of the network. This use case if by far the most common and must be resolved quickly in order to prevent the fork from becoming a problem for the users.
Latency induced forks can be mitigated by following some simple logic on determining the best chain in the short term.
a) All blocks must have a time stamp at least 1 minute after the previous block and must not have a timestamp in the future. Nodes are synchronized via NTP. This simple rule gives at least one minute of propagation time between blocks.
b) To produce a block in the first place requires at least a minimum number of votes and the accumulation of enough transaction fees to be worth the ‘miners’ time. This will serve as a delay on producing blocks.
c) The head block can always be replaced if a better head block is found. This means that if two (or more) blocks are found at once, then only one of them will be accepted by the network and there will be at least a minute between blocks for the network to converge.
Despite these protections, there is still the potential for there to be short 2 or 3 block forks. In this case nodes in the network defer to a trusted peer list which operates on a basis similar to Ripple’s consensus algorithm.
Perhaps the most important and critical factor in resolving forks is that the shareholders can always take action if necessary and unambiguously resolve the fork. Everything else is simply measures to reach consensus quicker.
All of that said, we will have a single trusted key broadcast the official fork after 2 blocks so that any nodes that end up on a different fork can switch to the proper fork without much delay. This will be for training wheels and security while the network is in its testing phase.
Topic: TaPOS Consensus / Fork Management (Read 7215 times)
