CN117527266A - Asynchronous network consensus method, device, electronic equipment and readable storage medium - Google Patents

Asynchronous network consensus method, device, electronic equipment and readable storage medium Download PDF

Info

Publication number
CN117527266A
CN117527266A CN202410017937.3A CN202410017937A CN117527266A CN 117527266 A CN117527266 A CN 117527266A CN 202410017937 A CN202410017937 A CN 202410017937A CN 117527266 A CN117527266 A CN 117527266A
Authority
CN
China
Prior art keywords
consensus
proposal
node
transaction proposal
asynchronous network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202410017937.3A
Other languages
Chinese (zh)
Other versions
CN117527266B (en
Inventor
邱炜伟
黄方蕾
袁超
尚璇
郑佩玉
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hangzhou Qulian Technology Co Ltd
Original Assignee
Hangzhou Qulian Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hangzhou Qulian Technology Co Ltd filed Critical Hangzhou Qulian Technology Co Ltd
Priority to CN202410017937.3A priority Critical patent/CN117527266B/en
Priority claimed from CN202410017937.3A external-priority patent/CN117527266B/en
Publication of CN117527266A publication Critical patent/CN117527266A/en
Application granted granted Critical
Publication of CN117527266B publication Critical patent/CN117527266B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3255—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using group based signatures, e.g. ring or threshold signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/46—Secure multiparty computation, e.g. millionaire problem
    • H04L2209/463—Electronic voting
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Abstract

The present application relates to the field of blockchain technologies, and in particular, to an asynchronous network consensus method, an asynchronous network consensus device, an electronic device, and a readable storage medium; the method comprises the following steps: receiving and verifying transaction proposals broadcast by other consensus nodes in the asynchronous network, and broadcasting the transaction proposals to the other consensus nodes; based on the historical submission record of the transaction proposal, counting the credit points corresponding to each consensus node in the asynchronous network; determining a target consensus round corresponding to a target transaction proposal to be submitted according to the credit points of each consensus node and a random source; by counting credit points of consensus nodes through historical submission records, a random source under an asynchronous network adds consideration to the activity degree of the consensus nodes, so that the probability of correct submission proposal is improved, the activity of an asynchronous consensus algorithm under a Bayesian fault tolerance system of the asynchronous network is improved, and the consensus achievement duration is shortened.

Description

Asynchronous network consensus method, device, electronic equipment and readable storage medium
Technical Field
The present disclosure relates to the field of blockchain technologies, and in particular, to an asynchronous network consensus method, an asynchronous network consensus device, an electronic device, and a readable storage medium.
Background
In a distributed system, the consensus problem is a very difficult problem to solve. The impossible result theorem (FLP) proves theoretically that if any faulty node exists in a distributed system, then the consensus problem is not solvable in an asynchronous system or the consensus is not guaranteed to end in a limited time.
At present, in an asynchronous network system, a random source is introduced when consensus cannot be achieved among nodes, and submission of a proposal is determined based on a random selection result of the random source; however, in the bayer scene, malicious or faulty nodes exist, and the manner of determining the submission based on the random selection result cannot avoid the error proposal of selecting the bayer nodes; thus, the whole asynchronous network system is influenced by the Bayesian node, and the delay of the consensus time is caused.
Disclosure of Invention
According to various embodiments of the application, an asynchronous network consensus method, an asynchronous network consensus device, an electronic device and a readable storage medium are provided, so that the influence of a Bayesian node on an asynchronous network can be reduced, and the consensus duration can be shortened.
In a first aspect, the present application provides an asynchronous network consensus method, the method comprising:
Receiving and verifying transaction proposals broadcast by other consensus nodes in the asynchronous network, and broadcasting the transaction proposals to the other consensus nodes; based on the historical submission record of the transaction proposal, counting the credit points corresponding to each consensus node in the asynchronous network; and determining that the target consensus round corresponds to the target transaction proposal to be submitted according to the credit points of each consensus node and the random source.
By means of the method, credit points of the consensus nodes are counted based on the historical submission records, consideration of the activity of the consensus nodes is added to a random source under the asynchronous network, probability of correct submission of the proposal is improved, activity of an asynchronous consensus algorithm under a Bayesian fault tolerance system of the asynchronous network is improved, and consensus achievement duration is shortened.
In a possible implementation manner of the first aspect, after the receiving and verifying the transaction proposal broadcast by other consensus nodes in the asynchronous network, the method further comprises:
based on the structure of the directed acyclic graph, storing the received transaction proposal sent by each consensus node in each consensus round; wherein each of said transaction proposals is validated by a quorum of consensus nodes, and each proposal references a quorum of transaction proposals of a previous round.
In a possible implementation manner of the first aspect, the history submission record includes at least one of a number of times that the consensus node submitted the correct transaction proposal and a number of times that a previously submitted transaction proposal was referenced in the directed acyclic graph; the statistics of reputation points corresponding to each consensus node in an asynchronous network based on the historical submission records of the transaction proposal comprises the following steps:
based on at least one of the number of times the correct transaction proposal was submitted and the number of times the previous submitted transaction proposal was referenced, a reputation score corresponding to each of the consensus nodes in the asynchronous network is counted.
In a possible implementation manner of the first aspect, the determining that the target consensus round corresponds to the target transaction proposal to be submitted according to the reputation score of each consensus node and a random source includes:
and in the target consensus round, if the credit score of a first consensus node is larger than the credit score of a second consensus node determined based on the random source, taking a transaction proposal sent by the first consensus node in the target consensus round and the quoted transaction proposal as the target transaction proposal.
In a possible implementation manner of the first aspect, the determining that the target consensus round corresponds to the target transaction proposal to be submitted according to the reputation score of each consensus node and a random source includes:
Submitting the first target transaction proposal if the second target transaction proposal to be submitted, which is determined in the second consensus round, refers to the first target transaction proposal which is not submitted in the first consensus round; updating the credit points of each consensus node in the second consensus round based on the quotation relation of the transaction proposal of each consensus node to the first target transaction proposal; if the third target transaction proposal to be submitted, which is determined based on the updated credit score, is different from the second target transaction proposal, replacing the second target transaction proposal with the third target transaction proposal; the first target transaction proposal is a transaction proposal submitted by other consensus nodes in the asynchronous network at the first consensus round.
In a possible implementation manner of the first aspect, the determining that the target consensus round corresponds to the target transaction proposal to be submitted according to the reputation score of each consensus node and a random source includes:
in a preset integral statistical period, calculating the total credit integral of all the consensus nodes based on the credit integral of each consensus node; and determining the target transaction proposal based on the operation result of the modulo operation of the random source and the total credit score.
In a possible implementation manner of the first aspect, the determining the target transaction proposal based on a modulo operation of the random source and the total reputation score includes:
dividing an integral interval corresponding to each node based on the credit integral of each consensus node and the total credit integral; and determining the target transaction proposal based on the integral interval corresponding to the operation result.
In a possible implementation manner of the first aspect, before the statistics of the reputation points corresponding to each of the consensus nodes in the asynchronous network based on the historical submission record of the transaction proposal, the method further includes:
a first submitted target transaction proposal is determined based on the random source.
In a second aspect, the present application provides a data synchronization apparatus, including:
a receiving unit, configured to receive and verify a transaction proposal broadcast by other consensus nodes in an asynchronous network, and broadcast the transaction proposal to the other consensus nodes;
the statistics unit is used for counting credit points corresponding to each consensus node in the asynchronous network based on the historical submission records of the transaction proposal;
and the output unit is used for determining that the target consensus round corresponds to the target transaction proposal to be submitted according to the credit points of each consensus node and the random source.
In a third aspect, the present application provides an electronic device comprising a memory storing a computer program and a processor implementing the method of any one of the first or second aspects when executing the computer program.
In a fourth aspect, the present application provides a computer readable storage medium having stored thereon a computer program which when executed by a processor implements the method of any one of the first or second aspects.
In a fifth aspect, the present application provides a computer program product for, when run on an electronic device, causing the electronic device to perform the method of any one of the first or second aspects above.
It will be appreciated that the advantages of the second to fifth aspects may be found in the relevant description of the first aspect, and are not described here again.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
Fig. 1 is a schematic architecture diagram of an asynchronous network cluster according to an embodiment of the present application;
FIG. 2 is a schematic diagram of a transaction proposal of an asynchronous network according to an embodiment of the present application;
fig. 3 is a schematic implementation flow chart of an asynchronous network consensus method provided in an embodiment of the present application;
FIG. 4 is a schematic diagram of a transaction proposal of an asynchronous network according to another embodiment of the present application;
FIG. 5 is a schematic diagram of a transaction proposal of an asynchronous network according to another embodiment of the present application;
FIG. 6 is a schematic diagram of a fast determination of a transaction proposal based on a random source and points provided in an embodiment of the present application;
fig. 7 is a schematic structural diagram of an asynchronous network consensus device according to an embodiment of the present application;
fig. 8 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
Detailed Description
Embodiments of the technical solutions of the present application will be described in detail below with reference to the accompanying drawings. The following examples are only for more clearly illustrating the technical solutions of the present application, and thus are only examples, and are not intended to limit the scope of protection of the present application.
Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application; the terms "comprising" and "having" and any variations thereof in the description and claims of the present application and in the description of the figures above are intended to cover non-exclusive inclusions.
In the description of the embodiments of the present application, the technical terms "first," "second," etc. are used merely to distinguish between different objects and are not to be construed as indicating or implying a relative importance or implicitly indicating the number of technical features indicated, a particular order or a primary or secondary relationship. In the description of the embodiments of the present application, the meaning of "plurality" is two or more unless explicitly defined otherwise.
Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the present application. The appearances of such phrases in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Those of skill in the art will explicitly and implicitly appreciate that the embodiments described herein may be combined with other embodiments.
In the description of the embodiments of the present application, the term "and/or" is merely an association relationship describing an association object, which means that three relationships may exist, for example, a and/or B may mean: a exists alone, A and B exist together, and B exists alone. In addition, the character "/" herein generally indicates that the front and rear associated objects are an "or" relationship.
Currently, in existing asynchronous network consensus algorithms, a completely random value (random source) is typically employed to determine whether a proposal or a group of proposals is allowed to be submitted, which may be generated by a simple hash calculation or threshold signature.
However, the value obtained by hashing the input random source does not consider the consensus state of each consensus node in the asynchronous network at all, the random source can determine the submitting result of the consensus protocol on probability, and for an asynchronous network system with the Bayesian node, a certain probability can not submit a correct proposal through the random source, so that the delay of consensus submitting is increased.
In addition, a submitting result determined based on a random source is obtained through a threshold signature mode, the communication process among the consensus nodes is increased, a random number (random source) determined in a range can be obtained through the information of the consensus nodes participating in the signature, and a proposal for submitting the consensus nodes which are active in the range is selected based on the random number. Although this approach can avoid the proposal submission of the bye-busy node to a certain extent, it is not suitable to determine the activity of the consensus node to submit the proposal according to the activity of the node participating in the random number generation, because compared with the broadcasting and verification process of the transaction proposal, the threshold signature process is easier, and there is a high probability that some consensus nodes submitting low activity can also participate in the threshold signature easily, but are difficult to participate in the proposal process, for example, the situation that the broadcasting of the proposal has high delay and is ignored by other consensus nodes.
Based on the problem of long time consumption of consensus, the embodiment of the application provides a consensus method of an asynchronous network, which is based on historical submission records of consensus nodes to count node credit points, and improves the activity of a Bayesian fault-tolerant system under the asynchronous network by combining consideration of the credit points of the consensus nodes, and improves the probability and efficiency of submitting correct proposals.
To facilitate understanding of the principles of implementation of the solutions by those skilled in the art, related technical terms are first described.
1. Asynchronous network: the asynchronous network assumes that the sending and receiving of messages is done with a complete asynchronization, that is, there may be any discrepancy in the clocks between the participants. Under the assumption of an asynchronous network, the reliability and the ordering of the messages cannot be guaranteed, so that more complex mechanisms are needed to guarantee the correctness and the safety of communication.
2. Asynchronous binary consensus (Asynchronous Binary Agreement, ABA): refers to nodes under an asynchronous network system that determine whether a proposal can be submitted through several rounds of communication and random numbers.
3. Directed acyclic graph (Directed Acyclic Graph, DAG): the proposal with legal number (n-f) of signatures is associated through the DAG structure, and the ABA process can be omitted in the submitting process, so that the proposal submitting process is simplified.
The following describes an application scenario of the asynchronous network consensus method proposed in the present application through a specific embodiment.
Referring to fig. 1, fig. 1 is a schematic diagram of an architecture of an asynchronous network cluster according to an embodiment of the present application. As shown in fig. 1, the architecture of the asynchronous network cluster may include a plurality of common nodes, such as node a, node B, node C, and node D, for example, with four common nodes being illustrated. Wherein f disuse nodes can be allowed to exist in the asynchronous network cluster, and 1 disuse node is allowed to exist in the 4 nodes (3f+1 nodes); in addition to disguising itself as being in an asynchronous network (e.g., not responding to a request), a disguising node may attack other nodes that may be in an asynchronous network, e.g., by distributing inconsistent messages to different nodes, thereby affecting the activity of the asynchronous network consensus protocol.
On the one hand, each consensus node in the asynchronous network cluster can complete the consensus process through the submitting proposal of the ABA process. On the other hand, each consensus node in the asynchronous network cluster can also adopt the structure of the directed acyclic graph to maintain the transaction proposal broadcasted by each consensus node; in each consensus round, each consensus node generates a transaction proposal, and each transaction proposal is correspondingly stored at each vertex of the DAG by continuously broadcasting the own transaction proposal and receiving the transaction proposals of nodes of other consensus nodes.
For example, as shown in the asynchronous network architecture of fig. 1, based on the scenario assumption of the asynchronous network, a single master node is not specified, each consensus node initiates a proposal at each consensus round, and forwards the proposal to other consensus nodes by means of reliable broadcasting, and at the same time, receives and verifies the transaction proposal broadcasted by other consensus nodes.
Wherein, any consensus node in the asynchronous network system does not necessarily receive proposals of all other consensus nodes, each consensus node continuously tries to send transaction proposals to other consensus nodes by reliable broadcasting until the other consensus nodes reply to the received message, and the consensus node enters the next round after receiving legal number of transaction proposals. For example: node a broadcasts transaction proposal A1 to nodes B, C and D on round 1, while also receiving transaction proposals B1, C1, D1 that nodes B, C and D send to him; then node a attempts to send proposal A1 to nodes B, C and D, respectively, until node B replies to the received message, and node a does not repeat to node B, nodes C and D being the same; node a does not go to the next round after it receives a quorum number of proposals (including its own proposal), such as proposal A1, B1, C1, and constructs a second round of new proposal A2. Node a may not receive enough proposal to enter the r+1 round at a certain round r, and it may be considered that this node a is in an asynchronous state network (e.g., a and other nodes are disconnected).
It should be noted that, the transaction proposal of each consensus round of DAG maintenance is a process that a proposal receives completion, i.e. a process of a bayer pattern broadcast is completed, and does not represent that a node has agreed. Fig. 1 illustrates only an architecture of an asynchronous network cluster, wherein a greater number of consensus nodes may also be included, without limitation.
In some embodiments, the consensus algorithm of the asynchronous network may generate a shared coin, a globally consistent random source (random number), after several rounds of proposals have received the end of the job, to select which proposals may be submitted. The random number can be generated through simple hash calculation or can be obtained through a threshold signature mode, the generation algorithm of the random number is not limited, and the generation result of the random number is only ensured to be consistent in all consensus nodes. Each consensus node can also calculate a hash value hash (r) of the current round information through a agreed random number sound field algorithm, for example, the random number can ensure enough discretization; if the random number is required to be unpredictable, a threshold signature method can be used, such as that all consensus nodes sign (r) the r rounds of information.
As shown in fig. 2, for convenience in explaining the implementation process of the embodiment of the present application, based on the architecture of the directed acyclic graph DAG, the transaction proposal generated by each consensus node under each consensus round is connected; the vertex of a DAG is selected through sharing coins, so that the process of submitting the proposal according to the credit points of the consensus nodes is more intuitively and indirectly described in the embodiment of the application.
It should be noted that the implementation of the embodiments of the present application does not rely solely on the structure of DAG association, but is equally applicable to the case of the conventional asynchronous consensus ABA (Asynchronous Binary Agreement) process and variants thereof. For example, during the voting phase of ABA, each consensus node determines whether to submit the proposal via a random number, and may also determine whether to submit the proposal based on the reputation score of the consensus node.
As shown in fig. 2, the transaction proposal maintained for the DAG structure, at which consensus round shared coins are generated (random source) is determined based on different commit algorithms; the different algorithms interpret the DAG structure in different ways, e.g., the DAG-riter algorithm defines 4 consecutive rounds in the DAG as one commit, such as two commit rounds 1234 and 5678, with the corresponding random number generated in the last round (4 and 8) of each commit, determining the proposed that was committed. The generation of the random number may be performed by performing a modulo operation based on the number of nodes in the consensus cluster, e.g., the consensus cluster has n nodes, so each column of the DAG has n vertex positions, and after the random number c of the r-th round is calculated, n is modulo, and then the transaction proposal of the (c mod n) vertex of the r-th round in the DAG column is taken as an index to be submitted.
It should be noted that, each consensus node generates its DAG structure according to its own received transaction proposal, for example, node a receives proposals A1, B1 and C1 in round 1, then column 1 of DAG of node a is definitely A1, B1 and C1, node B may receive proposals B1, C1 and D1, then column 1 of DAG of node B is proposals B1, C1 and D1 different from the view of node a.
As shown in fig. 2 (a), a random number is generated in round 4, a hash value is calculated for the number of rounds of consensus, i.e. hash (4) gives a hash value h, and then h is used to modulo the cluster size, i.e. h mod 4, to obtain an integer in the range of 0,4, e.g. 1, and the proposal found by the index is the proposal of node B, in round 4 is proposal B4.
Wherein, in the DAG structure, each proposal is validated by a legal number of n-f (quorum) nodes, and each proposal refers to n-f front 1-round proposals to ensure the consistency of the DAG structure. After selecting proposal B4 on round 4 by random numbers, all proposals (A3, B3, D3, A2, C2, D2, A1, B1, C1, D1) on B4 and the path it references can be submitted.
Accordingly, the random numbers generated by the 4 th round are completely random; as shown in fig. 2 (b), if the value generated by the random number selects the proposal C4 of the consensus node C, because the asynchronous network environment may not be received by most nodes, there is no way to select the proposal that can be submitted, and the proposal of 1-3 rounds may be delayed until the next time point of random number generation, thereby increasing the delay of proposal submission. Even, since the result of the generation of the random number is completely probabilistic, it is possible to select the proposal of Xr (r is round, X is node) in a certain period of time, and if the node X is a byesting node, the proposal in the period of time cannot be submitted, which affects the consensus activity of the asynchronous network.
In order to solve the problem of affecting the consensus activity of the asynchronous network, the specific implementation process of the consensus method of the asynchronous network is further described below by an embodiment based on the asynchronous network cluster architecture.
Referring to fig. 3, a schematic implementation flow chart of an asynchronous network consensus method is provided in an embodiment of the present application. The method can be applied to any consensus node in the asynchronous network cluster in fig. 1, and as shown in fig. 3, the method can include the following steps:
s301, receiving and verifying transaction proposals broadcast by other consensus nodes in the asynchronous network, and broadcasting the transaction proposals to the other consensus nodes.
Illustratively, each consensus node initiates a proposal at each consensus round, and forwards the proposal to other consensus nodes in a reliable broadcast manner, and at the same time, receives and verifies the proposals broadcast by other consensus nodes.
In some embodiments, after receiving and verifying the transaction proposal broadcast by other consensus nodes in the asynchronous network, the method further comprises: based on the structure of the directed acyclic graph, the received transaction proposal sent by each consensus node in each consensus round is stored.
Wherein each transaction proposal is validated by a quorum of consensus nodes, and each proposal references a quorum of transaction proposals of a previous round.
As shown in fig. 2 (a), nodes A, B, C and D represent different consensus nodes in an asynchronous network; an represents the proposal of node a at the nth round, and nodes B, C and D are the same. Each consensus node receives at least a legal number of the other consensus nodes' proposal for each consensus round, and can enter the next consensus round to generate a new proposal for the transaction. The connection between the vertices in the DAG structure indicates the quotation relationship of the transaction proposal in each round of consensus, each round of transaction proposal refers to the legal number of transaction proposals in the previous round, and the validity is ensured and the voting approval of the quoted proposal is indicated; for example, the vertex A2 superscript A, B, C indicates that proposal A2 references the last round of proposal A1, B1, C1.
Illustratively, in an asynchronous network cluster, each consensus node maintains a transaction proposal initiated by the respective node based on the DAG graph, and stores a legal certificate of the respective transaction proposal to a vertex of a corresponding consensus round of the DAG after the voting passes by the respective consensus node initiates the consensus transaction proposal. Because the opportunity of submitting the transaction proposal by each consensus node in the asynchronous network cluster is different, the consensus round of each consensus node is different, and the state of the DAG graph maintained by each consensus node is also different.
S302, based on historical submission records of transaction proposals, credit points corresponding to all the consensus nodes in the asynchronous network are counted.
In the embodiment of the application, when the proposal is selected to be submitted, in combination with the activity of the consensus node, if one node is more active (for example, the more times of the proposal that is successfully submitted in history, the higher probability that the proposal is selected to be submitted is. And characterizing the liveness of the consensus nodes through the credit points, and counting the credit points of each consensus node through the historical submission records of the consensus nodes to the transaction proposal.
For example, there may be various algorithms for calculating reputation scores of consensus nodes, taking DAG structure as an example, if a consensus node refers to a proposal that can be submitted before when it is proposed, the consensus node may submit the proposal with high probability (for example, in fig. 1, the proposal of starting consensus node at round 5 refers to proposal at round 4, which can be submitted before), and accordingly the activity of the node is higher. Therefore, the times of the previous correct submission proposal referenced by the statistical node can be counted in the multi-round submission process, and the credit points of the consensus node are accumulated.
In some embodiments, the history commit record includes at least one of a number of times the consensus node committed the correct transaction proposal and a number of times a previously committed transaction proposal was referenced in the directed acyclic graph; based on the historical submission record of the transaction proposal, counting the credit points corresponding to each consensus node in the asynchronous network, comprising: based on at least one of the number of times the correct transaction proposal was submitted and the number of times the previous submitted transaction proposal was referenced, a reputation score corresponding to each consensus node in the asynchronous network is counted.
For example, when the reputation score is counted, the reputation score can be calculated based on the number of times that the consensus node correctly submits the proposal, that is, the more the number of times that the proposal is correctly submitted and the more the number of times that the proposal which can be submitted before is referred to, the higher the reputation score corresponding to the consensus node is, and the higher the probability that the corresponding transaction proposal is submitted is.
Illustratively, before counting the reputation points corresponding to each consensus node in the asynchronous network based on the historical submission record of the transaction proposal, the method further comprises: a first submitted target transaction proposal is determined based on a random source.
For example, when a history commit record has not been generated, i.e., when an asynchronous network first committed a proposal, the number of nodes in the asynchronous network may be modulo the result based on a hash calculation or a random source of threshold signature generation to determine the proposal that can commit.
Taking the DAG structure as an example, as shown in fig. 2 (a), since no commit occurs before round 4, the reputation score of each node is 0 as an initial value; on round 4, the asynchronous network selects proposal B4 directly by random numbers, at which point B4 exists under the local view of node A, B, C and completes submitting a set of proposals A3-B3-D3-A2-C2-D2-A1-B1-C1-D1. Continuing with the consensus round, as shown in FIG. 4 (B) for node A, B, C in the local DAG view of round 4-7, since proposal B4 has been submitted, node A, B, C references proposal B4 in the statistical integration, and the reputation scores for each node are accumulated, affecting the proposal selection result at round 6.
It should be noted that, each consensus node submits record and reference relation of proposal to its history, and counts the credit points of each node under its view; because the submitting time, the quotation relation of the proposal and the DAG structure for maintaining the proposal in the asynchronous network system are possibly different, when the submitted turns are inconsistent, the credit points of corresponding statistics are also possibly inconsistent.
For example, in view of node D, at round 4, node D does not receive proposal B4 due to network problems, or node D receives proposal B4, but proposal B4 does not satisfy the commit condition under the DAG view constructed by node D: there are no subsequent quorum proposals referring to proposal B4, i.e. there are not enough proposals to vote on him. Therefore, in the 4 th round, the node D will not submit the proposal B4, so as shown in fig. 5, in the DAG structure of the 4 th round to 7 th round under the view of the node D, since the node D does not submit the proposal B4 in the 4 th round, among the reputation scores of the nodes counted in the node D, the node B, C cannot increase the reputation score through the reference paths of the proposal B5 and the proposal C5, and the corresponding accumulated situation of the reputation scores of the nodes is different from the accumulated situation of the node A, B, C.
Illustratively, for the process of ABA, the reputation score for each node may be calculated based on the number of times each node submitted the proposal correctly.
S303, determining that the target consensus round corresponds to the target transaction proposal to be submitted according to the credit points of each consensus node and the random source.
In the embodiment of the application, when the submittable proposal is determined based on a random source, the probability of selecting the submittable target transaction proposal is improved by combining the credit points counted for each node. In this case, when the node determined based on the random source is inconsistent with the node determined based on the reputation score, the proposal of the node with the highest reputation score may 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 time between nodes, replacing the proposal of the node selected before based on the proposal of the node determined after the credit integration of the node is reckoned, and taking the proposal of the node as a target transaction proposal which can be submitted; in one case, the reputation points of each node are subjected to modulo calculation by utilizing a random source, and a target transaction proposal which can be submitted is directly determined according to the calculation result.
It should be noted that, each submission is all the proposals on the submission reference path, but the submitted proposals will not be repeatedly submitted; for example, at the time of the 4 th round of commit, the proposals on the proposal B4 and proposal B4 reference paths are committed, at the time of the 6 th round of commit, the proposals on the proposal B6 and proposal B6 reference paths are committed, but the proposals on the submitted proposal B4 and proposal B4 reference paths are no longer committed.
In some embodiments, determining that the target consensus round corresponds to the target transaction proposal to be submitted based on the reputation score of each consensus node and the random source comprises:
and in the target consensus round, if the credit score of the first consensus node is larger than the credit score of the second consensus node determined based on the random source, taking the transaction proposal sent by the first consensus node in the target consensus round and the quoted transaction proposal as target transaction proposals.
For example, when the node determined based on the random source is inconsistent with the node having the highest reputation score, the proposal determined based on the node having the highest reputation score may be substituted for the proposal determined based on the random source. For example, on round 5, nodes A, B, C all refer to B4, all accumulate reputation scores, and it is assumed that node A, B, C is the node with the highest reputation score, node D is the node with the lowest reputation score, and the proposal of node D selected by the random number is replaced by the proposal of node B according to the reputation score of the node, i.e., proposal B6 is submitted as the target transaction proposal after accumulating reputation scores on round 5.
In some embodiments, determining that the target consensus round corresponds to the target transaction proposal to be submitted based on the reputation score of each consensus node and the random source comprises:
submitting the first target transaction proposal if the second target transaction proposal to be submitted, which is determined in the second consensus round, refers to the first target transaction proposal which is not submitted in the first consensus round; updating the credit points of each consensus node in the second consensus round based on the quotation relation of the transaction proposal of each consensus node to the first target transaction proposal; and if the third target transaction proposal to be submitted, which is determined based on the updated credit and point, is different from the second target transaction proposal, replacing the second target transaction proposal with the third target transaction proposal.
The first target transaction proposal is submitted by other consensus nodes in the asynchronous network in a first consensus round.
As described above, the submission timings of the asynchronous network are not determined, and the submission timings corresponding to the nodes are not completely synchronized, and the statistics of the reputation scores need to refer to the data of the historical submission records, so that temporary inconsistencies may exist in the reputation scores of the corresponding statistics, resulting in inconsistencies in the consensus protocol.
As shown in figure 4 (a), there is no reference to proposal B4 or proposal B4 does not get a quorum of proposals under the local DAG view of node D, so node D cannot choose proposal B4 to commit; further, as shown in fig. 5, in the DAG structure view of the node D at round 4 to 7, since the proposal B4 is not submitted at round 4, the reputation integration cannot be increased by the node A, B, C through the reference paths of the proposals A5, B5 and C5, so that the node D selects the proposal C6 in the proposal selection of round 6, or in the view of the node D, the reputation integration of the node A, B, C at round 5 is not accumulated, so that the integration at the moment of the node B is probably not highest, and the node D is probably not lowest, so that the proposal B6 is not selected during the selection, and inconsistent selection results of the node D and the node A, B, C occur.
As also shown in fig. 5, in the view of node D, proposal B4 is only referenced by proposal B5 and proposal C5, less than the value of quorum (n-f=3) of the bayer security definition, and therefore proposal B4 is not submitted on round 4; node D is in round 6, proposal C6 is referenced by proposals B7, C7 and D7, the value of quorum is satisfied, and a reference path C6-B5-B4 (or C6-C5-B4) exists with B4, so that node D can select proposal C6 in round 6. Since proposal C6 and proposal B4 have reference paths, node D can safely submit proposal B4 first. Also, since in the view of node D, proposal B4 can be referenced and submitted by proposal C6, proposal C6 must reference n-f proposals of the 5 th round, while node A, B, C can submit B4, indicating that in the view of node A, B, C, at least n-f proposals of the 5 th round reference proposal B4, two quorum values cross, and there must be f+1 reference paths from C6 to B4; thus, similarly, even if the proposal selected by the random number is D6, the node D submits the proposal B4 not submitted before based on the same principle.
As shown in fig. 5, after submitting the proposal B4, the node D re-counts the reputation points of the current nodes, namely, adds corresponding reputation points to the nodes A, B, C of the proposals A5, B5 and C5 referring to the proposal B4, and then re-selects the proposal B6 and replaces the proposal C6 for submitting according to the new reputation point statistics data.
For example, the process of selecting the proposal C6 from the DAG view of the node D can be taken as an election process, and the proposal C6 is taken as an election result; the election process can keep the original shared random number selection process, and the random numbers obtained by using the shared random algorithm in a certain round R are the same on all nodes; however, the election result selected in the election stage is not a direct result of submitting the proposal, but is only used to assist in submitting a proposal that was not submitted before. The process of proposal replacement by the node D refers to replacing the proposal randomly selected in the election stage with the proposal of the node with high activity according to the statistics of the credit score, and the replacement step follows the submitting step.
Illustratively, the first target transaction proposal may be proposal B4, the first consensus round may be the 4 th round in fig. 5, the second target transaction proposal may be the proposal of the transaction proposal selected by node D at the 6 th round, such as proposal C6 or D6, the second consensus round may be the 6 th round in fig. 5, and the third target transaction proposal may be the proposal of the node D reckoning the reputation score determination of each node after submitting the first target transaction proposal, such as proposal B6.
Illustratively, in the conventional asynchronous consensus ABA process, the proposal that can be submitted can also be determined by replacing the randomly selected 0 or 1 in the BA phase in the manner described above, by broadcasting a value that is integrated with the reputation of each node.
In some embodiments, determining that the target consensus round corresponds to the target transaction proposal to be submitted based on the reputation score of each consensus node and the random source comprises:
in a preset integral statistical period, calculating the total credit integral of all the consensus nodes based on the credit integral of each consensus node; and determining a target transaction proposal based on the operation result of the modular operation of the random source and the total credit integral.
In an asynchronous network, since a node fails to submit a proposal in time (e.g., node D in the figure fails to submit proposal B4 in time), and the post election stage may be based on random selection, and reputation integration based on a reference relationship between the non-submitted proposal and the newly elected proposal is not counted, the probability of selecting a proposal that cannot be submitted in the election stage is high, such as proposal C6 in fig. 5. When a proposal which is not submitted in time exists in the nodes, the reputation points corresponding to the nodes also need to be recalculated, and the proposal determined based on the new reputation points replaces the originally selected proposal, so that the process of selecting the proposal is complicated.
Therefore, in order to reduce the complexity of selecting proposal process, an integration statistics period is defined, the integration statistics result of each interval k round is applied to the proposal selection of the k th round thereafter, and the integration value is re-counted in the k th round thereafter; i.e., the reputation scores of all consensus nodes are updated every k rounds of consensus.
Illustratively, after the asynchronous network system generates the random number, the proposal of the node with higher credit score is selected with higher probability; because the credit points of all nodes are combined, the selected proposal has a high probability of being a proposal which can be submitted, and when the proposal which is not submitted in time before is submitted by the proposal, the new submission is only in the period k, the statistical result of the new credit points is not applied, and the frequent replacement process is avoided. That is, a certain consensus node cannot submit a proposal in time in a corresponding round, and as long as the proposal is submitted in k rounds, the situation that the credit score statistics tables of different consensus nodes are different can be avoided; and as long as the credit score statistical tables of all the consensus nodes are kept consistent and the random numbers generated by each round of consensus are consistent, the proposals selected by each consensus node in each round of consensus are consistent.
In some embodiments, determining the target transaction proposal based on a modulo operation of the random source and a total reputation score comprises:
dividing an integral interval corresponding to each node based on the credit integral and the total credit integral of each consensus node; and determining a target transaction proposal based on the integral interval corresponding to the operation result.
Illustratively, as shown in fig. 6, the reputation scores of the node A, B, C, D are respectively 10, 5, 2 and 8, which are respectively accumulated to obtain a sequential score list 10,15, 17 and 25, then a random number C is introduced or generated, and the total reputation score 25 is modulo C mod 25 to obtain an operation result, when the operation result falls in the [0,10 ] integration interval, the proposal of the node a is selected, when the operation result falls in the [10,15 ] integration interval, the proposal of the node B is selected, when the operation result falls in the [15,17 ] integration interval, the proposal of the node C is selected, and when the operation result falls in the [17, 25) integration interval, the proposal of the node D is selected.
Accordingly, by the above range statistics, as long as the random number C is completely discrete, the probability of C to a is 40%, the probability of B is 20%, the probability of C is 8%, and the probability of D is 32%; i.e. the proposal of nodes that have higher reputation scores after generation of the random number is selected with higher probability.
According to the embodiment of the application, the consideration of node liveness is added to a random source under an asynchronous network system, the probability of submitting a correct proposal is improved, the activity of an asynchronous consensus algorithm under a Bayesian fault tolerance system of the asynchronous network is improved, and the consensus duration is shortened; by counting credit points of the consensus nodes through the existing historical submission records, extra cryptographic calculation and network communication are not needed to be introduced, and the resource cost is low.
It should be understood that the sequence number of each step in the foregoing embodiment does not mean that the execution sequence of each process should be determined by the function and the internal logic of each process, and should not limit the implementation process of the embodiment of the present application in any way.
Corresponding to the asynchronous network consensus method provided in the above embodiment, fig. 7 shows a schematic structural diagram of the asynchronous network consensus device provided in the embodiment of the present application, and for convenience of explanation, only the portion relevant to the embodiment of the present application is shown.
Referring to fig. 7, the asynchronous network device includes:
a receiving unit 71, configured to receive and verify a transaction proposal broadcast by another consensus node in the asynchronous network, and broadcast the transaction proposal to the other consensus node;
A statistics unit 72, configured to, based on a historical submission record of the transaction proposal, count reputation points corresponding to each consensus node in an asynchronous network;
and an output unit 73, configured to determine that the target consensus round corresponds to the target transaction proposal to be submitted according to the reputation score and the random source of each consensus node.
In a possible implementation, the receiving unit 71 is further configured to store, based on the structure of the directed acyclic graph, the received transaction proposal sent by each of the consensus nodes at each consensus round; wherein each of said transaction proposals is validated by a quorum of consensus nodes, and each proposal references a quorum of transaction proposals of a previous round.
In one possible implementation, the history commit record includes at least one of a number of times that the consensus node committed the correct transaction proposal and a number of times that a previously committed transaction proposal was referenced in the directed acyclic graph; the statistics unit 72 is further configured to count a reputation score corresponding to each of the consensus nodes 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 transaction proposal that was submitted before is referenced.
In a possible implementation, the output unit 73 is further configured to, at the target consensus round, use a proposal of a transaction issued by the first consensus node at the target consensus round and the referenced proposal of the transaction as the target proposal if the credit score of the first consensus node is greater than the credit score of the second consensus node determined based on the random source.
In a 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, which is determined in the second consensus round, refers to the first target transaction proposal not submitted in the first consensus round; updating the credit points of each consensus node in the second consensus round based on the quotation relation of the transaction proposal of each consensus node to the first target transaction proposal; if the third target transaction proposal to be submitted, which is determined based on the updated credit score, is different from the second target transaction proposal, replacing the second target transaction proposal with the third target transaction proposal; the first target transaction proposal is a transaction proposal submitted by other consensus nodes in the asynchronous network at the first consensus round.
In a possible implementation manner, the output unit 73 is further configured to calculate, in a preset integral statistics period, a total reputation integral of all the consensus nodes based on the reputation integral of each of the consensus nodes; and determining the target transaction proposal based on the operation result of the modulo operation of the random source and the total credit score.
In a possible implementation manner, the output unit 73 is further configured to divide an integral interval corresponding to each node based on the reputation integral of each consensus node and the total reputation integral; and determining the target transaction proposal based on the integral interval corresponding to the operation result.
In a possible implementation, the output unit 73 is further configured to determine the first submitted target transaction proposal based on the random source.
According to the embodiment of the application, the consideration of node liveness is added to a random source under an asynchronous network system, the probability of submitting a correct proposal is improved, the activity of an asynchronous consensus algorithm under a Bayesian fault tolerance system of the asynchronous network is improved, and the consensus duration is shortened; by counting credit points of the consensus nodes through the existing historical submission records, extra cryptographic calculation and network communication are not needed to be introduced, and the resource cost is low.
Fig. 8 shows a schematic diagram of the hardware configuration of the electronic device 8.
As shown in fig. 8, the electronic device 8 of this embodiment includes: at least one processor 80 (only one is shown in fig. 8), a memory 81, said memory 81 having stored therein a computer program 82 executable on said processor 80. The steps in the above-described method embodiments are implemented when the processor 80 executes the computer program 82, for example S301 to S303 shown in fig. 3. Alternatively, the processor 80, when executing the computer program 82, performs the functions of the modules/units of the apparatus embodiments described above.
It is to be understood that the structure illustrated in the embodiments of the present application does 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 certain components may be combined, or certain components may be split, or different arrangements of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.
The electronic device 8 may be a common node in the asynchronous network cluster, for example, a computing device such as a desktop computer, a notebook computer, a palm computer, and a cloud server. The electronic device 8 may include, but is not limited to, a processor 80, a memory 81. It will be appreciated by those skilled in the art that fig. 8 is merely an example of the electronic device 8 and is not meant to be limiting as the electronic device 8, and may include more or fewer components than shown, or may combine certain components, or different components, e.g., the server may also include an input transmitting device, a network access device, a bus, etc.
The processor 80 may be a central processing unit (Central Processing Unit, CPU), but may also be other general purpose processors, digital signal processors (Digital Signal Processor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), off-the-shelf programmable gate arrays (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
A memory may also be provided in the processor 80 for storing instructions and data. In some embodiments, the memory in the processor 80 is a cache memory. The memory may hold instructions or data that the processor 80 has just used or recycled. If the processor 80 needs to reuse the instruction or data, it may be called directly from the memory. Repeated accesses are avoided and the latency of the processor 80 is reduced, thereby improving the efficiency of the system.
The above-mentioned memory 81 may in some embodiments be an internal storage unit of the electronic device 8, such as a hard disk or a 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 memory Card (Flash Card) or the like, which are provided on the electronic device 8. Further, the memory 81 may also include both an internal storage unit and an external storage device of the electronic device 8. The memory 81 is used for storing an operating system, application programs, boot loader (BootLoader), data, other programs, etc., such as program codes of computer programs, etc. The memory 81 may also be used to temporarily store data that has been transmitted or is to be transmitted.
In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.
It should be noted that the structure of the electronic device is only illustrated by way of example, and other entity structures may be included based on different application scenarios, and the entity structure of the electronic device is not limited herein.
In the foregoing embodiments, the descriptions of the embodiments are emphasized, and in part, not described or illustrated in any particular embodiment, reference is made to the related descriptions of other embodiments.
The present application also provides a computer readable storage medium storing a computer program which, when executed by a processor, implements steps for implementing the various method embodiments described above.
The present embodiments provide a computer program product which, when run on a server, causes the server to perform steps that enable the implementation of the method embodiments described above.
The integrated modules/units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the present application may implement all or part of the flow of the method of the above embodiment, or may be implemented by a computer program to instruct related hardware, where the computer program may be stored in a computer readable storage medium, and when the computer program is executed by a processor, the computer program may implement the steps of each method embodiment described above. Wherein the computer program comprises computer program code, which may be in the form of source code, object code, executable files or in some intermediate form, etc. The computer readable medium may include: any entity or device capable of carrying computer program code, a recording medium, a U disk, a removable hard disk, a magnetic disk, an optical disk, a computer Memory, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), an electrical carrier signal, a telecommunications signal, a software distribution medium, and so forth.
The apparatus, the electronic device, the computer storage medium, and the computer program product provided in the embodiments of the present application are all configured to execute the method provided above, so that the beneficial effects achieved by the apparatus, the electronic device, the computer storage medium, and the computer program product can refer to the beneficial effects corresponding to the method provided above, and are not described herein again.
It should be understood that the foregoing is only intended to assist those skilled in the art in better understanding the embodiments of the present application and is not intended to limit the scope of the embodiments of the present application. It will be apparent to those skilled in the art from the foregoing examples that various equivalent modifications or variations can be made, for example, certain steps may not be necessary in the various embodiments of the detection methods described above, or certain steps may be newly added, etc. Or a combination of any two or more of the above. Such modifications, variations, or combinations are also within the scope of embodiments of the present application.
The technical features of the above embodiments may be arbitrarily combined, and all possible combinations of the technical features in the above embodiments are not described for brevity of description, however, as long as there is no contradiction between the combinations of the technical features, they should be considered as the scope of the description.
It should also be understood that the manner, condition, class and division of the embodiments in the embodiments of the present application are for convenience of description only and should not be construed as being particularly limited, and the various manners, classes, conditions and features of the embodiments may be combined without contradiction.
It is also to be understood that in the various embodiments of the application, terms and/or descriptions of the various embodiments are consistent and may be referenced to one another in the absence of a particular explanation or logic conflict, and that the features of the various embodiments may be combined to form new embodiments in accordance with their inherent logic relationships.
Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
In the embodiments provided in the present application, it should be understood that the disclosed apparatus/network device and method may be implemented in other manners. For example, the apparatus/network device embodiments described above are merely illustrative, e.g., the division of the modules or units is merely a logical functional division, and there may be additional divisions in actual implementation, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection via interfaces, devices or units, which may be in electrical, mechanical or other forms.
The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
The above embodiments are only for illustrating the technical solution of the present application, and are not limiting; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present application, and are intended to be included in the scope of the present application.
Finally, it should be noted that: the foregoing is merely a specific embodiment of the present application, but the protection scope of the present application is not limited thereto, and any changes or substitutions within the technical scope of the present disclosure should be covered in the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims (11)

1. A method of asynchronous network consensus, the method comprising:
receiving and verifying transaction proposals broadcast by other consensus nodes in the asynchronous network without designating a single master node, and broadcasting the transaction proposals to the other consensus nodes;
based on the historical submission records of the transaction proposal, counting the credit points corresponding to each consensus node in an asynchronous network;
and determining that the target consensus round corresponds to the target transaction proposal to be submitted according to the credit points of each consensus node and the random source.
2. The method of claim 1, wherein after said receiving and verifying transaction proposals broadcast by other consensus nodes in an asynchronous network, the method further comprises:
based on the structure of the directed acyclic graph, storing the received transaction proposal sent by each consensus node in each consensus round;
wherein each of said transaction proposals is validated by a quorum of consensus nodes, and each proposal references a quorum of transaction proposals of a previous round.
3. The method of claim 2, wherein the history commit record includes at least one of a number of times that the consensus node committed the correct transaction proposal and a number of times that a previously committed transaction proposal was referenced in the directed acyclic graph; the statistics of reputation points corresponding to each consensus node in an asynchronous network based on the historical submission records of the transaction proposal comprises the following steps:
Based on at least one of the number of times the correct transaction proposal was submitted and the number of times the previous submitted transaction proposal was referenced, a reputation score corresponding to each of the consensus nodes in the asynchronous network is counted.
4. A method according to any one of claims 1 to 3, wherein said determining that a target consensus round corresponds to a target transaction proposal to be submitted based on reputation scores of each of the consensus nodes and a random source comprises:
and in the target consensus round, if the credit score of a first consensus node is larger than the credit score of a second consensus node determined based on the random source, taking a transaction proposal sent by the first consensus node in the target consensus round and the quoted transaction proposal as the target transaction proposal.
5. A method according to any one of claims 1 to 3, wherein said determining that a target consensus round corresponds to a target transaction proposal to be submitted based on reputation scores of each of the consensus nodes and a random source comprises:
submitting the first target transaction proposal if the second target transaction proposal to be submitted, which is determined in the second consensus round, refers to the first target transaction proposal which is not submitted in the first consensus round;
Updating the credit points of each consensus node in the second consensus round based on the quotation relation of the transaction proposal of each consensus node to the first target transaction proposal;
if the third target transaction proposal to be submitted, which is determined based on the updated credit score, is different from the second target transaction proposal, replacing the second target transaction proposal with the third target transaction proposal;
the first target transaction proposal is a transaction proposal submitted by other consensus nodes in the asynchronous network at the first consensus round.
6. A method according to any one of claims 1 to 3, wherein said determining that a target consensus round corresponds to a target transaction proposal to be submitted based on reputation scores of each of the consensus nodes and a random source comprises:
in a preset integral statistical period, calculating the total credit integral of all the consensus nodes based on the credit integral of each consensus node;
and determining the target transaction proposal based on the operation result of the modulo operation of the random source and the total credit score.
7. The method of claim 6, wherein the determining the target transaction proposal based on a modulo operation of the random source and the total reputation score comprises:
Dividing an integral interval corresponding to each node based on the credit integral of each consensus node and the total credit integral;
and determining the target transaction proposal based on the integral interval corresponding to the operation result.
8. The method of claim 1, wherein prior to said counting reputation points corresponding to each of said consensus nodes in an asynchronous network based on said historical submittal records of said transaction proposal, said method further comprises:
a first submitted target transaction proposal is determined based on the random source.
9. An asynchronous network consensus device, comprising:
a receiving unit, configured to receive and verify a transaction proposal broadcast by another consensus node in the asynchronous network without designating a single master node, and broadcast the transaction proposal to the other consensus node;
the statistics unit is used for counting credit points corresponding to each consensus node in the asynchronous network based on the historical submission records of the transaction proposal;
and the output unit is used for determining that the target consensus round corresponds to the target transaction proposal to be submitted according to the credit points of each consensus node and the random source.
10. An electronic device comprising a memory storing a computer program and a processor implementing the method of any one of claims 1 to 8 when the computer program is executed by the processor.
11. A computer readable storage medium, on which a computer program is stored, characterized in that the computer program, when being executed by a processor, implements the method of any one of claims 1 to 8.
CN202410017937.3A 2024-01-05 Asynchronous network consensus method, device, electronic equipment and readable storage medium Active CN117527266B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202410017937.3A CN117527266B (en) 2024-01-05 Asynchronous network consensus method, device, electronic equipment and readable storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202410017937.3A CN117527266B (en) 2024-01-05 Asynchronous network consensus method, device, electronic equipment and readable storage medium

Publications (2)

Publication Number Publication Date
CN117527266A true CN117527266A (en) 2024-02-06
CN117527266B CN117527266B (en) 2024-05-17

Family

ID=

Citations (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200074548A1 (en) * 2018-08-29 2020-03-05 Credit Suisse Securities (Usa) Llc Systems and methods for calculating consensus data on a decentralized peer-to-peer network using distributed ledger
WO2020138606A1 (en) * 2018-12-28 2020-07-02 연세대학교 산학협력단 Fault-tolerant consensus method for eliminating obstacle factors of consensus in blockchain network
CN112039964A (en) * 2020-08-24 2020-12-04 大连理工大学 Node reputation consensus method based on block chain
CN112073483A (en) * 2020-08-28 2020-12-11 武汉大学 Authority certification consensus method and system based on credit and committee endorsement mechanism
CN112149181A (en) * 2020-09-29 2020-12-29 合肥城市云数据中心股份有限公司 Hybrid cloud data center data transmission method with credit value analysis function
CN112152797A (en) * 2020-08-26 2020-12-29 西安电子科技大学 Block chain remote data auditing and monitoring method and system, computer equipment and terminal
CN113222690A (en) * 2021-04-27 2021-08-06 铭数科技(青岛)有限公司 Block chain consensus method applied to regional energy Internet
CN113343311A (en) * 2021-06-04 2021-09-03 北京邮电大学 Block chain consensus method and system based on reputation model and digital signature mechanism
CN113642019A (en) * 2021-08-16 2021-11-12 中国人民解放军国防科技大学 Double-layer grouping Byzantine fault-tolerant consensus method and system
US20220271957A1 (en) * 2019-09-11 2022-08-25 Visa International Service Association Blockchain sharding with adjustable quorums
CN115633035A (en) * 2022-12-07 2023-01-20 长春大学 Improved PBFT (physical layer transmission) based block chain consensus algorithm for Internet of things
CN115641139A (en) * 2022-07-12 2023-01-24 浙江师范大学 Block chain consensus method based on weight plan behavior certification
CN115834579A (en) * 2022-11-08 2023-03-21 北京邮电大学 Block chain consensus method, device and system and electronic equipment
CN115883308A (en) * 2022-11-18 2023-03-31 杭州趣链科技有限公司 Method and device for selecting main node in consensus algorithm, electronic equipment and storage medium
WO2023056958A1 (en) * 2021-10-09 2023-04-13 支付宝(杭州)信息技术有限公司 Consensus method, blockchain system, and consensus node
WO2023077796A1 (en) * 2021-11-04 2023-05-11 中国信息通信研究院 Backbone node access method and blockchain system
CN116723200A (en) * 2023-08-11 2023-09-08 杭州趣链科技有限公司 Cluster changing method and device, electronic equipment and computer readable storage medium
WO2023168993A1 (en) * 2022-03-07 2023-09-14 腾讯科技（深圳）有限公司 Blockchain-based data processing method, apparatus, and device, medium, and product
WO2023184881A1 (en) * 2022-03-30 2023-10-05 杭州趣链科技有限公司 Proposal consensus execution method, blockchain system, device and storage medium

Patent Citations (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200074548A1 (en) * 2018-08-29 2020-03-05 Credit Suisse Securities (Usa) Llc Systems and methods for calculating consensus data on a decentralized peer-to-peer network using distributed ledger
WO2020138606A1 (en) * 2018-12-28 2020-07-02 연세대학교 산학협력단 Fault-tolerant consensus method for eliminating obstacle factors of consensus in blockchain network
US20220271957A1 (en) * 2019-09-11 2022-08-25 Visa International Service Association Blockchain sharding with adjustable quorums
CN112039964A (en) * 2020-08-24 2020-12-04 大连理工大学 Node reputation consensus method based on block chain
CN112152797A (en) * 2020-08-26 2020-12-29 西安电子科技大学 Block chain remote data auditing and monitoring method and system, computer equipment and terminal
CN112073483A (en) * 2020-08-28 2020-12-11 武汉大学 Authority certification consensus method and system based on credit and committee endorsement mechanism
CN112149181A (en) * 2020-09-29 2020-12-29 合肥城市云数据中心股份有限公司 Hybrid cloud data center data transmission method with credit value analysis function
CN113222690A (en) * 2021-04-27 2021-08-06 铭数科技(青岛)有限公司 Block chain consensus method applied to regional energy Internet
CN113343311A (en) * 2021-06-04 2021-09-03 北京邮电大学 Block chain consensus method and system based on reputation model and digital signature mechanism
CN113642019A (en) * 2021-08-16 2021-11-12 中国人民解放军国防科技大学 Double-layer grouping Byzantine fault-tolerant consensus method and system
WO2023056958A1 (en) * 2021-10-09 2023-04-13 支付宝(杭州)信息技术有限公司 Consensus method, blockchain system, and consensus node
WO2023077796A1 (en) * 2021-11-04 2023-05-11 中国信息通信研究院 Backbone node access method and blockchain system
WO2023168993A1 (en) * 2022-03-07 2023-09-14 腾讯科技（深圳）有限公司 Blockchain-based data processing method, apparatus, and device, medium, and product
WO2023184881A1 (en) * 2022-03-30 2023-10-05 杭州趣链科技有限公司 Proposal consensus execution method, blockchain system, device and storage medium
CN115641139A (en) * 2022-07-12 2023-01-24 浙江师范大学 Block chain consensus method based on weight plan behavior certification
CN115834579A (en) * 2022-11-08 2023-03-21 北京邮电大学 Block chain consensus method, device and system and electronic equipment
CN115883308A (en) * 2022-11-18 2023-03-31 杭州趣链科技有限公司 Method and device for selecting main node in consensus algorithm, electronic equipment and storage medium
CN115633035A (en) * 2022-12-07 2023-01-20 长春大学 Improved PBFT (physical layer transmission) based block chain consensus algorithm for Internet of things
CN116723200A (en) * 2023-08-11 2023-09-08 杭州趣链科技有限公司 Cluster changing method and device, electronic equipment and computer readable storage medium

Similar Documents

Publication Publication Date Title
US20230089896A1 (en) Sharded Permissioned Distrbuted Ledgers
CN110875893B (en) Consensus verification method, check node and block chain system
JP2023509889A (en) Blockchain-based data detection method and device, computer device and program
Zhang et al. Reaching consensus in the byzantine empire: A comprehensive review of bft consensus algorithms
CN113610531B (en) Consensus method, block chain system and consensus node
CN109919760A (en) Byzantine failure tolerance common recognition algorithm based on voting mechanism
WO2023184881A1 (en) Proposal consensus execution method, blockchain system, device and storage medium
US20230017790A1 (en) Graphic-blockchain-orientated hybrid consensus implementation apparatus and implementation method thereof
CN114553434A (en) Consensus method, block chain system and consensus node
CN110661656B (en) Block chain rapid consensus method and device
CN114884652A (en) Method, system and consensus node for generating random number seed on block chain
CN116743771B (en) Block chain consensus method, apparatus, electronic device and computer readable storage medium
Zhang et al. Prestigebft: Revolutionizing view changes in bft consensus algorithms with reputation mechanisms
US20220278854A1 (en) Unity Protocol Consensus
CN113347174A (en) Consensus method and device in block chain and electronic equipment
CN117527266B (en) Asynchronous network consensus method, device, electronic equipment and readable storage medium
CN112994891B (en) Transaction request consensus method and system based on threshold signature
CN117527266A (en) Asynchronous network consensus method, device, electronic equipment and readable storage medium
CN110555764A (en) method and system for block chain consistency under decentralized environment
CN116723200B (en) Cluster changing method and device, electronic equipment and computer readable storage medium
CN116846916B (en) Data synchronization method, device, electronic equipment and computer readable storage medium
CN115392912B (en) Random number generation method, system, device and storage medium
CN114466034B (en) Block chain consensus method based on anonymous main node
CN117251889B (en) Block chain consensus method, related device and medium
Nezhadsistani et al. Blockchain consensus algorithms: Past, present, and future trends

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant