Categories
All Posts Posts

Long Range Attack in Proof of Stake (PoS) Blockchains

Definition: A long range attack is an attack on the consensus model of a proof of stake blockchain. A block producer (or validator) tries to create an alternative chain starting from a long ago created common block. The long range into the past is necessary to circumvent possible penalties for forking. Long range attacks are explained mostly in conjunction with proof of stake, since this problem is prevalent here and closely related to the nothing at stake problem.

Explanation of Long Range Attack

In order to avoid the nothing at stake problem in a PoS blockchain some networks apply penalties to validators who fork on two forks of a blockchain. Such a penalty is burning the deposit each validator has to stake when joining the validator pool.

The problem however is that the deposit is being paid back at some point in the future. And after the deposit has been returned to the validator it cannot be burned anymore. At this point the malicious validator can publish a secretly created fork without the fear of losing anything.

Long range attack in a naive PoS blockchain. After the returned deposit the validator publishes its attach branch

After the attacker got his deposit returned on the left side he can publish his fork.

This affects the finality of the blockchain. Users cannot be certain that a valid (well formed) block in the blockchain will not be revoked in future.

Attack Tactics

An attacker has to try to get as much stake as possible to grow the attack chain faster and with more deposit than the correct chain. Therefor he could apply different tactics.

Key Leakage

Attackers are confined to their funds, even if they are the only validator. And usually users take good care of their private keys. But if users have private keys they don’t use anymore, it might be possible that they don’t care anymore about their security. An attacker could gain knowledge of these keys.

Even if there are no coins at the moment “on” these keys, they had some funds in the past. And if the attacker creates an attack chain, he simulates the past and would be able to use the coins connected to those keys.

Private keys could also be obtained by bribing the former owner.

Stalling the correct chain

By not validating on the correct chain the validator could slow down it a bit. Of course other validators would still create and sign blocks but in every epoch all blocks from the attacker are skipped according to the stake. After a while the stake would dwindle and become less relevant but it can have a noticeable effect.

Remedy of Long Range Attacks

There are basically two remedies to avoid long range attacks

  1. Checkpoints
  2. Block validator selection
  3. Timestamps

Checkpoints

Long range attacks are the reason why some blockchains introduce checkpoints. Such checkpoints can be every 100 blocks. Those checkpoint blocks are considered as finalized. Every fork which starts before them is deemed as invalid and hence ignored.

A checkpoint can help to prevent long range attacks
The right fork is considered as invalid because it is created before the checkpoint.

While checkpoints seem to be a good solution, they have a disadvantage. A validator needs to know which checkpoints are actually valid. Validators who continuously listen to the blockchain are not vulnerable to a long range attack, unless it is combined with an eclipse attack. But validators who are new to a blockchain network or have been offline for many blocks are prone to follow the wrong chain. They need a trustworthy source of a valid recent block header in order to determine which chain is the correct one. This problem is called weak subjectivity.

A solution could be to check the density of the blockchain branch shortly after the fork. If there are many skipped blocks on one branch, this could be an indication of an unrightfully forked chain.

Validator Selection

Another obstacle for a long range attacker could be the validator selection and block signing process.

Typically, blockchains which introduce penalties and checkpoint require that validators register early. This means that the validators are determined before the fork.

If the attacker has a very low deposit (or stake) at the time of forking it is difficult to get selected as a validator. And if the other validators are unaware of the attack chain, they don’t contribute to the block signing process. This has two effects:

  1. The total stake is lower on the attack chain and hence is not considered as the preferable chain in the fork choice rule. But the attack validator reaps all block rewards (and to some extend validation fees) which he can stake again. In the end the attack chain would have a higher stake than the original blockchain.
  2. Blocks are skipped (at least at the beginning). Thus, the attack blockchain proceeds very slow. But it is possible to increase the speed either by lowering the difficulty, if a virtual mining rig is used or by stake grinding where favorable hash inputs are tried to solve the inequation.

If there is a (super)majority of validators necessary to create a checkpoint, a single attacker would need to split his deposit into sufficient chunks in order to have the required minimum number of signing validators. Together with a minimum stake amount for each validator this would mean high initial investments.

Timestamps

Timestamps prevent the attacker from creating blocks faster then the correct chain. Since validators are determined before the fork the attacker must skip a few blocks in each epoch. One way to do this could be going through the election cycles faster. Instead of waiting for every block 10 seconds as it might be stated in the correct chain, the attacker could wait just 0.1 second and create blocks 100 times faster. This only works if timestamps are not checked. Checking timestamps is a necessary but not sufficient condition for a secure PoS blockchain.

Further Readings

https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=8653269

https://eprint.iacr.org/2019/1440.pdf

 

Leave a Reply

Your email address will not be published. Required fields are marked *