Transaction Flow
本文件概述了在標準資產交換期間發生的交易機制。該方案包括兩個clientA和B，他們購買和銷售蘿卜。他們分別在網絡上有一個peer，通過peer發送他們的交易并與賬本交互。

假設
此流程假定通道已設置并運行。應用程序用戶registe并向組織的證書頒發機構（CA）enroll，并收回了必要的加密材料，用于向網絡進行身份驗證。

Chaincode（包含表示蘿卜市場初始狀態的一組鍵值對）被安裝在peer上并在channel上實例化。Chaincode包含了定義一組交易指令和商定的蘿卜價格的邏輯。Endorsement策略也被定為chaincode，指出peerA和對等體peerB必須支持任何交易。

Transaction Flow
Client A 初始化一個交易
Endorsing peers驗證簽名并執行交易
Proposal回應被檢查
Client將endorsement裝配到交易中
交易被驗證并提交
賬本更新
1. Client A 初始化一個交易

發生了什么？ - 客戶端A發送購買蘿卜的請求。請求目標peerA和peerB誰分別代表clientA和clientB。Endorsement策略規定兩個peer必須簽署任何交易，因此請求轉到peerA和peerB。

接下來，構建交易proposal。利用支持SDK（node，java，python）的應用程序使用可用的API之一來生成交易建議。該proposal是調用chaincode函數的請求，以便可以將數據讀取和/或寫入賬本（即為資產寫入新的鍵值對）。SDK用作中間件（shim），將交易proposal打包為適當的架構的格式（通過gRPC的協議緩沖區），并采用用戶的加密憑證為該交易建議生成唯一的簽名。

2. Endorsing peers驗證簽名并執行交易

Endorser驗證1）交易proposal正確的組織，2）交易在之前并沒有被提交(重訪攻擊保護)，3）簽名的合法性(使用MSP)，4）提交者（示例中的客戶端A）被正確地授權在該channel上執行建議的操作（即，每個endorser確保提交者滿足channel的Writer策略）。Endorser將交易proposal作為輸入invoked的chaincode的函數的參數，并針對當前狀態數據庫執行它們以產生包括響應值，讀集和寫集的交易結果。此時不會更新賬本。這些值的集合，以及支持peer的簽名和YES / NO認可語句作為“建議響應”傳遞回SDK，該SDK解析用于應用消費的有效載荷。

{MSP是在peer上運行的本地進程，它允許它們驗證從客戶端到達的交易請求并簽署交易結果（endorsement）。ACL（訪問控制列表）在信道創建時定義，并確定允許哪些對等端和最終用戶執行某些操作。}

3. Proposal回應被檢查

應用程序驗證endorser簽名并且比較proposal的響應（鏈接到包含有效載荷的表示的詞匯表術語）以確定proposal響應是否相同以及是否已經滿足指定的endorsement策略（即，是否peerA和peerB兩者都endorse）。該架構使得即使應用程序選擇不檢查響應或以其它方式轉發未endorsed的交易，該策略仍然將由peer實施并且在提交驗證階段被維護。

4. Client將endorsement裝配到交易中

應用程序將“交易消息”中的交易proposal和響應“廣播”到排序服務。交易將包含讀/寫集合，被承認的peer簽名和channel ID。Ordering服務不會讀取交易詳細信息，它只是從網絡中的所有渠道接收交易，根據channel安時間順序對其進行排序，并為每個渠道創建交易塊。

5. 交易被驗證并提交

交易塊被“傳遞”到信道上的所有peer。塊內的交易被驗證以確保endorsement策略被滿足并且確保賬本的read集變量狀態沒有改變，因為read集是由交易執行生成的。塊中的交易標記為有效或無效。

6. 賬本更新
每個peer將塊附加到channel的鏈，并且對于每個有效交易，write集被提交到當前狀態數據庫。發出事件以通知客戶端應用程序交易（調用）已被不可變地附加到鏈，以及通知交易是否被驗證或無效。

總結

以上是生活随笔為你收集整理的Hyperledger Fabric 交易流程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。