Consortiums and Shared Ledgers: Supply Chains as a Use Case
This post is based on a presentation I gave in Hong Kong for Chain of Things and also one for the Scotland Blockchain meetup. This was inspired by a recent whitepaper I co-authored with Gilbert & Tobin. Since a blockchain/shared ledger is a network of nodes all coming together to share information and work together on different use cases a consortium model makes sense to deploy.
This presentation focuses on:
1) Different Trust Models that are used by the different blockchain and shared ledger technologies.
2) Privacy and confidentiality are the key design features when architecting blockchain solutions for financial services.
3) What is a Private Shared Ledger? How it differs from other solutions.
4) Why use a consortium?
5) The different types of consortiums
6) How to Form/Structure a Consortium
7) Different examples of consortiums (public & private models) looking at supply chains
8) How Internet of Things (IOT) fits in.
Different Trust Models
Different types of networks require different trust models. Below is a chart I put together to highlight the differences in each model.
If privacy and confidentiality are the main design feature for shared ledgers, tradeoff need to occur in order to make this work. All systems have tradeoffs and using a triangle to understand this usually helps. In this triangle, one can only achieve two of three sides at any time. The three most important features of blockchain/shared ledgers: 1) Consistency 2) Full Decentralization & 3) Enterprise Scale. So for example with Bitcoin and Ethereum, you get full decentralization and consistency (all nodes get data replicated to them) but you can't get enterprise. With this triangle you can shift it like a slide ruler, so you can have something between full decentralization and centralization, but of course you will lose consistency or scale as you do. Many of the shared ledger/private blockchain solutions have sacrificed decentralization because of the trust model they employ. The nodes need to be known, but not trusted on these ledgers so why bother with decentralization at all? Some of these models are no different than centralized databases with the addition of blockchain "features". Once you sacrifice decentralization and synchronization by not replicating to all nodes you can get enterprise scale and privacy and confidentitality while keeping the data consistent. Some use a node to node model some use a master node which validates and achieves consensus.
The slide below shows the difference between open, permissionless ledgers and shared/distributed/permissioned ledgers.
Shared ledgers and private blockchains have some or all of the features found in the next slide. These are the common design features associated with blockchain solutions.
The next slide comes from the KPMG report on Consensus I co-authored and shows how many use cases there are for financial services. There are just as many consensus mechanisms as well and this can be really confusing particularly when trying to implement different use cases and figure out the design features necessary for what you want to accomplish. For all of these uses anonymity can't be used and privacy and confidentiality are necessary. This makes most ways of doing consensus not suitable.
tIn fact there are many different solutions which are being deployed to tackle the privacy problem. In my blog post: "The Trend Towards Blockchain Privacy: Zero Knowledge Proofs", I go into deep detail about these systems and why they are being implemented. This includes zkSnarks, Zero Knowledge Proofs, zCash, Hawk, Confidential Transactions and State Channels.
Why Use Consortiums?
Consortiums make sense because the success of shared ledger and blockchain technologies requires significant levels of market participation, collaboration and investment. The consortium is less about a technology solution or a particular business model. It's more about how companies who haven't been able to trust each other in the past can come together and collaborate and share information. The trust is shifted to the shared ledger/technology solution. The participants just need to have similar requirements in terms of:
- the mix of confidentiality and transaparency (as captured in the design choices and operating rules for the shared ledger platform)
- functionality and processes
- the approach to governance and
- a shared view of regulation and compliance
All participants need to commit to complying with the operating rules of the consortium. Since these participants are known to each other they can deal with each other directly, without the need for a third party and innovate in a cost effective manner. This leads to collaboration with other consortium members where it makes sense.
These new technology instances are most powerful when you using a consortia model. Below is a diagram showing at the bottom platform consortia. Moving left to right you get public (things like Ethereum and distributed autonomous communities (DACs) to hybrids like Hyperledger which is modular to private like R3, AMIS, and Clearmatics Utility Settlement Coin. Many of these private models rely heavily on industry input and engagement. In the public model you don'y pay to be a member. In Hyperledger you pay a small fee and companies of all shapes and sizes can join plus you have a fee to join the Linux Foundation. In the private models it is much more expensive and exclusive. Incidentally companies like R3 are also part of and main contributors to Hyperledger through one of the main projects Fabric. Other major projects include Sawtooth Lake (Intel) and Iroha. All of these models are trending toward open sourcing their code to allow developers to build on top of their platforms and form communities around the technology. The DACs are truly a new business model as they are building decentralized companies in which the network participants are part owners of the company. Centralized companies will go away and the projects are creating their own economic ecosystems. Many of these projects are raising money through Initial Coin Offerings (ICOs) and those who invest get "appcoins" and owners and users of the network. These are essentially decentralized software protocols and are "disrupting the disruptors".
At the top right are business consortia these can be public or private depending on use cases and business needs of the companies and business units involved. Shared ledgers allow companies and business units to work together in a way they couldn't in the past. They provide end to end business processing and record keeping for corporations (particularly intra-company). This, in turn, allows companies to derive new efficiencies by sharing information, reducing costs and producing revenue generating opportunities. Many blockchain technology providers are building their own shared ledger platforms which allow companies to use it and work together on use cases and improving inefficiencies.
Next is the critical choices that need to be made. This comes directly from the report I co-authored with Gilbert & Tobin.
1) Setting the Consortium Strategy
Setting a consortium strategy at the outset is critical to the long-term success of the business consortium:
++ Identifying new revenue opportunities, which may not have been viable outside of the shared ledger environment;
++ Identifying possibilities for working with new organisations which may not have been practical in the past – and which could deliver new opportunities for collaboration, innovation and efficiencies;
++ Identifying the target consortium members – as well as those who may not be permitted to join;
++ Strategically consider who should control the consortium?
++ What are the competitive threats and long-term strategies for the sustainability of the consortium?
2) Choosing the Ledger Platform
Selection of a shared ledger platform is not like any other technology project – status quo processes won’t work. Before
evaluating potential options and selecting a “fit for purpose” platform, critical preparatory steps need to be taken to establish the basis for evaluation:
++ identifying all of the business processes and operational requirements (including regulation) that will need to be performed on an end-to-end basis; and
++ identifying how those business processes will be reconstructed on the shared ledger platform.
Private shared ledger platforms are by no means standard or uniform. Each platform provides different options for:
++ how confidentiality is achieved and how the “permissions” are designed: who can see, who can write, who reads, who validates;
++ how scalability is achieved;
++ how consensus is done (although some platform developers are questioning if consensus is even necessary);
++ how encryption and security are implemented and managed;
++ how smart contracts are linked with “real world” contracts (including hashing options), and how validation is carried out to ensure consistency between them;
++ capabilities for interfacing with information feeds (or “oracles”); and
++ capabilities for interoperability with other shared ledger platforms and legacy systems.
It is critical to choose a “fit for purpose” shared ledger platform from the outset. If the platform design doesn’t readily lend itself to delivering the consortium’s strategy, there is no assurance that workarounds will achieve the required result. Even if workarounds are possible, they may prove to be just too complex in practice. Failure to choose a “fit for purpose” platform from the outset may leave the consortium with little choice but to start all over again.
3) Choosing the Solution Design
Once the shared ledger platform is chosen, that is not the end of the matter. A technical solution design is still required, determining how the consortium’s specific strategy and operational requirements will be delivered on the shared ledger platform. This requires decision-making around:
++ the overall architecture of the solution – including how security and safeguards will be built into the technology and the
processes, and how real-world governance and decision-making will be integrated with the technical solution;
++ the design of the “rules engine” and the “smart contracts system” for automated processing on the consortium (including automation of the consortium’s operating rules where practicable);
++ how to create trust and security on the shared ledger? How will the public / private encryption keys be managed? Who will hold those keys? Where will the keys be held?
++ the specific protocols to be adopted in relation to “permissions” on the shared ledger: who can see, who can write, who reads, who validates – and how consensus will be performed, if required;
++ how the technical design will prevent (as far as possible) any breach of the consortium’s operating rules – whether by the technical operator or by participants on the shared ledger?
++ the required information feeds or “oracles” to be incorporated into the design; and
++ how to achieve compliance with applicable regulatory requirements – and in financial services, this may include considerations around redundancy and other technology matters which could impact on the stability of the relevant financial markets.
4) Planning to Mitigate Potential Pitfalls
While there are clear efficiency benefits and cost savings that shared ledgers can provide through collaboration and more effective information sharing, this doesn’t mean that competition / antitrust risks will disappear. There is no reason why consortium activity on a private shared ledger would be exempt from these laws. Under current Australian laws, consortium activity can constitute cartel conduct if the structure fails to incorporate appropriate compliance and enforcement measures. Upcoming changes to Australia’s competition laws will see the introduction of a “concerted practice” prohibition which sets a lower threshold for illegal coordinated activity than the existing cartel laws.
It is arguable that current competition laws do not take appropriate account of developments in the digital economy – at least in Australia. While this may change in the future, efficiencies and cost savings do not currently constitute any defence to cartel conduct - unless the consortium members pre-emptively seek “authorisation” from the Australian Competition and Consumer Commission. This is a public process that could take six months to complete. By comparison, if the consortium can establish well-designed operating rules and governance for the consortium, then it may be possible to rely on that framework to clearly establish the efficiency benefits – without the need to go through the public authorisation process.
5) Establishing the Consortium Framework
This is detailed in the slide below
This slide shows how a consortium forms. Someone (consortium promoter) decides that there is a reason for the consortium to form. Once this happens founding members and participation members join with different benefits or tiers of benefits based on the operating rules of the consortium agreement which are decided by a governance board. These rules include such things as legal and structural decisions of the consortium as well as decisions which are to be implemented on the shared ledger based on a specific technology implemented by the consortium promoter with input from all of its members. The smart contract system and the rules engine have ensure consistency between real world contracts and smart contracts and as is shown below this is done in both private and public models because "code is king" does not hold up.
R3's Corda matches real world contracts with smart contracts and hashes them to a blockchain. This is a decision based on best practices and governance because smart contracts fail when you need them most: when you need dispute resolution. There isn't a way to code this in and know how a dispute will resolve. By doing this you can going off-chain into the real world of courts to settle disputes. Corda comes to consensus on these contracts in two ways: 1) transaction validity: which is based on state outputs and contract code which match the actual contracts and signatures necessary. This allows for the counter parties to agree by independently running the same smart code and validation logic and confirm that the contract is the same. 2) Transaction uniqueness: this essentially makes sure there is no double spend by making sure the inputs are unique and no other transaction matches this one with certainty. A third party is generally involved in this piece of the consensus mechanism.
CODE (Centrally Organized Distributed Entity) uses real world governance to counterbalance smart contract "code" for the Ethereum (public) blockchain in order to ensure another DAO does not happen. An article by Zach Lebeau describes what exactly this entails:
"CO + DE = Decentralization Generator
CODE stands for Centrally Organized Distributed Entity.
The CO — Centrally Organized component — can be represented by a number of different company structures in various jurisdictions around the world. Because MME — the Swiss legal architects of the Ethereum Foundation — were integral in the formation of the CODE structure, SingularDTV’s CO resides in Zug, Switzerland. The DE — Distributed Entity — is the component existing on Ethereum’s blockchain. Together, the CO and the DE build a bridge between the centralized legacy paradigm and the decentralized Ethereum paradigm.
The engine of SingularDTV’s CODE is its Smart Contract System (SCS). The SCS decentralizes legacy assets and places them on the blockchain. The SCS also directs the flow of decentralized assets for the purpose of funding, building, maintaining and growing real world projects. Value resulting from these real world projects are routed through the SCS and placed back onto the blockchain via SingularDTV’s tokens, SNGLS.
When functioning at its potential, the CODE acts as a decentralization generator that perpetually places centralized assets onto the blockchain, growing the Ethereum ecosystem. In the coming years, when trillions of dollars of assets are placed on the blockchain, it’s structures like the CODE that will have helped make it possible."
SUPPLY CHAINS and IOT
At Devcon 2, Tyler Smith from BHP Billiton, one of the world's largest natural resource producers, presented Project Rai Stones (which can be viewed here) which is being done in collaboration with Consensys and Block Apps using the Ethereum public blockchain. This project is a blockchain based tracking application for wellbore samples. Smith explained that these samples are extremely expensive and can not be replaced. The samples themselves pass through many custodians, mostly all BHP vendors and they are currently manually tracked using spreadsheets and email. This leads to human error which can cause large regulatory fines when things aren't right. Smith also explained that there is a lack of transparency to business unit stakeholders and a lack of efficiency in finding metadata about these samples.
There are 3 nodes in this project: BHP, Weatherford (who is providing data analysis) and the regulators and the goal is to properly map businesses processes to a granular level than understand how to map that to a blockchain architecture. This flow needs to have a simplified version of process flow of the samples through the vendors and custodians to capture the analysis of the sample itself and link it to the digital object of the sample on a blockchain.
Below is a slide of the business process flow.
This allows for real time updates of the samples while getting rid of siloed functions, making tracking of information across functions and processes that are not as efficient as they could be for supply chains of all sorts. Billions of dollars of value travel on supply chains each day.
Other companies, financial institutions and startups are focusing on supply chains. IBM will use Hyperledger to build its solutions on and focus on supply chains. Below is a slide showing other companies focusing on supply chains.
The other use case touched on was industry cooperation more than just sourcing and origins of supply chains. The example Tyler Smith gave was around required public regulatory data that resource companies must give to partner countries that are set up in a contract before extraction can begin. It's not just BHP, but all companies in this industry that need to record and report things like production and location of assets to the partner countries who are required to make it available to the public. Their are firms that aggregate public data for the governments and the countries into databases and costs multi billions of dollars annually. The idea is to cut out this middle man by forming a consortium in the natural resource industry to report all public regulatory data that is required. Countries, regulators and natural resource companies can all be nodes in this consortium and publish real time access of this data for all to see and share information amongst peers. The countries themselves can save money by not needed to house this data since the blockchain has built in redundancy. This also improves transparency dramatically.
Since this information all needs to be open and transparent and a publicly recorded, BHP has decided to use a public blockchain. There are cases however where using private shared ledgers are necessary, particularly because of data leakage and sensitivity around pricing of invoices and businesses processes as the slide below shows. There are many different financial institutions and companies involved who would require sensitivity and encryption around the transaction and data flows. Using a public model in this case would not be warranted. In many instances, just the counterparties involved in each part of the chain might need to be involved, while the entire chain itself just knows that business logic/process flows happened with integrity.
There are lots of corporations, banks and startups beginning to focus on supply chains. IBM has announced this as their focus using Hyperledger. The Slide below shows other companies and startups building supply chain solutions using a ledger.
Elements of IOT would be needed for both models in order to ensure this integrity as value get transferred over large distances between many parties in sensitive climates and by land, sea and air in areas where there may or may not be wi-fi. The image below shows what is needed in order to make a robust supply chain enhanced by IOT.
Filament is an example of an IOT technology that works where there is no wi-fi by using radio waves.
The consortium model using shared ledgers works really well for use cases such as supply chains where business processes and information sharing between many different counterparties is necessary from a geographic and company endpoint to endpoint. However, any business process, no matter how automated, always has to leave space for human judgement, nuance and contextual understanding. This is why the consortia model needs human governance and real world legal solutions to go with blockchain/shared ledger technology making for a robust solution.
Conclusion
- Institutional trust wasn't designed for the digital age.
- The emergence of shared ledger technologies – empowered by consortia – is a game changer for a major trust shift, which will empower new business models and relationships between corporations and consumers.
- If shared ledger technologies realise their full potential, then the consortium model should thrive and be sustainable in the way that hasn’t been possible in the past.