Fabric链码编写指南

在这篇文章里我不打算探讨Hyperledger Fabric链码设计的特定模式的好与坏，而是希望分享我在开发若干Hyperledger Fabric概念验证应用过程中总结的一些基本准则。

1.使用链码DevMode(开发模式) 使用开发模式开启你的Hyperledger Fabric链码开发流程。这会节省你大量的时间和精力，因为你可以自由地修改代码而无需https://github.com/hyperledger/fabric-samples/tree/release/chaincode-docker-devmode

P.S.-虽然这个教程是使用Golang，除了构建链码部分，使用其他语言其实也差不多。

2.使用链码Logging（日志） 这可能是能帮助你调试Hyperledger Fabric链码并快速找出链码bug的一个有用的技能。链码日志很简单易用，使用Fabric内建的logger即可。

参考文档： Golang：shim.ChaincodeLogger NodeJS：shim.newLogger Java：可以使用任何标准的日志框架，例如log4j

3.避免在Fabric链码中使用全局键（Global Keys） 在开发Hyperledger Fabric链码时，我们经常会发现在搜索数据方面限制很多，因此要跟踪在键值库中注册的键，我们有时会尝试使用某些全局数据。

例如，当你再Hyperledger Fabric应用中跟踪注册的弹珠时，可能想创建一个全局的计数器以便生成弹珠的下一个ID。但是这么做的时候，你就引入了对这个变量的依赖。在开始的时候这看起来不是个问题，但是当你提交并发交易时就会出错。

在提交交易时，Hyperledger Fabric使用一个优化的锁模型，因此当存在并发交易同时更新相同的键时，就有可能出现MVCC_READ_CONFLICT错误。

4.聪明地使用CouchDB查询 CouchDB查询（又称为Mongo查询）在搜索Fabric节点的键值库中的数据时非常有用，但是有些陷阱你需要注意：

a) CouchDB查询不会修改交易的READSET b) 只能搜索到已经存入CouchDB的数据

5.编写确定性的Fabric链码 永远不要编写不确定的链码。意思是说如果在多个不同的时间、不同的环境下执行链码，总应该得到相同的结果。例如，避免使用像rand.New(...)或t:=time.Now这样的代码，或者依赖于某个没有在账本中持久化的变量。

6.小心调用其他通道的Fabric链码 在链码中调用同一个通道中的另一个链码没问题，但是要了解的是，如果是要调用另一个通道的链码，你只能得到链码方法的返回结果，而不会在另一个通道账本中有任何提交。目前，跨通道的链码调用不会修改数据，因此，一个交易一次只能写入一个通道。

7.记得设置Fabric链码的执行超时时间 在高负载的情况下，你的Hyperledger Fabric链码可能不会在30s内完成。因此一个好的实践是根据需求定制链码执行超时值。在docker-compose文件中可以设置： CORE_CHAINCODE_EXECUTETIMEOUT=60s

8.避免从Fabric链码中访问外部资源 访问外部资源可能会暴露系统漏洞并给你的Hyperledger Fabric链码引入安全威胁。因此请尽可能的避免再Fabric链码中访问区块链外部的资源。

热点：智能合约