Smart contract parallel optimization execution method for stateless consensus

Abstract

A parallel optimization execution method for smart contracts with ownerless consensus is proposed. In the pre-execution phase, each node pre-executes requests in parallel according to its local world state, records key information, generates an ordered list, analyzes dependencies, and generates a directed acyclic graph (DAG) which is then added to the block proposal. Nodes broadcast their pre-execution dependencies, optimal scheduling method, and request set through consensus. In the execution phase, requests are executed with maximum parallelism according to the pre-execution dependencies. When a dependency update is detected, the updated request is re-executed. If the new read / write set changes compared to the pre-execution result, requests requiring re-execution are sorted by their index and executed sequentially. The execution results of requests that have finished execution and do not need to be re-executed are updated to the world state, completing the request submission. This invention, through a simple, effective, and easily implemented re-execution scheme, places requests with changed read / write sets at the end of the replay phase for sequential re-execution. This optimizes the performance of parallel execution while ensuring the serializability of parallel execution semantics, and also avoids the high overhead and difficulty in implementing request rollback.

Description

Technical Field

[0001] This invention relates to a technology in the field of smart contracts, specifically a parallel optimization execution method for smart contracts oriented towards ownerless consensus. Background Technology

[0002] For masterless consensus algorithms and horizontally scalable architectures, the main challenge and opportunity of parallel execution of smart contracts lies in maximizing the processing power of multi-core and multi-machine architectures to execute user requests with the highest possible parallelism while ensuring the serializability of the blockchain. Existing parallel execution methods for smart contracts can be broadly categorized into two types based on their order of execution with consensus: late scheduling and early scheduling. In late scheduling, nodes directly initiate consensus on the request, and other nodes attempt to execute the consensus result in parallel. If conflicts arise, execution is re-executed. In early scheduling, the master node pre-executes the request and then initiates consensus on the pre-execution result. Slave nodes then execute the request in parallel based on the pre-execution result. Summary of the Invention

[0003] This invention addresses the problems of existing delayed scheduling methods, which cannot pre-observe dependencies between requests and can only perform blind and limited parallelism, leading to high-frequency execution conflicts and request rollbacks. It also addresses the lack of conflict detection and error recovery mechanisms in pre-scheduling methods when errors occur. To solve these problems, this invention proposes a parallel optimization execution method for smart contracts based on a masterless consensus mechanism. This method significantly improves the parallelism of request execution during replay and avoids the need for request rollbacks. Employing a masterless consensus module, multiple nodes in the distributed system can participate in pre-execution analysis and complete data reading I / O operations and subsequent request block pre-execution analysis during the consensus process, fully utilizing the hardware performance of each node in multi-machine scaling scenarios. Through a simple, effective, and easy-to-implement re-execution scheme, this invention places requests with changed read / write sets at the end of the replay stage for serial re-execution. This optimizes the performance of parallel execution while maintaining the serializability semantics of parallel execution, and also avoids the high overhead and difficulty in implementing request rollbacks.

[0004] This invention is achieved through the following technical solution:

[0005] This invention relates to a parallel optimization execution method for smart contracts with ownerless consensus. In the pre-execution phase, each node pre-executes requests in parallel according to its local world state, records key information, generates an ordered list, analyzes dependencies, generates a directed acyclic graph (DAG), and puts it into the block proposal. Nodes broadcast the dependencies, optimal scheduling method, and request set obtained during pre-execution through consensus. In the execution phase, requests are executed with maximum parallelism according to the dependencies obtained during pre-execution. When an update to a dependency is detected, the updated request is re-executed. When the new read / write set changes compared to the pre-execution result, the requests that need to be re-executed are sorted by their index and executed sequentially. The execution results of requests that have finished execution and do not need to be re-executed are updated to the world state, thus completing the submission of the request.

[0006] The block proposal refers to: constructing a request set using a batch of user requests, packaging the request set, the pre-execution results of the request set (i.e., the read / write set obtained after pre-execution), and the DAG indicating the dependencies and execution order between requests into a block as a complete proposal.

[0007] The aforementioned broadcasting via consensus means that each node ensures that all nodes receive consistent proposal content and, when there are multiple proposals, receive a consistent proposal order through message passing.

[0008] This invention relates to a system for implementing the above method, comprising: a pre-execution unit, a masterless consensus unit, and a replay unit, wherein: the pre-execution unit executes requests in parallel based on the local initial state maintained by the nodes and the content of user requests, obtains read / write sets for each request, sorts the request list according to the read / write sets, analyzes the dependencies between requests, and then generates a DAG indicating the execution order of the requests; the masterless consensus unit packages the request set and the pre-execution result into a block to generate a complete proposal, and ensures that all nodes can obtain consistent proposal content and proposal order through the information transmission of the masterless consensus; the replay unit obtains the request set and the pre-execution result from the proposal result of the masterless consensus unit, executes and submits requests in parallel according to the DAG, and if the read / write set of a request has changed compared to the pre-execution, the request is re-executed at the end of the replay. Technical effect

[0009] This invention presents a smart contract parallel execution framework consisting of pre-execution, masterless consensus, and replay, which solves the problem that existing parallel execution schemes cannot be compatible with masterless consensus, thereby improving the speed of smart contract parallel execution and the throughput of system requests. Attached Figure Description

[0010] Figure 1 This is a flowchart of the present invention;

[0011] Figure 2 This is a flowchart of an implementation example;

[0012] Figure 3 The flowchart is re-executed for the example. Detailed Implementation

[0013] like Figure 1 As shown, this embodiment relates to a parallel optimization execution method for smart contracts with ownerless consensus, including:

[0014] Step 1) Pre-execution phase: Before constructing blocks, each node pre-executes requests in parallel according to its local world state, records the read / write sets and generates an ordered list, analyzes dependencies and generates a directed acyclic graph (DAG) to be put into the block proposal for subsequent consensus.

[0015] The ordered list refers to the following: The number of requests accessing each given key is counted, and these requests are grouped into dependency chains. These chains are then sorted according to their length, with requests from longer chains preceding those from shorter chains, resulting in an ordered list of requests. In this list, requests with smaller indices have higher execution priority than those with larger indices.

[0016] The analysis refers to determining the dependencies between requests based on the read / write set and the ordered list, and constructing a directed acyclic graph (DAG) accordingly to indicate the execution order of transactions.

[0017] The dependencies include: Read-Before-Write (WAR), Write-Before-Write (WAW), and Read-Before-Read (RAW), where: when a write request has the same key as a read request, the corresponding positions of these two requests in the DAG are marked as WAR dependencies; the other two types of dependencies are marked in a similar manner.

[0018] When there are multiple dependencies between two requests, WAW will be given priority. When two requests have both WAR and RAW dependencies, they will be considered to have a WAW dependency.

[0019] The block proposal refers to: constructing a request set using a batch of user requests, packaging the request set, the pre-execution results of the request set (i.e., the read / write set obtained after pre-execution), and the DAG indicating the dependencies and execution order between requests into a block as a complete proposal.

[0020] Step 2) Each node broadcasts its pre-execution dependencies, optimal scheduling method and request set through consensus, and ensures that all correct nodes can obtain consistent proposal content and proposal order. That is, each node passes messages to ensure that all nodes can obtain consistent proposal content and consistent proposal order when there are multiple proposals.

[0021] Step 3) After consensus is reached, each node executes requests with maximum parallelism according to the dependencies obtained before execution. When a dependency update is detected, the updated request is re-executed to ensure serializable semantics. Specifically, each node obtains a request block and its DAG from the consensus module and executes and submits requests in batches. Figure 3 As shown, during the replay phase, each node executes requests tx1, tx2, and tx4 in parallel first, based on the read / write set of each request obtained in the pre-execution phase, because they do not depend on previous requests; tx4 newly writes the key 'a', so it is re-executed at the end; requests tx3, tx5, and tx6 are executed in parallel and, because there is no WAW, are committed in parallel when they are completed. The execution result is equivalent to executing tx1, tx2, tx5, tx3, tx6, and tx4 in sequence.

[0022] The batch processing mentioned above refers to the parallel execution and submission of requests in the same batch, that is, each node continuously retrieves a batch of requests without forward dependencies from the request list, and then executes each of them in parallel.

[0023] The request without forward dependencies refers to: 1) the request has no WAW dependency on any pending preceding request, and 2) the request has no WAR or RAW dependency on any pending preceding request.

[0024] The re-execution refers to the following: when the new read / write set changes compared to the pre-execution result, the requests that need to be re-executed are sorted according to their index and executed sequentially; the execution results of the requests that have finished execution and do not need to be re-executed are updated to the world state, and the submission of the requests is completed.

[0025] The re-execution mentioned above occurs at the end of the replay phase;

[0026] Preferably, when the requested read / write set changes, but fewer keys are accessed during the replay phase, it does not necessarily lead to re-execution; that is, re-execution is not required. Specifically, all keys accessed during the pre-execution phase are combined and then judged.

[0027] 1) When a request reads / writes a new key, and other requests also access this key during the pre-execution phase, the request is likely to introduce new dependencies. In this case, the request will be re-executed.

[0028] 2) When a request reads a new key 'a' that other requests did not access during the pre-execution phase, it may not necessarily introduce a new dependency, but the request must wait for the preceding request to complete. If a preceding request has already written to key 'a', the request will be executed again immediately; otherwise, the request can be committed.

[0029] 3) When a request writes to a new key b that other requests did not access during the pre-execution phase, it may affect previous writes and subsequent reads. Therefore, the request must also wait for the preceding request to complete before it can be submitted.

[0030] Through specific practical experiments, this invention was implemented using a Golang-written smart contract library with Go-Ethereum as the codebase, combined with the Ethereum Virtual Machine (EVM) for request execution. Ethereum transaction data was used as test data. The masterless consensus mechanism was implemented using the HoneyBadger BFT algorithm (Andrew Miller, Yu Xia, Kyle Croman, Elaine Shi, and DawnSong. 2016. The Honey Badger of BFT Protocols. In Proceedings of the 2016 ACMSIGSAC Conference on Computer and Communications Security (Vienna, Austria) (CCS'16). Association for Computing Machinery, New York, NY, USA, 31–42. https: / / doi.org / 10.1145 / 2976749.2978399). The system was deployed on the Amazon EC2 platform using an m6i.4xlarge instance, which uses an Intel Xeon Ice Lake 8375C processor with 16 vCPUs, 64GB RAM, and Ubuntu as the operating system. 20.04 LTS. With 4 nodes, the system's request throughput is 20k transactions / s, which is 6.4 times faster than serial execution; with 10 nodes, the system's request throughput is 24k transactions / s, which is 6.9 times faster than serial execution.

[0031] Compared to the Block-STM algorithm, which employs delayed scheduling and does not pre-obtain the read / write sets and dependencies of requests, this invention allows for blind and limited parallel execution. Execution is re-executed whenever a conflict occurs, resulting in low parallelism and the possibility of a single request being repeatedly re-executed, impacting system performance. This invention, by pre-analyzing the dependencies between requests, allows for flexible adjustment of the execution order, achieving higher parallelism.

[0032] This invention obtains the requested read / write set within the block during the pre-execution phase. Therefore, when reaching consensus on the block, the data that needs to be read and written can be pre-read, saving IO overhead in the replay phase. Compared with Block-STM, it has a closer cooperation with consensus.

[0033] Compared to the PEEP algorithm, which controls whether a request can be executed by locking, this invention addresses the issue of lock management being costly and significantly impacting system performance. Instead, it constructs a Directed Acyclic Graph (DAG) based on the dependencies between requests and then controls the execution order of requests according to the DAG, resulting in a more efficient and faster approach than lock management.

[0034] PEEP lacks a re-execution strategy. To ensure the serializable semantics of parallel execution, a fully accurate set of read / write requests is required before parallel execution begins. This invention, however, proposes a simple and effective re-execution scheme that guarantees the correctness of parallel execution even when pre-execution analysis is not precise enough.

[0035] The algorithm was compared with the existing OCC algorithm (Yi Lu, Xiangyao Yu, Lei Cao, and Samuel Madden. 2020. Aria: A Fast and Practical Deterministic OLTP Database. Proc. VLDBEndow. 13, 12 (jul 2020), 2047–2060. https: / / doi.org / 10.14778 / 3407790.3407808). In a 4-node system, OCC's request execution speed is 2.7 times that of serial execution, while the present invention achieves 6.4 times the speed. In a 10-node system, OCC's request execution speed is 2.8 times that of serial execution, while the present invention achieves 6.9 times the speed.

[0036] In summary, this invention can be implemented in any distributed system and consortium blockchain system and significantly improves request execution speed.

[0037] The above-described specific implementations can be partially adjusted by those skilled in the art in different ways without departing from the principles and purpose of the present invention. The scope of protection of the present invention is defined by the claims and is not limited to the above-described specific implementations. All implementation schemes within the scope of the claims are bound by the present invention.

Claims

1. A method for parallel optimization execution of smart contracts oriented to stateless consensus, characterized in that, During the pre-execution phase, each node pre-executes requests in parallel according to its local world state, records key information, generates an ordered list, analyzes dependencies, generates a directed acyclic graph (DAG), and puts it into the block proposal. The nodes broadcast the dependencies, optimal scheduling method, and request set obtained during pre-execution through consensus. During the execution phase, requests are executed with maximum parallelism according to the dependencies obtained during pre-execution. When a dependency update is detected, the updated request is re-executed. When the new read / write set changes compared to the result of pre-execution, the requests that need to be re-executed are sorted by their index and executed sequentially. The execution results of the requests that have finished execution and do not need to be re-executed are updated to the world state, and the submission of the request is completed. The block proposal mentioned above refers to: constructing a request set with a batch of user requests, packaging the request set, the pre-execution result of the request set (i.e., the read / write set obtained after pre-execution), and the DAG indicating the dependencies and execution order between requests into a block as a complete proposal; The aforementioned broadcasting via consensus means that each node ensures that all nodes receive consistent proposal content and, when there are multiple proposals, receive a consistent proposal order through message passing. The ordered list refers to: counting the number of requests accessing each given key, grouping them into dependency chains, sorting them according to the length of different chains, placing requests in longer chains before requests in shorter chains, and obtaining an ordered list of requests; in this list, requests with smaller indices have higher execution priority than requests with larger indices. Each node obtains a request block and its DAG from the consensus module, and executes and submits the request in batch. During the replay phase, each node executes requests tx1, tx2, and tx4 in parallel first, based on the read / write set of each request obtained in the pre-execution phase, because they do not depend on the previous requests. tx4 newly wrote the key 'a', so it was re-executed at the end; tx3, tx5, and tx6 were requested to be executed in parallel and, since there was no WAW, were committed in parallel when they were completed. The execution result was equivalent to executing tx1, tx2, tx5, tx3, tx6, and tx4 in the order of tx1, tx2, tx5, tx3, tx6, and tx4. The batch processing mentioned above refers to the parallel execution and submission of requests in the same batch, that is, each node continuously retrieves a batch of requests without forward dependencies from the request list, and then executes each of them in parallel.

2. The method of claim 1, wherein the method is characterized in that include: Step 1) Pre-execution phase: Before constructing blocks, each node pre-executes requests in parallel according to its local world state, records the read / write sets and generates an ordered list, analyzes dependencies and generates a directed acyclic graph (DAG) to be put into the block proposal for subsequent consensus. The analysis refers to: determining the dependencies between requests based on the read / write set and the ordered list, and constructing a directed acyclic graph (DAG) accordingly to indicate the execution order of transactions; The dependencies include: Read-then-Write (WAR), Write-then-Write (WAW), and Read-then-Read (RAW). Specifically: when a request writes a key that is the same as a previous request reads a key, the corresponding positions of these two requests in the DAG are marked as WAR dependencies. The other two types of dependencies are marked in a similar way. When multiple dependencies exist between two requests, WAW dependencies are given priority, and when two requests have both WAR and RAW dependencies, they are considered to have a WAW dependency. Step 2) Each node broadcasts its pre-execution dependencies, optimal scheduling method and request set through consensus, and ensures that all correct nodes can obtain consistent proposal content and proposal order. That is, each node passes messages to ensure that all nodes can obtain consistent proposal content and consistent proposal order when there are multiple proposals. Step 3) After consensus is reached, each node executes the request with maximum parallelism according to the dependencies obtained in the pre-execution, and re-executes the updated request when a dependency update is detected, so as to ensure serializable semantics; The aforementioned request without forward dependencies means that: 1) the request has no WAW dependency on any pending preceding request, and 2) the request has no WAR or RAW dependency on any pending preceding request; The re-execution refers to: when the new read / write set changes compared to the pre-execution result, the requests that need to be re-executed are sorted by their index and executed sequentially; the execution results of the requests that have finished execution and do not need to be re-executed are updated to the world state, and the submission of the requests is completed. The re-execution mentioned above occurs at the end of the replay phase.

3. The parallel optimization execution method for smart contracts oriented towards ownerless consensus as described in claim 2, characterized in that, When the requested read / write set changes, but fewer keys are accessed during the replay phase, it doesn't necessarily lead to re-execution; that is, re-execution is unnecessary. Specifically, all keys accessed during the pre-execution phase are combined and then evaluated. 1) If a request reads / writes a new key, and other requests also access this key during the pre-execution phase, then the request is likely to introduce new dependencies. In this case, the request will be re-executed. 2) When a request reads a new key 'a' that other requests did not access during the pre-execution phase, it may not necessarily introduce a new dependency, but the request must wait for the preceding request to complete. If a preceding request has already written to key 'a', the request will be executed again immediately; otherwise, the request can be submitted. 3) When a request writes to a new key b that other requests did not access during the pre-execution phase, it may affect previous writes and subsequent reads. Therefore, the request must also wait for the preceding request to complete before it can be submitted.

4. A parallel optimized execution system for smart contracts oriented towards ownerless consensus, implementing the method of any one of claims 1-3, characterized in that, include: The system consists of a pre-execution unit, a masterless consensus unit, and a replay unit. The pre-execution unit executes requests in parallel based on the local initial state maintained by the nodes and the content of user requests, obtaining read / write sets for each request. It sorts the request list according to the read / write sets, analyzes the dependencies between requests, and then generates a DAG indicating the execution order of the requests. The masterless consensus unit packages the request set and the pre-execution results into a block to generate a complete proposal. Through the information transmission of the masterless consensus, it ensures that all nodes can obtain consistent proposal content and proposal order. The replay unit obtains the request set and pre-execution result from the proposal results of the masterless consensus unit, executes and submits the request in parallel according to the DAG. If the read / write set of a request to be executed changes compared to the pre-execution, the request is re-executed at the end of the replay.

Images