Asynchronous network consensus method and apparatus, electronic device and readable storage medium

Abstract

The present application relates to the technical field of block chains, and in particular to an asynchronous network consensus method and apparatus, an electronic device and a readable storage medium. The method comprises: receiving and verifying transaction proposals broadcasted by other consensus nodes in an asynchronous network, and broadcasting the transaction proposals to the other consensus nodes; on the basis of historical submission records of the transaction proposals, counting a reputation score corresponding to each consensus node in the asynchronous network; and on the basis of the reputation scores of the consensus nodes and a random source, determining a target transaction proposal to be submitted corresponding to a target consensus round. The reputation scores of the consensus nodes are counted by means of the historical submission records, and the random source in the asynchronous network takes into account the activity of the consensus nodes, improving the probability of correctly submitting proposals, improving the activity of an asynchronous consensus algorithm in a Byzantine fault-tolerant system of the asynchronous network, and shortening the consensus achievement duration.

Description

Asynchronous network consensus method, device, electronic device and readable storage medium

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on January 5, 2024, with application number 202410017937.3 and invention name “Asynchronous network consensus method, device, electronic device and readable storage medium”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of blockchain technology, and in particular to an asynchronous network consensus method, device, electronic device, and readable storage medium. Background Art

[0003] In distributed systems, consensus is a very difficult problem to solve. The Impossible Result Theorem (Fischer-Lynch-Paterson, FLP) theoretically proves that if any node in a distributed system fails, then the consensus problem in an asynchronous system is unsolvable, or there is no guarantee that consensus will be reached within a finite time.

[0004] Currently, in asynchronous network systems, when nodes cannot reach consensus, a random source is introduced. The random selection results of the random source are used to determine the submission of proposals. However, in Byzantine scenarios, there may be malicious or faulty nodes. The method of determining submission based on random selection results cannot avoid selecting erroneous proposals from these Byzantine nodes. As a result, the entire asynchronous network system is affected by Byzantine nodes, resulting in delays in reaching consensus. Technical issues

[0005] According to various embodiments of the present application, an asynchronous network consensus method, apparatus, electronic device, and readable storage medium are provided, which can reduce the impact of Byzantine nodes on the asynchronous network and shorten the time to reach consensus. Technical Solutions

[0006] The technical solution adopted in the embodiment of this application is:

[0007] In a first aspect, the present application provides an asynchronous network consensus method, the method comprising:

[0008] Receive and verify transaction proposals broadcast by other consensus nodes in the asynchronous network, and broadcast transaction proposals to other consensus nodes; based on the historical submission records of transaction proposals, count the credit points corresponding to each consensus node in the asynchronous network; determine the target consensus round corresponding to the target transaction proposal to be submitted based on the credit points of each consensus node and the random source.

[0009] Through the above method, the reputation points of consensus nodes are calculated based on historical submission records. The random source in the asynchronous network is added to consider the activity of consensus nodes, which improves the probability of correct proposal submission and the activity of the asynchronous consensus algorithm in the Byzantine fault-tolerant system of the asynchronous network, shortening the time to reach consensus.

[0010] In a possible implementation of the first aspect, after receiving and verifying the transaction proposal broadcast by other consensus nodes in the asynchronous network, the method further includes:

[0011] Based on a directed acyclic graph structure, the received transaction proposals issued by each consensus node in each consensus round are stored; wherein each transaction proposal is verified by a quorum of consensus nodes, and each proposal references a quorum of transaction proposals from the previous round.

[0012] In a possible implementation of the first aspect, the historical submission record includes at least one of the number of times a consensus node submitted correct transaction proposals and the number of times a previously submitted transaction proposal was referenced in the directed acyclic graph; and counting the reputation points corresponding to each consensus node in the asynchronous network based on the historical submission record of the transaction proposals includes:

[0013] Based on at least one of the number of correct transaction proposals submitted and the number of references to a previously submitted transaction proposal, a credit score corresponding to each consensus node in the asynchronous network is counted.

[0014] In a possible implementation of the first aspect, determining, based on the reputation points of each consensus node and the random source, a target transaction proposal to be submitted corresponding to the target consensus round includes:

[0015] In the target consensus round, if the reputation score of the first consensus node is greater than the reputation score of the second consensus node determined based on the random source, the transaction proposal issued by the first consensus node in the target consensus round and the referenced transaction proposal are used as the target transaction proposal.

[0016] In a possible implementation of the first aspect, determining, based on the reputation points of each consensus node and the random source, a target transaction proposal to be submitted corresponding to the target consensus round includes:

[0017] If the second target transaction proposal to be submitted determined in the second consensus round references the first target transaction proposal that was not submitted in the first consensus round, then the first target transaction proposal is submitted; based on the reference relationship between each consensus node's transaction proposal and the first target transaction proposal, the reputation score of each consensus node in the second consensus round is updated; if the third target transaction proposal to be submitted determined based on the updated reputation score is different from the second target transaction proposal, then the third target transaction proposal replaces the second target transaction proposal; wherein, the first target transaction proposal is the transaction proposal submitted by other consensus nodes in the asynchronous network in the first consensus round.

[0018] In a possible implementation of the first aspect, determining, based on the reputation points of each consensus node and the random source, a target transaction proposal to be submitted corresponding to the target consensus round includes:

[0019] Within a preset points statistics period, the total credit points of all consensus nodes are calculated based on the credit points of each consensus node; and the target transaction proposal is determined based on the result of a modulo operation between the random source and the total credit points.

[0020] In a possible implementation of the first aspect, determining the target transaction proposal based on a modulo operation between the random source and the total reputation score includes:

[0021] Based on the reputation points of each consensus node and the total reputation points, the score interval corresponding to each node is divided; based on the score interval corresponding to the calculation result, the target transaction proposal is determined.

[0022] In a possible implementation of the first aspect, before calculating the credit score corresponding to each consensus node in the asynchronous network based on the historical submission record of the transaction proposal, the method further includes:

[0023] A first submitted target transaction proposal is determined based on the random source.

[0024] In a second aspect, the present application provides a data synchronization device, comprising:

[0025] A receiving unit, configured to receive and verify transaction proposals broadcasted by other consensus nodes in the asynchronous network, and broadcast the transaction proposals to the other consensus nodes;

[0026] A statistics unit, configured to calculate the credit score corresponding to each consensus node in the asynchronous network based on the historical submission records of the transaction proposal;

[0027] The output unit is used to determine the target transaction proposal to be submitted corresponding to the target consensus round based on the reputation points of each consensus node and the random source.

[0028] In a third aspect, the present application provides an electronic device comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the method described in any one of the first aspect or the second aspect when executing the computer program.

[0029] In a fourth aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method according to any one of the first aspect or the second aspect.

[0030] In a fifth aspect, the present application provides a computer program product. When the computer program product is run on an electronic device, the electronic device executes any one of the methods in the first or second aspect above.

[0031] It can be understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant description of the first aspect mentioned above, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0033] FIG1 is a schematic diagram of the architecture of an asynchronous network cluster provided in an embodiment of the present application;

[0034] FIG2 is a schematic diagram of a transaction proposal submission process for an asynchronous network according to an embodiment of the present application;

[0035] FIG3 is a schematic diagram of an implementation flow of an asynchronous network consensus method provided in an embodiment of the present application;

[0036] FIG4 is a schematic diagram of a transaction proposal submission process for an asynchronous network according to another embodiment of the present application;

[0037] FIG5 is a schematic diagram of a transaction proposal submission process for an asynchronous network according to another embodiment of the present application;

[0038] FIG6 is a schematic diagram of quickly determining a transaction proposal based on a random source and points according to an embodiment of the present application;

[0039] FIG7 is a schematic diagram of the structure of an asynchronous network consensus device provided in an embodiment of the present application;

[0040] FIG8 is a schematic structural diagram of an electronic device provided in an embodiment of the present application. Modes for Carrying Out the Invention

[0041] The following embodiments of the technical solution of the present application will be described in detail with reference to the accompanying drawings. The following embodiments are only used to more clearly illustrate the technical solution of the present application and are therefore only examples and are not intended to limit the scope of protection of the present application.

[0042] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application belongs; the terms used herein are only for the purpose of describing specific embodiments and are not intended to limit this application; the terms "including" and "having" and any variations thereof in the specification and claims of this application and the above-mentioned figure descriptions are intended to cover non-exclusive inclusions.

[0043] In the description of the embodiments of this application, the technical terms "first" and "second" are used only to distinguish different objects and should not be understood to indicate or imply relative importance or implicitly specify the quantity, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, the meaning of "plurality" is more than two, unless otherwise clearly and specifically defined.

[0044] References herein to "embodiments" mean that a particular feature, structure, or characteristic described in connection with the embodiments may be included in at least one embodiment of the present application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it constitute an independent or alternative embodiment that is mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0045] In the description of the embodiments of this application, the term "and / or" is simply a description of the association relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent the following three situations: A exists alone, A and B exist simultaneously, and B exists alone. In addition, the character " / " in this document generally indicates that the associated objects are in an "or" relationship.

[0046] Currently, in existing asynchronous network consensus algorithms, a completely random value (random source) is usually used to determine whether a proposal or a group of proposals are allowed to be submitted. This random value can be generated through a simple hash calculation or threshold signature.

[0047] However, the value obtained by hashing the input random source completely ignores the consensus status of each consensus node in the asynchronous network. The random source can probabilistically determine the submission result of the consensus protocol. For asynchronous network systems with Byzantine nodes, there is a certain probability that the correct proposal cannot be submitted through this random source, thereby increasing the delay of consensus submission.

[0048] In addition, the threshold signature method is used to obtain submission results based on a random source, which increases the communication process between consensus nodes. Through the information of the consensus nodes participating in the signature, a random number (random source) within a certain range can be obtained. Based on this random number, proposals submitted by active consensus nodes within the range are selected. Although this method can circumvent the submission of proposals by Byzantine nodes to a certain extent, it is inappropriate to determine the activity of consensus nodes in submitting proposals based on the activity of nodes in participating in random number generation. This is because compared to the broadcast and verification process of transaction proposals, the threshold signature process is relatively easy. It is very likely that some consensus nodes with low submission activity can easily participate in the threshold signature process, but have difficulty participating in the proposal process. For example, there is a high delay when broadcasting proposals, and they are ignored by other consensus nodes.

[0049] Based on the above-mentioned problem of long consensus time, an embodiment of the present application provides a consensus method for an asynchronous network, which calculates the node reputation points based on the historical submission records of the consensus nodes, and combines the consideration of the reputation points of the consensus nodes to improve the activity of the Byzantine fault-tolerant system in the asynchronous network, and improve the probability and efficiency of submitting correct proposals.

[0050] In order to facilitate those skilled in the art to understand the implementation principle of the solution, relevant technical terms are first introduced.

[0051] 1. Asynchronous Networks: Asynchronous networks assume that message sending and receiving occur completely out of sync, meaning that clocks between participants may differ. Under this assumption, message reliability and ordering cannot be guaranteed, requiring more complex mechanisms to ensure correct and secure communication.

[0052] 2. Asynchronous Binary Agreement (ABA): refers to the nodes in an asynchronous network system using several rounds of communication and random numbers to determine whether a proposal can be submitted.

[0053] 3. Directed Acyclic Graph (DAG): The DAG structure is used to associate proposals that have passed the legal number (nf) signatures. The ABA process is no longer required in the submission process, simplifying the proposal submission process.

[0054] The following describes the application scenarios of the asynchronous network consensus method proposed in this application through specific embodiments.

[0055] Please refer to Figure 1, which shows a schematic diagram of the architecture of an asynchronous network cluster provided by an embodiment of the present application. As shown in Figure 1, the architecture of the asynchronous network cluster may include multiple consensus nodes, taking four consensus nodes as an example, such as node A, node B, node C and node D. Among them, the asynchronous network cluster can allow the existence of f malicious nodes, such as 1 malicious node is allowed in the above 4 nodes (3f+1 nodes); in addition to disguising itself as being in an asynchronous network (such as not responding to requests), the malicious node will also attack other nodes that may be in the asynchronous network, such as spreading inconsistent messages to different nodes, thereby affecting the activity of the asynchronous network consensus protocol.

[0056] On the one hand, each consensus node in the asynchronous network cluster can complete the consensus process by submitting proposals through the ABA process. On the other hand, each consensus node in the asynchronous network cluster can also use a directed acyclic graph structure to maintain the transaction proposals broadcast by each consensus node. In each consensus round, each consensus node generates a transaction proposal, and by continuously broadcasting its own transaction proposal and the transaction proposals received from other consensus nodes, each transaction proposal is stored at each vertex of the DAG.

[0057] For example, the asynchronous network architecture shown in Figure 1 is based on the asynchronous network scenario assumption. No single master node is specified. Each consensus node will initiate a proposal in each consensus round and forward the proposal to other consensus nodes through reliable broadcast. At the same time, it also receives and verifies transaction proposals broadcast by other consensus nodes.

[0058] In an asynchronous network system, each consensus node does not necessarily receive proposals from all other consensus nodes. Each consensus node continuously attempts to send transaction proposals to other consensus nodes through reliable broadcast until they respond to the received message. Upon receiving a quorum of transaction proposals, the consensus node advances to the next round. For example, in round 1, node A broadcasts transaction proposal A1 to nodes B, C, and D, while also receiving transaction proposals B1, C1, and D1 from nodes B, C, and D. Node A then attempts to send proposal A1 to nodes B, C, and D individually until node B responds to the received message. Node A then stops sending proposal A1 to node B, and similarly to nodes C and D. Only after node A receives a quorum of proposals (including its own, such as proposals A1, B1, and C1) does it advance to the next round and construct a new proposal A2 for the second round. If node A fails to receive enough proposals in round r to advance to round r+1, it can be considered to be in an asynchronous network state (e.g., if A is disconnected from all other nodes).

[0059] It should be noted that the transaction proposals for each consensus round maintained by the DAG represent the completion of a round of proposals, that is, the completion of a round of Byzantine atomic broadcasting, and do not represent a consensus among nodes. Figure 1 only illustrates the architecture of an asynchronous network cluster, which can also include a larger number of consensus nodes and is not specifically limited here.

[0060] In some embodiments, after several rounds of proposals are received, the consensus algorithm of the asynchronous network can generate a shared coin, that is, a globally consistent random source (random number), to select which proposals can be submitted. The random number can be generated by a simple hash calculation or obtained by a threshold signature. The embodiment of the present application does not limit the random number generation algorithm, but only ensures that the random number generation result is consistent across all consensus nodes. Each consensus node can also use an agreed random number sound field algorithm, such as finding a hash value hash(r) for the information of the current round. The random number can ensure sufficient discretization; if the random number needs to be unpredictable, a threshold signature method can be used, such as all consensus nodes signing sign(r) for the r-round information.

[0061] As shown in Figure 2, in order to facilitate the explanation of the implementation process of the embodiment of the present application, based on the architecture of the directed acyclic graph DAG, the transaction proposals generated by each consensus node in each consensus round are connected; by selecting a vertex of the DAG through shared coins, the embodiment of the present application is more intuitively and indirectly explained, and the process of submitting proposals based on the reputation points of the consensus node.

[0062] It should be noted that the implementation of the embodiments of this application does not rely solely on the DAG-related structure, but is also applicable to the conventional asynchronous consensus ABA (Asynchronous Binary Agreement) process and its variations. For example, during the voting phase of ABA, each consensus node determines whether to submit a proposal based on a random number, and can also determine whether to submit a proposal based on the consensus node's reputation points.

[0063] As shown in Figure 2, for transaction proposals maintained by a DAG structure, the consensus round in which the shared coin (randomness source) is generated is determined by different submission algorithms. Different algorithms interpret the DAG structure differently. For example, the DAG-Rider algorithm defines four consecutive DAG rounds as a submission, such as two submissions in rounds 1234 and 5678. The corresponding random number is generated in the last round of each submission (4 and 8) to determine the submitted proposal. The random number can be generated by performing a modulo operation based on the number of nodes in the consensus cluster. For example, if the consensus cluster has n nodes, then each column of the DAG has n vertex positions. After the random number c for round r is calculated, it is modulo n and used as an index to retrieve the transaction proposal for the (c mod n)th vertex in round r in the DAG column for submission.

[0064] It should be noted that each consensus node generates its own DAG structure based on the transaction proposals it receives. For example, if node A receives proposals A1, B1, and C1 in the first round, then the first column of node A's DAG must be A1, B1, and C1. Node B may receive proposals B1, C1, and D1, so the first column of node B's DAG is proposals B1, C1, and D1, which are different from node A's view.

[0065] As shown in Figure 2 (a), a random number is generated in the fourth round, and the hash value is calculated for the number of consensus rounds, that is, hash(4) to obtain a hash value h, and then h is used modulo the cluster size, that is, h mod 4, to obtain an integer in the range of [0,4), for example, 1. The proposal found by the index is the proposal of node B, which is proposal B4 in the fourth round.

[0066] In the DAG structure, each proposal is signed and verified by a quorum of nf nodes, and each proposal references nf proposals from the previous round to ensure DAG consistency. After proposal B4 is randomly selected in round 4, B4 and all proposals on the path it references (A3, B3, D3, A2, C2, D2, A1, B1, C1, D1) can be submitted.

[0067] Accordingly, the random number generated in the fourth round is completely random. As shown in Figure 2 (b), if the random number value selected consensus node C's proposal C4, due to the asynchronous network environment, proposal C4 may not be received by the majority of nodes. In this case, there is no way to select a proposal that can be submitted in this round. The proposals from rounds 1 to 3 will be delayed until the next random number generation time point, thereby increasing the delay in proposal submission. In fact, because the random number generation result is completely probabilistic, it is possible that proposal Xr (r is the round, X is the node) is always selected within a certain period of time. If node X is a Byzantine node, then the proposals in this period cannot be submitted, affecting the liveness of the asynchronous network consensus.

[0068] In response to the above-mentioned issues affecting the activity of asynchronous network consensus, the following examples further introduce the specific implementation process of the asynchronous network consensus method based on the above-mentioned asynchronous network cluster architecture.

[0069] See Figure 3, which is a schematic diagram of the implementation process of the asynchronous network consensus method provided in an embodiment of the present application. The method can be applied to any consensus node in the asynchronous network cluster in Figure 1 above. As shown in Figure 3, the method may include the following steps:

[0070] S301, receiving and verifying transaction proposals broadcast by other consensus nodes in the asynchronous network, and broadcasting the transaction proposals to other consensus nodes.

[0071] For example, each consensus node initiates a proposal in each consensus round, and forwards the proposal to other consensus nodes through reliable broadcasting, while also receiving and verifying the proposals broadcast by other consensus nodes.

[0072] In some embodiments, after receiving and verifying the transaction proposals broadcast by other consensus nodes in the asynchronous network, the method further includes: storing the received transaction proposals issued by each consensus node in each consensus round based on the structure of a directed acyclic graph.

[0073] Among them, each transaction proposal is verified by a quorum of consensus nodes, and each proposal references a quorum of transaction proposals from the previous round.

[0074] As shown in Figure 2 (a), nodes A, B, C, and D represent different consensus nodes in the asynchronous network; An represents node A's proposal in round n, and similarly for nodes B, C, and D. Each consensus node can enter the next consensus round and generate a new round of transaction proposals if it receives at least a quorum of transaction proposals from other consensus nodes in each consensus round. The lines between vertices in the DAG structure indicate the reference relationships between transaction proposals in each consensus round. Each transaction proposal in each round references a quorum of transaction proposals from the previous round, ensuring validity while expressing votes for the referenced proposals. For example, the A, B, and C on vertex A2 indicate that proposal A2 references proposals A1, B1, and C1 from the previous round.

[0075] For example, in an asynchronous network cluster, each consensus node maintains transaction proposals initiated by each node based on a DAG graph. After a transaction proposal is voted on and approved, the consensus node stores the legal certificate for each transaction proposal at the vertex of the corresponding consensus round of the DAG. Because each consensus node in the asynchronous network cluster submits transaction proposals at different times, each consensus node is in a different consensus round, and the state of the DAG graph maintained by each consensus node is also different.

[0076] S302: Based on the historical submission records of the transaction proposal, the credit points corresponding to each consensus node in the asynchronous network are counted.

[0077] In this embodiment of the application, the activity of the consensus node is taken into consideration when selecting proposals for submission. The more active a node is (for example, the more successful proposals it has submitted in the past), the higher the probability that its proposal will be selected for submission. The activity of the consensus node is represented by reputation points, and the reputation points of each consensus node are calculated based on the historical submission records of transaction proposals by the consensus node.

[0078] For example, there are various algorithms for calculating the reputation points of consensus nodes. Taking the DAG structure as an example, if a consensus node references the previous proposal that can be submitted when proposing, then the consensus node has a high probability of submitting this proposal (for example, in Figure 1, the proposal of the consensus node starting from the 5th round references the previous proposal B4 that can be submitted in the 4th round). Correspondingly, the activity of this node is also higher. Therefore, during the multi-round submission process, the number of times the node references the previous correctly submitted proposal can be counted, and the reputation points of the consensus node can be accumulated.

[0079] In some embodiments, the historical submission record includes at least one of the number of times the consensus node submits correct transaction proposals and the number of times the previously submitted transaction proposal is referenced in a directed acyclic graph; based on the historical submission record of the transaction proposal, the credit points corresponding to each of the consensus nodes in the asynchronous network are counted, including: based on at least one of the number of times the correct transaction proposals are submitted and the number of times the previously submitted transaction proposal is referenced, the credit points corresponding to each consensus node in the asynchronous network are counted.

[0080] For example, when counting reputation points, the reputation points can also be calculated based on the number of times the consensus node correctly submits proposals, that is, the more times the proposal is correctly submitted and the more times the previous proposal that can be submitted is referenced, the higher the reputation points corresponding to the consensus node will be, and the higher the probability that its corresponding transaction proposal will be submitted.

[0081] Exemplarily, before counting the credit points corresponding to each consensus node in the asynchronous network based on the historical submission records of the transaction proposal, the method further includes: determining the first submitted target transaction proposal based on a random source.

[0082] For example, when no historical submission record has been generated, that is, when the asynchronous network submits a proposal for the first time, the proposal that can be submitted can be determined based on the result obtained by taking the modulo of the number of nodes in the asynchronous network based on a random source generated by hash calculation or threshold signature.

[0083] As shown in Figure 2 (a), taking the DAG structure as an example, before round 4, since no submissions had occurred, the reputation points of each node were initially 0. In round 4, the asynchronous network directly selected proposal B4 using a random number. At this time, B4 existed in the local views of nodes A, B, and C, and a set of proposals A3-B3-D3-A2-C2-D2-A1-B1-C1-D1 was submitted. Continuing to advance the consensus rounds, as shown in Figure 4 (b), the local DAG views of nodes A, B, and C in rounds 4 to 7 show that since proposal B4 has been submitted, nodes A, B, and C all referenced proposal B4 when calculating the points, thus accumulating reputation points. The resulting reputation points of each node influence the proposal selection results in round 6.

[0084] It should be noted that each consensus node counts the reputation points of each node under its view based on its historical submission records and the reference relationships of proposals. Since the submission timing, proposal reference relationships, and DAG structure for maintaining proposals between consensus nodes in an asynchronous network system may be different, the corresponding reputation points may also be inconsistent when the submission rounds are inconsistent.

[0085] For example, from node D's perspective, in round 4, node D fails to receive proposal B4 due to network issues, or node D receives proposal B4, but the DAG view constructed by node D fails to meet the submission requirements: no subsequent quorum proposals reference proposal B4, meaning there are insufficient proposals to vote for it. Therefore, in round 4, node D does not submit proposal B4. As shown in Figure 5, the DAG structure for rounds 4-7 from node D's perspective shows that, because node D did not submit proposal B4 in round 4, nodes B and C are unable to increase their reputation points through the reference paths of proposals B5 and C5 in the reputation points counted by node D. Consequently, the accumulated reputation points for each node differ from those accumulated for nodes A, B, and C.

[0086] For example, for the ABA process, the reputation score of each node can be calculated based on the number of times each node correctly submits proposals.

[0087] S303: Determine the target transaction proposal to be submitted corresponding to the target consensus round based on the reputation points of each consensus node and the random source.

[0088] In an embodiment of the present application, when determining a proposal that can be submitted based on a random source, the reputation score calculated for each node is combined to improve the probability of selecting a target transaction proposal that can be submitted. In one case, when the node determined based on the random source is inconsistent with the node determined by the reputation score, the proposal of the node with the highest reputation score can be directly selected as the target transaction proposal; in another case, when different selection results are generated in the same consensus round due to inconsistent submission timing between nodes, the proposal of the node determined based on the re-calculation of the node's reputation score replaces the proposal of the previously selected node as the target transaction proposal that can be submitted; in another case, the reputation score of each node is modulo calculated using the random source, and the target transaction proposal that can be submitted is directly determined based on the calculation result.

[0089] It should be noted that each submission includes all proposals on the reference path, but proposals that have already been submitted will not be submitted repeatedly. For example, in the fourth round of submission, proposal B4 and the proposals on the reference path of proposal B4 are submitted. In the sixth round of submission, proposal B6 and the proposals on the reference path of proposal B6 are submitted, but proposal B4 and the proposals on the reference path of proposal B4 that have already been submitted will not be submitted again.

[0090] In some embodiments, determining a target transaction proposal to be submitted corresponding to a target consensus round based on the reputation score of each consensus node and a random source includes:

[0091] In the target consensus round, if the reputation score of the first consensus node is greater than the reputation score of the second consensus node determined based on the random source, the transaction proposal issued by the first consensus node in the target consensus round and the referenced transaction proposal are used as the target transaction proposal.

[0092] For example, when the node determined by the random source is inconsistent with the node with the highest reputation score, the proposal determined by the random source can be replaced by the proposal of the node with the highest reputation score. For example, in the fifth round, nodes A, B, and C all reference B4 and have accumulated reputation points. Assuming that after the reputation points of nodes A, B, and C are accumulated in the fifth round, node B has the highest reputation score and node D has the lowest reputation score. The proposal of node D, which was randomly selected, is replaced with the proposal of node B based on the node's reputation score, that is, proposal B6 is submitted as the target transaction proposal.

[0093] In some embodiments, determining a target transaction proposal to be submitted corresponding to a target consensus round based on the reputation score of each consensus node and a random source includes:

[0094] If the second target transaction proposal to be submitted determined in the second consensus round references the first target transaction proposal that was not submitted in the first consensus round, then the first target transaction proposal is submitted; based on the reference relationship between each consensus node's transaction proposal and the first target transaction proposal, the reputation score of each consensus node in the second consensus round is updated; if the third target transaction proposal to be submitted determined based on the updated reputation score is different from the second target transaction proposal, then the third target transaction proposal replaces the second target transaction proposal.

[0095] The first target transaction proposal is the transaction proposal submitted by other consensus nodes in the asynchronous network in the first consensus round.

[0096] As mentioned above, due to the uncertainty of the submission timing of the asynchronous network, the submission timing of each node is not completely synchronized. In addition, since the statistics of credit points need to refer to the data of historical submission records, the corresponding statistical credit points may also be temporarily inconsistent, resulting in inconsistencies in the consensus protocol.

[0097] As shown in Figure 4 (a), proposal B4 does not exist in the local DAG view of node D, or proposal B4 has not been referenced by a quorum of proposals. Therefore, node D cannot select proposal B4 for submission. Furthermore, as shown in Figure 5, in the DAG structure view of node D from rounds 4 to 7, since proposal B4 failed to be submitted in round 4, nodes A, B, and C were unable to increase their reputation points through the reference path of proposals A5, B5, and C5, resulting in node D selecting proposal C6 in the proposal selection in round 6. Alternatively, in the view of node D, since the reputation points of nodes A, B, and C in round 5 were not accumulated, node B may not have the highest score at this time, and node D may not have the lowest score either. Therefore, proposal B6 was not selected during the selection process, resulting in an inconsistent selection result between node D and nodes A, B, and C.

[0098] As shown in Figure 5, from node D's perspective, proposal B4 is referenced only by proposals B5 and C5, which is less than the quorum value defined by Byzantine safety (nf = 3). Therefore, proposal B4 is not submitted in round 4. In round 6, proposal C6 is referenced by proposals B7, C7, and D7, satisfying the quorum value. Furthermore, proposal C6 has a reference path C6-B5-B4 (or C6-C5-B4) with proposal B4, allowing node D to select proposal C6 in round 6. Because proposal C6 has a reference path with proposal B4, node D can safely submit proposal B4 first. Furthermore, from the perspective of node D, proposal B4 can be submitted by reference by proposal C6. Proposal C6 must reference nf proposals from the fifth round, and nodes A, B, and C can submit B4. This means that from the perspective of nodes A, B, and C, at least nf proposals from the fifth round referenced proposal B4. The intersection of the two quorum values ​​means there must be f+1 reference paths from C6 to B4. Therefore, even if the proposal selected by random number is D6, node D can still submit the previously unsubmitted proposal B4 based on the same principle.

[0099] As shown in Figure 5, after node D submits proposal B4, it recalculates the reputation points of each current node, that is, it increases the corresponding reputation points of nodes A, B, and C that reference proposal A5, B5, and C5 of proposal B4. Then, based on the new reputation point statistics, it reselects proposal B6 and replaces proposal C6 for submission.

[0100] For example, the process by which node D selects proposal C6 based on its own DAG view can be considered an election process, with proposal C6 serving as the election result. The election process can retain the original shared random number selection process, where the random numbers obtained using this shared random number algorithm in a given round R are identical across all nodes. However, the election results selected during the election phase are not used as a direct result of submitting proposals, but are only used to assist in submitting previously unsubmitted proposals. Node D's proposal replacement process involves replacing the proposal randomly selected during the election phase with a proposal from a highly active node with a higher probability, based on the statistical reputation score. The replacement step follows the submission step.

[0101] For example, the first target transaction proposal may be proposal B4, the first consensus round may be the fourth round in FIG5 , the second target transaction proposal may be the transaction proposal selected by node D in the sixth round, such as proposal C6 or D6, the second consensus round may be the sixth round in FIG5 , and the third target transaction proposal may be the proposal determined by node D after recalculating the credit points of each node after submitting the first target transaction proposal, such as proposal B6.

[0102] For example, in the ABA process of conventional asynchronous consensus, the above method can also be used to replace the 0 or 1 randomly selected in the BA stage, and determine the proposals that can be submitted by broadcasting a value that combines the reputation points of each node.

[0103] In some embodiments, determining a target transaction proposal to be submitted corresponding to a target consensus round based on the reputation score of each consensus node and a random source includes:

[0104] During the preset points statistics period, the total credit score of all consensus nodes is calculated based on the credit score of each consensus node; the target transaction proposal is determined based on the result of the modulo operation of the random source and the total credit score.

[0105] In an asynchronous network, if nodes fail to submit proposals in a timely manner (for example, Node D failed to submit Proposal B4 in the figure), the election phase can be based on random selection, and the reputation points based on the reference relationship between unsubmitted proposals and newly elected proposals are not calculated. Therefore, there is a high probability that unsubmitted proposals will be selected during the election phase, such as Proposal C6 in Figure 5. When a node has a proposal that is not submitted in time, the corresponding reputation points of each node need to be recalculated, and the proposal determined based on the new reputation points replaces the originally selected proposal, making the proposal selection process more cumbersome.

[0106] Therefore, in order to reduce the complexity of the proposal selection process, a points statistics cycle is defined. The points statistics results of each k-round interval are applied to the proposal selection in the next k-round, and the points values ​​are recalculated in the next k rounds; that is, the reputation points of all consensus nodes are updated once every k rounds of consensus.

[0107] For example, after the asynchronous network system generates a random number, proposals from nodes with higher reputation scores are selected with a higher probability. Because the reputation scores of each node are combined, the selected proposal is likely to be a proposal that can be submitted. When a proposal that was not submitted in time is submitted through this proposal, as long as the new submission is within the cycle k rounds, the new reputation score statistics will not be applied, thus avoiding the frequent replacement process. In other words, if a consensus node is unable to submit a proposal in time in the corresponding round, as long as it submits a supplementary proposal within k rounds, the situation where the reputation score statistics of different consensus nodes are different can be avoided. And as long as the reputation score statistics of each consensus node are kept consistent and the random numbers generated in each consensus round are consistent, the proposals selected by each consensus node in each consensus round will also be consistent.

[0108] In some embodiments, determining a target transaction proposal based on a modulo operation between the random source and the total reputation score includes:

[0109] Based on the reputation points and total reputation points of each consensus node, the corresponding score interval of each node is divided; based on the score interval corresponding to the calculation result, the target transaction proposal is determined.

[0110] For example, as shown in Figure 6, the reputation points of nodes A, B, C, and D are 10, 5, 2, and 8 respectively. After accumulating them, a ranked score list of 10, 15, 17, and 25 is obtained. Then, a random number c is introduced or generated, and the total reputation point 25 is modulo c mod 25 to obtain the operation result. When the operation result falls within the integration interval [0,10), the proposal of node A is selected; when the operation result falls within the integration interval [10,15), the proposal of node B is selected; when the operation result falls within the integration interval [15,17), the proposal of node C is selected; and when the operation result falls within the integration interval [17,25), the proposal of node D is selected.

[0111] Correspondingly, through the above range statistics, as long as the random number c is completely discrete, the probability of c selecting A is 40%, the probability of B is 20%, the probability of C is 8%, and the probability of D is 32%; that is, after the random number is generated, the proposals of nodes with higher reputation scores are selected with a higher probability.

[0112] Through the embodiments of the present application, the random source in the asynchronous network system takes into account the node activity, thereby improving the probability of correct proposal submission and the activity of the asynchronous consensus algorithm in the Byzantine fault-tolerant system of the asynchronous network, thereby shortening the time to reach consensus; the reputation points of the consensus nodes are calculated by using the existing historical submission records, without the need to introduce additional cryptographic calculations and network communications, and with low resource overhead.

[0113] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0114] Corresponding to the asynchronous network consensus method provided in the above embodiment, Figure 7 shows a structural diagram of the asynchronous network consensus device provided in the embodiment of the present application. For the sake of convenience, only the parts related to the embodiment of the present application are shown.

[0115] 7 , the asynchronous network device includes:

[0116] Receiving unit 71, configured to receive and verify transaction proposals broadcasted by other consensus nodes in the asynchronous network, and broadcast the transaction proposals to the other consensus nodes;

[0117] A statistics unit 72 is configured to calculate the credit score corresponding to each consensus node in the asynchronous network based on the historical submission records of the transaction proposal;

[0118] The output unit 73 is configured to determine a target transaction proposal to be submitted corresponding to a target consensus round based on the reputation points of each consensus node and a random source.

[0119] In one possible implementation, the receiving unit 71 is further configured to store, based on a directed acyclic graph structure, the received transaction proposals issued by each consensus node in each consensus round; wherein each transaction proposal is verified by a quorum of consensus nodes, and each proposal references a quorum of transaction proposals from the previous round.

[0120] In one possible implementation, the historical submission record includes at least one of the number of times the consensus node submits correct transaction proposals and the number of times the previously submitted transaction proposal is referenced in the directed acyclic graph; the statistical unit 72 is further used to count the credit points corresponding to each consensus node in the asynchronous network based on at least one of the number of times the correct transaction proposals are submitted and the number of times the previously submitted transaction proposal is referenced.

[0121] In one possible implementation, the output unit 73 is further configured to, in the target consensus round, if the reputation score of the first consensus node is greater than the reputation score of the second consensus node determined based on the random source, use the transaction proposal issued by the first consensus node in the target consensus round and the referenced transaction proposal as the target transaction proposal.

[0122] In one possible implementation, the output unit 73 is further configured to submit the first target transaction proposal if the second target transaction proposal to be submitted determined in the second consensus round references the first target transaction proposal that was not submitted in the first consensus round; update the reputation score of each consensus node in the second consensus round based on the reference relationship between the transaction proposal of each consensus node and the first target transaction proposal; if the third target transaction proposal to be submitted determined based on the updated reputation score is different from the second target transaction proposal, replace the second target transaction proposal with the third target transaction proposal; wherein the first target transaction proposal is the transaction proposal submitted by other consensus nodes in the asynchronous network in the first consensus round.

[0123] In one possible implementation, the output unit 73 is further used to calculate the total credit score of all consensus nodes based on the credit score of each consensus node within a preset credit statistical period; and determine the target transaction proposal based on the result of the modulo operation of the random source and the total credit score.

[0124] In one possible implementation, the output unit 73 is further configured to divide the score interval corresponding to each node based on the reputation score of each consensus node and the total reputation score; and determine the target transaction proposal based on the score interval corresponding to the calculation result.

[0125] In a possible implementation, the output unit 73 is further configured to determine a first-submitted target transaction proposal based on the random source.

[0126] Through the embodiments of the present application, the random source in the asynchronous network system takes into account the node activity, thereby improving the probability of correct proposal submission and the activity of the asynchronous consensus algorithm in the Byzantine fault-tolerant system of the asynchronous network, thereby shortening the time to reach consensus; the reputation points of the consensus nodes are calculated by using the existing historical submission records, without the need to introduce additional cryptographic calculations and network communications, and with low resource overhead.

[0127] FIG8 shows a schematic diagram of the hardware structure of the electronic device 8 .

[0128] As shown in FIG8 , the electronic device 8 of this embodiment includes: at least one processor 80 (only one is shown in FIG8 ) and a memory 81 , wherein the memory 81 stores a computer program 82 that can be executed on the processor 80 . When the processor 80 executes the computer program 82, the steps of the above-described method embodiment are implemented, such as S301 to S303 shown in FIG3 . Alternatively, when the processor 80 executes the computer program 82, the functions of the modules / units in the above-described device embodiments are implemented.

[0129] It should be understood that the structures illustrated in the embodiments of the present application do not constitute a specific limitation on the electronic device 8. In other embodiments of the present application, the electronic device 8 may include more or fewer components than shown, or may combine or separate certain components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0130] The electronic device 8 can be a consensus node in the asynchronous network cluster described above, and can be, for example, a computing device such as a desktop computer, a notebook, a PDA, or a cloud server. The electronic device 8 may include, but is not limited to, a processor 80 and a memory 81. Those skilled in the art will appreciate that FIG8 is merely an example of the electronic device 8 and does not limit the electronic device 8. The electronic device 8 may include more or fewer components than shown, or may combine certain components, or different components. For example, the server may also include an input and sending device, a network access device, a bus, etc.

[0131] The processor 80 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0132] Processor 80 may also include a memory for storing instructions and data. In some embodiments, the memory in processor 80 is a cache memory. This memory can store instructions or data that have just been used or are being recycled by processor 80. If processor 80 needs to use the same instruction or data again, it can directly access the memory. This avoids duplicate accesses, reduces processor 80 latency, and thus improves system efficiency.

[0133] In some embodiments, the memory 81 may be an internal storage unit of the electronic device 8, such as a hard disk or memory of the electronic device 8. The memory 81 may also be an external storage device of the electronic device 8, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the electronic device 8. Furthermore, the memory 81 may include both an internal storage unit of the electronic device 8 and an external storage device. The memory 81 is used to store an operating system, application programs, a boot loader, data, and other programs, such as program code of a computer program. The memory 81 may also be used to temporarily store data that has been sent or is about to be sent.

[0134] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0135] It should be noted that the structure of the above-mentioned electronic device is only illustrative, and based on different application scenarios, it may also include other physical structures, and the physical structure of the electronic device is not limited here.

[0136] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0137] An embodiment of the present application further provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it can implement the steps in the above-mentioned various method embodiments.

[0138] An embodiment of the present application provides a computer program product. When the computer program product runs on a server, the server can implement the steps in the above-mentioned method embodiments when executing the computer program product.

[0139] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the process in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form, etc. Computer-readable media may include: any entity or device that can carry computer program code, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc.

[0140] The devices, electronic devices, computer storage media, and computer program products provided in the above-mentioned embodiments of the present application are all used to execute the methods provided above. Therefore, the beneficial effects that can be achieved can refer to the corresponding beneficial effects of the methods provided above, and will not be repeated here.

[0141] It should be understood that the above is only to help those skilled in the art better understand the embodiments of the present application, and is not intended to limit the scope of the embodiments of the present application. Based on the above examples given, those skilled in the art can obviously make various equivalent modifications or changes. For example, certain steps in each embodiment of the above detection method may be unnecessary, or certain new steps may be added. Or a combination of any two or any multiple embodiments described above. Such modifications, changes, or combined solutions also fall within the scope of the embodiments of the present application.

[0142] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0143] It should also be understood that the division of the modes, situations, categories and embodiments in the embodiments of the present application is only for the convenience of description and should not constitute a special limitation. The features of various modes, categories, situations and embodiments can be combined without contradiction.

[0144] It should also be understood that in the various embodiments of the present application, unless otherwise specified or there is a logical conflict, the terms and / or descriptions between different embodiments are consistent and can be referenced by each other, and the technical features in different embodiments can be combined to form new embodiments according to their internal logical relationships.

[0145] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0146] In the embodiments provided in this application, it should be understood that the disclosed devices / network equipment and methods can be implemented in other ways. For example, the device / network equipment embodiments described above are merely illustrative. For example, the division of the modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as 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.

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

[0148] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the scope of protection of the present application.

[0149] Finally, it should be noted that the above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. An asynchronous network consensus method, characterized in that, The method includes: Receiving and verifying transaction proposals broadcast by other consensus nodes in an asynchronous network without specifying a single primary node, and broadcasting transaction proposals to the other consensus nodes; Statistically calculating the reputation scores corresponding to each consensus node in the asynchronous network based on the historical submission records of the transaction proposals; Determining the target transaction proposal to be submitted corresponding to the target consensus round according to the reputation scores of each consensus node and a random source.

2. The method according to claim 1, characterized in that, After the receiving and verifying transaction proposals broadcast by other consensus nodes in the asynchronous network, the method further includes: Storing the transaction proposals sent by each received consensus node in each consensus round based on the structure of a directed acyclic graph; Wherein, each transaction proposal is verified by a quorum of consensus nodes, and each proposal references a quorum of transaction proposals from the previous round.

3. The method according to claim 2, wherein The historical submission record includes at least one of the number of times a consensus node submits a correct transaction proposal and the number of times a previous submitted transaction proposal is referenced in the directed acyclic graph; The statistically calculating the reputation scores corresponding to each consensus node in the asynchronous network based on the historical submission records of the transaction proposals includes: Statistically calculating the reputation scores corresponding to each consensus node in the asynchronous network based on at least one of the number of times a correct transaction proposal is submitted and the number of times a previous submitted transaction proposal is referenced.

4. The method according to any one of claims 1 to 3, characterized in that, The determining the target transaction proposal to be submitted corresponding to the target consensus round according to the reputation scores of each consensus node and a random source includes: In the target consensus round, if the reputation score of the first consensus node is greater than the reputation score of the second consensus node determined based on the random source, then using the transaction proposal sent by the first consensus node in the target consensus round and the referenced transaction proposals as the target transaction proposal.

5. The method according to any one of claims 1 to 3, characterized in that The determining the target transaction proposal to be submitted corresponding to the target consensus round according to the reputation scores of each consensus node and a random source includes: If the second target transaction proposal to be submitted determined in the second consensus round references the first target transaction proposal that was not submitted in the first consensus round, then submitting the first target transaction proposal; Updating the reputation scores of each consensus node in the second consensus round based on the reference relationship of each consensus node's transaction proposal to the first target transaction proposal; If the third target transaction proposal to be submitted determined based on the updated reputation scores is different from the second target transaction proposal, then replacing the second target transaction proposal with the third target transaction proposal; Wherein, the first target transaction proposal is the transaction proposal submitted by other consensus nodes in the asynchronous network in the first consensus round.

6. The method according to any one of claims 1 to 3, characterized in that, The determining the target transaction proposal to be submitted corresponding to the target consensus round according to the reputation scores of each consensus node and a random source includes: Calculating the total reputation score of all consensus nodes based on the reputation scores of each consensus node within a preset score statistical period; Determining the target transaction proposal based on the operation result of the modulo operation of the random source and the total reputation score.

7. The method according to claim 6, wherein Determining the target transaction proposal based on the modulo operation of the random source and the total reputation score includes: Dividing the score intervals corresponding to each node based on the reputation score of each consensus node and the total reputation score; Determining the target transaction proposal based on the score interval where the operation result is located.

8. The method according to claim 1, characterized in that Before statistically calculating the reputation score corresponding to each consensus node in the asynchronous network based on the historical submission records of the transaction proposal, the method further includes: Determining the target transaction proposal for the first submission based on the random source.

9. The method according to claim 8, wherein Determining the target transaction proposal for the first submission based on the random source includes: Determining the target transaction proposal that can be submitted based on the result obtained by taking the modulo of the number of nodes in the asynchronous network with the random source generated by hash calculation or threshold signature.

10. The method according to claim 1, wherein Determining the target transaction proposal to be submitted corresponding to the target consensus round according to the reputation score of each consensus node and the random source includes: When the node determined based on the random source is inconsistent with the node determined based on the reputation score, selecting the proposal of the node with the highest reputation score as the target transaction proposal.

11. The method according to claim 1, characterized in that, Determining the target transaction proposal to be submitted corresponding to the target consensus round according to the reputation score of each consensus node and the random source includes: When different selection results occur among nodes in the same consensus round due to inconsistent submission times, replacing the proposal of the previously selected node with the proposal of the node determined based on the re-statistical reputation score of the nodes, and using it as the target transaction proposal.

12. The method according to claim 1, wherein Determining the target transaction proposal to be submitted corresponding to the target consensus round according to the reputation score of each consensus node and the random source includes: Performing a modulo calculation on the reputation scores of each node using the random source, and determining the target transaction proposal according to the calculation result.

13. An asynchronous network consensus device, characterized in that Including: A receiving unit, configured to receive and verify the transaction proposals broadcast by other consensus nodes in the asynchronous network and broadcast the transaction proposals to the other consensus nodes without specifying a single master node; A statistical unit, configured to statistically calculate the reputation score corresponding to each consensus node in the asynchronous network based on the historical submission records of the transaction proposal; An output unit, configured to determine the target transaction proposal to be submitted corresponding to the target consensus round according to the reputation score of each consensus node and the random source.

14. An electronic device, characterized in that, Including a memory and a processor, where the memory stores a computer program, and when the processor executes the computer program, the method described in any one of claims 1 to 8 is implemented.

15. A computer-readable storage medium, on which a computer program is stored, characterized in that, When the computer program is executed by the processor, the method described in any one of claims 1 to 12 is implemented.

16. A computer program product, characterized in that, When the computer program product runs on an electronic device, the electronic device is caused to execute the method described in any one of claims 1 to 12.

Images