In the previous module, we'd examined the technology behind a generic blockchain as a decentralized database. In this module, we look at a couple of examples of how this technology is actually implemented and start to examine some of the economic and business aspects as well. Will start by looking at Bitcoin, which is really what kicked off the whole blockchain boom. At its core, the bitcoin is a decentralized ledger database. That is, instead of storing any kind of data, the Bitcoin blockchain is a very specialized, limited purpose database that is really designed to accommodate simple transaction data. In other words, the main data transmitted to and stored on the blockchain is in the format of who paid whom and how much. If we go back in history, you'll find that when it was launched in 2009, the original vision was quite different than what it is now. The goal was to serve as a flexible, low-cost payment system like PayPal that everyone can use on their phones for payments large and small. But, unlike PayPal, it will replace the bank-based payment rails like ACH or credit cards, with the peer-to-peer blockchain, cutting out banks altogether. In fact, the designer seemed to have a profound distrust for existing financial intermediaries and really envisioned Bitcoin to be a digital replacement to fiat currencies. Themes like no central control of the system and total anonymity are often highlighted as the core features. Then over a decade into existence, we now know that reality was quite different because of a combination of technical limitations and economic factors. We'll go over these in the next videos, but in a nutshell, we realized it wasn't going to be a good payment system because it can't just handle that many, seven payments per second and max capacity. Also, economically, people were certainly not that keen on cutting out the central banks. Consequently, payment usage decline, and processing fees remain high. Moreover, the consensus mechanism, while very innovative, is extremely energy inefficient, which ironically resulted in a significant degree of centralization. Therefore, currently, Bitcoin exists somewhat like a digital gold or a digital treasure whose intrinsic value is hard to pin down and a lot of it is driven by investor sentiment. Technologically, now that we know the generic blockchain technology, it's very easy to define Bitcoin. Remember, we looked at the blockchain as a decentralized database consisting of three parts: the user application that maintains user identities and generates the data, the peer-to-peer network of nodes that receives the data and "processes" the data with a consensus protocol, and the database itself, which stores data in a unique chain format using hash pointers and linked list. Here's the Bitcoin implementation of this technology. The user application is called a Bitcoin wallet. If you want to send or receive Bitcoins, you could write a script yourself, but more often than not, you'll be using a wallet app to generate the transaction data and broadcast it to the network. Sometimes the wallet app could be used as a identity management tool as well and store your private keys. Second, the nodes of the Bitcoin network are called miners. They're the ones processing the transaction data by running some simple validation tasks like checking your crypto signatures and organizing the data into blocks following the so-called UTXO principle, which we'll review shortly. In the Bitcoin network, consensus across nodes are reached using a protocol called proof-of-work or mining, which is a major innovation of Bitcoin. Again, data on the Bitcoin database is limited to the transaction records in the form of who paid who, how much, and when and is stored using the generic hash pointers and linked lists to facilitate searching. Now, once we move from a generic technology to an actual business implementation, there are several key concerns that we need to address. First, we can't just use the generic random consensus protocol from the previous module. As we saw, it's way too vulnerable to double-spend attacks. So we need a more robust consensus. Second, it all sounds fine and dandy on paper, but how do we actually get the network up to scale? Obviously, people are not going to contribute their computing resources and participate as nodes for free so they need to be incentivized to do so. There needs to be a reward structure that encourages nodes to maintain the network so that it doesn't fall into disuse. We'll explore these topics in this and the next few videos. First, let's take a deeper look at the data structure, which is the easiest component to understand. Because the data is limited to transactions only, the Bitcoin blockchain is really a true ledger that records just who has paid how much to whom, and if you recall the final video from the last module, from the actual data, most of these transactions seem to have two or more recipients. Now, let's see why. Consider this chain of transactions. Andrew, the miner, mined 100 coins. He then paid 80 coins to Bob, who in turn paid 15 coins to Carol. Carol, then paid 10 coins back to Andrew, and finally, Andrew paid David 25 coins. How do you do it on an actual paper ledger? Well, you'll probably just write these five statements down. In the Bitcoin blockchain, however, these transactions are stored as input-output list to take advantage of the hash pointers to facilitate searching. The gist of the model is that most transactions have to have both the input field and the output field and they have to be equal. The exception is the first transaction in the block which is called the coinbase transaction. In this transaction, there's no input and the 100 coins are minted out of thin air and awarded to the miner Andrew. Now things get more interesting. When Andrew pays Bob 80 coins, he will generate and broadcast the transaction where in the input field, he will include a hash pointer pointing to his receipt of the 100 coins before. This is like including a piece of evidence of him receiving the coins. Now critically as the output, in addition to giving Bob the 80 coins, he has to include himself as the recipient and send the remainder, the 20 coins, back to himself. In other words, the previous transaction that Andrew referred as the evidence, must be fully consumed. Why? Well, if you think about it, this really makes searching easier because instead of traversing all the way up the chain, you only need to search back one step. Let's keep going down the ledger to see more of this in action. When Bob pays Carol 15 coins, he will include as evidence the transaction where his address received the 80 coins from Andrew. In the output field, he'll send 15 to Carol and 65 back to himself. Similarly, when Carol pays Andrew 10 coins, she will include the transaction of her receiving 15 coins as evidence and send 10 to Andrew and five back to herself. Finally, when Andrew wants to pay David 25 coins, he has to include two inputs because only the sum of the two can cover the transaction. He'll reference the transaction where he received 20 from himself and the transaction where he received 10 from Carol. This sums up to 30 coins. So he pays David 25 as the output and five coins back to himself. As you can see, for a miner validating these transactions, the task is quite easy. Remember the scripts: check, seek, and equal verify. Instead of searching through the entire chain, which could take some time, they simply check the signatures, then check the input and the output of the transaction to make sure they sum up equally and if they do, is guaranteed by design to be a valid transaction. This is called the UTXO principle, and the goal is to enhance the efficiency in transaction verification.
