Blockchain for beginnersIntroduction

This is a guide for developers who kinda sorta know what blockchains are for (making distributed crypto-currencies like Bitcoin possible) but have no idea what exactly is involved in that or how it works.

This problem is compounded by the fact that popular discussions of (e.g.) Bitcoin try to make it interesting by pumping up the mathematics side of it, which makes it sound even more inaccessible to developers without strong maths or CS chops. For instance, news articles will mention that placing a “block” in the “chain” - whatever that means - requires solving a very difficult mathematical problem. This sounds complicated! But it reality it’s just “mutate a string over and over until its md5 hash meets a very stringent condition”. Yes, it’s a difficult maths problem, but the implementation couldn’t be simpler.

By the end of this article, I hope you’ll understand why blockchains work, and feel comfortable writing a ~100 line toy blockchain client in your language of choice. (That’s one hundred lines, not a typo.) You can jump to the demo as soon as you like, but I’d recommend reading at least the first section below.

Why blockchain?

What kind of problem is a blockchain designed to solve? Suppose you want to write an database-backed app, without using a server. All your users will have a copy of your app, and must be able to read and write to a shared data store at will. When they read from the store, they should get the latest copy of everyone else’s writes. Since most blockchain implementations are crypto-currencies, this is often called a ledger.

How would we design an app like this? Since we don’t have a server, we’ll have to make all the copies of our app connect to each other and share data somehow. Luckily, this problem’s already been solved by peer-to-peer networking, most famously used in torrent clients.

But building a torrent client is easier than our problem, since torrenters will just be downloading copies of the same file. Torrenting is a write-once system: once a file is made available, it can’t be added to or altered. It’s easy to prevent people tampering with a file by putting a hash on it: if the hash of the copy of Twilight[aXXo].mp4 you downloaded doesn’t match the hash in the .torrent file, you (or at least your torrenting program) knows it’s an invalid download.

There’s nothing to stop a hacker from uploading a .torrent file that’s associated with a malicious copy of Twilight. But there’s safety in numbers: if thirty thousand people have downloaded a particular copy of the movie, and haven’t reported it as malicious, you can be pretty sure it’s safe - since you know from the hash that you’re getting exactly the same file that they did.

Like a torrent client, our blockchain app will rely on hashes to verify that you’ve got the right copy of the ledger. But unlike a torrent client, we don’t just want to download the right copy of the ledger - we also want to write to the ledger. The first glaring issue here is preventing someone from rewriting history. Since we don’t actually have a database, and thus have no single source of truth, we’ll have to find another way to stop people tampering.

Can we just stick a hash on the ledger, like we do with torrents? No, because every write will invalidate the hash. You could generate a new hash when you write, but there’s no reason for any other user to believe you’ve just added something to the ledger and haven’t altered anything you weren’t supposed to.

Hash lists

To solve this, blockchains rely on a data structure called a hash list (sometimes called a Merkle list). It’s a way to hash parts of the ledger and the whole thing at the same time. A hash list is a list where each element contains its content, a pointer to the previous element - like a regular linked list - and a hash of that previous element. If we both have a copy of the same hash list, and you add an element on the end, I can verify that you haven’t altered any of the existing elements by re-hashing the existing elements and checking the hash (stored on the next element). Once I’m satisfied that you haven’t tampered with history, I’ll accept your new element. Since each element contains the hash of the previous element, which then goes into the hash stored in the following element, you can’t tamper with the order of elements either.

In our blockchain app, our ledger will be stored as a hash list. Each element in the hash list is called a block. (This is where “blockchain” comes from: it’s a chain of blocks.) Every time we accept or generate a new block, our blockchain app will send the latest version of the ledger to all its peers on the P2P network. When they verify the hashes in the chain, they’ll add the block or blocks they were missing. Changes to the ledger will thus propagate over the network, without anybody being able to change the past.

Bitcoin

Even with a tamper-proof ledger, the distributed nature of blockchain means that...