How to manage governance in a Hyperledger Fabric network

Managing governance is a question that arises in any ambitious project with Fabric.

Governance refers to the rules and procedures for regulating the operation and management of something, in this case, a Hyperledger Fabric network.

There are multiple vital aspects:

• Consensus mechanism and validators

• Chaincode Lifecycle management

• Channel configuration (application)

These aspects can be managed separately, there can be separate governance for each of them.

Let’s start with consensus.

Consensus mechanism and validators

The orderer configuration in a channel consists of the following:

• Orderer organisations

• Consenters

Thankfully, the policies in Fabric allow us to configure them.

In Fabric, policies have these roles:

• Who can manage the configuration

• Who can read the configuration

In this case, we can have an organization managing the consensus configuration and an unlimited number of orderers from other organizations.

Chaincode Lifecycle management

Chaincode lifecycle management refers to who can commit to the chaincode definition.

By default, this policy is set so that the majority (+50%) of organizations need to approve the chaincode before it can be committed.

The problem with changing this policy is that organizations that haven’t approved a definition won’t be able to endorse (execute chaincode) until they approve it.

This rule is usually set when organizations don’t have peers (similar to light nodes in other networks).

These organizations use the chaincode of other organizations to interact with the network.

Of course, this has negative effects because those “light” organizations can’t have any private data collection.

So, make sure to verify the use case before modifying the policy LifecycleEndorsement in the channel configuration.

This policy can only be changed by changing the application configuration.

Channel configuration

This section refers to the Application configuration in the channel.

This configuration contains:

• LifecycleEndorsement (see above)

• Peer organisations and anchor peers

Usually, the simplest governance policy is to set an organization as the admin.

So that organization will be able to add and remove peer organizations as needed.

Of course, you can set the Admins policy to support as many organizations as you want to need to approve a change before being committed.

But it’s usually slow, especially in projects that start as PoC, where other participants don’t have much knowledge about Fabric or have limited resources.

An Admin policy in Fabric, in the channel configuration as JSON may look like this

In this case, either Org1MSP or Org2MSP can update the channel configuration, if we want to change the number of organizations that need to approve, we need to update the n in the rule n_out_of.

Hope you learnt something new this week.

See you next week!

— David