Fundamentals of the Blockchain #2 [Article Series]

Article 2: Decentralization

If you missed it, the first article looked at the history of blockchain technology, the double-spend issue, computational backing and the lead up to the creation of Bitcoin.

Today we're going to discuss decentralization and, briefly, public-key cryptography. Public-key cryptography is a system that uses pairs of keys, with a pair consisting of a public key (which may be known to others) and a private key (which may not be known by anyone except the owner). The generation of such key pairs depends on cryptographic algorithms which are based on mathematical problems termed one-way functions. Effective security requires keeping the private key private; the public key can be openly distributed without compromising security.

Why Decentralization Is Important:

So, imagine a coin that allowed us to use public-key cryptography but the blockchain was validated by a centralized validator, to overcome the double-spend issue. Here we have a very basic, but functioning, cryptocurrency. One of the issues in this scenario is that we have a weak point. Specifically, the centralized validator. In this situation, let’s say our centralized validator generates all the coins. They could punish users by not adding transactions to the blockchain, or they could hold the entire system ransom by refusing to update it. Even if they weren’t malicious, they are still a central point of failure. What if they just forgot to publish one day, or what if they decided that it was time to retire? This leaves us with one centralized place where the system could fail. The question is, could we take the strength of our coin (the ability to avoid double-spend attacks) but without bringing in a centralized party? The answer, of course, is yes. It shouldn't be too much of a surprise if you know that Bitcoin and related blockchain technology is decentralized.

What trade-offs are made to achieve decentralization?

There's never a free lunch. By trying to decentralize, we're actually going to bring in some additional problems. Just quickly, let's think about why we want things to be decentralized versus centralized… In any system, there's always going to be a tension between centralization and decentralization, because there are benefits and weaknesses to either direction that you go. This isn't just in cryptocurrency though, or even just technology. In general, we see this in a lot of different locations. For example, the Apple ecosystem is very centralized, but it means that their new (or perhaps controversial) software can be sold in their ‘walled garden’. The Android ecosystem is much more decentralized and many more different possible projects can go on it, but this also means that the quality may not be quite as high. Everything in software is a trade-off and most systems are a hybrid.

Even in blockchain, what we're going to see is that the system isn't as decentralized or distributed as it could be. There are some trade-offs to having some level of centralization in most blocked blockchains, but Bitcoin was designed to be as decentralized as possible while still providing a cryptocurrency that worked and protected against things such as double-spend attacks. If we look back to the original Bitcoin white paper, we see that it was designed to be a purely peer-to-peer version of electronic cash, without going through a financial institution. In fact, Satoshi Nakamoto noted that our original solutions, digital signatures, provide part of the solution, but the benefits of a cryptocurrency are lost if we are still required to trust a third party. So, Satoshi thought about what we need to do in order to decentralize.

This creates a number of questions…If we don't have a single person or entity in charge of the ledger, who maintains the ledger? Who has the authority to say whether or not a transaction is valid? Where do new Bitcoins come from? Who determines how the rules of the system change? And how do we determine what the value of a particular Bitcoin is?

So as I mentioned, Bitcoin is meant to be decentralized, but there are different levels of centralization. The network itself is very decentralized - if you would like to spin up your own fully validating node, it is relatively simple - anybody can do it and join the network. Mining, it turns out, is actually somewhat centralized. We'll discuss more about what miners are doing in a later article, but they're the ones who generate new blocks in the Bitcoin network. It's open to anyone, you can even use your computer to start mining, but it is extremely difficult to do profitably and there are extremely large economies of scale. What we see is that there are only a few very large miners in the world, that provide a majority of what's called the ‘hash power’, or attempts to generate a new block in Bitcoin. Updating the protocol or writing new software is generally pretty centralized in practice. The vast majority of nodes use a particular implementation of Bitcoin known as Bitcoin Core. Anyone can write their own node software and there are some alternatives, for example, Bitcoin J which is written in Java. The vast majority though, by which I mean probably over 98 or 99 per cent, use Bitcoin Core.

So, we have a very decentralized number of nodes. How can this anonymous group of nodes come to a consensus? We need what's called a distributed consensus protocol. We have n nodes, where n can be any number and actually, this number can fluctuate as some nodes go offline or some people decide they don't want to run a node. Some of these nodes may be faulty, they may be providing invalid data, or spamming the network. Some may even be malicious, that is, they're intentionally trying to harm the Bitcoin network. So a distributed consensus protocol, that would allow us to come to a consensus between all of these honest nodes, has to have a few different properties. It must end with all the honest nodes in agreement about what is the particular ledger that we agree upon. So here is how Bitcoin gets around that - where a Bitcoin network is a peer-to-peer system, think of it as a mesh of nodes in a network.

What we want to do is determine which transactions we are going to put into the blockchain. Since there's going to be different nodes that are going to have different ideas of what transactions are out there, we're going to need to come up with some consensus mechanism to determine which transaction should be put in the blockchain. In a simplified example, it might be every 10 minutes we're going to use some voting mechanism to determine which transactions are put in the blockchain. Every node is going to vote on which one is valid and which one is not. But, there's a problem with this simplified example of just voting on if more than 50 of our nodes have a transaction and consider it valid. First, there's no real notion of universal time. Who decides when it's been 10 minutes? Different computers may be slightly off in terms of time and so there's no way to have a universal network-wide decision on what exact time it is.

Also, the specific consensus mechanism we use to vote on this is imperfect. You may have a fault in the network, or you may have a system that's not responding. You may not know exactly how many nodes exist at a given time, so we could keep track of that, but that just brings us back to having some sort of centralized entity in charge of all of that. Malicious users could spam the network, i.e. they could send invalid transactions simply to chew up CPU. There are a lot of problems with our simplified consensus protocol of just voting to see which transactions go into the blockchain. It turns out that this issue of having to have a large number of nodes that have a limited amount of ways to communicate, some of which may be faulty, or even malicious, is a problem that the computer science world has referred to as the Byzantine Generals Problem. This goes back to the canonical explanation of the problem, which is that you have a variety of generals who wish to attack a city and those generals must all decide what time to attack. But, when they're sending their messages, other generals who may be traitors could modify the messages. So, how can we come to a conclusion of when we should attack the city, if some percentage of our generals may be traitors? Similarly, coming to a consensus in Bitcoin, or any other decentralized ledger technology, we need to have a way to determine what is the consensus amongst all the honest validators. The problem with doing this is what's called Segal's law.

A man with a watch knows what time it is, but a man with two watches is never sure.

What we mean by the above is that all of these different nodes are going to have to come up with conclusions on their own. There's no centralized mechanism of time control, there's no way to say that x event happened before y event, and once you've removed that ability to have ‘do x and then y’ it turns out that a lot of algorithms used for determining the correctness of an event are not really feasible.

One of the particular ways that our consensus can fail is through something called a Sybil attack. Remember we thought about having votes: our nodes would vote on which transactions to include. Say we have 16 nodes in our example. If nine nodes say that a transaction is valid we would add it to the ledger, but what if somebody creates 25 malicious nodes and adds them to the network. They are pretending to be multiple entities (that's why it's called a Sybil attack - it's based on an old book and movie about a woman who had multiple personalities, one of whom was named Sybil). In this Sybil attack, that malicious individual creates more nodes than there are honest nodes in the network, so they can always vote against adding any particular transaction, or adding a particular transaction as valid because they have more nodes. If we just vote based on the number of nodes, and nodes are relatively easy to set up, we are at risk of this Sybil attack.

So let's come up then with a simplified version of what Bitcoin uses as its consensus algorithm. Let’s say our new transaction is broadcast to all nodes. Each node is going to collect new transactions into a block and, in each round, some random node gets to broadcast its block. So, of the n nodes, a random node is going to broadcast its block so we are assuming here that we can avoid these Sybil attacks, but even if Sybil does have a large number, if the malicious individual has a large number of these nodes, the worst that can happen is that they would just generate a transaction that's invalid, or that doesn't contain any transactions. Everyone else would know about these transactions and as soon as a valid node is selected at random to be the next block producer, then they can do that and include any transactions that Sybil missed. The other nodes will accept the block if and only if all the transactions in it are valid. Remember, Sybil cannot generate new transactions. You would need to know the secret key of the owner of the coins to send a transaction.

Nodes will express their acceptance of this block by including its hash in the next block. So basically, generating a hash pointer from their newly generated block to the previous block that was generated by the previously selected node. As a side note, one of the other problems with a decentralized technology is that every node is going to need a copy of the blockchain, which can be tens or hundreds of gigabytes. You can imagine that it's going to use up a lot more storage than if something were centralized, even if you included a few backups.

The Bitcoin full blockchain, for instance, is stored on at least 10,000 actively running nodes. If a node was picked at random, from all the known nodes that are out there, it packages all valid transactions into a block and adds it to the blockchain. It then broadcasts the new block, thus the new blockchain and other nodes add this new block. We can see that this is going to cause a few different problems. One issue is that the individual node that was selected now has a lot of power. For instance, imagine a node was selected but doesn't like a certain transaction, for one reason or another. So it packages all the valid transactions into a block, adds the valid block to the blockchain, which does not have this transaction, and broadcasts the new block. In this case, the new blockchain goes out to other nodes which will add it and now that transaction is not going to be confirmed. Perhaps some other nodes have a copy of the transaction, but if enough different nodes are trying to blacklist it then it may be a while before the transaction actually goes through. This also allows for double spends.

Let's say Alice purchases software from Bob for one Bitcoin. She generates a transaction to send to Bob and an honest node includes that block in the blockchain. Bob sees this block has been confirmed and Alice downloads the software, so now Alice has gotten something for her Bitcoin. Then Alice's node is randomly selected as the producer for the next block, so instead of building on block n, the one in which she sent this Bitcoin to Bob, she instead builds on block n minus one. She ignores the previous block and makes her own block where the Bitcoin goes to some other address that she controls. Alice basically sends it to herself. The original transaction to Bob is now useless because the Bitcoin in that block cannot be used by him in later blocks.

Protecting Against Double-Spend Attacks

We can protect against double-spend by waiting for a number of blocks to be produced. If we're only waiting for one confirmation, that is one particular node that may or may not be honest, then the possibility of one randomly selected node being dishonest is relatively high. But, if we wait for a number of blocks then we would need to be more sure that not all of those blocks are dishonest. The general rule in Bitcoin is to wait for six blocks and blocks are generated on average in Bitcoin about once every 10 minutes and, as we'll see, generating a block in Bitcoin is extremely difficult. The more blocks they could put on top of that the more work and the more difficult it's going to be to do one of these double-spend attacks.