Understanding Fabric v2.0 Chaincode Lifecycle Improvements
In our previous blog post, we gave you a detailed overview of Hyperledger Fabric v2.0, the reason behind its release, the latest features added to this new version, and the comparison of Fabric v2.0 with previous Hyperledger Fabric versions. In case you missed reading it, here’s the link of our preceding post: https://bit.ly/3czcoRx
Hyperledger Fabric v2.0: A Perfect Fit for Enterprise-grade Production Environments
Ever since its first major roll-out, i.e. v1.0, back in 2017, Hyperledger Fabric (for all the right reasons) has been…
As promised, we’re back this week with another post to expand on that topic and offer a deeper look into each of the prominent features of Hyperledger Fabric v2.0. So, today, we’ll talk about the first major feature of Fabric v2.0, i.e. Decentralized Governance for Smart Contracts.
Before we dive deeper into this discussion, let’s give you a rundown of the topics we’ll be covering in this post:
- A brief about decentralized governance and new chaincode lifecycle
- Enhanced chaincode application patterns for collaboration and consensus
- A thorough explanation of how to use the Fabric Chaincode Lifecycle to install, define, and manage chaincode on your network
- How to use the new Fabric chaincode lifecycle to your best advantage
Now that you’ve got a glimpse of the key pointers to be talked about in this post, let’s get on with the nitty-gritty details.
First things first, we will begin with the brief of the decentralized feature, which is undoubtedly the biggest and most significant enhancement in Fabric v2.0.
The concept of “decentralized governance for smart contracts” basically revolves around forcing an agreement among the parties (organizations) before any new data can be added to the ledger. In practical terms, it means that the system will avert any entity from writing to the ledger until there is consensus among the parties involved in a transaction.
Docker, OpenShift or Kubernetes: Which Platform to Choose for Hyperledger Fabric Network…
If you’re into Hyperledger Fabric deployment, then you’re most likely aware of the term ‘Container Orchestration’. In…
Unlike previous Hyperledger Fabric versions, version 2.0 comes with this special decentralized feature which allows you to fluently install a chaincode on your peers and initiate it on a channel, giving rise to a new chaincode lifecycle.
The new Fabric chaincode lifecycle empowers multiple organizations to decide on an agreement based on the numerous parameters of a chaincode, including the chaincode name, version, and the endorsement policy before the chaincode can interact with the ledger.
Some of the key improvements made in the new chaincode lifecycle which was nowhere to be seen in the previous versions include:
- Requires consent from multiple organizations before giving the green light for the chaincode to go live. Each organization must agree on the chaincode endorsement policy and other details before the chaincode becomes active on a channel.
- More deliberate chaincode upgrade process, which certainly means that the upgrade transaction could no longer be issued by a single organization. This acts as a godsend for the channel member who is yet to install the new chaincode.
- An endorsement policy which you can change or modify without repackaging or reinstalling the smart contracts.
- Easy to access Fabric lifecycle packages, which empowers you to inspect the chaincode package and coordinate installation across multiple organizations.
For a detailed list of enhancements made in the new Fabric chaincode lifecycle, kindly refer to the following link: https://bit.ly/2X25Owu
Next in the queue, we will discuss the new chaincode application patterns for collaboration and consensus.
The decentralized method that underpins the new Fabric chaincode lifecycle management can also be leveraged and used in your own chaincode applications to ensure that organizations give their consent to data transactions before they are committed to the ledger. The chaincode application patterns can be classified into two different categories: Automated Checks and Decentralized Agreement.
Automated Checks can be added to chaincode functions by organizations to validate additional information before endorsing a transaction proposal.
On the other hand, Decentralized Agreements are human decisions that can be portrayed in a chaincode process that encompasses numerous transactions.
The chaincode may require the individuals involved with different organizations to convey their Terms and Conditions of agreement in a ledger transaction.
Then, a final chaincode proposal will be made which can help verify that the conditions from all the transactors are met and finality (for business transaction settlement) is maintained across all channel members.
Demystifying the Process of Building Distributed Multi-cloud Blockchain Network
Let’s face it, working in a production environment like Hyperledger Fabric is a grueling adventure, even with a good…
Last but not the least, we will explore chaincode through the eyes of a blockchain network operator and explain the process of how the Fabric chaincode lifecycle can be used for installing and defining chaincode on your network.
To install and define a chaincode, channel members need to come to an agreement using the following four steps. However, not every organization on a channel needs to complete each step.
Step 1: Package the chaincode
This step can be completed either by one or each organization in a channel.
In technical terms, to install the chaincode on your peers, you first need to package it in a tar file.
Chaincode packaging can be done using the following entities:
- Fabric peer binaries
- Node Fabric SDK
- A third-party tool such as GNU tar
To create a chaincode package, you need to provide a chaincode package label to create a succinct and human-readable description of the package.
Besides the options provided above, you can also use a third-party tool for packaging the chaincode. However, for that, you’ll need to keep the resulting files in the format mentioned below:
- The chaincode should be packed in a tar file ending with a .tar.gz file extension.
- The tar file must contain the following two files (without a directory): a metadata file “Chaincode-Package-Metadata.json” and another tar comprising the chaincode files.
- The metadata file “Chaincode-Package-Metadata.json” contains JSON that specifies the chaincode language, code path, and package label.
In the above depiction, the chaincode is packaged separately by two organizations namely Org 1 and org 2. Both organizations use MYCC_1 as their package label to identify the package using the name and version.
Note: Organizations don’t need to use the same package label.
Step 2: Install the chaincode on your peers
This step needs to be completed by every organization that will use the chaincode to endorse a transaction or query the ledger.
Once you’re done with the first step, i.e. packaging the chaincode, then comes the next step which involves installing the chaincode on your peers.
- The chaincode package needs to be installed on every peer that will execute and endorse transactions. Whether using the CLI or an SDK, you need to finish this step using your peer Administrator.
- Once the chaincode installation is done, your peer will build the chaincode and return a build error in case there’s any problem found with your chaincode.
- It is ideal that you package a chaincode once, and then install the same package on each peer belonging to your organization.
In case a channel wants to verify that each org is running the same chaincode, one organization can package a chaincode and pass it to other channel members out of band.
A chaincode package identifier will be returned on a successful install command, which is the package label combined with a hash of the package. The package identifier is basically used to associate a chaincode package installed on your peers with a chaincode definition approved by your organization. It is recommended that you save the package identifier for the next step.
In the above representation, a peer administrator from Org 1 and Org 2 installs the chaincode package MYCC_1 on the peers joined to the channel. Installing the chaincode package builds the chaincode and creates a package identifier of MYCC_1:hash.
Step 3: Approve a chaincode definition for your organization
This step is mandatory for every organization that will use the chaincode. A certain number of organizations need to approve the chaincode definition so as to satisfy the channel’s “Lifecycle Endorsement” policy before the chaincode can be started on the channel.
The chaincode is governed by a chaincode definition, and when channel members approve a chaincode definition, the approval acts as a vote by an org on the chaincode parameters it accepts. These approved org definitions permit channel members to give their consent on a chaincode before it can be used on a channel. The parameters of chaincode definition which need to be kept consistent across organizations include Name, Version, Sequence, Endorsement Policy, Collection Configuration, Initialization, ESCC/VSCC Plugins, etc.
The chaincode definition also comprises the Package Identifier which is an essential parameter for each organization looking forward to using the chaincode. The package ID needs to be different for all organizations. An organization can approve a chaincode definition without installing a chaincode package or including the identifier in the definition.
An organization administrator from Org1 and Org2 approve the chaincode definition of MYCC for their organization. Since both organizations will use the chaincode to endorse transactions, the approved definitions for both organizations need to include the packageID.
Step 4: Commit the chaincode definition to the channel
This step involves the commit transaction which needs to be submitted by one organization once the required number of organizations on the channel have approved. The submitter will first collect endorsements from various peers of the organizations that have approved before submitting the transaction to commit the chaincode definition.
As soon as most channel members approve a chaincode definition, one organization can commit the definition to the channel. It’s always recommended to use the checkcommitreadiness command to check whether committing the chaincode definition should be successful.
One organization administrator from Org1 or Org2 commits the chaincode definition to the channel. The definition on the channel does not include the packageID.
For a detailed view of each operation of the Fabric chaincode lifecycle, skim through the following link: https://bit.ly/36aKCsn
How to use the new Fabric chaincode lifecycle to your best advantage?
To use the new chaincode lifecycle, all you need to do is — create a new channel and set the channel capabilities to v2.0. Remember, by enabling v2.0 capabilities, you won’t be able to use the old lifecycle to install, instantiate, or update a chaincode on channels. Having said that, you can still invoke the chaincode installed using the previous lifecycle model once you enable v2.0 capabilities.
That’s all for this post! I hope it made your concept clear on Hyperledger Fabric v2.0 Chaincode Lifecycle Improvements.
We’ll be back soon with our subsequent blog posts covering the remaining two prominent features of Fabric v2.0, i.e. ‘External Chaincode Launcher’ and ‘Hyperledger Fabric v2.0 migration’. So, don’t miss out on that!
Feel free to share your thoughts in the comments below.