Blurring the Lines between Blockchains and Database Systems: the Case of Hyperledger Fabric

背景

分布式数据库与区块链的最大不同之处：
传统数据库要求可信节点，区块链技术支持拜占庭节点。

两种模型

order-execute

先通过共识算法排序，然后各节点本地再执行。代表有比特币、以太坊等。

该模型存在两点不足：

1. 无法并行执行

2. 每个节点都要执行

导致无法扩展、性能低。

而分布式数据库很多年前就解决了这些问题。

simulate-order-validata-commit

并行模拟、后验证。代表有Hyperledger Fabric.

支持了并发执行，但是Hyperledger Fabric实现的不够好：大量的transaction被abort，导致tps低。

优化

作者采用了两种并发控制的优化手段对Hyperledger Fabric进行优化：

• transaction recordering
• early transaction abort（需要细粒度并发的支持）

为什么采用了这两种并发控制优化措施？

1. 以区块的形式commit transactions，有些优化是针对单独的transactions
2. 区块链是分布式、replicate，传统数据库可能是单机、partition，
3. 区块链的transaction在多个节点模拟，节点状态可能不一致，而数据库状态一定一致
4. 区块链的性能瓶颈在加密签名、网络通信、信任验证。传统数据库的瓶颈在低级的组件，比如锁机制的使用。有的优化是针对低级的级别

并发控制技术分为两类：一是提高吞吐量的，二是将aborted transactions变为successful transactions的

作者经过分析只能采用第二种。

实现

transaction recordering

#1 强连通分量
#2 simple 环
#3 统计各点的环数
#4 去点，同时更新环数
#5 拓扑排序，逆序

early transaction abort

在模拟阶段或者排序阶段提前终止。

模拟阶段：

并行进行模拟和验证，模拟的时候读数据的时候要检查version，如果version大于last-version，说明在验证阶段数据被修改了，终止模拟，提前结束交易。

排序阶段：

如果同一个 block中的不同交易读取同一个数据的不同版本，那么说明两者模拟之间其他事务修改了数据，后者交易变为无效，不再对其进行排序，提前结束交易。