Block chain transaction processing method and device, equipment, medium and product

Abstract

The invention provides a block chain transaction processing method and device, equipment, a medium and a product. The method is executed by a first node device, and the method comprises the following steps: obtaining a target transaction in a block, the target transaction being a transaction whose consensus execution time is greater than or equal to a preset time threshold in a process of performing consensus processing on the block; packaging based on the target transaction to obtain a proposal, and broadcasting the proposal to N second node devices in the block chain; receiving voting information returned by the second node equipment for the proposal, wherein the voting information comprises a voting result of the target transaction in the proposal; analyzing each piece of received voting information by adopting a proposal consensus strategy, and determining the voting type of the target transaction; and performing transaction processing on the target transaction according to the voting type of the target transaction. According to the invention, the voting type of the overtime transaction in the block can be determined, and transaction processing is performed on the overtime transaction according to different voting types, so that the accuracy and efficiency of transaction processing can be improved.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular, to a blockchain transaction processing method, a blockchain transaction processing device, a computer device, a computer-readable storage medium, and a computer program product. Background Art

[0002] In the consensus processing of the blockchain, during the block packaging process, if there is a timeout transaction (that is, there is a method call with a relatively long running time in the contract function, so that the transaction calling the contract has a high probability of timing out during transaction execution and thus cannot reach a consensus) being packaged, it will greatly increase the duration of block packaging; and this timeout transaction will be released back to the transaction pool and thus repeatedly packaged, resulting in affecting the subsequent block generation process of the blockchain, thus greatly affecting the transaction processing efficiency of the blockchain. Summary of the Invention

[0003] Embodiments of this application propose a blockchain transaction processing method, device, equipment, medium, and product, which can determine the voting type of the timeout transaction (i.e., the target transaction) in the block, and perform transaction processing on the timeout transaction according to different voting types, which can improve the accuracy and efficiency of transaction processing.

[0004] On the one hand, embodiments of this application provide a blockchain transaction processing method. The blockchain includes: a first node device and N second node devices. The first node device is used to propose transactions in the blockchain, and the second node devices are used to perform voting processing on the proposals. N is a positive integer; this method is executed by the first node device, and this method includes:

[0005] Obtain the target transaction in the block. The target transaction refers to: in the process of consensus processing of the block, a transaction whose consensus execution time is greater than or equal to a preset time threshold;

[0006] Based on the target transaction, encapsulate a proposal and broadcast the proposal to the N second node devices in the blockchain, so that each second node device performs voting processing on the target transaction based on the consensus execution time of the target transaction;

[0007] Receive the voting information returned by the second node device for the proposal. The voting information includes the voting result for the target transaction in the proposal; the voting result includes a first result and a second result. The first result is used to indicate that the consensus execution time of the target transaction exceeds the preset time threshold; the second result is used to indicate that the consensus execution time of the target transaction does not exceed the preset time threshold;

[0008] Analyze each received voting information using a proposal consensus strategy and determine the voting type of the target transaction;

[0009] Perform transaction processing on the target transaction according to the voting type of the target transaction.

[0010] On the one hand, an embodiment of the present application provides a blockchain transaction processing method. The blockchain includes: a first node device and N second node devices. The first node device is used to propose a transaction in the blockchain, and the second node device is used to perform voting processing on the proposal, where N is a positive integer. This method is executed by the second node device and includes:

[0011] Receive the proposal sent by the first node device; the proposal is encapsulated based on the target transaction in the block, and the target transaction refers to: in the process of consensus processing on the block, a transaction whose consensus execution time is greater than or equal to the preset time threshold;

[0012] Call the timeout transaction processing engine to execute the target transaction in the proposal to obtain the execution result of the target transaction;

[0013] Based on the execution result, generate voting information for the target transaction; the voting information includes the voting result for the target transaction in the proposal; the voting result includes a first result and a second result. The first result is used to indicate that the consensus execution time of the target transaction exceeds the preset time threshold; the second result is used to indicate that the consensus execution time of the target transaction does not exceed the preset time threshold;

[0014] Return the voting information of the target transaction to the first node device;

[0015] Among them, the voting information is used to trigger the first node device to determine the voting type of the target transaction and perform transaction processing on the target transaction according to the voting type of the target transaction.

[0016] On the one hand, an embodiment of the present application provides a blockchain transaction processing device. The blockchain includes: a first node device and N second node devices. The first node device is used to propose a transaction in the blockchain, and the second node device is used to perform voting processing on the proposal, where N is a positive integer. This device is executed by the first node device and includes:

[0017] An acquisition unit, configured to acquire the target transaction in the block, where the target transaction refers to: in the process of consensus processing on the block, a transaction whose consensus execution time is greater than or equal to the preset time threshold;

[0018] A processing unit, configured to encapsulate a proposal based on the target transaction and broadcast the proposal to N second node devices in the blockchain, so that each second node device performs voting processing on the target transaction based on the consensus execution time of the target transaction;

[0019] A receiving unit, configured to receive voting information returned by a second node device for a proposal, where the voting information includes a voting result for a target transaction in the proposal; the voting result includes a first result and a second result, the first result is used to indicate that the consensus execution time of the target transaction exceeds a preset time threshold; the second result is used to indicate that the consensus execution time of the target transaction does not exceed the preset time threshold;

[0020] A processing unit, further configured to analyze each received voting information by using a proposal consensus strategy and determine the voting type of the target transaction;

[0021] The processing unit is further configured to perform transaction processing on the target transaction according to the voting type of the target transaction.

[0022] In a possible implementation, a timeout transaction processing engine is deployed in the first node device; after obtaining the target transaction in the block, the processing unit is further configured to perform the following operations:

[0023] Obtain a timeout transaction list maintained by the timeout transaction processing engine, where the timeout transaction list includes multiple data fields;

[0024] Call the timeout transaction processing engine to calculate the transaction information of the target transaction, where the transaction information includes any one or more of: an identifier of the target transaction, a timestamp for obtaining the target transaction, a block height of the block to which the target transaction belongs, and a block hash of the block to which the target transaction belongs;

[0025] Add the transaction information of the target transaction to each data field of the timeout transaction list.

[0026] In a possible implementation, the processing unit encapsulates a proposal based on the target transaction for performing the following operations:

[0027] Call the timeout transaction processing engine to pack the target transaction into a temporary block;

[0028] Execute the target transaction to obtain an execution result of the target transaction and a transaction read-write set;

[0029] Pack the execution result of the target transaction and the transaction read-write set into the temporary block, and perform signature processing on the packed temporary block by using the certificate data of the first node device to obtain a proposal.

[0030] In a possible implementation, a timer is deployed in the timeout transaction processing engine; the processing unit is further configured to perform the following operations:

[0031] Call the timer to periodically detect each target transaction in the timeout transaction list; where the periodic detection is used to indicate whether there is a target transaction that has not been synthesized into a voting set within a preset time period;

[0032] If it exists, delete the target transaction from the transaction pool of the blockchain.

[0033] In a possible implementation, the data fields of the timeout transaction list include: an identification field, a first voting field, and a second voting field. The first voting field is used to store voting data with a voting result of the first result, and the second voting field is used to store voting data with a voting result of the second result. After receiving the voting information returned by each second node device for the proposal, the processing unit is further configured to perform the following operations:

[0034] Query the identification field in the timeout transaction list. If the identification of the target transaction is found in the identification field, verify the voting information.

[0035] If the verification of the voting information is successful, obtain the voting result indicated by the voting information.

[0036] If the voting result indicated by the voting result is the first result, add the voting information to the first voting field of the timeout transaction list.

[0037] If the voting result indicated by the voting result is the second result, add the voting information to the second voting field of the timeout transaction list.

[0038] In a possible implementation, the processing unit analyzes the received voting information using a proposal consensus strategy and determines the voting type of the target transaction for performing the following operations:

[0039] Count the number K of voting information received by the first node device.

[0040] According to the received K voting information, synthesize a voting set for the target transaction using a proposal consensus strategy; K is a positive integer and K ≤ N.

[0041] Analyze the voting set to determine the voting type of the target transaction.

[0042] In a possible implementation, after the processing unit counts the number K of voting information received by the first node device, it is configured to perform the following operations:

[0043] Using a proposal consensus strategy, obtain the node fault tolerance number f corresponding to the N second node devices during the consensus process. f is a positive integer and N = 3f + 1.

[0044] If K ≥ 2f + 1, combine the K voting information into a voting set for the target transaction.

[0045] If K < 2f + 1, delete the target transaction from the transaction pool of the blockchain.

[0046] In a possible implementation, the proposal consensus strategy is used to indicate that the voting types of the target transaction include a first type and a second type; the processing unit analyzes the voting set to determine the voting type of the target transaction for performing the following operations:

[0047] Analyze K voting messages in the voting set using the proposal consensus strategy;

[0048] If the number of nodes with the first result in the voting is greater than or equal to f + 1, determine the voting type of the target transaction as the first type;

[0049] If the number of nodes with the second result in the voting is less than f + 1, determine the voting type of the target transaction as the second type.

[0050] In a possible implementation, any one of the voting messages includes the execution result obtained after the second node device executes the target transaction; the processing unit is further configured to perform the following operations:

[0051] If the number of nodes with the first result in the voting is greater than or equal to f + 1, obtain the execution results of the respective second node devices corresponding to the first result from the voting messages;

[0052] If the number of nodes with inconsistent execution results is greater than or equal to f + 1, determine the voting type of the target transaction as the first type.

[0053] In a possible implementation, the processing unit performs transaction processing on the target transaction according to the voting type of the target transaction for performing the following operations:

[0054] If the voting type of the target transaction is the first type, delete the target transaction from the transaction pool of the blockchain;

[0055] If the voting type of the target transaction is the second type, release the target transaction back to the transaction pool of the blockchain and update the status of the target transaction in the transaction pool.

[0056] On the one hand, an embodiment of the present application provides a blockchain transaction processing device. The blockchain includes: a first node device and N second node devices. The first node device is configured to propose a transaction in the blockchain, and the second node device is configured to perform voting processing on the proposal. N is a positive integer; the device is executed by the second node device, and the device includes:

[0057] A receiving unit, configured to receive a proposal sent by the first node device; the proposal is encapsulated based on a target transaction in a block, and the target transaction refers to: a transaction whose consensus execution time is greater than or equal to a preset time threshold during the process of consensus processing on the block;

[0058] A processing unit, configured to call a timeout transaction processing engine to execute a target transaction in a proposal, and obtain an execution result of the target transaction;

[0059] The processing unit is further configured to generate voting information for the target transaction based on the execution result; the voting information includes a voting result for the target transaction in the proposal; the voting result includes a first result and a second result, the first result is used to indicate that the consensus execution time of the target transaction exceeds a preset time threshold; the second result is used to indicate that the consensus execution time of the target transaction does not exceed the preset time threshold;

[0060] A sending unit, configured to return the voting information of the target transaction to the first node device;

[0061] Wherein, the voting information is used to trigger the first node device to determine the voting type of the target transaction, and perform transaction processing on the target transaction according to the voting type of the target transaction.

[0062] In a possible implementation, a coroutine pool is maintained in the timeout transaction processing engine, and at least one coroutine runs in the coroutine pool; the processing unit calls the timeout transaction processing engine to execute the target transaction in the proposal, and obtains the execution result of the target transaction, which is used to perform the following operations:

[0063] Call the timeout transaction processing engine to parse the proposal to obtain transaction information about the target transaction, where the transaction information includes any one or more of: an identifier of the target transaction, a timestamp for obtaining the target transaction, a block height of the block to which the target transaction belongs, and a block hash of the block to which the target transaction belongs;

[0064] Determine whether there is an idle coroutine in the coroutine pool;

[0065] If there is, execute the target transaction according to the transaction information in the idle coroutine, and obtain the execution result of the target transaction.

[0066] In a possible implementation, the processing unit generates voting information for the target transaction based on the execution result, which is used to perform the following operations:

[0067] Determine the consensus execution time of the target transaction based on the execution result;

[0068] If the consensus execution time of the target transaction is greater than or equal to the preset time threshold, determine that the voting result for the target transaction is the first result, and generate voting information based on the first result;

[0069] If the consensus execution time of the target transaction is less than the preset time threshold, determine that the voting result for the target transaction is the second result, and generate voting information based on the second result.

[0070] In a possible implementation, a trusted execution environment is deployed in the timeout transaction processing engine; the processing unit calls the timeout transaction processing engine to execute the target transaction in the proposal, and obtains the execution result of the target transaction for performing the following operations:

[0071] Obtain the transaction type of the target transaction;

[0072] If the transaction type is a preset type, call the timeout transaction processing engine in the trusted execution environment to execute the target transaction, and obtain the execution result of the target transaction.

[0073] On the one hand, an embodiment of the present application provides a computer device, which includes a memory and a processor. The memory stores a computer program. When the computer program is executed by the processor, the processor executes the above-mentioned blockchain transaction processing method.

[0074] On the one hand, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is read and executed by the processor of the computer device, the computer device executes the above-mentioned blockchain transaction processing method.

[0075] On the one hand, an embodiment of the present application provides a computer program product or a computer program, which includes computer instructions stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the above-mentioned blockchain transaction processing method.

[0076] In the embodiments of the present application, the first node device can obtain the target transaction in the block, where the target transaction refers to a transaction whose consensus execution time is greater than or equal to a preset time threshold during the consensus processing of the block; then a proposal can be encapsulated based on the target transaction and broadcast to N second node devices in the blockchain, so that each second node device votes on the type of the target transaction based on the consensus execution time of the target transaction; receive the voting information returned by the second node device for the proposal, and the voting information includes the voting result for the target transaction in the proposal; the voting result includes a first result and a second result, the first result is used to indicate that the consensus execution time of the target transaction exceeds the preset time threshold; the second result is used to indicate that the consensus execution time of the target transaction does not exceed the preset time threshold; analyze each received voting information using the proposal consensus strategy and determine the voting type of the target transaction; perform transaction processing on the target transaction according to the voting type of the target transaction. It can be seen that, on the one hand, the present application can separately execute the proposal processing for the timeout transaction (i.e., the target transaction) with a long consensus execution time in the block, so as to obtain the voting results of each second node device in the blockchain for the target transaction, and finally the voting type of the timeout transaction can be determined. Since the voting type for the timeout transaction is obtained after the proposal consensus of multiple second node devices in the blockchain, the determined voting type is more accurate; on the other hand, the method of separately processing the timeout transactions in the block according to the voting type can enable targeted transaction processing according to different transaction types during transaction processing, thereby improving the efficiency of transaction processing. BRIEF DESCRIPTION OF THE DRAWINGS

[0077] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the following drawings are some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0078] Figure 1 It is a flowchart of a chained consensus algorithm provided by an embodiment of the present application;

[0079] Figure 2a It is a schematic structural diagram of a blockchain system provided by an embodiment of the present application;

[0080] Figure 2b It is a flowchart of block generation provided by an embodiment of the present application;

[0081] Figure 2c It is a schematic structural diagram of a blockchain provided by an embodiment of the present application;

[0082] Figure 3It is a schematic structural diagram of a blockchain transaction processing system provided by an embodiment of the present application;

[0083] Figure 4 It is a schematic flowchart of a blockchain transaction processing method provided by an embodiment of the present application;

[0084] Figure 5a It is a schematic flowchart of a block consensus processing provided by an embodiment of the present application;

[0085] Figure 5b It is a schematic flowchart of a timeout transaction processing provided by an embodiment of the present application;

[0086] Figure 6 It is a schematic flowchart of a processing flow of voting information provided by an embodiment of the present application;

[0087] Figure 7 It is a schematic flowchart of another blockchain transaction processing method provided by an embodiment of the present application;

[0088] Figure 8a It is a schematic flowchart of a proposal processing provided by an embodiment of the present application;

[0089] Figure 8b It is a schematic flowchart of a processing flow of a voting set provided by an embodiment of the present application;

[0090] Figure 9 It is an interaction flowchart of a blockchain transaction processing method provided by an embodiment of the present application;

[0091] Figure 10 It is a schematic structural diagram of a blockchain transaction processing device provided by an embodiment of the present application;

[0092] Figure 11 It is a schematic structural diagram of another blockchain transaction processing device provided by an embodiment of the present application;

[0093] Figure 12 It is a schematic structural diagram of a computer device provided by an embodiment of the present application. Detailed implementation manners

[0094] Here, exemplary embodiments will be described in detail, and examples thereof are shown in the accompanying drawings. When the following description refers to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementation manners described in the following exemplary embodiments do not represent all implementation manners consistent with the present application. On the contrary, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0095] The present application provides a blockchain transaction solution, which is applicable to chain consensus algorithms such as the HotStuff algorithm, and can execute transaction processing on the timeout transaction in the block according to the voting type of the timeout transaction, thereby improving the accuracy and efficiency of transaction processing. Specifically, a timeout processing engine can be used to encapsulate the timeout transaction into a proposal and send it to each second node device in the blockchain for proposal consensus, so as to determine the voting type of the timeout transaction. Subsequently, based on the voting type, it can be determined how to execute transaction processing on the timeout transaction, such as deleting it from the transaction pool or putting it back into the transaction pool, etc.

[0096] The related technologies of the chain HotStuff algorithm will be introduced below. Please refer to Figure 1 for details. Figure 1 , Figure 1 is a schematic flowchart of a chain consensus algorithm provided by an embodiment of the present application. Among them, the chain HotStuff algorithm mainly includes the following four stages during consensus processing:

[0097] 1) Preparation stage (prepare stage): The primary node generates a proposal and broadcasts it to the secondary nodes; the secondary nodes generate prepare-stage votes (denoted as prepare votes) for the proposal and send them to the primary node.

[0098] 2) Pre-commit stage (pre-commit stage): The primary node synthesizes a preset number of prepare votes into a QC (vote set, denoted as prepareQC) in the preparation stage and broadcasts it to the secondary nodes; after verifying the prepareQC, the secondary nodes generate pre-commit stage votes (denoted as pre-commit votes) and send them to the primary node.

[0099] 3) Commit stage (commit stage): The primary node synthesizes a preset number of pre-commit votes into a QC in the pre-commit stage (denoted as pre-commitQC) and broadcasts it to the secondary nodes; after verifying the pre-commitQC, the secondary nodes generate commit stage votes (denoted as commit votes) and send them to the primary node.

[0100] 4) Decision stage (decide stage): The primary node synthesizes a preset number of commit votes into a QC in the commit stage (denoted as commitQC), broadcasts it to the secondary nodes, and submits the proposal; after verifying the commitQC, the secondary nodes submit the proposal.

[0101] As Figure 1 shown, the consensus process of the chain HotStuff algorithm mainly includes the following steps 1)-16), and these steps are further divided into view Figure 1 , view 2, view Figure 3 , view Figure 4Among them:

[0102] I. View Figure 1 。

[0103] 1) Node 1 serves as the primary node of the view Figure 1 to package the block and generate Proposal 1.

[0104] 2) Node 1 broadcasts Proposal 1, which it has generated, to the slave nodes (Nodes 2, 3, and 4); and generates a prepare vote for Proposal 1 and sends it to the primary node of the next view, i.e., Node 2.

[0105] 3) The slave nodes verify Proposal 1 and add Proposal 1 to the local memory of the nodes.

[0106] 4) The slave nodes generate a prepare vote for Proposal 1 and send it to the primary node of the next view (i.e., Node 2). Thus, Proposal 1 has completed the first phase, i.e., the preparation phase.

[0107] II. View 2.

[0108] 5) Node 2 serves as the primary node of View 2, collects the prepare votes for Proposal 1, synthesizes the prepare QC (QC1) of Proposal 1, packages a new block to generate Proposal 2, and attaches QC1 to Proposal 2.

[0109] 6) Node 2 broadcasts Proposal 2, which it has generated, to the slave nodes (Nodes 1, 3, and 4), and generates a vote for Proposal 2 and sends it to the primary node of the next view (i.e., Node 3).

[0110] 7) The slave nodes verify Proposal 2 and QC1 and add Proposal 2 and QC1 to the local memory of the nodes.

[0111] 8) The slave nodes generate a vote for Proposal 2 (this vote is a prepare vote for Proposal 2, but since it is cast after verifying QC1, it also serves as a pre-commit vote for Proposal 1); the slave nodes send the vote to the primary node of the next view (i.e., Node 3). Thus, Proposal 2 has completed the first phase, i.e., the preparation phase; at the same time, since QC1 (the prepare QC of Proposal 1) has also been verified and voted on by a preset number of slave nodes during this process, Proposal 1 has completed the second phase, i.e., the pre-commit phase.

[0112] III. View Figure 3 。

[0113] 9) Node 3 serves as the primary node of the view Figure 3 to collect the votes for Proposal 2, synthesize QC2, package a new block to generate Proposal 3, and attach QC2 to Proposal 3.

[0114] 10) Node 3 broadcasts the generated Proposal 3 to the slave nodes (nodes 1, 2, and 4); and generates a vote for Proposal 3 and sends it to the master node of the next view (i.e., node 4).

[0115] 11) The slave node verifies Proposal 3 and QC2, and adds Proposal 3 and QC2 to the node local memory.

[0116] 12) The slave node generates a vote for Proposal 3 and sends it to the master node of the next view (i.e., Node 2). At this point, Proposal 3 has completed the preparation phase; for the reasons mentioned above, Proposal 2 has also completed the pre-commit phase; since the vote contained in QC2 is also the pre-commit vote for Proposal 1, QC2 is not only the prepareQC for Proposal 2, but also the pre-commitQC for Proposal 1; therefore, the vote cast by the slave node after verifying QC2 is the prepare vote for Proposal 3, but also the pre-commit vote for Proposal 2 and the commit vote for Proposal 1; that is, Proposal 1 has completed the submission phase.

[0117] 4. Visual Figure 4 .

[0118] 13) Node 4 is used as the view Figure 4 The master node collects votes for Proposal 3, synthesizes QC3, packages a new block to generate Proposal 4, and attaches QC3 to Proposal 4.

[0119] 14) Node 4 broadcasts the generated Proposal 4 to the slave nodes (nodes 1, 2, and 3); Node 4 processes Proposal 4 and QC3, generates a vote for Proposal 4, and sends it to the master node of the next view (i.e., node 1); for the reasons mentioned above, QC3 serves as the prepareQC for Proposal 3, the pre-commitQC for Proposal 2, and also as the commitQC for Proposal 1; when processing QC3, Node 4 finds a proposal (i.e., Proposal 1) in memory that complies with the 3-chain rule (i.e., three QCs connected in sequence: QC1<-QC2<-QC3), that is, Proposal 1 has reached the decision-making stage, and Node 4 submits Proposal 1.

[0120] 15) The slave node verifies Proposal 4 and QC3, and adds Proposal 4 and QC3 to its own memory. During verification, the slave node finds that a proposal that complies with the 3-chain rule (i.e. Proposal 1) appears in its memory, which means that the proposal has reached the decision-making stage, so Proposal 1 is submitted.

[0121] 16) The follower node generates a vote for Proposal 4 (which serves as the prepare vote for Proposal 4, the pre-commit vote for Proposal 3, and the commit vote for Proposal 2) and sends it to the leader node of the next view, i.e., Node 2. For the reasons mentioned above, at this point, Proposal 4 has completed the prepare phase, Proposal 3 has completed the pre-commit phase, Proposal 2 has completed the commit phase, and Proposal 1 has completed the decision phase and has been committed.

[0122] As can be seen from the above steps 1)-16), Figure 1 View 1 is the prepare phase of Proposal 1; View 2 is the prepare phase of Proposal 2 and also the Figure 1 pre-commit phase of Figure 3 View 3 is the prepare phase of Proposal 3, the pre-commit phase of Proposal 2, and the commit phase of Proposal 1; Figure 4 View 4 is the prepare phase of Proposal 4, the pre-commit phase of Proposal 3, the commit phase of Proposal 2, and the decide phase of Proposal 1.

[0123] In this application, for timeout transactions (consensus execution time is greater than or equal to the preset time threshold) in the processing flow of the HotStuff chained consensus algorithm, to avoid the impact of timeout transactions on the entire consensus process. This application proposes a blockchain transaction processing solution, which is executed by the first node device (such as the leader node) in the blockchain. The blockchain includes: a first node device and N second node devices. The first node device is used to propose transactions in the blockchain, and the second node devices are used to vote on the proposals. N is a positive integer. Among them, the general principle of this blockchain transaction processing solution is as follows: During the block consensus process, obtain a timeout transaction (i.e., the target transaction) from the block. The target transaction refers to a transaction whose consensus execution time is greater than or equal to the preset time threshold during the consensus processing of the block. Then encapsulate the target transaction as a proposal and broadcast the proposal to the N second node devices in the blockchain, so that each second node device votes on the target transaction based on the consensus execution time of the target transaction. Subsequently, the first node device can receive the voting information returned by the second node devices for the proposal. The voting information includes the voting results of the second node devices on the target transaction in the proposal; the voting results include a first result and a second result. The first result is used to indicate that the consensus execution time of the target transaction exceeds the preset time threshold; the second result is used to indicate that the consensus execution time of the target transaction does not exceed the preset time threshold; the first node device analyzes the received voting information using the proposal consensus strategy and determines the voting type of the target transaction; finally, the target transaction can be processed according to the voting type of the target transaction.

[0124] It can be seen that based on the above process, on the one hand, the present application can hand over the timeout transactions in the block whose consensus execution time is greater than or equal to the preset time threshold to the timeout transaction processing engine for separate processing. Therefore, the present application can still not affect the main process of consensus processing when a timeout transaction occurs during the consensus process, thereby ensuring the correct execution of the consensus process and improving the accuracy and efficiency of transaction processing; on the other hand, the present application can encapsulate transactions with local execution timeout as proposals and broadcast them to each second node device for proposal consensus, thereby comprehensively determining the voting type of the timeout transaction according to the voting information of multiple second node devices, and subsequently executing corresponding transaction processing on the timeout transaction according to the voting type. This method of separately processing the timeout transactions in the block according to the voting type can enable targeted transaction processing according to different transaction types during transaction processing, thereby improving the accuracy of transaction processing.

[0125] The key technical terms involved in this application are introduced in detail below.

[0126] 1. Target transaction and proposal.

[0127] The target transaction refers to any transaction in the transaction pool of the blockchain, specifically: in the process of consensus processing of the block, the consensus execution time is greater than or equal to the preset time threshold. The so-called consensus execution time includes: the time spent on calling the smart contract to execute the target transaction. The target transaction can be any type of transaction, such as: game type, asset type, contract type, etc.; wherein, the consensus execution time corresponding to different types of transactions may be different, and different preset time thresholds may be set for different types of transactions, for example, the preset time threshold corresponding to game type transaction 1 is t1; and the preset time threshold corresponding to asset type transaction 2 is t2, t1≠t2 or t1=t2.

[0128] Among them, when the target transaction is a game-type transaction, the target transaction can be any transaction in the cloud game scenario. The cloud game here can be any game in the artificial intelligence scenario, the so-called artificial intelligence (AI) service. The so-called artificial intelligence is a comprehensive discipline that covers a wide range of fields, including both hardware-level technology and software-level technology. The basic technologies of artificial intelligence generally include technologies such as sensors, dedicated artificial intelligence chips, cloud computing, cloud games, distributed storage, big data processing technology, operation / interaction systems, and mechatronics. Artificial intelligence software technology mainly includes computer vision technology, speech processing technology, natural language processing technology, and machine learning / deep learning.

[0129] A proposal refers to a type of data that is exchanged between a first node device and a second node device during the consensus processing. For example, the first node device is responsible for generating the proposal, and the second node device is responsible for receiving the proposal. Among them, the proposal is obtained by encapsulating a block, and the block is obtained by encapsulating a transaction. For example, the process of generating a proposal in this application may include: obtaining a target transaction -> encapsulating the target transaction into a temporary block -> executing the target transaction to obtain an execution result and a transaction read-write set (i.e., the read data set and write data set of the target transaction) -> attaching the execution result and the transaction read-write set to the temporary block -> obtaining a proposal after the node signs the temporary block.

[0130] II. Voting.

[0131] Voting refers to an operation performed by a follower node on the target transaction in a proposal during the consensus processing of the proposal, and based on this operation, a voting result for the target transaction is obtained. The voting result includes a first result and a second result. Specifically, the voting operation of this application may include: First, the follower node needs to verify that the proposal comes from a specified first node device; Second, the follower node needs to determine the relationship between the consensus execution time of the target transaction in the proposal and a preset time threshold. If the consensus execution time of the target transaction exceeds the preset time threshold, a first result is generated; if the consensus execution time of the target transaction does not exceed the preset time threshold, a second result is generated. In summary, the voting process of this application is an operation based on the consensus execution time of the target transaction in the proposal, and the obtained voting result is also the voting result for the target transaction.

[0132] III. Voting Type.

[0133] The voting type is the type of the voting set analyzed based on the voting results of each second node device in the blockchain for the target transaction in the proposal. The so-called voting set refers to the QC (Quorum Certificate) set composed of the voting information of each second node device received by the first node device. If the number of received voting information exceeds 2f + 1, a QC set can be formed; if the number of received voting information in the first set is less than 2f + 1, a QC set cannot be formed. In this application, the voting types for the QC set formed for the target transaction can include the following two types: "Reject Qc" (the first type) and "Retry Qc" (the second type). Among them, different voting types are determined by analyzing each voting information. For example, when the number of nodes with the first result in the voting information is greater than or equal to f + 1, it can be considered that the voting type of the target transaction is the first type; another example is that when the number of nodes with the second result in the voting information is less than f + 1, it can be considered that the voting type of the target transaction is the second type.

[0134] IV. Blockchain Technology

[0135] Blockchain is a new application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithms. Blockchain, in essence, is a decentralized database, a series of data blocks generated by using cryptographic methods. Each data block contains information on a batch of network transactions, which is used to verify the validity of the information (anti-counterfeiting) and generate the next block. The following explains related concepts such as blockchain systems, blockchain nodes, and block structures.

[0136] (1) Blockchain system.

[0137] Please refer to Figure 2a , Figure 2a which is a schematic structural diagram of a blockchain system provided by an embodiment of this application. As Figure 2a shown, the blockchain system can be a data sharing system. A data sharing system refers to a system used for data sharing between node devices. The data sharing system 200 may include multiple blockchain nodes. The types of each blockchain node may be the same or different. For example, the blockchain nodes in the data sharing system 200 may specifically include: node device 201 and node device 202. Among them, node device 201 may be the main node in the blockchain (also referred to as the leader node or the first node device), and node device 202 may be the slave node (also referred to as the follower node or the second node device). The node device 201 may be a node elected by all consensus nodes in the blockchain network based on the consensus algorithm. Node device 201 and node device 202 may be collectively referred to as consensus nodes. Any blockchain node may refer to a computer device in the data sharing system. The computer device may be, for example, a terminal device or a server. Among them, each node in the data sharing system 200 may form a peer-to-peer network. A peer-to-peer protocol runs in the peer-to-peer network. The peer-to-peer protocol is an application layer protocol running on top of the Transmission Control Protocol (TCP). The TCP protocol is used to maintain the above data sharing system.

[0138] In an embodiment of this application, the node device 201 may generate a proposal corresponding to the target transaction, and the node device 201 broadcasts the proposal to each node device 202 in the blockchain, so that transaction processing of the target transaction is performed based on each blockchain node in the blockchain. Therefore, next, the corresponding introduction is made on how blocks are consensus among nodes (main node and slave node) in the blockchain system and related functions implemented by the nodes.

[0139] 1) Block consensus between the main node and the slave node:

[0140] Specifically, to ensure information intercommunication within the blockchain system, there may be information connections between each pair of nodes in the blockchain system, and information transmission can be carried out between nodes through the above-mentioned information connections. Among them, the above-mentioned information connections do not limit the specific connection method. For example, they can be directly or indirectly connected through wired communication methods, or directly or indirectly connected through wireless communication methods, or through other connection methods, which are not limited in this application.

[0141] It can be understood that each blockchain node (the main node 201 or the slave node 202) can receive input information during normal operation and maintain the shared data within the data sharing system based on the received input information. For example, when the main node 201 in the blockchain system receives input information (for example, the main node can receive one or more transaction data sent by a client), the main node 201 can package the received multiple transaction data into a block, and then sign the block based on the certificate data of the main node to generate a proposal corresponding to the block. Another example is that the slave node 202 can also receive input information (for example, a proposal sent by the main node 101), and the slave node 202 can parse the transactions in the proposal and perform voting processing on the transactions in the proposal. Finally, after the main node 201 and each slave node 202 in the blockchain reach a consensus on the proposal, both the main node 201 and the slave node 202 can store the current block, thereby maintaining the shared data (each transaction data) within the above-mentioned data sharing system.

[0142] 2) Functions of nodes:

[0143] a. Application function, which is used to be deployed in the blockchain, implement specific services according to actual business requirements, record the data related to the implemented functions to form record data (transaction data). For example, the transaction data can refer to the data used to implement the resource transfer service; another example is that the transaction data can refer to the data used to implement the electronic invoice service; and another example is that the transaction data can refer to the data used to implement the game service, and so on. A digital signature (such as the signature endorsement information executed by the main node on the transaction block based on certificate data such as node certificates or public keys) can be carried in the record data to indicate the source of the task data, and the record data can be sent to other slave nodes in the blockchain system. When other slave nodes verify the source and integrity of the record data successfully, the record data can be added to the temporary block. Subsequently, after the main node and the slave nodes reach a consensus on the transaction block, the transaction block including each transaction data can be added to the blockchain.

[0144] b. Routing function, which is a basic function possessed by any node in the blockchain system and is used to support communication between nodes. Specifically, in the block consensus process between the master node 201 and the slave node 202 mentioned above, data interaction between nodes is involved. During the data interaction process, the data interaction process between nodes is achieved based on the routing functions of each node.

[0145] 3) Node identifier:

[0146] For each node (master node and slave node) in the blockchain system, there is a corresponding node identifier, and each node in the blockchain system can store the node identifiers of other nodes in the blockchain system, so as to broadcast the generated block to other nodes in the blockchain system according to the node identifiers of other nodes later. A node identifier list as shown in the following table can be maintained in each node, and the node name and node identifier are correspondingly stored in this node identifier list.

[0147] Among them, the node identifier can be an IP (Internet Protocol) address and any other information that can be used to identify the node. Only the IP address is taken as an example in Table 1 for illustration.

[0148] Table 1. Node identifier list

[0149] Node Name Node Identifier Node 1 000.000.000.000 Node 2 111.111.111.111 … … Node N xxx.xxx.xxx.xxx

[0150] In the embodiments of the present application, when each node in the blockchain system conducts data interaction (for example, the data interaction process in which the master node sends a proposal to the slave node), it can carry its own node identifier, so that other nodes can perform node verification processing based on the corresponding node identifier before consensus processing, thereby improving the security of the blockchain consensus process.

[0151] (2) Block.

[0152] The present application mainly relates to block consensus. Before block consensus, the master node needs to generate a corresponding block according to the transaction data, so as to facilitate the subsequent block consensus of the slave node for the transactions in the block. Therefore, next, how to generate a block and the structure of the block will be elaborated in detail respectively.

[0153] 1) Generation of the block:

[0154] See Figure 2b , Figure 2b which is a schematic flowchart of the process of generating a block provided by the embodiments of the present application. As Figure 2bAs shown, when generating a block in the blockchain, upon receiving input information (transaction data), the master node can verify the input information. After completion of the verification, the input information is stored in the memory pool (transaction pool), and its hash tree for recording the input information is updated. Subsequently, the update timestamp is updated to the time when the input information is received, and different random numbers are tried, and the eigenvalue calculation is performed multiple times so that the calculated eigenvalue can satisfy the following formula:

[0155] SHA256(SHA256(version + prev_hash + merkle_root + ntime + nbits + x)) < TARGET

[0156] Wherein, SHA256 is the eigenvalue algorithm used for calculating the eigenvalue; version (version number) is the version information of the relevant block protocol in the blockchain; prev_hash is the block header eigenvalue of the parent block of the current block; merkle_root is the eigenvalue of the input information; ntime is the update time of the update timestamp; nbits is the current difficulty, which is a fixed value within a certain period of time and is determined again after exceeding the fixed time period; x is a random number; TARGET is the eigenvalue threshold, and this eigenvalue threshold can be determined according to nbits.

[0157] In this way, when a random number that satisfies the above formula is calculated, the information can be correspondingly stored to generate a block header and a block body, obtaining the current block. Subsequently, according to the node identifiers of other nodes (slave nodes) in the data sharing system, the master node sends the proposals of the newly generated block to the slave nodes in the data sharing system where it is located respectively. The slave nodes perform consensus on the transaction block, and after completion of the consensus, add the newly generated block to the blockchain stored by them.

[0158] 2) Structure of the block:

[0159] See Figure 2c , Figure 2c which is a schematic structural diagram of a blockchain provided by an embodiment of the present application. As Figure 2cAs shown in the figure, a blockchain consists of multiple blocks, and each blockchain contains a genesis block. As the name implies, the genesis block is the first block, the initial block. The genesis block includes a block header and a block body. The block header stores the input information feature value, version number, timestamp, and difficulty value, and the block body stores the input information (such as various transaction data); the next block of the genesis block uses the genesis block as its parent block. The next block also includes a block header and a block body. The block header stores the input information feature value of the current block, the block header feature value of the parent block, version number, timestamp, and difficulty value, and so on. This ensures that the block data stored in each block in the blockchain is associated with the block data stored in the parent block, guaranteeing the security of the transaction data in the block.

[0160] In the embodiment of this application, when constructing a proposal, the primary node can package the voting qc (quorum certificate) data of the previous block into the proposal. Based on the structure of the blockchain, when a secondary node receives the proposal later, it can verify that the parent block (the previous block) referenced by the current block has reached an agreement among most nodes according to the voting qc data in the proposal, ensuring the reliability of blockchain consensus.

[0161] V. Cloud Technology

[0162] In the blockchain transaction processing solution proposed in this application, there are a lot of data computing services and data storage services involved, so a large amount of computer operation costs are required. Then, the blockchain transaction processing solution provided in this application can adopt cloud technology. For example, it can adopt the data computing service and data storage service provided by cloud technology; specifically, this application can call the data computing service to analyze each received voting information to determine the voting type of the target transaction; and, this application can also call the data storage service to store the execution results of each transaction in the blockchain. Among them, cloud technology (Cloud technology) is the general term for network technology, information technology, integration technology, management platform technology, application technology, etc. based on the cloud computing business model, which can form a resource pool, be used on demand, and is flexible and convenient. Among them, cloud technology can include cloud storage technology. Cloud storage (cloud storage) is a new concept extended and developed from the cloud computing concept. A distributed cloud storage system (hereinafter referred to as the storage system) refers to a storage system that combines a large number of different types of storage devices (storage devices are also called storage nodes) in the network through functions such as cluster applications, grid technology, and distributed file systems, and works together through application software or application interfaces to jointly provide data storage and business access functions.

[0163] It should be noted that, in the present application, relevant data in the blockchain transaction processing process, such as voting information, voting results, and voting types of target transactions, etc. When the above embodiments of the present application are applied to specific products or technologies, user permission or consent needs to be obtained, and the processes of collecting, using, and processing relevant data need to comply with relevant laws, regulations, and standards of the country and region, and conform to the principles of legality, legitimacy, and necessity, without involving obtaining data types prohibited or restricted by laws and regulations. In some alternative embodiments, the relevant data involved in the embodiments of the present application are obtained after separate authorization by the object. In addition, when obtaining separate authorization from the object, the purpose of the relevant data involved needs to be stated to the object.

[0164] Next, a specific introduction to the architecture diagram of the blockchain transaction processing system provided by the present application will be given.

[0165] Please refer to Figure 3 , Figure 3 which is a schematic diagram of the architecture of a blockchain transaction processing system provided by an embodiment of the present application. As Figure 3 shown, the architecture diagram of the blockchain transaction processing system may at least include: a first node device 301 and at least one second node device 302. Among them, both the first node device 301 and the second node device 302 can be collectively referred to as consensus nodes in the blockchain system. The so-called consensus nodes are the key to maintaining the data consistency of the entire blockchain network. Generally speaking, in a plurality of consensus nodes corresponding to the block consensus process, the number of the first node devices 301 (also called master nodes) is one, and the number of the second node devices 302 (also called slave nodes) is multiple. The present application does not specifically limit the number of the second node devices 302, and the number of second nodes can be flexibly changed according to different types of transaction scenarios. In addition, the first node device 301 can be directly or indirectly connected to any second node device 302 through wired or wireless communication means.

[0166] In a blockchain transaction processing system, the first node device 301 and the second node device 302 can be mobile phones, tablet computers, laptop computers, palmtop computers, mobile internet devices (MIDs), vehicles, in-vehicle devices, roadside devices, aircraft, wearable devices, such as smart watches, smart bands, pedometers and other intelligent devices, virtual reality devices... and so on. The first node device 301 and the second node device 302 can also be servers. Specifically, the server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0167] It can be understood that the types of each node device in the blockchain transaction processing system of the present application can be the same or different. For example, the first node device 301 can be a server, and the second node device 302 can be a mobile phone; again, for example, both the first node device 301 and the second node device 302 can be laptop computers. The present application does not limit the number and type of each node device in the blockchain transaction processing system.

[0168] In a possible implementation manner, the first node device 301 can be a node selected by all consensus nodes in the blockchain network based on a consensus algorithm (for example, the consensus algorithm of chained HotStuff. Chained HotStuff is a consensus protocol based on View (view). A view represents a consensus unit, and the consensus process is composed of one view after another. In a view, there is a Leader node to dominate the consensus protocol, and consensus is reached through three-phase voting, and then switch to the next view to continue the consensus), and the second node device 302 refers to other consensus nodes in the blockchain network except the first node device 301.

[0169] The following describes the data interaction process between the first node device 301 and the second node device 302 in the blockchain transaction processing system.

[0170] ① The first node device 301 obtains the target transaction in the block. The target transaction refers to: in the process of consensus processing of the block, a transaction whose consensus execution time is greater than or equal to a preset time threshold.

[0171] ② The first node device 301 encapsulates a proposal based on the target transaction and broadcasts the proposal to N second node devices 302 in the blockchain.

[0172] ③ The second node device 302 votes on the target transaction based on the consensus execution time of the target transaction to obtain voting information. The voting information includes the voting result for the target transaction in the proposal; the voting result includes a first result and a second result, where the first result is used to indicate that the consensus execution time of the target transaction exceeds a preset time threshold; the second result is used to indicate that the consensus execution time of the target transaction does not exceed the preset time threshold.

[0173] ④ The second node device 302 sends the voting information to the first node device 301.

[0174] ⑤ The first node device 301 analyzes the received voting information using the proposal consensus strategy and determines the voting type of the target transaction.

[0175] ⑥ The first node device 301 processes the target transaction according to the voting type of the target transaction. For example, if the voting type is the first type, the target transaction is deleted from the transaction pool; if the voting type is the second type, the target transaction is returned to the transaction pool and the status is updated.

[0176] In the blockchain transaction processing system provided by this application, the first node device can obtain the target transaction in the block, where the target transaction refers to a transaction whose consensus execution time is greater than or equal to the preset time threshold during the consensus processing of the block; then a proposal can be encapsulated based on the target transaction and broadcast to N second node devices in the blockchain, so that each second node device votes on the type of the target transaction based on the consensus execution time of the target transaction; receive the voting information returned by the second node device for the proposal, where the voting information includes the voting result for the target transaction in the proposal; the voting result includes a first result and a second result, where the first result is used to indicate that the consensus execution time of the target transaction exceeds the preset time threshold; the second result is used to indicate that the consensus execution time of the target transaction does not exceed the preset time threshold; analyze the received voting information using the proposal consensus strategy and determine the voting type of the target transaction; process the target transaction according to the voting type of the target transaction. Thus, on the one hand, this application can separately execute the proposal processing for the timeout transactions (i.e., target transactions) with a long consensus execution time in the block, so as to obtain the voting results of each second node device in the blockchain for the target transaction, and finally determine the voting type of the timeout transaction. Since the voting type for the timeout transaction is obtained after the proposal consensus of multiple second node devices in the blockchain, the determined voting type is more accurate; on the other hand, the method of separately processing the timeout transactions in the block according to the voting type can enable targeted transaction processing according to different transaction types during transaction processing, thereby improving the efficiency of transaction processing.

[0177] It is understandable that the blockchain transaction processing system described in the embodiments of this application is to more clearly illustrate the technical solutions of the embodiments of this application, and does not constitute a limitation on the technical solutions provided by the embodiments of this application. As is known to those of ordinary skill in the art, with the evolution of the system architecture and the emergence of new business scenarios, the technical solutions provided by the embodiments of this application are equally applicable to similar technical problems.

[0178] The following describes specific embodiments related to the blockchain transaction processing solution with reference to the accompanying drawings.

[0179] Please refer to Figure 4 , Figure 4 which is a schematic flowchart of a blockchain transaction processing method provided by an embodiment of this application. This method can be executed by the first node device in the blockchain transaction processing system shown in Figure 3 . As shown in Figure 4 , this blockchain transaction processing method mainly includes, but is not limited to, the following steps S401 - S405:

[0180] S401: Obtain the target transaction in the block. The target transaction refers to: in the process of consensus processing of the block, a transaction whose consensus execution time is greater than or equal to a preset time threshold.

[0181] The target transaction can be any type of transaction, such as: game type, asset type, contract type, etc.; among them, the consensus execution time corresponding to different types of transactions can be different, and for different types of transactions, different preset time thresholds can be set. For example, the preset time threshold for transaction 1 of the game type is t1; another example is that the preset time threshold for transaction 2 of the asset type is t2, where t1 ≠ t2 or t1 = t2.

[0182] In a possible implementation manner, an overtime transaction processing engine is deployed in the first node device, and the first node device can obtain the target transaction from the block by calling the overtime transaction processing engine. The following briefly describes the process of obtaining the target transaction with reference to Figure 5a .

[0183] Please refer to Figure 5a , Figure 5a which is a schematic flowchart of a method for obtaining a target transaction provided by an embodiment of this application. As shown in Figure 5a , when the first node device performs consensus processing on the transactions in the blockchain, the following steps can be included: 1) Obtain a batch of transactions (for example, 100) from the transaction pool and package them into block 1; 2) Execute all the transactions in block 1; 3) For the successfully executed transactions, attach the execution results and transaction read - write sets to the block; 4) For the transactions that time out during execution (i.e., the target transactions), send them to the "overtime transaction processing engine"; 5) The overtime transaction processing engine encapsulates the block as a proposal; 6) Broadcast the proposal.

[0184] In the above consensus processing flow, for the timeout transactions in the block, the present application can separately hand over the timeout transactions to the timeout transaction processing engine for processing, which can not affect the main process of block consensus during the consensus processing, thereby improving the efficiency of block consensus.

[0185] S402: Package a proposal based on the target transaction, and broadcast the proposal to N second node devices in the blockchain, so that each second node device votes on the target transaction based on the consensus execution time of the target transaction.

[0186] In a possible implementation manner, the first node device packages a proposal based on the target transaction, which mainly includes the following steps: call the timeout transaction processing engine to package the target transaction into a temporary block; execute the target transaction to obtain the execution result and transaction read-write set of the target transaction; package the execution result and transaction read-write set of the target transaction into the temporary block, and sign the packaged temporary block with the certificate data of the first node device to obtain a proposal. Among them, the transaction read-write set includes a read data set and a write data set. The so-called read data set may include: relevant parameters of the smart contract to be called for executing the target transaction, such as: contract name, contract address; the so-called write data set may include: the execution result obtained by calling the smart contract to execute the target transaction, etc. In addition, the certificate data here may include: node certificate, node private key, etc. Specifically, the node certificate may include: the start time of certificate issuance, the expiration time of certificate validity, the organizational role corresponding to the first node device, etc. Among them, the so-called node certificate refers to a digital certificate with an authoritative nature (such as a CA certificate) issued by a certificate issuing authority (i.e., an institution with credibility) for the first node device, and one node corresponds to one node certificate.

[0187] For example, for Figure 5a the transactions with timeout execution in the block involved in the process, the present application can call the timeout transaction processing engine deployed in the first node device for processing. The specific processing process can refer to Figure 5b , Figure 5b which is a schematic flow diagram of a timeout transaction processing provided by an embodiment of the present application. As Figure 5b shown, the processing flow for timeout transactions may include the following steps:

[0188] 1. Receive a transaction with local execution timeout from the main process (i.e., Figure 5a the "transaction with timeout execution" mentioned in step 4), and use the Figure 5a mentioned transaction with timeout execution as the target transaction. The target transaction refers to: in the process of consensus processing of the block, a transaction whose consensus execution time is greater than or equal to the preset time threshold.

[0189] 2. Add the transaction information of the target transaction to the timeout transaction list. The transaction information may include: the identifier of the target transaction (such as ID, name, etc.), the timestamp when the target transaction is added, the block height based on which the transaction is executed, and the block hash, etc.

[0190] 3. Package the transaction into a "temporary block"; for example, add the transaction information of the target transaction to the block body of the temporary block, and add the transaction hash of the target transaction to the block header of the temporary block.

[0191] 4. Package the temporary block and related information into a "temporary proposal"; specifically, sign the temporary block to obtain the proposal, for example, sign the proposal using the private key of the first node device.

[0192] 5. Broadcast the "temporary proposal" to the slave nodes (i.e., N second node devices) so that each second node device votes on the type of the target transaction based on the consensus execution time of the target transaction.

[0193] In the processing flow shown in the above steps 1-5, for the timeout transaction in the block, this application can package the timeout transaction (i.e., the target transaction) into a temporary block; and package the temporary block into a proposal and broadcast it to each second node device to vote on the target transaction. It can be seen that the timeout transaction can be voted by multiple second node devices in the blockchain, avoiding situations such as the first node device acting maliciously, thereby improving the security and reliability of the processing of the timeout transaction.

[0194] S403: Receive the voting information returned by the second node device for the proposal. The voting information includes the voting result for the target transaction in the proposal; the voting result includes a first result and a second result. The first result is used to indicate that the consensus execution time of the target transaction exceeds the preset time threshold; the second result is used to indicate that the consensus execution time of the target transaction does not exceed the preset time threshold.

[0195] In a possible implementation, after the first node device obtains the target transaction in the block, it is further used to perform the following operations: First, obtain the timeout transaction list maintained by the timeout transaction processing engine, where the timeout transaction list includes multiple data fields; then, call the timeout transaction processing engine to calculate the transaction information of the target transaction, and the transaction information includes: any one or more of the identifier of the target transaction (such as name, or ID, etc.), the timestamp for obtaining the target transaction (this timestamp can be the timestamp corresponding to when the target transaction is added to the timeout transaction list), the block height of the block to which the target transaction belongs, and the block hash (PreHash) of the block to which the target transaction belongs; finally, add the transaction information of the target transaction to each data field of the timeout transaction list. For example, the data fields of the timeout transaction list can include: an identifier field, a timestamp field, a block height field, a block hash field, etc. Then, when adding the transaction information to the timeout transaction list, it specifically includes: the identifier of the target transaction is added to the identifier field; the timestamp for obtaining the target transaction is added to the timestamp field; the block height of the block to which the target transaction belongs is added to the block height field; and the block hash of the block to which the target transaction belongs is added to the block hash field.

[0196] In a possible implementation, the data fields of the timeout transaction list include: an identifier field, a first vote field, and a second vote field. The first vote field is used to store vote data with a vote result of the first result, and the second vote field is used to store vote data with a vote result of the second result; after the first node device receives the vote information returned by each second node device for the proposal, it is further used to perform the following operations: query the identifier field in the timeout transaction list, and if the identifier of the target transaction is found in the identifier field, perform verification processing on the vote information; if the verification of the vote information is successful, obtain the vote result indicated by the vote information; if the vote result indicated by the vote result is the first result, add the vote information to the first vote field of the timeout transaction list; if the vote result indicated by the vote result is the second result, add the vote information to the second vote field of the timeout transaction list.

[0197] Therefore, the data structure of the timeout transaction list can be as shown in Table 2 below:

[0198] Table 2. Timeout Transaction List

[0199]

[0200]

[0201] As shown in Table 2 above, assume that this application includes four node devices (e.g., Node 1, 2, 3, 4). For any transaction (e.g., Transaction 001), relevant data regarding the first voting result (e.g., timeout vote) of this Transaction 001 can be recorded in the first voting field, such as [Node 1 - timeout vote], [Node 2 - timeout vote]; similarly, relevant data regarding the second voting result (e.g., approval vote) of this Transaction 001 can be recorded in the second voting field, such as [Node 3 - approval vote], [Node 4 - approval vote].

[0202] In a possible implementation, a timer is deployed in the timeout transaction processing engine; the first node device is further configured to perform the following operations: call the timer to periodically detect each target transaction in the timeout transaction list; where the periodic detection is used to indicate whether there is a target transaction that has not been synthesized into a voting set within a preset time period; if so, delete the target transaction from the transaction pool of the blockchain. Specifically, for each timeout transaction in the timeout transaction list, it can be periodically detected (e.g., once a week or once a month) whether there is a timeout transaction that has not been synthesized into a QC for a long time. If so, the timeout transaction can be removed from the timeout transaction list and deleted from the transaction pool. In this way, the transactions in the timeout transaction list can be periodically detected, and the timeout transactions that have not been processed for a long time can be deleted, avoiding excessive memory occupation and resource waste.

[0203] S404: Analyze each received voting information using the proposal consensus strategy and determine the voting type of the target transaction.

[0204] In a possible implementation, the first node device analyzes each received voting information using the proposal consensus strategy and determines the voting type of the target transaction, which specifically includes the following process: count the number K of voting information received by the first node device; according to the received K voting information, synthesize a voting set for the target transaction using the proposal consensus strategy; K is a positive integer and K ≤ N; analyze the voting set to determine the voting type of the target transaction. Specifically, after the first node device counts the number K of voting information received by the first node device, it is further configured to perform the following operations: using the proposal consensus strategy, obtain the node fault tolerance number f corresponding to N second node devices during the consensus process (i.e., allowing f nodes to crash or have network anomalies), f is a positive integer and N = 3f + 1; if K ≥ 2f + 1, combine the K voting information into a voting set (QC) for the target transaction; if K < 2f + 1, delete the target transaction from the transaction pool of the blockchain, that is, an effective QC set cannot be synthesized, so the target transaction can be directly deleted.

[0205] The following details how to determine the voting type of the target transaction.

[0206] In a possible implementation, the proposal consensus policy is used to indicate that the voting types of the target transaction include a first type and a second type. The first node device analyzes the voting set to determine the voting type of the target transaction, which mainly includes the following steps: Analyze K voting messages in the voting set using the proposal consensus policy; if the number of nodes with the first result in the voting is greater than or equal to f + 1, then determine the voting type of the target transaction as the first type. For example, when the voting type is the first type, it can be expressed as RejectQc; if the number of nodes with the second result in the voting is less than f + 1, then determine the voting type of the target transaction as the second type. For example, when the voting type is the first type, it can be expressed as RetryQc.

[0207] Furthermore, any voting message includes the execution result obtained by the second node device after executing the target transaction; the first node device is further used to perform the following operations: if the number of nodes with the first result in the voting is greater than or equal to f + 1, then obtain the execution results of the respective second node devices corresponding to the first result from the voting messages; if the number of nodes with inconsistent execution results is greater than or equal to f + 1, then determine the voting type of the target transaction as the first type, that is, (RejectQc).

[0208] As can be seen from the above, based on the received voting messages, the first node device can use the proposal consensus policy for analysis and processing to determine the voting type of the target transaction (including the first type and the second type). Since the voting type of the target transaction is comprehensively determined based on the voting results of multiple second node devices, the determined voting type is relatively accurate, has a certain degree of credibility in the blockchain, and can ensure the reliability and accuracy of the voting type.

[0209] S405: Perform transaction processing on the target transaction according to the voting type of the target transaction.

[0210] In a possible implementation, if the voting type of the target transaction is the first type, then delete the target transaction from the transaction pool of the blockchain; if the voting type of the target transaction is the second type, then release the target transaction back to the transaction pool of the blockchain and update the status of the target transaction in the transaction pool. For example, the updated status is the "to be packaged" status, and subsequently, the target transaction can be normally processed by the node device for block packaging and consensus and other processes.

[0211] The processing flow of the voting messages will be described in detail below.

[0212] Please refer to Figure 6 , Figure 6 which is a schematic diagram of the processing flow of a voting message provided by an embodiment of the present application. As Figure 6As shown, the process of the first node device processing voting information mainly includes the following steps 1-14:

[0213] 1. Receive proposal information from the second node device.

[0214] 2. Query the timed transaction list.

[0215] 3. Whether the record is found. Specifically, check whether the target transaction identifier exists in the identifier field of the timeout transaction list shown in Table 2. If yes, execute step 4; if no, execute step 13.

[0216] 4. Verify the voting information. For example, verify the signature of the second node device that initiated the voting information. For example, the voting information can be parsed to obtain the signature data of the second node device, and the signature data can be verified using the public key of the second node device.

[0217] 5. Check whether the verification is successful. If so, proceed to step 6; if not, proceed to step 13.

[0218] 6. Add the voting information to the timeout transaction list. For example, the timeout transaction list after adding the voting information may be as shown in Table 2 above.

[0219] 7. Count the voting information of the target transaction.

[0220] 8. Determine whether QC can be synthesized. If yes, proceed to step 9; if no, end the process.

[0221] 9. Synthesize QC and broadcast.

[0222] 10. Determine whether it is RetryQC (i.e., whether the voting type of the target transaction is the second type). If yes, go to step 11; if no, go to step 14.

[0223] 11. Release the target transaction back to the transaction pool and update the status.

[0224] 12. Delete the transaction information of the target transaction in the timed transaction list.

[0225] 13. Discard the voting information.

[0226] 14. Delete the target transaction from the transaction pool.

[0227] In the process shown in the above steps 1-14, after receiving the voting information returned by each second node device, the first node device can analyze each voting result to determine the voting type of the target transaction, thereby adopting different transaction processing methods for the target transaction according to different voting types, which can improve the accuracy of transaction processing.

[0228] In an embodiment of the present application, the first node device may obtain a target transaction in a block. The target transaction refers to a transaction whose consensus execution time is greater than or equal to a preset time threshold during the consensus processing of the block. Then, a proposal can be encapsulated based on the target transaction and broadcast to N second node devices in the blockchain, so that each second node device votes on the type of the target transaction based on the consensus execution time of the target transaction. The voting information returned by the second node device for the proposal is received. The voting information includes the voting result for the target transaction in the proposal. The voting result includes a first result and a second result. The first result is used to indicate that the consensus execution time of the target transaction exceeds the preset time threshold. The second result is used to indicate that the consensus execution time of the target transaction does not exceed the preset time threshold. The received voting information is analyzed using a proposal consensus strategy, and the voting type of the target transaction is determined. According to the voting type of the target transaction, transaction processing is performed on the target transaction. Thus, on the one hand, in the present application, for the timeout transaction (i.e., the target transaction) with a relatively long consensus execution time in the block, proposal processing can be separately performed, so as to obtain the voting results of each second node device in the blockchain for the target transaction. Finally, the voting type of the timeout transaction can be determined. Since the voting type for the timeout transaction is obtained after proposal consensus among multiple second node devices in the blockchain, the determined voting type is more accurate. On the other hand, the method of separately processing the timeout transactions in the block according to the voting type can enable targeted transaction processing according to different transaction types during transaction processing, thereby improving the efficiency of transaction processing.

[0229] Please refer to Figure 7 , Figure 7 which is a schematic flowchart of another blockchain transaction processing method provided by an embodiment of the present application. This method can be executed by any second node device in the blockchain transaction processing system shown in Figure 3 . As shown in Figure 7 , the blockchain transaction processing method mainly includes but is not limited to the following steps S701 - S704:

[0230] S701: Receive a proposal sent by the first node device.

[0231] Among them, the proposal is encapsulated based on a target transaction in the block. The target transaction refers to: a transaction whose consensus execution time is greater than or equal to a preset time threshold during the consensus processing of the block. It should be noted that the specific process of the first node device generating the proposal can refer to the relevant process in Figure 4 the embodiment, and the embodiments of the present application will not elaborate on this here.

[0232] In a possible implementation, after the second node device receives the proposal sent by the first node device, it can also obtain the node identifier of the first node device and authenticate the first node device based on the node identifier, that is, verify whether the current first node device is the primary node in the blockchain. If so, it is determined that the authentication of the first node device passes; if not, the authentication of the first node device fails, and then the second node device can delete the proposal.

[0233] S702: Call the timeout transaction processing engine to execute the target transaction in the proposal to obtain the execution result of the target transaction.

[0234] In a possible implementation, a coroutine pool is maintained in the timeout transaction processing engine, and at least one coroutine is running in the coroutine pool; the second node device calls the timeout transaction processing engine to execute the target transaction in the proposal to obtain the execution result of the target transaction, which specifically includes the following process: Call the timeout transaction processing engine to parse the proposal to obtain the transaction information about the target transaction, and the transaction information includes: any one or more of the identifier of the target transaction, the timestamp for obtaining the target transaction, the block height of the block to which the target transaction belongs, and the block hash of the block to which the target transaction belongs; Determine whether there is an idle coroutine in the coroutine pool; If so, execute the target transaction according to the transaction information in the idle coroutine to obtain the execution result of the target transaction. Specifically, the target smart contract that matches can be called according to the transaction type of the target transaction, and the target smart contract is called to execute the target transaction. For example, if the transaction type of the target transaction is an asset type, the target smart contract can be an asset contract; Another example is that if the transaction type of the target transaction is a game type, the target smart contract can be a game contract. In this implementation, by calling the target smart contract that matches to execute the target transaction in the idle coroutine, the normal execution of the target transaction can be ensured, and the processing flow of the target transaction can be not affected.

[0235] In a possible implementation, a Trusted Execution Environment (TEE) is deployed in the timeout transaction processing engine. The second node device can also obtain the transaction type of the target transaction. If the transaction type is a preset type (such as the digital collectible type), the second node device can execute the target transaction in the trusted execution environment to obtain the execution result of the target transaction. In this implementation, for special types of target transactions such as the digital collectible type, the present application can execute the transaction in the TEE environment, thereby ensuring the security of the transaction execution process.

[0236] The following details the processing flow of the proposal.

[0237] Please refer to Figure 8a , Figure 8aIt is a schematic flowchart of a proposal processing provided by an embodiment of the present application. As Figure 8a shown, the process of the proposal processing mainly includes the following steps 1-10:

[0238] 1. Receive a proposal sent by the first node device.

[0239] 2. Determine whether there is an idle coroutine in the coroutine pool currently. If so, execute step 3; if not, execute step 8.

[0240] 3. Execute the target transaction in the idle coroutine.

[0241] 4. Determine whether the target transaction is successfully executed before timeout, that is, determine whether the consensus execution time of the target transaction exceeds a preset time threshold. If so, execute step 5; if not, execute step 9.

[0242] 5. Cast a "yes vote" on the proposal (that is, the voting result is the second result), and attach the execution result of the target transaction and the transaction read-write set.

[0243] 6. Determine whether there is a proposal to be processed in the cache. If so, execute step 7; if not, execute step 10.

[0244] 7. Obtain the proposal to be processed from the cache for processing.

[0245] 8. Put it into the cache and wait for an idle coroutine.

[0246] 9. Cast a "timeout vote" on the proposal (that is, the voting result is the first result).

[0247] 10. Release the current coroutine back to the coroutine pool.

[0248] In the proposal processing flow shown in the above steps 1-10, a coroutine pool runs in the timeout processing engine of the second node device, and the target transaction can be executed in the idle coroutine of the coroutine pool, so as to perform voting processing on the target transaction based on the consensus execution time of the target transaction to obtain the corresponding voting result.

[0249] S703: Generate voting information for the target transaction based on the execution result; the voting information includes the voting result for the target transaction in the proposal; the voting result includes a first result and a second result, the first result is used to indicate that the consensus execution time of the target transaction exceeds the preset time threshold; the second result is used to indicate that the consensus execution time of the target transaction does not exceed the preset time threshold.

[0250] In a possible implementation, the second node device generates voting information for the target transaction based on the execution result, which specifically includes the following steps: determining the consensus execution time of the target transaction based on the execution result; if the consensus execution time of the target transaction is greater than or equal to the preset time threshold, determining the voting result for the target transaction as the first result and generating voting information based on the first result; if the consensus execution time of the target transaction is less than the preset time threshold, determining the voting result for the target transaction as the second result and generating voting information based on the second result. Specifically, in implementation, the first result may be a timeout vote, the second result may be an approval vote, and the second node device may sign the voting result (such as the first result or the second result) with a private key to obtain the voting information.

[0251] S704: Return the voting information of the target transaction to the first node device.

[0252] Among them, the voting information is used to trigger the first node device to determine the voting type of the target transaction and process the target transaction according to the voting type of the target transaction. It should be noted that the relevant process of how the first node device processes the target transaction according to the voting type of the target transaction can be referred to in detail Figure 4 the relevant steps in Embodiment S405, which will not be elaborated in this embodiment of the present application.

[0253] In a possible implementation, after the second node device returns the voting information of the target transaction to the first node device, the second node device can also receive the voting set (QC) of the target transaction sent by the first node device. Among them, the specific process of how to generate the QC can be referred to in detail Figure 4 the relevant steps in the embodiment, which will not be elaborated in this application. The following will elaborate on the processing flow of the voting set.

[0254] Please refer to Figure 8b , Figure 8b which is a schematic diagram of the processing flow of a voting set provided by an embodiment of the present application. As Figure 8b shown, the processing flow of the voting set by the second node device mainly includes the following steps 1-7:

[0255] 1. Receive the QC sent by the first node device.

[0256] 2. Verify the basic information and voting information of the QC; for example, verify the identity of the first node device that sends the QC, or verify the identity of the sending object to which each voting information in the QC belongs, and so on.

[0257] 3. Whether the verification passes. If so, execute step 4; if not, execute step 7.

[0258] 4. Determine whether the QC is "RetryQC", that is, determine whether the voting type of the target transaction is the second type. If so, execute step 5; if not, execute step 6. Among them, for how to determine the voting type of the target transaction, refer to the process shown in step S404 in the above embodiment.

[0259] 5. Release the target transaction back to the transaction pool and update the status. For example, mark the status of the target transaction in the transaction pool as "pending packaging", and then it can be normally packaged and consensus reached subsequently.

[0260] 6. Delete the target transaction from the transaction pool.

[0261] 7. Discard the QC.

[0262] In the processing flow shown in the above steps, the second node device can receive the QC set of the target transaction, judge the voting type of the target transaction according to the QC, and then execute corresponding transaction processing on the target transaction according to different voting types. For timeout transactions, there is no need to perform unified processing according to a fixed processing method, which can improve the flexibility of transaction processing.

[0263] In the embodiment of the present application, the second node device can receive the proposal sent by the first node device and execute the target transaction in the proposal in an idle coroutine; and vote on the target transaction according to the consensus execution time of the target transaction, so as to return the voting information obtained after the voting process to the first node device. It can be seen that in the present application, the second node device can vote on the target transaction according to the consensus execution result of the target transaction to obtain the corresponding voting result, and then this voting result is used to determine the voting type of the target transaction, so as to execute corresponding transaction processing on the target transaction based on the voting type.

[0264] Please refer to Figure 9 , Figure 9 which is an interaction flowchart of a blockchain transaction processing method provided by an embodiment of the present application. This interaction process is jointly executed by the first node device and the second node device in the foregoing embodiment. Among them, the interaction process of this blockchain transaction processing method mainly includes but is not limited to the following steps S901 to S909:

[0265] S901: The client performs on-chain processing on the target transaction.

[0266] Specifically, the client where the target object is located can initiate a target transaction, and the target transaction can be any type of transaction such as an asset transaction or a game transaction; then sign the target transaction with the private key of the target object to generate a transaction on-chain request, and send the transaction on-chain request to the transaction pool of the blockchain.

[0267] S902: The first node device obtains a target transaction from a block.

[0268] In specific implementation, the first node device may obtain a batch of transactions from the transaction pool of the blockchain, package them into a block, and encapsulate the block into a proposal for consensus processing. Among them, for the timeout transactions in the block, the first node device may call the timeout transaction processing engine to obtain the timeout transactions in the block, and use the timeout transactions as target transactions. Among them, this process can refer to Figure 5a the specific process in the embodiment. The embodiments of the present application will not elaborate here.

[0269] S903: The first node device encapsulates a proposal based on the target transaction.

[0270] In specific implementation, the first node device packages the target transaction into a temporary block; executes the target transaction to obtain the execution result and transaction read-write set of the target transaction; packages the execution result and transaction read-write set of the target transaction into the temporary block, and uses the certificate data (such as the private key) of the first node device to sign the packaged temporary block to obtain a proposal. Among them, this process can refer to Figure 5b the specific process in the embodiment. The embodiments of the present application will not elaborate here.

[0271] S904: The first node device broadcasts the proposal to the second node device.

[0272] S905: The second node device votes on the target transaction in the proposal.

[0273] In specific implementation, after receiving the proposal, the second node device can vote on the target transaction in the proposal. Among them, this process can refer to Figure 7 the specific process in the embodiment. The embodiments of the present application will not elaborate here.

[0274] S906: The second node device obtains voting information for the target transaction according to the voting result.

[0275] S907: The second node device returns the voting information to the first node device.

[0276] S908: The first node device analyzes each voting information to obtain the voting type of the target transaction.

[0277] In specific implementation, the detailed process of the first node device processing the voting information can refer to Figure 8a the specific process in the shown embodiment. The embodiments of the present application will not elaborate here.

[0278] S909: The first node device executes transaction processing on the target transaction according to the voting type.

[0279] In specific implementation, if the voting type of the target transaction is the first type, the target transaction is deleted from the transaction pool of the blockchain; if the voting type of the target transaction is the second type, the target transaction is released back to the transaction pool of the blockchain, and the status of the target transaction is updated in the transaction pool. For example, the updated status is the "to-be-packaged" status, and subsequently, the target transaction can be normally processed by the node device for block packaging and consensus and other processing procedures.

[0280] The following provides the device of the embodiment of the present application. Next, in combination with the blockchain transaction processing solution provided by the above embodiment of the present application, the related devices of the embodiment of the present application are introduced accordingly.

[0281] Please refer to Figure 10 , Figure 10 which is a schematic structural diagram of a blockchain transaction processing device provided by an embodiment of the present application. As Figure 10 shown, the blockchain transaction processing device 1000 can be applied to the first node device mentioned in the foregoing embodiment. Specifically, the blockchain transaction processing device 1000 can be a computer program (including program code) running in a computer device. For example, the blockchain transaction processing device 1000 is an application software; the blockchain transaction processing device 1000 can be used to execute the corresponding steps in the blockchain transaction processing method provided by the embodiment of the present application. In specific implementation, the blockchain transaction processing device 1000 can specifically include:

[0282] An obtaining unit 1001, configured to obtain a target transaction in a block, where the target transaction refers to a transaction whose consensus execution time is greater than or equal to a preset time threshold during the consensus processing of the block;

[0283] A processing unit 1002, configured to encapsulate a proposal based on the target transaction and broadcast the proposal to N second node devices in the blockchain, so that each second node device votes on the target transaction based on the consensus execution time of the target transaction;

[0284] A receiving unit 1003, configured to receive voting information returned by the second node device for the proposal, where the voting information includes a voting result on the target transaction in the proposal; the voting result includes a first result and a second result, the first result is used to indicate that the consensus execution time of the target transaction exceeds the preset time threshold; the second result is used to indicate that the consensus execution time of the target transaction does not exceed the preset time threshold;

[0285] The processing unit 1002 is further configured to analyze each received voting information by using a proposal consensus strategy and determine the voting type of the target transaction;

[0286] The processing unit 1002 is further configured to perform transaction processing on the target transaction according to the voting type of the target transaction.

[0287] In a possible implementation, a timeout transaction processing engine is deployed in the first node device; after obtaining the target transaction in the block, the processing unit 1002 is further configured to perform the following operations:

[0288] Obtain the timeout transaction list maintained by the timeout transaction processing engine, where the timeout transaction list includes multiple data fields;

[0289] Call the timeout transaction processing engine to calculate the transaction information of the target transaction, where the transaction information includes any one or more of the identifier of the target transaction, the timestamp when the target transaction is obtained, the block height of the block to which the target transaction belongs, and the block hash of the block to which the target transaction belongs;

[0290] Add the transaction information of the target transaction to each data field of the timeout transaction list.

[0291] In a possible implementation, the processing unit 1002 encapsulates a proposal based on the target transaction for performing the following operations:

[0292] Call the timeout transaction processing engine to package the target transaction into a temporary block;

[0293] Execute the target transaction to obtain the execution result and transaction read-write set of the target transaction;

[0294] Package the execution result and transaction read-write set of the target transaction into the temporary block, and sign the packaged temporary block with the certificate data of the first node device to obtain a proposal.

[0295] In a possible implementation, a timer is deployed in the timeout transaction processing engine; the processing unit 1002 is further configured to perform the following operations:

[0296] Call the timer to periodically detect each target transaction in the timeout transaction list; where the periodic detection is used to indicate whether there is a target transaction that has not been synthesized into a voting set within a preset time period;

[0297] If so, delete the target transaction from the transaction pool of the blockchain.

[0298] In a possible implementation, the data fields of the timeout transaction list include: an identifier field, a first voting field, and a second voting field. The first voting field is used to store voting data with a first voting result, and the second voting field is used to store voting data with a second voting result; after receiving the voting information returned by each second node device for the proposal, the processing unit 1002 is further configured to perform the following operations:

[0299] Query the identification field in the timeout transaction list. If the identification of the target transaction is found in the identification field, verify the voting information.

[0300] If the verification of the voting information is successful, obtain the voting result indicated by the voting information.

[0301] If the voting result indicated by the voting result is the first result, add the voting information to the first voting field of the timeout transaction list.

[0302] If the voting result indicated by the voting result is the second result, add the voting information to the second voting field of the timeout transaction list.

[0303] In a possible implementation, the processing unit 1002 analyzes each received voting information using the proposal consensus strategy and determines the voting type of the target transaction for the following operations:

[0304] Count the number K of voting information received by the first node device.

[0305] According to the received K voting information, use the proposal consensus strategy to synthesize a voting set for the target transaction; K is a positive integer and K ≤ N.

[0306] Analyze the voting set to determine the voting type of the target transaction.

[0307] In a possible implementation, after the processing unit 1002 counts the number K of voting information received by the first node device, it is used for the following operations:

[0308] Use the proposal consensus strategy to obtain the node fault tolerance number f corresponding to N second node devices during the consensus processing. f is a positive integer and N = 3f + 1.

[0309] If K ≥ 2f + 1, combine the K voting information into a voting set for the target transaction.

[0310] If K < 2f + 1, delete the target transaction from the transaction pool of the blockchain.

[0311] In a possible implementation, the proposal consensus strategy is used to indicate that the voting type of the target transaction includes the first type and the second type; the processing unit 1002 analyzes the voting set to determine the voting type of the target transaction for the following operations:

[0312] Use the proposal consensus strategy to analyze the K voting information in the voting set.

[0313] If the number of nodes with the voting result as the first result is greater than or equal to f + 1, determine the voting type of the target transaction as the first type.

[0314] If the number of nodes with the voting result being the second result is less than f + 1, determine the voting type of the target transaction as the second type.

[0315] In a possible implementation, any voting information includes the execution result obtained after the second node device executes the target transaction; the processing unit 1002 is further configured to perform the following operations:

[0316] If the number of nodes with the voting result being the first result is greater than or equal to f + 1, obtain the execution results of each second node device corresponding to the first result from the voting information;

[0317] If the number of nodes with inconsistent execution results is greater than or equal to f + 1, determine the voting type of the target transaction as the first type.

[0318] In a possible implementation, the processing unit 1002 processes the target transaction according to the voting type of the target transaction, and is configured to perform the following operations:

[0319] If the voting type of the target transaction is the first type, delete the target transaction from the transaction pool of the blockchain;

[0320] If the voting type of the target transaction is the second type, release the target transaction back to the transaction pool of the blockchain and update the status of the target transaction in the transaction pool.

[0321] In an embodiment of the present application, the first node device may obtain a target transaction in a block, where the target transaction refers to a transaction whose consensus execution time is greater than or equal to a preset time threshold during the consensus processing of the block; then, a proposal may be encapsulated based on the target transaction and broadcast to N second node devices in the blockchain, so that each second node device votes on the type of the target transaction based on the consensus execution time of the target transaction; receive the voting information returned by the second node device for the proposal, where the voting information includes the voting result for the target transaction in the proposal; the voting result includes a first result and a second result, the first result is used to indicate that the consensus execution time of the target transaction exceeds the preset time threshold; the second result is used to indicate that the consensus execution time of the target transaction does not exceed the preset time threshold; analyze each received voting information using a proposal consensus strategy and determine the voting type of the target transaction; and perform transaction processing on the target transaction according to the voting type of the target transaction. It can be seen that, on the one hand, the present application can separately execute proposal processing for timeout transactions (i.e., target transactions) with a long consensus execution time in a block, so as to obtain the voting results of each second node device in the blockchain for the target transaction, and finally the voting type of the timeout transaction can be determined. Since the voting type for the timeout transaction is obtained after proposal consensus among multiple second node devices in the blockchain, the determined voting type is more accurate; on the other hand, the method of separately processing timeout transactions in a block according to the voting type can enable targeted transaction processing according to different transaction types during transaction processing, thereby improving the efficiency of transaction processing.

[0322] Please refer to Figure 11 , Figure 11 which is a schematic structural diagram of another blockchain transaction processing device provided by an embodiment of the present application. As Figure 11 shown, the blockchain transaction processing device 1100 may be applied to the second node device mentioned in the foregoing embodiment. Specifically, the blockchain transaction processing device 1100 may be a computer program (including program code) running in a computer device. For example, the blockchain transaction processing device 1100 is an application software; the blockchain transaction processing device 1100 may be used to execute the corresponding steps in the blockchain transaction processing method provided by an embodiment of the present application. Specifically, when implemented, the blockchain transaction processing device 1100 may specifically include:

[0323] A receiving unit 1101, configured to receive a proposal sent by a first node device; the proposal is encapsulated based on a target transaction in a block, where the target transaction refers to: a transaction whose consensus execution time is greater than or equal to a preset time threshold during the consensus processing of the block;

[0324] A processing unit 1102, configured to call a timeout transaction processing engine to execute the target transaction in the proposal to obtain an execution result of the target transaction;

[0325] The processing unit 1102 is further configured to generate voting information for the target transaction based on the execution result; the voting information includes the voting result for the target transaction in the proposal; the voting result includes a first result and a second result, the first result is used to indicate that the consensus execution time of the target transaction exceeds a preset time threshold; the second result is used to indicate that the consensus execution time of the target transaction does not exceed the preset time threshold;

[0326] The sending unit 1103 is configured to return the voting information of the target transaction to the first node device;

[0327] Wherein, the voting information is used to trigger the first node device to determine the voting type of the target transaction and process the target transaction according to the voting type of the target transaction.

[0328] In a possible implementation, a coroutine pool is maintained in the timeout transaction processing engine, and at least one coroutine is running in the coroutine pool; the processing unit 1102 calls the timeout transaction processing engine to execute the target transaction in the proposal to obtain the execution result of the target transaction, which is used to perform the following operations:

[0329] Call the timeout transaction processing engine to parse the proposal to obtain transaction information about the target transaction, where the transaction information includes any one or more of: the identifier of the target transaction, the timestamp for obtaining the target transaction, the block height of the block to which the target transaction belongs, and the block hash of the block to which the target transaction belongs;

[0330] Determine whether there is an idle coroutine in the coroutine pool;

[0331] If there is, execute the target transaction according to the transaction information in the idle coroutine to obtain the execution result of the target transaction.

[0332] In a possible implementation, the processing unit 1102 generates voting information for the target transaction based on the execution result, which is used to perform the following operations:

[0333] Determine the consensus execution time of the target transaction based on the execution result;

[0334] If the consensus execution time of the target transaction is greater than or equal to the preset time threshold, determine that the voting result for the target transaction is the first result and generate voting information based on the first result;

[0335] If the consensus execution time of the target transaction is less than the preset time threshold, determine that the voting result for the target transaction is the second result and generate voting information based on the second result.

[0336] In a possible implementation, a trusted execution environment is deployed in the timeout transaction processing engine; the processing unit 1102 invokes the timeout transaction processing engine to execute the target transaction in the proposal, and obtains the execution result of the target transaction for performing the following operations:

[0337] Obtain the transaction type of the target transaction;

[0338] If the transaction type is a preset type, then invoke the timeout transaction processing engine in the trusted execution environment to execute the target transaction, and obtain the execution result of the target transaction.

[0339] In the embodiment of the present application, the second node device can receive the proposal sent by the first node device, and execute the target transaction in the proposal in an idle coroutine; and perform a voting process on the target transaction according to the consensus execution time of the target transaction, so as to return the voting information obtained after the voting process to the first node device. It can be seen that in the present application, the second node device can perform a voting process on the target transaction according to the consensus execution result of the target transaction to obtain the corresponding voting result, and subsequently, the voting result is used to determine the voting type of the target transaction, so as to perform corresponding transaction processing on the target transaction based on the voting type.

[0340] Please refer to Figure 12 , Figure 12 which is a schematic structural diagram of a computer device provided by an embodiment of the present application. The computer device 1200 is used to execute the steps performed by the first node device or the second node device in the foregoing method embodiment. The computer device 1200 includes: one or more processors 1201; one or more input devices 1202, one or more output devices 1203, and a memory 1204. The foregoing processors 1201, input devices 1202, output devices 1203, and memory 1204 are connected through a bus 1205. Among them, the memory 1204 is used to store a computer program, and the computer program includes program instructions.

[0341] In a feasible embodiment, when the computer device is the first node device, the processor 1201 is used to invoke the program instructions stored in the memory 1204 for performing the following operations:

[0342] Obtain the target transaction in the block, where the target transaction refers to: in the process of performing consensus processing on the block, a transaction whose consensus execution time is greater than or equal to a preset time threshold;

[0343] Encapsulate a proposal based on the target transaction, and broadcast the proposal to N second node devices in the blockchain, so that each second node device performs a voting process on the target transaction according to the consensus execution time of the target transaction;

[0344] Receive the voting information returned by the second node device for the proposal, where the voting information includes the voting result for the target transaction in the proposal; the voting result includes a first result and a second result, the first result is used to indicate that the consensus execution time of the target transaction exceeds a preset time threshold; the second result is used to indicate that the consensus execution time of the target transaction does not exceed the preset time threshold;

[0345] Analyze each received voting information using the proposal consensus strategy and determine the voting type of the target transaction;

[0346] Perform transaction processing on the target transaction according to the voting type of the target transaction.

[0347] In a possible implementation, a timeout transaction processing engine is deployed in the first node device; after obtaining the target transaction in the block, the processor 1201 is further configured to perform the following operations:

[0348] Obtain the timeout transaction list maintained by the timeout transaction processing engine, where the timeout transaction list includes multiple data fields;

[0349] Call the timeout transaction processing engine to calculate the transaction information of the target transaction, where the transaction information includes any one or more of: the identifier of the target transaction, the timestamp when the target transaction is obtained, the block height of the block to which the target transaction belongs, and the block hash of the block to which the target transaction belongs;

[0350] Add the transaction information of the target transaction to each data field of the timeout transaction list.

[0351] In a possible implementation, the processor 1201 encapsulates a proposal based on the target transaction for performing the following operations:

[0352] Call the timeout transaction processing engine to package the target transaction into a temporary block;

[0353] Execute the target transaction to obtain the execution result and transaction read-write set of the target transaction;

[0354] Package the execution result and transaction read-write set of the target transaction into the temporary block, and sign the packaged temporary block using the certificate data of the first node device to obtain a proposal.

[0355] In a possible implementation, a timer is deployed in the timeout transaction processing engine; the processor 1201 is further configured to perform the following operations:

[0356] Call the timer to periodically detect each target transaction in the timeout transaction list; where the periodic detection is used to indicate whether there is a target transaction that has not been synthesized into a voting set within a preset time period;

[0357] If it exists, delete the target transaction from the transaction pool of the blockchain.

[0358] In a possible implementation, the data fields of the timeout transaction list include: an identification field, a first voting field, and a second voting field. The first voting field is used to store voting data with a first voting result, and the second voting field is used to store voting data with a second voting result. After receiving the voting information returned by each second node device for the proposal, the processor 1201 is further configured to perform the following operations:

[0359] Query the identification field in the timeout transaction list. If the identification of the target transaction is found in the identification field, verify the voting information.

[0360] If the verification of the voting information is successful, obtain the voting result indicated by the voting information.

[0361] If the voting result indicated by the voting result is the first result, add the voting information to the first voting field of the timeout transaction list.

[0362] If the voting result indicated by the voting result is the second result, add the voting information to the second voting field of the timeout transaction list.

[0363] In a possible implementation, the processor 1201 analyzes each received voting information using a proposal consensus strategy and determines the voting type of the target transaction for performing the following operations:

[0364] Count the number K of voting information received by the first node device.

[0365] According to the received K voting information, synthesize a voting set for the target transaction using a proposal consensus strategy; K is a positive integer and K ≤ N.

[0366] Analyze the voting set to determine the voting type of the target transaction.

[0367] In a possible implementation, after the processor 1201 counts the number K of voting information received by the first node device, it is configured to perform the following operations:

[0368] Using a proposal consensus strategy, obtain the node fault tolerance number f corresponding to the N second node devices during the consensus process. f is a positive integer and N = 3f + 1.

[0369] If K ≥ 2f + 1, combine the K voting information into a voting set for the target transaction.

[0370] If K < 2f + 1, delete the target transaction from the transaction pool of the blockchain.

[0371] In a possible implementation, the proposal consensus strategy is used to indicate that the voting types of the target transaction include a first type and a second type; the processor 1201 analyzes the voting set to determine the voting type of the target transaction for performing the following operations:

[0372] Analyze K voting messages in the voting set using the proposal consensus strategy;

[0373] If the number of nodes with the first result in the voting is greater than or equal to f + 1, determine the voting type of the target transaction as the first type;

[0374] If the number of nodes with the second result in the voting is less than f + 1, determine the voting type of the target transaction as the second type.

[0375] In a possible implementation, any voting message includes the execution result obtained after the second node device executes the target transaction; the processor 1201 is further configured to perform the following operations:

[0376] If the number of nodes with the first result in the voting is greater than or equal to f + 1, obtain the execution results of the respective second node devices corresponding to the first result from the voting messages;

[0377] If the number of nodes with inconsistent execution results is greater than or equal to f + 1, determine the voting type of the target transaction as the first type.

[0378] In a possible implementation, the processor 1201 performs transaction processing on the target transaction according to the voting type of the target transaction for performing the following operations:

[0379] If the voting type of the target transaction is the first type, delete the target transaction from the transaction pool of the blockchain;

[0380] If the voting type of the target transaction is the second type, release the target transaction back to the transaction pool of the blockchain and update the status of the target transaction in the transaction pool.

[0381] In another feasible embodiment, when the computer device is the second node device, the processor 1201 is configured to call the program instructions stored in the memory 1204 for performing the following operations:

[0382] Receive a proposal sent by the first node device; the proposal is encapsulated based on the target transaction in the block, and the target transaction refers to: in the process of performing consensus processing on the block, a transaction whose consensus execution time is greater than or equal to the preset time threshold;

[0383] Call the timeout transaction processing engine to execute the target transaction in the proposal to obtain the execution result of the target transaction;

[0384] Generate voting information for the target transaction based on the execution result; the voting information includes the voting result for the target transaction in the proposal; the voting result includes a first result and a second result, where the first result is used to indicate that the consensus execution time of the target transaction exceeds a preset time threshold; the second result is used to indicate that the consensus execution time of the target transaction does not exceed the preset time threshold;

[0385] Return the voting information of the target transaction to the first node device;

[0386] Among them, the voting information is used to trigger the first node device to determine the voting type of the target transaction and process the target transaction according to the voting type of the target transaction.

[0387] In a possible implementation, a coroutine pool is maintained in the timeout transaction processing engine, and at least one coroutine is running in the coroutine pool; the processor 1201 calls the timeout transaction processing engine to execute the target transaction in the proposal to obtain the execution result of the target transaction, which is used to perform the following operations:

[0388] Call the timeout transaction processing engine to parse the proposal to obtain the transaction information about the target transaction, where the transaction information includes any one or more of the following: the identifier of the target transaction, the timestamp for obtaining the target transaction, the block height of the block to which the target transaction belongs, and the block hash of the block to which the target transaction belongs;

[0389] Determine whether there is a coroutine in the idle state in the coroutine pool;

[0390] If there is, execute the target transaction according to the transaction information in the coroutine in the idle state to obtain the execution result of the target transaction.

[0391] In a possible implementation, the processor 1201 generates voting information for the target transaction based on the execution result, which is used to perform the following operations:

[0392] Determine the consensus execution time of the target transaction based on the execution result;

[0393] If the consensus execution time of the target transaction is greater than or equal to the preset time threshold, determine the voting result for the target transaction as the first result and generate voting information based on the first result;

[0394] If the consensus execution time of the target transaction is less than the preset time threshold, determine the voting result for the target transaction as the second result and generate voting information based on the second result.

[0395] In a possible implementation, a trusted execution environment is deployed in the timeout transaction processing engine; the processor 1201 calls the timeout transaction processing engine to execute the target transaction in the proposal to obtain the execution result of the target transaction, which is used to perform the following operations:

[0396] Get the transaction type of the target transaction;

[0397] If the transaction type is a preset type, the timeout transaction processing engine is called in the trusted execution environment to execute the target transaction and obtain the execution result of the target transaction.

[0398] In an embodiment of the present application, a first node device can obtain a target transaction in a block, where the target transaction refers to a transaction whose consensus execution time is greater than or equal to a preset time threshold during consensus processing of the block; then a proposal can be encapsulated based on the target transaction, and the proposal can be broadcast to N second node devices in the blockchain, so that each second node device votes on the type of the target transaction based on the consensus execution time of the target transaction; the voting information returned by the second node device for the proposal is received, and the voting information includes the voting result of the target transaction in the proposal; the voting result includes a first result and a second result, the first result is used to indicate that the consensus execution time of the target transaction exceeds the preset time threshold; the second result is used to indicate that the consensus execution time of the target transaction does not exceed the preset time threshold; the proposal consensus strategy is used to analyze each received voting information, and the voting type of the target transaction is determined; according to the voting type of the target transaction, the target transaction is processed. It can be seen from this that, on the one hand, the present application can separately perform proposal processing for timed-out transactions (i.e., target transactions) with a long consensus execution time in the block, thereby obtaining the voting results of each second node device in the blockchain on the target transaction, and finally determining the voting type of the timed-out transaction. Since the voting type for the timed-out transaction is obtained based on the proposal consensus of multiple second node devices in the blockchain, the determined voting type is more accurate; on the other hand, the method of separately processing timed-out transactions in the block according to the voting type can enable targeted transaction processing according to different transaction types during transaction processing, thereby improving the efficiency of transaction processing.

[0399] In addition, it should be pointed out here that: the embodiment of the present application also provides a computer storage medium, and a computer program is stored in the computer storage medium, and the computer program includes program instructions. When the processor executes the above program instructions, the method in the corresponding embodiment of the foregoing text can be executed, so it will not be repeated here. For technical details not disclosed in the computer storage medium embodiment involved in this application, please refer to the description of the method embodiment of this application. As an example, the program instructions can be deployed on a computer device, or executed on multiple computer devices located in one place, or, executed on multiple computer devices distributed in multiple locations and interconnected by a communication network.

[0400] According to one aspect of the present application, embodiments of the present application further provide a computer program product or a computer program. The computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device can execute the methods in the corresponding embodiments described above. Therefore, details will not be repeated here.

[0401] Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in combination with the embodiments disclosed in the present application can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Skilled artisans can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present application.

[0402] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present invention are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted through a computer-readable storage medium. The computer instructions can be transmitted from a website, computer, server, or data center to another website, computer, server, or data center in a wired manner (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or a wireless manner (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that the computer can access, or a data processing device such as a server or data center that includes one or more integrated available media. The available medium can be a magnetic medium (such as a floppy disk, hard disk, magnetic tape), an optical medium (such as a DVD), or a semiconductor medium (such as a solid state disk (SSD)).

[0403] The foregoing disclosure is only for the preferred embodiments of the present application, and of course cannot be used to limit the scope of rights of the present application. Therefore, equivalent changes made in accordance with the claims of the present application are still within the scope covered by the present application.

Claims

1. A blockchain transaction processing method, characterized in that, The blockchain includes: a first node device and N second node devices. The first node device is used to propose transactions in the blockchain, and the second node devices are used to vote on the proposals, where N is a positive integer. The method is executed by the first node device and includes: Obtain a target transaction in a block, where the target transaction refers to a transaction whose consensus execution time is greater than or equal to a preset time threshold during the consensus processing of the block; Encapsulate a proposal based on the target transaction and broadcast the proposal to the N second node devices in the blockchain, so that each second node device votes on the target transaction based on the consensus execution time of the target transaction; Receive the voting information returned by the second node device for the proposal. The voting information includes the voting result for the target transaction in the proposal. The voting result includes a first result and a second result. The first result is used to indicate that the consensus execution time of the target transaction exceeds the preset time threshold; the second result is used to indicate that the consensus execution time of the target transaction does not exceed the preset time threshold; Analyze the received voting information using a proposal consensus strategy and determine the voting type of the target transaction; Perform transaction processing on the target transaction according to the voting type of the target transaction.

2. The method according to claim 1, wherein An overtime transaction processing engine is deployed in the first node device. After obtaining the target transaction in the block, it further includes: Obtain the overtime transaction list maintained by the overtime transaction processing engine. The overtime transaction list includes multiple data fields; Call the overtime transaction processing engine to calculate the transaction information of the target transaction. The transaction information includes any one or more of the identifier of the target transaction, the timestamp when the target transaction is obtained, the block height of the block to which the target transaction belongs, and the block hash of the block to which the target transaction belongs; Add the transaction information of the target transaction to each data field of the overtime transaction list.

3. The method according to claim 2, wherein The encapsulating a proposal based on the target transaction includes: Call the overtime transaction processing engine to pack the target transaction into a temporary block; Execute the target transaction to obtain the execution result and transaction read-write set of the target transaction; Pack the execution result and transaction read-write set of the target transaction into the temporary block, and sign the packed temporary block using the certificate data of the first node device to obtain a proposal.

4. The method according to claim 3, wherein A timer is deployed in the overtime transaction processing engine. The method further includes: Call the timer to periodically detect each target transaction in the overtime transaction list. The periodic detection is used to indicate whether there is a target transaction that has not been synthesized into a voting set within a preset time period; If so, delete the target transaction from the transaction pool of the blockchain.

5. The method according to claim 2, wherein The data fields of the timeout transaction list include: an identification field, a first voting field, and a second voting field. The first voting field is used to store voting data with a voting result of the first result, and the second voting field is used to store voting data with a voting result of the second result. After receiving the voting information returned by each second node device for the proposal, it further includes: Query the identification field in the timeout transaction list. If the identification of the target transaction is found in the identification field, verify the voting information. If the verification of the voting information is successful, obtain the voting result indicated by the voting information. If the voting result indicated by the voting result is the first result, add the voting information to the first voting field of the timeout transaction list. If the voting result indicated by the voting result is the second result, add the voting information to the second voting field of the timeout transaction list.

6. The method according to claim 1, wherein Analyzing each received voting information using the proposal consensus strategy and determining the voting type of the target transaction includes: Count the number K of voting information received by the first node device. According to the received K voting information, use the proposal consensus strategy to synthesize a voting set for the target transaction; K is a positive integer and K ≤ N. Analyze the voting set to determine the voting type of the target transaction.

7. The method according to claim 6, wherein After counting the number K of voting information received by the first node device, it includes: Using the proposal consensus strategy, obtain the node fault tolerance number f corresponding to the N second node devices during the consensus process, where f is a positive integer and N = 3f + 1. If K ≥ 2f + 1, combine the K voting information into a voting set for the target transaction. If K < 2f + 1, delete the target transaction from the transaction pool of the blockchain.

8. The method according to claim 7, wherein The proposal consensus strategy is used to indicate that the voting type of the target transaction includes a first type and a second type. Analyzing the voting set to determine the voting type of the target transaction includes: Analyze the K voting information in the voting set using the proposal consensus strategy. If the number of nodes with a voting result of the first result is greater than or equal to f + 1, determine the voting type of the target transaction as the first type. If the number of nodes with a voting result of the second result is less than f + 1, determine the voting type of the target transaction as the second type.

9. The method according to claim 8, wherein Any one of the voting information includes the execution result obtained after the second node device executes the target transaction. The method further includes: If the number of nodes with a voting result of the first result is greater than or equal to f + 1, obtain the execution results of the respective second node devices corresponding to the first result from the voting information. If the number of nodes with inconsistent execution results is greater than or equal to f + 1, determine the voting type of the target transaction as the first type.

10. The method according to any one of claims 1-9, characterized in that, Performing transaction processing on the target transaction according to the voting type of the target transaction includes: If the voting type of the target transaction is the first type, delete the target transaction from the transaction pool of the blockchain. If the voting type of the target transaction is the second type, release the target transaction back to the transaction pool of the blockchain and update the status of the target transaction in the transaction pool.

11. A blockchain transaction processing method, characterized in that, The blockchain includes: a first node device and N second node devices. The first node device is used to propose transactions in the blockchain, and the second node devices are used to vote on the proposals, where N is a positive integer. The method is executed by the second node device, and the method includes: Receiving a proposal sent by the first node device; the proposal is encapsulated based on a target transaction in a block, and the target transaction refers to a transaction whose consensus execution time is greater than or equal to a preset time threshold during the consensus processing of the block; Invoking the timeout transaction processing engine to execute the target transaction in the proposal to obtain the execution result of the target transaction; Generating voting information for the target transaction based on the execution result; the voting information includes the voting result for the target transaction in the proposal; the voting result includes a first result and a second result. The first result is used to indicate that the consensus execution time of the target transaction exceeds the preset time threshold; the second result is used to indicate that the consensus execution time of the target transaction does not exceed the preset time threshold; Returning the voting information of the target transaction to the first node device; Among them, the voting information is used to trigger the first node device to determine the voting type of the target transaction and perform transaction processing on the target transaction according to the voting type of the target transaction.

12. The method according to claim 11, wherein There is a coroutine pool maintained in the timeout transaction processing engine, and at least one coroutine is running in the coroutine pool. The invoking the timeout transaction processing engine to execute the target transaction in the proposal to obtain the execution result of the target transaction includes: Invoking the timeout transaction processing engine to parse the proposal to obtain transaction information about the target transaction. The transaction information includes any one or more of: the identifier of the target transaction, the timestamp for obtaining the target transaction, the block height of the block to which the target transaction belongs, and the block hash of the block to which the target transaction belongs; Determining whether there is an idle coroutine in the coroutine pool; If there is, execute the target transaction according to the transaction information in the idle coroutine to obtain the execution result of the target transaction.

13. The method according to claim 11, wherein The generating voting information for the target transaction based on the execution result includes: Determining the consensus execution time of the target transaction based on the execution result; If the consensus execution time of the target transaction is greater than or equal to the preset time threshold, determining the voting result for the target transaction as the first result and generating voting information based on the first result; If the consensus execution time of the target transaction is less than the preset time threshold, determining the voting result for the target transaction as the second result and generating voting information based on the second result.

14. The method according to any one of claims 11-13, characterized in that, There is a trusted execution environment deployed in the timeout transaction processing engine. The invoking the timeout transaction processing engine to execute the target transaction in the proposal to obtain the execution result of the target transaction includes: Obtain the transaction type of the target transaction; If the transaction type is a preset type, then call the timeout transaction processing engine in the trusted execution environment to execute the target transaction and obtain the execution result of the target transaction.

15. A blockchain transaction processing device, characterized in that, The blockchain includes: a first node device and N second node devices. The first node device is used to propose transactions in the blockchain, and the second node devices are used to vote on the proposals. N is a positive integer. The device is executed by the first node device, and the device includes: An acquisition unit, configured to acquire a target transaction in a block, where the target transaction refers to a transaction whose consensus execution time is greater than or equal to a preset time threshold during the consensus processing of the block; A processing unit, configured to encapsulate a proposal based on the target transaction and broadcast the proposal to the N second node devices in the blockchain, so that each second node device votes on the type of the target transaction based on the consensus execution time of the target transaction; A receiving unit, configured to receive voting information returned by the second node device for the proposal. The voting information includes the voting result for the target transaction in the proposal. The voting result includes a first result and a second result. The first result is used to indicate that the consensus execution time of the target transaction exceeds the preset time threshold; the second result is used to indicate that the consensus execution time of the target transaction does not exceed the preset time threshold; The processing unit is further configured to analyze each received voting information by using a proposal consensus strategy and determine the voting type of the target transaction; The processing unit is further configured to perform transaction processing on the target transaction according to the voting type of the target transaction.

16. A blockchain transaction processing device, characterized in that, The blockchain includes: a first node device and N second node devices. The first node device is used to propose transactions in the blockchain, and the second node devices are used to vote on the proposals. N is a positive integer. The device is executed by the second node device, and the device includes: A receiving unit, configured to receive a proposal sent by the first node device. The proposal is encapsulated based on a target transaction in a block, where the target transaction refers to a transaction whose consensus execution time is greater than or equal to a preset time threshold during the consensus processing of the block; A processing unit, configured to call the timeout transaction processing engine to execute the target transaction in the proposal and obtain the execution result of the target transaction; The processing unit is further configured to generate voting information for the target transaction based on the execution result. The voting information includes the voting result for the target transaction in the proposal. The voting result includes a first result and a second result. The first result is used to indicate that the consensus execution time of the target transaction exceeds the preset time threshold; the second result is used to indicate that the consensus execution time of the target transaction does not exceed the preset time threshold; A sending unit, configured to return the voting information of the target transaction to the first node device; Among them, the voting information is used to trigger the first node device to determine the voting type of the target transaction, and perform transaction processing on the target transaction according to the voting type of the voting set.

17. A computer device, characterized in that, Including: A storage device and a processor; A memory, in which one or more computer programs are stored; A processor, configured to load the one or more computer programs to implement the blockchain transaction processing method according to any one of claims 1-10 or 11-14.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, and the computer program is suitable for being loaded and executed by the processor to implement the blockchain transaction processing method according to any one of claims 1-10 or 11-14.

19. A computer program product, characterized in that, The computing program product includes a computer program, and the computer program is suitable for being loaded and executed by the processor to implement the blockchain transaction processing method according to any one of claims 1-10 or 11-14.

Images