Introduction

We started this book by grounding ourselves and understanding the seven economic inefficiencies – time to settle transactions; fees paid to third parties for non-value-added activities; data-related redundant work, rework, and reconciliation work (the three Rs); rules and regulations from governmental and nongovernmental organizations; fraud; privacy trade-off; and data security – that our current technologies have not been able to address. We attributed this to the inability of our systems to create trust among inherently untrusting transacting parties.

After reviewing the capabilities and design issues with technologies associated with cryptography , distributed systems , and peer-to-peer networking, we discussed how these technologies can be integrated to create a blockchain system that includes four major components: distributed ledger , privacy preservation , consensus , and smart contracts . After conceptually exploring how these four components of blockchain work together to address the seven economic inefficiencies, we took an in-depth look at when blockchain is a suitable technology for addressing business problems; we provided design guidelines for building blockchain-based applications and provided examples of use cases for blockchain applications in finance, healthcare, supply chain, and entertainment.

Armed with all this knowledge, we feel it is necessary and appropriate to understand at a sufficient technical depth the original cryptocurrency and blockchain implementation, Bitcoin.

Bitcoin was introduced to the world through a paper published under the pseudonym Nakamoto (2008), to coincide with the subprime financial crisis that had undermined confidence in the banking system. Though Bitcoin was not the first electronic cash system implemented, it was the first system to include a credible solution for mitigating the double spend problem (Lee, Choi & Rhee, 2003). Nakamoto created the first block, referred to as the genesis block, in the Bitcoin blockchain on Jan 3, 2009, mining 50 BTCs (Bitcoins) for himself, and then on Jan 12, 2009, sent ten BTCs to Hal Finney,¹ a cryptographer, as the first transaction on the Bitcoin blockchain. After Nakamoto shared the original paper to an email list, there were a flurry of comments from other researchers, highlighting issues that Nakamoto responded to. The email thread is archived at https://satoshi.nakamotoinstitute.org/emails/cryptography/threads/1/#014810 .

In this chapter, we will describe Bitcoin at a technical level.² We will also provide a very brief overview of Ethereum and Hyperledger and a comparison of these three blockchain implementations. We also provide a brief overview of several consensus protocols that are being considered and used instead of the consensus protocol used in Bitcoin. We will end this chapter with a very brief summary of recent emerging developments.

Bitcoin Transactions, Blocks, and Mining

Let us start by looking at the life cycle of a Bitcoin transaction by reviewing how the Bitcoin blockchain will instantiate a payment from Alex to Sonia as shown in Figure 5-1.

An illustration of the bitcoin transaction life cycle. Illustrations of a man, a woman, bitcoin, Q R code, phone with a dollar sign, private and public keys, pickaxes, and vaults are exhibited. A man sends bitcoin to a woman through Q R code. The keys will be accessed and verifications will need to occur first before the woman receives the bitcoin.

Alex starts by opening his digital Bitcoin wallet. In this wallet, Alex has all the money that he can theoretically spend. Alex now wants to spend some of his money by sending it to Sonia. To do that, he scans or copies Sonia's address. This is Sonia's public key. He then fills the amount that he would like to send, and he decides what fee he wants to give for this transaction. He then hits the proverbial send button. So look at how Alex is in control and determines the transaction fee that he wants to spend.

Once Alex has entered Sonia’s address and entered the amount of money he wants to send and the transaction fee that he is willing to pay, Alex's wallet software signs this transaction with Alex's private key, formats the transaction that will include the conditions that the receiver (Sonia) will need to meet (custody of their private key) to spend the money, and communicates this transaction to other nodes that are running the Bitcoin software.

When a Bitcoin node receives Alex’s transaction, it verifies that the transaction is formatted correctly, the addresses in the transaction are valid, and Alex met the conditions that were imposed on him before he could spend the money that he is now sending to Sonia. The node³ then adds this transaction to a list of verified transactions that it maintains.

Some Bitcoin nodes serve as “miners ” – these mining nodes package valid transactions into a block. To create a block, the mining nodes do the equivalent of solving a puzzle. They execute a computational process to find a hash that has a specific pattern. This is a process we will describe in much more detail later in the chapter. Once this hash is found, the mining process is complete, and a new block has been created. The mining node adds this new block to the blockchain on the node and transmits the new block to other Bitcoin nodes. Each node that receives the block verifies the block by ensuring that the block leads to a valid hash and all the transactions contained in the block are valid. The verified block is then added to the blockchain by each node.

Once the block with Alex’s transaction is added to the blockchain, Alex has successfully sent the money to Sonia. Sonia now has this money available in her wallet, and whenever she applies her private key, assuming that was the condition that Sonia had to meet to spend the money, she will be able to spend the money.

Let's now step back and look at the components of Bitcoin as shown in Figure 5-2.

A diagram of the Bitcoin components. It is divided into three main components, namely, Block, Blockchain, and Nodes. Block Header and List of Transactions are under Block. The connection involving Block N minus 1 Header, Block N Header, and Block N plus 1 header is under Blockchain. Wallet, Miner, Blockchain, and Network are under Nodes.

These four components are the Wallet, the Distributed Ledger, the Miner, and the Network.

The wallet software component is responsible for formatting the transaction, maintaining custody of the public and private keys of the owner, and interfacing with the distributed ledger to perform simple verification of transaction inputs.

The distributed ledger software component manages the blockchain and provides other software components an interface with the blockchain and the data in the blockchain.

The miner software component interfaces with the blockchain and executes the computational processes to discover the hash for a block.

The network software component is responsible for the peer-to-peer communication of transactions and blocks with peer Bitcoin nodes.

A Bitcoin node can choose to execute all these four software components, or it can choose just to have the wallet, or the distributed ledger, or the miner software component. A Bitcoin node can also choose one or more combinations of these software components. All Bitcoin nodes, however, need to include the network software component.

This flexibility is in concert with the peer-to-peer networking ethos of Bitcoin. Needless to say, Bitcoin software is open source software that is free to download and relatively easy to install.⁵ It does not require the purchase of any special purpose hardware. All one needs is a (any) computer and an internet connection.

A Bitcoin transaction consists of a number of inputs and a number of outputs. The inputs into a Bitcoin transaction are the Bitcoins in our wallet that we intend to spend. The outputs describe how we intend to spend these Bitcoins. The outputs from one Bitcoin transaction become inputs for future Bitcoin transactions – cementing the notion of value exchange in our economy. Later we will describe a special kind of transaction that only has outputs, but no inputs.

To understand this structuring of inputs and outputs , let’s take the analogy of cash money in our physical wallet. If in your physical wallet you had two five-dollar bills, one ten-dollar bill and one one-dollar bill. Let's say you needed to spend 17 dollars. Characterizing this transaction in the structure of a Bitcoin transaction, you will have three inputs: the ten-dollar bill and two five-dollar bills. With the denominations of money available to you, this is the only way you can spend 17 dollars. Your transaction will need at least one output, the 17 dollars that you want to spend (based on how Bitcoin transactions are structured, it does not matter that there is no 17-dollar bill), directed to the address of the person you want to send this money to. If you do not have any other output in the transaction, then the difference between your inputs and your outputs becomes the transaction fee for the miner node that will include your transaction in a block. In this case, the transaction fee will be 20 – 17 or three dollars. Let’s say you only want to pay a transaction fee of one dollar. You will then need two outputs: the 17 dollars that you want to spend and a “change” of two dollars back to you (see the following flowchart).

A flow diagram illustrates an analogy of a Bitcoin transaction. Photographs of bills amounting to 21 dollars are on the left side of the diagram. The two five dollar bills and one 10 dollar bills connect to a rounded rectangle labeled Input and then to a rounded rectangle labeled Output. Two paths are opened, namely, 17 dollars and 2-dollar change.

Before we go any further, let’s understand a specific type of transaction called the coinbase transaction. This is the transaction that only has outputs and no inputs. The coinbase transaction is the sum of the transaction fees from all the transactions in the block and a reward given to the miner for expending computational power to discover the hash needed to create a block. In this sense, the reward portion of the coinbase transaction “creates” new Bitcoins, or we can say that the coinbase transaction results in new Bitcoins being “mined.” The reward portion of the Bitcoins in a coinbase transaction therefore is also sometimes referred to as the mining reward, or the coinbase reward, or the block reward. The Bitcoins in the coinbase transaction are sent to one or more addresses specified by the miner.

For example, if a block has ten transactions and the transaction fee in each transaction is 0.01 BTC, the coinbase transaction will result in 6.35 BTCs being sent to the miner since the current block reward is 6.25 BTCs. Later in our discussion on Bitcoin equilibrium economics, we will discuss the history of block rewards.

Except for the coinbase transaction, every input in a transaction has to be an output from a previous transaction. Figure 5-3 shows how the Bitcoin blockchain creates and maintains an audit trail of all the money being spent.

A diagram of the audit trail of money on the Bitcoin blockchain. Arrows connect to the Inputs 11 to 13 of Transaction T 1. Outputs 11 and 12 connect to Inputs 21 and 22 of Transaction T 2. Output 13 connects to Input 31 of Transaction T 3. Output 21 connects to Input 41 of Transaction T 4. Outputs 22, 41 to 43, and 31 and 32 connect to U T X O.

Transaction T1 has three inputs that were outputs from other transactions, not shown in Figure 5-3. Transaction T1 has three outputs; two of these are inputs for transaction T2, and the third output is an input for transaction T3. Transaction T2 has two outputs. The first output is an input for transaction T4. The second output from transaction T2 and the two outputs from transaction T3 are not yet inputs for any transaction; these outputs have not yet been spent and are referred to as an “unspent transaction output” or UTXO. Bitcoin keeps track of all the UTXOs in the blockchain and ensures that all the inputs in new transactions are UTXOs and thus include money that can be spent. This extensive “cradle-to-grave” audit trail in Bitcoin is sometimes referred to as triple-entry accounting⁶ because we can trace money from its source to wherever it's being spent and wherever it's going to be spent. This is a nifty feature of the Bitcoin blockchain; we can actually trace our economy and all the value exchanges in one ledger, albeit the distributed ledger.

The field “txid” is the identifier or the address of the output transaction where the corresponding output for this input is located. For transaction T3 in Figure 5-3, the txid for Input 31 is T1.⁷ The field “vout” identifies the value in the corresponding output index for the input in transaction txid. For Transaction T3, the vout for Input 31 will correspond to the value in Output 13.

The field “value” represents the number of Bitcoins that are being made available for spending. This is the value that the vout field in the corresponding input will be an index to. The field “scriptPubKey” sets forth the terms or conditions under which the Bitcoins in the value field can be spent – in the language we have used in the book, this is the smart contract. Bitcoin supports very rudimentary smart contracts as we will see in a minute.

For an input to be able to spend the Bitcoins in the value field, the scriptSig field should contain what the scriptPubKey requires. In this sense, scriptPubKey is referred to as the locking script, and scriptSig is referred to as the unlocking script. Another common terminology refers to scriptPubKey as the challenge script, and scriptSig is referred to as the response script. Both these fields are specified in a language called Bitcoin Script , which is a simple Forth-like⁸ stack-based programming language. The sidebar presents a simple example of how a stack-based programming language works. The Bitcoin Script language is limited because it does not support loops and conditional branching beyond the evaluation of simple conditional tests. Bitcoin takes the Bitcoin Script program specified in scriptSig and scriptPubKey, and if the output of executing all the commands in these two programs evaluates to a TRUE, then the money can be spent. In general, the programs contain references to public keys and digital signatures. These are hashed and encrypted using secure algorithms to preserve privacy.

Next, we drill down into the detailed structure of a block header .

As shown in Figure 5-2, a block in Bitcoin consists of a list of transactions and a block header. Bitcoin nodes maintain a list of all transactions that are valid but have not yet been added to a block. These transactions are referred to as unverified transactions, and the structure that holds these transactions is referred to as the mempool. Miner nodes select a subset of these transactions to include in the block by optimizing the transaction fee they will earn within the 1MB size of a Bitcoin block.

To start the process of creating a block, the miner node selects transactions from mempool to include in that block. It then goes to the last block that was added to the blockchain and extracts all the fields from its header and hashes⁹ those fields to determine the value of the hashPrevBlock field for the block it is trying to create as shown in Figure 5-4.

Diagram of block creation process. Block N Header and Block N plus 1 Header have similar components, except for the hash P r e v Block open and close parentheses N from the Hash for Block N of the combined n version, hash P r e v Block open and close parentheses N minus 1, hashMerkleRoot, n Time, n Bits, and n Nonce components of Block N Header.

It then creates the hashMerkleRoot field . The Merkle root is the hash of all the transactions in the block. The software takes two transactions at a time and hashes them, and it keeps repeating this process until it has one hash as shown in Figure 5-5. This hash is called the Merkle root hash, and it represents the information contained in all the transactions. So in a way the Merkle root process reduces the volume of all the transactions into this hash. A change in any transaction will result in the hash Merkle root changing the block header, making the hash of the block invalid.

A binary tree diagram of the Merkle root hash transaction. The H A to H P data will form a group of two with the nearby data until they reach the big rounded rectangle above labeled H A to P underneath the label ROOT. The groups on the left side mostly form the data inside the big rounded rectangle, as evidenced by highlighted borders.

The fields nversion and nBits do not have to be computed by the miner node. They are global configuration variables available to the miner. The field nTime is system generated.

The miner node is now ready to start the mining process. The mining process involves generating a hash. The input to the hashing function is the values of the fields nversion, hashPrevBlock, hashMerkleRoot, nTime, nBits, and nNonce. The value for nNonce is set by the miner. If the computed hash has the number of leading zeros specified by nBits, then the miner has discovered the hash for the block. If the resulting hash does not have the appropriate leading number of zeros, then the miner can change the value of nNonce and recompute the process. nNonce is the only field in the block header that the miner can change to search for a valid hash. The iterative process of changing nNonce to recompute the hash until a valid hash is found is the mining process in Bitcoin. This mining algorithm in Bitcoin is referred to as proof of work (POW) .¹⁰

We have learned previously in Chapter 2 that computing a hash is a very efficient computational process. However, searching through a large search space of the possible values for nNonce can take substantial computational power. This computational requirement is important for the security and trust of Bitcoin. Since discovering the hash for a block requires extensive computational power, any change to a block will require the rediscovery of the hash for that block and all other blocks that were added after this block. This reduces the likelihood that any changes to committed blocks will be attempted. As more blocks are subsequently chained to this block, the likelihood that any change to a block will be attempted decreases even further.

While discovering the hash for a block is computationally expensive, verifying that the hash is valid is a computationally efficient process. Once a miner node has determined the nNonce value for a block header, it transmits the block (header and all the transactions) to its peer nodes. When a node receives the block, it recomputes the hash (once) to ascertain its validity and confirms that all the transactions are also valid. Once the block has been validated, it chains it to the block with the matching hashPrevHeader.

When a node has received a valid block and has added it to its blockchain, then if it was involved in the mining process, it stops that process, resets its mempool, and selects a new subset of valid transactions to start the process of creating the next block.

At any given time, several Bitcoin miner nodes are working on creating a new block. Let’s assume that two nodes are working on creating Block N. We shall call these new blocks as candidate blocks, Block N(A) and Block N(B). Let’s assume that Block N(A) completes first and broadcasts its block. Another node – let’s call this node Node Q – receives Block N(A) and adds it to its blockchain as shown in Figure 5-6 at time T = t. All nodes in the Bitcoin network do not receive Block N(A) at the same time due to network latency. In fact, the node that is working on creating Block N(B) does not receive Block N(A) and proceeds to finish creating Block N(B) and broadcasts this block to its peer nodes. When Node Q receives Block N(B), it will attach this block also to Block N as shown in Figure 5-6 at time T = t + 1. The blockchain now has a fork. This type of fork is called a natural fork because it is created as an artifact of the natural functioning of the blockchain network. At time T = t + 1, we cannot make a determination which of the two blocks, Block N(A) or Block N(B), will eventually end up as being part of the blockchain. At time T = t + 2, Node Q received Block N(A)+1. Block N(A)+1 is added to Block N by Node Q as shown in Figure 5-6.

A diagram of the natural Bitcoin forks. At Time T, the Block minus 2, Block N minus 1, and Block N open and close parentheses A connection is observed. At Time t plus 1, Block N s open and close parentheses A and B a are observed. At Time t plus 2, Block N open and close parentheses A plus 1 from Block N open and close parentheses A is observed.

At time T = t + 2, the likelihood that Block N(A) will eventually be part of the blockchain is higher than the likelihood that Block N(B) will be part of the blockchain. At any given time, Bitcoin considers the longest chain of blocks to be the valid blockchain. Each node tries to extend the longest chain. This illustration is consistent with the BASE semantics of eventual consistency that were discussed in Chapter 2.

Similar to the description in the preceding text, we should also acknowledge that it is possible that there are nodes who might receive Block N(A)+1 before they receive Block N. If a node receives a block that it cannot add to the blockchain because the hashPrevBlock does not match the blocks it has in its chain, then it saves the block as an orphan block. If at a later time the node receives Block N(A), then at that time, both Block N(A) and Block N(A) + 1 will be added to the blockchain.

At any given time, there is a high probability that the leaf nodes of a blockchain will not be consistent. The notion of eventual consistency reassures us that eventually all the nodes will be consistent and the likelihood that nodes will be consistent away from the leaf nodes of the blockchain is high.

Based on the aforementioned, it is prudent for a transaction to not be considered settled until it is in a block to which a few more blocks have been chained. For transactions with large amounts, a rule of thumb is to wait for six blocks to be chained to a block before considering a block to be immutably added to the blockchain.

Let’s translate this for a merchant who has decided to accept Bitcoin as a form of payment. The merchant will share their address (public key) that their prospective customers can use to direct payments to them. If a customer buys from this merchant at time t, they will initiate a transaction; at some point after time t, this transaction will get added into a candidate block; and at some point, after that, this candidate block will get added to the blockchain. Once a merchant has confirmation that the block with the transaction has been added to the blockchain, they can perhaps wait for a few more blocks to be added to this block, and then they can consider the transaction fully committed. At this point, the merchant can ship the goods to the customer.¹¹

The Bitcoin software is designed to add a new block to the blockchain every ten minutes. This was a design decision and represented a trade-off to settle transactions as quickly as possible while also ensuring that the blockchain on individual nodes got out of sync for as little time as possible. How does the Bitcoin software ensure that this design goal is achieved?

After the creation of every 2016 blocks, the Bitcoin software calculates the average time it took for the miners to create a new block. If this time is greater than ten minutes, then it reduces the difficulty level represented by nBits so that miners can create blocks faster. To reduce the difficulty level, the Bitcoin software reduces the number of leading zeros required in the hash that the miners have to find. On the other hand, if the average time to create a block is less than ten minutes, then the Bitcoin software is programmed to automatically increase the difficulty level represented by nBits. The Bitcoin software increases the number of leading zeros that should be in a valid hash, making the hash harder to find.

This section has provided an in-depth description of how Bitcoin works. While the technical details were simplified, no important technical details were omitted. Next, we examine the economics of Bitcoin.

Bitcoin Economics

In the previous section , we have described the structure of transactions in Bitcoin, how transactions are validated, the mining process used to create blocks, and the process used to add blocks to the blockchain. We also discussed how when a miner creates a block, they are compensated through the coinbase transaction that includes transaction fees and a block reward. The block reward results in the "creation," "minting," or "mining" of new Bitcoins.

One of the design goals that Nakamoto had when the Bitcoin blockchain network was created was to limit the supply of Bitcoins. This was motivated by the point of view that the power governments have over the money supply is abused by expanding the supply of money. This was considered inflationary, and it was felt excess supply can lead to the debasement and devaluation of a currency. So not only did Nakamoto intend Bitcoin to be free from government intervention, but in order to protect the value of Bitcoin, Nakamoto limited the supply of Bitcoins.

The Bitcoin software is designed such that only 21 million Bitcoins will ever be minted.

The smooth and trustworthy operation of the Bitcoin network depends on mining nodes volunteering to expend their compute power, their electricity, and other resources to create new blocks. Because miners expend resources, they are compensated with the block reward through the coinbase transaction. When Bitcoin was launched in 2008, this block reward was 50 Bitcoins. The Bitcoin software “halves” this reward after the creation of 210,000 incremental blocks or approximately every four years as shown in Figure 5-7.

An illustration of the Bitcoin block reward halving for miners. A value of 50 B T C is observed in 2008, 25 B T C in 2012, 12.5 B T C in 2016, and 6.25 B T C in 2020. In 2140, the projected compensation will only be from transaction fees.

In 2012, the block reward was halved to 25 Bitcoins. In July of 2016, it was reduced to 12.5 Bitcoins, and on May 11, 2020, at around 3 p.m. Eastern time, the reward was reduced to 6.25 Bitcoins. By 2140, we will reach the 21 million Bitcoin limit in the Bitcoin software. From that point onward, there will be no more block reward for miners. The only compensation that will be available to miners for the resources they expend on mining will have to come from transaction fees.

When there is no more block reward, we say that Bitcoin has reached equilibrium economics.

Let us do some simple mathematics to understand how much the mining process might be costing the economy. We already know that we create a block every ten minutes. That means we create six blocks an hour; that means we create 144 blocks a day; and that translates to 52,560 blocks being created each year as shown in Figure 5-8.

Illustration of Bitcoin economics. The timeline above exhibits 1, 6, 144, and 52560 blocks for 10 minutes, 1 hour, 1 day, and 1 year. respectively. The timeline below exhibits tilde 10 M 50 per block, tilde 5 M 25 per block, 2.5 M 12.5 per block, 1.25 M 6.25 per block values between 2008 and 2012, 2012 and 2016, 2016 and 2020, and 2020 and beyond.

With the block reward per block of 50 Bitcoins per block for the first 210,000 blocks, we can calculate that approximately 10 million Bitcoins were mined for the first four years. Approximately 5 million Bitcoins were mined for the next four years and so on. At the current US dollar-to-Bitcoin conversion rate, this is equivalent to tens to hundreds of billions of dollars in wealth being created for miners.

That's a lot of money. That's how big this Bitcoin economy can be, and it kind of makes you pause and think whether this is sustainable. Is this something that can go on? Will volunteer miners continue to create blocks if the only compensation they receive is transaction fees? Will the transaction fees be low enough to support value exchange? Will I ever buy coffee and donuts using Bitcoin? What will happen to the US dollar–Bitcoin exchange rate once we are at equilibrium economics?

Well, these are things that we still have to figure out, but having an understanding of this economics as to how much Bitcoins we create and what the value of the Bitcoins is makes this a very interesting topic .

Consensus Protocols

In the previous section, we learned about the proof-of-work consensus mechanism used by Bitcoin. We noted that proof of work was an extremely computationally expensive consensus mechanism. The proof of work guarantees immutability at the cost of scalability and perhaps sustainability. In this section, we will review other consensus mechanisms such as proof of stake, delegated proof of stake , and proof of authority.

In proof of stake , nodes stake a certain amount of their currency or wealth to serve as validators (nodes that have the functionality to create new blocks).¹² These nodes take a certain amount of their wealth (the units of the wealth vary depending on the blockchain) and set it aside, or reserve it, for the privilege of serving as validators. This stake creates an incentive for these nodes to make sure that the blockchain is not compromised and stays immutable. The theory is that if the blockchain were to be compromised, these nodes would lose the stake that they have reserved.

Of all the nodes that stake a certain amount of currency, a validator is selected using a deterministic algorithm. This deterministic algorithm can change depending on the blockchain implementation. An example of a deterministic algorithm can be selecting validators in a round-robin fashion starting with the node with the highest stake. Other deterministic algorithms could select validators by weighting their stake, so nodes with a higher stake will be selected more frequently than nodes with a lower stake. Whichever node is selected then creates the block. There is no race for solving the puzzle or finding a hash with a certain number of leading zeros like we had in proof of work. In proof of stake, validators do not receive a mining or block reward; they merely take the transaction fees in all the transactions.

The advantages of a proof of stake are that it is more energy efficient, it consumes less electricity, and it doesn't require expensive specialized hardware, and we are already at equilibrium economics where everything is working based solely on transaction fees rather than on a block reward and a transaction fee.

The risks with proof of stake are that selecting validators can be problematic. Some consensus protocols try to insert some kind of randomness in the selection of validators, but this can be gamed and that creates risks that the blockchain may be compromised. Staking cannot also be uniquely guaranteed. What this means is we are staking based on public keys. We might have the same individual with many multiple keys doing the staking. So they are creating a lot of centralized control on the blockchain, and that can be a problem. Finally, staking doesn't always guarantee higher performance in terms of transaction throughput. We save electricity; we save computational power, but that in some cases does not necessarily translate into better performance in terms of transactions per second.

As an improvement over proof of stake, another consensus mechanism called delegated proof of stake has been invented.

In delegated proof of stake , we take all of the nodes that have a stake or have staked something for validation, and they make a proposal to the community of what they want in return for doing the validation or doing the mining and what they're willing to guarantee in terms of their performance for doing the validation.

The network then votes on which of these proposals should be selected as nodes who can do validation, and then among those selected, the algorithm selects a panel of validators, and then among those in the panel, some deterministic way is used for selecting the validator.

Now the delegate or whoever does the validation can get a reward if they said that they wanted a reward in the proposal and they were voted into the panel by the community. The delegated proof of stake creates a certain level of democracy in the voting process. We have some improvement over proof of stake, but some of the disadvantages still stay.

In general, both proof of stake and delegated proof of stake move us closer to centralization, but they give us some advantages in terms of energy consumption and sustainability.

Another type of consensus mechanism is proof of authority . In proof of authority, what is done is the validators who want to be selected establish their identity. They decide that they no longer will be anonymous; and once they have established that identity and now we know uniquely that this address refers to this identity, we can follow either the proof-of-stake method or the delegated proof-of-stake method. But what we've done is by confirming their identity, they have created disincentives for them for colluding or compromising the blockchain.

This is an exciting area of research within the blockchain and distributed computing community. There are many more consensus mechanisms, such as proof of elapsed time and proof of history, being proposed than the three we have briefly described in this section . Oyinloye, Teh, Jamil, & Alawida, M. (2021) provide an overview of alternate consensus protocols.

Ethereum

Part 2 of this book takes a deep dive into Ethereum and Enterprise Ethereum, explaining how blockchain business applications can be developed using Ethereum. In this section, we provide a brief overview of Ethereum and the implementation differences with Bitcoin. Ethereum is an alternate implementation of blockchain, different from Bitcoin in some very important ways.

In the previous section, we saw that in Bitcoin, the terms and conditions underlying transactions had to be very simple. Bitcoin wanted to keep the smart contract very simple because complicated smart contracts had risks of high computation costs and a higher likelihood of software defects.

The founder of Ethereum, Vitalik Buterin,¹³ who was involved early on in the Bitcoin community, felt that while Bitcoin was great digital money, the scripting language, Bitcoin Script, that was used to specify smart contracts was too weak. In addition to value exchange payments facilitated by Bitcoin, Buterin envisioned a class of decentralized applications that would be enabled by the features of distributed ledgers, privacy preservation, consensus, and smart contracts. Buterin outlined a vision of a smart contract language that would be a lot more robust and enable the creation of sophisticated decentralized applications on top of the blockchain. He wanted to create a Turing complete language for smart contracts that supported loops and complicated conditional branching. Ethereum includes a very easy JavaScript like language, called Solidity, to enable the development of smart contracts that could represent real-world business logic associated with transaction terms and conditions.

The availability of Solidity has led to Ethereum being referred to by some as programmable money or programmable currency. The blockchain applications developed with Ethereum are sometimes referred to as dApps or distributed applications.

In addition to the introduction of Solidity , a Turing complete programming language, Ethereum has also simplified and strengthened the tracking of transactions and spending. The Bitcoin software tracks every transaction, its inputs, its outputs, and the unspent transaction output (UTXO) from all transactions even if we have to go all the way back to the original genesis block.

In Bitcoin, if one transaction produced an output of one Bitcoin and another transaction produced another output of half a Bitcoin and a third transaction produced an output of another half of a Bitcoin, we couldn't combine these three to create two Bitcoins in our wallet without creating a transaction and paying transaction fees for that transaction. Bitcoin tracks the UTXOs for these three transactions separately as shown in Figure 5-9.

An illustration of the comparison between Bitcoin U T X O s versus Ethereum accounts. The illustration on the left exhibits five files with half Bitcoin symbols failing to form 2 complete Bitcoin symbols. The illustration on the right exhibits three files with two halves and complete Ethereum symbols succeeding to form 2 complete Ethereum symbols.

Instead of only tracking transactions, Ethereum created a structure for accounts where transactions owned by an account could be brought together and aggregated. This created other advantages where we could theoretically segregate and hold different kinds of assets or tokens in our account that are all based on the Ethereum native token or the Ethereum currency (Ether).

The currency behind Ethereum is Ether. The lower denominations of Ether are Finney, Szabo, and Wei as shown in Figure 5-10. Finney, Szabo, and Wei are all luminaries in the cryptocurrency world. They were all involved early on in the Bitcoin community.

An illustration of the Ether denominations. From highest to lowest, the denominations are Ether, Finney, Szabo, and Wei. Each is accompanied by the Ethereum symbol, shrinking in size the lower the denominations become.

Ethereum has two types of accounts: accounts that are externally owned and contract accounts. Externally owned accounts are the most common. They have a balance, and they're held in wallets. Contract accounts store and execute smart contract code. Contract accounts also have an associated balance representing the balance held by the associated smart contract for the programmable money.

One of the key achievements of Ethereum was the creation of the Ethereum Virtual Machine (EVM) or the World Computer. The Ethereum Virtual Machine sits on top of the blockchain and functions as a compiler that takes smart contract software written in Solidity and compiles it for the EVM into what is called EVM bytecode as shown in Figure 5-11. It is this bytecode that is executed on the blockchain. The blockchain network is going to expend computational power to run the smart contract, and all the nodes are going to have to execute the smart contract; the owner of the transaction executing the smart contract pays Gas in Ether for the execution of the smart contract.

Illustration of Ethereum Virtual Machine. A computer is on the leftmost side with an illustrated gas dispenser with the Ethereum logo exhibited on the monitor. It connects to a file labeled Smart Contract, Ethereum Compiler, a file labeled E V M Bytecode 10010010110110, a cloud labeled E V M with four monitors attached, and six vault-like figures.

The vision with Ethereum was the creation of distributed applications or dApps. This vision has been realized, and there are currently thousands of Ethereum dApps in production driving the excitement around blockchain. The creation of a dApp involves the development, testing, and deployment of smart contracts and a front end that interacts with the blockchain. Figure 5-12 shows the architecture of a dApp and examples of development tools that are available to dApp developers.

A diagram of the d App architecture and development tools. The Truffle logo and the Google Chrome and MetaMask logos are on the top and right sides of the Web Browser, respectively. The Ethereum Virtual Machine and Development Blockchain are inside the d App rectangle with Web 3 Frontend. The Drizzle, Infura, and Ganache logos are on the right.

Hyperledger

Hyperledger is the blockchain implementation that is used to develop enterprise business applications between transacting parties such as those in a supply chain.

The Hyperledger blockchain solution is provided and managed by the Linux Foundation. This is a collaborative effort created to advance cross-industry blockchain technologies for enterprise business applications. Founded in February 2016, there are now more than 200 member organizations in the Hyperledger collaborative.

Hyperledger has an open source, open standards, open and transparent governance mechanism. This is a governance model that many in the software world are familiar and comfortable with because it is the governance used by Linux and Apache, two well-known operating systems and web development platforms, respectively, for a long time.

Hyperledger comes with frameworks and tools that are highly modular technologies that can be integrated together.

Let's look at some of the tools and frameworks that are available with Hyperledger (please also see Figure 5-13):

• Hyperledger Aries, Indy, and URSA are tools and frameworks used to manage cryptographic identity and communicate these identities across the blockchain network.

• Hyperledger Fabric is the core distributed ledger within the Hyperledger ecosystem, and for Hyperledger Fabric you can write smart contracts using the Go programming language. You can also plug in different consensus mechanisms.

• Hyperledger Besu is an Ethereum client built for the Hyperledger ecosystem. Here, you can write smart contracts using the Solidity programming language and create private or public permissioned blockchains.

• Hyperledger Sawtooth is a framework and tool set to help you build blockchain applications using the proof of elapsed time or the practical Byzantine fault-tolerant consensus mechanisms.

• Iroha is specifically designed for IoT-based blockchain applications, and it uses the C++ programming language.

• Hyperledger Cactus is a blockchain integration tool where applications running on different blockchains can communicate and operate together.

• Cello is an operational dashboard that can be used to track multiple blockchain applications.

• Hyperledger Explorer provides a very simple web-based interface to query the data in the blockchain.

• Hyperledger Quilt is a Java implementation for an interledger payment mechanism. Here, you can work with crypto payments as well as fiat payments. Fiat payments or fiat currencies are currencies that are issued by sovereign governments .

Illustration of the Hyperledger ecosystem. The components have their own logos next to their name, under the Hyperledger umbrella, inside a square. Aries, Besu, Fabric, Indy, Iroha, and Sawtooth are exhibited above. The eleven projects underneath are Avalon, Burrow, Cactus, Caliper, Cello, Explorer, Firefly, Grid, Quilt, Transact, and Ursa.

Hyperledger provides a very rich developmental tool set that can be used to build enterprise business applications. All applications so far built using Hyperledger use a permissioned blockchain. Many of these applications are private permissioned, but they can also be public permissioned.

Bitcoin, Ethereum, and Hyperledger Comparison

In this section, we will compare Bitcoin, Ethereum, and Hyperledger and then take a quick tour to cover exciting developments that have been happening in blockchain over the past few years.

Bitcoin was made for payments. It's native for transferring value from one party to another. Ethereum was built as a general-purpose development platform where you could facilitate payments but also build distributed applications. Hyperledger was also designed as a general-purpose enterprise application development tool.

Bitcoin is governed by Bitcoin Improvement Proposals (BIP) , where an attempt is made to get consensus across all the Bitcoin nodes, and once a certain percentage of Bitcoin node agrees to a proposed change, consensus is deemed, and the community agrees to move to the next version. Those who don't want to agree can go their own way by creating a hard fork.

The Ethereum blockchain also uses an Ethereum Improvement Proposal (EIP) , and there is a core group under the leadership of Vitalik Buterin that drives that process.

The Hyperledger governance is based on the Linux foundation where people and companies come together as a collaborative and offer up their services as projects, frameworks, and tools.

The native currency for Bitcoin is BTC, and lower denominations are in Satoshis. The native currency of Ethereum is Ether, and lower denominations are Finney, Wei, and Szabo. Hyperledger doesn't have a native currency. Its purpose is less payment based and more data sharing and trust enabling.

The mining reward for Bitcoin is currently 6.25 BTCs. We've seen that this was halved from 12.5 BTCs in May 2020. Ethereum has a mining reward of 2 Ethers. Hyperledger does not have the notion of a mining reward.

The core data structure within Bitcoin is a transaction. In Ethereum, the core data structure is an account where outputs of transactions are consolidated. The underlying data structure within Hyperledger is an attribute-value database.

Bitcoin uses a proof-of-work consensus mechanism. Ethereum uses a proof-of-work consensus mechanism as well, and they are planning a move to a proof-of-stake mechanism. As we saw when we talked about Hyperledger, the consensus mechanism within Hyperledger is pluggable.

Bitcoin is a permissionless public blockchain . Ethereum implementations are available as permissionless or permissioned. In the more well-known setting, where we build distributed applications, we use the permissionless public implementation of Ethereum. If you want to build enterprise applications, you can use an implementation of Ethereum called Enterprise Ethereum, and this can be permissioned public or permissioned private.

Hyperledger is permissioned and provides scalability. We have many nodes in Bitcoin; however, the performance is low. In Ethereum, again, we have many nodes, and the performance is also low. Usually for each Hyperledger blockchain application implementation, you do not have many nodes, but you have very high performance and high throughput.

The smart contracts in Bitcoin with the Bitcoin Script programming language are very limited. In Ethereum, you have Solidity, which is a Turing complete programming language. The native Hyperledger Fabric gives you a Turing complete smart contract language with the Go programming language. Other frameworks in Hyperledger support smart contracts in other programming languages.

Emerging Blockchain Implementations

Let's now look at some of the exciting new work that is happening within blockchain. Both Bitcoin and Ethereum are currently suffering from network congestion, high transaction fees, as well as scalability issues. Bitcoin has released over the past 36 months two Layer 1 improvements. Layer 1 changes are to the core blockchain layer of a blockchain implementation, whereas Layer 2 changes are to the integration layer of a blockchain implementation as described in Chapter 4. Bitcoin has made data structure improvements to how data in transactions are stored, how scripts or smart contracts within a transaction are stored, and how scripts are hashed and communicated over the Bitcoin network. Layer 2 innovations have included developments such as the Lightning Network. The Lightning Network allows parties to transact offline but then commit to the main blockchain network an aggregation of their offline transaction value. This improves scalability.

Ethereum also has Layer 2 innovations such as Arbitrum, which were done outside the Ethereum core group. Arbitrum lets you roll up transactions out of Ethereum and write the aggregate result back into the Ethereum mainnet, improving scalability and reducing transaction fees.

Polygon was originally a side chain from Ethereum, but now it is used to develop multichain Ethereum systems. This also helps with scalability.

Cardano is what some people call a next-generation blockchain. It has a currency called Ada and a consensus mechanism called Ouroboros , which is an innovation on proof of stake. It has the smart contract development platform, Plutus, which is similar to the Ethereum Virtual Machine, based on the Haskell programming language.

Solana is another next-generation blockchain where a consensus mechanism called proof of history is used. This consensus mechanism enables very high transaction throughput.

Finally, Polkadot like Polygon is an up-and-coming multichain system.

Blockchain research and development continues at a torrid pace, and many exciting developments are in process.

Chapter Summary/Key Takeaways

Sidebar – Stack-Based Programming Language

Figure 5-14 demonstrates the workings of a stack-based programming language for a simple program: 4 5 OP_ADD 12 OP_SUB 3 EQUAL.

An illustration of a stack-based programming language. Four sets of stacks are exhibited. The first has 4, 5, O P underscore ADD, 12, O P underscore S U B, 3, and EQUAL. The second has 9, 12, O P underscore S U B, 3, and EQUAL. The third stack has 3, 3, and EQUAL. The fourth has TRUE.

Each element in this program is pushed onto a stack as shown in the figure. Elements are popped off the stack until we get to an operator. The operator is applied to the popped elements, and the result is pushed back on to the stack. For our program, first, 4 is popped off the stack; then 5 is popped off the stack; when OP_ADD is popped off the stack, it is applied to 4 and 5, that is, they are added together since the OP_ADD operator performs addition, and the result 9 is pushed back on to the stack. Next, we pop 9 and then 12, and when the operator OP_SUB is popped, 9 is subtracted from 12, and the result 3 is popped back on to the stack. Next, we pop 3 and then 3; when EQUAL is popped, we check if 3 equals to 3; the result TRUE is pushed back on to the stack. When TRUE is popped, it becomes the final output for our simple program.

Operators such as OP_ADD, OP_SUB, and EQUAL are referred to as opcodes in Bitcoin Script.¹⁴

Quiz Questions

References

Nakamoto, S. (2008) Bitcoin: A peer-to-peer electronic cash system. https://bitcoin.org/bitcoin.pdf

Lee, H., Choi, M., Rhee, C., (2003) Traceability of double spending in secure electronic cash system, 2003 International Conference on Computer Networks and Mobile Computing, 2003. ICCNMC 2003. 2003, pp. 330–333, doi: 10.1109/ICCNMC.2003.1243063

Antonopoulos, A. (2017). Mastering Bitcoin: Programming the open blockchain. (2nd. ed.). O'Reilly Media, Inc.

Yaga, D., Mell, P., Roby, N., Scarfone, K. (2018) Blockchain technology overview. National Institutes of Standards and Technology. October 2018. https://doi.org/10.6028/NIST.IR.8202

Oyinloye, D. P., Teh, J. S., Jamil, N., & Alawida, M. (2021). Blockchain Consensus: An Overview of Alternative Protocols. Symmetry, 13(8), 1363. MDPI AG. Retrieved from https://doi.org/10.3390/sym13081363