交易背書 - fabric交易并發的基礎

Hyperledger Fabric和其他許多區塊鍊的關鍵差別之一，就在于Fabric區塊鍊的交易執行過程：Fabric交易需要首先通過節點的背書，然後再進行交易排序，最後才利用有序交易進行賬本的更新。本文将介紹Hyperledger Fabric所采用的執行-排序-驗證這一三步交易模型的工作原理，以及引入背書環節對Hyperledger Fabric區塊鍊性能的有益作用。

Hyperledger Fabric相關開發教程：

• Java鍊碼與應用開發詳解
• Node.js鍊碼與應用開發詳解

1、交易的生命周期：Hyperledger Fabric vs. 其他區塊鍊

在其他區塊鍊平台中，交易生命周期基本由如下環節構成：

• 排序：交易有序加入賬本，然後擴散到所有節點
• 執行：交易在所有節點上按順序依次執行并更新賬本

為了讓所有節點保持一緻的狀态，交易必須确定性執行，也就是說，無論何時何地，同樣的交易必須産生同樣的結果。這一要求對智能合約形成了很強的限制，也是智能合約通常需要使用領域特定語言（DSL）來開發的原因之一，是以使用像Java或Go這樣的通用開發語言基本上無法保證确定性。

在Hyperledger Fabric中，交易的聲明周期則有所不同：

• 執行：交易（通過智能合約）以任意順序執行，甚至可以并行執行
• 排序：當足夠數量的節點對交易結果達成一緻，該交易就會 被加入賬本并擴散給所有節點。
• 驗證：每個節點驗證并按順序執行交易，進而更新賬本

首先需要注意的一點是，交易的執行和對賬本的實際更新被拆分為兩個環節，這一拆分帶來一些有益的作用：

• 所有節點都需要更新賬本，是以所有節點都需要執行驗證步驟。 但并不是所有的節點都需要執行智能合約。Hyperledger Fabric 使用背書政策來定義哪些節點需要執行交易。這意味着指定的 鍊碼（智能合約）不必開放給所有的節點 —— 那些不在背書政策中 的節點不需要由通路鍊碼的權限。
• 交易可以在被排序之前先執行。這是的節點可以并行執行交易， 進而提高系統的吞吐量

• 在Fabric的三步交易模型中，在交易被添加到賬本之前，其鍊碼 執行結果是顯式達成一緻的，其他區塊鍊的兩步交易模型使用 确定性的鍊碼，本身就隐含了節點之間就智能合約的執行結果 達成一緻。顯式達成一緻可以讓Fabric使用非确定性的鍊碼，

  這也是為什麼我們可以使用Go、Java和Node.js編寫Fabric鍊碼 的原因。

2、Hyperledger Fabric的交易背書政策

Hyperledger Fabric允許使用者自己定義鍊碼執行的政策。這些背書政策定義了在交易被加入賬本之前，哪些節點需要就交易結果達成一緻。Fabric提供了一個小型的DSL來定義背書政策。下面展示了一些背書政策樣例：

• 節點A、B、C和F都需要對類型為T的交易進行背書
• 通道中的大部分節點必須對類型為U的交易進行背書
• A、B、C、D、E、F、G中的至少3個節點必須對類型為V的交易進行背書

背書政策并不保證正确的鍊碼安裝在正确的節點上。然而，背書和安裝鍊碼的确存在類似的機制，我們将在後續教程中介紹這一點。

3、Hypereledger Fabric交易背書的實作機制

到目前為止，我們都是松散地使用交易（transaction）這一術語。在排序-執行模型中，鍊碼執行和賬本更新被合二為一 —— 交易。在Fabric中，這兩個概念是分開的，是以交易本身也被拆分。

Fabric從交易提議（Transaction Proposal）開始。這是一個用來觸發鍊碼執行的資料包。交易提議被發送給用于背書的節點。背書節點執行鍊碼，如果成功的話就生成一個實際的賬本交易。背書節點簽名建議并傳回交易提議的響應，這是執行-排序-驗證模型中的執行步驟。

一旦交易提議的建立者收到足夠的可以滿足背書政策的簽名，它就可以将交易（以及簽名）送出以便添加到賬本中，這就是排序步驟。

4、結論

Hyperledger Fabric在區塊鍊交易方面采取了一個新穎的思路，将智能合約的執行與賬本的更新分開使它可以提高交易吞吐量，支援更細粒度的隐私控制，實作更靈活強大的智能合約。而這些特性得以實作的一個關鍵因素就是在交易加入賬本之前進行顯式地交易背書。

原文連結：

Hyperledger Fabric交易背書的深入了解 - 彙智網