Claim: Proof of Stake can be faked easily. The money only exists on-chain, so I can make a thousand chains with different histories and you can’t choose the canonical one between them. To make it unforgeable, you need to add a new mechanism that is separate from the actual stake (such as outside trust sources and/or a “finality” mechanism”).
Category: Consensus protocols
Evidence/Argument: The attack that James Prestwich describes is more formally known as the “nothing at stake” attack. Vitalik does a great job of explaining the “nothing at stake” attack in this post:
Proof of work has a nice property that makes it much simpler to design effective algorithms for it: participation in the economic set requires the consumption of a resource external to the system. This means that, when contributing one’s work to the blockchain, a miner must make the choice of which of all possible forks to contribute to (or whether to try to start a new fork), and the different options are mutually exclusive. Double-voting, including double-voting where the second vote is made many years after the first, is unprofitable since it requires you to split your mining power among the different votes; the dominant strategy is always to put your mining power exclusively on the fork that you think is most likely to win.
With proof of stake, however, the situation is different. Although inclusion into the economic set may be costly (although as we will see it not always is), voting is free. This means that “naive proof of stake” algorithms, which simply try to copy proof of work by making every coin a “simulated mining rig” with a certain chance per second of making the account that owns it usable for signing a block, have a fatal flaw: if there are multiple forks, the optimal strategy is to vote on all forks at once. This is the core of “nothing at stake”.
I agree with James Prestwich that to overcome this problem, you need to bolt on an additional mechanism. For example, one approach is to add a security deposit: A validator must put down a security deposit, and if he is caught voting on multiple forks, the reward and security deposit is slashed.
The issue with security deposits is that they are only useful for a short range of blocks. Why? Because…
Let’s say we require validators to put up a security deposit, and we lock that up for N blocks. As soon as the validators have the right withdraw the security deposit, there is no longer any incentive not to vote on a wrong/fraudulent fork starting far back in time using those coins. In other words, unless we have some way to deterministically know the “canonical chain” before the security deposit is returned, the validator could vote on a wrong/fraudulent fork at some block between the latest block (n) and after the security deposit was made (n - N).
Therefore, the claim is accurate in that 1) nothing-at-stake problem makes it easier for validators to vote for multiple forks 2) you need some additional mechanisms (e.g. security deposits + finality mechanism) to fix this problem.