CN111915308A - Transaction processing method of blockchain network and blockchain network - Google Patents
Transaction processing method of blockchain network and blockchain network Download PDFInfo
- Publication number
- CN111915308A CN111915308A CN202010634877.1A CN202010634877A CN111915308A CN 111915308 A CN111915308 A CN 111915308A CN 202010634877 A CN202010634877 A CN 202010634877A CN 111915308 A CN111915308 A CN 111915308A
- Authority
- CN
- China
- Prior art keywords
- transaction
- request
- transaction request
- revocation
- node
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3825—Use of electronic signatures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4014—Identity check for transactions
Abstract
The embodiment of the invention discloses a transaction processing method of a block chain network and the block chain network. The method comprises the following steps: after the transaction request passes the verification, the transaction request generation block is sent to an accounting node in the block chain network according to the transaction request, the re-verification is carried out through the accounting node to verify whether an object associated with the transaction request meets the transaction request, and the object associated with the transaction request is locked under the condition that the object associated with the transaction request meets the transaction request; under the condition of meeting the transaction condition of the transaction request, the transaction indicated by the transaction request is executed, so that the reliability and the safety of the transaction in the block chain network can be greatly improved, and the transaction can be smoothly executed.
Description
Technical Field
The invention relates to the technical field of blockchain, in particular to a transaction processing method of a blockchain network and the blockchain network.
Background
In the related art, delayed transactions can be realized by a block chain technique. Generally, the transaction request is blocked in a transaction buffer pool or the flow of assets is limited in a locking way, and the transaction request is linked up to be finally processed after the transaction condition is reached. These approaches have poor reliability, because the transaction request is blocked in the buffer pool, there is a possibility of being tampered with, or easily affected by other factors, and it is finally not ensured that the transaction can be executed successfully, for example, there is a possibility that a transaction that cannot finally submit the uplink is locked, such as the following scenario: the account A sends a delayed transfer request from the node 1, and a normal transfer request from the node 2 in the period of time, the condition of requesting execution in the node 1 is damaged; on the other hand, for the way that locking restricts the flow of assets, it is not guaranteed that the transaction will be successfully executed after unlocking, as the final locked asset still belongs to the user.
In view of the above-mentioned problem of poor reliability of transaction processing, no effective solution has been proposed at present.
Disclosure of Invention
The embodiment of the invention provides a method for at least solving the technical problem of poor transaction processing reliability.
According to an aspect of an embodiment of the present invention, there is provided a transaction processing method for a blockchain network, including:
receiving a transaction request sent by a client through a first node in a blockchain network, wherein transaction conditions are indicated in the transaction request;
under the condition that the transaction request passes the first verification, generating a block according to the transaction request and sending the block to an accounting node in the block chain network;
performing a second verification on the transaction request through the accounting node, and locking an object associated with the transaction request if the transaction request passes the second verification, wherein the second verification is at least used for determining 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;
executing the transaction indicated by the transaction request if the transaction condition of the transaction request is satisfied.
According to another aspect of the embodiments of the present invention, there is also provided a blockchain network, including:
the system comprises a first node and a second node, wherein the first node is used for receiving a transaction request sent by a client, and transaction conditions are indicated in the transaction request;
the consensus node is used for generating a block according to the transaction request and sending the block to an accounting node in the block chain network under the condition that the transaction request passes the first verification;
a billing node for performing a second verification on the transaction request, and locking an object associated with the transaction request if the transaction request passes the second verification, wherein the second verification is at least used for determining 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; and is also used for executing the transaction indicated by the transaction request if the transaction condition of the transaction request is met.
According to another aspect of the embodiments of the present invention, there is also provided a blockchain network, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the transaction processing method through the computer program.
In the embodiment of the invention, after the transaction request is verified, the transaction request generation block is sent to an accounting node in a block chain network according to the transaction request, the block chain network is verified again through the accounting node to verify whether the object associated with the transaction request meets the transaction request, and the object associated with the transaction request is locked under the condition that the object associated with the transaction request meets the transaction request after verification; under the condition of meeting the transaction condition of the transaction request, the transaction indicated by the transaction request is executed, so that the reliability and the safety of the transaction in the block chain network can be greatly improved, and the transaction can be smoothly executed.
Drawings
The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the invention and together with the description serve to explain the invention without limiting the invention. In the drawings:
fig. 1 is a flow diagram of a transaction processing method of a blockchain network according to an embodiment of the present invention;
fig. 2 is a schematic structural diagram of a blockchain network according to an embodiment of the present invention;
FIG. 3 is a schematic flow diagram of transaction processing according to an example embodiment of the invention;
FIG. 4 is a schematic flow diagram of a method of preventing an account from overdrawing a balance in accordance with an example embodiment of the invention;
FIG. 5 is a flow diagram of a method of revoking unexecuted transactions, according to an example embodiment of the present invention;
FIG. 6 is a flowchart illustration of a method of revoking unexecuted transactions by a management node according to an example embodiment of the present invention;
FIG. 7 is a flow diagram of a method of delaying a transaction according to an example embodiment of the invention;
FIG. 8 is a schematic diagram of node cache deferred transactions, according to an example embodiment of the present invention;
FIG. 9 is a first schematic diagram of recording a transaction according to an example embodiment of the invention;
FIG. 10 is a diagram one of a client initiating a transfer transaction in accordance with an example embodiment of the present invention;
FIG. 11 is a second schematic diagram of a record transaction according to an example embodiment of the invention;
FIG. 12 is a diagram two of a client initiating a transfer transaction in accordance with an example embodiment of the present invention;
FIG. 13 is a schematic diagram of a node not performing a transfer transaction in accordance with an example embodiment of the present invention;
FIG. 14 is a schematic diagram of a client initiating an undo transaction in accordance with an example embodiment of the present invention;
FIG. 15 is a first schematic diagram of a ledger record reversal transaction, according to an example embodiment of the present invention;
FIG. 16 is a schematic diagram of a management node initiating a revocation transaction according to an example embodiment of the present invention;
fig. 17 is a second schematic diagram of a ledger record reversal transaction, according to an example embodiment of the present invention;
FIG. 18 is a block diagram of a network node according to an example embodiment of the present invention;
fig. 19 is a block diagram of a delayed transaction management module according to an example embodiment of the invention.
Detailed Description
In order to make the technical solutions of the present invention better understood, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
It should be noted that the terms "first," "second," and the like in the description and claims of the present invention and in the drawings described above are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the invention described herein are capable of operation in sequences other than those illustrated or described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.
In the embodiment of the present invention, the Block chain (Blockchain) is a storage structure of encrypted and chained transactions formed by blocks (blocks). The header of each block can comprise the hash values of all transactions in the block and also comprises the hash values of all transactions in the previous block, so that the falsification and forgery prevention of the transactions in the block are realized on the basis of the hash values; newly generated transactions, after being filled into the tiles and passing through the consensus of nodes in the blockchain network, are appended to the end of the blockchain to form a chain growth. A blockchain network (blockchain network) incorporates new blocks into a set of nodes of a blockchain in a consensus manner.
Consensus (Consensus), a process in a blockchain network, is used to agree on a transaction in a block between the nodes involved, the agreed block to be appended to the end of the blockchain. The mechanisms for realizing consensus include workload proofs (PoW), rights proofs (PoS), shares proof of authority (DPoS), elapsed time proofs (PoET), and the like.
The "Transaction request" in this embodiment, also referred to as "Transaction", is equivalent to the term Transaction (Transaction) of a computer, and the Transaction includes an operation to be submitted to the blockchain network for execution and a corresponding Transaction result. Rather than simply referring to transactions in the business context, embodiments of the present invention follow this convention in view of the convention colloquially employed in blockchain technology for the term "transaction". For example, the transactions may include a Deploy (Deploy) transaction for deploying smart contracts into nodes of the blockchain network and ready to be invoked and a call (Invoke) transaction; the Invoke (Invoke) transaction is used to perform a query operation (i.e., a read operation) or an update operation (i.e., a write operation, including additions, deletions, and modifications) on the state database in the ledger.
The present embodiment provides a transaction processing method for a blockchain network, and fig. 1 is a flowchart of a transaction processing method for a blockchain network according to an embodiment of the present invention, as shown in fig. 1, including:
step S101, receiving a transaction request sent by a client through a first node in a block chain network, wherein the transaction request indicates transaction conditions;
step S103, generating a block according to the transaction request and sending the block to an accounting node in the block chain network under the condition that the transaction request passes the first verification;
step S105, performing second verification on the transaction request through the accounting node, and locking an object associated with the transaction request if the transaction request passes the second verification, wherein the second verification is at least used for determining 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;
step S107, in case the transaction condition of the transaction request is satisfied, executing the transaction indicated by the transaction request.
Through the steps, after the transaction request is verified, the transaction request generation block is sent to the accounting node in the block chain network according to the transaction request, the accounting node is used for verifying again to verify whether the object associated with the transaction request meets the transaction request, and the object associated with the transaction request is locked under the condition that the object associated with the transaction request meets the transaction request; under the condition of meeting the transaction condition of the transaction request, the transaction indicated by the transaction request is executed, so that the reliability and the safety of the transaction in the block chain network can be greatly improved, and the transaction can be smoothly executed.
In an exemplary embodiment, the "transaction condition" in the present embodiment may refer to a condition that can trigger a transaction to be executed, or a transaction satisfying the transaction condition may be executed. In an exemplary embodiment, the transaction condition includes: an execution time condition for the transaction, such as a specified transaction execution time (e.g., a specified point in time or time period or time range).
In an exemplary embodiment, the accounting node in this embodiment may be all nodes in the blockchain network, or all nodes except the management node in the blockchain network.
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 satisfaction of the transaction request by the object may indicate that the transaction request can be successfully executed, but may also require waiting for a transaction condition to be fulfilled to determine whether to execute the transaction request.
In an exemplary embodiment, the object associated with the transaction request may be an element that determines whether the transaction corresponding to the transaction request can be established, and absent such elements, the transaction is logically not established. Taking a fund transaction as an example, a fund transaction is established, which at least needs to have a fund provider, a fund acceptor and a fund amount. The funds provider, the funds recipient, and the amount of funds are the elements for which the transaction is established. In this embodiment, taking a fund transaction as an example, the object associated with the transaction request may be an account of a fund provider, or may be an amount of fund to be transacted in the account of the fund provider.
It should be further noted that, in an exemplary embodiment, the "verification" in this embodiment may be, without special supplementary description, a verification process in a blockchain network in the related art, in order to determine whether information is accurate and perfect.
In an exemplary embodiment, in this embodiment, the terminal device may be a terminal device configured with a target client, and may include, but is not limited to, at least one of the following: mobile phones (such as Android phones, iOS phones, etc.), notebook computers, tablet computers, palm computers, MID (mobile internet devices), PADs, desktop computers, smart televisions, etc. The target client may be a video client, an instant messaging client, a browser client, an educational client, etc. Such networks may include, but are not limited to: a wired network, a wireless network, wherein the wired network comprises: a local area network, a metropolitan area network, and a wide area network, the wireless network comprising: bluetooth, WIFI, and other networks that enable wireless communication. The server may be a single server, a server cluster composed of a plurality of servers, or a cloud server. The above is merely an example, and this is not limited in this embodiment.
In an exemplary embodiment, prior to the executing the transaction indicated by the transaction request, the method further comprises: obtaining a latest block in the block chain 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 specifying information satisfies the transaction condition, it is determined that the transaction condition of the transaction request has been satisfied.
It should be noted that the "specifying information" in the present embodiment may be information related to the transaction condition, and whether the transaction condition is fulfilled or not can be determined by the specifying information. When the transaction condition is time-related content, the specified information may be a time stamp.
In an exemplary embodiment, prior to the executing the transaction indicated by the transaction request, the method further comprises: receiving a transaction revocation request sent by the client through a first accounting node in the accounting nodes; performing third verification on the transaction revocation request through the first accounting node, and generating a block according to the transaction revocation request and sending the block to the accounting node under the condition that the transaction revocation request passes the third verification; and performing fourth authentication on the transaction revocation request through the accounting node, and in the case that the transaction revocation request passes the fourth authentication, revoking the transaction request, wherein the fourth authentication is at least used for determining whether the transaction revocation request has revocation authority, and in the case that the transaction revocation request has the revocation authority, determining that the transaction revocation request passes the fourth authentication.
In an exemplary embodiment, prior to the executing the transaction indicated by the transaction request, the method includes: receiving a transaction revocation request to be signed, which is sent by a second accounting node in the accounting nodes, through a management node in the block chain network, wherein the transaction revocation request to be signed is verified through the management node, and the transaction revocation request to be signed is signed through the management node under the condition that the transaction revocation request to be signed is verified; generating a block according to the signed transaction revocation request, and sending the block to the accounting node; and performing fifth verification on the transaction revocation request after the signature through the accounting node, and in the case that the transaction revocation request after the signature passes the fifth verification, revoking the transaction request, wherein the fifth verification is at least used for determining whether the transaction revocation request after the signature has a revocation authority, and in the case that the transaction revocation request has the revocation authority, determining that the transaction revocation request passes the fifth verification.
In an exemplary embodiment, before the receiving, by the management node, a transaction revocation request to be signed sent by a second one of the billing nodes, the method further comprises: receiving, by the second accounting node in the accounting nodes, a revocation indication and permission information sent by the client, wherein the revocation indication is used for indicating that the transaction request is revoked, and the permission information is used for indicating that the client has permission to revoke the transaction request; and sending the to-be-signed revocation transaction request to the management node in the blockchain network through the second accounting node, wherein the to-be-signed revocation transaction request is sent by the second accounting node under the condition that the authority information is verified.
In an exemplary embodiment, the revoking the transaction request includes: unlocking the locked object associated with the transaction request; and clearing the transaction request.
In an exemplary embodiment, where the transaction request is a funds transfer transaction request, the transaction request indicates, in addition to the transaction conditions, the following information: transaction identification, payer information, payer account information, payee account information, transfer amount information, a transaction summary, and a transaction signature.
Fig. 2 is a schematic structural diagram of a block chain network according to an embodiment of the present invention, and as shown in fig. 2, the block chain network includes:
the first node 22 is used for receiving a transaction request sent by a client, wherein the transaction request indicates transaction conditions;
the consensus node 24 is used for generating a block according to the transaction request and sending the block to the accounting node in the block chain network under the condition that the transaction request passes the first verification;
a billing node 26 for performing a second validation of the transaction request, locking an object associated with the transaction request in case the transaction request passes the second validation, wherein the second validation is at least for determining whether the object associated with the transaction request satisfies the transaction request, and in case the object associated with the transaction request satisfies the transaction request, determining that the transaction request passes the second validation; and is also used for executing the transaction indicated by the transaction request under the condition that the transaction condition of the transaction request is met.
Through the steps, after the transaction request is verified, the transaction request generation block is sent to the accounting node in the block chain network according to the transaction request, the accounting node is used for verifying again to verify whether the object associated with the transaction request meets the transaction request, and the object associated with the transaction request is locked under the condition that the object associated with the transaction request meets the transaction request; under the condition of meeting the transaction condition of the transaction request, the transaction indicated by the transaction request is executed, so that the reliability and the safety of the transaction in the block chain network can be greatly improved, and the transaction can be smoothly executed.
It should be further noted that, a node of the blockchain network in this embodiment may further execute the method described in any of the above method embodiments, and any method described in the above embodiment may also be applied to this embodiment, which is not described herein again.
Example embodiments
The following further explains the embodiment of the present invention by taking fund transaction as an example. The technical scheme that this embodiment relates to can be applied to financial technology (Fintech) field and block chain (Blockchain) field. The present embodiment may implement an optional transaction with deferred execution functionality on the blockchain. In one example, transactions with delay attributes are executed in a transaction format, with uplink being performed first.
In one example implementation, the delayed transaction may be revoked before it is not executed.
In one example implementation, if the user's private key is lost, a revocation transaction may be initiated by its administrator.
In one example embodiment, a node in a blockchain network has an independent management module for deferred transactions, including independent physical storage.
In an example implementation mode, the earliest transaction time is set for the transaction in a time stamp mode, and therefore the transaction delay implementation function is achieved.
In one example implementation, delayed transactions are linked up, and all nodes lock the corresponding assets according to the linked up transactions.
In one example implementation, the normal behavior of the account is not affected after the corresponding asset is locked.
In one example embodiment, if the transaction is not undone, the transaction will be confirmed when the timestamp of the new chunk exceeds the earliest transaction time.
In one example implementation mode, two ways of canceling the transaction are designed, wherein one way is that the user cancels the transaction within the effective time; and secondly, the manager corresponding to the user initiates a revocation transaction, namely, the node issuing the certificate to the user initiates the revocation transaction.
In one example embodiment, the fields of the transaction (fused in the payload).
payload: the method is used for indicating the specific content of the transaction (encoding of the transaction content), and after the payload is analyzed, the payload contains a newly added field, i.e. first _ execute _ time, which represents the earliest time that the transaction can be executed, and if the field of the first _ execute _ time has no value, the transaction is immediately executed. Other content in payload may also include: transaction id (used to uniquely identify a transaction), content, summary, etc.;
signature (signature): signature is a signature on a payload, and all transactions verify the validity of the signature before parsing the payload.
In one example implementation, the entire blockchain system sets the maximum allowed delay time, i.e., the maximum delay time for a transaction. In this way, the overall performance of the system may be further optimized in terms of execution, cleaning, and the like.
Fig. 3 is a schematic flow chart of transaction processing according to an exemplary embodiment of the present invention, and as shown in fig. 3, in this embodiment, the flow chart of transaction processing includes: the client initiates a transaction to a node in the blockchain network, and the node performs transaction validity check and passes the common identification uplink after passing the check.
The process of verifying the transaction validity by the node is as follows:
verifying the validity of the transaction includes: verifying signature and verifying transaction content.
Verifying whether the signature is legal or not, if not, prompting that the transaction is invalid, and returning prompting information to the client; if the transaction content is legal, continuing to verify the transaction content; verifying the legality of transaction content (such as whether the balance of an account to be transacted is sufficient or not, whether a transfer amount is satisfied or not and the like), caching the delayed transaction and locking assets corresponding to the account if the transaction content is legal, and returning a receipt to a client if the transaction content is legal; if the transaction content is verified to be illegal, returning failure information to the client;
under the condition that the transaction content is verified to be legal, packaging is carried out through a consensus mechanism, a node in a block chain network receives a new block, and if the timestamp of the new block exceeds the content of a corresponding field of the transaction (for example, the earliest executable time of the transaction), the corresponding asset is unlocked, the transaction is executed, and the database is updated; thereafter, the client execution result may be returned.
It should be noted that, considering the time required for the transaction to be processed in the blockchain system, the delay parameter in the system has a certain discrepancy with the delay parameter seen by the client. Typically, the delay parameters of the system are broader to increase the robustness of the system. For example, if the client sees the transaction delayed by one day, the first _ execute _ time field of the transaction in the system may be more than one day, for example, 25 hours.
This embodiment also provides a method for preventing account overdraft balance, and fig. 4 is a flowchart illustrating the method for preventing account overdraft balance according to an exemplary embodiment of the present invention, as shown in fig. 4, including the following steps:
the client initiates a transaction to a node in the blockchain network, and the transaction is verified before the node is linked; checking whether a balance (unlocked part) corresponding to the transaction meets a condition; if the transaction is not satisfied, judging that the transaction is illegal, and sending the reason of the transaction failure to the client; if yes, the subsequent flow is continuously executed.
It should be noted that if a node maliciously sends an illegal message, the node cannot pass the validity detection of other nodes.
This embodiment further provides a method for revoking an unexecuted transaction, and fig. 5 is a flowchart illustrating a method for revoking an unexecuted transaction according to an exemplary embodiment of the present invention, as shown in fig. 5, including the following steps:
the transaction that is not executed is cancelled by the user through the client, and the client sends a cancellation transaction request to the node in the blockchain network, wherein the cancellation transaction request comprises the original transaction, the cancellation identifier and the signature of the requested transaction; the node verifies the validity of the client request transaction; verifying whether the current user can be revoked (namely verifying whether the current user has revocation authority), and if not, returning failure information to the client; if yes, continuing to verify;
continuously verifying whether the original transaction is committed, if so, prompting that the original transaction is committed, and returning a prompting message to the client; illustratively, by searching for a transaction in an account book according to an index, a transaction timestamp and the current system time are checked at the same time; if the verified revocation transaction passes through the common identity uplink, the revocation transaction can be preferentially packaged, for example;
undoing the transaction requires performing the following operations: and clearing the corresponding delayed transaction, unlocking the corresponding asset, and recording the revocation result in the account book. After the transaction is cancelled, the transaction cancellation is successful in response to the client.
This embodiment further provides a method for revoking an unexecuted transaction by a management node, and fig. 6 is a flowchart illustrating a method for revoking an unexecuted transaction by a management node according to an exemplary embodiment of the present invention, as shown in fig. 6, including the following steps:
if the private key is lost, the user can obtain the calling authority of the node through other methods, and sends the generated request to the management node through one node in the block chain network (the request has no user signature); the node verifies the validity of the requested transaction: for example, whether the original transaction is committed or not is verified, if yes, the fact that the original transaction is committed is prompted, and prompt information is returned to the node; the transaction can be searched in the account book according to the index, and the transaction timestamp and the current system time are verified at the same time;
the node sends the revocation transaction passing the verification to a management node;
the management node checks the validity of the cancelled transaction, signs the cancelled transaction by using a private key of the management node after the validity is confirmed, forms a new complete transaction, and then carries out chain link by common identification;
illustratively, the management node in the federation chain does not verify the validity of the transaction.
If the revocation transaction is verified to be successful, clearing the corresponding delayed transaction (namely the transaction request), unlocking the corresponding asset, and recording the revocation result in an account book; the node may also respond and return to the user indicating that the transaction revocation was successful.
It should be noted that the qualification checking of the management node invoked by the user may be performed in a combined manner of an up-chain and a down-chain.
The embodiment also provides a mode for updating the account book by the new network access node, which can be packaged by a consensus mechanism, the node receives a new block, checks whether the timestamp of the new block exceeds the first _ execute _ time of the transaction, passes the check, unlocks corresponding assets, executes historical transaction and updates the information of the account book; physically caching unexecuted deferred transactions; if the revocation request exists, the delayed transaction is not executed, but the corresponding delayed transaction is cleared, the assets are unlocked, and the revocation result is recorded into the account book; and triggering the unexecuted delayed transaction by the timestamp of the new block, and updating the account book after the transaction is executed after the transaction is linked.
In one example embodiment, unexecuted transactions may also be linked first, thereby ensuring that transactions must be executed without being revoked.
Generally, the locking of assets on the block chain is based on the private key of the asset holder (for example, UTXO), and the embodiment is based on the asset locking of all nodes for the management of the ledger, thereby allowing partial asset locking of the account without affecting the subsequent normal transaction of the account.
FIG. 7 is a flow diagram of a method of deferring transactions, according to an example embodiment of the invention, as shown in FIG. 7, in one example embodiment, the flow of deferring funds-transfer transactions is as follows:
the client initiates a request of delayed transaction 1 to the block chain node point 1;
the node 1 receives a client transaction request;
the node 1 verifies the validity of the transaction (whether the balance is sufficient, whether the transfer amount is satisfied, etc.) according to the own database of the node 1, and if the balance is not sufficient, error information is returned to the client; if the answer is legal, returning a receipt to the client;
the client checks whether the transaction receipt information is received, if not, the transaction is reinitiated, and if so, the transaction is continued;
the transaction request is cochain;
each node receives the transaction request information sent by the client:
the transaction request information includes: specific content payload (e.g., transaction id, payer current account, payee current account, transfer amount, summary, time first _ execute _ time at which the transaction can be executed earliest (if this field has no value, it means that the transaction is executed immediately)); signature;
for example:
{0103234445, zhangsan,6 XXXXXXXXXXXXX, lisi,6XXXXXXXXXXX, 10000.00, pay, 25 hours after the current time delay, signature };
the payee and payer information may include name and identity information (e.g., identification number).
Each node obtains information such as the account state of a payer, the account state of a payee, the current balance of the payer, the locked amount of the payer and the like from the own database of the node to verify transaction information:
verifying whether the signature is legal or not, if not, not executing the transaction, recording the transaction by the account book, and ending the transaction; if it is legal, the transaction continues;
verifying whether the account state of the payer and the account state of the payee are in a tradable state, if the account state has an untreatable state, not executing the transaction, recording the transaction by the account book, and ending the transaction; if the account status is tradable, the transaction continues;
verifying whether the transfer amount is greater than 0.00 yuan, if not, not executing the transaction, recording the transaction by the account book, and ending the transaction; if so, the transaction continues;
the current balance of the payer is 100000.00 yuan, the locked amount of the payer is 0.00 yuan, and the available amount is 100000.00-0.00-100000.00 yuan;
judging whether the available amount meets the transfer amount:
judging whether the available amount 100000.00 Yuan is larger than the transfer amount 10000.00 Yuan, if not, not executing the transaction, recording the transaction by the account book, and ending the transaction; if so, the transaction continues;
FIG. 8 is a schematic diagram of a node caching deferred transactions, according to an example embodiment of the invention, as shown in FIG. 8, each node separately caching deferred transactions 1, locking 10000.00-ary assets under the payer account number 6 XXXXXXXXXXX;
fig. 9 is a first schematic diagram of recording a transaction according to an exemplary embodiment of the present invention, as shown in fig. 9, the transaction is recorded by a consensus mechanism, a node receives a new block, determines whether a timestamp of the new block exceeds first _ execute _ time of the transaction, if so, unlocks 10000.00 yuan under a payment account number, executes a transfer transaction, and updates a database in a data storage module, and an account book records the transaction;
and returning the execution result of the client.
The following further explains embodiments of the present invention in connection with scenarios where after a delayed transaction is submitted, the success and failure of subsequent transactions due to locking part of the assets, the following method follows the above results:
after the delayed transaction 1, normal transaction 3 is performed, the payer account 6XXXXXXXXXXXX balance is 90000.00 yen, since the delayed transaction 2 locks an amount of 20000.00 yen, the available amount is 90000.00-20000.00-70000.00 yen;
FIG. 10 is a diagram illustrating a client initiated transfer transaction, according to an example embodiment of the invention-the success scenario for locking partial assets, as shown in FIG. 10:
the client initiates a transfer transaction 4 request to the block chain link point 1, and the transfer amount is 30000.00;
the node 1 receives a client transaction request;
the node 1 verifies the transaction validity (including signature and transaction content) according to the own database of the node 1:
judging whether the available amount meets the transfer amount: the available amount of 70000.00 dollars is greater than the transfer amount of 30000.00 dollars;
after verifying that the transaction content is legal, the node 1 returns a receipt to the client;
the transaction request performs a transfer transaction via the common identity uplink;
the payer account balance is 90000.00-30000.00-60000.00 yuan, the lock amount is still 20000.00 yuan, and the available amount is 60000.00-20000.00-40000.00 yuan.
FIG. 11 is a second schematic diagram of a record transaction, as shown in FIG. 11, with the database updated at the data storage module and the ledger recording the results of the transfer transaction, according to an example embodiment of the present invention;
and returning the execution result of the client.
Failure scenario for locking partial assets:
after the transfer transaction 4 is performed, the payer account 6xxxxxxxxxx balance is 60000.00 dollars, with a locked amount of 20000.00 dollars due to the deferred transaction 2, with an available amount of 60000.00-20000.00 versus 40000.00 dollars;
FIG. 12 is a diagram two illustrating a client initiated transfer transaction, as shown in FIG. 12, with a request for a transfer transaction 5 to block link point 2 for a transfer amount of 45000.00 dollars, in accordance with an exemplary embodiment of the present invention;
the node 2 receives a client transaction request;
and the node 2 verifies the transaction validity (including signature and transaction content) according to the own database of the node 2:
judging whether the available amount meets the transfer amount:
the available amount of 40000.00 dollars is less than the transfer amount of 45000.00 dollars, so the verification is not passed;
node 2 does not perform this transfer transaction; FIG. 13 is a diagram illustrating a node not performing a transfer transaction, as in FIG. 13, the transfer transaction 5 is not billed, according to an example embodiment of the present invention.
And returning the failure reason to the client.
And returning the transfer failure of the client.
The embodiment also provides a method for a user to actively cancel a transaction, which is described below with reference to specific scenarios:
the above test results were followed for this case:
after the transfer transaction 4 is performed, the payer account 6xxxxxxxxxx balance is 60000.00 dollars, with a locked amount of 20000.00 dollars due to the deferred transaction 2, with an available amount of 60000.00-20000.00 versus 40000.00 dollars;
deferred transaction 2 transaction id is 0103234444.
Fig. 14 is a schematic diagram of a client initiating a revocation transaction according to an example embodiment of the present invention, as shown in fig. 14, the client sending a revocation transaction 6 to a node 2 that revokes a deferred transaction 2;
the request information comprises a new transaction id, transaction 2, a revocation identifier and a signature; {0103213213, trade 2, 1, signature };
the node 2 receives a client transaction request;
the node 2 verifies the transaction validity (including signature and transaction content) according to the own database of the node 2;
after the verification, the node 2 returns a receipt to the client;
the revocation transaction 6 is linked up by consensus;
preferably, the block is packed out by the undo transaction priority;
each node verifies the validity of the revocation transaction:
firstly, verifying whether the current user has the revocation transaction authority, if not, not executing the revocation transaction; if so, the transaction continues;
according to the original transaction id: 0103234444 obtaining original trade information and original trade state from database, judging whether the original trade has been committed according to the original trade state, if yes, not executing cancel trade; if not, the transaction continues;
after the transaction validity verification is passed, each node unlocks corresponding assets, the delayed transaction 2 in the cache is cleared, and the account book records the cancelled transaction; fig. 15 is a schematic illustration of a ledger record-reversal transaction, according to an example embodiment of the present invention, first, as shown in fig. 15, reversal transaction 6 (i.e., transaction 6 in the figure) is recorded;
the account balance of the payer is 60000.00 yuan, the locking amount is 0.00 yuan, and the available balance is 60000.00 yuan; and returning the execution result of the client.
The embodiment also provides a method for a user to cancel a transaction through a manager, which is described below with reference to specific scenarios:
the above test results were followed for this case:
after the transfer transaction 4 is performed, the payer account 6xxxxxxxxxx balance is 60000.00 dollars, with a locked amount of 20000.00 dollars due to the deferred transaction 2, with an available amount of 60000.00-20000.00 versus 40000.00 dollars;
deferred transaction 2 transaction id is 0103234444.
Because the private key of the user is lost, the user presents the identity card to the node 3 on line to prove that the identity card is the original delayed transaction 2 initiator;
fig. 16 is a schematic diagram of a management node initiating a revocation transaction according to an example embodiment of the present invention, and as shown in fig. 16, a revocation transaction 6 in which a node 3 initiates a revocation deferred transaction 2:
the request information comprises a new transaction id, transaction 2 and a revocation identifier;
{0101231231, trade 2, 1 };
node 3 verifies the legitimacy of the requested transaction:
node 3, according to the original transaction id: 0103234444 obtaining original transaction information and original transaction state from its own node database, judging whether the original transaction has been committed according to the original transaction state, if yes, prompting the original transaction to be committed, and returning prompting information to the node 3; if not, the transaction continues;
the verified revocation transaction is sent to the management node;
the management node checks the validity of the transaction, after the validity is confirmed, the management node signs with a private key of the management node to form a final transaction 6, and then the final transaction passes through a common identification chain;
preferably, the block is packed out by the undo transaction priority;
each node verifies the validity of the revocation transaction;
after the transaction validity verification is passed, each node (including node 3) unlocks corresponding assets 20000.00 yuan, and the delayed transaction 2 in the cache and the revocation transaction of the ledger record are cleared; fig. 17 is a second schematic diagram of a ledger record-reversal transaction according to an example embodiment of the present invention, as shown in fig. 17, a reversal transaction 6 (i.e., transaction 6 in the figure) is recorded.
The account balance of the payer is 60000.00 yuan, the locking amount is 0.00 yuan, and the available balance is 60000.00 yuan.
Fig. 18 is a block diagram of a network node according to an exemplary embodiment of the present invention, and as shown in fig. 18, in this embodiment, a node apparatus includes:
a communication module: a transaction initiator initiates a transaction request, and the messages are interacted through a communication module;
an identity verification module: verifying signatures of the client, the nodes and the management nodes;
a consensus module: carrying out a consensus process, and generating blocks in the period;
a deferred transaction management module: delayed transactions are managed independently.
Fig. 19 is a block diagram of a deferred transaction management module according to an exemplary embodiment of the present invention, and as shown in fig. 19, in this embodiment, the deferred transaction management module includes:
the physical cache module is mainly used for preventing node faults and losing delayed transactions which are not committed;
the account locking amount management module is a module for counting the account locking amount;
and the cache transaction management module is used for managing transaction locking and cleaning, and managing a memory and a cache without verifying the validity.
It should be noted that, for simplicity of description, the above-mentioned method embodiments are described as a series of acts or combination of acts, but those skilled in the art will recognize that the present invention is not limited by the order of acts, as some steps may occur in other orders or concurrently in accordance with the invention. Further, those skilled in the art should also appreciate that the embodiments described in the specification are preferred embodiments and that the acts and modules referred to are not necessarily required by the invention.
According to another aspect of the embodiment of the invention, a blockchain network for implementing the transaction processing method is also provided. The blockchain network includes a memory in which a computer program is stored and a processor configured to execute the steps in any of the above method embodiments through the computer program, which are not described herein again.
Optionally, in this embodiment, the electronic device may be located in at least one network device of a plurality of network devices of a computer network.
In other embodiments, the node device, the terminal device or the server may be a node in a distributed system, where the distributed system may be a blockchain system, and the blockchain system may be a distributed system formed by connecting a plurality of nodes through a network communication. Nodes can form a peer-to-peer (P2P, PeerToPeer) network, and any type of computing device, such as a server, a terminal, and other electronic devices, can become a node in the blockchain system by joining the peer-to-peer network.
The above-mentioned serial numbers of the embodiments of the present invention are merely for description and do not represent the merits of the embodiments.
The integrated unit in the above embodiments, if implemented in the form of a software functional unit and sold or used as a separate product, may be stored in the above computer-readable storage medium. Based on such understanding, the technical solution of the present invention may be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for causing one or more computer devices (which may be personal computers, servers, network devices, etc.) to execute all or part of the steps of the method according to the embodiments of the present invention.
In the above embodiments of the present invention, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments.
In the several embodiments provided in the present application, it should be understood that the disclosed client may be implemented in other manners. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one type of division of logical functions, and there may be other divisions when actually implemented, for example, a plurality of units or components may be combined or may be integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, units or modules, and may be in an electrical or other form.
The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
In addition, functional units in the embodiments of the present invention may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.
The foregoing is only a preferred embodiment of the present invention, and it should be noted that, for those skilled in the art, various modifications and decorations can be made without departing from the principle of the present invention, and these modifications and decorations should also be regarded as the protection scope of the present invention.
Claims (10)
1. A transaction processing method for a blockchain network, comprising:
receiving a transaction request sent by a client through a first node in a blockchain network, wherein transaction conditions are indicated in the transaction request;
under the condition that the transaction request passes the first verification, generating a block according to the transaction request and sending the block to an accounting node in the block chain network;
performing a second verification on the transaction request through the accounting node, and locking an object associated with the transaction request if the transaction request passes the second verification, wherein the second verification is at least used for determining 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;
executing the transaction indicated by the transaction request if the transaction condition of the transaction request is satisfied.
2. The method of claim 1, wherein prior to the executing the transaction indicated by the transaction request, the method further comprises:
acquiring the latest block in the block chain network through the accounting node;
determining whether specified information indicated in a latest block in the blockchain network satisfies the transaction condition;
determining that the trade condition of the trade request has been satisfied in a case where the specifying information satisfies the trade condition.
3. The method of claim 1, wherein prior to the executing the transaction indicated by the transaction request, the method further comprises:
receiving a transaction revocation request sent by the client through a first accounting node in the accounting nodes;
performing third verification on the transaction revocation request through the first accounting node, and generating a block according to the transaction revocation request and sending the block to the accounting node under the condition that the transaction revocation request passes the third verification;
and revoking the transaction request by performing fourth authentication on the transaction revocation request through the accounting node, wherein the fourth authentication is at least used for determining whether the transaction revocation request has revocation authority or not, and determining that the transaction revocation request passes the fourth authentication if the transaction revocation request has the revocation authority.
4. The method of claim 1, wherein prior to the performing the transaction indicated by the transaction request, the method comprises:
receiving, by a 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 the transaction revocation request to be signed is signed by the management node when the transaction revocation request to be signed is verified;
generating a block according to the signed revocation transaction request, and sending the block to the accounting node;
and performing fifth verification on the transaction revocation request after the signature through the accounting node, and if the transaction revocation request after the signature passes the fifth verification, revoking the transaction request, wherein the fifth verification is at least used for determining whether the transaction revocation request after the signature has revocation authority or not, and if the transaction revocation request has the revocation authority, determining that the transaction revocation request passes the fifth verification.
5. The method of claim 4, wherein prior to said receiving, by a management node, a transaction cancellation request to be signed sent by a second one of the billing nodes, the method further comprises:
receiving, by the second accounting node in the accounting nodes, a revocation indication and permission information sent by the client, wherein the revocation indication is used for indicating that the transaction request is revoked, and the permission information is used for indicating that the client has permission to revoke the transaction request;
sending, by the second accounting node, the to-be-signed revocation transaction request to the management node in the blockchain network, where the to-be-signed revocation transaction request is sent by the second accounting node if the authority information is verified.
6. The method of any of claims 3 to 5, wherein said revoking the transaction request comprises:
unlocking the locked object associated with the transaction request; and the number of the first and second groups,
clearing the transaction request.
7. The method of claim 1, wherein in the case that the transaction request is a funds transfer transaction request, the transaction request indicates the following information in addition to the transaction conditions:
transaction identification, payer information, payer account information, payee account information, transfer amount information, a transaction summary, and a transaction signature.
8. The method of claim 1 or 7, wherein the transaction condition comprises: an execution time condition of the transaction.
9. A blockchain network, comprising:
the system comprises a first node and a second node, wherein the first node is used for receiving a transaction request sent by a client, and transaction conditions are indicated in the transaction request;
the consensus node is used for generating a block according to the transaction request and sending the block to an accounting node in the block chain network under the condition that the transaction request passes the first verification;
a billing node for performing a second verification on the transaction request, and locking an object associated with the transaction request if the transaction request passes the second verification, wherein the second verification is at least used for determining 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; and is also used for executing the transaction indicated by the transaction request if the transaction condition of the transaction request is met.
10. A blockchain network comprising a memory and a processor, characterized in that the memory has stored therein a computer program, the processor being arranged to execute the method as claimed in any of the claims 1 to 8 by means of the computer program.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010634877.1A CN111915308A (en) | 2020-07-04 | 2020-07-04 | Transaction processing method of blockchain network and blockchain network |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010634877.1A CN111915308A (en) | 2020-07-04 | 2020-07-04 | Transaction processing method of blockchain network and blockchain network |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111915308A true CN111915308A (en) | 2020-11-10 |
Family
ID=73227358
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010634877.1A Pending CN111915308A (en) | 2020-07-04 | 2020-07-04 | Transaction processing method of blockchain network and blockchain network |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111915308A (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113094753A (en) * | 2021-05-08 | 2021-07-09 | 重庆银行股份有限公司 | Big data platform hive data modification method and system based on block chain |
| CN113112359A (en) * | 2021-03-16 | 2021-07-13 | 卓尔智联(武汉)研究院有限公司 | Alliance chain consensus achieving method, device and storage medium |
| CN113537986A (en) * | 2021-07-16 | 2021-10-22 | 广州电力交易中心有限责任公司 | Electric power transaction method and system based on block chain and cryptographic technology |
-
2020
- 2020-07-04 CN CN202010634877.1A patent/CN111915308A/en active Pending
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113112359A (en) * | 2021-03-16 | 2021-07-13 | 卓尔智联(武汉)研究院有限公司 | Alliance chain consensus achieving method, device and storage medium |
| CN113094753A (en) * | 2021-05-08 | 2021-07-09 | 重庆银行股份有限公司 | Big data platform hive data modification method and system based on block chain |
| CN113537986A (en) * | 2021-07-16 | 2021-10-22 | 广州电力交易中心有限责任公司 | Electric power transaction method and system based on block chain and cryptographic technology |
| CN113537986B (en) * | 2021-07-16 | 2024-04-05 | 广州电力交易中心有限责任公司 | Power transaction method and system based on blockchain and password technology |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11477032B2 (en) | System and method for decentralized-identifier creation | |
| US11025435B2 (en) | System and method for blockchain-based cross-entity authentication | |
| US20200328878A1 (en) | System and method for blockchain-based cross-entity authentication | |
| US11210661B2 (en) | Method for providing payment gateway service using UTXO-based protocol and server using same | |
| CN110494877B (en) | System and method for issuing and tracking digital tokens within distributed network nodes | |
| CN110494876B (en) | System and method for issuing and tracking digital tokens within distributed network nodes | |
| CN109691008B (en) | Network topology | |
| CN110620810B (en) | Non-linked ownership of continuous asset transfer over blockchain | |
| US11170092B1 (en) | Document authentication certification with blockchain and distributed ledger techniques | |
| US20200145373A1 (en) | System for blockchain based domain name and ip number register | |
| US20200074470A1 (en) | Database configuration for asset transfers | |
| US20180308094A1 (en) | Time stamping systems and methods | |
| CN111915308A (en) | Transaction processing method of blockchain network and blockchain network | |
| AU2020202575A1 (en) | Online payment | |
| CN111383114A (en) | Asset information management method and device based on block chain | |
| CN111402033A (en) | Asset information management method and device based on block chain | |
| CN111340628A (en) | Asset information management method and device based on block chain | |
| Ahmed et al. | Turning trust around: smart contract-assisted public key infrastructure | |
| CN111274597B (en) | Data processing method and device | |
| CN112074861A (en) | Block chain based messaging service for time sensitive events | |
| AU2021300620A1 (en) | Permissioned eventing in a decentralized database | |
| CN113269639A (en) | Business processing method, device, equipment and medium based on block chain intelligent contract | |
| CN112074862A (en) | Storage management based on message feedback | |
| CN111177171A (en) | Service data authentication and management method and system based on block chain | |
| CN115099800A (en) | Block chain based method and device for transferring poor asset data |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |