Adaptive Parallel Scheduling Scheme for Smart Contract

Abstract

With the increasing demand for decentralized systems and the widespread usage of blockchain, low throughput and high latency have become the biggest stumbling blocks in the development of blockchain systems. This problem seriously hinders the expansion of blockchain and its application in production. Most existing smart contract scheduling solutions use static feature analysis to prevent contract conflicts during parallel execution. However, the conflicts between transactions are complex; static feature analysis is not accurate enough. In this paper, we first build the dependency between smart contracts by analyzing the features. After numerous experiments, we propose a conflict model to adjust the relationship between threads and conflict to achieve high throughput and low latency. Based on these works, we propose adaptive parallel scheduling for smart contracts on the blockchain. Our adaptive parallel scheduling can distinguish conflicts between smart contracts and dynamically adjust the execution strategy of smart contracts based on the conflict factors we define. We implement our scheme on ChainMaker, one of the most popular open-source permissioned blockchains, and build experiments to verify our solution. Regarding latency, our solution demonstrates remarkable efficiency compared with the fully parallel scheme, particularly in high-conflict transaction scenarios, where our solution achieves latency levels just one-twentieth of the fully parallel scheme. Regarding throughput, our solution significantly outperforms the fully parallel scheme, achieving 30 times higher throughput in high-conflict transaction scenarios. These results highlight the superior performance and effectiveness of our solution in addressing latency and throughput challenges, particularly in environments with high transaction conflicts.

1. Introduction

The rapid advancement of blockchain technology has led to an increasing number of individuals preferring to construct their projects on this decentralized system [1]. The way of creating services on the blockchain involves the usage of smart contracts. The concept of smart contract was first proposed by Nick Szabo [2] in the early 1990s. A smart contract is a self-executing contract with the terms of the agreement between buyer and seller being directly written into lines of code. The code and the protocols contained are deployed onto the blockchain.

It is also essential to mention that blockchain technology still faces numerous challenges. One of the most critical issues is its low performance and latency [3]. The widespread utilization of blockchain (such as non-fungible token NFT [4] and cryptocurrency [5]) has resulted in the deployment and numerous invocations of smart contracts on this decentralized platform. This high demand has exacerbated the situation, causing blockchain systems to become slower and more burdensome. Consequently, the low performance and the high latency of smart contracts may scarcely enhance the transaction processing speed on the blockchain and limit the scope of its implementation.

Throughput and latency reflect the number of transactions a block can contain and the time it takes for a block to be finalized, which heavily depends on the consensus and smart contract execution strategy applied. Many high-performance schemes, such as DumboBFT [6], Phantasm [7], and HCA [8,9], aim to expand the throughput and reduce the finalization time via consensus mechanisms. Although these consensus algorithms greatly improve the throughput and latency of a blockchain system, conflicts between smart contracts and the transaction re-execution still impact performance, especially with the deployment of numerous smart contracts. To address the issue of smart contract execution, scholars have proposed various creative schemes. Dickerson et al. [10] proposed a new method for miners and validators for executing smart contracts in parallel based on software transactional memory technology. Singh et al. [11] proposed a technique for executing smart contract transactions concurrently. Yu et al. [12] proposed a parallel smart contract model, which improves performance through multi-thread processing of the smart contracts that have no shared variables. Bartoletti et al. [13] proposed a static approximation of swappability based on a static analysis of the sets of keys read/written by transactions. Most proposed methods use static analysis to find the conflict between smart contracts. It is challenging when dynamic cross-contract invocations occur. Moreover, there is randomness and complexity in the process of cross-contract calls, and the results of static analysis may lead to high rollback rates and low parallelism in actual scenarios. Facing these challenges, after researching related work, we propose three research questions that we focus on.

RQ1 

How to solve cross-contracts calling conflicts in parallel execution? During parallel execution, conflicts can easily occur due to cross-contract calls, necessitating the re-execution of conflicting transactions, which can lower overall efficiency or even result in worse performance than serial execution. Simply employing parallel execution is not sufficient, and adjustments to the execution process are necessary.

RQ2 

How to dynamically adjust the scheduling of smart contracts to achieve parallel execution? Static analysis of smart contracts is challenging when dynamic cross-contract invocations occur since the contract access patterns are not predictable [14]. The conflict between transactions is complex, and static analysis from smart contracts is not enough. The execution strategy based on static analysis and dynamically adjusted during execution is the most efficient solution.

RQ3 

How to improve the implementation of parallel scheduling to achieve efficient usage of space and time? When implementing parallel scheduling in permissioned blockchains like ChainMaker, we have found it necessary to optimize the data structure for efficiency. It is crucial to consider how to better implement this technology in engineering practice.

To answer these research questions, in this paper, we propose adaptive parallel scheduling for smart contracts. Our scheme analyzes the characteristics of smart contracts in fields and the setting of smart contracts on ChainMaker to build a contract dependency based on the characteristics in an actual deployment. During the actual execution of transactions, moreover, regarding conflicts between transactions and the number of parallel threads, we propose a conflict model that can be used in adaptive execution. What is more, we propose a conflict factor as an indicator to describe the degree of conflict between contracts. During the transaction process, we adaptively update the conflict factors and classify strong conflict contracts and weak conflict contracts by a conflict threshold. For strong conflict contracts, we use serial execution. For weak conflict contracts, we still use parallel execution. According to this, we build and update the transaction DAG and execute the transactions. After the execution, we build the transaction execution processing to update the execution strategy. In the experiment, we proposed two indicators, transaction parallelism score and transaction parallelism rate, to build a more detailed evaluation of transaction parallelism. What is more, we use bitmap, which is more efficient in both space and time to optimize our schemes in the experiment. We implement our scheme on ChainMaker [15], and the results show that our scheme meets our expectations.

This paper makes the following contributions.

• Smart contract dependency DAG from static analysis. By analyzing the relationship of the field characteristics of smart contracts, we build the contract dependency by constructing a contract dependency DAG.
• Conflict model from numerous experiments. We build a conflict model that describes the relationship between the conflicts of transactions and the number of parallel threads during the actual execution of transactions. Through a large number of experiments, we construct the distribution of the number of threads when TPS is optimal.
• Dynamically parallel scheduling. We propose an adaptive smart parallel scheduling that adapts the conflict factors and dynamically adjusts the serial and parallel scheduling of contracts based on conflict factors.
• Technical optimization in actual implementation. We use a bitmap to improve the usage of space and time, and we implement this scheme on ChainMaker and obtain the expected results.

This paper is outlined as follows: In Section 2, we review the backgrounds of the blockchain, smart contracts, and previous related works. In Section 3, we define some indicators and structs we use. In Section 4, we introduce our scheme in detail. In Section 5, we implement our scheme on ChainMaker and analyze the results. In Section 6, we give a conclusion about this paper.

2. Related Work

The throughput rate of the blockchain is mainly subject to the following two aspects: one is the execution of the consensus mechanism, and another is the execution of smart contracts. The improvement of the consensus mechanism increases the throughput rate of the blockchain, like DumboBFT [6], Phantasm [7], and HCA [8,9]. However, with the continuous enrichment of smart contract content and the increasing number of transactions calling smart contracts, only using a better consensus mechanism is not enough. The execution of a transaction is generally the most time-consuming phase of the entire block-processing workflow. Therefore, the execution of smart contracts is becoming another key bottleneck [16], especially the mechanism of the serial execution of smart contract transactions, which greatly limits the throughput rate of the blockchain system.

Inspired by the scheme of the database system, most of the existing solutions on parallel scheduling in smart contracts apply a directed acyclic graph (DAG) [17] to blockchain to avoid the conflict of competitive transactions.

Dickerson et al. [10] proposed that nodes need to classify smart contracts into those that can be processed in parallel and those that can only perform serial computation by using the software transaction memory method. In particular, miners execute transactions in one block in parallel, using abstract locks and inverse logs to dynamically discover conflicts and to recover from inconsistent states.

Singh et al. [11] proposed a technique to execute smart contract transactions concurrently. The scheme is achieved by employing optimistic software transactional memory systems (STMs), primarily utilized by miners. In their scheme, a miner constructs a block comprising a set of transactions, a conflict graph, the hash of the previous block, and the final state of each shared data object. Furthermore, the study introduces a concurrent validator that is designed to re-execute the same smart contracts in the same manner in parallel.

Yu et al. [12] proposed a parallel smart contract model. This scheme uses multi-thread technology to implement the proposed model, where transactions are executed in parallel. Then they proposed a transaction splitting algorithm to resolve the synchronization problem. Their scheme still has many problems to be solved. They do not have a functional way to obtain shared variables in each transaction. Not all smart contracts with shared variables will conflict when called by transactions. Only judging the conflicts between smart contracts by shared variables is not accurate.

Bartoletti et al. [13] proposed a static approximation of swappability based on a static analysis of the sets of keys read/written by transactions. Then they put forth a strategy for miners to execute multiple smart contracts concurrently. Their technique involves employing parallel computation once the node has calculated the order in which the smart contracts will be executed beforehand.

Jin et al. [18] proposed a two-phase concurrency control protocol to optimize both phases. The primary executes transactions in parallel and generates a transaction dependency graph with high parallelism for validators. Then, a graph partition algorithm is devised to divide the original graph into several sub-graphs to preserve parallelism and reduce communication costs.

Piduguralla et al. [19] implemented a directed acyclic graph (DAG)-based parallel scheduler framework in Hyperledger Sawtooth V1.2.6 for the parallel execution of smart contract transactions. This framework represents transaction dependencies in blocks through a parallel DAG data structure, which helps in throughput optimization.

Relevant prior works are based on preset conditions and assumptions to execute the smart contracts in parallel. Static analysis lacks flexibility, and over time, static analysis approaches may require periodic updates to adapt to new conditions and data. Facing this problem, we use an adaptive smart contract model to dynamically adjust the serial and parallel scheduling of contracts in our scheme. By deploying and conducting experimental verification on ChainMaker v3.0.0, our scheme can effectively improve the parallelism of transaction execution and has performance advantages in throughput and latency.

3. Preliminaries

In this section, we briefly introduce the current blockchain and the key feature field of smart contracts. Namespace, the key field in the setting of smart contracts, can be used to find conflicts between smart contracts. What is more, we introduce the read–write set, which is the most important indicator to verify the execution results of the contract.

3.1. Blockchain and Smart Contracts

Blockchain technology, characterized by its decentralized nature, has significantly enhanced the functionality and applications of smart contracts. Blockchain can be mainly divided into two types: permissionless blockchain and permissioned blockchain [20]. A permissionless blockchain is a type of blockchain that allows anyone to participate in the network without requiring explicit permission or approval from a central authority. A permissioned blockchain is a type of blockchain where access to the network is restricted and controlled by a central authority or a consortium of entities. Unlike permissionless blockchains, where anyone can participate in the consensus process, permissioned blockchains require potential participants to obtain permission to join the network. This can include the ability to read, submit transactions, or participate in the consensus process.

Smart contracts are self-executing contracts with the terms of the agreement directly written into lines of code. They operate on blockchain platforms, ensuring a high level of security and trust in the digital environment. Smart contracts run on blockchain technology, which ensures they are immutable and distributed, meaning once deployed, they cannot be altered and are accessible to all parties involved. There are many feature fields of smart contracts. We introduce the two most important fields: namespace and read–write set.

3.2. Namespace

In a blockchain system, each contract typically sets its own namespace, which serves as a basis for distinguishing the data stored in the current contract from that of other contracts. In practice, the contract name is often used as the namespace, so we can regard the namespace as a way to distinguish smart contracts. In a key-value-based blockchain storage system, the NameSpace is often used as a prefix for the key, ensuring that the keys of different contracts do not interfere with each other during actual storage.

As Figure 1 shows, there are two smart contracts on chain1 named ‘Save’ and ‘Transfer’. The storage namespaces of these two contracts are ‘/chain1/Save/’ and ‘/chain1/Transfer’.

3.3. Read–Write Set

The read–write set of contracts refers to the set of read-and-write data generated during the execution of a contract, which is abbreviated as RWSet. The structure of the read–write set is shown in Figure 2.

In contract operations, each time data are read from the ledger, a read set (ReadSet) is generated. When data need to be written to the ledger, a write set (WriteSet) is generated. ReadWriteSet is closely related to the blockchain ledger storage, and therefore their own Keys also use the contract NameSpace for isolation, which can mask the interference between ReadWriteSets of different contracts.

The structure of ReadSet is shown in Figure 3. ReadSet is mainly used to determine whether there is a data (version) conflict between concurrent transactions after the concurrent execution of contract transactions. If there is a conflict, the dependency between transactions needs to be reflected in the DAG structure, and the execution order of the conflicting transactions needs to be adjusted and re-execute the contract.

The structure of WriteSet is shown in Figure 4. After the transaction is executed normally, if the world state changes, WriteSet will record detailed change records.

4. Design

In this section, we first introduce the system model of our scheme. Before proposing the scheme, we introduce some necessary components, such as DAG-based structs and conflict factors, that we define. Then we present our scheme and the algorithms we use.

4.1. System Model

We focus on permissioned blockchain systems such as ChainMaker. Our scheme has six parts: smart contracts, transaction pools, dependency build process, transaction DAG build process, transaction parallel execution, and transaction execution process. Figure 5 shows the system model and workflow. First, we build the dependency DAG of smart contracts based on the relationship between cross-contract calls. Then, we build the transaction DAG and parallel execute the transactions. After the execution, the execution processing part checks the executed transactions and processes the conflicts. Based on the results, we update the dependency DAG and re-execute the conflict transactions.

4.2. Components

Before we show our scheme, some necessary components should be introduced first.

4.2.1. Contract Dependency DAG

Contract dependency DAG is denoted as $G=(\mathcal{V},\mathcal{E})$, where $\mathcal{V}$ represents a set of smart contracts and $\mathcal{E}$ represents a set of relationships, each of which consists of two smart contracts. The relationship means that the contract calls the pointed contract internally. There is only the unidirectional relationship in the contract dependency DAG; i.e., if contract A calls contract B (denoted by $A\to B$), then no relationship exists from contract B to contract A (denoted by $B\to A$).

4.2.2. Transaction DAG

Transaction DAG is denoted as $G=(\mathcal{V},\mathcal{E})$, where $\mathcal{V}$ represents a set of transactions that invoke contracts and $\mathcal{E}$ represents a set of orders. From node A to node B (denoted as $A\to B$), the edge represents that transaction B is executed in series after transaction A is completed. This edge indicates the serial execution order between transactions A and B. Like the transaction-dependent DAG graph, each edge of the transaction DAG is also one-way. All the transactions in the same transaction DAG should be serially executed.

4.2.3. Conflict Factors

The conflict between contracts can be described by the conflict factor, which describes the probability of conflict between two contracts and has a range of [0, 1].

We will build a sliding window for two contracts. When the transactions of these contracts conflict, we mark the conflict transaction as 1 and mark the non-conflict transaction as 0. Then we move the sliding window one position to the left, fill in the last position with the token, and update the number of conflicts and the conflict factor (Figure 6).

For a smart contract, the conflict factor can be used as a characteristic of the contract’s interdependence. Contracts with a high conflict factor are defined as strongly dependent contracts and are processed in a conflicting manner when constructing the transaction DAG. Contracts with a low conflict factor are defined as weakly dependent contracts and are processed in a non-conflicting manner when constructing the transaction DAG. Based on the conflict relationship of contract A in the above figure, the threshold value of the conflict factor for strongly dependent contracts is set to 0.6.

4.2.4. Transaction Parallelism Score/Rate

Transaction parallelism score describes the degree of parallelism of transactions in a block.

$$f(n,m)=\left\{\begin{array}{cc}n/m\hfill & (m<n)\hfill \\ 0\hfill & (m=n)\hfill \end{array}\right.$$

(1)

In the equation, n represents all the transactions in the block, and m represents the number of transactions in the longest chain of the transaction DAG. When $m=n$, all the transactions in this block should serially execute. For the same number of blocks, the greater the transaction parallelism, the higher the score.

According to the equation of transaction parallelism score, for two blocks containing 100 transactions and 10 transactions, assuming that all transactions in both blocks are parallelizable, their transaction parallelism scores are 100 and 10, respectively. However, if the CPU parallel processing capability is sufficient, their actual execution time requires the longest execution time for any transaction. In order to determine the parallelism of two blocks, we propose the transaction parallelism rate.

$$f^{\prime }(n,m)=\left\{\begin{array}{cc}(n-m)/m\hfill & (m>1)\hfill \\ 1\hfill & (m=1)\hfill \end{array}\right.$$

(2)

When $m=1$, all the transactions can parallel execute. If all the transactions in the block are serial (m = n), then the transaction parallelism rate is 0; that is, no transaction can parallel execute.

4.3. Conflict Model

During the actual execution of a transaction, regarding conflicts between transactions and the number of parallel threads, there is usually the following relationship between them, as shown in Figure 7:

The process is shown in Appendix A. Regarding the above relationship, in summary, there are two main points:

• Under the low transaction conflict model, the number of threads is proportional to TPS; that is, in an environment with low transaction conflicts, the higher the number of threads within a certain range, the better.
• Under the high transaction conflict model, the number of threads is inversely proportional to TPS; that is, in an environment with high transaction conflicts, the lower the number of threads within a certain range, the better.

The gray area in Figure 7 is the distribution of the number of threads when TPS is optimal. In practice, this range can be obtained through multiple tests. After obtaining this range, we can use this range as the rule during an actual transaction execution to determine the number of threads based on conflict situations.

4.4. Smart Contract Dependency Build

Our scheme builds the smart contract dependency from the relationship between cross-contract calls. Through careful analysis and demonstration, we propose a set of conflict contracts that consist of four parts:

• The contract itself;
• The contract’s descendant contracts (child contracts and grandchild contracts, etc.);
• The contract’s parent contracts (parent contracts, grandfather contracts, etc.);
• Other parent contracts of the contract’s descendant contracts.

As you can see in Figure 8, this is an example of smart contract dependency. Taking contract C as an example, contract C internally invokes contract A and contract B, but since other contracts also have corresponding operations, the actual conflicting contract set of contract C is {A, G, B, E, F, H}. That means that only contract D does not conflict with contract C.

The blockchain system needs to load all contracts on the current chain when the chain starts and initialize the dependencies of all contracts in the memory of the scheduling module. The details are shown as follows:

First, the blockchain system starts and initializes the scheduling module and contract dependency DAG. Then, the system will obtain the list of smart contracts from the blockchain.

Second, traverse smart contracts and use the graphs.AddNode function to build. The process of the AddNode algorithm is shown in Algorithm 1.

Algorithm 1 AddNode

1: ContractNode[] = graph.Contract.DependentContracts 2: Node = {Children: children, Parents: nil, ConfilctNodes: children} 3: if isZero(len(graph.Roots)) then 4:     graph.Roots.Init(node) 5: else 6:     for child in node.Children do 7:        it.ConflictNodes.add(child.ConflictNodes) 8:        child.Parents.add(it) 9:        if Roots.Exit(child) then 10:          Roots.remove(child) 11:       end if 12:     end for 13:     for conflictNode in node.ConflictNodes do 14:         conflictNode.ConflictNodes.add(node) 15:     end for 16:     Roots.add(node) 17:     Contracts.update() 18:     Conflicts.cache.update() 19: end if

As depicted in Algorithm 1, our proposed method manages the addition of nodes to adaptively adjust the dependency graph and handle conflicts among contracts. Initially, we initialize the contract nodes from the graph’s dependent contracts (Line 1). Subsequently, a new node is created with its children defined, no parents initially and its conflict nodes set to its children (Line 2). If the graph lacks roots, the newly created node is initialized as the root (Lines 3–4). We then process each child of the new node by adding the child’s conflict nodes to the new node’s conflict nodes, adding the new node to the child’s parents, and removing the child from the roots if it exists there (Lines 6–12). Following this, the conflict nodes of the new node have the new node added to the conflict nodes (Lines 13–15). Finally, the new node is added to the roots (Line 16), and the contracts and conflict cache of the graph are updated (Line 17).

According to this smart contract dependency, we can build the transaction DAG, which is important for the parallel scheduling of smart contracts. We will introduce the steps for building the transaction DAG in the following subsection.

4.5. Transaction DAG Building

The generation of the transaction DAG model in the block depends on the corresponding contract relationships between transactions. There are two key points to building a transaction DAG model:

• The transaction DAG construction order depends on the order in which transactions are packaged in the block. The earlier the order, the more likely it is to be executed first.
• When each transaction is added to the transaction DAG, it is judged whether it has a dependency relationship with all previous transactions. If it exists, it is added to the latest dependent transaction set.

Then we can build the transaction DAG as follows:

First, initialize the transaction DAG. Then traverse the list of transactions and build the map between the name of the contract and the set of txid. From this map, you can obtain the set of txid that invoke the contract. According to the map of txid and contract dependency, we can find all the conflict transactions of one transaction immediately. Then we can build the list of preorder conflict transactions, that is, the list of transaction IDs that conflict with it for transaction txId1, among all transactions smaller than it.

While traversing the list of transactions, we can select the transactions of the contracts that have no conflicts with any contracts and set these transactions as separate root nodes.

When building the transaction DAG, we can simplify the transaction DAG. For example, transactions A, B, and C have conflicts $A\to B$, and C is behind and conflicts with A and B. In this situation, we can only set C behind B and do not need to set C behind A in the transaction DAG. This process can simplify the transaction DAG and limit the cost of time.

4.6. Transaction Parallel Execution

After building the smart contract dependency and transaction DAG, it is time to execute the transaction in parallel. Before this, we need to set transactions into the channel that is used to distribute transactions. The processes responsible for the transaction execution will receive and process these transactions.

In order to parallel execute the transactions, the node builds and starts a process pool. Every separate DAG will be executed in one process. This method makes the transactions that have no conflict parallel executed in different processes. The conflict transactions will be executed in the same process.

4.7. Transaction Execution Processing

The transaction execution processing algorithm can check the executed transactions and process the conflicts. If the transaction has a conflict with the read–write set, we should update the smart contract dependency of this transaction and update the transaction DAG. After these steps, we need to re-execute the conflict transactions until all the transactions are successfully executed.

Then we develop the transaction execution processing algorithm. As shown in Algorithm 2, our proposed scheme can process the results of transactions to adaptively adjust the transaction DAG and the execution of transactions. First, we initialize the executed transactions and set the field of transactions as true (Line 2). Then we traverse all the completed transactions in reverse order (Line 4). If the transaction conflicts with the read–write set, we update the transaction DAG and mark the field of the transaction as false (Lines 5–7). After judging the conflict, we update the contract dependency window (Line 9).

Algorithm 2 ExectionProcessing

1: for transaction.isExecuted() do 2:     transaction.isDone = True 3: end for 4: for transaction in DoneTxs do 5:     if RWSet.isConflict(transaction) then 6:         TransactionDAG.update(transaction) 7:         transaction.isDone = False 8:     end if 9:     ConflictTable.RelationMap[contract1][contract2] = isConflict 10:    ConflictFactorWindow.update(contract1,contract2) 11:    if globalSlidingWindows.needReCul() then 12:        globalSlidingWindows.flag = True 13:     end if 14: end for 15: if DoneTxs.isEmpty() then 16:    TransactionDAG.prune(transaction) 17:    processPool.add(root) 18:    DoneTxs.add(transaction) 19:    if block.judgeTxs(DoneTxs.length()) and midDAG.isEmpty() then 20:        BlockDone() 21:    end if 22: else 23:    transaction.reSend() 24: end if 25: Algorithm End

When updating the smart contract dependency, we need to use the sliding window to record the execution results of transactions that invoke the smart contract. In this step, we add one bit for the sliding window to record. For transactions that are detected as conflicts, we write ‘1’ in this bit; otherwise, we write ‘0’. Then we calculate the conflict factor of these two contracts (Line 10). This step is the key point of adaptation in the algorithm.

Then we judge whether the global sliding window meets the conditions for calculating the conflict rate; if so, we should mark the global sliding window as to be recalculated (Lines 11–13).

If all the executed transactions are processed, we prune the transaction DAG and the node (Line 16) and add the new root to the process pool that is used to execute transactions (Line 17). If the length of the set of ‘DoneTxs’ meets the condition and there are no transactions to be distributed, we package the block (Line 19–21). If there are transactions that are not processed, we redistribute these transaction nodes (Line 23). All the algorithm is ended.

5. Evaluation

In this section, we introduce the experiment of our adaptive parallel scheduling scheme. Based on the comparative experiment, we evaluate the performance of our scheme by some evaluation indicators, such as latency and throughput. By analyzing the experimental data, we demonstrate that our protocol meets expectations and solves the research questions we proposed in Section 1.

5.1. Experiment Setup

We introduce the basic information about our experiment setup.

Baseline. We compared our scheme with a fully parallel scheduling scheme that can be recognized as the traditional scheme. In the fully parallel scheduling scheme, the smart contracts are executed in parallel, and the contracts that have conflicts will be re-executed again.

TextBed. We deployed two scheduling schemes in Tencent Cloud environments for our experiments. The compute service instance from Tencent Cloud is equipped with an AMD EPYC 7K62 48-Core Processor CPU, 16 GB of RAM, and CentOS.

Implements. We implemented our proposed adaptive parallel scheduling scheme and conducted a comparative analysis of the latency and throughput. ChainMaker is an open-source library written in Golang that implements an assemblable architecture for permissioned blockchain [21]. We forked the code of ChainMaker and rewrote the smart contract scheduling module based on the logic of our scheduling scheme.

Testflow. We built a TestChain with a single node and solo consensus algorithm. Solo is a test mode of ChainMaker that is used to conduct full-process testing except network and consensus modules for developers. We conducted six sets of experiments at varying conflict rates. Each set of experiments was designed with transaction conflict rates set at 0%, 20%, 40%, 60%, 80%, and 100%. In each experimental set, we designated the fully parallel setting as the control group and our proposed scheme as the experimental group. Experiments were conducted separately for both the control and experimental groups, with latency and throughput being recorded for each.

5.2. Evaluation Results

In this experiment, we randomly generate a batch of transactions, and each set of transactions has a different degree of conflict. Experiments under different transaction conflict rates can test the adaptability and effectiveness of scheduling solutions in various situations. We use average latency and throughput that are always used as evaluation indicators to describe the adaptability and effectiveness of a scheduling scheme. In order to obtain more accurate experimental data, we set tens of thousands of transactions in experiments with different transaction conflict rates and recorded valid data to calculate average experimental results. For average latency, as shown in Figure 9, our scheduling scheme maintains a relatively stable and fast latency level (around 100 ms). Especially, in a high transaction conflict rate, our scheme has more than 20 times improvement in latency compared with the fully parallel scheme. The reason for this result is that, in the case of a high transaction conflict rate, conflicting transactions in the fully parallel scheme need to be executed multiple times to ensure the atomicity and non-tamperability of the blockchain system. Multiple executions lead to higher latency. Our solution can adaptively adjust the transaction scheduling strategy according to the degree of transaction conflict to produce a more efficient execution plan.

For throughput, as shown in Figure 10, our solution also has stable and high-level throughput under different transaction conflict rates. As the transaction conflict rate increases in the experiment, the throughput of the fully parallel scheme decreases significantly, almost exponentially. Based on the advantages of adaptively adjusting the scheduling strategy, our scheme can maintain stable and efficient throughput (around 860 TPS) even when the conflict rate increases.

Final Results. By conducting experiments under the transaction conflict rate, we can intuitively observe that our solution has greater advantages in both latency and throughput. From the perspective of latency data, in the case of high transaction conflict rate, our solution is one-twentieth of the average time consumption of the fully parallel scheme. From the perspective of throughput data, our scheme is 30 times better than the fully parallel scheme under the condition of high transaction conflict rate. These data all show that our solution has more advantages in transaction scheduling based on the following characteristics:

• Smart contract dependency DAG from static analysis;
• Conflict model from numerous experiments;
• Dynamically parallel scheduling;
• Technical optimization in actual implementation.

6. Conclusions

We propose an adaptive parallel scheduling scheme for a smart contract. By analyzing the features of a smart contract and the setting of a smart contract on ChainMaker, we build the smart contract dependency that can be used as the execution strategy. Then we propose a conflict model from the actual execution of transactions. Based on the conflict factor we define, we build the transaction DAG and execute the transactions. After the execution, we adaptively update the conflict factor and the transaction DAG to make a better execution strategy. The implementation on ChainMaker shows that our adaptive parallel scheduling scheme achieves 30 times the throughput of the traditional fully parallel scheme and one-twentieth of the average latency. Apart from the efficiency our scheme can achieve, the following are the two additional scientifically significant features: (i) Adaptability: our scheme merges static analysis and dynamic scheduling to achieve adaptability. (ii) Applicability: our scheme can be migrated to other DAG-based blockchain platforms by adjusting the data structure and implementation interface.

In the future, we will focus on adding artificial intelligence methods to the field of smart contract transaction scheduling, and use AI to train more adaptive scheduling strategies. What is more, we will try to add an intermediate layer in the architecture to achieve cross-platform compatibility.