一种提高区块链处理速度的交易预处理方案

一种提高区块链处理速度的交易预处理方案 | 登链社区 | 深入浅出区块链技术

一种提高区块链处理速度的交易预处理方案

提出了一个区块链交易处理的模型，以提高区块链系统在大量交易涌入时的交易处理速度至接近单机。区块链天然拥有安全性，不可篡改性，去中心化等特点，这些特性都基于一个可靠的共识系统，但现有较为可靠的共识系统都需要以矿工与验证者同步执行区块、多节点本地重现交易以及高网络复杂度共识算法来进行区块验证，极大限制了区块链系统的交易处理速度。

本次探讨的主要问题包括：

1. 节点空闲时间不做功：因为无法预测本地交易排序是否与其他节点相同而造成无法预执行交易，只有等待矿工出块后才能按该区块的顺序验证交易，等待的时间完全浪费
2. 矿工与验证者同步执行区块：等待上一个矿工出块完成才能进行下一个区块的出块造成了区块生产堵塞无法高效出块

本方案包含两个主要技术点：共识排序与预执行、交易量大时单节点连续出块。

1. 共识排序与预执行：在区块链系统中使用raft算法选定一个order节点进行共识排序，在接收交易后进行简单检查后广播给其他共识节点，让所有共识节点能拿到统一的交易排序并按照该排序预执行交易，将执行结果缓存下来，接收到区块信息之后直接取对应缓存点验证即可，这样可以让节点充分利用时间，加快交易处理速度，因为节点已有本地执行结果所以矿工只需要广播区块链hash等信息即可完成验证，节约了区块广播的网络带宽。
2. 交易量大时单节点连续出块：预执行让节点充分利用了时间，但按照老方法，一个区块的验证是基于父区块的，所以还是存在区块的堵塞情况，不能一次性将已预执行的大批量交易打包。单节点连续出块方案可以解决这个问题，矿工出块时将本地已预执行的所有交易打包成多个区块并广播区块hash等信息到验证者节点(不需要整个区块，足够验证即可)，验证者以自己本地的执行结果与矿工发送的信息相对比即可完成验证。

---

共识排序预执行与单节点连续出块

排序预执行大致流程：

客户端 → order排序 → 广播排序 → 节点预执行交易并保存结果 → 如果交易量太大，矿工连续打包已处理的交易并广播 → 共识本批次区块(一次共识即可)

排序流程：

对比fabric排序流程：

1. 客户端：客户端广播交易到所有验证者节点与order节点。
2. 验证者：缓存交易。
3. Order：按照时间顺序为交易排序并将其kv(number：hash)广播到其他验证者节点(附带消息的签名)。
4. 验证者：收到order节点发送的kv后，先验证order签名，再按照order的排序依次执行交易并缓存结果（如果需要考虑内存问题，可每N条交易清除前N-1条交易记录，可保证在最后收到区块时需要执行的交易不会超过N条，缓存也可有效缩减），缓存记录条数可设置最大值，超过最大值的交易暂时不处理。
5. 出块节点：按照order节点的排序进行交易打包并广播到各个验证者节点，如果本地已处理的交易太多则连续出块，广播最终结果即可（最后一个区块的hash，或者本批次区块的hash和number的键值对，交易number区间）。
6. 验证者：收到矿工发送的区块hash后，在本地取该批次区块的终止交易对应的缓存状态进行验证比较并开始共识，如果连续出块中有任何错则对该批次做验证失败的共识，例如pbft的viewchange。在共识期间如果本地还存在未处理的交易，则交易预执行、数据落盘与共识并行处理。

---

排序预处理与连续出块主要技术点详细：

1. 共识排序预执行
2. 单节点连续出块
3. Raft 切换 order

共识排序预执行

1. 缓存：客户端按照以太坊的老方法将交易广播，让所有验证节点都能收到交易并缓存交易。
2. 共识排序：排序节点收到交易之后做简单检查后以时间顺序排序，并广播交易编号与交易hash的键值对给其他验证者，验证者收到键值对后检查本地是否有该交易，有则排序执行，否则从order节点处拉取对应交易。
3. 预执行交易：验证节点通过收到的交易序号来依次执行交易，并保存每一笔交易的执行结果状态，区块落盘后删除旧状态。
4. 接收区块：矿工打包的区块只需要广播签名，区块hash，交易号区间和区块number即可完成验证，其余参数视情况而定（可选：state root，用于直接对比最终状态，但如果生成区块hash的元素可确定，可直接使用区块hash验证），因为本地已经有交易执行结果，直接对比最终状态即可完成验证。
5. 不合法交易：本地直接跳过，判定矿工也需要直接跳过。

单节点连续出块

1. 何时连续出块：不满区块gas阈值则等待1秒再出块，达到gas阈值则连续出块，或者直接判断本地交易池中的交易量是否需要连续出块，其余时间可保持轮流出块。
2. 如何连续出块：矿工每次出块需判断本地有多少已处理区块，将其起始区块号、末尾区块号和区块hash写入区块广播消息，以下3种方式可供参考：
   • 每打包好一个区块就广播其hash，广播最后一个区块时将本批次区块hash一起广播（依次广播是为了交易打包与共识并行，逐块共识）。
   • 直接将已处理的交易结果取出，计算出该批次所有区块hash，最后一起广播。
   • 设置每个区块最多能打包多少交易，矿工直接发送最后一笔交易number和区块hash，验证者通过本地计算区块hash与矿工区块hash对比。（或者矿工标注每个区块以哪一笔交易结尾，验证者直接查对应交易的状态即可）
   • 上述b和c可以直接共识最后的总结区块hash即可。
3. 区块信息的生成：连续出块的矿工本地有上一块区块信息科直接生成。验证者们：已有交易执行结果state root，但区块hash需要得到上一区块hash后计算，如果区块hash生成的参数可确定（一般来说是可以确定的），可以本地生成多个区块hash，参考2-2, 2-3。
4. 不合法区块：验证者在某矿工连续出块的过程中收到坏区块时，丢弃本批次区块，切换矿工（单矿工模式：raft协议切换，轮流出块模式：pbft协议切换），如果长时间收不到最后一个总结区块，发起矿工切换。

Raft切换order：

1. 某机制规定order宕机与否，宕机则切换，多次无效信息或者缺失心跳
2. 验证节点中有交易太久没有得到排序怎么办？该验证节点将交易发送给order节点，提醒其排序该交易，如果还是没有被排序则广播交易，其余验证者收到交易后将交易发送给order节点，然后开始计时，一段较长时间过后如果order节点仍然没有将该交易排序，则开始raft矿工切换。

---

Order作恶的防范措施：

order节点决定了网络中交易的排序，是预处理的前提条件，如果order节点作恶怎么办？

在区块链世界中，交易都是被多验证者执行验证的，所以不会存在假交易情况，现在讨论本方案是否保持了区块链的此特性！客户端提交交易到某节点并广播，让所有验证者都收到该交易并等待排序，验证者按照order节点的排序顺序执行交易并缓存，如果有坏交易则跳过，矿工同上，在本方案中对坏交易的处理是有效的。但可能存在order节点多次排序坏交易造成网络堵塞低效的情况，在现有的区块链系统中，坏交易能在交易池与evm中检查出来，order节点做类似交易池检查可以筛选出部分坏交易，但类似合约错误的交易只能在evm中表现，现有的区块链系统对此类交易也只能在链上处理，并且如果在order节点的排序过程中进行了太多费时操作则会影响整个系统的运行速度

长时间不处理某笔交易

当某验证者收到一笔交易但长时间没有被打包，该验证节点将交易发送给order节点，提醒其排序该交易，如果还是没有被排序则广播交易，其余验证者收到交易后将交易发送给order节点，然后开始计时，一段较长时间过后如果order节点仍然没有将该交易排序，则开始raft矿工切换。

某机制规定order宕机与否，宕机则切换，多次无效信息或者缺失心跳，使用raft协议切换矿工

---

排序预处理与连续出块期望达到的效果：

如果交易量太大，各个节点在打包区块和共识的同时仍然在预执行未处理的交易，所以多个批次期望的时间消耗（不计算客户端交易到节点的时间）：

• order的检查和排序时间 + 交易hash与number的kv广播时间 + 交易的预执行时间(单机处理) + 一次批次的共识时间（因为共识和打包操作是和预执行交易操作并行的）

---

与现有区块链交易处理的区别：

现有的区块链共识基本上都是阻塞，每个区块的生产必须基于上一个区块，所以得等待上一个区块在矿工处执行，验证者群体处执行和共识都完成以后才能继续。本方案是非阻塞的，预执行节省了多余的交易执行时间成本，连续出块节省了处理大批量交易时多余的共识时间成本，打包共识、数据落盘与预处理的并行让系统在巨大交易量时也能保持无阻塞交易处理。（当然是基于矿工和order等节点都正常的情况，如果矿工或order出错则会有额外的错误处理，拖慢整个网络）