Architecting A Digital Fortress. The Bitcoin’s Consensus Protocol.
A semi-technical overview for the uninitiated.
In a previous article, I touched on some technical aspects of Bitcoin mining, explaining what mining is and how it works. In particular, I expanded on the notion of blockchain and how the mining process is used to elongate such chain with new blocks containing the new transactions that occur within the network.
In presenting those concepts, however, I didn’t explain why Bitcoin needs a blockchain in the first place, why this blockchain is shared among the different participants of the Bitcoin network, and what rules these participants have to abide to for the different operations (such as mining itself) to work smoothly across the entire network.
In this article, I aim to fill those gaps by expanding on the concepts of distributed ledger, blockchain security and consensus protocol. Although these notions will be introduced in the context of Bitcoin, they are not necessarily limited to it.
What Is A Distributed Ledger?
Let’s start by saying what a ledger is. A ledger is a record book (either physical or digital) that keeps tracks of the monetary transactions between people and/or institutions. Traditionally, this ledger is entrusted in the hands of a central authority (the bank) that takes on itself the task of updating the records whenever a new transaction is made. It goes without saying that the amount of trust that such a central authority is given is immense, and, as history showed us, not always well placed. In addition to that, an external attack aimed at tampering with this centralized ledger can result in dreadful consequences, with enormous amounts of money being stolen.
Conversely, a distributed ledger is a record book of which all the participants of a network have a copy. This characteristics alone make the distributed ledger more secure than its centralized counterpart, generally speaking. The reason is that tampering with one or even a few of its copies wouldn’t necessarily result in compromising its content irreversibly. Because it is distributed, the ledger doesn’t have a single point of failure, making it more robust to attacks. This fact is quite intuitive and represents our first step in understanding why Bitcoin has a distributed architecture. However a distributed architecture, in and of itself, does not guarantee total immunity from attacks, and we may be left wondering “how can we prevent an attack on even just one copy of the distributed ledger to eventually spread like a virus across the network and compromise all the other copies?”
To answer this question we need to introduce the notion of the consensus protocol.
The Bitcoin’s Consensus Protocol
A consensus protocol is a set of rules that regulates how the participants of a network interact with each other and resolve possible conflicts, whether these originate from outside or from inside the network itself. In the world of cryptocurrencies, there are two main consensus protocols: Proof of Work (PoW) and Proof of Stake (PoS). In this article, we will focus on PoW, which is the consensus protocol adopted by the Bitcoin network.
In general, the purpose of a consensus protocol is two-fold:
- Protecting the network from attacks (hence protecting the integrity of the ledger)
- Resolving inconsistencies between different versions of the ledger that may arise as a result of the normal operations carried out by the network itself.
In what follows I try to explain how Bitcoin’s PoW consensus protocol tackles those two issues.
Protection From Attacks
As we already saw in my article on mining, the distributed ledger of Bitcoin is structured as a chain of blocks. New transactions are recorded on the ledger by adding them to new blocks. Importantly, a new block is appended at the end of the existing chain only after solving a cryptographic puzzle that requires a predetermined amount of computing power (which in turn involves a substantial monetary cost for the required energy). The solution to this puzzle consists of finding a number, called hash, that (i) represents a cryptographic fingerprint of the new block and, at the same time, (ii) satisfies some quite strict criterion (i.e. its value must be lower than a given threshold). Whoever solves the cryptographic puzzle for the new block, hence proving to have spent some considerable amount of work, is remunerated with a certain number of bitcoins plus the fees associated with the transactions contained in the new block.
Motivated by the prospect of this remuneration, a number of different actors in the Bitcoin network (called miners) take part in a race where every participant tries to solve the cryptographic puzzle — or, as commonly said, tries to mine the new block — before the others. As soon as a miner solves the puzzle, the corresponding new block is added to the blockchain, the winning miner receives his remuneration, and all the miners (including the winning one) start the race all over again to solve the new cryptographic puzzle associated with the next new block.
Now, how does the network know whether the winning miner has counterfeited the transactions in the block that was just mined?
Let’s take one step back. Once a new block is mined, the winning miner adds the block to his copy of the ledger and broadcasts this updated version of the blockchain through the network. When the other nodes (miners or not) receive this updated version, they start performing a long series of checks on the transactions contained in the new block. If any of those transactions fails any of those checks, the block is rejected by the network, and the “winning ” miner will not be remunerated for mining the invalid block. The key concept here is that the miners have to use a lot of energy to mine new blocks in this mining race. This simple fact deters any attempt to counterfeit transactions, as this would result in the entire block being rejected by the network, hence in a substantial cost not met by any remuneration.
What if someone tried to tamper with a block that is not the last one in the chain, in an attempt for example to remove or change an old transaction?
This kind of attack would be even more difficult and expensive to carry out successfully. As we know from my article on mining, each block in the blockchain contains a reference to the hash (the fingerprint) of the previous block. If an attacker changes and re-mines an old block, the network will soon detect that the hash of such corrupted block has changed because it won’t correspond anymore to its reference on the next block. Consequently, the corrupted version of the blockchain that the attacker tries to broadcast will be rejected by the network.
The only alternative would be for the attacker to re-mine not only the target block but all the subsequent blocks as well, so as to maintain the inter-block hash consistency, and only then broadcast his version of the chain. However, re-mining all the blocks that follow the target block in the chain would require a considerable amount of time (with the work, energy, and cost associated), during which the rest of the network would continue elongating the noncorrupted version of the ledger. This eventually would result in the network having two versions of the blockchain, one shorter (the corrupted one broadcast by the attacker) and one longer (the uncorrupted chain). As we will see later, when there are two or more competing versions of the blockchain, the consensus protocol favors the longest version and removes the other(s) from the network.
The amount of energy and the associated monetary cost of undertaking such an attack would be prohibitive for a single attacker or even a small group of attackers. Also, their chances to succeed would be virtually zero, given the size and the hashing power that the Bitcoin network has reached. Consequently, when people say that the Bitcoin network wastes a lot of energy they are not making an accurate statement. What the Bitcoin network does is using a lot of energy to guarantee the security of its ledger from attacks aiming to corrupt it. It should be noted, however, that the more hashing power a group of attackers can resort to, the thicker their chances to succeed. If the attackers gather more than half of the hashing power of the entire network, their chances to succeed becomes larger than their chances to fail. This scenario is known as the 51% attack and will be treated in a dedicated article.
Resolving Inconsistencies Between Competing Versions Of The Ledger
At times it is possible that more than one version of the blockchain is present in the network. This can happen not only as of the result of an attack, as previously discussed but also as the consequence of normal, non-malicious mining activity. As mentioned before, when a miner solves the cryptographic puzzle for a new block and adds this block to his copy of the ledger, this updated version of the chain is immediately broadcast to the rest of the network. The propagation will take a couple of seconds to a couple of minutes to complete. Now:
What happens if two miners mine two new blocks independently from each other and at roughly the same time?
In this case, there would exist two competing versions of the blockchain, version A and version B, one has started to propagate before the other finished. Each of these two versions will reach the different nodes of the network at slightly different times. Some of the nodes will receive version A before version B, and some other nodes will receive version B before version A, but within a reasonably short time, all the nodes will have both versions. Importantly, those nodes who received version A first will treat version A as their favorite candidate; similarly, those nodes who received version B first will consider version B as their favorite candidate. The question now is which version should be chosen over the other and which one should be dropped. In order to resolve this conflict, the networks wait for a further new block to be added to either of the two competing chains. The version of the chain that gets elongated first through the addition of this new extra block wins the consensus of the network. The expression associated with this consensus mechanism is “The longest chain is king”. More in detail, the probability of one chain to win over the other is proportional to the total hashing power of the miners that have that specific chain as their favorite candidate. The reason is that each miner will try elongating the first chain that it receives while keeping the other on hold until a consensus is reached.
What happens to the transactions that were in the last block of the chain that loses the consensus?
That block is said to be an orphaned block, and its transactions — unless included in the winning blockchain — are released back into the Mempool, a staging area containing all the unconfirmed transactions. It is easy to see how this could potentially lead to a problem. What if someone received a good or a service that was bought through one of the transactions in the orphaned block that were released back into the Mempool? It is worth noticing that if a transaction remains in the Mempool for too long (1 to 7 days) it is eventually rejected by the network, and the funds originally spent in that transaction will remain in the bitcoin address they were sent from. This is the so-called double-spending problem. The double-spending problem is avoided by considering the transactions contained in a newly mined block unconfirmed until a certain number of extra blocks are mined and added to the chain after the block in question. This number of extra blocks is set to 6 in the Bitcoin’s consensus protocol. This means that only transactions that are at least 6 blocks deep into the blockchain are considered confirmed. As a side-note, we point out that it would take about an hour for a transaction to be confirmed, as it takes in average 10 minutes to mine a new block. The rationale of this approach in tackling the double-spending problem is that the independent elongation of both competing chains becomes increasingly unlikely as new blocks are mined before the version conflict is resolved.
This concludes our overview on how the Bitcoin’s consensus protocol allows for a high degree of resilience in the face of attacks to the network and a robust mechanism to resolve the inconsistencies that may arise between competing versions of the distributed ledger.
What About The Infamous 51% Attack? A Topic For Another Article.
The 51% attack is strongly related to many of the concepts explained in this article, such as the consensus protocol, the double-spending problem and the resolution of competing versions of the blockchain.
However, to avoid making this article too lengthy and possibly daunting, I will write a dedicated piece on this subject (now available here), explaining it in great detail. So, stay tuned until next time!
