How I stopped worrying and learned to love Blockchain
By: Bennett Bullock
Tags: Startup, Bitcoin, Money, Blockchain, Security

When I lived in Guangzhou, China in 2001, I would go out on Sunday to teach a class in a small town outside the city. The owners of the school kindly set up a bank account for me in one of the local banks. When I came back to that bank to withdraw my money, I had forgotten my ID, but they recognized me (the only foreigner with a bank account), and gave me my money. They knew the owners, they knew me, so it was no problem. Then, I took a trip to Nanjing, in another province, and tried to access my bank account with my ID, in the same bank, and they told me there was no way to do it. The bankers in Nanjing didn’t really trust the office in Guangzhou, so no money.

China has changed a lot since then, but there is an interesting moral to the story. In the first case, they shouldn’t have given me my money, but they trusted me, so they did. In the second case, they should have, but they didn’t trust me, so they didn’t. Their job obligations didn’t mean much, but their personal trust did.

Absence of trust prevents business from being done. If I pay you, I need to trust that you will do the work. If I work for you, I need to trust that you will pay me. When there’s a government or legal system in place to punish people who don’t live up, this problem becomes trivial, but when there isn’t, I’m much less likely to take a chance on someone I don’t know. Here, people’s economic activity doesn’t go beyond their family and social circle, and it’s no coincidence that countries with stronger legal systems have stronger economies, while countries with weaker legal systems have weaker economies. I’d go as far as saying that much of the poverty in emerging markets stems from people just not wanting to take the risk of trusting other people, because there is no legal system to fall back on. If there were a solution to such a problem, it would lead to nothing short of a global economic renaissance.

Well, there is, and it’s Blockchain. Blockchain replaces trust with math. Although it became famous with Bitcoin, Ethereum was the game-changer. Ethereum has a scripting language that can run on the blockchain, so it’s possible to run contracts in a secure and verifiable framework that is independent of any centralized authority.

So I decided to teach myself the basics, by building up several versions of a “toy” blockchain protocol, which I call ToyBlockchain. This isn’t the real one exactly, but I think that building it up clearly explains why blockchain works.

ToyBlockchain 1.0 — No Verification at All

Let’s imagine a world where there are two people, Bob and Alice, giving money to each other. They keep a record called a “blockchain”. Bob has $5, Alice has $4, and Bob pays Alice $1. We divide this up into units of time and activity called “blocks”:

Block 1: {Bob has $5, Alice has $4} Block 2: {Bob gives $1 to Alice, Bob has $4, Alice has $5}

We call this version of events the “original blockchain”. Bob and Alice give one another a copy every time they finish a transaction. Anyone can look at this blockchain.

However, let’s say Bob is not the best person in the world, and he decides to change the blockchain, making a “fork”:

Block 1: {Bob has $6, Alice has $3} Block 2: {Bob gives $1 to Alice, Bob has $5, Alice has $4}

Looking only at the fork and the original blockchain, there’s no way to figure out who is more credible, or which is the “true record of events”. Alice calls the cops, but Bob is a cop. Alice calls her lawyers, but Bob has better lawyers. Alice calls the Godfather, but Bob had coffee with the Godfather last week, and the Godfather’s daughter is married. It’s Bob’s word against Alice’s, and Alice is up the creek.

ToyBlockchain 1.0 is easy to fork and impossible to validate.

Hashes and Brute Force Attacks

Here’s where the math comes in: A hash is an operation on a number which turns that number into something completely different. Let’s say we have a number 5, and a hash of that number h(5)=32823492341. We see that the hash of that number doesn’t look anything like the number 5, and that’s the point. You can’t look at 32823492341 and figure out that it’s 5. A good hash h(x) needs to satisfy:

A small change in x leads to a huge change in h(x), so that h(1)=452435342524, but h(2)=687400833225.

Because of this, there is no way to look at the value of h(x) and know what x is, even if you know how h is coded.

x can be any data, including Blocks. For example, h(Block 1) is a hash of Block 1, and h(Block 1, 2, “abc”) is a hash of Block 1, the number 2, and the string “abc”.

What if we wanted to find a number x so that h(x) was less than a magic number, like 2¹⁸⁰? Because we can’t relate x and h(x) in any way, we have to make guesses at x — is h(1) < 2¹⁸⁰? No? Is h(2) < 2¹⁸⁰? No? Is h(3) < 2¹⁸⁰? And so on, until we arrived at the answer.

If we have one computer making guesses, this is going to take a long time. Two computers, and the average time to solve gets cut in half. Four computers, and the time gets divided by four … The time it takes to solve this problem shrinks the more people try solving it.

ToyBlockchain 2.0 — Hashing the Chain

Let’s redesign our blockchain. We compute a hash of Block 1, called hashBlock1, which equals the hash of all the data in Block 1, or h(Block 1):

Block 1: [{Bob has $5, Alice has $4}] Block 2: [{Bob gives $1 to Alice, Bob has $4, Alice has $5}, hashBlock1]

We can check to see our blockchain is valid by look hasn’t been changed by looking at hashBlock1 in Block 2. Does h(Block 1) = hashBlock1? If yes, then the chain is valid. If not, then Block 1 has been changed. We said that a small change in Block 1 makes a huge change in h(Block 1), so there is no way to change Block 1 even a little. We know the chain has been forked. To make a change to Block 1, Bob has to compute Block 2 and create his own version of the change.

But how do we know which chain is the true record of events? We introduce a new character — a bystander named Millie. Millie helps Alice introduce new transactions and validate the blockchain. Alice and Millie work slightly faster than Bob, so maybe we can say that the longer valid blockchain is the true record of events.

That works as long as Alice and Millie keep adding blocks to the Blockchain at a constant rate. The problem is, blocks are not being added all the time. Sometimes business may slow down, and Alice and Millie stop adding blocks for a few hours. Because hashing does not take a long time, Bob can easily finish the fork while Alice and Millie are taking a break. The fork and the original blockchain are as long as one another, and there is no way to know which is the true record of events.

ToyBlockchain 2.0 is easy to validate, and somewhat easy to copy.

ToyBlockchain 3.0 — Adding a Nonce

Let’s say the longest blockchain is still the true record of events, and let’s add another feature to our blockchain:

Any block needs to have a hash of a previous block and a number called a “nonce”, h( Previous Block , nonce).

, nonce). This hash needs to be less than a number, which we call magicNumber, and which equals 2¹⁸⁰.

To add a block, we need to find a nonce that makes h(Current Block, h(Previous Block, if any), nonce) < magicNumber.

Our blockchain now looks like this:

Block 1: [{Bob has $5, Alice has $4}, nonce1] Block 2: [{Bob gives $1 to Alice, Bob has $4, Alice has $5}, hashBlock1, nonce2]

We can validate the chain by asking the following questions:

h({Bob has $5, Alice has $4}, nonce1) < magicNumber? (yes!) Look at hashBlock1 in Block 2. hashBlock1 = h({Bob has $5, Alice has $4}, nonce1)? (yes!) h({Bob gives $1 to Alice, Bob has $4, Alice has $5}, hashBlock1, nonce2) < magicNumber? (yes!)

If all these questions can be answered with “yes”, the blockchain is valid. If one or more of them is “no”, the blockchain is not valid. The longest valid blockchain is the true record of events.

Let’s add a new transaction, {Alice gives $3 to Bob, Bob has $7, Alice has $2}. To insert this into the blockchain, they first have to compute a hash of Block 2:

hashBlock2=h({Bob gives $1 to Alice, Bob has $4, Alice has $5}, hashBlock1, nonce2)

Now, they find a nonce, nonce3, that satisfies:

h({Alice gives $3 to Bob, Bob has $7, Alice has $2}, hashBlock2, nonce3) < magicNumber

Alice and Millie take guess after guess for nonce3. When one of them finds a good nonce3, Block 3 is inserted:

Block 1: [{Bob has $5, Alice has $4}, nonce1] Block 2: [{Bob gives $1 to Alice, Bob has $4, Alice has $5}, hashBlock1, nonce2] Block 3: [{Alice gives $3 to Bob, Bob has $7, Alice has $2}, hashBlock2, nonce3]

Remember, Alice and Millie will take less time than Bob to find this nonce, because hashes require brute-force attacks. This process is called “mining”. Now, we can validate the blockchain:

h({Bob has $5, Alice has $4}, nonce1) < magicNumber? (yes!) Look at hashBlock1 in Block 2. hashBlock1 = h({Bob has $5, Alice has $4}, nonce1)? (yes!) h({Bob gives $1 to Alice, Bob has $4, Alice has $5}, hashBlock1, nonce2) < magicNumber? (yes!) Look at hashBlock2 in Block 3. hashBlock2 = h({Bob gives $1 to Alice, Bob has $4, Alice has $5}, hashBlock1, nonce2)? (yes!) h({Alice gives $3 to Bob, Bob has $7, Alice has $2}, hashBlock2, nonce3) < magicNumber? (yes!)

Why do we need to validate the blockchain? Well, let’s say Bob wants to change Block 1 to {Bob has $10, Alice has $4}. Let’s go through the validation again, and see what Bob has to do:

h({Bob has $5, Alice has $4}, nonce1) < magicNumber? (no!)

Bob finds new nonce1 to make this true.

2. hashBlock1 = h({Bob has $5, Alice has $4}, nonce1)? (no!)

Bob has to recompute hashBlock1 and insert it into Block 2.

3. h({Bob gives $1 to Alice, Bob has $4, Alice has $5}, hashBlock1, nonce2) < magicNumber? (no!)

Bob finds new nonce2 to make this true.

4. hashBlock2=h({Bob gives $1 to Alice, Bob has $4, Alice has $5}, hashBlock1, nonce2)? (no!)

Bob has to recompute hashBlock2 and insert it into Block 3.

5. h({Alice gives $3 to Bob, Bob has $7, Alice has $2}, hashBlock2, nonce3) < magicNumber? (no!)

Bob has to find a nonce3 to make this true.

To build a fork, Bob has to find new nonces in Steps 1, 3, and 5. But remember, Alice and Millie can find nonces twice as fast as Bob. So by the time Bob has finished with 5, Alice and Millie have found nonces for Blocks 6–10, so Bob needs to do this too. Because the longest blockchain is the true record of events, there is only one way Bob can catch up with Alice and Millie — steal their computers.

If Bob has more than 50% of these three computers, he can fork a blockchain successfully. This is still possible if Bob, Alice, and Millie have one computer each — Bob, after all, has a gun. But if there hundreds of bystanders like Millie, working with Alice, then their mining will be hundreds of times faster than Bob’s mining. Even if Bob manages to steal 10, 20, or 50 more computers from everyone else, there will still be no way for him to successfully fork the chain. Now, Bob is out of luck — no amount of legal representation, mafia connections, or guns can help him beat the math.

But why would Millie and the other bystanders spend time working on the blockchain? What’s in it for them? Blockchain systems incentivize passive participants to mine blocks by paying them in some way. Usually, this is in the form of a cryptocurrency (Bitcoin, Ethereum, Litecoin). Every time they solve a problem, they get paid.

ToyBlockchain 3.0 is easy to validate, painfully hard to copy, and it incentivizes many people to participate.

The Future of Blockchain

If people not trusting each other is a drawback to economic growth, blockchain presents a solution. If an employer and employee complete a contract successfully, that completed contract can be put on a blockchain and securely verified anywhere in the world. That means a good programmer in India or Brazil can work for a reliable employer in Sweden, the work gets done, and both the employer and employee are incentivized to do the best they can to fulfill their contract. The impact of this could be enormous.

However, Blockchain isn’t perfect.

First of all, because there is no central authority, the security of the user’s password and id is entirely the user’s responsibility. The user’s credentials are only as safe as the security on their laptop. A hacker can steal this information, and steal all the user’s cryptocurrency. Sadly, Bitcoin’s version of Blockchain does that classic trick of tech — solving a problem by passing it onto the user.

Secondly, because the average time to complete a brute-force attack depends on the number of computers solving the problem, more and more electricity is devoted to mining. Currently, the yearly amount of electricity used to mine Bitcoin is as much as that consumed by Denmark. It is estimated that, by 2019, this amount will increase to that consumed by the US. (source) This is for one cryptocurrency — now, there are more than 100. We cannot afford this strain on our environment, and there is room for finding other ways to secure consensus that do not require brute-force attacks.

Thirdly, cryptocurrencies are hard to use. Only a handful of merchants accept them now, and the only way to get rich from Bitcoin is to sell it.

A good currency currency is worth what it is worth because a productive economy uses it, and the government that issues it controls for inflation. The dollar is used around the world because it is a stable indicator of value. It is quantifies the economic output of a strong economy, and it is stable. Cryptocurrencies are controlled for inflation, but do not have an economy associated with them. There is no real way to determine how much value they signify, and, because of this, they are vulnerable to speculative bubbles.

But these are problems that will even out in time. I love Blockchain because it is one of the few occasions where the Good Guys win and the cheats lose. The math ensures it.