金色財經訊：Fabric 1.0 的重要特徵是支持多chain和多channel；所謂的chain（鏈）實際上是包含Peer節點（負責維護區塊鏈的帳本）、帳本、ordering通道的邏輯結構，它將參與者與數據（包含chaincode在）進行隔離，滿足了不同業務場景下的」不同的人訪問不同數據「的基本要求。
同時，一個peer節點負責維護區塊鏈的帳本的同時也可以參與到多個chain中（通過接入多個channel）；如下圖所示
關於通道：通道是有共識服務（ordering）提供的一種通訊機制，類似於消息系統中的發布-訂閱（PUB/SUB)中的topic；基於這種發布-訂閱關係，將peer（負責維護區塊鏈的帳本）和orderer連接在一起，形成一個個具有保密性的通訊鏈路（虛擬），實現了業務隔離的要求；通道也與帳本（ledger）-狀態（worldstate）緊密相關；如下圖所示：
共識服務與（P1、PN）、（P1、P2、P3）、（P2、P3）組成了三個相互獨立的通道，加入到不同通道的Peer節點負責維護區塊鏈的帳本的同時能夠維護各個通道對應的帳本和狀態；也其實也對應現實世界中，不同業務場景下的參與方，例如銀行、保險公司；物流企業、生產企業等實體結構；我們可以看到channel機制實際上是的Fabric建模實際業務流程的能力大大增強了，大家可以發揮想像力去找到可能的應用領域
交易（數據）流程說明
新版本的架構變化導致新的交易流程的變化，我們簡述如下：
總體流程如下圖所示：
應用程式通過SDK發送請求道Peer節點（負責維護區塊鏈的帳本）（一個或多個）
peer節點分別執行交易（通過chaincode），但是並不將執行結果提交到本地的帳本中（可以認為是模擬執行，交易處於掛起狀態），參與背書的peer將執行結果返回給應用程式（其中包括自身對背書結果的籤名）
應用程式 收集背書結果並將結果提交給Ordering服務節點
Ordering服務節點執行共識過程並生成block，通過消息通道發布給Peer節點，由peer節點各自驗證交易並提交到本地的ledger中（包括state狀態的變化）
在新的架構中，Peer節點負責維護區塊鏈的帳本（ledger）和狀態（State），本地的帳本稱為PeerLedger，其結構如下：
我們可以看到，整個區塊結構分為文件系統存儲的Block結構和資料庫維護的State狀態，其中state的存儲結構是可以替換的，可選的實現包括各種KV資料庫（LEVELDB，CouchDB等）；
上邊就是我們對Fabric 1.0版本的簡要介紹，由於Fabric的複雜性，後續我也會針對1.0版本中的技術細節和實現機制進行專題說明，敬請關注；
同時，1.0 版本的代碼和文檔每天都在更新，請大家關注官網和github，這裡是最好學習天地。
最後說民一下大家比較關心的版本計劃：
1.0版本的版本計劃
下邊是劇透的官方開發計劃，只是「Proposed「，也許後期會有變化：
從官方公布的計劃看，1.0版本應該可以在3月份完成release，大家一起期待這個最新版本的面世。