Implementing a DLT-based solution has dogged the tech from the very beginning, severely limiting its application. Today, DLT can interoperate quickly & smoothly, permitting real possibility to be realized across many use cases. Over the years, several attempts have been made to solve the issue of interoperability. Of the numerous methods taken, the World Economic Forum (WEF) identified 3 main categories: Cross Authentication (DLT-relayers), Oracles & API Gateway.
Category 1: Cross Authentication
This category is the most decentralized of the 3 types. It needs separate authorization on each side of the interoperability connection. For instance:
- DLT-relayers: are distributed ledger communication protocols that perform as orchestration layers between other distributed ledgers. They are developed to exchange different message types between these networks. 2 DLT-relayers are Ethereum 2.0 & Polkadot.
- Hash-locking: used to atomically reciprocate assets across distributed ledgers.
Category 2: Oracles
This permits distributed ledgers to connect to external data resources. These are orchestration layers related to different resources to perform various functions per on-chain & off-chain pre-defined bespoken regulations. Some of them transfer data from an external data resource to smart contracts and send information from distributed ledger back to an external resource.
Usually, a single oracle is used to execute each task, but occasionally there can be oracle collections to perform a similar task (in a permissionless or permissioned manner). Smart contract logic then defines how data consensus is achieved between multiple inputs recorded by different oracles. An example of this system is Chainlink.
Category 3: API Gateway
An API offers access to the server & the resources it is connected to. It provides organized access for numerous underlying API resources, simplifying requests to enhance user experience. A DLT API gateway can have shared endpoints across distributed ledger networks, standardized DLT data objects & can compress several DLT functions into one endpoint. This method is taken with Quant's Overledger API.
DLT-relayers have been in development for several years; they aren't yet proven tech, as there isn't any stable implementation running in the high-load environment.
Decentralization procedure: According to WEF, 3 different models have different decentralization properties. DLT-relayers can be completely decentralized if a permissionless DLN is used. Oracle has 2 different permission levels, one depending on the network permissions & the other on the smart contract permissions. With API gateways, the decentralization amount is offered by a separate API gateway ecosystem run by different shareholders.
User interaction: For DLT-relayers, users either require to be offered direct access to relayer nodes or provide access to its nodes through an API gateway model. Non-oracle users can communicate with on-chain oracle smart contracts or can interact with an off-chain oracle instance. For API gateway, users interact via API using typical elements like REST.
Resilience: The resilience of DLT-relayers depends on the consensus protocols it runs, especially that of a connecting chain. Each consensus protocol limits the percentage of malicious nodes that it can tackle; the entire network resilience depends on the no. of nodes in the network. With oracles, the more oracles that feed information about the same subject, the more resilient the system will be. An API gateway's resilience is decided by the no. of instances running & its load balancing potentials, which can be tuned for each case type.
Combining permissioned & permissionless DLNs: There is no convincing theory or technical demonstration of how this can be completed using DLT-relayers without compromising security.
Image source: Unsplash.com