See how Botanical Water Technologies Ltd and Fujitsu have built a solution to the 3 trillion liters of water wasted every year using Hyperledger Fabric! 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
Category

Hyperledger Labs

Jan 18
Love0

Hyperledger Mentorship Spotlight: Enable Kubernetes Operators support for Fablo

By Great Umegbewe Nwebedu Blog, Hyperledger Fabric, Hyperledger Labs, Hyperledger Mentorship Program

What did you work on?

Project name: Enable Kubernetes Operators support for Fablo

Hello, I’m Great Umegbewe. I am currently a sophomore studying Computer Science at the University of Nigeria, Nsukka. During the fall of 2022, I had the chance to work on Fablo, a Hyperledger Lab, as part of the Hyperledger Mentorship Program. I was mentored by Jakub Dzikowski and Piotr Hejwowski and found the experience to be both valuable and enjoyable. This blog post will share some of my insights from this experience.

Fablo is a simple tool to generate a Hyperledger Fabric blockchain network from a config file and run it on Docker. Its main goal is to provide a super-easy start with Hyperledger Fabric. It uses a declarative approach to define components in a network, in a single file named fablo-config.json. This where users can define channels, chaincodes, organizations and engines (Docker or Kubernetes). Before I came in, only Docker was supported as an engine. I worked on adding support for Kubernetes.

Example of a fablo-config.json file

{
  "$schema": "https://github.com/hyperledger-labs/fablo/releases/download/1.1.0/schema.json",
  "global": {
    "fabricVersion": "2.4.0",
    "tls": false,
    "engine": "kubernetes",
    "peerDevMode": false
  },
  "orgs": [
    {
      "organization": {
        "name": "Orderer",
        "domain": "orderer.example.com"
      },
      "orderers": [
        {
          "groupName": "group1",
          "type": "solo",
          "instances": 1
        }
      ],
      "tools": {}
    },
    {
      "organization": {
        "name": "Org1",
        "domain": "org1.example.com"
      },
      "peer": {
        "instances": 2,
        "db": "LevelDb"
      },
      "tools": {}
    }  ],
  "channels": [
    {
      "name": "my-channel1",
      "orgs": [
        {
          "name": "Org1",
          "peers": [
            "peer0",
            "peer1"
          ]
        }
      ]
    }
  ],
  "chaincodes": [
    {
      "name": "chaincode1",
      "version": "0.0.1",
      "lang": "node",
      "channel": "my-channel1",
      "directory": "./chaincodes/chaincode-kv-node"
    }
  ]
}

What did you learn or accomplish?

Before the mentorship, I had previous experience working with Kubernetes and Bash, but none with Hyperledger Fabric. This mentorship helped me learn about Hyperledger Fabric and its components. It also taught me a whole lot about open source software and how the work of a maintainer isn’t that easy.

Hats off to Jakob Dzikowski and Piotr Hejwowski. They are really amazing maintainers and mentors.

To contribute to Fablo, I needed to learn how Fablo worked and understand Hyperledger Fabric. Again my mentors were very helpful with this.

I initially started by defining the various components on yaml’s with the images of peers, CAs, etc. This worked in one direction, but was daunting and had several problems. Luckily, Hyperledger had a Kubernetes Operator hlf-operator with a kubectl plugin that managed all aspects from the deployments, statefulsets and persistent volumes. With this abstraction what was left is to:

  • Write the shell scripts wrapped around the operator plugin to accommodate the required components (channels, chaincodes, CAs, peers).
  • Add support for Kubernetes engine in the fablo-config.
  • Template the shell scripts.
  • Create a snapshot and unit testing.

What comes next?

This has been a valuable experience. I was really challenged and my skills have improved so much. For the foreseeable future, I will continue working on Fablo and other open source projects. Big thanks to my mentors. Hopefully, I will become a maintainer for Fablo too.

Apr 28
Love0

Bosch leverages open source model; teams with PolyCrypt to tackle blockchain for the Economy of Things

By Hyperledger Blog, Hyperledger Labs

Read the full case study here.

Some years ago, researchers realized that IoT devices would need to buy and sell from one another. In this “Economy of Things,” the items to be traded will include power, data, and connectivity. Most transactions will be fast, low value, and high frequency. 

For a company like The Bosch Group that’s active in everything from autonomous vehicles to thermal plants, the Economy of Things will touch many lines of business. That’s why, in 2017, the company’s advanced research group, Bosch Research, was looking to find a way to scale up blockchain transactions to support the Economy of Things. 

Bosch set out to do meet that requirement by leveraging a specific, step-by-step open source strategy for developing new markets:

  1. Identify a requirement
  2. Set goals
  3. Consider the terrain
  4. Build a partnership
  5. Pick a suitable license
  6. Use open source archetypes

The goals were to lead an effort to create standards for the Economy of Things and to build a framework where different partners could work together. 

A survey for likely partners led the Bosch team to Perun, an early layer-2 protocol that passes state information off-chain through virtual channels. Bosch joined forces with several academics to implement this protocol and start creating an ecosystem.

As part of the process, Perun needed a stable home where everyone could access the latest code, and other people could find it. Hyperledger Labs provides a space where developments can be started without the overhead of creating an official Hyperledger project. 

In Q3 2020, Perun was welcomed into Hyperledger Labs, and development has continued with work from the team at Boch and PolyCrypt GbmH, a startup spun out of the Technical University Darmstadt, where much of the academic research behind Perun began. 

The Bosch team was eager to talk about its approaches and contributions to Hyperledger Foundation. To that end, they worked with Hyperledger marketing and others in the Perun community on a case study that details not only the business and technology challenges they’ve set out to tackle but also the strategic way they are leveraging open source development to advance the industry for all.

We never know what technology will turn into the Next Big Thing. 

Perhaps Perun will be one of them, powering billions of micropayments between IoT devices or enabling people to shop with Central Bank Digital Currencies (CBDCs) that are still on the drawing board today. 

Read the full case study here.

Apr 12
Love0

Hyperledger Lab Perun: Achievements of 2021 and Outlook for 2022

By the Perun community Blog, Hyperledger Labs

2021 was an eventful year for the Hyperledger Lab Perun, which is maintained by PolyCrypt GmbH and Robert Bosch GmbH’s project “Economy of Things.” Below we summarize developments and achievements for the project and the growing network surrounding it. We also  provide a brief outlook on what’s to come in 2022.

This Hyperledger Lab  aims at establishing an open-source project based on Perun channel protocols, which is a technology for scalability and interoperability of blockchains. The core components are the Go-Perun SDK and the Perun Node.

New features in Go-Perun SDK & Perun Node 

Virtual channels: The SDK now supports virtual channels. This allows opening channels with funds from other channels and therefore without any on-chain fees.

Reorg-resistance (Ethereum backend): The Ethereum backend now supports reorg-resistance. That is, it is possible to configure how many blocks are required in order to confirm an on-chain transaction. This improves the robustness of our library as it protects against chain reorgs.

External watcher: Go-Perun now has an interface for injecting a custom watcher logic. This means that SDK users can now implement their own watcher logic or use an external service for watching and reacting to chain events.

Perun Node v0.6: A new client that adds a text-based user interface for trying out Perun Node, support for ERC20 tokens and improved error handling.

More supported blockchains 

Polkadot backend: We successfully developed a Polkadot backend for Go-Perun. This means that it is now possible to use Go-Perun on Polkadot chains. The backend is currently restricted to single asset payment channels.

Cosmos backend: We successfully developed a Cosmos backend for Go-Perun. The on-chain logic has been implemented in the form of a CosmWasm smart contract. This means that it is now possible to use Go-Perun on a Cosmos chain supporting CosmWasm. The backend is currently restricted to payment channels.

Dfinity backend (smart contract): We started the development of a backend for the Dfinity Internet Computer. This currently includes the Perun smart contracts for this network. We plan to continue the backend development later this year.

Demonstrators, Tutorials, Talks

Perun Credential Payment: We have published a proof of concept implementation that shows how trustless and low-fee payments for verifiable credentials in the context of self-sovereign identities (SSI) can be realized using Perun State Channels.

Perun Tutorial and Protocol Documentation: We extended the documentation of our software. In particular, we added developer tutorials that explain how one can get started with using Go-Perun for developing their favorite state channel application. We also added a description of the perun protocols.

Talks: We have given several talks on the Perun Project:

  • Hyperledger In-depth: An hour with Bosch on Scaling DLTs with the Perun lab Framework
  • Getting hands on Perun State Channels (Hyperledger Lab)
  • Blockchain Scaling & Interoperability with Perun Framework

Outlook for 2022

Cross-chain interoperability: We will be working towards enabling cross-chain capabilities of the Perun Framework. This will enable, for example, asset swaps between different blockchains and more.

IoT Readiness: We will make the architecture of Perun Node more flexible, so that funding and watching services can be accessed over remote interfaces. We will also add an alternate client implementation that can be deployed on resource constrained embedded devices.

More blockchain backends: We will be looking into extending the feature set of our existing backends, for example, enabling generalized state channels on Polkadot. We plan to add more blockchains to our list of supported backends.

Building out the ecosystem: As development with the protocol and surrounding network continues, we will be working to further define the components of the Perun ecosystem and the communities working to advance these technologies.

If you want to learn more about the framework, please refer to the white paper and our last Hyperledger labs post or this Hyperledger presentation on Perun or reach out via our Discord channel. (New to Discord? Go here for more and to get signed up.)

Mar 24
Love1

Hyperledger Lab Perun Adds Payment Channel for Cosmos Network

By the Perun community Blog, Hyperledger Labs

We are excited to announce that Perun, a Hyperledger Lab, has published the first version of the Perun-CosmWasm blockchain backend. For the first time, this enables Perun Channels on the Cosmos Network using the CosmWasm smart contract technology. For our first release, we focused on payment channel functionality on a single Cosmos blockchain. This paves the way to enabling the full potential of Perun on Cosmos in the future: atomic transactions with arbitrary transaction logic across multiple Cosmos blockchains.

Payment Channels on Cosmos Network

A payment channel is a construct that allows users to transfer and swap funds at low latency and nearly zero fees without a trusted intermediary. It allows users to massively scale their transaction capabilities without losing the trustless nature of blockchain technology. 

Figure 1: Alice and Bob create an off-chain channel to interact.

In the future, Perun will support channels across multiple blockchains—for example, two Cosmos chains, or a Cosmos chain and an Ethereum chain. This will enable cross-chain applications based on channel technology. 

With the addition of CosmWasm, the Perun framework now contains three backends (Ethereum, Polkadot, Cosmos). Blockchain-agnostic applications can be written and run within Perun channels. The used backend can be exchanged with another to enable identical contracts across multiple blockchains. The possibility to add further backends increases the modularity of the architecture of blockchain-agnostic applications.

About Perun 

Perun, a Hyperledger Lab, is a joint DLT Layer-2 interoperability and scaling project contributed by Robert Bosch GmbH’s project “Economy of Things” and PolyCrypt. PolyCrypt is a spin-off of the Technical University of Darmstadt (TUDa).

If you want to learn more about the framework, please refer to the white paper and our last Hyperledger labs post or this Hyperledger presentation on Perun or reach out via our Discord channel. (New to Discord? Go here for more and to get signed up.)

Mar 07
Love0

Performance SandBox, a new Hyperledger Lab, is a test ground for blockchain performance research

By Sam Yuan, IBM Blog, Hyperledger Labs

Meet Performance SandBox, a new Hyperledger Lab for testing new research to boost performance of blockchain platforms. This is an open source effort and you’re welcome to get involved by checking out the lab’s repository or by joining the monthly Performance and Scale Working Group calls.

What is Performance SandBox?

A new addition to Hyperledger Labs, the Performance Sandbox is a testing environment for Hyperledger projects performance research usage. 

As the picture above shows, the Performance Sandbox uses Kubernetes as its infrastructure and is integrated with monitoring and open tracing (or say open telemetry).

– It supports users deploying a target network such as a test-network, also known as a SUT (system under test), for asset transform for Hyperledger Fabric

– It supports any traffic generator such as Tape, a light-weight tool to test performance of Hyperledger Fabric, that keeps sending traffic to the target network/SUT.

How does the Performance Sandbox work?

Performance researchers are able to use this lab to do research with the steps below:

1. Start the sandbox with Kurbenetes integrated with monitoring and open telemetry

2. Deploy the SUT onto the Kubernetes infrastructure.

3. Start the traffic generator to keep sending traffic to SUT

4. Monitor and analyze test results from the dashboard/open telemetry results.

5. Changes local source code (e.g., Hyperledger Fabric), make local docker image and redeploy the SUT.

It will extend the existing paper published by the PSWG with monitoring and open telemetry. As the right side in the above figure shows, we can see the performance test model published previously by PSWG, with SUT, traffic generator and observers.

Flexible design

– Migration from Kind to other Kubernetes platforms: In this lab, we use Kubernetes as infrastructure, hence it is easy to migrate to any other Kubernetes-based infrastructure.

– Use with blockchain systems other than Hyperledger Fabric: So far, the PoC and demos have been based on Hyperledger Fabric. However, as the orange area shows, the blockchain system can be replaced with any kind of blockchain system.

– Traffic generator: So far this has been deployed as a demo with Tape, as it is a Kubernetes development. It can be replaced with Hyperledger Caliper or Jmeter. Tape is a sample performance tool for Hyperledger Fabric without an SDK (close to the blockchain network itself). Caliper is based on the Hyperledger Fabric SDK (closer to the application level). You may need to use Jmeter to create traffic for end-to-end performance research assuming you expose the RESTFUL endpoint to the end user

– Size of SUT: you are able to scale the size for SUT, as it is a blockchain based on Kubernetes.

Technological details

Read on for technological details around three topics: deploying monitoring tools with operator, traffic generator, and dashboard.

Deploying monitoring tools with operator

In the Performance Sandbox, we used operator technology (refer to operator capablities) to make monitoring systems work with Auto Scaling and Auto Tuning.

For example:

When a blockchain node (e.g., Hyperledger Fabric peer) has been deployed, the Kubernetes operator will help make a connection between the blockchain node (as service/pod) and monitoring system (as Prometheus, Jaeger, etc.) to automatically tune the operator framework to a certain workload pattern.

Ideally, users are able to deploy any size of nodes (e.g., number of peers) for the SUT without spending too much effort on configuration.

Meanwhile, the operator is able to deploy across Kubernetes clusters, making it easy to migrate to any specific cluster.

Traffic generator

In most cases, performance is evaluated by TPS (transactions per second). However, there are different scenarios for the “transaction.”

Let’s assume we have an application server that receives a restful API to support Alice and Bob, sending traffic from the application GUI/mobile app. Normally, the application will connect with the blockchain network. Generally speaking, the application depends on the SDK and SDK relay on network protocols such as GRPC.

On the left side of the figure above, the three arrows indicate three different levels of traffic.

– At the end user level, indicated by the green arrows, an application receives a business transaction and returns it. Total time spent includes application logic and SDK level duration.

–  At the SDK level, indicated by the blue arrows, an SDK receives a business transaction and returns it. Total time spent includes SDK logic and communication level duration.

– At the communication level, indicated by the red arrows, the total time involves packaging business transactions following communication protocol and sending them to the blockchain network.

Hence, we can see from the open tracing span, the green line means the total time starts when the application received the user’s request and ends with application return. Then the blue line appears as SDK processing time. Then the gRPC time reflects the duration for a gRPC to send and receive a response back from the blockchain network.

Ideally, those TPS are nearly the same and you either focus on the application side or blockchain side. However, we’d better have tools on hand for handling some edge cases such as SDK overhead, bad application logic, etc. As on right side:

1. Indicates application processing time before transaction reach at SDK and ready for send to blockchain network.

2. Indicates SDK starts processing the transaction and time spent before network communication happens.

3. Indicates SDK received a result for network communication, and time spent before SDK return.

4. Indicates application processing time before transaction return back to end users from SDK result.

{Note: If you’re interested in blockchain performance testing tools, you can also check out Hyperledger Caliper.}

Dashboard

In the Performance Sandbox, we used a dashboard for system monitoring. In most cases, we analyze TPS as a collection for data drawn as a histogram.

For example, we are able to draw down Transaction Throughput based on timeline into a figure (refer to performance metric). However, as the blockchain is based on crypto service, which relays CPU resources and consensus, that relays bandwidth.

With the dashboard, we are able to collect both blockchain matrix and system matrix at the same time, by integrating different matrices together, identifying limitations/bottlenecks in a visual way.

Assuming bandwidth is a bottleneck for the current Performance Sandbox environment, we can see the CPU/time left with some capabilities at all rounds of testing. Each time when  the transaction throughput reaches a specific value, network bandwidth will be used up.

What’s Next

Now, let’s go back to the goal of this new Hyperledger Lab: to provide a sandbox to make performance research usage easier. To see what’s next:

BlockchainDeployment Communication Level TrafficSDK Level Traffic  User Level TrafficDashboard Metrics
Hyperledger Fabrictest-network-k8s (WIP, as application and couchdb) Tape Hyperledger Caliper (tbd)jmeter (tbd)  to be completed
Hyperledger FabricMinifab (tbd)…………
Hyperledger FabricHyperledger Bevel (tbd) …………
Hyperledger FabricHyperledger Cello (tbd)…………

Taking Hyperledger Fabric as a sample: we need to support different ways to deploy Hyperledger Fabric as a test network, including Kubernetes, Minifab, Hyperledger Bevel, Hyperledger Cello, etc.

Meanwhile, to fully support traffic generators, we need to go through different levels of traffic generators and complete a dashboard.

Want to get involved? 

Here are some places to connect with the code and the community:

  • Code repo: https://github.com/hyperledger-labs/PerformanceSandBox
  • Monthly meeting: https://wiki.hyperledger.org/display/PSWG/
Feb 28
Love0

#HyperledgerInterop: Delivering Cross-Chain Interoperability with Hyperledger Technologies

By Hyperledger Blog, Hyperledger Besu, Hyperledger Fabric, Hyperledger Labs

We kicked off #HyperledgerInterop month with Why is Interoperability Needed?, which explains the drivers for interoperating networks and then deep dives into the different Hyperledger technologies tackling the challenge. 

Below, we continue the conversation with highlights of some leading-edge efforts to deliver cross-chain interoperability built using Hyperledger technologies:

Cross-Ledger Interbank Settlement: As part of a series of wholesale CBDC trials, Banque de France, the French Central Bank, completed cross-ledger interbank settlement transactions in a multi-blockchain environment. Conducted in association with HSBC and IBM, this test case entailed the issuance and trading of digital bonds, settled instantly using CBDC. Transactions occurred across blockchain environments operated by HSBC for the custody of the assets and by the Banque de France for the securities settlement and the CBDC. In the trial, Hyperledger Fabric and R3’s Corda were able to transact with each other using Weaver, a Hyperledger Lab initially contributed by IBM. 

Digital Green Bond Project: The Bank for International Settlements Innovation Hub (BIS) Innovation Hub and the Hong Kong Monetary Authority (HKMA) set out to improve efficiencies in the distribution of green bonds and more insightful reporting on the environmental impact of projects supported by the bonds through Project Genesis. The aim is to develop digital platforms that will allow investors to buy and sell bonds that support green projects with real time access to both the financial performance of the bond and such metrics as clean energy created and O2 reduced by the investment. The first prototype from Project Genesis was developed with Digital Asset in partnership with GFT and leveraged Daml smart contracts as well as Digital Assets interoperability protocol layered over Hyperledger Besu and Hyperledger Fabric blockchains. It achieved real-time synchronization across these two ledgers while preserving the level of privacy demanded by regulated bodies. The prototype drives market efficiency with a unified view of the entire trade lifecycle and a single source of truth that automates market rules and adheres to market regulations.

Interoperable platform for international exchange of CBDCs: The BIS Innovation Hub, Hong Kong Monetary Authority, Bank of Thailand, People’s Bank of China, and Central Bank of the United Arab Emirates are working together on a prototype multi-CBDC platform for international payment that joins up national digital currencies on a common interoperable platform. During the Phase 2 and 3 explorations of the project, mBridge (formerly Inthanon-LionRock), they worked with ConsenSys on a Hyperledger Besu implementation that completed an international exchange of multiple CBDCs in seconds as opposed to several days and has the potential to reduce costs to users by up to half. 

Multichain Trade Settlement: In January, 2022, Tokio Marine & Nichido, NTT DATA, STANDAGE and TradeWaltz jointly conducted a demonstration experiment for a new trade settlement system in which electronic B/Ls (bills of lading) and digital currencies were exchanged simultaneously using two different blockchain networks. The simultaneous transfer of digital assets and digital currencies was conducted by Datachain with the cooperation of NTT DATA, and leveraged YUI, a Hyperledger Lab that was initially contributed by Datachain, to interconnect Hyperledger Fabric and Ethereum. Datachain successfully confirmed that two assets can be exchanged simultaneously by DVP settlement between digital assets on services built with Hyperledger Fabric and digital currencies on Ethereum.

Chime in on social to share other examples of #HyperlegerInterop.

Cover photo by Wilhelm Gunkel on Unsplash

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)



Dec 15
Love0

Hyperledger Mentorship Spotlight: Documentation and Use Cases for Climate Action

By Hyperledger Blog, Climate, Hyperledger Labs, Hyperledger Mentorship Program

The Hyperledger Mentorship Program is a structured hands-on learning opportunity for new developers who may otherwise lack the opportunity to gain exposure to Hyperledger open source development and entry to the technical community. These Mentorship Spotlights highlight the work done by the Mentors and the Mentees as part of their program participation. Learn more here.

 

Mentorship Project Title

Documentation and Use Cases for Climate Action

Description To improve documentation of the blockchain carbon accounting applications, including tutorials on how to develop and enhance the applications and use cases for the applications.
Status COMPLETED 
Difficulty LOW
Additional Details Learning Objectives, Expected Outcomes and Project Results available here.

Final Project Video

Mentee

Dounia Marbouh

Khalifa University

“The Hyperledger Mentorship Program was a great opportunity for me to grow and learn from others, especially my mentors. It is a chance to realize that in a world where many pieces of information can be simply “Googled,” there is still some knowledge that can only be gained through experience, and this mentorship program was the best example of that. Also, this experience focused on many competencies and talents, such as research, collaboration and communication, which are immensely invaluable. “

Mentors

Si Chen

Open Source Strategies, Inc.

Sherwood Moore

CA2 SIG Co-chair

Si Chen

“In this project, our different backgrounds came together to take us a lot further. We found out that the carbon credits and offsets market is much more complicated than originally anticipated. While many people want to use blockchains to improve the liquidity of the carbon credits market by making transactions more efficient, what the market really needs is greater trust in the quality of the credits and lower costs to bring them to market. We also learned that a successful mentorship is a partnership, where everyone—mentors and mentees—need to come prepared to both contribute and learn.”

Sherwood Moore

“I really enjoyed this opportunity to mentor, and I found that I learned from the experience as much as I shared my expertise. I really enjoyed being able to share from my experience conducting market research and identifying opportunities by tapping into the knowledge of the stakeholders within it. At the same time, it was really interesting to learn more about the voluntary carbon market, which was the focus of our research, as well as the world of academic publications, which was the end goal and deliverable of our work. All in all, a very successful internship project, and I look forward to participating in more.”

A special thanks to the Hyperledger member companies for funding this important program. To learn more about our Hyperledger Mentorship Program and how you can participate in our next cohort, head over to our program overview page on the Hyperledger wiki.

Dec 15
Love1

Hyperledger Mentorship Spotlight: Implement Client Side Security for Climate SIG Fabric Application

By Hyperledger Blog, Hyperledger Fabric, Hyperledger Labs, Hyperledger Mentorship Program

The Hyperledger Mentorship Program is a structured hands-on learning opportunity for new developers who may otherwise lack the opportunity to gain exposure to Hyperledger open source development and entry to the technical community. These Mentorship Spotlights highlight the work done by the Mentors and the Mentees as part of their program participation. Learn more here.

 

Mentorship Project Title

Implement Client Side Security for Climate SIG Fabric Application

Description To explore and implement an application with client side authentication for Hyperledger Fabric utility emissions data channel.
Status COMPLETED 
Difficulty HIGH 
Additional Details Learning Objectives, Expected Outcomes and Project Results available here.

Final Project Video

Mentee

Bertrand Rioux

King Abdullah Petroleum Studies and Research Center

“Climate side security involves moving private keys of users off Hyperledger Fabric network servers. To solve this problem, I built a custom identity provider type for Fabric using the WebSocket protocol. This required designing an identity server to create WS-X.509 certificates using secure asynchronous communication between a Fabric app and a user’s external keys. Learning how to build a custom crypto wallet app compatible with Fabric and contributing to active Hyperledger projects, including Hyperledger Cactus and the Blockchain Carbon Accounting Lab, were highly rewarding experiences. This mentorship project has helped accelerate my goal of building technology for climate action.”

Mentors

Si Chen

Open Source Strategies, Inc.

Kamlesh Nagware

Snapper Future Tech

Si Chen

“This mentorship started because we wanted to have our Hyperledger Fabric emissions accounting application authenticated at the client like other dApps. It went through several twists and turns as we tested different approaches. In the end, we came up with an elegant solution that could be used for mobile, IOT, and web apps. The mentoring process taught me more about how to bring more developers on board and listen to their input while still providing guidance on the direction of the project. This combination is very important in an open source, distributed development model.”

Kamlesh Nagware

“For this research project, which aimed to determine the right client side identity approach, we initially had something in mind like use TrustID but then turned to exploring Hyperleger Fabric off-line signing but for real client side identity model. Its very important to have a mechanism like Metamask in Ethereum. This was a really challenging project. Our mentee, Bertrand Rioux, put his research and experience with cryptography and client security to work in implementing this project. Special thanks to Pritam Singh, who is a mentee in another project, for joining hands to help build a more secure architecture design for the client security model in Hyperledger Fabric. Designing and adding WebSocket and supporting additional cryptography algorithms to the Hyperledger Fabric node SDK is the real achievement of this project.”

A special thanks to the Hyperledger member companies for funding this important program. To learn more about our Hyperledger Mentorship Program and how you can participate in our next cohort, head over to our program overview page on the Hyperledger wiki.

Dec 09
Love1

Hyperledger Mentorship Spotlight: Implement Two Compiler Passes for Solang Solidity Compiler

By Hyperledger Blog, Hyperledger Labs, Hyperledger Mentorship Program

The Hyperledger Mentorship Program is a structured hands-on learning opportunity for new developers who may otherwise lack the opportunity to gain exposure to Hyperledger open source development and entry to the technical community. These Mentorship Spotlights highlight the work done by the Mentors and the Mentees as part of their program participation. Learn more here.

 

Mentorship Project Title

Implement Two Compiler Passes for Solang Solidity Compiler

Description To implement two compiler passes for the Solang Solidity Compiler.
Status COMPLETED 
Difficulty HIGH 
Additional Details Learning Objectives, Expected Outcomes and Project Results available here.

Final Project Video

Mentee

Lucas Steuernagel

AERONAUTICS INSTITUTE
OF TECHNOLOGY

“After taking compilers and operating system classes at university, I wanted to work with something related to low-level computing. I enjoyed those subjects, and I found the mentorship as an opportunity to experience such areas. I gained  knowledge of compiler optimizations and learnt to analyze the trade off between design alternatives. The mentorship also paved the way for me to create new connections and to find job openings in low-level computing.”

Mentor

Sean Young

 

“I saw the Hyperledger Mentorship Program as an opportunity for someone to really make progress on an interesting idea that our work priorities don’t allow time for. I was hoping that this would make an exciting challenge and offer someone the opportunity to become familiar with Hyperledger and the Solang compiler. Lucas Steuernagel, the mentee this year, has a keen interest in compilers, and we had many interesting discussions regarding how to tackle the challenge. Lucas came up with a truly novel and innovative way to handle the task. It’s been a great success, highly enjoyable and rewarding. It has been fantastic to mentor and work with such young talent.”

A special thanks to the Hyperledger member companies for funding this important program. To learn more about our Hyperledger Mentorship Program and how you can participate in our next cohort, head over to our program overview page on the Hyperledger wiki.

1 2 3 Next

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