Policies in Hyperledger Fabric — Signature & ImplicitMeta

Let’s recall that the participants in a Hyperledger Fabric network are not individual users, but entire Organizations. An organization hosts one more Peer nodes and Client nodes. Even though the transactions are submitted by the client node, but they are submitted on behalf of the entire Organization. Therefore, the validation process must make sure that the organization is not doing any mischief. Since it is a Blockchain network, we do not have a central authority for validation, but a policy called “Endorsement Policy”.

Photo by Edwin Andrade on Unsplash

As the word suggests the Endorsement Policy defines which of the participants (Organizations) must endorse a transaction. To understand what endorsement means, consider an analogy. Let’s say you have to give $10 to someone called Bob, and there is a third person called John who is responsible for endorsing this transaction. Here, John makes sure that you had enough money to give to Bob, and you have actually given it to Bob.

Endorsers in the Hyperledger Fabric does a similar task. They make sure that before updating an asset, you have the correct state of the asset, and also none of the validations defined in the chaincode are stopping you from modifying that asset. Hyperledger Fabric allows us to make some complex combinations while selecting endorsers, like either of two participants, or both of two participants, or two of five participants, etc.

Once a transaction is endorsed by the relevant participants, Orderer Service Node comes into play. At this time, the client broadcast endorsed (signed) transaction to Orderer(s) in the channel. The Orderer does two things. Firstly, it verifies that the client has an appropriate role, which is required to modify the ledger. Once that is confirmed, Orderer collects the transaction into a block and broadcasts the block to the channel if it reaches a defined size or a defined amount of time has been elapsed.

What are Policies?

A Signature policy is a low-level policy and specifies the particular roles whose signature can satisfy the policy. It can be applied to all levels from organization related to channel related policies. There are some default Signature policies in Fabric: Readers, Writes, Admin. Readers defines which principal can read the ledger, Writes defines which principal can write in the channel ledger and Admins defines which principal can perform administrator actions (organization/channel update). Also, custom policies can be created according to the needs.

Rules in Signature policies involve expressions which consist of operations and principals. For example the statement:

Admins:
       Type: Signature
       Rule: "OR('Org2MSP.admin')"

For each Signature policy defined, there is a basic access right type associated with the policy, including:

1. Writers (to write)
2. Readers (to read)
3. Admins (to configure)

Signature Policy definition in configtx.yaml— Readers, Writes, Admin

An ImplicitMeta policy stands higher in configuration level. ImplicitMeta policies avoid duplicate records and the multiple changes when a policy is updated. Rule here is linked with other ImplicitMeta or Signatures policies, but the final decision will be evaluated by a Signature policy. In contrast to Signature, an ImplicitMeta can be applied only in channel configuration level.

For example:

Implicit Policy definition in configtx.yaml — ANY,ALL,MAJORITY

Admins is the Signature policy named Admins that specified the admins in organization level. Hence, in order to edit application-related parameter such as adding a new organization in the application channel, the majority of the organizations admins that participate in the channel must agree with that change

Interpretation of ImplicitMeta Policy

To proceed, let’s say we have a sample policy at Channel\Application level:

Readers:
       Type: ImplicitMeta
       Rule:  "MAJORITY Readers"

To interpret this ImplicitMeta policy, one needs to:

1. Know the level of that policy

In this sample, Channel\Application

2. List all policies with the same access right type in the lower level, people call these listed policies as sub-policies:

In this sample, those sub-policies are those “Readers” policies in level Channel\Application\*

That is,

• Sub-policy (a): Channel\Application\Org1\Readers
• Sub-policy (b): Channel\Application\Org2\Readers

3 Know the rule of the policy:

In this sample, it is an “ANY” policy.

There are also “MAJORITY” and “ALL”. They should be easy to understand by their names.

4. Know the requirement to pass this policy:

In this sample, the requirement is, “ANY sub-policy is enough”.Thus, any of sub-policies (a) and (b) is satisfied, then this ImplicitMeta policy is satisfied.

ImplicitMeta policy — Divide & Conquer

So, overall, the way to interpret an ImplicitMeta policy is kind of “Divide and Conquer”. That is, to evaluate an ImplicitMeta policy, we cut it into smaller pieces (sub-policies), and try to solve them. But those smaller pieces might be themselves ImplicitMeta policies, then we cut again… After some divisions, those lowest level sub-policies are those Signature type policies, no further cutting is needed, they could be solved immediately. Finally, we come back to the original biggest problem — our original ImplicitMeta policy, and combine those solutions of smaller problems, then solve the original biggest problem.

References:
1. https://medium.com/coinmonks/consensus-endorsement-in-hyperledger-fabric-5dbf233b452c