Consensus method in block chain system

Abstract

The invention provides a consensus method in a block chain system, and the method comprises the steps: carrying out the agreement of a standard timestamp for a to-be-consensus transaction set through consensus nodes, writing the standard timestamp into a block head of a block corresponding to the to-be-consensus transaction set, and carrying out the consensus of the to-be-consensus transaction set after the block is consensus-linked. The standard timestamps contained in the block heads are the time uniformly accepted by the consensus nodes, and transactions contained in the transaction sets of the blocks can be executed in sequence subsequently according to the sequence of the standard timestamps contained in the block heads of the blocks, so that global sorting of all the blocks can be realized even in a DAG-based block chain system, and the efficiency of the block chain system is improved. It can be effectively ensured that transactions in all the blocks are sequentially executed subsequently according to the sequence of all the blocks, and transaction errors cannot be caused.

Description

Technical Field

[0001] This specification relates to the field of blockchain technology, and in particular, to a consensus method in a blockchain system. Background Art

[0002] Blockchain is a new application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm. A blockchain system based on a Directed Acyclic Graph (DAG) can break the shackles of the traditional blockchain system that must serially chain data blocks into a chained data structure. That is, in a blockchain system based on DAG, a block can be used as a parent block and simultaneously referenced by other blocks, and a child block can also reference two or more parent blocks at the same time. In this way, parallel consensus in the blockchain system can be achieved, and the data processing efficiency of the blockchain system can be improved.

[0003] However, precisely because the blocks in a blockchain system based on DAG are no longer restricted to a serial chained structure, it is difficult to achieve a global sorting of all blocks. This leads to difficulties in determining in what order to execute the transactions in each block based on the sorting of the blocks subsequently, and transactions are prone to errors. Summary of the Invention

[0004] In view of this, this specification provides a consensus method in a blockchain system to solve the deficiencies in the related art.

[0005] Specifically, this specification is implemented through the following technical solutions:

[0006] According to the first aspect of the embodiments of this specification, a consensus method in a blockchain system is provided. The method is applied to a target consensus node participating in consensus in a blockchain system based on a Directed Acyclic Graph (DAG). The method includes:

[0007] The target consensus node generates a set of transactions to be consensus and sends the verifiable identifier of the set of transactions to other consensus nodes;

[0008] Collect the timestamps of a legal number of consensus nodes, including the timestamps returned by other consensus nodes. The timestamps returned by other consensus nodes are the timestamps corresponding to the time when the other consensus nodes received the verifiable identifier;

[0009] Determine a standard timestamp according to the collected timestamps of a legal number;

[0010] Write the standard timestamp into the block header of the block corresponding to the set of transactions to be consensus, and initiate consensus on the block with the standard timestamp written.

[0011] According to the second aspect of the embodiments of the present specification, a consensus method in a blockchain system is provided. The method is applied to other consensus nodes in a blockchain system based on a directed acyclic graph (DAG) except for a target consensus node. The method includes:

[0012] In response to receiving a verifiable identifier of a set of transactions to be consensus from the target consensus node, other consensus nodes return a timestamp corresponding to their own current time to the target consensus node, so that the target consensus node determines a standard timestamp according to the collected timestamps.

[0013] Receive a block header of a block corresponding to the set of transactions to be consensus sent by the target consensus node, where the standard timestamp is written in the block header of the block.

[0014] Perform consensus verification on the block according to the block header.

[0015] According to the third aspect of the embodiments of the present specification, a consensus device in a blockchain system is provided. The device is applied to a target consensus node participating in consensus in a blockchain system based on a directed acyclic graph (DAG). The device includes:

[0016] A sending module, configured to generate a set of transactions to be consensus and send a verifiable identifier of the set of transactions to be consensus to other consensus nodes.

[0017] A receiving module, configured to collect timestamps of a legal number of consensus nodes, including timestamps returned by other consensus nodes, where the timestamps returned by other consensus nodes are timestamps corresponding to the time when the other consensus nodes receive the verifiable identifier.

[0018] A determining module, configured to determine a standard timestamp according to the collected timestamps of a legal number.

[0019] A consensus module, configured to write the standard timestamp into a block header of a block corresponding to the set of transactions to be consensus and initiate consensus on the block with the standard timestamp written.

[0020] According to the fourth aspect of the embodiments of the present specification, a consensus device in a blockchain system is provided. The device is applied to other consensus nodes in a blockchain system based on a directed acyclic graph (DAG) except for a target consensus node. The device includes:

[0021] A sending module, in response to receiving a verifiable identifier of a set of transactions to be consensus sent by the target consensus node, returns a timestamp corresponding to the current time of the device itself to the target consensus node, so that the target consensus node determines a standard timestamp according to the collected timestamps.

[0022] A receiving module, configured to receive a block header of a block corresponding to a set of transactions to be consensus, where a standard timestamp is written in the block header of the block.

[0023] A consensus module, configured to perform consensus verification on the block according to the block header.

[0024] According to a fifth aspect of the embodiments of the present specification, there is provided an electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the program, the steps of the method described in the first aspect and / or the second aspect are implemented.

[0025] According to a sixth aspect of the embodiments of the present specification, there is provided a computer-readable storage medium, on which a computer program is stored. When the program is executed by a processor, the steps of the method described in the first aspect and / or the second aspect are implemented.

[0026] According to a seventh aspect of the embodiments of the present specification, there is provided a computer program product, including a computer program / instructions. When the computer program / instructions are executed by a processor, the steps of the method described in the first aspect and / or the second aspect are implemented.

[0027] In the technical solution provided in the present specification, each consensus node negotiates and agrees on a standard timestamp for the set of transactions to be consensus, and writes the standard timestamp into the block header of the block corresponding to the set of transactions to be consensus. After the block is consensus and chained, the standard timestamp included in the block header is the time uniformly recognized by each consensus node. Subsequently, the transactions included in the transaction set of each block can be executed in sequence according to the order of the standard timestamps included in the block headers of each block. In this way, even in a blockchain system based on DAG, global sorting of all blocks can be achieved, which can effectively ensure that the transactions in each block are executed sequentially according to the sorting of each block without causing transaction errors. Description of the Drawings

[0028] Figure 1 Shows the structure of each block in a DAG-based blockchain system according to an exemplary embodiment of the present specification;

[0029] Figure 2 Is a schematic flowchart of consensus in a blockchain system according to an exemplary embodiment of the present specification;

[0030] Figure 3 Is a schematic flowchart of the negotiation process according to an exemplary embodiment of the present specification;

[0031] Figure 4 Shows a schematic flowchart of a consensus method applied to other consensus nodes except the target consensus node in a DAG-based blockchain system according to an exemplary embodiment of the present specification;

[0032] Figure 5 It is a schematic structural diagram of a consensus device in a blockchain system shown in an exemplary embodiment of this specification;

[0033] Figure 6 It is a schematic structural diagram of another consensus device in a blockchain system shown in an exemplary embodiment of this specification;

[0034] Figure 7 It is a schematic structural diagram of an electronic device shown in an exemplary embodiment of this specification. Detailed implementation manners

[0035] In a traditional blockchain system, since each block is serially organized into a chain structure, the global sorting of each block is naturally achieved. When executing the transactions in each block, it only needs to execute the transactions in each block in sequence according to the sorting of each block organized in the chain structure. In a DAG-based blockchain system, each block is no longer strictly serially organized into a chain structure. Therefore, the global sorting of each block has become an urgent problem to be solved, as Figure 1 shown.

[0036] Figure 1 It is the structure of each block in a DAG blockchain system shown in an exemplary embodiment of this specification. Block A1_0 and block B1_0 are both parent blocks of block B2_0, and block A1_0 and block B2_0 are both parent blocks of block A2_0. It can be seen that in the chain (A1_0, A2_0), block A2_0 is sorted at the 2nd position, while in the chain (A1_0, B2_0, A2_0), block A2_0 is sorted at the 3rd position. Thus, it is impossible to determine in what order the transactions included in block A2_0 and block B2_0 should be executed.

[0037] Different transactions may be independent or related. The execution order of different independent transactions can be in any order, but different related transactions must be executed in a certain order, otherwise it will cause transaction errors. Figure 1 Once the execution order of the related transactions included in block A2_0 and block B2_0 shown is incorrect, it will cause transaction errors.

[0038] In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of this specification. Obviously, the described embodiments are only a part of the embodiments of this specification, rather than all the embodiments. Based on the embodiments in this specification, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of this specification.

[0039] Figure 2 This is a schematic diagram of the consensus process in a blockchain system shown in an exemplary embodiment of this specification. As Figure 2 shown, the method may include the following steps:

[0040] Step 202, the target consensus node generates a set of transactions to be consensus and sends the verifiable identifier of the set of transactions to be consensus to other consensus nodes.

[0041] Step 204, collect the timestamps of a legal number of consensus nodes, including the timestamps returned by other consensus nodes, and the timestamps returned by other consensus nodes are the timestamps corresponding to the time when other consensus nodes receive the verifiable identifier.

[0042] Step 206, determine the standard timestamp according to the collected timestamps of a legal number.

[0043] The embodiments of this specification Figure 2 The method shown is applied to the target consensus nodes participating in consensus in a DAG-based blockchain system. In step 202, any consensus node can generate a set of transactions to be consensus, and the consensus node that generates the set of transactions to be consensus is the target consensus node described in this specification. After the target consensus node generates the set of transactions to be consensus, it sends the verifiable identifier of the set of transactions to be consensus to other consensus nodes, that is, initiates Figure 2 the negotiation process of the standard timestamp shown in steps 202 - 206. Among them, the set of transactions to be consensus contains several transactions, and the verifiable identifier of the set of transactions to be consensus can be the digest or Merkle root of these transactions.

[0044] When the target consensus node initiates the negotiation process and sends the verifiable identifier of the set of transactions to be consensus generated by itself to other consensus nodes, it can be sent to other consensus nodes in the form of broadcasting, as Figure 3 shown.

[0045] In Figure 3 Node 1 is the target consensus node. After node 1 generates the set of transactions to be consensus, it broadcasts the verifiable identifier of the set of transactions to be consensus to nodes 2 - 4 at time t1.

[0046] After other consensus nodes receive the verifiable identifier sent by the target consensus node, they immediately return the timestamp corresponding to the current time of the other consensus node itself to the target consensus node, that is, return the timestamp corresponding to the time when the verifiable identifier is received to the target consensus node. Then in step 204, the timestamps collected by the target consensus node include the timestamps returned by other consensus nodes.

[0047] As Figure 3 shown, inFigure 3 Among them, the receiving times of nodes 2-4 for the verifiable identifier sent by node 1 are not the same. Nodes 2-4 received the verifiable identifier sent by node 1 at times t2, t3, and t4 respectively. Then node 2 returns its own timestamp t2 to node 1. Similarly, nodes 3 and 4 also return their own timestamps t3 and t4 to node 1 respectively.

[0048] In addition, in step 204, the timestamps collected by the target consensus node also include the timestamps corresponding to the times when the target consensus node broadcasts the verifiable identifier to other consensus nodes in step 202. Then in step 206, after the target consensus node receives the respective timestamps returned by other consensus nodes, it can determine the standard timestamp based on the timestamp corresponding to the time when it sends the verifiable identifier to other consensus nodes in step 202 and the timestamps returned by other consensus nodes received.

[0049] Specifically, the target consensus node can sort the timestamp corresponding to the time when the target consensus node sends the verifiable identifier to other consensus nodes in step 202 and the timestamps returned by each other consensus node received in step 204 in chronological order, and determine the standard timestamp according to the sorting result. Further, the target consensus node can determine the median timestamp in the sorting result as the standard timestamp.

[0050] Of course, other methods can also be used to determine the standard timestamp. For example, according to the sorting result, the average timestamp is determined as the standard timestamp. The following only takes the determination of the median timestamp as the standard timestamp as an example for illustration.

[0051] Step 208, write the standard timestamp into the block header of the block corresponding to the transaction set to be consensus, and initiate consensus on the block with the standard timestamp written.

[0052] As Figure 3 shown, after the target consensus node determines the standard timestamp through step 206, it can generate a block containing the transaction set to be consensus (i.e., the block corresponding to the transaction set to be consensus), write the determined standard timestamp into the block header of the block, and then send the block to other consensus nodes to initiate consensus on the block.

[0053] Specifically, the target consensus node can write the timestamp corresponding to the time when it sends the verifiable identifier to other consensus nodes in step 202, the timestamps returned by each other consensus node received in step 204, and the standard timestamp determined in step 206 into the block header of the block corresponding to the transaction set to be consensus, and send it to other consensus nodes in the form of broadcast, so that other consensus nodes can perform consensus verification on the block accordingly.

[0054] Among them, the timestamps returned by other consensus nodes received by the target consensus node in step 204 are the timestamps signed by the other consensus nodes respectively. Correspondingly, when the target consensus node writes the standard timestamp and the timestamp corresponding to the time when the verifiable identifier is sent in step 202 into the block header of the block corresponding to the transaction set to be consensus, it also needs to sign the standard timestamp and the timestamp corresponding to the time when the verifiable identifier is sent to other consensus nodes, and then write the signed standard timestamp, the signed timestamp corresponding to the time when the verifiable identifier is sent, and the timestamps signed by the other consensus nodes returned by the other consensus nodes into the block header of the block corresponding to the transaction set to be consensus.

[0055] Further, when other consensus nodes receive the block and perform consensus verification on the block, they can first verify the signatures of the standard timestamp signed by the target consensus node, the timestamp corresponding to the time when the verifiable identifier is sent signed by the target consensus node, and the timestamp signed by the other consensus nodes returned to the target consensus node included in the block header. If the signature verification of at least one timestamp fails, the verification fails. It can also verify whether the timestamp actually sent to the target consensus node by itself in step 204 is included in the block header of the block. If it is not included, the verification fails. It can also re-determine a standard timestamp according to the timestamp corresponding to the time when the target consensus node sends the verifiable identifier in step 202 and the timestamps returned by each other consensus node received by the target consensus node in step 204, and verify whether the standard timestamp re-determined by itself is consistent with the standard timestamp determined by the target consensus node included in the block header in step 206. If they are not consistent, the verification fails.

[0056] After performing consensus verification on the standard timestamp included in the block, other DAG consensus verifications can be continued on the block until a verification result is obtained, and the block is processed according to the verification result.

[0057] The above method allows each consensus node to negotiate and agree on a standard timestamp for the block corresponding to the transaction set to be consensus, and write the standard timestamp into the block. After each block is consensus-linked, the standard timestamps included in each block are the times uniformly recognized by each consensus node. Subsequently, the transactions in the transaction set included in each block can be executed in sequence according to the order of the standard timestamps included in each block. In this way, even in a DAG-based blockchain system, global sorting of all blocks can be achieved, which can effectively ensure that the transactions in each block are executed sequentially according to the sorting of each block without causing transaction errors.

[0058] In addition, through the above method, in the case of having n consensus nodes, as long as the number of consensus nodes with malicious behavior does not exceed f = |(n - 1) / 3|, attacks can be resisted. Therefore, in step 204, the target consensus node does not need to collect the timestamps returned by all other consensus nodes to determine the standard timestamp. As long as it collects a legal number of timestamps (the legal number of timestamps includes the timestamp corresponding to the time when the target consensus node itself sends the verifiable identifier), it can directly determine the standard timestamp based on these legal number of timestamps. In the above case, the legal number is 2f + 1. That is to say, the target consensus node only needs to receive the timestamps returned by 2f other consensus nodes, and can directly determine the median timestamp as the standard timestamp based on these 2f timestamps and the timestamp corresponding to the time when it sends the verifiable identifier to other consensus nodes in step 202. As Figure 3 shown, in Figure 3 , there are a total of 4 nodes, that is, n = 4, then f = 1, and the legal number 2f + 1 = 3. Therefore, as long as node 1 receives the timestamps returned by 2 other nodes, it can execute step 206 to determine the standard timestamp. Since in Figure 3 , node 1 first receives t2 and then receives t3. Therefore, when node 1 receives t3, it can sort according to the timestamp t1 corresponding to the time when it sends the verifiable identifier itself and the timestamps t2 and t3 returned by node 2 and node 3 respectively that it receives, and get (t1, t3, t2), and finally get the median timestamp t3 as the standard timestamp.

[0059] When discovering a consensus node with malicious behavior (hereinafter referred to as a malicious node) through the above formula method, the consensus nodes without malicious behavior (hereinafter referred to as normal nodes) in the DAG-based blockchain system can also initiate an abnormal handling process for the malicious node. The abnormal handling process described in this specification includes but is not limited to: the normal node freezes the virtual resources of the malicious node; the normal node distributes the virtual resources of the malicious node to other blockchain accounts or normal nodes.

[0060] Figure 4 is a schematic flowchart of a consensus method applied to other consensus nodes except the target consensus node in a DAG-based blockchain system shown in an exemplary embodiment of this specification. As Figure 4 shown, the method may include the following steps:

[0061] Step 402, in response to receiving the verifiable identifier of the set of transactions to be consensus sent by the target consensus node, other consensus nodes return the timestamp corresponding to their own current time to the target consensus node, so that the target consensus node determines the standard timestamp based on the collected timestamps.

[0062] Step 404: Receive the block header of the block corresponding to the set of transactions to be consensus, where the standard timestamp is written in the block header of the block.

[0063] Step 406: Perform consensus verification on the block according to the block header.

[0064] Among them, steps 402 - 406 have been correspondingly explained in the description of steps 202 - 208 shown in Figure 2 and will not be elaborated here one by one.

[0065] Figure 5 is a schematic structural diagram of a consensus device in a blockchain system shown in an exemplary embodiment of this specification. As Figure 5 shown, the device is applied to a target consensus node participating in consensus in a blockchain system based on a directed acyclic graph (DAG), and the device includes:

[0066] A sending module 501, configured to generate a set of transactions to be consensus and send the verifiable identifier of the set of transactions to be consensus to other consensus nodes;

[0067] A receiving module 502, configured to collect timestamps of a legal number of consensus nodes, including timestamps returned by other consensus nodes, where the timestamps returned by other consensus nodes are the timestamps corresponding to the time when the other consensus nodes received the verifiable identifier;

[0068] A determining module 503, configured to determine a standard timestamp according to the collected timestamps of a legal number;

[0069] A consensus module 504, configured to write the standard timestamp into the block header of the block corresponding to the set of transactions to be consensus and initiate consensus on the block with the standard timestamp written in.

[0070] Optionally, the receiving module 502 is specifically configured to collect the timestamp corresponding to the time when the target consensus node sends the verifiable identifier to other consensus nodes and the timestamps returned by other consensus nodes;

[0071] The legal number is 2f + 1, where n is the number of consensus nodes participating in consensus in the DAG - based blockchain system.

[0072] Optionally, the determining module 503 is specifically configured to sort the collected timestamps of a legal number in chronological order by the target consensus node; determine the median timestamp in the sorting result as the standard timestamp.

[0073] Optionally, the consensus module 504 is specifically configured to write the standard timestamp and the legally required number of collected timestamps into the block header of the block corresponding to the set of transactions to be consensus.

[0074] Optionally, the timestamps returned by the other consensus nodes are the timestamps signed by the other consensus nodes respectively;

[0075] The consensus module 504 is specifically configured to sign the standard timestamp and the timestamp corresponding to the time when the verifiable identifier is sent to the other consensus nodes, and write the signed standard timestamp, the signed timestamp corresponding to the time when the verifiable identifier is sent to the other consensus nodes, and the timestamps returned by the other consensus nodes received into the block header of the block corresponding to the set of transactions to be consensus.

[0076] Figure 6 It is a schematic structural diagram of a consensus device in another blockchain system shown in an exemplary embodiment of this specification. As Figure 6 shown, the device is applied to other consensus nodes except the target consensus node in a blockchain system based on a directed acyclic graph (DAG), and the device includes:

[0077] A sending module 601, in response to receiving the verifiable identifier of the set of transactions to be consensus sent by the target consensus node, returns the timestamp corresponding to the current time of the other consensus node itself to the target consensus node, so that the target consensus node determines the standard timestamp according to the collected timestamps;

[0078] A receiving module 602, configured to receive the block header of the block corresponding to the set of transactions to be consensus sent by the target consensus node, where the standard timestamp is written in the block header of the block;

[0079] A consensus module 603, configured to perform consensus verification on the block according to the block header.

[0080] Optionally, the sending module 601 is specifically configured to sign the timestamp corresponding to the current time of the other consensus node itself; return the signed timestamp to the target consensus node

[0081] Optionally, the standard timestamp written in the block header of the block is the standard timestamp signed by the target consensus node;

[0082] The timestamp corresponding to the time when the verifiable identifier is sent to the other consensus nodes signed by the target consensus node and the signed timestamp returned by the other consensus nodes to the target consensus node are also written in the block header of the block;

[0083] The consensus module 603 is specifically configured to verify the signatures of the standard timestamp signed by the target consensus node included in the block header, the timestamp corresponding to the time when the target consensus node sends the verifiable identifier to the other consensus nodes after signing, and the timestamp signed and returned by the other consensus nodes to the target consensus node; after the signature verification passes, at least verify the standard timestamp according to the standard timestamp, the timestamp corresponding to the time when the target node sends the verifiable identifier to the other consensus nodes, and the timestamp returned by the other consensus nodes to the target consensus node.

[0084] The above Figure 5 and Figure 6 The implementation processes of the functions and roles of each unit in the device are specifically described in detail in the implementation processes of the corresponding steps in the above method, and will not be elaborated here.

[0085] Figure 7 is a schematic structural diagram of an electronic device in an exemplary embodiment. Please refer to Figure 7 , at the hardware level, the electronic device includes a processor, an internal bus, a network interface, a memory, and a non-volatile memory. Of course, other required hardware may also be included. The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it, forming a consensus device in the blockchain system at the logical level. Of course, in addition to the software implementation method, this specification does not exclude other implementation methods, such as logical devices or a combination of software and hardware, etc. That is to say, the execution subject of the following processing flow is not limited to each logical unit, and can also be hardware or a logical device.

[0086] Based on the same concept as the above method, this specification also provides an electronic device, including: a processor; a memory for storing executable instructions that can be executed by the processor; wherein, the processor realizes the steps of the method as described in any of the above embodiments by running the executable instructions.

[0087] Based on the same concept as the above method, this specification also provides a computer-readable storage medium, on which computer instructions are stored, and when the instructions are executed by a processor, the steps of the method as described in any of the above embodiments are realized.

[0088] Based on the same concept as the above method, this specification also provides a computer program product, including a computer program / instructions, and when the computer program / instructions are executed by a processor, the steps of the method as described in any of the above embodiments are realized.

Claims

1. A consensus method in a blockchain system, the method being applied to a target consensus node participating in consensus in a blockchain system based on a directed acyclic graph (DAG), the method comprising: The target consensus node generates a set of transactions to be agreed upon, and sends a verifiable identifier of the set of transactions to be agreed upon to other consensus nodes; Collecting timestamps of a quorum of consensus nodes, including timestamps returned by other consensus nodes, where the timestamps returned by other consensus nodes are timestamps corresponding to the time when the other consensus nodes received the verifiable identifier; Determine a standard timestamp based on the timestamps of a quorum of collected timestamps; The standard timestamp is written into the block header of the block corresponding to the set of transactions to be agreed upon, and consensus is initiated on the block with the standard timestamp written into it.

2. The method of claim 1, collecting timestamps of a quorum of consensus nodes, specifically comprising: Collect the timestamp corresponding to the time when the target consensus node sends the verifiable identifier to other consensus nodes and the timestamp returned by the other consensus nodes; The quorum is 2f+1, where n is the number of consensus nodes participating in the consensus in the DAG-based blockchain system.

3. The method of claim 1, wherein determining a standard timestamp based on a legal number of collected timestamps comprises: The target consensus node sorts the collected timestamps of the quorum in chronological order; Determine the median timestamp in the sorted results as the standard timestamp.

4. The method according to claim 1, writing the standard timestamp into the block header of the block corresponding to the set of transactions to be agreed upon, specifically comprising: The standard timestamp and the collected timestamps of the legal number are written into the block header of the block corresponding to the set of transactions to be agreed upon.

5. According to the method of claim 4, the timestamp returned by the other consensus nodes is the timestamp signed by the other consensus nodes; Writing the standard timestamp and the collected legal number of timestamps into the block header of the block corresponding to the set of transactions to be agreed upon specifically includes: The standard timestamp and the timestamp corresponding to the time when the verifiable identifier is sent to the other consensus nodes are signed, and the signed standard timestamp, the signed timestamp corresponding to the time when the verifiable identifier is sent to the other consensus nodes, and the timestamp returned by the other consensus nodes are written into the block header of the block corresponding to the set of transactions to be agreed upon.

6. A consensus method in a blockchain system, the method being applied to other consensus nodes other than a target consensus node in a blockchain system based on a directed acyclic graph (DAG), the method comprising: In response to the verifiable identifier of the set of transactions to be agreed upon sent by the target consensus node, the other consensus nodes return the timestamp corresponding to the current time of the other consensus nodes themselves to the target consensus node, so that the target consensus node determines the standard timestamp according to the collected timestamps; Receive a block header of a block corresponding to the set of transactions to be agreed upon sent by the target consensus node, wherein the block header of the block has the standard timestamp written in it; The block is subjected to consensus verification according to the block header.

7. The method according to claim 6, returning the timestamp corresponding to the current time of the other consensus nodes themselves to the target consensus node, specifically comprising: Signing the timestamp corresponding to the current time of the other consensus nodes themselves; The signed timestamp is returned to the target consensus node.

8. The method as claimed in claim 7, wherein the standard timestamp written in the block header of the block is the standard timestamp signed by the target consensus node; The block header of the block also contains a timestamp corresponding to the time when the target consensus node sends the verifiable identifier to the other consensus nodes after signing, and a timestamp after signing returned by the other consensus nodes to the target consensus node; The consensus verification of the block includes: Verify the standard timestamp signed by the target consensus node contained in the block header, the timestamp corresponding to the time when the target consensus node sends the verifiable identifier to the other consensus nodes after signing, and the timestamp signed by the other consensus nodes returned to the target consensus node; After the signature verification is passed, at least the standard timestamp is verified according to the standard timestamp, the timestamp corresponding to the time when the target node sends the verifiable identifier to the other consensus nodes, and the timestamp returned by the other consensus nodes to the target consensus node.

9. A consensus device in a blockchain system, the device being applied to a target consensus node participating in consensus in a blockchain system based on a directed acyclic graph (DAG), the device comprising: A sending module, used to generate a set of transactions to be agreed upon, and send a verifiable identifier of the set of transactions to be agreed upon to other consensus nodes; A receiving module, configured to collect timestamps of a quorum of consensus nodes, including timestamps returned by other consensus nodes, where the timestamps returned by other consensus nodes are timestamps corresponding to the time when the other consensus nodes received the verifiable identifier; a determination module for determining a standard timestamp based on a quorum of collected timestamps; The consensus module is used to write the standard timestamp into the block header of the block corresponding to the transaction set to be agreed upon, and initiate consensus on the block with the standard timestamp written into it.

10. A consensus device in a blockchain system, the device being applied to other consensus nodes other than a target consensus node in a blockchain system based on a directed acyclic graph (DAG), the device comprising: A sending module, in response to receiving a verifiable identifier of the set of transactions to be agreed upon sent by the target consensus node, returns a timestamp corresponding to the current time of the device itself to the target consensus node, so that the target consensus node determines a standard timestamp according to the collected timestamp; A receiving module, configured to receive a block header of a block corresponding to the set of transactions to be agreed upon sent by the target consensus node, wherein the block header of the block has the standard timestamp written therein; A consensus module is used to perform consensus verification on the block according to the block header.

11. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of any one of the methods of claims 1 to 8 when executing the program.

12. A computer-readable storage medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the steps of the method according to any one of claims 1 to 8.

13. A computer program product, comprising a computer program / instruction, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 8.

Images