IEEE TKDE’23: 面向图式区块链的高效连续型事务处理方法FLUID

在基于区块链的新型应用中，节点通过连续型事务来实现一整套应用逻辑。连续型事务处理需要按正确顺序执行，且提交取决于前一个事务确认的结果。然而，传统链式区块链存储模型存在确认延迟高等问题，无法高效支持连续型事务处理。基于有向无环图（Directed Acyclic Graph，DAG）存储模型的图式区块链成为了一个备受关注的解决方案，其并行拓扑结构能显著降低事务的确认延迟，具有支持高效连续型事务处理的潜力。然而，图式区块链仍面临无序的事务执行和存储以及弱事务一致性的问题。为此，提出了首个面向图式区块链的高效连续型事务处理方法FLUID。FLUID的核心创新点包括：1）首次在区块链系统中正式阐明连续型事务的定义，并深入分析了连续型事务处理与区块链存储模型的紧密耦合关系，得出制约区块链技术推广应用的另一种瓶颈；2）设计了一个面向图式区块链的高效可靠连续型事务处理方法FLUID，在DAG账本中引入依赖性跟踪结构并接入部分链式区块链系统能力，使得连续型事务处理在具备低延迟特性的同时，以正确的顺序被提交、执行和存储。

该成果“FLUID: Towards Efficient Continuous Transaction Processing in DAG-based Blockchains”发表在IEEE Transactions on Knowledge and Data Engineering (TKDE) ，属于中国计算机学会CCF A类期刊，是计算机数据工程领域最权威的国际学术期刊之一，每月出版一期，影响因子为8.9，主要关注计算机科学、人工智能、电子工程、计算机工程等领域在知识与数据工程方向的研究。

论文链接：https://ieeexplore.ieee.org/abstract/document/10114601

研究背景与动机

传统的链式区块链中事务以区块为单位进行提交和处理，出块的高延迟导致其在连续型事务处理中存在延迟过高的性能瓶颈。最近的研究从链式区块链存储模型转向图式区块链存储模型，图式区块链显著减少了事务确认的延迟。具体来说，图式区块链中的事务可以直接追加到账本中，而不需要打包成区块，这比链式区块链在支持高效事务处理方面显示出更大的前景。

然而，目前图式区块链在连续型事务处理方面面临几个关键的挑战：1）如何实现连续型事务的顺序和交互属性？在图式区块链中，事务没有全序关系，它们被随机地附加到区块链上；2）如何实现原子属性？即要求系统有一个唯一确定的中间状态记录。中间状态指的是该状态下的事务执行不会改变账本状态，在弱一致性环境下，会导致潜在冲突的事务被提交；3）如何保证账本数据的最终确定性以确保节点之间的一致性？图式区块链低延迟的代价是牺牲一定的事务一致性。为此，我们需要一种面向图式区块链的高效连续型事务处理方法。

核心贡献

我们第一个正式定义和描述了区块链系统中的连续型事务，区别于一般区块链事务，连续型事务是由节点交互提交的多个有明确依赖关系的事务。
我们设计了一种基于依赖跟踪结构的新型图式区块链账本结构，使得连续型事务处理在具备低延迟特性的同时，以正确的顺序被提交、执行和存储。同时，提出了一种解决潜在冲突的冲突解决机制，并设计了一种基于检查点的一致性验证机制，以保证各节点的数据一致性。
我们实现并评估了FLUID，与目前最先进的图式区块链OHIE进行了连续型事务处理性能对比，实验结果表明了FLUID在连续型事务处理方面的可行性和高效性。

设计与实现

为了应对前文中的挑战，我们设计了面向图式区块链的高效连续型事务处理方法FLUID，其主要包含三部分核心设计：1）基于依赖跟踪结构的新型图式区块链账本结构，允许复杂应用中的连续型事务根据依赖性进行交互式的顺序处理，同时，基于事务依赖跟踪结构，中间状态的事务不需要被系统直接确认，避免了过早提交潜在冲突的事务；2）基于可信共识组的冲突事务解决机制，FLUID能够基于可信共识组进行事务提交监听，并在事务提交前丢弃冲突的事务；3）基于检查点的连续型事务一致性验证方法，FLUID能够对账本数据进行确定性共识，从而避免由事务数据不一致导致的潜在连续型事务冲突。

图1 数据交易场景中的连续型事务

我们基于一个数据交易场景中的连续事务处理过程来介绍FLUID的设计，图1展示了这个数据交易过程，其中TX1~TX3是由买方和卖方交互提交的连续型事务。在买方确认交易前，用户余额并不发生改变，这意味着，在TX3被执行之前，TX1和TX2都是中间状态事务。

图2 基于依赖跟踪结构的图式区块链账本结构

图2展示了基于依赖跟踪结构的新型图式区块链账本结构，其顶点由一次应用逻辑处理中全部的连续型事务组成，其中连续型事务被依赖跟踪信息强制连接在一起。它是一个逻辑层面的顶点，可能包含多个事务，区别于现有图式区块链中的单一事务，如上述数据交易过程中的TX1~TX3。FLUID中有两种类型的边，一种是连接连续型事务的边。另一种是连接DAG账本顶点的边。连续型事务的边是确定的，它们代表连续型事务之间的依赖关系。DAG账本顶点之间的边是由节点在提交新的事务时，随机选择两个顶点来验证批准时产生的。该结构确保了连续型事务按照依赖顺序提交和执行，同时延迟了中间状态事务在账本中的最终确认时机，避免了事务冲突的发生。

图3 基于可信共识组的冲突事务解决过程

依赖跟踪结构解决了交互处理过程中潜在的中间状态冲突，因为它避免了对中间状态的事务的立即验证。然而，仍然有可能在事务的初始提交阶段发生冲突，从而破坏连续型事务的原子性，如一个余额为10的用户提交了两个开销为10的购买请求。

为此，我们设计了一种基于可信共识组的冲突事务解决机制，利用部分链式区块链系统能力选取部分可信矿工节点在事务提交阶段进行交易监听并解决潜在事务冲突。图3展示了该过程，其中NV1~NVm是基于链式区块链系统中的DPoS算法经过投票选举得到的轮换矿工组。由发起的事务不会立即广播到网络，而是被可信共识组监听，验证新发起事务的有效性，并提交有效的事务。

图4 基于检查点机制的事务一致性验证过程

在保证了连续型事务处理能力之后，我们还需要解决图式区块链系统弱数据一致性的问题。我们设计了一种校验和机制来提取某一时刻DAG账本的事务信息，并利用链式区块链系统的确定性共识能力对其进行一致性校验。每个DAG顶点都有一个唯一的校验和信息，该校验和包含了该顶点及其前序路径上的信息，节点基于校验和可以快速地校验两份DAG账本数据在某个顶点及其前序路径上的数据是否一致。图4展示了基于检查点机制的事务一致性验证过程，我们使矿工以固定的频率进行系统范围的数据一致性验证，矿工将收集当前未被连接的DAG顶点的校验和，将他们打包成检查点提交到可信矿工组的节点上进行PBFT共识，矿工节点将基于本地校验和与检查点中的校验和信息来验证历史数据的一致性。

性能评估

我们将FLUID与链式区块链EOS（基于PBFT和DPOS的公链系统）和主流的图式区块链OHIE进行了全面的对比。评测根据随机产生的交易请求和响应来模拟节点之间的交易。工作负载的大小为10K交易量，请求字段的平均大小为457B，响应字段的平均大小为680B。评测中根据脚本参数不间断地向系统的网络接口提交数据交易请求，为了使测试条件标准化，测评过程利用相同的工作负载来测试两个基线系统。评测使用一个简单的数据交互过程来模拟数据交易流程：买方向系统提交交易请求，卖方根据交易请求返回签名后的数据包，最后由买方确认交易。

图5 整体性能表现

我们首先针对FLUID和基线系统在连续型事务处理过程中的整体性能表现进行了评估，图5展示了FLUID和基线系统在处理连续型事务时的系统吞吐量和延迟。与基线系统相比，FLUID能够实现超过1.5倍的吞吐量改进和降低两个数量级的延迟。这是因为FLUID避免了区块的打包开销。然而，FLUID的一些关键设计也不可避免地造成了一些性能上的妥协。

图6 连续型事务提交延迟

我们测量了FLUID和基线系统在处理不同交易量的连续型事务时的提交延迟表现。在基线系统EOS中，如6所示，当每秒提交1000个交易时，EOS的连续型事务提交延迟超过5s，是OHIE的1.7倍，是FLUID的7倍。

图7 依赖跟踪结构和冲突解决机制对性能的影响

进一步的，我们评估了依赖跟踪结构和基于可信共识组的冲突事务解决机制对系统吞吐量的影响。对于相同的数据量，FLUID的吞吐量几乎等于只禁用依赖跟踪结构的系统。这表明依赖跟踪结构的引入并没有对系统的吞吐量产生重大影响。这是因为依赖跟踪结构并没有改变DAG区块链系统的基本交易处理，而只是对交易之间的关系施加了限制。此外，可以看出，与FLUID相比，没有基于可信共识组的冲突解决机制的系统有1.8倍的吞吐量提升。基于可信共识组的冲突解决机制限制了吞吐量的表现。这是因为交易在提交时需要由一个可信的共识组进行验证。尽管验证单个交易的开销很小，但随着交易量的增加，由于拥堵导致的整体性能下降是不可避免的。

总结而言，实验结果表明FLUID相较于目前最先进的图式区块链系统OHIE能获得约66%的连续型事务处理吞吐量的提升，并且可以降低延迟两个数量级。

Leave a Reply Cancel Reply