I come from the enterprise space, have worked in setting up corporate governance frameworks and been exploring Blockchain applications for enterprises, so can share my thoughts on why there seems to be disconnect between the message in the Angus’s Coindesk post, and the thoughts expressed by the Trustory cohort. My comments will be limited to Financial Services space, as that is the industry I am most familiar with. For a bit of background, Angus was one of the key blockchain solution leads for EY’s Financial Services team in the US. While I have not interacted with him personal capacity, I am aware that he has interacted with a range of leading financial services, and it would be reasonable to assume the following:
Majority of his conversations are limited to exploration of permissioned blockchain solutions in the Financial Services space in US, and may be less relevant to non FS use cases (e.g., enabling supply chain transparency)
Some of the conclusions can be expected to be derived from project experience - this is not purely an opinion piece
In many instances, he may be bound by non-disclosure agreements, which is why some of his conclusions may seem to lack concrete evidence
It is helpful to breakdown the discussion into the following questions, and analyse each in turn:
What problems are private blockchain solutions attempting to solve for financial services?
Much like a distributed system, a group of enterprises often exchange information (e.g., terms of legal contracts) with each other to achieve some common goals (e.g., automation of a common business process). Ideally, enterprises want to automate the workflows supporting these information exchanges, as it helps reduce costs incurred mutually. However, automating workflows spanning organisations raises coordination costs:
Cost of developing standards: Enterprises can automate workflows for information exchanges if there is agreement on a set of protocols supporting the workflows (e.g., what certain contractual terms mean, how execution of these terms are implemented). If these information exchanges have significant manual work which results from lack of consistency/standardisation across enterprises, enterprises will set up dedicated consortiums which have representatives from each enterprise, and develop intercompany technical standards (e.g. ISO, SWIFT) which drive this standardisation across enterprises, and support automation of the workflows. This is the toughest part, and to Angus’ point, is largely a human/political problem, as you need representatives from competitors firm to think very deeply to identify common standards that apply across different operating models, and agree on terminology that can sometimes be impossible to agree on
Cost of implementation: Every party will ultimately have to integrate these protocols into legacy systems – depending on scale of project, this could take years to implement, and would require investment. (e.g., refer to consultation on ISO 15022 to 20022 messaging standards, which facilitates communications around payments and securities settlement – migration of securities messaging standards for some parties is expected to continue through to 2022!).
Cost of mitigating conduct risk: If poor implementation of these standards or protocols pose sufficient financial and reputational risk, enterprises will subsequently sign legal contracts which hold entities accountable should the protocols not be adhered to.
Costs of mitigating operational risk: If they believe the risks of contractual breaches is high (or very costly), and susceptible to “fat-finger” errors, they will additionally develop business process controls (e.g., reconciliation workflows) , and set of dedicated teams to perform those controls
Cost of governance: Additionally, dedicated committees will be set up to monitor these control failures, or contractual breaches, and will opine on how to mitigate them going forward, and also on designing or implementing changes to standards (these may very well be part of the consortiums)
Note: These are still oversimplifications to help develop a framework, and also are only a subset of the broader coordination costs I can envision.
In an ideal world, enterprises want to:
maximise the development of automated intercompany workflows that reduce costs mutually ,
minimise the costs of coordinating these workflows (brought out through requirement to develop technical standards, controls, committees, etc.).
What is a private blockchain, and what is wrong with them?
Private blockchains are networks operated by a consortium of entities which are using the network to support information exchanges. Typically, the information logged on the blockchain will be are append-only (meaning “immutable”), much like public blockchains, and the software network is mutually owned, and administered by the consortium members (although administration services can be node specific). One key difference between public and private blockchain is that enterprises in a private blockchain still continue to have legal relationships with each other, enforced through contracts. These contracts can be used to control against malicious behaviour, which limits the economic usefulness of on chain mechanisms that are more common in public blockchain applications.
The blockchain allows enterprises to develop autonomous workflows using the programmable standards they have designed, and the built in audit trail provides them with assurance that the standards operate as expected, which reduces the reliance on “off-chain” coordination mechanisms (controls, committees, etc.).
Use of private blockchains for designing intercompany workflows, however, pose some challenges:
- While automatable workflows lower costs mutually, reductions may not be allocated in a way that is mutually desirable, as some competitors in the platform may benefit more than others. This is precisely what happened with the TradeLens – IBM and Maersk’s DLT platform for supply chain of the shipping market (https://www.coindesk.com/ibm-blockchain-maersk-shipping-struggling)
- A bigger challenge with private blockchains is that they do not sufficiently minimise the coordination costs either. Let’s take some of the above coordination costs in turn:
Cost of developing and implementing standards: Implementation of automatable standards (much like the ERC 20 token standard) on a blockchain will require that standards are developed as a pre-requisite. This will invariably require a coordination body (such as a consortium) to develop and implement, and organisations would need to devote resources to fund this cause. This also means a business case for a blockchain solution has to be very strong for a consortium to be formed and sustained, which may deter participants from agreeing explore a blockchain solution in the first place.
Cost of mitigating conduct risk: Organisations are legally registered entities, and still rely on laws of regulations of relevant jurisdictions to facilitate transactional exchanges, and enforce accountability should the parties act “maliciously”. One could argue that digitisation of legal contracts, and enforcement of clauses through a set of smart contracts could minimise reliance on the justice system, but in the enterprise world, we are not even close to getting there (refer to UCL paper on smart contract development, which provides an excellent overview of challenges that faced in digitising legal contracts - http://www0.cs.ucl.ac.uk/staff/C.Clack/research/JDigitalBanking-Clack-AuthorPreprint.pdf)
Cost of mitigating operational risk and governance: I believe some of the controls and decision making processes can be developed into automatable standards, but again, this would require standards to be developed as pre-requisite.
Are there alternatives to automating intercompany workflows via private blockchain?
Yes, and some alternatives can offer lower coordination costs. One proposed model is development of “utility service”. The services could very well be the same set of workflows, but are deployed in a distributed database, centrally controlled and governed by a third party. It is upto the third party service provider to identify the common set of standards, and develop new utility services which can add value to multiple clients. While utility services have long existed in financial services (e.g., https://www.refinitiv.com/en/products/kyc-know-your-customer), there are open questions on if they are cost efficient, and if a third party can develop the service quicker and better than the organisations themselves (who go on to enable the services via a private Blockchain).
A hybrid model (e.g., promoted by Corda platform, developed by R3 consortiums), splits services expected from a distributed database, and allows entities to take on different roles, and operate different parts of the database which allows them to offer different services that the Corda platform helps coordinate (this will encourage development of new business models which allows governance of some of services to be more decentralised - the following blog by Gideon Greenspan provides a great deep dive in to the Corda platform, and compares it to other private blockchain solutions: https://www.multichain.com/blog/2018/05/r3-corda-deep-dive-and-technical-review/).
What, then, is the Unique Selling Point of a private blockchain, and when does this make sense?
My personal view is that the only unique selling point of a private blockchain solution is the built in audit trail it provides, assuming it is designed as an append only ledger that parties can rely on to collect a “proof-of-process”. This audit trail will offer parties the guarantee that the workflows they have developed are indeed working, and reduce reliance on external processes that they currently need to develop (controls, committees, contracts, etc.) - this in turn will reduce some of the coordination costs currently seen.
Note that this “proof-of-process” service can also be provided by a centralised service provider, should the organisations want, which can explain Amazon’s foray into this space (https://aws.amazon.com/ru/qldb/), so the USP is not yet set in stone.
So will private blockchains ever make sense?
Yes, if the following conditions hold:
- If the cost reductions/benefits are shared by parties in a manner which is considered as “fair”
- If cost reductions/benefits relayed are substantially better than a centralised solution (e.g., a utlility service)
- If the coordination costs are lowered - this will happen when (part of an ever growing wish list):
- More industry standards are developed
- Consortiums have been made operational (or already existed before blockchains were being explored)
- Infrastructure is tried and tested
- “Smart legal contracts” are real, which reduced reliance on justice system, and adds more value to use of blockchains
Note, all of these are happening in parallel, and different industries are in different stages of maturity. These are general observations I have had from my explorations, and would be curious to learn if people disagree with above, or have anything more to add.