Understanding Blockchain Consensus: POW, POS, DPOS, PBFT, Paxos & Raft Explained

On October 31, 2008 Satoshi Nakamoto released the Bitcoin whitepaper; on January 4, 2009 the Bitcoin genesis block was created. Blockchain technology emerged as a hot cutting‑edge field, evolving through various foundational platforms.

Blockchain is essentially a specialized distributed database. The main differences among blockchain platforms lie in the optimization and transformation of consensus algorithms. Traditional distributed databases use Crash Fault Tolerance (CFT) consensus assuming non‑malicious nodes, while most blockchains adopt Byzantine Fault Tolerance (BFT) consensus to achieve agreement among potentially untrusted nodes.

BFT (Byzantine Fault Tolerance)

BFT, or Byzantine Fault Tolerance, originates from the Byzantine Generals Problem and addresses unpredictable behavior caused by hardware errors, network issues, or malicious attacks. Blockchain networks match this model, containing normal, faulty, and adversarial nodes, and the consensus algorithm’s core is to form agreement among the normal nodes.

POW (Proof of Work)

POW, also known as mining, requires nodes to compete with hardware resources for the right to record blocks. Bitcoin and Ethereum are the most well‑known public chains that originally used POW; Ethereum later introduced improvements.

a) POW in Bitcoin

1) Generate the coinbase transaction and combine it with other pending transactions to form a transaction list, then compute the Merkle root hash. 2) Assemble the Merkle root and other fields into the block header; the 80‑byte block header serves as the input for the POW. 3) Continuously vary the nonce in the block header and perform double SHA‑256 hashing, comparing the result with the network target. When the hash is below the target, the POW is successful.

b) POW in Ethereum (Ethash)

With the advent of ASIC miners, ordinary PCs can no longer mine Bitcoin efficiently. Ethereum redesigned the POW algorithm as Ethash, which demands high memory size and bandwidth while keeping computational requirements low. Ethash generates a large memory‑intensive DAG that changes every 30,000 blocks, limiting the advantage of high‑hash‑rate hardware.

1) For each block, compute a seed that depends only on the current block information. 2) Use the seed to generate a pseudo‑random cache; light clients store the cache. 3) From the cache, generate a 1 GB DAG dataset; full mining clients store the DAG. 4) Mining consists of selecting random DAG elements and brute‑forcing a nonce so that the hash meets the difficulty target (i.e., a certain number of leading zeros). Verification recomputes the DAG element from the cache and checks the hash.

POS and DPOS

a) POS

Proof of Stake (POS) replaces the energy‑intensive POW by granting block‑production rights to holders of more tokens; the larger the stake, the higher the probability of being selected.

1) Assign block‑production work to token‑rich participants; the more tokens owned, the higher the chance of obtaining the right. 2) Block producers receive token rewards, analogous to interest on holdings. 3) Attacking the network would devalue the attacker’s own tokens, discouraging malicious behavior. 4) Block creation only requires proof of ownership, not computational power, saving energy.

POS reduces resource consumption but introduces issues such as the “nothing‑at‑stake” problem and potential centralization due to wealth accumulation.

b) DPOS

Delegated Proof of Stake (DPOS) lets token holders vote for a limited number of super‑nodes that produce blocks. If a super‑node fails to produce a block, it is replaced by a new elected node.

1) Token holders vote for candidate miners; votes are included in transactions. 2) The top 21 candidates become representatives for the next period. 3) Representatives produce blocks in a fixed time slot (e.g., every 3 seconds). 4) Each representative must extend the longest valid chain; they cannot produce blocks on forks.

PBFT

Practical Byzantine Fault Tolerance (PBFT) was proposed by Miguel Castro and Barbara Liskov in 1999 to improve the efficiency of classic BFT. It is widely used in permissioned blockchains such as Hyperledger Fabric.

1) Client sends a request to the primary node. 2) Primary broadcasts the request to all replicas, initiating the three‑phase PBFT consensus. 3) Pre‑prepare: Leader validates the request, assigns a sequence number, and broadcasts a pre‑prepare message. 4) Prepare: Replicas verify the request and sequence number, then broadcast prepare messages to achieve global ordering. 5) Commit: After receiving 2f+1 prepare messages, replicas broadcast commit messages, confirming the order. 6) Execution: After receiving 2f+1 commit messages, replicas execute the request and reply to the client. 7) The client considers the operation successful after receiving matching replies from f+1 replicas.

CFT and Paxos

Crash Fault Tolerance (CFT) addresses consensus when nodes may fail but are not malicious. The classic Paxos problem models such scenarios, and its main algorithms include Paxos and Raft, both providing strong consistency.

Paxos

Paxos follows a two‑phase commit style: proposers compete for proposal rights, and once a majority of acceptors agree, the proposal is chosen.

1) Proposer generates a unique proposal ID (e.g., timestamp + server ID). 2) Proposer broadcasts a Prepare(n) request to all acceptors. 3) Acceptors compare n with their current minProposal; if n is larger, they update minProposal and return any previously accepted proposal/value. 4) After receiving a majority of responses, the proposer selects the highest accepted value (if any) or chooses a new value. 5) Proposer broadcasts Accept(n, value) to all nodes. 6) Acceptors accept if n ≥ minProposal, persisting the proposal and value. 7) Once a majority have accepted, the value is chosen and the consensus is reached.

Raft

Raft, introduced by Ongaro in 2014, simplifies consensus by decomposing it into leader election, log replication, safety, log compaction, and membership changes. A leader receives client commands, replicates the log to followers, and once a majority acknowledge, the entry is committed.

Nodes can be in one of three states: leader, follower, or candidate. Followers become candidates to start an election; if a candidate receives votes from a majority, it becomes leader. Leaders maintain authority by periodically sending heartbeat messages; followers that miss heartbeats become candidates.

From Paxos and Raft to PBFT, from POW to POS and beyond, consensus algorithms continuously evolve to meet the growing complexity of distributed ledger environments, ranging from permissioned consortium chains to open public networks.