In the last few chapters, we have studied some of the mathematical concepts of cryptography which are pertinent to blockchains and cryptocurrencies. Now that we have all of this arcane theory in our heads, we are now ready to move to the heart of the matter, the construction of blockchain and cryptocurrency applications.
In this chapter and the chapters that follow, we will examine the components which are required to build blockchain applications. Components such as blockchains, Merkle trees, peer-to-peer networks, transactions, mining, and so forth. As we proceed, I will be building a cryptocurrency called Helium from scratch in Python. The chapters that follow will typically be paired. The first chapter will expose the theory of the particular component under examination. The following chapter will develop the Python code that implements this component. The entire code pertaining to this component will also be presented in an appendix of this book. If you are primarily interested in the underlying theory, you can safely ignore the code implementation chapters.
Since this is a book about learning blockchain concepts, I use the simplest possible Python code; lucidity is favored over brevity or Rubyesque magic. If you are an experienced Python developer, you may find the code non-idiomatic and verbose. This is deliberately so by intention, in order to keep the barrier to this book at the lowest level possible. Secondly, I have tried to annotate the code with extensive inline comments, even at the risk of being redundant and explaining the obvious. Our friend is the KISS principle (keep it simple, stupid). It has frequently been observed that nature favors simplicity over complexity.1 As a software developer, I have had very bad experiences reading the code written by other programmers, so I want to spare you the anguish and pain of such an experience.
Alright, let us start.
Why Write a Cryptocurrency in Python?
A cryptocurrency can be developed using a variety of languages. For Helium, I considered C++, Go, and Python. The main advantage of coding Helium in C++ would be that C++ has exceptional runtime performance and can produce very high-quality production code. Equally important, we can use C++ class constructs, data encapsulation, polymorphism, and other object-oriented design principles to develop Helium in a modular way. I discarded C++ as a candidate, primarily because this is a book about learning and implementing concepts, and C++ would have restricted readership. C++ is a complex language, and developing Helium in C++ would have required a readership that is very proficient in the language.
I like Go a lot.2 Go has been developed by programmers who were closely associated with the C language. Go is simple and easy to learn. The influence of the C programming language is manifestly evident in Go. In essence, Go is C for the Web. Go is a very minimalist language; it eschews complexity and follows the C metaprogramming principle that there should be only one way to do a particular thing. Go has many very cool features. It is a strictly typed, compiled language and is thus very fast. Like C, Go has a full-featured and high-quality standard library.3 It has an implementation of concurrency which is hands down better than that in any other language, excepting C++. The characterization of Go as a systems language for infrastructure applications is a canard. Go is, in fact, a general programming language, much like C++ and Python. Go is not an object-oriented language, and in lieu thereof it offers structs and interfaces. I eliminated Go as the development language for Helium on the basis that very few developers are acquainted with this language, and thus, its usage in this book would restrict readership.
When a programming language pole vaults into the rare stratosphere of the four most popular languages,4 joining heavyweights such as C++, Java, and C, you just know that it has something going for it. Python is a powerful and expressive interpreted language that is simple to learn. Python has a huge library of software packages and is thus used in a large spectrum of cutting-edge areas, such as machine learning, neural networks, finance, virtual reality, genomics, and so forth. Python is a favorite language of scientists and academics who are not programmers. We will develop Helium in Python. Note that once you understand the architecture and algorithms typically used in blockchain applications, you can develop your application in C++, Go, or any other language for that matter. You can, of course, re-code Helium in your preferred language.
One final note is in order; my endeavor is to make the Helium code largely self-contained, and therefore, I will shun the extensive use of Python libraries.
The Computer Is the Blockchain
In 1995 or thereabouts, John Gage opined that the network is the computer. Gage’s hypothesis was that, sometime in the future, desktop operating systems such as Windows and desktop applications would be replaced by applications running on wide area networks. It was a remarkable observation considering that it was made in 1996 when the Internet was still in a nascent stage. If blockchain technology fulfills its promise of being a foundation stone for Internet applications, we will be able to truthfully assert that the computer is the blockchain. So what exactly is a blockchain?
Understanding Blockchains
A Blockchain
Each block contains data which is specific to the domain of the blockchain application. Furthermore, each block is immutable once it is created. Each block is also tamper-proof; its data cannot be changed by a malicious interloper. Aside from the first block, each block is related to its previous block through a cryptographic relation. The blocks are ordered, meaning that they follow each other in a fixed, linear order. This ordered, immutable collection of blocks with cryptographic relations is called a blockchain.6
As more blocks are created, they are added to the head (right side) of the blockchain. In a canonical blockchain application, the blockchain keeps on increasing in size as more blocks are added on the right side. For example, the Bitcoin blockchain is over 250 GB and growing.
Canonical blockchain applications maintain a distributed blockchain. This means that there are entities on the Internet which have a copy of the blockchain. These copies need not be identical with each other, in which case it is the responsibility of each entity to synchronize its copy of the blockchain. This synchronization requires a distributed consensus mechanism that resolves the differences between these copies. Take note that this synchronization does not require any centralized entity. Distributed consensus algorithms are a very important part of blockchain applications, and we will be examining distributed consensus closely in later chapters. Since the blockchain is distributed, a blockchain is sometimes described as a distributed ledger.
Distributed consensus has important implications. There is no need for a central authority to maintain the integrity of the blockchain. This means that a blockchain is permission-less and open to the world at large. Distributed consensus solves one of the major hurdles in the creation of a distributed currency, the double-spend problem. This problem refers to a scenario where a person who owns a certain quantum of a cryptocurrency attempts to spend it twice. In centralized fiat money systems, it is trivial to prevent double-spending. However, it is a major hurdle when we are creating a distributed cryptocurrency. The foregoing discussion will become crystal clear when we get into the mechanics of actually creating a cryptocurrency.
In canonical blockchain applications such as Bitcoin, time is not an important variable. Transactions are not ordered by time, and there is no central timekeeper or any need to synchronize the times of blockchain entities. Transactions can occur in any order, and the distributed consensus algorithm will sort everything out. This is a very powerful idea. By way of contrast, in a fiat money banking system, time is very important and transaction validity is typically tied to which transaction occurred first.
Blockchains are typically meant to survive over time, so they are usually persisted to a hard disk or some other media. Lastly, in the typical blockchain application, members of the public are allowed to examine the blockchain, but this need not necessarily be so.
The Genesis Block
The very first block of a blockchain is called the genesis block. It is typically initiated by the application to bootstrap the blockchain. For example, in a cryptocurrency application, the genesis block will typically include an initial distribution of the currency.
The Blockchain Database
You may be inclined to conclude that a blockchain should be implemented using a database such as PostgreSQL, Cassandra, or Redis. This is a bad practice. A blockchain application should keep its implementation at the simplest and most transparent level that is possible, especially since cryptocurrency applications involve money. A database implementation introduces too much complexity. What do we do if the data in the database is corrupted or the database crashes?
The canonical blockchain application simply persists the blocks in a blockchain as a simple text or binary files. The underlying operating system is used to write blocks to disk. A block is a write once read many times file.
This does not mean that a blockchain application does not use databases. For example, Bitcoin uses LevelDB databases to index the blocks and maintain unspent amounts. In a blockchain application, these databases always play a role ancillary to the blockchain, and the data in these databases can always be built from scratch from the blockchain.
Hash Pointers Are the Secret Ingredient
A Block in a Blockchain
Hash Pointer Structure
Points to the location of the previous block
Contains the message digest of the previous block’s data and hash pointer
The pointer to the location of the previous block is the address of the previous block. For example, this pointer can be a path to a block file, a location in memory, or an index into a list. The pointer depends upon how the blocks are represented. Since the genesis block does not have a previous block, we simply set its hash pointer to null.
For the message digest computation, we can use SHA-256.
Thus, given a hash pointer, we can retrieve the data and message digest of the previous block. This permits us to verify that the data in the previous block has not been tampered with.
Blockchain Structure
Blockchain Immutability
It is quite easy to detect if a blockchain has been tampered with. Consider the blockchain represented in Figure 6-4. Suppose further that the hash pointer for each block (except for the genesis block) includes the SHA-256 message digest of the previous block’s data and hash pointer.
Suppose that a malicious party changes the data or the hash pointer in the second block. An entity that is verifying that the blockchain has not been altered will compute the SHA-256 message digest of the second block. It will then compare this value with the SHA-256 message digest contained in the hash pointer of the third block. Since these two digests do not match, the entity will conclude that either the second block has been altered or the message digest in the third block has been altered.
Since the malicious party has tampered with the second block, he will also have to change the cryptographic hash in the third block so that it matches the computed hash of the second block. But then the cryptographic hash in the fourth block will not match the computed hash for the third block. This changing of hash pointers will have to be effected for all of the blocks subsequent to the block which was initially changed. Furthermore, since a blockchain is a distributed data structure, the changed blocks will have to be transmitted to all of the other nodes in the blockchain network so that they can amend their copies of the blockchain. These nodes will detect the tampering and decline to change their copies.
Making a Simple Blockchain
The SHA-256 message digest of a block will be computed by converting the list element’s value to a JSON string and then computing the hexadecimal value of the SHA-256 message digest of this string.
and so forth.
One observation to be made is that since this blockchain is a list, the pointer to the previous block can be represented simply as the index of the previous list element.
The Blockchain Universe
So far, we have taken a deep dive into the theory of blockchains; it’s time to look at some of the applications of blockchains. As a general principle, we can state that any application that requires distributed consensus for decision-making is potentially a suitable candidate for the implementation of a blockchain.
The very first use of a blockchain was in the cryptocurrency Bitcoin, and cryptocurrencies still constitute a major application domain for blockchains. Another major domain is smart contract cryptocurrencies, such as Ethereum. These cryptocurrencies permit the specification of contracts which specify conditions under which value will be transferred. These contracts are specified through a programming language that a blockchain virtual machine understands.7 Projects, such as Ripple, are concerned with automating portions of the financial services industry with the objectives of reducing the costs of transactions and the time required for their completion.
In Chapter 2, we looked at the Brave browser which proposes a radical model for the distribution of digital advertising. The Brave project enhances privacy on the Internet and also rewards all of the stakeholders in the distribution of digital advertising: the content creators, the people viewing this content, and the browser which hosts the content. All these stakeholders are rewarded with units of the BAT cryptocurrency.
Another application domain is games and digital content. TRON is an example of such a project. TRON is designed to democratize the distribution of such content by eliminating gatekeepers who host this content. The TRON project uses the BitTorrent protocol to distribute and retrieve such content.8
Other application domains for blockchain technology include supply chain management, tamper-proof voting systems, distributed id systems, and permission-less escrow systems. There are, of course, many more potential application domains for this technology.
Conclusion
In this chapter, we have defined a blockchain and discussed its theoretical foundations and essential characteristics. We concluded by discussing some of the application domains for blockchain technology.
In the next chapter, we will start our main project, the construction of a cryptocurrency called Helium. Our first task will be to program a blockchain for Helium.
References
Antonopoulos, Andreas. Mastering Bitcoin, 2nd ed., O’Reilly Media Inc., 2017
Iyer, Kedar and Dannen, Kris. Building Games with Ethereum Smart Contracts, Apress, 2018