channel Configuration Transaction

Hyperledger Fabric区块链网络中的配置存储在一个configuration-transaction的集合中，每个channel都有一个。每个configuration-transaction通常简称为configtx。

configtx 具备如下几个特点：

• Versioned: 配置中的每一个元素都有一个与之关联的version，配置更改时version会增加。每个确认的配置都有一个序列号。


• Permissioned：配置中的每一个元素都有一个相关的策略，这个策略会控制对应元素是否允许修改。拥有旧configtx的任意角色都可以根据这些策略来验证新config的有效性。


• Hierarchical: config结构中的group项是递归定义的，这就形成了一种关系继承，后续详细讲。

config类型结构定义

配置作为一个HeaderType_CONFIG类型的transaction存储在一个没有其他交易的区块中。这些区块被称为配置区块，配置区块的第一个称之为创世块。

config的结构定义在fabric/protos/common/configtx.proto中，HeaderType_CONFIG类型消息包含了一个ConfigEnvelope成员作为Payload、data域。对于ConfigEnvelope的定义如下：

message ConfigEnvelope {
Config cOnfig= 1;
Envelope last_update = 2;
}

ConfigEnvelope结构中的last_update在后面会欧定义，但是只有当需要验证配置时候才有必要。当前确认的配置存储在config中。

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

序列号在每次确认配置时都会增加，其中的channel_group域是包含配置信息的root-group。ConfigGroup的定义是递归的，这形成了一个group构成的树结构，每个group都包含了值以及策略。

message ConfigGroup {
uint64 version = 1;
map groups = 2;
map values = 3;
map policies = 4;
string mod_policy = 5;
}

ConfigGroup是递归调用的，这就形成了一个继承关联的关系。

// Assume the following groups are defined
var root, child1, child2, grandChild1, grandChild2, grandChild3 *ConfigGroup
// Set the following values
root.Groups["child1"] = child1
root.Groups["child2"] = child2
child1.Groups["grandChild1"] = grandChild1
child2.Groups["grandChild2"] = grandChild2
child2.Groups["grandChild3"] = grandChild3
// The resulting config structure of groups looks like:
// root:
// child1:
// grandChild1
// child2:
// grandChild2
// grandChild3

每个group都定义了一个level的配置，每个group都有一系列相关的值和策略。

Value的定义如下：

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

策略定义如下：

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

需要注意的是，值、策略、group都有version和一个mod_policy。version是在每次修改时都会增加。mod_policy用来管理修改元素所需要的签名。对于group，修改行为就是针对三个map添加或者删除元素。对于值和策略，修改就是改变其中的值。每个元素中的mod_policy都是当前level的配置内容的评定。

Configuration updates

Configuration updates作为一个HeaderType_CONFIG_UPDATE类型的消息被提交，其中的Payload和data域是字节化后的ConfigUpdateEnvelope变量。

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

sigature域包含了一系列签名，签名的结构定义如下;

message ConfigSignature {
bytes signature_header = 1;
bytes signature = 2;
}

ConfigUpdateEnvelope->config_update是字节化的ConfigUpdate。

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

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

read_set指定了一组已经存在的配置的子集，只包含了已有配置结构中的version字段，而其他内容没有指定。config结构的中value和policy不能在read_set中设置。

write_set指定了配置要被修改的内容。由于ConfigGroup的递归继承特点，如果要修改较深层次上的配置，需要在write-set中包含高层次的元素。有的元素的version如果与read_set中的version版本一致，那么就应该向read_set中那样只定义version部分，因为不需要修改，所以value和policy不需要给出。

比如我们给出如下配置：

Channel: (version 0)
Orderer (version 0)
Application (version 3)
Org1 (version 2)

如果想要提交一个队Org1的修改，那么read_set应该为：

Channel: (version 0)
Application: (version 3)

write_set应该为：

Channel: (version 0)
Application: (version 3)
Org1 (version 3)

当Orderer收到ConfigUpdate消息的时候，就计算出配置结果，其过程如下：

1. 验证channel_id和read_set，read_set中的所有元素必须在给出的version版本上存在；


2. 通过write_set中的所有与read_set中version不同的元素计算出需要更新的配置；


3. 验证update-set中每一个需要更新的元素，并将其版本号增加1


4. 对于每个要更新的元素，都验证ConfigUpdateEnvelope后附着的签名符合mod_policy。


5. 对当前配置应用update-set，以产生一个新的完整的配置version


6. 将新的配置写入到ConfigEnvelope中，其中包含了CONFIG_UPDATE作为last_update，新的配置作为config域，同时增加序列号的值。


7. 将新的ConfigEnvelop打包进CONFIG类型的ENVELOP中，最终将其写入到一个新的config区块中。

当peer（或者是任何其他的Deliver接收者）收到这个配置区块时，就会验证配置，验证方法是，peer应用部署last_update域的配置，并验证config域中新的配置项。

Permitted configuration groups and values

任何有效的配置都是如下配置的一个子集。这里我们用peer.来定义个ConfigValue，其value域是经过字节序列化的，在文件fabric/protos/peer/configuration.proto中定义。common.、msp.、orderer.也相同，只是消息分别在下面几个文件中定义。

fabric/protos/common/configuration.proto,
fabric/protos/msp/mspconfig.proto, and
fabric/protos/orderer/configuration.proto respectively.

&ConfigGroup{
Groups: map {
"Application":&ConfigGroup{
Groups:map {
{{org_name}}:&ConfigGroup{
Values:map{
"MSP":msp.MSPConfig,
"AnchorPeers":peer.AnchorPeers,
},
},
},
},
"Orderer":&ConfigGroup{
Groups:map {
{{org_name}}:&ConfigGroup{
Values:map{
"MSP":msp.MSPConfig,
},
},
},
Values:map {
"ConsensusType":orderer.ConsensusType,
"BatchSize":orderer.BatchSize,
"BatchTimeout":orderer.BatchTimeout,
"KafkaBrokers":orderer.KafkaBrokers,
},
},
"Consortiums":&ConfigGroup{
Groups:map {
{{consortium_name}}:&ConfigGroup{
Groups:map {
{{org_name}}:&ConfigGroup{
Values:map{
"MSP":msp.MSPConfig,
},
},
},
Values:map {
"ChannelCreationPolicy":common.Policy,
}
},
},
},
},
Values: map {
"HashingAlgorithm":common.HashingAlgorithm,
"BlockHashingDataStructure":common.BlockDataHashingStructure,
"Consortium":common.Consortium,
"OrdererAddresses":common.OrdererAddresses,
},
}

Orderer system channel configuration

ordering system channel需要定义ordering parameters和consortium，以创建channel。对于一个ordering service必须有一个确切的ordering system channel，并且这是第一个创建的channel（更准确的说，这是在启动时就创建的channel）。建议不要允许应用部分来与ordering system channel的创世块交互，当然作为测试可以这样试一下。需要注意，任何对ordering system channel有读权限的成员都可以看到所有新channel的创建，所以说Orderer system channel的访问权限应该被严格限制的。

Orderer 参数是下面定义的子集：

&ConfigGroup{
Groups: map {
"Orderer":&ConfigGroup{
Groups:map {
{{org_name}}:&ConfigGroup{
Values:map{
"MSP":msp.MSPConfig,
},
},
},
Values:map {
"ConsensusType":orderer.ConsensusType,
"BatchSize":orderer.BatchSize,
"BatchTimeout":orderer.BatchTimeout,
"KafkaBrokers":orderer.KafkaBrokers,
},
},
},

Ordering service的每个组织Organization在Orderer group下都有一个group element。这个group定义了参数MSP，MSP包含对应Orgnazation的加密信息。 The Values of the Orderer group determine how the ordering nodes function. They exist per channel, so
orderer.BatchTimeout for instance may be specified differently on one channel than another.

启动时， Orderer会处理一个包含了channel信息的文件系统，Orderer通过识别带有consortium group的channel来识别系统channel，即系统channel才会定义consortium group。

&ConfigGroup{
Groups: map {
"Consortiums":&ConfigGroup{
Groups:map {
{{consortium_name}}:&ConfigGroup{
Groups:map {
{{org_name}}:&ConfigGroup{
Values:map{
"MSP":msp.MSPConfig,
},
},
},
Values:map {
"ChannelCreationPolicy":common.Policy,
}
},
},
},
},
},

每个consortium都定义了一系列成员，就像ordering orgs 的orgnization成员一样。每个consortium也定义了一个ChannelCreationPolicy，这是用来授权channel创建请求的策略。通常，这个值会被设置为ImplicitMetaPolicy，这时channel创建需要channel的成员来签名确认该channel创建请求。

Application channel configuration

这是应用类型的配置transaction，定义如下：

&ConfigGroup{
Groups: map {
"Application":&ConfigGroup{
Groups:map {
{{org_name}}:&ConfigGroup{
Values:map{
"MSP":msp.MSPConfig,
"AnchorPeers":peer.AnchorPeers,
},
},
},
},
},
}

就像在Orderer中一样，每个orgnization都作为一个group成员嵌入到Application ConfigGroup中。除了MSP信息，还包括了AnchorPeer信息。AnchorPeer可以在整个channel上可见，也就是说，可以实现用一个channel上不同org的消息gossip

Channel 创建

当Orderer收到一个对不存在channel的CONFIG_UPDATE时，就会认为这是一个channel创建请求，其过程如下：

1. Orderer识别channel创建请求中的consortium，这一步就是通过在group的顶层查看Consortium。


2. Orderer验证在Application group 中的organization是相关的consortium中organization的子集，并且ApplicationGroup的version是1。


3. Orderer验证consortium中有成员，新的channel也有成员


4. Orderer从系统channel的OrdererGroup中创建一个模板configuration，并在consortium中创建一个带有新成员并且有着特定修改策略的ApplicationGroup。策略的评价验证是在新的配置环境下进行的，所有如果修改策略是全部成员签名的话，全部成员指的是新的配置生效后的全部成员。


5. Orderer之后会应用ConfigUpdate作为模板的配置更新，因为ConfigUpdate会对Application group 进行修改，config代码会根据ChannelCreationPolicy来验证这些更新。如果创建请求中包含了任何其他修改，比如一个anchor-peer，相关的修改策略会被激活。


6. 带有新的channel配置信息的Config-Transaction会被打包然后被Orderer系统channel层排序，等排序完成后，channel就被创建了。