IPwe launches revolutionary platform and deploys 25M NFTs read more >

Skip to main content
Hyperledger Foundation
search
Menu
  • Learn
    • Case Studies
    • White Papers
    • Training & Certification
    • Training Partners
    • Webinars
    • Research
    • Blockchain Showcase
    • Wiki
  • Use
    • Distributed Ledgers
    • Domain-Specific
    • Libraries
    • Tools
    • Tutorials
    • Hyperledger Certified Service Providers
    • Vendor Directory
  • Participate
    • Collaboration Tools
    • Contribute to Coding
    • Academic Collaboration
    • Find a Meetup
    • Regional Communities
    • Speakers Bureau
    • Join a Community Group
    • Labs
  • Events
  • News
    • Blog
    • Announcements
    • Newsletter
  • About
    • Join Hyperledger
    • Members
    • Leadership
    • Charter
    • Job Board
    • Contact Us
  • Join
  • English
    • 简体中文
    • Português
    • Français
    • Malayalam
    • 日本語
    • Español
  • search
Close Search
Tag

Interoperability

Aug 23
Love1

Investing in Verifiable Credentials, Technical Interoperability and Open Source

By the Province of British Columbia, Office of the Chief Information Officer Blog, Hyperledger Aries, Identity

Our 20 Year Journey

Like many provinces and territories in Canada, British Columbia (BC) has a long history of providing secure access to online government services. We started our journey 20 years ago with the introduction of BCeID, a simple username and password solution. A lot has changed since then!

Today, we are investing in Verifiable Credentials (VCs) and a digital wallet. We see these as the cornerstones in the evolution of our digital strategy, adding a much needed layer of trust to the digital economy.  

We want to share what we are doing, why we focus on interoperability and open-source, and why we are excited about VCs being our natural next step.

Why We Care

As a public sector organization, BC has a strong interest in seeing the adoption of technologies that are secure, privacy-preserving, and convenient.  

Digital is obviously everywhere. In 2021, 94% of BC citizens said they are online, and 90% of Canadians have smartphones. Also, according to the Business Council of Canada, in the last decade Canada’s digital economy grew 40% faster than the overall world economy.  In Digital ID terms, this growth is an opportunity to make people’s online lives easier and safer.

We also know that cybersecurity threats are growing and there are no signs of it slowing down. BC sees an astonishing 496 million unauthorized access attempts per day – that’s 5,741 every second! Identity theft and fraud also continues to rise. We need digital trust solutions that counter this increasing risk.

In responding to this new reality, we recognize that people are familiar and comfortable with the many credentials that governments issue today. Things like physical copies of drivers’ licenses, health cards, passports, permits, and reports are widely accepted and trusted.  In BC, we are building on that trust and moving towards providing the same things digitally. We are also enabling confidential connections through the wallet to give people choice and confidence in their digital lives.  

BC’s Approach 

Clearly, digital trust goes far beyond just the government. Canadians expect more access, with greater security, to high-value services in both the public and private sectors. VCs and the wallet provide a highly flexible way to achieve that goal.

Collaboration is critical to achieving that goal and it’s important to us. BC’s Chief Information Officer, CJ Ritchie, strongly advocates for us working together to meet the expectations of Canadians.  She notes, “If we don’t all act together to deliver solutions that protect privacy and interact securely, trust will erode and there will be negative impacts for businesses, people’s livelihoods, and the broader digital economy.”

As our approach evolves, we also remain keen to support open source solutions that interoperate with other national and international efforts. There is no dominant design yet, no one network or technology, so we must remain nimble and flexible in our exploration. We also need to coexist with existing identity solutions that millions of British Columbians already rely upon.

Technology Interoperability

In exploring VCs, BC is contributing to solutions that allow agents to verify credentials from multiple networks. Indeed, through one of our Code With Us initiatives, DID indy, we contributed over 11,000 lines of open-source code to support and prove the viability of a “network of networks”.

We also are focused on the interoperability of Hyperledger Aries agents themselves, another key success metric.  We are leading contributors to Aries Agent Test Harness (AATH), open-source software that runs a series of Hyperledger Aries interoperability tests and delivers the results to the AATH website. Great interoperability requires that we test—and re-test!—that interoperability on a regular basis.

__

Side note: If you want to test the interoperability of any Aries agent with this ecosystem, please sign up to join the Hyperledger Aries Interoperability Event on August  31.

__

Driving Adoption

In BC we have a lot of technical skill in working with VCs and with Hyperledger Aries agents. However, for VCs to be successful, it needs to be easy for others to join in. 

On the agents side, to complement our extensive contributions to Hyperledger Aries Cloud Agent Python (ACA-Py) and other Aries and Indy projects, we also contribute to Hyperledger Aries Framework Javascript (AFJ), the agent commonly used for mobile digital wallets. 

That’s why, when thinking about mobile digital wallets, we opted to contribute to the Hyperledger Aries Bifold project, helping it also essentially become “Bifold as a framework”. Bifold uses AFJ, and BC and others can use it to easily deploy a custom-designed digital wallet. Jurisdictions within Canada and elsewhere in the world are already taking this approach for their own wallet explorations. It’s an open-source stack right the way down.

VC adoption will be helped by a thriving open-source community, and we are giving back wherever we can.

Open-Source Success

We believe the community’s success becomes our success. For years we’ve been committed to open-source, interoperable solutions in this space. Our approach is always evolving, but our contributions and commitment to various digital trust open-source projects and technologies continue.

We hope that even more organizations will join in and contribute. Our goal in BC is a new layer of trust for the internet, making it easier for people to work and play online with confidence. 

Jul 06
Love2

Introducing Hyperledger Aries Framework JavaScript 0.2.0

By Karim Stekelenburg, Hyperledger Aries Framework JavaScript Maintainer and Animo Solutions Co-founder Blog, Hyperledger Aries, Identity

About half a year before we started Animo Solutions, my co-founders and I discovered Hyperledger Aries Framework JavaScript, an open source JavaScript/TypeScript framework designed to create interoperable self-sovereign identity solutions. At the time we were just getting acquainted with the concept of SSI. Just the idea that we could use TypeScript to build made our lives so much easier and the tech so much less daunting. It turned into one of the building blocks of our company, and I would end up becoming a maintainer and strong advocate of Hyperledger Aries Framework JavaScript. Now, after two years of hard work by the community, we’re excited to announce the 0.2.0 release of the framework. In this article, I’ll take you through what this newest release entails and why it will change the way self-sovereign solutions are built.

Hyperledger Aries Framework JavaScript (AFJ) is a framework written in TypeScript for creating interoperable self-sovereign identity (SSI) solutions. The framework has two main focus points. It aims to be as accessible as possible for any developer whether new or experienced in the world of SSI. It is also designed specifically for multi-platform development, so both server-side and mobile solutions can be built with the framework.

The framework has gained a lot of momentum lately. The community has been growing quickly with various governments and organizations stepping in. Our current contributor count is 37, and the working group calls now have around 10 active participants (as opposed to the two we had two years ago). The potential of the framework has become clear to developers other than us (the fanatics). For example, at Animo we recently received funding from the EU NGI eSSIF-Lab initiative to lift the framework to the next level regarding mobile development options.

The new Hyperledger Aries Framework JavaScript release (0.2.0) contains some incredible steps forward. Especially in our goal to make the framework AIP 2.0 compliant. AIP 2.0 compliance will not only ensure the framework supports the latest standards and protocols, but it will also greatly increase interoperability and make it more useful outside of the Hyperledger Indy ecosystem. Specifically, this release contains:

  • Full support for the out of band and did-exchange protocols
  • Postgres wallet support
    • Previously the framework only supported SQLite. This addition ensures the framework is better suited for cloud infrastructure.
  • Wallet import/export support
    • This addition enables users to migrate their wallet data to and from other Hyperledger Indy-based wallets.
  • Pickup protocol v2 for better control over interactions with the mediator
  • Support for the issue-credential-v2 protocol
    • The issue credential and present proof v2 extend the framework with the ability to support multiple credential and proof formats. Instead of adding a separate API for the v2 protocols, we have put a lot of effort in designing a single, easy-to-use API that works with both versions and is extensible for later versions in the future. In the next release we’ll be adding support for the present proof v2 protocol.
  • Credential revocation and revocation notifications for holders and verifiers
    • This allows holders to prove that a credential hasn’t been revoked and verifiers to verify this. The revocation notifications allow the holders to be informed about the fact that one of their credentials has been revoked, rather than discovering this when trying to present proof.
  • Full did:peer support
  • A generic DID resolver that currently supports did:key, did:web, did:sov and did:peer.
  • An upgrade assistant to help users update their wallets to newer versions of the framework
    • As the framework evolves over time, some of the underlying data structures may change. With the upgrade assistant, we aim to make it as easy as possible for users to migrate.

We’re already working hard on version 0.3.0 that will, just like the 0.2.0 release, be packed with new features such as support for the W3C Verifiable Credential Format and BBS+ Signatures 2020, making the framework fully AIP 2.0 compliant.

Check out the 0.2.0 release here and the update instructions here. For general documentation, please see aries.js.org.

If you’re interested in Hyperledger Aries Framework JavaScript and its developments, we recommend you join the working group call (07:00 MT / 14:00 UTC on zoom) and check out the GitHub repo. If you want to discuss building a solution with the framework, feel free to reach out to me at karim@animo.id.

For hands-on experience with AFJ, join us at Hyperledger Global Forum (HGF) for the half day workshop: How To Build a Self-Sovereign Identity Agent With Hyperledger Aries Framework JavaScript. To get a 20% discount to attend HGF and learn more about Hyperledger Foundation Identity projects, use the code: HGFHLFWG22.

Mar 17
Love0

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

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

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
Love1

Why is Interoperability Needed?

By Hyperledger Cactus, Hyperledger FireFly, Weaver and YUI technical communities Blog, Hyperledger Cacti, 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. Cosmos7 and Polkadot8 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 Cactus9 and the Hyperledger Lab Weaver10 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 NameYUI Hyperledger CactusWeaver 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

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 Weaver.

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:

  1. Data transfer: ledger data (state) communication with proof
  2. Asset transfer: movement of an asset from one ledger to another
  3. 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
Love1

#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.

Copyright © 2022 The Linux Foundation®. All rights reserved. Hyperledger Foundation, Hyperledger, and the other Hyperledger Foundation trademarks are trademarks of The Linux Foundation. For a list of Hyperledger Foundation trademarks, please see our Trademark Usage page. Linux is a registered trademark of Linus Torvalds. Privacy Policy and Terms of Use.

Close Menu
  • Learn
    • Case Studies
    • White Papers
    • Training & Certification
    • Training Partners
    • Webinars
    • Research
    • Blockchain Showcase
    • Wiki
  • Use
    • Distributed Ledgers
    • Domain-Specific
    • Libraries
    • Tools
    • Tutorials
    • Hyperledger Certified Service Providers
    • Vendor Directory
  • Participate
    • Collaboration Tools
    • Contribute to Coding
    • Academic Collaboration
    • Find a Meetup
    • Regional Communities
    • Speakers Bureau
    • Join a Community Group
    • Labs
  • Events
  • News
    • Blog
    • Announcements
    • Newsletter
  • About
    • Join Hyperledger
    • Members
    • Leadership
    • Charter
    • Job Board
    • Contact Us
  • Join
  • English
    • 简体中文
    • Português
    • Français
    • Malayalam
    • 日本語
    • Español