WO2023056967A1 - Procédé de consensus, système de chaîne de blocs et nœuds de consensus - Google Patents

Procédé de consensus, système de chaîne de blocs et nœuds de consensus Download PDF

Info

Publication number
WO2023056967A1
WO2023056967A1 PCT/CN2022/124074 CN2022124074W WO2023056967A1 WO 2023056967 A1 WO2023056967 A1 WO 2023056967A1 CN 2022124074 W CN2022124074 W CN 2022124074W WO 2023056967 A1 WO2023056967 A1 WO 2023056967A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
consensus
node
data block
nodes
Prior art date
Application number
PCT/CN2022/124074
Other languages
English (en)
Chinese (zh)
Inventor
刘盛云
邓福喜
闫莺
徐文博
Original Assignee
支付宝(杭州)信息技术有限公司
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 支付宝(杭州)信息技术有限公司 filed Critical 支付宝(杭州)信息技术有限公司
Publication of WO2023056967A1 publication Critical patent/WO2023056967A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
    • G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
    • G06F11/1004—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's to protect a block of data words, e.g. CRC or checksum
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1469—Backup restoration techniques

Definitions

  • the embodiments of this specification belong to the field of blockchain technology, and in particular relate to a consensus method, a blockchain system, and consensus nodes.
  • Blockchain is a new application model of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm.
  • the data blocks are combined into a chained data structure in a sequentially connected manner in chronological order, and a non-tamperable and unforgeable distributed ledger is cryptographically guaranteed. Due to the characteristics of decentralization, non-tamperable information, and autonomy, the blockchain has also received more and more attention and application.
  • the purpose of the present invention is to provide a consensus method, blockchain system and consensus nodes, including: a consensus method in the blockchain system, including: the first round: the first consensus node uses the transaction set proposed by the consensus to correct Code deletion generates multiple data blocks; the first consensus node retains a copy of the data block, and sends the first message to other consensus nodes, and the first message sent to different consensus nodes includes different data blocks and the first consensus node
  • the second round the consensus node broadcasts the second message, the second message includes the data block, and includes the vote and signature on the transaction set; the vote includes the summary value of the transaction set;
  • the first consensus The data block broadcast by the node includes the reserved data block, and other consensus nodes broadcast the data block received in the first round; the third round: the other consensus nodes use the erasure code to restore the data block based on the received data block.
  • a blockchain system including consensus nodes, wherein: the first consensus node uses erasure codes to generate multiple data blocks from the transaction set proposed by the consensus; the first consensus node retains a copy of the data block, and sends the first message to other The consensus node, the first message sent to different consensus nodes includes different data blocks and the signature of the first consensus node; the consensus node broadcasts the second message, the second message includes the data block, and includes the transaction set vote and signature; the vote includes the summary value of the transaction set; the data block broadcast by the first consensus node includes the reserved data block, and other consensus nodes broadcast the data block received in the first round; the Other consensus nodes use the erasure code to restore the transaction set based on the received data block, and after collecting at least Quorum unanimous votes from different consensus nodes, broadcast a third message, the third message includes data block, the digest value and the collected signature set; after the other consensus nodes have collected at least Quorum third messages from different nodes, output the transaction set corresponding to the digest value as at least part of the consensus
  • a consensus node in a blockchain system comprising: a data block generation unit, used to generate multiple data blocks using erasure codes for a transaction set proposed by the consensus, and retain a copy of the data blocks; a first message broadcast unit, using When broadcasting the first message to other consensus nodes, the first messages sent to different consensus nodes include different data blocks and signatures of the first consensus node; the second message broadcast unit is used to broadcast the second message to other consensus nodes The node, the second message includes the reserved data block, and includes the signature of the first consensus node; the second message receiving unit is used to receive the second message, and the second message includes the vote and signature for the transaction set The vote includes the summary value of the transaction set; the third message broadcast unit broadcasts a third message when the second message receiving unit collects at least Quorum unanimous votes from different consensus nodes, and the third message includes all The collected signature collection; the third message collection unit, used to collect the third message from different consensus nodes; the output unit, after the third message collection unit collects at least Quorum third messages from different no
  • a consensus node in a blockchain system comprising: a first message receiving unit, configured to receive a first message broadcast by the first consensus node, the first message including a data block of a proposed transaction set and the first consensus node signature; the second message broadcasting unit is used to broadcast a second message when the first message receiving unit receives the first message, and the second message includes the data block, the vote and the signature on the transaction set; The vote includes a summary value of the transaction set; the second message receiving unit is configured to receive a second message, the second message includes a data block, and includes a vote and a signature on the transaction set; the vote includes the The summary value of the transaction set; the third message broadcasting unit, when the second message receiving unit collects at least Quorum unanimous votes from different consensus nodes, broadcasts a third message, the third message includes the summary value and the collected The signature set received; the third message collection unit collects the third message from different consensus nodes; the recovery unit uses the erasure code to restore the transaction set based on the data block received by the second message receiving
  • the erasure code is used to generate several data blocks for the transaction proposed by the consensus, and the proposed consensus node does not need to transmit larger data packets to other Instead, different data blocks of the data packet are transmitted to different consensus nodes, which can reduce the amount of data transmitted by the network. Forwarding the data blocks sent by the proposed consensus nodes in the second round can make full use of the bandwidth resources between nodes in the network, thereby improving the performance of the consensus protocol as a whole.
  • Fig. 1 is a schematic diagram of a conventional stage of a practical Byzantine fault-tolerant algorithm in an embodiment
  • Fig. 2 is a schematic diagram of the view switching stage of the practical Byzantine fault-tolerant algorithm in an embodiment
  • Fig. 3 is a schematic diagram of the honey badger Byzantine fault-tolerant algorithm in an embodiment
  • Fig. 4 is a flowchart of the consensus algorithm in an embodiment of this specification.
  • Fig. 5 is a schematic diagram of a consensus algorithm in an embodiment of this specification.
  • Fig. 6 is a schematic diagram of a consensus algorithm in an embodiment of this specification.
  • Fig. 7 is a schematic diagram of a consensus algorithm in an embodiment of this specification.
  • Fig. 8 is a schematic diagram of a consensus algorithm in an embodiment of this specification.
  • Fig. 9 is a schematic diagram of a consensus algorithm in an embodiment of this specification.
  • FIG. 10 is an architecture diagram of a consensus node in an embodiment of this specification.
  • Fig. 11 is an architecture diagram of a consensus node in an embodiment of this specification.
  • Fig. 12 is a schematic diagram of an erasure code in an embodiment of this specification.
  • Fig. 13 is a schematic diagram of Merkle Tree in an embodiment of this specification.
  • Fig. 14 is a schematic diagram of Merkle Tree in an embodiment of this specification.
  • nodes In the blockchain system, different participants can establish a distributed blockchain network through the deployed nodes (Nodes).
  • Nodes A decentralized (or multi-centered) distributed ledger constructed using a chained block structure is stored on each node (or most nodes, such as consensus nodes) in the distributed blockchain network.
  • Such a blockchain system needs to solve the problem of the consistency and correctness of the respective ledger data on multiple decentralized (or multi-centered) nodes.
  • Each node runs a blockchain program. Under the design of certain fault-tolerant requirements, the consensus mechanism is used to ensure that all loyal nodes have the same transaction, so as to ensure that all loyal nodes have the same execution results for the same transaction, and will Transactions and execution results are packaged to generate blocks.
  • the current mainstream consensus mechanisms include: Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), Practical Byzantine Fault Tolerance (PBFT) ) algorithm, Honey Badger Byzantine Fault Tolerance (HoneyBadgerBFT) algorithm, etc.
  • POW Proof of Work
  • POS Proof of Stake
  • DPOS Delegated Proof of Stake
  • PBFT Practical Byzantine Fault Tolerance
  • HoneyBadgerBFT Honey Badger Byzantine Fault Tolerance
  • the algorithm assumes that when at most f replicas (ie, nodes) fail, if there are at least 3f+1 replicas in total, security and liveness can be guaranteed to be provided in an asynchronous system.
  • a set of a certain number of copies required to ensure the data consistency and fault tolerance requirements of all copies is generally a collection of most nodes in a distributed system, forming a majority (Quorum).
  • the Quorum is 2f+1. In this way, for a distributed system containing four nodes, any three nodes can form a Quorum.
  • PBFT includes two processes, Normal Case Phase and View Change Phase.
  • Figure 1 is a flow chart of the Normal Case Phase (normal phase) process.
  • the Normal Case Phase mainly includes three phases: PRE-PREPARE (pre-preparation), PREPARE (preparation) and COMMIT (commitment).
  • node 3 can represent a downtime node (indicated by ⁇ in Figure 1), for example.
  • FIG. 2 is a schematic diagram of View Change Phase (view switching). If the master node goes offline or does evil and does not broadcast the client's request, etc., the client can set a timeout mechanism. If it times out, the client can broadcast the request message to all replica nodes.
  • the replica node After the replica node detects that the master node is malicious or goes offline, it can also initiate the View Change protocol phase to replace the master node (often referred to as "master change").
  • master change the three-stage consensus process of PRE-PREPARE, PREPARE and COMMIT may fail due to the wrong proposal initiated by the master node, or the PREPARE and COMMIT stages may not reach the number of Quorum (such as 2f+1 of 3f+1 nodes, Also known as the quorum), the consensus cannot be completed. In these cases it is also possible to initiate the View Change protocol phase to replace the master node.
  • the PBFT protocol is a partial synchronous protocol, which is characterized by assuming that the network is asynchronous at the beginning, but it can be synchronized from a certain moment. To allow different nodes to reach a consensus on the same proposal in the network, the easiest way is to set up a master node, and the master node will unify the opinions of each node. By setting the timer, you can prevent the master node from making mistakes. In PBFT, if the Normal Case Phase is not completed within a limited time, Backups will be triggered to initiate the View Change Phase to replace the primary node. PBFT fixes the master node in one position, and all requests can be sent to the master node first, and then broadcast to other consensus nodes by the master node.
  • the HoneyBadgerBFT also often abbreviated as HBBFT
  • HBBFT asynchronous (asynchronous) protocol.
  • Asynchronous protocols are suitable for asynchronous networks, that is, messages between nodes in this network can be delayed arbitrarily, but will eventually arrive. The timer is removed from HoneyBadgerBFT, and the execution of the protocol is driven by messages.
  • all nodes in the HoneyBadgerBFT algorithm are equal, there is no distinction between master nodes and backup nodes, and there is no process of changing masters.
  • Asynchronous network consensus protocols such as HBBFT have no concept of master nodes. Each node can propose a request and try to construct a block. Therefore, asynchronous network protocols alleviate the problems of fairness and single-node bottlenecks to a certain extent.
  • FIG 3 is a flow chart of the single node angle of the HoneyBadgerBFT algorithm.
  • all nodes in the HoneyBadgerBFT algorithm are peers, that is, all nodes can execute the process shown in Figure 3.
  • HoneyBadgerBFT mainly includes two stages, namely Reliable Broadcast (RBC) and Asynchronous Binary Agreement (ABA, asynchronous binary agreement, also known as "01 Asynchronous consensus").
  • RBC Reliable Broadcast
  • ABA Asynchronous Binary Agreement
  • the RBC phase includes at least three rounds of message interaction of Rval, Echo, and Ready
  • the ABA phase includes at least three rounds of message interaction of Bval, Aux, and Coin.
  • RBC uses three rounds of message exchanges to ensure reliable proposal broadcasting.
  • ABA first conducts two rounds of voting (Bval and AUX messages), and then uses Coin toss (Coin) to unify the proposals of each node, thereby bypassing the network synchronization requirements of the semi-synchronous protocol.
  • a HoneyBadgerBFT consensus must go through the RBC phase and at least one ABA phase. In the best case, there is a probability of 1/2 that the HoneyBadgerBFT consensus process can be ended. In this way, it takes 6 rounds to complete a consensus. In addition, there is a 1/4 probability that it will enter the ABA process again, as shown in Figure 3 for the second ABA process (the ABA process represented by rounds 7, 8, and 9), and there is a 1/4 probability that it will end in the second round.
  • HoneyBadgerBFT includes at least one RBC (three rounds) and one ABA (three rounds). If the ABA voting result is inconsistent with the coin toss result, the protocol enters a new round of ABA (at least three additional rounds). Tossing coins brings uncertainty to the rounds of consensus and may increase delays.
  • This application provides an embodiment of a consensus algorithm, as shown in Figure 4, which specifically includes: S41: [First round]
  • the first consensus node uses erasure codes to generate multiple data blocks from the transaction set proposed by the consensus; the first consensus node A copy of the data block is reserved, and a first message is sent to other consensus nodes.
  • the first messages sent to different consensus nodes include different data blocks and signatures of the first consensus node.
  • a consensus algorithm in this application may include 3 rounds of interaction. Similar to HBBFT, the consensus algorithm of the embodiment shown in Figure 5 is also an asynchronous protocol, that is, it is assumed that messages between nodes in the network can be delayed arbitrarily, but will eventually arrive. Similarly, the timer is also removed in the embodiment in Figure 5, and the execution of the protocol is driven by messages; at the same time, all nodes can be peer-to-peer, there is no distinction between the master node and the backup node, and any consensus node can initiate consensus Proposals, each consensus node can also participate in the consensus process where other nodes propose consensus proposals. The result of a consensus can include the sum of the transaction sets in the consensus proposal proposed by all nodes in this consensus and obtained at least the same number of Quorum votes.
  • Node 0 can initiate a consensus proposal, which can include a packaged transaction set, for example, marked as m 0 , m 0 can include a series of transaction sets ⁇ tx 01 , tx 02 ,..., tx 0n ⁇ . Furthermore, Node 0 can generate multiple data blocks by adopting erasure coding (Erasure Coding) for the transaction set m 0 proposed by the consensus. Generally, the number n of data blocks generated using erasure codes can be equal to the total number of consensus nodes.
  • Erasure Coding Erasure Coding
  • Node 0 uses erasure codes on m 0 to generate 4 data blocks (data blocks), namely m 00 , m 01 , m 02 , and m 03 .
  • data blocks data blocks
  • they can have corresponding hash values respectively, for example, the hash value corresponding to m 00 is hash 000
  • the corresponding hash value of m 01 is hash 001
  • the corresponding hash value of m 02 is hash 002
  • the corresponding hash value is hash 003 , as shown in Figure 12.
  • Erasure code is a coding error-tolerant technology, which was first used for data recovery in data transmission in the communication industry.
  • each split data is associated. In the case of a certain range of data errors, it can be recovered through erasure code technology.
  • Data m can be generated into N data blocks through EC.
  • the N data blocks generally include p data blocks after data m is split, and q data blocks for storing erasure codes are also added. In this way, the original data m can be restored through any p pieces of data in the p+q pieces.
  • Node 0 can also build a Merkle Tree (Merkle tree, usually also called a Hash Tree) for the generated data block.
  • Merkle tree Merkle tree, usually also called a Hash Tree
  • the hash values of the four data blocks m 00 , m 01 , m 02 , and m 03 are respectively hash 000 , hash 001 , hash 002 , and hash 003 .
  • To construct the hash values in pairs hash 00 , hash 01 can be obtained . .
  • hash 00 can be obtained by sequentially splicing hash 000 and hash 001 and calculating hash
  • hash 01 can be obtained by sequentially splicing hash 002 and hash 003 and calculating hash.
  • hash 00 and hash 01 can be sequentially concatenated to calculate hash, thereby obtaining hash 0 .
  • Node 0 can generate a corresponding merkle proof (Merkle proof).
  • Merkle proof For example, for m 01 , the generated Merkle proof includes hash 000 , hash 01 , hash 0 ; for m 02 , the generated Merkle proof includes hash 003 , hash 00 , hash 0 ; for m 03 , the generated Merkle proof The proof includes hash 002 , hash 00 , and hash 0 . It can be seen that the Merkle proof is an ordered set of hash values. Through such an ordered set, the hash value of the root node of the Merkle tree can be calculated.
  • the first consensus node sends the first message to other consensus nodes, which are the remaining consensus nodes in the blockchain system that are different from the first consensus node, and the first messages sent to different consensus nodes include different data block, the corresponding Merkle proof.
  • the first consensus node Node 0 can send the first message Val message to Node 1 , the Val message can include the data block m 01 , and include the Merkel proof hash 000 , hash 01 , and hash 0 corresponding to the data block.
  • Node 0 may send a first message Val message to Node 2 , the Val message may include data block m 02 , and include Merkle certificates hash 003 , hash 00 , and hash 0 corresponding to the data block.
  • Node 0 may send a first Val message to Node 3 , and the Val message may include a data block m 03 , and include the Merkle certificates hash 002 , hash 00 , and hash 0 corresponding to the data block. As shown in Figure 5.
  • the first consensus node may reserve a copy of the data block, for example, the above-mentioned data block m 00 .
  • Val message sent by Node 0 to Node 1 may also include the signature of Node 0 , for example, marked as sig 00 .
  • Node 0 can use its own private key to sign the payload (payload) part of the message.
  • sign m 01 and its corresponding Merkle certificate to obtain sig 00 .
  • Node 0 may firstly perform hash calculation on the payload (payload) part of the message to obtain a hash value (that is, a digest value), and then sign the hash value with its own private key to obtain sig 00 .
  • the Val message sent by Node 0 to other Nodes is similar and will not be repeated here.
  • the format of the Val message can be ⁇ r, m 01 , the Merkel proof corresponding to m 01 , sig 00 >, where r can represent the rth consensus.
  • the consensus proposal for m 0 here is the rth consensus
  • the transaction set m 1 of the next consensus proposal can correspond to the r+1th consensus.
  • the sig 00 may also be a signature of the data including r and m 01 and their corresponding Merkle certificates using its own private key.
  • S43 [Second round]
  • the consensus node broadcasts a second message, the second message includes a data block, and includes the vote and signature of the transaction set; the vote includes the digest value of the transaction set m 0 .
  • the consensus nodes that received the first message can verify the correctness of the received first message.
  • Node 1 may use the public key of Node 0 to verify the signature of Node 0 in the first message.
  • the first message may further include a Merkle certificate corresponding to the received data block.
  • the consensus node that received the first message can also verify the data block in the received first message and the corresponding Merkle proof.
  • the consensus node that receives the Val message can calculate the hash value of the consensus-proposed data block in the Val message.
  • Node 1 After Node 1 receives the Val message sent by the first consensus node Node 0 , it can calculate the hash value of the data block m 01 included in the Val message, for example, hash 001 .
  • the received Val message also includes the merkle proof corresponding to the contained data block.
  • Node 1 receives the Val message sent by the first consensus node Node 0 , which also includes the Merkel proof hash 000 , hash 01 , and hash 0 corresponding to data block m 01 .
  • the consensus node that receives the Val message can verify the correctness of the data through the Merkle proof contained in the Val message.
  • Node 1 After Node 1 obtains the hash value hash 001 of m 01 in the Val message through the aforementioned calculation, it further calculates together with the Merkel proof in the Val message, including calculating hash 000 and hash 001 to obtain hash' 00 , and then by Hash' 00 and hash 01 are calculated to obtain hash' 0 , so whether m 01 is correct is determined by comparing whether hash' 0 and hash 0 are consistent. This is because, generally speaking, the probability of a hash collision is extremely low, and it is difficult for the initiator of the message to forge a series of hash values while maintaining the corresponding relationship between these hash values and data blocks. Therefore, if the comparison between hash' 0 and hash 0 is consistent, subsequent processing can be performed; if not, the received Val message is not approved, that is, the data block contained therein is not approved.
  • the consensus node broadcasts the second message, and the second message includes the data block.
  • the data blocks broadcast by the first consensus node may include the reserved data blocks, and other consensus nodes may broadcast the data blocks received in the first round.
  • the data block broadcast by the first consensus node may include the reserved data block, for example, Node 0 broadcasts the data block m 00 reserved in the first round.
  • Other consensus nodes can broadcast the data blocks received in the first round.
  • Node 1 , Node 2 , and Node 3 can each broadcast the second message to other consensus nodes, such as Node 1 Broadcast the data block m 01 received in the first round, Node 2 broadcasts the data block m 02 received in the first round, and Node 3 broadcasts the data block m 03 received in the first round.
  • This broadcasted second message may be denoted as Bval.
  • Node 1 , Node 2 , and Node 3 can tell other consensus nodes to vote on the consensus proposal initiated by Node 0 by broadcasting the second message, and the vote can be to express approval or disapproval of the consensus proposal. If the consensus node approves the transaction set proposed by Node 0 in this consensus, it can broadcast the hash value of the transaction set in the second round of message interaction, such as hash 0 above. On the contrary, if the consensus node does not approve the transaction set proposed by Node 0 in this consensus, it can broadcast 0 in the second round of message interaction.
  • Node 0 does not need to broadcast votes, because Node 0 initiates a consensus proposal in the first round, which itself can represent Node 0’s approval of the message set in the consensus proposal.
  • Node 0 can also broadcast votes in the second round, such as broadcasting the hash value of the transaction set, such as hash 0 above.
  • the second message broadcast by the consensus node may also include the Merkle certificate corresponding to the broadcast data block.
  • the first consensus node if the first consensus node generates a corresponding Merkel proof for each data block, and sends the Merkle proof together with the data block in the first message, in the first round
  • the consensus node that received the first message can receive the data block and the Merkle proof corresponding to the data block.
  • the second message broadcast by Node 1 , Node 2 , and Node 3 may also include the Merkle certificate corresponding to the data block.
  • the first consensus node generates a corresponding Merkel proof for the broadcast data block, and sends the Merkle proof together with the data block in the second message.
  • the second message may also include a signature on the set of transactions.
  • the consensus node that receives the first message at the end of the first round can verify the correctness of the received first message, for example, Node 1 verifies whether the signature of Node 0 is correct.
  • the format of the Bval message can be such as ⁇ r, m 01 , the Merkel proof corresponding to m 01 , hash 0 , sig 10 >, where r can represent the rth consensus, and hash 0 is the hash value of m 0 , which means Voting opinion for m 0 is yes.
  • the sig 10 may also be the signature of data including r, m 01 , the Merkel certificate corresponding to m 01 and hash 0 by using its own private key.
  • sig 10 is obtained.
  • Node 2 can similarly verify whether the signature of Node 0 is correct, and verify the received data block m 02 and the corresponding Merkle proof. If the verification is correct, Node 2 can use its own private key to sign hash 0 in the first message it receives, or use its own private key to sign data including r and hash 0 , thereby obtaining sig 20 , and then It is also possible to broadcast Bval messages.
  • the Bval message can include r, m 02 , the Merkle proof corresponding to m 02 , hash 0 and signature sig 20 .
  • Node 3 can similarly verify whether the signature of Node 0 is correct. If the verification is correct, Node 3 can use its own private key to sign the hash 0 data block m 03 in the first message it receives, or use its own private key to sign the data including r and hash 0 , so as to obtain sig 30 , and then Bval messages can also be broadcast.
  • the Bval message can include r, m 03 , the Merkle proof corresponding to m 03 , hash 0 and signature sig 30 .
  • Node 0 can also use its own private key to sign hash 0 , or use its own private key to sign the data including r, m 00 , the Merkle certificate corresponding to m 00 , and hash 0 , so that Get sig 20 , and then broadcast the Bval message.
  • the Bval message can include r, m 00 , the Merkle proof corresponding to m 00 , hash 0 , and signature sig 00 .
  • S45 [Third round] Other consensus nodes use the erasure code to restore the transaction set based on the received data blocks, and after collecting at least Quorum consistent digest values from different consensus nodes, broadcast the first Three messages, the third message includes the digest value and the collected signature.
  • the consensus nodes that receive the Bval message can collect the data blocks in the Bval message.
  • a data block m 00 of the transaction set m 0 sent by Node 0 is received from the second round of Bval messages, and a data block of the transaction set m 0 sent by Node 2 is received from the second round of Bval messages Block m 02 , a data block m 03 of the transaction set m 0 sent by Node 3 is received from the third round of Bval messages.
  • Node 1 also receives m 01 from Node 0 through the first round of Val messages.
  • Node 1 According to the settings of p and q in the erasure code as mentioned above (generally q is at least 1, and by the end of the third round, Node 1 should receive at least p different data blocks), Node 1 has relatively With a high probability, m 0 can be decoded from m 00 , m 01 , m 02 , and m 03 , so that the complete proposed transaction set of Node 0 can be recovered.
  • Node 2 a data block m 00 of the transaction set m 0 sent by Node 0 is received from the second round of Bval messages, and the transaction set m 0 sent by Node 1 is received from the second round of Bval messages Receive a data block m 01 of the transaction set m 03 sent by Node 3 from the third round of Bval message.
  • Node 2 also receives the m 02 sent by Node 0 .
  • Node 2 has a high probability of being able to decode m 0 from m 00 , m 01 , m 02 , and m 03 , so that the complete Node 0 can be recovered
  • the set of proposed transactions The set of proposed transactions.
  • Node 3 a data block m 00 of the transaction set m 0 sent by Node 0 is received from the second round of Bval messages, and the transaction set m 0 sent by Node 1 is received from the second round of Bval messages Receive a data block m 01 of the transaction set m 02 sent by Node 2 from the second round of Bval messages. Through the first round of Val messages, Node 3 also receives the m 03 sent by Node 0 .
  • Node 3 has a high probability of being able to decode m 0 from m 00 , m 01 , m 02 , and m 03 , so that the complete Node 0 can be recovered
  • the set of proposed transactions The set of proposed transactions.
  • Node 0 itself has data block m 00 , and can receive a data block m 01 of the transaction set m 0 sent by Node 1 from the second round of Bval messages, and receive a data block m 01 from Node 2 in the second round of Bval messages
  • a data block m 02 of the transaction set m 0 of the transaction set m 0 receives a data block m 03 of the transaction set m 0 sent by Node 3 from the Bval message of the third round.
  • Node 0 has a high probability to decode m 0 from these m 00 , m 01 , m 02 , and m 03 , so as to recover and obtain the complete proposed transaction set of Node 0 .
  • Node 0 as the consensus node that initiates the consensus proposal, has its own transaction set, so it is not necessary to restore the transaction set based on the second round of Bval messages, thereby saving the work of decoding.
  • the second message broadcast by the consensus node may include the Merkle proof corresponding to the data block.
  • the third message broadcast by the consensus node may also include the Merkle proof corresponding to the data block.
  • the consensus node receiving the data block can also combine the corresponding Merkle proof for verification.
  • the original data can be recovered after passing the verification, that is, m 0 can be obtained from the aforementioned decoding, and the complete proposed transaction set of Node 0 can be recovered from it.
  • the consensus node that receives the Bval message can calculate the hash value of the data block in the Bval message.
  • Node 1 After Node 1 receives the Bval message sent by the first consensus node Node 0 , it can calculate the hash value of the data block m 00 included in the Bval message, for example, hash 000 .
  • the Bval message sent by Node 1 may also include the merkle proof corresponding to the included data block m 00 , such as hash 001 , hahh 01 , and hash 0 .
  • Node 1 After Node 1 obtains the hash value hash 000 of m 00 in the Prom message through the aforementioned calculation, it further calculates together with the Merkle proof, including calculating hash 000 and hash 001 to obtain hash' 00 , and then combining hash' 00 and Hash 01 is calculated to get hash' 0 , so whether m 01 is correct is determined by comparing whether hash' 0 is consistent with hash 0 .
  • the consensus nodes in the second round broadcast the second message Bval message, so that at the end of the second round, the consensus nodes that received the second message can collect the data blocks in the second message and votes on the consensus proposal.
  • Node 1 can collect the votes in the Bval message at the end of the second round, assuming that the votes collected by Node 1 in the second message broadcast by Node 2 and Node 3 are the hash value hash 0 of the transaction set m 0 , and if the vote in the second message broadcast by Node 1 in the second round is also the hash value hash 0 of the transaction set m 0 (also means the approval of the transaction set), and received in the first round
  • Node 2 and Node 3 are similar to Node 1 and will not be repeated here.
  • the consensus node can also collect the signatures of different nodes at the end of the second round, as mentioned earlier.
  • the number of votes collected up to the second round can be counted by signing.
  • Node 1 collects sig 00 , sig 10 (the Bval message broadcast by Node 1 in the second round contains the vote of Node 1 , and the signature is also collected), sig 20 , and sig 30 signatures include the same hash value , it means that there are 4 votes for approval of the hash (sig 00 can be received in the Val message sent from Node 0 in the first round, or it can be received in the Bval message sent from Node 0 in the second round If the above two cases are not counted repeatedly, then a total of 4 signatures are collected for the same hash value).
  • the third message is broadcast.
  • the third message can be recorded as a Prom message, which means that it promises not to change its opinion on the proposal m 0 .
  • the hash value of m 0 can indicate approval, and 0 can indicate disapproval.
  • Node 2 and Node 3 are also similar.
  • the third broadcast message may include the collected votes for m 0 , such as the hash values and signatures collected in the first and second rounds above.
  • the format of the Prom message can be such as ⁇ r,hash 0 , ⁇ signature collection>>.
  • Node 0 assuming that Node 0 collects Node 1 in the second round, and the votes in the Bval messages broadcast by Node 2 and Node 3 respectively are all hash values of the transaction set m 0 , so that Node 1 .
  • the signatures of Node 2 and Node 3 on m 0 are votes of sig 10 , sig 20 , and sig 30 respectively, and the Val message broadcast by Node 0 in the first round also includes its own vote for m 0
  • the signature of 0 (or the hash value of m 0 ) is the hash value of sig 00 .
  • the Prom message broadcast by Node 0 in the third round may include the hash value and the collected hash value and signature set that different nodes express approval for the proposed transaction set m 0 .
  • the signature set is, for example, sig 00 , sig 10 , sig 20 , sig 30 .
  • Node 1 collects the votes in the Bval messages broadcast by Node 0 , Node 2 , and Node 3 in the second round, all of which are the hash values of the transaction set m 0 , so that Node 0 , Node 2 and Node 3's respective signatures on m 0 (or the hash value of m 0 ) are votes of sig 00 , sig 20 , and sig 30 (or Node 0 includes its signature on m 0 (or m 0 ) in the Bval message broadcast in the first round.
  • the signature of the hash value of m 0 ) is the vote of sig 00
  • the Bval message broadcast by Node 1 in the second round also includes the vote that the signature of m 0 (or the hash value of m 0 ) is sig 10 .
  • the Prom message broadcast by Node 1 in the third round may include the hash value and the collected hash value and signature set that different nodes approve of the proposed transaction set m 0
  • the signature set includes, for example, sig 00 , sig 10 , sig 20 , sig 30 .
  • Node 2 and Node 3 are also similar to Node 1 .
  • the above signature set can also be replaced by an aggregate signature or a threshold signature.
  • consensus nodes that have received Prom messages can count the number of collected Prom messages.
  • the condition for the consensus node to send the Prom message in the third round is that at least Quorum unanimous votes from different consensus nodes have been collected in the second round, and it has not broadcast different votes for the proposal, which is equivalent to the second round
  • the consensus node confirms that a total of at least Quorum number of consensus nodes (including itself) votes for the proposal m 0 .
  • Node 0 collects at least Quorum consistent digest values in the second round, and then, the Prom message broadcast by Node 0 in the third round can include the hash value and the collection of transactions collected by different nodes for the proposal m 0 represents an approved hash value and signature set, for example, the signature set includes sig 00 , sig 10 , sig 20 , and sig 30 .
  • Node 1 collects at least Quorum consistent summary values in the second round, and then, the Prom message broadcast by Node 1 in the third round can include the hash value and the collection of transactions collected by different nodes for the proposal m 0 represents an approved hash value and signature set, for example, the signature set includes sig 00 , sig 10 , sig 20 , and sig 30 .
  • Node 2 and Nide 3 are also similar to Node 1 .
  • Node 0 can collect at least Quorum Prom messages. Through Quorum Prom messages, Node 0 can confirm that each of at least Quorum consensus nodes has collected at least Quorum number of votes to approve the proposed transaction set m 0 , and each consensus node that sends Prom messages commits to The point of view of voting will not be changed, so that Node 0 can further complete this consensus, that is, output the transaction set m 0 corresponding to the summary value as at least a part of the consensus result. Node 1 , Node 2 and Node 3 are also similar. Similarly, other consensus nodes such as Node 1 , Node 2 , and Node 3 can further complete this consensus, that is, output the transaction set m 0 corresponding to the digest value as at least a part of the consensus result.
  • the third round of Prom messages can add signatures.
  • the Prom message broadcast by Node 1 in the third round may include Node 1's signature of ⁇ r, hash, ⁇ signature set>> in the Prom message.
  • the number of bottom leaf nodes is 2n .
  • the number of data blocks generated by using erasure coding is not necessarily 2 n .
  • the hash of the last data block can be repeated several times to complete the 2 n leaf nodes of the Merkle Tree.
  • Node 0 uses the erasure code to generate 5 data blocks m 00 , m from the transaction set m 0 proposed by the consensus 01 , m 02 , m 03 , m 04 , and the constructed Merkle Tree can be shown in Figure 14.
  • the hash value corresponding to m 00 is hash 0000
  • the corresponding hash value to m 01 is hash 0001
  • the corresponding hash value to m 02 is hash 0002
  • the hash value corresponding to m 03 is hash 0003
  • the corresponding hash value to m 04 is hash 0004 .
  • the extra 3 leaf nodes of the Merkle Tree can take the hash value corresponding to the last data block. As shown in the figure, hash 0005 , hash 0006 and hash 0007 may all take the hash value of m 04 . In this way, Merkle Tree and Merkle proof can also be constructed.
  • FIG. 5 can be executed by Node 0 in the figure, and can also be extended to be executed by Node 0 , Node 1 , Node 2 and Node 3 .
  • every consensus node that collects at least Quorum third messages from different nodes can output the transaction set corresponding to the summary value as the entire consensus result, except for Figure 5
  • any one of Figs. 6, 7, 8, and 9 may be used.
  • Figure 5 is from the perspective of Node 0 , which initiates a consensus proposal.
  • Node 1 , Node 2 , and Node 3 Any one can also initiate a proposal, and other consensus nodes cooperate to complete the above-mentioned similar process, so that the whole is the superposition of Figures 5, 6, 7, 8, and 9.
  • the transaction set of Node 0 initiating the consensus proposal is m 0
  • the transaction set of Node 1 initiating the consensus proposal is m 1
  • the transaction set of Node 2 initiating the consensus proposal is m 2
  • the transaction set of Node 3 initiating the consensus proposal The set is m 3 , so m 0 can correspond to hash 0
  • m 1 can correspond to hash 1
  • m 2 can correspond to hash 2
  • m 3 can correspond to hash 3 .
  • the consensus output of each consensus node is ⁇ m 0 , m 1 , m 2 , m 3 ⁇ with high probability.
  • the order of m 0 , m 1 , m 2 , m 3 in the output results It can be sorted according to certain rules, for example, sorted according to the size order of the corresponding hash values.
  • the delay caused by the consensus process is greatly reduced.
  • it is equivalent to combining the last two rounds of the RBC process and the first two rounds of the ABA process in the HBBFT by using the forward-looking voting and digital signature technology, thereby shortening the required rounds.
  • the forward-looking voting refers to voting in the second round of Bval in the above embodiment, while HBBFT needs to vote in the fifth round of 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 embodiment.
  • the proposed consensus node does not need to transmit a larger data packet to each other consensus node, but transmits different data blocks of the data packet to different consensus nodes. nodes, which can reduce the amount of data transmitted by the network. Forwarding the data blocks sent by the proposed consensus nodes in the second round can make full use of the bandwidth resources between nodes in the network, thereby improving the performance of the consensus protocol as a whole.
  • the present application also provides an embodiment of a blockchain system, including consensus nodes, wherein: the first consensus node uses erasure codes to generate multiple data blocks from the transaction set proposed by the consensus; the first consensus node retains a copy of the data block, and Sending the first message to other consensus nodes, the first message sent to different consensus nodes includes different data blocks and the signature of the first consensus node; the consensus node broadcasts the second message, the second message includes the data block, and Including votes and signatures on the set of transactions; the vote includes the summary value of the set of transactions; the data block broadcast by the first consensus node includes the reserved data block, and other consensus nodes broadcast the received data in the first round data block; other consensus nodes use the erasure code to restore the transaction set based on the received data block, and after collecting at least Quorum unanimous votes from different consensus nodes, broadcast the third message, the first The three messages include the data block, the digest value and the collected signature set; after the other consensus nodes collect at least Quorum third messages from different nodes, the transaction
  • the first consensus node uses the erasure code to generate n data blocks from the transaction set proposed by the consensus, and the n is equal to the total number of consensus nodes.
  • the first consensus node generates a corresponding Merkel certificate for each data block, and the first message sent also includes the Merkel certificate; correspondingly, at the end of the first round, receiving The consensus node that received the first message also verifies the received data block and the Merkle proof; after passing the verification, it enters the second round.
  • the broadcasted second message or the third message further includes the Merkle certificate corresponding to the broadcasted data block.
  • the consensus node that received the second message also verifies the Merkle proof in the second message.
  • the consensus node that received the third message also verifies the received data block and the corresponding Merkle certificate; after the verification is passed, it enters the process of restoring the transaction set using erasure codes.
  • the correctness of the third message is also verified, including verifying that the signature set of the third message includes at least Quorum signatures.
  • each of at least Quorum number of consensus nodes in the blockchain system serves as the first consensus node.
  • the present application also provides an embodiment of a consensus node in a blockchain system, which may also be shown in Figure 10, including: a data block generation unit 101, which is used to generate multiple data blocks using an erasure code for the transaction set proposed by the consensus , and retain a data block; the first message broadcast unit 102 is used to broadcast the first message to other consensus nodes, and the first message sent to different consensus nodes includes different data blocks and the signature of the first consensus node ; The second message broadcasting unit 107 is used to broadcast the second message to other consensus nodes, the second message includes the reserved data block, and includes the signature of the first consensus node; the second message receiving unit 103 is used to receive The second message, including votes and signatures to the transaction set in the second message; the vote includes the abstract value of the transaction set; the third message broadcast unit 104, when the second message receiving unit collects at least Quorum from Broadcasting a third message after unanimous voting by different consensus nodes, the third message includes the collected signature set; the third message collection unit 105 is used to collect the third
  • the data block generation unit 101 generates n data blocks using erasure codes for the transaction set proposed by the consensus, where n is equal to the total number of consensus nodes.
  • the data block generating unit 101 also generates a corresponding Merkel certificate for each data block, and the first message sent by the first message broadcasting unit also includes the Merkel certificate.
  • the broadcasted second or third message further includes the Merkle certificate corresponding to the sent data block.
  • a verification unit is further included, configured to verify the data block in the second message and the corresponding Merkle certificate after the second message receiving unit receives the second message.
  • a verification unit is further included, configured to verify the data block and the corresponding Merkle certificate after the third message collection unit receives the third message.
  • the present application also provides an embodiment of a consensus node in a blockchain system, as shown in Figure 11, including: a first message receiving unit 111, configured to receive the first message broadcast by the first consensus node, in the first message Including a data block of the proposed transaction set and the signature of the first consensus node; the second message broadcast unit 112, used to broadcast the second message after the first message receiving unit 111 receives the first message, in the second message Including votes and signatures on the transaction set; the vote includes a summary value of the transaction set; the second message receiving unit 113 is configured to receive a second message, the second message includes the vote on the transaction set and signature; the vote includes the abstract value of the transaction set; the third message broadcast unit 114, when the second message receiving unit 113 collects at least Quorum unanimous votes from different consensus nodes, broadcasts the third message, the first The three messages include the digest value and the collected signature set; the third message collection unit 115 collects the third messages from different consensus nodes; the recovery unit 116 uses the data block received by the third message collection unit
  • the first message received by the first message receiving unit 111 also includes the Merkle certificate; correspondingly, the first message receiving unit 111 also verifies the received data block and the Merkle certificate.
  • the broadcasted second message also includes the Merkel certificate corresponding to the data block;
  • the consensus node also includes a verification unit, which is used to check the second message in the second message after the second message receiving unit receives the second message The data block and the corresponding Merkle proof are verified.
  • the broadcasted third message also includes the Merkle certificate corresponding to the data block; the consensus node also includes a verification unit for verifying the data block and the corresponding The Merkle proof is verified.
  • the improvement of a technology can be clearly distinguished as an improvement in hardware (for example, improvements in circuit structures such as diodes, transistors, and switches) or improvements in software (improvement in method flow).
  • improvements in circuit structures such as diodes, transistors, and switches
  • improvements in software improvement in method flow
  • the improvement of many current method flows can be regarded as the direct improvement of the hardware circuit structure.
  • Designers almost always get the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that the improvement of a method flow cannot be realized by hardware physical modules.
  • a programmable logic device Programmable Logic Device, PLD
  • PLD Programmable Logic Device
  • FPGA Field Programmable Gate Array
  • HDL Hardware Description Language
  • ABEL Advanced Boolean Expression Language
  • AHDL Altera Hardware Description Language
  • HDCal JHDL
  • Lava Lava
  • Lola MyHDL
  • PALASM RHDL
  • VHDL Very-High-Speed Integrated Circuit Hardware Description Language
  • Verilog Verilog
  • the controller may be implemented in any suitable way, for example the controller may take the form of a microprocessor or processor and a computer readable medium storing computer readable program code (such as software or firmware) executable by the (micro)processor , logic gates, switches, application specific integrated circuits (Application Specific Integrated Circuit, ASIC), programmable logic controllers and embedded microcontrollers, examples of controllers include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the control logic of the memory.
  • controller in addition to realizing the controller in a purely computer-readable program code mode, it is entirely possible to make the controller use logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded The same function can be realized in the form of a microcontroller or the like. Therefore, such a controller can be regarded as a hardware component, and the devices included in it for realizing various functions can also be regarded as structures within the hardware component. Or even, means for realizing various functions can be regarded as a structure within both a software module realizing a method and a hardware component.
  • the systems, devices, modules, or units described in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions.
  • a typical implementation device is a server system.
  • the computer that realizes the functions of the above embodiments can 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 , media players, navigation devices, email devices, game consoles, tablet computers, wearable devices, or any combination of these devices.
  • one or more embodiments of the present specification provide the operation steps of the method described in the embodiment or the flowchart, more or fewer operation steps may be included based on conventional or non-inventive means.
  • the sequence of steps enumerated in the embodiments is only one of the execution sequences of many steps, and does not represent the only execution sequence.
  • the methods shown in the embodiments or drawings can be executed sequentially or in parallel (such as a parallel processor or multi-thread processing environment, or even a distributed data processing environment).
  • These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture comprising instruction means, the instructions
  • the device realizes the function specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.
  • a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
  • processors CPUs
  • input/output interfaces network interfaces
  • memory volatile and non-volatile memory
  • Memory may include non-permanent storage in computer-readable media, in the form of random access memory (RAM) and/or nonvolatile memory such as read-only memory (ROM) or flash RAM. Memory is an example of computer readable media.
  • RAM random access memory
  • ROM read-only memory
  • flash RAM flash random access memory
  • Computer-readable media including both permanent and non-permanent, removable and non-removable media, can be implemented by any method or technology for storage of information.
  • 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 Disc (DVD) or other optical storage, Magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission medium that can be used to store information that can be accessed by computing devices.
  • computer-readable media excludes transitory computer-readable media, such as modulated data signals and carrier waves.
  • one or more embodiments of this specification 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 employ a computer program embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein. The form of the product.
  • program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types.
  • program modules may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network.
  • program modules may be located in both local and remote computer storage media including storage devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un procédé de consensus, un système de chaîne de blocs et des nœuds de consensus. Le procédé de consensus comprend les étapes suivantes dans lesquelles : un premier nœud de consensus génère une pluralité de blocs de données en utilisant des codes d'effacement sur un ensemble de transactions de propositions de consensus ; le premier nœud de consensus envoie un premier message à d'autres nœuds de consensus ; le nœud de consensus recevant le premier message diffuse un deuxième message, le deuxième message comprenant un bloc de données, et comprenant un vote et une signature sur l'ensemble de transactions ; le vote comprend une valeur de condensé de l'ensemble de transactions ; après la collecte d'au moins un nombre de Quorum de votes cohérents en provenance de différents nœuds de consensus au moyen du nœud de consensus recevant le deuxième message, le nœud de consensus diffuse un troisième message, le troisième message comprenant un ensemble de signatures collectées ; après la collecte d'au moins un nombre de Quorum de troisièmes messages en provenance de différents nœuds au moyen des autres nœuds de consensus, l'ensemble de transactions correspondant à la valeur abstraite est délivré en tant qu'au moins une partie du résultat de consensus.
PCT/CN2022/124074 2021-10-09 2022-10-09 Procédé de consensus, système de chaîne de blocs et nœuds de consensus WO2023056967A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202111178779.2 2021-10-09
CN202111178779.2A CN113761071B (zh) 2021-10-09 2021-10-09 一种共识方法、区块链系统和共识节点

Publications (1)

Publication Number Publication Date
WO2023056967A1 true WO2023056967A1 (fr) 2023-04-13

Family

ID=78799019

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/124074 WO2023056967A1 (fr) 2021-10-09 2022-10-09 Procédé de consensus, système de chaîne de blocs et nœuds de consensus

Country Status (2)

Country Link
CN (1) CN113761071B (fr)
WO (1) WO2023056967A1 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113761071B (zh) * 2021-10-09 2023-07-11 支付宝(杭州)信息技术有限公司 一种共识方法、区块链系统和共识节点
CN114782047B (zh) * 2021-12-29 2023-06-30 张海滨 数据共识方法及分布式系统
CN115174574A (zh) * 2022-06-30 2022-10-11 蚂蚁区块链科技(上海)有限公司 区块链系统中的数据广播方法、节点和区块链系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111526219A (zh) * 2020-07-03 2020-08-11 支付宝(杭州)信息技术有限公司 一种联盟链的共识方法及联盟链系统
CN112506671A (zh) * 2021-02-03 2021-03-16 支付宝(杭州)信息技术有限公司 区块链中的交易处理方法、装置及电子设备
US20210256016A1 (en) * 2018-06-25 2021-08-19 Commonwealth Scientific And Industrial Research Organisation Blockchain system and method
CN113377798A (zh) * 2021-07-07 2021-09-10 支付宝(杭州)信息技术有限公司 一种区块链一致性处理方法、区块链节点和区块链系统
CN113761071A (zh) * 2021-10-09 2021-12-07 支付宝(杭州)信息技术有限公司 一种共识方法、区块链系统和共识节点

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107392040B (zh) * 2017-04-28 2019-08-09 阿里巴巴集团控股有限公司 一种共识验证的方法及装置
CN107341660B (zh) * 2017-05-27 2021-06-29 唐盛（北京）物联技术有限公司 一种区块链底层共识机制以及基于该共识机制的区块链系统
CN109345386B (zh) * 2018-08-31 2020-04-14 阿里巴巴集团控股有限公司 基于区块链的交易共识处理方法及装置、电子设备
CN109379397B (zh) * 2018-08-31 2019-12-06 阿里巴巴集团控股有限公司 基于区块链的交易共识处理方法及装置、电子设备
CN109359223A (zh) * 2018-09-17 2019-02-19 重庆邮电大学 基于纠删码实现的区块链账本分布式存储技术
RU2724181C1 (ru) * 2018-11-07 2020-06-22 Алибаба Груп Холдинг Лимитед Упрощение консенсуса в цепочках блоков по принципу практичной отказоустойчивости на основе византийского соглашения и синхронизации узлов
CN109871366B (zh) * 2019-01-17 2021-09-10 华东师范大学 一种基于纠删码的区块链分片存储与查询方法
CN109902091B (zh) * 2019-02-21 2021-08-10 腾讯科技（深圳）有限公司 数据区块在区块链上记录的方法、领导记账节点和介质
CN110246038A (zh) * 2019-04-26 2019-09-17 众安信息技术服务有限公司 一种区块链交易快速确认方法及系统
US11343073B2 (en) * 2019-06-18 2022-05-24 Electronics And Telecommunications Research Institute Apparatus and method for achieving distributed consensus based on decentralized byzantine fault tolerance
CN111104460B (zh) * 2019-12-02 2023-09-19 远光软件股份有限公司 一种区块链共识方法、系统、电子设备、存储介质
CN111177263A (zh) * 2019-12-27 2020-05-19 中思博安科技（北京）有限公司 一种区块链共识方法及节点
CN111327414A (zh) * 2020-01-20 2020-06-23 布比（北京）网络技术有限公司 一种区块链共识方法、系统及计算机存储介质、电子设备
CN111414373B (zh) * 2020-03-18 2023-09-19 深圳市迅雷网络技术有限公司 一种共识方法和共识系统
CN111526218B (zh) * 2020-07-03 2020-09-22 支付宝(杭州)信息技术有限公司 联盟链中的共识方法和系统
CN111522800B (zh) * 2020-07-03 2020-10-30 支付宝(杭州)信息技术有限公司 蜜獾拜占庭容错共识机制的区块链共识方法、节点及系统
CN111526217B (zh) * 2020-07-03 2020-10-09 支付宝(杭州)信息技术有限公司 一种区块链中的共识方法和系统
CN112767152B (zh) * 2021-01-18 2024-02-09 中国工商银行股份有限公司 应用于联盟链的双园区灾备系统及方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210256016A1 (en) * 2018-06-25 2021-08-19 Commonwealth Scientific And Industrial Research Organisation Blockchain system and method
CN111526219A (zh) * 2020-07-03 2020-08-11 支付宝(杭州)信息技术有限公司 一种联盟链的共识方法及联盟链系统
CN112506671A (zh) * 2021-02-03 2021-03-16 支付宝(杭州)信息技术有限公司 区块链中的交易处理方法、装置及电子设备
CN113377798A (zh) * 2021-07-07 2021-09-10 支付宝(杭州)信息技术有限公司 一种区块链一致性处理方法、区块链节点和区块链系统
CN113761071A (zh) * 2021-10-09 2021-12-07 支付宝(杭州)信息技术有限公司 一种共识方法、区块链系统和共识节点

Also Published As

Publication number Publication date
CN113761071B (zh) 2023-07-11
CN113761071A (zh) 2021-12-07

Similar Documents

Publication Publication Date Title
WO2023056974A1 (fr) Procédé consensus, système de chaîne de blocs et noeuds de consensus
WO2023056964A1 (fr) Procédé de consensus, système de chaîne de blocs et nœud de consensus
WO2023056967A1 (fr) Procédé de consensus, système de chaîne de blocs et nœuds de consensus
WO2023056958A1 (fr) Procédé de consensus, système de chaîne de blocs et nœud de consensus
CN114401150B (zh) 区块链网络中加入节点的方法和区块链系统
WO2023056966A1 (fr) Procédé de consensus, système de chaîne de blocs et nœud de consensus
WO2023056976A1 (fr) Procédé de consensus, système à chaîne de blocs et nœud de consensus
WO2023056975A1 (fr) Procédé de consensus et système de chaîne de blocs
WO2023185051A1 (fr) Procédé de génération de valeurs de départ de nombre aléatoire sur une chaîne de blocs, et système et noeud de consensus
CN118473659A (zh) 区块链上实现分布式密钥生成的方法、系统和共识节点
CN114726517A (zh) 一种区块链上产生随机数种子的方法、系统和共识节点
CN115174048A (zh) 一种共识方法、系统和共识节点
WO2024207765A1 (fr) Procédé de proposition de transaction et nœud de consensus dans un système de chaîne de blocs, et système de chaîne de blocs
CN118473658A (zh) 区块链上实现分布式密钥生成的方法、系统和共识节点
WO2024092936A1 (fr) Procédé de réalisation d'une génération de clés distribuées sur une chaîne de blocs, système et nœud
CN114640452B (zh) 启动区块链上分布式密钥生成过程的方法和系统
CN114640450B (zh) 区块链上实现重传秘密份额与确定失败节点的方法、系统
CN116032461A (zh) 一种区块链上实现分布式密钥生成的方法和节点
CN115865341A (zh) 一种区块链上实现分布式密钥生成的方法、系统和节点
CN116846912A (zh) Pbft算法中的视图切换方法、共识节点和区块链系统
CN116846906A (zh) 一种共识方法、区块链节点
CN116527694A (zh) 一种区块链系统中的共识方法和共识节点、区块链系统
CN116846907A (zh) 一种共识方法、区块链节点
CN116015621A (zh) 一种区块链上实现分布式密钥生成的方法、系统和节点
CN115174573A (zh) 区块链系统中的数据广播方法、节点和区块链系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22877981

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22877981

Country of ref document: EP

Kind code of ref document: A1