In this track: Ethereum protocol concepts
advanced · 4 MIN READ

Weak subjectivity explained

A long-offline proof-of-stake node needs an appropriately trusted recent checkpoint.

LET’S PICTURE IT

A returning record keeper needs a reliable recent reference before deciding which long history to follow.

SEE IT FOR YOURSELF
Link blocks, then see what an edit breaksStep 1 / 4
Link blocks, then see what an edit breaksBLOCK 1Maya → Leo: 3Fingerprint A1A classroom model, not a live blockchainBLOCK 1Fingerprint A1BLOCK 2Parent A1Fingerprint B2The direction shows a relationship, not a transfer of ownershipBLOCK 1Hash A1BLOCK 2Parent A1Hash B2BLOCK 3Parent B2Hash C3Independent validation and consensus are additional requirementsEDITED BLOCK 1Maya → Leo: 9Hash X9BLOCK 2Parent A1 ≠ X9Invalid parentBLOCK 3Ancestor link invalidRevalidation neededRecalculating toy hashes does not rewrite Ethereum consensus

The first toy block records Maya sending Leo three units. A1 is an illustrative fingerprint label, not a real cryptographic digest.

Animated local teaching model. No wallet, RPC or live blockchain data. Some labels and hashes are abbreviated for readability.

Separate new and continuously online views

A node tracking consensus continuously has context that a new or long-offline node lacks. Historical signatures alone may not resolve every long-range ambiguity.

Understand the checkpoint role

Weak subjectivity uses a sufficiently recent trusted checkpoint to anchor synchronization under the relevant security assumptions. It is not a replacement for validating later rules.

Review the trust source

The node must obtain an appropriate checkpoint through a reliable process. An arbitrary value supplied by an untrusted peer is not automatically sufficient.

Avoid confusing it with ordinary finality

Finality describes agreement under consensus assumptions. Weak subjectivity addresses how a node anchors its view after lacking recent consensus context.

Map the protocol concept

trusted recent checkpoint
→ anchor synchronization
→ validate subsequent consensus and execution

Document the checkpoint acquisition process.

A conceptual model. Exact fields, limits and processing rules must be checked against the intended network fork.

QUICK CHECK · NO PRESSURE

Should a new node blindly trust any peer’s checkpoint?

Your progress stays in this browser.
Keep exploring the original referenceethereum.org ↗

Original explanations by EtherTools. Examples are educational and source-linked; this site is independent of the Ethereum Foundation. Our approach.