Long range attacks are a threat specific to proof of stake blockchains, in which an attacker builds an alternative history starting from a point far in the past. If the fake chain looks valid, a node joining the network for the first time may be unable to tell which history is genuine.
The attack exploits a property that proof of work does not share: creating blocks in proof of stake costs almost nothing in physical resources. This article explains why that matters, how attackers might acquire the keys they need, and how weak subjectivity, checkpoints, and careful node setup keep long range attacks in check.
Rewriting History Without Burning Energy
In proof of work, every block represents real computing effort. To rewrite deep history, an attacker would have to redo all that work and then outpace the honest network, which becomes enormously expensive as the chain grows.
In proof of stake, blocks are produced by validators who sign them with private keys. A validator is a participant who has locked tokens as collateral, called stake, in exchange for the right to propose and vote on blocks. Producing a signature takes negligible computing power.
That difference changes the threat model. If an attacker controls keys that held significant stake at some past point, it can produce a long sequence of valid-looking blocks from that point forward. The cost barrier that protects proof of work history simply does not exist in the same form.
Proof of stake designers do not consider this a fatal flaw, but they do treat it as a structural property that every serious protocol must explicitly address.
Where Attackers Find Old Validator Keys
The attack depends on obtaining keys that once controlled a large share of stake. Those keys must belong to validators who no longer face meaningful penalties, because they have already withdrawn their deposit.
Once a validator exits and withdraws, slashing can no longer touch its funds. Slashing is the protocol’s punishment of destroying part of a deposit when a validator provably misbehaves. A former validator’s old keys therefore lose their economic risk while keeping their historical signing power.
An attacker could buy such keys from former validators, steal them from poorly secured backups, or compromise infrastructure that still stores them. Because the original owners have little to lose, the price of old keys may be low. That economic gap is the root of the long range problem.
Three Variants of the Attack
Research usually distinguishes several forms of long range attack. They share the goal of creating a convincing alternate history but differ in method.
Simple Long Range Attack
In the simplest form, an attacker controls keys that held stake at an early point and produces an alternate chain from there. In networks where nodes check block timestamps against real time, the attacker must produce blocks with plausible timing.
This variant is relatively easy to detect if the fake chain contains fewer blocks or unusual timestamps compared with the honest chain. Simple defenses that compare chain characteristics can often reject it.
Posterior Corruption
In posterior corruption, the attacker gathers keys from validators who were active in the past but have since exited. Combining enough of them, the attacker recreates the stake majority they collectively held at that earlier time.
The resulting chain can contain correctly signed blocks for every slot, matching honest timing. Because each signature is genuine, cryptographic checks alone cannot distinguish the fake history from the real one.
Stake Bleeding
Stake bleeding is a slower variant in which the attacker grows its share of stake on the private chain over time. It collects block rewards and transaction fees that honest validators would have received, while honest validators on the fake chain appear inactive.
Over a long stretch of the alternate history, the attacker’s relative stake increases until it dominates. This variant shows how protocol reward rules themselves can be used to build a fake majority.
Who Is Actually at Risk
Long range attacks rarely threaten nodes that remain continuously online. A synced node already knows the real chain and will reject an alternative branch that diverges far in the past, because its fork-choice rules and finality markers forbid reverting finalized blocks.
The main targets are new nodes joining the network and nodes returning after being offline for a long period. Such a node has no recent knowledge of the chain. It receives competing histories from peers and must decide which to follow based on what it can verify.
Light clients, which verify only block headers or committee signatures rather than full blocks, can face similar risks. If an attacker controls the peers a fresh node connects to, it can present only the fake chain, combining a long range attack with network isolation.
Services that frequently spin up fresh nodes, such as cloud-based indexers or temporary test environments, face more exposure than a long-running validator that rarely restarts.
A Hypothetical Attack on a Fresh Node
Imagine a company launching a new node to verify customer deposits. The operator syncs from genesis, the first block, using a default peer list. Unknown to the operator, an attacker controls several of those peers and has prepared an alternate chain built with old validator keys.
The fake chain carries valid signatures for every block, and the honest peers are slow to respond. The node accepts the attacker’s history, in which certain deposits never happened or went elsewhere. The company’s balances now disagree with the real network.
The damage stays hidden until someone compares the node’s view against an independent source. A single trusted checkpoint, checked before syncing, would have caused the node to reject the fake branch at once. This is why bootstrapping procedures matter as much as the node software itself.
Weak Subjectivity Explained
Proof of stake designers accept that a fresh node cannot determine the correct chain from protocol rules alone. This property is called weak subjectivity, a term introduced in the Ethereum research community.
Under weak subjectivity, a new or long-offline node needs one piece of trusted recent information, typically a recent block hash or finalized checkpoint. With that anchor, the node can reject any history that conflicts with it, regardless of how valid the alternative signatures look.
The trust required is limited. Users obtain a checkpoint from sources they already rely on, such as several independent block explorers, community members, or client defaults. Within a window that varies by network, any node anchored to a recent checkpoint is protected against deep rewrites.
Critics note that this reintroduces a small element of social trust. Supporters respond that users already trust their software downloads, so a checkpoint adds little additional assumption.
How Finality Limits the Damage
Many proof of stake networks use explicit finality. Validators vote on checkpoint blocks, and once a supermajority of stake agrees, those blocks are finalized. Online nodes refuse to revert finalized blocks regardless of competing chains.
Finality protects active participants strongly. To revert a finalized block while validators are still staked, a large share of them would have to sign conflicting votes, which slashing rules detect and punish. This is accountable safety: misbehavior can be traced to specific validators.
The limit appears when the guilty validators have already exited. Their conflicting signatures can no longer be punished, which is exactly the situation long range attacks exploit. Finality must therefore be combined with checkpoints that new nodes trust from outside the chain.
In short, finality answers the question for nodes that were watching, while checkpoints answer it for nodes that were not.
Checkpoint Sync and Safe Node Setup
Modern consensus clients often support checkpoint sync, a method of starting a node from a recent finalized state rather than replaying history from the beginning. It improves speed and anchors the node to a recent checkpoint.
The security of checkpoint sync depends on where that state comes from. Operators should follow a careful process each time they bootstrap or resynchronize a node.
- Choose a checkpoint source run by a party you have reason to trust, ideally one you operate.
- Compare the finalized block root against at least two independent public sources.
- Confirm the checkpoint is recent relative to the network’s weak subjectivity period.
- Record the checkpoint used, along with the time and sources, for later auditing.
These steps turn a single point of trust into a cross-checked anchor. If an attacker compromised one source, comparison with others would expose the mismatch before the node ever followed a false chain.
Protocol-Level Defenses Beyond Checkpoints
Protocol designers have explored further protections that raise the cost or reduce the value of old keys. They complement weak subjectivity rather than replacing it.
Withdrawal delays are one important tool. Validators must wait through an exit queue and withdrawal period before receiving their stake. During that time, any misbehavior can still be detected and slashed, which keeps recently active keys economically exposed.
Key-evolving signatures provide another layer. In such schemes, a validator periodically updates its signing key and erases the previous one. Even if an attacker later obtains a validator’s current key, it cannot sign blocks for earlier periods. Several research protocols adopt this idea, though designs vary between networks.
None of these measures is complete alone. Combined, they shrink the window and the incentive for anyone hoping to profit from retired keys.
Guidance for Validators and Former Validators
Validators play a direct role in limiting long range risk. Every key that once held stake is a potential building block for an attacker, even after the validator has stopped participating.
- Destroy or securely archive signing keys after exiting, according to your client’s guidance.
- Never sell or transfer old validator keys, regardless of their apparent lack of value.
- Keep backups encrypted and stored separately from online infrastructure.
- Rotate access credentials for servers that ever held signing keys.
Responsible key retirement reduces the pool of keys available to attackers. Withdrawal keys and signing keys often have different roles, so validators should confirm which key controls what on their network and handle each according to its function.
Staking services should publish their key retirement procedures so delegators can judge whether exited keys are handled responsibly.
Comparing Long Range and Short Range Threats
Long range attacks reach deep into history, typically past the window in which slashing still applies. Short range threats, by contrast, involve forks near the current chain tip, where validators are still bonded.
Nothing at stake problems, for example, concern validators voting on several competing forks at once. That issue is handled mainly by slashing equivocation while validators are active. Long range attacks escape slashing because the keys involved are no longer at risk.
Understanding this split clarifies which defense fits which threat. Slashing and finality protect the recent chain, while weak subjectivity checkpoints and key hygiene protect deep history. A secure proof of stake network needs both layers to work together.
When reading a protocol’s security documentation, look for explicit treatment of both cases. Silence on either one is a reason to ask questions before committing funds or infrastructure.
Preparing Your Infrastructure for Safe Syncing
For most users, long range attacks are a theoretical concern handled by the client software they run. The risk becomes practical for anyone who operates nodes, builds infrastructure, or relies on light clients for important decisions.
Start by documenting how each node in your environment synchronizes. Identify where checkpoints come from, how often nodes go offline, and whether light clients verify against trusted anchors. Gaps in that documentation often reveal hidden single points of trust.
Then schedule routine checks. Compare finalized checkpoints from your own nodes with independent sources, update client software as networks change their sync rules, and review the weak subjectivity window for each chain you support. These habits keep fresh nodes anchored to genuine history.
Light clients deserve the same care. Confirm how each one obtains its trusted starting point and how it updates that anchor over time.