The Blockchain Problem Space – When to Use Blockchain?

You really need a blockchain for ONE THING:

To timestamp transactions in a distributed way.

Transactions can be signed, proving authorship.

At signing time, you can prove the transaction happened AFTER something else.

The only thing missing is PROVING THE TRANSACTION HAPPENED BEFORE SOMETHING ELSE.

For that, you need an incentive structure to keep each transaction be accepted by someone, somewhere, in a growing merkle tree.

That's the blockchain.

However we don't need proof of work to elect the next miner for every block. It leads to an incredibly wasteful arms race.

In fact we don't even need every transaction to be verified by a miner. Only the merkle tree that happened before the block signing time.

Proof of work does not elect the next miner.

Proof of work means that the lucky random miner has invested energy on a previous valid block, and is lucky enough to find another valid block.

If you take that away, you could as well use a database and a trusted timestamp server.

The other major issue with Blockchain is that "all nodes can see everything". This is theoretically a problem with distributed databases as well. However, in the case of distributed databases, the database nodes that can "see everything" are not the end user, whereas, in Blockchain because the nodes are untrusted, one must assume that the end user can see the entire Blockchain state.

This limits the number of use-cases tremendously to those where "everyone-can-see-everything" is an acceptable tradeoff.

There are several ways around this.

1) Zero Knowledge Proofs. But these are highly specialized and resource intensive. To my knowledge we don't have these for generalized Smart Contracts.

2) Split the overall state into Channels, Subledgers etc. with narrower "viewing rights". But again this typically involves an application compromise.

3) Encrypt or cryptographically hash portions of the state. But by definition, this portion of the state cannot be acted upon by smart contracts.

4) Use frameworks like Microsoft's recently released CoCo Framework which relies on Hardware Trusted Execution Environments (TEE). The issue here is that a compromise of a single TEE negates the whole scheme.

In my opinion the privacy characteristics of Blockchain are a critical factor that needs to be taken into account while deciding on the suitability of Blockchai for an application.

Can you clarify the disadvantages of the application compromises required for option 2?

I'm currently looking at Hyperledger Fabric and it falls into that category.

I probably should not be capitalizing it ever and using it as singular everywhere. Thanks for pointing that out