What is Distributed Ledger Technology , Interoperability & Its Layer ?

Summary

A DLT (distributed ledger) or blockchain implements a ledger that is shared across a network of nodes. Each node can create, broadcast, and validate transactions, which modify the distributed ledgers’ state. DLTs typically provide support to run smart contracts, computer programs whose output is recorded on the ledger state. Smart contracts are triggered by transactions, which are recorded on the ledger. Nodes agree on the validity and ordering of transactions via a consensus mechanism. 

Recently Research suggests that the market for applications using DLTs will grow, with many organizations stating that blockchain is a critical priority, due to, for example, cost reduction. A recent report from Gartner predicts that “by 2023, 35% of enterprise blockchain applications will integrate with decentralized applications and services”

Blockchain is slowly but steadily becoming an infrastructure for global value exchange and distributed computation Connecting those blockchains and making them cooperate (i.e., achieving interoperability) have a practical utility and importance. It allows communication between systems to exchange data and assets (fungible means. non-unique and non-fungible means Unique), leading to a higher heterogeneity of solutions in the market, synergies between projects, and higher liquidity to end-users. 

To connect DLTs and centralized systems, one needs blockchain interoperability techniques.

A centralized system can still be distributed, typically for scaling purposes, but its components are trusted and operate under the umbrella of one authority. More concretely, it is a system where the state consensus is decided by a single party or multiple parties under the same authority.

A decentralized system is distributed system where various parties control different components of the distributed system, and no party is fully trusted by all. In our context, we can consider a decentralized system to be a system where the state consensus is decided by conflicting or competing multiple parties, where accountability(from an external viewer’s point of view) of individual decisions is assured. Each party composing the system can vote autonomously and has different incentives from other parties.

Interoperability allows a set of systems to cooperate, to achieve a common goal – it is “the ability of two or more systems to cooperate despite differences in language, interface, and execution platforms”

Examples of interoperation between networks of the same and different technologies are studied

Cross-chain logic (or cross-chain rules) can be executed against pair of homogeneous DLTs (a pair of DLTs running the same DLT protocol) or heterogeneous DLTs (a pair of DLTs running different DLT protocols).

Interoperating heterogeneous blockchains is complex, as there may be differences in the underlying cryptographic primitives, data models, consensus models, privacy assumptions, integration capabilities, and others

This work proposes to support the choice of an interoperability mechanism(IM), also known as interoperability solution

Distributed Ledger Technologies, such as Hyperledger Fabric, Corda, and Ethereum implement DLT protocols. Each DLT protocol is defined by its protocol version, e.g., Hyperledger Fabric v2.3 , Corda v4 or Ethereum London Hard Fork. 

DLT Networks and subnetworks - DLT protocol scan be instantiated in DLT networks. DLT networks are groups of DLT nodes that make up a DLT system. For instance, Hyperledger Fabric might be instantiated in a DLT network composed by an enterprise consortium.

Each DLT network can be partitioned into subnetworks. Nodes of a subnetwork contain logically separated state compared to another subnetwork. Each subnetwork may offer different functionalities (e.g., data isolation, processing capabilities, governance) and security properties (e.g., partial consistency vs. consistency, better confidentiality, and so on).

At least one node of each subnetwork must connect to another node of another subnetwork for these two-subnetworks to be contained within the same DLT network.

Examples

1. In Hyperledger Fabric - a subnetwork corresponds to a channel. Channels isolate execution environments and data from other channels belonging to the same Fabric network.
2. Polkadot’s Parachains - could be considered subnetworks of the Polkadot network. A DLT network can therefore have multiple subnetworks. If the DLT network state can not be divided into multiple subnetworks, for the sake of simplicity of our evaluation, we say this DLT network has one subnetwork. 

Permissionless DLT networks - Every compatible DLT node can join the network. In permissionless DLT, anyone can run a node that interacts with the network

Permissioned DLT networks - Only compatible DLT nodes with permissions can join the network, where each DLT node may be assigned a particular role restricting the functions it can perform. There are two subcategories of permissioned DLT networks: private permissioned DLT networks, where DLT nodes do not provide public access to the data contained in the distributed ledger; and public permissioned DLT networks, where DLT nodes do provide public access to the data, such as via block explorers. In permissioned, only nodes with permissions can access the network.

Transactions are “the smallest unit of a work process related to interactions with distributed ledgers” , that, parametrized and signed by its creator, can be issued against a smart contract, via a DLT node.

DLT nodes agree on the order of transactions (and its content) to update the distributed ledger, by following a set of rules and procedures defined in a consensus mechanism. Typically, DLT networks have an anti-sybil component so that individual DLT nodes cannot replicate themselves to unfairly increase their influence on how the entire network reaches consensus. 

Interoperability among DLT networks. Different DLT networks can connect to other DLT networks. An interoperability mechanism (IM), often called a bridge, can connect networks to other networks, subnetworks, or centralized systems.

It depicts the mental model on DLT networks, subnetworks, and interoperability mechanisms. DLT protocols instantiate DLT networks that, in its turn, can be connected to DLT subnetworks.

The above picture considers the Carbon Emission Network (implemented with Hyperledger Fabric v2 and the Ethereum main net). The Hyperledger Fabric network contains two channels (subnetworks) that can communicate with each other, but not natively. 

Two Types of Interoperability 

1. Vertical interoperability - From networks to subnetworks and vice-versa
2. Horizontal interoperability - Between subnetworks and between networks of different systems

Blockchain interoperability is challenging because it implies going beyond two different trust boundaries and establishing a new boundary. Network boundaries also influence state ownership: in a centralized system, the state is owned by a single party, and hence any party interoperating with such a system needs to trust it. A decentralized system, in its turn, defers the state ownership to the collective, where a protocol is used to update that state (and achieve consensus).

A new (trust) boundary is formed when two systems are interoperating. The trust assumptions of the new boundary can be lowered by systems to provide proof of state for a blockchain view3. The new boundary needs to assume that each ledger is secure. Security depends on the threat model and network assumptions. 

Multiple DLT Decentralized Applications

Example

1. Hyperledger’s Cactus implementation of the Carbon Emission App from the Hyperledger Carbon Accounting and Neutrality Working Group 

• The purpose of this use case is to reward carbon emission reduction by orchestrating heterogeneous blockchains: one focused on data collecting, and another on the reward incentives.
• A Hyperledger Fabric network collects emission records (activity data), e.g., energy consumption, travel mileage, and widgets produced. The emissions records are not continuous because both the emissions factors and the data for calculating emissions are based on long time windows (e.g., utility bills are produced each month). Periodically, the activity is aggregated to be later converted to an emission token (ERC-721).
• Emission tokens are created on Ethereum’s public network from the collected data on Fabric to be traded against allowances that reward emission reduction. Figure3 depicts this network.
• The performance of Hyperledger Fabric in terms of throughput and end-to-end latency is superior to most public blockchains due to its consensus and low number of peers.

Interoperability Layers

Interoperability among computer systems is typically defined in terms of several layers. We adopt the European Interoperability Framework model from the European Commission. This model is based on four layers

1. Technical interoperability - Links systems and services by adopting compatible data formats, communication protocols, interface specifications, integration services.
2. Semantic interoperability - exists when systems can interpret information following a defined ontology (i.e. following a well-known model for information). 
3. Organizational interoperability - concerns aligning the requirements and interests of the user community by leveraging cooperation and integration of business processes between organizations via arrangements and protocols, typically under a formal or semi-formal deal.
4. Legal interoperability - ensures organizations can cooperate under “different legal frameworks, policies and strategies”. This includes a certain degree of coherence between legislations so that the assets managed under the semantic interoperability layer can be managed consistently.

The orchestration of the four layers (arguably, at least the first two) could lead to a seamless integration of DLTs, leading to value exchange.

There are four concerns are proposed on the Framework for Enterprise Interoperability (FEI) .

1. Business concern - regards barriers in organizations to cooperate despite differences in the decision-making process.
2. Process concern - regards how various artifacts that support the business (processes) work together.
3. Services concern - identify the applications and their interfaces that support processes.
4. Data concern - regard data management from different supports. Each concern is related to all interoperability layers, and each layer is related to one another

It is worth noting that other frameworks are equally valid, such as the Cloud Interoperability Standard ISO/IEC19941:2017, being currently studied by ISO’s WG7 (interoperability). In this framework, three layers exist: technical, business, and governance.

I will publish another article soon where we will discuss on the Interoperability Solution and why it needed?

Source - https://figshare.com/articles/preprint/Do_You_Need_a_Distributed_Ledger_Technology_Interoperability_Solution_/18786527

#anvitte #anvitteblockchain #blockchain #distributedledgertechnology #distributedledger #interoperability #learning #knowledgesharing