paper: FastFabric: Scaling Hyperledger Fabric to 20,000Transactions per Second
这篇论文对Fabric的设计做了一些优化，将TPS从3,000提高到了20,000。
目前区块链技术存在的问题：
- 吞吐量上不去（throughput）
- 扩展性不好（scalability）
- 延迟较高（latency）
本篇论文基于Fabric对第一个问题做了优化。
Intro
公有链（permissionless blockchains）依赖于PoW/PoS、或者BFT等共识算法，极大的限制了其吞吐量。
而联盟链（permissioned blockchains）降低了对共识算法的依赖，但共识算法仍然是系统的瓶颈。
目前很多的研究都在改进共识算法，本文的作者们选择了超级账本进行了架构级别的优化，将其吞吐量提高了7倍，同时降低了延迟。
核心贡献在于：
- 将元数据分离出来：共识层只需要TX的id就可以决定TX的顺序
- 并行&缓存：重新设计了fabric的validation模块
- 将存放world state的数据库换成了内存哈希表
- 将committer与endorser分离到不同的硬件
所有的优化都没有修改fabric的API，没有改变fabric的模块化设计。
Fabric架构
作者的工作是基于Fabric v1.2，这部分不再介绍。
设计
For these reasons, the goal of our work is not to improve orderer performance using better BFT consensus algorithms, but to mitigate new issues that arise when the consensus is no longer the bottleneck.
Orderer
| 序号 | Fabric v1.2 | 改进 |
|---|---|---|
| Opt1 | 将整个tx发送给Kafka集群进行排序 | 只发送txID给Kafka集训进行排序，减低communication overhead |
| Opt2 | orderer顺序的对收到的tx进行验证后再发往Kafka集训 | orderer对收到的每个tx都创建一个线程，并行验证后发往Kafka |
Peer
| 序号 | Fabric v1.2 | 改进 |
|---|---|---|
| Opt3 | world state存放在数据库中（LevelD/CouchDB） | world state存放到内存中（hashing table），加快MVCC时对world state的访问速度 |
| Opt4 | 将账本存储在每一个peer上 | 将账本存储到单独的cluster中，每台server存一部分（不过试验中只使用了一台server） |
| Opt5 | 每个peer都需要对block做validation，endorser压力很大 | 分离endorset和committer，committer验证完block后直接发给endorser，endorser不再需要单独做validation |
| Opt6 | block validation顺序进行，慢 | 每一个block从pool中取一个go-routine，并行验证 |
| Opt7 | unmarshaling & marshaling | 增加缓存？避免gRPCmarshaling导致的频繁的内存分配/回收 |
实验结果
-
测量了包含不同tx数量的block gRPC的TPS
-
测量了orderer的TPS，分别是原版、加上Opt1优化、再加上Opt2优化。
-
测量了peer的latency和TPS
-
并发线程的数量对TPS的影响
-
block中的tx数量对TPS的影响
-
e2e TPS