CN112037062A - Transaction consensus method, device, electronic equipment and readable storage medium - Google Patents
Transaction consensus method, device, electronic equipment and readable storage medium Download PDFInfo
- Publication number
- CN112037062A CN112037062A CN202010897500.5A CN202010897500A CN112037062A CN 112037062 A CN112037062 A CN 112037062A CN 202010897500 A CN202010897500 A CN 202010897500A CN 112037062 A CN112037062 A CN 112037062A
- Authority
- CN
- China
- Prior art keywords
- transaction
- executed
- consensus
- target
- intelligent contract
- 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.)
- Granted
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
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Engineering & Computer Science (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Technology Law (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
The embodiment of the invention provides a transaction consensus method, a transaction consensus device, electronic equipment and a readable storage medium, and aims to improve the fairness of transaction execution. Wherein the transaction consensus method comprises: obtaining a transaction to be executed; determining whether the transaction to be executed passes consensus or not based on a target consensus strategy corresponding to the transaction to be executed and a plurality of votes carried by the transaction to be executed, wherein each vote is used for representing whether a voter who votes agrees to execute the transaction to be executed or not; in the case that the transaction to be executed passes consensus, executing the transaction to be executed, including: and determining a target consensus strategy agreed by the target intelligent contract from the target intelligent contract depended by the transaction to be executed, comparing whether the target consensus strategy corresponding to the transaction to be executed is consistent with the target consensus strategy agreed by the target intelligent contract, and refusing to continuously execute the transaction to be executed if the target consensus strategy corresponding to the transaction to be executed is not consistent with the target consensus strategy agreed by the target intelligent contract.
Description
Technical Field
The present invention relates to the field of communications technologies, and in particular, to a transaction consensus method, an apparatus, an electronic device, and a readable storage medium.
Background
The block chain technology is built on a transmission network (also called as a block chain network), distributed node equipment (hereinafter referred to as nodes) in the transmission network generates block data by a preset consensus strategy through running a block chain program, and verifies and stores the block data by using a chain data structure, so that a data tamper-proof mechanism is finally realized, and a safe and reliable new technical idea is provided for business development.
The block chain technology can be applied to various service scenes, such as the financial field, the electronic commerce field, the commodity or raw material tracing field, the electronic evidence storage field and the like.
In the related art, services developed using block-chain techniques generally involve the benefit of multiple direct service participants and/or indirect service participants. However, when the blockchain network is used to execute the transactions corresponding to the services, due to the limitation of the existing blockchain technology, the benefits of each participant cannot be reasonably considered during the execution of the transactions, and thus the fairness of the execution of the transactions is difficult to guarantee.
Disclosure of Invention
The embodiment of the invention aims to provide a transaction consensus method, a transaction consensus device, electronic equipment and a readable storage medium, and aims to improve the fairness of transaction execution. The specific technical scheme is as follows:
in a first aspect of the embodiments of the present invention, there is provided a transaction consensus method applied to a node in a blockchain network, the method including:
obtaining a transaction to be executed, the transaction to be executed carrying: a plurality of votes for the transaction to be performed, wherein each vote is used for representing whether a voter of the vote agrees to perform the transaction to be performed;
determining whether the transaction to be executed passes consensus or not based on a target consensus strategy corresponding to the transaction to be executed and a plurality of votes carried by the transaction to be executed;
in the case that the transaction to be executed passes consensus, executing the transaction to be executed, including: and determining a target consensus strategy agreed by the target intelligent contract from the target intelligent contract depended by the transaction to be executed, comparing whether the target consensus strategy corresponding to the transaction to be executed is consistent with the target consensus strategy agreed by the target intelligent contract, and refusing to continuously execute the transaction to be executed if the target consensus strategy corresponding to the transaction to be executed is not consistent with the target consensus strategy agreed by the target intelligent contract.
In a second aspect of the embodiments of the present invention, there is provided a transaction consensus apparatus, applied to a node in a blockchain network, the apparatus including:
a transaction obtaining module, configured to obtain a transaction to be executed, where the transaction to be executed carries: a plurality of votes for the transaction to be performed, wherein each vote is used for representing whether a voter of the vote agrees to perform the transaction to be performed;
the transaction consensus module is used for determining whether the transaction to be executed passes consensus or not based on a target consensus strategy corresponding to the transaction to be executed and a plurality of votes carried by the transaction to be executed;
the transaction execution module is used for executing the transaction to be executed under the condition that the transaction to be executed passes consensus, and comprises the following steps: and determining a target consensus strategy agreed by the target intelligent contract from the target intelligent contract depended by the transaction to be executed, comparing whether the target consensus strategy corresponding to the transaction to be executed is consistent with the target consensus strategy agreed by the target intelligent contract, and refusing to continuously execute the transaction to be executed if the target consensus strategy corresponding to the transaction to be executed is not consistent with the target consensus strategy agreed by the target intelligent contract.
In a third aspect of the embodiments of the present invention, an electronic device is provided, which includes a processor, a communication interface, a memory, and a communication bus, where the processor, the communication interface, and the memory complete communication with each other through the communication bus;
the memory is used for storing a computer program;
the processor is used for realizing the transaction consensus method provided by any embodiment of the invention when the program stored in the memory is executed.
In a fourth aspect of the embodiments of the present invention, there is provided a computer-readable storage medium on which a computer program is stored, the program, when executed by a processor, implementing the transaction consensus method provided by any of the embodiments of the present invention.
In the invention, after the node in the block chain network obtains the transaction to be executed and before the transaction to be executed is executed, whether the transaction to be executed passes consensus or not is determined based on a target consensus strategy corresponding to the transaction to be executed and a plurality of votes carried by the transaction to be executed. Finally, in the case that the transaction to be executed passes the consensus, the transaction to be executed is started to be executed.
Because each vote carried by the transaction to be executed is used for representing whether the voter who votes agrees to execute the transaction to be executed, before the transaction to be executed is really executed, the transaction to be executed is identified based on a target consensus strategy corresponding to the transaction to be executed and the carried multiple votes, which is equivalent to checking the fairness of the transaction. And executing the transaction to be executed under the condition that the transaction to be executed passes the consensus, namely executing the transaction to be executed under the condition that the fairness is met. Therefore, the invention can improve the fairness of transaction execution.
Furthermore, since the transaction to be executed corresponds to the corresponding target consensus policy, in other words, different transactions to be executed may correspond to different target consensus policies, respectively. Thus, there is greater flexibility in performing trade consensus. In particular, different types of transactions to be executed may be mutually identified based on respective suitable consensus strategies, instead of forcing all transactions to be executed to be mutually identified based on the same consensus strategy. Thus, in this respect, the present invention can also improve the fairness of transaction execution.
In addition, during the execution of the transaction to be executed, it is also necessary to determine whether the target consensus strategy agreed in the target intelligent contract on which the transaction to be executed depends, and the target consensus strategy corresponding to the transaction to be executed are consistent. If not, it may not be reasonable to state a consensus of previously passed transactions. In this case, the node refuses to continue executing the transaction to be executed, so that the reasonability of transaction consensus is ensured, and the fairness of transaction execution is further improved.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below. It is obvious that the drawings in the following description are only some embodiments of the invention, and that for a person skilled in the art, other drawings can be derived from them without inventive effort.
Fig. 1 is a schematic diagram of a block chain network according to an embodiment of the present invention;
FIG. 2 is a schematic diagram of a transaction consensus process according to an embodiment of the present invention;
FIG. 3 is a flow chart of a transaction consensus method according to an embodiment of the present invention;
FIG. 4 is a schematic diagram of a transaction consensus apparatus according to an embodiment of the present invention;
fig. 5 is a schematic diagram of an electronic device according to an embodiment of the invention.
Detailed Description
The technical solution in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. It is to be understood that the embodiments described are only a few embodiments of the present invention, and not all 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.
The block chain technology is built on a transmission network (also called as a block chain network), distributed node equipment (hereinafter referred to as nodes) in the transmission network generates block data by a preset consensus strategy through running a block chain program, and verifies and stores the block data by using a chain data structure, so that a data tamper-proof mechanism is finally realized, and a safe and reliable new technical idea is provided for business development.
In the related art, services developed using block-chain techniques generally involve the benefit of multiple direct service participants and/or indirect service participants. However, when the blockchain network is used to execute the transactions corresponding to the services, due to the limitation of the existing blockchain technology, the benefits of each participant cannot be reasonably considered during the execution of the transactions, and thus the fairness of the execution of the transactions is difficult to guarantee.
Therefore, the invention provides a transaction consensus method, a transaction consensus device, an electronic device and a readable storage medium through the following embodiments, aiming at improving the fairness of transaction execution.
As shown in fig. 1, fig. 1 is a schematic diagram of a block chain network according to an embodiment of the present invention. As shown in fig. 1, the blockchain network includes a plurality of distributed node devices (hereinafter, referred to as nodes), each for running a blockchain program. The plurality of nodes implement the blockchain technique by running a blockchain program. The plurality of nodes of the blockchain network may include a master node, which may be a pre-designated node or a node periodically elected from the plurality of nodes. Illustratively, the master node in the blockchain network shown in fig. 1 is node 4.
The invention is based on the blockchain network shown in fig. 1, and can process transactions in the following way:
in the invention, after any node in the block chain network receives a transaction sent by a client side, a consensus strategy corresponding to the transaction can be determined from a plurality of preset consensus strategies according to a consensus strategy identifier carried by the transaction, and the transaction is sent to each voting node based on the consensus strategy, so that each voting node votes for the transaction. Wherein, a consensus strategy corresponding to a transaction is used for appointing: a voting node is required to vote for the transaction.
For ease of understanding, and by way of example, as shown in FIG. 1, assume that node 5 receives transaction a, which corresponds to a consensus policy contract: the voting nodes that need to vote for transaction a include node 1, node 2, node 3, node 6, and node 8. Node 5 sends transaction a to node 1, node 2, node 3, node 6, and node 8 based on the consensus policy so that these voting nodes vote for transaction a. Optionally, in some embodiments, each voting node may notify the administrator of the voting node to vote for transaction a after receiving transaction a sent by node 5. Wherein the vote of each voting node for transaction a is used to characterize: whether the voting node agrees to perform transaction a. In addition, each voting node can also sign the vote by using the private key of the voting node to obtain the voting signature of the vote. Each voting node signs its vote, along with the corresponding vote, back to node 5.
In the invention, after receiving the votes and the voting signatures returned by each voting node, the node verifies the signature of the voting signature of each voting node by using the public key of the voting node according to the voting signature of each voting node. And determining whether the transaction passes the consensus or not based on the vote corresponding to the voting signature passing the signature verification and the consensus strategy corresponding to the transaction. Wherein, the consensus strategy corresponding to one transaction is also used for constraining: a transaction is a target voting condition that needs to be satisfied by consensus.
For convenience of understanding, as shown in fig. 1, for example, after the node 5 receives the votes and the corresponding voting signatures returned by the respective voting nodes, the node 5 performs signature verification on the voting signature of each voting node by using the public key of the voting node. It is assumed that all voting signatures pass the signature verification. Assume again that the votes from node 1, node 2, node 3, and node 8 are "agree to execute transaction a" and the vote from node 6 is "disagree to execute transaction a". Then, assuming that the target voting condition constrained by the consensus strategy corresponding to the transaction a is: not less than 4 votes are "agreeing to execute a transaction". In other words, if the vote of "agree to perform a transaction" is not less than 4, the transaction passes consensus; if the vote to "agree to perform a transaction" is less than 4, the transaction fails consensus. Since the vote "agreeing to perform transaction a" is 4 out of all valid votes, node 5 determines that transaction a passes consensus.
Or, for example, after the node 5 receives the votes and the corresponding voting signatures returned by the respective voting nodes, the node 5 performs signature verification on the voting signatures of the voting nodes by using the public keys of the voting nodes for the voting signatures of each voting node. Assuming that the voting signatures of the nodes 1, 2, 3 and 8 of all the voting signatures pass signature verification, and the voting signature of the node 6 does not pass signature verification, the vote of the node 6 is regarded as an invalid vote and is discarded. Further, assume that the target voting condition constrained by the consensus policy corresponding to transaction a is: not less than 4 votes are "agreeing to execute a transaction". In other words, if the vote of "agree to perform a transaction" is not less than 4, the transaction passes consensus; if the vote to "agree to perform a transaction" is less than 4, the transaction fails consensus. Since the vote "agreeing to perform transaction a" is only 3 out of all valid votes, node 5 determines that transaction a has failed consensus.
In the invention, if the node determines that the transaction passes the consensus, the node packages the transaction, the voting signature passing the signature verification and the voting corresponding to the voting signature passing the signature verification into the transaction to be executed, and submits the transaction to be executed to the main node. If the node determines that the transaction does not pass the consensus, the optional processing mode is as follows: the node discards the transaction or the node returns the transaction to the transaction initiator (e.g., client) and prompts the transaction initiator "the transaction failed consensus".
For ease of understanding, taking the example of the node 5 determining that transaction a passes the consensus, as shown in fig. 1, the node 5 packages the following data into transaction a to be executed: transaction a, vote and vote signature for node 1, vote and vote signature for node 2, vote and vote signature for node 3, vote and vote signature for node 6, and vote signature for node 8. As shown in fig. 1, the packaged transaction a to be executed is submitted to the master node by the node 5.
In the invention, the main node can continuously receive the transactions to be executed submitted by a plurality of nodes, the main node sequences the transactions to be executed and sends the sequenced transactions to be executed to each node (including the main node) in the block chain network. To simplify the drawing, the process of the master node sending the ordered plurality of transactions to be executed to the respective nodes is not shown in fig. 1.
Optionally, in some embodiments, the master node ranks each time it receives a pending transaction after the last received pending transaction. When the number of the transactions to be executed arranged in the master node reaches a preset number (for example, 100), the master node sends the preset number of transactions to be executed as a set to each node (including the master node itself) in the blockchain network.
Referring to fig. 2, fig. 2 is a schematic diagram of a transaction consensus process according to an embodiment of the present invention, as shown in fig. 2, each node (including the master node itself) in the blockchain network receives a plurality of ordered transactions to be executed sent by the master node (step S21 in fig. 2). Each transaction to be executed carries: each voting node signs the vote and the digital signature of the vote for the transaction to be performed. As previously mentioned, each vote for one transaction to be performed is used to characterize: whether the voting node corresponding to the vote agrees to execute the transaction to be executed or not.
In the invention, after receiving a plurality of ordered transactions to be executed sent by a main node, nodes in a block chain network respond to each transaction to be executed in sequence according to the sequence of the plurality of transactions to be executed. Wherein, when the node responds to each transaction to be executed, specifically: the node performs signature verification on each voting signature carried by the transaction to be executed (as in step S22 in fig. 2); if the node determines that each voting signature carried by the transaction to be executed does not pass the signature verification, the node refuses to execute the transaction to be executed (as in step S23 in fig. 2); if the node determines that each voting signature carried by the transaction to be executed passes signature verification, the node determines whether the transaction to be executed passes consensus based on the target consensus policy corresponding to the transaction to be executed and the plurality of votes carried by the transaction to be executed (as in step S24 in fig. 2).
It should be noted that, in the present invention, the transactions to be executed are sorted by the master node, and the sorted transactions to be executed are sent to each node for execution. In this way, after each node executes each transaction to be executed in sequence, the execution results obtained by each node are the same, and the sequence of the execution results obtained by each node is also the same. For convenience of understanding, each node sequentially executes the transaction a to be executed, the transaction B to be executed, and the transaction C to be executed, which are sent by the master node, and each node sequentially obtains an execution result a, an execution result B, and an execution result C. Since the execution results obtained by each node are the same and the order of the execution results is also the same, the total hash value calculated by each node for all the execution results is the same. Therefore, as the total hash values calculated by each node in the whole block chain network are the same, each total hash value can quickly pass through consensus, and each execution result is quickly uplink-stored.
As described above, the voting signatures carried in the transaction to be executed, which is submitted to the master node by the node, are all voting signatures verified by the signature of the node. As shown in fig. 1, all the voting signatures included in the transaction a to be executed, which is packaged by the node 5, are voting signatures after signature verification. Therefore, after the master node sorts the transactions to be executed and sends the transactions to each node, all the voting signatures carried in each transaction to be executed received by the node all can pass signature verification. And if a certain voting signature fails to pass signature verification, the voting corresponding to the voting signature is falsified, and the transaction to be executed to which the voting signature belongs is an unsafe transaction. For this reason, if the node determines that each voting signature carried by a certain transaction to be executed does not pass the signature verification, the node refuses to execute the transaction to be executed. In other words, if the node determines that one or more voting signatures carried by a certain transaction to be executed fail to pass signature verification, the node refuses to execute the transaction to be executed.
In the invention, the signature verification is carried out on the transaction to be executed in the signature verification mode, which is beneficial to improving the transaction security and reducing the possibility that the transaction is attacked by a network.
In the invention, after the voting and the voting signature of each voting node on the transaction are collected, the node (such as the node 5 in fig. 1) needs to judge whether the transaction passes the consensus in advance based on the consensus strategy corresponding to the transaction and the voting on the transaction, and only when the transaction passes the consensus, the transaction and the corresponding voting and the voting signature are packaged into the transaction to be executed and submitted to the main node. In this way, some transactions that fail to pass the consensus are not submitted to the master node, so that invalid transactions (i.e. transactions that fail to pass the consensus) can be prevented from being transmitted in the blockchain network, and the data interaction pressure in the blockchain network can be reduced.
Optionally, in some embodiments, as mentioned above, the target consensus policy corresponding to the transaction to be executed is used to constrain: the transaction to be executed is a target voting condition to be satisfied by consensus. When the node determines whether the transaction to be executed passes the consensus based on the target consensus policy corresponding to the transaction to be executed and the multiple votes carried by the transaction to be executed (i.e. the step S24), specifically: the node judges whether a plurality of votes carried by the transaction to be executed meet a target voting condition constrained by a target consensus strategy corresponding to the transaction to be executed; under the condition that a plurality of votes carried by the transaction to be executed meet the target voting condition, the node determines that the transaction to be executed passes consensus; and under the condition that the multiple votes carried by the transaction to be executed do not meet the target voting condition, the node determines that the transaction to be executed does not pass consensus.
For convenience of understanding, following the above example, after the transaction a to be executed corresponding to the transaction a is sorted and distributed to each node by the master node, when one node responds to the transaction a to be executed, specifically: the consensus strategy corresponding to the transaction a to be executed can be determined from a plurality of preset consensus strategies according to the consensus strategy identifier carried by the transaction a to be executed. It should be noted that the transaction a to be executed is actually also the transaction a, and the target consensus policy corresponding to the transaction a to be executed is also the consensus policy corresponding to the transaction a. Then, the node judges whether the vote carried by the transaction A to be executed meets the target voting condition or not based on the target voting condition constrained by the determined target consensus strategy. As mentioned above, the target voting condition constrained by the target consensus policy is: not less than 4 votes are "agreeing to execute a transaction". In other words, if the vote of "agree to perform a transaction" is not less than 4, the transaction to be performed passes consensus; if the vote to "agree to perform a transaction" is less than 4, the transaction to be performed fails consensus. As described above, among all the votes carried in the transaction a to be executed, the number of votes "agreeing to execute the transaction a" is 4, and the target voting condition is satisfied, so that the transaction a to be executed passes consensus.
In the present invention, in the case that the transaction to be executed fails to pass the consensus, the node may refuse to execute the transaction to be executed, or the node may also directly generate an execution result of "execution failure" for the transaction to be executed (as in step S25 in fig. 2).
In the invention, the node starts to execute the transaction to be executed under the condition that the transaction to be executed passes the consensus. When the node executes the transaction to be executed, specifically: the node judges whether the transaction to be executed carries the intelligent contract identifier (as in step S26 in fig. 2); if the transaction to be executed does not carry the intelligent contract identifier, continuing to execute the transaction to be executed (as shown in step S29 in fig. 2); if the transaction to be executed carries the intelligent contract identifier, determining a target intelligent contract depending on the transaction to be executed according to the intelligent contract identifier carried by the transaction to be executed, determining a target consensus policy agreed by the target intelligent contract from the target intelligent contract depending on the transaction to be executed, comparing whether the target consensus policy corresponding to the transaction to be executed is consistent with the target consensus policy agreed by the target intelligent contract (as in step S27 in fig. 2), if not, refusing to execute the transaction to be executed continuously (as in step S28 in fig. 2), and if so, executing the transaction to be executed continuously (as in step S29 in fig. 2).
For understanding, assuming that the target consensus policy corresponding to a transaction to be executed is consensus policy X, the node performs consensus on the transaction to be executed based on the consensus policy X in step S24, and passes the consensus. And the agreed target consensus strategy in the target intelligent contract depended by the transaction to be executed is assumed to be the consensus strategy Y. The node refuses to proceed with the transaction to be executed because the two target consensus policies are not in agreement.
It should be noted that, if one transaction to be executed carries an intelligent contract identifier, it indicates that the execution of the transaction to be executed depends on the intelligent contract, and the dependent intelligent contract is an intelligent contract corresponding to the intelligent contract identifier. Wherein the intelligent contract identification may be a contract address.
Generally, a goal consensus policy may be agreed upon in the intelligent contract. If a target consensus strategy is agreed upon by an intelligent contract, the transaction to be executed depending on the intelligent contract actually needs to be agreed upon based on the target consensus strategy agreed upon by the intelligent contract. For ease of understanding, following the above example, assuming that the target consensus policy agreed upon in the target intelligent contract on which a transaction to be executed depends is consensus policy Y, the transaction to be executed actually needs to be agreed upon based on consensus policy Y. Therefore, in the invention, during the execution of the transaction to be executed, whether the target consensus strategy corresponding to the transaction to be executed is consistent with the target consensus strategy agreed by the target intelligent contract is verified again. If so, the transaction to be executed may continue to be executed. If the agreement is not consistent, the agreement which is previously carried out and passed is not reasonable, and in this case, the node refuses to continuously execute the transaction to be executed, so that the reasonability of the agreement of the transaction is ensured, and the fairness of the transaction execution is further improved.
Optionally, in some embodiments, as mentioned above, the transaction to be executed may also carry: and the consensus strategy mark of the target consensus strategy corresponding to the transaction to be executed. In addition, the target intelligent contract may also have recorded therein: and the consensus strategy mark of the target consensus strategy agreed by the target intelligent contract. When the node determines that the execution of a transaction to be executed depends on the intelligent contract during the execution of the transaction to be executed, specifically: the node can establish a virtual machine for the target intelligent contract which is depended by the transaction to be executed; and executing the contract instruction of the target intelligent contract through the virtual machine. When the virtual machine executes a contract instruction for comparing a target consensus strategy, the virtual machine acquires a consensus strategy identifier carried by the transaction to be executed, acquires a consensus strategy identifier recorded by the target intelligent contract, and compares whether the two acquired consensus strategy identifiers are consistent. If so, the subsequent contract instruction of the target intelligent contract (which is equivalent to the continued execution of the transaction to be executed) is continuously executed. If not, subsequent contract instructions for continuing the target smart contract are denied (equivalent to denying continuing execution of the pending transaction).
In the invention, each vote carried by the transaction to be executed is used for representing whether a voter (such as a voting node) who carries the vote agrees to execute the transaction to be executed, so that before the transaction to be executed is really executed, the transaction to be executed is identified based on a target consensus strategy corresponding to the transaction to be executed and the carried multiple votes, and the fairness of the transaction is checked. And executing the transaction to be executed under the condition that the transaction to be executed passes the consensus, namely executing the transaction to be executed under the condition that the fairness is met. Therefore, the invention can improve the fairness of transaction execution.
In the invention, the transaction to be executed corresponds to a corresponding target consensus strategy, in other words, different transactions to be executed can respectively correspond to different target consensus strategies. Thus, there is greater flexibility in performing trade consensus. In particular, different types of transactions to be executed may be mutually identified based on respective suitable consensus strategies, instead of forcing all transactions to be executed to be mutually identified based on the same consensus strategy. Thus, in this respect, the present invention can also improve the fairness of transaction execution.
In the invention, during the execution of the transaction to be executed, whether the target consensus strategy agreed in the target intelligent contract depended on by the transaction to be executed is consistent with the target consensus strategy corresponding to the transaction to be executed needs to be judged. If not, it may not be reasonable to state a consensus of previously passed transactions. In this case, the node refuses to continue executing the transaction to be executed, so that the reasonability of transaction consensus is ensured, and the fairness of transaction execution is further improved.
In the above, the invention provides a blockchain network and a transaction execution process based on the blockchain network according to some embodiments. Hereinafter, the present invention will provide a trade consensus method through other embodiments, and the following embodiments may include some or all of the technical features of the above embodiments, and the following embodiments and the above embodiments may be mutually referred to.
Referring to fig. 3, fig. 3 is a flowchart of a transaction consensus method applied to any node in a blockchain network according to an embodiment of the present invention. As shown in fig. 3, the transaction consensus method includes the following steps:
step S31: obtaining a transaction to be executed, the transaction to be executed carrying: a plurality of votes for the transaction to be performed, wherein each vote is used to characterize whether a voter for that vote agrees to perform the transaction to be performed.
Optionally, in some specific embodiments, as described above, the node obtains a plurality of ordered transactions to be executed sent by the master node in the blockchain network, where each transaction to be executed further carries: the digital signature of each voter's vote.
The main node obtains the transaction to be executed in advance through the following modes: a node in the block chain network collects multiple votes and multiple voting signatures of multiple voters for a certain transaction, carries out signature verification aiming at each voting signature, determines whether the transaction passes the consensus or not based on the consensus strategy corresponding to the transaction and the votes corresponding to the votes passing the signature verification, and packs the transaction, the votes passing the signature verification and the votes corresponding to the votes passing the signature verification into a transaction to be executed if the transaction passes the consensus, and submits the transaction to be executed to the main node.
Step S32: and determining whether the transaction to be executed passes consensus or not based on a target consensus strategy corresponding to the transaction to be executed and a plurality of votes carried by the transaction to be executed.
Optionally, in some embodiments, as mentioned above, the transaction to be executed may also carry: the digital signature of the vote to which each voter votes (i.e., the vote signature described above). Before executing step S32, the node may perform signature verification on each voting signature carried by the transaction to be executed, and only if it is determined that each voting signature passes the signature verification, then step S32 is executed. Otherwise, the response to the transaction to be executed is terminated. When verifying the voting signature of each voter, the public key corresponding to the voter can be used to verify the voting signature of the voter.
Optionally, in some embodiments, as mentioned above, the target consensus policy corresponding to the transaction to be executed is used to constrain: the transaction to be executed is a target voting condition to be satisfied by consensus. In executing step S32, specifically: the node judges whether a plurality of votes carried by the transaction to be executed meet a target voting condition constrained by a target consensus strategy corresponding to the transaction to be executed; under the condition that a plurality of votes carried by the transaction to be executed meet the target voting condition, the node determines that the transaction to be executed passes consensus; and under the condition that the multiple votes carried by the transaction to be executed do not meet the target voting condition, the node determines that the transaction to be executed does not pass consensus.
Optionally, in some embodiments, as previously described, the node refuses to execute the transaction to be executed in the event that the transaction to be executed fails to agree. In the case that the transaction to be executed passes the consensus, the node starts to execute the transaction to be executed, and the specific execution process is as follows.
Step S33: in the case that the transaction to be executed passes consensus, executing the transaction to be executed, including: and determining a target consensus strategy agreed by the target intelligent contract from the target intelligent contract depended by the transaction to be executed, comparing whether the target consensus strategy corresponding to the transaction to be executed is consistent with the target consensus strategy agreed by the target intelligent contract, and refusing to continuously execute the transaction to be executed if the target consensus strategy corresponding to the transaction to be executed is not consistent with the target consensus strategy agreed by the target intelligent contract.
Optionally, in some specific embodiments, as described above, when executing the transaction to be executed, the node further determines whether the transaction to be executed further carries an intelligent contract identifier; and under the condition that the transaction to be executed carries the intelligent contract identifier, determining a target intelligent contract which is depended by the transaction to be executed according to the intelligent contract identifier carried by the transaction to be executed. And after the target intelligent contract depended on by the transaction to be executed is determined, determining a target consensus strategy agreed by the target intelligent contract from the target intelligent contract depended on by the transaction to be executed.
It should be noted that, if a certain to-be-executed transaction carries an intelligent contract identifier, it indicates that the execution of the to-be-executed transaction depends on the intelligent contract, and the dependent intelligent contract is an intelligent contract corresponding to the intelligent contract identifier. If a certain transaction to be executed does not carry the intelligent contract identifier, the execution of the transaction to be executed does not depend on the intelligent contract, so that the transaction to be executed can be continuously executed, that is, whether a target consensus strategy corresponding to the transaction to be executed is consistent with a target consensus strategy agreed by the target intelligent contract or not does not need to be compared.
Optionally, in some embodiments, as mentioned above, the transaction to be executed may also carry: the consensus policy identifier of the target consensus policy corresponding to the transaction to be executed may also record: and the consensus strategy mark of the target consensus strategy agreed by the target intelligent contract.
After determining a target intelligent contract on which a transaction to be executed depends, the node can establish a virtual machine for the target intelligent contract on which the transaction to be executed depends; and executing the contract instruction of the target intelligent contract through the virtual machine. When the virtual machine executes a contract instruction for comparing a target consensus strategy, the virtual machine acquires a consensus strategy identifier carried by the transaction to be executed, acquires a consensus strategy identifier recorded by the target intelligent contract, and compares whether the two acquired consensus strategy identifiers are consistent. If consistent, the subsequent contract instructions of the target smart contract (equivalent to continuing to execute the transaction to be executed) continue to be executed, as previously described. If not, subsequent contract instructions for continuing the target smart contract are denied (equivalent to denying continuing execution of the pending transaction).
Based on the same inventive concept, the embodiment of the invention also provides a transaction consensus device. Referring to fig. 4, fig. 4 is a schematic diagram of a transaction consensus apparatus applied to a node in a blockchain network according to an embodiment of the present invention. As shown in fig. 4, the apparatus includes:
a transaction obtaining module 41, configured to obtain a transaction to be executed, where the transaction to be executed carries: a plurality of votes for the transaction to be performed, wherein each vote is used for representing whether a voter of the vote agrees to perform the transaction to be performed;
the transaction consensus module 42 is configured to determine whether the transaction to be executed passes consensus or not based on a target consensus policy corresponding to the transaction to be executed and multiple votes carried by the transaction to be executed;
the transaction executing module 43 is configured to execute the transaction to be executed if the transaction to be executed passes the consensus, and includes: and determining a target consensus strategy agreed by the target intelligent contract from the target intelligent contract depended by the transaction to be executed, comparing whether the target consensus strategy corresponding to the transaction to be executed is consistent with the target consensus strategy agreed by the target intelligent contract, and refusing to continuously execute the transaction to be executed if the target consensus strategy corresponding to the transaction to be executed is not consistent with the target consensus strategy agreed by the target intelligent contract.
Optionally, the transaction execution module is further configured to: and refusing to execute the transaction to be executed under the condition that the transaction to be executed does not pass the consensus.
Optionally, the transaction execution module is further configured to: judging whether the transaction to be executed further carries an intelligent contract identifier, wherein if the transaction to be executed carries the intelligent contract identifier, the execution of the transaction to be executed depends on the intelligent contract, and the dependent intelligent contract is an intelligent contract corresponding to the intelligent contract identifier; and under the condition that the transaction to be executed carries an intelligent contract identifier, determining a target intelligent contract which is depended by the transaction to be executed according to the intelligent contract identifier carried by the transaction to be executed, and executing a target consensus strategy which is agreed by the target intelligent contract from the target intelligent contract which is depended by the transaction to be executed.
Optionally, the transaction execution module is further configured to: and under the condition that the transaction to be executed does not carry the intelligent contract identification, continuing to execute the transaction to be executed.
Optionally, the transaction to be executed further carries: the consensus strategy mark of the target consensus strategy corresponding to the transaction to be executed is recorded in the target intelligent contract, wherein: the consensus strategy mark of the target consensus strategy agreed by the target intelligent contract;
the transaction execution module is specifically configured to: establishing a virtual machine for the target intelligent contract which is depended by the transaction to be executed; executing a contract instruction of the target intelligent contract through the virtual machine, wherein when the virtual machine executes the contract instruction for comparing a target consensus strategy, the virtual machine acquires a consensus strategy identifier carried by the transaction to be executed, acquires a consensus strategy identifier recorded by the target intelligent contract, and compares whether the two acquired consensus strategy identifiers are consistent.
Optionally, the target consensus policy is used to constrain: the transaction to be executed is a target voting condition which needs to be met through consensus;
the transaction consensus module is specifically configured to: judging whether the multiple votes carried by the transaction to be executed meet a target voting condition constrained by a target consensus strategy corresponding to the transaction to be executed; determining that the transaction to be executed passes consensus when the multiple votes carried by the transaction to be executed meet the target voting condition; and determining that the transaction to be executed does not pass consensus under the condition that the multiple votes carried by the transaction to be executed do not meet the target voting condition.
Optionally, the transaction obtaining module is specifically configured to: obtaining a plurality of ordered to-be-executed transactions sent by the master node in the block chain network, wherein each to-be-executed transaction also carries: a digital signature of the vote to each voter;
wherein the master node obtains in advance a transaction to be executed by: a node in the block chain network collects multiple votes and multiple voting signatures of a plurality of voters for a certain transaction, carries out signature verification aiming at each voting signature, determines whether the transaction passes the consensus or not based on a consensus strategy corresponding to the transaction and the votes corresponding to the votes passing the signature verification, packs the transaction, the votes passing the signature verification and the votes corresponding to the votes passing the signature verification into a transaction to be executed if the transaction passes the consensus, and submits the transaction to be executed to the main node;
the device further comprises: the signature verification module is used for performing signature verification on each voting signature carried by the transaction to be executed before the transaction consensus module determines whether the transaction to be executed passes consensus or not based on a target consensus strategy corresponding to the transaction to be executed and a plurality of votes carried by the transaction to be executed;
the transaction consensus module is specifically configured to: and under the condition that the signature verification module determines that each voting signature passes the signature verification, determining whether the transaction to be executed passes the consensus or not based on a target consensus strategy corresponding to the transaction to be executed and a plurality of votes carried by the transaction to be executed.
For the device embodiment, since it is basically similar to the method embodiment, the description is simple, and for the relevant points, refer to the partial description of the method embodiment.
Based on the same inventive concept, an embodiment of the present invention further provides an electronic device, as shown in fig. 5, including a processor 501, a communication interface 502, a memory 503, and a communication bus 504, where the processor 501, the communication interface 502, and the memory 503 complete communication with each other through the communication bus 504.
The memory 503 is used for storing computer programs;
the processor 501 is configured to implement the following steps when executing the program stored in the memory 503:
obtaining a transaction to be executed, the transaction to be executed carrying: a plurality of votes for the transaction to be performed, wherein each vote is used for representing whether a voter of the vote agrees to perform the transaction to be performed;
determining whether the transaction to be executed passes consensus or not based on a target consensus strategy corresponding to the transaction to be executed and a plurality of votes carried by the transaction to be executed;
in the case that the transaction to be executed passes consensus, executing the transaction to be executed, including: and determining a target consensus strategy agreed by the target intelligent contract from the target intelligent contract depended by the transaction to be executed, comparing whether the target consensus strategy corresponding to the transaction to be executed is consistent with the target consensus strategy agreed by the target intelligent contract, and refusing to continuously execute the transaction to be executed if the target consensus strategy corresponding to the transaction to be executed is not consistent with the target consensus strategy agreed by the target intelligent contract.
Alternatively, the processor 501, when executing the program stored in the memory 503, implements the transaction consensus method steps provided by the other method embodiments of the present invention above.
The communication bus mentioned in the electronic device may be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The communication bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is shown, but this does not mean that there is only one bus or one type of bus.
The communication interface is used for communication between the electronic equipment and other equipment.
The Memory may include a Random Access Memory (RAM) or a non-volatile Memory (non-volatile Memory), such as at least one disk Memory. Optionally, the memory may also be at least one memory device located remotely from the processor.
The Processor may be a general-purpose Processor, and includes a Central Processing Unit (CPU), a Network Processor (NP), and the like; the Integrated Circuit may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other Programmable logic device, a discrete Gate or transistor logic device, or a discrete hardware component.
In yet another embodiment of the present invention, there is also provided a computer-readable storage medium having stored therein instructions, which when run on a computer, cause the computer to perform the transaction consensus method as described in any of the above embodiments.
In yet another embodiment of the present invention, there is also provided a computer program product comprising instructions which, when run on a computer, cause the computer to perform the transaction consensus method as described in any of the above embodiments.
In the above embodiments, the implementation may be wholly or partially realized by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, cause the processes or functions described in accordance with the embodiments of the invention to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, from one website site, computer, server, or data center to another website site, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that incorporates one or more of the available media. The usable medium may be a magnetic medium (e.g., floppy Disk, hard Disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., Solid State Disk (SSD)), among others.
It is noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.
All the embodiments in the present specification are described in a related manner, and the same and similar parts among the embodiments may be referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.
The above description is only for the preferred embodiment of the present invention, and is not intended to limit the scope of the present invention. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention shall fall within the protection scope of the present invention.
Claims (10)
1. A transaction consensus method applied to a node in a blockchain network, the method comprising:
obtaining a transaction to be executed, the transaction to be executed carrying: a plurality of votes for the transaction to be performed, wherein each vote is used for representing whether a voter of the vote agrees to perform the transaction to be performed;
determining whether the transaction to be executed passes consensus or not based on a target consensus strategy corresponding to the transaction to be executed and a plurality of votes carried by the transaction to be executed;
in the case that the transaction to be executed passes consensus, executing the transaction to be executed, including: and determining a target consensus strategy agreed by the target intelligent contract from the target intelligent contract depended by the transaction to be executed, comparing whether the target consensus strategy corresponding to the transaction to be executed is consistent with the target consensus strategy agreed by the target intelligent contract, and refusing to continuously execute the transaction to be executed if the target consensus strategy corresponding to the transaction to be executed is not consistent with the target consensus strategy agreed by the target intelligent contract.
2. The method of claim 1, further comprising:
and refusing to execute the transaction to be executed under the condition that the transaction to be executed does not pass the consensus.
3. The method of claim 1, wherein the executing the transaction to be executed further comprises:
judging whether the transaction to be executed further carries an intelligent contract identifier, wherein if the transaction to be executed carries the intelligent contract identifier, the execution of the transaction to be executed depends on the intelligent contract, and the dependent intelligent contract is an intelligent contract corresponding to the intelligent contract identifier;
and under the condition that the transaction to be executed carries an intelligent contract identifier, determining a target intelligent contract which is depended by the transaction to be executed according to the intelligent contract identifier carried by the transaction to be executed, and executing a target consensus strategy which is agreed by the target intelligent contract from the target intelligent contract which is depended by the transaction to be executed.
4. The method of claim 3, wherein the executing the transaction to be executed further comprises:
and under the condition that the transaction to be executed does not carry the intelligent contract identification, continuing to execute the transaction to be executed.
5. The method of claim 1, wherein the transaction to be performed further carries: the consensus strategy mark of the target consensus strategy corresponding to the transaction to be executed is recorded in the target intelligent contract, wherein: the consensus strategy mark of the target consensus strategy agreed by the target intelligent contract;
the determining a target consensus policy agreed by the target intelligent contract from the target intelligent contract depended by the transaction to be executed, and comparing whether the target consensus policy corresponding to the transaction to be executed is consistent with the target consensus policy agreed by the target intelligent contract, includes:
establishing a virtual machine for the target intelligent contract which is depended by the transaction to be executed;
executing a contract instruction of the target intelligent contract through the virtual machine, wherein when the virtual machine executes the contract instruction for comparing a target consensus strategy, the virtual machine acquires a consensus strategy identifier carried by the transaction to be executed, acquires a consensus strategy identifier recorded by the target intelligent contract, and compares whether the two acquired consensus strategy identifiers are consistent.
6. The method according to any one of claims 1 to 5, wherein the target consensus strategy is used to constrain: the transaction to be executed is a target voting condition which needs to be met through consensus; the determining whether the transaction to be executed passes consensus or not based on the target consensus strategy corresponding to the transaction to be executed and the multiple votes carried by the transaction to be executed comprises:
judging whether the multiple votes carried by the transaction to be executed meet a target voting condition constrained by a target consensus strategy corresponding to the transaction to be executed;
determining that the transaction to be executed passes consensus when the multiple votes carried by the transaction to be executed meet the target voting condition;
and determining that the transaction to be executed does not pass consensus under the condition that the multiple votes carried by the transaction to be executed do not meet the target voting condition.
7. The method of any of claims 1 to 5, wherein obtaining the transaction to be performed comprises:
obtaining a plurality of ordered to-be-executed transactions sent by the master node in the block chain network, wherein each to-be-executed transaction also carries: a digital signature of the vote to each voter;
wherein the master node obtains in advance a transaction to be executed by: a node in the block chain network collects multiple votes and multiple voting signatures of a plurality of voters for a certain transaction, carries out signature verification aiming at each voting signature, determines whether the transaction passes the consensus or not based on a consensus strategy corresponding to the transaction and the votes corresponding to the votes passing the signature verification, packs the transaction, the votes passing the signature verification and the votes corresponding to the votes passing the signature verification into a transaction to be executed if the transaction passes the consensus, and submits the transaction to be executed to the main node;
before determining whether the transaction to be executed passes consensus based on a target consensus strategy corresponding to the transaction to be executed and a plurality of votes carried by the transaction to be executed, the method further includes:
and performing signature verification on each voting signature carried by the transaction to be executed, and under the condition that each voting signature is determined to pass the signature verification, executing the step of determining whether the transaction to be executed passes consensus or not based on the target consensus strategy corresponding to the transaction to be executed and the plurality of votes carried by the transaction to be executed.
8. A transaction consensus apparatus applied to a node in a blockchain network, the apparatus comprising:
a transaction obtaining module, configured to obtain a transaction to be executed, where the transaction to be executed carries: a plurality of votes for the transaction to be performed, wherein each vote is used for representing whether a voter of the vote agrees to perform the transaction to be performed;
the transaction consensus module is used for determining whether the transaction to be executed passes consensus or not based on a target consensus strategy corresponding to the transaction to be executed and a plurality of votes carried by the transaction to be executed;
the transaction execution module is used for executing the transaction to be executed under the condition that the transaction to be executed passes consensus, and comprises the following steps: and determining a target consensus strategy agreed by the target intelligent contract from the target intelligent contract depended by the transaction to be executed, comparing whether the target consensus strategy corresponding to the transaction to be executed is consistent with the target consensus strategy agreed by the target intelligent contract, and refusing to continuously execute the transaction to be executed if the target consensus strategy corresponding to the transaction to be executed is not consistent with the target consensus strategy agreed by the target intelligent contract.
9. An electronic device is characterized by comprising a processor, a communication interface, a memory and a communication bus, wherein the processor and the communication interface are used for realizing mutual communication by the memory through the communication bus;
the memory is used for storing a computer program;
the processor, when executing a program stored in the memory, is adapted to perform the method steps of any of claims 1-7.
10. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the method steps of any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010897500.5A CN112037062B (en) | 2020-08-31 | 2020-08-31 | Transaction consensus method, device, electronic equipment and readable storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010897500.5A CN112037062B (en) | 2020-08-31 | 2020-08-31 | Transaction consensus method, device, electronic equipment and readable storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112037062A true CN112037062A (en) | 2020-12-04 |
| CN112037062B CN112037062B (en) | 2023-08-25 |
Family
ID=73586407
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010897500.5A Active CN112037062B (en) | 2020-08-31 | 2020-08-31 | Transaction consensus method, device, electronic equipment and readable storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112037062B (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20220393879A1 (en) * | 2021-05-25 | 2022-12-08 | Zhejiang University | Decentralized mechanism for collaboratively governing multi-agent trade ecosystem |
| CN116777631A (en) * | 2023-08-17 | 2023-09-19 | 腾讯科技（深圳）有限公司 | Transaction uplink method and device based on blockchain, equipment and medium |
Citations (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2018192931A1 (en) * | 2017-04-19 | 2018-10-25 | Calastone Limited | Delivery versus payment mechanism |
| CN108768665A (en) * | 2018-07-02 | 2018-11-06 | 上海达家迎信息科技有限公司 | Block chain generation method, device, computer equipment and storage medium |
| CN108805562A (en) * | 2017-04-27 | 2018-11-13 | 中思博安科技（北京）有限公司 | The execution method and system of intelligent contract |
| CN109284197A (en) * | 2018-10-25 | 2019-01-29 | 中思博安科技（北京）有限公司 | Distributed Application platform and implementation method based on intelligent contract |
| CN109377230A (en) * | 2018-12-11 | 2019-02-22 | 四川大学 | A kind of method and device that the intelligent contract based on digraph is realized in block chain |
| AU2019201798A1 (en) * | 2019-03-15 | 2019-04-04 | BitScan Pty Ltd | Automatically assigning cryptographic tokens to cryptocurrency wallet addresses via a smart contract in response to analysis of transaction data |
| CN109933404A (en) * | 2018-12-12 | 2019-06-25 | 阿里巴巴集团控股有限公司 | A kind of decoding method and system based on block chain intelligence contract |
| CN110009321A (en) * | 2018-12-12 | 2019-07-12 | 阿里巴巴集团控股有限公司 | A kind of transfer account method and system based on block chain intelligence contract |
| CN110264351A (en) * | 2019-05-15 | 2019-09-20 | 阿里巴巴集团控股有限公司 | Copyright distribution method and device based on block chain |
| CN110569309A (en) * | 2019-09-17 | 2019-12-13 | 上海保险交易所股份有限公司 | Apparatus, method, system, and medium for implementing blockchains |
| CN110569251A (en) * | 2019-09-23 | 2019-12-13 | 腾讯科技（深圳）有限公司 | Data processing method, related equipment and computer readable storage medium |
| CN110659907A (en) * | 2019-09-24 | 2020-01-07 | 北京海益同展信息科技有限公司 | Method and device for executing intelligent contracts |
| CN110766554A (en) * | 2019-09-29 | 2020-02-07 | 南京金宁汇科技有限公司 | Intelligent contract consensus method, system and storage medium based on multi-centralization management |
| CN111222160A (en) * | 2019-12-30 | 2020-06-02 | 联动优势(北京)数字科技有限公司 | Intelligent contract execution method and system |
| CN111275555A (en) * | 2020-02-24 | 2020-06-12 | 中国工商银行股份有限公司 | Block chain transaction processing method, transaction node and block chain system |
| CN111274612A (en) * | 2018-12-04 | 2020-06-12 | 北京京东尚科信息技术有限公司 | Practitioner trust verification method and system, witness service system and storage medium |
| CN111324396A (en) * | 2020-03-19 | 2020-06-23 | 深圳市网心科技有限公司 | Block chain intelligent contract execution method, device and equipment |
| CN111427957A (en) * | 2020-03-26 | 2020-07-17 | 财付通支付科技有限公司 | Block chain voting information verification method, device, equipment and storage medium |
-
2020
- 2020-08-31 CN CN202010897500.5A patent/CN112037062B/en active Active
Patent Citations (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2018192931A1 (en) * | 2017-04-19 | 2018-10-25 | Calastone Limited | Delivery versus payment mechanism |
| CN108805562A (en) * | 2017-04-27 | 2018-11-13 | 中思博安科技（北京）有限公司 | The execution method and system of intelligent contract |
| CN108768665A (en) * | 2018-07-02 | 2018-11-06 | 上海达家迎信息科技有限公司 | Block chain generation method, device, computer equipment and storage medium |
| CN109284197A (en) * | 2018-10-25 | 2019-01-29 | 中思博安科技（北京）有限公司 | Distributed Application platform and implementation method based on intelligent contract |
| CN111274612A (en) * | 2018-12-04 | 2020-06-12 | 北京京东尚科信息技术有限公司 | Practitioner trust verification method and system, witness service system and storage medium |
| CN109377230A (en) * | 2018-12-11 | 2019-02-22 | 四川大学 | A kind of method and device that the intelligent contract based on digraph is realized in block chain |
| CN109933404A (en) * | 2018-12-12 | 2019-06-25 | 阿里巴巴集团控股有限公司 | A kind of decoding method and system based on block chain intelligence contract |
| CN110009321A (en) * | 2018-12-12 | 2019-07-12 | 阿里巴巴集团控股有限公司 | A kind of transfer account method and system based on block chain intelligence contract |
| AU2019201798A1 (en) * | 2019-03-15 | 2019-04-04 | BitScan Pty Ltd | Automatically assigning cryptographic tokens to cryptocurrency wallet addresses via a smart contract in response to analysis of transaction data |
| CN110264351A (en) * | 2019-05-15 | 2019-09-20 | 阿里巴巴集团控股有限公司 | Copyright distribution method and device based on block chain |
| CN110569309A (en) * | 2019-09-17 | 2019-12-13 | 上海保险交易所股份有限公司 | Apparatus, method, system, and medium for implementing blockchains |
| CN110569251A (en) * | 2019-09-23 | 2019-12-13 | 腾讯科技（深圳）有限公司 | Data processing method, related equipment and computer readable storage medium |
| CN110659907A (en) * | 2019-09-24 | 2020-01-07 | 北京海益同展信息科技有限公司 | Method and device for executing intelligent contracts |
| CN110766554A (en) * | 2019-09-29 | 2020-02-07 | 南京金宁汇科技有限公司 | Intelligent contract consensus method, system and storage medium based on multi-centralization management |
| CN111222160A (en) * | 2019-12-30 | 2020-06-02 | 联动优势(北京)数字科技有限公司 | Intelligent contract execution method and system |
| CN111275555A (en) * | 2020-02-24 | 2020-06-12 | 中国工商银行股份有限公司 | Block chain transaction processing method, transaction node and block chain system |
| CN111324396A (en) * | 2020-03-19 | 2020-06-23 | 深圳市网心科技有限公司 | Block chain intelligent contract execution method, device and equipment |
| CN111427957A (en) * | 2020-03-26 | 2020-07-17 | 财付通支付科技有限公司 | Block chain voting information verification method, device, equipment and storage medium |
Non-Patent Citations (2)
| Title |
|---|
| 孙仁超: "基于区块链的微电网智能合约应用研究", 《中国优秀硕士学位论文全文数据库工程科技Ⅱ辑》, no. 04, pages 042 - 61 * |
| 戴鹏: "基于实用拜占庭共识算法（PBFT）的区块链模型的评估与改进", 《中国优秀硕士学位论文全文数据库信息科技辑》, no. 09, pages 138 - 581 * |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20220393879A1 (en) * | 2021-05-25 | 2022-12-08 | Zhejiang University | Decentralized mechanism for collaboratively governing multi-agent trade ecosystem |
| CN116777631A (en) * | 2023-08-17 | 2023-09-19 | 腾讯科技（深圳）有限公司 | Transaction uplink method and device based on blockchain, equipment and medium |
| CN116777631B (en) * | 2023-08-17 | 2023-11-24 | 腾讯科技（深圳）有限公司 | Transaction uplink method and device based on blockchain, equipment and medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112037062B (en) | 2023-08-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109815657B (en) | Identity authentication method and device based on alliance chain, computer readable storage medium and terminal equipment | |
| US20190386834A1 (en) | Blockchain management apparatus, blockchain management method, and program | |
| CN110730225A (en) | Data processing method of Internet of things based on block chain, Internet of things and storage medium | |
| CN110838065A (en) | Transaction data processing method and device | |
| CN111523890A (en) | Data processing method and device based on block chain, storage medium and equipment | |
| CN110084600B (en) | Processing and verifying method, device, equipment and medium for resolution transaction request | |
| CN109886810B (en) | Crowdsourcing transaction method and system, readable storage medium and terminal | |
| CN112037062B (en) | Transaction consensus method, device, electronic equipment and readable storage medium | |
| CN110611647A (en) | Node joining method and device on block chain system | |
| CN111431908B (en) | Access processing method and device, management server and readable storage medium | |
| CN112398949A (en) | Transaction confirmation method, system, device and computer equipment | |
| CN111224782B (en) | Data verification method based on digital signature, intelligent device and storage medium | |
| CN111260475A (en) | Data processing method, block chain node point equipment and storage medium | |
| CN112037055B (en) | Transaction processing method, device, electronic equipment and readable storage medium | |
| CN113890739B (en) | Cross-blockchain authentication method and device, electronic equipment and medium | |
| CN115829731A (en) | Transaction information processing method and device | |
| CN112396427B (en) | Cross-chain interchange operation method for general scenes | |
| CN113468276A (en) | Trusted data acquisition method and device of on-chain prediction machine and electronic equipment | |
| CN112487487A (en) | Authority management method, device, equipment and storage medium for member of block chain node | |
| CN116452135A (en) | Distributed anonymous voting method, device, equipment and medium based on Ethernet | |
| CN112465516B (en) | Block chain network-based device management method, related device and storage medium | |
| CN112039893B (en) | Private transaction processing method and device, electronic equipment and readable storage medium | |
| CN111369246B (en) | Calling authentication method and device of intelligent contract, electronic equipment and storage medium | |
| CN111988202B (en) | Node switching method, device and storage medium | |
| US20220188829A1 (en) | Transaction verification of distributed ledgers |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |