长安链ChainMaker 交易池交易防重优化

本文主要是介绍长安链ChainMaker 交易池交易防重优化，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

我们将用三篇文章阐述长安链在提升交易防重能力方面所做的工作，本篇为第一篇。

全部三篇主要包括以下内容：

1. 长安链交易池及防重交易优化；

2. 布谷鸟过滤器如何提升校验效率；

3. bigfilter全局交易防重组件的介绍与应用。

一、交易池简介

在区块链中，交易池负责接收、校验、转发和缓存节点收到的待处理交易，并在共识提案时为核心引擎模块提供一批有效的交易进行区块构造。总体来说，交易池具有如下功能：

1. 接收客户端发送过来的交易，并将有效的交易广播给其他的节点；

2. 对交易签名、时间戳等进行有效性检查以及交易是否存在“双花”的防重检查；

3. 缓存交易，并在共识提案时为核心引擎模块提供一批有效的交易。

二、长安链交易池

在长安链交易池内部有两个重要的结构用于缓存交易，一个是缓存通过交易有效性检查和防重检查的待打包交易队列Queue，另一个是缓存已经被打包进区块正在共识中的交易Pending。

接下来将以一笔交易在交易池内部的流转过程，介绍交易池的内部设计思路：

接收交易：对于交易池来说，交易来源共有三种类型。一是通过RPC接收到的客户端发送的交易，由于在RPC模块进行了交易有效性检查，此时交易池只会进行交易防重检查，并将通过检查的交易广播给其他节点；二是通过P2P模块收到的其他节点广播的交易，此时会进行交易有效性检查和交易防重检查；三是核心引擎Core模块在提交区块时会对同一高度的其他区块进行剪枝，被剪枝区块中的交易在进行有效性检查和防重检查后也会被重新放入交易池中。
构造区块：主节点的Core模块会从交易池Fetch一批交易用于构造新区块，此时交易池会将该批交易从待打包交易队列Queue移至已打包交易缓存Pending，防止在MaxBFT共识下交易被重复打包。
验证区块：从节点在验证区块时，Core模块会从交易池Get块中的交易。对于块中存在于本节点交易池中的交易，Core模块只需比对块中交易和交易池中交易哈希是否一致即可（因为交易池已经做了相关检查）；对于不在本节点交易池中的交易则需要进行交易有效性检查和防重检查。验证区块有效后，Core模块会通知交易池将块中交易从待打包交易队列Queue中移至缓存已打包交易的Pending中，此操作也是确保在MaxBFT共识下交易不会被重复打包。
提交区块：在共识完成并提交区块后，主从节点都会对同一高度的旁枝区块进行剪枝，将被剪枝区块中的交易重新放入待打包Queue队列中，并将提交的区块中的交易从交易池Pending和Queue中移除。

图1

三、交易防重机制优化

1. 交易防重方式

说到交易防重，大体可以分为两种方案，一种是账户模型下的交易防重机制，如Ethereum和Diem；另一种是非账户模型下的交易防重机制，如Fabric和ChainMaker。在账户模型下，基本都是通过账户下Nonce值严格依次递增的方式实现对交易的去重，对于非账户模型更多的是在交易体中引入TxId(或者交易的hash)，以TxId唯一标识一笔交易，通过比对TxId实现交易的去重，但不管是哪种方式在进行交易防重时都需要对交易的唯一标识符进行对比。

在长安链中进行交易防重检查的最终目的是确保一笔交易不会被重复打包，因此对加入到交易池中的交易，需要保证：

（1）交易不在数据库中，即 !IsExistInDB()；

（2）交易不在交易池中，既不在Queue中也不在Pending中，即!IsExistInPool()；

（3）交易不在正在共识的区块中，即!IsExistInConsensus()。

首先，需要明确的是在交易池的实现中，由于添加交易AddTx操作和Core模块从交易池Fetch、Get、Remove交易的操作存在并发，所以在各个TxQueue中都需要进行锁保护。所以对于验证交易在不在DB的防重检查，可以和验证交易在不在交易池的防重检查一起在锁内进行，也可以在锁外单独进行。

2. 锁内进行DB防重检查

如果交易防重的IsExistInDB()和IsExistInPool()操作以及AddTx在交易池锁内进行，那么该三个操作属于一个原子操作。如下图所示，假设当前数据库提交了高度为90的区块，正在共识91高度的区块，那么正在共识的区块中的交易是不会被打包进下一个区块的。

图2

对于主节点，因为高度为91的区块是其产生的，那么区块91中的交易一定在主节点的交易池的Pending中，此时在添加区块91中的交易时，是不会被添加进去。

对于从节点，其对正在共识的高度为91的区块可能有两个操作，一个是验证区块有效后，会将区块中的交易添加到交易池的Pending中，另一个操作是共识完成且区块提交落库后，会将区块91中的交易从交易池删除。那么区块91中的交易在上图的三个时机都是加不进交易池待打包交易Queue中，在第一个时机即使加进Queue中，也会被删移除到Pending，另外两个时机完全加不进Queue，因为分别验证交易在交易池或交易在DB。

但是，当数据库中数据量较大时，验证交易在不在DB是一个非常耗时的操作。那么，将IsExistInDB()的操作放在交易池锁内进行的话，不仅影响Core模块从交易池Fetch、Get、Remove交易的操作，也会使得向交易池中添加交易的效率变低，最终导致构造新区块时不能从交易池获取足量的交易。因必须在交易池主锁外进行IsExistInDB()操作。

3. 锁外进行DB防重检查

在锁外进行DB防重检查，那么IsExistInDB()、IsExistInPool()操作以及AddTx()三个操作不再属于一个原子操作，会带来两个问题：

问题一：正在共识中的交易可能被加入到TxQueue中，主节点在下一次产块时可能重复打包已经上链落库的交易。

图3

主节点不存在这个问题，原因同上分析。

对于从节点，交易池收到正在共识的高度为91区块中的交易时，先调用IsExistInDB()验证通过后，再验证交易在不在交易池IsExistInPool()，都验证通过后会AddTx到交易池。如果此时共识很快已经落库提交了，那么在最后一个时机区块91中的交易是有可能被添加进交易池的。后续该节点成为主节点时有可能会将已经落库的交易重复打包，这就造成了交易的“双花”。

先验证IsExistInPool()，后验证IsExistInDB()同样也会存在正在共识中的区块91中的交易被加入交易池，进而被重复二次打包的问题。

图4

所以，在交易池主锁外进行IsExistInDB()操作时，主节点Core模块在交易池中Fetch 一批交易时，交易池内部需要对F etchc出来的这一批交易进行“增量”DB防重校验，即验证交易在不在91区块中。而该“增量”DB防重只需要在存储模块的缓存中进行判断即可，不需要从全量DB中进行判断，耗时极短。

问题二：主节点作恶，Fetch交易时未进行“增量”DB防重时，从节点需要能够识别出区块中的“双花”交易。

如果主节点作恶，从交易池Fetch 一批交易后，未进行“增量”DB防重检查，将刚刚共识完的高度为91区块中的交易打包进高度为92的区块中。而在区块91共识轮次中，其他从节点的交易池中也是有可能拥有区块91中的交易，所以在区块92共识轮次中，在验证区块92中交易是否有效时，交易池会给Core模块返回该交易，此时Core模块发现本节点交易池中拥有该笔交易，则只会比对交易哈希是否一致，验证一致则认为该交易有效，这样主节点将作恶成功，一笔交易被重复打包进区块91和92。

所以，在Core模块从交易池Get块中交易时，交易池内部也需要对get到的交易进行“增量”DB防重，防止主节点作恶成功。

四、总结

交易池通过“增量”DB防重机制，将验证交易在不在DB的防重检查拆出交易池主锁，避免防重检查长时间占用交易池主锁。一方面提升了交易添加进交易池的效率，确保在出块间隔时间内交易池能够加入足量的交易用于构造新的区块；另一方面减少了防重检查对交易池主锁的占用，提升了Core模块从交易池Fetch、Get、Retry和Remove的操作性能，提升了一轮共识的整体效率。

此外，长安链研发团队也同时开发了相关过滤器组件，以满足不同场景下的交易防重需求。

RECOMMEND