Nothing-At-Stake, Long Range Attacks & Dynamic Availability
Nothing At Stake
The principal of a Nothing-At-Stake issue with Proof-Of-Stake blockchains is that validator risks nothing when creating blocks on a different chain.
This can be illustrated by considering a fork into chain A and B. As a block producer (validator) gets rewarded for producing blocks, with the aforementioned fork the validator can choose to work on (1) only chain A (2) only chain B, or (3) both chain A and B. Even if there are differing probabilities that one of the two chains will eventually be the longest, as long as the smaller probability chain does not have zero probability of being the longest chain, the validator will always choose to work on both chains. Thus maximising their likely pay-out. This is because there is no need to split their stake to work on both chains. This is also unlike PoW where there is computing resource (electricity costs) which has to be spent in order to work on multiple chains, thus disincentivising this behaviour.
The solution to this problem is therefore to introduce a punishment, namely a deposit by the validator onto the blockchains which is at risk for misbehaving. Punishments may come in the form of either:
- Punish if found validating both chains at the same time
- Punish if found validating the wrong chain – in this case its wise to validate on the chain with the highest likeihood of being the longest as the probability of being fined is lower.
Long Range Attack on PoS
A long rang attack is where a validator has no risk of losses from misbehaving. This is when an amount of time has passed such that the at risk deposit is returned. At this point the validator can fork without the risk of principal losses, and the reason it is named a ‘long range’ attack is because the validator needs to be correctly validating on the network for a period of time (i.e. a new validator cannot initiate the attack).
In the above illustration, you can note that the attacker is able to build a dense long chain forking from earlier in the primary blockchain. This is because the attacker will always be able to append blocks in this chain. For a new participant (validator on the network) there is now a very difficult choice to make. Without additional information, the new participant will likely choose to grow the attacker chain.
In order to mitigate this, checkpoints are implemented along the blockchain. These are considered trusted blocks and such that any fork starting before a checkpoint is considered invalid. The deposit period is then set to be a period longer than the checkpoint periods. For validators persisting on the chain, the checkpoints are known, however for new participants, no validators which have been offline for a period of time, there is a difficulty in deciding the longest chain.
A solution to this is finding a trusted source for a recent block header of the valid blockchain (this is fundamentally different from PoW where you simply use the longest chain rule). This could be a block explorer or an organization which has a high reputation. This block header could be used as a check point.
Dynamic Availabiliy
This is where we can assume that participants on the network (validators) are able to join and leave at any given time. They may lose clock synchronisation and also there is no knowledge of participation at any given time. This would be an ideal situation.
Summary
The below table illustrates how long range attacks and dynamic availability work, or are possible for (1) PoW blockchain (2) PoS blockchain and (3) PoS BFT (byzantine fault tolerance).
Note that in PoS BFT (unlike PoS), the nodes running the protocol agree on all blocks, meaning you do not have forks because every time you produce a block, there is sufficient agreement. Therefore you do not have to resolve disagreements. Nevertheless in order to run a protocol, you need to know the level of participation.
For a new participant (validator) on the network, bootstrapping from genesis (the first block in the blockchain), you simply follow the longest chain (highest difficulty) for bitcoin. For a PoS chain you also have the requirement in knowing the latest checkpoint from a trusted source. Finally for PoS BTF, you need to be aware of the participation level on the blockchain at all times in history.
| Bitcoin | PoS Blockchain | PoS BFT | |
| Long Range Attacks | longest chain rule | longest change rule + moving local checkpoints + key evolving Signatures | only one proper squence of block certificates + key Evolving SIgnatures |
| Dynamic Availability | Possible using only the genesis block | (re)joining parties need a recent block (check point) | parties need to know participation level at all times in history |
Thanks GHost
Love the docs