Hyperledger Labs Archives

Jun 09

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

Jun 09

Love0

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

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

Meet Weaver: DLT Interoperability

By Venkatraman Ramakrishna, IBM Research – India

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

Overview

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

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

Weaver addresses three broad classes of use cases:

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

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

The Weaver architecture has three major components underpinning it:

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

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

Hyperledger Labs Project

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

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

Jun 09

Love0

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

By Steve Cerveny, co-founder and CEO of Kaleido Blog, Hyperledger Labs

Meet FireFly

By Steve Cerveny is co-founder and CEO of Kaleido

Today, we are excited to introduce you to FireFly. FireFly is a multi-party system for enterprise data flows. It provides a purpose-built system upon which to build decentralized blockchain applications. Decentralized applications are a new category of business application. They bring with them a new set of challenges to successfully build and deploy.

In particular, multi-party data flows are complex and require significant plumbing – both cross-party and internally across the stack – to run securely and reliably at an enterprise grade.

Key Ingredients of a Multi-Party System

In our experience, consortia end up trying to build a multi-party system as a side effect of implementing their enterprise blockchain use case. This results in a large amount of “reinventing the wheel” and we’ve observed that most of the resources are spent on plumbing components.

At a high level, enterprise blockchain use cases attempt to coordinate data flows and transactions across disparate, separately owned systems (ERP, mainframe, commerce, etc.). To do this end-to-end, four things are required:

the single source of truth coordination system across parties
per-member plumbing software to enable reliable, private integration to and from the coordination system
cross-org plumbing software that provides robust cross-connectivity among members alongside (1) for use when the coordination system is not suitable or not preferred as the data flow mechanism. Examples include sensitive data, low latency messaging, and large data flows
a control plane to manage all of these runtime and configuration details

We formally define a multi-party system as the set of technology, infrastructure, and management capability to enable a consortium to build and deploy a use case that includes (1), (2), (3), and (4). We observe nearly all the real world consortia that we worked with over the last six years require all of (1), (2), (3), and (4) to build and deploy an enterprise blockchain use case. It is our observation that consortia spend most of their budget on (2) and (3).

Meet FireFly

Hyperledger FireFly brings together (1), (2), (3), and (4) to offer a pre-integrated set of runtimes via a highly pluggable framework. Note that FireFly is NOT attempting to replace or invalidate any specific runtime technology, but rather pulls together multiple complementary technologies into a coherent, larger system. Indeed, many of the infrastructure runtimes FireFly relies on are separate open source projects. Industry consortia globally have been using this technology to accelerate time to value for their production solutions.

Enterprise blockchains are purpose built to deliver (1) with invaluable attributes like global ordering and finality. FireFly will support Hyperledger Fabric, Enterprise Ethereum (such as Quorum and Besu), and will investigate Corda support. (1) also includes global storage providers such as IPFS. FireFly also provides a significant amount of technology for (2) and (3) including cross-party messaging, cross-party private document transfer, and event propagation. All of these runtimes and connectors into the FireFly node. For (4), Hyperledger FireFly also provides a network map and registry that unifies all of the identity and bindings information needed.

In a FireFly network, each member of the network deploys and runs one or more FireFly Nodes. Each Node consists of a FireFly Core application, as well as its dependencies. Each dependency is abstracted from the Core by a modular plugin system, so underlying technologies, such as the database for example, can be changed if necessary.

About the author:

Steve Cerveny is co-founder and CEO of Kaleido. Steve has over fifteen years of experience in emerging technologies building, launching and growing enterprise products in a variety of business and technical roles. Prior to Kaleido, he led product teams at IBM, spearheading the creation of over a dozen cloud services and managed a strategic portfolio of software products. Steve launched the industry’s first blockchain managed service, developing new commercial approaches to meet the unique enterprise demands for privacy and scalability. Steve holds his Bachelor’s and Master’s degrees in Computer Engineering from Case Western and an MBA degree from Duke University.

Feb 17

Love0

Full decentralization of Hyperledger Fabric through embedded IoT solutions

By Gary Xu, aitos.io and María Teresa Nieto, Telefónica Blog, Hyperledger Fabric, Hyperledger Labs

Almost a year ago, Telefónica brought TrustID to Hyperledger Labs as an open source project. Telefónica initiated development of TrustID to ease the management of identities across several blockchain networks. The initial idea of TrustID was to decouple the issuance of identities from their consumption and allow users to operate in some networks with credentials issued in others. In this manner, users shouldn’t need to hold a different set of credentials for each network or decentralized application they interact with.

Furthermore, TrustID provides the opportunity to decentralize identity in Hyperledger Fabric. When you deploy a blockchain network using TrustID, identities are organization locking and, therefore, they are centralized on the Certificate Authorities (CAs) that have issued them. Inside the network, several CAs can co-exist, but easy onboarding of new organizations is an unsolved problem that makes it very hard for the network to grow organically as new partners join. Initially, TrustID, as a first approach, solves this restriction of the identity management in Hyperledger Fabric. Furthermore it brings to this technology the chance to really enable a custom decentralized identity management.

As you scale up a deployment, adding many different organizations from different origins, many without trust relationships between them, this identity issue becomes much more serious and limiting between them. However, shifting to decentralized identity management ensures that a network is not dependent on the companies that are part of the solution, making it more resilient in the face of change and growth.

A clear example where we can appreciate these characteristics is the case of the IoT world. Use cases often include companies providing monitoring services with IoT devices, operators offering the communication network, and owners of the devices looking to apply the benefits of this technology to their blockchain-based traceability projects.

The identity management in IoT is a complex scenario that involves the provisioning of certificates in the device and the need to have a public key infrastructure. This process must be accomplished in a secure way, verifying the software in the factory. Once provisioned, the device is able to use its certificate to sign communications with the aim of demonstrating its identity.

However, it’s also known that sometimes the devices are limited in performance or storage. For example, they could be designed to write once in their memory in all their useful life so, if we need to change an identity because the blockchain network has changed, the device could be useless for a blockchain use case.

On the opposite, when the devices can write in their memory many times, the process of updating the firmware or any information stored on it securely is also a hard process. So, at the end, it’s a requirement to have a flexible management of the keys stored at first instance, which, thanks to TrustID, is possible.

Recently, aitos.io and Telefónica have collaborated on a PoC to integrate IoT technology with Telefónica’s TrustOS product. The goal was to use blockchain technology to perform interactions from the device to the ledger, provisioning the identity and the keys associated directly on the device.

aitos.io developed its blockchain application framework, named BoAT (Blockchain of AI Things), which is an IoT-device-oriented C-language client library for blockchain services, to enable IoT devices to access blockchain. In this PoC, BoAT running in a Fibocom FG150, a 5G blockchain module, helps a FG150-based IoT device access TrustOS services directly. So, as a result, it has been possible to create signed transactions on the device in order to be stored in the TrustOS platform, which is based on Hyperledger Fabric, without any intermediary.

The device manufacturer could register every device onto the TrustID service of TrustOS and write the unique DID allocated by TrustID into the device. When the device is powered on and connected to the network for the first time, BoAT, in the device, imports the device into TrustOS by signing its DID in a JSON Web Signature (JWS) message. In this way, the device, and not the application, is the custodian of the private keys that would be used to sign transactions.

BoAT also provisions the IoT device asset, as a digital twin, on the TrustOS Track service that offers all the traceability functionalities in order to give full transparency of the physical device. Then, the device comprising the BoAT-enabled 5G blockchain module can send periodic updates on its status (e.g., vehicle speed, heading, etc.) to TrustOS by composing additional JWS messages. All of this generates the possibility of offering, in a transparent way, the traceability of the data generated by the device.

In deployments with integrated BoAT technology, all the data the IoT device captures could be directly sent to TrustOS with a cryptographically verifiable DID identifying their origin. That is, not only the data integrity is assured by the Hyperledger Fabric blockchain under TrustOS but also the data provenance can be identified by TrustID. Tampered-resistant IoT data with identifiable origin builds a great value for the industry.

From the point of view of TrustOS, thanks to the implementation of the machine-to-machine interaction and how TrustID manages the authentication and access to the system, it’s possible to avoid unauthorized tampering or unexpected updates. As a result, it adds extra trustworthiness-proof beyond the standard KPI.

Cover image by Pete Linforth from Pixabay.

Jan 13

Love0

Introducing “Hyperledger In-depth: An hour with…”

By Hyperledger Blog, Hyperledger Fabric, Hyperledger Labs

2020 was the Virtual Year (although many of us would prefer if 2020 virtually never happened). So last March, as the world transitioned to its new virtual state, we launched our webinar series. In the 10 months since, we’ve learned quite a lot.

First, there is amazing content out there that is worth sharing. Our members gave some great talks, and the attendance was incredible. We were really able to make up for the lack of in-person conferences. Second, it didn’t take long for us all to get tired of being on Zoom. There are only so many waking hours in the day and, for many, 70% of those are spent on virtual meetings, many of which, let’s be honest, do not require our participation.

How do we get out of this seemingly impossible situation and help our community connect online in a meaningful way? We are introducing a new concept: “Hyperledger In-depth: An hour with… .” In this series, Hyperledger members share learnings from their projects and try to answer all the hard questions about the pains of working with DLTs. It is not yet another webinar: participants will be encouraged to take part, come with prepared questions and voice opinions. Expect live demos and tutorials, stories from the battle field and hopefully some heated discussions. Let’s get out of the Zoom fatigue and engage to share experiences and build a stronger community.

This is exciting! We do think that with more active, engaging conversations, you will find the meetings really useful. We hope you can help us by recommending the program to your friends and colleagues – the more people, the more opinions and the better the discussions! But that’s not all. We are also bringing some more international, non-American centric vibe.

Starting January 20, we will hold webinars in two time zones so that, if you are in APAC, you will still get a chance to participate live and join the discussion. Of course, as always, all sessions will be recorded and available in our VOD library. Finally, we will now be also providing non-English content. We want to celebrate the diverse and vibrant community we have. Some of our most active members are in South Africa, India and Russia We do not want to exclude anyone! It is the host that will decide what language they will be running the session in, and we will work hard to get the slides and summary of the session in English for all of us non-polyglots.

On January 20, come join us for the first session of the year, which will be devoted to discussing Scaling DLTs with the Perun Framework, led by Bosch. On January 27, ConsenSys will host part one of a mini-series on collaboration between the Ethereum and Hyperledger communities. The session, What is Ethereum for the Hyperledger community?, will be an AMA and a design thinking session.

The Hyperledger In-depth calendar will be very busy as we will continue to have two events a month. Every first Wednesday of the month you can tune in at 7pm UK/2pm EST/11am PST. On the third Wednesday of every month, join us at 10am UK/7pm Japan time. Below is a sneak preview of the plan for Q1 (it might change as we are still confirming hosts):

January 20: Scaling DLTs with the Perun Framework, an hour with Bosch
January 27: What is Ethereum for the Hyperledger community? (Part I), an hour with ConsenSys
February 3: Deployment and management of Hyperledger Fabric Networks – is it possible to make it client friendly?, an hour with Intellect EU
February 17: Did the Global Pandemic give SSI the push it needed?, an hour with Evernym.
March 3: Blockchain promised to protect Intellectual Property. Is it delivering?, an hour with IPChain

To register, make sure to check out the event page on our website and follow us on Twitter!

Dec 15

Love0

Blockchain Automation Framework – the journey

By Michael Klein, Architecture Lead for Accenture Blockchain & Multiparty Systems, with contributions from Priyanka Vats, maintainer and project manager for Blockchain Automation Framework Blog, Hyperledger Labs

In the early days and excitement of blockchain, we saw the proverbial ‘hammer looking for nail’ application of the technology across nearly every use case. With a few years behind us, we now see a maturity in the understanding of the technology and the use cases it can best address. The ecosystem has evolved, and we even see live production implementations with enhanced understanding of where blockchain is the best solution to the problem vs. where it is an overkill.

However, it is not wrong to say that the adoption hasn’t been anywhere near to what was predicted. There are some clear barriers that have hindered the adoption of blockchain. Let’s bring the focus on our own technology journey and barriers in adoption from a technology lens that led us to conceptualize and then bring Blockchain Automation Framework to Hyperledger Labs as an open source project.

Situation in 2018

In early 2018, we made a conscious decision to steer clear of the blockchain hype that filled news cycles and instead focus on development and architecture work. By this time, we had completed over 100 proof-of-concepts and pilots with customers, and the architecture challenges of security, scalability and performance had surfaced with these implementations. We had by then built a reference architecture that communicated the full suite of capabilities necessary for a full production scale implementation. We had also built deep knowledge in multiple platforms and implementing in mixed cloud and on-prem environments. But we knew we could do more to ensure consistency and speed for our customers.

Disruption, the need for a change

The need was acutely apparent. Various teams across the globe pursued their own disparate ways of architecting and implementing, thus reinventing the wheel. Our team at Accenture had yet to become a collaborative ecosystem where we could learn from others’ mistakes or follow best practices uniformly.

We also saw multiple projects (inside and outside of Accenture) attempt to automate DLT deployments. The complexity around setting up a network, deploying it successfully and ensuring that network is up and running with all nodes communicating to each other seemed to be a challenge for the developer community.

But each project within the blockchain ecosystem focused narrowly on their chosen DLT platform or cloud provider. Many focused only on quickly deploying development or proof-of-concept environments. Almost all wanted to commercialize their narrowly focused solution.

Outcome

We decided to start a project codenamed “Fulcrum” to simplify use of best practices and accelerate DLT deployments. Our vision was to bring down the technology barriers and thus drive adoption. From the very beginning we had open source in mind.

We decided on some principles:

Design for security: Keys and other credentials are not stored in source, configuration files, environment variables, or filesystems
Modular Design: In order to provide an “enterprise” version, we should ensure that we are providing interfaces for modules where we might want to plug in a different component
Conform to DLT Reference Architecture: When making decisions, conform to Accenture’s DLT Reference Architecture non-functional requirements and principles
Open Source Components: Ensure that we are using open source licensed products in our solution so that it may be contributed to Hyperledger, favoring Apache 2.0 licensed components
Infrastructure Independent: Choose tools and components that do not limit lock-in to an infrastructure configuration or cloud provider
Choose Tools with Internal Expertise: Choose tools where Accenture has internal expertise to support and maintain

We then wrote down the problems we needed to solve while complying with the principles:

How do we abstract the network complexities to let a developer majorly focus on application development?
How do we make it easy and consistent for the developers to deploy different blockchain networks?

How do we make it easy for the architects working on their first blockchain projects to design something secure, scalable, performing and easy to maintain?
How do we reduce the time taken in manual deployment from days to automated deployment in minutes?

Our customer conversations and Hyperledger community engagements helped us understand that these questions need to be answered not only at an organizational level but also at an industry/ecosystem level. For those familiar with building consortiums, it will be no surprise to hear that intellectual property concerns and fears of vendor lock-in can present major roadblocks in collaboration. Hence, we designed a solution that would not just accelerate adoption of the technology for Accenture customers, but would also be open source and accessible to all, simplifying the deployment of the technology and accelerating adoption for the entire market. It was renamed to “Blockchain Automation framework” from its earlier name “Fulcrum” before it was open sourced.

Now, as a Hyperledger Labs project, Blockchain Automation framework delivers automation for rapidly deploying production ready DLT platforms on a chosen cloud infrastructure. It consumes a single configuration file where we enlist all details such as the DLT platform of choice, cloud infra of choice, network details, the node details and application details etc. to deploy a working distributed network.

The architecture is basically an implementation of DLT reference architecture, hence conforming to best practices and providing a consistent mean to deploy regardless of cloud provider chosen, type of vault chosen and even the underlying DLT platform. Thus, making it easy for developers to focus on the application development.

With multiple client implementations we have found out that it has on an average reduced 80% on the deployment time required through the automation. A single deployment that would take sometimes a couple of days can now be done in hours if not minutes, thus significantly accelerating the project implementation time.

What next?

There are many blockchain-as-a-service (BaaS) solutions available across the market, from the major cloud service providers, to well-known software companies, to a host of new startups. Many of the solutions have been limited to a single cloud provider and/or a single DLT platform, and we see many are crossing the bridge in supporting multiple DLT platforms and interoperating across many clouds. We share this vision of a thriving community of BaaS providers built upon standards and interoperable platforms.

Unfortunately, that vision is not quite a reality in all places today, and we see the Blockchain Automation Framework as an excellent complement to the existing BaaS solutions, providing more deployment options across a multi-cloud landscape. This is just the beginning of the evolution of a project within the Hyperledger greenhouse that simplifies the accessibility of many multiparty system technologies and allows organizations to select the best platform for their specific needs, with the ability to change over time.

We welcome all suggestions, contributions and collaborations to take Blockchain Automation Framework to the next level. To learn more about the lab, check out our previous blog for a tutorial overview. Ready to get started? Please visit our landing page on Wiki to get all the details on how to collaborate with us.

Nov 18

Love0

Perun, a blockchain-agnostic state channels framework, moves to Hyperledger Labs

By Hendrik Amler, Lisa Eckey, Chris Hoeppler, Daniel Kunz, Manoranjith A P and Sebastian Stammler, Perun Team Blog, Hyperledger Labs

We are excited to announce that Perun, a joint DLT Layer 2 scaling project between the Robert Bosch GmbH’s “Economy of Things” project and the Perun team of Technical University of Darmstadt (TUDa), joins Hyperledger as a Labs project. The project’s goal is to make blockchains ready for mass adoption and alleviate current technical challenges such as high fees, latency and low transaction throughput.

The Perun Hyperledger Labs project implements cryptographic protocols invented and formally analyzed by cryptography researchers at TUDa and the University of Warsaw. Designed as a scaling solution, the Perun protocol can be used on top of any blockchain system to accelerate decentralized applications and lower transaction fees. The payment and state-channel technology of Perun protocol is especially useful for high-frequency and small transactions. By providing a cheap, fast, and secure transaction system, the Perun protocol is a major step forward in the mass adoption of blockchain applications.

Overview over the Perun Protocol

The Perun protocol allows users to shift transaction and smart contract execution away from the blockchain into so-called payment and state-channels. These channels are created by locking coins on the blockchain and can be updated directly between the users and without any on-chain interaction. This makes state-channel-based transactions much faster and cheaper than on-chain transactions. The underlying blockchain guarantees that all off-chain transactions will be enforced on-chain eventually. In comparison to other channel technologies like the Lightning Network, the Perun construction offers the following unique features:

Perun’s state-channel virtualization: To connect users that do not have a joint open state-channel, existing state-channels can be composed to form so-called virtual channels. These virtual channels are created and closed off-chain over the state-channel network intermediaries. Once opened, the virtual channel is updated directly off-chain between the two connected end users.

Blockchain-agnostic: Its modular design enables the flexible integration of Perun’s state-channel technology into any Blockchain or traditional ledger system.

Interoperability: The blockchain agonistic design and state-channel virtualization enable transaction and smart contract execution even across different blockchains (cross-chain functionality).

High security: The Perun protocol specifications have been mathematically proven using the latest methods of security research (see perun publications).

The Perun protocol can be used for a wide range of applications in different areas such as finance/FinTech, mobility, energy, e-commerce, telecommunication and any other use case where direct microtransactions are needed.

The Hyperledger Labs Project

As a first step, we are developing a secure and efficient standalone payment application within the Perun Hyperledger Labs project. The labs project currently consists of the following main parts that together form the Perun Framework:

perun-eth-contracts: Provides the Ethereum smart contracts required for implementing the Perun protocol.
go-perun: An SDK that implements core components of the Perun protocol (state-channel proposal protocol, the state machine that supports persistence and a watcher) and an Ethereum blockchain connector. It is designed to be blockchain agnostic and we plan to add support for other blockchain backends.
perun-node: A multiuser node that uses the go-perun SDK to run the Perun protocol and provides an interface for users to manage their keys/identities; off-chain networking; open, transact and settle state-channels.

The Perun framework is built with flexibility in mind and can be integrated into many different environments since most components, like networking, logging or data persistence, are interchangeable and use state of the art software architecture practices that ensure flexibility and crypto agility.

Since joining Hyperledger Labs, we’ve been very active developing the software and we have released the first couple of versions. At the current stage the following functionality is given:

Two party direct payment channels on ethereum
Fully generalized state channel functionality
Command line interface

Features on the roadmap — also depending on community response:

Virtual channels
SSI integration with Hyperledger Aries
Additional blockchain backends
Cross-chain channels

We are thrilled to be part of the Hyperledger community and are looking forward to your feedback and contributions. We are hoping to jointly build exciting projects on top of Perun to unleash its true potential and build towards a decentralized future. Check out the Perun Lab repositories to see the code and start contributing. Feel free to contact us through the Hyperledger channel #perun if you have any questions.

Jul 14

Love5

How to quickly deploy blockchain networks that can scale to production With Blockchain Automation Framework, a Hyperledger Lab

By Mike Klein, Global Blockchain & Multiparty Systems Architecture Director at Accenture, and Project Maintainer for Blockchain Automation Framework, a Hyperledger Lab, and Priyanka Vats, Business & Integration Arch Manager at Accenture, and Project Maintainer for Blockchain Automation Framework, a Hyperledger Lab Blog, Hyperledger Labs

One of the key deterrents in the adoption of blockchain/DLT today is that it is perceived as a complex technology, with a time-consuming network setup and operations. Accenture’s Future Systems research shows that, for companies across the world, the biggest barrier to innovation at scale is the ability to build flexible, uniform architectures capable of responding to market demands. This is in line with what we hear from our blockchain clients who want to know how to scale a blockchain trial to a production environment while safeguarding their investments.

The presence of a variety of enterprise DLT providers today such as Hyperledger Fabric, Hyperledger Indy, Hyperledger Besu, R3 Corda, Quorum and more, each with their own architecture and disparate services, compound the complexity in the world of DLT.

We get it. Getting started can be hard.

Setting up a new DLT network or maintaining an existing DLT network in a production-scale environment is not straightforward. For the existing DLT platforms, the steps in setting up one DLT network cannot be applied to others. When blockchain developers are asked to use an unfamiliar DLT platform, it requires a great deal of effort for even experienced technicians to properly setup the DLT network. This is especially true in large-scale production projects across multiple corporate environments more focused on other key aspects such as security and service availability.

Another problematic trend across many different organizations’ blockchain/DLT implementations is the PoC (Proof of Concept) first approach. While this is a sound way to test whether the technology can work, scalability and security are not part of the design at the outset, and so significant efforts are required to rearchitect and rebuild for production deployments.

Cloud vendors such as AWS and Azure offer managed blockchain services (aka Blockchain as a Service or BaaS) to help alleviate various pain points during the process of preparing a production-scale DLT network. However, these solutions have network size limitations, lock all nodes into a single cloud provider, or offer few choices for DLT platforms, which may be deal-breakers in some scenarios.

What if it didn’t have to be?

Imagine if the several weeks of development time required to set up and deploy a DLT network could be reduced to a matter of hours. What if the same framework developed for a PoC could scale to pilots and production, evolving along with the applied solution for faster innovation and more seamless innovation?

With these opportunities in mind, our team at Accenture Blockchain and Multiparty Systems started conceptualizing “Blockchain Automation Framework.” BAF helps developers rapidly set up and deploy secure, scalable and production-ready solutions that also allow new organizations to be easily onboarded on the network. BAF accelerates delivery and lets developers focus on building blockchain applications without having to waste precious time standing up the environment or worrying whether the network will scale and meet production requirements.

How does it work?

Using a single configuration file, you deploy the distributed network on a cloud infrastructure of your choice, including certificate management and smart contract installation. Whether developing an early stage PoC, late stage pilot, or scaling for production, Blockchain Automation Framework can reduce the time required to bring up the network from days to hours. The secure, fault tolerant framework helps to ease onboarding of new organizations and accelerate testing or production deployments in multicloud or multiparty systems.

Here is a quick look at the components and features BAF uses to automate network deployment:

Ansible playbooks and role definitions that follow a specific order to automate the entire DLT network setup
HashiCorp Vaults to securely store tokens, passwords and certificates
Kubernetes services, including Ambassador or HAProxy Ingress Controller, to route traffic and enable inter cluster communication
GitOps method for continuous deployment to Kubernetes clusters via Flux operator
Helm Charts for designing and configuring the architecture
The ability to share a configured network.yaml file without disclosing any confidentiality

Learn more with this video overview of the Blockchain Automation Framework:

Collaborate with us!

We are actively searching for potential contributors, maintainers, and partners who understand the value of Blockchain Automation Framework and share the vision of building and owning well architected solutions. We wish to work with the Hyperledger community to identify the needs and requirements of other network operators and to further reduce the barriers in blockchain adoption. As we roll out new features and further DLT platform support, all are welcome and encouraged to collaborate with us and share their feedback. Check out the source code and documentation on GitHub and please do bring technical questions to our Chat channel or join our open BAF meetings.

Jun 30

Love5

Telefónica TrustID, its decentralized Identity solution, moves to Hyperledger Labs

By María Teresa Nieto, Blockchain Technological Specialist at Telefónica Blog, Hyperledger Labs

Earlier this year, we wrote a post for the Hyperledger blog about how we were working in Telefónica to face the challenges of managing identities in a new and actually decentralized way. Based on the interest raised by this work, we proposed TrustID as a new project under the umbrella of Hyperledger Labs. TrustID was accepted and has moved to Hyperledger Labs so, from now on, the open source community will contribute to the evolution of the solution initially developed by Telefónica. The aim is to develop a new standard to simplify identity management in blockchain networks regardless of the underlying technology of the networks.

Over the past few years, we have witnessed the development and creation of digital identity solutions based on blockchain technology. However, most of these solutions are in silos, not interoperable, and dependent on the underlying technology.

The same credentials used to access your owned Bitcoins and manage your tokens in Ethereum should let you update the state of a Hyperledger Fabric asset. This is the rationale behind TrustID. In the end, the goal that we have set for TrustID is to create a cross-platform mechanism to manage one unique identity to have access to any blockchain. It doesn’t matter if the network you are operating on is based on Hyperledger technologies (Fabric, Besu, Indy, etc.) or other common blockchain technologies.

In Hyperledger Fabric, identities are centralized by the Certificate Authorities (CAs) that have issued those identities. Initially, TrustID implements identity management in Hyperledger Fabric as a decentralized alternative to CAs by using the DID standard specified by the W3C. However, we expect to make it compatible with more Hyperledger platforms like Besu or Indy and even other blockchain technologies other than Hyperledger ones.

Going into a deeper level, TrustID is made up of two components: (1) a library (SDK) that implements the management of a single identity and (2) a chaincode to implement this logic in the blockchain in a decentralized way. That single identity will be interoperable with other identities on different blockchain platforms wallets.

At Telefónica, we started TrustID as a module to make it easier to enable identity management for our product TrustOS. Beyond our product need, TrustID solved a common issue for many blockchain projects. We realized it could be more than a module and instead be a standalone project itself. As we shared this vision with other members in the community, we confirmed the interest in the TrustID approach for managing identities, so we decided the best way to make it really awesome was to open source it. Hyperledger Labs became the best option. In the roadmap, we are envisioning a compatibility of TrustID with the proposal of the Sidetree protocol and Verified Credentials from the DIF (Decentralized Identity Foundation), and its integration with other projects of the ecosystem such as Hyperledger Cactus, Indy and Besu.

We expect TrustID to grow thanks to its inclusion as an Hyperledger Lab. Last but not least, we’d appreciate any feedback and contributions from the Hyperledger community. We hope and believe that TrustID is the starting point to allowing a level of interoperability between blockchain platforms for identity management. And remember, TrustID is looking for your contribution…We want you!

Check out the TrustID lab here to see the code and start contributing.

May 14

Love4

New to the Hyperledger Labs: Pluggable Hedera Consensus Service

By Donald Thibeau, Director of Product Management, Hedera Hashgraph Blog, Hyperledger Labs

The Hyperledger Labs Stewards recently approved the Pluggable Hedera Consensus Service Hyperledger Lab. The Lab, developed by Hedera with input from Hyperledger Fabric community members and maintainers, enables a permissioned Hyperledger Fabric network to connect to the Hedera Consensus Service running on the Hedera public network.

For those unfamiliar, Hedera Hashgraph is a public distributed ledger network, operated by the Hedera Governing Council. Council members include Boeing, Deutsche Telekom, DLA Piper, FIS Worldpay, Google, IBM, Magazineluiza, Nomura, Swirlds, Swisscom Blockchain, Tata Communications, and Wipro. The Hedera network supports four publicly accessible network services: Cryptocurrency, File Service, Smart Contract, and the aforementioned Consensus Service.

The Hedera Consensus Service provides an Asynchronous Byzantine Fault Tolerant order of transactions that cannot be manipulated or crash due to the action of any small group of actors. Effectively providing your Hyperledger Fabric network with a verifiable auditable log of all transactions validated by an impartial decentralized network. The plug-in can also enable multiple Fabric networks to receive consensus timestamps from a single, decentralized ordering service.

The plug-in included in the Hyperledger Lab allows the Hyperledger Fabric BYFN (Build Your First Network) sample to connect each Fabric orderer to the Hedera Consensus Service. The orderers submit endorsed transactions to Hedera using the Consensus Service by referencing a common topic ID and independently subscribing to the stream of ordered transactions. The orderers then use the ordered transaction to create a block for their organization’s peer.

Any developer can get up and running with the Hedera Consensus Service today by following the instructions provided in the Lab’s open source GitHub repo: https://github.com/hyperledger-labs/pluggable-hcs/blob/master/first-network/README.md

It will require a Hedera testnet account, which you can sign-up for at http://portal.hedera.com/. The sample then configures the Fabric network dependencies, connecting the orderers to the public testnet.

We hope that the Hyperledger Lab is only the start of our journey in the Hyperledger community. We’d appreciate any feedback and contributions you have as we look to continue to support users of the Hedera Consensus Service building with Hyperledger Fabric. In the future, we hope to expand upon this plug-in with support for the likes of Hyperledger Avalon and the Blockchain Interoperability Framework.