Placement of Trusts

All these boil down to one key concept – placement of trust . And that is, we place our trust on a central body. Think about it, in our everyday life, we place our trusts on banks, and we place our trusts on our governments.

Even for simple mundane day-to-day activities, we place our trusts in central bodies. For example, when you go to the library to borrow a book, you trust that the library would maintain a proper record of the books that you have borrowed and returned.

The key theme is that we trust institutions but don’t trust each other. We trust our government, banks, even our library, but we just don’t trust each other. As an example, consider the following scenario. Imagine you work at a cafe, and someone walks up to you and offers you a US ten-dollar bill for two cups of coffee. And another person who offers to pay you for the two cups of coffee using a handwritten note saying he owes you ten dollars. Which one would you trust? The answer is pretty obvious, isn’t it? Naturally you would trust the US ten-dollar bill, as opposed to the handwritten note. This is because you understand that using the ten-dollar bill, you can use it elsewhere to exchange for other goods or services, and that it is backed by the US government. In contract, the handwritten note is not backed by anyone else (except perhaps the person who wrote it), and hence it has literally no value.

Now let’s take the discussion a bit further. Again, imagine you are trying to sell something. Someone comes up to you and suggests paying for your goods using the currencies as shown in Figure 1-1.

Would you accept the currencies as shown in the figure? Here, you have two different currencies – one from Venezuela and one from Zimbabwe. In this case, the first thing you consider is whether these currencies are widely accepted and also your trust in these governments . You might have read from the news about the hyperinflation in these two countries, and that these currencies might not retain its value over time.

And so, would you accept these currencies as payment?

Trust Issues

Earlier on, I mentioned that people trust institutions and don’t trust each other. But even established economies can fail, such as in the case of the financial crisis of the United States in 2007–2008. Investment bank Lehman Brothers collapsed in September 2008 because of the subprime mortgage market. So, if banks from established economies can collapse, how can people in less developed countries trust their banks and governments? Even if the banks are trusted, your deposits may be monitored by the government, and they could arrest you based on your transactions.

As we have seen in the example in the previous section, there are times when people don’t trust institutions, especially if the political situation in that country is not stable.

All these discussions bring us to the next key issue – even though people trust institutions, institutions can still fail. And when people lose trust in institutions, people turn to cryptocurrencies . In the next section, we will discuss how we can solve the trust issues using decentralization, a fundamental concept behind cryptocurrency.

Solving Trust Issues Using Decentralization

Now that you have seen the challenges of trust – who to trust and who not to trust, it is now time to consider a way to solve the trust issues. In particular, blockchain uses decentralization to solve the trust issue.

In order to understand decentralization, let’s use a very simple example that is based on our daily lives.

Example of Decentralization

To understand how decentralization solves the trust issue, let’s consider a real-life example.

Imagine a situation where you have three persons with DVDs that they want to share with one another (see Figure 1-2).

The first thing they need to do is to have someone keep track of the whereabouts of each DVD. Of course, the easiest is for each person to keep track of what they have borrowed and what they have lent, but since people inherently do not trust each other, this approach is not very popular among the three persons.

To solve this issue, they decided to appoint one person, say B, to keep a ledger, to hold a record of the whereabouts of each DVD (see Figure 1-3).

This way, there is a central body to keep track of the whereabouts of each DVD. But wait, isn’t this the problem with centralization? What happens if B is not trustworthy? Turns out that B has the habit of stealing DVDs, and he in fact could easily modify the ledger to erase the record of DVDs that he has borrowed. So, there must be a better way.

And then, someone has an idea! Why not let everyone keep a copy of the ledger (see Figure 1-4)? Whenever someone borrows or lent a DVD, the record is broadcast to everyone, and everyone records the transaction.

We say that the record keeping is now decentralized! We now have three persons holding the same ledger. But wait a minute. What if A and C conspire to change the records together so that they can steal the DVDs from B? Since majority wins, as long as there is more than 50% of the people with the same records, the others would have to listen to the majority. And because there are only three persons in this scenario, it is extremely easy to get more than 50% of the people to conspire.

The solution is to have a lot more people to hold the ledger, especially people who are not related to the DVDs sharing business (see Figure 1-5).

This way, it makes it more difficult for one party to alter the records on the ledger, and that in order to alter a record, it would need to involve a number of people altering the record all at the same time, which is a time-consuming affair. And this is the key idea behind distributed ledger, or commonly known as blockchain.

Blockchain As a Distributed Ledger

Now that we have a better idea of a distributed ledger , we can now associate it with the term – blockchain. Using the DVD rental example, each time a DVD is borrowed or returned, a transaction is created. A number of transactions are then grouped into a block. As more transactions are performed, the blocks are linked together cryptographically, forming what we now call a blockchain (see Figure 1-6).

Chaining the Blocks

Before we discuss how blocks in a blockchain are chained together, we have to discuss a key concept in blockchain – hashing. A hash function is a function that maps data of arbitrary size to data of fixed size. By altering a single character in the original string, the resultant hash value is totally different from the previous one. Most importantly, observe that a single change in the original message results in a completely different hash, making it difficult to know that the two original messages are similar.

We are now ready to discuss how blocks in a blockchain are chained together. To chain the blocks together, the content of each block is hashed and then stored in the next block (see Figure 1-8). That way, if any transactions in a block is altered, that is going to invalidate the hash of the current block, which is stored in the next block, which in turn is going to invalidate the hash of the next block, and so on.

Observe that when hashing the content of a block, the hash of the previous block is hashed together with the transactions. However, do take note that this is a simplification of what is in a block. Later on, we will dive into the details of a block and see exactly how transactions are represented in a block.

Storing the hash of the previous block in the current block assures the integrity of the transactions in the previous block. Any modifications to the transaction(s) within a block causes the hash in the next block to be invalidated, and it also affects the subsequent blocks in the blockchain. If a hacker wants to modify a transaction, not only must he modify the transaction in a block but all other subsequent blocks in the blockchain. In addition, he needs to synchronize the changes to all other computers on the network, which is a computationally expensive task to do. Hence, data stored in the blockchain is immutable, for they are hard to change once the block they are in is added to the blockchain.

Up to this point, you have a high-level overview of what constitutes a blockchain and how the blocks are chained together. In the next section, you will understand the next important topic in blockchain – mining.

Mining

Whenever you talk about blockchain or cryptocurrencies, there is always one term that comes up – mining. In this section, you will learn what is mining, and what goes on behind the scene.

Mining is the process of adding blocks to a blockchain. In a blockchain network, such as the Bitcoin or Ethereum network, there are different types of computers known as nodes. Computers on a blockchain that add blocks to the blockchain are known as miner nodes (or mining nodes, or more simply miners).

We will talk about the different types of nodes later on in this course, but for now, we want to talk about a particular type of node, known as the miner node . The role of the miner node is to add blocks to the blockchain.

But how are blocks added?

Broadcasting Transactions

When a transaction is performed , the transaction is broadcasted to the network (see Figure 1-9).

Each mining node may receive them at different times. As a node receives transactions, it will try to include them in a block. Observe that each node is free to include whatever transactions they want in a block. In practice, which transactions get included in a block depends on a number of factors, such as transaction fees, transaction size, order of arrival, and so on.

At this point, transactions that are included in a block but which are not yet added to the blockchain are known as unconfirmed transactions. Once a block is filled with transactions, a node will attempt to add the block to the blockchain.

Now here comes the problem – with so many miners out there, who gets to add the block to the blockchain first?

The Mining Process

In order to slow down the rate of adding blocks to the blockchain, the blockchain consensus protocol dictates a network difficulty target (see Figure 1-10).

In order to successfully add a block to the blockchain, a miner would hash the content of a block and check that the hash meets the criteria set by the difficulty target. For example, the resultant hash must start with five zeros and so on.

As more miners join the network, the difficultly level increases, for example, the hash must now start with six zeros and so on. This allows the blocks to be added to the blockchain at a consistent rate.

But, wait a minute, the content of a block is fixed, and so no matter how you hash it, the resultant hash is always the same. So how do you ensure that the resultant hash can meet the difficulty target? To do that, miners add a nonce to the block, which stands for number used once (see Figure 1-11).

The first miner who meets the target gets to claim the rewards and adds the block to the blockchain. It will broadcast the block to other nodes so that they can verify the claim and stop working on their current work of mining their own blocks. The miners would drop their current work, and the process of mining a new block starts all over again. The transactions that were not included in the block that was successfully mined will be added to the next block to be mined.

Proof of Work

The process in which blocks are mined and added to the blockchain is known as the Proof of Work (PoW). It is difficult to produce the proof but very easy to validate. A good example of Proof of Work is cracking a combination lock – it takes a lot of time to find the right combination, but it is easy to verify once the combination is found.

Proof of Work uses tremendous computing resources – GPUs are required, while CPU speed is not important. It also uses a lot of electricity, because miners are doing the same work repeatedly – find the nonce to meet the network difficulty for the block.

A common question is why you need to use a powerful GPU instead of CPU for mining? Well, as a simple comparison, a CPU core can execute 4 32-bit instructions per clock, whereas a GPU like the Radeon HD 5970 can execute 3200 32-bit instructions per clock. In short, the CPU excels at doing complex manipulations to a small set of data , whereas the GPU excels at doing simple manipulations to a large set of data. And since mining is all about performing hashing and finding the nonce, it is a highly repetitive task, something that GPU excels in.

Immutability of Blockchains

In a blockchain, each block is chained to its previous block through the use of a cryptographic hash. A block’s identity changes if the parent’s identity changes. This in turn causes the current block’s children to change, which affects the grandchildren, and so on. A change to a block forces a recalculation of all subsequent blocks, which requires enormous computation power. This makes the blockchain immutable, a key feature of cryptocurrencies like Bitcoin and Ethereum.

As a new block is added to the blockchain, the block of transactions is said to be confirmed by the blockchain. When a block is newly added, it’s deemed to have one confirmation. As another block is added to it, its number of confirmation increases. Figure 1-12 shows the number of confirmations that the blocks in a blockchain have. The more confirmations a block has, the more difficult it is to remove it from the blockchain.

Types of Nodes

Before we address the rationale for storing the Merkle root in the block header, we need to talk about the types of nodes in a blockchain network. Figure 1-14 shows the different types of nodes in a blockchain network.

As we mentioned in our earlier sections, computers connected to the blockchain network are known as nodes. We have discussed the role of mining nodes, whose key responsibility is to gather transactions into blocks and then try to add the block to the blockchain by finding the nonce that satisfies the network difficulty. Mining nodes are also known as full nodes .

The purpose of a full node is to ensure the integrity of the blockchain and people running full nodes do not get rewards. On the other hand, mining nodes are rewarded when they add a block to the blockchain.

An example of a full node is a desktop wallet, which allows users to perform transaction using the cryptocurrency.

Each full node has a copy of the entire blockchain. Full nodes also validate every block and transactions presented to it.

Besides full nodes, there are also light nodes. Light nodes help to verify transactions using a method called simplified payment verification (SPV). SPV allows a node to verify if a transaction has been included in a block, without needing to download the entire blockchain. Using SPV, light nodes connect to full nodes and transmit transactions to the full nodes for verifications.

Light nodes only need to store the block headers of all the blocks in the blockchain. An example of a light node is a mobile wallet, such as the Coinbase mobile app for iOS and Android. Using a mobile wallet, a user can perform transactions on the mobile device.

Finally, let’s now see the use of representing the transactions as a Merkle root in the block header in the next section.

Merkle Tree and Merkle Root

The list of transactions in a block is stored as a Merkle tree. A Merkle tree is a tree data structure in which every leaf node is the hash of a transaction and every non-leaf node is the cryptographic hash of the child nodes. Figure 1-15 shows how the Merkle root is derived from the transactions.

As you can see from the figure, each transaction is hashed. The hash of each transaction is hashed together with the hash of another node. For example, the hash of transaction A (H_A) is combined with the hash of transaction B (H_B) and hashed to derive H_AB. This process is repeated until there’s only one resultant hash. This final hash is known as the Merkle root. In the preceding example, because H_E doesn’t have another node to pair with, it’s hashed with itself. The same applies to H_EE.

The Merkle root is stored in the block header, and the rest of the transactions are stored in the block as a Merkle tree. In the earlier discussion, I mentioned about full nodes. Full nodes download the entire blockchain, and there’s another type of node (known as light nodes) that downloads only the blockchain headers. Because light nodes don’t download the entire blockchain, they’re easier to maintain and run. Using a method called simplified payment verifications (SPV), a light node can query a full node to verify a transaction. Examples of light nodes are cryptographic wallets.

Uses of Merkle Tree and the Merkle Root

By storing the Merkle root in the block header and the transactions as a Merkle tree in the block , a light node can easily verify if a transaction belongs to a particular block. This is how it works. Suppose a light node wants to verify that transaction C exists in a particular block:

• The light node queries a full node for the following hashes: H_D, H_AB, and H_EEEE (see Figure 1-16).

• Because the light node can compute H_C, it can then compute H_CD with H_D supplied.

• With H_AB supplied, it can now compute H_ABCD.

• With H_EEEE supplied, it can now compute H_ABCDEEEE (which is the Merkle root).

• Because the light node has the Merkle root of the block, it can now check to see if the two Merkle roots match. If they match, the transaction is verified.

As you can see from this simple example, to verify a single transaction out of five transactions, only three hashes need to be retrieved from the full node. Mathematically, for n transactions in a block, it takes log₂n hashes to verify that a transaction is in a block . For example, if there are 1024 transactions in a block, a light node only needs to request ten hashes to verify the existence of a transaction in the block.