Hyperledger Labs Archives

Feb 17

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.

Nov 20

Love0

Accenture Open Sources Blockchain Integration Framework as a Hyperledger Lab

By Tracy A. Kuhrt, Senior Technical Architect, Accenture Blog, Hyperledger Labs

The growth in the number of blockchain platforms is booming. That is a good thing. Looking beyond a “one size fits all” platform sparks new possibilities and may lead to platform innovations we have yet to imagine. But the ecosystems developing around platforms must also interact for blockchain to achieve its full potential.

With the future state of interoperability as an end goal, last year Accenture announced that we developed and tested two solutions that allow two or more blockchain enabled ecosystems to integrate. Since then, we developed a new solution specifically created for permissioned blockchains that works without a central connector node. I am happy to announce that we open sourced this new solution as Blockchain Integration Framework, a Hyperledger Lab.

Blockchain Integration Framework defines a communication model that lets permissioned blockchain ecosystems exchange any on-chain data or custom assets, independent of the platform. Specifically, it introduces an “interoperability validator” overlay network for each of the blockchain networks for which you want to exchange assets. Interoperability validators are known or broadly discoverable by the ecosystem and typically participants already taking part in the governance or consensus.

Interoperability validators will collectively handle export requests from local nodes by verifying against their version of the ledger (steps 1 to 3). Each request is answered by a (configurable) minimum quorum of validator signatures (steps 4 and 5). The network can continue working even if some validators are down or not participating, assuming the minimum quorum can be guaranteed. Any secure off-chain communication system can deliver messages certified by a distributed ledger’s transfer validators (step 6). A proof coming from a foreign distributed ledger can be verified against the public keys of the transfer validators of that foreign distributed ledger either locally by the recipient or using on-chain logic – typically smart-contracts (step 7 and 8).

This tutorial demonstrates how to transfer a simple asset between a Hyperledger Fabric and a Quorum network. If you have a favorite DLT network, please consider contributing a connector. We encourage you to have a look at the source code and welcome any contributions no matter the size. Please reach out on the #blockchain-integration-framework chat channel with any questions.