The Blockchain For Dummies Guide — Part 1
When you say the word “blockchain” or “bitcoin”, both words connote various reactions, from salivation to eye rolls.
Everybody’s talking about it, but most people don’t know much about either Bitcoin or blockchain. What’s the big deal? Is it just another bubble?
Why are people losing their minds over this Bitcoin stuff?
I wanted to take some time to do a the definitive beginner’s guide on blockchain and Bitcoin, looking at underlying technology from a 10,000 ft overview, why its significant, what’s its great for, and what its not so great for.
After all, not everything needs a blockchain, so the obvious question: what is a blockchain and where is it needed?
Blockchain, the underlying technology of Bitcoin, is just another tool in the engineer‘s toolbox. So for this type of hammer, where’s the nail we use it on?
Before we can answer that, we need to look at databases in their current form.
Databases — Where Data Lives
Databases quite literally are the anchor points of our digital lives. They’re the buckets where all of the world’s data rests: able to be retrieved, viewed, manipulated, and stored again for future use.
In fact, databases are so important, that many companies derive a significant amount of their resale value from the data that rests in their databases.
Far From Perfect
But databases like MySQL, Postgres, MongoDB, and many others are not perfect. In fact, they’re far from it.
Databases are prone to a variety of issues, from data corruption, to eventual consistency (when a value is updated and then immediately retrieved, the old value might be returned), to disk corruption and other hardware failures.
If a database is storing trivial data such as blog posts or weather data, these aren’t huge problems.
But if a database is holding records as to who owns a particular asset and the price paid for it, corruption of this information would be catastrophic.
Fault Tolerance To The Rescue
So luckily, some very smart people throughout the progress of technology have realized that relying on only one database as a single source of truth was probably a bad idea in mission-critical situations.
So to protect against such failures, they enacted a variety of solutions, from read-replicas to distributed fault-tolerant architectures that would ensure data consistency.
But even these solutions don’t solve all of the problems inherent with databases. In fact, in the case of distributing a database (creating multiple databases with the same data and updating them in parallel), it actually creates another problem, and its a problem where blockchain enters as a potential solution.
The problem is known metaphorically in technology circles as the Byzantine Generals Problem (or BGP for short).
Never Trust A Byzantine General
A quick synopsis of BGP* is that two generals and their armies are encamped outside of a city. If they both attack, then they can win the city. If only one of the generals attacks, but not the other, the attacking army will perish. If they both don’t attack, then they both live to fight another day.
In order to determine what they’re going to do, they need to communicate with each other using messengers.
The problem though is if a general sends a message to the other general, how does he know it arrived? Maybe something happened to the messenger along the way.
The other general would need to send a message back confirming, but then that general also needs a confirmation that their message is received, and so on.
Essentially, this process could go on forever until one general decides “okay, no more messages, I’m attacking!”
The problem is further complicated that each general has their own interest at heart and not the other general’s. So how does each general know that if the other general sends the message “I’m attacking!”, that they will in fact do what they said they’ll do?
BGP is essentially the same problem we face in a publicly distributed architecture with computers, where we have no guarantee on the receipt of messages and we also have no guarantee as to the trustworthiness of the agents sending those messages.
So if we’re sending messages to a publicly distributed database to store information, and we have no guarantee that those message will be delivered or be accurate, how can we guarantee that the data stored in the database is both up-to-date and accurate?
Answer? We can’t.
At least not with a traditional database and distributed architecture, we need something different that guarantees consistency throughout the network, without fail.
In Part 2, we’ll go into how a blockchain database structure, how it solves this byzantine generals problem, and what it means having this new tool for solving real world problems that cost businesses billions per year…