斜槓工程師的問題筆記

Hyperledger Fabric 筆記(六)

Hyperledger Fabric 的智能合約打包

本系列文章是以 Blockchain with Hyperledger Fabric, Second Edition 書中的內容為基礎,配合一些實務上遇到的問題所做的筆記。

智能合約打包(Smart contract packaging)

我們現在知道如何使用私有數據,驗證型交易,插入型交易,或是傳輸型交易等。但還有一些需要注意的陷阱。 總結來說,智能合約打包的目標在於達成以下效果:

  • 使用不同的背書政策對應同一份合約。
  • 確保組織只能見到他該看到的合約內容。
  • 將不必要的程式碼最小化。

在 Hyperledger Fabric 2 中,智能合約與背書政策通常為一對一關係,但通過合約定義(definition),我們可以實現更多元的包裝方式。以下將介紹兩種主要的包裝策略:多重定義包裝和功能型包裝。

多重定義包裝(Multi-definition packages)

Multi-definition packages 在上表中,可以看到合約被兩個不同的定義(vehicleContracts1 與 vehicleContracts2)指向。即使兩個定義使用相同的合約,但產生的交易是完全不同的。即使交易內容以及使用的合約都相同,他們也會存在不同的命名空間,且擁有不同的背書政策。多重定義包裝可以允許我們使用同一份合約但不用重新命名。

功能型包裝(Functional packaging)

同樣的,不同的合約包裝也可以使用同一份定義。如下圖。 Functional packaging 我們可以看到 package1 擁有一個在 car 合約、boat 合約以及 truck 合約的特定的交易集合 subsetA。package2也有一個 subsetB。我們稱此為功能型包裝,因為不同的package可以從交易池中選擇並生成完全不同的交易。讓package 包含完全不同的業務函式。 Functional packaging 上圖是之前出現過的銀行內部安全網路架構合約範例。我們可以看到合約不是一個單純的class,而是有層級關係。 Functional packaging 我們將 verifyTrade 以及 insertTrade 放進 TradeConsumer 這個 Fabric 提供的 Contract Class 的 subClass 中,而將其他的交易createTrade 以及 readTrade 放進其衍生的 TradeProvider class中。

網路中的參與者彼此之間的關係被反映在這樣的層次結構中,TradeProviders 可以執行 TradeConsumers 可以執行的所有功能,然後將不同的交易分別放入TradeConsumer 和 TradeProvider 包中進行分發。 我們也可以使用不同的方式去規劃。 Functional packaging 在上圖中,左邊是有層級關係的合約包結構,右邊的TradeProvider 以及 TradeConsumer 則沒有任何重疊。一切都可以根據組織彼此之間的關係去配合。

但在我們目前的銀行網路中,這樣的包裝形式並不是很理想:

  • 合約可能包含商業機密信息。例如,當insertTrade僅僅是請求進行交易時,createTrade將有權訪問是否進行交易的規則。我們可能希望限制後者交易邏輯的分發。
  • 如果我們將智能合約邏輯分發給許多不同的參與者,則我們就會給他們訪問可能被惡意利用的代碼的機會。當然,即使在不法份子可以訪問代碼的情況下我們的系統也應該是安全的,但是從一開始就限制其分發可以減少攻擊面。
  • 在設計智能合約時,可以將不同的角色分配到不同的智能合約中,這樣會讓整個系統更容易理解和診斷,因為可以將不同角色的責任區分開來。這也有助於減少攻擊面。

圖7-3中的繼承和包裝設計是用來將功能鎖定到某些類型的參與者,根據他們的關係。比如說,TradeConsumer 的交易更一般且權限較少,而 TradeProvider 的交易更具體且權限較多。這樣的設計意圖是讓 TradeConsumer 的交易能夠廣泛地使用在網絡中,同時將 TradeProvider 的交易保留給提供服務的組織使用。

最終,使用 TradeConsumer 的組織應用程式必須要能夠與另一個使用 TradeProvider 的組織起作用。我們不能在沒有考慮使用情境的情況下任意將功能放入package中。

接下來,我們將所有的東西一起結合在車輛網路中。 Functional packaging 在上圖中,我們可以看到不同的組織如何根據他們可用的智能合約提供和使用不同的服務。例如,只有警察可以生成警察信息交易或車輛登記可以生成車主交易。這五個組織中的每一個都是交易信息的服務提供商,他們對這些信息擁有主權。

相反的,需注意誰能消費交易信息。在我們的網路中,警察和保險公司都能驗證車輛信息、警察信息和製造信息。但製造商沒有這些交易的訪問權。他們沒有形成哈希或其他交易的智能合約交易,因此無法與這些組織進行交易。

我們可以看到謹慎的智能合約封裝如何使車輛網絡更加智能、私密和安全。我們還看到了智能合約包(鏈碼)及其定義如何允許網絡就生成哪些交易及其各自的背書政策達成一致。智能合約繼承的精心設計允許組織網絡根據不同的網絡參與者的需要向他們提供精確的功能。

從上面的幾個例子可以明白,如果一個網路使用多重定義包裝的合約,那他就是同一份程式碼生成不同的交易,這對於程式碼的重複使用是很有幫助的。而如果使用功能型包裝的,則是同一份定義下生成不同的交易,這有助於限制不必要的和有時不需要的程式碼分發,有效地限制特定組織可以生成的交易。

All rights reserved.