5 Things I learned from Implementing a Simple Blockchain

I went on a quest to implement cryptocurency concepts in code. In my previous article In code we trust, I argued that one must implement cryptocurrency concepts in code in order to understand them. I still stand by that statement but now I understand why very few bloggers do that. It is very boring to read. Don't get me wrong; it was fun to think about it and write code but I must be honest with myself and admit that very few people will want to read it carefully. My Chain of thought jupyter notebook is for those brave souls. The rest of the article focuses on lessons I learned while writing code for a simple blockchain.

Not money

It's better to not think of cryptocurrency as money. It's an immutable list of transactions. When you add entities that maintain the ledger and validate each other entries, the most apparent application is to "send" units of value from one address to another. The true value of such ledgers comes from enabling cooperation between people, autobeings, aliens, unicorns, or anything else that follows the protocol.

Not complicated

It turns out that the main concepts are very simple. I reconstructed them with very few lines of code starting from a simple list of transactions and making any attempts to tamper apparent. Specific implementation matters a lot. That is what separates successful coin worth millions of dollars from worthless crap.

Not a database

I kind of knew that before but I didn't really appreciate how special the first and the last blocks are. Blockchain itself is a crappy database. It's only good for verifying chain integrity. It's incredibly inefficient even at that task. Any blockchain should have a better data format on top of it. It would be interesting to check what data formats are used by famous coins.

Game of rules

It's fascinating that a lot of coin rules don't need to be spelled out explicitly in the blockchain. They are reinforced only by miner implementation. For example, blockchain doesn't need to contain wallet balances. It's calculated by summing up all the transactions with the wallet's public key. This is a cool feature but it's easy to create ambiguous rules or rules with unintended consequences. Let's say we allow a negative balance in our transactions. It might work for a while until some smart soul realizes that she can create wallets, empty them down to that negative amount into another wallet, and abandon the ones with negative amounts. Even though the example is simple, the relationship between negative account balance and the ability to limitlessly print the coin is not very apparent. It seems to me that complexity increases with the number of those rules. With complexity the chance of unintended consequences increases as well.

Validation right

Distributing validation right using proof of work is genius but it feels wrong. It reminds me the famous Arthur C. Clarke story The Nine Billion Names of God. No wonder people are looking for alternatives. I wish there was some law of quantum randomness that could distribute validation rights and didn't accept bribes. I doubt it's possible in this universe though.

What's next?

First, I'm going to look into some real blockchain formats like Bitcoin, Ethereum, Steem, and maybe another interesting coin. There must be immutable database-like structures that are already implemented. After that, I'll work on some tools that can tell me some stats about blockchains. The rule is that the longest chain wins but I'm curious how many blocks die on average, replaced by a longer chain.

I'm going to continue to explore the cryptoverse through code. Any suggestions on which areas I should focus?