KrypC builds award-winning taXchain for EU tax forms new case study >

Skip to main content
Hyperledger Foundation
search
Menu
  • Learn
    • Case Studies
    • White Papers
    • Training & Certification
    • Training Partners
    • Webinars
    • Research
    • Blockchain Showcase
    • Wiki
  • Use
    • Distributed Ledgers
    • Domain-Specific
    • Libraries
    • Tools
    • Tutorials
    • Hyperledger Certified Service Providers
    • Vendor Directory
  • Participate
    • Collaboration Tools
    • Contribute to Coding
    • Academic Collaboration
    • Find a Meetup
    • Regional Communities
    • Speakers Bureau
    • Join a Community Group
    • Labs
  • Events
  • News
    • Blog
    • Announcements
    • Newsletter
  • About
    • Join Hyperledger
    • Members
    • Leadership
    • Charter
    • Job Board
    • Contact Us
  • Join
  • English
    • 简体中文
    • Português
    • Français
    • Malayalam
    • 日本語
    • Español
  • search
Close Search
Category

Hyperledger Mentorship Program

Jan 25
Love0

Hyperledger Mentorship Spotlight: Solang Solidity Compiler optimizations and error handling

By Salaheldin Soliman Blog, Hyperledger Mentorship Program, Hyperledger Solang

What did you work on?

Project name: Solang Solidity Compiler optimizations and error handling

Introduction: What is Hyperledger Solang?

Hyperledger Solang is a Solidity compiler for Solana and Substrate written in Rust that utilizes LLVM as the backend. It can be considered the first solid initiative towards making Solidity available for non-EVM chains, while maintaining compatibility with Ethereum’s Solidity compiler: Solc.

Chapter 1: Applying for the Hyperledger mentorship

I found out through a friend that Hyperledger Foundation hosts mentorships for open-source projects related to blockchain infrastructure, which has been my main interest since it covers a whole lot of different Computer Science topics (Distributed systems, cryptography, networking, etc.). As I scrolled through the presented projects, I found a Hyperledger Solang mentorship project addressing three issues:

  1. Make multiplication overflow detection during runtime work above a certain bit-width.
  2. Improve the efficiency (gas cost or compute units) of array bounds checks.
  3. Improve Solang’s parser resilience. 

The first issue intrigued me personally. I was working on a De-fi app, using Remix Solc compiler version 0.7.6 that didn’t have runtime overflow checking. The lack thereof was causing a function to misbehave and consumed me a few valuable days to dig into the issue I was facing. The debugging process was captivating and motivated me to go further in understanding how overflow checking works. Although the problem was fixed on later versions of Solc, I saw in the mentorship an opportunity to improve my knowledge about the topic.

I contacted Sean Young and Lucas Steuernagel, the mentors, and discussed some questions I had about the compiler. They were really helpful along the way.

Chapter 2: Getting warmed up

I was new to contributing to open source, didn’t have any experience with Rust and didn’t use Git quite often 🙂 I spent the first three weeks of my mentorship exploring the source code and deciding on what issue to start working on. Since it would give me a broader idea of the code base, I started with the array bounds optimization, whose goal was to decrease the number of instructions when checking if an array indexation is done within its length limits. More details about my work are available both in Solang’s documentation and in the pull request that addresses this.

In my first pull request, my mentors pointed out issues on how I was solving the task and raised many problems with my Rust programming style. I was clearly struggling with it.  If you are learning Rust, do not take my approach of “learn by doing.” Please go to the Rust Book, read it, and try out the examples there. It will take some time in the beginning, but the examples will teach you the correct programming concepts. This is the only thing I regret not doing at the beginning of the mentorship. 

After that PR was merged, I took some time to read Understanding Ownership and Smart Pointers chapters in the Rust book. That improved my code over the following PRs.

Chapter 3: Multiplication Overflow Detection

The issue at the core of this project was that there was no multiplication overflow detection for integers wider than 64 bits. There are some facts to consider before solving such a problem:

  1. LLVM introduces a set of intrinsics for arithmetic operations. The catch here is that there are no intrinsics for multiplication with overflow for integers wider than 64 bits, so we have to implement our own.
  2. Solidity was designed for the EVM, which supports bit widths up to 256, and bit sizes of multiples of 8 (int128, int136, etc…). On the other hand, Solang compiles for BPF/WASM, and there is no inherent support for types bigger than 64 bits. 

Given these two facts, Solang handled multiplication of larger bit widths by first rounding the value to the nearest 32 bits, then splitting the operands bits into chunks of 32 bits and performing long multiplication.

The multiplication of N bit values will result in at most 2N bit values. So overflow checking was done by assessing whether the uppermost N bits contain any set bits, and raising a runtime error if there are any. Signed multiplication overflow was done first by doing unsigned multiplication, then checking the result for an unexpected change in the sign.

Solang interfaces with LLVM using Inkwell crate. Basically, all of the above was written as Rust code that generates LLVM-IR with the desired logic.

What did you learn or accomplish?

  1. If one is in a mainly learning position, a mentorship, do not pinpoint your vision on completing the task. Instead, take some time and do some background readings in order to tie stuff together. For instance, the aforementioned issue needs some background readings on LLVM, and why Solang used Inkwell instead of LLVM’s C API.
  2. One cannot develop resilient code without random testing.

Chapter 4: Improving Solang’s parser resilience.

Solang utilizes LALRPOP, a parser generator, for its parser. The problem was that once a parser or lexical error was found, the parser would throw an error and stop. If there are multiple errors in a Solidity file, the programmer will only see the first one.

I have utilized LALRPOP’s error recovery documentation to add new grammar rules to account for errors, in such a way that the parser returns multiple errors which makes coding easier.

Some messages for future mentees:

  1. When in daily/weekly meetings with your mentors, do not focus on reporting what you have done. Try to focus more on what they have done, even if you do not understand immediately or have nothing to add to the conversation. This will give you a broader vision of the project and its future plans, in addition to benefiting from their knowledge in the field.
  2. Do not take code comments personally. Remember that the goal is to learn from a more experienced person. They are criticizing your code, not you 🙂 It is also useful to review your own code multiple times before asking for reviews.
  3. You will grow muscles, as in becoming a better software engineer. You will know  how the open source community works and gain a new set of technical and communication skills.

What comes next? 

For the next six months, I will continue working on Hyperledger Solang through a Web3 Foundation grant with a focus on improving the Solang developer experience. Also, my team and I will continue our thesis project (a cross chain wallet), making sure it is production ready by the end of the next Spring semester. For the long term, I will continue working on blockchain infrastructure-related projects.

Jan 25
Love0

Hyperledger Mentorship Spotlight: GVCR: Secure Verifiable Credential Registries (VCR) for GitHub & GitLab

By Sarvesh Shinde Blog, Hyperledger Aries, Hyperledger Indy, Hyperledger Mentorship Program, Hyperledger Ursa, Identity

What did you work on?

Project name: GVCR: Secure Verifiable Credential Registries (VCR) for GitHub & GitLab

My name is Sarvesh Shinde and this is my personal blog that I’m writing to share my experience of working on the GVCR Project. A little background about the project is really necessary to fully appreciate the objectives of this project. 

Self-Sovereign Identity (SSI) is a digital identity management model in which an individual or a company has the exclusive ownership over their accounts and personal data. A verifiable credential protocol, in turn, forms one of the three pillars of Self-Sovereign Identity, along with the Decentralized Identifiers protocol (DIDs) and Distributed Ledger Technology (or blockchain).

This project was conceptualized to provision secure verifiable credential registries that utilize Github’s data model and API to offer exactly the same APIs for any other verifiable credential registry. This project exists as an extension to the DRMan project.

The DRMan project, inspired by the SDKMan, acts as a tool for managing multiple versions of different software development libraries. These libraries form the necessary dependencies for the extended feature modules that reside inside DRMan, including GVCR.

What did you learn or accomplish?

GVCR, along with DRMan, is a command line utility. This project has been entirely written in shell script. Shell script has a distinct advantage of making the tool light weight, easy to install and to use.

As of now, GVCR has been provisioned to utilize Github and Gitlab as its two git based registries. The plugin architecture of GVCR allows it to provision for more VCRs in the relative future. The APIs of these individual git based registries are designed to be a collection of facade functions that provide the same feature on the surface, all the while accommodating for the individual data models of the specific registry under the hood.

GVCR can be utilized in an Hyperledger Aries Framework as an implementation of VCR and collaborates with existing Agent and Wallet open source projects in Hyperledger Aries. It can also be used in Hyperledger Indy projects by providing endpoints of cryptographic verifications for credential issuers.

In near future, GVCR is envisioned to leverage Hyperledger Ursa to implement encryption, decryption and verification functions for verifiable credentials.

I was responsible for the design and implementation of this very GVCR module.

Now coming to the topic of the mentorship program itself, let me give you a rundown of its structure, working mechanism and decision making process. This mentorship was a careful balance of a hands-off approach towards the design planning and realization part that I undertook and the existence of biweekly meetings that acted as an efficient feedback mechanism from the mentors. These biweekly meetings were really efficient in setting the tempo of the progress and made sure that all the involved participants were aware of their individual tasks at hand.

The mentorship started on June 1st and continued until November 16th. Further, the mentorship was broken into two halves. In general, the first half was more focused on the design aspect of this project while the second half came down to its implementation.

What comes next?

Overall, this mentorship has been a wonderful experience and has enabled me to pursue my career in blockchain. The future of a secure, verifiable digital identity and its co-operability with a decentralized ledger brings a new outlook to the future of digital identity and just how important its acceptance is to finally realizing the ultimate goal of exclusively owning our own identities. New technologies are constantly coming up to make this future a reality, and I’m looking forward to contributing my part towards it.

Jan 20
Love0

Hyperledger Mentorship Spotlight: Blockchain Network Operation in a Decentralized Way

By Xichen Pan Blog, Hyperledger Cello, Hyperledger Mentorship Program

What did you work on?

Project name: Blockchain Network Operation in a Decentralized Way

My Hyperledger Foundation mentorship project, which focused on Hyperledger Cello, gave me the opportunity to work on the development of an operational dashboard for deployed blockchains. Our goal was to make it easier for users to create, manage, and use blockchains, and to reduce the difficulty and complexity of these tasks.

Blockchain technology has the potential to revolutionize a wide range of industries, from finance and healthcare to supply chain management and beyond. However, for many users, the complexity of blockchain systems can be a barrier to entry. Hyperledger Cello aims to change that by developing an easy-to-use operational dashboard that allows users to manage their blockchain networks more flexibly and safely.

What did you learn or accomplish?

During my time on the project, I was fortunate to have Baohua Yang and Yang Feng as my mentors. Under their supervision, I implemented the backend APIs for node operations in the blockchain network using Django and also developed the frontend UI for channel and node operations. In addition to these technical contributions, I also became familiar with the Hyperledger Cello deployment using Docker through editing, enriching, and fixing the current project documentation. These efforts will help to make Hyperledger Cello more user friendly and easier to use.

In addition to the technical skills I gained during my work on Hyperledger Cello, I also had the chance to learn more about the broader context of blockchain technology and its potential to solve real-world problems. I was able to see firsthand the benefits of a decentralized, transparent, and secure system for storing and sharing data, and I am excited to continue exploring the possibilities of this technology.

What comes next?

Looking ahead, I plan to continue contributing to Hyperledger Cello and to learn as much as I can about blockchain technology. I am also interested in finding a job that is related to cryptocurrency and blockchain, where I can use my skills and knowledge to make a positive impact. Hyperledger Cello is making great progress, and I am proud to be a part of the project. I am looking forward to seeing what the future holds for this exciting technology and its potential to transform industries and solve complex problems.

Jan 20
Love0

Hyperledger Mentorship Spotlight: Optimizing the pipelines using Github Actions for Caliper and Caliper-Benchmarks

By Rinish Sam Blog, Hyperledger Caliper, Hyperledger Mentorship Program

What did you work on?

Project name: Optimizing the pipelines using Github Actions for Caliper and Caliper-Benchmarks

Hyperledger Caliper is a general-purpose benchmarking tool for distributed systems like DLTs with scalable workload generation, declarative workload definitions and comprehensive data analysis capabilities. The Caliper and Caliper-Benchmarks repositories had build systems to verify pull requests by running unit and integration tests and to deploy the latest packages to NPM and DockerHub. The objective of the project was to optimize the pipelines and reduce the build times to improve the experience of developers contributing to Caliper. The project was split into three phases:

  1. Migrate the Caliper repository from using Azure pipelines to GitHub Actions.
  2. Optimize the builds for Caliper and Caliper-Benchmarks.
  3. Enhance the builds of Caliper and Caliper-Benchmarks with new features.

I would like to thank my mentor David Kelsey from IBM for the guidance throughout the mentorship project.

What did you learn or accomplish?

Project-related learnings:

  • I developed  a good understanding of how Hyperledger Caliper works and, in general, how a benchmarking system is designed.
  • I explored various ways of setting up a Hyperledger Fabric system from scratch.
  • I learnt about various techniques to write unit tests in JavaScript.
  • I explored various approaches for collecting metrics from a distributed system.

Miscellaneous learnings:

  • I learnt about effectively breaking down a project into tasks and tracking them.
  • I gained a lot of insight into the inner workings of Hyperledger Fabric from the discussions with my mentor.
  • I got to discuss the recent developments in Fabric and the Fabric ecosystem with my mentor.

Accomplishments:

  • The Caliper repositories no longer depend on Azure pipelines.
  • The repository was migrated from lerna to NPM workspaces.
  • The total time taken for the build pipelines were reduced by 60%.
  • The pipelines only execute the tests of components that have been modified by a pull request.

The improvements in build times throughout the project:

What comes next?

In terms of the project,

  • The build times could be further reduced by switching to a lightweight Hyperledger Fabric deployment like Microfab.
  • Other miscellaneous improvements to the repository workflows like Dependabot could be integrated.

Personally,

  • I plan on continuing to contribute added features to Hyperledger Caliper. I started working on new features towards the end of the mentorship.
  • I also plan on being active in the Hyperledger community, attending various contributor meetings.
Jan 18
Love0

Hyperledger Mentorship Spotlight: Enable Kubernetes Operators support for Fablo

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

What did you work on?

Project name: Enable Kubernetes Operators support for Fablo

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

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

Example of a fablo-config.json file

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

What did you learn or accomplish?

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

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

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

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

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

What comes next?

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

Jan 18
Love0

Hyperledger Mentorship Spotlight: Technical Deep Dive Workshop Content Creation for Hyperledger Cactus 

By Mónica Gomez Blog, Hyperledger Cacti, Hyperledger Mentorship Program, Interoperability

What did you work on?

Project name: Technical Deep Dive Workshop Content Creation for Hyperledger Cactus 

My work on the Technical Deep Dive Workshop Content Creation for Hyperledger Cactus mentorship project was focused on delivering a three-hour long course in both English and Portuguese on the Hyperledger Cacti tool. This pluggable blockchain interoperability framework was recently merged from Hyperledger Cactus and Weaver, a Hyperledger Lab, and it enables a link between networks built on heterogeneous distributed ledgers. With its architecture, Cacti allows for a flexible and extensible development environment for DTL solutions.

Developing the workshop required a vast study of the background technology and the tool itself as well as how it connected to other projects of the Hyperledger ecosystem. I must thank my mentors, Peter Somogyvari and Rafael Belchior, for guiding me in my study of the technology and Cacti implementations. They were valuable resources for helping me construct content that will help the Hyperledger community to understand the Hyperledger Cacti tool better and more easily integrate it in their endeavors.

What did you learn or accomplish?

During my mentorship project, I had the opportunity to engage Hyperledger Cacti developers, allowing me to study and contribute to a highly organized and optimized repository. It taught me how work is done in a fast-paced, open source environment and how all the pieces are carefully thought through and put together. It was truly exciting to be working with cutting-edge technology in the blockchain industry and see the efforts being made by the Hyperledger community to assure that it is accessible and helpful in shaping the technology’s future.

What comes next?

After this experience, I certainly hope to work with blockchain in my future career. I’ll take this experience in open source blockchain development and apply it to my master’s degree thesis and personal projects. It will be a great contribution to the start of my career, both technical and community wise.

Jan 13
Love0

Hyperledger Mentorship Spotlight: Developer Marketing

By Parveen Karjiker Blog, Hyperledger Mentorship Program

What did you work on?

Project name: Developer Marketing

Objective: To create a developer marketing program

Impact: We hope that attracting more people who will contribute to blockchain will not only grow the community but also improve our collective understanding and ability to apply the technology across industries.

What did you learn or accomplish?

The mentorship project started with researching and understanding Hyperledger Foundation, its ecosystem and marketing and communications maps and channels as well as reviewing the marketing strategy.

We created developer and member personas. I was fortunate to be able to participate in the Blockchain Hackathon in Paris and was able to use my contacts to understand more about developers. We also created a persona messaging grid to deep dive into the personas.

Towards the end, we created a marketing campaign targeting a developer community of 30 million. The campaign leveraged the fact that developers tend to game and, similarly, gamers make great developers.

My mentor was Ben Thomas, Hyperledger Foundation’s Marketing Manager.

What I really appreciated about Ben is that I always found it easy and fun to engage with him, even at times when I knew his schedule was jam packed and stress levels were running high.

He shared the ins-and-outs of marketing, introduced me to Hubspot, and guided me through all the deliverables while providing valuable feedback in the process. He had a great mentorship style in which he would share a process or brief and then let me take ownership of it, guiding me as required.

Ben also recommended a book, Jono Bacon’s “People Powered,” which describes how communities can supercharge your business, brand, and teams. I thoroughly enjoyed it, and we spoke at length about the content and shared our insights.

In one of our sessions, Ben had arranged for Hyperledger Foundation Executive Director Daniela Barbosa to join us. What a remarkable woman! On review of the Developer personas that I had created, she challenged my assumptions that all the developers were male. It highlighted a bias I did not realize that I had.

What comes next?

I am in the middle of my MBA, so I plan to continue with classes after the New Year. In the not-too-distant future, I hope to use blockchain technology as a tool to improve health care for everyone.

Jan 13
Love0

Hyperledger Mentorship Spotlight: Support NFT standards in Weaver for cross-network asset operations

By Micky Yun Chan Blog, Hyperledger Besu, Hyperledger Cacti, Hyperledger Mentorship Program, Interoperability

What did you work on?

Project name: Support NFT standards in Weaver for cross-network asset operations

Mentors:
Dhinakaran Vinayagamurthy, IBM Research
Venkatraman Ramakrishna, IBM Research
Krishnasuri Narayanam, IBM Research
Sandeep Nishad, IBM Research

The aim of the Weaver lab (a Hyperledger lab this now part of Hyperledger Cacti) is to ensure smooth interoperability of assets between blockchain networks. During this mentorship, I had the pleasure of implementing different ERC asset standards interoperability for Weaver with the possibility to ensure future interoperability. 

The three token standards are ERC-20, ERC-721 and ERC-1155. ERC-20 are the most common fungible token standard, while ERC-721 is standard for non-fungible token commonly known as NFT. ERC-1155 is a hybrid standard of ERC-20 and ERC-721. ERC-1155 acts like a token factory that allows you to create multiple tokens in a single smart contract. 

There are three main components for weaver-interoperability for Hyperledger Besu. 

  • Besu-SDK
  • Solidity contract
  • Besu-CLI

Protobuf implementation in interoperability contract:

In order to support protobuf, we decided to use the Solidity protobuf library. It is a library that can automatically generate encoder and decoder for serialized protobuf messages in Solidity. Then we ran into the issue that converting types is difficult for Solidity. In the end, we used assembly in Solidity to convert strings to address, etc. This is far from optimal, but we did it as a tradeoff between using more gas and interoperability. 

Implementation of scalability in interoperability contract:

In order to ensure ease of implementation and future standard interoperability, an interface has been defined for which every standard has to extend it. This ensures the interoperability contracts can handle any future standard. The interoperability interface consists of two functions: approve and transfer. The interface uses the token contract as an intermediate to transfer assets between users and manage asset contracts. The motivation behind is to ensure compatibility with any asset type. In other words, the interoperability contract can handle any asset if they implement such an interface.

Other implementation:

Update in BESU-CLI and BESU-SDK and additionally testing for ERC20, ERC1155 and ERC721.

What did you learn or accomplish?

During this mentorship I have learned that there are many design tradeoffs such as the one we made in the implementation of the interoperability contract. While one protobuf message can adapt to different and future asset standards due to compatibility issues, three different types of protobuf messages are used. Moreover, I learned how to use protobuf as an exchange format.

What comes next?

There are things that could be refactored in the interoperability Solidity contract. For example, currently three different types of protobufs (Non Fungible, Fungible, Hybrid) are being used in the lockAsset function. Ideally, we could use a single type of protobuf for this purpose, but, in order to use this, we need to update protobuf in other types of blockchain such as Hyperledger Fabric and Corda. Additionally asset exchange tests between Corda, Hyperledger Besu and Hyperledger Fabric could be set up.

Jan 11
Love0

Hyperledger Mentorship Spotlight: Upgrade Fabric network from 1.4.x to 2.2.x using Hyperledger Bevel

By Mohit Vaish Blog, Hyperledger Bevel, Hyperledger Fabric, Hyperledger Mentorship Program

What did you work on?

Project name: Upgrade Fabric network from 1.4.x to 2.2.x using Hyperledger Bevel

Objective:

Hyperledger Bevel is an automation framework for rapidly and consistently deploying production-ready DLT platforms. This mentorship project enhances Hyperledger Bevel to perform a live upgrade of a Hyperledger Fabric network from version 1.4.x to 2.2.x and provide an operations guide to perform the steps. This project uses Ansible, Kubernetes, Helm, Hashicorp Vault and Hyperledger Fabric. 

My mentors for this project were Sownak Roy and Jagpreet Singh Sasan. Their support and guidance has been immensely helpful for implementation of this project. 

This development work has automated the steps to upgrade the Hyperledger Fabric network, which shall increase the productivity to carry out such upgrades.

What did you learn or accomplish?

Learnings:

Before the start of this project, I had a basic understanding of setting up a Hyperledger Fabric network using Docker Compose. Hyperledger Bevel provided insights on how to automate and set up a production grade Hyperledger Fabric network on Kubernetes platform in various cloud providers.

I learned how Ansible, Helm charts and Flux are tied together for this implementation. Ansible does the automation for deployment pipeline, Helm charts are the reusable packages for Kubernetes components, and Flux implements the GitOps model so that current Hyperledger Fabric Network state is available for the operator.

Accomplishments:

My mentors validated my approach and provided feedback. I learned about multiple orderer organizations in a Hyperledger Fabric network and improved the upgrade automation for such scenarios. I was able to set up the network in a local minikube environment and will be updating the Hyperledger Bevel documentation for the same. This will provide new developers who do not have a cloud Kubernetes environment to set up and learn Hyperledger Bevel.

The code can be accessed here.

The documentation is available at this link.

What comes next?

I worked primarily on SharePoint development during my career but last year started looking into blockchain technologies as it provides immense potential to bring trust to the internet. There are so many use cases in real-life scenarios that ultimately can be solved by these technologies

The productivity that blockchain solutions bring to the table will be a win-win solution for enterprises as well as customers. This is an evolving technology that is community driven and, being open source, provides opportunity for all to learn and contribute. This mentorship program provided me a similar opportunity and now, along with Linux Foundation certification, my work is noticed by employers. I wholeheartedly thank my mentors and Linux Foundation for this opportunity and wish to keep contributing to this ecosystem.

Jan 11
Love0

Hyperledger Mentorship Spotlight: Fabric-Ethereum token bridging

By André Augusto, Ph.D. Student, Instituto Superior Técnico, Lisbon, Portugal Blog, Hyperledger Besu, Hyperledger Cacti, Hyperledger Fabric, Hyperledger Mentorship Program, Interoperability

What did you work on?

Project name: Fabric-Ethereum token bridging

Main objectives:

  1. Review cross-chain bridges state of the art.
  2. Study and develop chaincode and smart contracts following ERC standards.
  3. Prototype a cross-chain bridge between Hyperledger Fabric and EVM-based blockchains. Hyperledger Technologies: Hyperledger Fabric, Hyperledger Besu, Hyperledger Cactus.

Mentors:

  1. Imre Kocsis, assistant professor, Budapest University of Technology and Economics (BME), Budapest, Hungary.
  2. László Gönczy, assistant professor, Budapest University of Technology and Economics (BME), Budapest, Hungary.

Impact yielded from work:

This work constitutes an add-on to the existing efforts to enable interoperability between permissioned networks. Moreover, we contribute to the community by developing a cross-chain bridge between Hyperledger Fabric and EVM-based blockchains using the Secure Asset Transfer Protocol (SATP), a protocol under standardization at the Internet Engineering Task Force (IETF).

What did you learn or accomplish?

Deliverables:

  1. Create a report on blockchain interoperability solutions.
  2. Design a cross-chain bridge between a Hyperledger Fabric and a Hyperledger Besu network.
  3. Implement a prototype of the designed cross-chain bridge solution in Hyperledger Cactus.
  4. Develop an academic paper.

Issues overcome:

  1. At the beginning there were a lot of unknowns: a new area, protocols, and new technology. After all, I am glad about the final product and all the lessons learned.

Lessons learned and advice:

  1. The community is here to help. We had fruitful discussions with various members of the Hyperledger community, which proved to be valuable for the final project.
  2. The best is always yet to come. Believe me when I say things will always be better than they are at the moment — bugs appear, and sometimes we need to take a step back to take two steps forward.

Exciting technology:

  1. Hyperledger Fabric was considered the most adopted enterprise blockchain solution.
  2. Hyperledger Cactus provides the building blocks for interoperability.
  3. The integration of Self-Sovereign Identity (SSI) with interoperability solutions seems to be the way forward to perform identity management.

What comes next?

  • The addition of SSI in our work seems a good next step as a way to remove some assumptions made in the solution design.
  • I envision to continue working and advancing the existing interoperability research. I aim to continue contributing to Hyperledger Cactus (now Hyperledger Cacti), the Hyperledger project directed toward interoperability.
1 2 3 … 6 Next

Copyright © 2022 The Linux Foundation®. All rights reserved. Hyperledger Foundation, Hyperledger, and the other Hyperledger Foundation trademarks are trademarks of The Linux Foundation. For a list of Hyperledger Foundation trademarks, please see our Trademark Usage page. Linux is a registered trademark of Linus Torvalds. Privacy Policy and Terms of Use.

Close Menu
  • Learn
    • Case Studies
    • White Papers
    • Training & Certification
    • Training Partners
    • Webinars
    • Research
    • Blockchain Showcase
    • Wiki
  • Use
    • Distributed Ledgers
    • Domain-Specific
    • Libraries
    • Tools
    • Tutorials
    • Hyperledger Certified Service Providers
    • Vendor Directory
  • Participate
    • Collaboration Tools
    • Contribute to Coding
    • Academic Collaboration
    • Find a Meetup
    • Regional Communities
    • Speakers Bureau
    • Join a Community Group
    • Labs
  • Events
  • News
    • Blog
    • Announcements
    • Newsletter
  • About
    • Join Hyperledger
    • Members
    • Leadership
    • Charter
    • Job Board
    • Contact Us
  • Join
  • English
    • 简体中文
    • Português
    • Français
    • Malayalam
    • 日本語
    • Español