Some years ago, researchers realized that IoT devices would need to buy and sell from one another. In this “Economy of Things,” the items to be traded will include power, data, and connectivity. Most transactions will be fast, low value, and high frequency.
For a company like The Bosch Group that’s active in everything from autonomous vehicles to thermal plants, the Economy of Things will touch many lines of business. That’s why, in 2017, the company’s advanced research group, Bosch Research, was looking to find a way to scale up blockchain transactions to support the Economy of Things.
Bosch set out to do meet that requirement by leveraging a specific, step-by-step open source strategy for developing new markets:
Identify a requirement
Set goals
Consider the terrain
Build a partnership
Pick a suitable license
Use open source archetypes
The goals were to lead an effort to create standards for the Economy of Things and to build a framework where different partners could work together.
A survey for likely partners led the Bosch team to Perun, an early layer-2 protocol that passes state information off-chain through virtual channels. Bosch joined forces with several academics to implement this protocol and start creating an ecosystem.
As part of the process, Perun needed a stable home where everyone could access the latest code, and other people could find it. Hyperledger Labs provides a space where developments can be started without the overhead of creating an official Hyperledger project.
In Q3 2020, Perun was welcomed into Hyperledger Labs, and development has continued with work from the team at Boch and PolyCrypt GbmH, a startup spun out of the Technical University Darmstadt, where much of the academic research behind Perun began.
The Bosch team was eager to talk about its approaches and contributions to Hyperledger Foundation. To that end, they worked with Hyperledger marketing and others in the Perun community on a case study that details not only the business and technology challenges they’ve set out to tackle but also the strategic way they are leveraging open source development to advance the industry for all.
We never know what technology will turn into the Next Big Thing.
Perhaps Perun will be one of them, powering billions of micropayments between IoT devices or enabling people to shop with Central Bank Digital Currencies (CBDCs) that are still on the drawing board today.
2021 was an eventful year for the Hyperledger Lab Perun, which is maintained by PolyCrypt GmbH and Robert Bosch GmbH’s project “Economy of Things.”Below we summarize developments and achievements for the project and the growing network surrounding it. We also provide a brief outlook on what’s to come in 2022.
This Hyperledger Lab aims at establishing an open-source project based on Perun channel protocols, which is a technology for scalability and interoperability of blockchains. The core components are the Go-Perun SDK and the Perun Node.
New features in Go-Perun SDK & Perun Node
Virtual channels: The SDK now supports virtual channels. This allows opening channels with funds from other channels and therefore without any on-chain fees.
Reorg-resistance (Ethereum backend): The Ethereum backend now supports reorg-resistance. That is, it is possible to configure how many blocks are required in order to confirm an on-chain transaction. This improves the robustness of our library as it protects against chain reorgs.
External watcher:Go-Perun now has an interface for injecting a custom watcher logic. This means that SDK users can now implement their own watcher logic or use an external service for watching and reacting to chain events.
Perun Node v0.6: A new client that adds a text-based user interface for trying out Perun Node, support for ERC20 tokens and improved error handling.
More supported blockchains
Polkadot backend: We successfully developed a Polkadot backend for Go-Perun. This means that it is now possible to use Go-Perun on Polkadot chains. The backend is currently restricted to single asset payment channels.
Cosmos backend:We successfully developed a Cosmos backend for Go-Perun. The on-chain logic has been implemented in the form of a CosmWasm smart contract. This means that it is now possible to use Go-Perun on a Cosmos chain supporting CosmWasm. The backend is currently restricted to payment channels.
Dfinity backend (smart contract): We started the development of a backend for the Dfinity Internet Computer. This currently includes the Perun smart contracts for this network. We plan to continue the backend development later this year.
Demonstrators, Tutorials, Talks
Perun Credential Payment:We have published a proof of concept implementation that shows how trustless and low-fee payments for verifiable credentials in the context of self-sovereign identities (SSI) can be realized using Perun State Channels.
Cross-chain interoperability: We will be working towards enabling cross-chain capabilities of the Perun Framework. This will enable, for example, asset swaps between different blockchains and more.
IoT Readiness: We will make the architecture of Perun Node more flexible, so that funding and watching services can be accessed over remote interfaces. We will also add an alternate client implementation that can be deployed on resource constrained embedded devices.
More blockchain backends: We will be looking into extending the feature set of our existing backends, for example, enabling generalized state channels on Polkadot. We plan to add more blockchains to our list of supported backends.
Building out the ecosystem: As development with the protocol and surrounding network continues, we will be working to further define the components of the Perun ecosystem and the communities working to advance these technologies.
We are excited to announce that Perun, a Hyperledger Lab, has published the first version of the Perun-CosmWasm blockchain backend. For the first time, this enables Perun Channels on the Cosmos Network using the CosmWasm smart contract technology. For our first release, we focused on payment channel functionality on a single Cosmos blockchain. This paves the way to enabling the full potential of Perun on Cosmos in the future: atomic transactions with arbitrary transaction logic across multiple Cosmos blockchains.
Payment Channels on Cosmos Network
A payment channel is a construct that allows users to transfer and swap funds at low latency and nearly zero fees without a trusted intermediary. It allows users to massively scale their transaction capabilities without losing the trustless nature of blockchain technology.
Figure 1: Alice and Bob create an off-chain channel to interact.
In the future, Perun will support channels across multiple blockchains—for example, two Cosmos chains, or a Cosmos chain and an Ethereum chain. This will enable cross-chain applications based on channel technology.
With the addition of CosmWasm, the Perun framework now contains three backends (Ethereum, Polkadot, Cosmos). Blockchain-agnostic applications can be written and run within Perun channels. The used backend can be exchanged with another to enable identical contracts across multiple blockchains. The possibility to add further backends increases the modularity of the architecture of blockchain-agnostic applications.
About Perun
Perun, a Hyperledger Lab, is a joint DLT Layer-2 interoperability and scaling project contributed by Robert Bosch GmbH’s project “Economy of Things” and PolyCrypt. PolyCrypt is a spin-off of the Technical University of Darmstadt (TUDa).
Meet Performance SandBox, a new Hyperledger Lab for testing new research to boost performance of blockchain platforms. This is an open source effort and you’re welcome to get involved by checking out the lab’s repository or by joining the monthly Performance and Scale Working Group calls.
What is Performance SandBox?
A new addition to Hyperledger Labs, the Performance Sandbox is a testing environment for Hyperledger projects performance research usage.
As the picture above shows, the Performance Sandbox uses Kubernetes as its infrastructure and is integrated with monitoring and open tracing (or say open telemetry).
– It supports users deploying a target network such as a test-network, also known as a SUT (system under test), for asset transform for Hyperledger Fabric
Performance researchers are able to use this lab to do research with the steps below:
1. Start the sandbox with Kurbenetes integrated with monitoring and open telemetry
2. Deploy the SUT onto the Kubernetes infrastructure.
3. Start the traffic generator to keep sending traffic to SUT
4. Monitor and analyze test results from the dashboard/open telemetry results.
5. Changes local source code (e.g., Hyperledger Fabric), make local docker image and redeploy the SUT.
It will extend the existing paper published by the PSWG with monitoring and open telemetry. As the right side in the above figure shows, we can see the performance test model published previously by PSWG, with SUT, traffic generator and observers.
Flexible design
– Migration from Kind to other Kubernetes platforms: In this lab, we use Kubernetes as infrastructure, hence it is easy to migrate to any other Kubernetes-based infrastructure.
– Use with blockchain systems other than Hyperledger Fabric: So far, the PoC and demos have been based on Hyperledger Fabric. However, as the orange area shows, the blockchain system can be replaced with any kind of blockchain system.
– Traffic generator: So far this has been deployed as a demo with Tape, as it is a Kubernetes development. It can be replaced with Hyperledger Caliper or Jmeter. Tape is a sample performance tool for Hyperledger Fabric without an SDK (close to the blockchain network itself). Caliper is based on the Hyperledger Fabric SDK (closer to the application level). You may need to use Jmeter to create traffic for end-to-end performance research assuming you expose the RESTFUL endpoint to the end user
– Size of SUT: you are able to scale the size for SUT, as it is a blockchain based on Kubernetes.
Technological details
Read on for technological details around three topics: deploying monitoring tools with operator, traffic generator, and dashboard.
Deploying monitoring tools with operator
In the Performance Sandbox, we used operator technology (refer to operator capablities) to make monitoring systems work with Auto Scaling and Auto Tuning.
For example:
When a blockchain node (e.g., Hyperledger Fabric peer) has been deployed, the Kubernetes operator will help make a connection between the blockchain node (as service/pod) and monitoring system (as Prometheus, Jaeger, etc.) to automatically tune the operator framework to a certain workload pattern.
Ideally, users are able to deploy any size of nodes (e.g., number of peers) for the SUT without spending too much effort on configuration.
Meanwhile, the operator is able to deploy across Kubernetes clusters, making it easy to migrate to any specific cluster.
Traffic generator
In most cases, performance is evaluated by TPS (transactions per second). However, there are different scenarios for the “transaction.”
Let’s assume we have an application server that receives a restful API to support Alice and Bob, sending traffic from the application GUI/mobile app. Normally, the application will connect with the blockchain network. Generally speaking, the application depends on the SDK and SDK relay on network protocols such as GRPC.
On the left side of the figure above, the three arrows indicate three different levels of traffic.
– At the end user level, indicated by the green arrows, an application receives a business transaction and returns it. Total time spent includes application logic and SDK level duration.
– At the SDK level, indicated by the blue arrows, an SDK receives a business transaction and returns it. Total time spent includes SDK logic and communication level duration.
– At the communication level, indicated by the red arrows, the total time involves packaging business transactions following communication protocol and sending them to the blockchain network.
Hence, we can see from the open tracing span, the green line means the total time starts when the application received the user’s request and ends with application return. Then the blue line appears as SDK processing time. Then the gRPC time reflects the duration for a gRPC to send and receive a response back from the blockchain network.
Ideally, those TPS are nearly the same and you either focus on the application side or blockchain side. However, we’d better have tools on hand for handling some edge cases such as SDK overhead, bad application logic, etc. As on right side:
1. Indicates application processing time before transaction reach at SDK and ready for send to blockchain network.
2. Indicates SDK starts processing the transaction and time spent before network communication happens.
3. Indicates SDK received a result for network communication, and time spent before SDK return.
4. Indicates application processing time before transaction return back to end users from SDK result.
{Note: If you’re interested in blockchain performance testing tools, you can also check out Hyperledger Caliper.}
Dashboard
In the Performance Sandbox, we used a dashboard for system monitoring. In most cases, we analyze TPS as a collection for data drawn as a histogram.
For example, we are able to draw down Transaction Throughput based on timeline into a figure (refer to performance metric). However, as the blockchain is based on crypto service, which relays CPU resources and consensus, that relays bandwidth.
With the dashboard, we are able to collect both blockchain matrix and system matrix at the same time, by integrating different matrices together, identifying limitations/bottlenecks in a visual way.
Assuming bandwidth is a bottleneck for the current Performance Sandbox environment, we can see the CPU/time left with some capabilities at all rounds of testing. Each time when the transaction throughput reaches a specific value, network bandwidth will be used up.
What’s Next
Now, let’s go back to the goal of this new Hyperledger Lab: to provide a sandbox to make performance research usage easier. To see what’s next:
Blockchain
Deployment
Communication Level Traffic
SDK Level Traffic
User Level Traffic
Dashboard Metrics
Hyperledger Fabric
test-network-k8s (WIP, as application and couchdb)
Tape
Hyperledger Caliper (tbd)
jmeter (tbd)
to be completed
Hyperledger Fabric
Minifab (tbd)
…
…
…
…
Hyperledger Fabric
Hyperledger Bevel (tbd)
…
…
…
…
Hyperledger Fabric
Hyperledger Cello (tbd)
…
…
…
…
Taking Hyperledger Fabric as a sample: we need to support different ways to deploy Hyperledger Fabric as a test network, including Kubernetes, Minifab, Hyperledger Bevel, Hyperledger Cello, etc.
Meanwhile, to fully support traffic generators, we need to go through different levels of traffic generators and complete a dashboard.
Want to get involved?
Here are some places to connect with the code and the community:
We kicked off #HyperledgerInterop month with Why is Interoperability Needed?, which explains the drivers for interoperating networks and then deep dives into the different Hyperledger technologies tackling the challenge.
Below, we continue the conversation with highlights of some leading-edge efforts to deliver cross-chain interoperability built using Hyperledger technologies:
Cross-Ledger Interbank Settlement: As part of a series of wholesale CBDC trials, Banque de France, the French Central Bank, completed cross-ledger interbank settlement transactions in a multi-blockchain environment. Conducted in association with HSBC and IBM, this test case entailed the issuance and trading of digital bonds, settled instantly using CBDC. Transactions occurred across blockchain environments operated by HSBC for the custody of the assets and by the Banque de France for the securities settlement and the CBDC. In the trial, Hyperledger Fabric and R3’s Corda were able to transact with each other using Weaver, a Hyperledger Lab initially contributed by IBM.
Digital Green Bond Project: The Bank for International Settlements Innovation Hub (BIS) Innovation Hub and the Hong Kong Monetary Authority (HKMA) set out to improve efficiencies in the distribution of green bonds and more insightful reporting on the environmental impact of projects supported by the bonds through Project Genesis. The aim is to develop digital platforms that will allow investors to buy and sell bonds that support green projects with real time access to both the financial performance of the bond and such metrics as clean energy created and O2 reduced by the investment. The first prototype from Project Genesis was developed with Digital Asset in partnership with GFT and leveraged Daml smart contracts as well as Digital Assets interoperability protocol layered over Hyperledger Besu and Hyperledger Fabric blockchains. It achieved real-time synchronization across these two ledgers while preserving the level of privacy demanded by regulated bodies. The prototype drives market efficiency with a unified view of the entire trade lifecycle and a single source of truth that automates market rules and adheres to market regulations.
Interoperable platform for international exchange of CBDCs: The BIS Innovation Hub, Hong Kong Monetary Authority, Bank of Thailand, People’s Bank of China, and Central Bank of the United Arab Emirates are working together on a prototype multi-CBDC platform for international payment that joins up national digital currencies on a common interoperable platform. During the Phase 2 and 3 explorations of the project, mBridge (formerly Inthanon-LionRock), they worked with ConsenSys on a Hyperledger Besu implementation that completed an international exchange of multiple CBDCs in seconds as opposed to several days and has the potential to reduce costs to users by up to half.
Multichain Trade Settlement: In January, 2022, Tokio Marine & Nichido, NTT DATA, STANDAGE and TradeWaltz jointly conducted a demonstration experiment for a new trade settlement system in which electronic B/Ls (bills of lading) and digital currencies were exchanged simultaneously using two different blockchain networks. The simultaneous transfer of digital assets and digital currencies was conducted by Datachain with the cooperation of NTT DATA, and leveraged YUI, a Hyperledger Lab that was initially contributed by Datachain, to interconnect Hyperledger Fabric and Ethereum. Datachain successfully confirmed that two assets can be exchanged simultaneously by DVP settlement between digital assets on services built with Hyperledger Fabric and digital currencies on Ethereum.
Chime in on social to share other examples of #HyperlegerInterop.
Blockchain interoperability is one of the crucial features of blockchain technology, operating in three main vectors: enabling scalability, diminishing risks and eliminating silos¹. This blog post focuses on interoperability projects connecting data and value silos.
Standardization bodies are pushing forward drafts to normalize operations across the different interoperability layers. Those working on standards includeOpen Digital Asset Protocol (ODAP) from IETF², the interoperability working group in Digital Currency Global Initiative (DCGI) at ITU³, the subgroup 7 (ISO/TC/SG7) from ISO TechnicalCommittee 307⁴, the Cross-Chain Interoperability working group at the Ethereum Enterprise Alliance⁵, and many others⁶. Interoperability solutions can follow guidelines from standardization bodies for seamless integration across their targets and other interoperability solutions.
Several blockchain interoperability projects focusing on solutions for interoperability among public blockchains flourished in the last years⁶. However, enterprise-grade interoperability solutions have only recently emerged, and the necessary standardization effort is still in its infancy. Although many different categorizations exist⁶, we can broadly classify interoperability solutions into two categories with different philosophies and approaches. In the first, a common “settlement” chain (or hub) is created as a permanent infrastructure to which other chains (e.g., “sidechains”) can connect; the common chain serves as an interoperation medium, offering decentralized trust guarantees to the sidechains for the settlement of cross-chain transactions. Cosmos7 and Polkadot8 exemplify this approach, which is particularly suited to public blockchains and distributed ledgers.
In the second category of interoperability solutions, a blockchain network, be it public or private, is augmented with modules and capabilities that allow it to interoperate directly with another network without depending on third-party infrastructure. This second category, into which Hyperledger Cactus9 and the Hyperledger Lab Weaver10 fall, is useful in enterprise scenarios where privacy as well as performance are core concerns. Both these approaches have their pros and cons, which are scenario dependent.
The Hyperledger community has been involved in notable efforts to advance open source solutions that respond to modern interoperation needs, which can be wide-ranging, and provides a collection of solutions from which blockchain users and consortia can select as per their requirements. This post explores how four technologies (two projects and two labs) under the Hyperledger umbrella approach the interoperability problem (public blockchains – consortium blockchains – centralized systems), comparing them across multiple criteria.
Hyperledger Cactus
Hyperledger Cactus is a pluggable enterprise-grade framework to transact on multiple distributed ledgers without introducing yet another competing blockchain. It’s an SDK of SDKs.
Hyperledger Cactus aims to provide Decentralized, Adaptable and Secure Integration to and between Blockchain Networks. It aims to cover as many protocols as possible through an extensible plugin architecture where new protocols or functionality can be added by creating new plugins.
Hyperledger FireFly
Hyperledger FireFly provides an API orchestration layer over multiple blockchain ledgers, fostering interoperability in the application tier. Allowing common blockchain programming constructs like tokens, off-chain/on-chain data orchestration, and identity verification to be implemented in pluggable microservice code modules against multiple blockchains. Patterns already implemented that span multiple chains in a single business transaction, include using a Hyperledger Fabric DLT for private business agreement and document verification, orchestrated with tokenized value transfer on a separate Ethereum blockchain. FireFly also provides an API layer into which blockchain interoperability platforms can plug into in the future, for a simplified developer experience.
Weaver
Weaver, a Hyperledger Lab, is a framework with a family of protocols to enable interoperation for data sharing and asset movements between independent networks built on heterogeneous DLTs in a manner that preserves the core blockchain tenets of decentralization and security.
Interoperation using Weaver does not rely on trusted mediators. Rules and requirements are framed using the networks’ internal governance mechanisms. Interoperation relies minimally on shared infrastructure, which may provide identity services but does not play a part in core protocols through which data and assets are shared. Interoperation occurs through protocols that derive their trust from the counterparty networks’ native consensus mechanisms.
Currently, a protocol for data sharing across ledgers with proof of authenticity and provenance is supported (for Fabric and Corda). We are currently adding a new protocol that enables asset exchanges using the HTLC pattern.
YUI
YUI is a Hyperledger Lab that achieves interoperability between multiple heterogeneous ledgers. The lab provides modules and middleware for cross-chain communication as well as modules and tools for cross-chain application development.
For cross-chain communication, YUI is based on Inter Blockchain Communication (IBC) protocol by Cosmos project, with extensions to support various Hyperledger projects. IBC provides the basis for ledgers’ interaction of arbitrary data transfer and computation without the assumption of the trusted third party.
Currently YUI supports cross-authentication between enterprise ledgers (Fabric, Besu and Corda). Each actor of ledgers has to interact with only a respective ledger of its interest to complete a cross-chain operation such as an atomic swap of tokens.
Feature Matrix of Projects
Legend
✅: Supported ❌: Out of Scope or not in the current roadmap 📝: Design/PoC but no official implementation 🏗️: Not *yet* supported
Feature Name
YUI
Hyperledger Cactus
Weaver
Hyperledger FireFly
Remote API access
🏗️
✅
✅
✅
Standard Data Model
✅(a)
🏗️
❌
❌
Client Language bindings – NodeJS
❌(b)
🏗️
✅
✅ (d)
Client Language bindings – JVM
❌
🏗️
✅
✅ (d)
Client Language bindings – Rust
❌
🏗️
❌
✅ (d)
Client Language bindings – .NET
❌
🏗️
❌
✅ (d)
Client Contract Language bindings – Go
❌
🏗️
✅
✅ (e)
Contract Language bindings – NodeJS
❌
🏗️
✅
✅ (e)
Contract Language bindings – JVM
❌
🏗️
✅
✅ (e)
Contract Language bindings – Rust
❌
🏗️
❌
✅ (e)
Contract Language bindings – .NET
❌
🏗️
❌
✅ (e)
Trusted Relays
✅
✅
✅
✅
Trustless Relayer
✅
✅
✅
🏗️
Generic Data Exports
🏗️
🏗️
🏗️
❌
Ledger Data Backups
❌
🏗️
❌
❌
Blockchain of Blockchains – To Store Data (e.g. Transactions)
✅
❌
🏗️
🏗️
Blockchain of Blockchains – To Store Network Information
🏗️
❌
🏗️
🏗️
Cross-authentication – light client
✅
🏗️
❌
🏗️
Cross-authentication – Federated via other identity providers
✅
🏗️
📝
📝
Arbitrary data transfer and computation
✅
✅
✅
✅
Exactly-once operation
✅
🏗️
🏗️
❌
Handling misbehaviour
✅
🏗️
🏗️
🏗️
Does not incorporate interaction between new actor(s)
✅
🏗️
✅
✅
Generate state proofs for external consumption
✅
✅
✅
❌
Verify state proofs independently, without becoming a network insider
✅
✅
✅
❌
Move assets from one ledger to another
✅(c)
✅
✅
✅
Copy assets across ledgers while retaining provenance knowledge
✅(c)
🏗️
✅
✅
Atomically exchange assets in different ledgers
✅(c)
🏗️
✅
🏗️
Accountability (auditability) for data, assets, transactions that involved interoperation
Ability to support cross-network smart contracts (ledger–>ledger invocations)
✅
🏗️
🏗️
✅
End-to-end confidentiality
🏗️
🏗️
📝
✅
Privacy-preserving queries
🏗️
🏗️
🏗️
🏗️
Support for network discovery and connection bootstrapping
🏗️
🏗️
🏗️
✅
Support for routing data and assets via intermediate networks
📝
🏗️
🏗️
✅
Future Work for 2022 Q1
Hyperledger Cactus
Support for the Open Digital Asset Protocol (ODAP)
Improved documentation and more examples (similar to fabric-samples)
Increased number of maintainers
Public test deployment of a Cactus network
Cactus benchmarks that are reproducible by anyone the same way the functional test cases are as long as they have access to a cloud provider account or a k8s cluster
Hyperledger FireFly
Multi-ledger support
Pluggable DID provider support
Pluggable API Security (e.g. OAuth 2.0)
Active-active clustering
NoSQL database support
Weaver
Implementation of cross-network decentralized identity and credential exchanges as trust basis for interoperation (currently in design spec)
Relay driver and support data/state view and asset transfers in Hyperledger Besu (Hyperledger Fabric and Corda already supported)
Relay module: more robustness (fault tolerance), add message queueing features, distribution and load balancing, make compatible with ODAP
Cross-network transaction invocation and event publish/subscribe
End-to-end confidentiality support for state and asset sharing
Augmented data/state sharing protocol to use verifiable external observation features through which the freshness of state can be verified
Improved documentation, tutorials, and testing features
Added performance evaluation capabilities
Inter-compatibility with Hyperledger Cactus through merged and aggregated features
YUI
Other ledger support (possibly other Hyperledger projects)
Enhanced support for Solidity and Ethereum-based ledgers
Enhanced support for connecting the Cosmos ecosystem (such as Tendermint light client for Solidity)
Improved documentation and release samples
Notes:
a) Based on the Inter Blockchain Communication Protocol (IBC) (i.e., the specifications define packet data structure and the interface of handler of packets) b) Developers only need to interact with the ledger and the framework does not incorporate another layer between them c) Supported by auxiliary modules such as Cross framework d) Hyperledger FireFly API is REST and JSON, so all language “bindings” are supported e) Access to contracts via Hyperledger FireFly is also fully REST-ified, so all language bindings are supported
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
Documentation and Use Cases for Climate Action
Description
To improve documentation of the blockchain carbon accounting applications, including tutorials on how to develop and enhance the applications and use cases for the applications.
Status
COMPLETED
Difficulty
LOW
Additional Details
Learning Objectives, Expected Outcomes and Project Results available here.
Final Project Video
Mentee
Dounia Marbouh
Khalifa University
“The Hyperledger Mentorship Program was a great opportunity for me to grow and learn from others, especially my mentors. It is a chance to realize that in a world where many pieces of information can be simply “Googled,” there is still some knowledge that can only be gained through experience, and this mentorship program was the best example of that. Also, this experience focused on many competencies and talents, such as research, collaboration and communication, which are immensely invaluable. “
Mentors
Si Chen
Open Source Strategies, Inc.
Sherwood Moore
CA2 SIG Co-chair
Si Chen
“In this project, our different backgrounds came together to take us a lot further. We found out that the carbon credits and offsets market is much more complicated than originally anticipated. While many people want to use blockchains to improve the liquidity of the carbon credits market by making transactions more efficient, what the market really needs is greater trust in the quality of the credits and lower costs to bring them to market. We also learned that a successful mentorship is a partnership, where everyone—mentors and mentees—need to come prepared to both contribute and learn.”
Sherwood Moore
“I really enjoyed this opportunity to mentor, and I found that I learned from the experience as much as I shared my expertise. I really enjoyed being able to share from my experience conducting market research and identifying opportunities by tapping into the knowledge of the stakeholders within it. At the same time, it was really interesting to learn more about the voluntary carbon market, which was the focus of our research, as well as the world of academic publications, which was the end goal and deliverable of our work. All in all, a very successful internship project, and I look forward to participating in more.”
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
Implement Client Side Security for Climate SIG Fabric Application
Description
To explore and implement an application with client side authentication for Hyperledger Fabric utility emissions data channel.
Status
COMPLETED
Difficulty
HIGH
Additional Details
Learning Objectives, Expected Outcomes and Project Results available here.
Final Project Video
Mentee
Bertrand Rioux
King Abdullah Petroleum Studies and Research Center
“Climate side security involves moving private keys of users off Hyperledger Fabric network servers. To solve this problem, I built a custom identity provider type for Fabric using the WebSocket protocol. This required designing an identity server to create WS-X.509 certificates using secure asynchronous communication between a Fabric app and a user’s external keys. Learning how to build a custom crypto wallet app compatible with Fabric and contributing to active Hyperledger projects, including Hyperledger Cactus and the Blockchain Carbon Accounting Lab, were highly rewarding experiences. This mentorship project has helped accelerate my goal of building technology for climate action.”
Mentors
Si Chen
Open Source Strategies, Inc.
Kamlesh Nagware
Snapper Future Tech
Si Chen
“This mentorship started because we wanted to have our Hyperledger Fabric emissions accounting application authenticated at the client like other dApps. It went through several twists and turns as we tested different approaches. In the end, we came up with an elegant solution that could be used for mobile, IOT, and web apps. The mentoring process taught me more about how to bring more developers on board and listen to their input while still providing guidance on the direction of the project. This combination is very important in an open source, distributed development model.”
Kamlesh Nagware
“For this research project, which aimed to determine the right client side identity approach, we initially had something in mind like use TrustID but then turned to exploring Hyperleger Fabric off-line signing but for real client side identity model. Its very important to have a mechanism like Metamask in Ethereum. This was a really challenging project. Our mentee, Bertrand Rioux, put his research and experience with cryptography and clientsecurity to work in implementing this project. Special thanks to Pritam Singh, who is a mentee in another project, for joining hands to help build a more secure architecture design for the clientsecurity model in Hyperledger Fabric. Designing and adding WebSocket and supporting additional cryptography algorithms to the Hyperledger Fabric node SDK is the real achievement of this project.”
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
Implement Two Compiler Passes for Solang Solidity Compiler
Description
To implement two compiler passes for the Solang Solidity Compiler.
Status
COMPLETED
Difficulty
HIGH
Additional Details
Learning Objectives, Expected Outcomes and Project Results available here.
Final Project Video
Mentee
Lucas Steuernagel
AERONAUTICS INSTITUTE OF TECHNOLOGY
“After taking compilers and operating system classes at university, I wanted to work with something related to low-level computing. I enjoyed those subjects, and I found the mentorship as an opportunity to experience such areas. I gained knowledge of compiler optimizations and learnt to analyze the trade off between design alternatives. The mentorship also paved the way for me to create new connections and to find job openings in low-level computing.”
Mentor
Sean Young
“I saw the Hyperledger Mentorship Program as an opportunity for someone to really make progress on an interesting idea that our work priorities don’t allow time for. I was hoping that this would make an exciting challenge and offer someone the opportunity to become familiar with Hyperledger and the Solang compiler. Lucas Steuernagel, the mentee this year, has a keen interest in compilers, and we had many interesting discussions regarding how to tackle the challenge. Lucas came up with a truly novel and innovative way to handle the task. It’s been a great success, highly enjoyable and rewarding. It has been fantastic to mentor and work with such young talent.”
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.”
