核心概念 - 智能合約和鏈碼
從應用程序開發人員的角度來看，智能合約與帳本一起構成了 Hyperledger Fabric 區塊鏈系統的核心。賬本保存有關一組業務對象的當前和歷史狀態的事實，而智能合約定義可執行邏輯，生成添加到賬本的新事實。管理員通常使用鏈碼對相關的智能合約進行分組以進行部署，但也可以將其用于 Fabric 的低級系統編程。在本主題中，我們將重點介紹為什么存在智能合約和鏈碼以及如何以及何時使用它們。
在本主題中，我們將介紹：
- 什么是智能合約
- 術語說明
- 智能合約和帳三個
- 如何開發智能合約
- 背書策略的重要性
- 有效交易
- 智能合約和通道
- 智能合約之間的通信
- 什么是系統鏈碼？
1. 智能合約
在業務彼此之間進行交易之前，他們必須定義一組通用合約，涵蓋通用條款，數據，規則，概念定義和流程。這些合約放在一起，構成了控制交易雙方之間所有交互的業務模型。
智能合約以可執行代碼定義了不同組織之間的規則。應用程序調用智能合約以生成記錄在賬本上的交易。
使用區塊鏈網絡，我們可以將這些合約轉換為可執行程序 (在業界稱為智能合約)，以開辟各種新的可能性。這是因為智能合約可以為任何類型的業務對象實施治理規則，以便在執行智能合約時可以自動執行這些規則。例如，智能合約可以確保在指定的時間范圍內完成新車交付，或者確保按照預先安排的條款釋放資金，從而分別改善了貨物或資金的流動。但是，最重要的是，智能合約的執行比人工業務流程要高效得多。
在上圖中，我們可以看到 ORG1 和 ORG2 這兩個組織如何定義了汽車智能合約來查詢，轉讓和更新汽車。這些組織的應用程序調用此智能合約在業務流程中執行約定的步驟，例如將特定汽車的所有權從 ORG1 轉移到 ORG2。
2. 術語
Hyperledger Fabric 用戶經?；Q使用術語智能合約和鏈碼。通常，智能合約定義了控制世界狀態中包含的業務對象生命周期的交易邏輯。然后將其打包成鏈碼，然后將其部署到區塊鏈網絡?？梢詫⒅悄芎霞s視為管理交易，而鏈碼則可以控制如何打包智能合約以進行部署。
智能合約在鏈碼中定義?？梢栽谕绘湸a中定義多個智能合約。部署鏈碼后，其中的所有智能合約都可用于應用程序。
在上圖中，我們可以看到一個包含三個智能合約的車輛 (vehicle) 鏈碼：汽車 (cars)，船只 (boats) 和卡車 (trucks)。我們還可以看到包含四個智能合約的保險 (insurance) 鏈碼：保單 (policy)，責任 (liablility)，銀團 (syndication) 和證券化 (securitization)。在這兩種情況下，這些合同均涉及與車輛和保險有關的業務流程的關鍵方面。在本主題中，我們將以汽車 (car) 合約為例。我們可以看到，智能合約是與特定業務流程相關的特定于域的程序，而鏈碼是一組用于安裝和實例化的相關智能合約的技術容器。
3. 賬本
在最簡單的層次上，區塊鏈一成不變地記錄更新賬本中狀態的交易。智能合約以編程方式訪問賬本的兩個不同部分：一個區塊鏈，它不變地記錄所有交易的歷史記錄；一個世界狀態，保存著這些狀態的當前值緩存，因為它是對象通常需要的當前值。
智能合約主要在世界狀態下放置 (put)，獲取 (get) 和刪除 (delete) 狀態，并且還可以查詢不可變的區塊鏈交易記錄。
- 獲取 (get) 通常代表查詢以檢索有關業務對象當前狀態的信息。
- 放置 (put) 通常會創建新的業務對象或修改帳本世界狀態中的現有業務對象。
- 刪除 (delete) 通常表示從帳本的當前狀態中刪除業務對象，但不刪除其歷史記錄。
智能合約有許多可用的 API。至關重要的是，在所有情況下，無論交易是在世界狀態下創建，讀取，更新還是刪除業務對象，區塊鏈都包含這些更改的 不可變記錄。
4. 開發
智能合約是應用程序開發的重點，正如我們已經看到的，可以在單個鏈碼中定義一個或多個智能合約。將鏈碼部署到網絡后，該網絡中的所有組織均可使用其所有智能合約。這意味著只有管理員才需要擔心鏈碼。其他人都可以根據智能合約進行思考。
智能合約的核心是一組交易定義。例如，查看 fabcar.js，你可以在其中看到創建新車的智能合約交易：
async createCar(ctx, carNumber, make, model, color, owner) {
const car = {
color,
docType: 'car',
make,
model,
owner,
};
await ctx.stub.putState(carNumber, Buffer.from(JSON.stringify(car)));
}
你可以在 編寫第一個應用程序教程 中了解有關 Fabcar 智能合約的更多信息。
智能合約可以描述與多組織決策中的數據不變性相關的幾乎無限的業務用例。智能合約開發人員的工作是采用可能控制金融價格或交付條件的現有業務流程，并以諸如 JavaScript，GOLANG 或 Java 的編程語言將其表示為智能合約。智能合約審核員越來越多地練習將數百年的法律語言轉換為編程語言所需的法律和技術技能。你可以在 開發應用程序主題 中了解如何設計和開發智能合約。
5. 背書
與每個鏈碼相關聯的是一種背書策略，該策略適用于其中定義的所有智能合約。背書非常重要；它指示區塊鏈網絡中的哪些組織必須簽署由給定智能合約生成的交易，才能將該交易宣布為有效。
每個智能合約都有與其相關的背書策略。該背書策略可確定哪些組織必須批準智能合約生成的交易，然后才能將其確認為有效交易。
示例性背書策略可能定義了參與區塊鏈網絡的四個組織中的三個必須在一筆交易被視為有效之前對其進行簽名。所有有效或無效交易都將添加到分布式帳本中，但只有有效交易會更新世界狀態。
如果背書策略指定必須由多個組織簽署交易，則必須由足夠多的組織來執行智能合約，以便生成有效的交易。在上面的示例中，轉讓汽車的智能合約交易需要由 ORG1 和 ORG2 執行并簽名，以使其有效。
背書策略使 Hyperledger Fabric 與以太坊或比特幣等其他區塊鏈有所不同。在這些系統中，網絡中的任何節點都可以生成有效的交易。Hyperledger Fabric 更現實地模擬了現實世界；交易必須由網絡中的受信任組織驗證。例如，管理組織必須簽署有效的 issueIdentity 交易，或者汽車的買 (buyer) 賣 (seller) 雙方都必須簽署汽車 (car) 轉讓交易。背書策略旨在使 Hyperledger Fabric 能夠更好地對這些類型的實際交互進行建模。
最后，背書策略只是 Hyperledger Fabric 中策略的一個示例。可以定義其他策略以標識誰可以查詢或更新帳本，或從網絡中添加或刪除參與者。一般而言，盡管不是一成不變的，但策略應由區塊鏈網絡中的聯盟組織事先達成協議。實際上，策略本身可以定義可以更改策略的規則。盡管是高級主題，但也可以在 Fabric 提供的規則之外定義 自定義背書策略 規則。
6. 有效交易
當智能合約執行時，它在區塊鏈網絡中的一個組織擁有的對端節點上運行。合約采用一組稱為交易提案的輸入參數，并將其與程序邏輯結合使用以讀取和寫入帳本。對世界狀態的更改被捕獲為交易提案響應 (或僅僅是交易響應)，其中包含一個讀寫集 (read-write set)，其中包含已讀取的狀態以及如果交易有效將要寫入的新狀態。請注意，執行智能合約時世界狀態不會更新！
[圖片上傳失敗...(image-4ff111-1575546689004)]
所有交易都具有由一組組織簽名的標識符，提案和響應。所有交易均記錄在區塊鏈上，無論其有效與否，但只有有效交易才能更新世界狀態。
檢查 car transfer 交易。你可以看到在 ORG1 和 ORG2 之間進行汽車轉移的交易 t3。查看交易如何輸入 {CAR1，ORG1，ORG2} 并輸出 {CAR1.owner = ORG1，CAR1.owner = ORG2}，表示所有者從 ORG1 變為 ORG2。請注意，輸入是由應用程序的組織 ORG1 簽名的，輸出是由背書策略 ORG1 和 ORG2 標識的兩個組織簽名的。這些簽名是通過使用每個參與者的私鑰生成的，意味著網絡中的任何人都可以驗證網絡中的所有參與者是否都同意交易細節。
分兩個階段驗證分發給網絡中所有對端節點的交易。首先，檢查交易，以確保有足夠的組織根據背書策略簽署了該交易。其次，檢查以確保世界狀態的當前值與由對端節點簽名的交易的讀取集相匹配；沒有中間更新。如果交易通過了這兩個測試，則將其標記為有效。所有交易都會添加到區塊鏈歷史記錄中，無論有效與否，但只有有效交易才會導致世界狀態的更新。
在我們的示例中，t3 是有效交易，因此 CAR1 的所有者已更新為 ORG2。但是，t4 (未顯示) 是無效交易，因此，盡管將其記錄在帳本中，但世界狀態并未更新，CAR2 仍歸 ORG2 所有。
最后，要了解如何在世界狀態下使用智能合約或鏈碼，請閱讀 鏈碼命名空間主題。
7. 通道
Hyperledger Fabric 允許組織通過通道同時參與多個獨立的區塊鏈網絡。通過加入多個通道，組織可以參與所謂網絡的網絡。通道可有效共享基礎架構，同時保持數據和通信的隱私。它們足夠獨立，可以幫助組織與不同的交易對手分離其工作量，但又足夠集成，可以在必要時協調獨立的活動。
通道在一組組織之間提供了完全獨立的通信機制。在通道上實例化鏈碼時，將為其定義背書策略。鏈碼中的所有智能合約均可供該通道上的應用程序使用。
管理員在通道上實例化鏈碼時為其定義了背書策略，并且可以在鏈碼升級時對其進行更改。背書策略同樣適用于在部署到通道的同一鏈碼中定義的所有智能合約。這也意味著可以將單個智能合約部署到具有不同背書策略的不同通道。
在上面的示例中，汽車合約已部署到 VEHICLE 通道，保險合約已部署到 INSURANCE 通道。汽車合約的背書策略要求 ORG1 和 ORG2 在被視為有效之前簽署交易，而保險合約的背書策略僅要求 ORG3 簽署有效交易。 ORG1 參與兩個網絡，即 VEHICLE 通道和 INSURANCE 網絡，并且可以分別通過 ORG2 和 ORG3 協調這兩個網絡之間的活動。
8. 互通
智能合約可以在同一通道內和不同通道之間調用其他智能合約。這樣，他們可以讀取和寫入由于智能合約命名空間而無法訪問的世界狀態數據。
合約間通信存在局限性，在 鏈碼命名空間 主題中已對此進行了全面介紹。
9. 系統鏈碼
鏈碼中定義的智能合約對一組區塊鏈組織之間達成共識的業務流程的域相關規則進行編碼。但是，鏈碼還可以定義與領域無關的系統交互相對應的低級程序代碼，而這些交互與業務流程的智能合約無關。
以下是不同類型的系統鏈碼及其相關的縮寫：
- 生命周期系統鏈碼 (Lifecycle system chaincode, LSCC) 在所有對端節點中運行，以處理程序包簽名，安裝，實例化和升級鏈碼請求。你可以閱讀有關 LSCC 實現此 過程 的更多信息。
- 配置系統鏈碼 (Configuration system chaincode, CSCC) 在所有對端節點中運行，以處理對通道配置的更改，例如策略更新。你可以在以下鏈碼 主題 中閱讀有關此過程的更多信息。
- 查詢系統鏈碼 (Query system chaincode, QSCC) 在所有對端節點運行提供賬本的 API，其中包括區塊查詢，交易查詢等，你可以在交易方面的 話題 了解更多有關這些帳本 API。
- 背書系統鏈碼 (Endorsement system chaincode, ESCC) 在背書對端節點以加密方式簽署交易響應時運行。你可以閱讀有關 ESCC 如何實施此 過程 的更多信息。
- 驗證系統鏈碼 (Validation system chaincode, VSCC) 驗證交易，包括檢查背書策略和讀寫集版本控制。你可以閱讀有關 LSCC 實現此 過程 的更多信息。
底層 Fabric 開發人員和管理員可以修改這些系統鏈碼以供自己使用。但是，系統鏈碼的開發和管理是一項專門的活動，與智能合約的開發完全分開，通常不需要。對系統鏈碼的更改必須格外小心，因為它們對于 Hyperledger Fabric 網絡的正常運行至關重要。例如，如果未正確開發系統鏈碼，則一個對端節點可能會與另一對端節點不同地更新其世界狀態或區塊鏈的副本。缺乏共識是賬本分叉的一種形式，這是非常不理想的情況。
Reference
- Docs ? Key Concepts ? Smart Contracts and Chaincode, https://hyperledger-fabric.readthedocs.io/en/release-1.4/smartcontract/smartcontract.html
- Docs ? Developing Applications ? Application design elements ? Transaction context, https://hyperledger-fabric.readthedocs.io/en/release-1.4/developapps/transactioncontext.html#structure
- Docs ? Key Concepts ? Ledger, https://hyperledger-fabric.readthedocs.io/en/release-1.4/ledger/ledger.html
- Docs ? Tutorials ? Writing Your First Application, https://hyperledger-fabric.readthedocs.io/en/release-1.4/write_first_app.html
- Docs ? Developing Applications, https://hyperledger-fabric.readthedocs.io/en/release-1.4/developapps/developing_applications.html
- Docs ? Operations Guides ? Pluggable transaction endorsement and validation, https://hyperledger-fabric.readthedocs.io/en/release-1.4/pluggable_endorsement_and_validation.html
- Docs ? Developing Applications ? Application design elements ? Chaincode namespace, https://hyperledger-fabric.readthedocs.io/en/release-1.4/developapps/chaincodenamespace.html
- Docs ? Developing Applications ? Application design elements ? Chaincode namespace, https://hyperledger-fabric.readthedocs.io/en/release-1.4/developapps/chaincodenamespace.html#cross-chaincode-access
項目源代碼
項目源代碼會逐步上傳到 Github，地址為 https://github.com/windstamp。
Contributor
- Windstamp, https://github.com/windstamp
