Consensus systems combine rules for valid blocks, a rule for choosing between conflicting histories, and resistance to fake identities. Compare Profiles record the scarce resource that limits participation with these values. Reputation: the right to take part comes from admission to a known set of validators or signers, or from being on other participants' trust lists; admission, not a spent or bonded resource, is what limits participation. Stake: participation depends on the native asset bonded for consensus, and the bonded amount decides which validators take part. Work: block producers expend computation on hash puzzles, and a producer's chance of adding a block follows its share of that computation. Designs that rely on another resource, or on a combination, are recorded as other, with the chain's own term in its profile. The resource choice does not by itself determine a chain's application model.
Key idea. Compare the scarce resource, who proposes blocks, how competing histories are resolved, and the consequences of a fault.
Example
To compare two designs, answer the same questions for each from its own documentation: what is scarce, who proposes blocks, which history nodes follow when two conflict, and what a fault costs. A design recorded as other is compared on the same questions in its own terms.
Keep in mind
- Proof of stake is a family of designs.
- No consensus label alone proves decentralization, low cost, or superior security.
Sources
- Bitcoin whitepaper (external site)
- Ethereum proof of stake (external site)
- XRP Ledger documentation: Unique Node List (UNL) (external site)