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<string,ConfigGroup> groups = 2;
- map<string,ConfigValue> values = 3;
- map<string,ConfigPolicy> 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 消息的时候, 就计算出配置结果, 其过程如下:
验证 channel_id 和 read_set,read_set 中的所有元素必须在给出的 version 版本上存在;
通过 write_set 中的所有与 read_set 中 version 不同的元素计算出需要更新的配置;
验证 update-set 中每一个需要更新的元素, 并将其版本号增加 1
对于每个要更新的元素, 都验证 ConfigUpdateEnvelope 后附着的签名符合 mod_policy.
对当前配置应用 update-set, 以产生一个新的完整的配置 version
将新的配置写入到 ConfigEnvelope 中, 其中包含了 CONFIG_UPDATE 作为 last_update, 新的配置作为 config 域, 同时增加序列号的值.
将新的 ConfigEnvelop 打包进 CONFIG 类型的 ENVELOP 中, 最终将其写入到一个新的 config 区块中.
当 peer(或者是任何其他的 Deliver 接收者) 收到这个配置区块时, 就会验证配置, 验证方法是, peer 应用部署 last_update 域的配置, 并验证 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
- , and
- fabric/protos/orderer/configuration.proto
respectively.
- &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
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<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 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<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 orgs 的 orgnization 成员一样. 每个 consortium 也定义了一个
ChannelCreationPolicy
, 这是用来授权 channel 创建请求的策略. 通常, 这个值会被设置为 ImplicitMetaPolicy, 这时 channel 创建需要 channel 的成员来签名确认该 channel 创建请求.
Application channel configuration
这是应用类型的配置 transaction, 定义如下:
- &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 中一样, 每个 orgnization 都作为一个 group 成员嵌入到 Application ConfigGroup 中. 除了 MSP 信息, 还包括了 AnchorPeer 信息. AnchorPeer 可以在整个 channel 上可见, 也就是说, 可以实现用一个 channel 上不同 org 的消息 gossip
Channel 创建
当 Orderer 收到一个对不存在 channel 的 CONFIG_UPDATE 时, 就会认为这是一个 channel 创建请求, 其过程如下:
Orderer 识别 channel 创建请求中的 consortium, 这一步就是通过在 group 的顶层查看 Consortium.
Orderer 验证在 Application group 中的 organization 是相关的 consortium 中 organization 的子集, 并且 ApplicationGroup 的 version 是 1.
Orderer 验证 consortium 中有成员, 新的 channel 也有成员
Orderer 从系统 channel 的 OrdererGroup 中创建一个模板 configuration, 并在 consortium 中创建一个带有新成员并且有着特定修改策略的 ApplicationGroup. 策略的评价验证是在新的配置环境下进行的, 所有如果修改策略是全部成员签名的话, 全部成员指的是新的配置生效后的全部成员.
Orderer 之后会应用 ConfigUpdate 作为模板的配置更新, 因为 ConfigUpdate 会对 Application group 进行修改, config 代码会根据 ChannelCreationPolicy 来验证这些更新. 如果创建请求中包含了任何其他修改, 比如一个 anchor-peer, 相关的修改策略会被激活.
带有新的 channel 配置信息的 Config-Transaction 会被打包然后被 Orderer 系统 channel 层排序, 等排序完成后, channel 就被创建了.
来源: http://www.bubuko.com/infodetail-2690692.html