Do You Need a Distributed Ledger Technology Interoperability Solution?

DLT protocols can be instantiated in DLT networks (Table 1). DLT networks are groups of DLT nodes that make up a DLT system [71]. For instance, Hyperledger Fabric might be instantiated in a DLT network composed by an enterprise consortium. The Ethereum mainnet, Bitcoin mainnet, and Substrate-based networks, such as Polkadot, Kusama, and Rococo [105] are other examples. DLT networks are typically called Layer-1 DLTs.

Each DLT network can be partitioned into subnetworks. Nodes of a subnetwork contain a logically separated state compared to another subnetwork [71].

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.

In Hyperledger Fabric, a subnetwork corresponds to a channel. Channels isolate execution environments and data from other channels belonging to the same Fabric network. Polkadot’s Parachains could be considered subnetworks of the Polkadot network.

A DLT network can therefore have multiple subnetworks. If the DLT network state cannot be divided into multiple subnetworks, for the sake of simplicity of our evaluation, we say this DLT network has one subnetwork. Any node in a DLT subnetwork is also a node of the DLT network, implying that DLT network nodes and DLT subnetwork nodes must be running the same DLT protocol. In permissionless DLT networks, every compatible DLT node can join the network. In contrast, in 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 permissionless DLT, anyone can run a node that interacts with the network; if it is permissioned, only nodes with permissions can access the network. Within a network boundary, a DLT stores the ledger state (which could be organized as a key-value store, such as the world state in Fabric [5], via the account model such as in Ethereum [23] or via a UTXO model such as in Bitcoin [96]), and have an identity management mechanism. Identities are then mapped to permissions that encode what each node can do on the network (in terms of reads and writes). Each identity typically has two main keys (public and private keys), an address, and a low-level storage. Nodes can perform updates to the ledger via transactions.

Transactions are “the smallest unit of a work process related to interactions with distributed ledgers” [71], that, parametrized and signed by its creator, can be issued against a smart contract, via a DLT node. Generally speaking (as different DLT technologies have different transaction lifecycles), transactions are sent to other DLT nodes via a network propagation protocol, such as a Gossip [35].

DLT nodes in the same DLT network will “gossip” to each other various messages, such as transactions to update the distributed ledger. 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. Some DLTs may allow for selectable consensus mechanisms (usually selectable only upon the genesis of the DLT network), such as with Ethereum or DLTs created with the Substrate framework. In contrast, other DLTs like Bitcoin have a hardcoded consensus mechanism.

How transactions affecting the distributed ledger are ordered gives different DLT types. A blockchain requires transactions to be grouped together in blocks, each block to be cryptographically linked to one previous valid block (a block that includes transactions that have modified the distributed ledger), and each DLT node must process each block in sequential order. In contrast, a directed acyclic graph (DAG) does not group transactions into blocks. Instead, each transaction references other valid transactions (that have modified the distributed ledger), and each DLT node can process each transaction in different orders. Finally, a block DAG groups transactions into blocks, each block is cryptographically linked to other previous valid blocks, and each DLT node can process blocks in different orders.

As regards collections of DLT networks, we say we have heterogeneous DLT networks when the technologies and their respective networks are different; we say we have homogeneous DLT networks when only the networks are different.

Different DLT networks can connect to other DLT networks. An IM, often called a bridge, can connect networks to other networks, subnetworks, or centralized systems. Figure 2 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. Subnetworks are more concerned with a specific scope (specialization of the network), i.e., they can focus on scalability, achieved, for example, via a different state model; or features. This figure 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. On the other hand, we consider the Substrate framework as the DLT protocol (or, more concretely, the SDK to generate blockchains), instantiated as the Polkadot network. Polkadot can connect to its subnetworks via the relay chain. A relay is a smart contract in a target blockchain that functions as a light client of a source blockchain. Light clients are network nodes that are solely part of the blockchain history, i.e., relevant transactions (vs. full clients that store the whole blockchain history). They can verify that a transaction was included in the blockchain, typically using block headers (e.g., via Merkle proofs [43]), but not validate it. Relay smart contract receives block headers from relayers, nodes that fetch blocks from the source blockchain, and gives them to the target blockchain. Relays behave like oracles (except that they have to process it instead of receiving the processed information). Blocks given to the relay smart contract can be contested by other relayers by presenting a Merkle tree proof. The relay chain acts as a relay, realizing the bridge between parachains. Each parachain can connect to the relay chain via a module called Cumulus, and send messages to other parachains by using a message format XCMP [107].

Vertical interoperability (from networks to subnetworks and vice versa) and horizontal interoperability (between subnetworks and between networks of different systems) compose the spectrum of interoperability covered by this article.

Horizontal interoperability can be implemented in a multitude of ways. Layer-2 solutions are independent DLT networks connected to other networks via interoperability mechanisms. They aim at solving scalability problems with the DLT networks they interoperate with. Scalability is enhanced by allowing the network to offload transaction processing and enabling new features from the original DLT network. Those subnetworks are pegged to the networks via cryptographic mechanisms [12, 115].

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 view² [3, 9]. The new boundary needs to assume that each ledger is secure. Security depends on the threat model and network assumptions. Generally, security properties such as safety assume an honest majority of participants and arbitrary Byzantine behavior. Furthermore, given those assumptions, each ledger can provide liveness and persistence [48]. Liveness says that all transactions originated by honest parties will eventually be included in the blockchain; persistence states that once a transaction is included in the blockchain of an honest party, it will be included in all honest parties.

Different trust assumptions exist for each ledger, e.g., at least one honest node in Hyperledger Fabric, or the majority of the computational power, in the case of proof of work blockchains such as Bitcoin. Thus, when choosing an interoperability solution, the users who participate in the origin DLT must trust the involved DLTs and the IM. Ideally, both should be decentralized [115].

Several studies have presented blockchain as an infrastructure for data storage and computation [88, 136]. Blockchain can be viewed as a system component that eases trust assumptions between mutually untrusting participants. DLTs can be accessed by centralized systems—and thus need software components that provide the necessary infrastructure for connecting with it (key management, secure connection, state storage). Interoperability across DLTs implies the existence of another middleware layer (another system component) that can bridge nodes.

The first example is Hyperledger’s Cactus implementation of the Carbon Emission App from the Hyperledger Carbon Accounting and Neutrality Working Group [28]. A detailed explanation of this use case can be found in Hyperledger [27]. 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. Figure 3 depicts this network.

This example contemplates a private, permissioned ledger used for performance and privacy reasons, but where the final output (carbon emission tokens) are stored in public blockchains as a reward. In particular, 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. Privacy can be assured because only the peers involved can read the global state or if needed, only a subset of peers could read part of the global state (i.e., by utilizing channels or private data).

LACChain [79] is a Global Alliance for the Development of the Blockchain Ecosystem in Latin America and in the Caribbean, led by the Innovation Laboratory of the Inter-American Development Bank Group (IDB LAB) in cooperation with partners and strategic allies.

LACChain aims to provide infrastructure and technical tools, on top of the three layers the LACChain network comprises (DLT, self-sovereign identity, and tokenized money) that are useful for developing applications with social impact that contribute to the development of the countries of the region.

LACChain aims to provide a community and a general-purpose infrastructure for the realization of several use cases, such as supply chain, cross-border payments, and financial inclusion. This project currently utilizes two blockchain technologies, Ethereum and EOS [114].

Quant [113] and LACChain are piloting a project to provide private currency payments between retail customers from different financial institutions. This prototype involves retail customers creating transactions on a public permissioned Ethereum network. These payment amounts between the customers are tallied, even though the identities involved in the transactions are hidden via zero-knowledge proof technology. As all payments are recorded, currency exchanges between financial institutions can be netted and settled efficiently on a separate private permissioned Ethereum network. The blockchain interoperability solution infrastructure to allow this netting and settlement to occur is Quant’s Overledger, where the related interoperability applications are built on top of it utilizing Overledger’s cross-DLT standardized data model.

The “what” question concerns the artifact managed by the blockchain interoperability solution, i.e., the interoperation mode. The artifact exchanged can be data or assets. Data are arbitrary byte strings representing a piece of information on the blockchain (technical layer). It could be a key-value pair, metadata about the blockchain. Data can be copied from blockchain to blockchain.

Assets can be represented in the technical layer (by a string, for example). However, in the semantic layer, they “take form” by representing a fungible or non-fungible value which is or is not linked to a physical identity (in case it is, it is called a digital twin [110]). Therefore, they should not be copied among DLT networks but rather be transferred under specific conditions. More specifically, an asset transfer should abide by the rules of each DLT (e.g., no double spend), i.e., preserve at all moments the invariants of all the DLTs it affects. In DLTs, double spend can occur when an attacker sends tokens for a pending payment in a transaction to a victim in return for a product. The victim releases the product. Then, the attacker cancels the pending payment transaction, such that the original token transfer does not become recorded on the blockchain ledger (and thus their tokens are preserved). In the context of interoperability, double spend can happen in cross-chain asset transfers, when a lock/burn on the source DLT (the DLT in which the transaction is initiated to be executed on a recipient DLT [12, 58]) was not performed. The same representation of an asset could be valid in several DLTs, leading to a new type of double spend. Solving this problem implies synchronizing DLTs at the semantic layer, i.e., the involved blockchain interoperability solutions need to run the same protocol that prevents invariants from being violated, with on-chain notarization (e.g., via smart contracts).

The interoperation modes are as follows:

Figure 7 represents a data transfer from the source blockchain to the target blockchain. A blockchain interoperability solution requests data from the source blockchain and writes it on the target blockchain. Data can be copied. As blockchains increasingly comprise more value, represented by assets, value transfer among blockchains needs to be handled carefully, as it exposes a new class of attacks: cross-chain attacks. In cross-chain attacks, attackers attempt to double spend an asset by manipulating cross-chain protocols. Assets are then more sensitive to manage in terms of interoperability.

Figure 8(a) represents an asset transfer from the source blockchain to the target blockchain. A blockchain interoperability solution requests data from the source blockchain and writes it on the target blockchain as an asset (semantic layer protocols are required). Thus, the IM needs to make sure the representation of the asset on the target blockchain is changed to used (or burned). This implies the IM needs to check for conformance on both DLTs. Figure 8(b) represents an asset exchange (bidirectional asset transfer, or two asset transfers) between both blockchains. Again, the IM needs to check that both blockchains are in a consistent state. Note that these figures are high-level and hide details. More detailed procedures show the rules for asset transfers in the next section.

Cross-chain asset exchanges can also be classified into two types, permanent and temporary:

In asset transfers, it is the responsibility of the interoperability solution to establish a new boundary of trust for both previously established boundaries. Since one asset transfer will typically involve several transactions (from the source and target blockchains), it is desirable to do so via atomic cross-chain transactions. Atomicity is desirable because, in the case not all transactions are completed, the union of systems might be left in an inconsistent state (although several solutions exist, such as rollback [11]).

There are three methods for a dApp or mdApp to connect to a DLT. These mechanisms are called the connection modes. They are as follows:

DLT gateways are not DLT nodes. Instead, they are a collection of services built around DLT nodes, as Figure 9 shows. The services it provides (i.e., the protocols it runs) and identity management, access control, security, and liveness properties are left to be instantiated by the DLT gateway administrator. An example of a gateway is the ODAP Gateway [11, 60]. DLT proxies can also promote geographical diversification, alleviating some known blockchain cyberattacks (e.g., eclipse attack). However, it could be desirable to run non-native business logic from DLT nodes.

A DLT gateway provides additional non-DLT functionalities. Such additional functionality can include data analytics or complicated cross DLT network processes.

It could be desirable to use a DLT gateway instead of a DLT node or DLT node proxy if the gateway’s additional services are crucial to your application or to smooth your application build process. For instance, a DLT gateway could utilize a standardized data model, meaning that, unlike DLT node proxies, a DLT gateway can be used to connect to many DLT networks of multiple DLT types. On the other hand, a DLT node proxy could be more desirable if the application developer is experienced and very familiar with the underlying APIs and data models of the DLT nodes.

Both DLT gateways and DLT node proxies can promote geographical node diversification. Additionally, DLT gateways and DLT node proxies can promote technical node diversification (e.g., running multiple different DLT node implementations for a particular DLT, such as geth and nethermind Ethereum nodes). This minimizes the risk of application failure if there is a bug in a particular node implementation.

However, it could be desirable to connect an application directly to a DLT node, for permissioned DLT networks where the attack vector of DLT nodes is significantly less and therefore running a DLT node in a container orchestration system (e.g., Kubernetes) would suffice.

Categorization of DLT interoperability solutions attempt at answering How is interoperation achieved?, and what are the trust boundaries each solution creates. In the previous section, we presented the connection modes. In this section, we present a unified IM categorization that considers the connection mode, interoperation mode, and trust assumptions required by the solution category. Contrary to common knowledge, there are only two non-intersecting IM categories. All interoperability mechanisms are created from the following categories of solutions.

In particular, transferring data requires oracles, and transferring or exchanging assets can be done in two ways: (1) locking an asset in a source DLT, and creating its representation on a target blockchain, implying transactions on both DLTs—using oracles—or (2) via native transfer transactions (Alice transfers to Bob asset A in DLT X for asset B in DLT Y)—cross-authentication.

Code deployed into a distributed ledger cannot access external resources or data without the help of an intermediary. These intermediaries (known as oracles) gather external data, placing it into transactions that are subsequently added to the distributed ledger, therefore allowing this retrieved data to be read by deployed smart contracts. Note that oracles can fetch data from a non-DLT system or another DLT-system. Oracles are classified into two types [94]: pull-based or push-based.

The parties involved are the user and its smart contract (deployed on a DLT), the oracle and its smart contract, and external systems (decentralized, centralized).

Oracles inject information into a trusted network. This information can be used for decision-making by nodes, meaning oracles greatly influence the subsequent state of the network as a whole. It means that oracles are trusted third parties. The trust model of oracles might vary, from voting-based oracles to reputation-based oracles to a single trusted oracle [100]. The choice of an oracle then boils down to the choice of functionality offered, weighted with the acceptable level of decentralization of that oracle network.

Note that single DLT network oracles also exist (sometimes referred to as on-chain oracles, meaning located, performed, or run inside a blockchain system [71]). These oracles (when triggered by a transaction) collect data from different on-chain sources and present it in an easy to consume format [45]. But these oracles do not aim at providing cross-DLT network interoperability [45].

Oracles also support asset transfers across chains (sometimes known as bridges), typically unidirectionally, with mediated off-chain communication. These transfers are considered by commit-and-execute protocols [89, 138]. In this scheme, an asset residing in the source DLT network is burned (i.e., deleted) or locked, and a representation of that asset is minted (i.e., created) in the recipient DLT network. Both stages are implemented with smart contracts that implement specific rules for these operations.

Asset transfers via Oracles can occur using both push- and pull-based oracles.

Optionally, cross-ledger audit trail information can be included in these transactions. Note that it is technically possible for token owners to operate their bridge, but this generates a problem around the general acceptance (e.g., by exchanges) of the token minted on the recipient DLT network. Some protocols that perform asset transfers include services to monitor the process for their users.

Trustless Asset Exchanges correspond to one asset exchange with non-mediated communication. The de-facto method for implementing this scheme is Hash Lock Time Contracts (HTLCs), where both parties deploy a smart contract in each chain that transfers the right amount of coins to the other party.

HTLCs consist in facilitating an asset exchange between two parties (typical case, although multi-party HLTCs exist [12, 63]) on a different blockchain (both parties can access it). Party from DLT 1 (P1) creates a secret s such that the hash of the secret, h(s), is put in a smart contract on DLT 1, transferring an asset to P2. The contract is hash locked with s, and a timelock t. Thus, P2 can redeem the assets from DLT 1 with secret s until time t. Upon confirming that the contract is correctly instantiated, P2 can create a smart contract on DLT 2 with the same hashlock h(s) but a timelock t \(^{\prime }\) \(\lt\) t. The smart contract sends assets to P2 from DLT 2. This ensures that P1 can redeem assets before P2, with a slack t-t \(^{\prime }\) . When P1 asserts that the contract from P2 is published, that party can send secret s, redeeming its assets. P2 now holds secret s, and can use it to redeem its assets on DLT 1.

HTLCs imply handling the technical layer (the hashing functions that are used to construct the secret needs to be supported by the involved DLTs) and the semantic layer (the information exchanged has meaning—assets—and needs to preserve a set of rules on both chains—avoiding double spending, for instance).

On the other hand, centralized asset exchanges are cross-authentication solutions that allow asset exchanges. These exchanges (also called notary schemes [12]) are a legal escrow that exchanges assets from one DLT for assets from another DLT. Decentralized exchanges are typically facilitators of such transactions by offering a bookkeeping system that matches buyers and sellers. Although decentralized exchanges running in heterogeneous DLTs are appearing [95], the mechanisms used for interoperation are classified as oracles. An overview of how centralized and decentralized exchanges work is present here [12].

New types of HTLCs are showing up. In Hyperledger Cactus [92], the cactus-plugin-htlc-eth-besu-erc20 allows one to automatically deploy HTLCs on Ethereum via Hyperledger Besu. A similar package could automatically deploy two contracts: one in a permissioned DLT, and another in a permissionless DLT. As long as the parties exchanging assets are present in both networks, this scheme would work.

Contrary to common knowledge, there are only two non-intersecting categories. We emphasize that this is a general overview. In-depth descriptions of the protocols and their implementations can be found in [12] (both), [25, 41, 94] (oracles), and [137] (cross-authorization). Table 2 summarizes the studied categories.

Oracles can perform data and asset transfers, typically using DLT gateways. This is due to the ability of gateways to process data to the format the oracle smart contracts accept. Oracles can enable general-purpose interoperability, thus they have implementation overhead, as well as decentralization overhead. On the other hand, cross-authentication solutions are used for asset exchanges only—a DLT node or DLT proxy suffice.

The immense variability of IM solutions stems from the fact that many design patterns are built on top of those two categories. A detailed study on the available design patterns for IM is left for future work.

The potentiality assessment evaluates technical interoperability (see Section 3). It takes a system based on a DLT protocol and evaluates its maturity toward interacting with other systems (requesting/providing data). Four levels of interoperability exist (cf. Figure 11), in increasing order of complexity:

We could also consider Level P5, providing interoperation with non-DLT systems (e.g., enterprise systems, payment systems). However, all IM solutions and DLT nodes provide capabilities for accessing the ledger. In the compatibility assessment, we consider interactions (e.g., digital asset exchanges across DLTs) to have legal binding.

For instance, Hyperledger Fabric–based networks can provide and receive information from and to the exterior, respectively, via smart contracts. Figure 12 depicts a practical example of a potentiality assessment. A high score for this assessment shows that the system can interoperate with systems significantly different from it as is. One could consider an IM as the cross-chain logic plus a connection mode (in this case a DLT gateway). The IM can then connect to multiple DLT networks, depending on how many of the latter the DLT gateway supports. Thus, business logic from the IM can spawn across several DLT networks. If this is the case, cross-chain logic can be implemented. Another interesting possibility can be implemented: connecting the IMs via the DLT gateways, allowing for second-order interoperability. Provided accountability guarantees, such as smart contracts as trust anchors, or a decentralized log storage for IMs, this enables cross-chain use cases operated by mutually untrusted IMs

The compatibility assessment evaluates compatibility aspects regarding semantic, organizational, and legal interoperability. Given a pair of systems, do they run protocols that both understand? Do they share similar organizational goals? Do they follow the same jurisdiction and regulations?

Figure 13 depicts this assessment. Three levels of compatibility maturity exist:

The score for this assessment is obtained by summing the weights of each level cumulatively, since the last layer typically depends on the previous (1, 2, and 3, respectively). In this article, we focus on the semantic aspect, leaving pointers for future work on the organizational and legal aspects. The granularity regarding the three layers can be defined by the users of the framework.

Figure 14 depicts an architecture of an interoperability solution (e.g., it could be connected by a network of gateways) that has a compatibility assessment conducted. A network of gateways is a set of gateways that run cross-chain logic shared by gateways, following a protocol.

The performance assessment studies how efficiently an IM executes its processes. The efficiency can be measured in metrics related to the Cross-chain transaction (CC-Tx) concept. A Cross-chain transaction (CC-Tx) is composed of transactions directed to the target systems (called subtransactions of a CC-Tx) plus the internal transactions of the IM. We call the logic that an IM executes cross-chain logic or cross-chain rules. The cross-chain logic accounts for business logic plugins’ execution, which can modify the final transactions issued against DLTs.

Following the blockchain integration framework, there are three main metrics to assess the performance of an IM [90]:

At the moment, it is not possible to establish specific guidelines for this type of assessment due to the lack of systematic evaluations of interoperability solutions. Although several solutions bring performance evaluations [12], they are not standardized according to any framework, making it difficult, if not impossible, to compare solutions systematically. Thus, we leave the judgment of a reasonable latency, throughput, and cost for interoperability solutions and a rigorous model to evaluate the performance for future work. We emphasize the challenges to measuring the energetic consumption of an IM, given that it interacts will multiple decentralized systems. Although some work has been done in evaluating the energetic consumption of Bitcoin [53, 55], the literature falls short in exploring other DLTs. Thus, this remains a problematic metric to assess.

The reader should start navigating from left to right, starting on the node with the START label. After that, a path should be followed by answering yes (yes) or (✗) to the proposed questions until an end node is reached (blue nodes), or a proceed flag is present in one of the arrows connected to the current node. More details on the proceed flag are available on the functionality decision model. The blue nodes output recommendations regarding the infrastructure or functionality of an IM.

Choosing an infrastructure refers to choosing the hosting infrastructure for an IM: DLT node, DLT proxy, or DLT gateway. Hosting an IM implies several challenges that require specialized, well-trained experts: (1) node and hardware management, including installation, maintenance, load balancing, software version management, redundancy, and scaling; (2) security, including monitoring the node and responding to cyber-attacks; (3) and others, such as adhering to regulations (e.g., GDPR). Thus, different needs require a different infrastructure. Depending on the use case, it is acceptable to defer the management of the infrastructure to third parties (versus self-hosting the infrastructure).

The following decision model, in Figure 15, guides on choosing the infrastructure (i.e., connection mode) for an IM and if it should be self-hosted or not.

DLT nodes are native blockchain clients, e.g., Geth Ethereum Node [42], Hyperledger Besu node (Ethereum node) [5], Hyperledger Fabric peer node [5], Bitcoin Core [14], and Polkadot node [108]. DLT proxies include Infura [67], Blockdaemon [15], and nodes hosted and accessible via cloud providers. DLT gateways include Quant Overledger [113], Hyperledger Cactus nodes [92], Weaver gateways [127], among others. More examples of each connection mode can be found in [12].

Choosing the functionality refers to choosing the IM functionality in terms of interoperation mode, P levels, and C levels.

Most IMs assure P \(\le 3\) , while a few provide all P levels (P1, P2, P3, and P4) [12]. On the other hand, IMs can be divided on C1, because most do provide \(C \lt 2\) . Most IMs can provide C1 (in fact, a system providing P4 implies that it provides C1), while a few attempt at implementing standards that could, in the future, support the legal layer. At the moment, we do not know of any IM providing level C3.

The following decision model, in Figure 16, guides on choosing the functionality. This decision model uses the proceed flag, meaning that when it is present in an arrow connected to the current node, the user should evaluate the condition, and then proceed (instead of stopping), accumulating the recommendations, until a node without a proceed node is found (and therefore the last decision is made on that node). Take, for example, the following flow: one starts in node 3a. As the proceed flag is present on that node, the reader will answer to the question and then (independently of the answer) move to the next node. In case the answer was yes (yes), the recommendation is saved. At the end of Figure 16, a maximum of five recommendations may be collected.

In this section, we define each solution group depicted in Figure 16. In particular, we systematically compare IMs according to their P level, C level, and interoperation mode. Table 4 shows examples of solutions belonging to each group proposed by Figure 16.

The first group comprises solutions providing levels P1–P3, and supporting data transfers, asset transfers, or asset exchanges. Most blockchains provide P1 interoperability by enabling functionality re-usage. For instance, smart contracts can call other smart contracts (even across subnetworks, providing level P2) in most blockchains. Level P2 requires some orchestration. For example, interoperability across subnetworks in Ethereum can be done via oracles or gateways running bespoke cross-chain logic. A similar level of orchestration happens when P3 is needed but could be more complex, as different networks may differ more than different subnetworks. Level P3 and P4 systems imply the usage of blockchain interoperability middleware (in some DLT protocols, level P3 can be achieved without specialized middleware) that can be centralized or decentralized.

Many of the examples present in group G2 supporting data transfers are classified as trusted relays or blockchain agnostic protocols, while G2 solutions supporting asset transfers and exchanges belong to sidechains and relays. Blockchain of blockchain platforms (Polkadot, Cosmos) provides level P3. The design and implementation of bridges to external DLTs would carry these systems to level P4, but they are still in development, and, furthermore, these bridges are not native to the DLT networks.

In this section, we present an example of the choice of the infrastructure and functionality of an oracle solution based on a simple use case. Let us consider an IM administrator who transfers data between the Ethereum blockchain and a Polkadot’s parachain.

Infrastructure: the administrator does not want to host the infrastructure and would like to have high availability. There is no preference to whether the IM can access the DLT nodes directly or not. The administrator accepts the risk of its data being read by third parties, for the comfort of an easier to deploy solution. Using the decision model from Figure 15, the administrator would answer:

Functionality: the IM would only need to transfer data. It needs to connect different DLT protocols and does not need to comply with any regulations. Using the decision model from Figure 16, the administrator would answer:

Therefore, the chosen IM is a P4 + C1 third-party hosted DLT gateway (see Table 4 to choose a solution).

In this section, we present an example of the choice of the infrastructure and functionality of a cross-authentication solution based on a simple use case. Let us consider an end-user who wants to perform an asset exchange. The user wants to exchange asset a in DLT a for asset b in DLT b.

Infrastructure: the user is looking to connect to two different DLTs, does not need to run cross-chain logic (as the only logic needed is a time-locked transfer), with no high availability requirements. The user wants to have direct access and control over the node. Using the decision model from Figure 15, the administrator would answer:

Functionality: the IM needs to exchange assets (or perform two independent asset transfers). It needs to connect different DLT protocols and does not need to comply with any regulation, but it must comply with rules on exchanging assets (e.g., hashlock time contract). Using the decision model from Figure 16, the administrator would answer:

Therefore, the chosen IM is a P4 + C1 self-hosted DLT proxy supporting asset exchanges.