We have discussed blockchain consensus as an automated process to ensure that there exists only one single copy of record shared by all the nodes. Now, let’s see how it’s actually done. This non-technical video will give you a high level conceptual picture of how consensus could be reached and it’s common limitations. We’ll discuss some specific algorithms used by leading blockchains like Bitcoin and Etherium in the next module. The problem is that we have thousands and thousands of nodes which are just computers connected in a peer-to-peer network. And each of them have a slightly different copy of data that they received from users closest to them.
The goal is to reduce these thousands and thousands of different data copies into one unified copy shared by all. Now, let’s think, what are the easiest ways to do this? How can we easily single out one copy out of these thousands? That’s right, the first solution that you might think of is well, let’s just imitate a centralized database. Let’s designate a central party and whatever data the central party have is going to be the official copy. We’ll have a central node hear the transactions, compile this block as usual and post the block in fixed intervals.
Once it’s posted the rest of the nodes simply assumed a much more passive role by verifying that for the transactions in the block the crypto signatures are correct and the amounts add up. And if it’s valid the block will be officially posted and the process repeats. If you think about it, this is similar in spirit to the ACH Network that we discussed in the pay tech course. The FED, like a central node, processes all the interbank transactions and the banks will simply trust the Fed. A simple variation of this approach is the majority vote.
In this process, the nodes simply post their transactions and transactions that have been heard by a majority of the nodes are automatically accepted onto the blockchain. This more centralized setting is notably used by Ripple. This central node setting is unbeatable in terms of efficiency. There’s no need for any mining or complex computation. Even with a large number of passive peripheral nodes transactions broadcast to the central nodes could be put on the blockchain as soon as they’re heard. Consequently, this consensus mode is very useful in private blockchains where the nodes are known to each other and in more enterprise folks settings where speed and efficiency are the key. However, the disadvantage of this consensus process is also quite obvious.
Who should be the central party? Obviously, it cannot be an unknown entity. Under the centralized consensus model, the parties have to be thoroughly vetted and this vetting process has to take place off the blockchain using traditional legal means. This will be quite expensive and consequently, the central validator process is not applicable to public blockchains where the nodes are more or less equal and all of them are anonymous.
Now, let’s take the central process up a notch to arrive at what I call the random consensus protocol serving as the foundation upon which most of the actual consensus algorithms are built. Let’s now assume that vetting is impossible. All the nodes are equal and all the nodes are equally anonymous to each other. Again, we have the same problem. How can we easily select one data copy out of the thousands of the copies held by different nodes.
That’s right, the easiest way to do this is well, let’s just randomly select the node. We’re going to let the nodes hear the transactions and compile their blocks as usual. But at the end of every interval, we’re going to throw a dart at the board of nodes and randomly select one node to post this block.
And here again the rest of the nodes assume a more passive role and simply verify the validity of transactions in the block, like having the right crypto signatures et cetera. And if the block is valid it will again be officially posted and downloaded by all the nodes. And the process then repeats with each node building upon the chain again, and another node being randomly selected at the next interval. If the block is not valid simply randomly select another node and rebuild the block.
So will this process work in guaranteeing that all the nodes receive the same chain of data blocks? Absolutely, if the proposed block contains valid transactions, the random consensus model guarantees that it will make it to the blockchain and become the quote-unquote master record held by all the nodes. This consensus protocol addresses the first part of the Byzantine Generals problem of data reconciliation.
However, it doesn’t really address the second part of the problem because this process where every node being equal does nothing to prevent a malicious node from being picked. And in an anonymous system, you’re going to have bad actors and if a malicious node happened to be picked it will seek to damage the system for their own gain. Let me be very clear about the kind of damage we’re talking about. Suppose you operate a malicious node, and your node happened to get lucky and be picked in the current interval. What are the bad things that you can do to benefit yourself at the expense of the system?
That’s right, the first thing that you probably think of is well, let’s steal other people’s data or money. Let’s sign away their Bitcoins, for example, from their addresses to our addresses.
This is certainly possible but not very likely because as we saw before a transaction still has to be authenticated with the user’s private key. Without obtaining the victim’s private keys, the transactions you generate on their behalf won’t be valid because the crypto signature will match. And therefore the other nodes will reject it. Even if your malicious nodes are picked, you still need to separately obtain the private keys to steal things. And once you have the keys the stealing will happen with any kind of consensus anyways, so this type of damage is less of a priority concern in designing consensus algorithms. Now if stealing is hard, what else can you do?
You could launch a denial-of-service attack. That is if you are picked you could simply refuse to process any or all transactions thereby halting the system and maybe you could demand some ransom to get the processing started up again. This will be very costly if the blocks are very long. However, if the blocks are relatively short like ten minutes for Bitcoin or ten seconds for your Etherium, the damage will be quite limited because in the next interval we’ll throw the dice again, and another node possibly not malicious will be randomly picked.
The bulk of the damage from a malicious node therefore is in the form of a double-spend attack. This is not a technical attack but an economic attack on the system. You probably heard of this term from the media and it works exactly as it sounds. If your malicious node is randomly picked in this round. While you can’t easily spend other people’s money you have a real possibility to spend your own money twice. Let me illustrate this with Bitcoin.
Suppose this is the accepted blockchain up until now. Your wallet address is A in this picture. Suppose that you have previously received some Bitcoin from address K. I have also recently spent it to address B in a valid transaction linking it to the receipt. Maybe you paid be for some services like a software download. Now suppose you also operate a malicious node, and in the random consensus process your node got lucky and happen to be selected in the latest ten-minute interval. Now, you have a real chance of reversing this transaction in green, refunding the coin back to you and leaving B with a loss.
Instead of doing things honestly, you’re going to propose a block with a fraudulent transaction sending the same coin back to yourself.
Notice that this is a completely valid transaction. It’s pointed correctly to a previous transaction where your address received the coin and you have your own private key to correctly sign the transaction.
Therefore once you post the block other nodes will accept it as valid. Now, immediately you can spot the problem. Both the green and the red blocks are valid and by getting selected and posting the red block you essentially created a temporary fork in the blockchain. Obviously only one of the forks will prevail and critically here which one does depend on what happens in the next rounds. Let’s suppose that your luck is temporary. In the next round, an honest node is picked because the green legitimate block happened earlier in time the honest node will build on that block and so on so forth. Therefore after a few rounds the fraudulent block will essentially be quote-unquote orphaned and removed from the chain.
However, suppose you managed to get picked again in the next round. Now, what are you going to do? Of course, you will build upon the fraudulent red block extending that fork instead. And after a few rounds, the legitimate block will be orphaned and your double-spend attack will be successful. You will have the coin back and B will have provided the service to you for nothing.
Now you see the gist of blockchain attacks. Both blocks are technically valid, referencing the right transaction with the right signatures. However, the technical validity does not equal economic truth because one of the blocks is clearly fraudulent. The double-spend attack is essentially an economic attack on the decentralized system. And under a random consensus model the likelihood of success is proportional to the likelihood of your fraudulent node getting picked. If you happen to control more than half of the node identities then the attack will on average be successful.
Therein lies the crucial limitation of our simple random consensus model. It’s extremely vulnerable to double-spend attacks because each of the nodes has an equal chance of being selected and all are anonymous. It’s completely costless to create a new identity which was simply a public/private key pairs. Therefore an attacker could simply create as many node addresses as they want to increase their chance of getting picked. The act of inundating the system with addresses is also called a Sybil attack and this is something that any real-world consensus algorithm must address. A good algorithm would build upon this model of random consensus to achieve data reconciliation but tweak the selection process so that it’s resistant to easy double-spend attacks.
And how this is done in practice boils down to one simple concept.
Instead of doing a completely equal weighted selection where the nodes are selected completely randomly, we should do a weighted selection. Whereas a node your probability of being selected, it’s going to be proportionally related to something that’s very costly to fake. This way, you can’t easily create another node without incurring some serious costs. This is currently done in two main ways. Number one is mining, or proof of work, where the nodes are weighted in the selection process by their computational power. Number two is virtual mining or proof of stake where the nodes are weighted by their wealth.
Both make the Sybil attack costly because without incurring the real cost in terms of computational power, energy, or wealth the fake nodes will have zero chance of being picked. We’ll discuss the details of these algorithms in the following module.