What is a blockchain?

Non-Asset Applications of a Blockchain

In researching this site, I explored a lot of alternative uses of blockchain technology. Despite many websites claiming such alternative uses exist, they all boil down to keeping track of assets as if they were in limited supply (like money).

For example, you could use a blockchain to keep track of who owns a digital book. I'm not sure why anyone other than a book-seller would want this, because it certainly wouldn't prevent book piracy, since the book's bits are valuable in and of themselves. Bitcoins are only valuable if someone accepts them as payment, which they would not do if you had “copied” them from someone else. A book, on the other hand, is useful to anyone that has the bits, so a copy of a book is just as valuable.

Blockchains could also be used for digital contracts, but it's not clear why these are better than legally-binding contracts in your country. It seems like all the reasons why my signature on a contract might be problematic still hold for a digital signature on a contract on a bloackchain. It's more likely that the interpretation of the terms of a contract would be in dispute, not the fact that the contract was signed.

In fact, blockchain-based currencies don't solve a fundamental problem in commerce, which is not getting what you paid for. If I purchase a vintage analog synthesizer on eBay and it turns out to be broken no trustworthy, highly-distributed ledger is going to make it easier for me to get my money back. In fact, it makes it much harder—in the United States you can issue a chargeback to your credit card if you the merchant didn't deliver what they promised. This is only possible of a single, central authority that we all trust. This would not be easy or possible using a blockchain-based currency.

The practical applications of a blockchain seem limited to situations when two parties who do not trust each other want to do business, and they also don't trust (or don't have) a central authority to broker the deal.

That said, a distributed trustworthy immutable ledger seems useful. Let's try to apply it to a real problem anyway and see how it works.

A Real-world Non-Asset-based Example

Suppose we maintain medical records and our users are distributed world-wide. A naive implementation would be to have a central server that our customers interact with via a web browser. The customer's distance from that server would affect their performance.

Customers farther have higher latency
Click to embiggen

If the customers are high-traffic sites like hospitals, the poor performance could have material impact on the hospital's operations. Although we need to eventually have a canonical store of all transactions the hospitals perform, we could put a local cache to capture them, shuttling them off to the central server in the background:

Customers could cache data locally for performance
Click to embiggen

There is a risk with this setup. If the central server is unavailable for some time, data will be trapped on each customer's node. In order to get all the data from all customers, they all need to be online and connected enough to transmit data around.

We could replace this system by using a blockchain. The distributed ledger would be our database of customer activity, and rather than have caches talk to a central server, each customer forms a network of nodes using the blockchain technology we've described. As long as one other node is up, the data could be replicated and there would be very little risk of data loss.

A cluster shared the blockchain
Click to embiggen

Each node would be logging transactions against the shared blockchain ledger. The central server becomes just another node that, in this case, consumes the ledger for reporting purposes only. If any node dies or loses its data, it only loses the transactions it hasn't yet broadcast, and can fetch the blockchain from another node. Even the central server can lose it's entire database and rebuild it from one of the other nodes.

This is an interesting solution, but is it the right one? Is this the best solution to the problem?

No, it's not.

This use case is different from BitCoin's, and suffers the downsides more heavily. In BitCoin's case, there is no trust in any central authority, and we're tracking money. The blockchain works for this (though not great—BitCoin is currently unusable as a currency for regular people). In our case, we're building a system we want to be reliable and fault tolerant, but we're the central authority and we trust ourselves.

Because the blockchain requires serializing all activity to ensure its integrtiy, the overall performance of our health management system is going to be terrible. During busy periods, every node will be re-doing proofs of work hoping to be the first one accepted by the majority. This means that most nodes will be behind and at risk of data loss, meaning we have to have backups and controls in place (there's also a tremendous power requirement to constantly perform the proof of work).

There's also the risk of a fork—half the nodes accept one transaction and half accept the others. We have to detect that and fix it when it happens, because we only want a single source of truth.

Since we control everything in this system, it's easier to use existing tools and techniques, since we aren't sharing data with untrusted sources. Further, there isn't a strong need to coordinate every activity because we aren't managing finite resources. This is really what a blockchain does—manage digital assets as if they were real.

Managing digital assets as if they were a finite resource is not a common use-case. For common use-cases, it's more likely that existing solutions for dealing with distributed data will work far better, be easier to manage, and cheaper to operate.