在這篇文章里我不打算探討Hyperledger Fabric鏈碼設(shè)計(jì)的特定模式的好與壞，而是希望分享我在開發(fā)若干Hyperledger Fabric概念驗(yàn)證應(yīng)用過程中總結(jié)的一些基本準(zhǔn)則。

1.使用鏈碼DevMode(開發(fā)模式) 使用開發(fā)模式開啟你的Hyperledger Fabric鏈碼開發(fā)流程。這會(huì)節(jié)省你大量的時(shí)間和精力，因?yàn)槟憧梢宰杂傻匦薷拇a而無需https://github.com/hyperledger/fabric-samples/tree/release/chaincode-docker-devmode

P.S.-雖然這個(gè)教程是使用Golang，除了構(gòu)建鏈碼部分，使用其他語言其實(shí)也差不多。

2.使用鏈碼Logging（日志） 這可能是能幫助你調(diào)試Hyperledger Fabric鏈碼并快速找出鏈碼bug的一個(gè)有用的技能。鏈碼日志很簡單易用，使用Fabric內(nèi)建的logger即可。

參考文檔： Golang：shim.ChaincodeLogger NodeJS：shim.newLogger Java：可以使用任何標(biāo)準(zhǔn)的日志框架，例如log4j

3.避免在Fabric鏈碼中使用全局鍵（Global Keys） 在開發(fā)Hyperledger Fabric鏈碼時(shí)，我們經(jīng)常會(huì)發(fā)現(xiàn)在搜索數(shù)據(jù)方面限制很多，因此要跟蹤在鍵值庫中注冊的鍵，我們有時(shí)會(huì)嘗試使用某些全局?jǐn)?shù)據(jù)。

例如，當(dāng)你再Hyperledger Fabric應(yīng)用中跟蹤注冊的彈珠時(shí)，可能想創(chuàng)建一個(gè)全局的計(jì)數(shù)器以便生成彈珠的下一個(gè)ID。但是這么做的時(shí)候，你就引入了對(duì)這個(gè)變量的依賴。在開始的時(shí)候這看起來不是個(gè)問題，但是當(dāng)你提交并發(fā)交易時(shí)就會(huì)出錯(cuò)。

在提交交易時(shí)，Hyperledger Fabric使用一個(gè)優(yōu)化的鎖模型，因此當(dāng)存在并發(fā)交易同時(shí)更新相同的鍵時(shí)，就有可能出現(xiàn)MVCC_READ_CONFLICT錯(cuò)誤。

4.聰明地使用CouchDB查詢 CouchDB查詢（又稱為Mongo查詢）在搜索Fabric節(jié)點(diǎn)的鍵值庫中的數(shù)據(jù)時(shí)非常有用，但是有些陷阱你需要注意：

a) CouchDB查詢不會(huì)修改交易的READSET b) 只能搜索到已經(jīng)存入CouchDB的數(shù)據(jù)

5.編寫確定性的Fabric鏈碼 永遠(yuǎn)不要編寫不確定的鏈碼。意思是說如果在多個(gè)不同的時(shí)間、不同的環(huán)境下執(zhí)行鏈碼，總應(yīng)該得到相同的結(jié)果。例如，避免使用像rand.New(...)或t:=time.Now這樣的代碼，或者依賴于某個(gè)沒有在賬本中持久化的變量。

6.小心調(diào)用其他通道的Fabric鏈碼 在鏈碼中調(diào)用同一個(gè)通道中的另一個(gè)鏈碼沒問題，但是要了解的是，如果是要調(diào)用另一個(gè)通道的鏈碼，你只能得到鏈碼方法的返回結(jié)果，而不會(huì)在另一個(gè)通道賬本中有任何提交。目前，跨通道的鏈碼調(diào)用不會(huì)修改數(shù)據(jù)，因此，一個(gè)交易一次只能寫入一個(gè)通道。

7.記得設(shè)置Fabric鏈碼的執(zhí)行超時(shí)時(shí)間 在高負(fù)載的情況下，你的Hyperledger Fabric鏈碼可能不會(huì)在30s內(nèi)完成。因此一個(gè)好的實(shí)踐是根據(jù)需求定制鏈碼執(zhí)行超時(shí)值。在docker-compose文件中可以設(shè)置： CORE_CHAINCODE_EXECUTETIMEOUT=60s

8.避免從Fabric鏈碼中訪問外部資源 訪問外部資源可能會(huì)暴露系統(tǒng)漏洞并給你的Hyperledger Fabric鏈碼引入安全威脅。因此請(qǐng)盡可能的避免再Fabric鏈碼中訪問區(qū)塊鏈外部的資源。

熱點(diǎn)：智能合約