Fabric v1.*** 通道（Channel）机制运行原理
一、Channel实现原理
1.1 System Channel
channel是Orderer的一个模块，Fabric的启动会创建一个内建的system channel，是系统的一个默认链，用于管理其他的user channel。
orderer启动的时候必须要有该channel的genesis block，genesis block里规定了所有关于system channel的配置，因此所有的orderer都必须拿到相同的genesis block才能启动。
1.2 创建新channel
创建一个新的user channel时，其实是向system channel发送一个“New Channel” transaction（包括要创建的channel的名字，channel的配置信息，包括哪些组织，出块属性等），这个transaction会被提交到sysem channel，然后orderer中会创建一个新的user channel，刚刚发送的transction里的信息作为user channel的genesis block，这样user channel就创建完成了。
1.3 普通交易（Normal Transaction）
join channel的操作就是把genesis block拿下来，送给peer，让peer知道去哪儿找到orderer节点（genesis block里含有orderer的address信息），peer也会知道链里包含哪些组织（peer一定是属于这个channel允许的组织），这时候peer就可以参与transaction了，下图中的“Normal”就是用户的普通交易。
1.4 配置交易（Config Transaction）
当需要修改channel的属性（新增一个组织、修改batchsize等配置），其实是向链发送一个“Config”transaction，该transaction无需遵循出块规则，会立即生成一个块，因为配置的信息需要尽快生效。修改一个链的属性的时候，本身也是需要共识的，共识产生块后，提交到orderer的本身的账本后，进行真正的属性更新。
1.5 总结
使用上述同样的方法，system channel可以创建一个新的user channel B，system channel只负责创建user channel，创建完之后，user channel完全独立，与system channel也没有任何关系了。
system channel与user channel在实现上没有区别，同样样可以提交一个“Config”transaction，共识产生块后更新配置属性。
Fabric的channel之间是相互隔离的，仅有的联系是user channel需要通过system channel进行创建，但是创建完之后，这些channel相互之间没有任何影响了。以此类推，新的user channel B同样可以通过提交“Config” transaction修改配置属性，或者参与业务交易；通过向system channel提交“New Channel”交易创建user channel C。
三、Channel数据隔离
创建channel的交易在system channel共识完成后，channel A就会被创建，里面包含OrgA和OrgB两个组织，如下图所示：
使用上述方法，可以创建出channel B和channel C，组织OrgA同时在channelA和channelB中，组织OrgB同时在channelA、channelB、channelC中，组织OrgC在channelB、channelC中，如下图所示：
在这种情况下，channelB中包含全部3个组织，3个组织都可以在channelB中互相交易，而组织OrgC无法获取到channelA中的交易，组织OrgA无法获取到channelC中的交易，这样就实现了数据隔离和隐私。
三、Channel上部署chaincode
channel建立完成后，就可以在channel上部署chaincode，如下图所示，在channelA上部署了“mycc_v1.0”的chaincode，部署该chaincode时指定了背书策略为“AND(OrgA, OrgB)”，组织OrgA和OrgB都必须给该chaincode的交易背书才会被写入账本，这也意味着组织OrgA和OrgB都必须部署“mycc_v1.0”chaincode，如下图所示：
利用规定的语法可以组成一些比较复杂的背书策略，如下图所示，在channelB部署“mycc_v1.0”chaincode的背书策略为“OR(OrgA, AND(OrgB, OrgC))”，表示组织OrgA单独背书即可，或者组织OrgB和OrgC一起背书，channelC的背书策略为“OutOf(1, OrgB, OrgC)”，表示要求除组织B和组织C外的另一个组织进行背书。
另外，任何channel上都可以部署多个chaincode，并且这些chaincode可以相互调用，在同一个channel上的智能合约互相调用可以修改数据，不同channel上的智能合约也可以互相调用（取决于ACL），但是只能读取数据，不能修改数据，不同的chaincode组织起来可以完成一个复杂的业务逻辑。如下图所示，channelB和channelC上还部署了“evmcc_v0.1*”chaincode，用于运行以太坊的智能合约，channelA上还部署了“hercc_v2.0”chaincode。
