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

It belongs to the method of statically analyzing smart contracts, and the method adopted is similar to the raft algorithm.

Summary

Contemporary blockchains such as Bitcoin and Ethereum have miners and validators executing transactions continuously and determining a Proof of Work (PoW). This serial execution cannot efficiently utilize modern multi-core resources, limiting system throughput and increasing transaction acceptance latency. The goal of this work is to increase transaction throughput by introducing parallel transaction execution using static analysis of transaction dependencies. We propose the DiPETrans framework for distributed execution of transactions in a block. Here, peers in a blockchain network form a community of trusted nodes to execute transactions and find PoW in parallel using a leader-follower approach. During the mining process, the Leader statically analyzes transactions, creates different groups (shards) of independent transactions, and distributes them to Followers for concurrent execution. After execution, use the computing power of the community to solve PoW simultaneously. When a block is successfully created, the leader broadcasts the proposed block to other peers in the network for verification. After receiving a block, validators re-execute the block transactions, accepting the block if they reach the same state shared with the miner. Validation can also be done in parallel, following the same leader-follower approach as mining. We report experiments using more than 5 million real transactions from the Ethereum blockchain and execute them using our DiPETrans framework to empirically verify the advantages of our technique over traditional sequential execution. When using 6 machines in the community, we achieve a maximum speed of 2.2x that of miners and 2.0x that of validators, with 100 to 500 transactions per block. Furthermore, we achieved a 5x peak end-to-end block creation speed using parallel miners compared to serial miners.

introduction

A blockchain is a distributed decentralized database, which is a secure, tamper-proof, publicly accessible collection of records organized as a chain of blocks. It maintains a distributed global state of transactions in the absence of a trusted central authority. Due to its practicality, it has attracted widespread interest in both industry and academia. A blockchain consists of nodes, or peers, maintained in a peer-to-peer (P2P) fashion. Nodes in the network can act as miners and/or validators. Miner m proposes blocks to be added to the blockchain and is therefore also called a block producer in the literature. Blocks generated by miners consist of transactions that usually encode some business logic. Node m then solves Proof-of-Work (PoW) to delay waiting on the network, and then broadcasts the block over the P2P network. Other peers in the network, after receiving a block, verify the transactions in that block and the PoW solution. Therefore, they are called validators. Clients (also known as users) outside the system consume blockchain services by sending transactions to network peers. After receiving a sufficient number of transactions from clients, nodes act as miners to form a block. It then follows the mining and verification process to append the block to the blockchain. A block in a typical blockchain (e.g. Ethereum [3]) consists of a set of transactions, their timestamp, block ID, nonce, coin base address (miner address), hash of the previous block in the chain , the hash of the current block, etc. Blocks are added to the blockchain by validating the consensus among peers of the block. Typically, an entire copy of the blockchain is stored on all nodes.

Bitcoin is the first blockchain system proposed by Satoshi Nakamoto, and it is by far the most popular blockchain system. It is a highly secure encrypted currency system where users do not need to trust others. Also, there is no central controlling authority like in today's banking system. Ethereum is another popular blockchain that offers complex services in addition to cryptocurrencies such as user-defined scripts, known as smart contracts. This smart contract is written in Solidity, a Turing-complete language. A smart contract is like an object in an object-oriented programming language, consisting of methods and data (state). They can be used to automatically define and enforce the terms and conditions in contracts without the intervention of trusted third parties. Requests from clients to execute contract methods, also known as transactions, consist of miners and validators calling a series of these methods and their input parameters. Such contracts can range from simple cryptocurrency exchanges between wallets to more complex logic such as Ballot and Simple Auction

Disadvantages of existing systems: Miners and validators in current blockchain systems execute transactions continuously. Also, PoW is found, a computationally intensive brute force process to create a new block. Miners compete to verify transactions and solve PoW to create a block. Dixon et al. [2] Observe that transactions execute consecutively in two different contexts. First, it is executed serially by miners when creating blocks. Afterwards, validators sequentially re-execute transactions to validate blocks. Typically, miners execute hundreds of transactions, while validators execute millions of transactions continuously for each new block. Serial execution of transactions results in poor throughput and is inefficient in the current era of distributed and multi-core systems. High transaction fees, low throughput (transactions/second), high block acceptance latency, and limited computing power hinder the widespread adoption of blockchains [5]. Therefore, adding parallelism to a blockchain can increase efficiency and enable higher throughput.

Solutions: Several solutions have been proposed and used in Bitcoin and Ethereum to alleviate these problems. One such solution is for several resource-constrained miners to form a pool or community to solve PoW. After block acceptance, they share incentives among themselves.

In contrast to these approaches, we propose to execute or verify transactions in a distributed fashion based on static analysis of transactions using clusters of machines forming communities. This improves the performance of block mining and validation. The community has a leader machine and a group of follower machines. The leader is part of the blockchain, and the follower nodes are governed by the leader, not part of the blockchain. Followers dominated by the leader form a trusted community with the leader, i.e., they belong to the same organization.

The leader performs static analysis on transactions in blocks to identify dependencies and shards them into independent transactions, each of which is executed concurrently by followers in a distributed fashion. Both miners and validators can perform this static analysis to execute in parallel. This avoids encoding the block dependency graph within a block and also prevents FBR errors. When mining, the PoW solution space is also partitioned and solved in parallel by followers. We implement and empirically verify the benefits of our approach in the Ethereum blockchain. However, the proposed approach is general and can be integrated into any other permissionless and permissioned (by excluding PoW computation from current approaches) blockchain platforms that follow an order execution transaction execution model. This means that DiPETrans can be integrated with any other consensus based (like PBFT) order execution blockchain platform. To our knowledge, this is the first work that uses static analysis to identify block transactions that can be executed in parallel and combines them with the benefits of sharding and pooling.

Contribute :

• We propose in Section II a DiPETrans: Distributed Parallel Execution of Block Transactions in a Blockchain Framework for executing transactions in parallel at miners and validators based on transaction shards identified using static analysis.
• We implement this technique using a distributed leader-slave approach in a mining community of servers, where the leader shards transactions in blocks, while followers execute (mining) or verify (validate) them concurrently. When mining, PoW is also partitioned and solved in parallel by community members.
• We report in §III an experimental blockchain using over 5 million real transactions from Ethereum and executing them with DiPETrans to empirically verify the advantage of our technique over traditional sequential execution. For 100 to 500 transactions per block, we achieve a maximum speedup of 2.18x for parallel miners and 2.02x for parallel validators. Furthermore, we achieve a maximum of 5x end-to-end block creation speed using parallel miners compared to serial miners when using 6 machines in the community (including the leader).

frame

Figure 1 shows the architecture of the DiPETrans framework. It shows two mining communities, one acting as miner nodes and the other acting as validator nodes in the blockchain. There are multiple computing servers inside each community, which use their distributed computing power to collaboratively execute transactions and solve PoW for a block in parallel. The resources can all be owned by the same user, or they can participate in parallel mining and get a part of the incentive fee according to the pre-agreed conditions.

One of the community workers was identified as the leader, while the others were followers. Leaders represent the community and appear as a single peer for all operations in the blockchain network. Therefore, each peer of the blockchain in our architecture is the leader of its respective community. When a user submits a transaction request to a node in the blockchain, the transaction is broadcast to every node, including the leader of each community.

As a miner:

1. Put the broadcasted transaction into the pending transaction queue of each peer, and each miner can perform calculations to obtain the right to build a block.
2. The leader is responsible for coordinating various functions within a group to execute smart contracts and calculate the nouce value in the POW consensus mechanism. These two stages are executed in stages. For the election of the leader, a leader election algorithm is required.
3. The leader selects blocks from the Pending Transaction Queue for transactions to build blocks. One of the blocks contains the hash of the previous block, the state of the previous block, the ID of the miner, timestamps, transaction headers, and other information.
4. Afterwards, all transactions are fragmented, and transactions with dependencies are placed in one fragment, and transactions without dependencies are placed in different fragments. The detailed distribution process uses the WCC algorithm to segment different transactions. The schematic diagram of the segmentation algorithm is shown in Figure 2. (The trading analysis algorithm is like Algorithm 1)
5. Afterwards, the leader will distribute the transactions and current state in the shard to all followers for execution. (Algorithm 2 is responsible for ensuring load balancing when assigning fragments to followers)
6. Followers feed back all executed state transaction information to the leader for summary and update all states.
7. The leader will calculate the POW difficulty, mainly coordinating all the followers to calculate different nouce intervals, to find the nouce value smaller than the target
8. The leader proposes a block with executed transactions and PoW, updates its local chain, and broadcasts it to all peers in the blockchain network for verification.

As validator:

9. After receiving a block from a miner, the remaining peer nodes of the blockchain network act as its validators. Validate blocks from miners.
10. The leader node of the verifier coordinates the resources of each community
11. The sharding that can be traded according to the sharding method sent by the miners can also be sharded by yourself. (However, there are still shards sent by miners to perform better performance.) Afterwards, the transaction will be divided into different transaction shards and distributed to different followers, which also follows the load balancing algorithm of Algorithm 2
12. The follower executes the shards of each transaction sent by the leader, and updates the status information of the transaction executed by itself.
13. The leader will verify whether the sum of the status information sent by each node is consistent with the status information sent by the miner. If it is consistent, it means that the miner’s block can be accepted on the chain. target value.
14. After the verification is passed, update your status information
15. Blockchain

The WCC algorithm is used, and the algorithm is as follows:

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();
        }
    }
}

The graph is divided like this:

The result is as follows:

Sequence diagram of blocks processed by miners and verifier communities in DiPETrans:
the process is consistent with the above process.

Summarize

In this paper, we propose a distributed leader-follower framework, DiPETrans, to execute block transactions in parallel on multiple nodes (part of the same community). To our knowledge, there are no such studies in the literature. We tested our prototype on real transactions extracted from the Ethereum blockchain. We achieved a performance increase proportional to the number of followers. We have also seen performance improvements in contract execution time and currency transactions. We evaluate DiPETrans on a variety of workloads, where the number of transactions in a block ranges from 100 to 500, contracts differ from currency transactions. We observe that the speedup in a distributed setting generally increases as the number of transactions per block increases, thereby increasing throughput. We observe that the block execution time increases with the number of contract calls. We also see that the speedup increases linearly with community size.

There are several directions for future research. Assuming that the number of transactions will increase over time, we can imagine a community proposing multiple blocks in parallel. Another way to improve performance, as mentioned before, is to use STM for follower nodes and run transactions simultaneously in each follower using multiple cores instead of serially. The other direction is that we assume that in this study there are no nested contract calls, but in practice nesting is common in contracts in blockchains. So adding nesting to our framework is very useful.

We've seen performance gains with only 5 followers in the community. It will be interesting to see how the system scales and reaches peak speedup over hundreds or thousands of transactions. In addition to the above optimizations, we plan to take a fully distributed approach within the community, rather than a leader-follower approach that is resilient to failures and other failures. We plan to integrate it with the Ethereum blockchain by deploying the DiPETrans community smart contract.