问题描述
应遵循哪些最佳实践以避免错误并编写有效的Hyperledger Fabric Chaincode?
What should be some of the best practices to follow to avoid bugs and write efficient Hyperledger Fabric Chaincode?
推荐答案
编写Hyperledger Fabric链码的一般准则.
有关以下内容的详细说明，请参见以下链接:
Refer to the below link for a detailed description on the same:
https://gist.github.com/arnabkaycee/d4c10a7f5c01f349632b42b67cee46db
以下简要介绍了一些步骤:
Some steps are concisely mentioned below:
- 使用Chaincode DevMode
- 使用链式代码记录
- Use Chaincode DevMode
- Use Chaincode Logging
使用日志记录非常简单.使用Fabric的内置记录器. Fabric提供了以下日志记录机制:
Using logging is simple and easy. Use Fabric's inbuilt logger. Fabric provides logging mechanism as follows:
对于Golang : https://godoc.org/github.com/hyperledger/fabric/core/chaincode/shim#ChaincodeLogger
对于NodeJS : https://fabric-shim .github.io/Shim.html#.newLogger__anchor
对于Java :您可以使用任何标准的日志记录框架，例如Log4J
For Java: You can use any standard logging framework like Log4J
-
避免使用全局密钥-Hyperledger Fabric在提交事务时使用乐观锁模型.在两个阶段的认可和承诺，如果您在背书"中读取的某些密钥版本已更改，直到您的交易到达提交阶段，您将收到MVCC_READ_CONFLICT错误.当一个或多个并发事务正在更新同一密钥时，通常是这种可能性.
Avoid using Global Keys - Hyperledger Fabric uses an Optimistic Locking Model while committing transactions. In the two-stage process of endorsement & committment, if some versions of the keys that you had read in the Endorsement has changed till your transactions reach the committing stage, you get an MVCC_READ_CONFLICT error. This often is a probability when one or more concurrent transactions are updating the same key.
明智地使用Couch数据库查询
-
沙发数据库查询请勿更改事务的读取集-Mongo查询仅用于查询键值存储(也称为StateDB).它不会更改事务的读取集.这可能会导致事务中的幻像读取.
Couch DB Queries DO NOT alter the READ SET of a transaction -Mongo Queries are for querying the Key Value store aka StateDB only. It does not alter the read set of a transaction. This might lead to phantom reads in the transaction.
仅可搜索存储在沙发数据库中的数据-不要试图使用MangoQuery通过键的名称搜索键.尽管可以访问CouchDB的Fauxton控制台，但是不能通过查询存储在数据库中的密钥来访问密钥.示例:不允许通过 channelName \ 0000KeyName 查询.最好将密钥作为属性存储在数据本身中.
Only the DATA that you have stored in the couchDB is searchable - Do not be tempted to search for a key by its name using the MangoQuery. Although you can access the Fauxton console of the CouchDB, you cannot access a key by querying a key by which it is stored in the database. Example : Querying by channelName\0000KeyName is not allowed. It is better to store your key as a property in your data itself.
写确定性链代码-切勿编写非确定性链代码.这意味着，如果我在2个或更多不同的环境中在不同的时间执行链码，则结果应始终相同，例如将值设置为当前时间或设置随机数.例如:避免使用诸如调用rand.New(...)，t := time.Now()或什至依赖于未持久化到分类帐的全局变量(check)之类的语句.这是因为，如果生成的读写集不相同，验证系统链码可能会拒绝它并抛出ENDORSEMENT_POLICY_FAILURE.
Write Deterministic Chaincode - Never write chaincode that is not deterministic. It means that if I execute the chaincode in 2 or more different environments at different times, result should always be the same, like setting the value as the current time or setting a random number. For example: Avoid statements like calling rand.New(...) , t := time.Now() or even relying on a global variable (check ) that is not persisted to the ledger.This is because, that if the read write sets generated are not the same, the Validation System chaincode might reject it and throw an ENDORSEMENT_POLICY_FAILURE.
从您的链码中调用其他链码"时要小心.-当两个链码都在同一通道上时，可以从另一个链图中调用一个链码.但是请注意，如果它在另一个通道上，则只会得到chaincode函数返回的内容(仅当当前调用者有权访问该通道上的数据时).即使试图写入一些数据，也不会在其他通道中提交任何数据.当前，跨通道链码链码调用不会更改其他通道上的数据(更改写集).因此，每次事务一次只能写入一个通道.
Be cautions when calling Other Chaincodes from your chaincode. - Invoking a chaincode from another is okay when both chaincodes are on the same channel. But be aware that if it is on the other channel then you get only what the chaincode function returns (only if the current invoker has rights to access data on that channel). NO data will be committed in the other channel, even if it attempts to write some. Currently, cross channel chaincode chaincode invocation does not alter data (change writesets) on the other channel. So, it is only possible to write to one channel at a time per transaction.
记住要设置链码执行超时-通常，在高负载期间，您的链码可能无法在30秒内完成执行.最好根据需要自定义设置超时时间.这由对等方的core.yaml中的参数控制.您可以通过在docker compose文件中设置环境变量来覆盖它:示例:CORE_CHAINCODE_EXECUTETIMEOUT=60s
Remember to Set Chaincode Execution Timeout - Often it might so happen that during high load your chaincode might not complete its execution under 30s. It is a good practice to custom set your timeout as per your needs. This is goverened by the parameter in the core.yaml of the peer. You can override it by setting the environment variable in your docker compose file :Example: CORE_CHAINCODE_EXECUTETIMEOUT=60s
避免访问外部资源-访问外部资源(http)可能会对链码暴露漏洞和安全威胁.您不希望外部来源的恶意代码以任何方式影响您的链码逻辑.因此，请尽可能避免拨打外部电话.
Refrain from Accessing External Resources - Accessing external resources (http) might expose vulnerability and security threats to your chaincode. You do not want malicous code from external sources to influence your chaincode logic in any way. So keep away from external calls as much as possible.
这篇关于编写Hyperledger Fabric Chaincode时应遵循的最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！