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。
