Blog

Hyperledger is firing on all cylinders, and there’s no sign of that impetus slowing down any time soon. The community is making massive strides in an attempt to make blockchain practical for enterprise use.

Hyperledger Fabric, an IBM-backed Distributed Operating System (DOS) for permissioned blockchains, recently released its latest version, i.e., v1.2.0, on July 3, 2018.

While the previous v1 releases (v1.0 and v1.1) were huge and noteworthy, v1.2 is out in essence to maintain a regular release cadence. That being said, it still brings something new and exciting to the table. Continue reading to know what it is …

In this blog post, I’ll give you a brief overview of Hyperledger v1.2.0 and will also compare it with Hyperledger v1.1.0. So, without wasting any time, let’s get started!

What’s new in v1.2.0?

The latest release comes with countless new features and enhancements which include new tools for interacting with a corporate network, privacy-preserving asset transfer, better-trusted transaction approval process, Ethereum smart contracts execution, and plenty more. On top of all, it is packed with Ginkgo-based integration tests and refactored component code, which makes it super easy to maintain the test code.

Here’s a closer look at some of the amazing stuff Hyperledger v1.2.0 is bringing our way:

Private Data Collections

In v1.1.0, to implement data abstraction between two parties, it was necessary to create different channels. There was no provision to keep data private within a single channel.

Unlike the previous versions, Hyperledger v1.2.0 offers a way to provide abstraction to multiple shareholders within a single channel. It allows you to create Private Data Collections, which help keep your chaincode data or certain transactions confidential among a subsection of channel members. Also, it authorizes a defined subset of organizations on a channel to endorse, commit, or query private data without having to create a different channel.

Before moving any further, let’s make you familiar with Private Data Collection Definition.

A Collection Definition, in general, comprises one or more collections, each having a Policy Definition portraying the list of organizations in the collection. It is deployed during the process known as Chaincode Instantiation. If the chaincode is instantiated using the peer CLI, then the Collection Definition file will be passed using the --collections-config flag.

There are five major properties of a Collection Definition: name, policy, requiredPeerCount, maxPeerCount and blockToLive.

Here’s an example of a Collection Definition JSON file containing an array of two collection definitions:

[

{

"name": "collectionDebut",

"policy": "OR('debutMSP.member', 'DemoMSP.member')",

"requiredPeerCount": 0,

"maxPeerCount": 3,

"blockToLive":1000000

},

{

"name": "collectionDebutPrivateDetails",

"policy": "OR('DebutMSP.member')",

"requiredPeerCount": 0,

"maxPeerCount": 3,

"blockToLive":3

}

]

In the above example, Debut and Demo are the two organizations used from the Building Your First Network (BYFN) sample network. The policy in the collectionDebut definition sanctions both organizations to the private data.

Service Discovery

Applications connect to an API (exposed by an SDK) for a plethora of reasons, such as to execute chaincode on peers, submit transactions to orderers, remain updated about the status of the transactions, and more. However, the SDK requires heaps of information to permit applications to connect to the appropriate network nodes. Besides obtaining the CA & TLS certificates and IP addresses & port numbers of the orderers and peers on the channel, the SDK needs to be familiar with the relevant endorsement policies and the peers that have the chaincode installed (to make it easy for applications to know which peers to send chaincode proposals to).

In Hyperledger v1.1.0, this information was statically encoded and organized, which didn’t allow applications to react to changes of the endorsement policy itself (for instance, when a new organization joins a channel). The biggest downside of static implementation is its unreactive nature to network changes, such as the addition of peers that have installed the relevant chaincode, or peers that are temporarily offline. Furthermore, there’s no possible way for the client application to know which peers have updated ledgers and which are still using the outdated ones. Hence, there’s a possibility that the application might submit proposals to peers whose ledger data is not updated, or in other words, is not in sync with the rest of the network, thereby resulting in invalid transactions and resource wastage.

Hyperledger v1.2.0 comes with a standout feature called Discovery Service, which improves this process by letting the peers compute the required gen dynamically and portray it to the SDK in a consumable fashion.

Here are the following queries to which the Discovery Service can respond:

• Configuration: This query returns the MSPConfig of all organizations in a particular channel as well as the orderer’s endpoints of that channel.

• Peer membership: This type of query simply returns the peers that have joined a specific channel.

• Endorsement: This query-type returns an endorsement descriptor for a given chaincode in a particular channel.

• Local peer membership: This query basically returns the local membership info of the peer that responds to the query. By default, the client ought to be an admin for the peer to reply to this query.

Below is an example of the descriptor from the evaluation of AND (org1, org2) policy, where org1 and org2 are Debut and Demo respectively, and each of these organizations contains two peers.

Layouts: [

QuantitiesByGroup: {

“Debut”: 1,

“Demo”: 1,

}

],

EndorsersByGroups: {

“Debut”: [peer0.debut, peer1.debut],

“Demo”: [peer0.demo, peer1.demo]

}

Access Control Lists (ACLs)

Hyperledger Fabric uses Access Control Lists (ACLs) to provide as well as manage access to resources by combining a policy with the resource. The policy stipulates a rule that evaluates to true or false, provided a set of identities.

Policies are an imperative part of Fabric as they allow identities associated with a request to be compared against the policy linked with the resource required to complete the request. Endorsement policies are used to determine whether or not a transaction is adequately endorsed. Policies, in general, can be structured in either of two ways: A Signature policy or an ImplicitMeta policy. Resources, on the other hand, are the endpoints which the users target. A resource can be a user chaincode, system chaincode, or an event stream source. The exhaustive list of all internal resources currently defined by Fabric can be found in configtx.yaml.

Previously, access control lists were managed in an isolated_data section of the channel creation transaction and were updated via PEER_RESOURCE_UPDATE transactions. In v1.2.0, ACL is implemented in a very different yet efficient manner, which allows you to effortlessly configure the client identities that can interact with peer functions on a per channel basis. Access control is specified inside configtx.yaml, the file that is used by configtxgen to build channel configurations.

Hyperledger v1.2.0 doesn’t support the traditional ACL methods, which compels network operators to shut down their traditional peers and upgrade them to the latest version. For that, they need to submit a channel reconfiguration transaction that triggers the v1.2.0 competency and installs the necessary ACLs before restarting the upgraded peers.

Apart from these, v1.2 comes with numerous other features, tweaks, and additional documentation such as pluggable endorsement and validation, new tutorials for CouchDB, Fabric CA and Private Data, service discovery CLI, fabric network as a concept, and much more. You can find it all here.

Upgrading to the Latest Version of Fabric

As you can see, there are a gazillion benefits of Hyperledger v1.2.0, which you can only reap once you upgrade your Fabric network to the latest version.

Here’s how you can do it:

• First, upgrade the binaries for the ordering service, the Fabric CA, and the peers. Note: These updates can be carried out in parallel.

• Once done, upgrade your client SDKs.

• Enable the v1.2 capability (crucial).

• Upgrade the Kafka cluster (optional).

Here’s a step-by-step guide to help you achieve these upgrades with minimal fuss.

If you’re into blockchain and haven’t upgraded your Hyperledger Fabric to v1.2 yet, you’re probably missing out on a pool of opportunities! Upgrade today to start taking advantage of these brand new features and capabilities.

Need help with anything related to blockchain technology? Leave that to the pros at Debut Infotech – a leading blockchain development company in India providing end-to-end, enterprise-grade blockchain solutions to global enterprises across diverse industry verticals. For a free consultation, call at 1-703-537-5009 or drop a line at info@debutinfotech.com.