Hyperledger Fabric Damn ImplicitMetaPolicy

Hyperledger Fabric Image

1. Introduction

In this tutorial, we refer to a sample configtx.yaml.

This sample file is a long one, so I don’t embed into the blog post. I suggest that you could quickly take a look, then continue, and read some related parts of the sample configtx.yaml whenever there is a need to refer to it. Also I assume that you have had a certain level of understanding for Hyperledger Fabric.

In the sample configtx.yaml, there are two types of policy:

The First Type — Signature

the first type of policy

The Second Type — ImplicitMeta

the second type of policy

Signature type policy is easy, while ImplicitMeta type policy is abstract. This short tutorial is to explain how to interpret ImplicitMeta type policy.

*It is assumed that, in this tutorial, ImplicitMeta’s name and ImplicitMeta’s rule target are always the same.

For example, the second type of policy, “Readers” (in line 1) and “Readers” (in line 3) are same, though they could be different.

2. The Level of Configuration

In the sample configtx.yaml, there are different levels of configuration, where each level represents a different subset of “access or configuration” items, such as channel update.

Below is the tree structure representation of those levels, according to the sample configtx.yaml.

tree structure of levels

3. Representation of Level of Configuration

According to the tree structure, there is a standard way to represent those levels.

For example, to represent the “Orderer” level, we use:

• Channel\Orderer.

One more example, to represent the “Org1” level, we use:

• Channel\Application\Org1.

4. The policy of Level of Configuration

For each level, there are policies defined to control different access rights for “access or configuration” items at that level.

5. Access Right Type of Policy

For each 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)

For example, a policy for Reader (to read):

Readers policy example (Signature type)

6. Interpretation of ImplicitMeta Policy

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

Readers policy example (ImplicitMeta type)

To interpret this ImplicitMeta policy, one needs to:

(6.1) Know the level of that policy

In this sample, Channel\Application

(6.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

(6.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.

(6.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.

7. One More Example

Let’s have one more sample at Channel level (which is the top level):

(7.1) Know the level of that policy

In this sample, Channel

(7.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 policies are those “Admins” policies in level Channel\*

• Sub-policy (a): Channel\Application\Admins

1. → Channel\Application\Org1\Admins
2. → Channel\Application\Org2\Admins

• Sub-policy (b): Channel\Orderer\Admins

1. → Channel\Orderer\OrdererOrg\Admins

(7.3) Know the rule of the policy:

In this sample, it is a “MAJORITY” policy.

(7.4) Know the requirement to pass this policy:

In this sample, the requirement is, “MAJORITY of sub-policies need to be satisfied”. Thus, once the MAJORITY of sub-policies (a) and (b) are satisfied, then this ImplicitMeta policy is satisfied. Here, the “MAJORITY” is 2 of them (i.e. all in this case).

8. Bonus 1

Continue the example above, if we would like to configure (because it is an “Admin” policy) the channel settings (because it is a policy at Channel level), one possible passing condition is to pass sub-policies (a) and (b), because there are 2 sub-policies and the “majority” in this case is 2 of them (all of them).

In the sample configtx.yaml, sub-policies (a.1), (a.2) and (b.1) are Signature type policies.

In other words, one possible passing condition is to collect signatures of org1 admin, org2 admin, and ordererOrg admin then you might be able to configure the channel settings if there are no other errors.

9. Bonus 2

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.

Next, is it PASS or FAIL?

Thanks! If you like my stories, please follow me for new updates!

Reference

Policies in Hyperledger Fabric - hyperledger-fabricdocs master documentation