CN113630257B - Consensus method, block chain system and consensus node - Google Patents
Consensus method, block chain system and consensus node Download PDFInfo
- Publication number
- CN113630257B CN113630257B CN202111175184.1A CN202111175184A CN113630257B CN 113630257 B CN113630257 B CN 113630257B CN 202111175184 A CN202111175184 A CN 202111175184A CN 113630257 B CN113630257 B CN 113630257B
- Authority
- CN
- China
- Prior art keywords
- message
- consensus
- consensus node
- signature
- node
- 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.)
- Active
Links
Images
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
-
- 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/3236—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 using cryptographic hash functions
- H04L9/3239—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 using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
Abstract
A consensus method, a block chain system and a consensus node, the consensus method comprising: a first round: the first consensus node broadcasts a first message, wherein the first message comprises a transaction set of the consensus proposal and a signature of the first consensus node; and a second round: the consensus node receiving the first message broadcasts a second message, wherein the second message comprises votes and signatures of the transaction set; the vote includes a summary value for the set of transactions; and a third round: after collecting at least Quorum consistent votes from different consensus nodes by the consensus node receiving the second message, if the consensus node does not broadcast different votes for the proposal, a third message is broadcasted, wherein the third message comprises the digest value and the collected signature set; and after the consensus node collects at least Quorum third messages from different nodes, outputting a transaction set corresponding to the abstract value as at least one part of the consensus result.
Description
Technical Field
The embodiment of the specification belongs to the technical field of block chains, and particularly relates to a consensus method, a block chain system and a consensus node.
Background
The Blockchain (Blockchain) is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like. In the block chain system, data blocks are combined into a chain data structure in a sequential connection mode according to a time sequence, and a distributed account book which is not falsifiable and counterfeitable is ensured in a cryptographic mode. Due to the characteristics of decentralized, information non-falsifiable, and autonomy, the blockchain has more and more applications.
Disclosure of Invention
The invention aims to provide a consensus method, a block chain system and a consensus node, comprising the following steps:
an embodiment of a consensus method in a blockchain system comprises:
a first round: the first consensus node broadcasts a first message, wherein the first message comprises a transaction set of the consensus proposal and a signature of the first consensus node;
and a second round: the consensus node receiving the first message broadcasts a second message, wherein the second message comprises votes and signatures of the transaction set; the vote includes a summary value for the set of transactions;
and a third round: after collecting at least Quorum consistent votes from different consensus nodes by the consensus node receiving the second message, if the consensus node does not broadcast different votes for the proposal, a third message is broadcasted, wherein the third message comprises the digest value and the collected signature set;
and after the consensus node collects at least Quorum third messages from different nodes, outputting a transaction set corresponding to the abstract value as at least one part of the consensus result.
An embodiment of a consensus method in a blockchain system comprises:
a first round: the first consensus node broadcasts a first message, wherein the first message comprises a transaction set of the consensus proposal and a signature of the first consensus node;
and a second round: the consensus node receiving the first message broadcasts a second message, wherein the second message comprises votes and signatures of the transaction set; the vote includes a value representing non-approval of the transaction set;
and a third round: after collecting at least Quorum consistent votes from different consensus nodes by the consensus node receiving the second message, if the consensus node does not broadcast a different vote for the proposal, a third message is broadcast, wherein the third message comprises the value representing that the transaction set is not approved and the collected signature set;
after the consensus node collects at least four third messages from different nodes, the transaction set is not output as part of the consensus result.
An embodiment of a blockchain system comprises a consensus node, wherein:
the first consensus node broadcasts a first message, wherein the first message comprises a transaction set of the consensus proposal and a signature of the first consensus node;
the consensus node receiving the first message broadcasts a second message, wherein the second message comprises votes and signatures of the transaction set; the vote includes a summary value for the set of transactions;
after collecting at least Quorum consistent votes from different consensus nodes by the consensus node receiving the second message, if the consensus node does not broadcast different votes for the proposal, a third message is broadcasted, wherein the third message comprises the digest value and the collected signature set;
and after the consensus node collects at least Quorum third messages from different nodes, outputting a transaction set corresponding to the abstract value as at least one part of the consensus result.
An embodiment of a blockchain system comprises a consensus node, wherein:
the first consensus node broadcasts a first message, wherein the first message comprises a transaction set of the consensus proposal and a signature of the first consensus node;
the consensus node receiving the first message broadcasts a second message, wherein the second message comprises votes and signatures of the transaction set; the vote includes a value representing non-approval of the transaction set;
after collecting at least Quorum consistent votes from different consensus nodes by the consensus node receiving the second message, if the consensus node does not broadcast a different vote for the proposal, a third message is broadcast, wherein the third message comprises the value representing that the transaction set is not approved and the collected signature set;
after the consensus node collects at least four third messages from different nodes, the transaction set is not output as part of the consensus result.
An embodiment of a consensus node in a blockchain system, comprising:
a first message receiving unit, configured to receive a first message broadcast by a first consensus node, where the first message includes a transaction set of a consensus offer and a signature of the first consensus node;
a second message broadcasting unit, configured to broadcast a second message after the first message receiving unit receives the first message, where the second message includes votes and signatures for the transaction set; the vote includes a summary value for the set of transactions;
the vote collecting unit is used for collecting votes from the consensus nodes;
a third message broadcasting unit, when the vote collecting unit collects at least Quorum consistent votes from different consensus nodes, if the third message does not broadcast different votes for the proposal, the third message is broadcasted, and the third message comprises the digest value and the collected signature set;
a third message collection unit which collects a third message from the consensus node;
and the output unit is used for outputting the transaction set corresponding to the abstract value as at least one part of the consensus result after the third message collection unit collects at least four third messages from different nodes.
An embodiment of a consensus node in a blockchain system, comprising:
a first message receiving unit, configured to receive a first message broadcast by a first consensus node, where the first message includes a transaction set of a consensus offer and a signature of the first consensus node;
a second message broadcasting unit, configured to broadcast a second message after the first message receiving unit receives the first message, where the second message includes votes and signatures for the transaction set; the vote includes a value representing non-approval of the transaction set;
the vote collecting unit is used for collecting votes from the consensus nodes;
a third message broadcasting unit, after the vote collecting unit collects at least four consistent votes from different consensus nodes, if the third message does not broadcast different votes for the proposal, the third message is broadcasted, and the third message comprises the value representing that the transaction set is not approved and the collected signature set;
a third message collection unit which collects a third message from the consensus node;
and the output unit does not output the transaction set corresponding to the digest value as at least one part of the consensus result after the third message collection unit collects at least four third messages from different nodes.
In the above embodiment, the number of rounds can be reduced to 3 on the certain premise to complete one consensus, and the delay caused by the consensus process is greatly reduced compared with at least 6 rounds in HBBFT. In the embodiment of the application, the two rounds of the RBC process and the two rounds of the ABA process in the HBBFT are combined equivalently by adopting a prospective voting and digital signature technology, so that the required rounds are shortened.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments described in the present disclosure, and it is obvious for a person skilled in the art to obtain other drawings based on these drawings without inventive labor.
FIG. 1 is a diagram illustrating a conventional phase of a practical Byzantine fault tolerance algorithm in one embodiment;
FIG. 2 is a diagram illustrating a view switching phase of an embodiment of a practical Byzantine fault-tolerant algorithm;
FIG. 3 is a schematic diagram of an embodiment of badger Byzantine fault tolerance algorithm;
FIG. 4 is a flow chart of a consensus algorithm in one embodiment of the present description;
FIG. 5 is a schematic diagram of a consensus algorithm in one embodiment of the present description;
FIG. 6 is a schematic diagram of a consensus algorithm in one embodiment of the present description;
FIG. 7 is a schematic diagram of a consensus algorithm in one embodiment of the present description;
FIG. 8 is a schematic diagram of a consensus algorithm in one embodiment of the present description;
FIG. 9 is a schematic diagram of a consensus algorithm in one embodiment of the present description;
FIG. 10 is a flow chart of a consensus algorithm in one embodiment of the present description;
fig. 11 is a diagram of a consensus node architecture in an embodiment of the present disclosure.
Detailed Description
In order to make those skilled in the art better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only a part of the embodiments of the present specification, and not all of the embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments in the present specification without any inventive step should fall within the scope of protection of the present specification.
In the block chain system, different participants can establish a distributed block chain network through deployed nodes (nodes). A decentralized (or multi-centric) distributed book constructed using a chained blockchain structure is maintained at each node (or at most nodes, such as a consensus node) in the distributed blockchain network. Such a blockchain system needs to address the issue of consistency and correctness of the respective ledger data across multiple nodes that are decentralized (or multicenter). Each node runs a blockchain program, and under the design of certain fault tolerance requirements, all loyalty nodes are ensured to have the same transaction through a consensus (consensus) mechanism, so that the execution results of all loyalty nodes on the same transaction are ensured to be consistent, and the transaction and the execution results are packaged to generate a block. The current mainstream consensus mechanisms include: proof of Work (POW), Proof of stock (POS), Proof of commission rights (DPOS), Practical Byzantine Fault Tolerance (PBFT) algorithm, badger Byzantine Fault Tolerance (honeybadger bft) algorithm, and the like.
Taking PBFT as an example, the algorithm is proposed in 1999 by Miguel Castro (Castoterol) and Barbara Liskov (Rickov), solves the problem of low efficiency of the original Byzantine fault-tolerant algorithm, reduces the complexity of the algorithm from exponential level to polynomial level, and enables the Byzantine fault-tolerant algorithm to be feasible in practical system application. This paper was published at 1999 international conference on operating system design and implementation (OSDI 99). In the PBFT algorithm, all copies (replica) are run in a rotation process called View (View). In a certain view, one copy serves as a primary node (primary) and the other copies serve as backup nodes (backups). Views are consecutively numbered integers. The master node is calculated from the formula p = v mod | R |, where v is the view number, p is the copy number, and | R | is the number of copy sets. The assumption in this algorithm is that when there are at most f copies (i.e., nodes) that fail, if there are a total of at least 3f +1 copies, it is guaranteed that security and activity will be provided in the asynchronous system. The set of a certain number of replicas, which is required in order to be able to ensure the data consistency requirements and fault tolerance requirements of all replicas, is typically the set of most nodes in a distributed system, constituting the majority (Quorum). For example, in the case where the total number of nodes n is 3f +1 (the case where n =3f +2 or n =3f generally does not improve the fault tolerance effect), the Quorum is 2f + 1. Thus, for a distributed system containing four nodes, any three nodes can constitute one Quorum.
PBFT includes two processes, Normal Case Phase and View Change Phase, and FIG. 1 is a flow chart of the Normal Case Phase (conventional Phase) process. The Normal Case Phase mainly includes three phases of PRE-PREPARE, and COMMIT, where node number 3 may represent, for example, a down node (represented by x in fig. 1). When a Primary node fails (denoted by x in fig. 2, for example, before a view is changed, i.e., when a Primary node Primary, i.e., a replay 0 (copy 0) fails), a view change (view change) process needs to be started, so that a state adjustment is performed when a system has a failure, and a new Primary node is changed (for example, after a view is changed, a replay 1 is a Primary node Primary). FIG. 2 is a View of View Change Phase. The client may set a timeout mechanism if the master node drops or goes bad without broadcasting the client's request, etc. If timed out, the client may broadcast a request message to all replica nodes. After detecting that the master node is malicious or offline, the replica node may also initiate a View Change protocol stage to Change the master node (often referred to as "master Change"). In addition, the PRE-PREPARE, PREPARE and COMMIT three-stage consensus process may fail due to the proposal of the primary node initiating an error, or the PREPARE and COMMIT stages may not be consistent with the Quorum number (e.g., 2f +1 of 3f +1 nodes, also referred to as a Quorum number), and the consensus may not be completed. It is also possible in these cases to initiate a View Change protocol phase to replace the master node.
The PBFT protocol belongs to the semi-synchronous (partial synchronization) protocol, which is characterized by assuming that the network is asynchronous from the beginning, but can be synchronized from a certain time. To have different nodes agree on the same proposal in the network, the simplest way is to set up a master node, which unifies the opinions of the nodes. By setting the timer, the master node can be prevented from making mistakes. In PBFT, if the Normal Case Phase is not completed within a limited time, Backups is triggered to initiate View Change Phase to replace the master node. The PBFT fixes the primary node in one location and all requests can be sent to the primary node first and then broadcast by the primary node to other cognate nodes. In addition to introducing additional delay in sending requests to the master node, the ingress and egress bandwidth of the master node may also become a performance bottleneck. In contrast, the honeybadgebft (also often abbreviated HBBFT) algorithm belongs to an asynchronous (asynchronous) protocol. Asynchronous protocols are applicable to asynchronous networks, i.e., messages between nodes in such a network may be arbitrarily delayed, but eventually arrive. The timer is removed from the honeybadgebft and the execution of the protocol is driven by a message. Meanwhile, all nodes in the HoneyBadgerBFT algorithm are peer-to-peer, and no difference exists between a main node and a backup node, and a process of changing the main node is omitted. Asynchronous network consensus protocols such as HBBFT and the like have no concept of a main node, and all nodes can propose requests and try to construct blocks, so that the asynchronous network protocols relieve the problems of fairness and single-node bottleneck to a certain extent.
Fig. 3 is a flow chart of a single node angle of the honeybadgebft algorithm. In fact, as mentioned above, all nodes in the honeybadgerbt algorithm are peer-to-peer, that is, all nodes can execute the flow shown in fig. 3. As shown in fig. 3, from the perspective of a single node, the honeybadger bft mainly includes two stages, namely, Reliable BroadCast (RBC) and Asynchronous consensus (ABA, Asynchronous Binary protocol, also referred to as "01 Asynchronous consensus"). In addition, there is an Asynchronous Common Subset (ACS) protocol over RBC and ABA. The RBC stage at least comprises three rounds of message interaction of Rval, Echo and Ready, and the ABA stage at least comprises three rounds of message interaction of Bval, Aux and Coin. RBC guarantees reliable offer broadcasting using three rounds of message interaction. ABA first performs two rounds of voting (Bval and AUX messages) and then knows the proposal of each node uniformly by throwing a Coin (Coin), thereby bypassing the requirement of the semi-synchronous protocol for network synchronization. One HoneyBadgerBFT consensus goes through the RBC stage and at least one ABA stage. In the best case, the probability of 1/2 exists to end the HoneyBadgerBFT consensus process, so that one consensus needs to be completed through 6 rounds. In addition, there is 1/4 probability that the current acquisition process will be completed in the next ABA process, for example, in the second ABA process in fig. 3 (ABA process represented by 7, 8, and 9 rounds), 1/4 probability that the current acquisition process is completed in the second round, and probability that at least 1/4 exists may be completed in the current HoneyBadgerBFT consensus process, so that one consensus needs to be completed through 9 rounds. After the second ABA process, there is overall a probability of 1/8 going into the second ABA process … … and so on.
In addition, for a finally generated block (corresponding to an epoch), one node can run one ACS and n RBCs + n ABAs, n is the number of consensus nodes, wherein 1 RBC and ABA corresponds to a consensus proposal initiated by itself, and the other (n-1) RBCs and ABAs correspond to consensus proposals initiated by other (n-1) nodes. That is, for an epoch, a node initiates a consensus proposal and simultaneously completes consensus proposals initiated by other nodes. Thus, for a node, after at least (n-f) RBCs are finished, the condition that the RBCs are finished (indicated by Ready message) is sent to the ACS, and the ACS gives an initial value to the corresponding ABA, so that the corresponding ABA process is started. After at least (n-f) consensus suggestions complete ABA, if the rest consensus suggestions still do not complete RBC, the initial value is set to 0, and then the ABA process corresponding to the suggestions is executed. From the global perspective, at least (n-f) nodes execute the same consensus process (at least (n-f) different nodes initiate proposed processes), and finally the ACS collects all proposed ABA results and sorts the proposed ABA results with 1 according to some rule to output.
In summary, the honeybadgebft includes at least one RBC (three rounds) and one ABA (three rounds), and if the voting result of the ABA is inconsistent with the coin-throwing result, the protocol enters a new round of ABA (at least three additional rounds). Coin throws introduce uncertainty into the consensus rounds, possibly increasing delay.
The present application provides an embodiment of a consensus algorithm, as shown in fig. 4, specifically including:
s41: the first consensus node broadcasts a first message comprising a set of transactions of the consensus proposal and a signature of the first consensus node.
In an embodiment of the consensus algorithm, 3 rounds of interaction may be included. Similar to HBBFT, the consensus algorithm of the embodiment shown in fig. 5 also belongs to an asynchronous protocol, i.e. it is assumed that messages between nodes in the network can be delayed arbitrarily, but will eventually arrive. Similarly, the timer is removed in the embodiment of fig. 5, and the execution of the protocol is driven by the message; meanwhile, all the nodes can be peer-to-peer without the division of the main node and the backup node, any consensus node can initiate a consensus proposal, and each consensus node can also participate in the consensus process of other nodes for lifting the consensus proposal. The result of one consensus may include the sum of the transaction sets in the consensus proposal in which all nodes in the consensus pick up and obtain at least the Quorum number votes to agree.
From the point of view of a node, e.g.The interaction process from the perspective of initiating the consensus proposal is shown in fig. 5. In one consensus, the first time a match is made,a consensus proposal may be initiated, which may include a packaged set of transactions, e.g., marked as,Wherein the collection can comprise a series of transaction constitutions}. Further, it is possible to prevent the occurrence of,the first message may be broadcast to other consensus nodes, such as broadcast to in fig. 5、And. The first message of the broadcast may includeIs a consensus proposal. This message may be referred to as a Val message.
The message may also include a first pair of common node pairsA signature, e.g. as. Generally, the first common nodeCan use its own private key pairDirect signature to obtainOr can be firstly alignedPerforming hash calculation to obtain a hash value (i.e. a digest value), and then signing the hash value by using a private key thereof, thereby obtaining the hash valueOr by using its own private key pairAnddirectly signing or pairing data thereinAndthe hash value of the data inside is signed.
The format of the Val message may be as< r, , >Where r may represent the r-th consensus. For example, this pairIf the consensus proposal is the r-th consensus, the transaction set of the next consensus proposal isMay correspond to the r +1 st consensus. The above-mentionedIt is also possible to use the private key pair itself comprising r andsignature of the data within. Similarly, the first pair can also bePerforming hash calculation to obtain a hash value, and then signing the data including the hash value and r by using a private key of the hash value to obtainIt is also possible to use its own private key for the data processing systemAnd the hash value of the data including r.
S43: a second message is broadcast by the consensus node receiving the first message, wherein the second message comprises votes and signatures for the transaction set; the vote includes the set of transactionsThe digest value of (a).
At the end of the first round, the consensus node receiving the first message may verify the correctness of the received first message. For example,can adoptIn the first messageThe signature of (2) is verified. If the verification is passed, S43 is entered.
S43, more particularly in FIG. 5, of receiving the first messageThe consensus node may broadcast the second message. In the second round of message interaction,、、each broadcasting a second message to other consensus nodes. The second message broadcasted by the consensus node may comprise the pairA vote of the initiated consensus proposal.
For example,、、the other consensus nodes may be told their vote for the consensus proposal by broadcasting a second message, which may be a vote of approval or disapproval of the message set in the consensus proposal. Specifically, at the end of the first round, the consensus node that received the Val message may calculate a hash value for the set of transactions for which the Val message is a consensus proposal. Further, if the consensus node approves the consensusThe proposed set of transactions may broadcast the hash value in the 2 nd round of messaging. Conversely, if the consensus node does not recognize the consensusThe proposed transaction set, may broadcast 0 in the 2 nd round of message interaction. This broadcasted second message mayTo be denoted as Bval. In addition, while the hash value is broadcast in the 2 nd round of message interaction, 1 may be used to indicate that the vote for the proposal represented by the hash value is approved or passed, and 0 may be used to indicate that the vote for the proposal represented by the hash value is not approved or passed, which is a simple change.
In the course of this round, the number of turns,may not participate in the broadcast becauseThe consensus proposal is initiated in the first round, which itself may representIs approved for the message set in the consensus proposal, so that the second round can be processed by、、And respectively broadcasting the second message to other consensus nodes.
It should be noted that the consensus node may change its own view and vote again, i.e. send out a plurality of different Bval messages. For example,a Bval message whose content is the hash value of the transaction set may be sent for the first time to indicate approval of the transaction set in the consensus proposal, and then a Bval message whose content is 0 may be sent again to indicate disapproval of the transaction set in the consensus proposal. As yet another example of an implementation of the method,the content can be sent out for the first timeA Bval message of 0 to indicate non-approval of the set of deals in the consensus offer, and then a Bval message whose contents are the hash values of the set of deals may be issued again to indicate approval of the set of deals in the consensus offer.
Additionally, a signature for the set of transactions may also be included in the second message. As mentioned above, the consensus node receiving the first message at the end of the first round may verify the correctness of the received first message, e.g. byAuthenticationWhether the signature of (2) is correct. Furthermore, the consensus node that receives the first message may sign the transaction set in the first message with its own private key. For exampleFor transaction set in first messageSigning to obtain(ii) a Or can beFirst to each otherPerforming hash calculation to obtain a hash value (i.e. a digest value), and then signing the hash value by using a private key thereof, thereby obtaining the hash value。
Similarly, the format of the Bval message may be as follows< r, hash, >Wherein r may represent the nth consensus and hash isHash value of (1), representing a pairThe voting viewpoint of (a) is acceptance. Then theIt is also possible to use the private key pair itself comprising r andsignature of the data within. Similarly, the first pair can also bePerforming hash calculation to obtain a hash value, and then signing the data including the hash value and r by using a private key of the hash value to obtainOr signing the hash value of the data including r and the hash by using the private key of the user.
Receive fromAfter sending Val message, similarly, Val message can be calculatedAnd signing the hash value by using a private key thereof to obtain the hash valueFurther, a Bval message may also be broadcast. The calculated hash value may be included in the Bval message toAnd signaturesMay also include r, hash value and signature。
Receive fromAfter sending Val message, similarly, Val message can be calculatedAnd signing the hash value by using a private key thereof to obtain the hash valueFurther, a Bval message may also be broadcast. The Bval message may include the calculated hash value and the signatureMay also include r, hash value and signature。
S45: third round the consensus node receiving the second message collects at least four consistent votes from different consensus nodes, and broadcasts a third message comprising the digest value and the collected signature if it has not broadcast a different vote for the proposal.
The consensus nodes in the second round broadcast the second message so that at the end of the second round, the consensus nodes receiving the second message can collect votes in the second message and broadcast a third message.
For exampleThe votes in the Bval message may be collected at the end of the second round. Suppose thatIs collected to,、The votes in the separately broadcast Bval messages are all the transaction setsA hash value of, andalso in the Val message broadcast in the first round isThe corresponding hash is obviouslyA hash value of, thenAt least qurum consistent digest values were collected in this round (e.g., when f =1, qurum =3, actually 4).
For exampleAt the end of the second round, the votes in the Bval message can be collected, assumingIs collected to、The votes in the respectively broadcasted second messages are all the transaction setsA hash value of, andvotes in a second message broadcast in a second round, if also the set of transactionsThe hash value of (also representing an approval of the transaction set), and received in the first roundIn transmitted Val messagesIs also the same hash value, thenAt least qurum consistent digest values were collected in this round (e.g., when f =1, qurum =3, actually 4). It should be noted that, in the first round,the broadcast Val message may includeSo that at the end of the first roundCan calculate that included in the Val messageSo that the hash value of the second round can be countedIn broadcast Bval messagesWhether the hash value of (a) is the same as that received in the second roundAndcoming fromWhether the hash values are the same or not is judged, and whether at least Quorum consistent hash values from different consensus nodes are collected or not is further judged.
In addition, the consensus node may also collect signatures of different nodes at the end of the second round, as described above. The number of votes collected up to the second round can be counted by signature. For exampleIs collected respectively to、、The same hash value of the signature indicates that there are 3 votes indicating approval for the hash (which may include receiving the vote at the end of the first roundSignature of same hash value in transmitted Val messageA total of 4 signatures are collected for the same hash value).
For theIf at least Quorum consistent hash values from different consensus nodes are collected and are directed to the proposal by themselvesIf 0 has not been broadcast (i.e., a different vote), then a third message is broadcast. The third message may be denoted as a Prom message, meaning that the commitment is not to offerAnd changing the viewpoint. As has been described in the foregoing, the present invention,a hash value of (1) may indicate approval and 0 may indicate non-approval.Against this proposalNot broadcasting 0 means that there is no suggestionHave possessedFrom the viewpoint of non-recognition, it is needless to say that such non-recognition may be expressed in other forms than 0.Andand similarly.
The third message of the broadcast may include the collected pairsSuch as the hash values and signatures collected in the first and second rounds described above.
Thus, the format of the Prom message may be as < r, hash, < signature set > >.
For exampleSuppose thatIs collected in the second round,、The votes in the separately broadcast Bval messages are all the transaction setsThe hash value of (1), thus collecting、Andare respectively coupled with(orHash value of) is、、Is voted for, andthe self-pair is also included in the Val message broadcast in the first round(orHash value of) isThe hash value of. In this way it is possible to obtain,at least qurum consistent digest values were collected in this round (e.g., when qurum = 3). Further, it is possible to prevent the occurrence of,in the Prom message broadcast in the third round, the hash value and the collected set of transactions for the offer by the different nodes may be includedRepresenting a recognized hash value and a set of signatures, e.g.、、、。
For example, supposeIs collected in the second round、The votes in the separately broadcast Bval messages are all the transaction setsThe hash value of (1), thus collectingAndare respectively coupled with(orHash value of) is、Is voted for, andthe Val message broadcast in the first round also includes its pair(orHash value of) isIs voted for, andits pair is also included in the Bval message broadcast in the second round(orHash value of) isThe voting of (1). In this way it is possible to obtain,at least qurum consistent digest values (e.g., when qurum = 3) and signatures of different nodes are collected in the first and second rounds. Further, it is possible to prevent the occurrence of,in the Prom message broadcast in the third round, the hash value and the collected set of transactions for the offer by the different nodes may be includedRepresenting a recognized hash value and a signature set, e.g. comprising、、、。
It should be noted that the signature set may be replaced by an aggregate signature or a threshold signature.
S47: and after the consensus node collects at least Quorum third messages from different nodes, outputting a transaction set corresponding to the abstract value as at least one part of the consensus result.
After the third round of execution, the consensus node that received the Prom message may count the number of the collected Prom messages. The condition that the consensus node sends out the Prom message in the third round is that at least four consistent votes from different consensus nodes are collected in the second round, and the consensus node does not broadcast different votes for the proposal by itself, i.e., the consensus node confirms at the end of the second round that at least four consensus nodes (including itself) total to the proposalAll votes areAre approved. However, the consensus result cannot be output immediately after the second round is finished, and it is necessary to observe whether other nodes collect at least the number of scores of the proposal at the end of the second roundRepresents a agreed vote, and therefore needs to be confirmed by a third round of the Prom message, and the commitment by this Prom message is no longer directed to the same proposal itselfRepresent different perspectives.
For exampleAt least four consistent digest values are collected in the first round and the second round, and further,in the Prom message broadcast in the third round, the hash value and the collected set of transactions for the offer by the different nodes may be includedRepresenting a recognized hash value and a signature set, e.g. comprising、、、。
For exampleAt least four consistent digest values are collected in the first round and the second round, and further,in the Prom message broadcast in the third round, the hash value and the collected set of transactions for the offer by the different nodes may be includedRepresenting a recognized hash value and a signature set, e.g. comprising、、、。
Thus, by a third wheel, e.g.At least Quorum Prom messages may be collected. With the qurum number of Prom messages,it can be confirmed that each of at least the Quorum consensus nodes has collected a set of transactions for the offerRepresenting at least the number of votes approved, and each consensus node issuing a Prom message promises that the view of the vote will no longer be altered, and, as such,the consensus can be further completed, namely the transaction set corresponding to the abstract valueAnd outputting as at least a portion of the consensus result.、Andand similarly. Similarly, other consensus nodes are e.g.、Andthe consensus can be further completed, namely, the transaction set corresponding to the abstract valueAnd outputting as at least a portion of the consensus result.
The third round of the Prom message may add a signature. For exampleProm messages broadcast in the third round may includeFor in Prom message<r, hash, <Signature collection>>The signature of (2).
The embodiment of fig. 5 can be as shown in the figureCan also be extended to the field of electronic devices、、Andare all executed. In the former case, each of the consensus nodes having collected at least qurum third messages from different nodes may output the transaction sets corresponding to the digest values as all of the consensus results, and may be any of fig. 6, 7, and 8 in addition to fig. 5.
For the latter, i.e. by、、Andare all executed, FIG. 5 isThe initiating consensus improvement of the one nodeThe angle of view of、Andany of which may also initiate a proposal and the other consensus nodes cooperate to perform a similar process as described above, thus being an overlay of fig. 5, 6, 7, 8 as a whole.
For the latter case, e.g.The set of transactions that initiate the consensus proposal is,The set of transactions that initiate the consensus proposal is、The set of transactions that initiate the consensus proposal is,The set of transactions that initiate the consensus proposal isIn this way, the flow rate of the gas,can correspond to,Can correspond to,Can correspond to,Can correspond to. If the execution is normal, the output result of the consensus of each consensus node is a great,,,As to the output result,,,The order of (c) may be ordered according to a certain rule, for example, according to the magnitude order of the corresponding hash values.
Specifically, the results of the above process may be collected by the consensus node. For example for the case of fig. 5, 6, 7, 8 superimposed, for exampleCan collectThe result of performing the consensus process described above, including for example, forIs finally a consensus result of 1, forIs finally a consensus result of 1, forIs finally a consensus result of 1, forIs finally a consensus result of 1. Wherein the content of the first and second substances,is composed ofThe proposal of consensus is initiated and,is composed ofThe proposal of consensus is initiated and,is composed ofThe proposal of consensus is initiated and,is composed ofA consensus proposal is initiated.
In the above embodiment, the number of rounds can be reduced to 3 on the certain premise to complete one consensus, and the delay caused by the consensus process is greatly reduced compared with at least 6 rounds in HBBFT. In fact, in the embodiment of the present application, it is equivalent to merge the last two rounds of the RBC process and the first two rounds of the ABA process in the HBBFT by using the look-ahead voting and digital signature techniques, so as to shorten the required rounds. The look-ahead voting refers to voting in the second round of the Bval in the above embodiment, and the HBBFT votes in the fifth round of the Bval in the ABA process. The digital signature refers to the digital signature used in the first round and the second round in the above embodiments.
In the embodiment of the present application, similar to PBFT and HBBFT, a certain number of error nodes may be tolerated, for example, f error nodes may be tolerated in a common node with a total n of 3f +1, and qurum is 2f + 1. An example of a failed node with f (f = 1) is given below.
in the first round of the process,broadcasting a Val message, the first message including a set of transactions for which a proposal is consensusAndis signed。E.g. a collection comprising a series of transaction components}。For example, isFirst to each otherAnd performing hash calculation to obtain a hash value, and then signing the hash value by using a private key of the hash value.
The format of the Val message may be as< r, , >Where r may represent the r-th consensus. Thus, the first pair can bePerforming hash calculation to obtain a hash value, and then signing the data including the hash value and r by using a private key of the hash value to obtainOr by using its own private key pairThe data including r is directly signed or pairedAnd the hash value of the data including r.
At the end of the first round, the consensus node that received the Val message can verify the correctness of the received Val message. In particular, the method comprises the following steps of,can adoptIn the first messageIs signedAnd performing verification, and entering a second round if the verification is passed. In a similar manner, the first and second substrates are,can adoptIn the first messageIs signedAnd performing verification, and entering a second round if the verification is passed. WhileIs a failed node.
In the second round, the consensus node receiving the Val message broadcasts a Bval message, wherein the Bval message comprises the transaction setVoting and signing of (2); the vote includes the set of transactionsThe hash value of. Due to the fact thatIs a failed node and therefore does not respond, i.e. does not broadcast the Bval message, instead、Respectively broadcasting the Bval message to other common nodes.Broadcast Bval messages include, for exampleHash value of andusing its own private key pairSignature of hash value of. In addition, the Bval message may be, for example< r, hash, >Therein, thenCan beWith a private key pair comprising r andsignature of the data including the hash value of (d).
Receive fromAfter sending Val message, similarly, Val message can be calculatedAnd signing the hash value by using a private key thereof to obtain the hash valueFurther, a Bval message may also be broadcast. The Bval message can includeHash value and signature of。
At the end of the second round, the consensus node that received the Bval message may collect the votes in Bval. For theAt the end of the second round, the votes in the Bval message are collected,The votes in the separately broadcast Bval messages all include the transaction setA hash value of, andalso in the Val message broadcast in the first round isThe hash corresponding thereto isA hash value of, and,the broadcast Bval messages include respective signaturesAnd,the signature is also included in the Val message broadcast in the first roundThen, thenA total of 3 consistent hash values were collected at the end of the second round (when f =1, Quorum = 3). For theCollected at the end of the second roundThe vote in the broadcast Bval message isHash value of andand is andthe votes in the Bval message broadcast in the second round are also hash values andand received in the first roundIn transmitted Val messagesIs also the same hash value andthen, then3 consistent hash values are collected in the round, and the number of the quadrum is met. For theCollected at the end of the second roundThe vote in the broadcast Bval message isHash value of andand is andthe votes in the Bval message broadcast in the second round are also hash values andand received in the first roundIn transmitted Val messagesIs also the same hash value andthen, then3 consistent hash values are collected in the round, and the number of the quadrum is met.
In the third round, after collecting at least four consistent hash values from different consensus nodes, the consensus node receiving the Bval message broadcasts a Prom message, wherein the Prom message comprises the hash values and the collected signatures, and if the consensus node does not broadcast 0 for the proposal.
For example,in the Prom message broadcast in the third round, the hash value and the collected set of transactions for the offer by the different nodes may be includedRepresenting a recognized hash value and a set of signatures of、、。In the Prom message broadcast in the third round, the hash value and the collected set of transactions for the offer by the different nodes may be includedRepresenting a recognized hash value and a signature set, which is also、、。In the Prom message broadcast in the third round, the hash value and the collected set of transactions for the offer by the different nodes may be includedRepresenting a recognized hash value and a signature set, which is also、、。
After the third round of execution, the consensus node receiving the Prom messages counts the number of the collected Prom messages, and if at least Quorum Prom messages from different nodes are collected, the transaction set corresponding to the hash value is collectedAnd outputting as at least a portion of the consensus result.
For theCollected after the third roundAndthe broadcasted Prom message, and itself also broadcasted the Prom message, thus totaling 3 Prom messages collected.
Similar toCollected after the third roundAndthe broadcasted Prom message, and itself also broadcasted the Prom message, thus totaling 3 Prom messages collected.
Similar toCollected after the third roundAndthe broadcasted Prom message, and itself also broadcasted the Prom message, thus totaling 3 Prom messages collected.
By means of the third wheel the first wheel,3 proms are collected, it can be confirmed that each of at least 3 consensus nodes (which satisfy Quorum) has collected a set of transactions for the offerIndicating at least 3 votes approved (that satisfy the query), and each consensus node issuing a Prom message promises that the view of the vote will no longer be altered, and thus,the consensus can be further completed, namely, the transaction set corresponding to the hash valueAnd outputting as at least a portion of the consensus result.、Are also similar, i.e.、And collecting the transaction corresponding to the hash valueAnd outputting as at least a portion of the consensus result.
FIG. 9 is a view ofThe process of initiating a consensus proposal, similarly,anda similar procedure can also be performed, i.e.Andseparately initiating a set of transactionsAnda consensus proposal is initiated. WhileAs previously described is a failed node and therefore does not initiate a consensus proposal. Thus, finally、Andthe output result in this consensus is,,Keep the same consensus result, wherein the consensus result comprises the same transaction sets with the same content and sequence. Of course, it is also possible to output the result as a final check through the above-mentioned consensus process,} andthe consensus is followed by the negative vote, soAnd is not included in the result output by the consensus.
The present application further provides another embodiment of a consensus algorithm, as shown in fig. 10, specifically including:
s101: the first consensus node broadcasts a first message comprising a set of transactions of the consensus proposal and a signature of the first consensus node.
From the point of view of a node, e.g.The interaction process from the perspective of initiating the consensus proposal is shown in fig. 5. In one consensus, the first time a match is made,a consensus proposal may be initiated, which may include a packaged set of transactions, e.g., marked as,Wherein the collection can comprise a series of transaction constitutions}. Further, it is possible to prevent the occurrence of,the first message may be broadcast to other consensus nodes, such as broadcast to in fig. 5、And. The first message of the broadcast may includeIs a consensus proposal. This message may be referred to as a Val message.
The message may also include a first pair of common node pairsA signature, e.g. as. Generally, the first common nodeCan use its own private key pairDirect signature to obtainOr can be firstly alignedPerforming hash calculation to obtain a hash value (i.e. a digest value), and then signing the hash value by using a private key thereof, thereby obtaining the hash value。
The format of the Val message may be as< r, , >Where r may represent the r-th consensus. For example, this pairIf the consensus proposal is the r-th consensus, the transaction set of the next consensus proposal isMay correspond to the r +1 st consensus. The above-mentionedIt is also possible to use the private key pair itself comprising r andsignature of the data within. Similarly, the first pair can also bePerforming hash calculation to obtain a hash value, and then signing the data including the hash value and r by using a private key of the hash value to obtain。
S103: a second message is broadcast by the consensus node receiving the first message, wherein the second message comprises votes and signatures for the transaction set; the vote includes a value representing non-approval of the transaction set.
At the end of the first round, the consensus node receiving the first message may verify the correctness of the received first message. For example,can adoptIn the first messageThe signature of (2) is verified. If the transaction set is not validated, at S103 a broadcast is broadcast that the transaction set is not approvedThe vote of (2) is represented by, for example, 0 as non-approval.
S103, as shown in fig. 5 specifically, the consensus node receiving the first message may broadcast the second message. In the second round of message interaction,、、each broadcasting a second message to other consensus nodes. The second message broadcasted by the consensus node may comprise the pairInitiated consensus proposalsThe vote of (2) is, for example, 0 as described above. This second message of the broadcast may be denoted as Bval.
In the course of this round, the number of turns,may not participate in the broadcast becauseThe consensus proposal is initiated in the first round, which itself may representIs approved for the message set in the consensus proposal, so that the second round can be processed by、、And respectively broadcasting the second message to other consensus nodes.
It should be noted that the consensus node may change its own view and vote again, i.e. send out a plurality of different Bval messages. For example,a Bval message whose content is the hash value of the transaction set may be sent for the first time to indicate approval of the transaction set in the consensus proposal, and then a Bval message whose content is 0 may be sent again to indicate disapproval of the transaction set in the consensus proposal. As yet another example of an implementation of the method,a Bval message whose content is 0 may be issued for the first time to indicate non-approval of the set of deals in the consensus proposal, and then a Bval message whose content is a hash value of the set of deals may be issued again to indicate approval of the set of deals in the consensus proposal.
Additionally, a signature for the set of transactions may also be included in the second message. The consensus node receiving the first message may sign with its own private key a value representing a non-approval of the set of transactions in the first message. For exampleDenote by 0 the set of transactions in the first messageIf not, the private key is used to sign 0 to obtain。
Similarly, the format of the Bval message may be as follows< r, 0, >Where r may represent the r-th consensus and 0 represents non-approval of the transaction setThe value of (c). Then theOr the consensus node adopts a self private key to sign data comprising r and 0.
S105: third round the consensus node receiving the second message collects at least four consistent votes from different consensus nodes, and if it has not broadcast a different vote for the proposal, broadcasts a third message comprising the value indicating disapproval of the transaction set and the collected signature set.
The consensus nodes in the second round broadcast the second message so that at the end of the second round, the consensus nodes receiving the second message can collect votes in the second message and broadcast a third message.
For exampleAt the end of the second round, the votes in the Bval message can be collected, assumingIs collected to、The votes in the second messages broadcast separately are all 0 values, andthe vote in the second message broadcast in the second round is also 0, thenAt least qurum consistent digest values were collected in this round (e.g., when f =1, qurum =3, actually 3).
In addition, the consensus node may also collect signatures of different nodes at the end of the second round, as described above. The number of votes collected in the second round can be counted by signature. For exampleIs collected respectively to、、A value of 0 for the signature indicates a set of transactions for the offerA total of 3 votes indicating disapproval. Of course, the uniqueness of the messages and thus the number of the messages can also be determined by recognizing the secure transmission channel established between the nodes. The secure Transport channel is created by a technique such as a Message Authentication Code (MAC), a secure Transport Layer protocol (TTL), or the like.
For theIf at least Quorum 0 values from different consensus nodes are collected and are themselves directed to the proposalIf a different vote has not been broadcast, a third message is broadcast. The third message may be denoted as a Prom message, meaning that the commitment is not to offerAnd changing the viewpoint. As previously mentioned, a 0 may indicate no approval.Against this proposalNo other points of view have been broadcast, meaning that no proposals have been madeIn the light of the recognition that it is already known,andis also the same asAnd (4) the same.
The third message of the broadcast may include the collected pairsSuch as the 0 values and signatures collected in the first and second rounds described above.
Thus, the format of the Prom message may be as < r, 0, < signature set > >.
For example, supposeIs collected in the second round、The votes in the broadcast Bval messages are all 0 values, and thus are collectedAndrespective signature, andits signature of vote 0 is also included in the Bval message broadcast in the second round. In this way it is possible to obtain,at least Quorum consistent 0 values (e.g., when Quorum = 3) and signatures of different nodes are collected in the first and second rounds. Further, it is possible to prevent the occurrence of,in the Prom message broadcast in the third round, it can includeThe value of 0 and the collection of transactions for the offer by the different nodesA value of 0 indicating non-approval and a signature set, e.g., including、、。
It should be noted that the signature set may be replaced by an aggregate signature or a threshold signature.
In addition, due toBroadcasting a proposed set of transactions in a first roundRepresenting an approval of the proposed set of transactions and, therefore,the Prom message can be not sent in the third round, or the opinion of the node can be changed after the second round, namely, the Bval message with different voting contents is sent, but the execution results of other nodes are not influenced.
S107: after the consensus node collects at least four third messages from different nodes, the transaction set is not output as part of the consensus result.
After the third round of execution, the consensus node that received the Prom message may count the number of the collected Prom messages. The condition that the consensus node sends out the Prom message in the third round is that at least four consistent votes from different consensus nodes are collected in the second round, and the consensus node does not broadcast different votes for the proposal by itself, i.e., the consensus node confirms at the end of the second round that at least four consensus nodes (including itself) total to the proposalAre all not agreed upon. However, the consensus result cannot be output immediately after the second round is finished, and it is necessary to observe whether other nodes collect at least the number of scores of the proposal at the end of the second roundRepresents a different vote and therefore needs to be confirmed by a third round of the Prom message, and by which commitment itself will no longer be made to the same proposalRepresent different perspectives.
For exampleAt least four consistent 0 values were collected in the first and second rounds, and,in the Prom message broadcast in the third round, the 0 value and the collected transaction set for the offer by the different nodes may be includedA value of 0 indicating non-approval and a signature set, e.g., including、、。
For theSince it broadcasts the proposed set of transactions in the first round, as previously describedRepresenting an approval of the proposed set of transactions and, therefore,the Prom message can be not sent in the third round, or the opinion of the node can be changed after the second round, namely, the Bval message with different voting contents is sent, but the execution results of other nodes are not influenced.
Thus, by a third wheel, e.g.At least Quorum Prom messages may be collected. With the qurum number of Prom messages,can confirm at least Quorum consensus nodesEach of which has collected a set of transactions for the offerIndicating at least a number of votes that are not approved, and each consensus node issuing a Prom message promises that the view of the vote will no longer be altered, and thus,this consensus may be further completed by not aggregating the transactionsAs part of the consensus result. As forEven if it aggregates transactionsThe output as part of the consensus result does not affect the availability of the blockchain system as a whole, since、Andthe opinion of the constituent Quorum number of nodes is consistent.
The third round of the Prom message may add a signature. For exampleProm messages broadcast in the third round may includeFor in Prom message<r, 0, <Signature collection>>The signature of (2).
The embodiment of FIG. 10 can be implemented as shown in the figureCan also be extended to the field of electronic devices、、Andthe execution is performed, that is, any one of fig. 6, 7, and 8 may be used in addition to fig. 5. By、、Andare all executed, FIG. 5 isThe point of view of this one node's initiative consensus proposal, in effect、Andany of which may also initiate the offer while others shareThe node identification coordinates the completion of the similar process described above, thus generally being a superposition of fig. 5, fig. 6, fig. 7, fig. 8.
Furthermore, by、、Andthe case of fig. 5 is performed, and it is possible that the flow shown in fig. 4 is viewed from the perspective of a node that partially initiates the consensus proposal, and the flow shown in fig. 10 is viewed from the perspective of another node that partially initiates the consensus proposal.
The present application further provides an embodiment of a block chain system, which includes a consensus node, where:
the first consensus node broadcasts a first message, wherein the first message comprises a transaction set of the consensus proposal and a signature of the first consensus node;
the consensus node receiving the first message broadcasts a second message, wherein the second message comprises votes and signatures of the transaction set; the vote includes a summary value for the set of transactions;
after collecting at least Quorum consistent votes from different consensus nodes by the consensus node receiving the second message, if the consensus node does not broadcast different votes for the proposal, a third message is broadcasted, wherein the third message comprises the digest value and the collected signature set;
and after the consensus node collects at least Quorum third messages from different nodes, outputting a transaction set corresponding to the abstract value as at least one part of the consensus result.
In the same consensus process, each of at least a Quorum number of consensus nodes in the blockchain system performs the aforementioned method as a first consensus node.
The present application further provides an embodiment of a block chain system, which includes a consensus node, where:
the first consensus node broadcasts a first message, wherein the first message comprises a transaction set of the consensus proposal and a signature of the first consensus node;
the consensus node receiving the first message broadcasts a second message, wherein the second message comprises votes and signatures of the transaction set; the vote includes a value representing non-approval of the transaction set;
after collecting at least Quorum consistent votes from different consensus nodes by the consensus node receiving the second message, if the consensus node does not broadcast a different vote for the proposal, a third message is broadcast, wherein the third message comprises the value representing that the transaction set is not approved and the collected signature set;
after the consensus node collects at least four third messages from different nodes, the transaction set is not output as part of the consensus result.
In the same consensus process, each of at least a Quorum number of consensus nodes in the blockchain system performs the aforementioned method as a first consensus node.
The present application further provides an embodiment of a consensus node in a blockchain system, which can be shown in fig. 11, and includes:
a first message receiving unit 111, configured to receive a first message broadcast by a first consensus node, where the first message includes a transaction set of a consensus offer and a signature of the first consensus node;
a second message broadcasting unit 112, configured to broadcast a second message after the first message receiving unit receives the first message, where the second message includes votes and signatures for the transaction set; the vote includes a summary value for the set of transactions;
a vote collection unit 113 for collecting votes from the consensus nodes;
a third message broadcasting unit 114, when the vote collecting unit collects at least four consistent votes from different consensus nodes, if it does not broadcast different votes for the proposal, it broadcasts a third message, the third message includes the digest value and the collected signature set;
a third message collection unit 115 that collects a third message from the consensus node;
and the output unit 116, when the third message collection unit collects at least four third messages from different nodes, outputs the transaction set corresponding to the digest value as at least a part of the consensus result.
The present application further provides an embodiment of a consensus node in a blockchain system, which can also be as shown in fig. 11, including:
a first message receiving unit 111, configured to receive a first message broadcast by a first consensus node, where the first message includes a transaction set of a consensus offer and a signature of the first consensus node;
a second message broadcasting unit 112, configured to broadcast a second message after the first message receiving unit receives the first message, where the second message includes votes and signatures for the transaction set; the vote includes a value representing non-approval of the transaction set;
a vote collection unit 113 for collecting votes from the consensus nodes;
a third message broadcasting unit 114, for broadcasting a third message if it has not broadcast a different vote for the proposal after the vote collecting unit collects at least four consistent votes from different consensus nodes, the third message including the value indicating that the transaction set is not approved and the collected signature set;
a third message collection unit 115 that collects a third message from the consensus node;
and the output unit 116, when the third message collection unit collects at least four third messages from different nodes, does not output the transaction set corresponding to the digest value as at least a part of the consensus result.
In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Hardware Description Language), traffic, pl (core universal Programming Language), HDCal (jhdware Description Language), lang, Lola, HDL, laspam, hardward Description Language (vhr Description Language), vhal (Hardware Description Language), and vhigh-Language, which are currently used in most common. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.
The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a server system. Of course, this application does not exclude that with future developments in computer technology, the computer implementing the functionality of the above described embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device or a combination of any of these devices.
Although one or more embodiments of the present description provide method operational steps as described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive approaches. The order of steps recited in the embodiments is merely one manner of performing the steps in a multitude of orders and does not represent the only order of execution. When an actual apparatus or end product executes, it may execute sequentially or in parallel (e.g., parallel processors or multi-threaded environments, or even distributed data processing environments) according to the method shown in the embodiment or the figures. The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in a process, method, article, or apparatus that comprises the recited elements is not excluded. For example, if the terms first, second, etc. are used to denote names, they do not denote any particular order.
For convenience of description, the above devices are described as being divided into various modules by functions, and are described separately. Of course, when implementing one or more of the present description, the functions of each module may be implemented in one or more software and/or hardware, or a module implementing the same function may be implemented by a combination of multiple sub-modules or sub-units, etc. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.
The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
As will be appreciated by one skilled in the art, one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of the present description may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
One or more embodiments of the present description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. One or more embodiments of the specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment. In the description of the specification, reference to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the specification. In this specification, the schematic representations of the terms used above are not necessarily intended to refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, various embodiments or examples and features of different embodiments or examples described in this specification can be combined and combined by one skilled in the art without contradiction.
The above description is merely exemplary of one or more embodiments of the present disclosure and is not intended to limit the scope of one or more embodiments of the present disclosure. Various modifications and alterations to one or more embodiments described herein will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement or the like made within the spirit and principle of the present specification should be included in the scope of the claims.
Claims (18)
1. A consensus method in a blockchain system, comprising:
a first round: the first consensus node broadcasts a first message, wherein the first message comprises a transaction set of the consensus proposal and a signature of the first consensus node;
and a second round: the consensus node receiving the first message broadcasts a second message, wherein the second message comprises votes and signatures of the transaction set; the vote includes a summary value for the set of transactions;
and a third round: after collecting at least Quorum consistent votes from different consensus nodes by the consensus node receiving the second message, if the consensus node does not broadcast different votes for the proposal, a third message is broadcasted, wherein the third message comprises the digest value and the collected signature set;
after the consensus node collects at least four third messages from different nodes, the transaction set corresponding to the abstract value is output as at least one part of the consensus result; in the same consensus process, each of at least a Quorum number of consensus nodes in the blockchain system serves as a first consensus node.
2. The method of claim 1, wherein the signature in the first round comprises a signature of the first consensus node on data comprising the set of transactions with its own private key or a signature of data comprising a digest value of the set of transactions.
3. The method of claim 1, at the end of the first round, the consensus node receiving the first message further verifies the correctness of the received first message; and entering a second round after the verification is passed.
4. The method of claim 1, the signing in the second round comprising signing, by a consensus node broadcasting the second message, data comprising digest values of the set of transactions with its own private key.
5. The method of claim 2 or 4, the data further comprising a round.
6. The method of claim 1, at the end of the third round, the consensus node that received the third message further verifies the correctness of the third message.
7. The method of claim 6, the verifying the correctness of the third message comprising verifying the correctness of the signature of the third message and verifying that at least Quorum signatures are included in the signature set of the third message.
8. The method of claim 1, wherein the consensus node broadcasting the third message no longer alters the voting perspectives for the same proposed set of transactions.
9. The method of claim 1, wherein the signature set is replaced with an aggregate signature or a threshold signature.
10. A consensus method in a blockchain system, comprising:
a first round: the first consensus node broadcasts a first message, wherein the first message comprises a transaction set of the consensus proposal and a signature of the first consensus node;
and a second round: the consensus node receiving the first message broadcasts a second message, wherein the second message comprises votes and signatures of the transaction set; the vote includes a value representing non-approval of the transaction set;
and a third round: after collecting at least Quorum consistent votes from different consensus nodes by the consensus node receiving the second message, if the consensus node does not broadcast a different vote for the proposal, a third message is broadcast, wherein the third message comprises the value representing that the transaction set is not approved and the collected signature set;
after the consensus node collects at least Quorum third messages from different nodes, the transaction set is not output as a part of the consensus result; in the same consensus process, each of at least a Quorum number of consensus nodes in the blockchain system serves as a first consensus node.
11. The method of claim 10, the signing in the second round comprising a consensus node broadcasting the second message signing data including a value representing non-approval of the set of transactions with its own private key.
12. The method of claim 10, verifying the correctness of the third message comprises verifying the correctness of the signature of the third message and verifying that at least qurum signatures are included in the signature set of the third message.
13. The method of claim 10, the consensus node broadcasting the third message no longer alters the voting perspectives for the same proposed set of transactions.
14. The method of any of claims 10-13, the signature set is replaced with an aggregate signature or a threshold signature.
15. A blockchain system comprising a consensus node, wherein:
the first consensus node broadcasts a first message, wherein the first message comprises a transaction set of the consensus proposal and a signature of the first consensus node;
the consensus node receiving the first message broadcasts a second message, wherein the second message comprises votes and signatures of the transaction set; the vote includes a summary value for the set of transactions;
after collecting at least Quorum consistent votes from different consensus nodes by the consensus node receiving the second message, if the consensus node does not broadcast different votes for the proposal, a third message is broadcasted, wherein the third message comprises the digest value and the collected signature set;
after the consensus node collects at least four third messages from different nodes, the transaction set corresponding to the abstract value is output as at least one part of the consensus result; in the same consensus process, each of at least a Quorum number of consensus nodes in the blockchain system serves as a first consensus node.
16. A blockchain system comprising a consensus node, wherein:
the first consensus node broadcasts a first message, wherein the first message comprises a transaction set of the consensus proposal and a signature of the first consensus node;
the consensus node receiving the first message broadcasts a second message, wherein the second message comprises votes and signatures of the transaction set; the vote includes a value representing non-approval of the transaction set;
after collecting at least Quorum consistent votes from different consensus nodes by the consensus node receiving the second message, if the consensus node does not broadcast a different vote for the proposal, a third message is broadcast, wherein the third message comprises the value representing that the transaction set is not approved and the collected signature set;
after the consensus node collects at least Quorum third messages from different nodes, the transaction set is not output as a part of the consensus result; in the same consensus process, each of at least a Quorum number of consensus nodes in the blockchain system serves as a first consensus node.
17. A consensus node in a blockchain system, comprising:
a first message receiving unit, configured to receive a first message broadcast by a first consensus node, where the first message includes a transaction set of a consensus offer and a signature of the first consensus node;
a second message broadcasting unit, configured to broadcast a second message after the first message receiving unit receives the first message, where the second message includes votes and signatures for the transaction set; the vote includes a summary value for the set of transactions;
the vote collecting unit is used for collecting votes from the consensus nodes;
a third message broadcasting unit, when the vote collecting unit collects at least Quorum consistent votes from different consensus nodes, if the third message does not broadcast different votes for the proposal, the third message is broadcasted, and the third message comprises the digest value and the collected signature set;
a third message collection unit which collects a third message from the consensus node;
the output unit is used for outputting the transaction set corresponding to the abstract value as at least one part of the consensus result after the third message collection unit collects at least four third messages from different nodes; in the same consensus process, each of at least a Quorum number of consensus nodes in the blockchain system serves as a first consensus node.
18. A consensus node in a blockchain system, comprising:
a first message receiving unit, configured to receive a first message broadcast by a first consensus node, where the first message includes a transaction set of a consensus offer and a signature of the first consensus node;
a second message broadcasting unit, configured to broadcast a second message after the first message receiving unit receives the first message, where the second message includes votes and signatures for the transaction set; the vote includes a value representing non-approval of the transaction set;
the vote collecting unit is used for collecting votes from the consensus nodes;
a third message broadcasting unit, after the vote collecting unit collects at least four consistent votes from different consensus nodes, if the third message does not broadcast different votes for the proposal, the third message is broadcasted, and the third message comprises the value representing that the transaction set is not approved and the collected signature set;
a third message collection unit which collects a third message from the consensus node;
the output unit does not output the transaction set as at least one part of the consensus result after the third message collection unit collects at least four third messages from different nodes; in the same consensus process, each of at least a Quorum number of consensus nodes in the blockchain system serves as a first consensus node.
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111175184.1A CN113630257B (en) | 2021-10-09 | 2021-10-09 | Consensus method, block chain system and consensus node |
CN202210158410.3A CN114553434B (en) | 2021-10-09 | 2021-10-09 | Consensus method, block chain system and consensus node |
PCT/CN2022/123979 WO2023056958A1 (en) | 2021-10-09 | 2022-10-09 | Consensus method, blockchain system, and consensus node |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111175184.1A CN113630257B (en) | 2021-10-09 | 2021-10-09 | Consensus method, block chain system and consensus node |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210158410.3A Division CN114553434B (en) | 2021-10-09 | 2021-10-09 | Consensus method, block chain system and consensus node |
Publications (2)
Publication Number | Publication Date |
---|---|
CN113630257A CN113630257A (en) | 2021-11-09 |
CN113630257B true CN113630257B (en) | 2022-01-04 |
Family
ID=78390703
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202111175184.1A Active CN113630257B (en) | 2021-10-09 | 2021-10-09 | Consensus method, block chain system and consensus node |
CN202210158410.3A Active CN114553434B (en) | 2021-10-09 | 2021-10-09 | Consensus method, block chain system and consensus node |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210158410.3A Active CN114553434B (en) | 2021-10-09 | 2021-10-09 | Consensus method, block chain system and consensus node |
Country Status (2)
Country | Link |
---|---|
CN (2) | CN113630257B (en) |
WO (1) | WO2023056958A1 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114553434A (en) * | 2021-10-09 | 2022-05-27 | 支付宝(杭州)信息技术有限公司 | Consensus method, block chain system and consensus node |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114782047B (en) * | 2021-12-29 | 2023-06-30 | 张海滨 | Data consensus method and distributed system |
CN114401271A (en) * | 2022-01-13 | 2022-04-26 | 中国人民解放军国防科技大学 | Test data tamper-proof method, block chain system and medium |
CN115174572B (en) * | 2022-06-30 | 2024-01-05 | 蚂蚁区块链科技(上海)有限公司 | Data multicasting method in blockchain, blockchain node and storage medium |
CN117527266A (en) * | 2024-01-05 | 2024-02-06 | 杭州趣链科技有限公司 | Asynchronous network consensus method, device, electronic equipment and readable storage medium |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111526219A (en) * | 2020-07-03 | 2020-08-11 | 支付宝(杭州)信息技术有限公司 | Alliance chain consensus method and alliance chain system |
Family Cites Families (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108182635A (en) * | 2017-12-18 | 2018-06-19 | 深圳前海微众银行股份有限公司 | Block chain common recognition method, system and computer readable storage medium |
WO2019213867A1 (en) * | 2018-05-09 | 2019-11-14 | 合肥达朴汇联科技有限公司 | Method and device for reaching consensus in blockchain |
US20210256016A1 (en) * | 2018-06-25 | 2021-08-19 | Commonwealth Scientific And Industrial Research Organisation | Blockchain system and method |
CN109379397B (en) * | 2018-08-31 | 2019-12-06 | 阿里巴巴集团控股有限公司 | Transaction consensus processing method and device based on block chain and electronic equipment |
RU2724181C1 (en) * | 2018-11-07 | 2020-06-22 | Алибаба Груп Холдинг Лимитед | Simplification of consensus in blockchain based on principle of practical fail-safety based on byzantine agreement and synchronization of nodes |
CN110113388B (en) * | 2019-04-17 | 2020-01-14 | 四川大学 | Improved clustering algorithm-based block chain system consensus method and device |
US11343073B2 (en) * | 2019-06-18 | 2022-05-24 | Electronics And Telecommunications Research Institute | Apparatus and method for achieving distributed consensus based on decentralized byzantine fault tolerance |
CN112689848A (en) * | 2019-06-28 | 2021-04-20 | 深圳市网心科技有限公司 | Consensus method of block chain data and related equipment |
CN110247774A (en) * | 2019-06-28 | 2019-09-17 | 深圳市网心科技有限公司 | A kind of the common recognition method and relevant device of block chain data |
CN110300172B (en) * | 2019-06-28 | 2022-06-07 | 深圳市迅雷网络技术有限公司 | Block chain data consensus method and related equipment |
CN110570311B (en) * | 2019-09-17 | 2021-05-25 | 北京海益同展信息科技有限公司 | Block chain consensus method, device and equipment |
CN111416708B (en) * | 2020-03-16 | 2023-01-31 | 麦希科技(北京)有限公司 | Block chain Byzantine fault-tolerant consensus method and system |
CN111049696B (en) * | 2020-03-16 | 2020-06-12 | 支付宝(杭州)信息技术有限公司 | Method, node and computing device for node management of blockchain system |
CN111522800B (en) * | 2020-07-03 | 2020-10-30 | 支付宝(杭州)信息技术有限公司 | Block chain consensus method, node and system of badger Byzantine fault-tolerant consensus mechanism |
CN111523899B (en) * | 2020-07-03 | 2021-09-07 | 支付宝(杭州)信息技术有限公司 | Consensus method of alliance chain, data verification method, device and system |
CN112532396A (en) * | 2020-12-04 | 2021-03-19 | 广东工业大学 | Optimized Byzantine fault-tolerant method based on aggregated signature and storage medium |
CN112506671B (en) * | 2021-02-03 | 2021-05-07 | 支付宝(杭州)信息技术有限公司 | Transaction processing method and device in block chain and electronic equipment |
CN113630257B (en) * | 2021-10-09 | 2022-01-04 | 支付宝(杭州)信息技术有限公司 | Consensus method, block chain system and consensus node |
-
2021
- 2021-10-09 CN CN202111175184.1A patent/CN113630257B/en active Active
- 2021-10-09 CN CN202210158410.3A patent/CN114553434B/en active Active
-
2022
- 2022-10-09 WO PCT/CN2022/123979 patent/WO2023056958A1/en unknown
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111526219A (en) * | 2020-07-03 | 2020-08-11 | 支付宝(杭州)信息技术有限公司 | Alliance chain consensus method and alliance chain system |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114553434A (en) * | 2021-10-09 | 2022-05-27 | 支付宝(杭州)信息技术有限公司 | Consensus method, block chain system and consensus node |
CN114553434B (en) * | 2021-10-09 | 2024-03-12 | 支付宝(杭州)信息技术有限公司 | Consensus method, block chain system and consensus node |
Also Published As
Publication number | Publication date |
---|---|
CN114553434B (en) | 2024-03-12 |
CN113630257A (en) | 2021-11-09 |
WO2023056958A1 (en) | 2023-04-13 |
CN114553434A (en) | 2022-05-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN113630257B (en) | Consensus method, block chain system and consensus node | |
CN113645044B (en) | Consensus method, block chain system and consensus node | |
CN113630258B (en) | Consensus method, block chain system and consensus node | |
CN113610531B (en) | Consensus method, block chain system and consensus node | |
CN109949157B (en) | Business data uplink method, device and system | |
CN110730204B (en) | Method for deleting nodes in block chain network and block chain system | |
CN113761071B (en) | Consensus method, block chain system and consensus node | |
CN113609515B (en) | Consensus method and block chain system | |
Yanovich et al. | Exonum: Byzantine fault tolerant protocol for blockchains | |
CN113630259B (en) | Consensus method, block chain system and consensus node | |
CN111147261B (en) | Method and system for using HotStuff consensus algorithm in block chain | |
WO2023185045A1 (en) | Method and system for generating random seed on blockchain, and consensus node | |
CN114884652A (en) | Method, system and consensus node for generating random number seed on block chain | |
CN115037472B (en) | Transaction processing method and system based on double-layer DAG consensus mechanism and service equipment | |
CN115174090A (en) | Block chain consensus method and device | |
Yin | Scaling the Infrastructure of Practical Blockchain Systems | |
CN116846912A (en) | View switching method, consensus node and block chain system in PBFT algorithm | |
CN116846907A (en) | Consensus method and block chain link point | |
CN116484417A (en) | Transaction proposal method in blockchain system, consensus node and blockchain system | |
CN116527694A (en) | Consensus method in block chain system, consensus node and block chain system | |
CN116823463A (en) | Transaction proposal method in blockchain system, consensus node and blockchain system | |
CN116846916B (en) | Data synchronization method, device, electronic equipment and computer readable storage medium | |
CN116846906A (en) | Consensus method and block chain link point | |
CN116823466A (en) | Transaction proposal method in blockchain system, consensus node and blockchain system | |
CN116823465A (en) | Transaction proposal method in blockchain system, consensus node and blockchain system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant | ||
REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 40062621 Country of ref document: HK |