Hyperledger Fabric has been around for the enterprises for quite some time now. In reality, it offers one of the creative platforms for blockchain use cases. But a technology that doesn’t improve over time becomes obsolete very quickly. That’s why Hyperledger brought us the new Hyperledger Fabric 2.0 release.
Basically, previously, the company offered a Fabric version 1.4. But now we have the next generation blockchain among us. If you are more than thrilled about the new release like us, check out this guide. Because today we’ll talk about what the new Hyperledger Fabric 2.0 release and about all the features it introduced.
But before we begin, we’ll give a retrace what the Hyperledger Fabric platform is and what features it initially offered.
So, let’s start!
What is Hyperledger Fabric?
Hyperledger Fabric is a distributed ledger platform for enterprise-grade solutions that comes with versatility, modularity, and performance. So, as you know, there are permissionless platforms as well. But Fabric is different from that.
It doesn’t allow just anyone to get an entry into the platform. Rather it offers permissioned access to the users that has authority in the system. More so, it also offers data privacy and smart contracts for scalable and secure performance.
That’s why any industry can just use Hyperledger Fabric for any kind of solution. The opportunities are limitless, and businesses will always get the best output from the distributed ledger platform.
Even though users within a network system will work together, but the enterprises do need to maintain privacy for certain interactions. It’s what the industry is based on. For example, maybe a purchaser is selling a product to different vendors but at different price ranges.
But the purchaser needs to maintain privacy about it. And this is where Hyperledger Fabric can help.
In reality, you can easily create separate channels in a transaction for separate sellers. Also, you can use private data options to keep the information on a hush-hush level.
Why Hyperledger Fabric?
In reality, Hyperledger Fabric evolved over time with the help of the open-source community, focusing mainly on enterprise-grade use cases. More so, it now offers a lot of features that the enterprise demand often. So, let’s see what these are –
- Modular and permissioned architecture.
- A very flexible endorsement solution for consensus among all the transacting organizations.
- Flexible and open smart contracts that can support various data models and solutions such as structured data, account model, unstructured data, UTXO model, etc.
- Pluggable consensus protocol options for ordering transactions and blockibution.
- Full data privacy for transaction isolation or sharing only need-to-know information using private data models.
- Versioning and governance for smart contracts.
- Support for Solidity.
- Support for Ethereum Virtual Machine.
- Continuous updates, enterprise operations, asymmetric version support.
- Quadrable data such as range queries, keyed queries, on-chain JSON queries, and many more.
Hyperledger Fabric 2.0: What’s New?
The first-ever Hyperledger Fabric release was back in v1.0. And now, we have the second major Hyperledger Fabric 2.0 release. This time it does come with a lot of new and improved features for both users and operators in the platform.
Hyperledger Fabric 2.0 release includes privacy patterns and supports new applications, new features for operating nodes, enhanced governance systems for smart contracts, and many more.
However, they won’t force you to upgrade to the latest Hyperledger Fabric 2.0 if you are not ready yet. So, you have the option to upgrade when you are ready, or your company is ready for the transition.
And that’s a huge plus point for Hyperledger Fabric 2.0.
Let’s check out some of the highlights of the new release –
Smart Contracts Decentralized Governance
Hyperledger Fabric 2.0 now comes with decentralized governance, especially for smart contracts. It also offers a new process where you can install a chaincode on the peers and start it on the channel. Thus, the new chaincode lifecycle management now allows multiple organizations to reach an agreement based on the parameters of the chaincode.
So, basically, you’ll be using the chaincode endorsement policy for interacting with the ledger. Let’s see what other improvements it offers over the previous chaincode lifecycle process –
Agreement to The Parameters of Chaincode
Basically, in the previous release, only one organization in the chaincode could set up the parameters even for other channel members as well. But the other members could refuse to get the chaincode and not take part in the transaction process. Therefore, invoking it.
However, the new Hyperledger Fabric 2.0 offers a more flexible route for the chaincode. Now it supports both centralized chaincode models and decentralized chaincode models. In the decentralized version, the companies have to reach an agreement on the chaincode become it can become active on the channel.
Cautious Chaincode Upgrades
Previously, only a single organization could upgrade the transaction. However, that would leave the other channel members at risk if they don’t have the chaincode installed. Thus, the new Hyperledger Fabric version 2.0 allows the chaincode to upgrade only after enough members agree on the upgrade without any issues.
Private Data Collection and Easy Endorsement Policy Updates
The new Hyperledger Fabric version 2.0 does offer a new endorsement policy where you can upgrade the private data collection or policy configuration without reinstalling the chaincode. More so, the users can take utilize the endorsement policy as it requires agreement from a vast number of users on the channel.
In reality, the policy will update every time a member gets on the ledger or leaves the ledger.
Inspectable Chaincode Packages
Now the Hyperledger Fabric version 2.0 comes with an easily readable tar file for chaincode. It will help you to inspect the chaincode files easily and determine the installations across other organizations.
Multiple Chaincodes On A Channel
In the previous version, the lifecycle used to define every chaincode using the version and name specified during the package installation. But now you can use only a single chaincode package and deploy it more than once with multiple names every time on the network. Also, you can do it on different channels or on the same channel.
Chaincode Packages Across Channel Members
In the Hyperledger Fabric version 2.0, users can extend a chaincode for their own use cases. For example, an organization can extend a chaincode for validations within their own company. But there’s a minimum number of requirements from organizations. So, when enough endorsement is possible, the transactions will get validated and get a place on the ledger.
Thus, it will help your company to automatically fix any issues in your own time without compromising the whole network.
Using the New Chaincode Lifecycle
The Hyperledger Fabric version 2.0 now offers a completely new chaincode lifecycle. However, if you aren’t ready for the new changes, you can just keep using the previous lifecycle with the Hyperledger Fabric version 2.0.
In reality, the new lifecycle will only become active when you update the capabilities to the v2.0.
New Chaincode Application Patterns
Basically, Hyperledger Fabric 2.0 roadmap allows you to use the same decentralized consensus method for your own chaincode applications as well. It will ensure that the organizations have consent for the data transactions before committing to the ledger.
An organization can add up automated checks to chaincode in order to validate more information before endorsing a transaction on the ledger.
The best part is that Hyperledger Fabric 2.0 roadmap allows you to model human decisions on the chaincode to span more than one transaction. However, you would need other users from organizations to interact with the terms and conditions of the agreement.
Then, finally, a chaincode proposal can verify that all the user’s conditions are fulfilled and settle the transaction based on that.
There are certain capabilities in the Hyperledger Fabric 2.0 roadmap. Let’s see what these are –
Application V2_0: It starts a new chaincode lifecycle for operators, as mentioned in the Chaincode.
Channel V2_0: Basically, it has no changes, but you can use it for maintaining consistency with the ordered capability level and applications.
Orderer V2_0: This one controls the UseChannelCreationPolicyAsAdmins, and changes the way typically a channel transaction is validated. If you combine it with the -baseProfile option, then you can change the previously inherited values in the orderer system.
But when you are updating your capability levels, always remember to update the peer binaries as well. Also, update the orderer binaries before you update the Orderer and Channel capabilities.
Private Data Enhancements
The Hyperledger Fabric 2.0 roadmap also comes with a new pattern for sharing all your private data without collecting all of them at once and then combine channel members based on that. More specifically, without sharing private information with a collection of users, you can just share it with a single organization.
But before we go a bit deeper into the Hyperledger Fabric 2.0 documentation, let’s see what private data actually refers to in Hyperledger.
What Is Private Data?
In many cases, an enterprise may need to keep certain information private in a channel from other companies. Thus, they have to create a new channel with only the organizations that can see the information separately. But that means it will also need additional administrations, policies, membership accesses, and many more.
More so, it also doesn’t allow the channel participant to use the system in any use cases where all parties can see some part of information while others remain hidden.
However, now the Hyperledger Fabric 2.0 roadmap will help you create a private data collection. Here you can define a subset of companies that can see the private data without creating a new channel for every case.
What Is Private Data Collection?
Basically, a collection is a combination of two different elements –
The actual information that is broadcasted between peers using the gossip protocol. But here, only the enterprise authorized to see it can see this. Basically, this data is on a private state database within the ledgers of the peers of that organization.
More so, there are no ordering services here, and they can’t see the private information. Anyhow, as the gossip protocols broadcast the information from one peer to another, you need to set up Anchor nodes in the channel.
It also contains a hash of that private data that is ordered, endorsed, and written on the ledger of all the peers in the channel. Basically, it serves as evidence for the validation of a transaction on the channel. You can also use it for audit purposes.
Using A Collection
Within A Channel
You need to use channels if you want to keep an entire transaction secret from a group of organizations within the channel.
According to Hyperledger Fabric 2.0 documentation, you can use collections when you need to keep only a portion of the ledger secret from a set of enterprises.
In reality, some organizations will have full access to the ledger, and others may only see what they are allowed to. If you also want to keep transactional data hidden from the ordering services, you can use private data collections for confidentiality.
Let’s check out an example from Hyperledger Fabric 2.0 documentation to understand the situation better.
Let’s say, in a trading platform, there are five enterprises in a channel.
- The farmer who sells goods
- Distributor who moves those goods
- Shipper who moves goods between two parties
- Wholesaler who buys goods from the distributor
- Retailer who buys the goods from the wholesalers and shippers
Basically, the distributor can charge differently in every case. So, he might want to keep transactions with the shipper and Farmer private because he may have other deals with the retailer and the wholesaler.
Also, the distributor does charge less to a wholesaler than to a retailer. Thus, he may want to keep that a secret from the retailer.
The wholesaler, on the other hand, can also have private relations with the shipper and the retailer. But if you want to create a separate channel for every private information, then the system would become much more complicated.
Rather than doing that, you can have different private data collections or PDCs for each of the members.
Private-Data-Collection-1: Shipper, Farmer, and Distributor
Private-Data-Collection-2: Shipper, Retailer, and Wholesaler
Private-Data-Collection-3: Wholesaler and Distributor
According to Hyperledger Fabric 2.0 documentation, all the distributor peer will have private databases containing private data for Shipper, Farmer, and Distributor relation and Wholesaler, and Distributor relation.
Enhancements in Data Patterns
According to Hyperledger Fabric 2.0 documentation, there are some enhancements that actually makes it possible for the new private data patterns to work. These are –
Sharing and Verifying Private Data
Receiving parties can use the GetPrivateDataHash() API to verify if the private data shared with them is authentic or not in two scenarios –
- When you share private information with a channel user who is not a member of a collection.
- When you share it with another collection that comes with one or more members.
Collection-Level Endorsement Policies
You can now define private data collections with the help of an endorsement policy that can override other chaincode level policies for keys among the collection. Basically, you can use it to restrict other enterprises to write on the collection and what can enable chaincode lifecycle and application patterns.
Well, for an example, you may need endorsement where if majority enterprises agree, you can start the transaction, but in cases, you may need the agreement from a specific organization to make it work.
Implicit Per-Organization Collections
According to Hyperledger Fabric 2.0 documentation, in any case, if you want to use a per-organization private data pattern than you can deploy chaincode without defining the collection in the new version. It’s one of the major Hyperledger Fabric 2.0 features.
External Chaincode Launcher
The external chaincode launcher is one of the awesome Hyperledger Fabric 2.0 features. Mainly, it will empower the operators as now they can choose to launch the chaincode of their choice of technology. More so, you won’t have to use an external launcher or builder for it, and it will run the chaincode using Docker API.
Basically, the peers now won’t have to access a Docker daemon to run or build the chaincode. In a production environment, it’s absolutely not desirable, and that’s why peers can now eliminate the dependency on Docker daemon.
Now you don’t have to run a chaincode in a Docker container, you can sue your own choice of environment to run the chaincode.
Additionally, the operators can offer external builder executables for overriding how the users launch or build chaincode.
Previously, peers launched a chaincode, and then it was connected back to them. But now you can run it as the external service.
Improved Performance on CouchDB
Previously, when you would use the CouchDB state database, you would face reading delays in validation and endorsement. So, it was hard to get performance as smooth as possible. But now, with Hyperledger Fabric 2.0 features, you get a new peer cache that will replace lengthy lookups with fast outputs. More so, you can configure them with core.yaml property cacheSize.
Alpine-Based Docker Images
In the new Hyperledger Fabric 2.0, it will use Alpine Linux for the Docker images. The Alpine Linux is a more secure and lightweight Linux distribution that can easily increase the performance of the network.
In reality, it means that Docker images will be smaller in size, so it would take less time to download or for the startup. More so, it won’t take up too much space from now on as well.
The company designed the Alpine Linux from scratch, keeping security in mind, and the minimalistic feature of this distribution gets rid of all vulnerabilities.
Sample Test Network
Now you’ll have a new sample test network in the fabric-samples repository. It’s one of the cool Hyperledger Fabric 2.0 features. In reality, this test network is modular and easy to use. So, you’ll have no issue in testing out your smart contracts or applications before launching the solution.
Additionally, you can also deploy the network with Certificate Authorities along with cryptogen.
How to Upgrade to Fabric v2.0
Every time a major release occurs, it brings a ton of upgrade consideration issues. In many cases, you may have to install the new version from scratch, but that can have downtimes. But, one of the Hyperledger Fabric 2.0 features is that, if you are already on version 1.4, you can directly upgrade to version 2.0 without any downtime.
Basically, upgrading to the latest release is a four-step process –
- First, you have to backup your ledgers and MSPs.
- Then start upgrading in a rolling fashion the orderer binaries to the latest version.
- After that, follow the same updating process for the peer binaries as well.
- Lastly, you need to update the application channels and the orderer system channel to their latest capabilities when they are available. More so, not all the releases will have increases capabilities, sometimes they have major enhancements sometime they won’t.
Before you upgrade any processes, you should consider checking out their tutorials for that. You can also heck out our Fabric tutorial as well. Anyhow, we are giving a short version of that here –
- Before you upgrade your capabilities, you should upgrade all your components first. Make sure they are the latest version.
- Also, ensure to update all the nodes to the latest version before updating the whole channel.
- You have to add endorsement policies for a specific company for starting a new chaincode lifecycle in the system.
The fabric now considers the upgrading of nodes and increasing capabilities as a standard.
Note: It’s recommended that you upgrade your SDK to the latest version as well. Even though your SDK should be capable of handling equivalent releases of Hyperledger Fabric and lower version, it would be best to update it because then you can use the latest Fabric features efficiently.
If you are still confused about the upgrading process, then check out their documentation on it.
The latest release of the version 2.0 is a milestone in history. In reality, Fabric 2.0 is considered to be the next-generation blockchain technology. More so, there are so many Hyperledger Fabric 2.0 features that offer a lot of opportunities.
As of now, we still don’t know how this technology will perform or if the new version can finally get rid of the negative aspects of blockchain. Even so, the new milestone for the Hyperledger family and community did bring lots of new enhancements, and we can only hope for the best.