Hyperledger, Author at Hyperledger Foundation

Mar 28

#HyperledgerHybrid in action: Connecting permissioned and public networks to maximize value

By Hyperledger Blog, Hyperledger Aries, Hyperledger Besu, Hyperledger Fabric, Hyperledger FireFly, Interoperability

We have long said there will not be one blockchain to rule them all. It will take a mix of blockchains and blockchain technologies to maximize the value of distributed ledgers, smart contracts, digital assets and self-sovereign identity between businesses, across industries and around the world.

Hybrid networks, which combine the capabilities of private and public blockchains, can deliver a number of advantages, including high levels of scalability and performance, and provide the right balance of security, privacy and transparency. The private blockchain offers secure, permissioned data storage—an essential feature that’s particularly crucial for highly regulated industries. Meanwhile, the public blockchain brings scale and immutability, enabling a more open and transparent ledger.

As part of our spotlight on #HyperledgerHybrid, we’ve compiled a sampling of production deployments and solutions leveraging Hyperledger technologies to deliver value across a mix of permissioned and public chains.

Blockchain for Energy

Energy industry consortium, Blockchain for Energy has launched a new decentralized and interoperable platform powered by Kaleido and leveraging Hyperledger FireFly. The B4E Network & Platform allows energy companies to access proven solutions and build applications that leverage Web3 constructs including smart contracts, digital assets, NFTs, and tokenization across both public and private chains. The first production-grade solution released on the new platform is from the B4E Commodity Transport Program, a collaborative effort led by Pioneer Natural Resources, that utilizes IIOT and blockchain technology to track chemical deliveries.

IPwe Digital Assets

In September 2022, Casper Labs and IPwe developed and launched a dynamic NFT blockchain solution, IPwe Digital Assets. The solution uses the permissioned distributed ledger technologies of open source Hyperledger Fabric and the public Casper Blockchain to securely store verified public and private information about each patent. The integration capitalizes on the data security and trust inherent on a Hyperledger Fabric network and enables Casper to securely bring assets locked on the private ledger to the public chain.

IPwe is now deploying 25 million patent NFTs leveraging the hybrid Casper Blockchain and Hyperledger Fabric network. On top of that, IPwe’s solution includes Smart Intangible Asset Management (SIAM), a comprehensive SaaS tool for IP valuation and management that allows enterprises to fully utilize these patent NFTs to transact, manage, and value their IP. This revolutionary implementation of blockchain technology will enable IPwe to bring liquidity to the IP space, where currently approximately 95% of IP assets are not transacted or commercialized

Palm Network

The Palm network is an Ethereum sidechain dedicated to selling, purchasing, and trading NFTs that are associated with real-world and digital assets. It is built with Hyperledger Besu and uses IBFT 2.0 proof of authority (PoA) consensus, with network validators being run by key stakeholders. IBFT 2.0 offers fast transaction speed and free minting.

An automated bridge relay service connects payment tokens, like DAI, and NFTs on Ethereum and the Palm network, with bridging contracts deployed on both networks to manage the connection. Fees collected from this bridge are partially used to purchase carbon offsets.

Starling Lab

Starling Lab is a joint effort developed by the USC Shoah Foundation and Stanford University’s Department of Electrical Engineering. The initiative’s goal is to develop a set of tools and principles to be used across non-profit organizations, news outlets, and industry experts to solve challenges when it comes to the uncertainty of the media we see today and our enduring effort to preserve the truth.

Starling provides an open-source, end-to-end framework for the media generation and verification process. The framework consists of three modules: capturing the image, storing the information, and verifying its authenticity. It leverages multiple blockchain and distributed ledger technologies. Each metadata record, such as the caption or photographer byline added by an editor to a photo’s record, is relayed to a Hyperledger Fabric peer for notarization on a private permissioned ledger. Each transaction posted to Hyperledger is recorded on Hedera Consensus Service (HCS) using a hashgraph that rapidly orders and stamps each entry.

Toko

Global law firm DLA Piper developed its TOKO tokenization platform to issue non-fungible tokens across asset classes including real estate, fine art, debt and even intellectual property. Toko is a digital asset creation engine to solve inefficiencies in today’s capital markets by using DLTs to distribute, trade and settle transactions rapidly, bypassing the need for trusted third party intermediaries that are both expensive and slow. It is built using the combination of a permissioned Hyperledger Fabric network and the Hedera Consensus Service.

Join the conversation about the use of Hyperledger technologies delivering value across permissioned and public networks with #HyperledgerHybrid.

Mar 22

Love0

Fujitsu Develops Hyperledger Fabric-Powered Exchange for Plant-Sourced Water Recovered by Botanical Water Technologies

By Hyperledger Blog, Climate, Hyperledger Fabric, Member Case Study, Supply Chain

Read the full case study here.

Water is the most precious resource on Earth. But with more and more storms, floods, and droughts, it’s not always where we need it. The UN says 4 billion people—half the world’s population—face severe water shortages at least one month a year.

Botanical Water Technologies (BWT) from Australia found a way to recover the water usually wasted making alcohol, juice, ketchup, and sugar. BWT estimates 3 trillion liters of water are wasted this way every year. If that water were recovered, it could be reused, commercially sold or gifted to people who need it most.

The company had a working process for capturing, purifying and creating the world’s most sustainable drinking water with technology housed in shipping containers and connected up to existing systems that process fruit, vegetables, or sugar cane. The next challenge was creating a marketplace for buyers and sellers of plant-sourced water that would support three different transactions:

Sales of actual water for food, beverage and other manufacturers
Sales of “water impact credits” (WICs) to help fulfill corporate water stewardship goals
Bulk donations of water to the world’s most vulnerable people

BWT asked Fujitsu to develop a world-first: Botanical Water Exchange (BWX) that securely tracks every drop of water from producer to end consumer. That exchange is powered by the leading open-source framework for enterprise blockchains, Hyperledger Fabric.

The BWX exchange went live in the second quarter of 2022. The platform is now testing all functions and features with a selection of key partners in the U.S., Australia, and India. A standard water harvesting unit (WHU) can harvest ~460,000 liters or ~122,000 gallons per day. The BWX doesn’t only allow producers and buyers to trade. It also covers production planning, logistics planning, and value chain management. In addition, it interfaces with the WHU’s software for audit and certification purposes, tracing over 170 touchpoints and sensors per WHU.

The Hyperledger Foundation team worked with Fujitsu and BWT on a case study covering the business plan, technical requirements and implementation details. The case study also highlights plans to build out the network and expand the ecosystem, including creating a real-time wall display that quantifies the amount of water harvested and delivered, along with the positive impact made to people and the environment. The goal is to deliver water to 100 million of the world’s most vulnerable people by 2025.

Read the full case study here.

Mar 15

Love0

Helping A Community Grow By Pruning Inactive Projects

By Ry Jones and David Boswell, Community Architects Blog, Governance, Hyperledger Avalon, Hyperledger Burrow, Hyperledger Explorer, Hyperledger Foundation Staff Corner, Hyperledger Quilt

It may sound counterintuitive, but removing projects from an open source community is a critical part of helping that community grow. All projects have a life cycle, and it is natural, even for highly successful projects, to have development slow down or for user adoption to peak and then decline. Life cycle planning happens inside of companies that produce proprietary software and should be part of open source community management plans as well.

There are advantages that come from monitoring the status of projects and taking steps to wind down a project when projects become inactive. For example, it lowers the barrier to entry for people with innovative ideas. These ideas may or may not work out, and there should be no stigma around trying something that might fail. The alternative is to only accept new ideas that you feel are guaranteed to work out and that have enough resources dedicated to keep a project going indefinitely. That approach will limit what new projects can get started in your community. As Linux Foundation Executive Director Jim Zemlin has said about projects becoming inactive: “It’s a good reminder, though, that if we are not losing sometimes, we are not making enough bets and pushing hard enough.”

Removing inactive projects also helps create clear pathways to connect potential users and contributors to the projects that are active. In the early days of open source, people coming into a community had an easier time navigating their way to projects where they can add value.

As open source development has become accepted in more and more industries, the landscape has become more complex. The Octoverse 2022 report states that there were a staggering 52 million new open source projects started by developers on GitHub last year alone. Sorting through this amount of code can be an overwhelming experience that can be eased by archiving those projects that are no longer under development.

There is also little downside to winding down a project because the code is still available and can be reactivated if people choose to do so. Ending a project can even prompt people who were using a project to become contributors. For people using open source code, it may seem like your contribution isn’t needed when maintainers are doing development and creating regular releases. However, if development stops on a project you rely on, it can be a good reminder that open source communities are driven by people with an interest in and a need for a project. We’ve seen this happen with Hyperledger Explorer. When the original maintainers had a shift in priorities that took them away from the project, it was archived because no one else stepped in to keep it going. As soon as it was wound down, we heard several people say “Hey, I was using that,” which gave us a chance to talk with them about how they could restart and contribute to the project.

How Pruning Happens At The Hyperledger Foundation

Hyperledger Foundation is hosted by the Linux Foundation where pruning inactive projects is considered a best practice. For instance, CNCF has archived projects before, stating that the process of reviewing project activity and winding down inactive projects is a sign of a healthy open source community. In this post, we will look in more detail about how the process happens in the Hyperledger community, but the process will be fairly similar with small differences for other communities.

Hyperledger’s Technical Oversight Committee is in charge of making decisions about each step of the lifecycle of a project – including starting a new project as well as deciding to end of life projects.

TOC members need data to make their decisions so they ask all projects to submit quarterly reports about the status of their work. In cases where maintainers mention plans to end development in their report, it can lead to a straightforward discussion between TOC members and project maintainers where they decide to wind down a project. If a project becomes inactive and there is no one to submit a report, that is also a clear signal that a project may be inactive. TOC members have tools to investigate project status, including LFX Insights, Orbit and a tool to show the last commit on the default branch.

Before 2022, the TOC had decided just once to end-of-life a project when they archived Hyperledger Composer in April 2020. As the Hyperledger Foundation has matured and more new projects have been started, we’ve also seen an increase in archiving projects. In 2022, Hyperledger moved four projects to end-of-life status: Hyperledger Avalon, Hyperledger Burrow, Hyperledger Explorer and Hyperledger Quilt.

If you have been using any of these projects or are interested in the code, please feel free to take a look and reach out to us (email to: community-architects@) if you’re interested in restarting development. For instance, Hyperledger Explorer has been restarted as the blockchain-explorer lab, and people are looking into how to restart development to shape the direction of the code to meet their needs. If you’re interested in connecting with people to discuss next steps with blockchain-explorer feel free to join the #blockchain-explorer channel on Hyperledger’s Discord server.

When we archive a project, it gets much less attention than when a new project launches, so we hope this post has given more attention to the projects that have been moved to end-of-life status and explains the decision making process behind these changes.

Mar 13

Love0

The Role of Decentralized Identity in Implementing the White House National Cybersecurity Strategy

By Heather Dahl, Hyperledger Foundation Governing Board Member and Indicio CEO Blog, Identity

On March 1, 2023, the Biden administration released its National Cybersecurity Strategy. The document has a clear and compelling theme: “We must ensure the Internet remains open, free, global, interoperable, reliable, and secure — anchored in universal values that respect human rights and fundamental freedoms.”

These goals are achievable and the route to making this strategy a success lies through open source decentralized identity technology. Simply put, the only way to meet the digital needs of the 21st century, whether in the provision of ecommerce, citizenship, or digital inclusion is to move past the legacy of the 20th: an internet that lacks a reliable way to verify people, data, things.

We’ve been working around this problem for decades and the workarounds don’t work. They’ve saddled us with fraud and stripped us of privacy. They’ve failed to provide the quality that every democratic society needs to thrive: trust. The ability to trust who you are while interacting online. The ability to trust data. The ability to hold one’s own personal data, keep it private, and only share it with consent.

You could say that a problem like this requires a moonshot to solve: that it needs to bring together our best engineers and experts to tackle a problem of global scale. It doesn’t. These problems have been a central concern among open-source technology communities like those at the Hyperledger Foundation for many years. And they—we—have found solutions.

Decentralized identity has provided a way to provide a verification layer for digital interaction; we have ways to prove who we are and know who we are interacting with; we have ways for people to hold their data and share it in a way that preserves their privacy.

It’s difficult to overstate the importance of the next point: These aren’t paper solutions or futureware; industries are leading the adoption of this technology. The prospect of secure, seamless travel — which would take a passenger from online check in to boarding, through border control, and all the way to unlocking their hotel room—is driving the creation of a verifiable digital travel credential.

At Indicio, we have worked with dozens of companies and organizations to design and build solutions for everything from employee identification to auditing devices monitoring emissions to tracking supply chains. We’ve used Hyperledger Foundation technologies to develop verifiable credentials that manage financial transactions, from passwordless proof of account ownership to reusable KYC.

The future is happening now. And because so much of this work has been built on open source codebases (meaning many developers, companies, and even governments passionate about the technology have contributed code), the future is available to everyone.

Strategic Objective 4.5: Support Development of a Digital Identity Ecosystem

In Strategic Objective 4.5 of the National Cybersecurity Strategy, the White House reminds us of the human cost of inaction and inertia: data breaches impacted nearly 300 million people in 2021. Many of these breaches were due to the lack of secure digital identity.

To counter this the Federal Government wants to “encourage and enable investments in strong, verifiable digital identity solutions that promote security, accessibility and interoperability, financial and social inclusion, consumer privacy, and economic growth.”

As the CEO of one of the leading companies developing verifiable digital identity solutions (what we at Indicio call “Trusted Digital Ecosystems”) and as a board member of the Hyperledger Foundation, an organization that supports open source technologies based on digital ledger technology, this is a strategic goal to applaud.

One of the remarkable things we have seen with open source verifiable digital identity is that it has been embraced by businesses and governments alike: everyone who sees the technology in action immediately sees how it is the building block for digital transformation: a way to upgrade web2 and tangible infrastructure for creating web3. With verifiable credentials, anything can be given an identity and that identity and the data associated with it can be verified seamlessly. Decentralized Ecosystem Governance — a machine-readable way of managing roles, rules, and trust within a verifiable identity ecosystem — solves the problem of governance, elegantly.

The ability to implement seamless verification transforms every aspect of digital interaction. If you can trust the data, you can devise processes, products, and services that are frictionless and trustworthy, whether it be proving you own a bank account or want to share your health records or cross a border. Again, this is already happening.

We reincorporated Indicio to become a public benefit corporation because we believed that advancing decentralized identity was a public good that would bring material benefit to everyone. We have encouraged our engineers to embrace work in the open-source communities to help develop new capacities and common standards—and we have encouraged our customers to get involved in these communities too. As the White House and the Federal Government move forward, we hope they will recognize the enormous progress that has been made, that the moonshot worked, and now we’re ready for the stars.

_____

To get involved in the Hyperledger Foundation’s decentralized identity community, join us on Discord in our Hyperledger Aries and/or Hyperledger Indy channels. All are welcome!

Mar 01

Love0

Welcome to the new Hyperledger Foundation Marketing Committee leaders

By Hyperledger Blog, Governance

Codified in the Hyperledger Foundation Charter, the Hyperledger Foundation Marketing Committee is a driving force in the work we do building the enterprise blockchain market. It’s a members-only group that is led by a nominated and elected chair and vice chair.

This year, we welcome a new chair: Helen Garneau, CMO of Indicio. Helen served as vice chair previously. Our new vice chair is Maryam Mahjoub, CMO of Simba Chain. As the leaders of the marketing committee, Helen and Maryam will guide messaging and marketing strategy for Hyperledger Foundation and work to maximize growth opportunities for members of all sizes. To foster an active community of marketing and business leaders, the monthly Marketing Committee call, held the first Tuesday of each month, will transition to the Business Development call.

This shift in focus for the monthly call is just one of the signs of Helen’s and Maryam’s new leadership. We asked them to share some of their thoughts on this committee, their roles and the market in general. Read on for their answers:

What is the marketing committee? Who should be part of it?

Helen: The Hyperledger Foundation Marketing Committee is essentially a working group for enterprise marketers from across the Hyperledger Foundation membership. Participation primarily consists of being part of the marketing email alias, where members can share news and learn about marketing updates and opportunities, and a monthly meeting for representatives from each member company to have the opportunity to learn more about the communications strategy and get a peek into the marketing and PR efforts of the Hyperledger Foundation. Members walk away with tips, content, and opportunities to incorporate into their own marketing strategies and campaigns.

The real magic of the Marketing Committee is when members participate and use the opportunity to announce the projects, products, and events they are involved in. This meeting, and the associated email list, is a place for connection among the members of the Hyperledger Foundation. Don’t feel limited to having someone in a traditional marketing role attend the meeting or follow the emails. I encourage members to make sure they have someone from their team participate, read the emails from other members, and take notes from the meeting. This could be from the CEO’s office, the business development team, PR, events, or comms teams. All are welcome!

The collective mindshare of the Hyperledger Marketing committee is probably one of the most valuable PR and Marketing resources in all of enterprise blockchain!

Maryam: The Marketing Committee has helped me understand what are the opportunities within the foundation for marketing to other organizations interested in blockchain technology. It’s also provided the opportunity to discuss the unique challenges we face in the space with my counterparts at other organizations. Anyone who wants to gain more insights on how to market their brand to other members or in general would benefit from participating.

What are some of your top priorities for 2023?

Helen: If you haven’t picked up on it already, my goal this year is to entice more Hyperledger Foundation members to interact with the marketing committee. It is my honor to Chair the Hyperledger Marketing committee. I’ve participated in this group for nearly five years. Starting out, I didn’t really understand how to communicate the open source advancements and projects that our team was engaged in, but it was this group that really opened my eyes to the ways that I as a marketer can add value to my company and how to communicate about our participation in the open source projects. I hope to bring more markers and business development representatives into the fold of the regular happenings of the Marketing Committee.

I’d love to see more members sharing news, attending calls, and leveraging the plethora of marketing opportunities that the Foundation offers. The speaker’s board, use cases, vendor listing, event participation, monthly content themes, and inclusion in press releases are just a few of the benefits included in member benefits for dues paying members.

Along with seeing more existing members leveraging their membership benefits, I also look forward to onboarding more marketers to our newly renamed monthly Business Development meeting. The Hyperledger Foundation is bringing on new members every month, and I’d love to provide ways for their marketing representative to become aware of the benefits, resources, and tools so they can make a smooth transition into the Marketing Committee.

Maryam: As a marketer, my goal is to garner more awareness and understanding of SIMBA Chain. However, collectively, we still have a long journey ahead in the adoption of blockchain technology. So a major goal is to focus on providing education of the capabilities (and limitations) of blockchain in various industries – helping garner more interest from innovation teams and more understanding from web2 companies who are curious about blockchain but don’t know where to start. I’m also excited about working with other blockchain companies – discovering how we can work together to grow our customer base, how our technologies can align for a better solution, and so on.

What, in your experience, can organizations gain from tapping into Hyperledger Foundation marketing and business development activities?

Helen: Companies and organizations that are already dues paying members of the Hyperledger Foundation have the opportunity to tap into a wealth of collective industry knowledge across one of the largest and most active communities at the Linux Foundation and hear from the leaders in enterprise blockchain. There is no other equivalent to what the Hyperledger Foundation Marketing Committee offers. Every single member of the Hyperledger Foundation has the opportunity to become further informed about enterprise blockchain market traction, campaign and communications lessons learned, and tap into opportunities for further collaboration.

Maryam: Hyperledger Foundation offers access to a group of organizations actively building (or looking to build) on the blockchain. This audience is very hard to find elsewhere. Most events, media and audiences are heavily geared towards crypto, and not business solutions. With tools like the newsletter, webinars, case studies and in person events, there is a lot for marketers to take advantage of, and various ways to get key conversations going.

What are some of the opportunities you see on the horizon? Challenges?

Helen: The Hyperledger community is doing a fantastic job defining enterprise blockchain and promoting the benefits of using distributed ledger technologies for a wide variety of real business challenges and opportunities. We’ve been writing, speaking, and educating the market about Hyperledger projects. Now is the time to promote and highlight the awesome deployments and projects from Hyperledger Members! Case studies are a fantastic resource to put some “legs” under the story behind the work that is being done in the community. I expect we’ll see more high-profile news coming out of our community very soon.

The challenge comes in getting members, most of which are moving a mile a minute, to take time to include Hyperledger in their promotion or launch plans. This community is primed to connect and engage with one another. I hope to encourage and see more cross-company collaboration and see more connections being made between vendor companies in the space.

Maryam: The negative media on NFTs and crypto has been hard on the entire industry. The current market slow down has also put a lot of innovation projects on hold. Realistically, blockchain is still at the innovation stage, slowly creeping into early adoption. We have a long road ahead until we reach the chasm. I think one critical piece most of us have not yet resolved is “what headache are we curing.” The more explicit we can be about that, the more we will make blockchain not just desirable but a necessity.

We also need to reduce the barriers to entry before we see any real leaps in the space. How do we introduce a complex technology and its wide array of benefits without being overwhelmingly technical or complicated? How do we highlight the possibilities of our solutions, without real world use cases to back them up?

I think we all recognize the opportunities blockchain provides. To foster them, we need to resolve these challenges.

How do people get involved?

Helen: The easiest way to engage with the Hyperledger Foundation Marketing Committee is to sign up on the email list and get the monthly meetings in your calendar. Reach out to Benjamin Thomas and the Marketing and PR email aliases with any news, announcements, or questions. We’ll be happy to answer any questions or help promote your wins across the enterprise blockchain community!

Maryam: In the prisoner’s dilemma, the best outcome is when both parties cooperate. This applies here as well. We are a community – we thrive with cooperation and collaboration. I would love to hear from others what they are missing in their go to market strategy or what they are looking to achieve in 2023. I have no doubt one person’s feedback will resonate with the majority of us. So together we can work to address them and improve activities for everyone. I think open dialogue, networking and leveraging the marketing activities set in place by Hyperledger Foundation will help us all move the needle.

___

The monthly, members-only Business Development call is the first Tuesday of every month at 11:00 am ET/8:00 am PT. There is also a monthly call for Marketing Committee members in Asia Pac. It is the second Tuesday of the month at 11:30am India ST/2pm HKT Singapore/3pm JST. For more details, go here.

To sign up for the marketing committee email list, please contact the Hyperledger Foundation marketing team. If you aren’t a Hyperledger Foundation member, talk to us about joining so you can be part of this grow-focused community. Email our membership team here.

Feb 27

Love0

Hyperledger Mentorship Spotlight: Visual Studio Code support for Hyperledger Caliper artifacts

By Eravatee Raje Blog, Hyperledger Caliper, Hyperledger Mentorship Program

What did you work on?

Project name: Visual Studio Code support for Hyperledger Caliper artifacts

A little background to the project

Hyperledger Caliper is a tool for performance benchmarking of existing Hyperledger projects. The goal here was to build a Visual Studio Code (VS Code) extension for Caliper to help developers understand the capabilities of Caliper and help work with it more effectively.

Objective

The primary objective of the project was to have a Visual Studio extension that provided assistance with the multiple configuration files the user has to write and to develop a way to index the config files on VS Code.

Mentor

Attila Klenik, Budapest University of Technology and Economics, Critical Systems Research Group

What did you learn or accomplish?

Achieved Outcomes

Create a schema for the benchmark configuration file of Hyperledger Caliper.
Create a schema for the Hyperledger Fabric network configuration file of Caliper.
Create a schema for the Ethereum/Hyperledger Besu configuration file of Caliper.
Create a schema for the runtime configuration file of Caliper.

Obstacles faced

I was supposed to create YAML schema files to help with creating schema for configuration files. The VSCode API does not traditionally come with support for YAML schema. It was complicated to navigate this issue. But we successfully found a solution for it. I initially attempted to build a solution by myself but, during the research, bumped into a plugin designed by RedHat that helped me achieve what I set out to do.

Highlights of my experience

I learned that the open source developer community is very helpful and friendly. My mentor was available to answer questions and go through issues, if any, with me.
It was surprising how smoothly I could interact with my mentor and complete my tasks despite the time zone differences. The world is truly becoming a smaller place with all the technology that bridges gaps and allows for seamless work.
It was very exciting to see my very first open source contribution go up online and for me to see my commit on the Hyperledger Caliper repository. It is a moment I will cherish.

What comes next?

The extension itself can be developed a lot more with a few added features, such as having a mechanism to identify and alert users to which configuration files are essential, to provide for a more seamless experience for the developer using it. It would be interesting to see it grow and become a tool that many people use. I personally wish to continue working with the open source community for more exciting work and contributions.

Feb 23

Love0

Citopia and the Integrated Trust Network (ITN): MOBI Zero Trust Approach to Web3 Multiparty Business Automation

By Tram Vo, CEO & Founder of MOBI, the Mobility Open Blockchain Initiative Blog, Hyperledger Fabric, Identity

The compelling network economics of centralized platforms prove an existential threat to traditional businesses. Companies that control the most powerful platforms are rewarded with exponential growth, insurmountable competitive advantage, high multiples, and access to cheap capital. Needing centralized platforms to validate counterparty identities and automate transactions, non-platform companies are often forced into business arrangements that see their business models commodified and their value chains held hostage.

Corporate support for open source collaborative efforts are, in part, a response to the centralizing tendencies of Web2. Open source blockchain technologies such as those hosted by Hyperledger Foundation promise to leverage the existing trust within corporate transaction networks by automating traceability, settlement, and audit processes. Public and private Distributed Ledger Technologies, together with World Wide Web Consortium (W3C) open standards — Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) — enable the creation of decentralized Zero Trust Networks. These networks allow companies to avoid centralized platforms when digitizing extended value chains and automating multiparty transactions while lowering the cost of trust.

Zero trust is a security model that assumes all network traffic is untrusted until proven otherwise. Organizations do not automatically trust traffic, even if it originates from a seemingly trusted source. Instead, all traffic is validated before being allowed to pass. By implementing strict access controls and continuous authentication of all entities entering the network for all transactions, zero trust:

Improves security by reducing the attack surface and minimizes the potential for data breaches
Strengthens compliance by helping organizations meet regulatory requirements and industry standards for data protection
Provides greater visibility into network traffic and activities, allowing organizations to identify and prevent potential threats

To develop and implement zero trust Web3 technologies for multiparty business processes, 35 companies joined together in early 2018 to launch MOBI, the Mobility Open Blockchain Initiative, a global nonprofit smart mobility alliance of forward-thinking vehicle manufacturers (OEMs), NGOs, government agencies, financial institutions, smart city leaders, and technology companies.

Since its launch, MOBI has continued to grow its membership and to date has created and released 17 blockchain-based standards to enable a zero trust environment for multiparty applications. These standards include:

MOBI VID (2019) was the first W3C DID-compliant vehicle identity based on the internationally accepted vehicle identification number (VIN) standard
MOBI Trusted Trip (2021) applied W3C VCs and DIDs guidelines to link trusted identity and location into a verifiable trip
Battery identification number (BIN) (2022) provided the necessary foundation for battery supply chain track-and-trace and the global Battery Passport

In 2020, MOBI began building a two-layer, member-owned and operated zero trust Web3 infrastructure (Citopia and the Integrated Trust Network, or ITN) to demonstrate MOBI Standards, enable multiparty applications interoperability, and allow entities to perform privacy-preserving, tamper-evident transactions via Self-Sovereign Identities (Digital Twins).

***Figure 1****: Citopia and the ITN are separated into two distinct organizations, each with its own legal structure, governance, network, and operators.*

Citopia is a federated Web3 marketplace leveraging VCs (or transactions) and Zero-Knowledge (ZK) cryptography to enable any entity to verify that another entity was present at a location, completed a trip, and performed relevant activities. Citopia VCs are machine-readable, privacy-preserving verifications for business automation in a zero trust ecosystem. These transaction verifications can be performed by any ecosystem stakeholders and do not rely on centralized certificate authorities.

The ITN is the first cross-industry permissioned network where participants agree to common identity standards and shared governance. As the first Zero Trust Certificate Authority for IoT, eCommerce, and business automation, the ITN acts as a global trust anchor for digital business. It is protocol, cloud, and technology agnostic. It’s currently built on Hyperledger Fabric with a Arbitrum One (EVM compatible optimistic layer 2 rollup on Ethereum) to anchor DIDs onto Ethereum as well. Plans call for this to be a multichain network.

Using the ITN, organizations can create secure digital services that are locally highly performant while also decentralized. The ITN is backed by three global industry consortia (MOBI, MEF, AAIS).

Together, Citopia and the ITN form the foundation for a community-owned and -operated Web3 infrastructure for connected ecosystems and IoT commerce. MOBI and its members are currently focusing on a selection of foundational use cases, including:

Platform agnostic global battery passports
Using in-vehicle telematics to provide real time accident data for reports and collision repair, using Web3 technology for data privacy
Multiparty supply chain track-and-trace
Zero-knowledge proof of vehicle location
Multimodal trip planning, booking, and payment
Maintenance and recall traceability

Figure 2: Working together to enable zero trust business automation, Citopia and the ITN offer end users and providers security, privacy, speed, and control.

Although Citopia and the ITN have some similarities to other industry networks, there are important differences that will enhance the speed, privacy, security, and regulatory compliance of connected ecosystems.

First, any organization can use Citopia and the ITN services. However, membership is required to run nodes on Citopia and/or the ITN.

Second, whereas most Web3 solutions combine DIDs registry (the ITN) and transactions processing (Citopia) on the same infrastructure/company, we choose to separate them into two distinct organizations, each with its own legal structure, governance, network, and operators. This increases decentralization by reducing the market power and information advantage of any single organization. Neither Citopia nor the ITN gets such dominant network effects that users can’t switch/leave, hence neither can abuse its position, rent seek, or meaningfully change the economics of the ecosystem.

***Figure 3****: A closer look at how Citopia and the ITN function together.*

Third, the separation permits Citopia to use any DIDs registry network following W3C DIDs standard, meaning that Citopia users aren’t locked to the ITN (and vice versa) and can use other networks.

Fourth, both Citopia and the ITN are vendor, technology, and protocol-agnostic, allowing applications interoperability and scaling of complex, cross industry, multiparty value chains.

Finally, through using Citopia and the ITN, DIDs are the only things registered and stored on chains. All personal and competitive information resides in the Self-Sovereign Digital Twin (SSDT) stored locally on the owner’s device or provider’s server and remains under the control of the owner, making the scraping and collection of data impractical, eliminating honeypots, reducing attack vectors, and improving security for all users.

***Figure 4****: Citopia SSDTs are designed to ensure the highest possible level of data privacy and security for users and providers while enabling seamless application interoperability.*

Through Citopia and the ITN, companies have the opportunity to combine the best of both worlds — building and leveraging applications that meet enterprise security, privacy, and compliance requirements while avoiding vendor or technology lock-in. Companies can retain their brand, their business models, and their customers without paying significant economic rent to a centralized certificate authority, platform, or data monopolist. They can reap the full benefits of value chain automation and digital efficiency in a shared zero trust ecosystem where the network effects accrue to the community. More information on MOBI’s standards, Web3 infrastructure, and multiparty pilots can be found on our website.

___

For more on displacing centralized platforms with zero trust networks, join Mobi’s Tram Vo and leaders from across the insurance market for a discussion about proving the efficacy and value of enterprise-level blockchain. It will cover the technical and business challenges the insurance market, like other multiparty industries, must tackle in the move to Web3.

The webinar, Measuring and Proving Enterprise-scale Blockchain Technology in the Insurance Industry, will take place on Thursday, March 30, 2023, at 1pm ET / 10am PT. To register, go here.

Feb 16

Love0

Benchmarking Hyperledger Fabric 2.5 Performance

By Dave Kelsey, Hyperledger Caliper Maintainer Blog, Hyperledger Caliper, Hyperledger Fabric

Hyperledger Fabric performance is a question that comes up frequently as users try to compare it to transactional databases or other blockchain platforms in terms of the maximum TPS (Transactions Per Second). Performance in a Hyperledger Fabric network is complex because in an appropriately deployed network there will be many organizations participating, each with their own hardware and networking infrastructure, along with different solution characteristics such as number of channels, chaincode implementations and policies.

Hyperledger Fabric 2.x has performance improvements over Hyperledger Fabric 1.4. Fabric 1.4 is now out of LTS and should not be used in production environments. Fabric 2.5 is the latest LTS version and includes the new peer Gateway service. When used with the new gateway SDKs, applications will demonstrate improved performance relative to applications based on the legacy SDKs.

Hyperledger Fabric documentation now has a section on Performance Considerations that can be found in the 2.5 and latest versions of the Hyperledger Fabric documentation. This content provides useful insight into helping to achieve a performant Fabric network. It doesn’t include information about certain scalability concerns such as large numbers of PDCS, channels, organizations, etc.

Performance Benchmarks

In conjunction with the new Performance Considerations documentation, the community has leveraged Hyperledger Caliper for some initial performance benchmarks for Hyperledger Fabric 2.5. This post shares the benchmark results for a sampling of Hyperledger Fabric 2.5 builds to give an example of transactions per second (TPS) achieved, based on a very specific chaincode running on dedicated hardware.

Hardware and Topology

The Hyperledger Fabric topology used was two peer Organizations (PeerOrg0, PeerOrg1) with a single peer node in each and one Ordering Service Organization (OrdererOrg0) with a single orderer service node configured for Raft. TLS was enabled for each node.

Each node had the same identical hardware

Intel(R) Xeon(R) Silver 4210 CPU @ 2.20GHz
40 Cores made up of 2 CPUs. Each CPU has 10 physical cores supporting 20 Threads in total
64Gb Samsung 2933Mhx Memory
MegaRAID Tri-Mode SAS3516 (MR9461-16i) disk controller
Intel 730 and DC S35x0/3610/3700 Series SSD attached to disk controller
Ethernet Controller X710/X557-AT 10GBASE-T
Ubuntu 20.04

The machines were all on the same switch.

Hyperledger Fabric was deployed natively to three physical machines (i.e., the native binaries were installed and executed; no container technology such as Docker or Kubernetes was used).

Hyperledger Fabric Application Configuration

LevelDB was used for the state database
Gateway Service Concurrency limit was set to 20,000
A single application channel was created and the 2 peers and orderer were joined to this channel
- The application capabilities were set to V1_4 so as to use the old lifecycle deployment. All other capabilities were set to V2_0 (capability level should not impact performance).
No system channel exists only the application channel
Go chaincode without the Contract API was deployed (fixed-asset-base from hyperledger Caliper-Benchmarks)
Endorsement policy 1 Of Any was specified for the chaincode
No private data was used
Default Fabric policies and configurations (note that in 2.5 SendBufferSize now defaults to 100) excluding anything previously mentioned
No range queries or JSON queries
The network was enabled for TLS, but not mutual TLS

Load Generator

Hyperledger Caliper 0.5.0 was used as the load generator and for the report output. Caliper was bound to Fabric 2.4, which means it used the peer Gateway Service to invoke and evaluate transactions. All transactions were generated from the same organization to its gateway peer.

The load itself was defined from fixed-asset in Hyperledger Caliper-Benchmarks.

Caliper used four bare metal machines to host remote Caliper workers and also to host a single Caliper manager to generate the load on the Hyperledger Fabric Network. In order to generate enough workload on the Fabric network, we have to use multiple Caliper workers, which equate to the number of current clients connecting to the network. In the results section, the number of Caliper workers is provided.

Diagram of overall Topology

Results

These results were generated against the latest builds of Hyperledger Fabric 2.5 and utilized the default node and channel config values. Specifically the following block cutting parameters were used:

block_cut_time: 2s
block_size: 500
preferred_max_bytes: 2Mb

In order to be able to push enough workload through without hitting concurrency limits, the gateway concurrency limit was set to 20,000.

In summary the following benchmarks are presented here:

Blind write of a single key with 100 Byte Asset Size (a create asset benchmark)
Blind write of a single key with 1000 Byte Asset Size (a create asset benchmark)
Read/Write of a single key with 100 Byte Asset Size (an update asset benchmark)
Read/Write of a single key with 1000 Byte Asset Size (an update asset benchmark)

The following should also be noted

Only a single channel is used and thus the peer doesn’t utilize its full resources (as described earlier a peer can achieve more throughput if more than one channel is utlized).
The chaincode is optimized for these tests. Real world chaincode will not be as performant.
The Caliper workload generator is also optimized for pushing transactions. Real world applications will also have a client implementation generating the workload which will introduce some latency.
The Caliper workload generator is sending transactions to a single gateway peer on the same organization. Real world applications are likely to have multiple organizations sending transactions concurrently. There is the potential for higher TPS results if the workload is sent to from multiple organizations rather than just the same organization.
Utilizing the gateway service means that blocks are not received by the client (Caliper) via the delivery service to determine whether a transaction has completed, improving the performance of the client and the network compared to using the legacy node SDK.

Blind Write of a single key 100 Byte Asset Size

A Blind write is a transaction that performs a single write to a key regardless of whether that key exists and contains data. This is a Create Asset type of scenario.

Caliper test configuration:

workers: 200
fixed-tps, tps: 3000

The TPS here is the peak. Trying to push beyond this resulted in unexpected failures and a drop in overall throughput.

Blind Write of a Single Key 1000 Byte Asset Size

Caliper test configuration:

workers: 200
fixed-tps, tps: 3000

Here we see that we can achieve roughly the same throughput (i.e., the peak) but latency increases.

Read Write of a Single Key 100 Byte Asset Size

This is a test where the transaction will randomly pick an already existing key with data, read it, then modify that key. The world state was loaded with 1 million assets for this test to reduce the chance of using the same key in two concurrent transactions resulting in MVCC_READ_CONFLICT validation errors. In this example, the TPS rate was low enough and fortunate that no MVCC_READ_CONFLICT validation errors were received.

Caliper test configuration:

workers: 200
fixed-tps, tps: 2550

Note that the above results were done with an expectation of no failures. We see that the fabric network was not reaching capacity in this test as latency remains very low.

Read Write of a Single Key 1000 Byte Asset Size

The above was repeated using a 1000 byte asset size.

Caliper test configuration:

workers: 200
fixed-tps, tps: 1530

Note that the above results were done with an expectation of no failures. We see that the Fabric network was not reaching capacity in this test as latency remains very low.

Acknowledgements

I would like to thank Shivdeep Singh for running the Hyperledger Caliper benchmarks to get the results presented in this blog and Dave Enyeart for reviewing the content.

Feb 13

Love0

Hyperledger FireFly V1.2 Is Now Available

By Nicko Guyer, Sr. Full Stack Engineer at Kaleido and Hyperledger FireFly Community Lead Blog, Hyperledger FireFly

Since the launch of Hyperledger FireFly 1.1 in October, the community has been hard at work on a number of improvements, and today we’re pleased to announce that version 1.2 is now available. In version 1.2, we’ve introduced a number of changes focused on the user, making it easier and faster than ever to make and run your web3 applications at scale.

Token API Enhancements

We’ve added support for a much wider variety of ERC-20, ERC-721, and ERC-1155 contracts.

OpenZepplin Wizard Support: Hyperledger FireFly’s token APIs now work for variations of ERC-20, ERC721, and ERC-1155 contracts generated by the OpenZepplin Contract Wizard. The older sample token contracts ERC20NoData and ERC721NoData contracts have been deprecated.

Experience Enhancements

Additional controls and feedback make the Hyperledger FireFly experience even more powerful.

Error Feedback: Custom smart contract error types are now returned on the API.
Data Management: Data objects and blob rows may be removed from the FireFly database and Data Exchange microservice. This can be very useful if your organization has data retention requirements for sensitive, private data and needs to purge data after a certain period of time.
Dynamic Reload of Core Config File: You can now edit the configuration file and have FireFly automatically reload it, without having to restart the whole service.
Distributed Request Tracking: The X-FireFly-Request-ID HTTP header is now passed through to FireFly dependency microservices to allow for distributed request tracking through various systems.
Custom HTTP Header Passthrough: Custom HTTP headers can be passed through to FireFly dependency microservices.

Blockchain Connector

Evmconnect is now the default blockchain connector for Ethereum-based FireFly stacks. Differences compared with Ethconnect include:

Policy Management Engine: Engine for gas cost estimation and automatic transaction resubmission
Signing and Nonce Management: Compatibility with public blockchains

The Next-gen Platform

Hyperledger FireFly 1.2 is another step toward bringing the enterprise closer to realizing the full potential of web3—both with permissioned chains and connections to public ecosystems. It’s designed to make application development easier and faster to deploy.

If that’s something you’re interested in, we invite you to come be part of our community. You can learn more in the Hyperledger FireFly docs and download the CLI on the Hyperledger FireFly Github. If you have any questions, find us in the FireFly channel on the Hyperledger Discord.

Feb 08

Love0

Project Services Update: Ensuring Hyperledger Projects and Labs have Access to the Tools and Services They Need to Grow

By Ry Jones and David Boswell, Community Architects Blog, Hyperledger Foundation Staff Corner

The Hyperledger Foundation offers a strong backbone of services and tools to open source projects in the blockchain ecosystem. These are built to sustain projects’ needs for growth and adoption and extend beyond just code management and technical decisions. When developers start a new project or a new lab at the Hyperledger Foundation, we want to make sure that they will be successful and regularly improving the tools and services they have access to is a big part of that.

Like many enterprise open source communities, over the years Hyperledger Foundation staff has worked with project maintainers and the Technical Oversight Committee (TOC) to assess tools and services and make them available to the community. These project services are regularly reviewed and updated as community requirements change and projects mature.

Just as open source development continues to evolve, so too do the many tools used to support the projects. For example, over 20 years ago in the early years of open source, launching a project might have included setting up an IRC server for chat, putting the code on a CVS server and setting up Bugzilla to track bugs and issues Developer tools improve rapidly, and communities use a whole new set of tools today. We need to keep adapting as things evolve to serve our projects. We did this last year when the Chat Task Force reviewed the chat tool we were using at the time and they recommended a move to Discord to provide a better experience to community members.

We’ve started this year by reviewing the available tools and services and seeing where we need to bring in something better or add something new. This post will explain the recent changes we’ve been making.

Recommended List of Developer Tools

We’ve created a new page on the Hyperledger wiki that documents all of the tools that are available. This page breaks the available options down into a set of categories to help developers and maintainers make decisions about what tools to use. This includes a recommended set of tools to use for documentation, continuous integration, artifact storage, communication and issue tracking. In the past, this information hasn’t been as clear as it could be and we want to save people the time of evaluating a range of tools on their own when we have done that work and can offer our guidance.

There are tools we offer beyond the recommended tools that are available to address other specific needs. To help give guidance for all tools, we’ve clearly documented which tools we plan to provide on a long-term basis as well as those we may not be able to support past the short term for a variety of factors. We also specify tools we currently offer while we work to move projects to better tools as well as tools we used to provide but no longer do.

The set of legacy tools in the community reflect that Hyperledger was founded in 2015 and many of the tools we’ve relied on in the past now have better alternatives. For one example, we have been using Azure Pipelines but anticipate it will be replaced by Github Actions in the near future.

Additional Resources for Documentation and Translation

Documentation is critical to the health and success of open source projects. However, this is an area that can get overlooked when talking about tools and services since the focus is often on how to help developers create the code instead of document it. We’ve been looking at ways to help get more documentation activity happening in the community and have some ideas we are going to try this year.

Our annual Mentorship program is a prime opportunity to bring more people into the community to work on documentation for projects and labs. Last year a mentee helped develop documentation for Hyperledger Cacti that was delivered in the Blockchain Interoperability with Hyperledger Cacti workshop in November. Based on the success of that project, we are reserving several spots in the 2023 program for documentation related efforts. If you are involved in a project or lab and would like to work with a mentee who can help you improve existing docs or add new docs, then consider signing up as a mentor. The call for projects and mentors is underway.

Translating documentation into other languages is also a key part of making this information available to everyone who wants to use or learn about a project. Only around 20% of the world’s population speaks English so, if we provide our content only in English, it dramatically limits who is able to get involved with using or contributing. We have had some success with community members translating content, such as Hyperledger Fabric documentation, into other languages. In the process, we learned that we could benefit from tools that are specifically focused on helping people with their translations. We are looking into other options this year and welcome feedback about what people would recommend or find useful.

Exploring Other Changes Around Accessibility and Security

Later this year we’ll also be looking into ways to provide more services around security and accessibility. On the list: ways to improve the existing process for running security audits, expand the bug bounty program to more projects and help for rolling out security best practices. We also want to make sure that as many people as possible can use our tools and are not running into barriers, so we plan to conduct an accessibility audit. The audit will help us identify areas where we can make improvements that enable more people to take part in the community.

If you have questions about any of this or would like to suggest additional tools and services for us to take a look at, feel free to reach out. And, if you’re a maintainer of a project or lab and would like to talk more about how to get help using any of this for the development you’re doing, let us know. You can reach out to us at community-architects at hyperledger dot org.

Previous 1 2 3 4 … 134 Next