參考：http://hyperledger-fabric.readthedocs.io/en/latest/chaincode4noah.html
chaincode也能被稱作“智能合約”，一般情況下，chaincode不能直接去訪問另一個chaincode創建的狀態，但是在相同網絡下，在合適的許可下，chaincode可以調用另一個chaincode去訪問其創建的狀態。
1.chaincode生命周期
Hyperledger Fabric API允許與blockchain網絡中的各個節點（peers，orderers，MSPs）進行交互，同時也允許在endoring peer上package、install、instantiate以及upgrade chaincode。Hyperledger Fabric語言特定的SDK抽象了Hyperledger Fabric API的細節，以幫助應用程序開發，盡管它也能用作管理chaincode的生命周期。另外，CLI可以直接訪問Hyperledger Fabric API。
我們提供了4種命令去管理chaincode生命周期：package、install、instantiate、upgrade。將來發布的版本的會增加stop以及start transaction用於停止與開啟chaincode，而不用去卸載chaincode。chaincode在成功install以及instantiate之后，chaincode則是運行狀態，能夠通過invoke transaction來處理transaction。后續也能夠對chaincode進行升級。
2.package
chaincode package包括三個部分：
- 由ChaincodeDeploymentSpec（CDS）定義的chaincode。CDS根據代碼及其他屬性（如名稱與版本）定義了chaincode package；
- 一個可選的instantiation策略，能夠被用作endorsement的策略（Endorsement policie）進行描述；
- 擁有chaincode的entities的一組簽名。
其中簽名有以下幾種目的：
- 建立chaincode的所有權；
- 允許驗證package中的內容；
- 允許檢測package是否被篡改。
channel上的chaincode的instantiation交易的創建者能夠被chaincode的instantiation策略驗證。
2.1 創建package
現有兩種打包chaincode的方法。第一種，當你想有被多個所有者所擁有的某個chaincode，需要該chaincode package被上述多個所有者簽名。上述工作流需要我們首先初始化創建一個被簽名的chaincode package（SignedCDS），然后將其按順序的傳遞給其他所有者進行簽名。
第二種也是更簡單的工作流程是，當部署一個僅有節點（該節點能夠發布install transaction）的身份簽名的SignedCDS的時候。
首先，讓我們來看看更復雜的情況。
使用如下命令創建一個被簽名的chaincode package，
peer chaincode package -n mycc -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -v 0 -s -S -i "AND('OrgA.admin')" ccpack.out
其中，-s選項創建了一個能被多個所有者簽名的package，而不是簡單的創建一個原始的CDS。一旦-s被指定，如果其他所有者想要簽名這個CDS，則-S選項必須被指定。否則，這個過程將會創建一個SignedCDS，除CDS之外僅僅包括instantiation策略。
-S選項使用被在core.yaml文件中定義的localMspid屬性的值標識的MSP對package進行簽名。
-S選項是可選的。然而如果創建了一個沒有簽名的package，它不能被其他所有者使用signpackage命令進行簽名。
可選的-i選項允許為chaincode指定instantiation策略。instantiation策略與endorsement策略有着相同的格式，指定哪些身份能夠實例化chaincode。在上述的例子中，僅僅OrgA的admin能夠實例化chaincode。如果沒有策略被提供，那么將會使用默認的策略，這個僅僅允許擁有peer的MSP的管理員身份實例化chaincode。
2.2 package的簽名
在創建階段就被簽名的chaincode package能夠交給其他所有者進行檢查與簽名。該工作流程支持帶外對chaincode進行簽名。
ChaincodeDeploymentSpec可以選擇由所有者集合進行簽名，從而創建一個SignedChaincodeDeploymentSpec(SignedCDS)。SignedCDS包括3個部分：
1.CDS包括源代碼，chaincode的名稱與版本號；
2.chaincode的實例化策略，表示為endorsement策略；
3.chaincode所有者的列表，該列表由 Endorsement 定義。
注意：當在某些channel上實例化chaincode的時候，這種endorsement策略是在帶外確定的，用於提供合適的MSP主體。如果沒指定實例化策略，則默認的策略就是channel的任何MSP管理員。
每一個chaincode的所有者通過將其與該所有者的身份（例如證書）組合並簽署組合結果來endorse ChaincodeDeploymentSpec。
一個chaincode的所有者能夠對之前創建的簽名過的package進行簽名，需要使用如下命令：
peer chaincode signpackage ccpack.out signedccpack.out
其中cpack.out 與 signedccpack.out分別是輸入與輸出包。signedccpack.out包括一個對package附加的簽名（通過local msp進行的簽名）。
3.安裝chaincode
安裝transaction將chaincode的源代碼打包成被稱之為ChaincodeDeploymentSpec（CDS）的規定的格式，然后安裝到將會執行chaincode的peer節點上。
注意：需將chaincode安裝到channel中每個endoring peer（將會執行chaincode）上。
當安裝API只是一個ChaincodeDeploymentSpec時，它將默認初始化策略並包括一個空的所有者列表。
注意：chaincode應該僅僅被安裝在chaincode所有者成員的endoring peer節點上，用於實現該chaincode對於網絡中其他成員在邏輯上是保密的。沒有chaincode的成員，不能成為chaincode transaction的endorser；也就是說，它們不能執行chaincode。但是，他們仍然能夠驗證與提交transaction到Ledger上。
安裝chaincode會發送一個SignedProposal到lifecycle system chaincode (LSCC) 。例如，使用CLI安裝sacc的樣例chaincode，命令如下：
peer chaincode install -n asset_mgmt -v 1.0 -p sacc
CLI內部創建了sacc的SignedChaincodeDeploymentSpec，然后把這個發送給本地peer，該peer會調用LSCC上的安裝方法。參數-p選擇指定了chaincode的路徑，該源代碼必須在GOPATH的路徑下，例如$GOPATH/src/sacc。
注意：為了在peer上安裝chaincode，SignedProposal的簽名必須來自於peer的本地MSP管理員之一。
4.實例化（instantiate）
實例化transaction調用lifecycle System Chaincode (LSCC) 用於創建及初始化channel上的chaincode。chaincode-channel綁定過程：chaincode能夠被綁定到任意數量的channel，以及在每個channel上單獨的操作。換句話說，無論有chaincode安裝及實例化到多少個channel上，每個channel的狀態都是隔離的。
實例化transaction的創建者必須滿足包含在SignedCDS內chaincode的實例化策略，而且還必須是channel的寫入器（作為channel創建的一部分被配置）。這對於channel來說很重要，這樣可以防止部署chaincode的流氓實體或者欺騙者在未被綁定的channel上執行chaincode。
默認的實例化策略是任意的channel MSP的管理員，因此chaincode實例化transaction的創建者必須是channel管理員之一。當transaction proposal到達endorser后，endorser會根據實例化策略驗證創建者的簽名。在提交這個transaction到Ledger之前，在transaction驗證時再一次完成該操作。
實例化transaction同樣設置了channel上的chaincode的endorsement策略 。endorsement 策略描述了 transacation被channel上成員接受的認證要求。
例如，使用CLI去實例化sacc的chaincode並初始化狀態為john與0，命令如下：
peer chaincode instantiate -n sacc -v 1.0 -c '{"Args":["john","0"]}' -P "OR ('Org1.member','Org2.member')"
上述endorsement策略表示，org1.member 或者 org2.member 必須對調用使用sacc的transaction進行簽名，以保障transaction是有效的。在成功實例化后，channel的chaincode進入激活狀態，可以處理任意的transaction proposal。transaction到達endoring peer時，這些transaction同時被處理。
5.升級
chaincode的升級通過改變其版本號（作為SignedCDS的一部分）。SignedCDS另外的部分，如所有者及實例化策略都是可選的。然而，chaincode的名稱必須是一致的，否則會被當做另外一個新的chaincode。
在升級之前，必須將新版本的chaincode安裝到有需求的endorser上。升級也是transaction，類似於實例化transaction，該transaction會把新版本的chaincode綁定到channel中去。其他綁定老版本的chaincode仍然執行老版本。換句話說，升級transaction只能在一個時間點對一個channel產生影響。
注意：由於可能存在多個版本的chaincode同時存在，升級過程不會自動刪除老版本chaincode，用戶必須手動操作這個過程。
升級transaction與實例化transaction有一點不同的是：通過現有的chaincode實例化策略檢查升級transaction，而不是用新的策略檢查。這是為了確保只有當前實例化策略中指定的成員能夠升級chaincode。
注意：在升級期間，chaincode的init函數也會被調用，執行有關升級的數據或者使用這些數據重新進行初始化，需要小心的是，在升級chaincode的期間避免對狀態進行重置了。
6.停止及啟動
目前該功能還沒有實現，目前可以通過手動刪除chaincode容器以及從每個endorser上刪除SignedCDS 來實現停止功能。通過刪除endoring peer節點正在運行的主機或者虛擬機上的chaincode容器來實現刪除chaincode容器，接下來刪除每個endoring peer節點上的SignedCDS。
docker rm -f <container id> rm /var/hyperledger/production/chaincodes/<ccname>:<ccversion>
停止功能在以受控的方式進行升級的流程中是很有用的，在發布升級之前對chaincode進行停止操作。
7.CLI
目前，你可以在運行的docker容器中調用命令。為了看看現有的CLI命令，你可以在運行的fabric-peer的docker容器中執行如下命令：
docker run -it hyperledger/fabric-peer bash
# peer chaincode --help
輸入如下：
為方便在腳本應用下使用，在命令失敗的條件下，peer命令總是會產生一個非0的返回碼。
chaincode的命令事例如下：
peer chaincode install -n mycc -v 0 -p path/to/my/chaincode/v0 peer chaincode instantiate -n mycc -v 0 -c '{"Args":["a", "b", "c"]} -C mychannel peer chaincode install -n mycc -v 1 -p path/to/my/chaincode/v1 peer chaincode upgrade -n mycc -v 1 -c '{"Args":["d", "e", "f"]} -C mychannel peer chaincode query -C mychannel -n mycc -c '{"Args":["query","e"]}' peer chaincode invoke -o orderer.example.com:7050 --tls $CORE_PEER_TLS_ENABLED --cafile $ORDERER_CA -C mychannel -n mycc -c '{"Args":["invoke","a","b","10"]}'
8.系統chaincode
系統chaincode跟普通chaincode有着相同的編程模型，除了在peer內運行而不是像普通chaincode在隔離的容器中運行。因此，系統chaincode內置為peer的可執行文件中，不用遵循上述的生命周期。特別地，安裝、實例化、以及升級不適用於系統chaincode。
系統chaincode的目的就是減少peer與chaincode的gRPC通信的開銷，同時權衡管理的靈活性。例如，系統chaincode只能通過peer的二進制文件升級。系統chaincode必須通過一組固定的參數進行注冊，同時不具有endorsement策略。
Hyperledger Fabric用到的系統chaincode，實現了一系列系統功能，以便系統集成人員能夠根據需求對它們進行修改與替換。
現有的系統chaincode如下：
LSCC 生命周期系統chaincode處理上述描述的生命周期管理。
CSCC 配置系統chaincode處理在peer上的channel配置。
QSCC 查詢系統chaincode提供賬本的查詢API，例如獲取block以及transaction。
ESCC endorsement系統chaincode通過對transaction proposal響應進行簽名來處理endorsement過程。
VSCC 驗證系統chaincode處理transaction驗證，包括檢查endorsement策略以及多進程並發控制。
在修改或者替換特別是LSCC,ESCC以及VSCC 系統chaincode時必須小心，因為他們在主transaction執行的路徑中。值得注意的是，VSCC在將block提交至賬本之前，所有在channel的peer會計算相同的驗證以避免賬本分歧（不確定性）。如果VSCC被改變或者替換了，需要特別小心。