Introducing Hyperledger Fabric 2.2 LTS Support on Amazon Managed Blockchain

As of January 5, 2022, Amazon Managed Blockchain supports the creation of new fully managed Hyperledger Fabric blockchain networks with the current long-term support (LTS) version 2.2. The milestone upgrade to Hyperledger Fabric 2.x brought a variety of useful features and improvements to Hyperledger Fabric, including refinements to features added in 1.4, and subsequent 2.1 and 2.2 releases were intended to improve stability and add minor features.

Amazon Managed Blockchain is a fully managed service that allows you to set up and manage production-grade blockchain infrastructure with just a few clicks. Amazon Managed Blockchain eliminates the overhead required to create both private Hyperledger Fabric networks and Ethereum full nodes on the public mainnet and testnets. With the Hyperledger Fabric private blockchain offering, once your network is up and running, Managed Blockchain makes it easy to manage and maintain your blockchain network, including critical tasks like managing certificates and facilitating network governance to add or remove member organizations from your blockchain network. With the launch of Hyperledger Fabric 2.2.4 LTS, you can take advantage of the latest features and improvements to help you build scalable, more secure, and production-ready blockchain applications.

In this post, we discuss the following four improvements and migration considerations. Following the v1.4 release, Hyperledger Fabric v2.x brought several changes to make blockchain networks more efficient, scalable, and usable:

• A brand new chaincode lifecycle that enables decentralized governance for the deployment of chaincode and a more developer-friendly process for deploying and managing chaincode
• A set of new functionalities that enables a wide variety of new private data patterns for granular control over which network members have access to certain data on the blockchain
• Foundational upgrades to core infrastructure components within Hyperledger Fabric that may improve performance, stability, and more
• Chaincode environment enhancements that bring more modern versions of Go, JavaScript, and Java environments

This is not an exhaustive list of changes brought in Hyperledger Fabric’s 2.x updates. For more information, see What’s new in Hyperledger Fabric v2.x on the official Hyperledger Fabric documentation.

Decentralized governance for smart contracts: The new chaincode lifecycle

The largest and most far-reaching change in Hyperledger Fabric’s milestone 2.x release is the monumental improvement to the chaincode management process on the network. In earlier versions of Hyperledger Fabric 1.x, chaincode was managed on the network using a process that generally allowed a single organization to take the lead on determining chaincode parameters and endorsement policies without explicit approval from other network members in the channel. This process was defined by the install/instantiate flow for net-new chaincode on the network, and the install/upgrade flow for new versions of existing chaincode, as illustrated in the following diagram.

The legacy chaincode lifecycle process required each member organization in a channel to install the same chaincode source code to their peers, but only one single organization was required to instantiate the chaincode and set the chaincode parameters. This gave one single organization more influence over the chaincode lifecycle process than other organizations in the channel, because the chaincode parameters like the endorsement policy could be set by the instantiating organization without agreement from other channel members. Furthermore, upgrades to an existing piece of chaincode could be facilitated by one organization in a channel without approvals from other organizations in the channel or guarantees that they had installed the new chaincode version.

In Hyperledger Fabric 2.0, a new decentralized chaincode lifecycle process was introduced to alleviate the weaknesses of the legacy model. The separate two-step process for both new and existing chaincode was replaced with a single four-step model to cover both net-new and upgrades to existing chaincode, as illustrated in the following diagram.

This new chaincode lifecycle provides a mechanism to facilitate decentralized governance of chaincode, which allows much broader configurability for how chaincode is implemented in a channel and how each organization in that channel can participate in the process democratically. Instead of a single organization instantiating the installed chaincode and setting parameters, a chaincode definition must be agreed upon by any channel members who will use the chaincode. The chaincode definition is where critical parameters can be set, such as the endorsement policy for transactions that interact with the chaincode itself. This decentralized agreement process is also used for upgrading chaincode, which replaces the upgrade process led by a single organization in the legacy lifecycle process.

Along with this new model for reaching agreement on chaincode to be activated in the channel, Hyperledger 2.x introduced other features that make the process of deploying and using chaincode more efficient and effective. For example, the process of updating a chaincode instance’s endorsement policy or private data collection configuration no longer requires reinstallation of chaincode. This can reduce development time and maintenance effort on networks that rely on frequent changes to channel membership and chaincode. Furthermore, you can install a chaincode package one time and deploy it multiple times to one or more channels, eliminating the arduous process of installing the same chaincode package multiple times to deploy copies of the same chaincode, as was required in Hyperledger Fabric 1.x.

Developers who are building chaincode applications can also use this decentralized agreement process for chaincode deployment within your business logic to facilitate the definition and fulfillment of terms from various organizations in a business process. Only after all conditions are met by each organization does a finalized transaction occur.

If you’re operating on a Hyperledger Fabric 2.2 network, you can enable the new chaincode lifecycle features in your channels by updating the channel configuration such that the Application capability parameter is V2_0. Learn more about enabling the latest chaincode lifecycle and all the features available in this latest version.

In Hyperledger Fabric 2.2.0, the legacy 1.x chaincode lifecycle was deprecated. Applications that utilize the 1.x chaincode lifecycle should be upgraded to use the new 2.x chaincode lifecycle ahead of removal in future versions.

New patterns for private data

As an enhancement to the private data collections feature introduced in Hyperledger Fabric 1.x, which allows you to more granularly control access to data and transaction data within a channel, Hyperledger 2.x introduces more flexible models for sharing private data with organizations across collections.

In addition to a well-established pattern where you define standalone policies and collections for each group of organizations with which data must be shared, you can now share and verify private data in a variety of different patterns. For example, you might want to share private data with many different regulatory or oversight organizations on an individual basis; you can use the new implicit collections feature to share private data on a per-organization basis with each of these required organizations. Or you might want to build a track-and-trace solution for a supply chain where there is both private metadata and public metadata; you can restrict private metadata to each relevant organization’s private data collection while leaving a public key mapping accessible to all organizations.

Many of these new patterns and concepts rely upon new features like collection-level endorsement policies and powerful chaincode methods like GetPrivateDataHash(), which is used to verify private data in a collection by its hash that is recorded on-chain. You can use it to share and verify private data across collections or with organizations that don’t belong to collections in which that data resides. For more information about the variety of private data patterns enabled by Hyperledger Fabric 2.x features and examples, refer to Private data.

Core component enhancements

Hyperledger Fabric 2.x brought a series of improvements to the underlying foundations of Hyperledger Fabric and its operative components. Arguably the most critical piece of infrastructure for an organization that uses Hyperledger Fabric is the peer node, which serves as the primary interaction point for an organization to read, write, and subscribe to events on the Hyperledger Fabric network. Peer nodes are the crux of many operations in Hyperledger Fabric, such as storing a copy of the ledger state, managing the chaincode lifecycle, and handling requests from Fabric client applications. For high availability, many organizations run more than one peer node to interact with the blockchain from their client applications. Other components like ordering service nodes are also critical for ordering endorsed transactions and consummating them into blocks during network operations.

In the new versions of Hyperledger Fabric, some key enhancements were made to the implementation of various network components. For example, peer nodes that use the CouchDB state database option can now utilize a performant local cache for improved read performance, which can reduce delays during the endorsement process and queries to the ledger.

Chaincode environment improvements

In addition to the chaincode lifecycle overhaul that Hyperledger Fabric 2.x introduced, it also brought updates to the underlying environments where chaincode is run. Chaincode itself is run from its source code in a containerized environment according to the language the chaincode is written in as defined in the chaincode definition; for example, chaincode written in JavaScript is run in a containerized Node.js environment.

By virtue of updates to the client libraries, the SDKs, and underlying environments for chaincode in Hyperledger Fabric, developers also have access to more modern versions of Go, Node.js, and Java when running chaincode, which is important for developers that need features from modern versions of these frameworks or updates to remain compliant. More specifically, Go v1.16.7, Node.js v12.16.1, and Java v11.0.4+11 are supported for Hyperledger Fabric chaincode run on Managed Blockchain.

As a result of changes made to the chaincode environment in Hyperledger Fabric 2.x, those using Go chaincode need to vendor the chaincode shim interface, because the ccenv environment for Go chaincode no longer includes this by default.

The notable features outlined in this post as well as other features released in Hyperledger Fabric 2.x are now available for AWS customers who create new Hyperledger Fabric networks on the AWS Management Console, via the AWS Command Line Interface (AWS CLI), or with AWS CloudFormation. Hyperledger Fabric 2.2 is the default framework version for Managed Blockchain on the console (see the following screenshot).

You can define it in your scripts when deploying your network via the AWS CLI or AWS CloudFormation.

Migration considerations

If you’re currently using Hyperledger Fabric 1.2 or 1.4 versions on Managed Blockchain or in your own environment hosted for example in Amazon Elastic Compute Cloud (Amazon EC2) or Amazon Elastic Kubernetes Service (Amazon EKS), and want to migrate to Hyperledger Fabric 2.2 on Managed Blockchain, you should understand the impact such a migration will have at the various layers of the architecture and what modifications you may need to make to accommodate the new platform or Hyperledger Fabric version.

For example, if you want to migrate an application from Hyperledger Fabric 1.4 to Hyperledger Fabric 2.2 without migrating the state of the 1.4 network ledger, you mainly have to focus on updating the chaincode, application code (Fabric client), and chaincode lifecycle operations. On the other hand, if you want to move the state of the Hyperledger Fabric 1.4 ledger, you have to manually migrate that state from one network to the other.

For other key considerations to take into account when moving from Hyperledger Fabric 1.4 to Hyperledger Fabric 2.x, refer to Upgrading to 2.2 from the 1.4.x long-term support release. However, some of these are managed for you as part of the fully managed nature of Managed Blockchain. The following are a few of the most critical areas for operators using Managed Blockchain:

• Enabling the new chaincode lifecycle process and migrating operations to utilize it
• Changes to Go chaincode that may require modifications to existing chaincode
• Creating channels with the latest capabilities (V2_0)
• Updating applications to use the latest Fabric client SDK

For non-production networks, the recommended approach is to deploy your chaincode to a new Hyperledger Fabric 2.2 network created from scratch. In instances where production networks store data that requires access long term, you have two options to maintain continuity:

• Continue to operate the 1.4 network with minimal peer node resources, shift net-new read/write operations to the new 2.2 network, and query the 1.4 network with client applications as needed via the existing endpoint
• Propagate the state data from the existing 1.4 network to a database such as Amazon DynamoDB or a ledger database with immutable characteristics like Amazon Quantum Ledger Database (Amazon QLDB) for future queries

If you want to migrate the state of your existing Hyperledger Fabric network to a new network on Managed Blockchain by replaying transactions, this approach presents significant challenges. Firstly, the destination network requires a new Fabric Certificate Authority (CA) to be created, and therefore member identities that wrote transactions on the original network aren’t the same on the destination network. Secondly, replaying transactions to a new destination network can render different ordering of transactions and result in an inexact copy of the network. As a result of these potential issues during migration via replaying transactions, this is not a recommended approach to migrating from Hyperledger Fabric 1.4 to 2.2.

Conclusion

In this post, we outlined some of the core improvements featured in Hyperledger Fabric v2.x, as well as migration considerations for those looking to migrate from an existing Hyperledger Fabric network to v2.2 now supported on Amazon Managed Blockchain. With this knowledge, you will be able to determine which Hyperledger Fabric version is ideal for your use case or workload. Get started building a Hyperledger Fabric blockchain network in minutes with AWS on Amazon Managed Blockchain here.

About the Authors

Forrest Colyer is a blockchain specialist Solutions Architect at Amazon Web Services. Through his experience with private blockchain solutions led by consortia and public blockchain use cases like NFTs and DeFi, Forrest helps enable customers to identify and implement high-impact blockchain solutions.