Block chain system transaction processing method and device

Abstract

The invention provides a block chain system transaction processing method and device. The method comprises the steps that a leader node generates a DDT candidate list and broadcasts the DDT candidate list to all consensus nodes; each consensus node sequentially executes each transaction according to the DDT candidate list, judges whether each transaction is completed within the validity period, determines execution result information of each consensus node and feeds back the execution result information to the leader node; the leader node identifies valid transactions in the DDT candidate list according to the execution result information of each consensus node, generates a valid transaction table, and broadcasts the valid transaction table to all the consensus nodes; the consensus node performs a consensus process according to the transaction validity table to obtain a consensus result; and each consensus node packages each effective transaction in the consensus result to generate a new block, adds the new block to a local account book, and updates the states related to the transactions. The success rate of processing the DDT transaction by the system is improved, and the transaction demand of the user is met.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a blockchain system transaction processing method and device for transactions with a latest completion time requirement. Background Art

[0002] In auctions, elections, bidding and other scenarios, transactions often have a deadline for completion, and transactions must be completed within the validity period. We call this type of transaction DDT (deadline-driven transaction). After the validity period of the DDT transaction, the business logic of the transaction will lose its meaning or the original processing requirements of the transaction will no longer exist, and the transaction will become an invalid transaction. Even if the invalid transaction is packaged and uploaded to the chain, it will be useless. At the same time, the processing of invalid transactions will lead to a waste of blockchain system resources. The DDT type of transaction application scenario puts forward new service requirements for the blockchain system - that is, to schedule transaction processing according to the latest completion time of the transaction, and complete the transaction as soon as possible before the transaction deadline. Transactions that cannot be completed within the validity period will affect the user experience of such applications carried by the blockchain, and even seriously damage the availability of such services.

[0003] However, existing blockchain systems assume that transactions have no deadline by default, that is, no matter when the system processes a transaction, the transaction is valid. In addition, these blockchain systems often aim to maximize the overall transaction processing performance, namely TPS (transaction per second), and are unable to meet new service requirements for transactions to be completed within a specified deadline.

[0004] As mentioned above, using the existing blockchain system to directly process DDT cannot adapt well to new service requirements. In the current blockchain system, the transaction set takes effect after consensus verification in the form of blocks, in which the completion time of all transactions is a unified block time. Therefore, the completion time of transactions can only be distributed in discrete intervals. In order to achieve the latest completion time requirement of the transaction, the system will estimate a latest processed block height for each transaction based on the previous block interval time, and the block time meets the latest completion time requirement of the transaction. The leader node in the system will schedule transactions based on the latest processed block height of the pending transactions in the current transaction pool, and select appropriate transactions to be packaged and produced. However, such a blockchain architecture has two problems when facing DDT transaction requirements:

[0005] 1. There is an error in the height of the latest processed block of the conversion, resulting in transaction failure and waste of resources.

[0006] Due to the uncertainty of the block interval in the system, the actual block time of the latest processed block height estimated based on the latest transaction completion time may be different from the estimated block time. If the estimated block height is greater than the actual latest processed block height, the packaged transaction will exceed the latest completion time limit of the transaction, wasting system resources.

[0007] 2. It shortens the effective processing time of transactions and increases the processing pressure of the system.

[0008] When selecting transactions according to block height, the transaction must be included in the block and successfully generated before the latest completion time of the transaction, that is, the block generation time of the block containing the transaction must be less than the latest completion time of the transaction. This results in the latest completion time of all transactions being brought forward to the completion time of the latest block within the latest completion time, compressing the effective processing time of the transaction. The system needs to complete the transaction within a shorter validity period, increasing the system processing pressure.

[0009] At the same time, it is difficult for various blockchain applications to adapt to this approach, which increases the difficulty of developing decentralized applications and makes it difficult to meet the actual processing needs of this type of transaction. Summary of the invention

[0010] In view of the above problems, the present invention proposes a blockchain system transaction processing method and device for transactions with a latest completion time requirement, which improves the success rate of the system in processing DDT transactions and meets the transaction needs of users.

[0011] In order to achieve the above-mentioned object, the present invention provides a blockchain system transaction processing method on one hand, wherein each transaction has a validity period with a latest completion time, and the method comprises:

[0012] The leader node generates a DDT candidate list and broadcasts it to all consensus nodes;

[0013] Each of the consensus nodes executes each transaction in turn according to the DDT candidate list, and determines whether each transaction is completed within the validity period, determines the execution result information of each consensus node and feeds it back to the leader node, and the execution result information includes the number of transactions executed by the consensus node, and the effective completion information of each transaction or the invalid completion information of the transaction;

[0014] The leader node identifies valid transactions in the DDT candidate list based on the execution result information of each consensus node, generates a valid transaction table, and broadcasts the transaction valid table to all consensus nodes;

[0015] The consensus node performs a consensus process according to the transaction validity table to obtain a consensus result, wherein the consensus result includes a set of valid transactions completed within the validity period;

[0016] Each consensus node packages each valid transaction in the consensus result into a new block, adds it to the local ledger, and updates the status involved in these transactions.

[0017] Optionally, each consensus node packages the valid transactions in the consensus result to generate a new block, adds it to the local ledger, and updates the status, which specifically includes:

[0018] If each valid transaction in the consensus result is identified as valid completion information in the node's local execution result information, the consensus node will use the recorded state involved in the transaction to change the read-write set to update the local ledger state involved;

[0019] If there is at least one valid transaction in the consensus result that is identified as invalid transaction completion information in the node's local execution result information, the consensus node will re-execute the transaction or synchronize the local ledger status involved in the transaction from other consensus nodes.

[0020] Optionally, the leader node generates a DDT candidate list and broadcasts it to all consensus nodes, including:

[0021] The leader node uses the block transaction selection and sorting mechanism to select the transactions expected to be packaged in this cycle and give the transaction execution order according to the currently available resources of each consensus node, the latest completion time of the transaction set in the current transaction pool, and the execution completion time information of each transaction, and generates the DDT candidate list;

[0022] The leader node signs the DDT candidate list using a private key and then broadcasts it to all consensus nodes.

[0023] Optionally, each of the consensus nodes executes each transaction in sequence according to the DDT candidate list, and determines whether each transaction is completed within the validity period, and determines the execution result information of each consensus node, including:

[0024] Each of the consensus nodes executes each transaction in the DDT candidate list in sequence according to the transaction execution order, and determines the estimated execution completion time of each transaction;

[0025] If the estimated execution completion time of each transaction does not exceed the latest completion time of the transaction, it means that the consensus node completes the transaction within the validity period and generates the transaction effective completion information;

[0026] If the estimated execution completion time of each transaction exceeds the latest completion time of the transaction, it means that the consensus node cannot complete the transaction within the validity period, and the transaction invalid completion information is generated;

[0027] The execution result information of the consensus node is obtained according to the number of transactions executed by the consensus node and the valid completion information or the invalid completion information of each transaction.

[0028] Optionally, before each of the consensus nodes executes each transaction in sequence according to the DDT candidate list, the process further includes:

[0029] Each of the consensus nodes uses a public key to verify the identity of the leader node and the correctness of the DDT candidate list.

[0030] Optionally, the leader node identifies valid transactions in the DDT candidate list based on the execution results of each consensus node, including:

[0031] For each transaction, the leader node counts the number of consensus nodes that have completed the transaction within the validity period based on the valid completion information or the invalid transaction completion information;

[0032] If the number of consensus nodes exceeds a first threshold, the transaction is identified as a valid transaction.

[0033] Optionally, before identifying the valid transactions in the DDT candidate list, the method further includes:

[0034] The leader node verifies the correctness of the execution results of each consensus node and verifies the number of executed transactions and node signature information.

[0035] Optionally, before the leader node broadcasts the transaction validity table to all consensus nodes, it also includes:

[0036] The leader node runs the BFT protocol, reaches consensus on the block transactions that can be completed before the latest completion time in this cycle, and generates consensus information, which includes the transaction validity table, the execution result information of other consensus nodes for the transaction, and the current block height information;

[0037] The leader node broadcasts the consensus information to all consensus nodes.

[0038] Optionally, the consensus node performs a consensus process according to the transaction validity table, including:

[0039] For each valid transaction in the transaction validity table, the consensus node verifies, based on the execution result information of other consensus nodes for the transaction, that at least a first threshold number of consensus nodes complete the transaction within the validity period;

[0040] The consensus node executes the BFT consensus protocol, effectively expresses the transaction into a consistent consensus, and screens valid transactions that reach a hash consensus as a set of transactions completed within the validity period.

[0041] Another aspect of the present invention further provides a blockchain system transaction processing device, which adopts the above method and at least comprises:

[0042] DDT candidate list generation module, used by the leader node to generate the DDT candidate list and broadcast it to all consensus nodes;

[0043] DDT candidate list execution module, used for each consensus node to execute each transaction in turn according to the DDT candidate list, and determine whether each transaction is completed within the validity period, determine the execution result information of each consensus node and feed it back to the leader node, the execution result information includes the number of transactions executed by the consensus node, and the effective completion information or invalid completion information of each transaction;

[0044] A valid transaction confirmation module is used for the leader node to identify valid transactions in the DDT candidate list according to the execution result information of each consensus node, generate a valid transaction table, and broadcast the transaction validity table to all consensus nodes;

[0045] A consensus module, used for the consensus node to perform a consensus process according to the transaction validity table to obtain a consensus result, wherein the consensus result includes a set of transactions completed within the validity period;

[0046] The consistency confirmation module is used for each consensus node to package each valid transaction in the consensus result to generate a new block, add it to the local ledger, and update the status involved in these transactions.

[0047] It can be seen from the above scheme that the advantages of the present invention are:

[0048] The transaction processing method for a blockchain system with a latest completion time transaction requirement provided by the present invention generates a DDT candidate list through a leader node and broadcasts it to all consensus nodes; at the same time, each of the consensus nodes executes each transaction in turn according to the DDT candidate list, and determines whether each transaction is completed within the latest completion time, determines the execution result information of each consensus node and feeds it back to the leader node; then, the leader node identifies the valid transactions in the DDT candidate list according to the execution result information of each consensus node, generates a valid transaction table, and broadcasts the transaction validity table to all consensus nodes; the consensus nodes reach a consensus based on the transaction validity table, and by determining whether the local validity of the transaction is the same as the validity agreed upon between the final nodes, ensure that the transaction execution validity determined by all consensus nodes is consistent, and finally write it into the account book. This method avoids the problem that in the traditional scheme, transactions can only be processed according to the block height, resulting in a large number of DDT transactions that cannot be completed on schedule. By using this protocol, the blockchain system can select fine-grained processing timing for transactions with the latest completion time requirement according to the expected execution completion time of the transaction. At the same time, this protocol achieves a consensus among distributed nodes on the effectiveness of whether transactions with the latest completion time requirement can be completed within the completion period, thereby greatly improving the DDT transaction processing success rate. Compared with the traditional blockchain architecture, it can improve the DDT transaction success rate, and at the same time, it has significant performance improvements in terms of system effective throughput and system resource utilization. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] Figure 1 A schematic diagram of a process of a blockchain system transaction processing method provided by an embodiment of the present invention is shown;

[0050] Figure 2 An architectural diagram of a blockchain system transaction processing device is shown;

[0051] in,

[0052] 200-Blockchain system transaction processing device;

[0053] 201-DDT candidate list generation module;

[0054] 202-DDT candidate list execution module;

[0055] 203-valid transaction confirmation module;

[0056] 204-consensus module;

[0057] 205-Consistency confirmation module. DETAILED DESCRIPTION

[0058] In order to make the above features and effects of the present invention more clearly understood, embodiments are given below and described in detail with reference to the accompanying drawings.

[0059] As mentioned above, when directly using the existing blockchain system to process transactions with a deadline, it is necessary to convert the deadline to the latest block height at which the transaction is packaged. There is a time error in this conversion process, and the transaction success rate is low. At the same time, it is difficult for various blockchain applications to adapt to this method, which increases the difficulty of developing decentralized applications, and it is difficult to meet the actual processing needs of this type of transaction, and it is impossible to meet user needs.

[0060] In reality, the block generation time of a block is not the time when each transaction in the block is executed. Each transaction packaged in a block is executed sequentially on the distributed nodes in the blockchain system. Assuming that the transactions in the block are executed serially in order, if the estimated execution completion time of each transaction packaged in the block can be determined, then when scheduling transactions, the timing of transaction packaging can be determined more accurately, avoiding the disadvantage that all transactions are completed at the block generation time when the block is used as the scheduling unit. Therefore, this application considers determining the timing of packaging based on the estimated execution completion time of the transaction, so as to accurately utilize the latest completion time of the transaction to schedule pending transactions and meet the service requirements of DDT type transactions.

[0061] However, due to the clock deviation between different nodes in the blockchain system, the inconsistent time of accepting transactions due to the difference in transmission delay in the network, and the different node performance due to the heterogeneity of nodes, the execution completion time of the same transaction is different. Therefore, the estimated execution completion time of the same transaction by different nodes is inconsistent. However, the system needs to reach a consensus on whether the transaction is completed within the validity period (that is, the latest completion time). Therefore, this application considers using a special protocol to determine whether the transaction is completed within the latest completion period based on the estimated execution completion time of the transaction, that is, to determine the validity of the transaction, so that the DDT transaction can be selected for processing based on the estimated execution completion time of the transaction, thereby improving the success rate of the system in processing DDT transactions and meeting the transaction needs of users.

[0062] Therefore, in order to solve the problem that the success rate of traditional blockchain systems in processing transactions with the latest completion time requirement is low and cannot meet user needs, this application proposes a blockchain system transaction processing method designed specifically for DDT transaction scenarios, which processes transactions according to the estimated execution completion time of DDT transactions, maximizes the proportion of transactions in the system that can be completed before the latest completion deadline of transactions, thereby adapting to application requirements with transaction completion time requirements and providing users with service quality guarantees as much as possible, and realizing the consistent consensus requirements on transaction validity among nodes in a distributed system. The present invention will be described in detail below.

[0063] like Figure 1 As shown in Figure 1 The flowchart of the blockchain system transaction processing method provided by the embodiment of the present invention is shown as follows:

[0064] A blockchain system transaction processing method is provided for transaction requirements with a latest completion time, that is, each transaction has a validity period with a latest completion time, the method comprising:

[0065] S1. The leader node generates a DDT candidate list and broadcasts it to all consensus nodes.

[0066] The blockchain protocol proposed in this application for transactions with a latest completion time requirement is based on a BFT consensus mechanism. In each round, the leader node of this round is determined unbiasedly and randomly based on the VRF function. The leader node's selection of the block transaction set determines the timing of each transaction being processed. Assuming that the transactions are executed serially on each node, the round in which the transactions are packaged and the order in which they are arranged will determine whether the transactions can be completed on time before the latest completion time. At the same time, when selecting a transaction set, the leader node needs to consider whether the unselected transactions will lose the opportunity to be processed in the future, so as to minimize the impact of the current selection scheme on the future system service quality.

[0067] Therefore, considering that the DTT transactions to be processed in the system have differences in resource usage, transaction execution completion time, latest completion time, etc., and at the same time, since the leader node’s own available resources are limited, the number of transactions that the leader node can select in a block cycle is limited. How to satisfy as many transactions as possible within the validity period under a dynamic transaction load with a latest completion time limit is a problem that the leader node block transaction selection algorithm needs to solve. The present invention can be applied to any leader block transaction selection algorithm. In a specific implementation, the leader node uses a block transaction selection sorting mechanism to select transactions expected to be packaged in this cycle and give a transaction execution order based on the current available resources of each consensus node, the latest completion time of the transaction set in the current transaction pool, the transaction execution completion time and other information, and generates a DDT candidate list; then, the leader node signs the DDT candidate list with a private key and broadcasts it to all consensus nodes. Specifically, assuming that the leader node of the current round e is N L , the transaction set in the leader node's current transaction pool is Q(v), (v is the current round), and the leader transaction selection algorithm is F

[0068]

[0069] Then output leader node N LThe DDT candidate list selected for block generation in the current round is denoted as DDTCL, where the order of transactions represents the transaction execution order given by the leader node. The leader node signs the candidate block sequence with its private key and then broadcasts the DDT candidate list to other consensus nodes, namely the Candidate message. Then wait for the response from other consensus nodes. is the leader node N L Sign the message with your own private key.

[0070] S2. Each consensus node executes each transaction in sequence according to the DDT candidate list, and determines whether each transaction is completed within the validity period, determines the execution result information of each consensus node and feeds it back to the leader node. The execution result information includes the number of transactions executed by the consensus node, and the effective completion information of each transaction or the invalid completion information of the transaction.

[0071] In this stage, each consensus node executes each transaction in turn according to the received DDT candidate list (i.e., Candidate message) to determine whether the completion time of the transaction has expired. The network topology and communication bandwidth of different consensus nodes and leader nodes lead to inconsistent message reception time; at the same time, due to the heterogeneity between different consensus nodes, the time taken by different consensus nodes to execute the same transaction may be different; in addition, there is asynchrony between the clocks of nodes in the distributed system. These reasons will lead to differences in the execution completion time of the same transaction by different consensus nodes. Therefore, it is impossible to reach a consensus on the precise completion time of the transaction in a distributed blockchain system. This application does not need to determine the precise completion time of the transaction, but only needs to reach a consensus in the distributed nodes on whether the transaction is completed within the latest completion time. In this stage, each consensus node feeds back the valid / invalid completion information of each transaction in the DDT candidate list to the leader.

[0072] Specifically, first, each consensus node uses the public key to verify the leader node identity and the correctness of the DDT candidate list. When the verification is correct, each consensus node executes each transaction in the DDT candidate list in sequence according to the transaction execution order, and determines the estimated execution completion time of each transaction; if the estimated execution completion time of each transaction does not exceed the latest completion time of the transaction, it means that the consensus node completes the transaction within the validity period, and generates transaction valid completion information; if the estimated execution completion time of each transaction exceeds the latest completion time of the transaction, it means that the consensus node cannot complete the transaction within the validity period, and generates transaction invalid completion information; based on the number of transactions executed by the consensus node, and the effective completion information or invalid completion information of each transaction, the execution result information of the consensus node is obtained. For example, for consensus node N CReceive the DDT candidate list Candidate message for this round After that, firstly, according to the public key Verify the leader node identity and the correctness of the Candidate message. Then the consensus node N C Each transaction in the DDT candidate list will be executed locally in the order specified by the leader, and a binary valid flag validFlag will be assigned to the transaction based on the execution result. If the expected completion time of the transaction after the execution is less than the latest completion time of the transaction, then the transaction will be executed on the consensus node N. C From the perspective of the transaction, it can be completed on schedule, and the validFlag value is 1, that is, a transaction valid completion information is generated, indicating that the transaction is effectively completed; if the estimated execution completion time after the execution is completed is less than the latest completion time of the transaction, then the consensus node N C The transaction is considered invalid, the validFlag value is 0, and an invalid transaction completion message is generated, indicating that the transaction is invalid. The transaction will not modify the local state of the node during execution. The node will record the read and write sets of the relevant state locally. At this time, the consensus node N C During the execution process, once the transaction DDT is found i The previous transaction execution completion time has exceeded DDT i The latest completion time of consensus node N C This transaction DDT will be skipped i , directly execute the next transaction, thus ensuring that more transactions can be completed on time. After executing all transactions in the DDT candidate list, consensus node N C The execution result information (i.e. Exec message ) is fed back to the leader node, where k is the number of transactions in the DDT candidate list, and Γ is the validFlag information of all transactions arranged in order, that is, the valid completion information of each transaction or the invalid completion information of the transaction.

[0073] S3. The leader node identifies valid transactions in the DDT candidate list based on the execution result information of each consensus node, generates a valid transaction table, and broadcasts the transaction validity table to all consensus nodes.

[0074] At this stage, the leader node N LThe execution result information (Exec message) of each consensus node will be collected, and the correctness of the execution result of each consensus node will be verified first, for example: whether the number of transactions executed in the monitoring message is k, whether the node signature information is correct, etc. Then, after verifying the accuracy, a valid transaction table in the DDT candidate list is generated. The transactions in the valid transaction table are all valid transactions in the DDT candidate list that can be completed before the latest completion time. Specifically, for each transaction, the valid completion information of the transaction indicates that the transaction is effectively completed within the validity period, and the invalid completion information of the transaction indicates that the transaction cannot be completed within the validity period. The leader node can count the number of consensus nodes that complete the transaction within the validity period based on the valid completion information or the invalid completion information of the transaction; if the number of consensus nodes exceeds a preset first threshold, the transaction is identified as a valid transaction and added to the valid transaction table.

[0075] In this embodiment, the valid transaction table includes multiple data structures: (1) validNum, which is a k-dimensional integer vector, where the initial value of validNum[i] is 0 and stores the leader node N L The number of nodes that have completed the execution of the i-th transaction in the determined DDT candidate list within the validity period (where k is the number of transactions in the candidate list). (2) validTable is a list that is initially empty and stores the transactions in the DDT candidate list that can be completed before the latest completion time. (3) validTableHash is a list that is initially empty and stores the hash values ​​of all transactions in validTable. L After sending the DDT candidate list (Candidate message) to other consensus nodes, it starts waiting for the consensus node to reply with the execution result (Exec message) to determine the actual completion status of each transaction in the DDT candidate list. L The time for waiting to collect the execution result Exec message of the Candidate message from each consensus node is Δ, including time Δ1, which is the maximum round-trip communication delay of the message between honest nodes, and Δ2, which is the estimated maximum time for executing transactions in the DDT candidate list (including clock drift between nodes). Specifically, the DDT of each transaction can be determined based on the valid completion information / invalid transaction completion information (validFlag information Γ value) in the execution result information (Exec message). i Is it in consensus node N? C Completed on time, if the value of Γ[i] is 1, then the value of validNum[i] increases by 1. Leader node N L All received execution result Exec messages are processed similarly, and validNum value is continuously updated. Finally, if validNum[i] is greater than or equal to the first threshold 2f+1, (i∈{0,1,2,…,k-1}), then the transaction DDTi For a valid transaction, it will be added to the validTable, transaction DDT i The hash of is added to validTableHash; otherwise, the transaction DDT i If a transaction cannot be completed on time in the majority of nodes, it will be considered an invalid transaction and will not participate in the subsequent consensus process.

[0076] In addition, after confirming the valid transaction table, the leader node will further run a BFT protocol to reach a consensus on the block transactions that can be completed before the latest completion time in this cycle, and generate consensus information. The consensus information includes the transaction validity table, the execution result information of other consensus nodes for the transaction, the current block height information, etc. Specifically, the leader node N L Generate the consensus message of this round (i.e., Consensus message ) reached an agreement, among which N is the leader node L The transaction hash list of this block cycle in the determined valid transaction table validTableHash, p is the leader node N L The execution result information of the transaction received from other consensus nodes (from the Exec message), b is the current block height. Then, the leader node broadcasts the generated consensus information Consensus message to all consensus nodes.

[0077] S4. The consensus node performs a consensus process according to the transaction validity table and obtains a consensus result. The consensus result includes a set of transactions completed within the validity period.

[0078] After receiving the consensus message, the consensus node performs the consensus process. Specifically, for each valid transaction in the transaction validity table, the consensus node verifies that at least a first threshold number of consensus nodes have completed the transaction within the validity period based on the execution result information of the transaction by other consensus nodes, that is, based on p verification Each transaction in the block is completed by at least the first threshold 2f+1 consensus nodes within the validity period. Then, the consensus nodes execute the BFT consensus protocol, express the transaction effectively as a consistent consensus, and select the valid transactions that reach the hash consensus as the transaction set completed in the final validity period, that is, the transaction corresponding to the hash value set is the valid transaction set completed in the validity period selected for the block generation cycle.

[0079] S5. Each consensus node packages each valid transaction in the consensus result into a new block, adds it to the local ledger, and updates the status involved in these transactions.

[0080] Specifically, in this embodiment, after the consensus nodes reach an agreement on the consensus information (i.e., the Consensus message), it will check whether the transaction set completed within the validity period (i.e., the transaction corresponding to the effective completion information of the transaction) selected in the process of executing the DDT candidate list locally at each consensus node in step S2 is consistent with the transaction set completed within the validity period after the final consensus. That is:

[0081] If each valid transaction in the consensus result is identified as valid completion information in the node's local execution result information, at this time, the transaction set is consistent, then the consensus node will directly submit the previous transaction execution result based on the local state, and at the same time, the consensus node will use the recorded state involved in the transaction to change the read-write set to update the local ledger state involved.

[0082] In addition, due to the clock drift and execution time differences between consensus nodes, the validity of some transactions locally may be different from the validity agreed upon between the final nodes, that is, there may be a situation where the transaction validity result after the node execution is inconsistent with the consensus result. At this time, the consensus node will handle two different situations separately: if the transaction completed within the validity period selected during the local execution of the DDT candidate list is not in the valid transaction set completed within the validity period after the final consensus, then the consensus node will delete the write operation of the relevant state; if there is at least one valid transaction in the consensus result that is identified as invalid transaction completion information in the node's local execution result information, that is, there is a valid transaction in the transaction set completed within the validity period after the final consensus that is not executed on the node, then the node will re-execute the transaction and record the status change information. At the same time, if there is a dependency between transactions, then all transactions involving read and write operations on the same state need to be re-executed. By confirming the consistency between the local execution result information and the transaction set completed within the validity period after the consensus, the consensus node submits the write operation set involved in the transaction set to the local state, and packages each transaction corresponding to the valid completion information to generate a new block and add it to the local account. Based on the consistent consensus results, all consensus nodes will obtain consistent local states and local ledgers.

[0083] Through the above process, all consensus nodes reach a consensus on the validity of transaction execution and finally write it into the ledger. Such a workflow mechanism ensures that the system can schedule transactions according to the precise latest completion time requirements of transactions, and meet the service quality of DDT transactions as much as possible.

[0084] In summary, this application aims at the problem that the current blockchain system cannot well meet the transaction processing requirements with the latest completion time requirement, and proposes a blockchain system transaction processing method for transactions with the latest completion time requirement. The method generates a DDT candidate list through the leader node and broadcasts it to all consensus nodes; at the same time, each consensus node executes each transaction in turn according to the DDT candidate list, and determines whether each transaction is completed within the latest completion time, determines the execution result information of each consensus node and feeds it back to the leader node; then, the leader node identifies the valid transactions in the DDT candidate list according to the execution result information of each consensus node, generates a valid transaction table, and broadcasts the transaction validity table to all consensus nodes; the consensus nodes reach consensus based on the transaction validity table, and by determining whether the local validity of the transaction is the same as the validity agreed upon between the final nodes, ensure that the transaction execution validity determined by all consensus nodes is consistent, and finally write it into the account book. This method avoids the problem that in the traditional scheme, transactions can only be processed according to the block height, resulting in a large number of DDT transactions that cannot be completed on schedule. By using this protocol, the blockchain system can select fine-grained processing timing for transactions with the latest completion time requirement according to the expected execution completion time of the transaction. At the same time, this protocol achieves a consensus among distributed nodes on the effectiveness of whether transactions with the latest completion time requirement can be completed within the completion period, thereby greatly improving the DDT transaction processing success rate. Compared with the traditional blockchain architecture, it can improve the DDT transaction success rate, and at the same time, it has significant performance improvements in terms of system effective throughput and system resource utilization.

[0085] In addition, the above-mentioned embodiments of the present invention can be applied to terminal devices that function as blockchain system transaction processing methods. The terminal devices may include personal terminals and host computer terminals, etc., and the embodiments of the present invention are not limited to this.

[0086] A blockchain system transaction processing device 200 is provided for transactions with a latest completion time requirement and can be applied to a blockchain distributed system. Figure 1 The blockchain system transaction processing method shown, the blockchain system transaction processing device provided in the embodiment of the present application can implement each process implemented by the above-mentioned blockchain system transaction processing method. Figure 2 The architecture diagram of the blockchain system transaction processing device 200 is shown.

[0087] A blockchain system transaction processing device 200, comprising at least:

[0088] DDT candidate list generation module 201, used by the leader node to generate the DDT candidate list and broadcast it to all consensus nodes;

[0089] DDT candidate list execution module 202, used for each consensus node to execute each transaction in turn according to the DDT candidate list, and determine whether each transaction is completed within the validity period, determine the execution result information of each consensus node and feed it back to the leader node. The execution result information includes the number of transactions executed by the consensus node, and the effective completion information of each transaction or the invalid completion information of the transaction;

[0090] The valid transaction confirmation module 203 is used by the leader node to identify valid transactions in the DDT candidate list based on the execution result information of each consensus node, generate a valid transaction table, and broadcast the transaction validity table to all consensus nodes;

[0091] Consensus module 204, used for consensus nodes to perform consensus process according to the transaction validity table to obtain a consensus result, and the consensus result includes a set of transactions completed within the validity period;

[0092] The consistency confirmation module 205 is used for each consensus node to package each valid transaction in the consensus result to generate a new block, add it to the local account book, and update the status involved in these transactions.

[0093] In addition, it should be understood that in the blockchain system transaction processing device 200 according to the embodiment of the present application, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the blockchain system transaction processing device 200 can be divided into functional modules different from the modules illustrated above to complete all or part of the functions described above.

[0094] It should be noted that, in this article, the terms "comprise", "include" or any other variant thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "including one..." do not exclude the presence of other identical elements in the process, method, article or device including the element. In addition, it should be pointed out that the scope of the methods and devices in the embodiments of the present application is not limited to performing functions in the order shown or discussed, and may also include performing functions in a substantially simultaneous manner or in the opposite order according to the functions involved, for example, the described method may be performed in an order different from that described, and various steps may also be applied, omitted, or combined. In addition, the features described with reference to certain examples may be combined in other examples.

[0095] The embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of the present application, ordinary technicians in this field can also make many forms without departing from the purpose of the present application and the scope of protection of the claims, all of which are within the protection of the present application.

Claims

1. A blockchain system transaction processing method, wherein each transaction has a validity period with a latest completion time, characterized in that: Include: The leader node generates a DDT candidate list and broadcasts it to all consensus nodes; Each of the consensus nodes executes each transaction in turn according to the DDT candidate list, and determines whether each transaction is completed within the validity period, determines the execution result information of each consensus node and feeds it back to the leader node, and the execution result information includes the number of transactions executed by the consensus node, and the effective completion information of each transaction or the invalid completion information of the transaction; The leader node identifies valid transactions in the DDT candidate list based on the execution result information of each consensus node, generates a valid transaction table, and broadcasts the transaction valid table to all consensus nodes; The consensus node performs a consensus process according to the transaction validity table to obtain a consensus result, wherein the consensus result includes a set of valid transactions completed within the validity period; Each consensus node packages each valid transaction in the consensus result into a new block, adds it to the local ledger, and updates the status of these transactions. 。 2. The method according to claim 1, characterized in that Each consensus node packages the valid transactions in the consensus result into a new block, adds it to the local ledger and updates the status, including: If each valid transaction in the consensus result is identified as valid completion information in the node's local execution result information, the consensus node will use the recorded state involved in the transaction to change the read-write set to update the local ledger state involved; If there is at least one valid transaction in the consensus result that is identified as invalid transaction completion information in the node's local execution result information, the consensus node will re-execute the transaction or synchronize the local ledger status involved in the transaction from other consensus nodes.

3. The method according to claim 1, characterized in that: The leader node generates a DDT candidate list and broadcasts it to all consensus nodes, including: The leader node uses the block transaction selection and sorting mechanism to select the transactions expected to be packaged in this cycle and give the transaction execution order according to the currently available resources of each consensus node, the latest completion time of the transaction set in the current transaction pool, and the execution completion time information of each transaction, and generates the DDT candidate list; The leader node signs the DDT candidate list using a private key and then broadcasts it to all consensus nodes.

4. The method according to claim 3, characterized in that Each of the consensus nodes executes each transaction in turn according to the DDT candidate list, and determines whether each transaction is completed within the validity period, and determines the execution result information of each consensus node, including: Each of the consensus nodes executes each transaction in the DDT candidate list in sequence according to the transaction execution order, and determines the estimated execution completion time of each transaction; If the estimated execution completion time of each transaction does not exceed the latest completion time of the transaction, it means that the consensus node completes the transaction within the validity period and generates the transaction effective completion information; If the estimated execution completion time of each transaction exceeds the latest completion time of the transaction, it means that the consensus node cannot complete the transaction within the validity period, and the transaction invalid completion information is generated; The execution result information of the consensus node is obtained according to the number of transactions executed by the consensus node and the valid completion information or the invalid completion information of each transaction.

5. The method according to claim 4, characterized in that Before each of the consensus nodes executes each transaction in sequence according to the DDT candidate list, it also includes: Each of the consensus nodes uses a public key to verify the identity of the leader node and the correctness of the DDT candidate list.

6. The method according to claim 4, characterized in that The leader node identifies valid transactions in the DDT candidate list based on the execution results of each consensus node, including: For each transaction, the leader node counts the number of consensus nodes that have completed the transaction within the validity period based on the valid completion information or the invalid transaction completion information; If the number of consensus nodes exceeds a first threshold, the transaction is identified as a valid transaction.

7. The method according to claim 6, characterized in that Before identifying the valid transactions in the DDT candidate list, it also includes: The leader node verifies the correctness of the execution results of each consensus node and verifies the number of executed transactions and node signature information.

8. The method according to any one of claims 1 to 7, characterized in that: Before the leader node broadcasts the transaction validity table to all consensus nodes, it also includes: The leader node runs the BFT protocol, reaches consensus on the block transactions that can be completed before the latest completion time in this cycle, and generates consensus information, which includes the transaction validity table, the execution result information of other consensus nodes for the transaction, and the current block height information; The leader node broadcasts the consensus information to all consensus nodes.

9. The method according to claim 8, characterized in that The consensus node performs a consensus process according to the transaction validity table, including: For each valid transaction in the transaction validity table, the consensus node verifies, based on the execution result information of other consensus nodes for the transaction, that at least a first threshold number of consensus nodes complete the transaction within the validity period; The consensus nodes execute the BFT consensus protocol, effectively express the transaction into a consistent consensus, and screen valid transactions that reach a hash consensus as a set of valid transactions completed within the validity period.

10. A blockchain system transaction processing device, characterized in that: The method according to any one of claims 1 to 9 comprises at least: DDT candidate list generation module, used by the leader node to generate the DDT candidate list and broadcast it to all consensus nodes; DDT candidate list execution module, used for each consensus node to execute each transaction in turn according to the DDT candidate list, and determine whether each transaction is completed within the validity period, determine the execution result information of each consensus node and feed it back to the leader node, the execution result information includes the number of transactions executed by the consensus node, and the effective completion information or invalid completion information of each transaction; A valid transaction confirmation module is used for the leader node to identify valid transactions in the DDT candidate list according to the execution result information of each consensus node, generate a valid transaction table, and broadcast the transaction validity table to all consensus nodes; A consensus module, used for the consensus node to perform a consensus process according to the transaction validity table to obtain a consensus result, wherein the consensus result includes a set of transactions completed within the validity period; The consistency confirmation module is used by each consensus node to package each valid transaction in the consensus result into a new block, add it to the local ledger, and update the status of these transactions. 。

Images