一种账户体系下的联盟链交易的重放攻击防范方法

技术领域

本申请涉及区块链技术领域，尤其涉及一种账户体系下的联盟链交易的重放攻击防范方 法。

背景技术

区块链作为一种分布式的公共记账系统，具有防重放攻击能力是系统记账正确性的重要 保证。在目前的区块链产品中，包括公链以及联盟链，都采取了防重放攻击的一些措施防范 交易的重放攻击。交易的重放攻击是一个很严重的问题，最直观的后果是会导致转账交易的 付款方在未同意的情况下重复支出其账户中的余额。对于存在转账交易以外的其他操作类型 的区块链产品，比如以太坊，如果反复调用其合约账户中的代码，将会导致系统状态的异常， 对于Hyperledger fabric(开源区块链分布式账本)，则可能会使验证实体重复做链上编码 的唤醒操作，消耗其计算资源，影响系统的数据吞吐量。

为了实现防重放攻击的功能，现有技术中，提供多种解决方案，例如，记录历史交易的 哈希值作为解决方案，在该解决方案中，系统每执行一笔交易，都会在系统中记录该交易的 哈希值，通过在验证节点维护一个已经执行过的全部历史交易哈希记录，当区块中的节点收 到一笔新交易的时候，将该交易发送至验证节点进行验证，验证节点将其与本地存储的历史 交易哈希记录进行比对，并将验证结果发送回该节点。这种解决方案的思路比较直观，容易 理解和实现。但是，随着交易规模的增大，占用本地的存储空间将急剧增大，而且查询的过 程中也需要花费大量的时间，从而会显著影响网络的数据吞吐量，不能适用于大型的以及对 交易处理吞吐量较高的场景。

又例如，通过将系统设计为天然具有防重放攻击能力的系统，作为防重放攻击的解决方 案，比如在基于UTXO的账户体系模型的虚拟货币交易过程中，由于每一笔交易的输入均关联 到上一笔交易的未花费输出(UTXO)，从而天然具有防重放攻击能力。但是，这种虚拟货币交 易的天然防重放能力依赖于其发币权，以及以此为基础的货币拥有权的转移，随着交易的进 行，UTXO也形成了链式的结构，从而可以进行溯源来查看每笔UTXO的来源。显然这种方式 不适用于推广到通用的联盟链产品中。且另一个客观存在的问题是，如果通过溯源的方式来 验证一笔UTXO是否有效，在该UTXO链比较长的情况下会耗费大量是时间，当下的解决方式 是在节点同步的过程中，在本地维护一个可用的UTXO池，当验证一笔交易的输入是否有效的 时候，可以直接在该UTXO池中做查询，属于以空间换时间的做法，会消耗本地较多的存储资 源。

又例如，通过构建严格的交易序列，作为防重放攻击的解决方案，比如，以太坊在每笔 交易中加入变量AccountNonce(账户随机数),并在客户端有一个Nonce(随机数)变量， 用于记录账户目前已经发送的所有交易，当一笔交易被验证是否有效的时候，通过比对交易 的AccountNonce与客户端的Nonce是否一致，如果一致，交易才会被处理，随后客户端的 Nonce自增1，当有重复交易过来的时候，就会被判定为无效。通过这种方式以太坊实现了防 重放攻击能力。这种解决方案，通过在账户下构建严格的交易序列，并在客户端设置一个类 似于计数器的组件来串行处理账户下的交易，导致交易必须严格按照顺序执行，且容错性较 低，如果中间存在一个交易执行失败，那么客户端的Nonce将不再增加，导致该交易之后的 所有交易由于AccountNonce均大于客户端Nonce而全部不能被系统接收。

发明内容

为了提高分布式的公共记账系统的防重放攻击能力，本申请提供一种一种账户体系下的 联盟链交易的重放攻击防范方法。

本申请提供的一种账户体系下的联盟链交易的重放攻击防范方法，包括：

获取客户端发送的交易请求；

获取所述交易请求的客户端时间，若所述客户端时间早于第一参照时间点T1，则拒绝所 述交易请求；

判断所述客户端时间是否早于或等于第二参照时间点T2，若所述客户端时间早于或等于 第二参照时间点T2，则将所述交易请求对应的交易与交易缓存池P内的全部交易进行对比；

若交易缓存池P内存在所述交易请求对应的交易，则拒绝所述交易请求；若交易缓存池 P内不存在所述交易请求对应的交易，则将所述交易请求对应的交易打包至当前区块内，并 将所述交易请求对应的交易缓存至交易缓存池P。

可选的，在所述获取所述交易请求的客户端时间的步骤之后，还包括：

若所述客户端时间晚于或等于第一参照时间点T1，则判断所述交易请求对应的交易签名 正确，若所述交易请求对应的交易签名正确，则将所述交易请求对应的交易放入到交易池中； 若所述交易请求对应的交易签名不正确，则拒绝所述交易请求。

可选的，所述判断所述客户端时间是否早于或等于第二参照时间点T2的步骤中，还包括：

若所述客户端时间晚于第二参照时间点T2，则将所述客户端时间对应的交易请求继续保 留在交易池中；

当所述客户端时间早于或等于更新后的第二参照时间点T2，则判断所述客户端时间是否 晚于或等于更新后的第一参照时间点T1，若所述客户端时间晚于或等于更新后的第一参照时 间点T1，则将相应的交易请求对应的交易与交易缓存池P内的全部交易进行对比。

可选的，以当前区块的高度m向前取n个区块，选取第m-n个区块的构建时间作为第一 参照时间点T1。

可选的，所述一种账户体系下的联盟链交易的重放攻击防范方法还包括：

获取所述交易缓存池P内的全部交易请求对应的区块打包时间，并将区块打包时间早于 或等于第一参照时间点T1的交易请求，从所述交易缓存池P中剔除。

可选的，所述将所述交易请求打包至当前区块内的步骤中，还包括：

获取上一区块的打包时间，如果所述上一区块的打包时间小于或等于当前区块打包节点 的本地时间，则将当前区块的打包时间设置为当前区块打包节点的本地时间；

如果所述上一区块的打包时间大于当前区块打包节点的本地时间，则计算当前区块前K 个区块的平均出块时间Δk，在上一区块的打包时间上延迟平均出块时间Δk，作为当前区块 的打包时间。

可选的，所述计算当前区块前K个区块的平均出块时间Δk的步骤，具体为：

获取当前区块前K个区块对应的K个出块时间，判断K个区块中任意连续两个区块之间 的出块间隔时间是否大于默认出块时间间隔；

若某一连续两个区块之间的间隔时间大于默认出块时间间隔，则用默认出块时间间隔替 换所述某一连续两个区块之间的间隔时间，并用替换后的出块间隔时间计算所述K个区块的 平均出块时间Δk。

可选的，包括：

定期校准各节点之间的时钟，保持各节点之间的时钟同步；

在所述将所述交易请求打包至当前区块内的步骤之后，还包括：

副本节点接收到当前区块打包节点产生的当前区块后，将当前区块的构建时间与副本节 点的本地时间进行比较，若当前区块的构建件时间与副本节点的本地时间的间隔大于第一预 设阈值，则副本节点不对当前区块投票。

可选的，所述一种账户体系下的联盟链交易的重放攻击防范方法还包括：

在节点宕机之后，获取节点当前已确认区块，从当前已确认区块向前查找n个区块，并 将n个区块对应的交易请求缓存至交易缓存池P。

可选的，在所述获取所述交易请求的客户端时间的步骤之后，还包括：

将所述交易请求的客户端时间与节点本地时间进行比较，若所述交易请求的客户端时间 与节点本地时间之间的间隔大于第二预设时间，则拒收所述交易请求。

可选的，所述将所述交易请求打包至区块内的步骤中，所述区块的构建时间严格递增。

由以上技术方案可知，本申请实施例提供的一种账户体系下的联盟链交易的重放攻击防 范方法，包括：获取客户端发送的交易请求；获取所述交易请求的客户端时间，若所述客户 端时间早于第一参照时间点T1，则拒绝所述交易请求；判断所述客户端时间是否早于或等于 第二参照时间点T2，若所述客户端时间早于或等于第二参照时间点T2，则将所述交易请求对 应的交易与交易缓存池P内的全部交易进行对比；若交易缓存池P内存在所述交易请求对应 的交易，则拒绝所述交易请求；若交易缓存池P内不存在所述交易请求对应的交易，则将所 述交易请求对应的交易打包至当前区块内，并将所述交易请求对应的交易缓存至交易缓存池 P。

在实际应用过程中，通过滑动时间窗的设计，只需要记录在第一参照时间点T1之后所有 打包过的交易，在时间窗比较短的情况下，可以将交易记录缓存在内存中，时间窗比较长的 情况下，可以考虑将交易记录存储在数据库中。由于存储的交易规模小，在时间窗不是特别 长的情况下，还可以将该部分交易放在缓存中，所以交易的判重速度极快，不会影响到系统 的Tps。且交易的打包执行并没有严格的顺序限制，一笔交易的失败不会影响到其他交易的 正常打包执行。而且可以根据系统的Tps大小来动态调整时间窗的大小，满足多种场景。由 于只需要缓存从当前区块往前n个区块到交易缓存池中，所以对于节点宕机等异常情况的交 易缓存池恢复是非常简单的，不会影响到联盟链系统的性能。

附图说明

图1为本申请实施例提供的一种账户体系下的联盟链交易的重放攻击防范方法的整体流 程示意图；

图2为本申请实施例提供的第一参照时间点T1的确定原理示意图；

图3为本申请实施例提供的当前区块前K个区块的平均出块时间Δk的获取原理示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描 述，显然，所描述的实施例仅仅是本申请的一部分实施例，而不是全部的实施例。基于本申 请的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的的所有其他实施 例，都属于本申请保护的范围：

图1为本申请实施例提供的一种账户体系下的联盟链交易的重放攻击防范方法的整体流 程示意图。本申请实施例提供的一种账户体系下的联盟链交易的重放攻击防范方法，包括步 骤S101至步骤S104。

步骤S101：获取客户端发送的交易请求。

步骤S102：获取所述交易请求的客户端时间，若所述客户端时间早于第一参照时间点T1， 则拒绝所述交易请求。

步骤S103：判断所述客户端时间是否早于或等于第二参照时间点T2，若所述客户端时间 早于或等于第二参照时间点T2，则将所述交易请求对应的交易与交易缓存池P内的全部交易 进行对比；。

具体的，所述第一参照时间点T1是以当前区块的高度m向前取n个区块，选取第m-n个 区块的构建时间作为第一参照时间点T1，其中，第二参照时间点T2为节点的当前时间点， 即当前区块的高度m。现有技术中，对于交易在时间上行是否合法，一般会参考各节点的网 络时钟，但是，在实际应用过程中，由于网络延迟等原因，如果选取各节点的网络时钟来计 算参照时间，则会出现参照时间选取的是一段时间区间，而不是一个精确的时间点，从而对 某一个交易请求，例如，一个交易请求为交易客户端时间在参照时间所对应的时间区间内的 交易，但是，由于各节点的网络时钟不一致，导致对同一交易请求，不同节点的判断不一致。

参见图2，为本申请实施例提供的第一参照时间点T1的确定原理示意图，对于正常共识 的节点来说，每个节点本地都具有相同的一个区块链副本，且已经落盘的区块的构建时间是 确定的。因此以区块高度作为参考标准，以当前区块的高度m向前取n个区块，选取该区块 构建的时间作为第一参照时间点T1，在交易缓存池P中需要缓存从当前区块向前的n-1个区 块中的交易。随着共识的进行，待打包区块的高度m会不断的增大，m每增加1，就对应了一 个新的时间区间。

其中，若所述客户端时间晚于或等于第一参照时间点T1，则判断所述交易请求对应的交 易签名正确，若所述交易请求对应的交易签名正确，则将所述交易请求对应的交易放入到交 易池中；若所述交易请求对应的交易签名不正确，则拒绝所述交易请求。

交易节点从交易池中获取交易请求，并判断交易请求的客户端时间是否早于或等于第二 参照时间点T2，若所述客户端时间早于或等于第二参照时间点T2，则将所述交易请求对应的 交易与交易缓存池P内的全部交易进行对比。

若所述客户端时间晚于第二参照时间点T2，则将所述客户端时间对应的交易请求继续保 留在交易池中。

随着时间的推移，区块不断的生成，当前区块高端m变化一次，则对应的第一参照时间 点T1和第二参照时间点T2均会更新，当所述客户端时间早于或等于更新后的第二参照时间 点T2，则判断所述客户端时间是否晚于或等于更新后的第一参照时间点T1，若所述客户端时 间晚于或等于更新后的第一参照时间点T1，则将相应的交易请求对应的交易与交易缓存池P 内的全部交易进行对比，如果交易缓存池P内存在了交易请求对应的交易，则需要将所述交 易请求对应的交易从交易池中剔除。需要说明的是，系统没生成一个新的区块，第一参照时 间点T1就会更新一次，对应的，则会把小于第一参照时间点T1的交易请求从交易池中剔除 掉。

步骤S104：若交易缓存池P内存在所述交易请求对应的交易，则拒绝所述交易请求；若 交易缓存池P内不存在所述交易请求对应的交易，则将所述交易请求打包至当前区块内，并 将所述交易请求对应的交易缓存至交易缓存池P。

在本申请实施例中提供的交易重放攻击防范方法对应的模型中，需要为每一个通道建立 一个交易缓存池P，交易缓存池P用来缓存交易的客户端时间在第一参照时间点T1，并且已 经成功打包的交易。第一参照时间点T1用来判别一条交易是否在有效接收时间内，交易请求 的交易客户端时间早于T1的所有交易被判定为过期交易。

具体流程为：当前区块的打包区块需要打包一条交易时，首先判断该交易请求的客户端 时间是否在有效时间内，如果该交易请求的客户端时间CT早于T1，则认为该交易请求对应 的交易已经超过了打包的有效时间，拒绝打包该交易。如果交易请求的客户端时间在有效时 间内，即CT晚于T1，则判断该交易请求对应的交易是否存在于交易缓存池P中，如果存在， 则说明该交易请求在参照时间点T之后已经被重复执行过，则拒绝打包该交易请求对应的交 易，如果不存在，则成功将该交易请求对应的交易打包至区块内。

进一步的，由于本申请实施例中，随着共识的进行，待打包区块的高度m会不断的增大， m每增加1，从而导致第一参照时间点T1会随着待打包区块(当前区块)的高度变化，为了 保证所述交易缓存池P内缓存的交易一直处于有效期内，在本申请实施例中，所述一种账户 体系下的联盟链交易的重放攻击防范方法还包括：获取所述交易缓存池P内的全部交易请求 对应的区块打包时间，并将区块打包时间早于或等于第一参照时间点T1的交易请求，从所述 交易缓存池P中剔除。

具体的，随着区块高度的增长，每一个区块的增加都意味着最旧(缓存中高度最小的块) 的区块失效了，所以将失效区块对应的交易从交易缓存池中删除。

在本申请实施例中，交易缓存池P中缓存的交易应该是所有在第一参照时间点T1之后执 行过的交易，即所有交易请求的客户端时间戳在第一参照时间点T1之后的交易一定不会被打 包在m-n个区块以及之前的区块中，即需要保证用于建立交易缓存池P的第一参照时间点T1 能够严格划分时间区域，在不同阶段的第一参照时间点T1在时间上是严格递增的，避免后一 时间的第一参照时间点T1早于前一时间的第一参照时间点T1，故需要满足两个条件，条件 一：区块的构建时间是严格递增的；条件二：区块内被打包的所有交易对应的交易请求的客 户端时间都必须小于该区块的构建时间。

在本申请实施例中，为了满足条件一，要求各共识节点的出块时间必须严格递增，而在 实际应用过程中，当系统存在多个节点共识时，由于各个节点的时钟并不是完全同步，若节 点出块的时间间隔很小，则可能会导致出块时间不是严格递增，为了保证存在多个节点共识 的情况下，节点出块的时间严格递增，本申请实施例中，所述将所述交易请求打包至当前区 块内的步骤中还包括步骤S201至步骤S202。

步骤S201，获取上一区块的打包时间，如果所述上一区块的打包时间小于或等于当前区 块打包节点的本地时间，则将当前区块的打包时间设置为当前区块打包节点的本地时间。

步骤S202，如果所述上一区块的打包时间大于当前区块打包节点的本地时间，则计算当 前区块前K个区块的平均出块时间Δk，在上一区块的打包时间上延迟平均出块时间Δk，作 为当前区块的打包时间。

参见图3，为本申请实施例提供的当前区块前K个区块的平均出块时间Δk的获取原理示 意图，其中，对于当前区块前K个区块的平均出块时间Δk采用步骤S301至步骤S302获得。

步骤S301，获取当前区块前K个区块对应的K个出块时间，判断K个区块中任意连续两 个区块之间的出块间隔时间是否大于默认出块时间间隔。

步骤S302，若某一连续两个区块之间的间隔时间大于默认出块时间间隔，则用默认出块 时间间隔替换所述某一连续两个区块之间的间隔时间，并用替换后的出块间隔时间计算所述K个区块的平均出块时间Δk。

需要说明的是，区块的构建时间一旦写入区块，属于区块中无法修改的属性，这里用默 认出块时间间隔替换所述某一连续两个区块之间的间隔时间，并不是指把原来区块的时间修 改掉，只是用默认出块时间间隔去计算平均出块时间。

具体的，为了保证当前区块的上一区块的区块构建时间不是特别离谱，即leader打包节 点本地时钟和其他节点时钟的误差不能够太大，可以采取以下两个措施：

措施一：定期校准各节点之间的时钟，保持各节点之间的时钟同步，具体的，运维层面 对系统进行再部署时，使用工具来保持节点之间的时钟同步，现在的物理时钟同步应该可以 精确到秒级，故实际应用过程中，秒级同步完全能够满足设计需求。

措施二：在所述将所述交易请求打包至当前区块内的步骤之后，还包括：

副本节点接收到当前区块打包节点产生的当前区块后，将当前区块的构建时间与副本节 点的本地时间进行比较，若当前区块的构建件时间与副本节点的本地时间的间隔大于第一预 设阈值，则副本节点不对当前区块投票

具体的，所述第一预设阈值的大小可以根据实际的设计需求设定，在本申请实施例中， 所述第一预设阈值取2分钟，如果当前区块的构建件时间与副本节点的本地时间的间隔超过 了所述第一预设阈值，则不对该区块投票，因为此时的节点很可能是一个拜占庭节点，通过 设置的第一预设阈值，有效恶意节点的拜占庭攻击。

对于符合第一预设阈值的交易，leader节点从交易池中拿取有效的交易->leader节点 构建区块，设置区块构建时间->leader节点发送区块给副本节点->副本节点进行投票—> 下一个leader节点收集投票，如果投票超过2/3则该区块经过共识，设置区块共识时间-> 区块持久化，设置区块持久化时间。

具体的，在本申请实施例中，为了降低当前区块的前K个区块的平均出块时间Δk的误 差，考虑到节点在没有交易的时候不会出块，若在这K个区块中，有两个区块中间隔了很长 时间才发送交易，则会导致Δk的值很大，如果有多个这样的情况就会造成更大的误差。如 图3所示，所以如果计算出某一区块的出块时间(t

对于条件二，由于Leader节点在打包交易的时候，需要进行一个判断，只有交易的客户 端时间早于当前时间的交易才可以被成功打包，因为区块的构建时间肯定是晚于打包时间， 从而保证满足条件二。

由于运行交易的系统在实际工作过程中，可能会发生节点宕机，在本申请实施例中，所 述一种账户体系下的联盟链交易的重放攻击防范方法还包括：在节点宕机之后，获取节点当 前已确认区块，从当前已确认区块向前查找n个区块，并。将n个区块对应的交易请求缓存 至交易缓存池P，而对于记录全部历史交易的解决方案来说，节点宕机或者物理损坏导致的 数据丢失将会导致无法使用，重新建立全部交易记录需要耗费非常大的时间。本方案在发生 节点宕机或由于硬盘物理损坏导致数据缓存数据丢失时，可以很快恢复交易缓存池P。

为了防止客户端随意篡改时间，在本申请实施例中。所述获取所述交易请求的客户端时 间的步骤之后，还包括：将所述交易请求的客户端时间与节点本地时间进行比较，若所述交 易请求的客户端时间与节点本地时间之间的间隔大于第二预设时间，则拒收所述交易请求。 具体的，在本申请实施例中，将所述第二预设时间设置为10分钟，例如，节点本地时间为15:00，则可以被接收的交易请求的客户端时间为14:50至15:10。

本申请实施例提供的一种账户体系下的联盟链交易的重放攻击防范方法，当节点接收到 一笔新的交易请求时，如果交易请求的客户端时间早于第一参照时间点T1，就说明该交易请 求对应的交易本应该是被打包在第一参照时间点T1之前的区块中的，但是这些区块的交易已 经确定了，所以就认为该交易请求已经超过了交易的打包有效期，拒绝该交易请求。如果交 易请求的客户端时间晚于第一参照时间点T1，且交易请求的客户端时间早于或等于第二参照 时间点T2，那么则会查询交易缓存池P中是否存在该条交易，如果存在，说明该交易以及被 打包过了，则丢弃该条交易请求。如果不存在，说明该交易请求对应的交易为有效的交易， 则在最新的区块中进行打包，通过拒绝交易客户端时间在第一参照时间点T1之前的所有交易 请求，是因为第一参照时间点T1之前的交易是没有进行缓存的，所以无法判断该交易是否在 第一参照时间点T1之前已经打包过了。这也是本方案节省存储空间和高效率的关键点，经过 在Newspiral新一代联盟链的实际测试，在出块间隔为2s的情况下，所述交易缓存池P内缓 存的交易请求数量为150个，已经可以保证所有的交易都可以被正常打包，几乎不会出现因 为交易超过有效期而被拒绝的情况。当然随着区块链技术的进步，联盟链的Tps(系统吞吐 量)未来肯定会达到十万乃至百万级别，这个时候只要增大区块的缓存高度，该技术方案仍 然是适用的，对于Tps的增大，可以调整参数n，来进行动态适应，其他方法则没有调整能 力。

本申请实施例提供的一种账户体系下的联盟链交易的重放攻击防范方法，通过滑动时间 窗的设计，只需要记录在第一参照时间点T1之后所有打包过的交易，在时间窗比较短的情况 下，可以将交易记录缓存在内存中，时间窗比较长的情况下，可以考虑将交易记录存储在数 据库中。由于存储的交易规模小，在时间窗不是特别长的情况下，还可以将该部分交易放在 缓存中，所以交易的判重速度极快，不会影响到系统的Tps。且交易的打包执行并没有严格 的顺序限制，一笔交易的失败不会影响到其他交易的正常打包执行。而且可以根据系统的Tps 大小来动态调整时间窗的大小，满足多种场景。由于只需要缓存从当前区块往前n个区块到 交易缓存池中，所以对于节点宕机等异常情况的交易缓存池恢复是非常简单的，不会影响到 联盟链系统的性能。