Standardization can provide “economies of scale” benefits and ensure effective interoperability between different systems and platforms.
It also provides the conditions to avoid anti-competitive behaviours and to efficiently conduct market operations. Nevertheless, there are concerns regarding an overly prescriptive approach that could prevent innovation at this early stage of DLT maturity.
Taking an abstract approach, a DLT use case can be broken down to two abstract layers: the ledger layer and the applications layers. The ledger layer is based on either open-source ledgers, downloadable from public repositories such as github.com, or on proprietary ledgers developed by individual developers/vendors. One may ask if standardization is actually required on the ledger level. Multiple ledger types exist for a reason, as they vary one from another by features such as consensus mechanism, smart-contract coding language, resource requirements, and more. They also vary by their suitability to specific use cases.
By now, it is technically impossible for ledgers of different types to use the same chain. Thus, standardization of the ledger layer should not focus on reducing all variants of ledgers down to one common ledger type or to one common chain type, but rather on promote interoperability between different ledgers. One possibility is to create a standard method to link or refer to records that exist on different chains created by different ledgers. A technique called “atomic swap” may be used where at least two parties want to exchange digital assets without intermediaries. It can theoretically be implemented on any chain but it easier between ledgers that share some features (like the same consensus algorithm).
“Standards facilitate interoperability: this is important for competition. Furthermore, by setting ground rules, common terminology, development methods, and measurement techniques, standards enable the development of follow-up innovations and the diffusion of innovations. Standardization may also help create critical mass in the formative stages of a given market. However, setting standards can also pose risks: they may lead to undesirable lock-in into sub-optimal technologies and allow incumbents to create barriers to market entry with negative implications for innovation.”
Source: Innovation policy platform.
So, standardization at the application level is where the industry should focus. One must keep in mind that to-date, all applications are proprietary developments. While DLT may disintermediate hierarchical top-level repositories, the applications remain the IP of the developers thereby creating a vendor-lock-in. When the application is developed in-house and serves a single organization, this may not pose a problem. However, in instances where the application serves multiple (sometimes competing) entities, vendor lock-in is a situation to be avoided. Vendor lock-in creates dependency, reduces diversity and increases operational risks. This is where standardization can bring real benefit. To begin with, there are certain functions, such as identity and payment, which are common to the vast majority of use cases. Those functions would be the first candidates for standardization. Other functions may be more use-case specific and it may make sense to dissect them to what one may define as an MVP (Minimum Viable Product) and VAF (Value Added Features). Standardization of MVPs would then allow developers to compete on the VAFs, differentiating their offering from that of others.
A common approach towards standardization would be to build an abstract RA (Reference Architecture) that defines the basic building blocks, and their relations/information-exchange points. The next phase would be to look at the functionality of each building block and define it using state-machines or flow-diagrams for all lifecycle operations of the entire application which then constitute the standard operation of such blocks that developers should built to. It is not uncommon that when use cases (MVPs) are being added, commonalities are discovered thus making certain developments in one MVP reusable in another. This is the approach followed by iCommunity Labs, which seeks to create a RA that serves as a ecosystem platform for the quick development of use cases from the reuse of others already created, or of some of its existing building blocks.
Another important aspect of standardization is portability of applications between ledger types. Clearly, each ledger has a somewhat different northbound (ledger to application) interface that requires, as a minimum, different APIs (AKA “2nd layer”). However, with the use of different coding languages for smart-contracts by each ledger, such portability may require rewriting the contracts which, to-date, is a manual task. It would be of benefit to develop a standard abstract smart-contract template that can then be automatically compiled to the ledger of choice. Though it may look far fetched by combining application portability between ledger types and standardizing linking or referring records between chains, we allow interoperability of applications that run on any type of ledger.
Data portability is also relevant both in a context of application portability. Additionally, there are no standards for data exchange between ledgers (through inter-chain interoperability) that may include public keys, hash values, tokens or other data managed by smart contract.
Looking at the different use cases, it would be safe to state that most of them will benefit from the adoption of a standardized approach to application development. It is not recommended, at this stage, to enforce the choice of ledger type (e.g., Ethereum, HyperLedger, a proprietary ledger or any other ledger available for use) per use-case type, but it is recommended that the industry develops guidelines highlighting the benefits and disadvantages of different ledgers and thus their level of suitability for use cases of different natures. From electronic mortgages to pharmaceutical supply chains and distributed energy generation to public sector loans, all applications can take advantage of cost reductions and the interoperability inherent to standardized interfaces. A core benefit considered with standard interfaces is the portability of solutions between alternative service providers.