Blockchain system transaction processing method and device

Abstract

The present invention proposes a blockchain system transaction processing method and device. The method includes: a leader node generates a DDT candidate list and broadcasts it to all consensus nodes; each consensus node sequentially executes each transaction based on the DDT candidate list, determines whether each transaction is completed within its validity period, determines the execution result information of each consensus node, and feeds it back to the leader node; 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; the consensus nodes perform a consensus process based on the transaction validity table to obtain a consensus result; 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 the transactions involved. This method improves the system's success rate in processing DDT transactions and meets user transaction needs.

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 scenarios like auctions, elections, and bidding, transactions often have deadlines within which they must be completed. We call these transactions DDTs (deadline-driven transactions). After a DDT transaction's expiration date, the transaction's business logic becomes meaningless or the original processing requirements cease to exist, rendering the transaction invalid. Even if invalidated transactions are packaged and uploaded to the blockchain, they are useless, and processing them wastes blockchain system resources. DDT-type transaction scenarios place new service demands on blockchain systems—scheduling transactions based on their deadlines to ensure they are completed as close to the deadline as possible. Transactions that fail to complete within their deadlines can negatively impact the user experience of these blockchain-based applications and can even severely compromise the availability of these services.

[0003] However, existing blockchain systems assume that transactions have no deadlines by default, meaning that no matter when the system processes a transaction, the transaction is valid. Furthermore, these blockchain systems often aim to maximize overall transaction processing performance, or 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 existing blockchain systems to directly process DDTs is not well adapted to new service requirements. In current blockchain systems, transaction sets are validated as a whole in the form of blocks, and the completion time of all transactions is a unified block time. Therefore, transaction completion times can only be distributed at discrete intervals. To meet the latest transaction completion time requirement, the system will estimate a block height for each transaction based on the previous block interval, with a block time that meets the latest transaction completion time requirement. The leader node in the system will schedule transactions based on the latest processed block height of pending transactions in the current transaction pool, selecting the appropriate transaction to package and publish in the block. However, this blockchain architecture faces two problems when dealing with 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 generation interval in the system, the actual block generation time estimated based on the latest transaction completion time may differ from the estimated block generation time. If the estimated block generation height is greater than the actual latest processed block height, the packaged transaction will exceed the latest transaction completion time limit, wasting system resources.

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

[0008] When selecting transactions based on block height, the transaction must be included in a block and successfully generated before the transaction's latest completion time. This means the block generation time of the block containing the transaction must be less than the transaction's latest completion time. This results in the latest completion time of all transactions being moved up to the completion time of the latest block within the latest completion time, compressing the effective transaction processing time. The system needs to complete transactions within a shorter validity period, increasing system processing pressure.

[0009] At the same time, various blockchain applications are difficult 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 response to 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 system's success rate in processing DDT transactions and meets users' transaction needs.

[0011] To achieve the above objectives, the present invention provides a blockchain system transaction processing method, 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 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 valid completion information or invalid completion information of each 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 valid transaction 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 into 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 at least one valid transaction in the consensus result 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, to generate 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 based on 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 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 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, the process further includes:

[0036] The leader node runs the BFT protocol to reach a consensus on the block transactions that can be completed before the latest completion time in this cycle, and generates consensus information. The consensus information 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 the transaction by other consensus nodes, that at least a first threshold number of consensus nodes have completed 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 the valid transactions that reach the hash consensus as the transaction set completed within the validity period.

[0041] Another aspect of the present invention 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] The DDT candidate list execution module is used for each consensus node to execute each transaction in sequence according to the DDT candidate list, determine whether each transaction is completed within the validity period, determine the execution result information of each consensus node, and feedback it to the leader node. The execution result information includes the number of transactions executed by the consensus node and the valid completion information or invalid completion information of each transaction;

[0044] A valid transaction confirmation module 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;

[0045] A consensus module, configured for the consensus nodes 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 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 involved in these transactions.

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

[0048] The present invention provides a transaction processing method for a blockchain system with a latest completion time transaction requirement. The method generates a DDT candidate list through a leader node and broadcasts it to all consensus nodes. At the same time, each consensus node executes each transaction in sequence according to the DDT candidate list, 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 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. 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 by the final node, ensure that the transaction execution validity determined by all consensus nodes is consistent, and finally write it into the ledger. This method avoids the problem in traditional solutions where transactions can only be processed according to block height, resulting in a large number of DDT transactions not being completed on time. This protocol enables blockchain systems to make fine-grained decisions about when to process transactions with deadlines based on their estimated completion times. Furthermore, it enables distributed nodes to reach consensus on the effectiveness of transactions with deadlines, significantly improving the DDT transaction processing success rate. Compared to traditional blockchain architectures, this protocol improves DDT transaction success rates while significantly improving system throughput and resource utilization. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0050] Figure 2 The following is an architectural diagram of a blockchain system transaction processing device;

[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 previously mentioned, directly using existing blockchain systems to process transactions with deadlines requires converting the deadline to the block height at which the transaction was last included. This conversion process introduces time errors, resulting in low transaction success rates. Furthermore, various blockchain applications struggle to adapt to this approach, increasing the complexity of decentralized application development and making it difficult to meet the actual processing requirements of these transactions, effectively failing to meet user needs.

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

[0061] However, due to the clock deviation that may exist between different nodes in the blockchain system, and the inconsistent time of accepting transactions due to the difference in transmission delay in the network, the heterogeneity of nodes leads to different node performance, and 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 DDT transactions 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, to address the low success rate of transactions with a deadline in traditional blockchain systems, which cannot meet user needs, this application proposes a blockchain system transaction processing method specifically designed for DDT transaction scenarios. This method processes transactions based on the expected execution completion time of DDT transactions, maximizing the proportion of transactions in the system that can be completed before the deadline. This method adapts to the needs of applications with transaction completion time requirements and provides users with the greatest possible quality of service guarantees, achieving a consistent consensus on transaction validity among nodes in a distributed system. The present invention is described in detail below.

[0063] like Figure 1 As shown in Figure 1 The following is a flow chart of a blockchain system transaction processing method provided by an embodiment of the present invention, specifically:

[0064] A blockchain system transaction processing method is provided for transactions requiring a latest completion time, i.e., each transaction has a validity period with a latest completion time. The method comprises:

[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, suitable for transactions with a deadline, is based on a BFT-style consensus mechanism. In each round, the leader node is determined unbiasedly and randomly using a VRF function. The leader node's selection of the transaction set for block generation determines the timing of each transaction's processing. Assuming transactions are executed serially across nodes, the round in which transactions are packaged and the order in which they are arranged will determine whether they can be completed on time before the deadline. Furthermore, when selecting a transaction set, the leader node must consider whether unselected transactions will lose the opportunity to be processed in the future, thereby minimizing the impact of the current selection on future system service quality.

[0067] Therefore, considering that there are differences in the DTT transactions to be processed in the system in terms of 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 one block cycle is limited. How to satisfy as many transactions as possible to be completed within the validity period under the dynamic transaction load with the 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 the transactions expected to be packaged in this cycle and give the 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, to generate 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 the block 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. The execution result information of each consensus node is determined and fed back to the leader node. The execution result information includes the number of transactions executed by the consensus node and the valid completion information or invalid completion information of each transaction.

[0071] During 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 the leader node lead to inconsistent message reception times; 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 among the distributed nodes on whether the transaction is completed within the latest completion time. During 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 identity of the leader node and the correctness of the DDT candidate list. If 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 valid 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, first 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 time, and the validFlag value is 1, which means that a transaction is effectively completed. If the expected completion time after the execution is less than the latest completion time of the transaction, then the consensus node N C The transaction will be considered invalid, the validFlag value will be 0, and a transaction invalid completion message will be 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 execution completion time of the previous transaction 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, the 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 sequence, 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. First, the correctness of the execution result of each consensus node will be verified, 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 is generated in the DDT candidate list. 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 transaction completion information indicates that the transaction is effectively completed within the validity period, and the invalid transaction completion information indicates that the transaction cannot be completed within the validity period. The leader node can count the number of consensus nodes that 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 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 begins to wait 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 to wait for the collection of the execution results of the Candidate message from each consensus node is Δ, including the time Δ1 is the maximum round-trip communication delay of the message between honest nodes, and Δ2 is the estimated maximum time to execute the transaction in the DDT candidate list (including the clock drift between nodes). Specifically, the DDT of each transaction can be determined based on the valid completion information / invalid 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 the 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 valid transactions, they 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 among 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 based on the transaction validity table to obtain 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 the p verification. Each transaction in the block is completed by at least the first threshold 2f+1 consensus nodes within the validity period. The consensus nodes then execute the BFT consensus protocol, reach a consensus on the transaction validity, and select the valid transactions that reach the hash consensus as the transaction set completed within the final validity period. That is, the transactions corresponding to the hash value set are the valid transactions completed within 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), they will check whether the transaction set completed within the validity period (i.e., the transactions corresponding to the valid transaction completion information) selected during the local execution of the DDT candidate list by 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, then the transaction set is consistent. In this case, the consensus node will directly submit the previous transaction execution result based on the local state. 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] Furthermore, due to clock drift and execution time differences between consensus nodes, the local validity of some transactions may differ from the validity agreed upon by the final nodes. This means that the transaction validity results after node execution may be inconsistent with the consensus results. In this case, the consensus node will handle two different situations: If the transactions that were completed within the validity period during the local execution of the DDT candidate list are not included in the valid transactions with the validity period after the final consensus, the consensus node will delete the write operation to the relevant state. If at least one valid transaction in the consensus result is identified as invalid in the node's local execution result information, that is, a valid transaction in the valid transaction set after the final consensus was not executed on the node, the node will re-execute the transaction and record the state change information. Furthermore, if there are dependencies between transactions, all transactions involving read and write operations on the same state must be re-executed. After confirming the consistency between the local execution result information and the valid transaction set after the consensus, the consensus node commits the write operation set involved in the transaction set to the local state and packages each transaction corresponding to the valid completion information into a new block, which is added 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 the transaction execution and ultimately write it into the ledger. This 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 addresses the problem that the current blockchain system cannot well meet the transaction processing needs 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 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; 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 ledger. This method avoids the problem in the traditional solution that transactions can only be processed according to the block height, resulting in a large number of DDT transactions not being completed on schedule. This protocol enables blockchain systems to make fine-grained decisions about when to process transactions with deadlines based on their estimated completion times. Furthermore, it enables distributed nodes to reach consensus on the effectiveness of transactions with deadlines, significantly improving the DDT transaction processing success rate. Compared to traditional blockchain architectures, this protocol improves DDT transaction success rates while significantly improving system throughput and 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 designed for transactions with a latest completion time 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 diagram shows the architecture of the blockchain system transaction processing device 200.

[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] The DDT candidate list execution module 202 is used for each consensus node to execute each transaction in sequence according to the DDT candidate list, determine whether each transaction is completed within the validity period, determine the execution result information of each consensus node, and feedback it to the leader node. The execution result information includes the number of transactions executed by the consensus node and the valid completion information or invalid completion information of each 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, which 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 ledger, 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, the division of the above-mentioned functional modules is only 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 variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the statement "comprises a ..." does not exclude the presence of other identical elements in the process, method, article or device comprising the element. In addition, it should be noted 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 this application, ordinary technicians in this field can also make many forms without departing from the purpose of this application and the scope of protection of the claims, all of which are within the protection of this 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 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 valid completion information or invalid completion information of each 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 valid transaction 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 involved in 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 at least one valid transaction in the consensus result 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, to generate 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 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: 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 based on 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, the process further 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 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 to reach a consensus on the block transactions that can be completed before the latest completion time in this cycle, and generates consensus information. The consensus information 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 the transaction by other consensus nodes, that at least a first threshold number of consensus nodes have completed the transaction within the validity period; The consensus nodes execute the BFT consensus protocol, effectively express the transactions into a consistent consensus, and screen the valid transactions that reach the hash consensus as the valid transaction set completed during the validity period.

10. A blockchain system transaction processing device, characterized in that: The method according to any one of claims 1 to 9, comprising 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; The DDT candidate list execution module is used for each consensus node to execute each transaction in sequence according to the DDT candidate list, determine whether each transaction is completed within the validity period, determine the execution result information of each consensus node, and feedback it to the leader node. The execution result information includes the number of transactions executed by the consensus node and the valid completion information or invalid completion information of each transaction; A valid transaction confirmation module 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; A consensus module, configured for the consensus nodes 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 involved in these transactions.

Images