Deals with github pull request

Once you forked the upstream repo and may have also done a pull request, the upstream repo most likely will be moving forward with new commits. To work on new fixes, it is important to synch up your own repo with the upstream. Here is the process to do that.


git fetch upstream
git checkout master
git merge upstream/master
git push origin master

The commands above basically do the following things:

1. get the latest from upstream (it should be showing what the upstream is at .git/config)
2. switch to your local master branch
3. then merge the upstream and your own master branch
4. eventually push everything in the local master branch to your own remote repo.

Fabric channel configuration structure and its meanings

The fabric configuration is a hierarchical structure. It is basically a nested ConfigGroup.  If look at the exported genesis block, it starts at data.data[0].payload.data.config.  (parent elements are not showing in the picture)

fabric configuration config contains nested ConfigGroup and an element called sequence. sequence element must increment every time a committed change happens to the configuration. The root ConfigGroup is named channel_group as shown in the picture.

The channel_group element likes any other ConfigGroup always contain 5 elements, these 5 elements are groups, mod_policy, policies, values and version.

The groups element regardless where it is, is a map of ConfigGroups, or you can think the groups element as a list of ConfigGroup with names. For example, the top level groups which belongs to channel_group basically contains 3 ConfigGroup, their names are Application, Consortiums and Orderer. Each of these 3 things is a ConfigGroup.

The mod_policy is used to govern the required signatures to modify that element. For groups, modification is adding or removing elements (or changing the mod_policy). For values and policies, modification is changing the value and policy fields respectively (or changing the mod_policy). Each element’s mod_policy is evaluated in the context of the current level of the config

The policies element is a map of ConfigPolicy which contains mod_policy, policy and version

The values element is a map of ConfigValue, which is basically a key name value pair and is specific to each element.

The version element tracks number of the changes to the config group.

The official fabric doc on the topic can be found here

I feel that policies really just defines group of people, only when policies are combined with ACL, then things started become a bit clearer. Traditional application ACL only requires one actor to act on resources, but blockchain normally would require a group of actors (thus the policies) to act on, so the policy has to define who and how many, that will be the differences comparing to traditional ACL.

Findings of the fabric cryptogen

Hyperledger fabric cryptongen is an utility to generate a set of certificates and private keys. It will take a yaml file normally named crypto-config.yaml to produce a set of files. Here is a structure for an organization.

Each ca should have its cert and private key.

Each org (peer or orderer org) should have its admin user and other users.

Each node (peer or orderer node) should have its signcert and private key (file in keystore directory).

Directories such as admincerts, cacerts and tlscacerts under each peer or orderer node msp directory contain admin cert, ca cert and tls ca certs.

Either a user or node (peer or orderer node) should also have its tls directory which is parallel to msp directory. tls directory contains ca.crt, server.crt and server.key


started in version 1.4.3, cryptogen no longer places the admin cert in the admincert folder under any msp directory. Even though the direcctory still gets created, it remains empty.