Hyperledger Fabric channel配置交易

时间  2019-11-19
标签 hyperledger fabric channel 配置 交易 繁體版
原文   原文链接

一个超级帐本区块链网络里每一个channel的共享配置都是存储在一个配置交易里。每一个配置交易一般被简称为configtx。golang

Channel 配置有如下重要属性：网络

1、有版本标识：配置里的全部元素都有一个关联版本。每次更新配置，版本号都维持最新。另外，每一个提交的配置会得到一个序列号。app

2、有权限：配置里的每一个元素都有一个关联策略，用来管理是否容许对这个元素进行修改。每个保存有当前配置副本的实例，都会按照关联策略的内容对新收到的配置改动进行验证权限。区块链

3、层次性：一个配置根组包含多个子组，而且层次中的每一个组都有关联的值和策略。较低层次能够获取上层的策略。测试


配置分析ui

配置做为一个HeaderType_CONFIG类型的交易存储在一个不包含其余交易的区块中。这些区块被称为Configuration Blocks，全部区块中的第一个区块称为genesis block。this

配置的样例存储在fabric/protos/common/configtx.proto。HeaderType_CONFIG类型的Envelope编码ConfigEnvelop信息做为Payload data的值。ConfigEnvelop定义以下：编码

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

last_update字段在下面的更新配置中有定义，该字段仅用于验证配置。当前提交的配置存在config字段，包含一个Config消息。加密

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

sequence的值在每次提交配置后加1,channel_group字段是包含该配置的根组。ConfigGroup是一个递归定义的结构，生成一个gruops树，每一个组都包含值和策略。ConfigGroup的定义以下：spa

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

由于ConfigGroup是一个递归结构，有层次概念。接下来咱们用go语言例子来表示。


// 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

在config层次结构中，每一个组定义了一个层次，每一个组有一系列关联的值和策略。值的定义以下：

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

策略的定义以下：

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

注意值、策略和组都有一个version和mod_policy字段。一个元素的version在每次更改后递增。mod_policy用来管理修改元素的签名。对于组，更改就是添加或者移除Values、Policies、或者组地图（或者修改mod_policy）。对于Values和Policies，修改就是改变修改Value或者Policy字段（或者修改mod_policy)。每一个元素的mod_policy在当前当前元素中有效

下面是一个定义在Channel.Groups["Application"]中的策略的示例（这里用的是golang语法，所以Channel.Groups["Application"].Policies["policy1"]表示根组Channel的子组Application的Policies里的policy1对应的策略）

  • policy1对应Channel.Groups["Application"].Policies["policy1"]

  • Org1/policy2对应Channel.Groups["Application"].Groups["Org1"].Policies["policy2"]

  • /Channel/policy3对应Channel.Policies["policy3"]

注意，若是mod_policy引用了一个不存在的策略，那么该元素不可修改。

Configuration updates / 更新配置

更新配置是提交一个HeaderType_CONFIG_UPDATE类型的Envelope消息，交易的Payload.data字段是序列化的ConfigUpdateEnvelope，其定义以下：

message ConfigUpdateEnvelope {
bytes config_update = 1; // A marshaled ConfigUpdate structure
repeated ConfigSignature signatures = 2; // Signatures over the config_update
}

其中signatures字段包含了受权更新配置的签名集，定义以下：

message ConfigSignature {
bytes signature_header = 1; // A marshaled SignatureHeader
bytes signature = 2; // Signature over the concatenation signatureHeader bytes and config bytes
}

signature_header如标准交易所定义，而签名则是signature_header字节和ConfigUpdateEnvelope中的config_update字节的拼接。

ConfigUpdateEnvelope中的config_update字段是序列化的ConfigUpdate，其定义为：

message ConfigUpdate {
string channel_id = 1; // Which channel this config update is for
ConfigGroup read_set = 2; // ReadSet explicitly lists the portion of the config which was read, this should be sparse with only Version set
ConfigGroup write_set = 3; // WriteSet lists the portion of the config which was written, this should included updated Versions
}

其中channel_id是配置更新所对应的channel ID，该字段是必要，由于它界定了支持本次配置更新的所需的签名范围。

read_set是现有配置的一个子集，其中仅含version字段，ConfigValue.value和ConfigPolicy.policy等其余字段不包含在read_set中。ConfigGroup会map字段组成的子集，以便引用配置树的深层元素。例如，为使Applicationgroup包含到read_set，它的上层（Channelgroup）也必须包含到read_set中，但没必要将Channelgroup中全部的key都包括进去，好比Orderer``group或者任何values或policies。

write_set指定了要被修改的那部分配置。因为配置的分层特性，修改深层元素就必须在write_set中包含其上层元素。write_set中的任意元素都会在read_set中指定相同版本的该元素。

例如，给出以下配置：

Channel: (version 0)
Orderer (version 0)
Appplication (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)

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

接收到CONFIG_UPDATE后，orderer会经过如下步骤计算CONFIG结果：

  1. 校验channel_id和read_set，read_set中全部元素必须存在对应的版本。

  2. 收集read_set与write_set中版本不一致的元素，计算更新集。

  3. 校验更新集中的元素的版本号是否递增1

  4. 校验更新集中每一个元素，ConfigUpdateEnvelope的签名知足mod_policy。

  5. 经过将更新集应用于当前配置，计算该配置的完整新版本

  6. 将新配置写成ConfigEnvelope做为CONFIG_UPDATE赋给last_update字段，新的配置赋给config字段，sequence字段自增。

  7. 将ConfigEnvelope写成CONFIG类型的Envelope，最终将此做为惟一交易写入配置区块。

当peer（或者任意其余接收Deliver者）接收到这个配置区块后，就会经过将last_update信息应用到当前配置并校验orderer计算的config字段是否包含正确的新配置，来验证该配置是否被正确校验。

Permitted configuration groups and values / 组和值得配置许可

有效的配置都是下面配置的子集。在此，用peer.<MSG>表示一个ConfigValue，其value字段是称为<MSG>的序列化后的信息，定义在fabric/protos/peer/configuration.proto。common.<MSG>，msp.<MSG>和orderer.<MSG>分别定义在fabric/protos/common/configuration.proto，fabric/protos/msp/mspconfig.proto和fabric/protos/orderer/configuration.proto。

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

注意，下面的{{org_name}} 和 {{consortium_name}}是任意的名字，表示能够重复使用不一样名称的元素。

&ConfigGroup{
Groups: map<string, *ConfigGroup> {
"Application":&ConfigGroup{
Groups:map<String, *ConfigGroup> {
{{org_name}}:&ConfigGroup{
Values:map<string, *ConfigValue>{
"MSP":msp.MSPConfig,
"AnchorPeers":peer.AnchorPeers,
},
},
},
},
"Orderer":&ConfigGroup{
Groups:map<String, *ConfigGroup> {
{{org_name}}:&ConfigGroup{
Values:map<string, *ConfigValue>{
"MSP":msp.MSPConfig,
},
},
},



Values:map<string, *ConfigValue> {
"ConsensusType":orderer.ConsensusType,
"BatchSize":orderer.BatchSize,
"BatchTimeout":orderer.BatchTimeout,
"KafkaBrokers":orderer.KafkaBrokers,
},
},
"Consortiums":&ConfigGroup{
Groups:map<String, *ConfigGroup> {
{{consortium_name}}:&ConfigGroup{
Groups:map<string, *ConfigGroup> {
{{org_name}}:&ConfigGroup{
Values:map<string, *ConfigValue>{
"MSP":msp.MSPConfig,
},
},
},
Values:map<string, *ConfigValue> {
"ChannelCreationPolicy":common.Policy,
}
},
},
},
},



Values: map<string, *ConfigValue> {
"HashingAlgorithm":common.HashingAlgorithm,
"BlockHashingDataStructure":common.BlockDataHashingStructure,
"Consortium":common.Consortium,
"OrdererAddresses":common.OrdererAddresses,
},
}

Orderer system channel configuration / Order channel 配置

ordering系统channel定义了建立channel的ordering参数和consortiums。ordering service必须有一个ordering系统channel，这是被建立的第一个channel。建议不要在ordering系统channel初始配置中定义application部分，可是测试是能够这么作。注意，任何对ordering系统channel有读权限的成员均可以查看全部channel建立，所以channel的访问应受限制。

The ordering parameters are defined as the following subset of config:

ordering参数定义以下：

&ConfigGroup{
Groups: map<string, *ConfigGroup> {
"Orderer":&ConfigGroup{
Groups:map<String, *ConfigGroup> {
{{org_name}}:&ConfigGroup{
Values:map<string, *ConfigValue>{
"MSP":msp.MSPConfig,
},
},
},



Values:map<string, *ConfigValue> {
"ConsensusType":orderer.ConsensusType,
"BatchSize":orderer.BatchSize,
"BatchTimeout":orderer.BatchTimeout,
"KafkaBrokers":orderer.KafkaBrokers,
},
},
},

ordering中的每一个组织都在Orderer组下有一个组元素，这个组定义了一个MSP参数，这个参数包含该组织的加密身份信息。Orderer组中的Values决定了ordering节点的功能。他们存在于每一个channel中，因此像orderer.BatchTimeout就可在不一样channel中指定不一样值。

启动时，orderer面对含有不少channel信息的文件系统，orderer经过识别带有consortiums组定义的channel来标识系统channel。consortiums组结构以下。

&ConfigGroup{
Groups: map<string, *ConfigGroup> {
"Consortiums":&ConfigGroup{
Groups:map<String, *ConfigGroup> {
{{consortium_name}}:&ConfigGroup{
Groups:map<string, *ConfigGroup> {
{{org_name}}:&ConfigGroup{
Values:map<string, *ConfigValue>{
"MSP":msp.MSPConfig,
},
},
},
Values:map<string, *ConfigValue> {
"ChannelCreationPolicy":common.Policy,
}
},
},
},
},
},

注意，每一个consortium定义一组成员，就行ordering组织的组织成员同样。每一个consortium也都定义了一个ChannelCreationPolicy，它是一种应用于受权channel建立请求的策略，一般这个值设为ImplicitMetaPolicy，要求channel的新成员签名受权channel建立。有关channel建立更信息的内容，请参阅文档后面的内容。

Application channel configuration / APP channel 配置

应用程序配置用于为应用类型交易设计的channel。其定义以下：

&ConfigGroup{
Groups: map<string, *ConfigGroup> {
"Application":&ConfigGroup{
Groups:map<String, *ConfigGroup> {
{{org_name}}:&ConfigGroup{
Values:map<string, *ConfigValue>{
"MSP":msp.MSPConfig,
"AnchorPeers":peer.AnchorPeers,
},
},
},
},
},
}

就像Orderer部分，每一个组织被编码为一个组。然而，app channel不只有MSP身份信息，每一个组织都附加了一个AnchorPeers列表。这个列表容许不一样组织的节点彼此联系。

应用程序channel经过对orderer组织和共识选项的编码，以容许对这些参数进行肯定性更新，所以包含了orderer系统channel配置的相同Orderer部分。但从应用角度看，这会在很大程度上被忽略。

Channel creation / 建立channel

当Orderer 接收到对一个不存在的channel的CONFIG_UPDATE信息时，orderer就会假设这是个建立channel的请求并执行如下操做：

  1. 经过查看高层组中的Consortium值，orderer标识所要执行建立channel请求的consortium（译注：这个词暂时不知翻译成什么好）。

  2. orderer验证Application组中的组织是对应的consortium中组织的一部分，并验证ApplicationGroup的版本是1。

  3. orderer验证consortium是否有成员，新的channel也会有application成员（建立没有成员的consortiums和channel只用于测试）。

  4. orderer从ordering系统channel取得Orderer组，并建立一个包含新指定成员的Application组，并将其mod_policy指定为在consortium config中指定的ChannelCreationPolicy，从而建立一个模板配置。注意，这个策略（mod_policy）是基于新配置的上下文的，所以须要全部成员的策略就是要须要新channel中全部成员的签名，而不是consortium中的全部成员。

  5. orderer用CONFIG_UPDATE更新这个模板配置。由于CONFIG_UPDATE用于Application组（其版本是1）的修改，因此配置码根据ChannelCreationPolicy验证这些更新。若是channel建立包含任何其它修改，例如修改单个组织的锚节点，则调用该元素的相应mod策略。

  6. 带有新channel配置的CONFIG交易被包装并经过order系统channel发送到ordering，ordering以后channel就建立完成。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程