CN110943838A - Method, apparatus and storage medium for determining consensus of blocks in a blockchain network - Google Patents

Method, apparatus and storage medium for determining consensus of blocks in a blockchain network Download PDF

Info

Publication number
CN110943838A
CN110943838A CN201811110802.2A CN201811110802A CN110943838A CN 110943838 A CN110943838 A CN 110943838A CN 201811110802 A CN201811110802 A CN 201811110802A CN 110943838 A CN110943838 A CN 110943838A
Authority
CN
China
Prior art keywords
block
consensus
node
master node
blocks
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.)
Pending
Application number
CN201811110802.2A
Other languages
Chinese (zh)
Inventor
曹锋
马占锋
戚晓冬
杨寅
吕浩进
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shanghai Pailian Information Technology Co Ltd
Original Assignee
Shanghai Pailian Information Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shanghai Pailian Information Technology Co Ltd filed Critical Shanghai Pailian Information Technology Co Ltd
Priority to CN201811110802.2A priority Critical patent/CN110943838A/en
Publication of CN110943838A publication Critical patent/CN110943838A/en
Pending legal-status Critical Current

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
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1861—Physical mapping arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/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/3226—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 a predetermined code, e.g. password, passphrase or PIN
    • 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/3297—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 time stamps, e.g. generation of time stamps

Abstract

Embodiments of the present disclosure provide a method, apparatus, and storage medium for determining consensus of tiles in a blockchain network. In an example method, a tile is broadcast at a master node in a blockchain network. The master node receives a plurality of votes for a block from a plurality of backup nodes in a blockchain network. Each vote of the plurality of votes includes a respective signature of a predetermined size generated by a respective backup node using a respective private key. The primary node generates an aggregate signature of a predetermined size based on a plurality of signatures of a plurality of backup nodes and broadcasts the aggregate signature and a bitmap indicating the backup nodes. In this way, the efficiency of consensus determination can be significantly improved.

Description

Method, apparatus and storage medium for determining consensus of blocks in a blockchain network
Technical Field
Embodiments of the present disclosure relate generally to the field of computer technology and, more particularly, relate to a method, apparatus, and storage medium for determining consensus of tiles in a blockchain network.
Background
The utility byzantine fault tolerant (PBFT) algorithm is a commonly used block chain consensus algorithm. By utilizing the algorithm, malicious attacks and software errors and any behaviors of the failure nodes caused by the malicious attacks and the software errors can be relieved, and the adverse effect on the consensus achievement efficiency is reduced. According to the PBFT algorithm, a plurality of nodes form a consensus group. In the consensus group, one node acts as a master (or leader) and the other nodes act as backup (or verifiers). When the primary node receives a request from a client, the primary node broadcasts the request to the backup node, thereby initiating a consensus determination process.
Traditionally, the consensus determination process based on the PBFT algorithm includes the following five stages: a REQUEST (REQUEST) phase, a PRE-preparation (PRE-PREPARE) phase, a preparation (PREPARE) phase and an acknowledgement (COMMIT) phase and a REPLY (REPLY) phase, wherein the PRE-preparation, preparation and acknowledgement phases are three key phases. In the pre-prepare phase, the master node proposes a new record (or chunk) and broadcasts a pre-prepare message in the consensus group. In the preparation phase, the backup node broadcasts the preparation message after verifying the correctness of the pre-preparation message, thereby entering the preparation phase. In the acknowledgement phase, once a node receives a prepare message from more than two-thirds of the replica nodes in the consensus group, the node broadcasts an acknowledgement message in the consensus group. Finally, the master node waits for acknowledgement messages from more than two-thirds of the nodes to ensure that a sufficient number of nodes make an acknowledgement decision. In the consensus group, the consensus determination process performed for the request of the client is performed in order. That is, each node in the consensus group performs consensus determination according to the sequence of the request initiation.
The PBFT algorithm described above may be applied in the consensus determination process of blocks in a block chain network. For example, the master node may broadcast the chunks to be acknowledged in a blockchain network. And the backup node votes for the block after receiving the block. The backup node may broadcast its own vote in the blockchain network. The master node determines whether more than two-thirds of the backup nodes have voted for and may broadcast the confirmation. According to the PBFT algorithm, each communication of the primary and backup nodes takes a broadcast form, which causes a large amount of communication overhead in the blockchain network.
Disclosure of Invention
In general, embodiments of the present disclosure propose methods, apparatuses, and storage media for determining consensus of tiles in a blockchain network.
In a first aspect, embodiments of the present disclosure provide a method of determining consensus of blocks. In the method, a tile is broadcast at a master node in a blockchain network. The master node receives a plurality of votes for a block from a plurality of backup nodes in a blockchain network. Each vote of the plurality of votes includes a respective signature of a predetermined size generated by a respective backup node using a respective private key. The primary node generates an aggregate signature of a predetermined size based on a plurality of signatures of a plurality of backup nodes and broadcasts the aggregate signature and a bitmap indicating the backup nodes.
In a second aspect, embodiments of the present disclosure provide a method of determining consensus of blocks. In the method, a block broadcast by a primary node in a blockchain network is received at a backup node in the blockchain network. The backup node sends a vote to the master node. The vote includes a signature of a predetermined size of the backup node generated using the private key of the backup node. The backup node receives an aggregated signature of a predetermined size broadcast by the primary node. The aggregated signature is generated by the primary node based on signatures of a predetermined size for a plurality of backup nodes in the blockchain network. The backup nodes also receive bitmaps broadcast by the primary node indicating these backup nodes. The backup nodes use the public keys of these backup nodes to verify the aggregated signature.
In a third aspect, embodiments of the present disclosure provide an apparatus for determining consensus of tiles. The apparatus includes a processor and a memory including computer-executable instructions stored thereon. The computer executable instructions, when executed by the processor, cause the device to perform the method according to the first or second aspect.
In a fourth aspect, embodiments of the present disclosure provide a computer-readable storage medium comprising computer-executable instructions stored thereon. The computer executable instructions, when executed by a processor on the device, cause the device to perform the method according to the first or second aspect.
It should be understood that the statements herein reciting aspects are not intended to limit the critical or essential features of the embodiments of the present disclosure, nor are they intended to limit the scope of the present disclosure. Other features of the present disclosure will become apparent from the following description.
Drawings
The above and other features, advantages and aspects of various embodiments of the present disclosure will become more apparent by referring to the following detailed description when taken in conjunction with the accompanying drawings. In the drawings, like or similar reference characters designate like or similar elements, and wherein:
FIG. 1 illustrates a conventional example consensus determination process based on the PBFT algorithm;
FIG. 2 illustrates an example process of applying a PBFT algorithm to block chain consensus;
fig. 3 illustrates an example blockchain network in which embodiments of the present disclosure may be implemented;
FIG. 4 illustrates an example voting process, in accordance with certain embodiments of the present disclosure;
FIG. 5 illustrates an example process for a backup node to vote and receive data sub-blocks in parallel, in accordance with certain embodiments of the present disclosure;
FIG. 6 illustrates a flow diagram of a method according to certain embodiments of the present disclosure;
FIG. 7 shows a flow diagram of a method according to certain other embodiments of the present disclosure; and
FIG. 8 illustrates a block diagram of a device suitable for implementing embodiments of the present disclosure.
Detailed Description
Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While certain embodiments of the present disclosure are shown in the drawings, it is to be understood that the present disclosure may be embodied in various forms and should not be construed as limited to the embodiments set forth herein, but rather are provided for a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the disclosure are for illustration purposes only and are not intended to limit the scope of the disclosure.
The term "blockchain network" as used herein refers to a consensus network based on blockchain technology. Information is shared or some inter-trusted transactions are performed between various network nodes or entities in the network. The blockchain network may be overlaid on top of conventional communication networks such as cellular networks and computer networks.
The term "node" as used herein refers to a communication device in a blockchain network. Example implementations of a node include, but are not limited to, a mainframe, a server, a Personal Computer (PC), a desktop computer, a laptop computer, a notebook computer, a tablet computer, a netbook, a Personal Digital Assistant (PDA), a mobile phone, or a smartphone, among others.
The terms "include" and variations thereof as used herein are inclusive and open-ended, i.e., "including but not limited to. The term "based on" is "based, at least in part, on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment". Relevant definitions for other terms will be given in the following description.
As described above, in the PBFT algorithm, the consensus process performed within a consensus group consisting of a plurality of nodes includes five stages: a request phase, a pre-preparation phase, a preparation phase and a confirmation phase and a reply phase.
Fig. 1 shows a conventional consensus determination process 100 based on the PBFT algorithm. As shown, process 100 includes a request phase 105, a pre-preparation phase 110, a preparation phase 115, a validation phase 120, and a response phase 125. In the request phase 105, the client 130 sends a REQUEST message (REQUEST) to master node 135 requesting that an operation be performed. The format of the request message is for example<REQUEST,o,t,c>σcWhere o denotes the requested operation, t denotes the timestamp, c denotes the client, σ denotescIndicating the client's signature on the request message.
Upon receiving the request message from client 130, master node 135 may first determine whether the message being processed exceeds the limit. If the limit is exceeded, home node 135 buffers the message and then sends it in bulk. Master node 135 may generate a sequence number n for the message to be sent.
The process 100 then enters a PRE-PREPARE phase 110 where the primary node 135 broadcasts a PRE-PREPARE message (PRE-PREPARE) to all backup nodes 140-1, 140-2 … … 140-N (collectively referred to as "backup nodes 140" where N is any suitable positive integer). The format of the pre-prepared message is, for example<<PRE-PREPARE,v,n,d>σP,m>Where v denotes a view number, m denotes a message piggybacked to a backup node (i.e., a request message sent by a client), n denotes a sequence number of the message, d denotes a message digest of m, and σ denotesPIndicating the master node's signature on the pre-prepared message.
Each backup node 140 needs to check whether the signature of the pre-prepared message is correct and whether the digest of the message is correct. The backup node 140 also needs to determine whether the current view is v and check whether messages with v and n being the same but with different digests have been received. In addition, the backup node 140 needs to determine whether n is between the upper bound H and the lower bound H of the watermark (watermark).
If the acceptance condition for the pre-PREPARE message is satisfied, the backup node 140 accepts the pre-PREPARE message and the process 100 enters the preparation phase 115 where the backup node 140 broadcasts a PREPARE message (PREPARE) to the primary node 135 and other backup nodes. The format of the prepared message is, for example<PREPARE,v,n,d,i>σiWhere i denotes the node number, σiRepresenting the signature of node i on the ready message.
All nodes (including primary node 135 and backup node 140) check that the signature of the prepared message is correct, and that the message is correctWhether the abstract is correct or not; and determines whether the current view is v and n is between H and H. Once the acceptance condition for the acknowledgment message is satisfied, the node may write both the received messages (including the prepare message and the prepare message) into the log. If the number of correct prepare messages received is greater than 2f (f represents the number of Byzantine nodes, where N ≧ 3f +1), process 100 proceeds to an acknowledgement phase 120 where the replica node broadcasts an acknowledgement message (COMMIT). The format of the acknowledgement message is for example<COMMIT,v,n,D(m),i>σiWhere d (m) represents the message digest of m.
After each node receives the confirmation message, checking whether the signature of the confirmation message is correct and whether the abstract of the message is correct; and determines whether the current view is v and n is between H and H. If the above conditions are satisfied, the replica node writes the received message into the log. If the number of correct acknowledgement messages received is greater than or equal to 2f +1 (including acknowledgement messages broadcast by the node itself), the process 100 proceeds to a REPLY phase 125 where the node sends a REPLY message (REPLY) to the client 130, e.g., in the format of<REPLY,v,t,c,i,r>σiWhere r represents the result of the performed operation of node i.
If the client 130 receives correct response messages from nodes greater than or equal to f +1, e.g., the signature is correct, the timestamp t is the same, and the execution result r is the same, the client 130 determines that consensus is achieved. In the example shown in FIG. 1, the backup node 140-N is a failed node. Thus, in both the prepare phase 115 and the confirm phase 120, no broadcast message is received by each node from the backup node 140-N. In the reply phase 125, the client 130 also does not receive a reply message from the backup node 140-N. However, since the client 130 receives the correct reply messages from more than f +1 nodes, consensus is achieved.
The PBFT algorithm described above may be applied to the consensus determination process in the block chain network in order to improve the efficiency of the consensus process.
Fig. 2 illustrates an example process 200 of applying a PBFT algorithm to block chain consensus. As shown in fig. 2, the process 200 includes a proposal (prompt) phase 205, a pre-vote (PREVOTE) phase 210, and a pre-confirm (preconmit) phase 215. In proposal phase 205, master node 235 proposes block 245 at round R at altitude H (e.g., at round R consensus determination for the H-th block), including the submitted batch of pending transactions. The master node 235 broadcasts the block 245 to all of the backup nodes 240-1, 240-2 … … 240-N (collectively, backup nodes 240).
During the pre-vote phase 210, each node (including the primary node 235 and the backup node 240) validates the proposed block 245 and broadcasts a PREVOTE message, i.e., makes a preliminary vote (250). The pre-voting on the block is used to prepare the network to confirm the vote of the block. A pre-vote containing an empty message (e.g., an empty string nil) is a vote indicating that the network is expected to prepare for the next round of consensus determination. After the node receives a PREVOTE message from more than two-thirds of the nodes in the consensus group, the node enters the pre-acknowledgement phase 215.
In the pre-validation stage 215, the actual voting for validation of the block is performed (255). The pre-confirmation containing the null message is an actual vote indicating that the next round of voting is desired. If a node receives a PREVOTE message for more than two-thirds of the nodes in the group, the node broadcasts a PRECOMMIT message within the group. Block 245 is acknowledged at acknowledgement point 260 if a node receives a preamble message from more than two-thirds of the nodes in the group. Thereby, it can be ensured that a sufficient number of nodes make the same decision for a block. After consensus on the tile is achieved, master node 235 may propose a new tile and initiate a new round of consensus process (not shown).
The inventor notices that in the consensus determination process of the block chain network based on the PBFT algorithm, each round of voting adopts a broadcast (or multicast) mode, so that the communication complexity is O (n)2) Where n represents the number of nodes participating in the vote. This makes the PBFT algorithm inapplicable to common blockchain networks consisting of thousands of nodes. In addition, the PBFT algorithm generally assumes that the size of the set of nodes is fixed and does not change over time. However, in a blockchain network, there are often nodes joining or leaving.
The inventors have also noted that another assumption of the PBFT algorithm is that the master node is only replaced when a problem (e.g., failure) occurs, and thus it is easier for an attacker to discover and attack the master node. If a malicious (attacked) master node does not collect transactions for a given node into a block, these transactions will never be executed. Furthermore, some backup nodes may cause a block chain to branch if they do not synchronize to the latest network state within a short time. Furthermore, the backup node typically does not start verification until after receiving the proposed complete block, and then starts the voting process. Thus, consensus is inefficient, especially if the block is large.
Embodiments of the present disclosure provide a mechanism for consensus in a new blockchain network. According to this mechanism, on the master node side in a blockchain network, after a block is broadcast, the master node receives a plurality of votes for the block from a plurality of backup nodes. Each vote includes a signature generated by the corresponding backup node using its private key. The master node generates an aggregate signature based on the signatures, the aggregate signature being the same size as the signature of the backup node. The master node then broadcasts the generated aggregated signature. Because the size of the aggregated signature is the same as that of a backup node, the communication overhead between the main node and the backup node is greatly reduced.
On the side of the backup node, in each round of voting, the backup node sends the voting to the main node in a unicast mode instead of broadcasting the voting in a block chain network. After the backup node receives the aggregated signature broadcast by the main node, the backup node verifies the aggregated signature by using the public keys of other backup nodes which send votes to the main node and the signatures in the votes participate in the generation of the aggregated signature, thereby determining whether the consensus of the blocks is achieved. The voting of the backup node is changed from multicast to unicast, so that the communication complexity is changed from O (n)2) Reduced to O (n).
Fig. 3 illustrates an example blockchain network 300 in which embodiments of the present disclosure may be implemented. Network 300 includes a plurality of nodes 305-1, 305-2 … … 305-m (collectively referred to as nodes 305), where m is any suitable positive integer. The nodes 305 may communicate with each other in a wired or wireless manner. The communication may be any suitable communication technology currently known and developed in the future. The scope of the present disclosure is not limited in this respect.
Among these nodes 305, one node acts as a primary node (e.g., node 305-1) and the other nodes (e.g., node 305-2 … … 305-m) act as backup nodes. The master node broadcasts a block in the network 300 and receives votes for the block from the backup nodes. In various embodiments of the present disclosure, the backup node sends a vote to the primary node in a unicast manner, and the vote includes a signature generated by the backup node using its private key. The master node generates an aggregated signature from the signatures contained in the individual votes, wherein the aggregated signature is the same size as the signature in the vote.
Fig. 4 illustrates an example voting process 400 in accordance with certain embodiments of the present disclosure. In this example, node 305-1 acts as the primary node and the other nodes 305-2 … … 305-m act as backup nodes. In the proposal phase 405, the master node (e.g., node 305-1) broadcasts the block. During the pre-vote phase 410, the backup node (e.g., node 305-2 … … 305-m) sends a vote for the block to the primary node in unicast. For example, the backup node may vote in favor of the block if it is verified to be valid, and vote otherwise (e.g., an empty string nil or an empty ticket). As an example, the vote may include an identification of the tile (e.g., a hash value of the tile), a height H of the tile (e.g., the H-th tile), a number of rounds R to determine consensus at the height H (e.g., the R-th round of consensus determination for the H-th tile), and any suitable other information associated with the tile and the consensus determination. The backup node may send an empty string nil as an anti-vote for the block, indicating that the backup node desires to proceed with the next round of consensus determination.
The vote sent by the backup node includes a signature generated by the node using its private key. For example, the backup node may generate a private key and public key pair using a traceback search (BLS) algorithm. The backup node signs the vote with the generated private key. Also, the backup node may also broadcast the generated public key in network 300.
The master node generates an aggregated signature based on signatures in votes from the plurality of backup nodes that is the same size as the nodes in the votes. For example, the primary node may multiply the signatures of multiple backup nodes to generate an aggregate signature. In some embodiments, the master node may multiply the signatures in the positive tickets for the blocks, such that the generated aggregated signature contains the signature of the backup node that voted positive. The aggregated signature may be generated if the master node determines that more than a predetermined threshold number of nodes (e.g., more than two-thirds of the nodes) in the network 300 vote in favor of the block. In this way, in the case where a node sends a conflicting or wrong vote because it is attacked, since the impact is limited to this single node, the consensus is still valid if more than two-thirds of the nodes are secure.
The aggregated signature is broadcast by the master node in the network 300. Meanwhile, the main node also broadcasts a bitmap of a backup node participating in voting, and the signature in the voting participates in the generation of the aggregated signature. After receiving the aggregated signature and the bitmap, the backup nodes may determine from the bitmap which backup nodes' public keys to use to verify the aggregated signature and verify it using the associated public keys. For example, the backup node may multiply the public keys of other backup nodes that sent votes to the primary node and the signatures in the votes participated in aggregate signature generation to generate an aggregate public key, which is then used to verify the aggregate signature. Therefore, each backup node can determine the voting result of the pre-voting stage and can determine whether the main node is a malicious node. For a backup node participating in the voting, the signature of the backup node may not participate in the generation of the aggregated signature. Accordingly, the bitmap may also have no information for the node. This is because, as described above, the master node may generate an aggregate signature upon determining that more than a predetermined threshold number (e.g., more than two-thirds) of nodes cast positive or negative votes (or null votes, e.g., null strings nil) to the block, without having to wait for the signatures of all backup nodes to be collected.
Similar to the pre-vote phase 410, the master node also broadcasts the block during the pre-validation phase 415. Accordingly, the backup node sends a vote to the master node containing the signature. If the backup node determines that more than a predetermined threshold number of nodes vote for the block by verifying the aggregated signature in the pre-vote stage 410, the backup node may vote for the block in the pre-validation stage 415. Otherwise, the backup node may send a vote containing a null string to indicate an objection to the block. The master node generates an aggregate signature based on the respective signatures and broadcasts the aggregate signature in the network 300. The backup node verifies the aggregated signature based on the associated public key. The features and operations of the primary and backup nodes described above with respect to the pre-voting stage 410 are equally applicable to the pre-validation stage 415, and thus the details are not repeated.
If the master node is attacked, it may not make the proposal or discard some transactions when building the proposed block. It is also possible for the attacked master node to propose different blocks to different nodes. This may lead to failure to achieve consensus. In some embodiments, a new master node is determined in network 300 in response to the consensus determination for the tiles being completed to reduce the likelihood of a master node attack. Any suitable algorithm may be employed to elect a new node. In some embodiments, the new node may be determined based on the aggregated signature. For example, a Hash (Hash) operation may be performed on the aggregate signature of the previous consensus block and the current consensus round number, and the number of nodes is used to modulo the obtained Hash value, thereby obtaining an index or number of the new master node.
In some embodiments, a new master node may be determined at the end of each block height and each round of consensus. For example, after the consensus determination is complete, if consensus is achieved, a new chunk height is entered, and a new master node is determined based on the hash value of the aggregated signature generated by the previous consensus achieved. If the consensus is not achieved, a new consensus round is entered, and a new master node is determined according to the aggregate signature of the last block achieving the consensus and the hash value of the number of consensus rounds on the current block height. For example, when determining the consensus master node for the 101 th block, a new master node may be selected by modulo the hash value of the aggregate signature of the 100 th block and the current consensus round number 1 of the 101 th block using the number of nodes. If consensus on the 101 th chunk is not achieved, a new master node may be determined by modulo the hash value of the aggregate signature of the 100 th chunk with the new consensus round number 2 of the 101 th chunk using the number of nodes. For the first chunk, the master node may be determined based on the hash value of the empty string (nil). In this way, it is difficult to guess in advance who is the next master node, thereby greatly reducing the possibility of the master node being attacked.
Each node 305 in the network 300 may vote for only one block at each altitude and each round of consensus determination to allow consensus to be achieved as quickly as possible. In some embodiments, each node may record a block if more than a predetermined threshold number of backup nodes vote for the block during consensus determination for the block. The master node may determine whether more than a predetermined threshold number of backup nodes cast in favor of a vote based on the received votes. The backup node may perform the above determination based on the aggregated signature broadcast by the primary node. If consensus on the blocks is not achieved, the nodes may make a new round of consensus determination based on the recorded blocks.
For example, in a new round of consensus determination, the master node broadcasts the recorded chunks. The backup node may compare the received blocks with the recorded blocks after receiving the blocks broadcast by the primary node. If the two are the same, the backup node approves the ticket. This ensures that more than a predetermined threshold number (e.g., more than two thirds) of the voting rights are locked to the same block, thereby preventing divergence and achieving consensus as early as possible.
A new round of consensus determination may also include two phases, pre-voting and pre-validation. In the pre-vote phase, if a node has recorded or bound a block, the node still votes for this block even though it currently receives a new block. If the node has not previously recorded or locked any blocks, it is verified whether the currently received block is valid. If valid, the node approves the ticket, otherwise it approves the ticket (e.g., the empty string nil) to indicate that the node wishes to enter the next round of consensus determination.
In the pre-validation phase, if the node determines that more than a predetermined threshold number (e.g., more than two-thirds) of positive tickets have not been received in the pre-voting phase, the node votes against the tickets (e.g., the empty string nil or empty tickets). In the event that more than a predetermined threshold number of positive tickets are received, the node may also vote negatively (e.g., an empty ticket) to indicate a desire to enter the next round of consensus determination. At which point unlocking (or binding) is required. If more than a predetermined threshold number of votes are received and the node has bound to the received tile, the node directly honors the votes. If a predetermined threshold number of positive tickets are received but the blocks for which positive tickets are directed are not the same as the recorded or bound blocks, then it is verified whether the blocks for which positive tickets are directed are valid. If valid, the ticket is voted for and this new chunk is recorded or bound. If more than a predetermined threshold number of votes are received, the node does not vote for the corresponding block. The node may request this block from other nodes and cast a null ticket.
In the validation phase, if more than a predetermined threshold number of positive tickets are received for a block, the block is validated before the next height (i.e., block height H plus 1) is entered. If more than a predetermined threshold number (e.g., more than two-thirds) of empty tickets are received, the next round of consensus determination is entered (i.e., the number of rounds R plus 1) and the current tile height remains unchanged.
If the block is very large, it takes a long time for the master node to broadcast the block and for the backup node to receive the block. It also takes a long time for the master node to collect the votes of the backup nodes. This will greatly reduce the number of Transactions Per Second (TPS) in a blockchain network. In some embodiments, the master node may divide the data of the block into a plurality of data sub-blocks while generating summary information for the block. By way of example, the summary information may include an identification of the block, a height of the block, a number of rounds at which consensus was determined, and a number of data sub-blocks, among others. The summary information may also include verification information for the data sub-blocks, such as a hash value for each data sub-block or a hash tree value for the entire block (e.g., a Merkle tree hash value).
The master node may broadcast summary information for the blocks and a plurality of data sub-blocks separately. For example, the host node may broadcast the summary information first, and then broadcast the data sub-blocks. Alternatively, the master node may also broadcast the summary information and the data sub-blocks in parallel. The backup node may start voting after receiving the summary information while receiving the data sub-blocks in parallel. In this way, latency can be greatly reduced, improving the efficiency of consensus determinations.
Fig. 5 illustrates an example process 500 for a backup node to vote and receive data sub-blocks in parallel, in accordance with certain embodiments of the present disclosure. As shown in fig. 5, at 505, the backup node is in an idle state. At 510, the backup node receives summary information for the blocks broadcast by the primary node. At 515, in response to receiving the summary information, the backup node determines whether to approve or disapprove the block and performs a pre-vote. At 520, the backup node preacknowledges the block. The operations and features described above with respect to pre-voting and pre-validation are also applicable here and will not be described further.
In process 500, in parallel with receiving the summary information (510), the backup node receives 525 a plurality of data sub-blocks of blocks broadcast by the primary node. At 530, the backup node verifies the block.
After two rounds of pre-voting and pre-validation, the backup node validates the block at 535 after verifying the block even if the backup node determines that more than a predetermined threshold number of nodes voted for the block. If no node exceeding the predetermined threshold number votes for approval or the block fails verification, the block is discarded and the next round of consensus confirmation is entered (i.e., the height H is not changed, the number of rounds R is incremented by one).
Fig. 6 illustrates a flow diagram of an example method 600 in accordance with certain embodiments of the present disclosure. The method 600 may be implemented at a master node in a blockchain network 300 as shown in fig. 3.
As shown in fig. 6, at block 605, a tile is broadcast at a master node in a blockchain network. At block 610, a plurality of votes for a block is received from a plurality of backup nodes in a network of block chains. Each vote includes a respective signature of a predetermined size generated by the respective backup node using the respective private key. At block 615, an aggregate signature of a predetermined size is generated based on the plurality of signatures of the plurality of backup nodes. At block 620, the aggregate signature is broadcast along with a bitmap indicating the backup nodes.
In some embodiments, method 600 may also include broadcasting a bitmap indicating a plurality of backup nodes. In some embodiments, each vote may further include at least one of: the identity of the block, the height of the block, and the number of consensus rounds determined at that height.
In some embodiments, method 600 may further include, in response to the determination of consensus for the tiles being complete, determining a new master node from the blockchain network based at least in part on the aggregated signature. In some embodiments, a determination may be made whether consensus is achieved in response to a determination of consensus for a block being completed. A new master node may also be determined from the blockchain network based on the aggregated signature and the latest number of consensus rounds at the height of the current chunk in response to determining that consensus is not achieved.
In some embodiments, method 600 may further include: determining, based on the received plurality of votes, whether a number of backup nodes of the plurality of backup nodes that favor the block exceeds a predetermined threshold number; in response to the number exceeding a predetermined threshold number, recording the block; and in response to the consensus of the blocks not being achieved, performing a new round of consensus determination based on the recorded blocks.
In some embodiments, the recorded chunks may be broadcast if the master node is acting as the master node in a new round of determination. If the master node is acting as a backup node in a new round of consensus determination, it may be determined whether the received tile is the same as the recorded tile in response to receiving the tile broadcast by the current master node in the blockchain network. A vote indicating approval of the received chunk may also be transmitted to the current master node in response to determining that the received chunk is the same as the recorded chunk.
In some embodiments, a block may include summary information about the block and a plurality of sub-blocks of data for the block. In these embodiments, summary information about a block may be broadcast, and a plurality of data sub-blocks of the block are broadcast. The summary information on the block may include at least one of: an identification of the block, a height of the block, a number of rounds at which consensus is determined, a number of data sub-blocks, and authentication information for the data sub-blocks.
Fig. 7 illustrates a flow diagram of an example method 700 in accordance with certain other embodiments of the present disclosure. Method 700 may be implemented at a backup node in a blockchain network 300 as shown in fig. 3.
As shown in fig. 7, at block 705, a tile broadcast by a primary node in a blockchain network is received at a backup node in the blockchain network. At block 710, a vote is sent to the primary node, the vote including a signature of a predetermined size for the backup node generated using the private key of the backup node. At block 715, an aggregated signature of a predetermined size broadcast by the primary node is received. The aggregated signature is generated by the primary node based on signatures of a predetermined size for a plurality of backup nodes in the blockchain network. At block 720, a bitmap broadcast by the primary node indicating the backup nodes is received. At block 725, the backup nodes verify the aggregated signature using the public keys of these backup nodes.
In some embodiments, the voting may further include at least one of: the identity of the block, the height of the block, and the number of consensus rounds determined at that height.
In some embodiments, method 700 may further include determining a new master node from the blockchain network based at least on the aggregated signature in response to the determination of consensus of the tiles being complete. In some embodiments, a determination may be made whether consensus is achieved in response to a determination of consensus for a block being completed. A new master node may also be determined from the blockchain network based on the aggregated signature and the latest number of consensus rounds at the height of the current chunk in response to determining that consensus is not achieved.
In some embodiments, method 700 may further include: determining, based on the received plurality of votes, whether a number of backup nodes of the plurality of backup nodes that favor the block exceeds a predetermined threshold number; in response to the number exceeding a predetermined threshold number, recording the block; and in response to the consensus of the blocks not being achieved, performing a new round of consensus determination based on the recorded blocks.
In some embodiments, the recorded blocks may be broadcast if the backup node is acting as the master node in a new round of determination. If the backup node is acting as a backup node in a new round of consensus determination, it may be determined whether the received tile is the same as the recorded tile in response to receiving the tile broadcast by the current master node in the blockchain network. A vote indicating approval of the received chunk may also be transmitted to the current master node in response to determining that the received chunk is the same as the recorded chunk.
In some embodiments, a block may include summary information about the block and a plurality of sub-blocks of data for the block. In these embodiments, summary information about a tile broadcast by a master node may be received, and a plurality of data sub-tiles for the tile broadcast by the master node may be received. In some embodiments, it may be determined whether to approve or disapprove the block in response to receiving the summary information, and a vote indicating approval or disapproval of the block may be sent to the master node.
In some embodiments, the summary information about the tile may include at least one of: an identification of the block, a height of the block, a number of rounds at which consensus is determined, a number of data sub-blocks, and authentication information for the data sub-blocks.
It should be understood that the operations and related features of the primary and backup nodes described above in connection with fig. 3 through 5 are equally applicable to methods 600 and 700 and have the same effect, and detailed description is omitted.
Fig. 8 illustrates a block diagram of a device 800 suitable for implementing certain embodiments of the present disclosure. Device 800 can be used to implement, for example, node 305 shown in fig. 3.
As shown, the device 800 includes a controller 810. The controller 810 controls the operation and functions of the device 800. For example, in certain embodiments, the controller 810 may perform various operations by way of instructions 830 stored in a memory 820 coupled thereto. The memory 820 may be of any suitable type suitable to the local technical environment and may be implemented using any suitable data storage technology, including but not limited to semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems. Although only one memory unit is shown in FIG. 8, there may be multiple physically distinct memory units within device 800.
The controller 810 may be of any suitable type suitable to the local technical environment and may include, but is not limited to, one or more of general purpose computers, special purpose computers, microcontrollers, digital signal controllers (DSPs), and controller-based multi-core controller architectures. The device 800 may also include a plurality of controllers 810. Controller 810 is coupled to communication module 840. The communication module 840 may transmit and receive information by means of a cable or an antenna.
When the device 800 functions as a master node, the controller 810 and the communication module 840 may operate in cooperation to implement the method 600 described above with reference to fig. 6. When device 800 is acting as a backup node, controller 810 and communication module 840 may operate in conjunction to implement method 700 described above with reference to fig. 7. All of the features described above with reference to fig. 3-7 apply to the apparatus 800 and are not described in detail herein.
In particular, the processes described above with reference to fig. 3-7 may be implemented by computer-executable instructions, according to embodiments of the present disclosure. The instructions may be tangibly stored on a non-transitory computer-readable storage medium, which when executed, cause a device to implement various aspects in accordance with the present disclosure.
The computer readable storage medium may be a tangible device that may store instructions for use by an instruction execution device. The computer readable storage medium may include, for example, but is not limited to, an electronic memory device, a magnetic memory device, an optical memory device, an electromagnetic memory device, a semiconductor memory device, or any suitable combination of the foregoing. More specific, non-exhaustive examples of the computer readable storage medium include: a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a Static Random Access Memory (SRAM), a portable compact disc read-only memory (CD-ROM), a Digital Versatile Disc (DVD), a memory stick, a floppy disk, a mechanical coding device, such as punch cards or in-groove projection structures having instructions stored thereon, and any suitable combination of the foregoing. Computer-readable storage media as used herein is not to be construed as transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., optical pulses through a fiber optic cable), or electrical signals transmitted through electrical wires.
The computer program instructions for carrying out operations of the present disclosure may be assembler instructions, Instruction Set Architecture (ISA) instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer-executable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider). In some embodiments, the electronic circuitry that can execute the computer-executable program instructions implements aspects of the present disclosure by utilizing state information of the computer-executable program instructions to personalize the electronic circuitry, such as a programmable logic circuit, a Field Programmable Gate Array (FPGA), or a Programmable Logic Array (PLA).
Various aspects of the disclosure are described herein with reference to block diagrams and/or flowchart illustrations. It will be understood that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by computer-executable program instructions.
Various embodiments of the present disclosure have been described for purposes of illustration, but the present disclosure is not intended to be limited to the disclosed embodiments. All such modifications and variations are within the scope of the disclosure as defined in the appended claims without departing from the spirit thereof.

Claims (24)

1. A method of determining consensus of blocks, comprising:
broadcasting the tiles at a master node in a blockchain network;
receiving, from a plurality of backup nodes in the blockchain network, a plurality of votes for the tile, each vote of the plurality of votes comprising a respective signature of a predetermined size generated by the respective backup node using a respective private key;
generating an aggregated signature of the predetermined size based on a plurality of signatures of the plurality of backup nodes; and
broadcasting the aggregated signature and a bitmap indicating the plurality of backup nodes.
2. The method of claim 1, wherein each vote of the plurality of votes further comprises at least one of: the identity of the block, the height of the block, and the number of consensus rounds determined at the height.
3. The method of claim 1, further comprising:
in response to the determination of the consensus of the tiles being complete, determining a new master node from the blockchain network based at least in part on the aggregated signature.
4. The method of claim 3, wherein determining the new master node based at least in part on the aggregated signature comprises:
in response to the determination of the consensus for the block being complete, determining whether the consensus is achieved; and
in response to determining that the consensus is not achieved, determining the new master node from the blockchain network based on the aggregate signature and a number of rounds of consensus determined at the height of the tile.
5. The method of claim 1, further comprising:
determining, based on the received plurality of votes, whether a number of backup nodes of the plurality of backup nodes that favor the block exceeds a predetermined threshold number;
in response to the number exceeding the predetermined threshold number, recording the block; and
in response to the consensus of the blocks not being achieved, a new round of consensus determination is performed based on the recorded blocks.
6. The method of claim 5, wherein performing a new round of consensus determination based on the recorded blocks comprises:
broadcasting the recorded blocks if the master node is acting as the master node in the new round of determination.
7. The method of claim 5, wherein performing a new round of consensus determination based on the recorded blocks comprises: if the master node is acting as a backup node in the new round of consensus determination,
in response to receiving a block broadcast by a current master node in the blockchain network, determining whether the received block is the same as the recorded block; and
in response to determining that the received tile is the same as the recorded tile, sending a vote to the current master node indicating approval of the received tile.
8. The method of claim 1, wherein the block comprises summary information about the block and a plurality of sub-blocks of data for the block, and broadcasting the block comprises:
broadcasting the summary information about the block; and
broadcasting the plurality of data sub-blocks of the block.
9. The method of claim 8, wherein each vote of the plurality of votes is a vote for the summary information by a respective backup node of the plurality of backup nodes.
10. The method according to claim 8 or 9, wherein the summary information about the block comprises at least one of: an identification of the block, an elevation of the block, a number of rounds at which consensus is determined, a number of the sub-blocks of data, and authentication information for the sub-blocks of data.
11. A method of determining consensus of blocks, comprising:
receiving, at a backup node in a blockchain network, a block broadcast by a master node in the blockchain network;
sending a vote to the primary node, the vote comprising a signature of a predetermined size of the backup node generated using a private key of the backup node;
receiving an aggregated signature of the predetermined size broadcast by the master node, the aggregated signature generated by the master node based on signatures of the predetermined size for a plurality of backup nodes in the blockchain network;
receiving a bitmap broadcast by the primary node indicating the plurality of backup nodes; and
verifying the aggregated signature using public keys of the plurality of backup nodes.
12. The method of claim 11, wherein the voting further comprises at least one of: the identity of the block, the height of the block, and the number of consensus rounds determined at the height.
13. The method of claim 11, further comprising:
in response to the determination of the consensus of the tiles being complete, determining a new master node from the blockchain network based at least on the aggregated signature.
14. The method of claim 13, wherein determining the new master node based at least on the aggregated signature comprises:
in response to the determination of the consensus for the block being complete, determining whether the consensus is achieved; and
in response to determining that the consensus is not achieved, determining the new master node from the blockchain network based on the aggregate signature and a number of rounds of consensus determined at the height of the tile.
15. The method of claim 11, further comprising:
determining, based on the received plurality of votes, whether a number of backup nodes of the plurality of backup nodes that favor the block exceeds a predetermined threshold number;
in response to the number exceeding the predetermined threshold number, recording the block; and
in response to the consensus of the blocks not being achieved, a new round of consensus determination is performed based on the recorded blocks.
16. The method of claim 15, wherein performing a new round of consensus determination based on the recorded blocks comprises:
broadcasting the recorded blocks if the backup node is acting as a master node in the new round of determination.
17. The method of claim 15, wherein performing a new round of consensus determination based on the recorded blocks comprises: if the backup node is acting as a backup node in the new round of consensus determination,
in response to receiving a block broadcast by a current master node in the blockchain network, determining whether the received block is the same as the recorded block; and
in response to determining that the received tile is the same as the recorded tile, sending a vote to the current master node indicating approval of the received tile.
18. The method of claim 11, wherein the block comprises summary information about the block and a plurality of data sub-blocks of the block, and receiving the block broadcast by the master node comprises:
receiving the summary information about the blocks broadcast by the master node; and
receiving the plurality of data sub-blocks of the block broadcast by the master node.
19. The method of claim 18, wherein sending the vote comprises:
determining whether to approve or disapprove the block in response to receiving the summary information; and
sending the vote to the master node indicating approval or disapproval of the block.
20. The method according to claim 18 or 19, wherein the summary information about the block comprises at least one of: an identification of the block, an elevation of the block, a number of rounds at which consensus is determined, a number of the sub-blocks of data, and authentication information for the sub-blocks of data.
21. An apparatus for determining consensus of tiles, comprising:
a processor, and
a memory comprising computer-executable instructions stored thereon that, when executed by the processor, cause the device to perform the method of any of claims 1-10.
22. An apparatus for determining consensus of tiles, comprising:
a processor, and
a memory comprising computer-executable instructions stored thereon that, when executed by the processor, cause the device to perform the method of any of claims 11-20.
23. A computer-readable storage medium comprising computer-executable instructions stored thereon that, when executed by a processor on a device, cause the device to perform the method of any of claims 1-10.
24. A computer-readable storage medium comprising computer-executable instructions stored thereon that, when executed by a processor on a device, cause the device to perform the method of any of claims 11-20.
CN201811110802.2A 2018-09-21 2018-09-21 Method, apparatus and storage medium for determining consensus of blocks in a blockchain network Pending CN110943838A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201811110802.2A CN110943838A (en) 2018-09-21 2018-09-21 Method, apparatus and storage medium for determining consensus of blocks in a blockchain network

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201811110802.2A CN110943838A (en) 2018-09-21 2018-09-21 Method, apparatus and storage medium for determining consensus of blocks in a blockchain network

Publications (1)

Publication Number Publication Date
CN110943838A true CN110943838A (en) 2020-03-31

Family

ID=69905518

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811110802.2A Pending CN110943838A (en) 2018-09-21 2018-09-21 Method, apparatus and storage medium for determining consensus of blocks in a blockchain network

Country Status (1)

Country Link
CN (1) CN110943838A (en)

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111382456A (en) * 2020-06-01 2020-07-07 腾讯科技（深圳）有限公司 Proposal message processing method, device, equipment and storage medium
CN111478772A (en) * 2020-06-22 2020-07-31 杭州趣链科技有限公司 Assembly line friendly signature and signature verification method, device and storage medium
CN111586168A (en) * 2020-05-06 2020-08-25 恒宝股份有限公司 Waterline height changing and setting method
CN111582843A (en) * 2020-04-07 2020-08-25 浙商银行股份有限公司 Block chain privacy transaction method based on aggregated signature
CN111708833A (en) * 2020-05-18 2020-09-25 杜晓楠 Method for data synchronization in DBFT consensus network, computer-readable storage medium and DBFT consensus network
CN112118239A (en) * 2020-09-03 2020-12-22 腾讯科技（深圳）有限公司 Block chain consensus method and device, electronic equipment and storage medium
CN112398949A (en) * 2020-11-26 2021-02-23 卓尔智联(武汉)研究院有限公司 Transaction confirmation method, system, device and computer equipment
CN112532396A (en) * 2020-12-04 2021-03-19 广东工业大学 Optimized Byzantine fault-tolerant method based on aggregated signature and storage medium
CN113254272A (en) * 2021-06-09 2021-08-13 腾讯科技（深圳）有限公司 Data processing method and device for block chain network, computer equipment and medium
CN113794694A (en) * 2021-08-25 2021-12-14 清华大学 Binary consensus method and device based on reliable broadcast
CN113890744A (en) * 2021-10-04 2022-01-04 杭州复杂美科技有限公司 Aggregate signature consensus method, computer device, and storage medium
CN114329616A (en) * 2022-03-10 2022-04-12 浙江数秦科技有限公司 Credible file system based on block chain
CN114650289A (en) * 2020-12-02 2022-06-21 王志诚 Method and device for block chain consensus
CN115665170A (en) * 2022-10-17 2023-01-31 重庆邮电大学 Block chain consensus method based on reputation and node compression mechanism

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107968708A (en) * 2017-11-10 2018-04-27 财付通支付科技有限公司 Generate method, apparatus, terminal and the server of signature
US20180157558A1 (en) * 2016-10-04 2018-06-07 Nec Europe Ltd. Method and system for byzantine fault-tolerance replicating of data on a plurality of servers
CN108182635A (en) * 2017-12-18 2018-06-19 深圳前海微众银行股份有限公司 Block chain common recognition method, system and computer readable storage medium
CN108521328A (en) * 2018-03-26 2018-09-11 杭州秘猿科技有限公司 A kind of block chain common recognition method, apparatus and electronic equipment

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180157558A1 (en) * 2016-10-04 2018-06-07 Nec Europe Ltd. Method and system for byzantine fault-tolerance replicating of data on a plurality of servers
CN107968708A (en) * 2017-11-10 2018-04-27 财付通支付科技有限公司 Generate method, apparatus, terminal and the server of signature
CN108182635A (en) * 2017-12-18 2018-06-19 深圳前海微众银行股份有限公司 Block chain common recognition method, system and computer readable storage medium
CN108521328A (en) * 2018-03-26 2018-09-11 杭州秘猿科技有限公司 A kind of block chain common recognition method, apparatus and electronic equipment

Cited By (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111582843A (en) * 2020-04-07 2020-08-25 浙商银行股份有限公司 Block chain privacy transaction method based on aggregated signature
CN111586168B (en) * 2020-05-06 2022-04-08 恒宝股份有限公司 Waterline height changing and setting method
CN111586168A (en) * 2020-05-06 2020-08-25 恒宝股份有限公司 Waterline height changing and setting method
CN111708833B (en) * 2020-05-18 2023-06-06 杜晓楠 Method for data synchronization in DBFT consensus network, computer readable storage medium and DBFT consensus network
CN111708833A (en) * 2020-05-18 2020-09-25 杜晓楠 Method for data synchronization in DBFT consensus network, computer-readable storage medium and DBFT consensus network
CN111382456B (en) * 2020-06-01 2020-10-23 腾讯科技（深圳）有限公司 Proposal message processing method, device, equipment and storage medium
CN111382456A (en) * 2020-06-01 2020-07-07 腾讯科技（深圳）有限公司 Proposal message processing method, device, equipment and storage medium
JP7407925B2 (en) 2020-06-22 2024-01-04 杭州趣鏈科技有限公司 Flowline friendly signature and signature verification methods, equipment and storage media
CN111478772A (en) * 2020-06-22 2020-07-31 杭州趣链科技有限公司 Assembly line friendly signature and signature verification method, device and storage medium
JP2022553995A (en) * 2020-06-22 2022-12-27 杭州趣鏈科技有限公司 Flowline-friendly signature and signature verification methods, facilities and storage media
WO2021258549A1 (en) * 2020-06-22 2021-12-30 杭州趣链科技有限公司 Assembly line friendly signing and signature verifying methods, device, and storage medium
CN112118239A (en) * 2020-09-03 2020-12-22 腾讯科技（深圳）有限公司 Block chain consensus method and device, electronic equipment and storage medium
CN112398949A (en) * 2020-11-26 2021-02-23 卓尔智联(武汉)研究院有限公司 Transaction confirmation method, system, device and computer equipment
CN114650289A (en) * 2020-12-02 2022-06-21 王志诚 Method and device for block chain consensus
CN114650289B (en) * 2020-12-02 2023-04-14 王志诚 Method and device for block chain consensus
CN112532396A (en) * 2020-12-04 2021-03-19 广东工业大学 Optimized Byzantine fault-tolerant method based on aggregated signature and storage medium
CN113254272A (en) * 2021-06-09 2021-08-13 腾讯科技（深圳）有限公司 Data processing method and device for block chain network, computer equipment and medium
CN113794694A (en) * 2021-08-25 2021-12-14 清华大学 Binary consensus method and device based on reliable broadcast
CN113890744A (en) * 2021-10-04 2022-01-04 杭州复杂美科技有限公司 Aggregate signature consensus method, computer device, and storage medium
CN114329616A (en) * 2022-03-10 2022-04-12 浙江数秦科技有限公司 Credible file system based on block chain
CN115665170A (en) * 2022-10-17 2023-01-31 重庆邮电大学 Block chain consensus method based on reputation and node compression mechanism
CN115665170B (en) * 2022-10-17 2024-03-22 重庆邮电大学 Block chain consensus method based on reputation and node compression mechanism

Similar Documents

Publication Publication Date Title
CN110943838A (en) Method, apparatus and storage medium for determining consensus of blocks in a blockchain network
TWI705690B (en) System for changing master node in distributed network
CN109361740B (en) Block generation method, device, equipment and medium of block chain
US20230259430A1 (en) Byzantine agreement using communications having linear complexity
US11133939B2 (en) Private blockchain transaction management and termination
CN112685796B (en) Block chain-based block consensus method and related equipment
CN110169015B (en) Achieving consensus among network nodes in a distributed system
CN110178340B (en) Recovery processing of network nodes in distributed systems
CN108667614B (en) Byzantine fault-tolerant method and implementation system thereof
CN110869967B (en) System and method for parallel processing of blockchain transactions
CN108648084B (en) Data processing method, device and equipment of block chain network and storage medium
US11222009B2 (en) High throughput blockchain consensus systems and methods with low finalization time
CN112041872A (en) Maintaining blocks of a blockchain in a partitioned blockchain network
CN110941859A (en) Method, apparatus, computer-readable storage medium, and computer program product for block chain formation consensus
CN108900364B (en) Block chain network management method, block chain network management device, block chain network management medium and electronic equipment
CN108320155B (en) Method for realizing block chain consensus mechanism
KR101962686B1 (en) System and method for electronic voting
CN108737105B (en) Method and device for retrieving private key, private key equipment and medium
CN109194493B (en) Information management system, method and device
TWI497438B (en) A system for firmware upgrade in ami and method thereof
CN109685505B (en) Byzantine fault-tolerant consensus optimization method based on association ring signature
CN116094731A (en) Signature authentication method and system based on Wen Haxi chain
CN111582843A (en) Block chain privacy transaction method based on aggregated signature
CN113127569A (en) Consensus method and device for block chain system, electronic equipment and storage medium
KR20200081533A (en) Blockchain Consensus Method based Improved Dynamic Blind Voting for Internet of Things Environment

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