Consensus Is More Than PoW or PoS

Knowing that a blockchain uses proof of work (PoW) or proof of stake (PoS) does not tell us enough about how it reaches agreement, or whether its guarantees fit an application.

In a 2021 thread, I raised a distinction that is still useful: preventing one person from gaining influence through many identities is a different problem from getting participants to agree on a result. The thread went on to discuss attack thresholds and the blockchain trilemma. These topics belong together because they invite the same mistake: letting a familiar label stand in for the mechanism behind it.

PoW and PoS are useful shorthand for families of blockchains. But when comparing security or deciding when an application can rely on a transaction, we need to unpack that shorthand. Ethereum's own developer documentation distinguishes Sybil resistance from a complete consensus protocol.^[1]

Does one person with ten thousand accounts get ten thousand votes?

Imagine an open network where every account gets one vote. An attacker does not need to persuade anyone. They can create more accounts. Each can have its own name and a perfectly functional signing key, while all remain under one person's control.

This is the basic Sybil problem. John Douceur's 2002 paper, The Sybil Attack, examines how an entity presenting multiple identities undermines assumptions about redundancy and trust in distributed systems.^[2]

Sybil resistance limits the influence gained by cheaply multiplying identities. It does not necessarily prevent new identities, and it does not establish that every account belongs to a different human.

PoW ties mining influence to computational work. Dividing the same computing resources among more names does not create more total computing power. PoS relates participation weight to stake committed under the protocol's rules. Renaming or splitting that stake should not create weight from nothing. Proposal selection, voting and penalties still depend on the particular protocol.^[1]

This also explains why a DID does not automatically solve Sybil resistance. A signature can establish authorization by a corresponding key; it does not establish that its controller has only one identity. An application offering one vote per person needs additional eligibility and uniqueness rules. Understanding DID and deciding who receives voting weight are connected questions, with different answers.

Even with participation weight settled, a network faces another problem. Two transactions might otherwise meet its requirements but spend the same funds. Some participants see one first; others see the other. Knowing who may vote has not yet told them how to resolve that disagreement.

Eligibility still needs a decision procedure

A protocol becomes easier to examine when we ask specific questions. These are responsibilities to distinguish, not a promise that the implementation consists of interchangeable modules.

Bitcoin provides a useful example. “The longest chain wins” is shorthand: nodes select the greatest cumulative-work chain among candidates that satisfy their validation rules. This is neither a simple count of blocks nor permission to accept invalid transactions because sufficient work accompanies them. PoW contributes both to proposal opportunities and to comparing competing histories. Those opportunities are weighted by computing power, not distributed equally among account names.^[3]

Fork choice alone is not the complete protocol either. Validity rules determine what can be considered; network and resource assumptions affect what confirmation means. A chain-selection slogan cannot provide those guarantees by itself.^[3]

Finality is an assurance that, under the protocol’s assumptions, a confirmed result will not be replaced by a conflicting history. Bitcoin confirmation instead generally reduces replacement risk as more work accumulates.

Ethereum offers another way to see the distinction. Gasper combines LMD-GHOST fork choice with Casper FFG finality. One helps select the current branch; the other establishes stronger confirmation for particular checkpoints (designated block positions). There is no need to memorize the names before grasping the point: “uses PoS” has not answered all these questions.^[4]

Two candidate branches are also different from two conflicting finalized results. A protocol can allow temporary disagreement while protecting against conflicting final decisions. Applications need to know which kind of assurance they are relying on.

Why 51% and two thirds are not security scores

These percentages are often presented as though they measured the same thing.

A Bitcoin majority-hashpower attack concerns influence over competing histories. It does not supply other users' private keys or make arbitrary invalid transactions acceptable to nodes enforcing unchanged validation rules. Minority hashpower does not eliminate reorganization risk: nodes can switch to another history, undoing previously accepted transactions.^[3]

Byzantine fault tolerance concerns agreement despite participants that may lie, send conflicting messages, or fail to respond. A requirement for two-thirds approval does not imply that everything remains safe until two thirds of participants are malicious.

Two goals must be separated. Safety means correct participants do not finalize conflicting outcomes. Liveness means the system continues processing under its stated conditions. Stopping confirmation and confirming contradictory histories are different failures.

For a small illustration, take four nodes maintaining the service and require three votes. Any two such voting groups overlap in at least two members. With at most one faulty member, that overlap contains an honest member. Protocol rules restricting honest support for conflicting decisions can therefore help exclude conflicting decisions. Requiring three votes is not permission to tolerate three malicious replicas. A group meeting the protocol’s voting requirement is called a quorum. This illustrates quorum intersection, not the entire PBFT proof.^[5]

Classic PBFT generalizes this to n = 3f + 1 replicas, or service nodes, tolerating at most f Byzantine faults with relevant quorums of 2f + 1. Progress also requires eventual timely communication; it is not guaranteed if messages remain blocked forever.^[5]

In a stake-weighted system, counts of machines must also be distinguished from voting weight. Ten thousand validator names need not represent ten thousand independent controllers.

In Ethereum's Gasper, preventing finalization and producing conflicting final outcomes require separate analysis. With a fixed validator set and voting weights, conflicting finalization exposes at least one third of voting weight violating rules for which stake can be taken away (slashing). This does not mean a one-third adversary can execute that attack under any network conditions.^[6]

Real protocols also handle changing weights. During a prolonged split, the inactivity leak gradually reduces the weight of validators that each branch sees as not participating. Ethereum's documentation discusses how both branches can eventually finalize in such a situation, requiring social recovery. Fixed-weight quorum reasoning cannot simply be extended to partitions of arbitrary duration.^[7]

Before comparing percentages, complete the sentence. What does the attacker control: computing power, stake, or admitted members? Are we discussing stalled progress, reorganization of unfinalized history, or violated finality? What delays does the network model allow, and how can the system recover?

If the answers differ, 66.67% > 51% proves nothing about which system is safer. For an application, the failure it might experience, the evidence left behind, and the people needed for recovery are more useful than an isolated percentage.

The trilemma needs its assumptions too

The same discipline applies to decentralization, security and scalability.

CAP is a result about a specified model. A network partition means some nodes cannot communicate. Its consistency requirement makes operations behave like access to a single ordered copy of data; availability requires requests to non-faulty nodes to receive responses eventually. Gilbert and Lynch examine why atomic consistency and a particular availability requirement cannot both be guaranteed under network partitions. These terms have precise meanings. CAP is not a universal template saying that every system may choose only two desirable qualities.^[8]

The blockchain trilemma uses different concepts. Even “decentralization” can refer to independent operators, the cost of verifying the system, or the distribution of decision-making authority. Changing that definition while retaining the same triangle can quietly change the comparison.

Sharding distributes work across different parts of a system instead of having every node repeat all the work. In his 2021 essay on sharding, Vitalik describes the trilemma in terms of simple techniques, then discusses how sharding seeks to change the constraint and what extra costs and assumptions it brings. The useful lesson is that architecture can change the design space, not that sharding is free of tradeoffs.^[9]

Nor does this establish that there are no theoretical limits, or that a newer chain has solved everything. Researchers can establish lower bounds and impossibility results within defined models. A proposed improvement needs to identify which assumptions it retains and which constraints it changes. An engineering shorthand and a theorem with a specified scope deserve different readings.

For ArcBlock, this distinction matters because we start from applications. An application needs more than the name of its underlying chain mechanism. What establishes identity and authority? When can it rely on a transaction? Where does a cross-chain operation settle? ArcBlock's chain and applications and DID and blockchain are useful next steps. Those design choices are not, by themselves, proof of universal security superiority.

“Earlier” and “newer” are labels too. Early adoption does not establish that every technical choice is optimal. A newer design does not establish that it is more suitable either. Examining actual guarantees lets us compare blockchains without asking readers to choose a camp from a handful of acronyms.

When reading a blockchain introduction, ask one more question: does this explain who may participate, or how participants decide on the same history? If it answers only the first, the explanation of consensus is not finished.

References