A transaction processing method for blockchain network and blockchain network

Abstract

The embodiment of the present invention discloses a transaction processing method of a blockchain network and a blockchain network. The method includes: after a transaction request is verified, a block is generated according to the transaction request and sent to an accounting node in the blockchain network, and the accounting node performs re-verification to verify whether the object associated with the transaction request satisfies the transaction request, and if the object associated with the transaction request satisfies the transaction request, the object associated with the transaction request is locked; if the transaction conditions of the transaction request are met, the transaction indicated by the transaction request is executed, so that the reliability and security of transactions in the blockchain network can be greatly improved, and the transaction can be ensured to be executed smoothly.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a transaction processing method for a blockchain network and a blockchain network. Background Art

[0002] In the related technology, delayed transactions can be achieved through blockchain technology. Generally, transaction requests are blocked in the transaction buffer pool or the flow of assets is locked and restricted until the transaction conditions are met, and then the transaction request is put on the chain for final processing. The reliability of these methods is poor. Since the transaction request is blocked in the buffer pool, there is a possibility of tampering, or it is easily affected by other factors, and ultimately it cannot ensure that the transaction can be successfully executed. For example, it is possible to lock a transaction that cannot be submitted to the chain in the end. For example, in this scenario: Account A sends a delayed transfer request from Node 1, and during this period, a normal transfer request is sent from Node 2, which will destroy the conditions for request execution in Node 1; on the other hand, for the method of locking and restricting the flow of assets, since the locked assets still belong to the user in the end, it cannot ensure that the transaction can be successfully executed after unlocking.

[0003] Currently, no effective solution has been proposed to address the above-mentioned problem of poor reliability in transaction processing. Summary of the invention

[0004] The embodiment of the present invention provides a method to at least solve the technical problem of poor reliability of transaction processing.

[0005] According to one aspect of an embodiment of the present invention, a transaction processing method of a blockchain network is provided, comprising:

[0006] Receiving, through a first node in the blockchain network, a transaction request sent by a client, wherein the transaction request indicates a transaction condition;

[0007] If the transaction request passes the first verification, generating a block according to the transaction request and sending it to a bookkeeping node in the blockchain network;

[0008] performing a second verification on the transaction request through the accounting node, and locking the object associated with the transaction request if the transaction request passes the second verification, wherein the second verification is at least used to determine whether the object associated with the transaction request satisfies the transaction request, and determining that the transaction request passes the second verification if the object associated with the transaction request satisfies the transaction request;

[0009] When the transaction condition of the transaction request is met, the transaction indicated by the transaction request is executed.

[0010] According to another aspect of an embodiment of the present invention, a blockchain network is provided, including:

[0011] A first node is configured to receive a transaction request sent by a client, wherein the transaction request indicates a transaction condition;

[0012] A consensus node, configured to generate a block according to the transaction request and send it to a bookkeeping node in the blockchain network if the transaction request passes the first verification;

[0013] A bookkeeping node, configured to perform a second verification on the transaction request, and lock an object associated with the transaction request if the transaction request passes the second verification, wherein the second verification is at least used to determine whether the object associated with the transaction request satisfies the transaction request, and if the object associated with the transaction request satisfies the transaction request, determine that the transaction request passes the second verification; and further configured to execute the transaction indicated by the transaction request if the transaction conditions of the transaction request are met.

[0014] According to another aspect of an embodiment of the present invention, there is further provided a blockchain network, comprising a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to execute the transaction processing method through the computer program.

[0015] In an embodiment of the present invention, after a transaction request passes verification, a block is generated according to the transaction request and sent to a bookkeeping node in the blockchain network, and is verified again by the bookkeeping node to verify whether the object associated with the transaction request satisfies the transaction request. When it is determined that the object associated with the transaction request satisfies the transaction request, the object associated with the transaction request is locked; when the transaction conditions of the transaction request are met, the transaction indicated by the transaction request is executed. Therefore, the reliability and security of transactions in the blockchain network can be greatly improved, ensuring that the transaction can be executed smoothly. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0017] Figure 1 is a flowchart of a transaction processing method of a blockchain network according to an embodiment of the present invention;

[0018] Figure 2 is a schematic diagram of the structure of a blockchain network according to an embodiment of the present invention;

[0019] Figure 3is a flowchart of transaction processing according to an exemplary embodiment of the present invention;

[0020] Figure 4 is a flow chart of a method for preventing an account overdraft balance according to an exemplary embodiment of the present invention;

[0021] Figure 5 is a flow chart of a method for revoking an unexecuted transaction according to an exemplary embodiment of the present invention;

[0022] Figure 6 is a flow chart of a method for revoking an unexecuted transaction by a management node according to an exemplary embodiment of the present invention;

[0023] Figure 7 is a flow chart of a method for delaying transactions according to an exemplary embodiment of the present invention;

[0024] Figure 8 is a schematic diagram of a node cache delay transaction according to an example embodiment of the present invention;

[0025] Fig. 9 is a schematic diagram of recording transactions according to an exemplary embodiment of the present invention Figure 1 ;

[0026] Fig.10 is a schematic diagram of a client initiating a transfer transaction according to an exemplary embodiment of the present invention Figure 1 ;

[0027] Fig.11 is a schematic diagram of recording transactions according to an exemplary embodiment of the present invention Figure 2 ;

[0028] Fig.12 is a schematic diagram of a client initiating a transfer transaction according to an exemplary embodiment of the present invention Figure 2 ;

[0029] Fig.13 is a schematic diagram of a node not executing a transfer transaction according to an exemplary embodiment of the present invention;

[0030] Fig.14 is a schematic diagram of a client initiating a revocation transaction according to an exemplary embodiment of the present invention;

[0031] Fig.15 Schematic diagram of a ledger record revocation transaction according to an exemplary embodiment of the present invention Figure 1 ;

[0032] Fig.16 is a schematic diagram of a management node initiating a revocation transaction according to an exemplary embodiment of the present invention;

[0033] Fig.17Schematic diagram of a ledger record revocation transaction according to an exemplary embodiment of the present invention Figure 2 ;

[0034] Fig.18 is a block diagram of a network node according to an exemplary embodiment of the present invention;

[0035] Fig.19 is a structural block diagram of a delayed transaction management module according to an exemplary embodiment of the present invention. DETAILED DESCRIPTION

[0036] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0037] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0038] It should be noted that in the embodiment of the present invention, the blockchain is an encrypted, chained transaction storage structure formed by blocks. The header of each block can include the hash value of all transactions in the block, as well as the hash value of all transactions in the previous block, so as to achieve tamper-proof and anti-forgery of transactions in the block based on the hash value; the newly generated transaction is filled into the block and after the consensus of the nodes in the blockchain network, it will be appended to the end of the blockchain to form a chain growth. The blockchain network is a collection of a series of nodes that incorporate new blocks into the blockchain by consensus.

[0039] Consensus is a process in the blockchain network that is used to reach agreement on transactions in a block among multiple nodes involved. The agreed blocks will be appended to the end of the blockchain. Mechanisms for achieving consensus include Proof of Work (PoW), Proof of Stake (PoS), Delegated Proof-of-Stake (DPoS), Proof of Elapsed Time (PoET), etc.

[0040] The "transaction request" in this embodiment is also called "transaction", which is equivalent to the computer term transaction. The transaction includes the operations that need to be submitted to the blockchain network for execution, as well as the corresponding transaction results. It does not refer only to transactions in the business context. In view of the conventional use of the term "transaction" in blockchain technology, the embodiment of the present invention follows this convention. For example, transactions may include deployment transactions and call transactions. Deployment transactions are used to deploy smart contracts to nodes in the blockchain network and prepare them to be called; call transactions are used to query operations (i.e., read operations) or update operations (i.e., write operations, including addition, deletion, and modification) on the status database in the ledger.

[0041] This embodiment provides a transaction processing method for a blockchain network. Figure 1 is a flow chart of a transaction processing method of a blockchain network according to an embodiment of the present invention. Figure 1 As shown, including:

[0042] Step S101, receiving a transaction request sent by a client through a first node in the blockchain network, wherein the transaction request indicates a transaction condition;

[0043] Step S103, when the transaction request passes the first verification, generating a block according to the transaction request and sending it to the accounting node in the blockchain network;

[0044] Step S105, performing a second verification on the transaction request through the accounting node, and if the transaction request passes the second verification, locking the object associated with the transaction request, wherein the second verification is at least used to determine whether the object associated with the transaction request satisfies the transaction request, and if the object associated with the transaction request satisfies the transaction request, determining that the transaction request passes the second verification;

[0045] Step S107: When the transaction conditions of the transaction request are met, execute the transaction indicated by the transaction request.

[0046] Through the above steps, after the transaction request is verified, a block is generated according to the transaction request and sent to the accounting node in the blockchain network, and is verified again by the accounting node to verify whether the object associated with the transaction request satisfies the transaction request. When it is verified that the object associated with the transaction request satisfies the transaction request, the object associated with the transaction request is locked; when the transaction conditions of the transaction request are met, the transaction indicated by the transaction request is executed. Therefore, the reliability and security of transactions in the blockchain network can be greatly improved, ensuring that the transaction can be executed smoothly.

[0047] In an exemplary embodiment, the "transaction condition" in this embodiment may refer to a condition that can trigger the execution of a transaction, or in other words, a transaction that satisfies the transaction condition can be executed. In an exemplary embodiment, the transaction condition includes: an execution time condition of the transaction, such as a specified transaction execution time (such as a specified time point or time period or time range).

[0048] In an exemplary embodiment, the accounting nodes in this embodiment may be all nodes in the blockchain network, or all nodes in the blockchain network except the management node.

[0049] In an exemplary embodiment, whether the object associated with the transaction request satisfies the transaction request may refer to whether the object associated with the transaction request meets the requirements of the transaction request. The object satisfies the transaction request, which may indicate that the transaction request can be successfully executed, but it is still necessary to wait for the transaction conditions to be met to determine whether to execute the transaction request.

[0050] In an exemplary implementation, the object associated with a transaction request may be an element that determines whether the transaction corresponding to the transaction request can be established. Without these elements, the transaction cannot be established logically. Taking a fund transaction as an example, a fund transaction must at least have a fund provider, a fund recipient, and a fund amount. Then the fund provider, the fund recipient, and the fund amount are the elements of the transaction. In this embodiment, taking a fund transaction as an example, the object associated with a transaction request may be the account of the fund provider, or the amount of funds to be traded in the fund provider's account.

[0051] It should also be noted that, in an exemplary embodiment, the "verification" in this embodiment, unless otherwise specified, may be a verification process in a blockchain network in the related technology, the purpose of which is to determine whether the information is accurate and complete.

[0052] In an exemplary implementation, in this embodiment, the above-mentioned terminal device can be a terminal device configured with a target client, which can include but is not limited to at least one of the following: a mobile phone (such as an Android phone, an iOS phone, etc.), a laptop, a tablet computer, a PDA, a MID (Mobile Internet Devices, mobile Internet devices), a PAD, a desktop computer, a smart TV, etc. The target client can be a video client, an instant messaging client, a browser client, an education client, etc. The above-mentioned network can include but is not limited to: a wired network, a wireless network, wherein the wired network includes: a local area network, a metropolitan area network and a wide area network, and the wireless network includes: Bluetooth, WIFI and other networks that realize wireless communication. The above-mentioned server can be a single server, or it can be a server cluster composed of multiple servers, or a cloud server. The above is only an example, and no limitation is made to this in this embodiment.

[0053] In an exemplary embodiment, before executing the transaction indicated by the transaction request, the method also includes: obtaining the latest block in the blockchain network through the accounting node; determining whether the specified information indicated in the latest block in the blockchain network satisfies the transaction condition; and determining that the transaction condition of the transaction request has been met if the specified information satisfies the transaction condition.

[0054] It should be noted that the "specified information" in this embodiment may be information related to the transaction conditions, and whether the transaction conditions are met can be determined through the specified information. When the transaction conditions are time-related, the specified information may be a timestamp.

[0055] In an exemplary embodiment, before executing the transaction indicated by the transaction request, the method also includes: receiving a transaction cancellation request sent by the client through a first accounting node among the accounting nodes; performing a third verification on the transaction cancellation request through the first accounting node, and if the transaction cancellation request passes the third verification, generating a block according to the transaction cancellation request and sending it to the accounting node; performing a fourth verification on the transaction cancellation request through the accounting node, and if the transaction cancellation request passes the fourth verification, canceling the transaction request, wherein the fourth verification is at least used to determine whether the transaction cancellation request has the cancellation authority, and if the transaction cancellation request has the cancellation authority, determining that the transaction cancellation request passes the fourth verification.

[0056] In an exemplary embodiment, before executing the transaction indicated by the transaction request, the method includes: receiving, through the management node in the blockchain network, a transaction revocation request to be signed sent by the second accounting node in the accounting node, wherein the transaction revocation request to be signed is verified by the management node, and if the transaction revocation request to be signed passes the verification, the transaction revocation request to be signed is signed by the management node; a block is generated according to the signed transaction revocation request, and sent to the accounting node; a fifth verification is performed on the signed transaction revocation request by the accounting node, and if the transaction revocation request after the signature passes the fifth verification, the transaction request is revoked, wherein the fifth verification is at least used to determine whether the transaction revocation request after the signature has revocation authority, and if the transaction revocation request has revocation authority, it is determined that the transaction revocation request passes the fifth verification.

[0057] In an exemplary embodiment, before the management node receives the transaction revocation request to be signed sent by the second accounting node among the accounting nodes, the method further includes: receiving a revocation instruction and permission information sent by the client through the second accounting node among the accounting nodes, wherein the revocation instruction is used to indicate the revocation of the transaction request, and the permission information is used to indicate the permission to revoke the transaction request; and sending the transaction revocation request to be signed to the management node in the blockchain network through the second accounting node, wherein the transaction revocation request to be signed is issued by the second accounting node when the permission information is verified.

[0058] In an exemplary embodiment, the revoking the transaction request includes: unlocking a locked object associated with the transaction request; and clearing the transaction request.

[0059] In an exemplary embodiment, when the transaction request is a funds transfer transaction request, the transaction request, in addition to indicating the transaction conditions, also indicates the following information: transaction identification, payer information, payer account information, payee information, payee account information, transfer amount information, transaction summary and transaction signature.

[0060] This embodiment also provides a blockchain network. Figure 2 is a schematic diagram of the structure of a blockchain network according to an embodiment of the present invention. Figure 2 As shown, including:

[0061] The first node 22 is used to receive a transaction request sent by a client, wherein the transaction request indicates a transaction condition;

[0062] The consensus node 24 is used to generate a block according to the transaction request and send it to the accounting node in the blockchain network if the transaction request passes the first verification;

[0063] The accounting node 26 is used to perform a second verification on the transaction request. If the transaction request passes the second verification, the object associated with the transaction request is locked, wherein the second verification is at least used to determine whether the object associated with the transaction request satisfies the transaction request. If the object associated with the transaction request satisfies the transaction request, it is determined that the transaction request passes the second verification; and is also used to execute the transaction indicated by the transaction request if the transaction conditions of the transaction request are met.

[0064] Through the above steps, after the transaction request is verified, a block is generated according to the transaction request and sent to the accounting node in the blockchain network, and is verified again by the accounting node to verify whether the object associated with the transaction request satisfies the transaction request. When it is verified that the object associated with the transaction request satisfies the transaction request, the object associated with the transaction request is locked; when the transaction conditions of the transaction request are met, the transaction indicated by the transaction request is executed. Therefore, the reliability and security of transactions in the blockchain network can be greatly improved, ensuring that the transaction can be executed smoothly.

[0065] It should also be noted that the nodes of the blockchain network in this embodiment can also execute any of the methods described in the above method embodiments, and any of the methods described in the above embodiments can also be applied to this embodiment, which will not be repeated here.

[0066] Example Implementations

[0067] The following uses fund transactions as an example to further explain the embodiments of the present invention. The technical solution involved in this embodiment can be applied to the fields of financial technology (Fintech) and blockchain (Blockchain). This embodiment can implement optional transactions with delayed execution functions on the blockchain. Among them, illustratively, transactions with delayed attributes will be executed in the form of transactions, first on the chain and then on the blockchain.

[0068] In an example implementation, a delayed transaction may be revoked before it is executed.

[0069] In one example implementation, if a user's private key is lost, a revocation transaction may be initiated by its administrator.

[0070] In one example implementation, nodes in a blockchain network have independent management modules for delayed transactions, including independent physical storage.

[0071] In an implementation of an example, the earliest transaction time is set for the transaction by means of a timestamp, thereby achieving the function of delaying the transaction.

[0072] In one example implementation, delayed transactions are put on the chain, and then all nodes lock the corresponding assets according to the transactions on the chain.

[0073] In an example implementation, after the corresponding assets are locked, the normal behavior of the account is not affected.

[0074] In an example implementation, if the transaction is not revoked, the transaction will eventually be confirmed when the timestamp of the new block exceeds the earliest transaction time.

[0075] In an implementation of an example, two transaction revocation methods are designed. One is that the user revokes the transaction within the valid time; the other is that the administrator corresponding to the user initiates the transaction revocation, that is, the node that issues the certificate to the user.

[0076] In one example implementation, the fields of the transaction (fused into the payload).

[0077] Payload: used to indicate the specific content of the transaction (the encoding of the transaction content). After parsing the payload, the payload contains a new field first_execute_time, which indicates the earliest time when the transaction can be executed. If the first_execute_time field has no value, it means that the transaction is executed immediately. Other contents in the payload may also include: transaction id (used to uniquely identify a transaction), content, summary, etc.

[0078] Signature: The signature is the signature of the payload. All transactions must verify the legitimacy of the signature before parsing the payload.

[0079] In an implementation example, the entire blockchain system sets a maximum allowed delay time, i.e., the maximum delay time for a transaction. In this way, the overall system performance can be further optimized in terms of execution, cleanup, etc.

[0080] Figure 3 is a flow chart of transaction processing according to an exemplary embodiment of the present invention. Figure 3 As shown, in this embodiment, the transaction processing process includes: the client initiates a transaction to a node in the blockchain network, and the node performs a transaction legitimacy check. After the check passes, it is uploaded to the chain through consensus.

[0081] The process of verifying the legitimacy of the transaction by the node is as follows:

[0082] Verifying the legitimacy of a transaction includes: verifying the signature and verifying the transaction content.

[0083] Among them, verify whether the signature is legal. If it is not legal, prompt that the transaction is invalid and return a prompt message to the client; if it is legal, continue to verify the transaction content; among them, verify the legality of the executed transaction content (for example, whether the account balance to be traded is sufficient, whether the transfer limit is met, etc.). If it is legal, cache the delayed transaction and lock the assets corresponding to the account. If the transaction content is legal, a receipt will be returned to the client; if the verified transaction content is illegal, return a failure message to the client;

[0084] After verifying that the transaction content is legal, it is packaged through a consensus mechanism, and the nodes in the blockchain network receive a new block. If the timestamp of the new block exceeds the content of the corresponding field of the transaction (such as the earliest time when the transaction can be executed), the corresponding assets are unlocked, the transaction is executed, and the database is updated; after that, the execution result can be returned to the client.

[0085] It should be noted that, considering that it takes time for transactions to be processed in the blockchain system, the delay parameters in the system are somewhat different from the delay parameters seen by the client. Usually, the delay parameters of the system should be broader to increase the robustness of the system. For example, if the client sees a transaction delay of one day, the first_execute_time field of the transaction in the system can be more than one day, for example, it can be 25 hours.

[0086] This embodiment also provides a method for preventing an account from overdrawing its balance. Figure 4 is a flow chart of a method for preventing an account overdraft balance according to an exemplary embodiment of the present invention, such as Figure 4 As shown, the steps included are as follows:

[0087] The client initiates a transaction to a node in the blockchain network, and the node verifies the transaction before uploading it to the chain; checks whether the balance corresponding to the transaction (the part that is not locked) meets the conditions; if not, it is determined to be an illegal transaction, and the reason for the transaction failure is sent to the client; if it is satisfied, the subsequent process continues.

[0088] It should be noted that if a node maliciously sends illegal messages, it will not pass the legitimacy detection of other nodes.

[0089] This embodiment also provides a method for revoking an unexecuted transaction. Figure 5 is a flow chart of a method for revoking an unexecuted transaction according to an exemplary embodiment of the present invention, such as Figure 5 As shown, the steps included are as follows:

[0090] The revocation of unexecuted transactions can be initiated by the user through the client. The client sends a revocation request to the node in the blockchain network. The revocation request includes the original transaction itself, the revocation identifier, and the signature of the requested transaction. The node verifies the legitimacy of the transaction requested by the client and verifies whether the current user can revoke it (i.e., verifies whether the current user has the revocation authority). If not, a failure message is returned to the client. If yes, verification continues.

[0091] Continue to verify whether the original transaction has been completed. If so, prompt that the original transaction has been completed, and return the prompt information to the client; exemplary, by searching for the transaction by index in the ledger, and verifying the transaction timestamp and the current system time; if the revoked transaction passes the verification, it is uploaded to the chain after consensus, and exemplary, the revoked transaction can be packaged first;

[0092] To cancel a transaction, you need to do the following: clear the corresponding delayed transactions, unlock the corresponding assets, and record the cancellation results in the ledger. After canceling the transaction, respond to the client and the transaction is successfully canceled.

[0093] This embodiment also provides a method for canceling unexecuted transactions through a management node. Figure 6 is a flow chart of a method for revoking an unexecuted transaction by a management node according to an exemplary embodiment of the present invention, such as Figure 6 As shown, the steps included are as follows:

[0094] If the user loses the private key, he can obtain the node's calling authority through other methods, and send the generated request from a node in the blockchain network to the management node (the request is not signed by the user); the node verifies the legitimacy of the requested transaction: for example, verify whether the original transaction has been completed. If so, it prompts that the original transaction has been completed and returns the prompt information to the node; the transaction can be searched by index in the ledger, and the transaction timestamp and the current system time can be verified at the same time;

[0095] The node sends the verified revocation transaction to the management node;

[0096] The management node verifies the legitimacy of the revoked transaction. After confirming the legitimacy, it signs with its own private key to form a new complete transaction, which is then uploaded to the chain after consensus.

[0097] For example, the management nodes in the consortium chain do not verify the legitimacy of transactions.

[0098] If the verification of the revocation transaction is successful, the corresponding delayed transaction (i.e. the transaction request mentioned above) is cleared, the corresponding assets are unlocked, and the revocation result is recorded in the ledger; the node can also be responded to and returned to the user, indicating that the transaction revocation is successful.

[0099] It should be noted that the qualification verification for users to call management nodes can be carried out by combining on-chain and off-chain methods.

[0100] This embodiment also provides a method for a newly connected node to update the ledger, which can be packaged through a consensus mechanism. The node receives a new block and verifies whether the timestamp of the new block exceeds the first_execute_time of the transaction. If the verification is passed, the corresponding assets are unlocked, historical transactions are executed, and the ledger information is updated; unexecuted delayed transactions are physically cached; if there is a revocation request, the delayed transaction is not executed, but the corresponding delayed transaction is cleared, the assets are unlocked, and the revocation result is recorded in the ledger; the new block timestamp triggers the unexecuted delayed transaction, which is first uploaded to the chain and then executed, and the ledger is updated.

[0101] In an implementation example, unexecuted transactions may also be uploaded to the chain first, thereby ensuring that the transactions are executed unless they are revoked.

[0102] Generally, the locking of assets on blockchain is based on the private key of the asset holder (such as UTXO), while this embodiment locks assets based on the management of the ledger by all nodes, thereby allowing partial asset locking of the account without affecting subsequent normal transactions of the account.

[0103] Figure 7 is a flow chart of a method for delaying transactions according to an exemplary embodiment of the present invention. Figure 7 As shown, in one example implementation, the process of delaying a funds transfer transaction is as follows:

[0104] The client initiates a delayed transaction 1 request to blockchain node 1;

[0105] Node 1 receives the client transaction request;

[0106] Node 1 verifies the legality of the transaction based on its own database (whether the balance is sufficient, whether the transfer limit is met, etc.). If it is illegal, an error message is returned to the client; if it is legal, a receipt is returned to the client.

[0107] The client verifies whether it has received the transaction receipt information. If not, it re-initiates the transaction. If it has, the transaction continues.

[0108] The transaction request is uploaded to the blockchain after consensus;

[0109] Each node receives the transaction request information sent by the client:

[0110] The transaction request information includes: specific content payload (such as transaction id, payer, payer's current account number, payee, payee's current account number, transfer amount, summary, the earliest time the transaction can be executed first_execute_time (if this field has no value, it means that the transaction is executed immediately)); signature signature;

[0111] For example:

[0112] {0103234445,zhangsan,6XXXXXXXXXXXX,lisi,6XXXXXXXXXXXX,10000.00,pay,current time delayed 25 hours,signature};

[0113] The information of the payee and payer may include name and identity information (such as ID number).

[0114] Each node obtains the payer's account status and the payee's account status, the payer's current balance, the payer's locked amount and other information from its own database to verify the transaction information:

[0115] Verify whether the signature is legal. If it is not legal, the transaction will not be executed, the ledger will record the transaction, and the transaction will end; if it is legal, the transaction will continue;

[0116] Verify whether the payer's account status and the payee's account status are tradable. If one of the account statuses is not tradable, the transaction will not be executed, the ledger will record the transaction, and the transaction will end; if both account statuses are tradable, the transaction will continue;

[0117] Verify whether the transfer amount is greater than 0.00 yuan. If not, the transaction will not be executed, the ledger will record the transaction, and the transaction will end; if yes, the transaction will continue;

[0118] The payee's current balance is RMB 100,000.00, the payee has locked an amount of RMB 0.00, and the available amount is RMB 100,000.00-0.00=RMB 100,000.00;

[0119] Determine whether the available amount meets the transfer amount:

[0120] Determine whether the available amount of 100,000.00 yuan is greater than the transfer amount of 10,000.00 yuan. If not, the transaction will not be executed, the account book will record the transaction, and the transaction will end; if yes, the transaction will continue;

[0121] Figure 8 is a schematic diagram of a node cache delay transaction according to an exemplary embodiment of the present invention, such as Figure 8As shown, each node caches delayed transaction 1 and locks 10,000.00 yuan of assets under the payer account 6XXXXXXXXXXXX;

[0122] Fig. 9 is a schematic diagram of recording transactions according to an exemplary embodiment of the present invention Figure 1 ,like Fig. 9 As shown, the node receives the new block through the consensus mechanism packaging, and determines whether the timestamp of the new block exceeds the first_execute_time of the transaction. If it exceeds, the 10,000.00 yuan under the payment account is unlocked, the transfer transaction is executed, the database is updated in the data storage module, and the ledger records this transaction;

[0123] Returns the client execution result.

[0124] The following further explains the embodiments of the present invention in combination with the scenarios of success and failure of subsequent transactions due to locking of some assets after submitting a delayed transaction. The following method uses the above results:

[0125] After executing delayed transaction 1 and normal transaction 3, the balance of the payer's account 6XXXXXXXXXXXX is 90,000.00 yuan. Since delayed transaction 2 locks an amount of 20,000.00 yuan, the available amount is 90,000.00-20,000.00=70,000.00 yuan;

[0126] Fig.10 is a schematic diagram of a client initiating a transfer transaction according to an exemplary embodiment of the present invention Figure 1 ,like Fig.10 As shown, a successful scenario of locking part of the assets:

[0127] The client initiates a transfer transaction 4 request to blockchain node 1, and the transfer amount is 30000.00;

[0128] Node 1 receives the client transaction request;

[0129] Node 1 verifies the legitimacy of the transaction (including signature and transaction content) based on its own database:

[0130] Determine whether the available amount meets the transfer amount: the available amount of 70,000.00 yuan is greater than the transfer amount of 30,000.00 yuan;

[0131] After verifying the legality of the transaction content, node 1 returns a receipt to the client;

[0132] The transaction request is uploaded to the blockchain through consensus to execute the transfer transaction;

[0133] The payer's account balance is 90000.00-30000.00=60000.00 yuan, the locked amount is still 20000.00 yuan, and the available amount is 60000.00-20000.00=40000.00 yuan.

[0134] Fig.11 is a schematic diagram of recording transactions according to an exemplary embodiment of the present invention Figure 2 ,like Fig.11 As shown, the database is updated in the data storage module, and the account book records the result of this transfer transaction;

[0135] Returns the client execution result.

[0136] Failure scenarios for locking some assets:

[0137] After executing transfer transaction 4, the balance of the payer's account 6XXXXXXXXXXXX is 60,000.00 yuan. Since delayed transaction 2 locks an amount of 20,000.00 yuan, the available amount is 60,000.00-20,000.00=40,000.00 yuan;

[0138] Fig.12 is a schematic diagram of a client initiating a transfer transaction according to an exemplary embodiment of the present invention Figure 2 ,like Fig.12 As shown, the client initiates a transfer transaction 5 request to blockchain node 2, and the transfer amount is 45,000.00 yuan;

[0139] Node 2 receives the client transaction request;

[0140] Node 2 verifies the legitimacy of the transaction (including signature and transaction content) based on its own database:

[0141] Determine whether the available amount meets the transfer amount:

[0142] The available amount of 40,000.00 yuan is less than the transfer amount of 45,000.00 yuan, so the verification fails;

[0143] Node 2 does not execute this transfer transaction; Fig.13 is a schematic diagram of a node not executing a transfer transaction according to an exemplary embodiment of the present invention, such as Fig.13 As shown, the transfer transaction 5 has not been recorded.

[0144] Return the failure reason to the client.

[0145] Return to the client that the transfer failed.

[0146] This embodiment also provides a method for a user to actively cancel a transaction, which is described below in conjunction with a specific scenario:

[0147] This case uses the above test results:

[0148] After executing transfer transaction 4, the balance of the payer's account 6XXXXXXXXXXXX is 60,000.00 yuan. Since delayed transaction 2 locks an amount of 20,000.00 yuan, the available amount is 60,000.00-20,000.00=40,000.00 yuan;

[0149] The transaction id of delayed transaction 2 is 0103234444.

[0150] Fig.14 is a schematic diagram of a client initiating a transaction cancellation according to an exemplary embodiment of the present invention. Fig.14 As shown, the client sends the cancellation transaction 6 that cancels the delayed transaction 2 to node 2;

[0151] The request information includes: new transaction id, transaction 2, revocation flag, signature; {0103213213, transaction 2, 1, signature};

[0152] Node 2 receives the client transaction request;

[0153] Node 2 verifies the legitimacy of the transaction (including signature and transaction content) based on its own database.

[0154] After verification, node 2 returns a receipt to the client;

[0155] The cancellation transaction 6 is uploaded to the chain after consensus;

[0156] Preferably, canceled transactions are packaged and produced first;

[0157] Each node verifies the legitimacy of this revocation transaction:

[0158] First, verify whether the current user has the authority to cancel the transaction. If not, the transaction will not be canceled; if yes, the transaction will continue.

[0159] According to the original transaction ID: 0103234444, the original transaction information and the original transaction status are obtained from the database, and it is determined whether the original transaction has been completed according to the original transaction status. If it has been completed, the cancellation transaction will not be executed; if not, the transaction will continue;

[0160] After the transaction legitimacy is verified, each node unlocks the corresponding assets, clears the delayed transaction 2 in the cache, and the ledger records this revoked transaction; Fig.15 Schematic diagram of a ledger record revocation transaction according to an exemplary embodiment of the present invention Figure 1 ,like Fig.15 As shown, the revocation transaction 6 (i.e., transaction 6 in the figure) is recorded;

[0161] The payer's account balance is 60,000.00 yuan, the locked amount is 0.00 yuan, and the available balance is 60,000.00 yuan; the execution result is returned to the client.

[0162] This embodiment also provides a method for a user to cancel a transaction through an administrator, which is described below in conjunction with a specific scenario:

[0163] This case uses the above test results:

[0164] After executing transfer transaction 4, the balance of the payer's account 6XXXXXXXXXXXX is 60,000.00 yuan. Since delayed transaction 2 locks an amount of 20,000.00 yuan, the available amount is 60,000.00-20,000.00=40,000.00 yuan;

[0165] The transaction id of delayed transaction 2 is 0103234444.

[0166] Since the user's private key is lost, the user shows his ID card to Node 3 offline to prove that he is the original initiator of delayed transaction 2;

[0167] Fig.16 is a schematic diagram of a management node initiating a revocation transaction according to an exemplary embodiment of the present invention, such as Fig.16 As shown, node 3 initiates the cancellation transaction 6 to cancel delayed transaction 2:

[0168] The request information includes: new transaction ID, transaction 2, and cancellation flag;

[0169] {0101231231, transaction2, 1};

[0170] Node 3 verifies the legitimacy of the requested transaction:

[0171] Node 3 obtains the original transaction information and status from its own node database according to the original transaction ID: 0103234444, and determines whether the original transaction has been completed according to the original transaction status. If so, it prompts that the original transaction has been completed and returns the prompt information to node 3; if not, the transaction continues;

[0172] The verified revocation transaction is sent to the management node;

[0173] The management node verifies the legitimacy of the transaction. After confirming the legitimacy, the management node signs with its own private key to form the final transaction 6, which is then uploaded to the chain through consensus;

[0174] Preferably, canceled transactions are packaged and produced first;

[0175] Each node verifies the legitimacy of this revocation transaction;

[0176] After the transaction legitimacy is verified, each node (including node 3) unlocks the corresponding assets of 20,000.00 yuan, clears the delayed transaction 2 in the cache, and the ledger records this revoked transaction; Fig.17 Schematic diagram of a ledger record revocation transaction according to an exemplary embodiment of the present invention Figure 2 ,like Fig.17 As shown, revocation transaction 6 (ie, transaction 6 in the figure) is recorded.

[0177] The payer's account balance is RMB 60,000.00, the locked amount is RMB 0.00, and the available balance is RMB 60,000.00.

[0178] Fig.18 is a block diagram of a network node according to an exemplary embodiment of the present invention. Fig.18 As shown, in this embodiment, the node device includes:

[0179] Communication module: The transaction initiator initiates a transaction request, and messages are exchanged through the communication module;

[0180] Authentication module: Verify the signatures of clients, nodes, and management nodes;

[0181] Consensus module: carries out the consensus process and generates blocks during the process;

[0182] Delayed transaction management module: independently manage delayed transactions.

[0183] Fig.19 is a block diagram of a delayed transaction management module according to an exemplary embodiment of the present invention. Fig.19 As shown, in this embodiment, the delayed transaction management module includes:

[0184] The physical cache module is mainly used to prevent node failures and the loss of uncompleted delayed transactions;

[0185] The account lock amount management module is a module that counts the account lock amount;

[0186] The cache transaction management module does not verify the legitimacy, manages transaction locking and cleanup, and manages two components: memory and cache.

[0187] It should be noted that, for the above-mentioned method embodiments, for the sake of simplicity, they are all described as a series of action combinations, but those skilled in the art should know that the present invention is not limited by the described action sequence, because according to the present invention, certain steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present invention.

[0188] According to another aspect of an embodiment of the present invention, a blockchain network for implementing the above transaction processing method is also provided. The blockchain network includes a memory and a processor, the memory stores a computer program, and the processor is configured to execute the steps in any of the above method embodiments through the computer program, which will not be repeated here.

[0189] Optionally, in this embodiment, the electronic device may be located in at least one network device among a plurality of network devices of a computer network.

[0190] In other embodiments, the node device, terminal device or server may be a node in a distributed system, wherein the distributed system may be a blockchain system, and the blockchain system may be a distributed system formed by connecting the multiple nodes in the form of network communication. Among them, the nodes may form a peer-to-peer (P2P, PeerToPeer) network, and any form of computing device, such as a server, terminal or other electronic device, may become a node in the blockchain system by joining the peer-to-peer network.

[0191] The serial numbers of the above embodiments of the present invention are only for description and do not represent the advantages or disadvantages of the embodiments.

[0192] If the integrated units in the above embodiments are implemented in the form of software functional units and sold or used as independent products, they can be stored in the above computer-readable storage medium. Based on such an understanding, the technical solution of the present invention, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling one or more computer devices (which can be personal computers, servers or network devices, etc.) to perform all or part of the steps of the methods described in various embodiments of the present invention.

[0193] In the above embodiments of the present invention, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0194] In the several embodiments provided in the present application, it should be understood that the disclosed client can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0195] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0196] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0197] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principle of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A transaction processing method for a blockchain network, characterized in that: include: Receiving, through a first node in the blockchain network, a transaction request sent by a client, wherein the transaction request indicates a transaction condition; If the transaction request passes the first verification, generating a block according to the transaction request and sending it to a bookkeeping node in the blockchain network; performing a second verification on the transaction request through the accounting node, and locking the object associated with the transaction request if the transaction request passes the second verification, wherein the second verification is at least used to determine whether the object associated with the transaction request satisfies the transaction request, and determining that the transaction request passes the second verification if the object associated with the transaction request satisfies the transaction request; If the transaction condition of the transaction request is met, executing the transaction indicated by the transaction request; Before executing the transaction indicated by the transaction request, the method further includes: Receiving, through a first accounting node among the accounting nodes, a transaction cancellation request sent by the client; Performing a third verification on the transaction cancellation request by the first accounting node, and if the transaction cancellation request passes the third verification, generating a block according to the transaction cancellation request and sending it to the accounting node; The accounting node performs a fourth verification on the transaction cancellation request, and if the transaction cancellation request passes the fourth verification, cancels the transaction request, wherein the fourth verification is at least used to determine whether the transaction cancellation request has cancellation authority, and if the transaction cancellation request has cancellation authority, determines that the transaction cancellation request passes the fourth verification; Before executing the transaction indicated by the transaction request, the method includes: Receiving, through the management node in the blockchain network, a transaction revocation request to be signed sent by a second accounting node in the accounting nodes, wherein the transaction revocation request to be signed is verified by the management node, and if the transaction revocation request to be signed passes the verification, the transaction revocation request to be signed is signed by the management node; Generate a block according to the signed transaction cancellation request and send it to the accounting node; The transaction revocation request after the signature is subjected to a fifth verification by the accounting node. If the transaction revocation request after the signature passes the fifth verification, the transaction request is revoked. The fifth verification is at least used to determine whether the transaction revocation request after the signature has revocation authority. If the transaction revocation request has revocation authority, it is determined that the transaction revocation request passes the fifth verification.

2. The method according to claim 1, characterized in that Before executing the transaction indicated by the transaction request, the method further includes: Obtain the latest block in the blockchain network through the accounting node; Determining whether the specified information indicated in the latest block in the blockchain network satisfies the transaction condition; In a case where the designated information satisfies the transaction condition, it is determined that the transaction condition of the transaction request has been satisfied.

3. The method according to claim 1, characterized in that Before the management node receives the transaction revocation request to be signed sent by the second accounting node among the accounting nodes, the method further includes: Receiving, through the second accounting node among the accounting nodes, a revocation instruction and permission information sent by the client, wherein the revocation instruction is used to indicate the revocation of the transaction request, and the permission information is used to indicate the authority to revoke the transaction request; The transaction revocation request to be signed is sent to the management node in the blockchain network through the second accounting node, wherein the transaction revocation request to be signed is issued by the second accounting node when the authority information is verified.

4. The method according to claim 3, characterized in that The cancelling the transaction request comprises: unlocking the locked object associated with the transaction request; and, Clear the transaction request.

5. The method according to claim 1, characterized in that In the case where the transaction request is a fund transfer transaction request, the transaction request indicates the following information in addition to the transaction conditions: Transaction ID, payer information, payer account information, payee information, payee account information, transfer amount information, transaction summary and transaction signature.

6. The method according to claim 1 or 5, characterized in that: The transaction conditions include: execution time conditions of the transaction.

7. A blockchain network, characterized in that: include: A first node is configured to receive a transaction request sent by a client, wherein the transaction request indicates a transaction condition; A consensus node, configured to generate a block according to the transaction request and send it to a bookkeeping node in the blockchain network if the transaction request passes the first verification; A bookkeeping node, configured to perform a second verification on the transaction request, and lock an object associated with the transaction request if the transaction request passes the second verification, wherein the second verification is at least used to determine whether the object associated with the transaction request satisfies the transaction request, and if the object associated with the transaction request satisfies the transaction request, determine that the transaction request passes the second verification; and further configured to execute the transaction indicated by the transaction request if the transaction conditions of the transaction request are met.

8. A blockchain network, comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to execute the method according to any one of claims 1 to 6 through the computer program.

Images