Understanding Proof of Stake through it’s Flaws. Part 2 — ‘Nothing’s at Stake’

Note: This is the second part in a series in which I investigate the major problems with Proof of Stake currencies in an attempt at gaining better understanding of them. See part 1 for an introduction to Proof of Stake and part 3 for a discussion of ‘Long-Range Attacks’

The first major flaw in Proof of Stake is something lovingly termed the ‘Nothing at Stake’ problem by it’s opponents, and at the heart of this flaw lies the very social nature of ‘consensus’ on a blockchain.

Blockchainers use ‘consensus’ to refer to the process by which blocks are added to the blockchain. If two different miners validate the same block at the same exact time, and broadcast their blocks to the network, then at that moment there would be two competing versions of the blockchain at the same time. Bitcoin (and most proof of work currencies) resolve this by accepting whichever chain ends up growing longer, faster. This way of determining which chain is the ‘main’ chain is called the mechanism of ‘consensus,’ and it’s extremely important for bitcoin and other cryptocurrencies. If there were many different bitcoin blockchains floating around, and no one knew which one to use, the currency would be useless.

However, it’s important to understand that the mechanism of consensus, though codified in bitcoin clients, is simply a social norm enforced by those who use it. If I wanted to, I could code a bitcoin client that, instead of accepting the longest chain, did something different, like accepting the chain with the highest number of transactions or the chain in which the number ‘1’ appears most frequently. However, it would be pointless for me to do this if others all used a different mechanism of consensus, as no one would interact with my client.

The ”nothing at stake” problem is grounded in the fact that voting on a particular version of a proof of stake blockchain requires no resources and therefore has no opportunity cost. Unlike Proof of Work, where miners must choose which chain to point their mining power at, to the exclusion of other chains, miners can stake their coins on every version of a Proof of Stake blockchain that exists. Since there’s no opportunity cost to mining on a particular chain, the miners have ‘nothing at stake’. So rational miners should simply mine on every competing branch they see, so as to maximize the amount of mining returns they get.

Vitalik gives two ways of addressing the nothing at stake problem in his essay, ”On Stake”:

Introduce into the protocol a way to penalize those who ”equivocated” on a given block, i.e., voted on two different versions of it.

Introduce into the protocol a way to penalize those who voted on the wrong block, regardless of whether or not they double-voted.

Among the Proof of Stake currencies, each of them handles the ‘Nothing at Stake’ problem slightly differently:

CASPER handles this by introducing a ”wrong-voting penalty” to the protocol, which allows users to submit evidence of voting on the wrong chain by miners in order to penalize that miner for wrong-voting.

In Peercoin, the longer your coin is staked, the more likely you are to be able to mine the next block. Peercoin clients use the chain with the”most coin-age consumed”, i.e., the one in which the sum of the total number of coins staked for each block multiplied by the amount of time those coins were staked is highest.

NXT clients tackle this problem by not having any block-reward whatsoever, and simply let transaction-fees dictate the process. [Thanks to Petko Petkov for clearing that up for me!] In addition, NXT clients use something called “cumulative difficulty” to come to consensus on a chain.

Another interesting approach is one proposed by Daniel Larimer called ”Transactions as Proof of Stake”, in which the transactions themselves are used to build the blockchain, with the senders acting as the ”miners”. In this situation, there is no ”double-voting” problem, as an attacker is in fact incentivesed to have their transaction only be present on one chain. Of course, this approach does not scale well.

In my next post I’ll be talking about the other major flaw in Proof of Stake, it’s vulnerability to something called a ‘Long-Range Attack,’ which is a much more insidious version of this flaw, with no easy solutions.