PoS Long-Range Attacks and Weak Subjectivity: Why New Nodes Need Recent Checkpoints

Abstract: PoS long-range attacks target the new node's view

A proof-of-stake long-range attack is not the same problem as a short reorg near the head of the chain. The dangerous case is historical: validators exit, withdraw, and eventually no longer have current slashable capital behind the keys they once used. If a new node starts from genesis and tries to select a chain using only objective historical rules, it may be unable to distinguish the socially accepted current chain from a ghost history signed by old keys. Weak subjectivity is therefore not a temporary workaround. It is part of the security model. A node needs a recent checkpoint from a credible source, then it can verify forward using signatures, finality rules, and fork choice. This article analyzes asymmetric long-range attacks through Casper FFG, Gasper, LMD-GHOST, validator churn, weak-subjectivity periods, VDFs, and forward-secure signatures. The AllSwap relevance is direct: cross-chain routes and bridge verifiers should treat finality as a time-anchored claim, not a context-free word.

Scope: defensive synchronization, not chain forgery

This article is a defensive protocol analysis. It does not provide private-key collection methods, ghost-chain construction procedures, node-deception tactics, or target-selection logic. The roles are current validators, exited validators, newly syncing nodes, checkpoint providers, light clients, bridges, cross-chain routers, and users. The adversary is modeled as someone who may obtain old signing keys from historical validators, construct a historical fork, and present a complete but stale chain history to a node that lacks a recent checkpoint. The adversary is not assumed to control the current validator majority, forge BLS signatures, compromise all checkpoint sources, or bypass client implementation rules.

Short reorgs and long-range attacks have different economics. A short-range attack happens while current validators remain accountable. Casper FFG slashing conditions can punish double votes and surround votes. A long-range attack moves to a different time scale. Validators have exited; withdrawals may be complete; and old signing keys may no longer correspond to current slashable capital. The target is also different. A short-range attack affects online nodes and the head fork choice. A long-range attack mainly affects new nodes, nodes offline longer than the weak-subjectivity window, light clients, and cross-chain verifiers.

This is what "weak subjectivity" means. A PoS chain is not fully subjective and not fully objective. Nodes still verify cryptographic signatures, finality, state transitions, and fork choice. But they need a recent checkpoint from the real world. Once that checkpoint is inside the weak-subjectivity period, the node does not need to trust every later proposer. It can verify forward.

Weak-subjectivity period model

Divide time into three points:

```text t0: checkpoint time t1: the node starts syncing t2: current head ```

If `t1 - t0` is smaller than the weak-subjectivity period, the node can start from the checkpoint at `t0` and verify forward to `t2`. Security is backed by validators that are current or recent enough to remain accountable. If `t1 - t0` is too large, many validators may have exited, and old keys may no longer carry meaningful economic risk. At that point, a conflicting history can be signed by historical keys without forcing the attacker to defeat the current chain.

Let `S_active(t)` be the active validator weight at time `t`, and let `S_exited(t0, t1)` be the validator weight that exited between `t0` and `t1` and is no longer effectively slashable. If the checkpoint is too old, `S_exited` may be large enough to give a stale fork convincing historical weight. The safety boundary is that the checkpoint must be recent enough that any conflicting history still needs accountable, slashable, or socially identifiable current weight.

Ethereum's weak-subjectivity calculations and validator exit limits have the same high-level purpose: bound the speed at which the validator set can change. Exits cannot replace the entire set instantly. After a recent checkpoint, the validator set cannot become unrelated in a short period. A node can therefore use Casper FFG finality and LMD-GHOST fork choice to verify forward, instead of treating all histories since genesis as live candidates.

This should not be read as "PoS is insecure." Proof-of-work also has external assumptions: a new node must find the real network, run legitimate client software, and avoid being isolated with a false view of work history. PoS makes a specific assumption explicit: a new node needs a recent checkpoint. Explicit assumptions are easier to engineer into client defaults, checkpoint sync, social recovery, and bridge verification.

Why the attack is asymmetric

The asymmetry is a cost curve. The honest chain advances in real time. Current validators must lock capital, stay online, and accept slashing risk. If an attacker obtains historical keys, a stale fork can be produced off-chain without recreating the same economic commitment. The attacker does not need to beat current validators in real-time block production. The attacker needs only to convince a node without a fresh anchor that a historical chain is valid.

This is why comparing chain length, block count, or historical vote weight is insufficient. PoS security comes from a binding between signing weight and slashable capital over time. Once the signing key belongs to an exited validator, a signature may remain cryptographically valid but economically stale. Cryptography proves that a key signed a message. It does not prove that the signer currently bears economic risk for that message.

Casper FFG constrains conflicting checkpoint votes by slashable validators. Gasper combines FFG finality with LMD-GHOST fork choice to provide safety and liveness for online nodes. But these rules assume the node's view is recent enough. If a node is offline longer than the weak-subjectivity period, it needs a human or client-trusted checkpoint channel before resuming.

A practical synchronization flow should look like:

```text obtain_recent_checkpoint() verify_checkpoint_from_multiple_sources() sync_headers_and_states_forward() apply_fork_choice_and_finality_rules() reject_histories_conflicting_before_checkpoint() ```

The final line is the important one. A weak-subjectivity checkpoint is not a cache optimization. It is a security boundary. The node should not reopen fork-choice competition before that checkpoint. Otherwise, old histories re-enter the candidate set.

VDFs and forward-secure signatures

Verifiable delay functions are often proposed as a way to attach physical time to history. If every historical segment must include sequential VDF output, an attacker with old validator keys cannot instantly generate years of valid-looking history. The value of a VDF is that it converts historical generation from parallel signing into sequential elapsed time. But VDFs introduce hardware fairness, parameter selection, verification cost, latency tolerance, and protocol-integration questions. They are not a direct replacement for weak subjectivity. They are a possible way to make long-history forgery more expensive.

Forward-secure signatures address a different part of the problem. If a validator's signing key evolves one way across epochs and old key material is destroyed, a key leaked in the future cannot sign messages for the past. In theory, this reduces the market value of old validator keys. In practice, blockchain validator operations require recoverable, auditable, and hardware-compatible key management. If key evolution fails, the validator may be unable to sign or unable to prove that a signing fault was accidental. Current PoS systems also benefit from BLS aggregation, so replacing or wrapping BLS with forward-secure behavior requires careful work on aggregation, verification, client compatibility, and hardware wallet support.

The realistic answer is layered defense. Weak-subjectivity checkpoints are the base. VDFs or time proofs may raise the cost of long-history generation. Forward-secure signatures may reduce the value of old keys. Clients, bridges, and routers must still reject stale checkpoints. No single mechanism makes PoS a system that can be safely bootstrapped from genesis with no external assumptions.

Engineering checkpoint distribution

Weak-subjectivity checkpoint security depends on two operational questions: who provides the checkpoint, and how the client decides it is recent enough. The weakest implementation is a single RPC endpoint returning a checkpoint root that the client accepts. A more robust implementation cross-checks client releases, independent RPCs, block explorers, foundation announcements, community-signed checkpoint lists, and locally known peers. A checkpoint is not private data and not a central control switch. It should be public, reproducible, cacheable, and auditable.

A checkpoint object should not contain only a block root. A useful object includes:

```text checkpointRoot, slot, epoch, finalizedRoot, validatorSetDigest, source, signature, observedAt ```

`checkpointRoot` is the sync anchor. `slot` and `epoch` let the client compute age. `finalizedRoot` places the anchor at a finality boundary. `validatorSetDigest` helps light clients understand which weight set is being verified. `source` and `signature` support auditability. `observedAt` prevents an old local cache from masquerading as fresh data. Without these fields, a user interface can say "synced" while hiding the safety context.

Checkpoint distribution also needs a conflict state. If sources disagree, the client should not automatically pick the history with higher apparent weight. The disagreement is itself a safety event. A better state is `checkpointConflict`: pause bridge releases, stop new light-client root updates, allow queries and refunds, and wait for human or social-layer confirmation. That is safer than silently accepting one history and more usable than a total unstructured halt.

Cross-chain light-client boundaries

A bridge or light client should not store only one latest root. For a PoS source chain, it should maintain at least `trustedCheckpoint`, `checkpointAge`, `finalizedHeader`, `validatorSetRoot`, `syncCommitteeOrValidatorDigest`, `lastUpdateSlot`, and `maxStaleness`. These fields decide whether the target-chain verifier remains inside a valid security window. If a target-chain contract verifies aggregate signatures but ignores trusted-root age, it can be cryptographically correct and economically stale.

The light client should distinguish at least three states. `fresh` means the checkpoint and validator set are inside the allowed window. `staleButRecoverable` means new releases should stop, but the client can recover by importing a newer checkpoint. `unsafe` means there is a checkpoint conflict or a maximum-age violation, so risk actions depending on that source chain must pause. New orders, in-flight orders, refunds, history queries, and administrative recovery should not all be collapsed into one global switch.

This field-level design matters for routing. A router can filter `unsafe` paths at quote time, re-check `fresh` status before execution, and record whether a failure came from price, bridge state, checkpoint age, or target execution. The user sees a simple status. The system keeps an auditable consensus-time anchor.

Checkpoint source scoring

A checkpoint is safer when its provenance is diverse and reproducible. A practical client or route engine can score a checkpoint source by four dimensions: independence, authentication, freshness, and replay resistance. Independence means the checkpoint is confirmed by sources that do not share the same operator or infrastructure. Authentication means the root is signed or distributed through a channel whose identity can be audited. Freshness means the slot and epoch are within a policy window. Replay resistance means the client can tell whether it is reading an old cached checkpoint that is being presented as current.

The score should not be a social popularity vote. A thousand mirrors of the same stale source are not a thousand independent confirmations. A more useful rule is quorum over source classes: at least one local client anchor, one independent public endpoint, one signed community or foundation channel, and one peer-derived confirmation. Different networks will choose different policies, but the structure matters. The system should know why a checkpoint was accepted.

This is also where user interface and protocol logic should separate. A normal user should not have to inspect root hashes. But a client, bridge operator, or route engine should store the source set behind the accepted checkpoint. During an incident, this turns "the bridge was stale" into a specific statement: which checkpoint, which slot, which source, which observed time, and which policy allowed it.

Failure modes and detection signals

The first failure mode is syncing from an old checkpoint. The client starts from genesis or from a stale state and accepts a finalized history that conflicts with current social consensus. Defenses include checkpoint sync, multiple independent sources, client-level weak-subjectivity warnings, and rejection of expired checkpoints.

The second failure mode is a bridge or light client failing to update its trusted root. If a bridge keeps accepting an old validator set or old finalized root, an attacker does not need to attack the current chain. The verifier is already operating under stale context. Defenses are maximum checkpoint age, validator-set freshness windows, and explicit degraded states.

The third failure mode is treating signature validity as economic validity. An old BLS signature can verify, but the signer may have exited and withdrawn. Detection signals include verification paths that do not check epoch, exit status, withdrawal status, or validator-set freshness. Defense requires binding signature verification, validator state, and economic accountability in the same state machine.

The fourth failure mode is a single checkpoint source. If a client trusts one API, one node, or one unauthenticated mirror, a new node can be fed a targeted checkpoint. Defenses include multi-source comparison, signed checkpoint lists, client-release anchors, community-signature channels, and UI disclosure of checkpoint source.

The fifth failure mode is cross-chain applications ignoring weak subjectivity. A router or bridge may treat "source finalized" as complete while failing to store checkpoint age and light-client sync status. Defenses include route fields such as `checkpointAge`, `validatorSetFreshness`, `finalitySource`, and `syncStatus`.

AllSwap relevance: finality needs a time anchor

AllSwap's practical concern is cross-chain exchange, refunds, and explainable settlement. Users do not need to understand weak-subjectivity calculations, but the product needs to know whether a source-chain finality claim is based on a fresh, verifiable checkpoint. If a route depends on a bridge or light client whose trusted root has not been updated for too long, "source finalized" is incomplete. It should say which checkpoint backs the finality claim and whether that checkpoint is still inside the safety window.

A route engine can split PoS long-range risk into five components: `checkpointAgeRisk`, `validatorChurnRisk`, `lightClientFreshnessRisk`, `bridgeRootRisk`, and `recoveryRisk`. `checkpointAgeRisk` measures how far the trusted root is from the present. `validatorChurnRisk` measures how quickly the validator set is changing. `lightClientFreshnessRisk` measures whether the target-chain verifier is tracking source finality. `bridgeRootRisk` measures whether the bridge still accepts old roots. `recoveryRisk` measures whether abnormal state can pause release and preserve refund.

For cross-chain exchange, the most dangerous case is not a small reorg on a healthy online chain. It is a system component believing it is verifying the current chain while actually verifying stale security context. Order state should distinguish `sourceFinalized`, `checkpointFresh`, `bridgeRootUpdated`, `targetReleaseReady`, and `refundSafe`. If a checkpoint is too old, the system can pause new routes, allow refunds, and require light-client resynchronization instead of executing target-chain release.

At the order level, checkpoint expiry should not be treated as an ordinary execution failure. A normal failure might be slippage, balance, or target-chain gas. Checkpoint expiry means the finality source has lost freshness. A better response is to freeze target-chain release, preserve the source-chain payment proof, record checkpoint source and expiry time, and move the order into an auditable refund queue. Before execution resumes, the bridge root and target-chain release condition should be checked again. Recovery records must remain traceable.

Bridge verifier policy should be conservative at the boundary between `staleButRecoverable` and `unsafe`. If a light client has missed a few updates but still has a clear path to import a fresh finalized root, the product can pause new releases and continue status queries. If sources disagree about the checkpoint or validator set, the verifier should stop accepting new state transitions for that source chain. The two states look similar to a user because both delay execution, but they are different operationally. One is a freshness problem; the other is a safety conflict.

Refund design should reflect that difference. A freshness delay can often keep the original route open while waiting for a new checkpoint. A safety conflict should move orders into a refund-safe or manual-review path and avoid target-chain release until the conflict is resolved. Without this distinction, systems either overreact to minor delays or underreact to real consensus-context risk.

This does not turn AllSwap into a consensus protocol. It turns consensus time anchors into route-quality inputs. A cheaper or faster path that relies on a stale checkpoint or a long-unupdated light client may be riskier than a slower path with fresh finality context.

Open problems

First, checkpoint distribution still lacks a single standard. Clients, browser wallets, bridges, RPC providers, and light clients may all use different checkpoint sources, and users cannot easily compare them.

Second, VDF engineering remains uncertain. VDFs can add elapsed-time cost to history generation, but hardware fairness, latency parameters, verification overhead, and upgrade paths need careful design.

Third, forward-secure signatures and BLS aggregation pull in different directions. Forward security reduces old-key value, while BLS aggregation supports efficient current PoS operation. Combining them remains an open engineering problem.

Fourth, bridges rarely expose weak-subjectivity state clearly. Many show a finality height while hiding trusted-root age, validator-set freshness, and checkpoint source.

Fifth, social recovery and automated recovery are hard to balance. Fully automatic recovery can amplify a wrong checkpoint; fully manual recovery can block user exits and refunds.

References

[1] Ethereum Consensus Specs, Weak Subjectivity, https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/weak-subjectivity.md

[2] Ethereum Consensus Specs, Beacon Chain, https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md

[3] Ethereum Consensus Specs, Fork Choice, https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/fork-choice.md

[4] Ethereum Consensus Specs, Honest Validator, https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/validator.md

[5] Ethereum.org, Weak Subjectivity, https://ethereum.org/developers/docs/consensus-mechanisms/pos/weak-subjectivity/

[6] Vitalik Buterin, Proof of Stake FAQ, https://vitalik.eth.limo/general/2017/12/31/pos_faq.html

[7] Vitalik Buterin and Virgil Griffith, Casper the Friendly Finality Gadget, arXiv 2017, https://arxiv.org/abs/1710.09437

[8] Hsiao-Wei Wang et al., Gasper: Combining GHOST and Casper, arXiv 2020, https://arxiv.org/abs/2003.03052

[9] Ethereum PoS Evolution, https://github.com/ethereum/pos-evolution/blob/master/pos-evolution.md

[10] Benjamin Wesolowski, Simple Verifiable Delay Functions, IACR ePrint 2018/183, https://eprint.iacr.org/2018/183

[11] Mihir Bellare and Sara K. Miner, A Forward-Secure Digital Signature Scheme, https://cseweb.ucsd.edu/~mihir/papers/fsig.pdf

[12] Ethereum Annotated Specification, Consensus, https://eth2book.info/capella/part2/consensus/