The only post you need to finally understand how a blockchain works

Why do you even need a blockchain?

Most blockchain guides start by jumping straight into the technical details and jargon. This is a bad way to start. The main question you should be asking first is: why do we even need a blockchain? What's the point of one?

Imagine you want to try to keep a list of events, e.g. you're on a group trip to Portugal and want to track who paid for what, so you can work out who is owed what when you fly back home (imagine there are no apps like Splitwise for a moment too).

The easiest way to do this would probably be for one person, e.g. Ben, to record stuff in his phone notes:

• "Ben paid £50 for dinner"
• "Sam spent £30 on the museum"
• "Henry spent £20 on drinks"

This works pretty well and is efficient, but there are some problems:

• Ben could lie about the list, perhaps saying he's owed £500 for dinner, or change some values.
• Ben could lose the list or accidentally delete it.
• Ben could ban people from being included on the list for some reason.

Anyone could be holding this list, and these three things could be true.

The question blockchains solve is: how do we maintain a list of events like this that's decentralised, i.e. no one person is in charge of maintaining the list, and it's a somewhat true version of events?

Pause and think for a second about how you'd actually do this. A list of events, but no one person is in charge of making sure it's correct.

A stupidly simple system

The solution is stupidly simple: everyone maintains a copy of the same list and records their own version of the events; then they come together to check everything matches up.

Yep, that's basically it. This is a decentralised system and is what a blockchain is: just a load of people keeping their own lists.

If you take anything from this blog post, it's this: a blockchain is essentially just everyone having their own list in their phone notes instead of one list.

Making sure the list doesn't go wrong

With this system decided, there are just a few more problems to figure out, mainly:

What happens if people have different lists or versions of events?

If the version of events is wrong, it might mean that people end up with more or less money than they should have at the end of the trip, which is not a good system.

This is where we need some way to "vote" between the people involved as to which version of events is the true one, and what order the events came in. You could just do a simple vote and see which version of the list gets the most votes, but there is one problem, especially if you're doing this online:

There's nothing stopping Ben from lying and making 10 versions of the same list to increase his votes in a fake way.

The only way to avoid bad behaviour like this is to:

• Require some sort of effort or cost to vote.
• Punish voters who are lying.

In this example, perhaps you need to do 10 press-ups to submit a list, and if your list is outvoted or wrong compared to the other lists, you need to do 100 press-ups as punishment.

With this system in place, we can sort of cobble together a system that works. It's not perfect, e.g. there could be a lot of liars working together, but it gets the job done well enough.

Making sure the list can't be changed

The final piece of the puzzle is: once everyone agrees on the list of events, how do we ensure that it can't go back and be changed? We need some way to link event 1 to event 2 and lock their order in: alas, a bit like a chain!

Chain link 1 is locked into chain link 2. You can't take one chain link out and move it because then you'd have a broken chain.

For our case, this is where we need to use something computers are good at: hashing. It lets you take a string of characters, e.g. "Ben paid £50 for dinner", and turn it into a scrambled jumble of letters, e.g. "7abe1..." A common algorithm used to do this is SHA-256, which stands for "Secure Hashing Algorithm 256-bit". It takes in any bit of text and produces a 64-character hexadecimal string (a-f, 0-9). This is an interesting algorithm because:

• A text input will ALWAYS produce the same output (deterministic), e.g. "bob" will always produce "8acb..."
• It's collision-resistant: no two different inputs will produce the same output, e.g. nothing other than "bob" can produce "8acb..."

That's basically all you need to know, other than that you can run it pretty fast.

The idea of a blockchain, specifically the chain part, is that you do a SHA-256 hash on the event "Ben paid £50 for dinner" to produce "7abe1...", and then you include "7abe1..." at the start of the next event. For example:

"start" -> "Ben paid £50 for dinner" -> "7abe1..."
"7abe1..." -> "Sam spent £30 on the museum" -> "a9b12..."
"a9b12..." -> "Henry spent £20 on drinks" -> "56df1..."

This means that if you decided to change the first event to "Ben paid £500 for dinner", it would break the chain.

So far: everyone keeps the list. Hashes stop old entries from being quietly changed. A cost stops one person from creating thousands of fake votes.

Starting with Bitcoin

Satoshi Nakamoto was the first person to propose a decentralised system like this in his famous Bitcoin whitepaper. His main breakthrough was to combine an "effort system" specifically designed for computers to stop them from submitting lots of votes for their specific version of events. In other words, the computer version of press-ups.

This is called "proof of work". When we were talking about the SHA-256 hash, it spits out a random load of letters and numbers. It is random, but sometimes randomness can produce certain patterns, e.g. "dad123..." or "111111...", in the same way that number plates on a car are random, but the letters and numbers can sometimes spell things.

Proof of work is basically a dumb challenge to try to get the SHA-256 algorithm to specifically spit out a sequence that starts with zeroes. You can do this by trying to find a "nonce" value (basically a useless value) that can be combined with the previous hash, e.g. "7abe1...", to create a new one, like the word "cat":

SHA-256("7abe1..." + "cat") = "000e7b..."

It doesn't actually do this; it's just a demo.

In this example, "cat" would be the nonce. The core concept is that finding this nonce is hard. It takes billions of attempts with random characters, but once you know it, it's really easy to check. Also, the more computing power you have, the quicker you can try different nonce values and land on an answer.

So why is this important when it comes to keeping a list of who paid for what? Well, let's say we have our list and append a few zeroes in front of each hash to make it the Bitcoin blockchain:

"start" -> "Ben paid £50 for dinner" -> "007abe1..."
"007abe1..." -> "Sam spent £30 on the museum" -> "00a9b12..."
"00a9b12..." -> "Henry spent £20 on drinks" -> "0056df1..."

And we want to add a new item to the list:

"Ben paid £10 for an Uber"

We'd take the last hash, "0056df1...", and start looking for a nonce that produces another hash with zeroes at the start. Ben, Sam, and Henry all start doing this. Ben manages to find one:

"0056df1..." + "Ben paid £10 for an Uber" + "mylilnonce123" = "00cab8a..."

Ben tells Henry and Sam. They also check that it works: it does. They also remember and agree that Ben did pay £10 for an Uber, so everyone adds it to their list. Ben gets the honour of proposing it because he won the race, and the others agree. Maybe he had more computers, so he put in the most effort or paid the most in hardware and electricity to do it. Either way, he sacrificed something to find the nonce.

Why would you do all this work?

This is great and all. Ben has done a lot of work and added another entry to the list, but what's in it for Ben to do the proposing? And what if he is lying to add a fake transaction?

To give some incentive, small rewards are given out to the first person who finds the nonce value and proposes the new addition, giving them a reason to do all this work to try to find it. For example, "Ben receives a £1 tip" is added to the list.

When it comes to whether Ben is lying, he definitely could be. He could find the nonce value and say, "Ben paid £1,000 for an Uber." But we assume three things:

• If Ben is constantly winning the proof of work competitions, perhaps because he has loads of computing power, then the list system is now essentially centralised instead of decentralised, defeating the whole point.
• Ben is only proposing the next event. If it contains a fake item like "Ben gets £1,000", then Sam and Henry don't agree: "I don't recall this happening?!" They can still outvote it. If they do, Ben is just wasting energy.
• If lots of fake transactions are happening on the list, then the monetary values on the list are essentially worthless: "Yeah... It says you're owed £1,000, but I don't believe you." Ben ends up with worthless paper money. It's much better for Ben to just get those £1 tips.

If, for some reason, Ben and Sam come up with a nonce value at the same time, they both add the new item to their lists, each including their £1 tip, and we now have two lists. We continue like this with two lists, or a fork. This happens quite a lot! To resolve this, we actually just keep going with the exact same system, but we now have two competing lists. Whichever one gets an item added to its list next is the winner, and that becomes the "true list". This also means whoever's list had the tip is the one who gets the tip, because that becomes the solid version of history.

Technically, transactions on a blockchain are never confirmed, but the more events you add after them, the more likely they are to stick. This is because if you wanted to create a new version of history, e.g. starting at event 2, you'd have to go back and find a new nonce, then do the same for event 3, event 4, etc. This requires a lot of effort, and whilst you're doing this, the true list continues to grow and get longer.

By using this system, we can have a somewhat decentralised way of recording who is owed what, i.e. who has what money, a way of verifying which transactions came in which order using the hash chain, and a way to decide who proposes the next items added to the list. By replaying the chain of events in the list, you can work out who is owed what.

It might be wrong, it might be right, and we don't know, but it's enough to give us an acceptable working system, in the same way that a centralised system could appear correct but might be wrong or contain errors or lies.

A better way to agree on history

We now have a system for tracking who is owed what money in a distributed way that can, to some degree, be trusted as well as any centralised system.

You may have heard on the news how "Bitcoin wastes as much energy as the entire country of Argentina". This is mainly due to its system of nonce-finding, which consumes a huge amount of electricity for the comparatively tiny outcome of recording an event in time. You're forcing these computers to perform billions of unnecessary generations and tests of random nonces that serve no purpose until they find the correct one. So perhaps there's another way of doing this that isn't so wasteful.

At the core, we need a mechanism that makes it "costly" to propose a new item to the list. Before, we used effort, energy, press-ups, or computing nonces on a computer. What other ways can you think of that symbolise cost?

Other than pure energy and time, the only other thing with a cost is something with perceived value, e.g. money, gold, Lamborghinis, cash, or digital currencies.

So instead of saying you need to do 10 press-ups to propose a new item to the list, or do a billion computations to find a nonce, why don't we say, "You need to put up £100 to propose a new item. If it's right, you'll get it back, plus your tip. If you're outvoted, you'll lose your £100."

This is exactly what proof of stake is. You "stake" some money to give yourself the right to vote, a.k.a. to submit your history of what happened on the blockchain. The more money you stake, the bigger your voting power, but the more you stand to lose if you are found out to be a fraud.

This is basically all you need to understand about proof of stake. It's just a simple and more energy-efficient way to add a "cost" to voting, so that no one person can submit 10,000 votes and people have a stake in determining the true version of events.

If Ben stakes £10, Sam stakes £10, and Henry stakes £10, then we randomly choose one of them to be the person who adds the next item to the list, because each person has 33% of the stake.

Let's say there's a new item:

"Ben paid £8 for some coffees"

Ben is randomly picked to add it, so he does. Henry and Sam agree, "Yes, he bought us both mochas," so it's added to the list, and Ben gets a £1 tip.

Let's say Ben is evil. He wins the stake but tries to add this item:

"Ben paid £800 for some coffees"

Henry and Sam don't agree: "I'm not sure coffee costs that much," so they vote against him. Not only does Ben get no tips, but he loses his £10. The stake gives you the chance to propose a new entry and win a tip. It does not automatically mean it's added to history.

Wrapping things up

At this point, you should have a basic understanding of why blockchains even exist and how they work at the fundamental level.

You can go further than this in terms of technical details, but you are then just wading into optimisations.

If you only remember three things: a blockchain is a shared list. Hashes link its history together. Proof of work or proof of stake helps everyone agree on what gets added.

If you read this guide and got lost, we'd love for you to get in touch so we can improve it!