Remain Sovereign with Blockchain Interoperability

The World Economic Forum is an International Organization for public-private corporations. Its mission states, “The Forum strives in all its efforts to demonstrate entrepreneurship in the global public interest while upholding the highest standards of governance. Moral and intellectual integrity is at the heart of everything it does.” They believe that by bringing people together who have the drive and influence to make a positive change, they can assist organizations in being accountable to all parts of society.

The World Economic Forum recently released a white paper entitled Inclusive Deployment of Blockchain for Supply Chain, With A Framework for Blockchain Interoperability. The report was part six of a larger look into what tools are required to support “interoperability, integrity, and inclusivity” in distributed ledger technology for the supply chain.

Up to now, interoperability between systems has been relatively simple. However, with the increase in blockchain usage, interoperability has become more complex. A successful interop system will benefit all parties by supporting intellectual processes and sovereignty while delivering greater benefits for the consumer such as transparency, security, and privacy.

The World Economic Forum report sets forth a framework for analyzing requirements to achieve interoperability. They cite a few examples of projects that are working towards interoperability. However, none of the projects cited have addressed all the problems that face an enterprise when implementing blockchain interoperability. Because of the limited scope of the interoperability systems, the WEF concludes interoperability is immature. And while there is some agreement with that statement, the WEF was remiss when they neglected to recognize that there is one company that has achieved every one of their metrics.

Proudly, a US-based company, Dragonchain created the only operational platform that focuses on decentralization, privacy, and security. Interoperability has been a core focus of the hybrid public/private enterprise blockchain company since 2016 when they were the first to successfully interop a private blockchain to a public chain. They were awarded a patent for their interoperability system, Interchain™ in 2018 which was recently expanded in 2020.

This post examines the metrics the WEF believes are crucial to an interoperability system and compares those to the architecture of Dragonchain’s Interchain interoperability solution. Dragonchain built an all-inclusive platform. Featured on the platforms Interchain™, a cohesive product that can be applied to a variety of enterprise interoperability goals. Let’s break it down.

Types of Interoperability

Merriam-Webster defines interoperability as the ability of a system to work with or use the parts or equipment of another system. The World Economic Forum outlines two types of interoperability.

Digital Asset Exchange

Digital asset exchange is the transfer and exchange of assets from different blockchains without having a trusted middleman. An example of this would be what is termed “atomic swap”.

Arbitrary Data Exchange

Arbitrary data is the capacity to do something on one blockchain that affects something on another blockchain. Citing the inability for most blockchains to produce a verifiable-by-others signature WEF reports this type of interoperability is the most difficult to implement.

Dragonchain takes a four-dimensional approach to interoperability with its Interchain™ solution.

Token Transfer

Dragonchain sees token transfers as the most popular in terms of the development taking place within projects today. FinTech and asset work are benefitting from atomic swaps. Interesting from a technology standpoint, blockchain companies focusing solely on this myopic approach to interoperability are unlikely to drive adoption. In operation since 2018, Dragonchain’s own console uses token swaps between Dragons and Ethereum.

Security Interchain™

As the first hybrid private/public blockchain, Dragonchain’s architecture starts at the private business logic level, allowing the business to decide what data to expose. This approach to interoperability is important because it harnesses the security of public blockchain ledgers with privacy crucial to business data and paves a way for a hybrid blockchain that is scalable.

Dragonchain’s security protocols involve low-cost multi-algorithms. By using the combined hash power of multiple chains This is useful because if any of them has a 51% attack or any other issue, transactions on Dragonchain are still secure and backed by all of those chains.

All transactions go through five levels of validation within Dragon Net, including the business Level 1 node. Each node within Dragon Net is its own blockchain interchaining with the next level. For instance, for each transaction, Level 1 business nodes interchain with the Level 2 nodes. All three Level 2 nodes interchain with the Level 3 node. The Level 3 node then interchains with the Level 4 node. And finally, the Level 4 node interchains with the Level 5 security node to the public blockchain.

Utility Interchain™

For businesses, a major concern is flexibility. When writing to Dragonchain you can leverage Ethereum when it’s needed and when a new chain comes along a business can use Interchain™ to capitalize on the new utility. This flexibility lowers the risk to businesses using blockchain and reduces strain on any chain, keeping speeds high and cost low. When using Utility Interchain™, businesses can integrate with a utility chain at a significantly lower risk than if they built their systems right into that chain. They can write their entire system in glue code in smart contracts and they can control their data and be very specific about which parts they put onto another system. With Dragonchain, businesses have the option to leverage both the specialized features of utility chains and the all-purpose capabilities of public blockchains, giving them the best of both worlds.

Traditional Legacy Systems Interop

Dragonchain’s architecture is paramount for integrating legacy systems into the world of blockchain. To provide the benefits of the utility chain or the security of a public chain, the business spins up its own blockchain. Dragonchain configures the business blockchain to work with the business’ legacy system. Transactions will then go through validation using Dragon Net, Dragonchain’s consensus platform. Besides connecting a legacy system to a blockchain, Dragonchain connects legacy systems such as an accounting system to an employee system using blockchain. This standardizes some processing and logging or persistence of state so that if something goes wrong, no matter what the other systems are logging you can see what the state was between them.

An additional crucial component is an ability for developers to immediately, using their own favorite language such as Java, Python, Go, Dart, C#, and even shell script, create a system of smart contracts within a Docker container to deploy to the business’s private blockchain.

Dragonchain showed its Interchain™ capabilities on January 7, 2020, with a live performance test. On an in-production network, they averaged 2800 transactions per second with a peak of 15,000. Twenty-four hours later the final tally was 252,537,715 total transactions.

Layers of Interoperability

The interoperability decision requires a thoughtful approach. When deciding to interop with another system the solution should be economical and frictionless. Minimal disruption to existing infrastructures and system cohesion is of the utmost importance. Enterprise requires scalable solutions that will grow and remain flexible in an ever-evolving environment. The World Economic Forum’s interoperability model framework comprises three layers to achieve cohesion between systems. Dragonchain’s architecture is agnostic to differences in business models, platforms, and infrastructures. But let’s look at the three the WEF has outlined.

Business Model Layer

Governance

Governance is a structure that every user or participant agrees to follow. It’s a way that a group of people does things. With blockchain governance the thought is we should account for how systems will adapt and adjust over time in a decentralized environment, to stay relevant.

The WEF contends that technical connectivity alone can not supersede incompatible governance models. To ensure trustworthiness, governance must be comparable with a clear legal framework and commercial arrangements.

"To help ensure the trustworthiness of the participants, a prudent governance model has to be designed and agreed between the different blockchain ecosystems. For instance, if a bank in a know-your-customer (KYC) network opened an account for a blacklisted manufacturer, the second bank would then finance the blacklisted manufacturer by trusting the first bank. To potentially avoid these kinds of situations, a very stringent onboarding process for the blockchain platform will have to be in place so that only qualified financial institutes can contribute KYC information to the platform because they are essentially conducting KYC on behalf of the whole ecosystem." - World Economic Forum

When it’s understood that with Dragonchain all business logic remains at the business level, on an individual private blockchain, governance becomes a construct left for networks trying to conform to a set of standards. Dragonchain considers the necessity for a consortium for governance as a symptom of an architectural flaw. It increases risks, costs, and time to market and therefore lessens adoption. A company would need to convince competitors to standardize data structures, communications, and processes, which is antithetical to competition.

Dragonchain’s architecture and model allow the business to go it alone and use its proprietary technology to better compete. This has many other benefits, including privacy and scalability. It also applies to Ethereum and other public blockchains as well which require all nodes to know about all smart contract logic and data to do their job.

“We don't consider it to be altogether too special of a topic. Our consensus model is general and considers the network rules/protocol and NOT the business logic or data. All verifications in "Context-Based Verification" consider only the transaction and block metadata - the network data - without visibility into the transaction payload, the sensitive business data, and logic.” - Joe Roets

If an individual enterprise seeks a specified governance system or algorithm or even proof-of-compliance for authorities, it can be modeled on Dragonchain.

So, how would Dragonchain handle World Economic Forum’s KYC example above? Sovereignty. Dragonchain would make it possible for each bank in the KYC network to implement an individual sovereign blockchain per bank. The banks in the network will interop via Interchain™ exposing only the data that each bank needs to grant an account. Dragon Factor, Dragonchain’s digital identity solution, can provide the digital ID containing specific factors that attribute to securing an account.

It’s unclear why one bank would open an account for a manufacturer because a different bank opened an account for that manufacturer. It seems to be a question of due diligence, not governance. If there is only one blockchain for all banks to use, then that makes sense. But that means there is only one blockchain for an entire network of lenders, each with their own sovereignty. What if bank A sees potential in said blacklisted manufacturer because of some change in their situation? Is bank A not able to have sovereignty over its decision to grant an account to the manufacturer?

Data Standardization

Data standardization is the process of bringing data into a common format so that all systems are understandable and accepted by all parties. The World Economic Forum lists twelve (there are more) organizations providing standards to drive interoperability, including the Blockchain Industrial Alliance, GS1, and the International Organization for Standardization. The WEF stresses that all data must follow a form of data standardization for a successful interop.

"In many blockchain platforms, the value lies in the exchange of validated data among participants in the ecosystem. As a result, the trustworthiness of the records in a blockchain platform depends on the trustworthiness of the participants. For participants to share information, all data must follow a form of data standardization to ensure it can be understood by all parties. Consequently, every blockchain ecosystem necessarily standardizes the data representation of its entities (contracts, parties, etc.). When we want to make blockchain platforms interoperable, different standards may collide with missing attributes, for example." - World Economic Forum

Dragonchain remains judicious of the various entities providing standardization across the blockchain spectrum, however, they will not limit themselves by using one standard. Most organizations tend to be manned by people from big businesses who push one standard that makes it more difficult for competitors to compete and innovate. With Dragonchain, differences in standards are sovereign to the individual business, remain at the business level, and do not interfere with interoperability.

Legal Framework

The World Economic Forum points out that decentralization makes it difficult to determine who has legal responsibility and jurisdiction over data. Networks must reconcile liability and integrity. They also emphasize that matters are further complicated by the append-only nature of blockchains and data cannot be changed after the fact.

"It can be difficult to ascertain who “owns” the network and its data due to the decentralized characteristics of blockchain platforms, which makes it hard to place who is legally responsible for it. In a decentralized environment, it may be challenging to know who has processed what data, where, and when, and thus to ascertain who is “responsible” for it, what jurisdiction applies in disputes or who controls the information and is liable for its security or responsible for its integrity. Moreover, blockchain ledgers are generally append-only and cannot be changed after the fact, which can raise issues in a number of regulatory spheres, such as data privacy or consumer protection." - World Economic Forum

Dragonchain maintains that any transaction on-chain should be radically more valuable than a one not on-chain as it simplifies the question of legal jurisdiction. The interaction with and location of data attached to a transaction on-chain is verifiable. The architecture considers both sides of the legality issue and takes into account the human trust side of the question and the measurable proof. It’s a math-based approach to legality.

To provide a legal component, i.e. accountability, to transaction verifications, Dragonchain wove a Level 4 Notary node into the architecture. Transaction verification must first go to three diverse Level 2 nodes. The Level 3 node then checks network diversity to confirm that three separate Level 2 nodes verified that transaction.

After the Level 3 node has verified the transaction, a Level 4 Notary node will verify the transaction. The Level 4 Notary node examines the hash and signs the hash with keys owned by the KYC approved entity. The KYC approved entity is an identified source with a set of rules and upon signing the hash is named in the proof report. This makes it possible to know who has processed what data, where and when. The Dragonchain architecture ends at the Level 5 security node, which is a decentralized and anonymous measurable proof.

“The entire verification platform is interesting, but the added Level 4 Notary is invaluable from a legal perspective. With the platform, we can already show any identified entity a piece of information has been verified by a diverse set of prior verification nodes, but with the Level 4 Notary node we also confirm when and where a user did something in a transaction and that a notary signed the hash, all without access to the actual private information.” - Joe Roets

This also addresses the append-only nature of blockchains. The proof of the transaction is eternal on public blockchains, but the data remains at the business level. That business must follow regulatory guidelines such as GDPR at that level. The transaction payload contains no private data and isn’t at risk.

Individual businesses can easily follow regulatory guidelines, such as GDPR or HIPAA since the private data remains at the business level and not in the transaction payload. In the event edits are required, a solution to the append-only nature of blockchain can be addressed through administrative actions with additional transactions pointing to changes in the information.

Commercial Arbitrage

According to the World Economic Forum, there are opportunities for arbitrage for different commercial models between blockchain ecosystems and may not necessarily be bad, but it may not be welcomed.

"The commercial model will be critical for success. If a bank initially takes two hours to conduct KYC and, based on that record, a second bank can then open an account for the same customer in a few minutes, the second would have to pay the first bank back, otherwise, the first bank would never contribute the KYC record. However, commercial models will inevitably be different in different blockchain ecosystems. Making blockchains interoperable could introduce arbitrage opportunities, for example. This may not be bad, but some participants might not like it." -World Economic Forum

Commercial arbitrage wouldn’t directly affect interoperability with Dragonchain, although Dragon Factor solves the above situation outlined by the WEF. When a customer goes from bank A to bank B, the customer would simply release specified KYC factors for approval. The identity of the customer remains with the customer and need not be additionally verified for every interaction. In the case of repeated identity verification, the identity is stronger, and Dragon Factor could be used to incent efficiency improvements.

Platform Layer

Consensus Mechanism

According to the World Economic Forum, differing consensus mechanisms are not interoperable. If two platforms use the same consensus mechanism, the WEF contends it can remain difficult to agree on the order of transactions.

"Different consensus mechanisms that are inherently different (e.g. proof-of-work (PoW), proof-of-stake (PoS), and Raft) are not interoperable by default. Blockchain platforms that use the same consensus mechanism can be interoperable. However, even if two platforms use the same consensus mechanism, it can be difficult to synchronize data across platforms with consensus about the order of those data transactions. For example, Hyperledger Fabric and Corda may both use Raft as the consensus mechanism, but they use different models for how data is stored, how it persists, and who participates in the consensus." -World Economic Forum

With Interchain™, different consensus mechanisms do not interfere with interoperability. Dragonchain built Interchain™ for different blockchain consensus mechanisms and legacy systems. The Dragonchain architecture comprises multiple blockchains that interop with each other. At the business level, a blockchain interops with the business’s legacy system. Then each verification node is an individual blockchain that interops with other blockchains via a RESTful API. The Dragonchain Level 5 security node interacts and listens or publishes transactions to proof-of-work blockchains, such as Bitcoin, Ethereum, and Ethereum Classic AND proof-of-stake blockchains, such as Binance. A business could also use their Level 1 node to directly publish or listen via an API to Bitcoin, Ethereum, or any other chain.

Smart Contracts

The World Economic Forum explains that different blockchain platforms using different programming languages and integrations across various platforms are not workable.

"Different blockchain platforms may use different languages for smart contracts, from Turing incomplete Bitcoin script to Turing complete Java code with legal proses. As a result, sharing codified logics for automated contract executions is usually infeasible across heterogeneous blockchain platforms." -World Economic Forum

Smart contracts are a fundamental component of Dragonchain’s interoperability system because they provide flexibility. The enterprise’s existing developers can immediately, use their own preferred language (e.g. Java, Python, Go, Dart, C#, or even shell script) to create a system of smart contracts. Those smart contracts are placed within a Docker container and deployed to the business’s private blockchain. This is an economical solution in two ways. First, the enterprise can integrate its existing non-blockchain systems, eliminating the need to train supporting staff to new programs. Second, the enterprise does not have to spend resources on training or hiring specialized developers and instead can use existing staff that already know the systems, the data, the processes, and the customers.

Authentication and Authorization

Blockchains support multi-signature transactions, however, these may be designed differently across blockchain platforms. The World Economic Forum contends differences in multi-signature design are not interoperable and must rely on a cross-authentication mechanism.

"Blockchains can support multi-signature transactions, allowing multiple participants to digitally sign on the same transaction. Yet this is designed differently across blockchain platforms. For instance, Hyperledger generally allows signing at the user level while Corda does so at the node level. The authentication and authorization are hence not interoperable across some blockchains despite their similar consensus mechanisms. Consequently, interoperability methods must rely on cross-authentication mechanisms. These mechanisms could range from simple storage of encrypted passwords to overlaying user authentication on top of the blockchain platforms." -World Economic Forum

When discussing multi-signatures, Dragonchain’s architecture allows for variations in different blockchains and legacy systems. Authentication and authorization protocols are sovereign to the enterprise system itself. Dragonchain incorporates multi-signature capability in every step of the verification process, with each active node signing the transaction. This provides the flexibility needed for Corda to allow its signing at the node level and for Hyperledger to allow its signing at the user level.

Infrastructure Layer

The World Economic Forum believes compatible infrastructures are necessary, but proprietary components complicate interoperability.

Hybrid Cloud

According to the World Economic Forum, the lack of performance within a cloud infrastructure makes it unappealing to the enterprise. Also, the lack of a governance model creates vulnerabilities, which are why most enterprises opt-out of hybrid clouds for their blockchain infrastructures.

"Theoretically, an ecosystem can deploy a blockchain platform on hybrid infrastructures, because blockchain is a distributed system. For public blockchains, machines – from home computers to large server farms with hypercomputing power (HPC) – can become a data node and participate in a blockchain ecosystem. However, these networks are usually not sufficiently high performing for enterprise-grade solutions, and their lack of governance models creates vulnerabilities, which can be exploited for, for example, money laundering and breach of currency controls, etc. These challenges are exacerbated when attempting to make two solutions interoperable. Therefore, most enterprises opt-out of hybrid clouds for their blockchain infrastructures." -World Economic Forum

As mentioned earlier, governance is not an issue for Dragonchain as all business logic remains with each independent business. Dragonchain considers using the cloud an advantage as it assists in Dragonchain’s ability to scale. With cloud infrastructure, Dragonchain can deploy infinite blockchain nodes with zero to little physical infrastructure requirements. This makes the platform flexible and efficient.

Managed Blockchain (BaaS)

As pointed out by the World Economic Forum, obstacles for a BaaS center on rules providers apply to solutions that limit interoperability. Even though providers claim to be open-sourced, typically there is a piece that is proprietary based.

"For managed blockchain as a service (BaaS) solutions, the challenge lies in the hidden control cloud providers have over the solution, limiting the options for interoperability. While most cloud providers claim that the blockchain services they are offering are open-sourced, there are always some components in the services that are proprietary based. This implies a certain dependency on the vendor for part of the blockchain architecture. It could be an order hosted centrally by the cloud provider, a membership onboarding tool, a special access management method, or innovative security-management design." -World Economic Forum

Dragonchain is a Blockchain as a Service that uses cloud infrastructure to scale and deploy smart contracts. When designing the connection between cloud infrastructure Dragon Net takes the specific cloud architecture into account. Any cloud provider, such as AWS, Azure, or Google can be used in the same manner. Clashes between individual enterprise and any cloud infrastructure would not be of concern as the connection from the enterprise to the cloud runs through Dragon Net.

Proprietary Components in Private Blockchains

According to the World Economic Forum, private blockchain interoperability requires compatible characteristics of infrastructures.

"Private blockchains are always permissioned and differ greatly from public blockchains – especially in terms of infrastructure requirements. They are not demanding on computing power and electricity consumption and can achieve high performance in transaction processing. As a result, they can be deployed in traditional data centers or, more often, on virtual private clouds. Blockchain data nodes deployed in different geographical locations on different network segments can effectively exchange data through the internet, especially because network latency or intermittent disruptions will not affect eventual data consistency. The interoperability challenge for private blockchains lies in finding private blockchains that have sufficiently similar characteristics." -World Economic Forum

The Dragonchain architecture calls for one or more private business nodes per Enterprise, each with its own private blockchain. If two businesses wish to interop, they would each simply spin up their own business node and code the necessary integration for the needed interoperability. Because each Level 1 node is compatible with Dragon Net, there are no issues with proprietary components.

Three Approaches to Blockchain Interoperability

The World Economic Forum stipulates there are three ways to address blockchain interoperability. The method used by an organization depends on the systems being connected. Dragonchain uses a form of each approach, although not in the same way as defined by the WEF.

Cross- Authentication

The World Economic Forum outlines three technical methods to achieve cross-authentication.

Notary Schemes

Notary schemes refer to when trusted parties come to an agreement through consensus and issue a signature to complete a transaction. According to the World Economic Forum, notary schemes are a straightforward way to achieve cross-chain interoperability. Unfortunately, they centralize trust.

"Executed by trusted parties (notaries) that help participants on blockchain A confirm that some event occurred on blockchain B and vice versa. The notaries will come to an agreement through some form of consensus algorithm and will then issue a signature that can be used to finalize a transaction on chain A, conditional on this consensus. Notary schemes are one of the simplest ways to achieve the full suite of cross-chain interoperability. However, they centralize trust, which goes against the main paradigm of blockchain, namely decentralization. This consequence might be acceptable in situations where blockchain consortia members can agree on a central party to operate the notary scheme. Ultimately, if the use case relies solely on the immutability of the distributed ledger and does not need to replace institutional trust in a central party with a systemic trust through decentralization, a notary scheme should be considered as a viable option. Multiple enterprise use cases on permissioned networks would fall into this category." -World Economic Forum

When data is standardized, shared, and verified by all parties, notary schemes as described by the WEF can be an issue. With ‘“Context-Based Verification" Dragonchain considers the transaction and not private data. Accountability is an important part of the architecture so Dragonchain built a notary component into Dragon Net at the Level 4 Notary node with signed hashes at each step of the process.

Here is the process:

  • The hash from the Level 1 private blockchain travels to the Level 2 node.
  • The Level 2 node then forms a new block with the hash of the prior Level 2 and the hash of the validated Level 1.
  • That block travels to the Level 3 node.
  • A new block is formed at the Level 3 node that contains
  • the hash of the prior Level 3 record created by the Level 3 node for the same origin (Level 1) and creating a Level 3 blockchain.
  • The hash of the Level 2 validation record (which holds the hash of the Level 1 validation) that approved the criteria thus providing a second dimension to the blockchain.
  • The transaction then travels to Level 4 and is verified.
  • After the Level 4 verifies the transaction, it travels to the Level 5 security node to the public chain with all those hashes present and on the immutable record.

The decentralized Level 4 Notary node has gone through KYC. The proof report contains the signed transaction and the signee. With the Level 4 Notary, it is possible to provide accountability to the transaction and verify an event happened, or an entity processed the data, and when that data was processed. The notary node in this case though is only signing provable evidence of the transaction and its data, without suffering exposure of the data to any third party.

Relays

Relays are chain to chain communication that verify an event on one chain has taken place on another chain with no trusted party. The trusted party is the relay. The problem arises when blockchain characteristics differ as blockchains must be compatible.

"Systems inside one blockchain platform that can validate and read events and/or states in other blockchain platforms. More specifically, a relay is a contract on blockchain platform A that functions as a light client of blockchain platform B, using blockchain platform B’s standard verification procedure to verify block headers fed into the contract. This gives blockchain platform A the capacity to understand event changes on blockchain platform B, without using a trusted party. As the relay would allow a secure message to pass between the two blockchain platforms in question, it can allow each blockchain platform to execute transactions on its own state machine using the synthetic versions of assets from the other blockchain platform. The downside is that it is very difficult to connect blockchain platforms that don’t have the desired or similar characteristics. For relays to work best, the blockchain platforms should share certain characteristics, including flexible multisignature capability and fast consensus finality." -World Economic Forum

Dragonchain doesn’t use relays per se but uses what they call Watchers and Publishers. Any event on any chain can trigger activity on Dragonchain. Dragonchain can then turn around and publish or post a transaction to any other chain (or system). Neither Watchers or Publishers require similarity of multi-signature capability as described with relays.

Hash-locking

The World Economic Forum explains hash-locking as operations between blockchains that have the same trigger, usually the revelation of the preimage of a particular hash. This is the most practical method, however, it’s the most limiting in that it only supports digital asset exchange.

"Setting up operations on blockchain platform A and blockchain platform A that have the same trigger, usually the revelation of the preimage of a particular hash. This is the most practical technical method to interoperability in cross-authentication but is also the most limiting in terms of functionality, supporting only digital asset exchange. Two general types of hash-locking exist: on-chain hashed time-lock contracts (HTLC) and off-chain hashed time-lock agreements (HTLA). An HTLC is on-chain and is a class of blockchain-based payment that uses hash locks and time locks to require the receiver of a payment to either acknowledge receipt prior to a deadline or forfeit the ability to claim the payment, returning it to the payer. HTLCs allow for cross-chain atomic swaps and fully funded bidirectional payment channels between assets on certain types of blockchain platforms. An alternative solution is HTLA over a peer-to-peer network that is used for cryptocurrency payments across different blockchain platforms. Unlike HTLCs, this solution is not built as a smart contract on the blockchain platform but an off-chain solution. Hence, it does not provide the same inbuilt decentralized characteristic as HTLC." -World Economic Forum

In general, when talking about releasing a transaction from one entity to another, Dragonchain uses Watchers and Publishers to release and push specified data and transactions. An HTLC is best suited for token transfers which are not the primary focus of Dragonchain. However, a Dragonchain interop with any blockchain-based or traditional based payment network will provide an increased ability to scale and additional security.

According to the WEF, the three methods of cross-authentication come with the following pros and cons:

Pros: Excluding notary schemes, this approach does not need a central trusted party.

Cons: Only relays and notary schemes support the arbitrary data exchange type of interoperability.

As interoperability with Dragonchain is agnostic to differences in cross-authentication, the pros and cons of each method are inconsequential.

API Gateway

APIs are the rules for interaction. A system has a set of codes and descriptions to choose from. When wanting to interact with that system another system must follow those codes. Businesses use APIs as an additional external layer. An API gateway will organize various APIs to organize the incoming requests for connections. According to the World Economic Forum, APIs are drastically different, not sufficiently high level, and speak the language of the underlying blockchain, not the language of the business.

"Given the challenges introduced in the cross-authentication approach, interoperability solutions are hard to achieve through smart contracts in relay and hash-lock solutions. Also, given the challenges introduced in the platform layer, few blockchain platforms are fit for interoperability solutions. Therefore, organizations may opt to use an API approach, where APIs are used in an additional external layer on top of the blockchain platform. Yet, the challenge here can be that the APIs tend to be drastically different, not sufficiently high level and speak the language of the underlying blockchain not the language of the business. Another problem when using the API approach is that it may not be able to guarantee eventual data consistency across the two blockchain platforms, meaning that it may not be possible to guarantee that no new updates are made to a given data item. Moreover, it centralizes trust to whoever operates the APIs." -World Economic Forum

Dragonchain does not agree that the above cross-authentication approaches nor the verifying platform layers are hindrances to interoperability as Interchain™ does not hinge on these being compatible. However, Dragonchain does use APIs extensively to allow business nodes to connect to traditional business systems. But, again, the language of the business does not interfere with the integration to Dragon Net as the business’s private chain is designed to “speak” via any coding language to the business’s legacy system.

Although Dragonchain can’t plan for eventual API changes, when a business adjusts the APIs, it does not compromise the data as the data doesn’t leave the individual Level 1 blockchain. As far as APIs centralizing trust to whoever operates the APIs, Dragonchain respects the liberty of the owners of the APIs to maintain control of their proprietary business logic. If an owner wishes to change the API, it is up to the owner. If they want their private systems to connect to their Level 1 node, they will make the new API available.

The WEF sees APIs as having the following pros and cons:

Pros: Tried and tested technology– easy to implement.

Cons: May not guarantee eventual data consistency and centralizes trust to whoever operates the APIs

Dragonchain would agree with the ease of using an API but would have to disagree with the WEF’s take on negative aspects to APIs. With Interchain™, data remains at the business level and APIs would not affect the data. And again, Dragonchain supports the sovereignty of the business to adjust their own APIs.

Oracles

Oracles According to the World Economic Forum, an oracle is an agent that enables the transfer of external data to the blockchain for on-chain use. Smart contracts set the parameters around the real-world events for the oracle to interact with the blockchain. Oracles need to be trusted.

"An oracle is an agent that enables the transfer of external data to the blockchain for on-chain use. This is done using smart contracts that add information about real-world events to the blockchain. Simple examples of data that are useful to import include temperatures, prices or information about flight delays. Once entered on the blockchain, this data can be used to automate processes based on real-world events (e.g. if a train is delayed, an insurance contract automatically and autonomously delivers the indemnification). Technically speaking, oracles are no different from other smart contracts. However, in order to be useful, oracles need to be trusted, either because they are operated by a trusted third party or thanks to cryptographic attestations." -World Economic Forum

Dragonchain business nodes can act as oracles for other systems or blockchain, as well as act as oracles for themselves via Cron or time based smart contracts. Traditionally with other blockchain solutions, maintaining an oracle is either tedious or complicated, but with Dragonchain it’s built right into the architecture.

The WEF sees the following pros and cons with oracles:

Pros: Proven and easy-to-implement systems. Oracles provide a data feed about external events.

Cons: Do not create actual blockchain-to-blockchain interoperability; they make blockchains interoperable only with non-blockchain systems. Applications are only as reliable and trusted as their oracles are.

Dragonchain agrees oracles are easy to implement and provide data feeds about external events. And Dragonchain also agrees oracles are only as reliable as the data that feeds them. However, Dragonchain does not agree that oracles only connect blockchains to traditional systems. In fact, Dragonchain could Interchain with a specialized, decentralized oracle platform like Chainlink to expand the capabilities to any degree.

Picking the Right Approach

The World Economic Forum says at this point the organization should examine the above information and compare that to the organizational structure and its specific goals.

"When organizations need to decide on an interoperability approach to go by, they need to understand two dimensions. First, they need to understand the business context they are coming from, which can be split into four types of consortia. Second, they need to understand the system they wish to become interoperable with, split into three types. To understand this system, organizations should use the three layers in the blockchain interoperability model to understand whether the system is a compatible blockchain, a non-compatible blockchain or a non-blockchain platform. When this is clear, organizations should now know which of the three interoperability approaches to pick." -World Economic Forum

blockchain interoperability

There is no need to pigeonhole businesses. For Dragonchain, neither the type of organization nor the systems being connected change its approach to interoperability. There may be things that require consideration when implementing solutions, but interop is interop, it’s all software in the end.

“If you're writing something in Dragonchain for, let’s say your QuickBooks system, and you're hitting an API, you have to know how the state is handled, how the messaging is handled, and what you want to do with indexing but it’s just connecting software to software.” -Joe Roets

When framing interop as a connection of software it's easier to understand the flexibility the Dragonchain architecture provides. Implementation is as easy as writing something in Linux or inside a Docker container, which is why a business’s existing devs can build solutions in any programming language. This flexibility will give the enterprise a better chance at a successful interop with a higher likelihood of delivering a good product fast.

blockchain interoperability platform solutions

Current State of Interoperability

There are a few recent articles that touch briefly on projects still trying to solve the interoperability puzzle so there is no need to go into too much detail here. But it should be noted that reports on the status of interoperability solutions, whether those reports are from the World Economic Forum or the blockchain media, repeatedly neglect to mention Dragonchain. Reasons for that are unclear. But it's clear the enterprise and consumers are the ones who miss out on all that Interchain™ offers.

Joe Roets knew early on that the crucial component in bringing blockchain front and center would be to lift the individual and their company. He built a way to support each person's craft and not require conformity. Any business from a Fortune 500 company to a mom and pop pizza joint can prosper from the platform that Dragonchain has built. Any industry from healthcare to food service, from logistics to supply chain, and from music to art can benefit from the industry- agnostic architecture.

Dragonchain was built to provide privacy and yet transparently holds people accountable by proving that an event occurred. There is immense value in aggregating the combined hash power of any public chain to provide an inconceivable amount of security. Working together to support the innovations found within the various utility chains is invaluable.

It’s important to never lose one's sovereignty, whether it's the sovereignty of a nation, an enterprise, or an individual. Dragonchain holds these values close to heart. Freedom and Liberty are the lifeblood of Dragonchain. They can maintain individual rights and proprietary innovations while integrating systems to realize the greater benefits for the whole.