Interoperability Archives – Hyperledger Foundation

Mar 17

Hyperledger Cactus: Release V1 on the Road to General Blockchain Integration

By Peter Somogyvari at Accenture and Takuma Takeuchi at Fujitsu Limited Blog, Hyperledger Cactus

Since its inception as a Hyperledger project almost two years ago, Hyperledger Cactus has come a long way. Today, the maintainers are excited to announce a version 1 release that supports many exciting integration applications and moves us in the direction of our “dream” modular architecture.

For creating a new token economy beyond financial and non-financial areas, blockchain interoperability has an essential role in interacting with multiple blockchains in various industries. But it is challenging to develop codes integrating with multiple blockchains because the SDKs provided by each blockchain for posting transactions or getting block data are entirely different. So, this community published a blockchain interoperability tool called “Hyperledger Cactus” to help engineers integrate multiple blockchains easily.

Hyperledger Cactus is a pluggable enterprise-grade framework for transacting multiple blockchains. This project aims to provide a decentralized, adaptable and secure integration between blockchains and various platforms. Cactus codes are composed of three types of parts. “Cactus Servers” provide abstracted APIs that can be uniformly called independent of each blockchain SDK’s format, and APIs that can use each blockchain SDK wrapped with the typescript-axios API format using Cactus API Server. “Business Logic Plugins” coordinate cross-blockchain business logic applications. “Ledger Connectors” facilitate connections to various blockchains, including all the blockchains of Graduated Hyperledger projects.

The Hyperledger Cactus v1 release includes the following modules:

Ledger Connectors – connectors to communicate with various blockchain platforms using multiple programming languages: (TypeScript and Python)
- Hyperledger Besu
- Hyperledger Fabric
- Hyperledger Indy
- Hyperledger Iroha
- Hyperledger Sawtooth
- Corda
- Go-Ethereum
- Quorum
- Xdai
Business Logic Plugin samples – the application integrates multiple blockchains:
- supply-chain-app: management application of supply chains process using Hyperledger Besu, Fabric, and Quorum
- carbon-accounting: carbon accounting application using Ethereum and Hyperledger Fabric
- discounted-cartrade: car ownership trading application using Ethereum currency, tokens on Hyperledger Fabric, and digital identity certification using Hyperledger Indy
- electricity-trade: automatic electricity payment application using Ethereum currency, whose events are triggered by electricity metering transactions on Hyperledger Sawtooth.
Keychain Plugins – A set of plugins for storing sensitive information in storage engines outside of Cactus. Currently, these plugins support AWS, GCP, Azure, and Hashicorp Vault
Support Libraries – Various utility libraries that simplify programming business logic plugins. These are great for setting up your applications and can even help your test automation, where the simulation of a new blockchain is required with the lowest possible resource usage.

As part of the continual effort to mitigate risks, the current 1.0.0 release is undergoing a a third-party security audit at the time of this writing.The process will take about 6 to 8 weeks to complete, but we are planning to keep the 1.0.0 API stability in place as dictated by the semantic versioning rules.

It’s effortless to try out Hyperledger Cactus today. We provide instructions for running a sample implementation of the Business Logic Plugins (service applications in Hyperledger Cactus architecture) that takes advantage of various blockchain platform features so you can evaluate Hyperledger Cactus on your PC.

It is even possible to set up a container with a supply chain example using a single command-line command! Here is a link to this example. We encourage you to see for yourself how easy it can be to get started with blockchain integration using Hyperledger Cactus.

Our long-term architectural goals for Hyperledger Cactus are to offer a flexible, modular system that allows users to configure blockchain integration systems to fit their needs exactly. We want users to reuse code as much as possible while still avoiding code bloat and duplication in the features. In future releases, we will actively cooperate with other Interoperability infrastructures besides Cactus, and we hope to provide more user-friendly tools by incorporating more features.

(Note: for more on the Hyperledger interoperability ecosystem, read Why is Interoperability Needed?)

We would love to welcome you into the Hyperledger Cactus community. Unlike our project namesake, we are not prickly! Whether you want to contribute or are just interested in using Cactus, we would love to connect.

It’s easy to get in touch with us! The simplest way is to reach out on the Hyperledger Cactus Discord channel. (New to Discord? Go here for more and to get signed up.) We have pair programming sessions set up for new contributors and users almost daily (please check the Hyperledger calendar), so we would be more than happy to help if you would like to contribute or want help getting up and running. We look forward to hearing from you!

Mar 14

Love0

Interoperability in the Open Source community

By Tim Spring, Indicio Blog, Healthcare, Hyperledger Aries, Hyperledger Indy, Identity

Without interoperability, you wouldn’t be able to read this article. Websites, computers, and servers must be able to recognize and share information with each other, and shared standards and protocols allow them to do so, thereby giving us the web. On a smaller scale, companies have their own intranets, and, on the smallest scale, you might have your own private thumb drive for personal documents that can interact with whatever machines you typically work on.

Interoperability is not a technological given or an inexorable process. It is a choice that needs to be actively made, and it can sometimes take considerable effort to make work. Think of electronic health care records and the years it has taken to make it easier for a patient to access their health data, something originally provisioned in a 2000 Privacy Rule to the Health Insurance Portability and Accountability Act (HIPAA) of 1996.

Crises, however, can accelerate the slog to technological convergence—and that’s precisely what we’ve seen as a result of the global COVID-19 pandemic. In April 2021, a data-sharing provision of the 21st Century Cures Act came into effect: Patients must be able to have direct digital access to eight categories of clinical notes in an electronic health record, notably—given the need for COVID testing—lab test results.

Cometh the legislation, cometh the tech. Indicio and SITA had already been working on a decentralized, verifiable credential solution to integrate passenger health data with air travel in a privacy-preserving way. Built on Hyperledger Indy and Hyperledger Aries, the technology solved the problem of patient privacy by eliminating the need for a centralizing party to store patient data in order to facilitate verification.

With the Cures Act provision, there was now no obstacle to passengers in the US accessing their COVID test data directly from a Health Information Exchange in the form of a digital credential. They could use this credential to prove their test status without having to share personal information. In situations where it was important to know which test they had taken and when, they could choose to share this information with a verifier, such as the border control or health agency of the country they were visiting.

This solution is now known as the Cardea Project. Successfully trialed in Aruba, its codebase has been donated to Linux Foundation Public Health as an open source solution for sharing health data through verifiable digital credentials. It has an active community group, led by Indicio and Shatzkin Systems, that is working on expanding its features and, critically, its interoperability.

To do this, Cardea launched a hackathon for interoperability— dubbed an “Interop-a-thon”— in September 2021. The goal was to get companies using Aries agents to test those agents against a reference implementation of Cardea and each other. Over a half day, SITA, Liquid Avatar, IdRamp, GlobalID, Canadian Credentials Network, and Network Synergies all successfully interoperated. That’s the headline; the story, however, is that it took work to make this happen—it was an exercise in uncovering glitches, unexpected problems, and overcoming them. That’s what made the Interop-a-thon so valuable for all the participants—and that’s why Cardea is holding a second Interop-a-thon on March 17.

This time, in addition to agent testing, Cardea is going to field “out-of-band” invitations (a critical change coming to Hyperledger Aries at the end of March) and a simple reference implementation of machine readable governance (a way of adding governance rules at the agent level, thereby making governance portable and available offline).

Participants see interop-a-thons as a testing ground for interoperability, and therefore a way to ensure that the products and services they are building have the capacity to scale. This is a critical step toward achieving a network of networks effect. Not surprisingly, the number of participants signed up for the next Interop-a-thon is much greater than the first.

For Cardea, there are more and bigger trials on the way. And with each solution delivered, the scope for expansion becomes greater. If we can successfully implement a system for incorporating health data in travel, what about all the other clinical notes described by the Cures Act? What’s the roadmap to creating a decentralized health record?

This is the perfect challenge for an open source community to solve. And by testing the solution through an interop-a-thon, we can figure out how to make the many function as one.

If you want to learn about interoperability first hand, I highly encourage you to watch the video of their last Interopathon here: https://www.youtube.com/watch?v=KVywPPLhG0U. For more details or to register for the next event on the 17th of March, go here: https://docs.google.com/forms/d/e/1FAIpQLSdpQmjxnYqohk0SfleulNOJXYsi1bhVhMjeGP5MxBMxCa-9TA/viewform

Feb 02

Love0

Why is Interoperability Needed?

By Hyperledger Cactus, Hyperledger FireFly, Weaver and YUI technical communities Blog, Hyperledger Cactus, Hyperledger Firefly, Hyperledger Labs

Blockchain interoperability is one of the crucial features of blockchain technology, operating in three main vectors: enabling scalability, diminishing risks and eliminating silos¹. This blog post focuses on interoperability projects connecting data and value silos.

Standardization bodies are pushing forward drafts to normalize operations across the different interoperability layers. Those working on standards includeOpen Digital Asset Protocol (ODAP) from IETF², the interoperability working group in Digital Currency Global Initiative (DCGI) at ITU³, the subgroup 7 (ISO/TC/SG7) from ISO TechnicalCommittee 307⁴, the Cross-Chain Interoperability working group at the Ethereum Enterprise Alliance⁵, and many others⁶. Interoperability solutions can follow guidelines from standardization bodies for seamless integration across their targets and other interoperability solutions.

Several blockchain interoperability projects focusing on solutions for interoperability among public blockchains flourished in the last years⁶. However, enterprise-grade interoperability solutions have only recently emerged, and the necessary standardization effort is still in its infancy. Although many different categorizations exist⁶, we can broadly classify interoperability solutions into two categories with different philosophies and approaches. In the first, a common “settlement” chain (or hub) is created as a permanent infrastructure to which other chains (e.g., “sidechains”) can connect; the common chain serves as an interoperation medium, offering decentralized trust guarantees to the sidechains for the settlement of cross-chain transactions. Cosmos⁷ and Polkadot⁸ exemplify this approach, which is particularly suited to public blockchains and distributed ledgers.

In the second category of interoperability solutions, a blockchain network, be it public or private, is augmented with modules and capabilities that allow it to interoperate directly with another network without depending on third-party infrastructure. This second category, into which Hyperledger Cactus⁹ and the Hyperledger Lab Weaver¹⁰ fall, is useful in enterprise scenarios where privacy as well as performance are core concerns. Both these approaches have their pros and cons, which are scenario dependent.

The Hyperledger community has been involved in notable efforts to advance open source solutions that respond to modern interoperation needs, which can be wide-ranging, and provides a collection of solutions from which blockchain users and consortia can select as per their requirements. This post explores how four technologies (two projects and two labs) under the Hyperledger umbrella approach the interoperability problem (public blockchains – consortium blockchains – centralized systems), comparing them across multiple criteria.

Hyperledger Cactus

Hyperledger Cactus is a pluggable enterprise-grade framework to transact on multiple distributed ledgers without introducing yet another competing blockchain. It’s an SDK of SDKs.

Hyperledger Cactus aims to provide Decentralized, Adaptable and Secure Integration to and between Blockchain Networks. It aims to cover as many protocols as possible through an extensible plugin architecture where new protocols or functionality can be added by creating new plugins.

Hyperledger FireFly

Hyperledger FireFly provides an API orchestration layer over multiple blockchain ledgers, fostering interoperability in the application tier. Allowing common blockchain programming constructs like tokens, off-chain/on-chain data orchestration, and identity verification to be implemented in pluggable microservice code modules against multiple blockchains. Patterns already implemented that span multiple chains in a single business transaction, include using a Hyperledger Fabric DLT for private business agreement and document verification, orchestrated with tokenized value transfer on a separate Ethereum blockchain. FireFly also provides an API layer into which blockchain interoperability platforms can plug into in the future, for a simplified developer experience.

Weaver

Weaver, a Hyperledger Lab, is a framework with a family of protocols to enable interoperation for data sharing and asset movements between independent networks built on heterogeneous DLTs in a manner that preserves the core blockchain tenets of decentralization and security.

Interoperation using Weaver does not rely on trusted mediators. Rules and requirements are framed using the networks’ internal governance mechanisms. Interoperation relies minimally on shared infrastructure, which may provide identity services but does not play a part in core protocols through which data and assets are shared. Interoperation occurs through protocols that derive their trust from the counterparty networks’ native consensus mechanisms.

Currently, a protocol for data sharing across ledgers with proof of authenticity and provenance is supported (for Fabric and Corda). We are currently adding a new protocol that enables asset exchanges using the HTLC pattern.

YUI

YUI is a Hyperledger Lab that achieves interoperability between multiple heterogeneous ledgers. The lab provides modules and middleware for cross-chain communication as well as modules and tools for cross-chain application development.

For cross-chain communication, YUI is based on Inter Blockchain Communication (IBC) protocol by Cosmos project, with extensions to support various Hyperledger projects. IBC provides the basis for ledgers’ interaction of arbitrary data transfer and computation without the assumption of the trusted third party.

Currently YUI supports cross-authentication between enterprise ledgers (Fabric, Besu and Corda). Each actor of ledgers has to interact with only a respective ledger of its interest to complete a cross-chain operation such as an atomic swap of tokens.

Feature Matrix of Projects

Legend

✅: Supported
❌: Out of Scope or not in the current roadmap
📝: Design/PoC but no official implementation
🏗️: Not *yet* supported

Feature Name	YUI	Hyperledger Cactus	Weaver	Hyperledger FireFly
Remote API access	🏗️	✅	✅	✅
Standard Data Model	✅^(a)	🏗️	❌	❌
Client Language bindings – NodeJS	❌^(b)	🏗️	✅	✅ (d)
Client Language bindings – JVM	❌	🏗️	✅	✅ (d)
Client Language bindings – Rust	❌	🏗️	❌	✅ (d)
Client Language bindings – .NET	❌	🏗️	❌	✅ (d)
Client Contract Language bindings – Go	❌	🏗️	✅	✅ (e)
Contract Language bindings – NodeJS	❌	🏗️	✅	✅ (e)
Contract Language bindings – JVM	❌	🏗️	✅	✅ (e)
Contract Language bindings – Rust	❌	🏗️	❌	✅ (e)
Contract Language bindings – .NET	❌	🏗️	❌	✅ (e)
Trusted Relays	✅	✅	✅	✅
Trustless Relayer	✅	✅	✅	🏗️
Generic Data Exports	🏗️	🏗️	🏗️	❌
Ledger Data Backups	❌	🏗️	❌	❌
Blockchain of Blockchains – To Store Data (e.g. Transactions)	✅	❌	🏗️	🏗️
Blockchain of Blockchains – To Store Network Information	🏗️	❌	🏗️	🏗️
Cross-authentication – light client	✅	🏗️	❌	🏗️
Cross-authentication – Federated via other identity providers	✅	🏗️	📝	📝
Arbitrary data transfer and computation	✅	✅	✅	✅
Exactly-once operation	✅	🏗️	🏗️	❌
Handling misbehaviour	✅	🏗️	🏗️	🏗️
Does not incorporate interaction between new actor(s)	✅	🏗️	✅	✅
Generate state proofs for external consumption	✅	✅	✅	❌
Verify state proofs independently, without becoming a network insider	✅	✅	✅	❌
Move assets from one ledger to another	✅^(c)	✅	✅	✅
Copy assets across ledgers while retaining provenance knowledge	✅^(c)	🏗️	✅	✅
Atomically exchange assets in different ledgers	✅^(c)	🏗️	✅	🏗️
Accountability (auditability) for data, assets, transactions that involved interoperation	✅	🏗️	🏗️	🏗️
Cross-network identity management (including authentication)	🏗️	🏗️	📝	🏗️
Ability to support complex queries	✅	✅	🏗️	✅
Ability to support cross-network smart contracts (ledger–>ledger invocations)	✅	🏗️	🏗️	✅
End-to-end confidentiality	🏗️	🏗️	📝	✅
Privacy-preserving queries	🏗️	🏗️	🏗️	🏗️
Support for network discovery and connection bootstrapping	🏗️	🏗️	🏗️	✅
Support for routing data and assets via intermediate networks	📝	🏗️	🏗️	✅

Future Work for 2022 Q1

Hyperledger Cactus
- Support for the Open Digital Asset Protocol (ODAP)
- Improved documentation and more examples (similar to fabric-samples)
- Increased number of maintainers
- Public test deployment of a Cactus network
- Cactus benchmarks that are reproducible by anyone the same way the functional test cases are as long as they have access to a cloud provider account or a k8s cluster

Hyperledger FireFly
- Multi-ledger support
- Pluggable DID provider support
- Pluggable API Security (e.g. OAuth 2.0)
- Active-active clustering
- NoSQL database support

Weaver
- Implementation of cross-network decentralized identity and credential exchanges as trust basis for interoperation (currently in design spec)
- Relay driver and support data/state view and asset transfers in Hyperledger Besu (Hyperledger Fabric and Corda already supported)
- Relay module: more robustness (fault tolerance), add message queueing features, distribution and load balancing, make compatible with ODAP
- Cross-network transaction invocation and event publish/subscribe
- End-to-end confidentiality support for state and asset sharing
- Augmented data/state sharing protocol to use verifiable external observation features through which the freshness of state can be verified
- Improved documentation, tutorials, and testing features
- Added performance evaluation capabilities
- Inter-compatibility with Hyperledger Cactus through merged and aggregated features

YUI
- Other ledger support (possibly other Hyperledger projects)
- Enhanced support for Solidity and Ethereum-based ledgers
- Enhanced support for connecting the Cosmos ecosystem (such as Tendermint light client for Solidity)
- Improved documentation and release samples

Notes:

a) Based on the Inter Blockchain Communication Protocol (IBC) (i.e., the specifications define packet data structure and the interface of handler of packets)
b) Developers only need to interact with the ledger and the framework does not incorporate another layer between them
c) Supported by auxiliary modules such as Cross framework
d) Hyperledger FireFly API is REST and JSON, so all language “bindings” are supported
e) Access to contracts via Hyperledger FireFly is also fully REST-ified, so all language bindings are supported

References:

1 – https://web.ist.utl.pt/~ist180970/papers/phd_cat_rafael_belchior.pdf
2 – https://datatracker.ietf.org/doc/draft-hargreaves-odap/02/
3 – https://www.itu.int/en/ITU-T/extcoop/dcgi/Pages/default.aspx
4 – https://www.iso.org/committee/6266604.html
5 – https://entethalliance.org/participate/working_groups/
6 – https://dl.acm.org/doi/10.1145/3471140
7 – https://v1.cosmos.network/
8 – https://polkadot.network/
9 – https://www.hyperledger.org/use/cactus
10 – https://github.com/hyperledger-labs/weaver-dlt-interoperability

Authors:

Rafael Belchior (Hyperledger Cactus), Nicko Guyer (Hyperledger FireFly), Jun Kimura (YUI), Hart Montgomery (Hyperledger Cactus), Venkatraman Ramakrishna (Weaver), Peter Somogyvari (Hyperledger Cactus), Susumu Toriumi (YUI), Dhinakaran Vinayagamurthy (Weaver), and Jim Zhang (Hyperledger FireFly)

Jun 09

Love1

Meet YUI, one of the new Hyperledger Labs taking on cross-chain and off-chain operations

By Jun Kimura, CTO of Datachain Blog, Hyperledger Labs

As enterprises and organizations increase their adoption and deployment of blockchain technology and networks, the overall complexity of systems are growing exponentially. While it’s exciting to see the expanding reach of blockchain, it also creates a host of new requirements for cross chain and off chain sharing of data, transactions and more.

At Hyperledger Global Forum (HGF) 2020 in Phoenix, one group of developers got together to share their work and create a blockchain integration tool designed to allow users to securely integrate different blockchains. They brought their project to Hyperledger Labs and, within a few months, it was approved as Hyperledger Cactus.

During this year’s HGF, three new Hyperledger Labs that are each tackling elements of cross-chain or off-chain operations are making their debuts: FireFly, Weaver and YUI. Read on to learn more about YUI.

Meet YUI

By Jun Kimura (https://github.com/bluele), CTO of Datachain (https://twitter.com/datachain_en)

YUI is a new Hyperledger Labs project to achieve interoperability between multiple heterogeneous ledgers. The word “YUI” is derived from a Japanese word to represent knot, join and connect.

YUI provides modules and middleware for cross-chain communication as well as modules and tools for cross-chain application development, including an explorer to track status and events for cross-chain environments.

This is the brief summary of YUI’s design principles.

Cross-Authentication: Cross-authentication allows blockchains to be interoperable without requiring a trusted third party by on-chain verification.

Blockchain-agnostic communication specs: By using a unified communication protocol, we can introduce a blockchain-agnostic message layer between blockchains.

Arbitrary data transfer and computation: By exchanging messages with a unified communication protocol, arbitrary data transfer and computation is possible. It also enables developers to implement arbitrary application logic that is not limited to a token transfer.

Avoid adding components that introduce additional trust: Introducing such components that need additional trust may decrease the level of security of a system as it would be bounded by the lowest security component in the system.

Do not introduce a new layer: Each actor (of ledgers) has only to interact with a respective ledger of its interest to complete a cross-chain operation unless the application has additional requirements.

Check out the YUI’s Lab page to learn more about the design principles of YUI: https://labs.hyperledger.org/labs/yui.html

High Level Architecture

For now, the modules and middleware for cross-chain communication (IBC Module) are available. The basic components of IBC Module are described in the following diagram:

As you can see on the diagram, we have an IBC Module on each ledger and a Relayer between them. As Client modules should be designed to support each underlying ledger, we have built different Client modules for each ledger such as Client modules for Hyperledger Fabric and for Hyperledger Besu.

For cross-chain communication, the design of YUI is based on Inter Blockchain Communication (IBC) protocol by Cosmos project, with extensions to support various Hyperledger projects.

Check out the IBC GitHub page to learn more about IBC and related words: https://github.com/cosmos/ibc

Get added background from this session at HGF: Fabric-IBC, Besu-IBC Combined with IRITA – Bringing Interoperability on Enterprise Blockchain – Zhiwei (Jeffrey) Hu, Shanghai Bianjie AI Co., Ltd. & Ryo Sato, Datachain, Inc.

Jun 09

Love1

Meet Weaver, one of the new Hyperledger Labs taking on cross-chain and off-chain operations

By Venkatraman Ramakrishna, IBM Research - India Blog, Hyperledger Labs

Meet Weaver: DLT Interoperability

By Venkatraman Ramakrishna, IBM Research – India

We are excited to announce Weaver, a project that was incubated in IBM Research. Weaver is an architectural framework with a family of protocols that enables scalable interconnectivity and interoperability between distributed ledgers while preserving core tenets of decentralization and security. This framework was motivated by the fragmentation of the blockchain ecosystem, with different flavors of permissioned blockchain and distributed ledger technologies (DLTs) leading to the proliferation of independent networks managing processes of limited scope and keeping assets in silos. Weaver’s mission is to link processes and enable seamless but controlled flow of assets and data across network boundaries. It seeks to achieve this while maintaining the autonomy of the networks and the ledgers within and avoiding dependencies on trusted intermediaries.

Overview

Weaver is a general-purpose interoperability framework that provides a common set of capabilities for trustworthy information communication across ledgers, whether they belong to the same network or different networks running on different DLT stacks. Key principles that guide Weaver’s design are:

Accommodate DLT heterogeneity without favoring a particular DLT design
Allow networks to maintain their independence and collective sovereignty
Minimize coupling during cross-network interactions
Rely on common standards for cross-network protocol units
Do not require a trusted intermediary or third-party ledger
Do not require changes to existing DLT stacks
Make no security and trust assumptions on Weaver components
Treat privacy and least privilege as a first-class requirement

Weaver addresses three broad classes of use cases:

Data transfer: ledger data (state) communication with proof
Asset transfer: movement of an asset from one ledger to another
Asset exchange: atomic exchange of asset ownership in different ledgers

The protocols to realize these use cases can be abstracted into a common stack of layers akin to the OSI model, from message formats at the bottom to governance rules at the top (see diagram below).

The Weaver architecture has three major components underpinning it:

DLT-agnostic Relays with DLT-specific drivers to route cross-network requests and responses.
Interoperation modules that operate through their network’s native consensus processes, typically smart contracts or decentralized applications.
Decentralized identity framework to share and authenticate network members’ identities.

The figure below illustrates this architecture, with a typical Fabric network to the left and a typical Corda network at the right. Weaver components are marked in green, and the design of the relay is called out in detail.

Hyperledger Labs Project

The Weaver Hyperledger Labs project was launched at the end of March 2021 with specifications detailed in a set of RFCs, a framework to run end-to-end network tests for updated or new interoperation protocols, and documentation to help users understand Weaver concepts and code in more detail.

Weaver currently offers protocols for data transfers among Hyperledger Fabric and Corda networks, and asset exchanges among Hyperledger Fabric networks. We hope to expand the coverage to more DLTs with the help of the community! Please check out the project repository for useful links and references and start contributing.

Learn more about Weaver and other recent code contributions from IBM in this panel from HGF:

Panel: Hyperledger Contributions from IBM – Kelly Ryan, Rakesh Mohan, Chris Ferris, Arnaud Le Hors & Elli Androulaki, IBM (Sponsored by IBM)

For a more technical dive into the challenges of interoperability and approaches to tackles them, check out this HGF session:

Blockchain Interoperability: Challenges, Ongoing Efforts, and Potential Solutions – Vinayaka Pandit, IBM Research – India

May 26

Love0

#HyperledgerInterop: A Sampling of Production Cross-Platform Solutions and Deployments Built with Hyperledger Technologies

By Hyperledger Blog, Hyperledger Besu, Hyperledger Fabric, Hyperledger Sawtooth

The rapid pace of innovation in the development and deployment of blockchain technologies is creating more points of intersection for cross chain and cross application data and transaction flow. Fortunately, there is also a robust effort underway to deliver new approaches to ensuring that solutions work across platforms and protocols. Case in point: at the upcoming Hyperledger Global Forum, there will be 20 talks covering various aspects of blockchain interoperability and integration.

Below, we take a look at a sampling of use cases where Hyperledger technologies are at play in solutions that are operating in or enabling cross-platform production deployments:

Daml
Daml, a multi-party application platform created by Digital Asset, is widely used in distributed applications that deliver portability across a number of blockchain platforms, including Hyperledger frameworks: Besu, Fabric and Sawtooth. Recently, using Hyperledger Fabric, Ethereum and a traditional Postgres database, Digital Asset demonstrated platform interoperability and open sourced the code to help CBDCs (and other applications that need to integrate with CBDCs) interoperate, making the digital currencies compatible regardless of the underlying technology. The code for this CBDC use case is available on Git Hub. Read more and watch the demo here.

Hala System’s Sentry

Hala Systems is using Hyperledger Fabric alongside Hedera as part of its Sentry early warning system, which helps protect 2M+ people in Syria. Hala Systems uses both Hyperledger Fabric and Hedera to manage the metadata of created media and user input produced in conflict. The hashed metadata is simultaneously written to a private blockchain built on an IBM Blockchain Platform powered by Hyperledger Fabric and to Hedera Consensus Service. Hala Systems uses the IBM Blockchain Platform to act as its internal repository, preserving additional metadata to augment the auditable hash data sent to Hedera Consensus Service. With these two sets of records, any third party can verify the information on the public ledger to match the image and, if necessary, its accompanying data stored on the private ledger.

Project Starling

Project Starling was developed to help empower organizations to securely capture, store, and verify human history. Starling represents a ground-breaking methodology in the fight against the spread of misinformation and the looming threat of deep fakes by providing open-source tools. Starling uses the latest cryptographic methods and decentralized web protocols to meet the challenges of establishing trust in our most sensitive digital records.

Jointly developed by teams at USC and Stanford, the Starling framework leverages multiple decentralized technologies including IPFS, GUN, Hyperledger Fabric, and Hedera Hashgraph throughout its process. For each piece of media captured, the framework is designed to store images on IPFS, using Filecoin, these image’s associated metadata is then stored in a permissioned Hyperledger Fabric network, securely protecting any sensitive information. For each media file, a hash of the information stored in Hyperledger Fabric is taken and recorded on the public Hedera network. By doing so, third parties are able to more readily trust the application owner and be assured no bad actor has falsified or modified results after the fact.

Join the conversation this month about developments and deployments using Hyperledger technologies to drive interoperability with #HyperledgerInterop on social channels.

Cover image by Clker-Free-Vector-Images from Pixabay.

May 10

Love0

Universal DLT interoperability is now a practical reality

By Luke Riley, Head of Innovation at Quant Blog, Hyperledger Besu, Hyperledger Fabric

Anyone who’s involved in the implementation of DLT-based solutions will need no introduction to the problem of interoperability. It’s an issue that has dogged the technology from the very beginning and has severely limited its application. Now, though, that era is in the past. Today, DLTs can interoperate seamlessly and easily, allowing their full potential to be realised across a multitude of use cases. Here, we’ll take a look at how this breakthrough has been achieved. And we’ll begin with a review of the problem and the various attempts to solve it.

Over the years, there have been many attempts to solve the problem of interoperability. Of the various approaches taken, the World Economic Forum (WEF) identified three main categories: Cross Authentication (DLT-relayers), Oracles and the API Gateway. Which, of course, begs the obvious question: which is the best path to follow in the search for true universal interoperability?

To answer this question we will firstly introduce each approach and follow with a comparison between them.

WEF DLT Interoperability Category 1: Cross Authentication

This interoperability category is the most decentralised of the three categories. It requires separate authorization on each side of the interoperability connection. Examples include:
– Hash-locking: this is used, for example, to atomically swap assets across distributed ledgers.
– DLT-Relayers: these are distributed ledger communication protocols that act as orchestration layers between other distributed ledgers. They are designed for the exchange of different types of messages between these networks. Two DLT- relayer examples are Polkadot and Ethereum 2.0.

WEF DLT Interoperability Category 2: Oracles

Oracles allow distributed ledgers to connect to external data resources (which may be another distributed ledger). Oracles are therefore orchestration layers, connected to different resources, that perform various actions according to on-chain and off-chain pre-defined bespoke rules. Some oracles not only pass information from an external data resource to smart contracts but also send data from the distributed ledger back to the external resources. There is usually a single oracle to perform each task, but occasionally there can be a collection of oracles performing the same task (in a permissioned or permissionless manner). Smart contract logic then states how consensus of data is achieved between multiple inputs recorded by different oracles. An example of an oracle system is Chainlink.

WEF DLT Interoperability Category 3: API Gateway

An API provides access to a server and the resources it is connected to. An API gateway provides organised access to many underlying API resources, simplifying requests to the underlying resources to improve the user experience. A DLT API gateway can have shared end points across distributed ledger networks, standardise DLT data objects and can compress many DLT actions into one endpoint. This is the approach we take with Quant’s Overledger API.

One way to determine the best interoperability path to follow in the search for true universal interoperability is to look at how each approach “scores” in terms of the key functional criteria that defines a robust, flexible and scalable solution. These criteria are:

Proven Technology

While it’s true that DLT-relayers have been in development for many years, they are not yet proven technology – there is, as yet, no stable implementation running in a high-load environment. A similar story is true of oracles – although data feed technology is established, data feeds from one distributed ledger network (DLN) to another and back again has yet to be proven in practice. API gateways, on the other hand, have a long-proven record with many thousands of implementations around the world.

Decentralisation method: As pointed out by the WEF, the three different models have different decentralisation properties. DLT-relayers, for example, can be fully decentralised if a permissionless DLN is used. Oracles, however, have two different levels of permissions. One depends on the network permissions, the other depends on the smart contract permissions. With API gateways, on the other hand, the amount of decentralisation is provided by the ecosystem of separate API gateways run by different stakeholders.

How users interact: For DLT-relayers, users either need to be provided with direct access to relayer nodes, or they must be given access to DLT-relayer nodes through an API gateway model. Non-oracle users can interact with the on-chain oracle smart contracts, or they can interact with an off-chain oracle instance. For the API gateway itself, users interact through the API using standard elements like REST.

Resilience: The resilience of DLT-relayers depends on the consensus protocols it runs, particularly that of the connecting chain. As each consensus protocol has limits on the percentage of malicious nodes that it can handle, the resilience of the entire network is dependent on the number of nodes in the network. With oracles, the more oracles that feed data about the same topic, the more resilient the system – generally speaking – will be. An API gateway’s resilience is determined by the number of instances running and its load balancing capabilities and can be tuned for each type of use case.

Combining permissionless and permissioned DLNs: As yet there is no technical, or convincing theoretical demonstration, of how this can be completed using DLT-relayers without compromising security.

The brief analysis above points to a clear conclusion: API gateways have significant advantages over the other approaches. And it was for this reason that Quant chose the API gateway model for Overledger, our own solution to the challenge of interoperability. Developed by a team highly experienced in enterprise security and nation-level critical systems, Overledger is built on research that began as a collaboration with UCL, and now provides a secure, simple, and cost-effective API connection to all major DLTs. A robust, enterprise-grade solution, Overledger is easily integrated with multiple DLTs, including Hyperledger Fabric and Hyperledger Besu, and Quant is constantly expanding the list of supported DLTs.

Today, Overledger is helping to unlock the potential of DLTs in many major projects across the world. One of the most ambitious of these projects is LACChain, an alliance led by the Inter-American Development Bank. Operating across the Latin American and Caribbean region, LACChain is already having demonstrable positive social impact, and the consortium has developed a roadmap that will ultimately lead to the interconnection of regional DLT ecosystems.

Achieving success will require the integration of LACChain (which provides both Hyperledger Besu and EOS technologies) and Quant’s unique Overledger technology. This will facilitate the creation of a new, fast cross-border payments system for the region, using tokenised currency. By flexibly tokenising money, using Quant’s (patent-pending) multi-DLT token technology (MLTS), the LACChain DLN will power a variety of new solutions, ranging from money transfers between private individuals to government and corporate payments, as well as many other future LACChain use cases.

One immediate benefit of this breakthrough will be a revolution in remittances and financial inclusion. For example, where, currently, cross-border banking services for people such as migrant workers or farmers are hard to access and unreliable, the LACChain solution, supported by Overledger, will allow foreign and/or local currency to be transferred in a simple but secure manner, with affordable transaction costs. The system has the potential to be expanded to the large-volume market of the unbanked or others currently excluded from the financial system. In short, the LACChain/Quant partnership will open the door to a host of faster, more efficient and more inclusive financial processes and applications in the LAC region, ranging from cross-border and interbank settlement, to the deployment of digital wallets and smart contracts. The pilot phase of the LACChain project is already well advanced, and full commercial development over the coming twelve months will be a landmark year for DLTs and DLNs.