The Blockchain For Dummies Guide — Part 3

RECAP: In Part 2, we talked about what a blockchain is using crayons, and how a blockchain’s data is chained together by the order of entry, but we still don’t know how the participants in the network reach an agreement as to the correct order of the data.

So we now came across the issue that we have this great new database called a blockchain that allows us to chain data together in a particular order.

This allows us to quickly determine if data has become corrupted or people are trying to manipulate our database, but we still don’t know how the network agrees on the proper order of data in the first place.

As an example, if you wanted to say the next crayon in the dataset is “pink” but at the same time, I say the next color should be “cyan”, how does the network decide which crayon should come first?

This is known as the consensus problem, and its a big one. After all, if we can chain together data in a database but nobody can agree on the correct order, its a pretty useless feature.

We need to have a mechanism or protocol in place by which all network participants are bound to follow in order to guarantee our ordering in the blockchain.

As we discussed in Part 2, in order for the protocol to be effective, it needs to help our Generals answer three fundamental questions:

1. How do we agree upon the proper order of the crayons?
2. How do we know that we’ve reached an agreement on the order?
3. How do we know we aren’t wrong about #1 or #2?

How Do We Know?

There are a number of ways we can go about answering the first question.

One way we could go the route of a central authority or a set of delegates that determine the proper order of the crayons (this is how blockchains like EOS and Hyperledger function).

Basically the way ordering works in a system like this is relatively straight forward: the central authority or delegates tell the network what the proper order should be as new crayons are added to the the set. Simple.

But what if we don’t want to trust one central authority or a group of delegates? What if this blockchain is going to be used publicly by people who don’t really trust any one participant or group more than the other?

Luckily, there are a number of ways that we can decentralize the consensus process, one of the most popular of which is known as proof of work, which involves mining.

Mining involves certain agents in the network serving as maintainers of the blockchain.

In a proof of work blockchain, miners are incentivized to compete against each other in the effort to determine the proper order of the next entries or transactions to go into the blockchain. For this effort, miners are rewarded economically.

Mining gets a lot more complex than this, but keeping this high-level, that’s essentially how it works: it a race to the finish with a reward for accuracy and speed.

So in a delegate-based system, the delegates choose the ordering. In a proof of work based system, the fastest miner determines the ordering, both of which solve Question #1 for our Generals.

How Do We Know We Know?

But what about Question #2, how do the Generals know when an agreement has been reached?

This is where the cryptography aspect of blockchain comes into play. We could dedicate an entire post to cryptography alone, however to keep this as high-level as possible, we’ll only talk about what’s needed.

Cryptography is the science of encrypting or scrambling messages in a way that either provides us security or proof. An easy to understand example of cryptography is the Caesar Cipher, used by Julius Caesar himself to send messages regarding military actions.

Caesar Cipher Illustration

In a Caesar Cipher, messages are encrypted by shifting letters a certain amount times down the alphabet. So if we wanted to encrypt “hello” and our shift was 1 letter backwards (we’ll call this “shift-1”), the encrypted message we’d send is “gdkkn”. This scrambled message is known as the cipher text, which could be decrypted back again just by shifting those letters one step forward again.

The Caesar Cipher is known as a cryptographic algorithm and there are many of them. Some are two-way like the Caesar Cipher (can be encrypted and decrypted back), others are one-way (you can encrypt, but you can’t decrypt).

Good cryptographic algorithms provide us with a unique functional property known as a trap door.

A trap door in cryptography means its easy to do something in one direction, but hard to do it back in the other direction.

In our Caesar Cipher example, our trap door is the fact that the person reading the encrypted message would first need to know the number of steps to shift in order to decrypt the message (easy to do), otherwise they would need to shift-1, shift-2, shift-3, shift-4…ad nauseum until they finally found a message that actually made sense. That’s a lot harder.

So going back to Question #2, how does the network know an agreement has been reached? Essentially, the delegates or miners broadcast a cryptographic proof that is unique to the data they’ve chosen to be entered next into the blockchain.

As an example of this, with our Caesar Cipher “hello” example, “hello” becomes “gdkkn” when the encryption algorithm is shift-1.

The proof is unique because no other word besides “hello” in the english language can become “gdkkn” when the algorithm we’re using is shift-1.

We also have a decent trap door because its easy to verify if we already know the protocol is shift-1, but its harder to crack if we don’t.

So essentially, if we had a blockchain protocol that would require our delegates or miners to take the next data and then “shift-1” it, the miners or delegates could broadcast to the network “hello:gdkkn” as the next link in the blockchain, and the network would immediately know it to be a valid next entry because the network has previously agreed to use the “shift-1” protocol.

When a majority of the network has confirmed “hello:gdkkn” as a valid next record to be entered into the blockchain, we know we’ve got a proper consensus.

How Do We Know We’re Never Wrong?

This one is actually pretty simple now. Sticking with our Caesar Cipher “hello” example, we can easily show how “shift-1” would never be wrong because “gdkkn” is the proof that is publicly verifiable and has been confirmed as valid by a majority of the network.

So between our chosen consensus process and our cryptographic algorithm:

1. We have consensus process for everybody to agree on the proper ordering of elements added to the blockchain.
2. We know when agreement has been reached because we get a publicly verifiable proof and a majority confirmation.
3. We know its right because we’ve all committed to the protocol. Anybody who isn’t using the protocol, we can just ignore.

Wow, we’re flying through this stuff! So far we’ve covered the common problems with databases, we know how a blockchain works, we even learned some cryptography skills and how they combine with blockchain to give us an ordering guarantee.

All this stuff is great, but what can we do with a blockchain that we couldn’t before with a regular database?

In Part 4, we‘ll talk about some of the unique things blockchain enables us to do that we couldn’t do before with traditional databases. Things like tracking assets, currencies, or just about anything that has real world value.

Looking For Blockchain Development or ICO support? Reach out to us at KaizenTek.

If you liked this post, give me 10 claps and a follow!

This story is published in The Startup, Medium’s largest entrepreneurship publication followed by 323,238+ people.

Subscribe to receive our top stories here.