失败类型：
- 背书策略失败。说的是不同背书节点读取的同一数据版本不同
- MVCC(Multi-Version Concurrency Control)读冲突。同一个交易，执行和验证的版本不一致
- 幻影读冲突：范围读取中，其中有键的增删改。本质是MVCC读冲突。
GitHub - fengfeng651/HyperLedgerLab: Hyperledger testbed
hyperladgerLab: Kubernetes集群上的Hyperledger测试平台：用于分析和测试的分布式企业区块链网络的自动部署
链码类型：EHR(Electronic Health Records电子健康档案）：个人信息 + 电子健康档案
DV（Digital Voting数字投票）：1000个选民，12个政党
SCM（Supply Chain Management 供应链管理）
DRM（Digital Rights Management数字版权管理）
链码生成器：输入链码函数的数量，每个函数中读，增，删，范围读的数量
工作负载生成器：输入交易数量，交易增删改查分布，键的读取分布（Zipfian
skew）
fabric++，streamchain，fabricsharp
实验结果
the best block size：the least percentage of failed transactions
intra-block MVCC read conflicts：Transaction failures caused due to a dependency among
transactions in the same block
除了区块大小，工作负载对交易延迟和成功率的影响，实验还考虑了数据库类型（levelDB，couchdb）,组织数量，背书策略，键的分布zipfian skew，read-heavy/write-heavy,增加网络延迟（模拟组织间的地理分布）
建议和可能研究方向
- 块大小随之交易的到达速率自适应调整。
- 构建一个组织节点少，背书签名少的网络
- rich queries and range queries减少，可以对couchdb做优化
- 减少背书执行时，不同节点间状态不一致的情况
- 链码优化
感受
文章工作量很大，考虑很细致。但没有给出在HyperLedgerLab上的实验代码(如果你们找到了可以发一份）