The future is already here it's just not evenly distributed。

Fabric的区块结构是高度层级化得，每一个层级都是单独序列化和反序列化的，这将占用大量的内存。 committer接收到block数据之后，fabric并没不会缓存解析的block数据，因此之后当我们再次需要这些数据的时候，我们就需要重复这部分工作。 这部分修改比较简单，就是保存解析之后的block数据，这样下次在需要这部分数据的时候，如果已经解析了，我们就可以直接使用，而不需要再次解析。 测试结果： 性能提升6%左右； ...

fabric中交易管理器txmgr/lockbasedtxmgr/是基于锁的交易管理器，当交易比较多的时候，会导致锁的竞争；交易在模拟的过程中，NewTxSimulator或者NewQueryExecutor都会首先会获取一个读锁；如果说我们的交易时间都比较长，那么在交易模拟频率较高的情况下，势必会影响committer阶段写锁的获取； 锁的存在就是为了保证状态的一致性；lockbasedtxmgr是一种实现方式，它通过锁保证了readset中每一个键的版本和状态数据库中键的版本保持一致； 我们都知道，

当peer节点从orderer或者peer节点接收到block之后，主要有两个验证的步骤， 1、验证交易的格式，签名、背书策略等，txid是否重复，结果会存储到blockmetadata中； 2、MVCC交易，block存储，block/tx indexes 存储等；这一步中会再次检测txid是否重复，但是这次是从leveldb中查询； 步骤二中，检测txid是否重复的时候，存在重复操作，而且从leveldb中查询会导致效率低下，当一个block中有1000笔交易时，这就意味着需要访问leveldb1

这个确实会有性能的提升，根据测试大概会有接近20%的提升；不过不是所有的leveldb都可以替换，其中状态数据库、历史数据库、idstore都可以替换，因为他们都可以从账本中恢复；私有数据库不能替换，因为leveldb就是为了持久化账本； 这也说明了存储的IO是fabric性能优化可以深入的一个点； 由于mvcc冲突的时候，不会写入历史数据库，所以做测试的时候，需要注意一下链码是否能够覆盖自己的代码； ...

fabric的交易处理过程大致可以分为三个过程， 1、背书，交易的模拟执行，生成读写集； 2、排序，对交易的顺序达成共识，生成区块； 3、验证存储，验证区块，存储到账本； 今天讨论一些读写集和MVCC这种方式优缺点，首先看一下优点， 1、由于背书阶段分散到不同peer节点，所以该阶段可以并行进行，这意味交易读写集生成的效率也是大幅度提升了； 2、交易的模拟执行，生成读写集，可以说为后续的验证阶...

区块链的性能一直都是大家诟病的一个点，本文为作者在做fabirc性能优化时的一些经验总结，希望能对读者有一些帮助。 1、使用hashtable代替fabric中的leveldb 这个确实会有性能的提升，根据测试大概会有接近20%的提升；不过不是所有的leveldb都可以替换，其中状态数据库、历史数据库、idstore都可以替换，因为他们都可以从账本中恢复；私有数据库不能替换，因为leveldb就是为了持久化账本； 这也说明了存储的IO是fabric性能优化可以深入的...

最近在做可信区块链测试时，想起来了之前一个一直没有解决的问题，正好趁着这个时间，做了一下解决方案；主要的问题时，我们在做BaaS的时候，用户的私钥一直没有找到比较好的存储方式，最近根据以太坊的钱包和私钥管理的方案，总结了一个fabric的私钥管理方案； 方案一：keystore 我将用户从ca申请的私钥，放入keystore中，然后将keystore保存到...