paint-brush
NXT POS Block Skipping Attack Mythby@ly
502 reads
502 reads

NXT POS Block Skipping Attack Myth

by Lior YaffeJune 16th, 2018
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

In the <a href="https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ" target="_blank">Ethereum proof of stake FAQ</a>, NXT is mentioned as suffering from a class of “Stake Grinding” attack. The author refers to this attack as “Block Skipping Attack”. In this article, I’ll explain why this imaginary attack is not practical.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail

Coin Mentioned

Mention Thumbnail
featured image - NXT POS Block Skipping Attack Myth
Lior Yaffe HackerNoon profile picture

In the Ethereum proof of stake FAQ, NXT is mentioned as suffering from a class of “Stake Grinding” attack. The author refers to this attack as “Block Skipping Attack”. In this article, I’ll explain why this imaginary attack is not practical.

The idea of a block skipping attack is that as a proof of stake block generator i.e. forger, as we call them in *NXT, when my time comes to forge the next block, I can decide to skip my turn to forge if I can calculate that I will be able to forge more future blocks which may provide a greater block reward.

Let’s analyze why this attack might work theoretically.

Every NXT block stores the “Generation Signature” of the block, which is simply a hash of the public key of the account which generated the block.

When forging the next block each forger calculates a hash of the previous block generation signature concatenated with its own public key to get a “hit” value. This “hit” value is multiplied by the forger account stake and compared with the base target value to define a time window in which the forger is allowed to generate the next block. When a forger does generate the next block and submits it to the network all nodes repeat this simple calculation to validate that there was no cheating.

Clearly a forger can calculate the “hit” value of any other account and knows the stake of any account and therefore can predict with high certainty which forger is about to generate the next block and who is next in turn and so on. Based on this knowledge a forger can decide to skip his turn.

To execute the attack, what a forger can do is wait for her turn to forge, but instead of forging the next block, she will calculate who is about to forge the next block in case she skips her turn. Then given the public key of the would be forger, she can calculate the generation signature of the next block and then check who will be able to forge the next sequence of blocks.

In theory, in this way the forger can predict who will generate a long sequence of blocks and then decide to skip this block in order to generate, say, three out of the next ten blocks with only 5% of the stake if she gets very lucky.

This attack is not a serious threat.

As with most “attacks” against NXT’s POS algorithm, this is another interesting theoretical attack which is entirely impractical.

In practice, using this attack successfully is very tricky for several reasons. Forgers may not be online to generate the next block, forgers can decide to skip their turn as well for the same reasons, or nodes can switch to a better fork thus changing the calculation. Any of these common events will break the attack and will leave the attacker with one less block reward because of the block she skipped, so will in a sense penalize her for attempting this attack.

Furthermore, since in NXT/Ardor, the only reward for forgers are the transaction fees of the transactions included in the block, and since the forger has no way to predict what would be the transaction fees of the next blocks if she were to skip the current block, it is almost impossible to be certain about the outcome of this attack.

To further mitigate this attack, and similar attacks based on the predictability of the next forger, we also stagger the fee received from forged transactions over a period of four blocks to make this type of attack attempts even less predictable.

Ethereum’s Casper POS algorithm may not suffer from this type of attack, but it has been in development for over three years and is not even close to being deployed to production. Meanwhile NXT is working successfully, in production since 2013 and Ardor, which is based on the same consensus algorithm, is working successfully in production since January 2018.

I hereby call to the Ethereum team, please remove this unjustified criticism of the NXT proof of stake algorithm from your official documentation.

  • Everything explained in this article about NXT is also applicable to Ardor.