高性能联盟区块链技术研究（论文学习）

1. 文章创新点

文章地址：PDF下载

① 业务逻辑与共识分离的架构

• 典型的联盟链系统的工作流程：

1. client将签名后的交易发送给联盟链节点，由HTTP服务器校验签名和证书等信息。
2. 校验通过后的交易，原子广播给共识模块。共识模块完成交易的排序后，将打包好的block传递给执行模块。
3. 执行模块进行签名验证，并调用虚拟机模块执行block中的交易。
4. 交易执行结束后，交易结果会先在执行模块中缓存，只有当交易结果的hash经过公示模块的共识以后，才会最终写入账本。

1. madledger中通过Collector对peer的执行结果进行收集，目前采用的是大多数策略。即超过一半的peer由相同的执行结果，则client认为交易已成功打包上链。

艺华的回复：
a. peer账本在非拜占庭场景下是都一致的，但是在拜占庭场景下是不能保证的，只能保证善意的节点状态一致。
b. 在raft场景下，client收集到一个peer的执行结果即可；在bft场景下，client需要收集到$2/3n+1$的执行结果。
c. 目前的madledger需要给用户提供一个设置这个阈值的配置属性（带默认值），由用户自己去配置。

• 优化后的系统架构： 将交易的执行和共识进行了解耦，将交易执行的任务交给了外部业务系统去完成，而非采用智能合约的形式。
  
• 为什么要进行这样的优化？

1. 生成一个区块的流程包括：区块打包、区块共识和执行、区块提交。注意： 先打包再共识，其实跟raft中一样，leader按照自己收到交易的先后顺序将其打包，将一个block作为一个entry广播给follower发起共识。在整个共识过程中，entry就是一串byte数据，无需关心具体内容，只要对这串数据进行共识即可。
   
2. 区块中的交易是按序执行的，大大增加了区块生成所用的时间，是整个系统的性能瓶颈。
3. 证券系统中的证券撮合业务非常复杂，很难通过智能合约去实现。
4. 智能合约每处理一笔交易都需要重新加载合约，处理的效率低，无法满足证券交易所需的吞吐量。

• 业务逻辑和共识分离架构的优点：

1. 简化了共识流程，提高了共识速度。
2. 大大提高了执行模块的可扩展性，可以根据需要选择使用内嵌的虚拟机，或者使用网络通信对接企业原有的业务系统。
3. 执行模块的拔插，不仅减低了开发成本，还有利于交易的并行执行，使得交易执行速度可以满足实际生产中高频交易处理需求。

② 存储优化

• 优化前，Hyperchain需要存储的3部分内容：

1. 区块信息： 包含了区块上链所需的所有内容，使用LevelDB进行存储。
2. 单笔交易信息和交易回执： 交易hash作为key，交易内容作为value，存储单笔交易信息；交易hash + 特定前缀作为key，交易内容作为value，存储交易回执。

使用独立的数据库（LevelDB）存储以上信息，以空间换取时间，一次数据库读取操作就可以完成交易信息和交易回执的查询。

3. 账户数据： 和以太坊一样，智能合约采用账户模型组织数据。

• 存储优化：

1. 采用业务逻辑和共识分离的策略，使用外部业务系统执行交易后，交易流水和账户信息都会存储于上交所的数据库中。

1. 用户交易流水和账户信息的查询，默认访问上交所数据库。
2. 如果用户指定从Hyperchain中查询，先尝试从内存中读取订单信息；如果需要查询历史订单信息，从区块中解析出订单信息返回给用户。

上交所业务系统的TPS为15万，深交所为30万左右。在高频业务场景下，I/O可能会成为Hyperchain的性能瓶颈。
交易执行和存储任务的转移，缓解了Hyperchain的数据库读写压力。

2. 机构查账和审计是低频率时间，且演示要求低，可以将原有的区块存储方式，从LevelDB存储改为文件存储。

1. 以一定的形式组织区块，存储在特定后缀的文件中，每个文件存储固定数据的区块。
2. 文件写入完成或，文件头部预留处将添加区块索引。
3. 存取区块的时间复杂度为$O(1)$，磁盘I/O多为顺序写，可以提高I/O效率。
交易执行和存储任务的转移，缓解了Hyperchain的数据库读写压力。

③ 数字签名验证优化

• 优化点1： 多订单打包验签

1. 证券交易中包含OPS（order per second）的概念，订单和交易并不是一一对应的，一笔交易可能包含多笔订单。
2. 将多笔订单打包成一个整体进行统一的签名，随后由服务器进行统一验签。
3. 打包后的订单被当成一笔交易，但在进行交易验证时，需要对其进行反序列化，按订单打包顺序依次执行每笔订单。
   

• 优化点2： 基于GPU加速的椭圆曲线验签算法

1. 使用Tesla M40加速卡来加速SM2算法（椭圆曲线公钥密码算法，国密的一种）的签名验证。
2. 为了达并行系统的最佳性能，程序并行度应该大于等于并行系统的物理并行线程数（Tesla M40为3072）。
3. 经过数学变换后，签名操作的并行度为6，签名验证操作的并行度为12。
   $$BlockSize签名=3072/6=512$$
   $$BlockSize签名验证=3072/12=256$$
4. 通过提升有限域运算性能、以并行方式实现椭圆曲线标量乘法运算，实现了基于硬件加速的椭圆曲线加密算法。

2. 实验结果分析

内容	比较点	结论
业务逻辑与共识分离 VS 传统架构	不同系统运行时间下的TPS 和 Latency	分离架构使得TPS提升，延迟降低
存储优化前 VS 存储优化后	不同系统运行时间下的TPS 和 Latency	存储优化使得TPS提升，延迟降低
多订单打包验签	不同batch size下的TPS 、OPS 和 Latency	多订单打包使得TPS逐渐下降，延迟逐渐增加。原因： 一是因为网络带宽压力增加，转发时间变长；二是因为处理的订单数增加，反序列化更加缓慢。OPS增加，是因为打包验签降低了验签次数。
GPU验签 VS CPU验签	不同batch size下的TPS 和 Latency	GPU验签始的TPS和延迟始终优于CPU验签
节点数量	不同节点数量下的TPS 和 Latency	随着节点数量的增加，系统性能先升高后后略有下降。原因： 节点数在一定范围内，系统带宽还未成为瓶颈；节点数过多后，系统带宽逐渐成为性能瓶颈。
Batch Time	不同Batch time下的TPS 和 Latency	Batch time对系统的TPS和延迟没有显著影响
Batch Size	不同Batch size下的TPS 和 Latency	TPS随着Batch size的增大先逐渐增大再逐渐减小，而延迟却一直在增大。原因： 区块大小对网络带宽的压力，更多交易给系统带来的共识、执行等的压力。
网络延迟	不同网络延迟下的TPS 和 Latency	网络延迟提升，TPS略有下降，系统延迟几句增加；大于500ms后，共识无法达成，使得系统无法正常运行。
网络带宽	不同网络带宽下的TPS 和 Latency	网络带宽是限制联盟链吞吐量、造成系统延迟最主要的因素之一。