This is Part 3 of my conversation with Robert about well-known attacks against blockchains and the types of defense taken by DFINITY. In a Long-Range Attack, the attacker buys old (unused) secret keys to overwrite history. By requiring a notarization on each block and getting rid of old keys, DFINITY makes such attacks much harder.
Cédric: Okay, so it sounds like DFINITY has implemented a couple of policies that prevent Nothing-at-Stake Attacks or let’s just say problems from happening on a network.
Robert: So in our system it’s not a profitable strategy for you as a block maker to just mine on more than one chain because then you won’t get your block accepted, so neither of your blocks will get accepted and you will also get penalized.
Cédric: And with that let’s head on to the third.
Robert: Yes, so the third Attack Vector or Long-Range Attacks.
Robert: These Long-Range Attacks are somewhat similar to the Nothing-at-Stake problem in that the attacker also tries to recreate a longer fork; in this case, that the attacker goes back in past, so it does not just create some equivocating blocks in the present, but he goes back in past and tries to rewrite a longer portion of the history. And so how can an attacker achieve that?
Robert: So if we imagine a proof-of-stake blockchain, like a traditional one, then we know that each block has been created by some miner or a block maker, which has private and the public key, and so on. Now if in a simple system, these keys can also be used to send transactions but eventually every miner may stop its activity as a miner or may just lose its interest in keeping or in participating in the system, so it can happen that these miners have no interest any longer and they sell their whole stakes, so they don’t have anything to do anymore with the blockchain.
Now if an attacker comes and tries to buy these keys from the old miners, who have already sold their stakes and are not interested any more in mining, it is very likely that these keys wouldn’t have a high value anymore, they are nothing worth. The attacker wouldn’t have to spend a lot of money to buy old keys from old miners.
Robert: Is this reader-problem or why is it a problem? So we have to see whether an attacker can buy a couple of old keys, whether this allows him to create a longer chain, then honest chain. And of course, the attacker won’t be able to buy a hundred percent of all the old keys; that’s not realistic. Maybe not even 50% or maybe the attacker can buy 10% at some point, so we can say so for this section of the history the attacker buys 10% of the keys. So at first sight, we would say the attacker wouldn’t have any chance of creating a longer fork and because the honest chain has 100 percent of the keys or a 100 percent of the miners are still building on this chain which grows over time.
Robert: But there is another problem, which comes in this situation and this is called the Stake-Grinding problem. Because if the chain in proof-of-stake you need a way to select or to choose which miner should have the right to create the next block, optimally this selection mechanism should be completely random. Now it turns out that naive systems or maybe the first generation proof-of-stake systems, they had random number generator which was prone to manipulation. The attacker could go back in past and could try to alter some parameters in the blocks, which were used to derive the randomness for the selection of the next miner or for the next block. By doing so, the attacker could multiply his chances of creating a longer chain. With that, the attacker could have created along a chain maybe even with 10% or just a minority of old keys.
The combination of having old keys that don’t have an inherent value anymore and having a way of manipulating past randomness, allows an attacker in some cases to create longer forks that go back in past to overcome the honest chain and to rewrite a section.
Cédric: And essentially double spent some of his coins that might be one of the motivations behind it.
Robert: Double spend or whatever reason he might just want to censor all or just delete all transactions because he doesn’t like the parties that are involved or of course double spends would also be possible.
Cédric: How does DFINITY approach that?
Robert: As already mentioned, in DFINITY for each block we have an notarization, so a notary which should collectively sign and validate this block and this notarization gives you as an output a so-called Threshold Signature. For this to create such a Threshold Signature, you need at least 50% of the notaries. So 50% of the notaries must participate by creating a signature share on the block and then by collecting more or at least 50% of these shares you can recreate the notarization on the block. And this, of course, is the same for every block.
Robert: Now, if an adversary wants to rewrite history, he not only has to get the keys to create new blocks, but he also needs to get a majority – every single committee or group that notarized these blocks, which means that he would have to buy for a whole section of history more than 50% of the key shares or the private keys of the participants, who participated with their key shares or signature shares. He would have to buy them. Over a longer period, he would have to buy a lot of keys. So in that sense effectively need more than 50%, you need maybe 55% of the whole population, if you look at the whole population of miners in order to be able to get a majority in a whole series of old notary groups.
Cédric: And, of course, that’s a lot more expensive and thus a lot less likely to happen than if you only need to acquire 5 to 10% of all key shares.
Key Shares for Notarization
Robert: Exactly because there’s another aspect which I should mention. The key shares used for notarization – they only have this kind of use, they are not used for other purposes, like for signing transactions, they are just used internally by the client software to notarize the block. So once the block has been notarized, the client software just throws away these key shares. So they are deleted automatically by the client.
This also means that a miner who has been using the official client, who hasn’t manipulated a client, just use the official client that gets rid of the key shares because they are not needed anymore, an attacker couldn’t even buy up these key shares because they don’t exist.
Cédric: Great, so we’ve covered three potential attack vectors – Selfish Mining, Nothing-at-Stake problems and then third, last but not least, Long-Range Attacks and how DFINITY copes with all these three potential attack scenarios. Thanks Robert. Super helpful. I think that was a great overview.
If you guys liked this video and you would to hear more about one about of these strategies, let us know in the comments and we’ll produce a video about one of each and go into a bit more detail and make it a bit more scientific as well. With that, if you like this video and you would like to see more, click Subscribe and with that, we’ll see you soon.