PBFT性能到底如何

1. PBFT https://github.com/yeasy/blockchain_guide/blob/master/evaluation/hyperledger.md

Hyperledger Fabric v0.6 - PBFT 性能评测

环境配置

类型 操作系统 内核版本 CPU(GHz) 内存(GB)
物理机 Ubuntu 14.04.1 3.16.0-71-generic 4x2.0 8

每个集群启动后等待 10s 以上,待状态稳定。

仅测试单客户端、单服务端的连接性能情况。

评测指标

一般评测系统性能指标包括吞吐量(throughput)和延迟(latency)。对于区块链平台系统来说,实际交易延迟包括客户端到系统延迟(往往经过互联网),再加上系统处理反馈延迟(跟不同 consensus 算法关系很大,跟集群之间互联系统关系也很大)。

本次测试仅给出大家最为关注的交易吞吐量(tps)。

query 交易

pbft:classic
clients VP Nodes iteration tps
1 4 2000 193.05
pbft:batch
clients VP Nodes batch size iteration tps
1 4 2 2000 193.99
1 4 4 2000 192.49
1 4 8 2000 192.68

invoke 交易

pbft:classic
clients VP Nodes iteration tps
1 4 2000 141.34
pbft:batch
clients VP Nodes batch size iteration tps
1 4 2 2000 214.36
1 4 4 2000 227.53
1 4 8 2000 237.81

PBFT结论

PBFT单客户端连接情况下,TPS 基本在 190 ~ 300 范围内。

============================================

2.tendermint https://www.inf.usi.ch/faculty/pedone/Paper/2021/srds2021a.pdf

我们使用 Tendermint 版本 0.33.8 和 Go 版本 1.15,使用默认配置。 内存池最多可存储5000笔交易,最大字节大小为1GB,块大小为20MB。 这些默认限制足以应付未完成交易的最大数量。两个都连接的最大发送和接收速率为 5000 KB/s,控制gossip通信的时间间隔是 100 毫秒。
我们在地理分布式环境中进行了实验,验证器节点均匀分布在各大洲的 16 个 AWS 区域中。另一个 AWS 实例托管 1 个以种子模式运行的非验证器节点和所有客户端。
我们将所有客户端托管在单个 AWS 服务器中,以将所有测量集中在一个位置。客户端在闭环中均匀地向验证器提交 1KB 交易。

图中比较了 Tendermint 在 16、32、64 和 128 个验证者规模下的性能。 我们并不期望通过增加验证器的数量来提高性能,因为消息复杂性和共识成本随着进程数量的增加而增加。 本次比较中使用了 128 个验证器的参考工作负载,在实验中的验证器之间均匀分配 1536 个客户端。 采用了第 VII-B 节中考虑的相同实验设置。图中,在相同的工作负载下,当我们将验证器数量增加一倍时,吞吐量会适度下降。

Tendermint结论

Tendermint 的 TPS 基本在 400 ~ 600 范围内。交易延时在2~4秒。

根据以上性能数据,可以在设计区块链系统时,预先分析得出系统综合来看,性能瓶颈到底在哪里。如,某些外部的SaaS服务,性能可能会低于上述区块链指标,从而拖累系统的整体性能。