CN112073538A - Method and system for realizing multi-node transaction parallel execution in block chain - Google Patents
Method and system for realizing multi-node transaction parallel execution in block chain Download PDFInfo
- Publication number
- CN112073538A CN112073538A CN202011242294.0A CN202011242294A CN112073538A CN 112073538 A CN112073538 A CN 112073538A CN 202011242294 A CN202011242294 A CN 202011242294A CN 112073538 A CN112073538 A CN 112073538A
- Authority
- CN
- China
- Prior art keywords
- transaction
- block
- execution result
- consensus
- node
- 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
Images
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/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
- H04L67/025—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP] for remote control or remote monitoring of applications
-
- 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/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
-
- 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/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
Abstract
The application discloses a method and a system for realizing multi-node transaction parallel execution in a blockchain, which comprises the steps of generating a transaction according to a transaction request, and broadcasting the transaction request and the transaction to other nodes in the blockchain system; the block output node and other nodes execute the transaction according to the transaction request respectively to obtain an execution result; the block outlet node packs the first execution result and the data of the transaction into a block and sends the block to other nodes in the block chain system; other nodes recognize results together; when all consensus is completed, all nodes update the local ledger with the transaction execution results that make the consensus successful. According to the method and the device, the transaction is pre-executed at the non-block-out node, so that the non-block-out node can also pre-execute the transaction in the process of waiting for the block-out of the block-out node on the premise that the transaction time difference of the nodes in a block chain system is not large, the effect of parallel execution of the transaction at a plurality of nodes is achieved, the transaction processing capacity of the whole system is improved, and the transaction confirmation delay is reduced.
Description
Technical Field
The present invention relates to the field of blockchain technologies, and in particular, to a method and a system for implementing parallel execution of multi-node transactions in a blockchain.
Background
When the current block chain system executes transaction, the transaction is usually carried out in the mode shown in fig. 1, a block outlet node of the transaction executes the transaction first, and a transaction result is packaged into a block (step I); after the block is packed, the out-block node broadcasts the block to other non-out-block nodes in the block chain system to execute a consensus process (step two); after the successful consensus, each non-block-out node executes transaction to the received block (step three). It can be seen that, assuming a certain execution time for a tile, the identified tiles will go through at least two serial executions in the same blockchain system. When the transaction number in the block is very large, the whole execution time length is remarkably increased, the speed of the block chain common identification block is greatly influenced, and finally the transaction throughput capacity of the whole system is low and the transaction confirmation delay is remarkably improved.
The reason for this is that, in the consensus process of the current blockchain system, when the out-of-block node executes the transaction and packs the data into blocks, other non-out-of-block nodes are in a state of waiting for the out-of-block, and the consensus process must be completed, so that the CPU resources at the non-out-of-block nodes can be fully utilized, which not only wastes system resources, but also increases transaction confirmation delay. Therefore, a method for improving transaction processing capability of the blockchain system is needed.
Disclosure of Invention
The application provides a method and a system for realizing multi-node transaction parallel execution in a block chain, which are used for solving the problems of high transaction confirmation delay and insufficient transaction processing capacity of the system in the prior art.
In a first aspect, the present application provides a method for implementing parallel execution of multi-node transactions in a blockchain, including:
the method comprises the following steps that a block outlet node receives a transaction request sent by a client side and generates a plurality of transactions according to the transaction request;
broadcasting the transaction request and the transaction to other nodes in a blockchain system by the egress node;
the output block node executes the transaction according to the transaction request to obtain a first execution result corresponding to each transaction; the other nodes execute the transaction according to the received transaction request to obtain a second execution result corresponding to each transaction;
the block outlet node packs the first execution result and the data of the transaction into a block;
the out-block node sends the block to other nodes in the block chain system;
the other nodes judge whether the received block is legal or not to obtain a consensus result;
when all other nodes obtain a consensus result that the consensus is successful, all other nodes update the local ledger with the transaction execution result that the consensus is successful.
In some embodiments, the step of the other node determining whether the received block is legal or not, and obtaining the consensus result includes:
judging the transaction type of the transaction in the block;
if the transaction type is non-associated transaction, judging whether the first execution result is consistent with the second execution result, if so, taking the first execution result or the second execution result as a transaction execution result which enables the consensus to be successful, and generating a consensus result which enables the consensus to be successful; if not, generating a consensus result of consensus failure;
if the transaction type is the associated transaction, re-executing the transaction in the block according to the transaction request to obtain a third execution result, judging whether the third execution result is consistent with the first execution result, if so, taking the third execution result or the first execution result as the transaction execution result which enables the consensus to be successful, and generating a consensus result which enables the consensus to be successful; and if the two are not consistent, generating a consensus result of the consensus failure.
In some embodiments, the method of determining the transaction type of the transaction in the block comprises:
extracting a modified state value when a first execution result is generated in any transaction in the block;
if the modified state value of the transaction is the same as the modified state value generated when the first execution result is generated in any other transaction in the block, the transaction type of the transaction is a related transaction;
if the modified state value of the transaction is different from the modified state value generated when the first execution result is generated in any other transaction in the block, the transaction type of the transaction is a non-associated transaction.
In some embodiments, when the transaction type is a related transaction, the method of obtaining a third execution result includes:
acquiring a final state value of a previous transaction modification state value in the associated transaction;
and taking the final state value as the initial state value of the later transaction modification state value in the associated transaction to continue executing the transaction to obtain a third execution result.
In some embodiments, when the transaction type is a related transaction, the transactions are executed serially according to the order of the related transactions in the block, and a third execution result is obtained.
In a second aspect, the present application also provides a system corresponding to the method of the first aspect, including:
the client is used for sending a transaction request to the block output node;
a block egress node configured to perform the following method:
receiving a transaction request sent by a client, and generating a plurality of transactions according to the transaction request;
broadcasting the transaction request and the transaction to a non-out-of-block node in a blockchain system;
executing the transaction according to the transaction request to obtain a first execution result corresponding to each transaction;
packaging the first execution result and the data of the transaction into a block;
sending the block to a non-block-out node;
the system further comprises:
a plurality of non-egress block nodes located in the same blockchain system as the egress block node, each configured to perform the following method:
executing the transaction according to the received transaction request to obtain a second execution result corresponding to each transaction;
judging whether the received block is legal or not to obtain a consensus result;
and when all the non-blocked nodes obtain the consensus result of successful consensus, updating the local account book with the transaction execution result of successful consensus.
According to the method and the device, the transaction is pre-executed at the non-block-out node, so that the non-block-out node can also pre-execute the transaction in the process of waiting for the block-out of the block-out node on the premise that the transaction time difference of the nodes in a block chain system is not large, the effect of parallel execution of the transaction at a plurality of nodes is achieved, the transaction processing capacity of the whole system is improved, and the transaction confirmation delay is reduced.
Drawings
In order to more clearly explain the technical solution of the present application, the drawings needed to be used in the embodiments will be briefly described below, and it is obvious to those skilled in the art that other drawings can be obtained according to the drawings without any creative effort.
FIG. 1 is a schematic diagram of a computing unit implementing the computing method provided in the present application;
FIG. 2 is a diagram illustrating an application scenario of the method provided in the present application;
FIG. 3 is a flow chart of a method for implementing parallel execution of multi-node transactions in a blockchain according to the present application;
FIG. 4 is a schematic diagram of data flow in step S700 of the method shown in FIG. 3;
FIG. 5 is a schematic diagram illustrating a determination of transaction types for transactions in a block.
Detailed Description
Referring to fig. 2, for an application scenario diagram of the method provided by the present application, for any node in the blockchain system, when the node receives a transaction request sent by a client and needs to execute a transaction, the node may be used as a block-out node to execute operations such as transaction and block packing, and other nodes in the blockchain system may be used as non-block-out nodes corresponding to the block-out node to execute a consensus operation on the block packing and a local account book update operation. That is, the same node may be an out-of-block node or a non-out-of-block node, depending on the role in the transaction process. The method is provided based on data interaction between any one block output node and a non-block output node, a plurality of non-block output nodes corresponding to one block output node are provided, and the method can be used in the operation process between the block output node and each non-block output node.
Referring to fig. 3, a flowchart of a method for implementing parallel execution of multi-node transactions in a blockchain is provided;
as can be seen from fig. 3, the method of the present application includes:
s100: the method comprises the following steps that a block outlet node receives a transaction request sent by a client side and generates a plurality of transactions according to the transaction request;
in this embodiment, the transaction request sent by the client includes at least information of both transaction parties, transaction items and other transaction data, and one transaction request may include data of one transaction, data of several consecutive transactions of the same transaction party, data of multiple transactions of different transaction parties, and the like. For example, a merchant may receive single transaction data for one customer, multiple transaction data for the same customer, and multiple transaction data for multiple customers. When the received transaction request is a single transaction, the out-block node generates a transaction according to the transaction request, and when the received transaction request is a plurality of transactions, the out-block node generates a plurality of transactions according to the transaction request. The number of transactions is not limited in this embodiment.
In this embodiment, generating a plurality of transactions means preparing data for executing the transactions according to the transaction request, and the data may be generated by the transaction request or input by the customer at the same time as inputting the transaction request.
S200: broadcasting the transaction request and the transaction to other nodes in a blockchain system by the egress node;
in this embodiment, after the out-block node generates a plurality of transactions according to the transaction request, the execution result is not obtained by executing the transactions immediately, but the transaction request and the related data of the transactions are notified to other nodes (non-out-block nodes) in the blockchain system in a broadcast manner, so that the other nodes know that the current node is about to execute a certain transaction, and the nodes can execute a pre-transaction process on the received transaction request and the related data of the transaction in advance.
S300: the output block node executes the transaction according to the transaction request to obtain a first execution result corresponding to each transaction;
after the out-block node completes broadcasting the transaction request and the transaction information, the transaction may be executed locally at the out-block node, and in this embodiment, the transaction execution process may be summarized as three operation types: respectively, an initialization operation, an update operation, and a delete operation. For example, two pairs of key-value pairs may be used to represent each transaction operation, representing a pre-operation state value (initial state value) and a post-operation state value (final state value), respectively. When a transaction occurs and needs to update the state, the data marked by the key is updated from value to value1 by (< key, value >, < key, value1 >), initialization is used for initializing a key to value by null, and deletion is used for deleting the value pointed by the key by (< key, value >, null).
When the transaction process is completed, the execution result of the transaction, i.e. the modified status value key (abbreviated as K) when the transaction is completed, is recorded, and the status value is an important reference for determining whether the transaction is related in the present application.
S400: the other nodes execute the transaction according to the received transaction request to obtain a second execution result corresponding to each transaction;
at the same time when the above step S300 is performed, after each other node (non-out-block node) receives the transaction request, the pre-transaction process may be performed in advance, that is, step S400, at this time, the local resource of each other node may be used to perform the transaction according to the transaction request and the transaction data to obtain the transaction result (the second execution result), so that, after the block sent by the out-block node is received again, it is only necessary to verify whether the first execution result included in the block is legal by using the second execution result, and once the block is legal, the local account book may be updated without performing the transaction again.
S500: the block outlet node packs the first execution result and the data of the transaction into a block;
s600: the out-block node sends the block to other nodes in the block chain system;
the process of packaging the block can be that one transaction is packaged into one block and then sent to other nodes, or multiple transactions are packaged into blocks at one time and sent in a unified mode. Each block is as packaged as possible with the transaction and its transaction results.
S700: the other nodes judge whether the received block is legal or not to obtain a consensus result;
in this embodiment, step S700 is a process of executing consensus, and different from the prior art, since each non-blocked node in the present application has executed the pre-transaction process in advance, in the consensus process, what is needed is to determine whether the result of the pre-transaction process is the final transaction result, specifically, this step can be illustrated by the flowchart shown in fig. 4:
after the consensus process is started, firstly, the transaction type of the transaction in the block is judged; the limited transaction types in the application include two types, namely, a related transaction and a non-related transaction, wherein the related transaction refers to two different transactions (different modifications are performed on the same state value) executed on the same book data, namely, when one transaction is related to any other transaction (in the same block), the transaction is defined as the related transaction; otherwise, a transaction is not associated with any other transaction (in the same block), and the transaction is defined as an unassociated transaction.
If the transaction type is a non-associated transaction, which indicates that no connection exists between the transaction and other transactions, the transaction executed locally (non-out-of-block node) and the transaction executed at the out-of-block node can be regarded as the same transaction process, so that only a second execution result needs to be adopted to check the first execution result at this time, whether the first execution result is consistent with the second execution result is judged, if so, the first execution result or the second execution result is taken as a transaction execution result which enables the consensus to be successful, and a consensus result which enables the consensus to be successful is generated; if the data are inconsistent, the situation that the data are possibly tampered or lost and the like is shown, and a consensus result of consensus failure is generated; the consensus result needs to be fed back to the block node to indicate whether the node judges the current transaction to be a legal transaction.
If the transaction type is the associated transaction, which means that the transaction data state value of the transaction is modified at least twice, then the pre-transaction process executed by the non-transaction node no longer has the function of verifying the first execution result, and the transaction in the block must be re-executed according to the transaction request to obtain the third execution result, at this time, the relationship among the associated transactions must be considered to obtain the third execution result, and the execution process must serially execute the transactions in the associated transaction sequence to obtain the execution result.
Specifically, for the associated transaction, the method of obtaining the third execution result may be to first obtain a final state value of the previous transaction modification state value in the associated transaction; and taking the final state value as the initial state value of the later transaction modification state value in the associated transaction to continue executing the transaction to obtain a third execution result. For example, the former transaction is to modify the state value a from 1 to 10 (+ 9), and the latter transaction (to increase the state value a from 1 to 4) will actually perform the operation of modifying from 10 to 14.
After a third execution result is obtained, whether the third execution result is consistent with the first execution result is judged, if so, the third execution result or the first execution result is used as a transaction execution result which enables the consensus to be successful, and a consensus result which enables the consensus to be successful is generated; and if the two are not consistent, generating a consensus result of the consensus failure. Similarly, the consensus result needs to be fed back to the block node to indicate whether the node determines the current transaction to be a valid transaction.
Further, in the above step, the specific method for determining the transaction type of the transaction in the block may be:
extracting a modified state value K when a first execution result is generated in any transaction in the block; since there may be multiple transactions in the block, multiple K values may be extracted for the multiple transactions: k1, K2 … … Kn, as shown in FIG. 5;
if the modified state value of the transaction is the same as the modified state value generated when the first execution result is generated in any other transaction in the block, the transaction type of the transaction is a related transaction; for example, if the status values of K1 and K2 are the same in FIG. 5, then transaction A and transaction B may be considered related transactions;
if the modified state value of the transaction is different from the modified state value generated when the first execution result is generated in any other transaction in the block, the transaction type of the transaction is a non-associated transaction, and if Kn is different from the K value of any other transaction in fig. 5, the transaction N is a non-associated transaction.
In this embodiment, the process of obtaining the consensus result in step S700 substantially combines the transaction processes executed by the consensus and non-out-of-block nodes between the nodes, i.e., the consensus and non-out-of-block nodes can be considered to execute the transaction simultaneously in time, and each non-out-of-block node executes the transaction in parallel, and after the consensus is completed, the non-out-of-block node no longer needs to execute the transaction time, and can directly perform the operation of updating the local account book, thereby reducing the processing time.
In step S700, each non-block-out node may obtain a corresponding execution result and a consensus result, which need to be fed back to the block-out node, and when the block-out node receives the consensus result that all other nodes successfully obtain the consensus, the block-out node may notify the information of the end of the consensus process to each other node, and the node regards the transaction as legal and the information for updating the transaction data is legal, and continues to execute step S800: all other nodes update the local ledger with the transaction execution result that the consensus is successful, and since the transaction execution result that the consensus is successful in the previous step may be the execution result of the out-of-block node, the execution result of the non-out-of-block node, or the execution result obtained by the non-out-of-block node re-executing the transaction according to different judgment processes, the transaction execution result finally used for updating the local ledger should be selected accordingly.
According to the technical scheme, the transaction is pre-executed at the non-block-out node, so that the non-block-out node can also pre-execute the transaction in the process of waiting for the block-out of the block-out node on the premise that the transaction time of the node in a block chain system is not different much, the effect of parallel execution of the transaction at a plurality of nodes is achieved, the transaction processing capacity of the whole system is improved, and the transaction confirmation delay is reduced.
Corresponding to the method, the application also provides a system applying the method, and the system comprises the following steps:
the client is used for sending a transaction request to the block output node;
a block egress node configured to perform the following method:
receiving a transaction request sent by a client, and generating a plurality of transactions according to the transaction request;
broadcasting the transaction request and the transaction to other nodes in a blockchain system;
executing the transaction according to the transaction request to obtain a first execution result corresponding to each transaction;
packaging the first execution result and the data of the transaction into a block;
sending the block to a non-block-out node;
the system further comprises:
a plurality of non-egress block nodes located in the same blockchain system as the egress block node, each configured to perform the following method:
executing the transaction according to the received transaction request to obtain a second execution result corresponding to each transaction;
judging whether the received block is legal or not to obtain a consensus result;
and when all the non-blocked nodes obtain the consensus result of successful consensus, updating the local account book with the transaction execution result of successful consensus.
Further, the non-egress block node is further configured to:
judging the transaction type of the transaction in the block;
if the transaction type is non-associated transaction, judging whether the first execution result is consistent with the second execution result, if so, taking the first execution result or the second execution result as a transaction execution result which enables the consensus to be successful, and generating a consensus result which enables the consensus to be successful; if not, generating a consensus result of consensus failure;
if the transaction type is the associated transaction, re-executing the transaction in the block according to the transaction request to obtain a third execution result, judging whether the third execution result is consistent with the first execution result, if so, taking the third execution result or the first execution result as the transaction execution result which enables the consensus to be successful, and generating a consensus result which enables the consensus to be successful; and if the two are not consistent, generating a consensus result of the consensus failure.
Further, the non-egress block node is further configured to:
extracting a modified state value when a first execution result is generated in any transaction in the block;
if the modified state value of the transaction is the same as the modified state value generated when the first execution result is generated in any other transaction in the block, the transaction type of the transaction is a related transaction;
if the modified state value of the transaction is different from the modified state value generated when the first execution result is generated in any other transaction in the block, the transaction type of the transaction is a non-associated transaction.
Further, the non-egress block node is further configured to:
acquiring a final state value of a previous transaction modification state value in the associated transaction;
and taking the final state value as the initial state value of the later transaction modification state value in the associated transaction to continue executing the transaction to obtain a third execution result.
Further, the non-egress block node is further configured to:
and when the transaction type is the associated transaction, serially executing the transactions according to the sequence of the associated transactions in the block to obtain a third execution result.
The system in this embodiment may refer to the description in the method embodiment when executing the method, and is not described herein again.
Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the invention and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.
Claims (10)
1. A method for enabling parallel execution of multi-node transactions in a blockchain, the method comprising:
the method comprises the following steps that a block outlet node receives a transaction request sent by a client side and generates a plurality of transactions according to the transaction request;
broadcasting the transaction request and the transaction to other nodes in a blockchain system by the egress node;
the output block node executes the transaction according to the transaction request to obtain a first execution result corresponding to each transaction; the other nodes execute the transaction according to the received transaction request to obtain a second execution result corresponding to each transaction;
the block outlet node packs the first execution result and the data of the transaction into a block;
the out-block node sends the block to other nodes in the block chain system;
the other nodes judge whether the received block is legal or not to obtain a consensus result;
when all other nodes obtain a consensus result that the consensus is successful, all other nodes update the local ledger with the transaction execution result that the consensus is successful.
2. The method of claim 1, wherein the other nodes performing the validity determination on the received block to obtain the consensus result comprises:
judging the transaction type of the transaction in the block;
if the transaction type is non-associated transaction, judging whether the first execution result is consistent with the second execution result, if so, taking the first execution result or the second execution result as a transaction execution result which enables the consensus to be successful, and generating a consensus result which enables the consensus to be successful; if not, generating a consensus result of consensus failure;
if the transaction type is the associated transaction, re-executing the transaction in the block according to the transaction request to obtain a third execution result, judging whether the third execution result is consistent with the first execution result, if so, taking the third execution result or the first execution result as the transaction execution result which enables the consensus to be successful, and generating a consensus result which enables the consensus to be successful; and if the two are not consistent, generating a consensus result of the consensus failure.
3. The method of claim 2, wherein determining the transaction type for the transaction in the block comprises:
extracting a modified state value when a first execution result is generated in any transaction in the block;
if the modified state value of the transaction is the same as the modified state value generated when the first execution result is generated in any other transaction in the block, the transaction type of the transaction is a related transaction;
if the modified state value of the transaction is different from the modified state value generated when the first execution result is generated in any other transaction in the block, the transaction type of the transaction is a non-associated transaction.
4. The method of claim 3, wherein when the transaction type is an associated transaction, the method of obtaining a third execution result comprises:
acquiring a final state value of a previous transaction modification state value in the associated transaction;
and taking the final state value as the initial state value of the later transaction modification state value in the associated transaction to continue executing the transaction to obtain a third execution result.
5. The method of claim 3, wherein when the transaction type is a related transaction, the transactions are executed serially according to the order of the related transactions in the block, resulting in a third execution result.
6. A system for enabling parallel execution of multi-node transactions in a blockchain, the system comprising:
the client is used for sending a transaction request to the block output node;
a block egress node configured to perform the following method:
receiving a transaction request sent by a client, and generating a plurality of transactions according to the transaction request;
broadcasting the transaction request and the transaction to a non-out-of-block node in a blockchain system;
executing the transaction according to the transaction request to obtain a first execution result corresponding to each transaction;
packaging the first execution result and the data of the transaction into a block;
sending the block to a non-block-out node;
the system further comprises:
a plurality of non-egress block nodes located in the same blockchain system as the egress block node, each configured to perform the following method:
executing the transaction according to the received transaction request to obtain a second execution result corresponding to each transaction;
judging whether the received block is legal or not to obtain a consensus result;
and when all the non-blocked nodes obtain the consensus result of successful consensus, updating the local account book with the transaction execution result of successful consensus.
7. The system of claim 6, wherein the non-egress block node is further configured to:
judging the transaction type of the transaction in the block;
if the transaction type is non-associated transaction, judging whether the first execution result is consistent with the second execution result, if so, taking the first execution result or the second execution result as a transaction execution result which enables the consensus to be successful, and generating a consensus result which enables the consensus to be successful; if not, generating a consensus result of consensus failure;
if the transaction type is the associated transaction, re-executing the transaction in the block according to the transaction request to obtain a third execution result, judging whether the third execution result is consistent with the first execution result, if so, taking the third execution result or the first execution result as the transaction execution result which enables the consensus to be successful, and generating a consensus result which enables the consensus to be successful; and if the two are not consistent, generating a consensus result of the consensus failure.
8. The system of claim 7, wherein the non-egress block node is further configured to:
extracting a modified state value when a first execution result is generated in any transaction in the block;
if the modified state value of the transaction is the same as the modified state value generated when the first execution result is generated in any other transaction in the block, the transaction type of the transaction is a related transaction;
if the modified state value of the transaction is different from the modified state value generated when the first execution result is generated in any other transaction in the block, the transaction type of the transaction is a non-associated transaction.
9. The system of claim 8, wherein the non-egress block node is further configured to:
acquiring a final state value of a previous transaction modification state value in the associated transaction;
and taking the final state value as the initial state value of the later transaction modification state value in the associated transaction to continue executing the transaction to obtain a third execution result.
10. The system of claim 8, wherein the non-egress block node is further configured to:
and when the transaction type is the associated transaction, serially executing the transactions according to the sequence of the associated transactions in the block to obtain a third execution result.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011242294.0A CN112073538A (en) | 2020-11-10 | 2020-11-10 | Method and system for realizing multi-node transaction parallel execution in block chain |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011242294.0A CN112073538A (en) | 2020-11-10 | 2020-11-10 | Method and system for realizing multi-node transaction parallel execution in block chain |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112073538A true CN112073538A (en) | 2020-12-11 |
Family
ID=73655614
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011242294.0A Pending CN112073538A (en) | 2020-11-10 | 2020-11-10 | Method and system for realizing multi-node transaction parallel execution in block chain |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112073538A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113535849A (en) * | 2021-07-08 | 2021-10-22 | 电子科技大学 | Extensible consensus method for block chain |
| CN113568981A (en) * | 2021-09-24 | 2021-10-29 | 腾讯科技（深圳）有限公司 | Transaction data processing method, device, equipment and medium |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107678865A (en) * | 2017-09-20 | 2018-02-09 | 中国银行股份有限公司 | The verification method and system of block chain based on transaction packet |
| CN107833060A (en) * | 2017-11-13 | 2018-03-23 | 中国银行股份有限公司 | The verification method and system of intelligent contract transaction in a kind of block chain |
| CN108647966A (en) * | 2018-05-09 | 2018-10-12 | 深圳市融讯科技有限公司 | A kind of data interactive method and device based on block chain |
| CN108846659A (en) * | 2018-06-13 | 2018-11-20 | 深圳前海微众银行股份有限公司 | Transfer account method, device and storage medium based on block chain |
| CN109242467A (en) * | 2018-09-17 | 2019-01-18 | 金蝶软件（中国）有限公司 | Network-building method, device, computer equipment and storage medium based on block chain |
| CN110825755A (en) * | 2019-10-30 | 2020-02-21 | 北京海益同展信息科技有限公司 | Block chain consensus method, consensus node, electronic device, and storage medium |
| CN111159295A (en) * | 2019-12-28 | 2020-05-15 | 深圳市网心科技有限公司 | Block chain system, data storage method, data storage device, data storage apparatus, and computer-readable medium |
| CN111526167A (en) * | 2020-07-06 | 2020-08-11 | 南京可信区块链与算法经济研究院有限公司 | Data transmission method and device applied to block chain |
-
2020
- 2020-11-10 CN CN202011242294.0A patent/CN112073538A/en active Pending
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107678865A (en) * | 2017-09-20 | 2018-02-09 | 中国银行股份有限公司 | The verification method and system of block chain based on transaction packet |
| CN107833060A (en) * | 2017-11-13 | 2018-03-23 | 中国银行股份有限公司 | The verification method and system of intelligent contract transaction in a kind of block chain |
| CN108647966A (en) * | 2018-05-09 | 2018-10-12 | 深圳市融讯科技有限公司 | A kind of data interactive method and device based on block chain |
| CN108846659A (en) * | 2018-06-13 | 2018-11-20 | 深圳前海微众银行股份有限公司 | Transfer account method, device and storage medium based on block chain |
| CN109242467A (en) * | 2018-09-17 | 2019-01-18 | 金蝶软件（中国）有限公司 | Network-building method, device, computer equipment and storage medium based on block chain |
| CN110825755A (en) * | 2019-10-30 | 2020-02-21 | 北京海益同展信息科技有限公司 | Block chain consensus method, consensus node, electronic device, and storage medium |
| CN111159295A (en) * | 2019-12-28 | 2020-05-15 | 深圳市网心科技有限公司 | Block chain system, data storage method, data storage device, data storage apparatus, and computer-readable medium |
| CN111526167A (en) * | 2020-07-06 | 2020-08-11 | 南京可信区块链与算法经济研究院有限公司 | Data transmission method and device applied to block chain |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113535849A (en) * | 2021-07-08 | 2021-10-22 | 电子科技大学 | Extensible consensus method for block chain |
| CN113535849B (en) * | 2021-07-08 | 2023-03-07 | 电子科技大学 | Extensible consensus method for block chain |
| CN113568981A (en) * | 2021-09-24 | 2021-10-29 | 腾讯科技（深圳）有限公司 | Transaction data processing method, device, equipment and medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111080449B (en) | Cross-chain transaction method of blockchain, management node and blockchain network | |
| CN108492183B (en) | Block chain account transaction method, system and computer readable storage medium | |
| CN112073538A (en) | Method and system for realizing multi-node transaction parallel execution in block chain | |
| CN111049696B (en) | Method, node and computing device for node management of blockchain system | |
| CN111026367B (en) | Micro-service arrangement method, device, terminal equipment and storage medium | |
| CN110599177A (en) | Transaction verification method and related equipment | |
| CN111008206A (en) | Method and device for storing state data of cross-chain transaction and storage medium | |
| CN112583811A (en) | Wallet retrieving method, equipment and storage medium | |
| CN111507714B (en) | Verification method, verification device, server and storage medium | |
| CN107038025B (en) | SOA architecture-based system calling method and device | |
| CN114612101A (en) | Reliable inter-link route cross-link method and system for connection | |
| CN112734410B (en) | Method and device for pre-executing chain code in Fabric Block chain | |
| CN112396427B (en) | Cross-chain interchange operation method for general scenes | |
| CN110691122A (en) | Parallel chain consensus method, device and storage medium | |
| CN111143041B (en) | Data consistency method, distributed coordinator and central coordinator | |
| CN113254467B (en) | Method and blockchain node for performing transactions in blockchain system | |
| CN112995344B (en) | Block chain all-in-one machine, and chain crossing method and device and storage medium of multiple nodes in block chain all-in-one machine | |
| CN111754348A (en) | Scene combined transaction method and device | |
| US20100082762A1 (en) | Message tying processing method and apparatus | |
| CN112395104A (en) | Method and device for realizing transmission of distributed transaction context at routing layer | |
| CN115145997A (en) | Distributed transaction implementation method and distributed system | |
| CN113610527A (en) | Alliance chain transaction method, device, system, terminal device and storage medium | |
| CN112950349A (en) | Method and system for processing exception of orthogonal time sequence of base distributed system | |
| CN113052607A (en) | Multi-chain management method and system based on collaboration chain and work chain decoupling | |
| CN111581446B (en) | Graph relation generation method, device, system, equipment and storage medium |
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 | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20201211 |
|
| RJ01 | Rejection of invention patent application after publication |