Channel Configuration (configtx)

Note

This topic describes how channels are configured when the network has not been bootstrapped using a system channel genesis block. For information about the structure of configurations, including the configuration of the system channel, check out Channel Configuration (configtx) from the v2.2 documentation.

Shared configuration for a Hyperledger Fabric blockchain network is stored in a collection configuration transactions, one per channel. Each configuration transaction is usually referred to by the shorter name configtx.

Channel configuration has the following important properties:

  1. Versioned: All elements of the configuration have an associated version which is advanced with every modification. Further, every committed configuration receives a sequence number.

  2. Permissioned: Each element of the configuration has an associated policy which governs whether or not modification to that element is permitted. Anyone with a copy of the previous configtx (and no additional info) may verify the validity of a new config based on these policies.

  3. Hierarchical: A root configuration group contains sub-groups, and each group of the hierarchy has associated values and policies. These policies can take advantage of the hierarchy to derive policies at one level from policies of lower levels.

Anatomy of a configuration

Configuration is stored as a transaction of type HeaderType_CONFIG in a block with no other transactions. These blocks are referred to as Configuration Blocks, the first of which is referred to as the Genesis Block.

The proto structures for configuration are stored in fabric-protos/common/configtx.proto. The Envelope of type HeaderType_CONFIG encodes a ConfigEnvelope message as the Payload data field. The proto for ConfigEnvelope is defined as follows:

  1. message ConfigEnvelope {
  2.     Config config = 1;
  3.     Envelope last_update = 2;
  4. }

The last_update field is defined below in the Updates to configuration section, but is only necessary when validating the configuration, not reading it. Instead, the currently committed configuration is stored in the config field, containing a Config message.

  1. message Config {
  2.     uint64 sequence = 1;
  3.     ConfigGroup channel_group = 2;
  4. }

The sequence number is incremented by one for each committed configuration. The channel_group field is the root group which contains the configuration. The ConfigGroup structure is recursively defined, and builds a tree of groups, each of which contains values and policies. It is defined as follows:

  1. message ConfigGroup {
  2.     uint64 version = 1;
  3.     map<string,ConfigGroup> groups = 2;
  4.     map<string,ConfigValue> values = 3;
  5.     map<string,ConfigPolicy> policies = 4;
  6.     string mod_policy = 5;
  7. }

Because ConfigGroup is a recursive structure, it has hierarchical arrangement. The following example is expressed for clarity in Go syntax.

  1. // Assume the following groups are defined
  2. var root, child1, child2, grandChild1, grandChild2, grandChild3 *ConfigGroup
  4. // Set the following values
  5. root.Groups["child1"] = child1
  6. root.Groups["child2"] = child2
  7. child1.Groups["grandChild1"] = grandChild1
  8. child2.Groups["grandChild2"] = grandChild2
  9. child2.Groups["grandChild3"] = grandChild3
  11. // The resulting config structure of groups looks like:
  12. // root:
  13. //     child1:
  14. //         grandChild1
  15. //     child2:
  16. //         grandChild2
  17. //         grandChild3

Each group defines a level in the config hierarchy, and each group has an associated set of values (indexed by string key) and policies (also indexed by string key).

Values are defined by:

  1. message ConfigValue {
  2.     uint64 version = 1;
  3.     bytes value = 2;
  4.     string mod_policy = 3;
  5. }

Policies are defined by:

  1. message ConfigPolicy {
  2.     uint64 version = 1;
  3.     Policy policy = 2;
  4.     string mod_policy = 3;
  5. }

Note that Values, Policies, and Groups all have a version and a mod_policy. The version of an element is incremented each time that element is modified. The mod_policy is used to govern the required signatures to modify that element. For Groups, modification is adding or removing elements to the Values, Policies, or Groups maps (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. Consider the following example mod policies defined at Channel.Groups["Application"] (Here, we use the Go map reference syntax, so Channel.Groups["Application"].Policies["policy1"] refers to the base Channel group’s Application group’s Policies map’s policy1 policy.)

  • policy1 maps to Channel.Groups["Application"].Policies["policy1"]

  • Org1/policy2 maps to Channel.Groups["Application"].Groups["Org1"].Policies["policy2"]

  • /Channel/policy3 maps to Channel.Policies["policy3"]

Note that if a mod_policy references a policy which does not exist, the item cannot be modified.

Configuration updates

Configuration updates are submitted as an Envelope message of type HeaderType_CONFIG_UPDATE. The Payload data of the transaction is a marshaled ConfigUpdateEnvelope. The ConfigUpdateEnvelope is defined as follows:

  1. message ConfigUpdateEnvelope {
  2.     bytes config_update = 1;
  3.     repeated ConfigSignature signatures = 2;
  4. }

The signatures field contains the set of signatures which authorizes the config update. Its message definition is:

  1. message ConfigSignature {
  2.     bytes signature_header = 1;
  3.     bytes signature = 2;
  4. }

The signature_header is as defined for standard transactions, while the signature is over the concatenation of the signature_header bytes and the config_update bytes from the ConfigUpdateEnvelope message.

The ConfigUpdateEnvelope config_update bytes are a marshaled ConfigUpdate message which is defined as follows:

  1. message ConfigUpdate {
  2.     string channel_id = 1;
  3.     ConfigGroup read_set = 2;
  4.     ConfigGroup write_set = 3;
  5. }

The channel_id is the channel ID the update is bound for, this is necessary to scope the signatures which support this reconfiguration.

The read_set specifies a subset of the existing configuration, specified sparsely where only the version field is set and no other fields must be populated. The particular ConfigValue value or ConfigPolicy policy fields should never be set in the read_set. The ConfigGroup may have a subset of its map fields populated, so as to reference an element deeper in the config tree. For instance, to include the Application group in the read_set, its parent (the Channel group) must also be included in the read set, but, the Channel group does not need to populate all of the keys, such as the Orderer group key, or any of the values or policies keys.

The write_set specifies the pieces of configuration which are modified. Because of the hierarchical nature of the configuration, a write to an element deep in the hierarchy must contain the higher level elements in its write_set as well. However, for any element in the write_set which is also specified in the read_set at the same version, the element should be specified sparsely, just as in the read_set.

For example, given the configuration:

  1. Channel: (version 0)
  2.     Orderer (version 0)
  3.     Application (version 3)
  4.        Org1 (version 2)

To submit a configuration update which modifies Org1, the read_set would be:

  1. Channel: (version 0)
  2.     Application: (version 3)

and the write_set would be

  1. Channel: (version 0)
  2.     Application: (version 3)
  3.         Org1 (version 3)

When the CONFIG_UPDATE is received, the orderer computes the resulting CONFIG by doing the following:

  1. Verifies the channel_id and read_set. All elements in the read_set must exist at the given versions.

  2. Computes the update set by collecting all elements in the write_set which do not appear at the same version in the read_set.

  3. Verifies that each element in the update set increments the version number of the element update by exactly 1.

  4. Verifies that the signature set attached to the ConfigUpdateEnvelope satisfies the mod_policy for each element in the update set.

  5. Computes a new complete version of the config by applying the update set to the current config.

  6. Writes the new config into a ConfigEnvelope which includes the CONFIG_UPDATE as the last_update field and the new config encoded in the config field, along with the incremented sequence value.

  7. Writes the new ConfigEnvelope into a Envelope of type CONFIG, and ultimately writes this as the sole transaction in a new configuration block.

When the peer (or any other receiver for Deliver) receives this configuration block, it should verify that the config was appropriately validated by applying the last_update message to the current config and verifying that the orderer-computed config field contains the correct new configuration.

Permitted configuration groups and values

Any valid configuration is a subset of the following configuration. Here we use the notation peer.<MSG> to define a ConfigValue whose value field is a marshaled proto message of name <MSG> defined in fabric-protos/peer/configuration.proto. The notations common.<MSG>, msp.<MSG>, and orderer.<MSG> correspond similarly, but with their messages defined in fabric-protos/common/configuration.proto, fabric-protos/msp/mspconfig.proto, and fabric-protos/orderer/configuration.proto respectively.

Note, that the keys {{org_name}} and {{consortium_name}} represent arbitrary names, and indicate an element which may be repeated with different names.

  1. &ConfigGroup{
  2.     Groups: map<string, *ConfigGroup> {
  3.         "Application":&ConfigGroup{
  4.             Groups:map<String, *ConfigGroup> {
  5.                 {{org_name}}:&ConfigGroup{
  6.                     Values:map<string, *ConfigValue>{
  7.                         "MSP":msp.MSPConfig,
  8.                         "AnchorPeers":peer.AnchorPeers,
  9.                     },
  10.                 },
  11.             },
  12.         },
  13.         "Orderer":&ConfigGroup{
  14.             Groups:map<String, *ConfigGroup> {
  15.                 {{org_name}}:&ConfigGroup{
  16.                     Values:map<string, *ConfigValue>{
  17.                         "MSP":msp.MSPConfig,
  18.                     },
  19.                 },
  20.             },
  22.             Values:map<string, *ConfigValue> {
  23.                 "ConsensusType":orderer.ConsensusType,
  24.                 "BatchSize":orderer.BatchSize,
  25.                 "BatchTimeout":orderer.BatchTimeout,
  26.                 "KafkaBrokers":orderer.KafkaBrokers,
  27.             },
  28.         },
  29.         "Consortiums":&ConfigGroup{
  30.             Groups:map<String, *ConfigGroup> {
  31.                 {{consortium_name}}:&ConfigGroup{
  32.                     Groups:map<string, *ConfigGroup> {
  33.                         {{org_name}}:&ConfigGroup{
  34.                             Values:map<string, *ConfigValue>{
  35.                                 "MSP":msp.MSPConfig,
  36.                             },
  37.                         },
  38.                     },
  39.                     Values:map<string, *ConfigValue> {
  40.                         "ChannelCreationPolicy":common.Policy,
  41.                     }
  42.                 },
  43.             },
  44.         },
  45.     },
  47.     Values: map<string, *ConfigValue> {
  48.         "HashingAlgorithm":common.HashingAlgorithm,
  49.         "BlockDataHashingStructure":common.BlockDataHashingStructure,
  50.         "Consortium":common.Consortium,
  51.         "OrdererAddresses":common.OrdererAddresses,
  52.     },
  53. }

Channel configuration

Application configuration is for channels which are designed for application type transactions. It is defined as follows:

  1. &ConfigGroup{
  2.     Groups: map<string, *ConfigGroup> {
  3.         "Application":&ConfigGroup{
  4.             Groups:map<String, *ConfigGroup> {
  5.                 {{org_name}}:&ConfigGroup{
  6.                     Values:map<string, *ConfigValue>{
  7.                         "MSP":msp.MSPConfig,
  8.                         "AnchorPeers":peer.AnchorPeers,
  9.                     },
  10.                 },
  11.             },
  12.         },
  13.     },
  14. }

Just like with the Orderer section, each organization is encoded as a group. However, instead of only encoding the MSP identity information, each org additionally encodes a list of AnchorPeers. This list allows the peers of different organizations to contact each other for peer gossip networking.

Channel creation

For information about how to create a channel, check out Create a channel.