Consensus processing method and device in block chain system

Abstract

The invention discloses a consensus processing method in a block chain system. The method is applied to any target consensus node participating in consensus in the block chain system. Wherein a consensus protocol operated by a consensus node participating in consensus in the block chain system is a hashgraph consensus protocol; comprising the steps of obtaining verification information corresponding to a target event; the target event is used for accommodating a transaction list proposed by the target consensus node; the running consistency broadcast algorithm broadcasts and sends verification messages containing the verification information to other consensus nodes, and collects response messages which are returned by other consensus nodes through the running consistency broadcast algorithm and aim at the verification messages; the response message comprises a signature submitted by other consensus nodes for the target event after validity verification of the target event based on the verification information is passed; and in response to the collected at least Quorum response messages, generating a target event, and running a hashgraph consensus protocol to initiate consensus processing for the target event.

Description

Technical Field

[0001] The embodiments of this specification belong to the field of blockchain, and more particularly to a consensus processing method and device in a blockchain system. Background Art

[0002] In the blockchain field, there is a type of consensus protocol driven by master nodes. In this type of consensus protocol, there is usually only one master node in each round of consensus, and the only master node initiates the consensus proposal; for example, the PBFT protocol and the HotStuff protocol are this type of consensus protocol driven by master nodes.

[0003] Different from the consensus protocols driven by master nodes, the Hashgraph consensus protocol does not distinguish between master and slave nodes participating in the consensus. Each consensus node can actively initiate consensus on transactions.

[0004] Moreover, the Hashgraph consensus protocol no longer uses a block structure to accommodate transactions proposed by consensus nodes, but instead uses a data structure called events to accommodate transactions proposed by consensus nodes. It also maintains a hash graph locally on the consensus node to record all events published by all consensus nodes participating in the consensus in the blockchain system in each consensus round, as well as the relationship between these events.

[0005] In addition, compared with the traditional master node-driven consensus protocol, the Hashgraph consensus protocol also has obvious differences in the communication mechanism and consensus voting method adopted.

[0006] On the one hand, based on the Hashgraph consensus protocol, each consensus node can exchange event information with other consensus nodes by running the gossip protocol. Among them, unlike the traditional communication mechanism, the gossip protocol adopts a special communication mechanism that draws on the characteristics of rumor propagation. Based on the gossip protocol, the consensus node can randomly select a consensus node as a communication partner, exchange all the latest events received between the consensus nodes, and repeat the above process. By continuously communicating between the consensus nodes, all events released by the consensus nodes in a certain consensus round will eventually gradually spread to each consensus node and be recorded in the hash map maintained locally by each consensus node, so that all consensus nodes will record exactly the same set of events on the hash map maintained locally.

[0007] On the other hand, based on the Hashgraph consensus protocol, by running the virtual voting mechanism unique to the Hashgraph consensus protocol, the consensus voting results corresponding to any given event can be independently calculated on the hash graph maintained locally by the consensus node, without the need to exchange voting messages with other consensus nodes.

[0008] For example, the virtual voting mechanism based on the Hashgraph consensus protocol usually runs three algorithms, namely "DivideRound", "DecideFame" and "FindOrder", on the hash graph maintained locally by the consensus node to sort each event recorded on the locally maintained hash graph and reach a consensus.

[0009] However, in a blockchain system running the Hashgraph consensus protocol, once a malicious consensus node publishes a malicious event in a consensus round, based on the special communication mechanism adopted by the gossip protocol, the malicious event usually cannot spread quickly to each consensus node in a short period of time. This may cause the consensus node to continue to run subsequent virtual voting mechanisms based on a malicious event, thereby affecting the overall consensus performance and efficiency of the blockchain system, and even threatening the stability of the blockchain system. Summary of the invention

[0010] This specification proposes a consensus processing method in a blockchain system, which is applied to any target consensus node participating in the consensus in the blockchain system; wherein the consensus protocol run by the consensus node participating in the consensus in the blockchain system is the hashgraph consensus protocol; the method comprises:

[0011] Acquire verification information corresponding to a target event to be published; wherein the target event is used to contain a list of transactions proposed by the target consensus node; and the verification information is used to verify the validity of the target event;

[0012] Running a consistency broadcast algorithm to broadcast a verification message containing the verification information to other consensus nodes, and collecting response messages to the verification message returned by the other consensus nodes by running the consistency broadcast algorithm; wherein the response message includes the signature submitted by the other consensus nodes for the target event after the validity verification for the target event based on the verification information is passed;

[0013] In response to collecting at least a Quorum of the response messages, the target event is generated, and the hashgraph consensus protocol is run to initiate consensus processing for the target event.

[0014] Optionally, the data structure of the target event includes an event header and event content; wherein the event header includes the verification information;

[0015] generating an event header corresponding to the target event based on the verification information;

[0016] The consistency broadcast algorithm is run to broadcast a verification message including the event header to other consensus nodes.

[0017] Optionally, the verification information is used to verify whether the target event is the only event proposed by the target consensus node in the same consensus round;

[0018] Conduct validity verification for the target event, including:

[0019] Based on the verification information, verify whether the target event is the only event proposed by the target consensus node in the same consensus round; if the target event is the only event proposed by the target consensus node in the same consensus round, determine that the validity verification of the target event is passed.

[0020] Optionally, the verification information includes: a node identifier of the target consensus node, a hash value of a root node of a Merkle tree constructed based on hash values ​​of transactions in a transaction list contained in the target event, and a timestamp corresponding to a creation time of the target event;

[0021] Determining a consensus round corresponding to the target event based on the timestamp information;

[0022] Determine whether an event header of another event broadcasted by the target consensus node has been received in the consensus round; wherein the hash value of the root node of the Merkle tree constructed based on the hash value of the transaction in the transaction list contained in the other event and contained in the event header of the other event is different from the hash value of the root node of the Merkle tree contained in the event header of the target event;

[0023] If no event header of other events published by the target consensus node has been received in the consensus round, it is determined that the target event is the only event proposed by the target consensus node in the same consensus round.

[0024] Optionally, the verification information further includes a latest event set maintained in a local hash map of the target consensus node; the latest event set is an event set recorded in the local hash map and consisting of the latest events published by other consensus nodes;

[0025] If no event header of other events published by the target consensus node has been received in the consensus round, determining that the target event is the only event proposed by the target consensus node in the same consensus round includes:

[0026] If no event headers of other events published by the target consensus node have been received in this consensus round, further verify whether the latest event set maintained in the local hash map is consistent with the latest event set maintained in the local hash map of the target consensus node; if so, determine that the target event is the only event proposed by the target consensus node in the same consensus round.

[0027] Optionally, generating the target event includes:

[0028] Generate a certificate corresponding to the target event based on at least a Quorum of the response messages; wherein the certificate is used to indicate that the target event has passed the validity verification;

[0029] A data structure of the target event is created based on the generated event header, and the transaction list proposed by the target consensus node and the proof are added to the data structure as event content contained in the target event.

[0030] Optionally, the hashgraph consensus protocol no longer uses the gossip protocol to publish events to other consensus nodes;

[0031] Run the hashgraph consensus protocol to initiate consensus processing for the target event, including:

[0032] The generated target event is broadcasted to the other consensus nodes so that the other consensus nodes can verify the proof contained in the data structure of the target event; if the verification of the proof is passed, the target event is added to its local hash graph, and the virtual voting mechanism of the hashgraph consensus protocol continues to run, and the parent events of each latest event contained in the latest event set are iteratively traced on the hash graph to obtain the latest parent event set, and on the basis of the latest parent event set obtained by tracing, the target event added to the local hash graph is virtually voted to complete the consensus processing of the target event.

[0033] Optionally, the proof is a response message set consisting of at least a Quorum of the response messages;

[0034] Verifying the proof contained in the data structure of the target event includes:

[0035] Verifying signatures contained in at least a Quorum of the response messages contained in the data structure of the target event;

[0036] If the signatures included in at least a quorum of the response messages are verified successfully, it is determined that the verification of the certificate is successful.

[0037] Optionally, the verification message further includes a hash value of the verification information; the signature submitted for the target event is a signature submitted for the hash value of the verification information included in the verification message;

[0038] Before verifying whether the target event is the only event proposed by the target consensus node in the same consensus round based on the verification information, the method further includes:

[0039] Calculate a hash value of the verification information contained in the verification message, and determine whether the calculated hash value is the same as the hash value of the verification information contained in the verification message; if so, further verify based on the verification information whether the target event is the only event proposed by the target consensus node in the same consensus round.

[0040] Optionally, the consistency broadcast algorithm includes a Reiter broadcast algorithm.

[0041] This specification also proposes a consensus processing device in a blockchain system, the device is applied to any target consensus node participating in the consensus in the blockchain system; wherein the consensus protocol run by the consensus node participating in the consensus in the blockchain system is the hashgraph consensus protocol; the device comprises:

[0042] An acquisition module, which acquires verification information corresponding to a target event to be published; wherein the target event is used to contain a list of transactions proposed by the target consensus node; and the verification information is used to perform validity verification on the target event;

[0043] A collection module, which runs a consistency broadcast algorithm to broadcast a verification message containing the verification information to other consensus nodes, and collects response messages to the verification message returned by the other consensus nodes by running the consistency broadcast algorithm; wherein the response message includes a signature submitted by the other consensus nodes for the target event after the validity verification for the target event based on the verification information is passed;

[0044] The consensus module, in response to collecting at least a Quorum of the response messages, generates the target event and runs the hashgraph consensus protocol to initiate consensus processing for the target event.

[0045] In the above embodiment, by optimizing the process of generating new events by the hashgraph consensus protocol, a mechanism for pre-validation of the target event based on the consistency broadcast algorithm is introduced before generating the target event to be published, so that the consensus node running the Hashgraph consensus protocol can only create and publish the target event after the majority of the consensus nodes have passed the validity verification for the target event, thereby preventing the consensus node running the Hashgraph consensus protocol from generating malicious events at the source. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0047] Figure 1 It is a flow chart of a consensus processing method in a blockchain system shown in an embodiment of this specification;

[0048] Figure 2 It is a schematic diagram of a hash graph maintained locally by a consensus node shown in an embodiment of this specification;

[0049] Figure 3 is a schematic structural diagram of an electronic device shown in an embodiment of this specification;

[0050] Figure 4 It is a block diagram of consensus processing in a blockchain system shown in one embodiment of this specification. DETAILED DESCRIPTION

[0051] 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 described clearly and completely below in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this specification.

[0052] The purpose of the specification is to propose a technical solution that introduces a mechanism for pre-validation of the events to be generated in the hashgraph consensus protocol, thereby preventing the consensus nodes from generating malicious events at the source.

[0053] See also Figure 1 , Figure 1This is a flowchart of a consensus processing method in a blockchain system shown in this specification, and the method is applied to any target consensus node participating in the consensus in the blockchain system; wherein the consensus protocol run by the consensus nodes participating in the consensus in the blockchain system is the hashgraph consensus protocol; the method includes the following execution process:

[0054] Step 102: Acquire verification information corresponding to the target event to be published; wherein the target event is used to contain a list of transactions proposed by the target consensus node; and the verification information is used to verify the validity of the target event;

[0055] In this specification, the process of generating new events in the hashgraph consensus protocol can be transformed, and a mechanism for pre-validating the validity of the target event is introduced before the consensus node generates a new target event.

[0056] The above-mentioned target consensus node running the hashgraph consensus protocol can first obtain verification information corresponding to the target event to be published before generating the target event to be published.

[0057] The verification information is specifically information used to verify the validity of the target event. In practical applications, the verification information may specifically include any form of information used to verify the validity of the target event.

[0058] It should be noted that the type of information included in the verification information usually corresponds to the verification requirement for the validity verification of the target event. Under different validity verification requirements, the specific type of information included in the verification information may also be different.

[0059] In one embodiment shown, the validity verification may specifically include a verification process to confirm whether the target event is the only event proposed by the target consensus node in the same consensus round; that is, through the validity verification, it can be confirmed whether the target consensus node has malicious behavior of proposing multiple different events in the same consensus round. Accordingly, the verification information may specifically include any form of information for verifying whether the target event is the only event proposed by the target consensus node in the same consensus round.

[0060] For example, in one example, based on the hashgraph consensus protocol, the information used to verify whether the target event is the only event proposed by the above-mentioned target consensus node in the same consensus round may generally include the following information: the node identifier of the above-mentioned target consensus node, the hash value of the root node of the Merkle tree constructed based on the hash value of the transaction in the transaction list accommodated by the target event, the timestamp corresponding to the creation time of the target event, and the like.

[0061] In another example, the information used to verify whether the target event is the only event proposed by the target consensus node in the same consensus round may include, in addition to the information listed above, the latest event set maintained in the local hash map of the target consensus node; wherein the latest event set specifically refers to the event set recorded in the local hash map of the target consensus node and consisting of the latest events released by other consensus nodes.

[0062] Of course, the above-mentioned validity verification, in addition to the verification process of confirming whether the target event is the only event proposed by the above-mentioned target consensus node in the same consensus round, in practical applications, it can obviously also include other forms of verification processes related to the validity of the target event.

[0063] For example, the verification process of confirming whether the event content contained in the target event has been tampered with, the verification process of confirming whether the target event is a repeated event that has been completed by consensus, the verification process of determining whether the target event belongs to the event of the consensus round currently being executed, etc., will not be listed one by one in this manual.

[0064] Step 104: Run the consistency broadcast algorithm to broadcast a verification message containing the verification information to other consensus nodes, and collect response messages to the verification message returned by the other consensus nodes by running the consistency broadcast algorithm; wherein the response message includes the signature submitted by the other consensus nodes for the target event after the validity verification based on the verification information for the target event is passed;

[0065] In this specification, the mechanism for pre-validation of the above-mentioned target events introduced in the hashgraph consensus protocol may specifically be a validity verification mechanism implemented by the consensus node based on a consistent broadcast algorithm.

[0066] It should be noted that the above-mentioned consensus broadcast algorithm mentioned in this specification can specifically refer to a type of algorithm that can ensure that all normal nodes can eventually receive the same message set in a distributed system with Byzantine nodes (which can be malicious nodes or faulty nodes), and the messages contained in these message sets can be processed by each normal node in the same order. The specific algorithm type of the above-mentioned consensus broadcast algorithm is not particularly limited in this specification.

[0067] For example, in one implementation, the above consistency broadcast algorithm may specifically be the Reiter broadcast algorithm, which is an algorithm proposed by Reiter in 1994 to solve the Byzantine Generals Problem.

[0068] After obtaining the verification information corresponding to the target event, the target consensus node may run the consistency broadcast algorithm to broadcast a verification message containing the verification information to other consensus nodes.

[0069] In this specification, in addition to the mechanism for pre-validation of the above-mentioned target events introduced in the hashgraph consensus protocol, the data structure of the events supported by the hashgraph consensus protocol can also be modified.

[0070] For example, the data structure of events supported by the traditional hashgraph consensus protocol is usually as follows:

[0071] Event{self-parent, other-parent, timestamp, transaction list, eventash…}

[0072] In the above data structure, self-parent represents the latest event (i.e., the previous event) created by the same consensus node before creating this event; other-parent represents the latest event created by other consensus nodes and received by the consensus node from other consensus nodes before creating this event; Timestamp represents the timestamp corresponding to the moment when the event was created; transaction list represents the transaction list contained in the event; event hash represents the hash value calculated based on the event content of the event.

[0073] In this specification, the data structure of the events supported by the hashgraph consensus protocol can be modified based on the above data structure of the events supported by the hashgraph consensus protocol.

[0074] In one embodiment shown, the events supported by the hashgraph consensus protocol can be transformed into the following data structure:

[0075] Event{event_head, event_date}

[0076] In the above data structure, event_head represents the event header of the event; event_date represents the event content of the event; wherein, event_head may specifically include the above verification information; and event_date may specifically include the transaction list proposed by the consensus node that created the event.

[0077] In this case, after obtaining the verification information corresponding to the target event, the target consensus node can generate an event header corresponding to the target event based on the obtained verification information, and then run the consistency broadcast algorithm to broadcast a verification message containing the event header to other consensus nodes.

[0078] In one embodiment shown, the data structure of the event_head may be as follows:

[0079] event_head(creator, parent_list(creator), timestamp, merkle_root(transaction lists), event_hash…)

[0080] In the above data structure, creator represents the node representation of the target consensus node that creates the event; parent_list(creator) represents the latest event set maintained in the local hash graph of the above target consensus node; wherein the latest event set specifically refers to the event set consisting of the latest events released by other consensus nodes and recorded in the local hash graph of the target consensus node; the latest event set can replace self-parent and other-parent contained in the data structure of events supported by the traditional hashgraph consensus protocol as the parent event list of the event; timestamp represents the timestamp corresponding to the moment when the above target consensus node creates the event; merkle_root(transaction lists) represents the hash value of the root node of the Merkle tree constructed based on the hash value of the transaction in the transaction list contained in the event; event_hash represents the hash value of the event; for example, event_hash can be represented by a hash value calculated as a whole using all the information contained in the event header, such as creator, parent_list(creator), timestamp, merkle_root(transaction lists), etc.

[0081] In practical applications, the fields contained in the event_head data structure can be flexibly increased or decreased based on specific needs, and are not specifically limited in this specification. For example, in one example, the timestamp can be replaced with a round identifier of a consensus round.

[0082] It should be emphasized that the data structure of the events supported by the modified hashgraph consensus protocol described in the above example no longer needs to include self-parent and other-parent, compared with the data structure of the events supported by the traditional hashgraph consensus protocol, but can instead include the above-mentioned parent_list(creator).

[0083] Since each event stored in the hash graph of the traditional hashgraph consensus protocol needs to establish a relationship with self-parent and other-parent, the in-degree of each event stored in the hash graph of the traditional hashgraph consensus protocol is 2. If parent_list(creator) is used to replace self-parent and other-parent in the data structure of the transformed event, since parent_list(creator) is usually a list containing N latest events, the transformed event described above needs to establish a relationship with each parent event contained in the parent_list(creator) after being recorded on the hash graph. In this case, the in-degree of each event stored in the hash graph will be expanded from 2 to N. In-degree is an important concept in graph theory, which refers to the number of edges pointing to a vertex.

[0084] The above-mentioned target consensus node broadcasts a verification message containing the above-mentioned verification information to other consensus nodes by running the above-mentioned consistency broadcast algorithm. After receiving the verification message, other consensus nodes can obtain the verification information contained in the verification message, and then perform validity verification on the above-mentioned target event based on the verification information.

[0085] After the validity verification of the target event is passed, a signature can be submitted for the target event, indicating that the target event is recognized as a valid event. Then, a response message containing the signature can be constructed, and then the response message can be returned to the target consensus node by running the above-mentioned consistency broadcast algorithm. The method of returning the above-mentioned response message to the above-mentioned target consensus node can still be broadcast, or other message propagation methods other than broadcast can be used; for example, unicast or multicast.

[0086] After the target consensus node broadcasts a verification message containing the verification information to other consensus nodes by running the consistency broadcast algorithm, it can also collect response messages returned by other consensus nodes, and confirm the recognition of the target event by other consensus nodes based on the signatures contained in the collected response messages.

[0087] In one embodiment shown, the validity verification may specifically include a verification process to confirm whether the target event is the only event proposed by the target consensus node in the same consensus round; that is, through the validity verification, it can be confirmed whether the target consensus node has proposed malicious behavior of multiple different events at the same time in the same consensus round. Accordingly, the verification information may specifically include any form of information for verifying whether the target event is the only event proposed by the target consensus node in the same consensus round.

[0088] In this case, when other consensus nodes perform validity verification on the above-mentioned target event based on the obtained verification information, they can specifically verify whether the target event is the only event proposed by the above-mentioned target consensus node in the same consensus round based on the verification information; if the target event is the only event proposed by the target consensus node in the same consensus round, it indicates that the target event is not a malicious event released by the target consensus node, and it can be determined that the validity verification of the target event has passed.

[0089] For example, in one embodiment shown, the verification information may specifically include the creator, timestamp, and merkle_root (transaction lists) in the event_head. In this case, when other consensus nodes verify the validity of the target event based on the obtained verification information, they may first determine the consensus round corresponding to the target event based on the timestamp; for example, based on the hashgraph consensus protocol, each consensus round usually corresponds to a timestamp range, so the timestamp contained in the event_head may be used to determine the consensus round to which the event belongs. Of course, in actual applications, the event_head may also include a round identifier of a consensus round. In this case, the consensus round may be determined based on the round identifier.

[0090] Then, it can be further determined whether the event headers of other events broadcast by the target consensus node have been received in the consensus round; wherein the merkle_root(transaction lists) contained in the event headers of the other events (i.e., the hash value of the root node of the Merkle tree constructed based on the hash values ​​of the transactions in the transaction lists contained in the other events) is different from the merkle_root(transaction lists) contained in the event_head of the above target event.

[0091] If no event headers of other events published by the target consensus node have been received in this consensus round, it can be determined that the target event is the only event proposed by the target consensus node in the same consensus round. In other words, it can be confirmed that the target consensus node has not maliciously proposed multiple different events at the same time in this consensus round.

[0092] In another embodiment shown, the verification information may include parent_list (creator) in the event_head in addition to creator, timestamp and merkle_root (transaction lists) in the event_head.

[0093] In this case, after other consensus nodes verify the validity of the above-mentioned target event based on the obtained verification information, if it is confirmed that no event headers of other events published by the target consensus node have been received in the consensus round, the parent_list(creator) maintained in the local hash map can be further obtained, and the parent_list(creator) maintained in the local hash map can be verified to be consistent with the parent_list(creator) contained in the above-mentioned verification information; if the two are consistent, it can be determined that the target event is the only event proposed by the target consensus node in the same consensus round.

[0094] Of course, if the two are inconsistent, it indicates that the above-mentioned latest event set maintained on the local hash map of the other consensus node and the above-mentioned target consensus node is inconsistent. In this case, an event synchronization can be performed between the other consensus node and the above-mentioned target consensus node to make the above-mentioned latest event set maintained on the local hash map of the other consensus node and the above-mentioned target consensus node reach a consistent state.

[0095] In this way, in the process of verifying the validity of the target event, a step can be added to verify the state of the hash graph maintained locally by each consensus node, so that the hash graphs maintained locally by all consensus nodes can have a strongly consistent state.

[0096] In one embodiment shown, the verification message may further include a hash value of the verification information; for example, the event header of the target event may further include event_hash. In this case, after the validity verification of the target event is passed, other consensus nodes may submit signatures for event_hash included in the verification message at the stage of submitting signatures for the target event.

[0097] Correspondingly, before performing validity verification on the above-mentioned target event based on the obtained verification information, other consensus nodes can also calculate the hash value of the obtained verification information, and determine whether the calculated hash value is the same as the event_hash contained in the verification message; if so, it indicates that the obtained verification information has not been tampered with, and the process of performing validity verification on the target event based on the obtained verification information can continue to be executed.

[0098] Step 106: In response to collecting at least a Quorum of the response messages, the target event is generated, and the hashgraph consensus protocol is run to initiate consensus processing for the target event.

[0099] In this specification, the target consensus node may also determine whether the collected response messages have reached a quorum during the process of collecting the response messages returned by other consensus nodes.

[0100] It should be noted that Quorum usually refers to a threshold number of consensus nodes that can represent the majority of the blockchain. For example, when the number of consensus nodes participating in the consensus in the blockchain is n3f+1, the value of Quorum can be nf, that is, 2f+1. In this way, for a distributed system containing 4 nodes, any 3 nodes can form a Quorum. f refers to the number of Byzantine nodes (i.e. malicious nodes) that the blockchain can tolerate.

[0101] When the target consensus node collects the Quorum response messages returned by other consensus nodes, it indicates that most of the consensus nodes have recognized the target event. At this time, the validity verification process for the target event introduced in the hashgraph consensus protocol ends, and the target consensus node can officially start generating the target event.

[0102] In one embodiment shown, when the target consensus node generates the target event, it can specifically generate a certificate corresponding to the target event based on at least a Quorum response message collected; wherein the certificate can specifically be used to indicate that the target event has passed the above validity verification. Then, the data structure of the target event can be created based on the generated event header, and the transaction list proposed by the target consensus node and the generated certificate are added to the data structure as the event content contained in the target event.

[0103] In this way, other consensus nodes can confirm whether the target event is a valid event by verifying the proof contained in the target event during the consensus processing of the target event, so that the target event can be quickly added to the local hash map.

[0104] The specific form of the above proof is not specifically limited in this specification. In practical applications, it can be any form of verifiable credentials generated based on cryptographic technology. For example, in one example, the above proof can be a response message set consisting of at least a Quorum of the above response messages. In one embodiment shown, the events supported by the hashgraph consensus protocol can be transformed into the following data structure as an example:

[0105] Event{event_head, event_date}

[0106] The data structure of the event_date above can be as follows:

[0107] event_date(echos(event),transaction list)

[0108] In the above data structure, echos(event) represents the response message set returned by other consensus nodes to the event; the response message set may specifically include at least Quorum of the above response messages returned by other consensus nodes collected by the target consensus node. Transaction list represents the transaction list proposed by the target consensus node.

[0109] After the target consensus node generates the target event, the consensus processing for the target event can be initiated by running the hashgraph consensus protocol.

[0110] In one embodiment shown, the mechanism of exchanging event information between consensus nodes adopted by the hashgraph consensus protocol can also be modified. The modified hashgraph consensus protocol can no longer use the gossip protocol to publish events to other consensus nodes. Instead, it can use broadcasting to publish the generated events to other consensus nodes.

[0111] In this case, when the above-mentioned target consensus node runs the hashgraph consensus protocol to initiate consensus processing for the target event, it can no longer use the gossip protocol to publish the target event to other consensus nodes, but instead broadcast the generated target event to other consensus nodes.

[0112] After receiving the target event, other consensus nodes can obtain the above-mentioned proof contained in the data structure of the target event, and then verify the proof; the verification method used to verify the proof usually corresponds to the generation method used to generate the proof. In different proof generation methods, the verification method for verifying the proof will usually be different.

[0113] For example, in one example, the proof may specifically be a response message set consisting of at least a Quorum of the response messages. In this case, when other consensus nodes verify the proof contained in the data structure of the target event, they may specifically verify the signatures contained in at least a Quorum of the response messages contained in the data structure of the target event; if the signatures contained in at least a Quorum of the response messages pass verification, it can be determined that the verification of the proof has passed.

[0114] When other consensus nodes pass the verification of the proof, it indicates that the target event is a valid event recognized by the majority of consensus nodes. At this time, other consensus nodes can add the target event to their local hash map.

[0115] For example, since the data structure of the target event also contains the above-mentioned parent_list(creator), and parent_list(creator) is usually a list containing N latest events, after adding the target event to its local hash map, the target event can also establish a relationship with each parent event contained in the parent_list(creator).

[0116] After other consensus nodes add the target event to their local hash graph, they can continue to run the virtual voting mechanism of the hashgraph consensus protocol, iteratively tracing the parent events of each latest event contained in the parent_list(creator) in the data structure of the target event on the hash graph to obtain the latest parent event set; wherein, the so-called iterative tracing of the parent events of each latest event means first searching for the parent event of the latest event on the local hash graph, and then continuing to query the parent event of the parent event, and so on, until the entire hash graph is traversed.

[0117] After tracing back to the latest parent event set, the target event added to the local hash map can be virtually voted on based on the latest parent event set to complete the consensus processing for the target event.

[0118] For example, the virtual voting mechanism based on the Hashgraph consensus protocol usually runs three algorithms, namely "DivideRound", "DecideFame" and "FindOrder", on the hash graph maintained locally by the consensus node to sort each event recorded on the locally maintained hash graph and reach a consensus.

[0119] The DivideRound algorithm is used to divide all events recorded on the locally maintained hash map into multiple rounds, each of which will contain a set of witness events. By running the DivideRound algorithm, the parent events of each latest event contained in the parent_list (creator) in the data structure of the target event can be iteratively traced on the hash map to obtain the latest parent event set, and the events contained in the latest parent event set can be divided into rounds.

[0120] The DecideFame algorithm is used to calculate famous events among all events recorded on the locally maintained hash graph. Based on the Hashgraph consensus protocol, a famous event refers to a witness event in a specific round that can be "strongly seen" by more than two-thirds of the witness events in the subsequent rounds. The see defined in the Hashgraph consensus protocol is divided into ordinary see and strong see. A witness event can see another target witness event, which means that by analyzing the relationship between events in the hash graph, it is ensured that these witness events can indeed be traced back to the target witness event. And a witness event can strongly see another witness event, which means that the witness event can be traced back to the target witness event through a series of causal relationships, and this path will not pass through any competing events from the same height. Running the DecideFame algorithm can further determine whether the target event is a famous event based on the latest parent event set obtained by running the DivideRound algorithm; for example, it can determine whether the target event is "strongly seen" by at least a Quorum of witness events in the subsequent rounds. If the target event is determined to be a famous event, the famous event can be marked on the local hash graph.

[0121] The FindOrder algorithm is used to assign a globally unique sequence number to all transactions based on the causal relationship between famous events and other witness events. When the DecideFame algorithm is run, a globally unique sequence number can be assigned to the target event when it is determined that the target event is a famous event. Subsequently, the consensus nodes on the blockchain can execute the famous events marked on the hash graph in sequence based on the sequence number.

[0122] It should be noted that the specific algorithm logic of the above-mentioned "DivideRound", "DecideFame" and "FindOrder" algorithms will not be described in detail in this specification. Those skilled in the art may refer to the records in the relevant technology when assisting in implementing the technical solution of this specification.

[0123] The following is a more detailed introduction to the above technical solution in combination with the scenario where a consensus node proposes malicious behavior of multiple different events in the same consensus round.

[0124] In a blockchain system running the Hashgraph consensus protocol, when a consensus node proposes multiple different events in the same consensus round, it is usually considered a malicious behavior.

[0125] In the traditional Hashgraph consensus protocol, the gossip protocol is used to exchange event information with other consensus nodes. Based on the special communication mechanism similar to rumor propagation adopted by the gossip protocol, the multiple different events proposed by the target consensus node usually cannot be quickly spread to other consensus nodes in a short period of time. This may cause each consensus node to continue to run subsequent virtual voting mechanisms based on the multiple different events, thereby affecting the overall consensus performance and efficiency of the blockchain system, and even threatening the stability of the blockchain system.

[0126] See also Figure 2 , Figure 2 A schematic diagram of a hash graph maintained locally by a consensus node shown in this specification.

[0127] like Figure 2 As shown, assuming that the blockchain system contains three consensus nodes A, B and C, Figure 2 The hash graph shown is the hash graph maintained locally by consensus node A.

[0128] Assume that consensus node B publishes two different events, B2_0 and B2_1, in a consensus round, misleading consensus node A and consensus node C. In the process of consensus node A gradually spreading B2_0 and B2_1 to consensus nodes A and C based on the gossip protocol, when consensus nodes A and consensus nodes C have not yet communicated with each other, consensus nodes A and consensus nodes C may continue to generate new events along branch B2_0 and event B2_1 respectively. For example, Figure 2As shown, consensus node A continues to generate event A2_0 with B2_0 as other-parent based on B2_0; consensus node C continues to generate event C2_0 with B2_1 as other-parent based on B2_1.

[0129] From a global perspective, node B has generated two branches, but nodes A and C are not aware of this at first. This situation may cause the following three problems.

[0130] 1. Event synchronization issues:

[0131] Generally speaking, when synchronizing events between consensus nodes running the Hashgraph consensus protocol, incremental synchronization is usually used. By default, a consensus node will not synchronize all events maintained on the local hash graph of another node. The consensus node only needs to synchronize the latest events published by each consensus node maintained on the local hash graph to the other node, and the other node only needs to send the incremental events whose consensus rounds (also called consensus height) maintained on the local hash graph are greater than the latest events synchronized by the consensus node to the consensus node.

[0132] For example, suppose Figure 2 At the moment when consensus node A maintains the latest events published by consensus nodes A and B on the hash graph as A2_0 and B2_0 respectively, and requests consensus node C to synchronize its missing events, if the latest event published by consensus node C is C3_0, consensus node C will usually return events C1_0, C2_0, B3_1, C3_0 to consensus node A, but B2_1 is missing. This is because consensus node C assumes that consensus node B will not issue two different events at the same time in a consensus round, and there should be only one event published by consensus node B in the consensus round to which B2_1 belongs.

[0133] In this case, it will be necessary to introduce additional processes based on the gossip protocol process to fill in the missing events to ensure the correct operation of the algorithm, or it will be necessary to design a more complex synchronization mechanism to ensure the correct operation of the algorithm.

[0134] 2. The relationship between events:

[0135] The virtual voting mechanism of the traditional Hashgraph consensus protocol usually runs three algorithms, namely "DivideRound", "DecideFame" and "FindOrder", on the hash graph maintained locally by the consensus node. The basis of these three algorithms is the judgment of "seeing" and "strong seeing" mentioned above.

[0136] If there is no malicious behavior of publishing two different events in a certain consensus round, the "parent event set" of the event is usually iteratively traced based on the other-parent and self-parent of the event, and the "seeing" and "strong seeing" judgments are made based on this parent event set. For example, assuming that the parent event set of event A2_0 is [A2_0, B2_0], then A1_0 and B1_0, which have lower rounds than A2_0 and B2_0, are visible to A2_0 and B2_. However, if there is such a malicious behavior of publishing two different events in a certain consensus round, it will be difficult for the above-mentioned algorithm to correctly make "seeing" and "strong seeing" judgments without traversing the hash graph.

[0137] 3. The DecideFame algorithm becomes more complex:

[0138] Since the DecideFame algorithm of the Hashgraph consensus protocol stipulates that a famous event itself cannot be a malicious event that is proposed repeatedly, if there is a malicious behavior of publishing two different events in a certain consensus round, it may be necessary to introduce additional judgment logic in the DecideFame algorithm to determine whether the famous event determined by the algorithm is a malicious event that is proposed repeatedly.

[0139] It can be seen that in the traditional Hashgraph consensus protocol, if there is malicious behavior that proposes multiple different events in the same consensus round, it will affect the overall consensus performance and efficiency of the blockchain system, and even threaten the stability of the blockchain system.

[0140] In the specification, the process of generating new events in the hashgraph consensus protocol can be transformed. Before the consensus node generates a new event, a mechanism for pre-validation of the target event can be introduced. The consensus node can generate and publish a new event only after the majority of other consensus nodes have verified the validity of the event to be published and confirmed that the consensus node does not have the malicious behavior of publishing two different events in a consensus round. This prevents the malicious behavior of consensus nodes running the hashgraph consensus protocol publishing multiple different events in one round of consensus from the source.

[0141] Moreover, in this way, it is possible to avoid introducing additional detection logic for malicious behavior such as publishing multiple different events in one round of consensus in the Hashgraph consensus protocol, thereby simplifying the process of the Hashgraph consensus protocol and improving the consensus efficiency of the Hashgraph consensus protocol.

[0142] Corresponding to the embodiments of the aforementioned method, this specification also provides embodiments of an apparatus, an electronic device, and a storage medium.

[0143] Figure 3 is a schematic structural diagram of an electronic device provided by an exemplary embodiment. Figure 3 At the hardware level, the device includes a processor 302, an internal bus 304, a network interface 306, a memory 308, and a non-volatile memory 310, and may also include other required hardware. One or more embodiments of this specification may be implemented based on software, such as the processor 302 reading the corresponding computer program from the non-volatile memory 310 into the memory 308 and then running it. Of course, in addition to the software implementation, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0144] like Figure 4 As shown, Figure 4 This is a block diagram of a consensus process in a blockchain system according to an exemplary embodiment of the present specification. The device can be applied to Figure 3 In the electronic device shown, the technical solution of this specification is implemented. The device is applied to any target consensus node participating in the consensus in the blockchain system; the consensus protocol run by the consensus node participating in the consensus in the blockchain system is the hashgraph consensus protocol; the device 400 includes:

[0145] Acquisition module 401, acquiring verification information corresponding to a target event to be published; wherein the target event is used to contain a list of transactions proposed by the target consensus node; and the verification information is used to perform validity verification on the target event;

[0146] The collection module 402 runs a consistency broadcast algorithm to broadcast a verification message containing the verification information to other consensus nodes, and collects response messages to the verification message returned by the other consensus nodes by running the consistency broadcast algorithm; wherein the response message includes a signature submitted by the other consensus nodes for the target event after the validity verification for the target event based on the verification information is passed;

[0147] The consensus module 403 generates the target event in response to collecting at least a Quorum of the response messages, and runs the hashgraph consensus protocol to initiate consensus processing for the target event.

[0148] Accordingly, the present specification also provides an electronic device, which includes a processor; a memory for storing instructions executable by the processor; wherein the processor is configured to implement the steps in all the method flows described above.

[0149] Accordingly, the present specification also provides a computer-readable storage medium on which executable computer program instructions are stored; wherein, when the instructions are executed by a processor, the steps in all the method flows described above are implemented.

[0150] Accordingly, the present specification also provides a computer program product having executable computer program instructions stored thereon; wherein, when the computer program instructions are executed by a processor, the steps in all the method flows described above are implemented.

[0151] In the 1990s, improvements to a technology could be clearly distinguished as hardware improvements (for example, improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the method flow). However, with the development of technology, many improvements to the method flow today can be regarded as direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement in a method flow cannot be implemented using a hardware entity module. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user's programming of the device. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to ask a chip manufacturer to design and produce a dedicated integrated circuit chip. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing and writing programs, and the original code before compilation must also be written in a specific programming language, which is called hardware description language (HDL). There is not only one HDL, but many kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages ​​and program it into the integrated circuit, and then it is easy to obtain the hardware circuit that implements the logic method flow.

[0152] The controller can be implemented in any appropriate manner, for example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing a computer-readable program code (such as software or firmware) that can be executed by the (micro)processor, a logic gate, a switch, an application-specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art also know that in addition to implementing the controller in a purely computer-readable program code manner, the controller can be implemented in the form of a logic gate, a switch, an application-specific integrated circuit, a programmable logic controller, and an embedded microcontroller by logically programming the method steps. Therefore, this controller can be considered as a hardware component, and the devices included therein for implementing various functions can also be regarded as structures within the hardware component. Or even, the devices for implementing various functions can be regarded as both software modules for implementing the method and structures within the hardware component.

[0153] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, the present application does not exclude that with the development of computer technology in the future, the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0154] Although one or more embodiments of the present specification provide method operation steps as described in the embodiments or flow charts, more or less operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps, and does not represent the only execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "include", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements includes not only those elements, but also includes other elements that are not clearly listed, or also includes elements inherent to such process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements. For example, if the first, second and other words are used to represent the name, they do not represent any specific order.

[0155] For the convenience of description, the above devices are described in various modules according to their functions. Of course, when implementing one or more of the present specification, the functions of each module can be implemented in the same or more software and / or hardware, or the module implementing the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0156] The present invention is described with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0157] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0158] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0159] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0160] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0161] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be used to store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, read-only compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include temporary computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0162] It should be understood by those skilled in the art that one or more embodiments of the present specification may be provided as a method, system or computer program product. Therefore, one or more embodiments of the present specification may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, one or more embodiments of the present specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0163] One or more embodiments of this specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. One or more embodiments of this specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0164] Each embodiment in this specification is described in a progressive manner, and the same and similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. In the description of this specification, the description of the reference terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representation of the above terms does not necessarily target the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples without contradiction.

[0165] The above description is only an example of one or more embodiments of this specification and is not intended to limit one or more embodiments of this specification. For those skilled in the art, one or more embodiments of this specification may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification should be included in the scope of the claims.

Claims

1. A consensus processing method in a blockchain system, the method being applied to any target consensus node participating in the consensus in the blockchain system; wherein: The consensus protocol run by the consensus nodes participating in the consensus in the blockchain system is the hashgraph consensus protocol; the method comprises: Acquire verification information corresponding to a target event to be published; wherein the target event is used to contain a list of transactions proposed by the target consensus node; and the verification information is used to verify the validity of the target event; Running a consistency broadcast algorithm to broadcast a verification message containing the verification information to other consensus nodes, and collecting response messages to the verification message returned by the other consensus nodes by running the consistency broadcast algorithm; wherein the response message includes the signature submitted by the other consensus nodes for the target event after the validity verification for the target event based on the verification information is passed; In response to collecting at least a Quorum of the response messages, the target event is generated, and the hashgraph consensus protocol is run to initiate consensus processing for the target event.

2. The method according to claim 1, wherein the data structure of the target event includes an event header and event content; wherein: The event header includes the verification information; Run the consistency broadcast algorithm to broadcast a verification message containing the verification information to other consensus nodes, including: generating an event header corresponding to the target event based on the verification information; The consistency broadcast algorithm is run to broadcast a verification message including the event header to other consensus nodes.

3. The method of claim 2, wherein the verification information is used to verify whether the target event is the only event proposed by the target consensus node in the same consensus round; Conduct validity verification for the target event, including: Verifying, based on the verification information, whether the target event is the only event proposed by the target consensus node in the same consensus round; If the target event is the only event proposed by the target consensus node in the same consensus round, it is determined that the validity verification of the target event is passed.

4. The method according to claim 3, wherein the verification information includes: a node identifier of the target consensus node, a hash value of a root node of a Merkle tree constructed based on hash values ​​of transactions in a transaction list contained in the target event, and a timestamp corresponding to a creation time of the target event; Verifying whether the target event is the only event proposed by the target consensus node in the same consensus round based on the verification information includes: Determining a consensus round corresponding to the target event based on the timestamp information; Determine whether an event header of another event broadcasted by the target consensus node has been received in the consensus round; wherein the hash value of the root node of the Merkle tree constructed based on the hash value of the transaction in the transaction list contained in the other event and contained in the event header of the other event is different from the hash value of the root node of the Merkle tree contained in the event header of the target event; If no event header of other events published by the target consensus node has been received in the consensus round, it is determined that the target event is the only event proposed by the target consensus node in the same consensus round.

5. According to the method of claim 3, the verification information further includes the latest event set maintained in the local hash map of the target consensus node; the latest event set is an event set recorded in the local hash map and composed of the latest events released by other consensus nodes; If no event header of other events published by the target consensus node has been received in the consensus round, determining that the target event is the only event proposed by the target consensus node in the same consensus round includes: If no event headers of other events published by the target consensus node have been received in this consensus round, further verify whether the latest event set maintained in the local hash map is consistent with the latest event set maintained in the local hash map of the target consensus node; if so, determine that the target event is the only event proposed by the target consensus node in the same consensus round.

6. The method of claim 5, generating the target event, comprising: Generate a certificate corresponding to the target event based on at least a Quorum of the response messages; wherein the certificate is used to indicate that the target event has passed the validity verification; A data structure of the target event is created based on the generated event header, and the transaction list proposed by the target consensus node and the proof are added to the data structure as event content contained in the target event.

7. The method of claim 6, wherein the hashgraph consensus protocol no longer uses the gossip protocol to publish events to other consensus nodes; Run the hashgraph consensus protocol to initiate consensus processing for the target event, including: The generated target event is broadcasted to the other consensus nodes so that the other consensus nodes can verify the proof contained in the data structure of the target event; if the verification of the proof is passed, the target event is added to its local hash graph, and the virtual voting mechanism of the hashgraph consensus protocol continues to run, and the parent events of each latest event contained in the latest event set are iteratively traced on the hash graph to obtain the latest parent event set, and on the basis of the latest parent event set obtained by tracing, the target event added to the local hash graph is virtually voted to complete the consensus processing of the target event.

8. The method according to claim 7, wherein the proof is a response message set consisting of at least a quorum of the response messages; Verifying the proof contained in the data structure of the target event includes: Verifying signatures contained in at least a Quorum of the response messages contained in the data structure of the target event; If the signatures included in at least a quorum of the response messages are verified successfully, it is determined that the verification of the certificate is successful.

9. The method according to claim 8, wherein the verification message further includes a hash value of the verification information; the signature submitted for the target event is a signature submitted for the hash value of the verification information included in the verification message; Before verifying whether the target event is the only event proposed by the target consensus node in the same consensus round based on the verification information, the method further includes: Calculate a hash value of the verification information contained in the verification message, and determine whether the calculated hash value is the same as the hash value of the verification information contained in the verification message; if so, further verify based on the verification information whether the target event is the only event proposed by the target consensus node in the same consensus round.

10. The method of claim 1, wherein the consistency broadcast algorithm comprises a Reiter broadcast algorithm.

11. A consensus processing device in a blockchain system, the device being applied to any target consensus node participating in the consensus in the blockchain system; wherein: The consensus protocol run by the consensus nodes participating in the consensus in the blockchain system is the hashgraph consensus protocol; the device includes: An acquisition module, which acquires verification information corresponding to a target event to be published; wherein the target event is used to contain a list of transactions proposed by the target consensus node; and the verification information is used to perform validity verification on the target event; A collection module, which runs a consistency broadcast algorithm to broadcast a verification message containing the verification information to other consensus nodes, and collects response messages to the verification message returned by the other consensus nodes by running the consistency broadcast algorithm; wherein the response message includes a signature submitted by the other consensus nodes for the target event after the validity verification for the target event based on the verification information is passed; The consensus module, in response to collecting at least a Quorum of the response messages, generates the target event and runs the hashgraph consensus protocol to initiate consensus processing for the target event.

12. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 10 are implemented.

13. A computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of any one of the methods of claims 1 to 10.

14. A computer program product, comprising a computer program, wherein when the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 10 are implemented.

Images