Understanding Distributed Consensus: PBFT, PoW, and PoS Algorithms
This article explains the challenges of distributed consistency in decentralized environments and provides an in‑depth overview of classic consensus algorithms such as PBFT, Proof‑of‑Work, and Proof‑of‑Stake, including their mechanisms, limitations, and suitable application scenarios.
Distributed consistency is a long‑standing problem that seeks to guarantee that data across multiple nodes remains identical, especially in decentralized settings where nodes are equal but potentially untrustworthy. Traditional protocols like Paxos and Raft work well in homogeneous, centrally‑controlled networks, but they break down when the network spans the entire Internet.
The article identifies two main categories of faults: Crash Faults, where nodes may crash, lose power, or experience network partitions, and Byzantine Faults, where malicious actors can send conflicting or forged messages, making consensus far more challenging.
To address Byzantine faults, the Practical Byzantine Fault Tolerance (PBFT) algorithm is introduced. PBFT operates in a series of views, each with a designated primary (leader) node selected as primary = view_number mod total_nodes . The protocol consists of four phases—Request, Pre‑Prepare, Prepare, Commit, and Reply—each requiring cryptographic signatures, hash verification, and quorum thresholds (typically 2n/3 + 1) to progress.
Key data structures used in PBFT are defined as follows:
type Request struct {
Data []byte // message content
Hash []byte // message digest
Sign []byte // signature
PubKey []byte // public key, used to derive client address
}
type PrePrepare struct {
SortedReqs []Request // ordered client requests
Hash []byte // digest of this message
Sign []byte // signature
PubKey []byte // public key
V int64 // view number (or block height)
}
type Prepare struct {
PrePrepare PrePrepare // the pre‑prepare message
Hash []byte // digest
Sign []byte // signature
PubKey []byte // public key
}
type Commit struct {
PrePrepareHash []byte // hash of the pre‑prepare message
Hash []byte // digest
Sign []byte // signature
PubKey []byte // public key
}PBFT’s limitations include quadratic message complexity (O(n²)), the need for all nodes to be fully connected, and sensitivity to view‑change timeouts; it also requires a permissioned network where participants are vetted, making it unsuitable for fully open public blockchains.
The article then contrasts PBFT with Proof‑of‑Work (PoW), the consensus mechanism used by Bitcoin. PoW relies on computational puzzles where miners repeatedly hash a block header until sha256(BlockHeader) < target . The difficulty adjusts dynamically to maintain a stable block interval, and the longest‑chain rule resolves forks.
PoW’s drawbacks are high energy consumption, low throughput, and the tendency toward centralization as specialized mining hardware dominates.
Proof‑of‑Stake (PoS) is presented as an alternative that selects block proposers probabilistically based on the amount of stake they lock up. To prevent predictability attacks, Verifiable Random Functions (VRF) are introduced, allowing nodes to prove they were randomly chosen without revealing the selection in advance.
Finally, the article discusses the “blockchain trilemma” – the impossibility of simultaneously achieving full decentralization, high performance, and strong security – and notes that each consensus algorithm makes different trade‑offs within this space.
ByteDance Dali Intelligent Technology Team
Technical practice sharing from the ByteDance Dali Intelligent Technology Team
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.