協議規範

前言

這份文件是帶有許可權的區塊鏈的工業界實現的協議規範。它不會詳細的解釋實現細節，而是描述系統和應用之間的介面和關係。

目標讀者

這份規範的目標讀者包括：

• 想實現符合這份規範的區塊鏈的廠商
• 想擴充套件 fabric 功能的工具開發者
• 想利用區塊鏈技術來豐富他們應用的應用開發者

作者

下面這些作者編寫了這份分檔： Binh Q Nguyen,Elli Androulaki, Angelo De Caro, Sheehan Anderson, Manish Sethi, ThorstenKramp, Alessandro Sorniotti, Marko Vukolic, Florian Simon Schubert, Jason KYellick, Konstantinos Christidis, Srinivasan Muralidharan, Anna D Derbakova,Dulce Ponceleon, David Kravitz, Diego Masini.

評審

下面這些評審人評審了這份文件： Frank Lu, JohnWolpert, Bishop Brock, Nitin Gaur, Sharon Weed, Konrad Pabjan.

致謝

下面這些貢獻者對這份規範提供了技術支援: Gennaro Cuomo,Joseph A Latone, Christian Cachin

目錄

1. 介紹

• 1.1 什麼是 fabric ?
• 1.2 為什麼是 fabric ?
• 1.3 術語

2. Fabric

• 2.1 架構
• 2.1.1 Membership 服務
• 2.1.2 Blockchain 服務
• 2.1.3 Chaincode 服務
• 2.1.4 事件
• 2.1.5 應用程式介面
• 2.1.6 命令列介面
• 2.2 拓撲
• 2.2.1 單驗證 Peer
• 2.2.2 多驗證 Peers
• 2.2.3 多鏈

3. 協議

• 3.1 訊息
• 3.1.1 發現訊息
• 3.1.2 交易訊息
• 3.1.2.1 交易資料結構
• 3.1.2.2 交易規範
• 3.1.2.3 交易部署
• 3.1.2.4 交易呼叫
• 3.1.2.5 交易查詢
• 3.1.3 同步訊息
• 3.1.4 共識訊息
• 3.2 總賬
• 3.2.1 區塊鏈
• 3.2.1.1 塊
• 3.2.1.2 塊 Hashing
• 3.2.1.3 非雜湊資料(NonHashData)
• 3.2.1.4 交易
• 3.2.2 世界狀態(World State)
• 3.2.2.1 世界狀態的 Hashing
• 3.2.2.1.1 Bucket-tree
• 3.3 Chaincode
• 3.3.1 Virtual Machine 例項化
• 3.3.2 Chaincode 協議
• 3.3.2.1 Chaincode 部署
• 3.3.2.2 Chaincode 呼叫
• 3.3.2.3 Chaincode 查詢
• 3.3.2.4 Chaincode 狀態
• 3.4 可插拔的共識框架
• 3.4.1 共識者介面
• 3.4.2 共識程式介面
• 3.4.3 Inquirer 介面
• 3.4.4 Communicator 介面
• 3.4.5 SecurityUtils 介面
• 3.4.6 LedgerStack 介面
• 3.4.7 Executor 介面
• 3.4.7.1 開始批量交易
• 3.4.7.2 執行交易
• 3.4.7.3 提交與回滾交易
• 3.4.8 Ledger 介面
• 3.4.8.1 ReadOnlyLedger 介面
• 3.4.8.2 UtilLedger 介面
• 3.4.8.3 WritableLedger 介面
• 3.4.9 RemoteLedgers 介面
• 3.4.10 Controller 包
• 3.4.11 Helper 包
• 3.5 事件
• 3.5.1 事件流
• 3.5.2 事件結構
• 3.5.3 事件介面卡

4. 安全

•  
  4. 安全
• 4.1 商業安全需求
• 4.2 使用成員管理的使用者隱私
• 4.2.1 使用者/客戶端註冊過程
• 4.2.2 過期和廢止證書
• 4.3 基礎設施層面提供的交易安全
• 4.3.1 交易的安全生命週期
• 4.3.2 交易保密性
• 4.3.2.1 針對使用者的保密
• 4.3.2.2 針對驗證器的保密
• 4.3.3 防重放攻擊
• 4.4 應用的訪問控制功能
• 4.4.1 呼叫訪問控制
• 4.4.2 讀訪問控制
• 4.5 線上錢包服務
• 4.6 網路安全(TLS)
• 4.7 當前版本的限制
• 4.7.1 簡化客戶端
• 4.7.2 簡化交易保密

5. 拜占庭共識

• 5.1 概覽
• 5.2 Core PBFT

6. 應用程式設計介面

• 6.1 REST 服務
• 6.2 REST API
• 6.3 CLI

7. 應用模型

• 7.1 應用組成
• 7.2 應用樣例

8. 未來發展方向

• 8.1 企業整合
• 8.2 效能與可擴充套件性
• 8.3 附加的共識外掛
• 8.4 附加的語言

9. References

1. 介紹

這份文件規範了適用於工業界的區塊鏈的概念，架構和協議。

1.1 什麼是 fabric?

fabric 是在系統中數字事件，交易呼叫，不同參與者共享的總賬。總賬只能通過共識的參與者來更新，而且一旦被記錄，資訊永遠不能被修改。每一個記錄的事件都可以根據參與者的協議進行加密驗證。

交易是安全的，私有的並且可信的。每個參與者通過向網路membership服務證明自己的身份來訪問系統。交易是通過發放給各個的參與者，不可連線的，提供在網路上完全匿名的證書來生成的。交易內容通過複雜的金鑰加密來保證只有參與者才能看到，確保業務交易私密性。

總賬可以按照規定規則來審計全部或部分總賬分錄。在與參與者合作中，審計員可以通過基於時間的證書來獲得總賬的檢視，連線交易來提供實際的資產操作。

fabric 是區塊鏈技術的一種實現，比特幣是可以在fabric上構建的一種簡單應用。它通過模組化的架構來允許元件的“插入-執行”來實現這份協議規範。它具有強大的容器技術來支援任何主流的語言來開發智慧合約。利用熟悉的和被證明的技術是fabric的座右銘。

1.2 為什麼是 fabric?

早期的區塊鏈技術提供一個目的集合，但是通常對具體的工業應用支援的不是很好。為了滿足現代市場的需求，fabric 是基於工業關注點針對特定行業的多種多樣的需求來設計的，並引入了這個領域內的開拓者的經驗，如擴充套件性。fabric 為許可權網路，隱私，和多個區塊鏈網路的私密資訊提供一種新的方法。

1.3 術語

以下術語在此規範的有限範圍內定義，以幫助讀者清楚準確的瞭解這裡所描述的概念。

交易(Transaction)是區塊鏈上執行功能的一個請求。功能是使用**鏈碼(Chaincode)**來實現的。

交易者(Transactor)是向客戶端應用這樣發出交易的實體。

總賬(Ledger)是一系列包含交易和當前**世界狀態(World State)**的加密的連結塊。

世界狀態(World State)是包含交易執行結果的變數集合。

鏈碼(Chaincode)是作為交易的一部分儲存在總賬上的應用級的程式碼（如智慧合約）。鏈碼執行的交易可能會改變世界狀態。

驗證Peer(ValidatingPeer)是網路中負責達成共識，驗證交易並維護總賬的一個計算節點。

非驗證Peer(Non-validatingPeer)是網路上作為代理把交易員連線到附近驗證節點的計算節點。非驗證Peer只驗證交易但不執行它們。它還承載事件流服務和REST服務。

帶有許可權的總賬(PermissionedLedger)是一個由每個實體或節點都是網路成員所組成的區塊鏈網路。匿名節點是不允許連線的。

隱私(Privacy)是鏈上的交易者需要隱瞞自己在網路上身份。雖然網路的成員可以檢視交易，但是交易在沒有得到特殊的許可權前不能連線到交易者。

保密(Confidentiality)是交易的內容不能被非利益相關者訪問到的功能。

可審計性(Auditability)作為商業用途的區塊鏈需要遵守法規，很容易讓監管機構審計交易記錄。所以區塊鏈是必須的。

2. Fabric

fabric是由下面這個小節所描述的核心元件所組成的。

2.1 架構

這個架構參考關注在三個類別中：會員(Membership)，區塊鏈(Blockchan)和鏈碼(chaincode)。這些類別是邏輯結構，而不是物理上的把不同的元件分割到獨立的程序，地址空間，（虛擬）機器中。

2.1.1 成員服務

成員服務為網路提供身份管理，隱私，保密和可審計性的服務。在一個不帶許可權的區塊鏈中，參與者是不需要被授權的，且所有的節點都可以同樣的提交交易並把它們彙集到可接受的塊中，既：它們沒有角色的區分。成員服務通過公鑰基礎設施(Public KeyInfrastructure (PKI))和去中心化的/共識技術使得不帶許可權的區塊鏈變成帶許可權的區塊鏈。在後者中，通過實體註冊來獲得長時間的，可能根據實體型別生成的身份憑證（登記證書enrollmentcertificates）。在使用者使用過程中，這樣的證書允許交易證書頒發機構（TransactionCertificate Authority (TCA)）頒發匿名證書。這樣的證書，如交易證書，被用來對提交交易授權。交易證書儲存在區塊鏈中，並對審計叢集授權，否則交易是不可連結的。

2.1.2 區塊鏈服務

區塊鏈服務通過 HTTP/2 上的點對點（peer-to-peer）協議來管理分散式總賬。為了提供最高效的雜湊演算法來維護世界狀態的複製，資料結構進行了高度的優化。每個部署中可以插入和配置不同的共識演算法（PBFT, Raft, PoW,PoS）。

2.1.3 鏈碼服務

鏈碼服務提供一個安全的，輕量的沙箱在驗證節點上執行鏈碼。環境是一個“鎖定的”且安全的包含簽過名的安全作業系統映象和鏈碼語言，Go，Java 和 Node.js 的執行時和 SDK 層。可以根據需要來啟用其他語言。

2.1.4 事件

驗證 peers 和鏈碼可以向在網路上監聽並採取行動的應用傳送事件。這是一些預定義好的事件集合，鏈碼可以生成客戶化的事件。事件會被一個或多個事件介面卡消費。之後介面卡可能會把事件投遞到其他裝置，如 Web hooks 或 Kafka。

2.1.5 應用程式設計介面(API)

fabric的主要介面是 REST API，並通過 Swagger 2.0 來改變。API 允許註冊使用者，區塊鏈查詢和釋出交易。鏈碼與執行交易的堆間的互動和交易的結果查詢會由 API 集合來規範。

2.1.6 命令列介面(CLI)

CLI包含REST API的一個子集使得開發者能更快的測試鏈碼或查詢交易狀態。CLI 是通過 Go 語言來實現，並可在多種作業系統上操作。

2.2 拓撲

fabric 的一個部署是由成員服務，多個驗證 peers、非驗證 peers 和一個或多個應用所組成一個鏈。也可以有多個鏈，各個鏈具有不同的操作引數和安全要求。

2.2.1 單驗證Peer

功能上講，一個非驗證 peer 是驗證 peer 的子集；非驗證 peer 上的功能都可以在驗證 peer 上啟用，所以在最簡單的網路上只有一個驗證peer組成。這個配置通常使用在開發環境：單個驗證 peer 在編輯-編譯-調試周期中被啟動。

單個驗證 peer 不需要共識，預設情況下使用noops外掛來處理接收到的交易。這使得在開發中，開發人員能立即收到返回。

2.2.2 多驗證 Peer

生產或測試網路需要有多個驗證和非驗證 peers 組成。非驗證 peer 可以為驗證 peer 分擔像 API 請求處理或事件處理這樣的壓力。

網狀網路（每個驗證peer需要和其它驗證peer都相連）中的驗證 peer 來傳播資訊。一個非驗證 peer 連線到附近的，允許它連線的驗證 peer。當應用可能直接連線到驗證 peer 時，非驗證 peer 是可選的。

2.2.3 多鏈

驗證和非驗證 peer 的各個網路組成一個鏈。可以根據不同的需求建立不同的鏈，就像根據不同的目的建立不同的 Web 站點。

3. 協議

fabric的點對點（peer-to-peer）通訊是建立在允許雙向的基於流的訊息gRPC上的。它使用Protocol Buffers來序列化peer之間傳輸的資料結構。Protocol buffers是語言無關，平臺無關並具有可擴充套件機制來序列化結構化的資料的技術。資料結構，訊息和服務是使用proto3 language註釋來描述的。

3.1 訊息

訊息在節點之間通過Messageproto 結構封裝來傳遞的，可以分為 4 種類型：發現（Discovery）, 交易（Transaction）, 同步(Synchronization)和共識(Consensus)。每種型別在payload中定義了多種子型別。

messageMessage {

   enum Type {

        UNDEFINED = 0;

        DISC_HELLO = 1;

        DISC_DISCONNECT = 2;

        DISC_GET_PEERS = 3;

        DISC_PEERS = 4;

        DISC_NEWMSG = 5;

        CHAIN_STATUS = 6;

        CHAIN_TRANSACTION = 7;

        CHAIN_GET_TRANSACTIONS = 8;

        CHAIN_QUERY = 9;

        SYNC_GET_BLOCKS = 11;

        SYNC_BLOCKS = 12;

        SYNC_BLOCK_ADDED = 13;

        SYNC_STATE_GET_SNAPSHOT = 14;

        SYNC_STATE_SNAPSHOT = 15;

        SYNC_STATE_GET_DELTAS = 16;

        SYNC_STATE_DELTAS = 17;

        RESPONSE = 20;

        CONSENSUS = 21;

    }

    Type type = 1;

    bytes payload = 2;

    google.protobuf.Timestamp timestamp = 3;

}

payload是由不同的訊息型別所包含的不同的像Transaction或Response這樣的物件的不透明的位元組陣列。例如：type為CHAIN_TRANSACTION那麼payload就是一個Transaction物件。

3.1.1 發現訊息

在啟動時，如果CORE_PEER_DISCOVERY_ROOTNODE被指定，那麼 peer 就會執行發現協議。CORE_PEER_DISCOVERY_ROOTNODE是網路（任意peer）中扮演用來發現所有 peer 的起點角色的另一個 peer 的 IP 地址。協議序列以payload是一個包含：

messageHelloMessage {

  PeerEndpoint peerEndpoint = 1;

  uint64 blockNumber = 2;

}

messagePeerEndpoint {

    PeerID ID = 1;

    string address = 2;

    enum Type {

      UNDEFINED = 0;

      VALIDATOR = 1;

      NON_VALIDATOR = 2;

    }

    Type type = 3;

    bytes pkiID = 4;

}

messagePeerID {

    string name = 1;

}

這樣的端點的HelloMessage物件的DISC_HELLO訊息開始的。

域的定義:

• PeerID 是在啟動時或配置檔案中定義的 peer 的任意名字
• PeerEndpoint 描述了端點和它是驗證還是非驗證 peer
• pkiID 是 peer 的加密ID
• address 以ip:port這樣的格式表示的 peer 的主機名或IP和埠
• blockNumber 是 peer 的區塊鏈的當前的高度

如果收到的DISC_HELLO訊息的塊的高度比當前 peer 的塊的高度高，那麼它馬上初始化同步協議來追上當前的網路。

DISC_HELLO之後，peer 會週期性的傳送DISC_GET_PEERS來發現任意想要加入網路的 peer。收到DISC_GET_PEERS後，peer 會發送payload包含PeerEndpoint的陣列的DISC_PEERS作為響應。這是不會使用其它的發現訊息型別。

3.1.2 交易訊息

有三種不同的交易型別：部署（Deploy），呼叫（Invoke）和查詢（Query）。部署交易向鏈上安裝指定的鏈碼，呼叫和查詢交易會呼叫部署號的鏈碼。另一種需要考慮的型別是建立（Create）交易，其中部署好的鏈碼是可以在鏈上例項化並定址的。這種型別在寫這份文件時還沒有被實現。

3.1.2.1 交易的資料結構

CHAIN_TRANSACTION和CHAIN_QUERY型別的訊息會在payload帶有Transaction物件：

messageTransaction {

    enum Type {

        UNDEFINED = 0;

        CHAINCODE_DEPLOY = 1;

        CHAINCODE_INVOKE = 2;

        CHAINCODE_QUERY = 3;

        CHAINCODE_TERMINATE = 4;

    }

    Type type = 1;

    string uuid = 5;

    bytes chaincodeID = 2;

    bytes payloadHash = 3;

    ConfidentialityLevel confidentialityLevel =7;

    bytes nonce = 8;

    bytes cert = 9;

    bytes signature = 10;

    bytes metadata = 4;

    google.protobuf.Timestamp timestamp = 6;

}

messageTransactionPayload {

         bytes payload = 1;

}

enumConfidentialityLevel {

    PUBLIC = 0;

    CONFIDENTIAL = 1;

}

域的定義:

• type - 交易的型別, 為1時表示:
  • UNDEFINED - 為未來的使用所保留.
  • CHAINCODE_DEPLOY - 代表部署新的鏈碼.
    • CHAINCODE_INVOKE - 代表一個鏈碼函式被執行並修改了世界狀態
    • CHAINCODE_QUERY - 代表一個鏈碼函式被執行並可能只讀取了世界狀態
    • CHAINCODE_TERMINATE - 標記的鏈碼不可用，所以鏈碼中的函式將不能被呼叫
• chaincodeID - 鏈碼原始碼，路徑，建構函式和引數雜湊所得到的ID
• payloadHash - TransactionPayload.payload所定義的雜湊位元組.
• metadata - 應用可能使用的，由自己定義的任意交易相關的元資料
• uuid - 交易的唯一ID
• timestamp - peer 收到交易時的時間戳
• confidentialityLevel - 資料保密的級別。當前有兩個級別。未來可能會有多個級別。
• nonce - 為安全而使用
• cert - 交易者的證書
• signature - 交易者的簽名
• TransactionPayload.payload - 交易的payload所定義的位元組。由於payload可以很大，所以交易訊息只包含payload的雜湊

交易安全的詳細資訊可以在第四節找到

3.1.2.2 交易規範

一個交易通常會關聯鏈碼定義及其執行環境（像語言和安全上下文）的鏈碼規範。現在，有一個使用Go語言來編寫鏈碼的實現。將來可能會新增新的語言。

messageChaincodeSpec {

    enum Type {

        UNDEFINED = 0;

        GOLANG = 1;

        NODE = 2;

    }

    Type type = 1;

    ChaincodeID chaincodeID = 2;

    ChaincodeInput ctorMsg = 3;

    int32 timeout = 4;

    string secureContext = 5;

    ConfidentialityLevel confidentialityLevel =6;

    bytes metadata = 7;

}

messageChaincodeID {

    string path = 1;

    string name = 2;

}

messageChaincodeInput {

    string function = 1;

    repeated string args  = 2;

}

域的定義:

• chaincodeID - 鏈碼原始碼的路徑和名字
• ctorMsg - 呼叫的函式名及引數
• timeout - 執行交易所需的時間（以毫秒錶示）
• confidentialityLevel - 這個交易的保密級別
• secureContext - 交易者的安全上下文
• metadata - 應用想要傳遞下去的任何資料

當 peer 收到chaincodeSpec後以合適的交易訊息包裝它並廣播到網路

3.1.2.3 部署交易

部署交易的型別是CHAINCODE_DEPLOY，且它的payload包含ChaincodeDeploymentSpec物件。

messageChaincodeDeploymentSpec {

    ChaincodeSpec chaincodeSpec = 1;

    google.protobuf.Timestamp effectiveDate =2;

    bytes codePackage = 3;

}

域的定義:

• chaincodeSpec - 參看上面的3.1.2.2節.
• effectiveDate - 鏈碼準備好可被呼叫的時間
• codePackage - 鏈碼原始碼的gzip

當驗證 peer 部署鏈碼時，它通常會校驗codePackage的雜湊來保證交易被部署到網路後沒有被篡改。

3.1.2.4 呼叫交易

呼叫交易的型別是CHAINCODE_DEPLOY，且它的payload包含ChaincodeInvocationSpec物件。

messageChaincodeInvocationSpec {

    ChaincodeSpec chaincodeSpec = 1;

}

3.1.2.5 查詢交易

查詢交易除了訊息型別是CHAINCODE_QUERY其它和呼叫交易一樣

3.1.3 同步訊息

同步協議以3.1.1節描述的，當 peer 知道它自己的區塊落後於其它 peer 或和它們不一樣後所發起的。peer 廣播SYNC_GET_BLOCKS，SYNC_STATE_GET_SNAPSHOT或SYNC_STATE_GET_DELTAS並分別接收SYNC_BLOCKS,SYNC_STATE_SNAPSHOT或SYNC_STATE_DELTAS。

安裝的共識外掛（如：pbft）決定同步協議是如何被應用的。每個訊息是針對具體的狀態來設計的：

SYNC_GET_BLOCKS是一個SyncBlockRange物件，包含一個連續區塊的範圍的payload的請求。

messageSyncBlockRange {

    uint64 correlationId = 1;

    uint64 start = 2;

    uint64 end = 3;

}

接收peer使用包含SyncBlocks物件的payload的SYNC_BLOCKS資訊來響應

messageSyncBlocks {

    SyncBlockRange range = 1;

    repeated Block blocks = 2;

}

start和end標識包含的區塊的開始和結束，返回區塊的順序由start和end的值定義。如：當start=3，end=5時區塊的順序將會是3，4，5。當start=5，end=3時區塊的順序將會是5，4，3。

SYNC_STATE_GET_SNAPSHOT請求當前世界狀態的快照。payload是一個SyncStateSnapshotRequest物件

messageSyncStateSnapshotRequest {

  uint64 correlationId = 1;

}

correlationId是請求 peer 用來追蹤響應訊息的。接受 peer 回覆payload為SyncStateSnapshot例項的SYNC_STATE_SNAPSHOT資訊

messageSyncStateSnapshot {

    bytes delta = 1;

    uint64 sequence = 2;

    uint64 blockNumber = 3;

    SyncStateSnapshotRequest request = 4;

}

這條訊息包含快照或以0開始的快照流序列中的一塊。終止訊息是len(delta) == 0的塊

SYNC_STATE_GET_DELTAS請求連續區塊的狀態變化。預設情況下總賬維護500筆交易變化。 delta(j)是block(i)和block(j)之間的狀態轉變，其中i=j-1。payload包含SyncStateDeltasRequest例項

messageSyncStateDeltasRequest {

    SyncBlockRange range = 1;

}

接收 peer 使用包含SyncStateDeltas例項的payload的SYNC_STATE_DELTAS資訊來響應

messageSyncStateDeltas {

    SyncBlockRange range = 1;

    repeated bytes deltas = 2;

}

delta可能以順序（從i到j）或倒序（從j到i）來表示狀態轉變

3.1.4 共識訊息

共識處理交易，一個CONSENSUS訊息是由共識框架接收到CHAIN_TRANSACTION訊息時在內部初始化的。框架把CHAIN_TRANSACTION轉換為CONSENSUS然後以相同的payload廣播到驗證 peer。共識外掛接收這條訊息並根據內部演算法來處理。外掛可能建立自定義的子型別來管理共識有窮狀態機。3.4節會介紹詳細資訊。

3.2 總賬

總賬由兩個主要的部分組成，一個是區塊鏈，一個是世界狀態。區塊鏈是在總賬中的一系列連線好的用來記錄交易的區塊。世界狀態是一個用來儲存交易執行狀態的鍵-值(key-value)資料庫

3.2.1 區塊鏈

3.2.1.1 區塊

區塊鏈是由一個區塊連結串列定義的，每個區塊包含它在鏈中前一個區塊的雜湊。區塊包含的另外兩個重要資訊是它包含區塊執行所有交易後的交易列表和世界狀態的雜湊

messageBlock {

  version = 1;

  google.protobuf.Timestamp timestamp = 2;

  bytes transactionsHash = 3;

  bytes stateHash = 4;

  bytes previousBlockHash = 5;

  bytes consensusMetadata = 6;

  NonHashData nonHashData = 7;

}

messageBlockTransactions {

  repeated Transaction transactions = 1;

}

域的定義:

• version - 用來追蹤協議變化的版本號
• timestamp - 由區塊提議者填充的時間戳
• transactionsHash - 區塊中交易的merkle root hash
• stateHash - 世界狀態的merkle root hash
• previousBlockHash - 前一個區塊的hash
• consensusMetadata - 共識可能會引入的一些可選的元資料
• nonHashData - NonHashData訊息會在計算區塊的雜湊前設定為nil，但是在資料庫中儲存為區塊的一部分
• BlockTransactions.transactions - 交易訊息的陣列，由於交易的大小，它們不會被直接包含在區塊中

3.2.1.2 區塊雜湊

• previousBlockHash雜湊是通過下面演算法計算的
  1. 使用protocol buffer庫把區塊訊息序列化為位元組碼
  2. 使用描述的SHA3 SHAKE256演算法來對序列化後的區塊訊息計算大小為512位的雜湊值
• transactionHash是交易merkle樹的根。定義merkle tree實現是一個代辦
• stateHash在3.2.2.1節中定義.

3.2.1.3 非雜湊資料(NonHashData)

NonHashData訊息是用來儲存不需要所有 peer 都具有相同值的塊元資料。他們是建議值。

messageNonHashData {

  google.protobuf.TimestamplocalLedgerCommitTimestamp = 1;

  repeated TransactionResult transactionResults= 2;

}

messageTransactionResult {

相關推薦