
[July 2026 edition]
Consensus Algorithms, Underground (Part 4) — A World Where Identities Cannot Be Counted: PoW and PoS
Published: Jul 22, 2026
Reading time: ~8 min
Everything so far assumed a known set of participants. Majorities and 2f+1 can be counted precisely because the validators are known. This final part removes that assumption.
A World Where One Node One Vote Does Not Work
In a permissionless network where neither the identity nor the number of participants is known, one node one vote does not hold, because an attacker can create nodes without limit.
Nakamoto Consensus solved this by binding voting power to computational resources.
one CPU / hash power ≈ voting weightEach miner searches for a nonce that yields a block hash satisfying the difficulty condition.
import hashlib
def mine(header: bytes, difficulty_prefix: bytes):
nonce = 0
while True:
digest = hashlib.sha256(
header + nonce.to_bytes(8, "big")
).digest()
if digest.startswith(difficulty_prefix):
return nonce, digest
nonce += 1Because identities cannot be counted, something measurable is counted instead: the computation consumed. That substitution is the core of the design.
Probabilistic Finality
In Raft and PBFT, a committed value is not reversed by the rules. In Nakamoto Consensus the chain with the greatest cumulative work is selected, so recent blocks may be reorganized.
canonical = max(candidate_chains, key=lambda c: c.total_work)The probability of reversal falls as confirmations accumulate, but never reaches zero. The difference between deterministic and probabilistic finality propagates directly into application design. The operational judgment of how many confirmations constitute a settled deposit exists because of this property.
PoW is not merely a block production method. It integrates Sybil resistance, the leader lottery, fork choice, the cost of rewriting history, and history verification by new participants into a single economic mechanism. The costs are energy consumption, low throughput, probabilistic finality, and concentration of mining capital.
Proof of Stake: Not Impossible, Merely Unprofitable
PoS uses stake as voting power in place of computation. Ethereum migrated from PoW to PoS in 2022. Official material cites reduced energy consumption and compatibility with subsequent scaling work as reasons for the transition.
Selecting a leader in proportion to balance is, however, insufficient on its own. Double voting, long-range attacks, nothing-at-stake, stake concentration, validator exit, weak subjectivity, censorship, MEV, and clock and slot synchronization are all attendant problems.
At the center is slashing: an economic penalty imposed on a validator that signs contradictory histories.
def slashable(vote_a, vote_b):
same_validator = vote_a.validator == vote_b.validator
double_vote = (
vote_a.target_epoch == vote_b.target_epoch
and vote_a.target_hash != vote_b.target_hash
)
surround_vote = (
vote_a.source_epoch < vote_b.source_epoch
and vote_b.target_epoch < vote_a.target_epoch
)
return same_validator and (double_vote or surround_vote)PoS-BFT uses economic safety in addition to cryptographic safety. Double signing is not made technically impossible; it remains possible, but the evidence persists and the stake is lost. Where the algorithms through Part 3 constructed safety from impossibility, this constructs it from loss.
Solana: A Clock and a Lockout
In Solana, Proof of History provides a verifiable ordering of time, and Tower BFT performs stake-weighted voting on top of it. Ethereum and Solana both use PoS, but the composition of block production and consensus differs.
Proof of History is not consensus itself; it is a cryptographic clock that lets validators handle a common ordering of time efficiently. Rather than agreeing on order after the fact, it generates evidence of order in advance.
In Tower BFT, the lockout period extends the longer a validator keeps voting for the same fork.
class TowerVote:
def __init__(self, slot):
self.slot = slot
self.confirmations = 1
@property
def lockout(self):
return 2 ** self.confirmationsAs votes accumulate, the waiting cost of reversing past votes grows exponentially. Rather than finalizing a decision in one step, the design accumulates the cost of reversing it.
Avalanche / Snowman: Not Asking Everyone
Instead of collecting a large explicit quorum from all validators at once, the Avalanche family repeatedly queries a small randomly chosen subset.
def poll(sample, preference):
votes = [peer.query() for peer in sample]
winner, count = most_common(votes)
if count >= alpha:
if winner == preference:
confidence += 1
else:
preference = winner
confidence = 1
else:
confidence = 0
return confidence >= betaLocal majority preference is amplified network-wide through repeated sampling. The aim is to reduce the all-to-all communication and fixed-leader dependence of classical BFT and converge preferences quickly even with a large validator set.
Snowman applies the original Avalanche DAG to a linear chain suited to smart contracts. Avalanche’s Primary Network uses Snowman, targeting low block latency and high throughput.
What must be noted is that this is not simply a matter of querying a few peers and taking a majority. Weighted sampling, metastability, confidence thresholds, adversarial sampling, network churn, and handling of conflicting transactions must be analyzed as one system.
The Option of Not Agreeing at All
Finally, this section separates the mechanisms that are frequently confused with consensus but are of a different kind. In design work this distinction is usually the one with the largest effect.
CRDTs
A CRDT is a data type that converges to the same state as long as all updates are exchanged, without agreeing on the same operation order.
class GCounter:
def __init__(self, node_id):
self.node_id = node_id
self.counts = {}
def increment(self):
self.counts[self.node_id] = self.counts.get(self.node_id, 0) + 1
def merge(self, other):
for node, value in other.counts.items():
self.counts[node] = max(self.counts.get(node, 0), value)
def value(self):
return sum(self.counts.values())This is not fast agreement on operation order. It avoids the problem that required consensus by reshaping it into a commutative data structure. Counters, sets, collaborative editing, and observational data are typical targets.
Invariants such as decrementing inventory exactly once, preventing a withdrawal beyond the account balance, or electing a single leader cannot be handled this way as-is. Getting this wrong produces a system that converges but does not satisfy the business requirement.
Gossip
Gossip is a dissemination mechanism.
def gossip(node, peers):
peer = random.choice(peers)
delta = node.state.diff(peer.version)
peer.merge(delta)It propagates state to all nodes efficiently, but it does not decide on a single correct value.
SWIM
SWIM is a failure detection and membership dissemination mechanism.
PING B
↓ no response
PING-REQ B through C, D
↓ no response
mark B suspected
↓ timeout
mark B failedIt estimates whether a node is part of the cluster; it is not consensus that determines transaction order. As Part 1 established, crashes and delays cannot be distinguished, so what SWIM returns is an estimate.
What to Choose
| Problem | Suitable approach |
|---|---|
| Three to seven trusted servers | Raft / Multi-Paxos |
| Distributed KV, distributed SQL | Multi-Raft |
| Geo-distributed writes originating in many places | EPaxos / WAN-optimized Paxos |
| Byzantine tolerance with few permissioned validators | PBFT / Tendermint / HotStuff |
| Large-scale BFT with high throughput | Narwhal + Bullshark family |
| Lower steady-state latency in BFT | Mysticeti / Shoal family |
| Public network with unrestricted participants | PoW / PoS-BFT |
| Repeated sampling over a large validator set | Avalanche / Snowman |
| Commutative operations with no need for a strict total order | CRDTs |
| Failure detection and membership dissemination | SWIM / Gossip |
The selection criterion is not novelty. What must be checked is the following.
failure model how much failure is assumed
network model synchronous, partially synchronous, or asynchronous
membership model fixed, dynamic, or unrestricted participants
finality requirement deterministic, or is probabilistic sufficient
write locality where writes originate
conflict rate how much operations conflict with each other
validator count how far the node count will grow
trust model whether nodes that lie are assumed
storage durability how far the disk is trusted
operational complexity how many people can be assigned to operationsThe last item is not an incidental condition. As Part 2 established, most of a production Raft implementation lives outside the papers, and whether it can be maintained is the practical constraint on selection.
What Is Happening Underground
On the surface, consensus algorithms look like variations in voting.
Raft = majority
PBFT = two thirds
PoS = stake-weighted voting
Avalanche = samplingBeneath that surface, however, the problem being handled differs in each case.
Raft handles the crash and restart of trusted nodes. PBFT handles signed falsehood and contradiction. Nakamoto Consensus handles an environment where participant identities cannot be counted. DAG-BFT handles a bandwidth problem in which data dissemination saturates before ordering does. CRDTs do not accelerate agreement; they reshape the problem into one that does not require agreement.
The largest change is that consensus is no longer a single mechanism.
identity / Sybil resistance
data availability
transaction dissemination
ordering
finality
execution
storage durability
economic incentivesThe direction of travel is to separate these and combine different mechanisms. Narwhal separated dissemination from ordering. HotStuff compressed votes into QCs. Mysticeti removed certificate formation from the normal path. Multi-Raft subdivided the unit of agreement. CRDTs removed order agreement entirely from a subset of problems.
The question for future consensus design is therefore not only which algorithm to adopt. More precisely, it is at which boundary of the system, about what, and under which failure model agreement is required.
Consensus is not the engine that drives an entire system. It is the locking mechanism in the substrate that protects only the minimum necessary invariants.
Summary
- One node one vote does not hold in permissionless settings. PoW counts consumed computation, which is measurable, in place of identities, which are not.
- PoW finality is probabilistic. The operational judgment of how many confirmations constitute finality inevitably surfaces in the layers above.
- PoS safety is constructed from loss rather than impossibility. Its center is slashing and the structure that preserves the evidence.
- Solana generates evidence of order in advance (PoH), and Tower BFT accumulates the cost of reversal exponentially. Avalanche does not query everyone, converging preferences through repeated sampling.
- CRDTs, Gossip, and SWIM are not consensus. CRDTs in particular are not a means of accelerating agreement but of reshaping the problem so agreement is unnecessary.
- The question is not which algorithm to adopt, but at which boundary of the system, about what, and under which failure model agreement is required.