区块链性能测试设计方案分享
近期区块链的技术概念在传统 IT 圈逐渐升温，成为许多遗产系统升级重构方
案的备选技术路线。笔者本人多年从事应用系统研发，目前所维护的系统性能渐露瓶颈，
分片扩容难度较大且面临分布式改进的潜在需求，因而亟需区块链架构技术储备。
应用系统性能提升的关键在于运维端的接入管理模型（AAA，认证 AuthenticaTIon、授权
AuthorizaTIon、计费 AccounTIng）及业务端的并发（Concurrency）/吞吐量（Throughput）
模型。区块链是典型的“运维友好型”系统，天然的自我治理能力极大程度上优化了接入
管理模型，但现有区块链系统的并发/吞吐量模型指标却饱受诟病。无论是 BTC 的 7tps，
还是 ETH 的 40tps 在传统业务系统动辄万级甚至十万级 tps 面前都难以抬头。
本着不重复造轮子的宗旨，首先梳理了一下对区块链项目的需求：
根据需求有的放矢地寻觅区块链项目，寻觅的过程其实远比想象的简单。区块链项目多如
牛毛，但纯做技术框架不扯业务场景或者经济模型的项目真心不多。通过对主流交易所的
项目筛选（毕竟不能找一个不稳定的团队做的东西），基本圈定了 EOS、QTUM、AELF
项目。EOS 官宣吞吐量约 3300~3500tps，QTUM 官宣吞吐量为 BTC 的十倍（权且估算
100tps），AELF 项目 7 月伊始发布测试网，官方暂未发布吞吐量信息。选定AELF 作为调
研对象的原因一方面是开发指南新近发布，与最近代码版本的可操作性强，且 AELF 采用
的 Akka 并发框架应用范围较广，先前有所接触。
测试设计现有的区块链系统业务处理能力普遍面向价值传递进行建设，因此对于区块链系
统性能的评测思路应面向交易过程展开。AELF 项目在区块链架构方面主打的特征是“主
链+多级侧链”，链间有专门的跨链算法实现相对隔离的业务单元间资源的协同，链内节点
均运行于集群，节点内部通过并行化方案提升吞吐量指标。根据官方在社区披露的信息，
测试网初期（即目前）提供主链并行计算模块的测试验证，确认主链性能后再灰度升级至
资源评论
