In his recent article “Four genuine blockchain use cases”, Gideon Greenspan rightly points to one of the hidden trade-offs around Blockchain.

Gideon writes: “The two most important differences between blockchains and centralized databases can be characterized as follows:

• Disintermediation. Blockchains enable multiple parties who do not fully trust each other to safely and directly share a single database without requiring a trusted intermediary
• Confidentiality: All participants in a blockchain see all of the transactions taking place. (Even if we use pseudonymous addresses and advanced cryptography to hide some aspects of those transactions, a blockchain will always leak more information than a centralized database.)”

“In other words, blockchains are ideal for shared databases in which every user is able to read everything, but no single user controls who can write what. By contrast, in traditional databases, a single entity exerts control over all read and write operations, while other users are entirely subject to that entity’s whims. […] Blockchains represent a trade-off in which disintermediation is gained at the cost of confidentiality.”

Slightly changing Gideon’s conclusion, I would rather consider it as a trade-off between confidentiality and transparency. Disintermediation is a desirable by-product of transparency. We can observe in many markets that higher transparency fuels disintermediation.

The second trade-off is between trust and speed. Using the Bitcoin blockchain with its proof-of-work generates trust, but at the price of speed. A private blockchain or distributed ledger with a different distributed consensus method (e.g. proof-of-stake) can be much faster, but we need to rely on a group of trusted parties (nodes) again.

While people might say, that this trade-off is rather of technical nature and can be overcome, I would doubt that. Any proof-of-work needs to be hard enough to give the majority of honest nodes/miners a fair chance to compete with a minority of dishonest nodes acting in concert. This basically forms a lower limit for the envisaged amount of time to pass the proof-of-work. (Bitcoin is designed in a way to maintain an average block time of 10 minutes.)

Closely related is another trade-off, efficiency versus energy consumption and costs. A proof-of-work like the one used for the Bitcoin blockchain requires not only time, but also a significant amount of computational power to complete, which consumes a lot of energy – by the “winning” miner but also by the competing miners. While Bitcoin currently has about 5,700 nodes according to Bitnodes, the number of miners might be as high as 100,000 due to mining pools, which multiplies the energy consumption. In an academic research published in 2014 (“Bitcoin Mining and its Energy Footprint” by Karl J. O’Dwyer and David Malone), the authors estimated that Bitcoin’s energy consumptions at that time was already comparable to that of the Republic of Ireland.

Of course, those costs of that computational power plus reasonable profit margins for the miners will be charged to the users as transaction fees (and perhaps also indirectly in the form of block rewards for miners, as in the Bitcoin blockchain).

The fourth area we might need to look at is deterministic versus probabilistic finality. Using a blockchain for any kind of asset-transferring transactions, we need to ask ourselves first (and afterwards our lawyers), when those transactions are final and irrevocable. In any central ledger, there are clear rules for legal finality of transactions. Sometimes they are easy, sometimes more complicate (e.g. for selling companies, real estate or securities), but they all have in common that at a certain, well-defined point in time the transactions are legally final. At that point in time we are the legitimate owners of those assets.

In a blockchain, however, this is nontrivial. In the Bitcoin blockchain the majority of nodes decides eventually, but – as Bitcoin wiki points out: “To be secure against double spending, a transaction should not be considered as confirmed until it is a certain number of blocks deep.” Even after that, there is still a – however very tiny – residual risk of rejection.

What do you want to require in a private blockchain? That a majority of trusted nodes confirm the transaction? Means just 51% is fine? That would be a rather small margin in that context, where we are supposed to trust the nodes and assume that they all will come to the same conclusion. Do all nodes need to confirm the transaction? What is, if a few are offline or face a DDoS attack? Is 95% okay? Or 75%? Eventually, that needs to be decided by policy makers, regulators and lawyers, of course.

Probably there are more trade-offs behind blockchain and I am very much looking forward to discuss that.

If we have clarity about those trade-offs, it is much easier to find the right distributed or central ledger solution for our applications. By all means, we should avoid falling into the Maslow’s hammer trap: “If all you have is a hammer, everything looks like a nail” with blockchain technology being our hammer.

Please also read Gideon’s original article here. It is definitely worthwhile reading, as it also elaborates on the following four blockchain use cases:

1. Lightweight financial systems.
2. Provenance tracking.
3. Interorganizational record keeping.
4. Multiparty aggregation.