On Stake and Consensus

In 2009, Satoshi Nakamoto introduced the Bitcoin cryptocurrency[Nak09], an online currency system which allowed peer-to-peer transfer of digital tokens. To ensure a consistent view of token ownership, Nakamoto used a public ledger which can be replicated and validated by all network participants. To avoid a single point of failure, this ledger is authenticated using a dynamic membership multiparty signature (DMMS)[BCD+14] consisting of an expensive (but cheaply verifiable) computation done on the entire ledger history every “heartbeat”. Unlike a traditional digital signature, there is no notion of “forgeability” for a DMMS. Instead, every DMMS is costly to produce (in Bitcoin, by requiring a large energy expenditure) and rewarded by introduction of new coins on the ledger. Since these coins are only useful if others recognize them, participants are incentivized to extend one “true ledger” rather than attempting to create their own version of history1. Because Bitcoin’s DMMS is computationally, and therefore thermodynamically[Poe14a], very expensive, alternatives have been proposed which seek to be economically and environmentally more efficient. One popular alternative, proof-of-stake, is frequently proposed as a mechanism for a cheap distributed consensus. As argued by the author[Poe14b] in 2014, this is simply not workable, but nonetheless the idea continues to arise in various forms. Meanwhile, the author’s argument is commonly asserted on various forums to be “debunked” or “wrong”, despite the author having never been made aware of any workable counterexamples or mistakes. This, combined with (correct) accusations that the paper is obtuse and unreadable, demonstrate that its exposition leaves much to be desired. Although this author is not aware of any inaccuracies in his former work, he has taken the opportunity to continue and elaborate his argument more formally. Further, there has been significant progress in scientific understanding of Bitcoin’s consensus[MLJ14, BMC+15] which was not available when the original paper was written. This paper aims to be an updated version of the author’s original paper, which gives more explication on the problem Bitcoin solves, why it makes the design decisions that it does, and why 1To ensure that the “true ledger” is visible to all participants, we require a synchronous network such that all (valid) data reaches all participants in some characteristic time λ , and that the network heartbeat time is much larger than λ . Without a synchronous network, distributed consensus is much harder. (There is an oft-cited impossibility result for distributed consensus using deterministic algorithms [FLP85]; this is easy to evade simply by using probabilistic algorithms, and therefore doesn’t say much about the difficulty of designing consensus systems. Thanks to Dominic Williams for pointing this out; an earlier version of this document erroneously quoted this result as blocking any distributed consensus in an asynchronous network.)