asopi tech
asopi techIndie Developer
Consensus Algorithms, Underground (Part 4) — A World Where Identities Cannot Be Counted: PoW and PoS

[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 weight

Each 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 += 1

Because 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.confirmations

As 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 >= beta

Local 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 failed

It 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

ProblemSuitable approach
Three to seven trusted serversRaft / Multi-Paxos
Distributed KV, distributed SQLMulti-Raft
Geo-distributed writes originating in many placesEPaxos / WAN-optimized Paxos
Byzantine tolerance with few permissioned validatorsPBFT / Tendermint / HotStuff
Large-scale BFT with high throughputNarwhal + Bullshark family
Lower steady-state latency in BFTMysticeti / Shoal family
Public network with unrestricted participantsPoW / PoS-BFT
Repeated sampling over a large validator setAvalanche / Snowman
Commutative operations with no need for a strict total orderCRDTs
Failure detection and membership disseminationSWIM / 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 operations

The 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 = sampling

Beneath 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 incentives

The 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.