The Hyperledger Mentorship Program is a structured hands-on learning opportunity for new developers who may otherwise lack the opportunity to gain exposure to Hyperledger open source development and entry to the technical community. These Mentorship Spotlights highlight the work done by the Mentors and the Mentees as part of their program participation. Learn more here.
Mentorship Project Title
Support Clique Consensus for Besu on Blockchain Automation Framework
Description
To support the Clique consensus for Hyperledger Besu so that BAF can be used to deploy and operate a Hyperledger Besu network with Clique consensus. This will also include upgrading BAF to support the latest stable Besu version.
Status
COMPLETED
Difficulty
MEDIUM
Additional Details
Learning Objectives, Expected Outcomes and Project Results available here.
Final Project Video
Mentee
Roshan Raut
Pune Vidhyarthi Griha’s College of Engineering and Technology
“This Mentorship program gave me real-world software engineering experience. I’ve learned to dig and work on a large codebase. Write production-ready code. Figure out the specific code files and documentation that is required to complete the specific task. Regular mentor meetings and discussions helped me to plan my way and complete all the tasks on time. I am thankful to my mentor for understanding my capabilities and mentoring me throughout the program. Also, I’m thankful to the entire Hperledger community for such an amazing program. Open source is interesting, and I would like to be part of it even after the mentorship program.”
Mentor
Sownak Roy
Accenture
“Learner is one of my top strengths, and I also like to share the knowledge with other people. That is why I joined this program as a mentor. Also, I wanted to have more people contributing to open-source projects. The main highlight was when my mentee completed all the tasks and was able to deploy a Besu network. The most significant growth for my mentee was his ability to spin up a Cloud environment and then execute Ansible on the server. Lessons learned for me were to be patient and to explore multiple options of the execution environment. The most rewarding part of this experience is the knowledge that there is at least one additional person who will now contribute to the betterment of an open-source code.”
Hyperledger is once again sponsoring the annual AnitaB.org Grace Hopper Celebration as a way of supporting leaders and future women technologists in our global community. Hyperledger and the Linux Foundation are committed to supporting women-led initiatives centered around recruitment and engagement like AnitaB.org.
This year, Hyperledger is putting its resources behind Open Source Day (OSD), an all-day hackathon for participants of all skill levels to learn about open source while contributing to projects designed to solve real world problems. OSD will be held October 1 as part of this year’s Grace Hopper Celebrations (vGHC).
During OSD, the women taking part will spend the day diving into the open source world to level up their skills and start contributing code. Participants will work in groups and with the mentors for hands-on learning, tailored to their experience level.
Hyperledger is an official Open Source Partner Project for OSD and is teaming with maintainers from four Hyperledger projects to introduce participants to its diverse ecosystem. Maintainers from these projects will on hand as guides to both the Hyperledger technologies and the code contribution process:
Hyperledger Besu, an Ethereum client designed to be enterprise-friendly for both public and private permissioned network use cases;
Hyperledger Cactus, a blockchain integration tool designed to allow users to securely integrate different blockchains;
Hyperledger Indy, a framework that provides tools, libraries, and reusable components for providing digital identities rooted on blockchains or other distributed ledgers; and
For each of these projects, the maintainers have compiled an array of pull requests or tasks that are tagged as “Good First Issues” that participants can tackle as their initial code contributions to Hyperledger. These triaged, non-documentation requests include everything from bug fixes to enhancements to security plug-ins. For those who want to challenge themselves or move deeper into a project, the Hyperledger Cactus list is broken down based on level of experience:
We want to thank our maintainers Anastasia Lalamentik (FireFly), Grace Hartley (Besu), Justin Florentine (Besu), Linlu Liu (FireFly), Nicko Guyer (FireFly),Peter Somogyvar (Cactus), Renata Toktar (Indy), and Tracy Kuhrt (Cactus) for offering their time and expertise to OSD. They will play a vital role in welcoming the Grace Hopper community into the world of open source and setting them up for success as contributors to Hyperledger and other projects.
Minifabric is a Hyperledger Lab that makes setting up a Hyperledger Fabric network easy and fast. It also helps application developers with needed connection profiles and wallets when a Fabric network is up and running. Hyperledger Fabric has powerful capabilities, but there can be challenges with using it to deploy and implement a network, especially for those who are new to distributed ledgers or are used to other blockchain systems such as Bitcoin and Ethereum.
With the right tooling though, you can easily deploy Fabric networks, learn how Fabric works, understand the life cycles of Fabric artifacts and become an expert as a Fabric network administrator or chaincode developer. The Minifabric Lab was started with these goals in mind. allows you to easily setup a Fabric network, expand your network, install and upgrade your own chaincode, invoke transactions, inspect your ledger, and change configurations of your channel.
Minifabric comes as a 10-line bash script (for Linux and OS X) or 30-line batch script (for Windows) and is available on github.com under Apache 2 license. You can get started with Minifabric to start your Hyperledger Fabric journey by simply following this README.
Recent development work has also added the capability to deploy Hyperledger Fabric onto Kubernetes. In the past, one could use Minifabric to deploy and use Fabric in a Docker environment. Now, with this new added feature, you can deploy Fabric onto Kubernetes clusters such as IKS, GKE and AKS. The commands to accomplish this task are identical with the commands to deploy in a Docker environment, which makes a big difference in terms of using and learning Minifabric.
There are also already recorded videos that can help you learn to use Minifabric. Here’s a rundown of video resources and what they cover:
Minifabric Introduction and demo An overview of Minifabric and demonstration of how to develop go applications using these profiles and monitor the Fabric network using Hyperledger Explorer.
Quick Start How to use Minifabric to stand up a Fabric network and clean up
Channels How to create channels, join peers to channels, inspect and change channel configuration
Chaincode How to work with chaincode including install, approve, commit, upgrade, invoke and query
Policy and Organizations How to inspect and change endorsement policies, how to bring in new organizations and how to work with private data collections
Artifacts and VSCode Fabric Extension How to use VSCode Fabric extension to work with a production like Fabric network. Minifabric creates many files that help Fabric SDK users easily connect to a Fabric network.
Inside Minifabric How Minifabric executes various commands and how Minifabric is able to always keep up with the latest Fabric. Discusses how Minifabric was designed and implemented, its commands and parameters.
Get Involved
As an open source project, you are welcome to check out the code, submit your own contributions and connect with other people in the community. Check out the Minifabric repo on Github to learn more about how to get involved.
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.
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.
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.
As enterprises and organizations increase their adoption and deployment of blockchain technology and networks, the overall complexity of systems are growing exponentially. While it’s exciting to see the expanding reach of blockchain, it also creates a host of new requirements for cross chain and off chain sharing of data, transactions and more.
At Hyperledger Global Forum (HGF) 2020 in Phoenix, one group of developers got together to share their work and create a blockchain integration tool designed to allow users to securely integrate different blockchains. They brought their project to Hyperledger Labs and, within a few months, it was approved as Hyperledger Cactus.
During this year’s HGF, three new Hyperledger Labs that are each tackling elements of cross-chain or off-chain operations are making their debuts: FireFly, Weaver and YUI. Read on to learn more about Weaver.
Meet Weaver:DLT Interoperability
By Venkatraman Ramakrishna, IBM Research – India
We are excited to announce Weaver, a project that was incubated in IBM Research. Weaver is an architectural framework with a family of protocols that enables scalable interconnectivity and interoperability between distributed ledgers while preserving core tenets of decentralization and security. This framework was motivated by the fragmentation of the blockchain ecosystem, with different flavors of permissioned blockchain and distributed ledger technologies (DLTs) leading to the proliferation of independent networks managing processes of limited scope and keeping assets in silos. Weaver’s mission is to link processes and enable seamless but controlled flow of assets and data across network boundaries. It seeks to achieve this while maintaining the autonomy of the networks and the ledgers within and avoiding dependencies on trusted intermediaries.
Overview
Weaver is a general-purpose interoperability framework that provides a common set of capabilities for trustworthy information communication across ledgers, whether they belong to the same network or different networks running on different DLT stacks. Key principles that guide Weaver’s design are:
Accommodate DLT heterogeneity without favoring a particular DLT design
Allow networks to maintain their independence and collective sovereignty
Minimize coupling during cross-network interactions
Rely on common standards for cross-network protocol units
Do not require a trusted intermediary or third-party ledger
Do not require changes to existing DLT stacks
Make no security and trust assumptions on Weaver components
Treat privacy and least privilege as a first-class requirement
Weaver addresses three broad classes of use cases:
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.
Learn more about Weaver and other recent code contributions from IBM in this panel from HGF:
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 FireFly.
Meet FireFly
By Steve Cerveny, 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.
To jumpstart the community around FireFly, the contributors held a virtual event to introduce the Lab and demo its capabilities:
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.
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.
TrustOS and BoAT interaction diagram
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.
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):
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.
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 (seeperunpublications).
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.
