失败类型：

• 背书策略失败。说的是不同背书节点读取的同一数据版本不同
• 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,增加网络延迟（模拟组织间的地理分布）

 建议和可能研究方向

1. 块大小随之交易的到达速率自适应调整。
2. 构建一个组织节点少，背书签名少的网络
3. rich queries and range queries减少，可以对couchdb做优化
4. 减少背书执行时，不同节点间状态不一致的情况
5. 链码优化

感受

文章工作量很大，考虑很细致。但没有给出在HyperLedgerLab上的实验代码(如果你们找到了可以发一份）