This post is a rebuttal of this article on Coindesk posted on September 27th by Angus Champion. As a company that trains on blockchain use cases, develops solutions with private and permissioned blockchains and has a mission of adoption, we felt that the article simply muddied the water.
On definition, Angus gets it wrong either due to narrowness of research or simple lack of it. For instance, Kenya’s government has had a taskforce receive proposals and presentations on blockchain. The definition they worked with led to a proposal to create a national cryptocurrency – a Central Bank Digital Currency (CBDC) – and release it by ICO. The taskforce chair Bitange Ndemo is an experienced ICT policymaker with a good grasp of technology, very capable of telling the difference between a distributed ledger and Google Docs. When IEBC proposed using a blockchain system for the 2022 election, they were referring to a blockchain or distributed ledger with the append-only characteristic that makes blockchains so attractive where trust is eroded or absent…elections are an obvious area for this in Kenya.
On differentiation, Angus conflates a blockchain with a smart-contract platform. These are very different and do not necessarily go together. A blockchain with smart contracts is possible and there are examples, but it is not necessary for a blockchain to be a blockchain. Just like a phone may have two SIM-cards, and such phones are common, but people generally don’t treat the dual-SIM feature as a default expectation on a phone. Secondly, a distributed database is not append-only and neither does it enforce consensus by default. So saying a distributed database can do everything a blockchain can do except for prevention of central governance is deceptive and inaccurate. Especially since private blockchains are not designed for the decentralization of control but rather for the multiplicity of audit points that must all agree and the append-only nature of such agreement. His contention that blockchains have to be changed by creating new software and upgrading nodes is almost silly when one thinks of the ubiquity of software updates on phones, PCs and so on.
His key question:
What are the reasons an enterprise would prefer to sacrifice many measurable metrics – transactions per second, disk space, speed and efficiency of computation, cost of maintenance – and opt instead for deploying a technology that is harder to administer?
is both wrongly framed and not that difficult to answer nonetheless. An enterprise would opt for a blockchain to maintain an audit layer beneath their database layer, defending themselves against malicious activity by employees or other actors on one hand and accidental data corruption on the other. Would they sacrifice anything? No. A private blockchain usually works together with a database layer, not in place of one. Is a blockchain hard to administer? If it is public then yes – the current BCH mining war is proof enough, as is the ETH-ETC split and the original BTC-BCH split. But Angus is specifically talking about private blockchains.
On process impact, Angus again conflates blockchain with smart contract without clear reasons. And seems to think legal contracts are the thing private blockchains are targeting. As a Multichain Partner, we work with a private blockchain that has no smart contracts of any sort. And the use cases abound because we are building solutions. If people are suspicious of public procurement, or elections management, or distribution of food aid..saying ‘use a legal contract’ would be a nonsensical solution. Saying ‘use a distributed ledger’ is a real solution, and WFP has in fact deployed a blockchain-based solution in Syria.
In his conclusion, Angus tries to lay out how he sees a private permissioned blockchain deployment going. And his stage 3 is ‘A trusted central party has now been created to govern the development of the blockchain’. He then goes on to explain that this central party should handle the transactions rather than the blockchain doing this. That is exactly like saying that since we pay a dentist to fix our teeth, let us instead just hire him to chew for us. His argument suggests a lack of appreciation of why institutions are using private blockchains. They are not using them to avoid trusted third parties. That is NOT what permissioned blockchains are for.
He finally predicts that if decentralized businesses emerge in the future, they are likely to come as a result of public rather than private blockchains. Which is a prediction at odds with reality. Most enterprise blockchain deployments are private or consortium-based, not public. Because organizations are trying to protect their data from single-actor or small-group manipulation, which any large organization faces as a real problem. Private blockchains allow them to do this, and with that resolve the risks of fraud, corruption, favoritism, theft and other ills that emerge from an ability to manipulate stored data undetected. In essence, a private blockchain gives an organization the ability to place important data in front of hundreds or even thousands of eyeballs, preventing unsanctioned edits by a small group of actors such as an ICT department or a group of sysadmins. At the same time ensuring only known (permissioned) eyeballs participate.