To understand a distributed system, we need to first distinguish it from traditional centralized systems. Traditional centralized systems consist of two main components: the client and the server. In the simplest setup, the client is the one who makes a request for getting a job done, and a server is the one who gets it done. This was how web 1.0 operated; the one we started calling the World Wide Web. For example, you placed a search request on Google search engine, and it gave you back a set of web links and summarized results.

Now, if two clients want to communicate between each other, they have to place request via the server, which serves as the middleman. A second example might be, for instance, if I send you a message from the client app of my mobile, this message is pushed to the WhatsApp server, which then notifies your client app about my message. Once you see my message, your client app sends back an acknowledgement signal in terms of a blue double tick to my client app, again using the WhatsApp server. This is how the present internet operates and we call it web 2.0, the advent of the social network. In both of these examples, we can see the centralized system works just fine. In Figure 1.1, this centralized setup is represented by the left-side lego block setup. The aggregated middle blocks represent the server, whereas the circumferential isolated blocks represent the clients. However, these centralized servers are generally owned by business organizations and can be influenced by a criminal entity or central authority to leak private data while the clients communicate. To overcome this fundamental flaw, peer-to-peer networking (web 3.0) came into practice (for example, BitTorrent). These were distributed systems, as depicted in the right of Figure 1.1, where each node can be a client or server or both and are not distinguishable from other nodes. Even though these systems were good at privacy, they faced challenges like the Byzantine Generals' Problem and the CAP theorem, which we will discuss in the subsequent sections.

Imagine a time during the dark ages, where a pirate ship is under attack. There are 200 pirates aboard the pirate ship surrounded by six army ships of 50 warriors each, who've anchored, surrounding the pirate ship. Each army ship is commanded by a captain. The 300 warriors can easily overpower the 200 pirates aboard the pirate ship. However, if they don't all attack simultaneously, there is a very real risk that the warriors will be outnumbered by the pirates and they'll go on to lose the battle.

So, how can the captains all agree on the same time to attack the pirate ship? These days, we'd simply need a quick group video-conference call, and the captains would have to agree to attack at 22:00 hours (10 PM).

However, back in the dark ages, things were a little more complicated:

• The 22:00 attack message could only be passed on by a sailor on a small boat. He has to sail around each army ship, visiting each captain in turn to confirm.
• Any captain may be a traitor and in league with the pirates in the pirate ship.

Captain 1 decides to attack at 22:00. He sends his sailor out with the message (22:00 attack) to deliver to Captain 2. Upon arrival, Captain 2 reads the message, notes the time of the attack, and sends a message that also says 22:00 attack. He sends the sailor on to share the message with Captain 3. However, we have a problem. Captain 3 is a traitor. He wants the attack to fail. So, when he gets the message, he rips it up and replaces it with a new message that says 21:00 attack (9 PM). The sailor continues unaware. Captain 4 now receives a message saying 21:00 attack. He notes the time, signs the message saying 21:00 attack and sends this on to Captain 5, who then sends the same message to Captain 6. Now, the message has gone around everyone, but we have a problem. The dishonest captain has disrupted the result. We now have three captains (4, 5, and 6) with 150 warriors attacking the pirate ship at 21:00. Expecting others to join them, they instead get outnumbered and overpowered by the 200 pirates. The victorious pirates now stream out of the pirate ship and join forces with the treacherous Captain 3. Suddenly, the two remaining captains (1 and 2) have only 100 warriors and find themselves fighting 200 pirates plus 50 traitors. Unfortunately, the pirates and traitors win.

Captain 1 wants to send the same message (attack at 22:00). However, this time, there are two new rules he must obey:

• He must spend 10 minutes preparing any new message for it to be valid
• He must include the history of every previous message in every new message

So, let's see what happens this time. As before, Captain 1 sends the message (22:00 attack) with the sailor on the boat. This time, however, it is different for Captain 2, because he knows two things for certain:

• The message must have taken 10 minutes to prepare
• There are no previous messages, so it must be the truth (even if Captain 1 is a traitor and put in the wrong time, it doesn't matter; if the majority of captains followed this suggestion and went with a 22:00 attack time, they would still outnumber those in the pirate ship and win the battle)

So, now it is time for Captain 2 to send a message. As required, he spends 10 minutes preparing the new message and he embeds Captain 1's message into his own. The sailor then sets off with this message (now in fact, it is two messages chained together as the second has the first embedded within it). Now it gets to Captain 3.

Remember, he's the traitor. So, what does he do? Last time, he changed the message to 21:00 attack so that captains 4, 5, and 6 would attack early and get overpowered. Now, however, he can't because, under the new rules, he has only 10 minutes to prepare a message for Captain 4. He has two options:

1. Cheat by changing the message to 21:00 attack. To do this, he needs to (a) spend 10 minutes creating his message and then (b) spend an extra 2 x 10 minutes working to create replacement 21:00 attack messages from Captains 1 and 2 to embed these into his message and carry out this 30 minutes of work within the next 10 minutes to avoid the other captains knowing that he's a traitor.
2. Admit defeat and prepare the 22:00 attack message during those 10 minutes.

In other words, every captain has got no more than 10 minutes to provide the next captain with something that would take more than 10 minutes to fake if they were trying to be dishonest. If they can't deliver it within 10 minutes, everyone knows they're dishonest and ignores them, rendering their attempts to mislead others useless.

Before stating the CAP theorem, let's try to understand consistency, availability, and partition tolerance using a real-world problem.

As a married person, I know how pathetic a person's life can become if they forget important dates like the birthday and anniversary of their spouse (in most cases, the husband is the culprit, but that is a separate discussion). One of my friends, let's call him Kaushik, saw an opportunity in this and opened up a start-up, HappySpouse.com, to address this issue. During a typical business day, Kaushik (K) and his customer (C) would have the following conversation:

K: Hello from HappySpouse.com. How may I help you?

C: Hey, I want you to remember my wife's birthday.

K: Sure! When is it?

C: September 3.

K: (Writing it down on a page exclusive for C.) Stored. Call me any time to remind you of your spouse's birthday again!

C: Thank you!

K: No problem! Your credit card has been charged with $0.05.

Kaushik's idea was so simple, needed nothing but a notebook and phone, yet so effective that it rolled off like an avalanche. VC firms started pouring in funds. He also started getting hundreds of calls every day. That's where the problem started. Now, more and more of his customers had to wait in the queue to speak to him. Most of them even hung up, tired of the waiting tone. Besides, when he was sick for a day and could not come to work, he lost a whole day of business. Not to mention all those unsatisfied customers who wanted information on that day. So, Kaushik decided to scale up and bring in his wife to help him.

He started with a simple plan to solve his availability to customers:

1. He and his wife both got an extension phone
2. Customers still dialed the same number
3. A PBX routed the customer calls to whoever was free at that moment

A few weeks went by smoothly. One fine morning, he got a call from one of his old customers, Joey (J):

J: Hello, am I speaking to Kaushik from HappySpouse.com?

K: Hi Joey, great you remembered us. What can I do for you?

J: Can you tell me when our anniversary was?

K: Sure. 1 sec, Joey (looking up in his notebook, there was no entry on Joey's page). Joey, I have only your spouse's birthday here.

J: Holy cow! I just called you guys yesterday! (Cuts the call!)

How did that happen? Was Joey lying? Kaushik thought about it for a second and the reason hit him! Yesterday, did Joey's call reach his wife? He goes to his wife's desk and checks her notebook. Sure enough, it's there. He tells this to his wife and she realizes the problem too. What a terrible flaw in this distributed setup! This setup was not consistent!

Now, they decided that whenever either of them got a call to note, they would update each other's notebook. In that way, they would both have the same up-to-date information. Even if one of them was offwork, the other would email the updates so that the person could come the next day and jot down the updates. That way, they would be both consistent and available.

However, fate has its own plans. Due to this hectic schedule, Kaushik himself forgot his wife's birthday. Now his wife was angry with him and would not share any updates, creating a partition. To patch things up, Kaushik had to make himself unavailable to clients and make up to his wife.

Let's look at the CAP theorem now. It states that when we are designing a distributed system, we cannot achieve all three of consistency, availability, and partition tolerance. We can pick only two of CAP and sacrifice the third, that is CA, AP, or CP, where:

• Consistency: Once a customer updates information with HappySpouse.com, they will always get the most up-to-date information when they call subsequently, no matter how quickly they call back
• Availability: HappySpouse.com will always be available for calls as long as any one of them (Kaushik or his wife) reports to work
• Partition tolerance: HappySpouse.com will work even if there is a communication gap/couple-fight between Kaushik and his wife!

Consensus is a problem that arises in distributed systems that are replicating a common state, such as data in a database. It is the task of getting all processes in a group to agree on some specific value based on the votes of each process. The consensus algorithm cannot just invent a value. All processes must agree upon the same value and it must be a value that was submitted by at least one of the processes.

In the previous example of HappySpouse.com, to prevent the consistency problem, we can have a run-around clerk, who will update the other notebook when one of the notebooks is updated. The greatest benefit of this is that he can work in the background, and an update doesn't have to wait for the other person to update. Formally speaking, in such distributed systems, one node updates itself locally, and a background process synchronizes all the other nodes accordingly. The only problem is that we will lose consistency for some time.

For example, a customer's call reaches Kaushik's wife first, and before the clerk has a chance to update his notebook, the customer calls back and it reaches him. Then, the customer won't get a consistent reply. So, we have to safely assume a customer won't forget things so quickly that he calls back in a few minutes in order for this eventually consistent solution to work.

Also, if we look back into the winning strategy of the Byzantine Generals' Problem, we see that a consensus among various captains needs to be achieved in order to distinguish a true message from a lie.

Later in this chapter, we will get back to this with the proof-of-work algorithm employed by bitcoin on a blockchain. As for now, it is good enough to be aware of two facts on consensus:

• Raft and Paxos algorithms were some early attempts to solve the consensus problem. Both Paxos and Raft managed to solve the consensus problem using majority votes in a cluster. They differed mostly by their focus. Raft aimed to provide a complete practical algorithm, whereas Paxos provided the building blocks of a consensus algorithm.
• There are two main ways of finding consensus in a distributed ledger system: the practical byzantine fault tolerance algorithm (PBFT) and algorithms for blockchains. Blockchain algorithms can be further classified into the proof-of-stake algorithm (PoS) and the proof-of-work algorithm (PoW). The PoS also has a special form called the delegated proof-of-stake algorithm (DPoS).

Cryptography is the art and science of hiding a message. It is more of an art than a science. Science here just acts as a mere tool to transform an artistic imagination into a mathematical algorithm.

In this section, we will concentrate only on two specific concepts from this immensely vast subject, which will help us to understand the true essence of a blockchain. These are the hash function and Merkle tree. Please note that these are used for verifying integrity, rather than hiding anything.

Let's now understand what a hash function is and how it works. Figure 1.3 illustrates a hash function. As we can see in this figure, a hash function is a one-way mapping:

That means that it can take an input (the input is usually a large sequence of bits; it can be a movie, a song, an e-book, a picture, or any digital data) and produce a fixed-size value as output, often much smaller than the input size. However, if I change only one bit in this input, the output will be completely different. This is property number one of the hash function and makes the hash function very much collision resistant. The second property is that there is no way to figure out the input if I only have the output. So, if I have the input to a hash function I can always get an output, no matter how big the input is. However, if I only have an output of a hash function, there is no way to reconstruct the input from it, because hash functions are unidirectional. Also note that the output hash is a fixed-length random bit sequence but, when it gets displayed on the terminals, it gets converted to a hexadecimal format and looks alphanumeric.

You might wonder what happens if I take the output of a hash function and feed it back into its input. Nice try! We still get a completely different sequence of fixed-length bits. And guess what, now we cannot even reconstruct the original output. This new output is not just a hash. It is a hash of a hash. It is called a hash chain and is denoted by h(h(x)) or h2(x), where x is the original string of bits.

The next thing we need to understand is what a Merkle tree is. A Merkle tree is a data structure where each layer is a combination of hashes from its child layer. Generally, a Merkle tree is represented using a binary hash tree, where each node has at most two children. The branches are the hash of the combined hashes of the two children. This process of re-hashing the concatenation of the child nodes to create the parent node is performed until the top of the tree is reached, called the root hash or the Merkle root. Let me show you how it works with Figure 1.4:

Let's say we have two hash values (2ad5 and 3ce9). Please note that 0x represents a hexadecimal notation, but I will omit the prefix for simplicity. To get the next value in the tree, I combine them to a single hash and get the value 23a2. As I told you before, this hash is a one-way function. So, by combining 2ad5 and 3ce9 we can always get the hash value 23a2, but if we only have 23a2 there is no way to figure out the original values. I now do the same hashing with 0ab4 and 1bd4 and combine them to get the value 01e3 and then hashing 01e3 and 23a2 to get the root value 0123. So, this root value will be a representation of this data structure, but there would be no way for me to go back and figure out all the individual values in the tree, let alone the original data blocks D0, D1, D2, and D3. That would be very difficult.

Let's say I am the owner of the data block D2 in the preceding diagram. I also acquire, from the distributed consensus, the root hash, which in our situation is 0123. I ask the distributed system to prove to me that my record D2 is in the tree. What the server returns to me are the hashes 3ce9, 01e3, and 0123. Using this information, the proof is somewhat as follows (please note that, here, the + sign denotes a combiner, and not addition, and that the proof is basically a verification process):

1. Hash of D2, which we compute to get 2ad5
2. Hash of [2ad5 + 3ce9] from which we compute 23a2
3. Hash of [01e3 + 23a2] from which we compute 0123

Since we know the root hash from our distributed consensus, the proof validates that 2ad5 exists in the tree. So does our record D2. Furthermore, the system from which you have obtained the proof is proving to you that it is an authority because it is able to provide valid hashes so that you can get from D2 to your known root hash 0123. Any system pretending to validate your request would not be able to provide you with the intermediate hashes. Since you're not giving the system the root hash, you're just telling it to give you the proof, the distributed consensus just can't invent the proof because it doesn't know your root hash; only you know that. Moreover, in order to verify the proof, very little information about the tree is revealed to you. Furthermore, the data packet that is needed for this proof is very small, making it efficient to send over a network and to make the proof computation. Now, if I claimed that I had D4 in place of D2, I could not have proved it with the data 3ce9, 01e3, and 0123 because the hash of the hash of D4 combining 3ce9 would have been a completely different number, that is, not 23a2 as we got in Step 2. We would have eventually got a different root hash, which would contradict the consensus root hash value of 0123.

Now that we understand what a hash, a hash chain, and a Merkle tree are and how they work, we can proceed to understand a blockchain which will be discussed in the next section.

From a software developer's perspective, a blockchain is just a giant Merkle tree. Take a moment now, pause your reading. Let this information sink in. I repeat with another layer of clarity.

A blockchain is a giant Merkle tree, where each new block embeds the hash of the previous block as well as the root hash of the present block-action, eventually forming a chain of hash-blocks. It might be not very obvious, but such a Merkle tree structure does not require a central server; each block can come from physically separate clients. Hence, a blockchain is also a distributed system. I can feel you are starting to feel confused right now. Just look at Figure 1.5 to mitigate some of your confusion. We will discuss timestamp and nonce later, when we explore inside a block.

You might argue that blockchain looks more like a linked list with a Merkle tree hanging on each block, but it would be a fundamentally wrong perception because here we cannot backpropagate to the original data value. A more appropriate statement would be that it is very difficult to backpropagate to get back the actual values x0, x1, x2, and x3, using the root hash of the block. Yet the advantage lies in the fact that these hashes are immutable. You cannot revert a blockchain, in principle, once it is formed.

Before discussing the trader's perspective of a blockchain, it would be a good time to realize what a bitcoin blockchain is and what an Ethereum blockchain is and how they are different in principle and practice. For beginners who are reading the preceding lines, I would like to state that, in blockchain community, it is an agreed standard to represent a cryptocurrency with small cap while representing the technology, protocol, and ecosystem of that currency with large cap. So, bitcoin or Ethereum represents the virtual cryptocurrency, while bitcoin or Ethereum represents the tech stack, protocol, and ecosystem surrounding the respective virtual cryptocurrency.

Let's look at the over-simplified diagram of blockchains in Figure 1.6. All blockchains have some kind of root value R. So, when I send 2 bitcoins (BTC) to a friend, I actually do a transaction. Let's call it T1.

This transaction, T1, a transfer of value, will be hashed together with the previous root R and create a new root, R1. So, this is almost like a Merkle tree (in fact, it is a Merkle tree) where the data blocks, that is, the leaves of the Merkle tree, are storing bits of data representing a transaction, which in turn get hashed into a new root hash. Then, another transaction T2 comes in and it gets hashed with root R1 to form yet another new root R2. This is how a bitcoin blockchain works, keeping a permanent store of all transactions which have taken place since the start of the original hash root (also called the genesis block). Now, if we try to cheat the system by stating that my transaction T1 was of 100 BTC (in reality, we sent only 2 BTC), the fake transaction will be checked by blockchain community, by hashing it with R that will generate an entirely new root hash value R'1, completely different from R1. This rise in contradiction will falsify our 100 BTC claim. This is what makes bitcoin as a cryptocurrency so elegant in preventing the double-spend problem.

An interesting aspect that now arises is how an Ethereum blockchain works. We saw that a bitcoin blockchain is a decentralized application for transferring value and verifying transactions. An Ethereum blockchain, on the other hand, can even execute codes. As software developers, most of you might be familiar with states of a code in runtime.

In simple terms, it is the configuration of a piece of code at any given instant of time. An Ethereum blockchain acts as a decentralized application platform, which stores each state of a code while in execution (that is, during runtime) and creates a hash chain out of it. Again, take a moment to let this concept sink in. So, when we execute a code on an Ethereum blockchain, each and every state (S1, S2) of the executed code will merge with the roots R' and R'1 respectively and will be publicly visible. Any type of code glitches will be captured and stored on the public blockchain and will remain there for eternity. In the future, we could see all the previous states of all the codes that ever got executed on the Ethereum blockchain. An obvious question arises about how such blockchains can ever scale, with the exponential growth of runtime logs when many such codes will run across the world over the Ethereum platform. Think about it.

Meanwhile, we move on to understand a blockchain from a trader's perspective. A trader of financial instruments or a banker views currency as something which serves the three key functions:

• Medium of exchange
• Store of value
• Unit of account

Cryptocurrency for a trader is no different from physical currencies, even though it has only a virtual presence and has no central authority of control. Blockchain, from a trader's perspective, is viewed as a distributed ledger, where the distributed consensus serves as the apparent central authority for such virtual currencies.

A Blockchain being immutable serves as a permanent record of any transfer of value that has ever taken place in the past, while cryptographically preserving the privacy of the identity of clients at both ends of any transaction.

It needs to be emphasized that both of these perspectives of a blockchain are not mutually exclusive. These apparently different perspectives are not like comparing apples with oranges. They both exist in unison and synergize to give rise to a decentralized economy, which we will explore in later chapters. Now, you can refer to Figure 1.7, to understand how a blockchain can be positioned within the financial-technological ecosystem:

Let's now discuss the contents of a block of bitcoin blockchain. This will help us in understanding and comparing Ethereum, which we will take up in Chapter 2, Grokking Ethereum. A block is a very interesting concept, because a block gives blockchain its properties. It is the basic element of a blockchain.

Therefore, it is important to know what a block consists of. Figure 1.8 lists the basic parts of a bitcoin block. First of all, we have a magic number, also called bitcoin network ID.

It is four bytes long and is an arbitrary number that signals that this is a bitcoin block. The magic number is not something specific to bitcoin. All nodes communicate using transmission control protocol.

In TCP, different types of data packets use different magic numbers to identify themselves. It is like declaring our gender while filling out a passport to identify ourselves as male, female, or transgender. In our context, a block is actually a sequence of 0 and 1. When any machine reads such a data sequence and it encounters the binary version of 0xD9B4BEF9, it will identify the data as a bitcoin block. So, this number is the same for all bitcoin blocks. Now, why was 0xD9B4BEF9 chosen for bitcoin blocks?

As per the comments found in the bitcoin main.cpp files (bitcoin implementations were written in C++ language), the magic number was chosen in such a way that the characters are rarely used in upper ASCII, not valid as UTF-8, and produce a large four-byte integer at any alignment.

Next, we have the block size which is also four bytes and tells us how long this block is with all of its transactions. As of July 2017, the size of an entire bitcoin block can be a maximum of 1 MB. We then have the block header, which is 80 bytes and it is the most interesting part; we will talk about its contents in a short while. The next one is the transaction counter, which is an integer that tells us how many transactions this block has and next we have a list of transactions, which simply contains all the transactions that are in this block.

For example, if we have the transaction counter as 20, we have 20 transactions in the block. The transaction counter is one to nine bytes. So, these were the basic parts of the block.

So, let's go ahead and look up what the bitcoin block header consists of. Here, in Figure 1.9, we have the header parts. The header has a version that simply tells us which version of the format we are on currently.

For example, the current bitcoin version is 2.

Now, if for some reason a bitcoin block from the version 1 client comes, it will be ignored by blockchain. In the future, there might be a change in the size and format of a bitcoin block. Then, we would have to change this version in each block to keep them relevant in blockchain. The version number is four bytes. Next, we have 32 bytes of hash of the previous block. This represents the hash of the previous block header. This field is very powerful because, in case of any unforeseen catastrophic hack that breaks away blockchain, we can generate the entire blockchain if even one single block remains preserved. Next, we have the hash of the Merkle root. These 32 bytes store the hash of the Merkle root of all the transactions associated with the present block as depicted earlier in Figure 1.5 as Tx_Root. We saw that the body of the block contains transactions. These are indirectly hashed through the Merkle root. So, hashing a block with one transaction takes exactly the same amount of effort as hashing a block with 10,000 transactions. Next, we have a four-byte timestamp field, which updates every few seconds to keep the current timestamp. The next field of four bytes, called the target, is another interesting field. This field tells us the level of difficulty of this current block. To understand how the target field works, we need to understand how the four-byte nonce field works, where the word nonce stands for nonsensical incrementer, which leads us to our next section on mining and forking.

When a miner mines a block, what does the miner actually do? What the miner does is take the hash Merkle root of the current block and then append a nonce which they guess by starting the increment from zero. They will hash this concatenated data to get a new hash and compare this result with the target. If this new hash is less than the target, which is basically a 256-bit number specified by bitcoin protocol, then they are done solving the puzzle and get the mining reward. However, if the new hash value is higher than the target value, they have to increase the nonce; that is, increase the nonce from zero to one, and append this one with the hash of the Merkle root, take the hash again to get another completely different new hash value and compare it with the target to check whether this new hash value is lower than the target value. If the new hash is now lower, then, again, they have solved this puzzle; otherwise, they keep repeating this entire process by incrementing the nonce value. So, it is important to realize that the lower the target is, the more difficult it is to find a hash value lower than the target value.

The bitcoin network automatically adjusts this target so that each 10 minutes we get a new block (recall the 10 minute puzzle from the pirate ship captains, this is what the puzzle means here). So, if the bitcoin network notices that it takes 5 minutes for blockchain to mine a new block, it will decrease the target value until it becomes difficult enough to take 10 minutes to solve. Conversely, if, for some reason, it takes 1 hour to mine a new block, the target value will be increased to make the mining easy enough to solve in 10 minutes. This is what the PoW algorithm does. So, what we understand is that mining is nothing but a dumb puzzle and a nonce is a possible solution to this dumb puzzle, while the target field is a benchmark value to check whether I have solved the dumb puzzle with optimal PoW; otherwise, my target benchmark gets changed. Also, it is very important to note that this process is entirely a hit or miss process with the gradual increment of the nonce. In computer science parlance, we call this process a brute force attack, where we try every possible combination to crack a code in shortest amount of time. This is the very reason we require high-performance devices like application-specific integrated circuit (ASIC) chips to mine bitcoins rather than normal central processing unit (CPU), graphics processing unit (GPU), or even field-programmable gate arrays (FPGAs). The reward amount for one such mining puzzle is presently 12.5 BTC for solving one block. Earlier, it was 50 BTC, and then it came down to 25 BTC and again down to what we have in the present. The mining of bitcoin will continue with degraded mining reward till all of the 21 million bitcoins have been mined.

Forking, on the other hand, is an entirely different phenomenon that causes a split on blockchain due to a change in the protocol or due to a requirement for reorganization. A blockchain fork splits a single chain of blocks into two. The new forks are the same till the point of forking and behave differently in terms of principles and technicalities post a forking event.

There are two types of fork (hard and soft), which occur in blockchain community. Each of them can be activated by the users or miners as depicted in Figure 1.10:

For example, in the bitcoin blockchain community, BIP148 from Segwit that occurred on August 01, 2017, was actually an user-activated soft fork (UASF); whereas, in the Ethereum blockchain community, the ETH/ETC Split post DAO tragedy was a user-activated hard fork (UAHF). To summarize, soft forks are backward compatible, while hard forks are not. In hard forks, the community has to choose only one of the forking paths and cannot go back to the other later with the changed specifications. A hard fork is like the red/blue pill of Morpheus from the movie The Matrix.

We live in exponential times. As mere mortals, we normally perceive time in a linear way.

For example, one of the greatest inventions of mankind, the landline telephone, took about half a century to establish itself as a mainstream consumer appliance from a symbol of luxury, whereas smart phones crossed that barrier within a decade.

Blockchain is a disruptive computing paradigm. It has been positioned as fifth after mainframes, personal computers, the World Wide Web, and social networking. Melanie Swan, a blockchain educator and visionary, has segregated the existing and potential activities in blockchain evolution into three phases: blockchain 1.0, 2.0, and 3.0:

• Blockchain 1.0: It includes currency, the deployment of cryptocurrencies in applications related to cash, such as currency transfer, remittance, and digital payment systems.
• Blockchain 2.0: It includes contracts (the entire slate of economic, market, and financial applications using blockchain) that are more extensive than simple cash transactions: stocks, mortgages, titles, bonds, futures, loans, smart property, and the Internet of Things.
• Blockchain 3.0: It includes blockchain applications beyond currency, finance, and markets. This includes the areas of government, health, science, literacy, culture, and art.

Interestingly, Robert-Reinder Nederhoed, an industry practitioner and grass-roots level blockchain implementer, has classified blockchain technology into three distinct generations. Figure 1.11 summarizes the three generations the blockchain has experienced since its inception in 2009 by Satoshi Nakamoto (an unknown entity; the word Satoshi translates as wisdom, Naka as central and Moto as origin, so it roughly translates to central intelligence). These are money, assets, and contracts.

As linear thinkers, we must accept the bitter truth that technology life cycles are becoming shorter. Gartner, a market research group, traces this using a famous graph called the hype cycle.

A generic representation of such a graph is shown in Figure 1.12:

As of July 2017, the blockchain has entered the trough of the disillusionment phase. This is the reality check phase for any innovative technology, when the general interest wanes as experiments and implementations fail to deliver. Producers of the technology shake out or fail. Investments continue only if the surviving providers improve their products to the satisfaction of early adopters. Smart contract technology is one such hope which can take the blockchain out of this trough into enlightenment.

This chapter introduced us to the important challenges and limitations of distributed systems, such as the Byzantine Generals' Problem and the CAP theorem. Then, we moved on to understand the one-way hash function and generating a hash chain and a Merkle tree. We realized how a blockchain is a giant Merkle tree and that the subtle difference between a bitcoin and an Ethereum blockchain lies in representing the leaf nodes of such a tree as a transaction or a state of execution, respectively. We took a deep dive into the bitcoin block structure to demystify mining as an incentivized brute force attack. Forking, on the other hand, signified a change of protocol on blockchain. Lastly, we identified the three types of blockchain generation as money, assets, and contracts, and we contemplated how blockchain is going through its reality check phase, as per Gartner's hype cycle.

In Chapter 2, Grokking Ethereum, we will have a gentle introduction to Ethereum as a platform, which has its own Turing complete programming language and has the ability to deploy smart contracts in a decentralized manner.