~$ crypto-under-the-hood

# The machinery behind the coins

~/notes / consensus and blocks

Checkpoints and Weak Subjectivity

A new proof-of-stake node cannot determine the correct chain from the protocol alone. What it needs instead and why that is acceptable.

Ivan Kruse · · 2 min

A proof-of-work node syncing from scratch can identify the correct chain by finding the one with the most accumulated work. A proof-of-stake node cannot do the equivalent, and the reason is worth understanding.

The problem

In proof of stake, validators who have withdrawn their stake no longer have anything at risk. They could, in principle, use their old keys to sign an alternative history.

A node syncing from genesis with no other information cannot distinguish that alternative from the real chain, because both are internally consistent and neither required expending an external resource.

The solution

A syncing node is given a recent checkpoint: a block hash it treats as definitely part of the canonical chain.

From that point, the protocol’s rules determine everything. The checkpoint anchors the node to the correct history.

This is called weak subjectivity because it requires one piece of information from outside the protocol.

Where the checkpoint comes from

Client software ships with recent checkpoints. Community sources publish them. Block explorers and infrastructure providers offer them.

The node operator obtains one from a source they trust, which is an explicit trust assumption and a narrow one.

Why it is acceptable

The window is long. Weak subjectivity has a period, typically weeks or months, within which a node with any recent checkpoint is safe. Only a node that has been offline longer than that needs a fresh one.

The checkpoint is verifiable against multiple sources. Comparing several independent publishers makes a fabricated checkpoint easy to detect.

Proof of work has an analogous requirement in practice. A new node syncing a proof-of-work chain also obtains the software, and the software encodes assumptions. The difference is one of degree rather than kind, though the degree is real.

What this means for an operator

When setting up a node, obtain a checkpoint from a source you trust and, ideally, verify it against a second.

A node that has been offline beyond the weak subjectivity period should be resynced with a fresh checkpoint rather than allowed to sync from its stale state.

The honest framing

This is a genuine difference between the two consensus families, and it is frequently either overstated by proof-of-work advocates or dismissed by proof-of-stake ones.

The accurate version: proof of stake requires one externally supplied reference point for a node syncing from far behind, verifiable against multiple sources, within a long window. That is a real assumption and a small one.

For anyone not running a node, it is invisible, which is true of most of what makes these systems work.

# Corrections and technical nitpicks are welcome. Send them over. They get published with the fix.

consensussynctrust

# related notes