CN113630259B - Consensus method, block chain system and consensus node - Google Patents
Consensus method, block chain system and consensus node Download PDFInfo
- Publication number
- CN113630259B CN113630259B CN202111178795.1A CN202111178795A CN113630259B CN 113630259 B CN113630259 B CN 113630259B CN 202111178795 A CN202111178795 A CN 202111178795A CN 113630259 B CN113630259 B CN 113630259B
- Authority
- CN
- China
- Prior art keywords
- message
- consensus
- node
- nodes
- round
- 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
- 238000000034 method Methods 0.000 title claims abstract description 67
- 230000008569 process Effects 0.000 claims description 31
- 238000012795 verification Methods 0.000 claims description 11
- 238000011084 recovery Methods 0.000 claims description 6
- 238000004422 calculation algorithm Methods 0.000 description 25
- 238000010586 diagram Methods 0.000 description 21
- 230000008859 change Effects 0.000 description 11
- 230000006870 function Effects 0.000 description 11
- 238000003860 storage Methods 0.000 description 10
- 230000006872 improvement Effects 0.000 description 9
- 230000003993 interaction Effects 0.000 description 8
- 238000004590 computer program Methods 0.000 description 7
- 238000005516 engineering process Methods 0.000 description 6
- 238000012545 processing Methods 0.000 description 6
- 238000004364 calculation method Methods 0.000 description 5
- 238000004891 communication Methods 0.000 description 4
- 230000007246 mechanism Effects 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 3
- 230000008878 coupling Effects 0.000 description 3
- 238000010168 coupling process Methods 0.000 description 3
- 238000005859 coupling reaction Methods 0.000 description 3
- 238000013461 design Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 230000000977 initiatory effect Effects 0.000 description 3
- 241000282346 Meles meles Species 0.000 description 2
- 241000282344 Mellivora capensis Species 0.000 description 2
- 230000003111 delayed effect Effects 0.000 description 2
- 230000018109 developmental process Effects 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- QERYCTSHXKAMIS-UHFFFAOYSA-M thiophene-2-carboxylate Chemical compound [O-]C(=O)C1=CC=CS1 QERYCTSHXKAMIS-UHFFFAOYSA-M 0.000 description 2
- OKTJSMMVPCPJKN-UHFFFAOYSA-N Carbon Chemical compound [C] OKTJSMMVPCPJKN-UHFFFAOYSA-N 0.000 description 1
- 229930182628 Forbeside Natural products 0.000 description 1
- 241000764238 Isis Species 0.000 description 1
- 108010001267 Protein Subunits Proteins 0.000 description 1
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 239000007795 chemical reaction product Substances 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 229910021389 graphene Inorganic materials 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000005055 memory storage Effects 0.000 description 1
- 229920001296 polysiloxane Polymers 0.000 description 1
- 239000000047 product Substances 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 239000010979 ruby Substances 0.000 description 1
- 229910001750 ruby Inorganic materials 0.000 description 1
- 239000002904 solvent Substances 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
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/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
-
- 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/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Computer And Data Communications (AREA)
Abstract
A consensus method, a block chain system and a consensus node, the consensus method comprising: the first consensus node generates a plurality of data blocks by using erasure codes for the transaction set suggested by the consensus; the first common node sends a first message to other common nodes; the consensus node which receives the first message broadcasts a second message, wherein the second message comprises the received data block and comprises the vote and the signature of the transaction set; the vote includes a summary value of the transaction set; after the consensus node receiving the second message collects at least equal votes from different consensus nodes, broadcasting a third message, wherein the third message comprises a digest value and a collected signature set; and recovering the transaction set by the consensus node based on the received data blocks at the end of the second round or the third round by adopting an erasure code, and outputting the transaction set corresponding to the digest value as at least one part of the consensus result after collecting at least four third messages from different nodes.
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. Because the blockchain has the characteristics of decentralization, information non-tampering, autonomy and the like, the blockchain is also paid more and more attention and is applied by people.
Disclosure of Invention
The invention aims to provide a consensus method, a block chain system and a consensus node, comprising the following steps:
a consensus method in a blockchain system, comprising:
a first round: the first consensus node generates a plurality of data blocks by using erasure codes for the transaction set suggested by the consensus; the first common node reserves a data block and sends a first message to other common nodes, and the first message sent to different common nodes comprises different data blocks and signatures of the first common node;
and a second round: the consensus node receiving the first message broadcasts a second message, wherein the second message comprises the received data block and comprises the vote and the signature of the transaction set; the vote includes a summary value for the set of transactions;
and a third round: after the consensus node receiving the second message collects at least equal votes from different consensus nodes, broadcasting a third message, wherein the third message comprises the digest value and the collected signature set;
and the consensus node recovers the transaction set by adopting the erasure code based on the received data blocks at the end of the second round or the third round, and outputs the transaction set corresponding to the digest value as at least one part of a consensus result after collecting at least Quorum third messages from different nodes.
A blockchain system comprising a consensus node, wherein:
the first consensus node generates a plurality of data blocks by using erasure codes for the transaction set suggested by the consensus; the first common node reserves a data block and sends a first message to other common nodes, and the first message sent to different common nodes comprises different data blocks and signatures of the first common node;
the consensus node receiving the first message broadcasts a second message, wherein the second message comprises the received data block and comprises the vote and the signature of the transaction set; the vote includes a summary value for the set of transactions;
after the consensus node receiving the second message collects at least equal votes from different consensus nodes, broadcasting a third message, wherein the third message comprises the digest value and the collected signature set;
and the consensus node recovers the transaction set by adopting the erasure code based on the received data blocks at the end of the second round or the third round, and outputs the transaction set corresponding to the digest value as at least one part of a consensus result after collecting at least Quorum third messages from different nodes.
A consensus node in a blockchain system, comprising:
the data block generating unit is used for generating a plurality of data blocks by adopting erasure codes for the transaction set of the consensus proposal and reserving one data block;
the first message broadcasting unit is used for broadcasting a first message to other common nodes, and the first message sent to different common nodes comprises different data blocks and signatures of the first common nodes;
a second message receiving unit, configured to receive a second message, where the second message includes a data block and includes a vote and a signature for the transaction set; the vote includes a summary value for the set of transactions;
a third message broadcasting unit, which broadcasts a third message after the second message receiving unit collects at least equal votes from different consensus nodes, wherein the third message comprises the digest value and the collected signature set;
the third message collecting unit is used for collecting third messages from different consensus nodes;
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 collecting unit collects at least four third messages from different nodes.
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 data block of a proposed transaction set 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 the data block, the vote for the transaction set, and a signature; the vote includes a summary value for the set of transactions;
a second message receiving unit, configured to receive a second message, where the second message includes a data block and includes a vote and a signature for the transaction set; the vote includes a summary value for the set of transactions;
a third message broadcasting unit, for broadcasting a third message when the second message receiving unit collects at least equal votes from different consensus nodes, wherein the third message comprises the digest value and the collected signature set;
a third message collection unit for collecting third messages from different consensus nodes;
the recovery unit is used for recovering the transaction set by adopting the erasure codes based on the data blocks received by the second message receiving unit or the third message collecting unit;
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.
In the above embodiment, on the basis of completing one consensus in 3 rounds on a certain premise, the erasure code is adopted to generate a plurality of data blocks for the transaction proposed by the consensus, and the proposed consensus node does not need to transmit a larger data packet to each of the other consensus nodes, but transmits different data blocks of the data packet to different consensus nodes, so that the data amount transmitted by the network can be reduced. And forwarding the data blocks sent by the proposed consensus node in the second round can fully utilize bandwidth resources among nodes in the network, thereby improving the performance of the consensus protocol as a whole.
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 an architecture diagram of a consensus node in an embodiment of the present specification;
FIG. 11 is an architecture diagram of a consensus node in an embodiment of the present specification;
FIG. 12 is a schematic diagram of erasure codes in one embodiment of this specification;
FIG. 13 is a schematic diagram of a Merkle Tree according to one embodiment of the present disclosure;
FIG. 14 is a schematic diagram of a Merkle Tree according to 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"). 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 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: a first consensus node generates a plurality of data blocks from a set of transactions proposed by consensus using erasure codes; the first common node reserves a data block and sends a first message to other common nodes, and the first message sent to different common nodes comprises different data blocks and signatures of the first common 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 a node perspective, for exampleSuch as by
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 transactions of consensus offers can be aggregated
A plurality of data blocks are generated using Erasure Coding (Erasure Coding). In general, the number n of data blocks generated using erasure codes may be equal to the total number of consensus nodes. For example in a blockchain system comprising 4 common nodes,
will be provided with
Generating 4 data blocks (data blocks) using erasure codes, respectively
、
、
、
. For these 4 generated data blocks, there may be a corresponding hash value, for example
A corresponding hash value of
、
A corresponding hash value of
、
A corresponding hash value of
、
A corresponding hash value of
As shown in fig. 12. Erasure codes are a coding fault-tolerant technique that was used for data recovery in data transmission in the communications industry at the earliest. And adding check data into the original data to correlate each split data. Recovery can be achieved through erasure coding techniques in the event of a range of data errors. The data m may be generated into N data blocks by the EC. In a common design, the N data blocks generally include p data blocks obtained by splitting data m, and q data blocks used for storing erasure codes are added. Thus, the original data can be restored through any p parts of data in p + q partsAnd (5) data m.
Further, for each block of data,
the corresponding merkle proof can be generated. For example, for
The generated Mercker proof includes
、
、
(ii) a For the
The generated Mercker proof includes
、
、
(ii) a For the
The generated Mercker proof includes
、
、
. It can be seen that the merke proof is an ordered set of hash values, and the hash value of the root node of the merke tree can be calculated through the ordered set.
The first common node sends the first message to other common nodes, and the first message sent to different common nodes may include different data blocks and corresponding merkel certificates. First common node
May send a first message Val message to
The Val message may include a data block
And includes the corresponding merkel proof of the data block
、
、
。
May send a first message Val message to
The Val message may include a data block
And includes the corresponding merkel proof of the data block
、
、
。
May send a first message Val message to
The Val message may include a data block
And includes the corresponding merkel proof of the data block
、
、
. As shown in fig. 5. The first common node may reserve a data block, for example, the data block mentioned above
。
In addition to this, the present invention is,
is sent to
May also include in the Val message
A signature, e.g. as
. In general terms, the amount of the solvent to be used,
the payload portion of a message may be signed with its own private key, where for example the signature comprises
And its corresponding Mercker's proof signature, get
. In addition to this, the present invention is,
or the hash calculation may be performed on the payload (payload) portion of the message to obtain a hash value (i.e., a digest value), and then the hash value is signed by using its own private key to obtain the signature
。
The Val messages sent to other nodes are similar and will not be described in detail.
The format of the Val message may be as< r, 
, 
The corresponding merkel proof is that,
>where r may represent the r-th consensus. For example, this pair
If the consensus proposal is the r-th consensus, the transaction set of the next consensus proposal is
May correspond to the r +1 st consensus. The above-mentioned
It is also possible to use the private key pair itself comprising r and
and its corresponding signature of the data including the mercker certificate. Similarly, the first pair can also be
And carrying out hash calculation on the corresponding Mercker certification to obtain a hash value, and then signing the data including the hash value and r by using a private key of the Mercker certification to obtain
。
S43: (second round) the consensus node receiving the first message broadcasts a second message comprising the received data block and comprising a transaction set(ii) a combined vote and signature; the vote includes the set of transactions
The 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 adopt
In the first message
The signature of (2) is verified. In addition, the first message may further include a merkel proof corresponding to the received data block. In this way, at the end of the first round, the consensus node that received the first message can also verify the data blocks and the corresponding merkel proof in the received first message. Specifically, at the end of the first round, the consensus node that receives the Val message may calculate a hash value of the data block of the consensus proposal in the Val message. For example,
receiving a first common node
After the transmitted Val message, the data block included in the Val message may be calculated
A hash value of, e.g.
. The received Val message, as mentioned above, further includes a merkle proof corresponding to the included data block. For example,
receiving a first common node
The transmitted Val message also comprises a data block
Corresponding merkel proof
、
、
. The consensus node receiving the Val message can verify the correctness of the data through the mercker proof contained in the Val message. For example,
in the Val message obtained by the calculation
Hash value of
Then, further calculation is carried out together with the Mercker proof in the Val message, including
And
is calculated to obtain
Then is further prepared by
And
is calculated to obtain
Thereby by comparison
And
whether to agree to determine
Whether it is correct. This is because, generally, the probability of hash collision is very low, and it is difficult for the originator of the message to forge a series of hash values while keeping the correspondence between the hash values and the data blocks. Thus, if compared
And
if the two are consistent, the subsequent treatment can be carried out; if not, the received Val message is not acknowledged, i.e., the data block contained therein is not acknowledged.
If the verification is passed, S43 is entered. S43, specifically as in fig. 5, 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. As in the example shown in fig. 5, since
、
、
Each respectively only receives
A portion of the data blocks in the set of consensus-proposed transactions may not restore the complete set of consensus-proposed transactions. Therefore, the second message broadcasted by the consensus node may include the data block in the received first message. This second message of the broadcast may be denoted as Bval.
In addition to this, the present invention is,
、
、
other consensus nodes may be told their own pair by broadcasting a second message
A vote of the initiated consensus proposal, the vote being indicative of approval or disapproval of the consensus proposal. If the consensus node approves the consensus
A proposed transaction set whose hash value may be broadcast in a 2 nd round of messaging, as described above
. Conversely, if the consensus node does not recognize the consensus
The proposed transaction set, may broadcast 0 in the 2 nd round of message interaction.
In the course of this round, the number of turns,
may not participate in the broadcast because
The consensus proposal is initiated in the first round, which itself may represent
Is 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.
The second message broadcast by the consensus node may further include a merkel proof corresponding to the received data block. For example, in a case where the first common node generates a corresponding mercker certificate for each data block in the first round and transmits the mercker certificate together with the data block in the first message, at the end of the first round, the common node that received the first message may receive the data block and the mercker certificate corresponding to the data block. In this way, in the second round, the second message broadcast by the consensus node may include, in addition to the data block received in the first round, the tacle proof corresponding to the data block. At the end of the second round, the consensus node that received the second message may also verify the data blocks and the corresponding merkel proof in the second message.
In addition, the second message may also includeTo include a signature for the transaction set. 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. by
Authentication
And verifies the received data block and the corresponding merkel proof. If the verification is correct, the consensus node receiving the first message can sign the data block in the first message received by the consensus node by using a private key of the consensus node. For example
For transaction set in first message
Data block of
Signing to obtain
(ii) a Or can be
By its own private key pair
Hash value of
Is signed, thereby obtaining
。
Similarly, the format of the Bval message may be as follows< r, 
, 
The corresponding merkel proof is that,
, 
>where r may represent the r-th consensus,
is composed of
Hash value of (1), representing a pair
The voting viewpoint of (a) is acceptance. Then the
Or may use its own private key pair including r,
, 
Corresponding merkel proof and
signature of the data within. Similarly, r, and r may be used in advance,
, 
Corresponding merkel proof and
carrying out hash calculation on the data to obtain a hash value, and then signing the hash value by using a private key of the hash value to obtain
。
S45: a third round, after the consensus node receiving the second message collects at least qurum number of consistent digest values from different consensus nodes, broadcasts a third message, which includes the digest values and the collected signatures.
The consensus node in the second round broadcasts a second message Bval message so that at the end of the second round, the consensus node receiving the second message can collect the data blocks in the second message and the vote for the consensus proposal.
For example
The votes in the Bval message may be collected at the end of the second round. Suppose that
Is collected to
，
、
The votes in the separately broadcast Bval messages are all the transaction sets
Hash value of, i.e.
And is and
also included in the Val message broadcast in the first round
Then, then
At least qurum consistent digest values were collected in this round (e.g., when f =1, qurum =3, actually 4).
For example
At the end of the second round, the votes in the Bval message can be collected, assuming
Is collected to
、
The votes in the respectively broadcasted second messages are all the transaction sets
Hash value of
And is and
votes in a second message broadcast in a second round, if also the set of transactions
Hash value of
(also representing approval of the transaction set), and received in the first round
The sent Val message also comprises the same hash value
Then, then
At least qurum consistent digest values were collected in this round (e.g., when f =1, qurum =3, actually 4).
For the
Received from the first round Val message
Set of sent transactions
A data block of
Received from the second round of Bval messages
Set of sent transactions
A data block of
Received from the second round of Bval messages
Set of sent transactions
A data block of
. According to the arrangement of p, q in the erasure code as described previously (generally q is at least 1, while in the second round
At least p different data blocks should be received),
with a greater probability can be selected from
、
、
In and out of
Thereby being capable of recovering to be complete
The proposed transaction set of (1).
Similarly, for
Received from the first round Val message
Set of sent transactions
A data block of
Received from the second round of Bval messages
Set of sent transactions
A data block of
Received from the second round of Bval messages
Set of sent transactions
A data block of
. According to the arrangement of p, q in the erasure code as described previously (generally q is at least 1, while in the second round
At least p different data blocks should be received),
with a greater probability can be selected from
、
、
In and out of
Thereby being capable of recovering to be complete
The proposed transaction set of (1).
Similarly, for
Received from the first round Val message
Set of sent transactions
A data block of
Received from the second round of Bval messages
Set of sent transactions
One ofData block
Received from the second round of Bval messages
Set of sent transactions
A data block of
. According to the arrangement of p, q in the erasure code as described previously (generally q is at least 1, while in the second round
At least p different data blocks should be received),
with a greater probability can be selected from
、
、
In and out of
Thereby being capable of recovering to be complete
The proposed transaction set of (1).
In this way, the consensus node may recover the set of transactions at the end of the second round using the erasure code based on the received data blocks.
As mentioned above, the second message broadcasted by the consensus node may includeIncluding the data blocks and their corresponding merkel certificates. In this way, at the end of the second round, the consensus node that received the second message can also verify the data blocks and the corresponding merkel proof in the second message. The original data can be restored after passing the verification, i.e. the decoding is obtained
And recovered therefrom to be intact
The proposed transaction set of (1).
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 example
Is collected respectively to
(in the second round)
Broadcast Bval message includes
Votes, signatures are also collected) &,
、
The inclusion of the same hash value in the content of the signature indicates that there are 3 votes indicating approval for the hash (which may also include the receipt of the last vote of the first round
Signature of same hash value in transmitted Val message
A total of 4 signatures are collected for the same hash value).
For the
And broadcasting a third message if at least Quorum of consistent hash values from different consensus nodes are collected. The third message may be denoted as a Prom message, meaning that the commitment is not to change the view to the proposal. As has been described in the foregoing, the present invention,
a hash value of (1) may indicate approval and 0 may indicate non-approval.
And
and similarly.
The third message of the broadcast may include the collected pairs
Such 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 example
Suppose that
Is collected in the second round
，
、
The votes in the separately broadcast Bval messages are all the transaction sets
The hash value of (1), thus collecting
、
And
are respectively coupled with
(or
Hash value of) is
、
、
Is voted for, and
the self-pair is also included in the Val message broadcast in the first round
(or
Hash value of) is
The 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 included
Representing a recognized hash value and a set of signatures, e.g.
、
、
、
。
For example, suppose
Is collected in the second round
、
The votes in the separately broadcast Bval messages are all the transaction sets
The hash value of (1), thus collecting
And
are respectively coupled with
(or
Hash value of) is
、
Is voted for, and
the Val message broadcast in the first round also includes its pair
(or
Hash value of) is
Is voted for, and
its pair is also included in the Bval message broadcast in the second round
(or
Hash value of) is
The 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 included
Representing 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.
In addition, in the third round,
data blocks reserved in the first round may also be included in the broadcasted Prom message
. Thus, for
Besides, the common nodes can collect more data blocks at the end of the third round, so that the decoding can be promoted
And further facilitates recovery to obtain complete
The proposed transaction set of (1).
S47: and recovering the transaction set by the consensus node based on the received data blocks at the end of the second round or the third round by using the erasure codes, and outputting the transaction set corresponding to the digest value as at least one part of a consensus result after collecting at least four third messages from different nodes.
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 proposal
Are all 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 round
Represents 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 itself
Represent different perspectives.
For example
At 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 included
Representing a recognized hash value and a signature set, e.g. comprising
、
、
、
。
For example
At least four consistent digest values are collected in the first round and the second round, and further,
the hash value and the collected hash value may be included in the Prom message broadcast in the third roundTransaction collections for the offer by different nodes
Representing 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 offer
Representing 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 value
And outputting as at least a portion of the consensus result.
、
And
and similarly. Similarly, other consensus nodes are e.g.
、
And
the consensus can be further completed, namely, the transaction set corresponding to the abstract value
And outputting as at least a portion of the consensus result.
Since multiple data blocks may be received at the end of the second round, the consensus node has a greater probability of recovering the transaction set at the end of the second round using the erasure code based on the received data blocks. Since the data blocks reserved by the first consensus node in the first round can be received at the end of the third round, that is, more data blocks can be collected than at the end of the second round, the consensus node has a greater probability to recover the transaction set at the end of the third round based on the received data blocks using the erasure code.
Of the third wheelThe Prom message may add a signature. For example
Prom messages broadcast in the third round may include
For in Prom message<r, hash, <Signature collection>>The signature of (2).
The aforementioned manner of generating the Merkle Tree in FIG. 13 is that, generally for a binary Merkle Tree, the number of leaf nodes at the bottom is
And (4) respectively. The number of data blocks generated by using Erasure Coding (Erasure Coding) is not necessarily the number
And (4) respectively. In this case, the hash of the last data block may be repeated several times to complete the Merkle Tree
A leaf node. For example, there are 5 consensus nodes in total
、
、
、
、
In the case of (a) in (b),
transaction aggregation to agree on offers
Generating 5 data blocks using erasure codes
、
、
、
、
And the constructed Merkle Tree can be shown in figure 14,
a corresponding hash value of
，
A corresponding hash value of
，
A corresponding hash value of
，
A corresponding hash value of
，
A corresponding hash value of
. The number of leaf nodes at the bottom is generally the smallest number greater than the number of data blocks
Where the number of data blocks is 5,
. The extra leaf nodes of the 3 Merkle Tree can take the hash value corresponding to the last data block. As shown in the figure, the first and second,
、
and
all can be taken
The hash value of. Thus, Merkle Tree and Mercker proofs can be constructed as well.
The embodiment of fig. 5 can be as shown in the figure
Can also be extended to the field of electronic devices
、
、
And
are all executed. In the former case, each of the consensus nodes having collected at least four third messages from different nodes may output the transaction sets corresponding to the digest values as all of the consensus results, and any of fig. 6, 7, 8, and 9 may be used in addition to fig. 5.
For the latter, i.e. by
、
、
And
are all executed, FIG. 5 is
The point of view of this one node's initiative consensus proposal, in effect
、
And
any of which may also initiate a proposal and the other consensus nodes cooperate to perform a similar process as described above, thus being a superposition of fig. 5, 6, 7, 8, 9 as a whole.
For the latter case, e.g.
Transaction set for initiating consensus offersAre synthesized into
，
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
In 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.
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.
Moreover, the erasure code is adopted to generate a plurality of data blocks for the transaction proposed by the consensus, and the proposed consensus node does not need to transmit a larger data packet to each of the rest consensus nodes, but transmits different data blocks of the data packet to different consensus nodes, so that the data volume transmitted by the network can be reduced. And forwarding the data blocks sent by the proposed consensus node in the second round can fully utilize bandwidth resources among nodes in the network, thereby improving the performance of the consensus protocol as a whole.
The present application further provides an embodiment of a block chain system, which includes a consensus node, where:
the first consensus node generates a plurality of data blocks by using erasure codes for the transaction set suggested by the consensus; the first common node reserves a data block and sends a first message to other common nodes, and the first message sent to different common nodes comprises different data blocks and signatures of the first common node;
the consensus node receiving the first message broadcasts a second message, wherein the second message comprises the received data block and comprises the vote and the signature of the transaction set; the vote includes a summary value for the set of transactions;
after the consensus node receiving the second message collects at least equal votes from different consensus nodes, broadcasting a third message, wherein the third message comprises the digest value and the collected signature set;
and the consensus node recovers the transaction set by adopting the erasure code based on the received data blocks at the end of the second round or the third round, and outputs the transaction set corresponding to the digest value as at least one part of a consensus result after collecting at least Quorum third messages from different nodes.
The first consensus node generates n data blocks by using an erasure code for the transaction set of the consensus suggestions, wherein n is equal to the total number of the consensus nodes.
A first common node in a first round generates a corresponding Mercker proof for each data block, and the sent first message further includes the Mercker proof;
correspondingly, the consensus node which receives the first message at the end of the first round also verifies the received data block and the merk proof; and entering a second round after the verification is passed.
Wherein, the second message also includes the corresponding merkel proof of the received data block.
At the end of the second round, the consensus node receiving the second message also verifies the data block and the corresponding merkel proof in the second message.
Wherein in the third round, the first common node further includes in the broadcasted third message the data blocks reserved in the first round.
Wherein, in the same consensus process, each of the at least equal number of consensus nodes in the block chain system is used as a first consensus node.
The present application further provides an embodiment of a common node in a blockchain system, which can also be shown in fig. 10, including:
a data block generating unit 101, configured to generate a plurality of data blocks by using an erasure code for a transaction set of consensus proposals, and reserve one data block;
a first message broadcasting unit 102, configured to broadcast a first message to other common nodes, where the first message sent to different common nodes includes different data blocks and signatures of the first common nodes;
a second message receiving unit 103, configured to receive a second message, where the second message includes a data block and includes a vote and a signature for the transaction set; the vote includes a summary value for the set of transactions;
a third message broadcasting unit 104, which broadcasts a third message after the second message receiving unit collects at least four consistent votes from different consensus nodes, wherein the third message comprises the digest value and the collected signature set;
a third message collecting unit 105, configured to collect third messages from different consensus nodes;
and the output unit 106 is used for outputting the transaction set corresponding to the digest value as at least one part of the consensus result after the third message collecting unit collects at least four third messages from different nodes.
The data block generating unit 101 generates n data blocks from the transaction set of consensus suggestions by using erasure codes, where n is equal to the total number of consensus nodes.
The data block generating unit 101 further generates a corresponding tacle proof for each data block, and the tacle proof is also included in the first message sent by the first message broadcasting unit.
The second message also includes the corresponding merkel proof of the received data block.
The device also comprises a verification unit used for verifying the data block and the corresponding Mercker certificate in the second message after the second message receiving unit receives the second message.
The third message broadcast by the third message broadcasting unit further includes the data block reserved in the data block generating unit.
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 data block of a proposed transaction set 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 111 receives the first message, where the second message includes the data block, the vote for the transaction set, and the signature; the vote includes a summary value for the set of transactions;
a second message receiving unit 113, configured to receive a second message, where the second message includes a data block and includes votes and signatures for the transaction set; the vote includes a summary value for the set of transactions;
a third message broadcasting unit 114, configured to broadcast a third message when the second message receiving unit 113 collects at least four consistent votes from different common nodes, where the third message includes the digest value and the collected signature set;
a third message collection unit 115, which collects third messages from different common nodes;
a recovery unit 116, which recovers the transaction set by using the erasure code based on the data block received by the second message receiving unit 113 or the third message collecting unit 115;
the output unit 117, when the third message collecting unit 115 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.
Wherein, the first message received by the first message receiving unit 111 further includes the tacle proof;
accordingly, the first message receiving unit 111 also verifies the received data block and the merkel proof.
The second message further includes a tacle certificate corresponding to the received data block, and the second message receiving unit 113 further verifies the data block and the corresponding tacle certificate in the second message.
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, Programmable Logic Devices (PLDs) (e.g., Field Programmable Gate Arrays (FPGAs)) are integrated circuits whose Logic functions are determined by a user programming the device.a designer, instead of manually programming an integrated circuit chip, may instead "integrate" a digital system onto a PLD using "Logic compiler" software, similar to the software compiler used in program development, but instead of manually programming an integrated circuit chip, the original code before compilation is written in a specific programming Language, known as Hardware Description Language (HDL), such as abel (advanced programming Language), but not just HDL, but any of a variety of languages, such as various types of integrated circuit chips (FPGAs), AHDL (Altera Hardware Description Language), Confluent, CUPL (Central University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALSM, RHDL (Ruby Hardware Description Language), etc., with VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog being most commonly used at present. 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 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 (20)
1. A consensus method in a blockchain system, comprising:
a first round: the first consensus node generates a plurality of data blocks by using erasure codes for the transaction set suggested by the consensus; the first common node reserves a data block and sends a first message to other common nodes, and the first message sent to different common nodes comprises different data blocks and signatures of the first common node;
and a second round: the consensus node receiving the first message broadcasts a second message, wherein the second message comprises the received data block and comprises the vote and the signature of the transaction set; the vote includes a summary value for the set of transactions;
and a third round: after the consensus node receiving the second message collects at least equal votes from different consensus nodes, broadcasting a third message, wherein the third message comprises the digest value and the collected signature set;
and the consensus node recovers the transaction set by adopting the erasure code based on the received data blocks at the end of the second round or the third round, and outputs the transaction set corresponding to the digest value as at least one part of a consensus result after collecting at least Quorum third messages from different nodes.
2. The method of claim 1, the first consensus node generating n data blocks with an erasure code for the set of transactions for the consensus proposal, the n being equal to a total number of consensus nodes.
3. The method of claim 1, wherein a first common knowledge node in a first round generates a corresponding merkel proof for each data block, and the merkel proof is further included in the sent first message;
correspondingly, the consensus node which receives the first message at the end of the first round also verifies the received data block and the merk proof; and entering a second round after the verification is passed.
4. The method of claim 3, wherein the second message further comprises a Mercker proof corresponding to the received data block.
5. The method of claim 4, at the end of the second round, the consensus node that received the second message further verifies the data blocks and the corresponding merkel proof in the second message.
6. The method of claim 1, wherein in the third round, the first common node further includes in the broadcasted third message the data blocks reserved in the first round.
7. The method of claim 1, further verifying the correctness of the third message at the end of the third round, comprising verifying that the signature set of the third message includes at least qurum signatures.
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 any of claims 1-8, the signature set is replaced with an aggregate signature or a threshold signature.
10. The method of claim 1, wherein each of the at least a Quorum number of consensus nodes in the blockchain system performs the method of claim 1 as a first consensus node in a same consensus process.
11. A blockchain system comprising a consensus node, wherein:
the first consensus node generates a plurality of data blocks by using erasure codes for the transaction set suggested by the consensus; the first common node reserves a data block and sends a first message to other common nodes, and the first message sent to different common nodes comprises different data blocks and signatures of the first common node;
the consensus node receiving the first message broadcasts a second message, wherein the second message comprises the received data block and comprises the vote and the signature of the transaction set; the vote includes a summary value for the set of transactions;
after the consensus node receiving the second message collects at least equal votes from different consensus nodes, broadcasting a third message, wherein the third message comprises the digest value and the collected signature set;
and the consensus node recovers the transaction set by adopting the erasure code based on the received data blocks at the end of the second round or the third round, and outputs the transaction set corresponding to the digest value as at least one part of a consensus result after collecting at least Quorum third messages from different nodes.
12. A consensus node in a blockchain system, comprising:
the data block generating unit is used for generating a plurality of data blocks by adopting erasure codes for the transaction set of the consensus proposal and reserving one data block;
the first message broadcasting unit is used for broadcasting a first message to other common nodes, and the first message sent to different common nodes comprises different data blocks and signatures of the first common nodes;
a second message receiving unit, configured to receive a second message, where the second message includes a data block and includes a vote and a signature for the transaction set; the vote includes a summary value for the set of transactions;
a third message broadcasting unit, which broadcasts a third message after the second message receiving unit collects at least equal votes from different consensus nodes, wherein the third message comprises the digest value and the collected signature set;
the third message collecting unit is used for collecting third messages from different consensus nodes;
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 collecting unit collects at least four third messages from different nodes.
13. The consensus node of claim 12, the data block generation unit to generate n data blocks using an erasure code for the set of transactions for the consensus proposal, the n being equal to a total number of consensus nodes.
14. The consensus node of claim 12, wherein the data block generating unit further generates a corresponding merkel proof for each data block, and wherein the merkel proof is further included in the first message sent by the first message broadcasting unit.
15. A consensus node as claimed in claim 12, further comprising a merkel proof corresponding to said received data block in a second message.
16. The consensus node of claim 15, further comprising a verification unit to verify the data blocks and the corresponding merkel certificates in the second message after the second message receiving unit receives the second message.
17. The consensus node of claim 12, wherein the third message broadcast by the third message broadcasting unit further comprises the data block reserved in the data block generating unit.
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 data block of a proposed transaction set 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 the data block, the vote for the transaction set, and a signature; the vote includes a summary value for the set of transactions;
a second message receiving unit, configured to receive a second message, where the second message includes a data block and includes a vote and a signature for the transaction set; the vote includes a summary value for the set of transactions;
a third message broadcasting unit, for broadcasting a third message when the second message receiving unit collects at least equal votes from different consensus nodes, wherein the third message comprises the digest value and the collected signature set;
a third message collection unit for collecting third messages from different consensus nodes;
the recovery unit is used for recovering the transaction set by adopting erasure codes based on the data blocks received by the second message receiving unit or the third message collecting unit;
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.
19. The consensus node of claim 18, wherein the first message received by the first message receiving unit further comprises a merkel proof;
correspondingly, the first message receiving unit also verifies the received data block and the mulck certificate.
20. The consensus node of claim 18, wherein the second message further comprises a merkel certificate corresponding to the received data block, and wherein the second message receiving unit further verifies the data block and the corresponding merkel certificate in the second message.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111178795.1A CN113630259B (en) | 2021-10-09 | 2021-10-09 | Consensus method, block chain system and consensus node |
| PCT/CN2022/124051 WO2023056966A1 (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 |
|---|---|---|---|
| CN202111178795.1A CN113630259B (en) | 2021-10-09 | 2021-10-09 | Consensus method, block chain system and consensus node |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113630259A CN113630259A (en) | 2021-11-09 |
| CN113630259B true CN113630259B (en) | 2021-12-14 |
Family
ID=78390849
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111178795.1A Active CN113630259B (en) | 2021-10-09 | 2021-10-09 | Consensus method, block chain system and consensus node |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN113630259B (en) |
| WO (1) | WO2023056966A1 (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113630259B (en) * | 2021-10-09 | 2021-12-14 | 支付宝(杭州)信息技术有限公司 | Consensus method, block chain system and consensus node |
| CN114782047B (en) * | 2021-12-29 | 2023-06-30 | 张海滨 | Data consensus method and distributed system |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111522800A (en) * | 2020-07-03 | 2020-08-11 | 支付宝(杭州)信息技术有限公司 | Block chain consensus method, node and system of badger Byzantine fault-tolerant consensus mechanism |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109345386B (en) * | 2018-08-31 | 2020-04-14 | 阿里巴巴集团控股有限公司 | Transaction consensus processing method and device based on block chain and electronic equipment |
| US11048596B2 (en) * | 2018-12-14 | 2021-06-29 | Nokia Technologies Oy | Hierarchical weighted consensus for permissioned blockchains |
| US20210026745A1 (en) * | 2019-07-24 | 2021-01-28 | The University Of North Carolina At Charlotte | Methods, systems, and computer readable media for providing byzantine fault tolerance |
| CN111526217B (en) * | 2020-07-03 | 2020-10-09 | 支付宝(杭州)信息技术有限公司 | Consensus method and system in block chain |
| CN111526219B (en) * | 2020-07-03 | 2021-02-09 | 支付宝(杭州)信息技术有限公司 | Alliance chain consensus method and alliance chain system |
| CN113630259B (en) * | 2021-10-09 | 2021-12-14 | 支付宝(杭州)信息技术有限公司 | Consensus method, block chain system and consensus node |
-
2021
- 2021-10-09 CN CN202111178795.1A patent/CN113630259B/en active Active
-
2022
- 2022-10-09 WO PCT/CN2022/124051 patent/WO2023056966A1/en active Application Filing
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111522800A (en) * | 2020-07-03 | 2020-08-11 | 支付宝(杭州)信息技术有限公司 | Block chain consensus method, node and system of badger Byzantine fault-tolerant consensus mechanism |
| CN112416905A (en) * | 2020-07-03 | 2021-02-26 | 支付宝(杭州)信息技术有限公司 | Block chain consensus method, node and system of badger Byzantine fault-tolerant consensus mechanism |
Non-Patent Citations (1)
| Title |
|---|
| 异步环境下的拜占庭共识算法研究;翁良;《中国优秀博硕士学位论文全文数据库（硕士） 信息科技辑》;20210215;全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113630259A (en) | 2021-11-09 |
| WO2023056966A1 (en) | 2023-04-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN113645044B (en) | Consensus method, block chain system and consensus node | |
| CN113630258B (en) | Consensus method, block chain system and consensus node | |
| CN113630257B (en) | Consensus method, block chain system and consensus node | |
| EP3934165B1 (en) | Consensus method of consortium blockchain, and consortium blockchain system | |
| CN114401150B (en) | Method for adding node in blockchain network and blockchain system | |
| CN113761071B (en) | Consensus method, block chain system and consensus node | |
| CN113610531B (en) | Consensus method, block chain system and consensus node | |
| CN113630259B (en) | Consensus method, block chain system and consensus node | |
| CN110730204A (en) | Method for deleting nodes in block chain network and block chain system | |
| CN113609515B (en) | Consensus method and block chain system | |
| Yanovich et al. | Exonum: Byzantine fault tolerant protocol for blockchains | |
| 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 | |
| CN118473659A (en) | Method, system and consensus node for realizing distributed key generation on block chain | |
| CN115174048A (en) | Consensus method, system and consensus node | |
| WO2024207765A1 (en) | Transaction proposal method and consensus node in blockchain system, and blockchain system | |
| CN118473658A (en) | Method, system and consensus node for realizing distributed key generation on block chain | |
| CN115174090A (en) | Block chain consensus method and device | |
| CN116032461A (en) | Method and node for realizing distributed key generation on blockchain | |
| Yin | Scaling the Infrastructure of Practical Blockchain Systems | |
| CN116846912A (en) | View switching method, consensus node and block chain system in PBFT algorithm | |
| CN116527694A (en) | Consensus method in block chain system, consensus node and block chain system | |
| CN116846907A (en) | Consensus method and block chain link point | |
| CN116823463A (en) | Transaction proposal method in blockchain system, consensus node and blockchain system | |
| CN116823466A (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: 40062510 Country of ref document: HK |
|
| TR01 | Transfer of patent right |
Effective date of registration: 20240920 Address after: Room 803, floor 8, No. 618 Wai Road, Huangpu District, Shanghai 200010 Patentee after: Ant blockchain Technology (Shanghai) Co.,Ltd. Country or region after: China Address before: 310000 801-11 section B, 8th floor, 556 Xixi Road, Xihu District, Hangzhou City, Zhejiang Province Patentee before: Alipay (Hangzhou) Information Technology Co.,Ltd. Country or region before: China |