Hyperledger Labs

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

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

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

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

New to the Hyperledger Labs: Pluggable Hedera Consensus Service

By 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: 

It will require a Hedera testnet account, which you can sign-up for at 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.

Accenture Open Sources Blockchain Integration Framework as a Hyperledger Lab

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

High-Level Workflow

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.