Blockchains are commoditised off-the-shelf platforms. So, almost all projects designed to anchor data on a blockchain begin by choosing one of the available blockchain platforms (Bitcoin, Ethereum, Hyperledger Indy etc) and creating the application services stack around it. At Dhiway we spent a bit of time prototyping the design of our services stack and decided that we would look at something more fundamental – a set of libraries which allow us to design our own blockchain. And thus we built the CORD blockchain around the Substrate platform created by Parity Technologies.
There are well established methods and models by which teams select from an array of technology options. Some of these approaches include creating synthetic workload tests for performance, scalability and reliability. Others consider aspects of maturity of product or a short list of capabilities. Since we were at a stage where we completed a robust analysis of the business opportunities in front of us, we felt that the model best suited to us was to determine what form the technology platform takes to deliver what we need. The other necessary aspects of testing for performance; economics of node sizing and complexity of consensus algorithms follow from the ability to adapt this ‘form follows function’ approach towards the platform.
From the beginning our concept of a distributed ledger utility has been that of a ‘platform’. This is a term that is often misunderstood through overuse. To us CORD provides the bedrock utility around which a range of applications and microservices can be designed using available APIs. These applications and services can be plugged into existing or new ecosystems to build an expanding network of trust. At a grand scale of things, the availability of a resilient, well designed and always available platform becomes the key contributor to the creation of a rich ecosystem of trusted data sources and verifiable data exchange.
The discussions leading to the design choice focused on 3 broad areas of consensus – ability to get up to speed with a viable platform; availability of flexibility and modularity and not being tied down with tokenomics. It is important to mention that a design choice like this one is an integral part of the business strategy. It is necessary and absolutely important that anyone attempting a similar approach begins with a very clear understanding of the focus of their business.
- Building from scratch – Existing blockchain platforms have developed over the years with a large number of projects built around them. Whilst this creates a level of confidence, it also means that there continue to exist a set of assumptions. These design choices take time to be refactored and improved. The approach in Substrate is somewhat more aligned to our systems programmer view of the technology stack – use libraries to build projects; use modules to extend features and select a programming language in which team capacity can be built quickly. It took us less time to get up and running with an early version of a Substrate based blockchain than it took us to understand other platforms like Ethereum or Hyperledger and complete the analysis required to assess the customization load. The Pallet approach taken in Substrate allows us to build and extend the functionality and capability of CORD in a more secure, less compute intensive manner than in any other case. More importantly, this flexibility has opened up avenues to not be tied down by design choices in the underlying platform arising out of the existing project ecosystem making it more difficult to iterate and improve.
- Network of networks – The ‘one distributed ledger for everyone’ is a conceptual notion. In practice a host of regulatory requirements including scope of governance means that interconnected services often have interoperable blockchains. The design concept of ‘parachains’ enables this potential. So, data interchange and interoperability is enabled without the need to create special and custom plumbing between instances of distributed ledgers. The choice of Substrate as the underlying set of libraries also allows us to create need-based public/private and permissioned/non-permissioned chains as the deployment maturity demands.
- Avoiding tokenomics – We walked through this topic multiple times and concluded that being able to have a choice around tokenomics when we deploy our blockchain was desirable. Building around Substrate allowed us to spend time reviewing the cost of operations arising from tokenomics and rates of exchange. This allowed us to focus on improving elements of provenance and verification thus building the underlying platform to be ready for the business domains we focus on.
We think that the actively engaged community around Substrate is well placed to help jump start the adoption of deployments. And that the team has done a stellar job of building just enough to generate interest while keeping opportunities for contribution identified. For us it was very liberating to not have our plans and ideas constrained by existing design patterns and instead have the ability to create a customized approach based on secure, robust and well designed modules which enable a pragmatic degree of choice around consensus algorithms, scalability and performance as well as token related topics.
|Purpose||Cryptocurrency||Smart Contracts||Enterprise Use Cases||Enterprise Use Cases|
|Architecture||Single Chain||Multiple chains (shards)||Single Chain||Multiple Heterogeneous Chains (Domain / Consortium / Single Organisation)|
|Network Type||Public||Public||Permissioned||Public, Permissioned|
|Participants||Anonymous||Anonymous||Identified and Trusted||Identified and Trusted|
|Consensus Model||Proof of Work||Proof of Work||RAFT – Leader/Follower||Proof of Authority|
|Transaction Confirmation||10 – 60 Minutes||1 – 4 minutes||Variable (depends on transaction size)||4 Seconds with Finality|
Dhiway’s mission is to build scalable verifiable credentialing platform and choosing Substrate allows us to build meaningful platforms that contribute to this.