天天看點

Hyperledger Fabric 2.4 Fabric Gateway文檔翻譯寫用戶端應用用戶端應用API gateway怎麼背書(簽署)交易提案

翻譯:原文位址

Fabric Gateway是Hyperledger Fabric v2.4 在peers上增加的一項服務,為向網絡送出事務提供簡單的小型的API。之前用戶端SDK的需求,比如從不同組織的peers中收集交易背書,在v2.4中通過使用Fabric Gateway服務,隻需要一個peer運作一個應用程序即可送出事務。

寫用戶端應用

使用Fabric2.4,寫用戶端應用可以用到 Fabric Gateway 的一些API,而且流程經過了優化。這些API如同v1.4版本時介紹的高水準程式設計模型。

Fabric Gateway 管理如下事務步驟:

  • 評估交易提案。這将在一個peer上調用職能合約并傳回結果給用戶端。這個操作通常用于查詢目前賬本的狀态而不是用于賬本更新。gateway優先選擇同一個組織的peer作為the gateway peer ,且選擇的是賬本中區塊最高的peer。如果gateway的組織内沒有合适的peer,此時會從其他組織中選擇peer。
  • 背書(簽署)交易提案。gateway會收集足夠的背書來滿足聯合簽名政策,将準備好的交易envelope傳回給用戶端,讓其進行簽名。
  • 送出交易。送出交易事務到order服務上,送出到賬本中。
  • 等待送出狀态事件。讓用戶端可以等待交易送出到賬本後的結果,擷取交易狀态碼
  • 接收鍊碼事件。這會允許用戶端應用根據鍊碼執行後傳回的資料進行響應。

Fabric Gateway 用戶端的 API組合Endorse/Submit/CommitStatus 動作到一個 SubmitTransaction函數,來做到一行代碼實作交易事件。或者,可以使用單個操作來支援靈活的應用程式模式。

用戶端應用API

Fabric Gateway及其API設計的目的是,讓用戶端應用開發者能夠專注于業務邏輯,而不必關系Fabric的基礎架構邏輯。是以,API提供了組織和合約的邏輯抽象,而不是對操作抽象也不是對鍊碼和peer的抽象。【旁注——很明顯,管理API希望公開這些操作抽象,而不是管理API】

Fabric目前支援以下三種用戶端應用程式設計語言:

  • Go 檢視GO API
  • Node,檢視Node API
  • Java,檢視 Java API

 gateway怎麼背書(簽署)交易提案

為了交易事務成功送出到賬本中,需要滿足背書政策要求的背書數量。擷取一個組織的背書需要聯系組織中的一個peer,并讓它在自己複制的賬本上模拟執行。peer通過調用鍊碼來模拟執行交易事務,以交易的名稱和參數做标記,建立一個讀寫集合。這個讀寫集包含了目前賬本狀态和執行交易後的狀态。

應用于事務的背書政策或多個政策之和取決于正在調用的鍊碼函數的實作,可以使以下各項的組合:

  • 鍊碼背書政策。channel的組織成員在準許鍊碼時同意的政策。如果鍊碼函數調用了另一個鍊碼,則兩方政策都需要滿足。
  • 私有資料集合背書政策。如果鍊碼向私有資料中寫入一個狀态,則該集合的認可政策将覆寫該狀态的鍊碼政策。
  • 如果鍊碼函數從私有資料集合中讀取資料,則它将僅限于該集合成員的組織。
  • 基于狀态的背書政策(SBE)。這些政策也被稱為密鑰級簽名政策,可應用于單獨的狀态,并将覆寫鍊碼政策或者私有資料集合的政策。背書政策存貯在賬本上,可以通過交易事務更新。

應用于交易事務的背書政策組合是在鍊碼運作是确定的,不一定是從靜态分析得出的。gateway使用以下過程代表用戶端管理交易背書的複雜性:

  • gateway從組織中選擇peer做背書,選擇的是最高塊高度的peer。假設在gateway peer組織内的peer都是被聯系它的用戶端所信任的。
  • 在標明的peer上模拟交易提案。該模拟擷取有關通路狀态的資訊,是以,需要将背書政策結合起來(包括peer上任何獨立地基于狀态的背書政策)。
  • 捕獲的背書政策被組裝入

    ChaincodeInterest

     協定結構,并将其傳遞給發現服務,以得出特定于交易事務的背書計劃。
  • gateway通過請求滿足計劃中所有政策所需來準許應用準許計劃。對于每個組織,gateway peer會選取組織中區塊最高的peer

gateway是依靠discovery service 來擷取需要聯系的peer和order的資訊,并計算交易事務需要背書所需哪些peer。是以在gateway服務開啟的peer上,discovery service也要開啟。

gateway背書程序對私密資料有嚴格的限制,資料會以臨時資料的方式在組織中傳遞,因為私密資料往往是敏感和個人資料,不能在全部組織中傳遞。對于這種情況,gateway需要限制背書組織為私密資料集合的成員(或讀或寫)。如果限制沒有滿足背書政策,gateway會傳回error到用戶端,而不是繼續将私密資料在組織間傳遞,因為這可能會被私密資料拒絕通路。這種情況下用戶端應用需要寫清楚 explicitly define which organizations should endorse。

指明背書peer

在某些情況下,一個用戶端應用必須明确指定需要哪些組織來審議和背書交易提案。例如,臨時資料經常包含個人或敏感資訊隻能寫入到私密資料集合,是以需要限制背書組織集合。這些情況下,用戶端應用指明背書組織,以滿足隐私和背書需求;gateway需要從指定的背書組織中選取區塊最高的peer。但是,如果用戶端指明的背書組織沒有滿足背書政策,交易依然會擷取指明的peer的背書,并送出到order,但在驗證和送出階段,所有peer會使交易無效。這次無效會記錄在賬本上,但交易不會寫入到狀态任何peer的狀态資料庫中。

重試和錯誤處理

gateway處理節點有重試連接配接,錯誤和延時處理。

重試

gateway會使用discovery service的資訊來重試連接配接不可以用peer和node。如果一個組織運作了多個peer或order節點,那另一個合格的節點會被嘗試連接配接。如果一個組織背書交易時失敗,那另一個組織會被嘗試。如果一個組織一緻背書失敗,一組滿足條件的組織會成為新的目标。隻有沒有了滿足背書政策的peer可用,gateway才會停止嘗試。gateway會一緻嘗試,直到所有可能的背書peer都被試過。

錯誤處理

Fabric gateway通過gRPC聯系網絡中的peer和order。如果gateway請求錯誤源于peer和order的網絡(也就是gateway外部),gateway會傳回錯誤,端口,群組織ID資訊給用戶端在details字段中。如果details字段為空,那錯誤來自原gateway peer。

逾時

Fabric gateway的評估和背書方法向外部的gateway發送gRPC請求。為了限制用戶端需要等待響應的時間,core.yaml中的peer.gateway.endorsementTimeout可以再gateway中重置。

Fabric gateway用戶端api也提供了預設設定和單次調用逾時設定的機制。

接收事件

gateway 提供了簡單的接受chaincode events的API。用戶端API提供了一種機制,可以使用特定于語言的習慣用法來處理這些事件。