Learn about the database limitations topic and the idea of a distributed database.
- We've discussed that a core characteristic of a traditional database is that it typically has a central authority that governs it. For instance, all rights to a database are owned by the organization that creates it. They can decide who has access and what type of access that they can have. They decide what is stored in it, what is deleted, and what is archived. However, this has at least two potential flaws to it.
First, if a system relies on a central database, this can result in a single point of failure. In other words, if either the central authority is compromised or a backdoor is exposed, the database can be subject to all manner of risk. The second major flaw is that all power is held by the central authority. Now, in general this is okay. For example, if you run an e-commerce website, you probably want total control over it.
Your own central authority, perhaps you as CEO, gets to decide all aspects of that environment, including shutting it down if that's what you want. What central power can do, however, is create control that limits access, say by being cost-restrictive or requiring special skills, by creating onerous human checks and balances, like approval workflows. In most cases, by extension, humans remain the final arbiter of the validity of a transaction.
We see this in most contract work. A contract between two entities completed over the Internet still requires one or more central authority to validate data. For example, with a mortgage, banks must validate savings and approve loans. Title companies must validate properties. And legal professionals must validate signatures and other contractual requirements. Each one of these central authorities has unique power that levies considerable overhead in a mortgage transaction.
The transactions in the very databases all take time to process, cost money, are vulnerable to hacking, provide limited participation from those involved, require special skills, and can be error prone. Up until now, we've generally been okay with this. The blockchain however solves almost all of these challenges. Let's discuss how it does this. The blockchain is a new type of database.
Instead of a centralized or decentralized database on one or more servers, a blockchain database is installed on individual computers used by the people who use the database. In fact, a copy of the same database is installed on every computer of every user who uses that database. As I've already demonstrated, in a central database we have the database on one server in the center. In the decentralized database, it is spread out among several servers.
However, a distributed blockchain database is copied to every client computer on this network. There are no database servers. Now, let's walk through what happens when a transaction takes place in this distributed database. To keep things really simple, we'll use our earlier example of a contacts database that has names and phone numbers, our electronic phone book. Let's start with creating a rule for our phone book. In it, we have decided we only want the owner of a phone number to be able to modify it.
This rule is now codified into our software. Okay, so I've just received my new smartphone and I need to update my phone number in this electronic phone book. First I make the change in the phone book database that's on my computer. Next, my database transmits this transaction to every identical database on the distributed network over the Internet. At this point, all of the individual computers where the database resides have to agree that I have the permission to change my phone number.
Since all the distributed databases already know this rule, that is, only the owner can change the phone number, they allow my change. We can think of as consensus-based permission because computers on the network have to reach agreement before a change is allowed. Each database then appends a new block of data in the database that contains my new phone number. I'm going to demonstrate that using some blocks right here. And so this represents some data.
I've got a new entry. In this case, we could imagine this to be my new phone number. And then we go ahead and cap that off. Now, we talked about the fact that this entry then gets replicated across all the participants in the blockchain database. Here I have three examples on a normal blockchain database. This will probably be thousands of computers. Now, we're going to go ahead and add another entry to this database. This could be perhaps another person's phone number.
And now this phone number gets appended to all the other databases. It should be identical. The database itself has agreed that this is allowable. And now we have a chain of blocks, we call it the blockchain, that has identical information in all of the different databases that are distributed throughout. Now, what makes this really interesting is that if somebody wanted to hack this, perhaps they wanted to change this block here by replacing it, say, with a blue block, the blockchain database is not going to permit this.
And the reason for that is because each row in this database right here relies on the identical row in each database previous to it. So any changes wouldn't permit this to exist, so the integrity of the database would be broken. This is a really important quality. Blocks are only added and never deleted. All changes are simply captured as new blocks. We call this characteristic immutability. Put another way, a blockchain database is an immutable database.
We can think of the blockchain database as keeping track of changes, like an accounting ledger where financial transactions are recorded. For this reason, the blockchain is often referred to as a distributed ledger. Let's go a little deeper on this example to reveal just how transformative it is. First, there is no central authority. The power is now distributed across the entire network of users of the database. No single person or system can approve or deny my phone number change in the electronic phone book.
Power has been decentralized. It requires the consensus of all participating computers. Since the distributed database knows that I am the only person allowed to change my own phone number, it is almost hack-proof. We are able to create these immutable transactions. A hacker would need to change the information on hundreds and likely thousands of computers in order to get the authority to make the change. This quality then ensures integrity to the database creates inherent trust.
It's why the blockchain is sometimes referred to as the trust protocol. Next, when I made the change to my phone number, the change was accepted and reflected almost immediately. A small delay does exist, only because participating requests for changes to the blockchain are queued up and processed in order. We'll also discover in a later video that there is some mathematical processing required by some computers that creates some delay too.
While simplified, these are the basics of the blockchain database. To summarize, this new model has no central database. A blockchain database is installed on all the computers that use the database. Any transaction in that database must be validated by all the participating members. It has the power to be almost hack-proof. It eliminates central authorities, significantly reduces transaction costs.
It quickly processes complex transactions and more. To fully understand the blockchain requires us to understand its origin story, and it begins with Bitcoin.
Jonathan begins by describing some of the current challenges with the Internet, including existing risks and security problems such as identity management. Next, he describes how traditional online databases function, so that you have a basis for how the blockchain redesigns this function. He then describes how the blockchain becomes a potential solution for many of the existing limitations of online databases. Since the blockchain has its genesis in Bitcoin—the digital currency—he provides some background on that too. He also discusses how blockchain technology actually offers new capabilities beyond simply solving old problems. To wrap up the course, Jonathan shares steps you can take in your organization to understand the implications of the blockchain.
- Risk and security challenges
- Rethinking the traditional database
- What is the blockchain?
- What problems does the blockchain solve?
- Transforming transactions
- Examples of the blockchain in action
- Obstacles to blockchain adoption
- Risks to existing solutions and enterprises