【论文研读】-DiPETrans: A Framework for Distributed Parallel Execution of Transactions of Blocks in BLC

属于静态分析智能合约的方法，采取的方法类似于raft算法。

摘要

比特币和以太坊等当代区块链由矿工和验证者连续执行交易，并确定工作量证明 (PoW)。这种串行执行无法有效利用现代多核资源，从而限制了系统吞吐量并增加了事务接受延迟。这项工作的目标是通过使用对事务依赖关系的静态分析引入并行事务执行来增加事务吞吐量。我们提出了 DiPETrans 框架，用于在一个块中分布式执行事务。在这里，区块链网络中的对等点形成一个受信任节点社区，以执行交易并使用领导者 - 跟随者方法并行找到 PoW。在挖矿过程中，Leader静态分析交易，创建独立交易的不同组（分片），分发给Follower并发执行。执行后，利用社区的计算能力同时解决 PoW。当一个区块被成功创建时，领导者将提议的区块广播给网络中的其他对等方进行验证。收到区块后，验证者重新执行区块交易，如果它们达到与矿工共享的相同状态，则接受该区块。验证也可以并行完成，遵循与采矿相同的领导者 - 追随者方法。我们报告了使用来自以太坊区块链的超过 500 万笔真实交易的实验，并使用我们的 DiPETrans 框架执行它们，以凭经验验证我们的技术相对于传统顺序执行的优势。当在社区中使用 6 台机器时，我们实现了矿工的 2.2 倍和验证者的 2.0 倍的最大速度，每块 100 到 500 笔交易。此外，我们使用并行矿工比串行矿工实现了 5 倍的端到端块创建速度峰值。

引言

区块链是一个分布式去中心化数据库，它是一个安全、防篡改、可公开访问的记录集合，组织为块链 。在没有受信任的中央机构的情况下，它维护交易的分布式全局状态。由于它的实用性，它在工业界和学术界引起了广泛的兴趣。区块链由以点对点（P2P）方式维护的节点或对等点组成。网络中的节点可以充当矿工和/或验证者。矿工 m 提出要添加到区块链的区块，因此在文献中也被称为区块生产者。矿工生成的区块由通常编码某些业务逻辑的交易组成。节点 m 然后解决工作量证明 (PoW) 以延迟等待网络，然后通过 P2P 网络广播该块。网络中的其他对等方在接收到块后，会验证该块中的交易以及 PoW 的解决方案。因此，它们被称为验证器。系统外部的客户端（也称为用户）通过向网络对等方发送交易来使用区块链服务。在从客户端接收到足够数量的交易后，节点会扮演矿工的角色来形成一个区块。然后它遵循挖掘和验证过程将块附加到区块链。典型区块链（如以太坊 [3]）中的一个区块由一组交易、其时间戳、区块 ID、随机数、硬币基地址（矿工地址）、链中前一个区块的哈希、当前区块的哈希、等等。通过验证区块的对等方之间的共识，将区块添加到区块链中。通常，区块链的整个副本存储在所有节点上。

比特币 是中本聪提出的第一个区块链系统，是迄今为止最流行的区块链。它是一种高度安全的加密货币系统，用户无需信任他人。此外，没有像当今的银行系统那样的中央控制机构。以太坊 是另一种流行的区块链，除了加密货币（例如用户定义的脚本，称为智能合约）之外，它还提供复杂的服务。这种智能合约是用图灵完备的语言 Solidity 编写的。智能合约就像面向对象编程语言中的一个对象，由方法和数据（状态）组成。它们可用于自动定义和执行合同中的条款和条件，而无需受信任的第三方的干预。客户端执行合约方法的请求，也称为交易，由矿工和验证节点组成，调用一系列这些方法及其输入参数。此类合约可以是钱包之间的简单加密货币交换，也可以是更复杂的逻辑，例如 Ballot 和 Simple Auction

现有系统的缺点： 当前区块链系统中的矿工和验证者连续执行交易。此外，找到 PoW，一个计算密集型的蛮力过程来创建一个新块。矿工竞争验证交易并解决 PoW 以创建一个块。迪克森等人。 [2] 观察到事务在两个不同的上下文中连续执行。首先，由矿工在创建区块时串行执行。之后，验证者会依次重新执行交易以验证区块。通常，矿工执行数百笔交易，而验证者为每个新区块连续执行数百万笔交易。事务的串行执行导致吞吐量不佳，在当前分布式和多核系统时代效率低下。高交易费用、低吞吐量（交易/秒）、高块接受延迟和有限的计算能力阻碍了区块链的广泛采用 [5]。因此，向区块链添加并行性可以提高效率并实现更高的吞吐量。

解决方案： 在比特币和以太坊中提出并使用了几种解决方案来缓解这些问题。一种这样的解决方案是，几个资源受限的矿工组成一个矿池或社区来解决 PoW。在区块接受后，他们在他们之间分享激励。

与这些方法相比，我们建议使用形成社区的机器集群，基于事务的静态分析以分布式方式执行或验证事务。这提高了块挖掘和验证的性能。社区有一台leader机器和一组follower机器。领导者是区块链的一部分，而追随者节点由领导者支配，而不是区块链的一部分。受领导者支配的追随者与领导者形成一个受信任的社区，例如，他们属于同一个组织。

领导者对块中的事务执行静态分析以识别依赖关系并将它们分片为独立的事务，每个事务由跟随者以分布式方式并发执行。矿工和验证者都可以执行此静态分析以并行执行。这避免了对块内的块依赖图进行编码，同时也防止了 FBR 错误。在挖矿时，PoW 的解空间也由追随者进行分区和并行求解。我们在以太坊区块链 中实施并实证验证了我们的方法的好处。然而，所提出的方法是通用的，可以集成到任何其他无许可和许可（通过排除当前方法的 PoW 计算）区块链平台中，该平台遵循订单执行交易执行模型。这意味着 DiPETrans 可以与任何其他基于共识（如 PBFT）的订单执行区块链平台集成。据我们所知，这是第一个使用静态分析来识别可以并行执行的块交易并将它们与分片和矿池的好处相结合的工作。

贡献 ：

• 我们在第 II 节中提出了一个 DiPETrans：区块链框架中区块交易的分布式并行执行，用于基于使用静态分析识别的交易分片在矿工和验证者处并行执行交易。
• 我们在服务器的挖矿社区中使用分布式领导者-从者方法来实施这项技术，其中领导者对块中的交易进行分片，而追随者同时执行（挖掘）或验证（验证）它们。挖矿时，PoW也由社区成员进行分区和并行解决。
• 我们在§III 中报告了使用来自以太坊的超过 500 万笔真实交易的实验区块链并使用 DiPETrans 执行它们，以凭经验验证我们的技术相对于传统顺序执行的优势。对于每块 100 到 500 个事务，我们实现了并行矿工的最大加速 2.18 倍和并行验证器的 2.02 倍。此外，当使用社区中的 6 台机器（包括领导者）时，我们使用并行矿机比串行矿机实现最大 5 倍的端到端块创建速度。

框架

图 1 显示了 DiPETrans 框架的体系结构。它显示了两个挖矿社区，一个充当矿工节点，另一个充当区块链中的验证者节点。每个社区内部都有多个计算服务器，它们使用它们的分布式计算能力协同执行交易并为一个块并行解决 PoW。资源可以全部归同一个用户所有，也可以参与并行挖矿，根据预先约定的条件获得一部分激励费用。

其中一名社区工作人员被确定为领导者，而其他人则是追随者。领导者代表社区，并在区块链网络中作为所有操作的单个对等点出现。因此，我们架构中区块链的每个对等点都是其各自社区的领导者。当用户向区块链中的一个节点提交交易请求时，该交易被广播给每个节点，包括每个社区的 Leader。

作为挖矿者（miner）：

1. 将广播的交易放入各个对等方的待处理交易队列中，每个挖矿者都可以进行计算去获取构建区块的权利。
2. 领导者负责协调一个团体内各个功能，来进行智能合约的执行以及计算POW共识机制当中的nouce值，这两个阶段是分阶段进行执行的。对于领导者（leader）的选举是需要进行领导者选举算法的。
3. 领导者从Pending Transaction Queue当中选择区块进行交易来构建区块。其中一个区块包含前一个区块的哈希值、上一个区块的状态、矿工的ID、时间戳、交易头和其他信息。
4. 之后将所有的交易进行分片，有依赖关系的交易放置到一个分片当中，没有依赖关系的交易放置到不同的分片当中。详细的分发过程利用到WCC算法来将不同的交易进行分片，分割算法的示意图如图2。（交易分析算法如算法1）
5. 之后领导者会将分片当中的交易和当前的状态分发给所有的跟随者进行执行。（算法2 负责给跟随者分配分片的时候，保证负载均衡）
6. 跟随者将所有执行后的状态交易信息反馈给领导者进行汇总，更新所有的状态。
7. 领导者将进行计算POW难度，主要统筹所有的跟随者计算不同的nouce区间，来寻找小于target的nouce值
8. 领导者提出带有已执行交易和 PoW 的区块，更新其本地链，并将其广播给区块链网络中的所有对等方进行验证。

作为验证者：

9. 在收到来自矿工的区块后，区块链网络的剩余对等节点充当其验证者。验证来自矿工的区块。
10. 验证方的领导者节点统筹各个社区的资源
11. 可以按照矿工发来的分片方式进行交易的分片，也可以自己进行分片。（不过还是有矿工发来的分片方式来执行性能方面会更高。）之后会将交易分成不同的交易分片，分发给不同的跟随者，也是遵循算法2的负载均衡算法
12. 跟随者执行来自领导者发来的各个交易的分片，并且更新由自己执行后的交易状态信息。
13. 领导者会验证各个节点发来状态信息的总和来与矿工发来的状态信息是否一致，一致则说明可以接受矿工的区块上链，不一致则拒绝，并且会验证POW的nouce值是否会小于当前的目标值。
14. 验证通过后，更新自己的状态信息
15. 区块上链

其中用到了WCC算法，算法如下：

import java.util.ArrayList;
//构建图所需要的方法和变量
public class Graph {
    
    
    int vertices;
    ArrayList<ArrayList<Integer>> adjacencyList;
    public Graph(int vertices) {
    
    
        this.vertices = vertices;
        adjacencyList = new ArrayList<>(vertices);
        for (int i = 0; i < this.vertices; i++)
            adjacencyList.add(new ArrayList<>());
    }
    public void addEdge(int u, int v) {
    
    
        // Use of noEdge(int, int)
        // prevents duplication of edges
        if (noEdge(u, v))
            adjacencyList.get(u).add(v);
    }
    // Returns true if there does NOT exist
    // any edge from u to v
    boolean noEdge(int u, int v) {
    
    
        for (int destination : adjacencyList.get(u))
            if (destination == v)
                return false;
        return true;
    }
}

import java.util.ArrayList;

public class WCC {
    
    
    private final Graph directedGraph;
    public WCC(Graph directedGraph) {
    
    
        this.directedGraph = directedGraph;
    }
    // Finds all the connected components of the given undirected graph
    private ArrayList<ArrayList<Integer> > connectedComponents(Graph undirectedGraph) {
    
    
        ArrayList<ArrayList<Integer> > connectedComponents = new ArrayList<>();
        boolean[] isVisited = new boolean[undirectedGraph.vertices];
        for (int i = 0; i < undirectedGraph.vertices; i++) {
    
    
            if (!isVisited[i]) {
    
    
                ArrayList<Integer> component = new ArrayList<>();
                findConnectedComponent(i, isVisited, component, undirectedGraph);
                connectedComponents.add(component);
            }
        }
        return connectedComponents;
    }
    // Finds a connected component
    // starting from source using DFS
    private void findConnectedComponent(int src, boolean[] isVisited, ArrayList<Integer> component, Graph undirectedGraph) {
    
    
        isVisited[src] = true;
        component.add(src);
        for (int v : undirectedGraph.adjacencyList.get(src))
            if (!isVisited[v])
                findConnectedComponent(v, isVisited, component, undirectedGraph);
    }
    public ArrayList<ArrayList<Integer> > weaklyConnectedComponents() {
    
    
        // Step 1: Construct the underlying undirected graph
        Graph undirectedGraph = new Graph(directedGraph.vertices);
        for (int u = 0; u < directedGraph.vertices; u++) {
    
    
            for (int v : directedGraph.adjacencyList.get(u)) {
    
    
                undirectedGraph.addEdge(u, v);
                undirectedGraph.addEdge(v, u);
            }
        }
        // Step 2: Find the connected components of the undirected graph
        return connectedComponents(undirectedGraph);
    }
}

import java.util.ArrayList;

public class WCCdemo {
    
    
    public static void main(String[] args) {
    
    
        Graph directedGraph = new Graph(6);
        directedGraph.addEdge(0, 1);
        directedGraph.addEdge(0, 2);
        directedGraph.addEdge(3, 1);
        directedGraph.addEdge(3, 2);
        directedGraph.addEdge(4, 5);
        ArrayList<ArrayList<Integer>> weaklyConnectedComponents = new WCC(directedGraph).weaklyConnectedComponents();
        int index = 1;
        for (ArrayList<Integer> component : weaklyConnectedComponents) {
    
    
            System.out.print("Component " + index++ + ": ");
            for (Integer i : component)
                System.out.print(i + " ");
            System.out.println();
        }
    }
}

划分的是这样的图：

结果如下：

DiPETrans 中矿工和验证者社区处理区块的序列图：
过程和上述的过程一致。

总结

在本文中，我们提出了一个分布式领导者 - 跟随者框架 DiPETrans 来在多个节点（同一社区的一部分）上并行执行块事务。据我们所知，文献中没有这样的研究。我们在从以太坊区块链中提取的实际交易中测试了我们的原型。我们实现了与追随者数量成比例的绩效增长。我们还看到了合同执行时间和货币交易的性能提升。我们在各种工作负载上评估了 DiPETrans，其中一个区块中的交易数量从 100 到 500 不等，合约与货币交易不同。我们观察到，随着每个块的事务数量的增加，分布式设置中的加速通常会增加，从而增加吞吐量。我们观察到区块执行时间随着合约调用次数的增加而增加。我们还看到加速比随着社区规模线性增加。

未来的研究有几个方向。假设交易数量会随着时间的推移而增加，我们可以设想一个并行提出多个区块的社区。如前所述，提高性能的另一种方法是将 STM 用于追随者节点，并使用多核而不是串行地在每个追随者中同时运行事务。另一个方向是我们假设在这项研究中没有嵌套的合约调用，但实际上嵌套在区块链的合约中很常见。所以在我们的框架中加入嵌套是非常有用的。

我们已经看到社区中只有 5 个跟随者的性能提升。看看系统如何扩展并在数百或数千笔交易中达到峰值加速会很有趣 。除了上述优化之外，我们还计划在社区内采用完全分布式的方法，而不是对故障和其他故障具有弹性的领导者-跟随者方法。我们计划通过部署 DiPETrans 社区智能合约将其与以太坊区块链集成。