好了，進入正題。我今天分享的內容的題目是Fabric1.0 Chaincode介紹。除了介紹Chaincode程序編寫、調試的基本方法之外，我還加入了一些有關Chaincode原理的內容，希望能夠幫助大家更好地理解Chaincode，進而編寫出更加高效的Chaincode程序以及更加快速地調試自己的Chaincode程序。
Page 2

我把內容分成了三個部分。內容包括：在fabric 中Chaincode是什么、如何編寫Chaincode程序以及如何調試Chaincode程序。中間會穿插與Chaincode相關的重要概念介紹，以及Chaincode運行原理的介紹。
Page 3

首先是第一部分內容：在fabric中，Chaincode是什么呢？我覺得可以從以下幾個方面來理解。
第一，編寫Chaincode程序實際上就是要編寫一個類，并且這個類要實現fabric預先定義的一個接口。關于這個接口后面第二部分會有更詳細的介紹。
第二，如何運行Chaincode程序呢？我們知道blockchain系統是一個網絡，由若干結點構成。Fabric區塊鏈系統也不例外，而要運行Chaincode程序，就要把它首先部署到fabric系統的結點上。也就是說，Chaincode程序是依賴于fabric系統結點的。
第三點和第四點可以放在一塊來看。對于一個區塊鏈系統來說，顯然，區塊鏈其中是最重要的組成部分。右邊這個圖展示了最基本的區塊鏈結構：首先區塊鏈是由一個一個的區塊串接而成，每個區塊又是由若干的Transaction構成。所以，可以說Transaction是一個區塊鏈系統中最基本的組成要素。而在Fabric中，Chaincode的運行是生成Transaction的唯一來源，也因此Chaincode是外界與Fabric區塊鏈交互的唯一渠道。由此可見chaincode的重要性。
最后一點講的是Chaincode與智能合約的關系。相信大家都聽說智能合約的概念，簡單來講智能合約就是用程序實現合約的內容，并且這個程序是事件驅動、有狀態的。智能合約是早就出現的概念，早于區塊鏈提出。但是，區塊鏈的出現為智能合約的實現提供了一個非常理想的環境。而在Fabric中，Chaincode就是開發者實現智能合約的方式。
Page 4
這一頁是在fabric1.0中與Chaincode相關的幾個比較重要的概念。
Channel是1.0增加的一個比較大的feature。字面意思，通道。流過通道的數據對于加入該通道的結點是共享的。因此，對于加入同一通道的結點來說，就相當于構建了一條子鏈。這條子鏈上的內容對于通道外的結點是不可知的。并且，同一個peer結點可以加入不同channel。而Chaincode的執行是基于channel進行的，在一條channel上chaincode執行的結果會被該channel上所有的結點同步到本地Ledger中。
然后是Endorser、Orderer、Committer，它們是將原來0.6中VP的功能進行拆分后產生的三個角色。
Endorser結點會模擬執行chaincode，這樣就相當于把計算任務從consensus結點獨立出來，進而減輕了consensus結點的負擔，也就可以增加系統吞吐量。同時，比較重要是fabric1.0可以支持endorsement policy，即一個transaction的提交需要哪些endorser進行背書才可通過。這樣整個系統的訪問控制就更加靈活。
Orderer結點的工作就是consensus。Chaincode在endorser結點處執行之后，會被發送給orderer進行排序或者說consensus，保證transaction的順序是一致的。然后，orderer結點會把transaction發送給相應的channel中的所有committer結點。 Committer結點會將接收到的transaction寫進block。
Page 5

這是fabric1.0對chaincode開發情況的支持。
在開發語言上，支持go和Java兩種語言來編寫chaincode程序。我下面是以go語言為例來介紹chaincode的編寫的。
關于SDK，如果使用vagrant方式搭建自己的fabric開發環境的話，在你的這條路徑下，$GOPATH/src/github.com/hyperledger/fabric/core/chaincode/shim，就是chaincode開發的SDK。
Page 6

接下來是第二部分，如何編寫Chaincode。
前面提到編寫chaincode就是實現一個接口，這里就是那個接口的定義。 可以看到這個接口定義了兩個方法，分別具有不同的作用。
首先，Init方法會在Instantiate chaincode時被調用。因此，一般在其中完成一些初始化工作，并且僅被執行一次。
Invoke方法會在Invoke或Query chaincode時被調用。其中的代碼可以查詢或更新底層的數據，并且可被多次調用。
Page 7

這一頁是使用go語言編寫chaincode時的一個最基本的框架。
可以看到，最主要的是編寫自己的chaincode類，實現剛剛看到的兩個方法。然后在main函數中通過API shim.start()來向特定peer結點注冊該chaincode。
那么如何使用相關的API呢？兩種方式，一種是通過參數stub shim.ChaincodeStubInterface，fabric在該接口中定義了豐富的API；此外，fabric也定義了一些全局的函數可被使用，比如這里的start()函數就是其中之一。
Page 8

那么，先看ChaincodeStub提供了哪些API。我將這些API分成了五大類。
第一大類與state操作相關。通過這些API可以根據key來查詢/添加/更新相應的state。這些API提供了單key的讀寫操作、key字典序范圍讀取操作、composite key讀取操作、底層數據庫語法的查詢操作等。
第二大類與與參數相關。fabric1.0修改了chaincode接口的定義，需要開發者自己調用API獲取傳入的參數。注意，傳入的參數第一個是函數名稱，之后才是相應的函數輸入參數。
Page 9

第三大類與Transaction有關，并且這一類都是讀操作，讀取transaction中各種信息，比如transaction id、timestamp等。
第四類是與chaincode間相互調用有關的一個API。Fabric允許在一個chaincode中根據chaincode name和channel name去調用另一個chaincode。可以看到并沒有deploy的API，也就是說，fabric不允許在一個chaincode中去部署新的chaincode。
最后一類也只有一個API，SetEvent。Fabric允許開發者定義自己的event，然后這個event會在transaction寫進block時觸發，因此開發者就可以自己寫相應的event handler程序做一些相關的工作。
Page 10

此外就是一些全局的或輔助的API。
比如剛才看到的Start函數，它向指定的peer結點注冊chaincode。
輔助類StateRangeQueryIterator與前面state范圍查詢的API有關。
關于API的詳細說明可以打開這個鏈接看到。但是上面基于的是最新的fabric實現，所以跟剛才講的會有很多不同。具體以你使用fabric版本為準。
Page 11

第三部分講的是如何調試chaincode。
在介紹具體調試步驟之前，我想先介紹一下chaincode運行的基本原理，我覺得這有助于chaincode的開發。
首先，fabric peer結點有兩種運行模式。一種是一般模式，在這種模式下chaincode運行在Docker容器中。這也是fabric在production環境下的運行模式。這就相當于給chaincode的運行提供了一個相對隔離的環境，這樣整個系統也就更加的健壯。但是在這種模式下，調試過程就變得非常復雜。因為一旦調試過程中發現bug，重新install，然后重新部署。而在這個過程中，install和Docker image的build過程都比較耗時。
所以，針對這個問題，fabric又提供了開發模式。在這種模式下chaincode直接運行在本地，這樣chaincode的調試過程就與普通程序的調試過程完全一樣，因此開發調試過程就更加容易。 要說明的是，我目前看的fabric1.0的代碼對于開發模式的支持還不完備，部署的時候回失敗。
Page 12

但是因為開發模式的原理比較容易理解，這里我還是以開發模式為例介紹一下chaincode的運行原理。一般模式下，只需將chaincode的運行放在Docker容器中進行理解。
首先，這個圖描述的是開發模式下chaincode注冊時的執行過程。
首先，chaincode會向指定的peer結點發送相關信息，比如chaincode name。然后，peer結點會做一些檢查，主要是看該chaincode name是否已存在。如果不存在，則注冊成功，為其創建相應的handler，然后返回相關信息。此后，chaincode就與peer結點建立起了聯系，并且二者始終處于互相監聽狀態。
Page 13

這個圖描述的是開發模式下chaincode Instantiate/invoke/query時的運行過程。
首先，通過CLI或App向指定endorser結點發送Instantiate/invoke/query請求。
endorser接收到請求之后，如果相關chaincode存在，就會將請求發送到chaincode端，并執行相應函數。由于執行過程中，可能涉及到多次的state的讀寫，而每一次的讀寫都會涉及到底層db的操作，所以這個過程會涉及到多次與endorser結點的通信。
最后，chaincode執行完畢之后，會發送消息給endorser結點。如果執行成功，endorser結點就會封裝執行結果并對其endorse，并把結果返回給CLI/APP端，然后進行ordering。這個圖里沒有給出ordering和committing的過程。
Page 14

這里給出一般模式下Chaincode的開發調試過程。以fabric chaincode_example02為例，完全本地，并且使用fabric默認配置。我的環境是使用vagrant方式搭建的。 首先，啟動orderer結點，運行在solo模式下。
然后，本地啟動一個peer結點，指定peer的名稱。
然后，install chaincode程序，指定chaincode的名稱以及version，它們將用于命名build出來的docker image。默認配置下，需要你的chaincode程序位于GOPATH/src路徑下，并且這個命令會將GOPATH/src下的幾乎所有文件都打包發送到指定的peer結點。
Page 15

接下來，通過Instantiate命令部署剛剛install的chaincode，同樣需要給出chaincode名稱和version。channel的名稱是可選的，如果省略將默認使用testchainid這個channel，peer啟東時會默認加入這個channel。
之后，就可以通過invoke和query命令來調試自己的chaincode程序了。這里同樣使用默認的channel testchainid。
Page 16

答疑解惑
問：Fabric 1.0中的系統 chaincode 可否簡單介紹下？ 答：1.0中有五個系統chaincode，分別是lccc/cscc/escc/vscc/qscc，它們在peer啟動或創建channel的時候就會部署，并且與peer運行在同一進程中，而不是Docker container中。 lccc是生命周期系統chaincode，用于管理用戶chaincode的install、Instantiate等；cscc是配置系統chaincode，與系統配置有關，比如join channel的時候，就是通過cscc來進行的；escc和vscc分別是endorsement系統chaincode和verification系統chaincode，主要是endorser用于對用戶chaincode進行相關驗證和背書，它們可以在Instantiate chaincode的時候指定，也就是說用戶可以根據自己的情況給某個endorser結點設置定制化的escc和vscc；qscc，不好意思我還不太了解，后面研究清楚之后再跟大家分享。
問：Fabric 1.0 調用其他 CHAINCODE 現在支持了嗎？ 答：1.0 里面是計劃支持跨 chaincode 的讀操作的。
問：chaincode處理的數據來源可以自己獲取嗎，比如時間，或者其他服務器的一些數據？ 答：理論上 chaincode 就是一個獨立運行的可執行程序，它會與遠端的endorser 進行通信，所以 chaincode 程序是可以訪問外部數據源的。
問：fabric 中每個 block 都有 world state 的 hash，但是這個歷史的 world state 存放在什么地方？如何讀取指定 block height 的world state？ 答：fabric 1.0 中每個 peer 結點會維護四個 db，分別是 id store，存儲 chainID；stateDB，存儲 world state；versioned DB，存儲 key 的版本變化；還有 blockdb，存儲 block。
問：請問在chaincode運行原理這塊，CLI或App是把請求直接發給endoser節點還是發給install了這個chaincode的peer節點，再由這個peer去與endoser交互呢？ 答：實際上是發給了 endorser 結點，這個是在你的調用請求里指定的。
問：chaincode 的 world state 何時被寫入？ 答：ordering之后，channel 上的所有 peer 都會執行 commiting 操作,即寫入stateDB操作。
與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的Hyperledger Fabric Chaincode 开发的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。