Blockchain for Nerds — Part 1: The basics

One of the things I find most peculiar about the blockchain / distributed ledger space is how alien it feels to me as a developer. After all, it is software, which is what I do for a living.

This blog is my attempt to bend this space to look more like what I’m used to.

I should point out that this is largely for me. If it proves interesting to others then that is a happy accident ;-)

A trip back in time

So what was the problem Satoshi was trying to solve all those years ago?

I remember in the early naughties, there was an expectation that we’d soon have a digital cash. I’d have some e-coins on my phone which I could transfer to your phone just like I could hand you a dollar note.

But of course the problem was, how could you stop me cloning that e-coin? Creating a high quality counterfeit note takes some effort, but a counterfeit electronic dollar is just a matter of copying some bits.
This came to be called the “double spend” problem.

How did Satoshi solve the double spend problem?

Well firstly, the solution was to not implement it like cash, but ironically, more like a normal bank account.
A Bitcoin is not transferred from my phone to yours. Instead a transfer is recorded in the Bitcoin ledger from my account to yours.

DIY centralized coin (aka Bankcoin)

Let’s step back a bit and think about how you might implement a simple bank account system if you were building one in a centralized manner today.
It will be for a coin that the bank (Bank) issues called Bankcoin.

We’ll represent this as the following two database tables (Account and Transfer):

Account 
 — accountId
 — balance

Transfer
 — fromAccountId
 — toAccountId
 — amount

Account is the current state of a single account. It has a unique identifier and the current balance.

Transfer is a ledger of transfers from one account to another.

We’ll have a TransferService that will process Transfers. It will apply the following business logic:

1. check that there is sufficient balance in the from account
   fromAccount.balance ≥ amount
2. store the transfer object in the Transfer table
3. deduct the amount from the fromAccount balance
   fromAccount.balance -= amount
4. add the amount to the toAccount balance
   toAccount.balance += amount

And voila we are done. We now have:

• a way to transfer money between accounts (whilst ensuring no-one can spend more than they have in their account)
• a record of each transfer (audit trail)

Decentralizing Bankcoin

OK so how do we take Bankcoin and turn it into a decentralized version?

Our previous implementation relied on trusting Bank to run the TransferService and maintain the integrity of our Account and Transfer data.

In a decentralized system, there is no single party that owns the data - we all do. So the essence of what we need to achieve is to end up with a system where:

• participants reach consensus about the Transfer records and their order. This is our shared ledger.
• participants are ensuring that we always enforce our TransferService business rules.
  This solves the so called “double spend” problem

When we are talking about the native coin of a blockchain at a 20,000 ft level, this in a large part what they provide.

The complexity is all in how they go about achieving that consensus. Somehow participants need to be incentivized to follow those rules and strongly disincentivized to break them.

Achieving that was the genius of Satoshi.

I won’t go into how that was achieved as that is covered extensively elsewhere.

My goal was simply to try to squint my eyes enough to see what it looks like in a form more familiar to me and likely to other nerds.

A Passing Thought

One last point worth noting in this post. In most applications that a typical developer deals with, the focus is on the current state of the database.

It is rare to explicitly capture an audit trail of how the current state came to be. This is essentially what a ledger is.

Blockchains tend to focus on the ledger, as that is where the challenge comes in. I think this is a big source what makes blockchains seem alien to me.

Next time

In Part 2: I’ll take a stab at smart contracts