Understanding the Basics of a Proof-of-Stake Security Model

Devcon3 is fully underway, and despite the development-focused agenda at the conference, a majority of the audience is still befuddled during talks about consensus protocols. We took this as an opportunity to translate the technical jargon into plain English.

Consensus Basics

Standard Definitions

The ‘Consensus’ Problem

At the core of every distributed fault-tolerant system is the fundamental problem of ensuring that all remote processes within said systems arrive at the same conclusion. This is known as requiring ‘consensus’ among participants. In completely reliable, controlled environments where faulty processes are tightly monitored and swiftly corrected, reaching consensus is straightforward. Real world decentralized protocols, however, are subject to significantly more arbitrary failures, requiring much higher reliability guarantees in order to be useful, much less secure. As Ethan Buchman at Cosmos puts it, distributed consensus mechanisms must “make a reliable system from unreliable parts.”

The consensus protocol ensures that every transaction is replicated and recorded in all the machines in the network in the same order. The scheme for state replication in this context is implemented in the blockchain paradigm, where the blockchain is the resultant hash-linked “batched log” of transactions replicated deterministically across all processes in the network.

‘Safety’ & ‘Liveness’

Safety implies having a single agreed upon chain where there are not two or more competing chains with valid transactions in either. A consensus protocol can be ‘safe’ when blocks have settlement finality, or else probabilistic finality.

A consensus protocol is said to be ‘live’ if it is responsive, therefore available, to new transaction propagation, where valid transactions eventually make it onto the blockchain. A liveness fault occurs when transaction omission, information withholding, or message reordering, among a number of violations are observed. These are indistinguishable from simple network latency, which makes liveness faults difficult to detect.

‘Asynchronous’ Networks

In asynchronous networks, the arrival order of transactions is witnessed at varying times among nodes. Therefore, to ensure safety, concurrent processes in a consensus system must follow a set of protocol rules in order to agree upon the order in which messages were received. To do so requires that we make synchrony assumptions; we suggest some maximum threshold for the latency of network transactions and the speed of processor clocks.

Those assumptions make failures in asynchronous networks detectable with the use of ‘timeouts’, wherein a process is assumed to have crashed if it is unresponsive for a defined amount of time.

‘Cryptoeconomic’ Security Incentives

“Cryptographic primitives are…fundamentally related to the problem of trust, and may similarly be defined as mechanisms which allow for a massive reduction in entropy — successfully authenticating a cryptographic function collapses a distribution over possible outcomes to a single, or in some cases a small number, of outcomes….Most interestingly, economic mechanisms may also serve as means for reducing entropy, in so far as economic agents can be incentivized — which is to say be made more likely to execute a particular behaviour. In fact, Bitcoin’s great insight was that cryptographic primitives could be used in conjunction with economic incentives to sufficiently reduce the entropy of a public consensus network to achieve secure replication of state.”

— Ethan Buchman, Tendermint: Byzantine Fault Tolerance in the Age of Blockchains

Stake

Assuming those majority economic agents are not Byzantine (malicious or lying) but are rational rather, we can devise certain in-protocol incentives to modify decisions with determinism. The leveraging of ‘stake’ in Proof-of-Stake consensus provides stronger security guarantees than Proof-of-Work consensus due to the bonding of collateralized capital, or security deposits. Utilizing this is so key to modern, fault tolerant PoS design, that the major protocols like Tendermint and Casper adopt security deposits at the core of their incentive mechanisms.

This is because stake that is bonded by a node which exhibits faulty behavior can be forfeit, or ‘slashed’, by the protocol. The protocol can therefore define some strong disincentive, or maximal penalty for incorrect behavior which can potentially far outweigh any transaction fees or mining rewards defined for correct behavior.

‘Validators’ as Security

In Proof-of-Stake, the consensus nodes are known as validators, whereas in Proof-of-Work, they are known as miners. The term ‘bonded validator’, or ‘validator’ for short, was first introduced by Jae Kwon in his pivotal white paper, Tendermint: Consensus without Mining. Each validator’s voting power, or weight, amounts to the proportion of stake that’s self-funded or allotted to them. All three of the aforementioned consensus protocols employ dynamic validator sets.

In many systems, not all validators will have the same “weight” in the consensus protocol. Thus, we are not so much interested in ⅓ or ⅔ of the validators, but in those proportions of the total voting power, which may not be uniformly distributed across individual validators. So when you hear “⅔ or more” validators, what you’re really hearing can be translated as “⅔ or more” of the deposit-weighted percentage of the total deposit size of all validators in a set.

Hope this was helpful.

With love,

Your Fellow Cosmonauts + Devcorn