CN116450316A - Method, device, electronic equipment and storage medium for parallel transaction processing - Google Patents
Method, device, electronic equipment and storage medium for parallel transaction processing Download PDFInfo
- Publication number
- CN116450316A CN116450316A CN202310413970.3A CN202310413970A CN116450316A CN 116450316 A CN116450316 A CN 116450316A CN 202310413970 A CN202310413970 A CN 202310413970A CN 116450316 A CN116450316 A CN 116450316A
- Authority
- CN
- China
- Prior art keywords
- transaction
- task
- execution
- current
- tasks
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 77
- 238000012545 processing Methods 0.000 title claims abstract description 58
- 238000012795 verification Methods 0.000 claims abstract description 48
- 230000001419 dependent effect Effects 0.000 claims description 30
- 230000008569 process Effects 0.000 claims description 25
- 230000005540 biological transmission Effects 0.000 claims description 2
- 238000010586 diagram Methods 0.000 description 6
- 238000004891 communication Methods 0.000 description 5
- 238000005516 engineering process Methods 0.000 description 4
- 238000007781 pre-processing Methods 0.000 description 4
- 238000013459 approach Methods 0.000 description 2
- 238000013508 migration Methods 0.000 description 2
- 230000005012 migration Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 238000010200 validation analysis Methods 0.000 description 2
- 238000003491 array Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000003139 buffering effect Effects 0.000 description 1
- 238000004422 calculation algorithm Methods 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000014509 gene expression Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000003672 processing method Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Abstract
The application provides a method, a device, electronic equipment and a storage medium for parallel transaction processing, which relate to the technical field of blockchain and comprise the following steps: the method is applied to a blockchain system, wherein the blockchain system comprises a scheduling node and a plurality of working threads which are executed in parallel; the method comprises the following steps: generating a transaction task through a scheduling node, and sending the transaction task to a task queue; the method comprises the steps that transaction tasks of a task queue are obtained through a working thread, parallel processing is carried out on the transaction tasks, and execution results of each execution version of each transaction task are cached into a multi-version data structure; and carrying out transaction conflict verification on the current transaction task through the working thread, and sending an execution result of the current transaction task to the scheduling node when the transaction is verified to be conflict-free, so that the scheduling node submits the execution result. When the method and the device are used for carrying out parallel transaction processing, the processing efficiency of parallel execution and the accuracy of the execution result are improved, transaction conflict is avoided, and the safe submission of the transaction is ensured.
Description
Technical Field
The present disclosure relates to the field of blockchain technologies, and in particular, to a method, an apparatus, an electronic device, and a storage medium for parallel transaction processing.
Background
In the existing transaction execution engine of the ethernet workshop, for consistency before and after block execution, a sequential execution mode is generally adopted for processing. In order to improve the processing efficiency, there are also parallel execution methods in the related art, such as an execution scheme based on a directed acyclic graph (Directed Acyclic Graph, DAG). However, this approach builds a DAG dependency graph of transactions prior to execution, requiring that the transactions be analyzed or executed first; and the DAG parallel result and the sequential execution result may not be consistent, so that the certainty and repeatability of the parallel execution cannot be guaranteed.
Disclosure of Invention
The purpose of the application is to provide a method, a device, electronic equipment and a storage medium for parallel transaction processing, which promote the processing efficiency of parallel execution and the accuracy of an execution result when the parallel transaction processing is carried out, avoid transaction conflict and ensure that the transaction is submitted safely.
In a first aspect, the present invention provides a method of transaction parallel processing, the method being applied to a blockchain system including a scheduling node and a plurality of worker threads executing in parallel; the method comprises the following steps:
generating a transaction task through the scheduling node, and sending the transaction task to a task queue;
the working thread acquires the transaction tasks of the task queue, processes the transaction tasks in parallel, and caches the execution results of each execution version of each transaction task into a multi-version data structure;
and carrying out transaction conflict verification on the current transaction task through the working thread, and sending an execution result of the current transaction task to the dispatching node when the fact that the transaction has no conflict is verified, so that the dispatching node submits the execution result.
In a second aspect, the present invention provides an apparatus for parallel processing of transactions, the method being applied to a blockchain system including a scheduling node and a plurality of worker threads executing in parallel; the device comprises:
the task generation and transmission module is used for generating transaction tasks through the scheduling node and transmitting the transaction tasks to a task queue;
the parallel processing and result caching module is used for acquiring transaction tasks of the task queue through the working thread, carrying out parallel processing on the transaction tasks, and caching the execution result of each execution version of each transaction task into a multi-version data structure;
and the verification and transaction submitting module is used for carrying out transaction conflict verification on the current transaction task through the working thread, and sending the execution result of the current transaction task to the dispatching node when the verification transaction has no conflict, so that the dispatching node submits the execution result.
In a third aspect, the invention provides an electronic device comprising a processor and a memory storing computer executable instructions executable by the processor to implement the method of transaction parallel processing of any of the preceding embodiments.
In a fourth aspect, the present invention provides a computer readable storage medium storing computer executable instructions which, when invoked and executed by a processor, cause the processor to implement a method of parallel processing of transactions according to any of the preceding embodiments.
The method, the device, the electronic equipment and the storage medium for parallel transaction processing have the beneficial effects that:
executing the transaction task through the parallel working thread, caching the execution result into a multi-version data structure, temporarily not submitting the transaction, performing conflict verification on the transaction task, and submitting the execution result after verification is conflict-free, thereby ensuring that no conflict exists between transactions when the transaction task is processed in parallel, and finally being submitted safely.
The method does not need a preprocessing stage of the DAG scheme before execution and ensures the certainty of parallel execution results, improves the processing efficiency of parallel execution and the accuracy of the execution results when carrying out transaction parallel processing, avoids transaction conflict and ensures that the transaction is submitted safely.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are needed in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are some embodiments of the present application, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 is a schematic diagram of a scheduling node and a plurality of worker threads according to an embodiment of the present disclosure;
FIG. 2 is a schematic diagram of a transaction flow according to an embodiment of the present disclosure;
FIG. 3 is a flow chart of a method for parallel transaction processing according to an embodiment of the present application;
FIG. 4 is a block diagram of an apparatus for parallel transaction processing according to an embodiment of the present application;
fig. 5 is a block diagram of an electronic device according to an embodiment of the present application.
Detailed Description
For the purposes of making the objects, technical solutions and advantages of the embodiments of the present application more clear, the technical solutions of the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is apparent that the described embodiments are some embodiments of the present application, but not all embodiments. The components of the embodiments of the present application, which are generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations.
Thus, the following detailed description of the embodiments of the present application, as provided in the accompanying drawings, is not intended to limit the scope of the application, as claimed, but is merely representative of selected embodiments of the application. All other embodiments, which can be made by one of ordinary skill in the art based on the embodiments herein without making any inventive effort, are intended to be within the scope of the present application.
It should be noted that: like reference numerals and letters denote like items in the following figures, and thus once an item is defined in one figure, no further definition or explanation thereof is necessary in the following figures.
Term interpretation:
blockchain: a distributed account book technology realized by taking a distributed fault tolerance technology as a principle is characterized in that log data (namely block data) is stored through a chained structure, a common algorithm is used for determining the block data finally submitted, and the block data finally completes the modification of the account book data by an intelligent contract formed by an automatic script, so that the distributed account book technology is a new distributed basic facility and calculation paradigm.
Transaction execution engine: blockchains are essentially distributed state machines, with migration of states being accomplished through the input, execution, of transactions. Typically, execution of transactions on the blockchain is done inside the virtual machine, eventually updating the results onto the blockchain state, enabling the migration of the overall state.
In the prior art, for example, in a transaction execution engine of an ethernet, for consistency of block execution before and after, a sequential execution mode is adopted, and concurrency capability of multi-core and multi-thread of a modern computer cannot be fully utilized. In a few platforms adopting parallel execution engines, such as FISCO, DAG execution schemes are introduced, and a transaction dependency graph is constructed according to mutually exclusive resources involved in transaction execution, wherein the dependency graph organizes transactions in a DAG mode. Judging whether the transaction represented by the node has dependence according to the relationship between the outbound degree and the inbound degree of the DAG graph node, and if not, directly distributing the transaction to available parallel threads for execution; if there is a dependency, the transaction execution of the outbound node associated with the inbound side needs to be waited for to be completed before the transaction execution can be executed.
However, building a DAG dependency graph of transactions prior to execution requires analyzing or otherwise executing the transactions first; 2. the DAG parallel results may not be consistent with the sequential execution results. The certainty and repeatability of the parallel execution cannot be guaranteed.
Based on the above, the embodiment of the application provides a method, a device, an electronic device and a storage medium for parallel transaction processing, which do not need a preprocessing stage of a DAG scheme before execution and ensure the certainty of parallel execution results, and when parallel transaction processing is performed, the processing efficiency of parallel execution and the accuracy of the execution results are improved, transaction conflicts are avoided, and the safe submission of the transaction is ensured.
The embodiment of the application provides a transaction parallel processing method, which is applied to a blockchain system, wherein the blockchain system comprises a scheduling node and a plurality of working threads which are executed in parallel, as shown in fig. 1, the blockchain system presets one scheduling node and a plurality of working threads, the scheduling node is responsible for generating tasks and submitting transaction execution results, the working threads are responsible for acquiring the tasks generated by the scheduling node and executing the tasks, and the executed execution results are returned to the scheduling node, so that the parallel execution of the transaction is completed through cooperation of the scheduling node and the plurality of working threads.
When the method and the device are executed in parallel, the software transactional memory is used for recording the update of each transaction to the state, the read set of each transaction is verified after the execution is completed, if verification fails, the states related to the transaction are proved to have conflicts in reading and writing, the dependency relationship is built by utilizing conflict information, and the failed transaction is re-executed until the execution of the transaction in the block is completed. The overall execution scheme is divided into two execution phases from transaction execution to being committed: an optimistic execution phase and a verify-re-execution phase:
(1) Optimistic execution phase: the dispatching node distributes all transactions to a working thread for execution, the status is updated and read through a read-write set record in the execution, and if the execution is successful, the write set is recorded into a multi-version data structure (the realization of a software transaction memory); if the execution fails, a dependency relationship is built according to the failed read-write information, and the transaction with the failed execution waits for re-execution.
Because the optimistic execution strategy is adopted, the parallel threads directly take the execution task to execute, update values of states are cached through the software transaction memory, and the dependency relationship of transactions is dynamically built in the execution process, so that the time for preprocessing transactions to build the DAG graph is reduced, and the parallel efficiency is improved.
(2) Verification-re-execution phase: when the optimistic execution of all the transactions is completed, the scheduling node distributes verification tasks of the transactions to the worker threads according to the execution results, and each thread verifies whether the read set of the current transaction conflicts with the write set of all the transactions preceding the current transaction in a preset sequence. If a transaction conflicts, the writing set of the transaction in the multi-version data structure is updated to be effective state information, then the transaction is re-executed, and the transaction with the preset sequence larger than that of the current transaction is re-verified.
Fig. 2 shows a schematic diagram of a transaction flow, the principle followed by the execution of a transaction: 1) Optimistic execution, the first time all transactions are executed, all transactions that do not produce dependencies are executed; 2) Only transactions that fail verification or fail execution are repeated. The principle followed by transaction verification: if verification fails, only higher transactions in the preset serial order need to be re-verified.
For easy understanding, the initialization parameters used in this embodiment will be described first:
1.[tx 1 ，tx 2 ，tx 3 ，...tx n ]n transactions.
Mvdata: the multi-version data structure is a hash Map, mvdata= < k, v >. Wherein, k= (location, tx.s), where location is the reading position of the variable in the virtual machine, and tx.s is the preset serial number of the transaction; v= (version, value), version is the current execution version, each execution process generates a new version number, value is the value written in the location by the execution transaction tx of version; if v=aborded, the value indicating that writing the location position was terminated when executing transaction tx;
3. the read set rs is a data pair array of a read variable position and a version in the transaction execution process, and is recorded as rs= { (location, version) }, location, version.
4. The write set ws is a data pair array of writing variable positions and values in the transaction execution process, and is recorded as ws= { (location, value) }, location, value.
5. The latest version of read set lastRead is the last successfully executed read set array of the transaction in the current execution block, and is denoted as lastread= { { ws }, wherein |lastread|=n, and n is the number of transactions in the block.
6. The latest version write set lastWrite is an array of write position sets successfully executed last time for transactions in the current execution block, and is denoted as lastwrite= { { location| (location) ∈ws }, where |lastwrite|=n.
7. The transaction dependence set des is a set of transaction reading positions dependent on other transaction writing positions in the current intra-block transaction execution process, and is recorded as ps= { tx 0 ，tx 1 ,..}, where |deps|=n, deps [0 ]]＝{tx 0 ，tx 1 ,..} reading position dependent transaction tx during execution for transaction tx.s=0 0 ，tx 1 .., etc.
8. Task queue T: including validation tasks and execution tasks.
9. Execution result queue R: including the execution results.
10. Verifying a successful transaction set V: including verifying a successful transaction.
Aborted is state information valid in the multi-version data structure mvData, mvDdata [ k ] is updated at the time of verification conflict, i.e., mvData [ k ] = Aborted.
Referring to fig. 3, the method for parallel processing of transactions mainly includes the following steps S310 to S330:
step S310, generating a transaction task through the scheduling node, and sending the transaction task to the task queue.
Step S320, the transaction tasks of the task queue are obtained through the working thread, the transaction tasks are processed in parallel, and the execution result of each execution version of each transaction task is cached to the multi-version data structure.
And step S330, carrying out transaction conflict verification on the current transaction task through the working thread, and sending the execution result of the current transaction task to the dispatching node when the transaction is verified to be conflict-free, so that the dispatching node submits the execution result.
In specific implementation, an initialization process is first performed:
initializing:
block＝[tx 1 ，tx 2 ，tx 3 ，...tx n ]n transactions, wherein the sequence of transaction index numbers is a preset sequence and is recorded as s;
mvData, multi-version data structure;
lastWrite, lastRead, the latest version of the read/write set;
deps, recording a dependent transaction set of each transaction;
a task queue T containing verification tasks and execution tasks;
an execution result queue R containing execution results;
verifying a successful transaction set V, which comprises the transactions successfully verified;
minv=int_max, the minimum verification success transaction sequence number s, initialized to the maximum value int_max;
minc=0, the minimum submittal transaction sequence number s (here implicit use of minc sequence number means submitting a collection of transactions, all transactions < minc in the collection);
the execution task of the transaction of block (generation version number version=0) is added to the queue T.
From this point on, the initialization process execution is completed.
When parallel processing of transactions is performed, for a scheduling node, if an execution result queue R is not empty and |v|noteqn is not equal, that is, after a transaction is started, a transaction task result tx=tx in the execution result queue R is obtained i 。
For the execution result: if the execution result is successful, updating the multi-version data structure mvData according to the version and the write set ws, and simultaneously updating the lastWrite with the read-write set ws, rs in the read/write set of the latest version of lastRead; and is transaction tx i Generating a verification task and adding the verification task to a task queue T; if the execution result fails, the transaction tx i Version number version+1 of the execution task is re-added to the task queue T;
for the verification result: if failure occurs: update minv=min (tx i S, minv), and will be less than tx in set V i S, transaction generation verification tasks are added to a task queue T; if successful and minc=i+1, commit the transaction, update the dependent transaction set deps with respect to txiDependency term (deps [ tx ] j .s]＝{...，tx i ,.. }/tx_i; otherwise, adding to the verification success transaction set V.
In an optional embodiment, the step S320, which obtains the transaction task of the task queue through the work thread, and processes the transaction task in parallel, may include the following steps 2-1 to 1-3:
step 2-1, acquiring transaction tasks of a task queue through each working thread, and inquiring whether dependent items of the transaction tasks in the transaction dependent set are empty in parallel; the transaction dependence set is a set in which each transaction reading position depends on other transaction writing positions in the current intra-block transaction execution process in the blockchain system;
step 2-2, if the transaction task is empty, determining that the transaction task is successfully executed, and collecting a success state and corresponding first reading and writing to an execution result queue;
and 2-3, if the result is not null, determining that the execution of the transaction task fails, exiting the transaction task, and returning the failure state and the corresponding second read-write set to the execution result queue.
In one example, when executing a trading task, a worker thread first obtains a task in a task queue T, and executes a trade tx=tx in the task i The method comprises the steps of carrying out a first treatment on the surface of the Query transaction tx i Dependency of deps [ tx ] i .s]If not, returning a failure result to an execution result queue R; in the execution process, if the variable reading is generated, the variable reading is directly performed to mvData through the location, if the variable writing is generated, the written variable and the position are recorded in ws, and the read variable and the version number also need to be recorded in rs. If Aborted is read, at deps [ tx ] i .s]Record of the Aborted transaction tx j As tx i The dependency term of (1) exits and returns the execution failure result and the read-write set ws, rs to an execution result queue R; if the execution is successful, returning a successful result and the read-write set ws, rs to the execution result queue R.
Further, if the current transaction task cannot be executed, determining a target transaction task generating effective state information as a transaction dependent item of the current transaction task, and caching the target transaction task to a transaction dependent set; the target transaction task and the current transaction task have a corresponding relation in the transaction dependency set.
Each write set is recorded during execution of the transaction. Meanwhile, if the data is read, firstly reading the data into a multi-version data structure, and if the data is not read, reading the data into a storage; if the read to Aborted indicates that the lower write variable for that location is terminated. Therefore, the current transaction cannot be operated, dependence is added to the current transaction by utilizing the Aborted information, no operation is needed as the reading is terminated, a failure result is directly returned at the moment, and the transaction needs to wait for the dependent item to finish and then continue to operate.
In one embodiment, when the transaction tasks are processed in parallel through the working thread, if the transaction tasks are successfully executed, the state update information of each transaction task is cached into a multi-version data structure; if the transaction task fails to be executed, a dependency relationship between the transaction tasks is built based on the failed read-write information in the execution process of the transaction task, and the transaction task with the failed execution waits for being executed again. This approach may be re-executed only for transaction tasks that failed to execute.
Step S330, performing transaction conflict verification on the current transaction task by the working thread, and when it is verified that the transaction has no conflict, sending the execution result of the current transaction task to the scheduling node, where in implementation, the method may include the following steps 3-1 to 3-3:
step 3-1, each working thread reads the state update information of the current transaction task in the multi-version data structure;
step 3-2, carrying out transaction conflict verification on the current transaction task based on the state update information so as to verify whether the dependent item of the current transaction task is successfully executed;
and step 3-3, if the current transaction task is executed, sending an execution result of the current transaction task to the scheduling node.
For the step 3-2, performing transaction conflict verification on the current transaction task based on the state update information may further include a step 3-2.1 and a step 3-2.2:
step 3-2.1, verifying whether the read set of the current transaction task has transaction conflict with the write sets of all transactions occurring before the current transaction task in a preset sequence based on the state update information; the reading set is a data pair array for reading variable positions and variable versions in the transaction execution process, and the writing set is a data pair array for writing variable positions and variable values in the transaction execution process.
Specifically, each working thread reads a history version number corresponding to a current transaction task from a read set of the multi-version data structure based on state update information; if the historical version numbers are not equal to the current version numbers according to a preset sequence, the transaction conflicts, and the fact that the dependent items of the current transaction task are not successfully executed is determined; if the historical version number is equal to the current version number, the transaction does not conflict, and it is determined that the dependent item of the current transaction task is successfully executed.
And 3-2.2, if the transaction conflicts, updating state update information corresponding to the current transaction task in the multi-version data structure, re-executing the current transaction task, and re-verifying other transaction tasks with the preset sequence larger than that of the current transaction task.
In a specific embodiment, the worker thread first obtains lastRead TX when executing validation of transaction tx= txi in execution tasks i .s]Transaction tx in i Is a latest read set rs; reading the value variable of the corresponding location in the mvData according to rs again, if the version is not equal to the version in the current rs, then conflicting, and describing the transaction tx i After execution, mvData is updated, verification fails, according to lastWrite [ tx ] i .s]Setting transactions in mvData (, tx) i S) is Aborted, and returns a verification failure result to the execution result queue R; if the version is the same as the version in the current rs, the version is not in conflict. And (5) passing the verification, and returning a verification passing result to the execution result queue R.
During the concurrent execution, an optimistic execution strategy is adopted, and the transaction is verified after execution. Thus, the execution of the transaction will not succeed once, will be performed multiple times, and in order to ensure the correctness of the verification, the write set of each execution version of each transaction is recorded using the multi-version data structure, and the transaction is not submitted temporarily. The multi-version data structure can be verified with the read set of other transactions in the subsequent verification process, so that no conflict is ensured, and the multi-version data structure is finally submitted safely.
Transaction verification is to ensure that dependent items of the read set of the transaction currently being verified are successfully executed. Aborted or version inconsistencies occur in the data at the same location in the multi-version data structure if the location read in the last executed read set of the current transaction. Description: 1) The dependent transaction write set is terminated and the data of the write location is not available; 2) The write set version of the relied transaction is updated and the current dependent version is not available. Whereby verification fails, and the write set of the current verification transaction becomes unavailable, the write set of the current version of the current transaction in the multi-version data structure needs to be updated to Aborted. Meanwhile, since the preset serial order is adopted as the guarantee of repeatability, all transactions with all preset orders larger than the current transaction need to be re-verified.
According to the embodiment of the application, the transaction parallel processing is carried out based on the software transactional memory, the state is not directly updated in the transaction execution process, and the record writing set is carried out by utilizing the multi-version data structure. After passing the verification, the write sets in the multi-version data structure need to be submitted one by the scheduling node according to a preset sequence. And finally completing the execution and submission of the transaction.
Based on the method embodiment, the embodiment of the application also provides a device for parallel transaction processing, the method is applied to a blockchain system, and the blockchain system comprises a scheduling node and a plurality of working threads which are executed in parallel; referring to fig. 4, the device mainly comprises the following parts:
a task generating and transmitting module 42, configured to generate a transaction task through the scheduling node, and transmit the transaction task to the task queue;
the parallel processing and result caching module 44 is configured to obtain a transaction task of the task queue through a working thread, perform parallel processing on the transaction task, and cache an execution result of each execution version of each transaction task to a multi-version data structure;
the verification and transaction submitting module 46 is configured to perform transaction conflict verification on the current transaction task through the worker thread, and send an execution result of the current transaction task to the scheduling node when it is verified that the transaction has no conflict, so that the scheduling node submits the execution result.
According to the transaction parallel processing device provided by the embodiment of the application, the transaction tasks are executed through the parallel working threads, the execution results are cached to the multi-version data structure, the transaction is not submitted temporarily, conflict verification is carried out on the transaction tasks, and the execution results are submitted after verification is carried out, so that no conflict exists between transactions when the transaction tasks are processed in parallel, and finally the transaction tasks are submitted safely. Therefore, the preprocessing stage of the DAG scheme before execution is not needed, the certainty of parallel execution results is ensured, the processing efficiency of parallel execution and the accuracy of the execution results are improved when the transaction is processed in parallel, transaction conflict is avoided, and the transaction is ensured to be submitted safely.
In a possible embodiment, the parallel processing and result buffering module 44 is further configured to: when the transaction tasks are processed in parallel through the working thread, if the transaction tasks are successfully executed, the state update information of each transaction task is cached into a multi-version data structure;
the device further comprises a dependency relationship construction module, which is used for: if the transaction task fails to be executed, a dependency relationship between the transaction tasks is built based on the failed read-write information in the execution process of the transaction task, and the transaction task with the failed execution waits for being executed again.
In one possible embodiment, the verification and transaction submission module 46 is further configured to: each working thread reads the state update information of the current transaction task in the multi-version data structure; carrying out transaction conflict verification on the current transaction task based on the state updating information so as to verify whether the dependent item of the current transaction task is successfully executed; and if the current transaction task is executed, sending an execution result of the current transaction task to the scheduling node.
In one possible embodiment, the verification and transaction submission module 46 is further configured to: verifying whether a read set of the current transaction task has transaction conflicts with write sets of all transactions occurring before the current transaction task in a preset sequence based on the state update information; the reading set is a data pair array for reading variable positions and variable versions in the transaction execution process, and the writing set is a data pair array for writing variable positions and variable values in the transaction execution process; if the transaction conflicts, updating state updating information corresponding to the current transaction task in the multi-version data structure, re-executing the current transaction task, and re-verifying other transaction tasks with the preset sequence larger than that of the current transaction task.
In one possible embodiment, the verification and transaction submission module 46 is further configured to: each working thread reads a history version number corresponding to the current transaction task from a read set of the multi-version data structure based on the state update information; if the historical version numbers are not equal to the current version numbers according to a preset sequence, the transaction conflicts, and the fact that the dependent items of the current transaction task are not successfully executed is determined; if the historical version number is equal to the current version number, the transaction does not conflict, and it is determined that the dependent item of the current transaction task is successfully executed.
In one possible implementation, the parallel processing and result caching module 44 is further configured to: acquiring transaction tasks of the task queue through each working thread, and inquiring whether dependent items of the transaction tasks in the transaction dependent set are empty in parallel; the transaction dependence set is a set in which each transaction reading position depends on other transaction writing positions in the current intra-block transaction execution process in the blockchain system; if the transaction task is empty, determining that the transaction task is successfully executed, and collecting the success state and the corresponding first reading and writing to an execution result queue; if the result is not null, determining that the transaction task fails to be executed, exiting the transaction task, and returning the failure state and the corresponding second read-write set to an execution result queue.
In a possible embodiment, the above device further comprises: a dependent item caching module for: if the current transaction task cannot be executed, determining the target transaction task generating the valid state information as a transaction dependent item of the current transaction task, and caching the target transaction task into a transaction dependent set; the target transaction task and the current transaction task have a corresponding relation in the transaction dependency set.
The implementation principle and the technical effects of the transaction parallel processing device provided in the embodiment of the present application are the same as those of the foregoing method embodiment, and for brevity description, reference may be made to corresponding contents in the foregoing method embodiment of transaction parallel processing where an embodiment portion of the transaction parallel processing device is not mentioned.
The embodiment of the present application further provides an electronic device, as shown in fig. 5, which is a schematic structural diagram of the electronic device, where the electronic device 100 includes a processor 51 and a memory 50, where the memory 50 stores computer executable instructions that can be executed by the processor 51, and the processor 51 executes the computer executable instructions to implement a method for parallel processing of any of the foregoing transactions.
In the embodiment shown in fig. 5, the electronic device further comprises a bus 52 and a communication interface 53, wherein the processor 51, the communication interface 53 and the memory 50 are connected by the bus 52.
The memory 50 may include a high-speed random access memory (RAM, random Access Memory), and may further include a non-volatile memory (non-volatile memory), such as at least one magnetic disk memory. The communication connection between the system network element and at least one other network element is achieved via at least one communication interface 53 (which may be wired or wireless), and the internet, wide area network, local network, metropolitan area network, etc. may be used. Bus 52 may be an ISA (Industry Standard Architecture ) bus, a PCI (Peripheral Component Interconnect, peripheral component interconnect standard) bus, or EISA (Extended Industry Standard Architecture ) bus, among others. The bus 52 may be classified as an address bus, a data bus, a control bus, or the like. For ease of illustration, only one bi-directional arrow is shown in FIG. 5, but not only one bus or type of bus.
The processor 51 may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware in the processor 51 or by instructions in the form of software. The processor 51 may be a general-purpose processor, including a central processing unit (Central Processing Unit, CPU for short), a network processor (Network Processor, NP for short), etc.; but also digital signal processors (Digital Signal Processor, DSP for short), application specific integrated circuits (Application Specific Integrated Circuit, ASIC for short), field-programmable gate arrays (Field-Programmable Gate Array, FPGA for short) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in connection with the embodiments of the present application may be embodied directly in hardware, in a decoded processor, or in a combination of hardware and software modules in a decoded processor. The software modules may be located in a random access memory, flash memory, read only memory, programmable read only memory, or electrically erasable programmable memory, registers, etc. as well known in the art. The storage medium is located in a memory, and the processor 51 reads the information in the memory, and in combination with its hardware, performs the steps of the method of parallel processing of transactions of the previous embodiment.
The embodiment of the application further provides a computer readable storage medium, where the computer readable storage medium stores computer executable instructions, where the computer executable instructions, when being called and executed by a processor, cause the processor to implement the method for parallel processing of transactions, and the specific implementation may refer to the foregoing method embodiment and will not be repeated herein.
The method, apparatus, electronic device and computer program product of storage medium for parallel transaction processing provided in the embodiments of the present application include a computer readable storage medium storing program code, where instructions included in the program code may be used to execute the method described in the foregoing method embodiment, and specific implementation may refer to the method embodiment and will not be described herein.
The relative steps, numerical expressions and numerical values of the components and steps set forth in these embodiments do not limit the scope of the present application unless specifically stated otherwise.
The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a non-volatile computer readable storage medium executable by a processor. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art or in a part of the technical solution, in the form of a software product stored in a storage medium, including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a magnetic disk, or an optical disk, or other various media capable of storing program codes.
In the description of the present application, it should also be noted that, unless explicitly specified and limited otherwise, the terms "connected," "connected," and "connected" are to be construed broadly, and may be either fixedly connected, detachably connected, or integrally connected, for example; can be mechanically or electrically connected; can be directly connected or indirectly connected through an intermediate medium, and can be communication between two elements. The specific meaning of the terms in this application will be understood by those of ordinary skill in the art in a specific context.
Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some or all of the technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present application.
Claims (10)
1.A method of transaction parallel processing, wherein the method is applied to a blockchain system that includes a scheduling node and a plurality of worker threads executing in parallel; the method comprises the following steps:
generating a transaction task through the scheduling node, and sending the transaction task to a task queue;
the working thread acquires the transaction tasks of the task queue, processes the transaction tasks in parallel, and caches the execution results of each execution version of each transaction task into a multi-version data structure;
and carrying out transaction conflict verification on the current transaction task through the working thread, and sending an execution result of the current transaction task to the dispatching node when the fact that the transaction has no conflict is verified, so that the dispatching node submits the execution result.
2. The method of parallel processing of transactions according to claim 1, wherein said method further comprises:
when the transaction tasks are processed in parallel through the working thread, if the transaction tasks are successfully executed, the state update information of each transaction task is cached to the multi-version data structure;
if the transaction task fails to be executed, a dependency relationship between the transaction tasks is built based on the failed read-write information in the execution process of the transaction task, and the transaction task with the failed execution waits for being executed again.
3. The method for parallel processing of transactions according to claim 2, wherein said executing, by said worker thread, transaction conflict verification of a current transaction task, and when it is verified that there is no conflict in the transaction, the execution result of the current transaction task is sent to said scheduling node, comprising:
each working thread reads the state update information of the current transaction task in the multi-version data structure;
carrying out transaction conflict verification on the current transaction task based on the state updating information so as to verify whether the dependent item of the current transaction task is successfully executed;
and if the current transaction task is executed, sending an execution result of the current transaction task to the scheduling node.
4. A method of parallel processing of transactions according to claim 3 wherein said verifying of transaction conflicts for current transaction tasks based on said status update information comprises:
verifying whether a read set of the current transaction task has transaction conflict with write sets of all transactions occurring before the current transaction task in a preset sequence based on the state update information; the reading set is a data pair array for reading variable positions and variable versions in the transaction execution process, and the writing set is a data pair array for writing variable positions and variable values in the transaction execution process;
if the transaction conflicts, updating the state updating information corresponding to the current transaction task in the multi-version data structure, re-executing the current transaction task, and re-verifying other transaction tasks with the preset sequence larger than that of the current transaction task.
5. The method of parallel transaction processing according to claim 4, wherein verifying whether a read set of a current transaction task has a transaction conflict with a write set of all transactions occurring prior to the current transaction task in a preset order based on the status update information comprises:
each working thread reads a history version number corresponding to the current transaction task from a read set of the multi-version data structure based on the state update information;
if the historical version numbers are not equal to the current version numbers according to a preset sequence, the transaction conflicts, and the fact that the dependent items of the current transaction task are not successfully executed is determined;
if the historical version number is equal to the current version number, the transaction does not conflict, and it is determined that the dependent item of the current transaction task is successfully executed.
6. The method for parallel processing of transactions according to claim 1, wherein obtaining transaction tasks of said task queue by said worker thread, said transaction tasks being processed in parallel, comprises:
acquiring transaction tasks of the task queue through each working thread, and inquiring whether dependent items of the transaction tasks in the transaction dependent set are empty in parallel; wherein the transaction dependence set is a set in which each transaction reading position depends on other transaction writing positions in the current intra-block transaction execution process in the blockchain system;
if the transaction task is empty, determining that the transaction task is successfully executed, and collecting the success state and the corresponding first reading and writing to an execution result queue;
if the result is not null, determining that the transaction task fails to be executed, exiting the transaction task, and returning the failure state and the corresponding second read-write set to an execution result queue.
7. The method of parallel processing of transactions according to claim 1, wherein said method further comprises:
if the current transaction task cannot be executed, determining a target transaction task generating effective state information as a transaction dependent item of the current transaction task, and caching the target transaction task into a transaction dependent set; wherein the target transaction task and the current transaction task have a correspondence in the transaction dependency set.
8. An apparatus for parallel processing of transactions, the apparatus being applied to a blockchain system including a scheduling node and a plurality of worker threads executing in parallel; the device comprises:
the task generation and transmission module is used for generating transaction tasks through the scheduling node and transmitting the transaction tasks to a task queue;
the parallel processing and result caching module is used for acquiring transaction tasks of the task queue through the working thread, carrying out parallel processing on the transaction tasks, and caching the execution result of each execution version of each transaction task into a multi-version data structure;
and the verification and transaction submitting module is used for carrying out transaction conflict verification on the current transaction task through the working thread, and sending the execution result of the current transaction task to the dispatching node when the verification transaction has no conflict, so that the dispatching node submits the execution result.
9. An electronic device comprising a processor and a memory, the memory storing computer executable instructions executable by the processor, the processor executing the computer executable instructions to implement the method of transaction parallel processing of any of claims 1 to 7.
10. A computer readable storage medium storing computer executable instructions which, when invoked and executed by a processor, cause the processor to implement the method of parallel processing of transactions of any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310413970.3A CN116450316A (en) | 2023-04-10 | 2023-04-10 | Method, device, electronic equipment and storage medium for parallel transaction processing |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310413970.3A CN116450316A (en) | 2023-04-10 | 2023-04-10 | Method, device, electronic equipment and storage medium for parallel transaction processing |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116450316A true CN116450316A (en) | 2023-07-18 |
Family
ID=87119747
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310413970.3A Pending CN116450316A (en) | 2023-04-10 | 2023-04-10 | Method, device, electronic equipment and storage medium for parallel transaction processing |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116450316A (en) |
-
2023
- 2023-04-10 CN CN202310413970.3A patent/CN116450316A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107528882B (en) | Method and device for processing consensus request in block chain consensus network and electronic equipment | |
| WO2021036253A1 (en) | Method and device for executing transactions in parallel in blockchain | |
| CN113743950B (en) | Method, node and blockchain system for performing transactions in blockchain system | |
| US9280348B2 (en) | Decode time instruction optimization for load reserve and store conditional sequences | |
| WO2021036254A1 (en) | Method and apparatus for concurrently executing transactions in blockchain | |
| CN110648124B (en) | Method and apparatus for concurrently executing transactions in a blockchain | |
| TWI733390B (en) | Method and device for simultaneously executing transactions in block chain, computer readable storage medium and computing equipment | |
| US20150370554A1 (en) | Providing code change job sets of different sizes to validators | |
| CN113157710B (en) | Block chain data parallel writing method and device, computer equipment and storage medium | |
| CN115237444A (en) | Concurrent control method, device and equipment based on version number and storage medium | |
| CN109597697B (en) | Resource matching processing method and device | |
| CN110689344B (en) | Method and apparatus for concurrently executing transactions in a blockchain | |
| CN113743943A (en) | Method for executing transaction in block chain, main node and slave node | |
| US20100180024A1 (en) | Reducing occurrences of two-phase commits in a multi-node computing system | |
| CN110706108B (en) | Method and apparatus for concurrently executing transactions in a blockchain | |
| CN116450316A (en) | Method, device, electronic equipment and storage medium for parallel transaction processing | |
| US20150052305A1 (en) | Arithmetic processing device, arithmetic processing method and arithmetic processing system | |
| CN114331440A (en) | Conflict detection and performance optimization method and device | |
| CN113743949A (en) | Method for executing transaction in block chain, main node and slave node | |
| CN110175182B (en) | Data checking method and device | |
| WO2021057165A1 (en) | Method for concurrently executing transactions in blockchain, and device | |
| CN115203218A (en) | Method for solving problem of inconsistent consensus when block link points process transaction in parallel | |
| CN110865874B (en) | Transaction commit method and device | |
| KR20220116655A (en) | System of speculative transaction execution for Blockchain scalability and method thereof | |
| US20230342775A1 (en) | Adaptive block processor for blockchain machine compute acceleration engine |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |