如果看完创建与加入通道的部分，这里基本上比他们要更简单。

前面重复的部分我们就不再赘述，直接来到orderer来处理配置更新的部分。

func (bh *Handler) ProcessMessage(msg *cb.Envelope, addr string) (resp *ab.BroadcastResponse) {
   ...

   if !isConfig {
   ...
   } else { // isConfig

      config, configSeq, err := processor.ProcessConfigUpdateMsg(msg)

      err = processor.Configure(config, configSeq)
      
   }

   return &ab.BroadcastResponse{Status: cb.Status_SUCCESS}
}

创建通道的部分，我们已经知道当没有通道的时候，processor是SystemChannel来处理，而这里是完全不同的情况，会用StandardChannel来托管

StandardChannel

ProcessConfigUpdateMsg

func (s *StandardChannel) ProcessConfigUpdateMsg(env *cb.Envelope) (config *cb.Envelope, configSeq uint64, err error) {
   logger.Debugf("Processing config update message for channel %s", s.support.ChainID())

   // Call Sequence first.  If seq advances between proposal and acceptance, this is okay, and will cause reprocessing
   // however, if Sequence is called last, then a success could be falsely attributed to a newer configSeq
   seq := s.support.Sequence()
   err = s.filters.Apply(env)
   if err != nil {
      return nil, 0, err
   }

   configEnvelope, err := s.support.ProposeConfigUpdate(env)
   if err != nil {
      return nil, 0, err
   }

   config, err = utils.CreateSignedEnvelope(cb.HeaderType_CONFIG, s.support.ChainID(), s.support.Signer(), configEnvelope, msgVersion, epoch)
   if err != nil {
      return nil, 0, err
   }
   
   err = s.filters.Apply(config)
   if err != nil {
      return nil, 0, err
   }

   return config, seq, nil
}

这里首先会筛选一遍，创建通道的时候我们知道SystemChannel的过滤器，这里我们来看下StandardChannel的过滤器。

• func CreateStandardChannelFilters(filterSupport channelconfig.Resources) *RuleSet {
     ordererConfig, ok := filterSupport.OrdererConfig()
     if !ok {
        logger.Panicf("Missing orderer config")
     }
     return NewRuleSet([]Rule{
        EmptyRejectRule,
        NewExpirationRejectRule(filterSupport),
        NewSizeFilter(ordererConfig),
        NewSigFilter(policies.ChannelWriters, filterSupport),
     })
  }
  

  • envelope的签名身份不能过期
  • 消息大小不能超标
  • 要满足/channel/writer的权限，也就是Any member，看你配置。

• 如果过滤器都没问题，接下来处理配置。里面主要是将变更的配置与现有通道配置进行合并，产出一份完整的通道配置。

• 之后组装HeaderType_CONFIG类型的SignedProposal

• 再次做一遍筛选

• 之后的流程就是发给orderer的共识服务里去流转，中间的流程跟通道创建类似，这里直接跳到最终接收HeaderType_CONFIG的地方。

WriteConfigBlock

func (bw *BlockWriter) WriteConfigBlock(block *cb.Block, encodedMetadataValue []byte) {
   ...

   switch chdr.Type {
   case int32(cb.HeaderType_ORDERER_TRANSACTION):
      ...
   case int32(cb.HeaderType_CONFIG):
      configEnvelope, err := configtx.UnmarshalConfigEnvelope(payload.Data)

      err = bw.support.Validate(configEnvelope)

      bundle, err := bw.support.CreateBundle(chdr.ChannelId, configEnvelope.Config)
     
      bw.support.Update(bundle)
   default:
      logger.Panicf("Told to write a config block with unknown header type: %v", chdr.Type)
   }

   bw.WriteBlock(block, encodedMetadataValue)
}

• 这里又将configEnvelope转换成bundle。这个过程已经转两次了，实在是浪费。不管了，配置部分就是这样，我习惯了。
• 为了更新配置，当然了需要去更新通道绑定的bundle，这次毫无意外调用了bw.support.Update(bundle)，这里就是最终的目的，通道配置更新。

小结

之后就是写入本地账本，然后同步给orderer，然后被leaderpeer拉取，然后再同步非peer成员，然后整个世界都同步配置了。而全部都是通过update bundle来实现配置更新。