Timeout transaction processing method based on block chain and related equipment

Abstract

The invention discloses a block chain-based timeout transaction processing method and related equipment. The method comprises the following steps of: creating a transaction execution block based on a plurality of transactions stored in a local transaction pool; executing a plurality of transactions in the transaction execution block to obtain an execution result of each transaction; determining to execute an overtime transaction from the plurality of transactions based on the execution result; packaging the transaction execution block into an initial proposal; adding a transaction identifier for executing the timeout transaction and a contract method called for executing the timeout transaction into the initial proposal to obtain a first target proposal; and sending the first target proposal to a slave node, so that the slave node performs verification processing based on the first target proposal. According to the method, the situation of overtime transactions can be reduced, so that the time consumption of block packaging is reduced, and the block chain processing capability is improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a timeout transaction processing method based on blockchain and related equipment. Background Art

[0002] In the blockchain system, there are cases where transactions that call individual contract methods time out during execution. When the existing technology encounters a transaction execution timeout, the system can only wait for the result of the transaction execution, and cannot avoid the impact of the timed-out transaction; at the same time, the timed-out transaction will be released back to the transaction pool by the master node, and the timed-out transaction will be executed repeatedly, resulting in a significant increase in the time required for block packaging and a significant reduction in the blockchain processing capacity. Summary of the invention

[0003] The embodiments of the present application provide a blockchain-based timeout transaction processing method and related equipment. The related equipment may include a blockchain-based timeout transaction processing device, an electronic device, a computer-readable storage medium and a computer program product, which can reduce the occurrence of timeout transactions, thereby reducing the time consumption of block packaging and improving the blockchain processing capability.

[0004] The present application embodiment provides a method for processing a timeout transaction based on a blockchain, comprising:

[0005] Create transaction execution blocks based on multiple transactions stored in the local transaction pool;

[0006] Execute multiple transactions in the transaction execution block to obtain the execution result of each transaction;

[0007] Based on the execution result, determining an execution timeout transaction from the plurality of transactions;

[0008] Encapsulating the transaction execution block into an initial proposal;

[0009] Adding the transaction identifier of the timed-out transaction and the contract method called by the timed-out transaction to the initial proposal to obtain a first target proposal;

[0010] The first target proposal is sent to the slave node so that the slave node performs verification processing based on the first target proposal.

[0011] Accordingly, the embodiment of the present application provides a timeout transaction processing device based on blockchain, applicable to a master node, including:

[0012] A creation unit, used to create a transaction execution block based on multiple transactions stored in the local transaction pool;

[0013] An execution unit, configured to execute multiple transactions in the transaction execution block and obtain an execution result of each transaction;

[0014] A first determining unit, configured to determine an execution timeout transaction from a plurality of transactions based on the execution result;

[0015] A packaging unit, used for packaging the transaction execution block into an initial proposal;

[0016] An adding unit, configured to add the transaction identifier of the timed-out transaction and the contract method called by the timed-out transaction to the initial proposal to obtain a first target proposal;

[0017] A sending unit is used to send the first target proposal to the slave node so that the slave node performs verification processing based on the first target proposal.

[0018] Optionally, in some embodiments of the present application, the first determining unit may include a first recording subunit and a third determining subunit, as follows:

[0019] The first recording subunit is used to record the contract method corresponding to the execution timeout transaction into a first local cache list;

[0020] The third determination subunit is used to determine the contract method state corresponding to the contract method as a to-be-triggered state if it is detected in the first local cache list that the contract method satisfies a preset execution timeout condition.

[0021] Optionally, in some embodiments of the present application, the adding unit may include a fourth determining subunit, a constructing subunit, a calling subunit and a first updating subunit, as follows:

[0022] The fourth determining subunit is used to query the contract method whose contract method status is the to-be-triggered state from the first local cache list, and determine the contract method whose contract method status is the to-be-triggered state as the to-be-triggered contract method;

[0023] The construction subunit is used to construct a frozen contract method transaction based on the contract method to be triggered;

[0024] The calling subunit is used to call the local transaction pool interface and put the frozen contract method transaction into the local transaction pool;

[0025] The first update sub-unit is used to update the contract method status of the to-be-triggered contract method in the first local cache list to a consensus status.

[0026] Optionally, in some embodiments of the present application, the first updating subunit may include a creating subunit, an executing subunit, a packaging subunit, an adding subunit, a sending subunit and a returning subunit, as follows:

[0027] The creation subunit is used to create a transaction execution block based on multiple transactions stored in the local transaction pool;

[0028] The execution subunit is used to execute multiple transactions in the transaction execution block and obtain the execution result of each transaction;

[0029] The determining subunit is used to determine an execution timeout transaction from the plurality of transactions based on the execution result;

[0030] The encapsulation subunit is used to encapsulate the transaction execution block into an initial proposal;

[0031] The adding subunit is used to add the transaction identifier of the execution timeout transaction and the contract method called by the execution timeout transaction to the initial proposal to obtain a second target proposal, wherein the second target proposal includes transaction information corresponding to the frozen contract method transaction;

[0032] The sending subunit is used to send the second target proposal to the slave node.

[0033] The returning subunit is used to return to the step of creating a transaction execution block based on multiple transactions stored in the local transaction pool until the master node no longer sends a proposal to the slave node.

[0034] Accordingly, the embodiment of the present application provides a timeout transaction processing device based on blockchain, applicable to a slave node, including:

[0035] A receiving unit, used to receive target proposals from the master node;

[0036] A second determining unit, configured to determine, if the target proposal is a second target proposal, a frozen contract method transaction corresponding to the second target proposal;

[0037] A determination unit, configured to determine whether the contract method state of the contract method corresponding to the frozen contract method transaction in the second local cache list is a to-be-triggered state;

[0038] An updating unit is used to update the contract method status of the contract method corresponding to the frozen contract method transaction in the second local cache list to a consensus status if yes.

[0039] Optionally, in some embodiments of the present application, the receiving unit may include a receiving subunit, a fifth determining subunit, and a second recording subunit, as follows:

[0040] The receiving subunit is used to receive proposals from other nodes;

[0041] The fifth determining subunit is configured to determine that the received proposal is a target proposal from the master node if it is detected that the proposal carries transaction information corresponding to the timed-out transaction;

[0042] The second recording subunit is used to record the transaction information corresponding to the timed-out transaction into the second local cache list.

[0043] An electronic device provided in an embodiment of the present application includes a processor and a memory, wherein the memory stores a computer program, and the processor is used to run the computer program in the memory to execute the steps in the blockchain-based timeout transaction processing method provided in the embodiment of the present application.

[0044] An embodiment of the present application also provides a computer-readable storage medium, which stores a computer program, and the computer program is suitable for a processor to load to execute the steps in the blockchain-based timeout transaction processing method provided in the embodiment of the present application.

[0045] In addition, an embodiment of the present application also provides a computer program product, including a computer program, which, when executed by a processor, implements the steps in the blockchain-based timeout transaction processing method provided in the embodiment of the present application.

[0046] The embodiment of the present application provides a method and related equipment for processing timeout transactions based on blockchain, which can create a transaction execution block based on multiple transactions stored in a local transaction pool; execute multiple transactions in the transaction execution block to obtain the execution result of each transaction; determine the timeout transaction from multiple transactions based on the execution result; encapsulate the transaction execution block into an initial proposal; add the transaction identifier of the timeout transaction and the contract method called by the timeout transaction to the initial proposal to obtain a first target proposal; send the first target proposal to the slave node so that the slave node performs verification processing based on the first target proposal. The present application can enable the master node to record the contract method called by the timeout transaction in the first local cache list of this node when generating a proposal, if it encounters a timeout transaction, and add the timeout transaction and the contract method called by it to the proposal, and then send it to the slave node, and also generate a frozen contract method transaction based on the contract state as a contract method to be triggered, waiting for the next time the master node packages it into a proposal and sends it to the slave node. At the same time, the slave node will also update the status of the contract method called by the timed-out transaction in the second local cache list of the slave node according to the proposal of the master node, and judge the transaction type proposed by the master node, reach a consensus on the transaction that freezes the contract method when the consensus conditions are met, and then delete the contract method from the local cache list of each consensus node to avoid the transaction that calls the contract method being repeatedly packaged, executed, and timed out by the master node. This can reduce the time consumption of block packaging and improve the blockchain processing capacity. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0048] Figure 1a This is a scenario diagram of a method for processing a timeout transaction based on blockchain provided in an embodiment of the present application;

[0049] Figure 1b It is an optional structural diagram of the distributed system 100 provided in the embodiment of the present application applied to the blockchain system;

[0050] Figure 1c It is an optional schematic diagram of the block structure provided in the embodiment of the present application;

[0051] Figure 2a It is a first flow chart of a method for processing a timeout transaction based on a blockchain provided by a master node in an embodiment of the present application;

[0052] Figure 2b It is a second flow chart of the method for processing timeout transactions based on blockchain provided by the master node in an embodiment of the present application;

[0053] Figure 2c It is a state transformation diagram of a contract method of a timeout transaction processing method based on blockchain provided in an embodiment of the present application;

[0054] Figure 2d It is a flow chart of the implementation of the chained HotStuff consensus algorithm of the blockchain-based timeout transaction processing method provided in the embodiment of the present application;

[0055] Figure 3a It is a third flow chart of the method for processing a timeout transaction based on blockchain from a slave node provided in an embodiment of the present application;

[0056] Figure 3b It is a fourth flow chart of a method for processing a timeout transaction based on a blockchain from a slave node provided in an embodiment of the present application;

[0057] Figure 4 It is a fifth flow chart of the method for processing timeout transactions based on blockchain provided in an embodiment of the present application;

[0058] Figure 5 It is a structural diagram of a timeout transaction processing device based on blockchain of a master node provided in an embodiment of the present application;

[0059] Figure 6 It is another structural schematic diagram of a timeout transaction processing device based on blockchain from a slave node provided in an embodiment of the present application;

[0060] Figure 7 It is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0061] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of this application.

[0062] The embodiment of the present application provides a method for processing timeout transactions based on blockchain and related equipment, and the related equipment may include a timeout transaction processing device based on blockchain, an electronic device, a computer-readable storage medium, and a computer program product. The timeout transaction processing device based on blockchain can be specifically integrated in an electronic device.

[0063] 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, and big data and artificial intelligence platforms. The terminal can be a smart phone, tablet computer, laptop computer, desktop computer, smart speaker, smart watch, etc., but is not limited to this. The terminal and the server can be directly or indirectly connected via wired or wireless communication, and this application does not limit this.

[0064] like Figure 1a As shown, the blockchain-based timeout transaction processing device can be integrated into a server as an example. The blockchain-based timeout transaction processing system provided in the embodiment of the present application includes a master node and a slave node.

[0065] Among them, the master node can be used to: create a transaction execution block from multiple transactions stored in the local transaction pool; execute multiple transactions in the transaction execution block to obtain the execution result of each transaction; based on the execution result, determine the execution timeout transaction from the multiple transactions; encapsulate the transaction execution block into an initial proposal; add the transaction identifier of the execution timeout transaction and the contract method called by the execution timeout transaction to the initial proposal to obtain a first target proposal; send the first target proposal to the slave node so that the slave node performs verification processing based on the first target proposal.

[0066] The slave node can be used to: receive a target proposal from the master node; if the target proposal is a second target proposal, determine the frozen contract method transaction corresponding to the second target proposal; determine whether the contract method status of the contract method corresponding to the frozen contract method transaction in the second local cache list is a to-be-triggered state; if so, update the contract method status of the contract method corresponding to the frozen contract method transaction in the second local cache list to a consensus state.

[0067] The server may be a single server, or a server cluster or cloud server composed of multiple servers. The blockchain-based timeout transaction processing method or device disclosed in the present application, wherein multiple servers may form a blockchain, and the server is a node on the blockchain.

[0068] It should be noted that the blockchain-based timeout transaction processing system provided in the embodiment of the present application can be a distributed system connected by a client and multiple nodes (any form of computing device connected to the network, such as a server, a user terminal) through network communication.

[0069] Take the distributed system as the blockchain system as an example, see Figure 1b , Figure 1b This is an optional structural diagram of the distributed system 100 provided in the embodiment of the present application applied to the blockchain system, which is formed by multiple nodes 200 (any form of computing devices in the access network, such as servers, user terminals) and clients 300, and a peer-to-peer network is formed between the nodes. This protocol is an application layer protocol running on the Transmission Control Protocol (TCP). In a distributed system, any machine such as a server or a terminal can join and become a node, and the node includes a hardware layer, an intermediate layer, an operating system layer, and an application layer.

[0070] See also Figure 1b The functions of each node in the blockchain system shown include:

[0071] 1) Routing: a basic function of a node, used to support communication between nodes.

[0072] In addition to the routing function, the node can also have the following functions:

[0073] 2) Applications are deployed in the blockchain to implement specific businesses based on actual business needs, record data related to the implementation of functions to form record data, carry digital signatures in the record data to indicate the source of the task data, and send the record data to other nodes in the blockchain system for other nodes to add the record data to a temporary block when they successfully verify the source and integrity of the record data.

[0074] See also Figure 1c , Figure 1c This is an optional schematic diagram of the block structure provided by the embodiment of the present application. Each block includes the hash value of the transaction record stored in this block (the hash value of this block) and the hash value of the previous block. Each block is connected by the hash value to form a blockchain. In addition, the block can also include information such as the timestamp when the block was generated. Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods. Each data block contains relevant information for verifying the validity of its information (anti-counterfeiting) and generating the next block.

[0075] It is understandable that in the specific implementation of this application, related data such as user information is involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of relevant data need to comply with relevant laws, regulations and standards of relevant countries and regions.

[0076] The following are detailed descriptions. It should be noted that the description order of the following embodiments is not intended to limit the preferred order of the embodiments. This embodiment will be described from the perspective of a timeout transaction processing device based on blockchain, which can be specifically integrated in a server. The following will take the master node part of the timeout transaction processing device based on blockchain as an example for further detailed description, such as Figure 2a As shown, the process of master node timeout transaction processing based on blockchain is as follows:

[0077] 201. The master node creates a transaction execution block based on multiple transactions stored in the local transaction pool.

[0078] Among them, blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods. Each data block contains a batch of network transaction information, which is used to verify the validity of its information and generate the next block. Blockchain nodes usually refer to computers in the blockchain network, that is, any computer connected to the blockchain network is called a node; master nodes are usually more equipped than slave nodes. In addition to verifying, saving and transmitting transactions, master nodes sometimes promote other events in the blockchain according to their nature, such as voting events, execution of protocol operations and compliance with blockchain laws.

[0079] Among them, the transaction pool refers to the temporary storage of transaction records that have not been added to the block. The transaction pool can also be called a memory pool. Each node in the blockchain network has a corresponding transaction pool. When a new transaction is generated, the generated new transaction can be sent to the adjacent nodes in the blockchain network, so that the transaction can be propagated in the blockchain network. After receiving the new transaction, the adjacent node needs to verify the new transaction and add the verified new transaction to the transaction pool corresponding to the adjacent node. At the same time, the adjacent node can also broadcast the new transaction to the blockchain network. Other nodes in the blockchain network also need to verify the new transaction and add it to their respective transaction pools after confirmation. In other words, after receiving the transaction data, the nodes in the blockchain network will not immediately package the received transaction data into blocks, but temporarily store the transaction data in the transaction pool, and then extract a part of the data from the transaction pool according to the data selection rules and package it into blocks. After the block reaches a consensus, the block is added to the blockchain to complete the transaction chain process.

[0080] Among them, a transaction is a digital record. The transaction data is disseminated throughout the entire network through the blockchain network, notifying the transfer of ownership of the cryptocurrency, and is confirmed and verified throughout the entire network through a consensus mechanism, making the transaction irreversible and tamper-proof.

[0081] Among them, a block refers to a data block that is generated by cryptographic methods and packaged together. The data is permanently stored in the form of electronic records.

[0082] In order to improve the efficiency of transaction processing in the blockchain and to ensure transactionality by determining the execution order after the transaction, when there is a transaction in the local transaction pool, the thread is responsible for taking out a certain number of transactions from the local transaction pool in the order of first-in-first-out, and assembling them into transaction execution blocks. The transaction execution blocks will then be sent to each node for processing.

[0083] For example, in the embodiment of the present application, Figure 2b As shown, the master node can take a batch of transactions from the local transaction pool and package them into transaction execution blocks.

[0084] 202. The master node executes multiple transactions in the transaction execution block and obtains the execution result of each transaction.

[0085] For example, Figure 2b As shown, the master node can execute multiple transactions in the transaction execution block, among which there may be transactions that are successfully executed and there may also be transactions that are timed out. For transactions that are successfully executed, the execution results and transaction read-write sets can be attached to the transaction execution block.

[0086] Among them, the transaction read-write set is generated during the transaction simulation. The transaction read-write set will be verified during the transaction verification phase. The transaction read-write set can tell the blockchain transaction which data has been read, written or updated. The transaction read-write set includes the read set, write set and version number.

[0087] 203. The master node determines, based on the execution result, an execution timeout transaction from the multiple transactions.

[0088] For example, after the master node executes multiple transactions in a transaction execution block, it can determine which transactions are timed-out transactions from the multiple transactions through the execution results.

[0089] Optionally, in one embodiment, after the step of “determining the execution timeout transaction from multiple transactions based on the execution result”, the following may be included:

[0090] Record the contract method corresponding to the timed-out transaction into the first local cache list;

[0091] If it is detected in the first local cache list that the contract method meets the preset execution timeout condition, the contract method state corresponding to the contract method is determined as a to-be-triggered state.

[0092] Among them, both the master node and the slave node include a local cache list. In the embodiment of the present application, the local cache list corresponding to the master node is called the first local cache list, and the local cache list corresponding to the slave node is called the second local cache list. In the local cache list, the total number of contract method timeouts, the timed transaction ID and other information can be recorded, as shown in Table 1:

[0093]

[0094] Table 1

[0095] As can be seen from Table 1, the states of contract methods can be divided into the following categories:

[0096] 1) Normal status: Since a contract method is not identified as a contract method that needs to be blacklisted after a single execution timeout, a contract method in a normal state means that there are transactions that call the contract method and execution timeouts have occurred, but the conditions for blacklisting have not yet been met;

[0097] 2) Consensus status: A contract method in a consensus state means that the blacklisting conditions have been met, and a proposal to blacklist the contract method transaction has been initiated or received. The proposal is in the process of consensus and there is no need to initiate a request again;

[0098] 3) To-be-triggered state: A contract method in the to-be-triggered state means that the blacklisting conditions have been met, but the configuration transaction to blacklist the contract method has not yet been initiated. It can be initiated at the next local node proposal.

[0099] Among them, the preset execution timeout condition refers to the condition under which the contract method reaches the blacklist standard. Since a contract method is not identified as a contract method that needs to be blacklisted after a single execution timeout, the preset execution timeout condition is set in advance. Only contract methods that meet the preset execution timeout condition meet the blacklist standard. For example, for a certain contract method, there are the following three conditions to control whether it is added to the timeout blacklist:

[0100] 1) When executing a transaction that calls the contract method, the number of consensus nodes that have timed out reaches the preset minimum number of nodes;

[0101] 2) When a timeout occurs during execution, the number of transactions that call the contract method reaches the preset minimum number of transactions;

[0102] 3) When the total number of timeouts for all transactions that call the contract method on all consensus nodes reaches the preset minimum total number;

[0103] You can configure only one of the above three conditions, or configure multiple at the same time. If multiple conditions are configured at the same time, a logical AND relationship is taken. When multiple configured conditions are met at the same time, the contract method will be "blacklisted".

[0104] For example, Figure 2b As shown, in the process of traversing the execution timeout transactions, the master node will record the contract method corresponding to the execution timeout transaction into the first local cache list, and then check whether the contract method meets the preset execution timeout condition. If the contract method meets the preset execution timeout condition, the contract method state corresponding to the contract method is determined as a to-be-triggered state; if the contract method does not meet the preset execution timeout condition, the execution timeout transactions will continue to be traversed until all the execution timeout transactions in the first local cache list have been checked by the master node.

[0105] Among them, the transition conditions between the normal state, consensus state, and to-be-triggered state are as follows: Figure 2c As shown, if a timeout occurs during the execution of a local transaction, or after receiving execution timeout information from other nodes, the contract method can be considered to be in a normal state; if a timeout occurs during the execution of a local transaction, or after receiving execution timeout information from other nodes, and the conditions for blacklisting the contract method are met, the contract method can be considered to be in a pending trigger state; if the local master node initiates a freezing contract method transaction when proposing, or receives a proposal from other nodes containing a freezing contract method transaction, the contract method can be considered to be in a consensus state; if the system contract transaction that freezes the contract method has been successfully submitted, the node can directly delete the record of the contract method in the local cache list.

[0106] Among them, for frozen contract methods, when a user initiates a transaction and tries to call them, the system contract layer will check the status of the contract method and directly return an error message to the user that "the contract method has been frozen and cannot be called" without going through the consensus layer of the blockchain.

[0107] In addition, after receiving a new proposal from the node and successfully verifying it, the timeout transaction information attached to the proposal will also be counted in the second local cache list.

[0108] 204. The master node encapsulates the transaction execution block into an initial proposal.

[0109] Among them, the initial proposal refers to a preliminary proposal that does not include the execution timeout transaction and the contract method information it calls. The timeout transaction information needs to be added later to serve as a reference for modifying the local cache list from the node and judging the proposal type.

[0110] 205. The master node adds the transaction identifier of the timed transaction and the contract method called by the timed transaction to the initial proposal to obtain the first target proposal.

[0111] Among them, the transaction identifier, namely the transaction ID, is a string of characters calculated based on the size, time, type, creator, machine, etc. of each transaction. It is equivalent to the identity proof of each transaction and is unique and unchangeable.

[0112] For example, Figure 2b As shown, the transaction identifier of the timed transaction and the contract method called to execute the timed transaction can be added to the proposal as additional information, and the added initial proposal can be used as the first target proposal.

[0113] Optionally, in one embodiment, after the step of “adding the transaction identifier of the timed transaction and the contract method called by the timed transaction to the initial proposal to obtain the first target proposal”, the following may also be included:

[0114] Query the contract method whose contract method status is in the to-be-triggered state from the first local cache list, and determine the contract method whose contract method status is in the to-be-triggered state as the to-be-triggered contract method;

[0115] Construct a frozen contract method transaction based on the contract method to be triggered;

[0116] Call the local transaction pool interface to put the frozen contract method transaction into the local transaction pool;

[0117] Update the contract method status of the to-be-triggered contract method in the first local cache list to the consensus status.

[0118] For example, Figure 2b As shown, the master node can query the contract method whose status is to be triggered in the first local cache list, and generate a frozen contract method transaction accordingly, using the method name of the contract method as the parameter of the frozen contract method transaction, and then calling the transaction pool interface to put the frozen contract method transaction into the transaction pool, and at the same time change the status of the contract method in the first local cache list to the consensus status.

[0119] In one embodiment, the local transaction pool may also include a deduplication mechanism when packaging blocks, that is, to prevent different consensus nodes from repeatedly freezing the same contract method.

[0120] Optionally, in one embodiment, after the step of “updating the contract method status of the to-be-triggered contract method in the first local cache list to the consensus status”, the following may be included:

[0121] Create transaction execution blocks based on multiple transactions stored in the local transaction pool;

[0122] Execute multiple transactions in the transaction execution block and obtain the execution result of each transaction;

[0123] Based on the execution result, determining the execution timeout transaction from the plurality of transactions;

[0124] Encapsulate transaction execution blocks into initial proposals;

[0125] Add the transaction identifier of the timed-out transaction and the contract method called by the timed-out transaction to the initial proposal to obtain the second target proposal, which includes the transaction information corresponding to the frozen contract method transaction;

[0126] Send the second target proposal to the slave nodes.

[0127] Among them, although the master node generates a frozen contract method transaction and puts the transaction into the local transaction pool, the content of the frozen contract method transaction is not included in this proposal. The content of the frozen contract method transaction needs to be included in the next proposal. Therefore, the embodiment of the present application needs to be continuously cycled. Figure 2b Flowchart shown.

[0128] For example, the master node generated a frozen contract method transaction during the last proposal process and made a proposal. Then, the cycle will repeat as follows: Figure 2b The steps of the flowchart shown can be as follows: create a transaction execution block based on multiple transactions stored in the local transaction pool. At this time, the local transaction pool includes the frozen contract method transaction, and then execute multiple transactions in the transaction execution block to obtain the execution result of each transaction. Based on the execution result, determine the execution timeout transaction from multiple transactions, and encapsulate the transaction execution block into an initial proposal. Then, add the transaction identifier of the execution timeout transaction and the contract method called by the execution timeout transaction to the initial proposal to obtain the second target proposal. The second target proposal includes the transaction information corresponding to the frozen contract method transaction, and finally send the second target proposal to the slave node.

[0129] That is, the difference between the first target proposal and the second target proposal is that the first target proposal does not include information on freezing contract method transactions, while the second target proposal includes information on freezing contract methods.

[0130] Optionally, in one embodiment, after the step of “updating the contract method status of the to-be-triggered contract method in the first local cache list to the consensus status”, the following may be included:

[0131] Return to the steps of creating a transaction execution block based on multiple transactions stored in the local transaction pool until the master node no longer sends proposals to the slave node.

[0132] For example, after publishing the second target proposal, you can continue to return to the step of creating a transaction execution block based on multiple transactions stored in the local transaction pool until the master node no longer sends proposals to the slave node.

[0133] 206. The master node sends the first target proposal to the slave node, so that the slave node performs verification processing based on the first target proposal.

[0134] For example, after generating the first target proposal, the master node can send the first target proposal to the slave node; after generating the second target proposal, the master node can send the second target proposal to the slave node so that the slave node can perform the corresponding consensus step. In one embodiment, the technical solution of the present application can be used as a typical optimization solution, and appropriate publicity can be carried out externally, and the code level can be implemented according to the technical solution of the present application to optimize the corresponding blockchain underlying code.

[0135] Among them, the blockchain HotStuff consensus algorithm is a partial synchronization model based on the Byzantine problem of the leader node. Once the network enters the synchronization state, the HotStuff algorithm will allow a leader node to initiate consensus at a certain frequency.

[0136] In the prior art, the several stages of the blockchain HotStuff consensus algorithm are as follows:

[0137] 1. Preparation phase: The master node generates a proposal and broadcasts it to the slave nodes; the slave nodes vote on the proposal generation preparation phase and send it to the master node;

[0138] 2. Pre-submission phase: The master node combines the preparation phase votes of the quorum into the preparation phase QC and broadcasts it to the slave nodes; after the slave nodes verify the preparation phase QC, they generate the pre-submission phase vote and send it to the master node;

[0139] 3. Submission phase: The master node combines the pre-submission phase votes of the quorum into the pre-submission phase QC and broadcasts it to the slave nodes; after the slave nodes verify the pre-submission phase QC, they generate the submission phase vote and send it to the master node;

[0140] 4. Decision-making stage: The master node synthesizes the submission stage votes of the quorum into the submission stage QC, broadcasts it to the slave nodes, and submits the proposal; after the slave nodes verify the submission stage QC, they submit the proposal.

[0141] The implementation process of the chained HotStuff consensus algorithm can be as follows Figure 2d As shown:

[0142] The circles represent the step numbers, and the processing of each step is as follows:

[0143] 1. Node 1 serves as the master node of view 1, packages the block, and generates proposal 1;

[0144] 2. Node 1 broadcasts the generated Proposal 1 to the slave nodes (nodes 2, 3, and 4); and generates a preparation phase vote for Proposal 1 and sends it to the master node of the next view, that is, node 2;

[0145] 3. The slave node verifies Proposal 1 and adds Proposal 1 to its own memory;

[0146] 4. The slave node generates a preparation phase vote for Proposal 1 and sends it to the master node of the next view, i.e., Node 2. At this point, Proposal 1 has completed the first phase, i.e., the preparation phase.

[0147] 5. Entering view 2, node 2 serves as the master node of view 2, collects the preparation phase votes of proposal 1, synthesizes the preparation phase QC (QC1) of proposal 1, packages a new block, generates proposal 2, and attaches QC1 to proposal 2;

[0148] 6. Node 2 broadcasts the generated Proposal 2 to the slave nodes (nodes 1, 3, and 4), generates a vote for Proposal 2, and sends it to the master node of the next view, that is, node 3;

[0149] 7. The slave node verifies Proposal 2 and QC1, and adds Proposal 2 and QC1 to its own memory;

[0150] 8. The slave node generates a vote for Proposal 2 (this vote is a vote for the preparation phase of Proposal 2, but because it is cast after verifying QC1, it is also a vote for the pre-submission phase of Proposal 1); the slave node sends the vote to the master node of the next view, that is, Node 3; so far, Proposal 2 has completed the first phase, that is, the preparation phase; at the same time, since QC1 is also verified and voted by a quorum of slave nodes in this process, Proposal 1 has completed the second phase, that is, the pre-submission phase;

[0151] 9. Enter view 3. Node 3 acts as the master node of view 3, collects votes for proposal 2, synthesizes QC2, packages a new block, generates proposal 3, and attaches QC2 to proposal 3;

[0152] 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, that is, node 4;

[0153] 11. The slave node verifies Proposal 3 and QC2, and adds Proposal 3 and QC2 to its own memory;

[0154] 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-submission phase. Since the vote contained in QC2 is also the pre-submission phase vote for Proposal 1, QC2 is not only the QC for the preparation phase of Proposal 2, but also the QC for the pre-submission phase of Proposal 1. Therefore, the vote cast by the slave node after verifying QC2 is the preparation phase vote for Proposal 3, the pre-submission phase vote for Proposal 2, and the submission phase vote for Proposal 1. That is, Proposal 1 has completed the submission phase.

[0155] 13. Enter the video Figure 4 , node 4 is the view Figure 4 The master node collects votes for Proposal 3, synthesizes QC3, packages a new block, generates Proposal 4, and attaches QC3 to Proposal 4;

[0156] 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 QC in the preparation stage of Proposal 3, the QC in the pre-submission stage of Proposal 2, and also as the QC in the submission stage of Proposal 1; when processing QC3, Node 4 finds that a proposal that complies with the 3-chain rule (i.e., three QCs connected in sequence: QC1<-QC2<-QC3) appears in the memory, i.e., Proposal 1. In other words, Proposal 1 has reached the decision-making stage, and Node 4 submits Proposal 1;

[0157] 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 appears in the memory, Proposal 1, which means that the proposal has reached the decision-making stage, so Proposal 1 is submitted.

[0158] 16. The slave node generates a vote for Proposal 4 (also serving as a preparation phase vote for Proposal 4, a pre-submission phase vote for Proposal 3, and a submission phase vote for Proposal 2), and sends it to the master node of the next view, i.e., Node 2. For the reasons mentioned above, at this point, Proposal 4 has completed the preparation phase, Proposal 3 has completed the pre-submission phase, Proposal 2 has completed the submission phase, and Proposal 1 has completed the decision phase and has been submitted.

[0159] That is, view 1 is the preparation stage of proposal 1; view 2 is the preparation stage of proposal 2, and also the pre-submission stage of view 1; view 3 is the preparation stage of proposal 3, the pre-submission stage of proposal 2, and the submission stage of proposal 1; Figure 4 It is the preparation stage for Proposal 4, the pre-submission stage for Proposal 3, the submission stage for Proposal 2, and the decision stage for Proposal 1.

[0160] In the prior art, the process of masternode packaging blocks and generating proposals can be as follows:

[0161] The master node takes a batch of transactions from the transaction pool, packages them into block 1, and executes all transactions in block 1. Then, for transactions that are successfully executed, the execution results and transaction read-write sets are attached to the block. For transactions that have timed out, the transactions are released back to the transaction pool, and the transaction status is reset to the pending packaging status. Then, the block is encapsulated as a proposal and the proposal is broadcast to other nodes.

[0162] The native chained hotstuff consensus algorithm handles timed transactions as follows:

[0163] 1. If block 1 of proposal 1 contains 100 transactions, the master node will first execute these 100 transactions in parallel (or serially) when packaging the block. After successful execution, the execution results and transaction read-write sets will be attached to the block, then encapsulated into a proposal and broadcast to the slave nodes;

[0164] 2. If one of the transactions times out, the transaction is removed after the timeout, and the remaining 99 transactions are repackaged into a block. The execution results of these 99 transactions and the transaction read-write set are attached to the block, which is then packaged into a proposal and broadcast to the slave nodes.

[0165] 3. A transaction that has timed out will be released back to the transaction pool by the master node and wait for the next packaging.

[0166] However, if the transaction execution timeout is 10s, and it takes less than 10ms to execute 100 transactions in parallel, then the throughput of the original blockchain can theoretically reach 10,000tps. However, if one of the 100 transactions happens to time out, then the transaction will be confirmed to have timed out when the block reaches 10s, and the block can be packaged and broadcasted normally. During the processing of this block, the throughput of the blockchain is temporarily reduced to 10tps. In addition, this transaction will be repeatedly retried during the subsequent consensus process, and each retry will reduce the processing capacity of the blockchain.

[0167] Among them, the throughput of the blockchain refers to the number of transactions that can be processed in a fixed time, and the latency refers to the response and processing time of the transaction. The performance indicators of the blockchain mainly include transaction throughput and latency. In practical applications, it is necessary to comprehensively examine the two factors - it is incorrect to only use transaction throughput without considering latency. Long transaction response will hinder user use and affect user experience; only using latency without considering throughput will lead to a large number of transactions queuing. Some platforms must be able to handle a large number of concurrent users, and technical solutions with too low transaction throughput will be directly abandoned.

[0168] In other words, the shortcomings of the existing technology are very obvious. From the above process analysis, it can be clearly seen that the chain hotstuff consensus algorithm cannot avoid the impact of timed transactions. After encountering a timed transaction, it will repeatedly try to execute the transaction like a normal transaction and package the transaction into a block, which eventually causes the entire chain to be affected by these transactions, greatly reducing the chain's processing capacity.

[0169] Therefore, the technical solution of this application proposes a solution for timed transactions to address the problems existing in the current processing flow, and makes process adjustments to the risks of possible evidence in the solution. Through this solution, the chained HotStuff consensus cluster can identify the contract method when it encounters transactions that call a certain contract method and frequently timeouts, and temporarily disable this contract method, and shield the risks existing in the solution, thereby avoiding the hidden dangers of timed transactions to the blockchain.

[0170] The technical solution proposed in this application has established a "timeout contract method blacklist" system, which can support the chained HotStuff consensus to identify and temporarily disable some unreasonable contracts. Each consensus node has a local cache list to record the contract method identifier corresponding to the timeout transaction that has timed out, as well as the number of transaction timeouts of the contract method and other information. Specifically, when the chained HotStuff consensus encounters a transaction execution timeout, it records the contract method called by the transaction. If the transaction timeout corresponding to the contract method reaches a certain condition, the chained HotStuff consensus will generate a configuration transaction. As an ordinary system contract transaction, it will first enter the transaction pool and then be processed according to the consensus process of normal transactions. It is used to notify the contract management and automatically freeze the contract method. At the same time, in order to avoid the risk of the main node doing evil, it is necessary to reach a consensus on multiple nodes to blacklist a contract method. The frozen contract method can still be viewed in the chain, but it cannot be called temporarily. It requires manual intervention to unfreeze, that is, to re-enable the contract method. This technical solution can avoid the long-term impact of timeout transactions on the chain.

[0171] The technical solution of the present application solves the problem that in the blockchain system, transactions that call individual contract methods frequently experience execution timeouts, which leads to a significant increase in the time required for block packaging, affects the consensus reached in normal transactions, and further affects the overall processing capacity of the blockchain.

[0172] As can be seen from the above, this embodiment can create a transaction execution block based on multiple transactions stored in a local transaction pool; execute multiple transactions in the transaction execution block to obtain the execution result of each transaction; based on the execution result, determine the execution timeout transaction from the multiple transactions; encapsulate the transaction execution block into an initial proposal; add the transaction identifier of the execution timeout transaction and the contract method called by the execution timeout transaction to the initial proposal to obtain a first target proposal; send the first target proposal to the slave node so that the slave node performs verification based on the first target proposal. This application allows the master node to record the contract method called by the timed transaction in the local cache list of this node if it encounters a transaction with a timeout when generating a proposal, and add the timed transaction and the contract method it calls to the proposal, and then send it to the slave node. It will also generate a frozen contract method transaction based on the contract status of the contract method to be triggered, waiting for the next time the master node packages it into a proposal and sends it to the slave node. At the same time, the slave node will also update the status of the contract method called by the timed transaction in the local cache list of the slave node according to the proposal of the master node, judge the transaction type of the master node proposal, reach a consensus on the frozen contract method transaction that meets the consensus conditions, and then delete the contract method from the local cache list of each consensus node to avoid the transaction that calls the contract method being repeatedly packaged, executed, and timed out by the master node. This can reduce the time consumption of block packaging and improve the blockchain processing capacity.

[0173] The following will take the slave node part of the timeout transaction processing device based on blockchain as an example to further explain in detail. Figure 3a As shown, the process of timeout transaction processing based on blockchain from the slave node is as follows:

[0174] 301. The slave node receives the target proposal from the master node.

[0175] For example, the slave node may receive a target proposal from the master node, wherein the slave node may receive a first target proposal from the master node or a second target proposal from the master node.

[0176] Optionally, in one embodiment, the step of “receiving a target proposal from a master node” may include:

[0177] Receive proposals from other nodes;

[0178] If it is detected that the proposal carries transaction information corresponding to the timed-out transaction, it is determined that the received proposal is the target proposal from the master node;

[0179] The transaction information corresponding to the timed-out transaction is recorded in the second local cache list.

[0180] Among them, the transaction information corresponding to the timed-out transaction is the transaction identifier of the timed-out transaction and the contract method called by the timed-out transaction. It is attached to the proposal generated by the master node when the timed-out transaction is encountered during the master node proposal generation process.

[0181] Among them, the second local cache list in this embodiment of the application is a local cache list corresponding to the slave node.

[0182] For example, Figure 3b As shown, after receiving the proposal from the master node, the slave node first determines whether the proposal contains the transaction identifier of the timed-out transaction and the contract method called by the timed-out transaction. If not, it is identified as a non-target proposal and the proposal is processed normally. If yes, it is identified as a target proposal, and the transaction information corresponding to the timed-out transaction is recorded in the second local cache list of the slave node. At the same time, if the contract method called by the timed-out transaction meets the conditions for modifying the state of the contract method, the state of the contract method in the second local cache list is modified.

[0183] 302. If it is detected that the target proposal is the second target proposal, the slave node determines the frozen contract method transaction corresponding to the second target proposal.

[0184] For example, Figure 3b As shown, it is determined whether there is a frozen contract method transaction in the transaction type included in the target proposal. If there is a frozen contract method transaction, the process proceeds to step 303; if there is no frozen contract method transaction, the proposal is processed normally.

[0185] 303. The slave node determines whether the contract method status of the contract method corresponding to the frozen contract method transaction in the second local cache list is in a to-be-triggered state.

[0186] 304. If yes, the contract method status of the contract method corresponding to the frozen contract method transaction in the second local cache list is updated to the consensus status.

[0187] For example, if the contract method status of the contract method corresponding to the frozen contract method transaction in the second local cache list is in the pending trigger state, the frozen contract method transaction corresponding to the contract method is verified, and the proposal is voted on. After the vote is successful, the contract method status of the contract method corresponding to the frozen contract method transaction in the second local cache list is modified, and the contract method status is modified to the consensus state. After the status of this contract method status in the local cache lists of multiple consensus nodes is modified to the consensus state, the frozen contract method transaction corresponding to this contract method reaches a consensus normally, and then after this frozen contract is submitted to the chain, the local cache list of each consensus node will delete the contract method. If the contract method status of the contract method corresponding to the frozen contract method transaction in the second local cache list is not in the pending trigger state, the verification transaction fails and the slave node does not vote. After the transaction reaches a consensus normally and is submitted to the chain, each consensus node will delete the contract method from the local cache list.

[0188] As can be seen from the above, this embodiment can receive a target proposal from the master node; if the target proposal is a second target proposal, determine the frozen contract method transaction corresponding to the second target proposal; determine whether the contract method status of the contract method corresponding to the frozen contract method transaction in the second local cache list is a to-be-triggered state; if so, update the contract method status of the contract method corresponding to the frozen contract method transaction in the second local cache list to a consensus state. This application allows the master node to record the contract method called by the timed transaction in the local cache list of this node if it encounters a transaction with a timeout when generating a proposal, and add the timed transaction and the contract method it calls to the proposal, and then send it to the slave node. It will also generate a frozen contract method transaction based on the contract status of the contract method to be triggered, waiting for the next time the master node packages it into a proposal and sends it to the slave node. At the same time, the slave node will also update the status of the contract method called by the timed transaction in the local cache list of the slave node according to the proposal of the master node, judge the transaction type of the master node proposal, reach a consensus on the frozen contract method transaction that meets the consensus conditions, and then delete the contract method from the local cache list of each consensus node to avoid the transaction that calls the contract method being repeatedly packaged, executed, and timed out by the master node. This can reduce the time consumption of block packaging and improve the blockchain processing capacity.

[0189] The following will take the blockchain-based timeout transaction processing device as an example to further explain in detail. Figure 4 As shown, the process of blockchain-based timeout transaction processing is as follows:

[0190] 401. The master node executes multiple transactions in the local transaction pool, and determines to execute a timed-out transaction from the multiple transactions.

[0191] For example, there are two types of transactions: timeout and non-timeout. When the master node packages the execution block based on multiple transactions in the local transaction pool, it will first execute all transactions in the execution block in parallel or in sequence, and obtain the execution result corresponding to each transaction in order to understand whether the transaction is an execution timeout transaction.

[0192] Then, the execution timeout transaction and the execution successful transaction can be processed differently. For example, the master node can attach the execution result and transaction read-write set of the execution successful transaction with a successful execution result to the execution block, and record the execution timeout transaction with a timeout as the execution result; record the information of the execution timeout transaction with a timeout as the execution result, traverse all the execution timeout transactions with timeouts, and record the relevant information of the contract method called by the execution timeout transaction with timeouts into the first local cache list of the master node, and compare the timeout information of the contract method called by the corresponding execution timeout transaction with timeouts in the first local cache list with the conditions for blacklisting the contract method. If the conditions are met, the state of this contract method in the first local cache list is changed to pending triggering until all execution timeout transactions are traversed.

[0193] 402. The master node adds the relevant information of executing the timed-out transaction to the first target proposal, and sends the first target proposal to the slave node.

[0194] For example, after the master node has traversed all the timed-out transactions, it will encapsulate the execution block containing the execution results of the successfully executed transactions and the transaction read-write set into an initial proposal, and then add the transaction identifier of the timed-out transaction and the contract method called by the timed-out transaction as additional information to the initial proposal, and use the added initial proposal as the first target proposal.

[0195] Among them, the transaction identifier of the timed transaction and the contract method called by the timed transaction can be used as a reference for the subsequent slave node to modify the local cache list and determine the proposal type. Proposals that do not contain the transaction identifier of the timed transaction and the contract method called by the timed transaction are treated as normal proposals and processed normally by the slave node; proposals that contain the transaction identifier of the timed transaction and the contract method called by the timed transaction are treated as target proposals for subsequent judgment and processing by the slave node.

[0196] 403. The master node constructs a frozen contract method transaction based on the contract method to be triggered, and puts the frozen contract method transaction into the local transaction pool.

[0197] For example, the master node can query the contract method whose contract method status is to be triggered from the first local cache list, and determine the contract method whose contract method status is to be triggered as the contract method to be triggered, and then query the contract method whose contract method status is to be triggered from the first local cache list, and generate a frozen contract method transaction, using the method name of the to-be-triggered contract method as the parameter of the frozen contract method transaction, and then call the transaction pool interface to put the frozen contract method transaction into the transaction pool, and at the same time change the status of this contract method in the first local cache list to the consensus status.

[0198] 404. The master node executes multiple transactions in the local transaction pool, and determines to execute a timed-out transaction from the multiple transactions.

[0199] For example, after the master node sends the first target proposal, the operation content of step 401 can be executed cyclically, but at this time the local transaction pool also includes the frozen contract method transaction.

[0200] 405. The master node adds the relevant information of executing the timeout transaction to the second target proposal, and sends the second target proposal to the slave node.

[0201] For example, the master node can select multiple transactions from the transaction pool again, package them into blocks, execute the transactions in the blocks, attach the execution results and transaction readers of the successfully executed transactions to the execution blocks, and then encapsulate the execution blocks into the initial proposals, and then add the transaction identifiers of the timed-out transactions and the contract methods called by the timed-out transactions to the initial proposals as the second target proposals. The master node will continue to create transaction execution blocks from multiple transactions stored in the local transaction pool until the master node no longer sends proposals to the slave nodes.

[0202] Among them, the second target proposal includes a frozen contract method transaction generated by the local node when generating the proposal.

[0203] 406. The slave node receives the target proposal from the master node.

[0204] For example, there are many types of proposals received from the master node by the slave node. So after receiving the proposal from the master node, the slave node first determines whether there is an additional transaction identifier of the execution timeout transaction and the contract method called by the execution timeout transaction in the proposal. If not, it is identified as a normal proposal and the normal proposal is processed normally; if so, it is identified as a target proposal, and the transaction information corresponding to the execution timeout transaction is recorded in the second local cache list of this slave node. At the same time, if the contract method called by the execution timeout transaction meets the conditions for modifying the state of the contract method, the state of this contract method in the second local cache list is modified. Secondly, it is determined whether the transaction in the proposal determined as the target proposal contains a frozen contract method transaction. If there is a frozen contract method transaction, the target proposal is determined to be the second target proposal.

[0205] Among them, the transaction information corresponding to the timed-out transaction is the transaction identifier of the timed-out transaction and the contract method called by the transaction with the timed-out execution. It is the information attached to the proposal generated by the master node when encountering a timed-out transaction during the proposal generation process.

[0206] 407. If the slave node detects that the target proposal is the second target proposal, determine the frozen contract method transaction corresponding to the second target proposal.

[0207] 408. The slave node determines whether the contract method status corresponding to the frozen contract method transaction is in a to-be-triggered state.

[0208] 409. If yes, the slave node updates the contract method status corresponding to the frozen contract method transaction in the second local cache list to the consensus status.

[0209] For example, if the contract method status of the contract method corresponding to the frozen contract method transaction in the second local cache list is in the pending trigger state, the frozen contract method transaction corresponding to the contract method is verified, and the corresponding second target proposal is voted on. After the vote is successful, the contract method status of the contract method corresponding to the frozen contract method transaction in the second local cache list is modified, and the contract method status is modified to the consensus state. After the status of this contract method status in the local cache lists of multiple consensus nodes is modified to the consensus state, the frozen contract method transaction corresponding to this contract method reaches a consensus, and then after this frozen contract is submitted to the chain, the local cache list of each consensus node will delete the contract method.

[0210] As can be seen from the above, this embodiment can execute multiple transactions in the local transaction pool through the master node, and determine the execution timeout transaction from the multiple transactions; add the relevant information of the execution timeout transaction to the first target proposal, and send the first target proposal to the slave node; construct a frozen contract method transaction based on the contract method to be triggered, and put the frozen contract method transaction into the local transaction pool; execute multiple transactions in the local transaction pool, and determine the execution timeout transaction from the multiple transactions; add the relevant information of the execution timeout transaction to the second target proposal, and send the second target proposal to the slave node; receive the target proposal from the master node through the slave node; if the slave node detects that the target proposal is the second target proposal, determine the frozen contract method transaction corresponding to the second target proposal; the slave node determines whether the contract method state corresponding to the frozen contract method transaction is a to-be-triggered state; if so, the slave node updates the contract method state corresponding to the frozen contract method transaction in the second local cache list to a consensus state. This application allows the master node to record the contract method called by the timed transaction in the local cache list of this node if it encounters a transaction with a timeout when generating a proposal, and add the timed transaction and the contract method it calls to the proposal, and then send it to the slave node. It will also generate a frozen contract method transaction based on the contract status of the contract method to be triggered, waiting for the next time the master node packages it into a proposal and sends it to the slave node. At the same time, the slave node will also update the status of the contract method called by the timed transaction in the local cache list of the slave node according to the proposal of the master node, judge the transaction type of the master node proposal, reach a consensus on the frozen contract method transaction that meets the consensus conditions, and then delete the contract method from the local cache list of each consensus node to avoid the transaction that calls the contract method being repeatedly packaged, executed, and timed out by the master node. This can reduce the time consumption of block packaging and improve the blockchain processing capacity.

[0211] In order to better implement the above method, the present application embodiment also provides two blockchain-based timeout transaction processing devices, such as Figure 5 As shown, the master node based on the blockchain timeout transaction processing device may include a creation unit 501, an execution unit 502, a first determination unit 503, an encapsulation unit 504, an adding unit 505 and a sending unit 506, as follows:

[0212] (1) Create unit 501;

[0213] A creation unit, used to create a transaction execution block based on multiple transactions stored in the local transaction pool;

[0214] (2) Execution unit 502;

[0215] An execution unit, configured to execute multiple transactions in the transaction execution block and obtain an execution result of each transaction;

[0216] (3) a first determining unit 503;

[0217] A first determining unit, configured to determine an execution timeout transaction from a plurality of transactions based on the execution result;

[0218] Optionally, in some embodiments of the present application, the first determining unit may include a recording subunit and a third determining subunit, as follows:

[0219] The recording subunit is used to record the contract method corresponding to the timed-out transaction into the first local cache list;

[0220] The third determination subunit is used to determine the contract method state corresponding to the contract method as a to-be-triggered state if it is detected in the first local cache list that the contract method satisfies a preset execution timeout condition.

[0221] (4) Encapsulation unit 504;

[0222] A packaging unit, used for packaging the transaction execution block into an initial proposal;

[0223] (5) adding unit 505;

[0224] An adding unit, configured to add the transaction identifier of the timed-out transaction and the contract method called by the timed-out transaction to the initial proposal to obtain a first target proposal;

[0225] (6) a sending unit 506;

[0226] A sending unit is used to send the first target proposal to the slave node, so that the slave node performs verification based on the first target proposal.

[0227] like Figure 6 As shown, the timeout transaction processing device based on blockchain of the slave node may include a receiving unit 601, a second determining unit 602, a determining unit 603 and an updating unit 604, as follows:

[0228] (1) receiving unit 601;

[0229] The receiving unit is used to receive target proposals from the master node.

[0230] Optionally, in some embodiments of the present application, the receiving unit may include a receiving subunit, a fifth determining subunit, and a second recording subunit, as follows:

[0231] The receiving subunit is used to receive proposals from other nodes;

[0232] The fifth determining subunit is configured to determine that the received proposal is a target proposal from the master node if it is detected that the proposal carries transaction information corresponding to the timed-out transaction;

[0233] The second recording subunit is used to record the transaction information corresponding to the timed-out transaction into the second local cache list.

[0234] (2) a second determining unit 602;

[0235] The second determining unit is used to determine the frozen contract method transaction corresponding to the second target proposal if the target proposal is the second target proposal.

[0236] (3) determination unit 603;

[0237] A determination unit is used to determine whether the contract method status of the contract method corresponding to the frozen contract method transaction in the second local cache list is a to-be-triggered status.

[0238] (4) Update unit 604;

[0239] An updating unit is used to update the contract method status of the contract method corresponding to the frozen contract method transaction in the second local cache list to a consensus status if yes.

[0240] As can be seen from the above, this embodiment can create a transaction execution block based on multiple transactions stored in a local transaction pool; execute multiple transactions in the transaction execution block to obtain the execution result of each transaction; based on the execution result, determine the execution timeout transaction from the multiple transactions; encapsulate the transaction execution block into an initial proposal; add the transaction identifier of the execution timeout transaction and the contract method called by the execution timeout transaction to the initial proposal to obtain a first target proposal; send the first target proposal to the slave node so that the slave node performs verification based on the first target proposal. This application allows the master node to record the contract method called by the timed transaction in the local cache list of this node if it encounters a transaction with a timeout when generating a proposal, and add the timed transaction and the contract method it calls to the proposal, and then send it to the slave node. It will also generate a frozen contract method transaction based on the contract status of the contract method to be triggered, waiting for the next time the master node packages it into a proposal and sends it to the slave node. At the same time, the slave node will also update the status of the contract method called by the timed transaction in the local cache list of the slave node according to the proposal of the master node, judge the transaction type of the master node proposal, reach a consensus on the frozen contract method transaction that meets the consensus conditions, and then delete the contract method from the local cache list of each consensus node to avoid the transaction that calls the contract method being repeatedly packaged, executed, and timed out by the master node. This can reduce the time consumption of block packaging and improve the blockchain processing capacity.

[0241] The present application also provides an electronic device, such as Figure 7 As shown, it shows a schematic diagram of the structure of an electronic device involved in an embodiment of the present application, and the electronic device may be a terminal or a server, etc. Specifically:

[0242] The electronic device may include components such as a processor 701 with one or more processing cores, a memory 702 with one or more computer-readable storage media, a power supply 703, and an input unit 704. Those skilled in the art will appreciate that Figure 7 The electronic device structure shown in the figure does not constitute a limitation on the electronic device, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0243] The processor 701 is the control center of the electronic device, which uses various interfaces and lines to connect various parts of the entire electronic device, and executes various functions of the electronic device and processes data by running or executing software programs and / or modules stored in the memory 702, and calling data stored in the memory 702. Optionally, the processor 701 may include one or more processing cores; preferably, the processor 701 may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface, and application programs, and the modem processor mainly processes wireless communications. It is understandable that the above-mentioned modem processor may not be integrated into the processor 701.

[0244] The memory 702 can be used to store software programs and modules. The processor 701 executes various functional applications and data processing by running the software programs and modules stored in the memory 702. The memory 702 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 702 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage devices. Accordingly, the memory 702 may also include a memory controller to provide the processor 701 with access to the memory 702.

[0245] The electronic device also includes a power supply 703 for supplying power to each component. Preferably, the power supply 703 can be logically connected to the processor 701 through a power management system, so as to manage charging, discharging, and power consumption through the power management system. The power supply 703 can also include any components such as one or more DC or AC power supplies, recharging systems, power failure detection circuits, power converters or inverters, and power status indicators.

[0246] The electronic device may further include an input unit 704, which may be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal input related to user settings and function control.

[0247] Although not shown, the electronic device may further include a display unit, etc., which will not be described in detail herein. Specifically in this embodiment, the processor 701 in the electronic device will load the executable files corresponding to the processes of one or more application programs into the memory 702 according to the following instructions, and the processor 701 will run the application programs stored in the memory 702, thereby realizing various functions, as follows:

[0248] A transaction execution block is created based on multiple transactions stored in a local transaction pool; multiple transactions in the transaction execution block are executed to obtain an execution result of each transaction; based on the execution result, an execution timeout transaction is determined from multiple transactions; the transaction execution block is encapsulated into an initial proposal; the transaction identifier of the execution timeout transaction and the contract method called by the execution timeout transaction are added to the initial proposal to obtain a first target proposal; the first target proposal is sent to a slave node so that the slave node performs verification processing based on the first target proposal.

[0249] The specific implementation of the above operations can be found in the previous embodiments, which will not be described in detail here.

[0250] As can be seen from the above, this embodiment can create a transaction execution block based on multiple transactions stored in a local transaction pool; execute multiple transactions in the transaction execution block to obtain the execution result of each transaction; based on the execution result, determine the execution timeout transaction from the multiple transactions; encapsulate the transaction execution block into an initial proposal; add the transaction identifier of the execution timeout transaction and the contract method called by the execution timeout transaction to the initial proposal to obtain a first target proposal; send the first target proposal to the slave node so that the slave node performs verification based on the first target proposal. This application allows the master node to record the contract method called by the timed transaction in the local cache list of this node if it encounters a transaction with a timeout when generating a proposal, and add the timed transaction and the contract method it calls to the proposal, and then send it to the slave node. It will also generate a frozen contract method transaction based on the contract status of the contract method to be triggered, waiting for the next time the master node packages it into a proposal and sends it to the slave node. At the same time, the slave node will also update the status of the contract method called by the timed transaction in the local cache list of the slave node according to the proposal of the master node, judge the transaction type of the master node proposal, reach a consensus on the frozen contract method transaction that meets the consensus conditions, and then delete the contract method from the local cache list of each consensus node to avoid the transaction that calls the contract method being repeatedly packaged, executed, and timed out by the master node. This can reduce the time consumption of block packaging and improve the blockchain processing capacity.

[0251] A person of ordinary skill in the art will appreciate that all or part of the steps in the various methods of the above embodiments may be completed by instructions, or by controlling related hardware through instructions. The instructions may be stored in a computer-readable storage medium and loaded and executed by a processor.

[0252] To this end, an embodiment of the present application provides a computer-readable storage medium, in which a plurality of instructions are stored, and the instructions can be loaded by a processor to execute the steps in any of the blockchain-based timeout transaction processing methods provided in the embodiments of the present application. For example, the instructions can execute the following steps:

[0253] As can be seen from the above, this embodiment can create a transaction execution block based on multiple transactions stored in a local transaction pool; execute multiple transactions in the transaction execution block to obtain the execution result of each transaction; based on the execution result, determine the execution timeout transaction from the multiple transactions; encapsulate the transaction execution block into an initial proposal; add the transaction identifier of the execution timeout transaction and the contract method called by the execution timeout transaction to the initial proposal to obtain a first target proposal; send the first target proposal to the slave node so that the slave node performs verification based on the first target proposal.

[0254] The specific implementation of the above operations can be found in the previous embodiments, which will not be described in detail here.

[0255] Among them, the computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc. Since the instructions stored in the computer-readable storage medium can execute the steps in any of the timeout transaction processing methods based on blockchain provided in the embodiments of the present application, the beneficial effects that can be achieved by any of the timeout transaction processing methods based on blockchain provided in the embodiments of the present application can be achieved. See the previous embodiments for details, which will not be repeated here.

[0256] According to one aspect of the present application, a computer program product or a computer program is provided, the computer program product or the computer program comprising computer instructions, the computer instructions being stored in a computer-readable storage medium. A processor of a 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 method provided in various optional implementations of the above-mentioned blockchain-based timeout transaction processing.

[0257] The above is a detailed introduction to a blockchain-based timeout transaction processing method and related equipment provided in an embodiment of the present application. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea; at the same time, for technical personnel in this field, according to the idea of ​​the present application, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A method for processing timeout transactions based on blockchain, characterized in that: Applicable to the master node, the method comprises: Create transaction execution blocks based on multiple transactions stored in the local transaction pool; Execute multiple transactions in the transaction execution block to obtain the execution result of each transaction; Based on the execution result, determining an execution timeout transaction from the plurality of transactions; Encapsulating the transaction execution block into an initial proposal; Adding the transaction identifier of the timed-out transaction and the contract method called by the timed-out transaction to the initial proposal to obtain a first target proposal; The first target proposal is sent to the slave node so that the slave node performs verification processing based on the first target proposal.

2. The method for processing overtime transactions based on blockchain according to claim 1, characterized in that: After determining the timed-out transaction from the plurality of transactions based on the execution result, the method further includes: Recording the contract method corresponding to the timed-out transaction into the first local cache list; If it is detected in the first local cache list that the contract method meets the preset execution timeout condition, the contract method state corresponding to the contract method is determined as a to-be-triggered state.

3. The method for processing overtime transactions based on blockchain according to claim 2 is characterized in that: After adding the transaction identifier of the timeout transaction and the contract method called by the timeout transaction to the initial proposal to obtain the first target proposal, the method further includes: Querying the contract method whose contract method status is the to-be-triggered state from the first local cache list, and determining the contract method whose contract method status is the to-be-triggered state as the to-be-triggered contract method; Constructing a frozen contract method transaction based on the contract method to be triggered; Call the local transaction pool interface to put the frozen contract method transaction into the local transaction pool; Update the contract method status of the to-be-triggered contract method in the first local cache list to a consensus status.

4. The method for processing overtime transactions based on blockchain according to claim 3 is characterized in that: After the contract method status of the to-be-triggered contract method in the first local cache list is updated to a consensus status, the method further includes: Creating a transaction execution block based on multiple transactions stored in the local transaction pool; Execute multiple transactions in the transaction execution block to obtain the execution result of each transaction; Based on the execution result, determining an execution timeout transaction from the plurality of transactions; Encapsulating the transaction execution block into an initial proposal; Adding the transaction identifier of the timeout transaction and the contract method called by the timeout transaction to the initial proposal to obtain a second target proposal, wherein the second target proposal includes the transaction information corresponding to the frozen contract method transaction; The second target proposal is sent to the slave node.

5. The method for processing overtime transactions based on blockchain according to claim 3 is characterized in that: After the contract method status of the to-be-triggered contract method in the first local cache list is updated to a consensus status, the method further includes: Return to executing the step of creating a transaction execution block based on the multiple transactions stored in the local transaction pool until the master node no longer sends a proposal to the slave node.

6. A method for processing timeout transactions based on blockchain, characterized in that: Applicable to a slave node, the method comprises: Receive a target proposal from a master node, wherein the target proposal includes a first target proposal and a second target proposal; If it is detected that the target proposal is the second target proposal, determining a frozen contract method transaction corresponding to the second target proposal; Determine whether the contract method status of the contract method corresponding to the frozen contract method transaction in the second local cache list is in a to-be-triggered state; If so, the contract method status of the contract method corresponding to the frozen contract method transaction in the second local cache list is updated to the consensus status.

7. The method for processing overtime transactions based on blockchain according to claim 6 is characterized in that: The receiving of the target proposal from the master node includes: Receive proposals from the masternode; If it is detected that the proposal carries transaction information corresponding to the timed-out transaction, it is determined that the received proposal is the target proposal from the master node; The transaction information corresponding to the timed-out transaction is recorded in the second local cache list.

8. The method for processing overtime transactions based on blockchain according to claim 6, characterized in that: After the contract method status of the contract method corresponding to the frozen contract method transaction in the second local cache list is updated to a consensus status, the method further includes: The contract method of the consensus state of the contract method state is deleted from the second local cache list.

9. A timeout transaction processing device based on blockchain, characterized in that: Applicable to a master node, the device comprises: A creation unit, used to create a transaction execution block based on multiple transactions stored in the local transaction pool; An execution unit, used to execute multiple transactions in the transaction execution block and obtain an execution result of each transaction; A first determining unit, configured to determine an execution timeout transaction from a plurality of transactions based on the execution result; A packaging unit, used for packaging the transaction execution block into an initial proposal; An adding unit, configured to add the transaction identifier of the timed-out transaction and the contract method called by the timed-out transaction to the initial proposal to obtain a first target proposal; A sending unit is used to send the first target proposal to the slave node so that the slave node performs verification processing based on the first target proposal.

10. A timeout transaction processing device based on blockchain, characterized in that: Applicable to a slave node, the device comprises: A receiving unit, used to receive target proposals from the master node; A second determining unit, configured to determine, if the target proposal is a second target proposal, a frozen contract method transaction corresponding to the second target proposal; A determination unit, configured to determine whether the contract method state of the contract method corresponding to the frozen contract method transaction in the second local cache list is a to-be-triggered state; An updating unit is used to update the contract method status of the contract method corresponding to the frozen contract method transaction in the second local cache list to a consensus status if yes.

11. An electronic device, characterized in that: It includes a memory and a processor; the memory stores a computer program, and the processor is used to run the computer program in the memory to execute the steps in the blockchain-based timeout transaction processing method as described in any one of claims 1 to 8.

12. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, which is suitable for loading by a processor to execute the steps in the blockchain-based timeout transaction processing method according to any one of claims 1 to 8.

13. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps in the blockchain-based timeout transaction processing method described in any one of claims 1 to 8 are implemented.

Images