智能合約與鏈碼
從應用程序開發人員的角度來看，智能合約與賬本一起構成了 Hyperledger Fabric 區塊鏈系統的核心。賬本包含了與一組業務對象的當前和歷史狀態有關的事實，而智能合約定義了生成這些被添加到賬本中的新事實的可執行邏輯。管理員通常使用鏈碼將相關的智能合約組織起來進行部署，但鏈碼也可以用於Fabric的低級系統編程。在本主題中，我們將重點討論爲什麼智能合約和鏈碼都存在，以及如何和何時使用它們。
在本主題中，我們將討論：
智能合約
在各業務彼此進行交互之前，必須先定義一套通用的合約，其中包括通用術語、數據、規則、概念定義和流程。將這些合約放在一起，就構成了管理交易各方之間所有交互的業務模型。
智能合約用可執行的代碼定義了不同組織之間的規則。應用程序調用智能合約來生成被記錄到賬本上的交易。
使用區塊鏈網絡，我們可以將這些合約轉換爲可執行程序（業內稱爲智能合約），從而實現了各種各樣的新可能性。這是因爲智能合約可以爲任何類型的業務對象實現治理規則，以便在執行智能合約時自動執行這些規則。例如，一個智能合約可能會確保新車在指定的時間內交付，或者根據預先安排的條款釋放資金，前者可改善貨物流通，而後者可優化資本流動。然而最重要的是，智能合約的執行要比人工業務流程高效得多。
在上面的圖中，我們可以看到組織ORG1 和 ORG2是如何定義了一個 car 智能合約來query、transfer和update汽車的。來自這些組織的應用程序調用此智能合約以執行業務流程中已商定的步驟，例如將特定汽車的所有權從 ORG1 轉移到 ORG2。
術語
Hyperledger Fabric 用戶經常交替使用智能合約和鏈碼。通常，智能合約定義的是控制世界狀態中業務對象生命週期的交易邏輯，隨後該交易邏輯被打包進鏈碼，緊接着鏈碼會被部署到區塊鏈網絡中。可以將智能合約看成交易的管理者，而鏈碼則管理着如何將智能合約打包用於部署。
一個智能合約定義在一個鏈碼中。而多個智能合約也可以定義在同一個鏈碼中。當一個鏈碼部署完畢，該鏈碼中的所有智能合約都可供應用程序使用。
從上圖中我們可以看到，vehicle 鏈碼包含了以下三個智能合約：cars、boats和 trucks；而 insurance 鏈碼包含了以下四個智能合約：policy、liability、syndication和securitization。以上每種智能合約都涵蓋了與車輛和保險有關的業務流程的一些關鍵點。在本主題中，我們將以car 智能合約爲例。我們可以看到，智能合約是一個特定領域的程序，它與特定的業務流程相關，而鏈碼則是一組相關智能合約的技術容器。
賬本
以最簡單的方式來說，區塊鏈記錄着更新賬本狀態的交易，且記錄不可篡改。智能合約以編程方式訪問賬本兩個不同的部分： 一個是區塊鏈（記錄所有交易的歷史，且記錄不可篡改），另一個是世界狀態（保存這些狀態當前值的緩存，是一個經常需要用到的對象的當前值）。
智能合約主要在世界狀態中將狀態寫入（put）、讀取（get）和刪除（delete），還可以查詢不可篡改的區塊鏈交易記錄。
- 讀取（get） 操作一般代表的是查詢，目的是獲取關於交易對象當前狀態的信息。
- 寫入（put） 操作通常生成一個新的業務對象或者對賬本世界狀態中現有的業務對象進行修改。
- 刪除（delete） 操作代表的是將一個業務對象從賬本的當前狀態中移除，但不從賬本的歷史中移除。
智能合約有許多可用的 API（應用程序編碼接口）。但關鍵的是，在所有情況下，無論交易創建、讀取、更新還是刪除世界狀態中的業務對象，區塊鏈都包含了這些操作的記錄，且記錄不可更改 。
開發
智能合約是應用程序開發的重點，正如我們所看到的，一個鏈碼中可定義一個或多個智能合約。將鏈碼部署到網絡中以後，網絡上的組織就都可以使用該鏈碼中的所有智能合約。這意味着只有管理員才需要考慮鏈碼；其他人都只用考慮智能合約。
智能合約的核心是一組 transaction 定義。例如，在 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 等編程語言來表示成一個智能合約。將數百年的法律語言轉換爲編程語言需要法律和技術方面的技能，智能合約審覈員們不斷地實踐着這些技能。您可以在開發應用程序主題中瞭解如何設計和開發智能合約。
背書
每個鏈碼都有一個背書策略與之相關聯，該背書策略適用於此鏈碼中定義的所有智能合約。背書策略非常重要，它指明瞭區塊鏈網絡中哪些組織必須對一個既定智能合約所生成的交易進行簽名，以此來宣佈該交易有效。
每個智能合約都有一個與之關聯的背書策略。這個背書策略定義了在智能合約生成的交易被認證爲有效之前，哪些組織必須同意該交易。
一個示例背書策略可能這樣定義：參與區塊鏈網絡的四個組織中有三個必須在交易被認爲有效之前簽署該交易。所有的交易，無論是有效的還是無效的，都會被添加到分佈式賬本中，但僅有效交易會更新世界狀態。
如果一項背書策略指定，必須有不止一個組織來簽署交易，那麼只有當足夠數量的組織都執行了智能合約，才能夠生成有效交易。在上面的示例中，要使用於車輛 transfer 的智能合約交易有效，需要 ORG1 和 ORG2 都執行並簽署該交易。
背書策略是 Hyperledger Fabric 與以太坊（Ethereum）或比特幣（Bitcoin）等其他區塊鏈的區別所在。在這些區塊鏈系統中，網絡上的任何節點都可以生成有效的交易。而 Hyperledger Fabric 更真實地模擬了現實世界；交易必須由 Fabric 網絡中受信任的組織驗證。例如，一個政府組織必須簽署一個有效的 issueIdentity 交易，或者一輛車的 buyer 和 seller 都必須簽署一個 car轉移交易。背書策略的設計旨在讓 Hyperledger Fabric 更好地模擬這些真實發生的交互。
最後，背書策略只是 Hyperledger Fabric 中策略的一個例子。還可以定義其他策略來確定誰可以查詢或更新賬本，或者誰可以在網絡中添加或刪除參與者。總體來說，雖然區塊鏈網絡中的組織聯盟並非一成不變，但是它們需要事先商定好策略。實際上，策略本身可以定義對自己進行更改的規則。雖然現在談論這個主題有點早，但是在 Fabric 提供的規則基礎上來定義自定義背書策略的規則也是可能實現的。
有效交易
當智能合約執行時，它會在區塊鏈網絡中組織所擁有的節點上運行。智能合約提取一組名爲交易提案的輸入參數，並將其與程序邏輯結合起來使用以讀寫賬本。對世界狀態的更改被捕獲爲交易提案響應（或簡稱交易響應），該響應包含一個讀寫集，其中既含有已讀取的狀態，也含有還未書寫的新狀態（如果交易有效的話）。注意，在執行智能合約時世界狀態沒有更新！
所有的交易都有一個識別符、一個提案和一個被一羣組織簽名的響應。所有交易，無論是否有效，都會被記錄在區塊鏈上，但僅有效交易會更新世界狀態。
檢查 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所有。
最後，要了解如何通過世界狀態來使用智能合約或鏈碼，請閱讀鏈碼命名空間主題。
通道
Hyperledger Fabric 允許一個組織利用通道同時參與多個、彼此獨立的區塊鏈網絡。通過加入多個通道，一個組織可以參與一個所謂的網絡的網絡。通道在維持數據和通信隱私的同時還提供了高效的基礎設施共享。通道是足夠獨立的，可以幫助組織將自己的工作流量與其他組織的分開，同時它還具有足夠的協調性，在必要時能夠協調各個獨立的活動。
通道在一羣組織之間提供了一種完全獨立的通信機制。當鏈碼定義被提交到通道上時，該通道上所有的應用程序都可以使用此鏈碼中的智能合約。
雖然智能合約代碼被安裝在組織節點的鏈碼包內，但是隻有等到鏈碼被定義在通道上之後，該通道上的成員才能夠執行其中的智能合約。鏈碼定義是一種包含了許多參數的結構，這些參數管理着鏈碼的運行方式，包含着鏈碼名、版本以及背書策略。各通道成員批准各自組織的一個鏈碼定義，以表示其對該鏈碼的參數表示同意。當足夠數量（默認是多數）的組織都已批准同一個鏈碼定義，該定義可被提交至這些組織所在的通道。隨後，通道成員可依據該鏈碼定義中指明的背書策略來執行其中的智能合約。這個背書策略可同等使用於在相同鏈碼中定義的所有智能合約。
在上面的示例中，car 智能合約被定義在 vehicle 通道上，insurance 智能合約被定義在 INSURANCE 通道上。car 的鏈碼定義明確了以下背書策略：任何交易在被認定爲有效之前必須由 ORG1 和 ORG2 共同簽名。insurance 智能合約的鏈碼定義明確了只需要 ORG3對交易進行背書即可。ORG1 參與了 VEHICLE 通道和 INSURANCE 通道這兩個網絡，並且能夠跨網絡協調與 ORG2和 ORG3 的活動。
將汽車合約部署到車輛通道，並將保險合約部署到保險通道。汽車合約有一個背書策略，要求 ORG1 和 ORG2 在交易被認爲有效之前簽署該交易，而保險合約也有一個背書策略，只要求 ORG3 簽署有效交易。ORG1 參與車輛通道和保險網絡兩個網絡，分別與 ORG2 和 ORG3 協調這兩個網絡之間的活動。
互通
一個智能合約既可以調用同通道上的其他智能合約，也可以調用其他通道上的智能合約。這樣一來，智能合約就可以讀寫原本因爲智能合約命名空間而無法訪問的世界狀態數據。
這些都是智能合約彼此通信的限制，我們將在鏈碼命名空間主題中詳細描述。
系統鏈碼
鏈碼中定義的智能合約爲一羣區塊鏈組織共同認可的業務流程編碼了領域相關規則。然而，鏈碼還可以定義低級別程序代碼，這些代碼符合無關於領域的系統交互，但與業務流程的智能合約無關。
以下是不同類型的系統鏈碼及其相關縮寫：
_lifecycle在所有 Peer 節點上運行，它負責管理節點上的鏈碼安裝、批准組織的鏈碼定義、將鏈碼定義提交到通道上。你可以在這裏閱讀更多關於_lifecycle如何實現 Fabric 鏈碼生命週期的內容。- 生命週期系統鏈碼（LSCC）負責爲1.x版本的 Fabric 管理鏈碼生命週期。該版本的生命週期要求在通道上實例化或升級鏈碼。你可以閱讀更多關於LSCC如何實現這一過程。如果你的 V1_4_x 或更低版本設有通道應用程序的功能，那麼你也可以使用LSCC來管理鏈碼。
- 配置系統鏈碼（CSCC）在所有 Peer 節點上運行，以處理通道配置的變化，比如策略更新。你可以在這裏閱讀更多 CSCC 實現的內容。
- 查詢系統鏈碼（QSCC）在所有 Peer 節點上運行，以提供賬本 API（應用程序編碼接口），其中包括區塊查詢、交易查詢等。你可以在交易場景主題中查閱更多這些賬本 API 的信息。
- 背書系統鏈碼（ESCC）在背書節點上運行，對一個交易響應進行密碼簽名。你可以在這裏閱讀更多 ESCC 實現的內容。
- 驗證系統鏈碼（VSCC）驗證一個交易，包括檢查背書策略和讀寫集版本。你可以在這裏閱讀更多 LSCC 實現的內容。
底層的 Fabric 開發人員和管理員可以根據自己的需要修改這些系統鏈碼。然而，系統鏈碼的開發和管理是一項專門的活動，完全獨立於智能合約的開發，通常沒有必要進行系統鏈碼的開發和管理。系統鏈碼對於一個 Hyperledger Fabric網絡的正常運行至關重要，因此必須非常小心地處理系統鏈碼的更改。例如，如果沒有正確地開發系統鏈碼，那麼有可能某個 Peer 節點更新的世界狀態或區塊鏈備份與其他 peer 節點的不同。這種缺乏共識的現象是賬本分叉的一種形式，是極不理想的情況。