WO2020258252A1 - Procédé de consensus pour données de chaîne de blocs et dispositif associé - Google Patents

Procédé de consensus pour données de chaîne de blocs et dispositif associé Download PDF

Info

Publication number
WO2020258252A1
WO2020258252A1 PCT/CN2019/093705 CN2019093705W WO2020258252A1 WO 2020258252 A1 WO2020258252 A1 WO 2020258252A1 CN 2019093705 W CN2019093705 W CN 2019093705W WO 2020258252 A1 WO2020258252 A1 WO 2020258252A1
Authority
WO
WIPO (PCT)
Prior art keywords
signature
block
node
confirmed
voting
Prior art date
Application number
PCT/CN2019/093705
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 深圳市网心科技有限公司
Priority to PCT/CN2019/093705 priority Critical patent/WO2020258252A1/fr
Priority to CN201980059451.3A priority patent/CN112689848A/zh
Publication of WO2020258252A1 publication Critical patent/WO2020258252A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • 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

Definitions

  • This application relates to blockchain technology, and in particular to a consensus method of blockchain data and related equipment.
  • blockchain can support different consensus mechanisms.
  • the consensus mechanism is an important component of blockchain technology.
  • the goal of the blockchain consensus mechanism is to make all honest nodes maintain a consistent view of the blockchain.
  • PBFT Practical Byzantine-Fault-Tolerant
  • the consensus process is divided into three stages: pre-prepare, prepare, and commit.
  • the consensus process is as follows:
  • a proposal node (node C) is elected from the nodes of the whole network (node C, node 0, node 1, node 2, node 3), and the new block is generated by the proposal node; other nodes send the transaction sent by the client to the whole network Broadcast, the proposed node will collect multiple transactions that need to be placed in the new block from the network and store them in a list, and broadcast the list to the entire network; after receiving the transaction list, other nodes will execute these transactions according to the ranking simulation.
  • the embodiments of the present application provide a consensus method for blockchain data and related equipment to simplify the consensus process of the blockchain.
  • the first aspect of the embodiments of the present application provides a consensus method for blockchain data, which is applied to a proposal node, the proposal node is a node in a blockchain system, and the blockchain system further includes a plurality of voting nodes,
  • the method includes:
  • the aggregate signature is sent to the voting node, so that the block to be confirmed is determined to be valid when the voting node passes verification of the aggregate signature.
  • the block to be confirmed includes the transaction result, and before the receiving the signature information sent by the multiple voting nodes, the method further includes:
  • the transaction list is sent to the voting node, so that after the voting node simulates the execution of the transaction list to obtain a transaction result, the voting node generates a block to be confirmed according to the transaction result.
  • the transaction list includes historical block information
  • sending the transaction list to the voting node specifically includes:
  • the historical block information is sent to the voting node, so that the voting node matches the historical block information.
  • the method before the aggregating and generating an aggregated signature using the received multiple pieces of signature information, the method further includes:
  • the aggregating and generating an aggregate signature using the received multiple pieces of signature information includes:
  • the signature information further includes the hash value of the block header of the block to be confirmed.
  • the blockchain system includes 3F+1 nodes, the preset value includes 2F, and F is a natural number greater than zero.
  • the second aspect of the embodiments of the present application provides a consensus method for blockchain data, which is applied to voting nodes, where the voting nodes are nodes in a blockchain system, and the blockchain system further includes a proposal node.
  • Methods include:
  • the block to be confirmed includes a transaction result, and obtaining the block to be confirmed includes:
  • the transaction list includes historical block information
  • the method further includes:
  • the method further includes:
  • the blockchain system includes 3F+1 nodes, where F is a natural number greater than 0, and the verification of the aggregate signature includes:
  • the signature information further includes the hash value of the block header of the block to be confirmed.
  • the third aspect of the embodiments of the present application provides a consensus device for blockchain data.
  • the device includes a memory and a processor.
  • the memory stores a consensus program for blockchain data that can run on the processor.
  • the consensus program of the blockchain data is executed by the processor, the method described in any one of the foregoing method embodiments is implemented.
  • the device is a node of a blockchain network.
  • the fourth aspect of the embodiments of the present application provides a consensus system for blockchain data, which is applied to a proposed node.
  • the proposed node is a node in a blockchain system.
  • the blockchain system also includes a voting node.
  • the system includes:
  • the first receiving unit is configured to receive signature information respectively sent by the multiple voting nodes, where the signature information includes the signature of the block to be confirmed by the voting node;
  • a judging unit for judging whether the quantity of the received signature information reaches a preset value
  • the first generating unit is configured to, when the judging unit determines that the quantity of the received signature information reaches a preset value, use the multiple received signature information to aggregate to generate an aggregate signature;
  • the first sending unit is configured to send the aggregate signature to the voting node, so that the block to be confirmed is determined to be valid when the voting node passes the verification of the aggregate signature.
  • the block to be confirmed includes the transaction result, and the system further includes:
  • the second receiving unit receives transaction information sent by the multiple voting nodes respectively;
  • the sorting unit is used to sort the transaction information to obtain a transaction list
  • the second sending unit is configured to send the transaction list to the voting node, so that after the voting node simulates the execution of the transaction list to obtain a transaction result, the voting node generates a block to be confirmed according to the transaction result .
  • the transaction list includes historical block information
  • the second sending unit is further configured to:
  • the historical block information is sent to the voting node, so that the voting node matches the historical block information.
  • system further includes:
  • the simulation execution unit is used to simulate execution of the transaction list to obtain the transaction result
  • the second generating unit is configured to generate a block to be confirmed according to the transaction result, and sign the block to be confirmed to obtain a first signature
  • the first generating unit is specifically configured to:
  • the signature information further includes the hash value of the block header of the block to be confirmed.
  • the blockchain system includes 3F+1 nodes, the preset value includes 2F, and F is a natural number greater than zero.
  • the fifth aspect of the embodiments of the present application provides a consensus system for blockchain data, which is applied to voting nodes.
  • the voting nodes are nodes in a blockchain system.
  • the blockchain system further includes a proposal node.
  • Methods include:
  • the obtaining unit is used to obtain the block to be confirmed
  • the voting signature unit is used to sign the block to be confirmed and generate signature information
  • a sending unit configured to send the signature information to the proposal node
  • a receiving unit configured to receive an aggregate signature sent by the proposing node, where the aggregate signature is generated by the proposing node after aggregating multiple pieces of signature information;
  • the first determining unit is configured to determine that the block to be confirmed is valid when the aggregate signature is verified.
  • the block to be confirmed includes a transaction result
  • the obtaining unit is specifically configured to:
  • the transaction list includes historical block information
  • the system further includes:
  • the judging unit is configured to use its own database to judge whether there is target data matching the historical block message;
  • the trigger unit is configured to trigger the generation of the block to be confirmed according to the transaction result when the judgment unit determines that there is target data matching the historical block message in its own database.
  • the system further includes:
  • the second determining unit is configured to determine that the target data in the own database is valid after determining that the block to be confirmed is valid.
  • the blockchain system includes 3F+1 nodes, F is a natural number greater than 0, and the verification unit is specifically configured to:
  • the signature information further includes the hash value of the block header of the block to be confirmed.
  • the sixth aspect of the embodiments of the present application provides a computer-readable storage medium.
  • the computer-readable storage medium stores a consensus program for blockchain data.
  • the consensus program for blockchain data can be configured by one or more
  • the processor executes to implement the blockchain data consensus method according to any one of the foregoing method embodiments.
  • the embodiments of this application have the following advantages: receiving signature information respectively sent by the multiple voting nodes, where the signature information includes the signature of the block to be confirmed by the voting node; judging all received Whether the amount of the signature information reaches a preset value; if so, use the received multiple signature information to aggregate to generate an aggregate signature; send the aggregate signature to the voting node, so that when the voting node When the aggregate signature is verified, it is determined that the block to be confirmed is valid. Therefore, generating aggregated signatures in the consensus process of the blockchain can aggregate the signature votes from various voting nodes, simplify the consensus process of the blockchain, and achieve consensus on more data, thereby reducing congestion in the network. risk.
  • Figure 1 is an embodiment of a consensus method for blockchain data in the prior art
  • FIG. 2 is a schematic diagram of an embodiment of a consensus method for blockchain data in an embodiment of the application
  • FIG. 3 is another schematic diagram of an embodiment of a consensus method for blockchain data in an embodiment of the application.
  • Figure 3-1 is another schematic diagram of an embodiment of a blockchain data consensus method in an embodiment of the application
  • FIG. 4 is another schematic diagram of an embodiment of a consensus method for blockchain data in an embodiment of the application.
  • FIG. 5 is another schematic diagram of an embodiment of a blockchain data consensus method in an embodiment of the application.
  • Fig. 6 is a schematic diagram of an embodiment of a consensus system for blockchain data in an embodiment of the application
  • FIG. 7 is another schematic diagram of an embodiment of a consensus system for blockchain data in an embodiment of the application.
  • FIG. 8 is a schematic diagram of an embodiment of a consensus system for blockchain data in an embodiment of the application.
  • the following embodiments of the present application provide a blockchain data consensus method and related equipment for simplifying the blockchain consensus process.
  • PBFT Practical Byzantine-Fault-Tolerant
  • N 3f+1
  • the consensus process includes a request process (request), a consensus process and a response process (reply).
  • the consensus process is divided into three stages: pre-prepare, prepare, and commit.
  • the consensus process is as follows: C. Node 0, node 1, node 2, node 3) elect a proposal node (node C), the new block is generated by the proposal node; other nodes will broadcast the transaction sent by the client to the whole network, and the proposal node will The network collects multiple transactions that need to be placed in the new block and stores them in a list, and broadcasts the list to the entire network; after other nodes receive the transaction list, they execute these transactions according to the sorting simulation.
  • the embodiments of the present application provide a blockchain data consensus method and related equipment to simplify the blockchain consensus process.
  • An embodiment of a blockchain data consensus method in the embodiment of the present application includes:
  • the voting node obtains the block to be confirmed
  • the voting node obtains the block to be confirmed.
  • proposal nodes Proposer
  • voting nodes voting nodes
  • the proposal node is responsible for collecting transactions, packaging blocks and verifying voting information
  • the voting node is responsible for verifying blocks and voting for valid blocks.
  • the voting node can obtain the block to be confirmed sent by the proposal node to the voting node through the blockchain system, or it can receive the message to be confirmed sent by the proposal node to further generate the block to be confirmed, or other The method of obtaining is not limited here.
  • the voting node can use the aggregate signature algorithm to vote and sign the block to be confirmed to obtain signature information.
  • the voting node can verify the legality of the voting information.
  • the voting node uses the aggregate signature algorithm to vote and sign the block to be confirmed to obtain the signature information .
  • the voting node sends signature information to the proposing node
  • the voting node after obtaining the signature information in step 202, the voting node sends the signature information to the proposing node, so that the proposing node knows that the voting node has voted on the block to be confirmed, that is, knows that the voting node approves The block to be confirmed.
  • the signature information may also include the hash value of the block header of the block to be confirmed, where the hash value of the block header of the block to be confirmed is used to identify the block information corresponding to the signature information , That is, it indicates that the signature information has a corresponding relationship with the block to be confirmed.
  • the proposing node judges whether the preset value is reached
  • the proposing node judges whether the quantity of the received signature information reaches a preset value, if so, execute step 205, and if not, execute step 208.
  • the proposing node can determine whether the number of signature information received within a preset time period reaches a preset value.
  • a verification mechanism of the PBFT algorithm can be introduced here, that is, the proposed node can also be used as a voting node to participate in voting, or not to participate in voting.
  • the specific judgment process can refer to the authentication mode of the PBFT algorithm, that is, the blockchain system includes a total of 3F+1 nodes, and F is a natural number greater than 0.
  • the default value in this step is 2F, that is, if the proposal node receives 2F nodes within the preset time period to determine the signature information for the block to be confirmed, that is, it is determined that the number of signature information reaches the preset value, then step 205 is executed, if not, Step 208 is executed.
  • the signature information is aggregated using an aggregation signature algorithm.
  • this step is similar to the aforementioned step 202, and does not limit the aggregation signature algorithm.
  • the EC-Schnorr signature algorithm can be taken as an example for description. Please refer to the implementation process of the EC-Schnorr algorithm described in Figure 5. The interaction between users can be abstracted into 4 steps.
  • the signing node sends a Commitment to the aggregation node, as shown in 1 in the figure; in the second step, the aggregation node sends a challenge to the signing node, as shown in 2 in the figure; the third step, the signing node According to the challenge, a response (Response) is generated, as shown in Figure 3; in the fourth step, the aggregation node generates an aggregate signature according to the commitment and response of the signature node, and broadcasts the aggregate signature to all signature verification nodes, as shown in Figure 4.
  • the multiple interactions between the aggregation node and the signature node are to ensure that each signature node is the owner of the public key corresponding to the signature and prevent the signature node from doing evil.
  • the proposing node sends the aggregate signature to the voting node
  • the proposing node after obtaining the aggregate signature in step 205, the proposing node sends the aggregate signature to the voting node.
  • the voting node determines that the aggregate signature is valid
  • the voting node determines that the aggregated signature passes the legality verification, it is determined that the block to be confirmed is valid.
  • the voting node receives the aggregated signature and verifies that the aggregated signature contains legal multi-signatures from 2F+1 nodes for the current block, it can be determined to be confirmed The block is valid, and you can subsequently submit a new block and its transaction to the local blockchain, update the status database, or add the voting information to the transaction pool to wait for the transaction, etc.
  • the specifics are not limited here.
  • the proposing node determines in step 204 that the quantity of the received signature information does not reach the preset value, other operations are performed, that is, it is determined that the block to be confirmed has not been approved by the blockchain system .
  • the proposing node does not perform the step of generating an aggregated signature based on the signature information, and can directly discard the block to be confirmed, or resubmit and wait for the next polling process, or other operations, which are not specifically done here limited.
  • the proposing node receives the signature information sent by the multiple voting nodes, the signature information includes the signature of the block to be confirmed by the voting node; it is judged whether the amount of the received signature information reaches a preset value Value; if so, use the multiple received signature information to aggregate to generate an aggregate signature; send the aggregate signature to the voting node, so that when the voting node passes the verification of the aggregate signature, it is determined that the The block to be confirmed is valid. Therefore, generating aggregated signatures in the consensus process of the blockchain can aggregate the signature votes from various voting nodes, simplify the consensus process of the blockchain, and achieve consensus on more data, thereby reducing congestion in the network. risk.
  • a proposal node is elected from the nodes of the entire network, and the new block is generated by the proposal node.
  • node 0 is a proposal node, and other nodes are voting nodes.
  • the voting node broadcasts the transaction sent by the client to the entire network.
  • the proposed node will collect multiple transactions that need to be placed in the new block from the network and store it in a list, and broadcast the list to the entire network.
  • After the voting node receives the transaction list it executes these transactions according to the ranking simulation. After all transactions are executed, use your private key to sign the block to be confirmed, and then return the signature to the proposing node.
  • the proposing node verifies the received block voting signatures. If the proposing node receives legal signatures from more than 2f nodes, it will use the multi-signature aggregation algorithm to aggregate the signatures together with its own signature on the block to generate a multi-signature. If a node receives a multi-signature message and verifies that this multi-signature message contains legal multi-signatures from 2f+1 nodes for the current block, it can submit the new block and its transactions to the local blockchain and state database.
  • the process of obtaining the block to be confirmed by the voting node in step 201 may be implemented by the proposal node. Please refer to Figure 3 below.
  • the specific execution process of step 201 may include:
  • Voting nodes obtain transaction information
  • the voting nodes obtain transaction information, that is, each voting node obtains transaction information generated by its own client.
  • the voting node sends transaction information to the proposal node
  • each voting node sends the obtained transaction information to the proposal node.
  • each voting node can send it in the form of a blockchain network broadcast, or it can be sent in a direct point-to-point sending mode. Make a limit.
  • the proposal node sorts the transaction information
  • the proposing node sorts the transaction information collected in step 302 to obtain a transaction list.
  • step 205 when the proposing node determines in step 204 that the quantity of the received signature information reaches the preset value, the signature Information is aggregated using an aggregate signature algorithm, and the process of obtaining an aggregate signature can specifically incorporate the transaction list into the aggregate signature.
  • the proposing node simulates the execution of the transaction list to obtain the transaction result; after generating the block to be confirmed according to the transaction result, the proposing node signs the block to be confirmed to obtain the first signature, so that the step Aggregating and generating an aggregate signature by using the plurality of received signature information in 204 specifically includes: aggregating the first signature of the proposing node with the multiple signature information received in step 203 to obtain the aggregate signature.
  • the proposing node sends a transaction list to the voting node
  • the proposing node sends the transaction list generated in step 303 to the voting node.
  • the voting node simulates the execution of the transaction
  • the voting node simulates the execution of the transaction list according to the standard process, and generates the transaction result.
  • the voting node generates a block to be confirmed.
  • the voting node generates a block to be confirmed according to the transaction result obtained in step 305.
  • the block to be confirmed may be a block to be confirmed, and the block contains all the transactions in the above transaction list;
  • the transaction ranking list obtained by the voting node in step 304 also includes historical block information, and a judgment step for the execution preconditions of step 305 can also be added.
  • the specific additional steps include:
  • the voting node uses its own database to determine whether the historical block message has target data that matches the historical block message, if yes, execute step 308, and if not, execute step 309.
  • the historical block information can be all the information of the historical block or the hash value of all the information of the historical block.
  • the historical block information can also be the proposal The hash value of the latest n (n is an integer greater than 0) blocks in the node database.
  • the historical block information can be stored in the transaction ranking list information in the form of a block header, or it can be Other types of historical block information are not specifically limited here.
  • the voting node when the voting node determines that there is target data matching the historical block information in its database, it triggers the execution of step 306 to generate a block to be confirmed according to the transaction result.
  • the voting node finds whether the hash value in the historical block information of the block to be confirmed matches the previous block in its own database, if it matches, it means that the block of the voting node and the proposed node are highly consistent.
  • the follow-up consensus process can be executed.
  • the voting node when the voting node determines that there is no target data matching the historical block information in its database, the voting node performs other operations.
  • the voting node can check the block height, if If the block height in the historical block information is higher than the corresponding block height in the own database, the block must be synchronized first; if it is not higher than yourself, then no voting will be performed.
  • the voting node can determine its own database
  • the target data matching the historical block information is also a valid block.
  • Another difference between the multi-signature-based consensus algorithm in this solution and the traditional PBFT algorithm is that the consensus algorithm in this solution requires an additional block to confirm the absolute consistency of the previous block. Due to the loss of messages or other abnormal attacks in the network, a single round of consensus may be inconsistent between different nodes, but for two consecutive blocks that pass the consensus, a consensus is reached in the following block Time can mean that the block before it can be confirmed absolutely consistent in the network, so the security of the consensus algorithm can still be guaranteed.
  • a consensus system for blockchain data in an embodiment of the present application which is applied to a proposed node, and the system includes:
  • the first receiving unit 601 is configured to receive signature information sent by the multiple voting nodes, where the signature information includes the signature of the block to be confirmed by the voting node;
  • the judging unit 602 is configured to judge whether the quantity of the received signature information reaches a preset value
  • the first generating unit 603 is configured to, when the judging unit determines that the quantity of the received signature information reaches a preset value, use the multiple received signature information to aggregate to generate an aggregate signature;
  • the first sending unit 604 is configured to send the aggregate signature to the voting node, so that the block to be confirmed is determined to be valid when the voting node passes the verification of the aggregate signature.
  • the block to be confirmed includes the transaction result, and the system further includes:
  • the second receiving unit 605 is configured to receive transaction information respectively sent by the multiple voting nodes
  • the sorting unit 606 is configured to sort the transaction information to obtain a transaction list
  • the second sending unit 607 is configured to send the transaction list to the voting node, so that after the voting node simulates the execution of the transaction list and obtains the transaction result, the voting node generates an area to be confirmed according to the transaction result Piece.
  • the transaction list includes historical block information
  • the second sending unit 607 is further configured to:
  • the historical block information is sent to the voting node, so that the voting node matches the historical block information.
  • the system further includes:
  • the simulation execution unit 608 is configured to simulate execution of the transaction list to obtain the transaction result
  • the second generating unit 609 is configured to generate a block to be confirmed according to the transaction result, and sign the block to be confirmed to obtain a first signature;
  • the first generating unit 603 is specifically configured to:
  • the signature information further includes the hash value of the block header of the block to be confirmed.
  • the blockchain system includes 3F+1 nodes, the preset value includes 2F, and F is a natural number greater than zero.
  • an embodiment of the present application also provides a consensus system for blockchain data, which is applied to voting nodes, where the voting nodes are nodes in a blockchain system, and the blockchain system also includes a proposal node ,
  • the system includes:
  • the obtaining unit 701 is configured to obtain a block to be confirmed
  • the voting signature unit 702 is configured to sign the block to be confirmed and generate signature information
  • the sending unit 703 is configured to send the signature information to the proposal node
  • the receiving unit 704 is configured to receive an aggregate signature sent by the proposing node, where the aggregate signature is generated by the proposing node after aggregating multiple pieces of signature information;
  • the verification unit 705 is configured to verify the aggregate signature
  • the first determining unit 706 is configured to determine that the block to be confirmed is valid when the aggregated signature is verified.
  • the block to be confirmed includes a transaction result
  • the obtaining unit 701 is specifically configured to:
  • the transaction list includes historical block information
  • the system further includes:
  • the judging unit 707 is configured to use its own database to judge whether there is target data matching the historical block message;
  • the trigger unit 708 is configured to trigger the generation of the block to be confirmed according to the transaction result when the judgment unit determines that there is target data matching the historical block message in its own database.
  • the system further includes:
  • the second determining unit 709 is configured to determine that the target data in the own database is valid after determining that the block to be confirmed is valid.
  • the blockchain system includes 3F+1 nodes, F is a natural number greater than 0, and the verification unit 705 is specifically configured to:
  • the signature information further includes the hash value of the block header of the block to be confirmed.
  • the blockchain data consensus device 1 may be a PC (Personal Computer, personal computer), or a smart phone, a tablet computer, a palmtop computer, a portable computer, or a network storage device terminal device.
  • PC Personal Computer
  • smart phone a tablet computer, a palmtop computer, a portable computer, or a network storage device terminal device.
  • the device 1 may be a node forming a CDN network or a blockchain network.
  • the data consensus device 1 of the blockchain may include a memory 11, a processor 12, and a bus 13.
  • the memory 11 includes at least one type of readable storage medium, and the readable storage medium includes flash memory, hard disk, multimedia card, card-type memory (for example, SD or DX memory, etc.), magnetic memory, magnetic disk, optical disk, etc.
  • the memory 11 may be an internal storage unit of the data consensus device 1 of the blockchain, for example, the hard disk of the data consensus device 1 of the blockchain.
  • the memory 11 may also be an external storage device of the data consensus device 1 of the blockchain, for example, a plug-in hard disk equipped on the data consensus device 1 of the blockchain, a smart media card (SMC). ), Secure Digital (SD) card, Flash Card, etc.
  • SMC smart media card
  • SD Secure Digital
  • the memory 11 may also include both an internal storage unit of the data consensus device 1 of the blockchain and an external storage device.
  • the memory 11 can be used not only to store the application software and various data of the data consensus device 1 installed in the blockchain, such as the code of the data consensus program 01 of the blockchain, etc., but also to temporarily store the output or will be output The data.
  • the processor 12 may be a central processing unit (CPU), controller, microcontroller, microprocessor or other data processing chip in some embodiments, and is used to run the program code or processing stored in the memory 11 Data, such as the implementation of blockchain data consensus program 01, etc.
  • CPU central processing unit
  • controller microcontroller
  • microprocessor or other data processing chip in some embodiments, and is used to run the program code or processing stored in the memory 11 Data, such as the implementation of blockchain data consensus program 01, etc.
  • the bus 13 may be a peripheral component interconnect standard (PCI) bus or an extended industry standard architecture (EISA) bus, etc.
  • PCI peripheral component interconnect standard
  • EISA extended industry standard architecture
  • the bus can be divided into address bus, data bus, control bus, etc. For ease of presentation, only one thick line is used in FIG. 8 to represent, but it does not mean that there is only one bus or one type of bus.
  • the data consensus device of the blockchain may also include a network interface 14.
  • the network interface 14 may optionally include a wired interface and/or a wireless interface (such as a WI-FI interface, a Bluetooth interface, etc.), which is usually used in the device 1 Establish a communication connection with other electronic devices.
  • the device 1 may also include a user interface.
  • the user interface may include a display (Display) and an input unit such as a keyboard (Keyboard).
  • the optional user interface may also include a standard wired interface and a wireless interface.
  • the display may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, an OLED (Organic Light-Emitting Diode, organic light emitting diode) touch device, etc.
  • the display can also be appropriately called a display screen or a display unit, which is used to display the information processed in the data consensus device 1 of the blockchain and to display a visualized user interface.
  • FIG. 8 only shows the data consensus device 1 of the blockchain with components 11-14 and the data consensus program 01 of the blockchain.
  • the definition of the block chain data consensus device 1 may include fewer or more components than shown in the figure, or a combination of certain components, or a different component arrangement.
  • the size of the sequence number of each step does not mean the order of execution.
  • the order of execution of each step should be determined by its function and internal logic, and it is not applicable to this application.
  • the implementation process of the embodiment constitutes any limitation.
  • the disclosed system, device, and method may be implemented in other ways.
  • the device embodiments described above are only illustrative.
  • the division of the units is only a logical function division, and there may be other divisions in actual implementation, for example, multiple units or components can be combined or It can be integrated into another system, or some features can be ignored or not implemented.
  • the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or units, and may be in electrical, mechanical or other forms.
  • the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the objectives of the solutions of the embodiments.
  • each unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units may be integrated into one unit.
  • the above-mentioned integrated unit can be implemented in the form of hardware or software functional unit.
  • the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer readable storage medium.
  • the technical solution of this application essentially or the part that contributes to the existing technology or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium , Including several instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the method described in each embodiment of the present application.
  • the aforementioned storage media include: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), magnetic disk or optical disk and other media that can store program code .

Abstract

Les modes de réalisation de la présente invention concernent un procédé de consensus pour des données de chaîne de blocs qui consiste : à recevoir, au moyen d'un nœud de proposition, des informations de signature envoyées par une pluralité de nœuds de vote respectivement, les informations de signature comprenant des signatures des nœuds de vote sur un bloc à confirmer; à déterminer si le nombre d'éléments d'informations de signature reçues atteint une valeur préétablie; si tel est le cas, à agréger la pluralité d'éléments d'informations de signature reçues pour générer une signature agrégée; à envoyer la signature agrégée aux nœuds de vote, de telle sorte que le bloc à confirmer est déterminé comme étant valide lorsque la vérification effectuée par les nœuds de vote pour la signature agrégée est réussie. L'invention concerne également un système et un dispositif destinés aux données de chaîne de blocs. Une signature agrégée est générée dans le processus de consensus de chaînes de blocs, et les votes de signature provenant de nœuds de vote peuvent être agrégés, de telle sorte que le processus de consensus de chaînes de blocs est simplifié, ce qui permet de réduire le risque d'apparition d'une congestion de réseau.
PCT/CN2019/093705 2019-06-28 2019-06-28 Procédé de consensus pour données de chaîne de blocs et dispositif associé WO2020258252A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/CN2019/093705 WO2020258252A1 (fr) 2019-06-28 2019-06-28 Procédé de consensus pour données de chaîne de blocs et dispositif associé
CN201980059451.3A CN112689848A (zh) 2019-06-28 2019-06-28 一种区块链数据的共识方法及相关设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2019/093705 WO2020258252A1 (fr) 2019-06-28 2019-06-28 Procédé de consensus pour données de chaîne de blocs et dispositif associé

Publications (1)

Publication Number Publication Date
WO2020258252A1 true WO2020258252A1 (fr) 2020-12-30

Family

ID=74061449

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/093705 WO2020258252A1 (fr) 2019-06-28 2019-06-28 Procédé de consensus pour données de chaîne de blocs et dispositif associé

Country Status (2)

Country Link
CN (1) CN112689848A (fr)
WO (1) WO2020258252A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114615281A (zh) * 2022-03-07 2022-06-10 中国科学院软件研究所 基于小规模委员会的区块链出块方法及PoS协议确认方法

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113256417B (zh) * 2021-05-14 2022-07-12 杭州链网科技有限公司 一种基于交易共享的共识出块方法及系统
CN113783935B (zh) * 2021-08-12 2022-04-01 清华大学 一种拜占庭容错方法及装置
CN113783946A (zh) * 2021-08-25 2021-12-10 山东区块链研究院 一种基于门限签名的可再投票二元共识方法及装置
CN114553434B (zh) * 2021-10-09 2024-03-12 支付宝(杭州)信息技术有限公司 一种共识方法、区块链系统和共识节点
CN114782047B (zh) * 2021-12-29 2023-06-30 张海滨 数据共识方法及分布式系统
CN114338715A (zh) * 2021-12-31 2022-04-12 杭州趣链科技有限公司 数据同步方法、区块链系统、终端设备及存储介质
CN114745140B (zh) * 2022-06-13 2022-08-23 天津市城市规划设计研究总院有限公司 基于聚合加密的城市规划领域区块链共识验证方法及系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107968708A (zh) * 2017-11-10 2018-04-27 财付通支付科技有限公司 生成签名的方法、装置、终端及服务器
CN108182635A (zh) * 2017-12-18 2018-06-19 深圳前海微众银行股份有限公司 区块链共识方法、系统和计算机可读存储介质
CN109150598A (zh) * 2018-08-10 2019-01-04 上交所技术有限责任公司 一种基于块片的bft共识算法带宽使用率改进方法
CN109360100A (zh) * 2018-11-13 2019-02-19 北京航空航天大学 基于区块链技术的交易快速确认方法及装置

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110959281B (zh) * 2017-08-05 2022-03-22 普罗克鲁斯科技有限公司 使用交易证明使得区块链安全化的方法和系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107968708A (zh) * 2017-11-10 2018-04-27 财付通支付科技有限公司 生成签名的方法、装置、终端及服务器
CN108182635A (zh) * 2017-12-18 2018-06-19 深圳前海微众银行股份有限公司 区块链共识方法、系统和计算机可读存储介质
CN109150598A (zh) * 2018-08-10 2019-01-04 上交所技术有限责任公司 一种基于块片的bft共识算法带宽使用率改进方法
CN109360100A (zh) * 2018-11-13 2019-02-19 北京航空航天大学 基于区块链技术的交易快速确认方法及装置

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114615281A (zh) * 2022-03-07 2022-06-10 中国科学院软件研究所 基于小规模委员会的区块链出块方法及PoS协议确认方法
CN114615281B (zh) * 2022-03-07 2023-02-28 中国科学院软件研究所 基于小规模委员会的区块链出块方法及PoS协议确认方法

Also Published As

Publication number Publication date
CN112689848A (zh) 2021-04-20

Similar Documents

Publication Publication Date Title
CN110300172B (zh) 一种区块链数据的共识方法及相关设备
WO2020258252A1 (fr) Procédé de consensus pour données de chaîne de blocs et dispositif associé
CN110288479B (zh) 一种区块链数据的共识方法及相关设备
CN110383279B (zh) 用于检测重放攻击的系统和方法
CN107579848B (zh) 实用拜占庭容错共识机制中动态更改共识节点的方法
CN112685796B (zh) 一种基于区块链的区块共识方法以及相关设备
CN110431577B (zh) 用于检测重放攻击的系统和方法
US20200082126A1 (en) Methods and system for collecting statistics against distributed private data
WO2021244208A1 (fr) Procédé et appareil de traitement de message de proposition, et dispositif et support de stockage
US20210256016A1 (en) Blockchain system and method
CN111414373B (zh) 一种共识方法和共识系统
CN110489946B (zh) 基于区块链的版权认证方法、装置、设备和存储介质
CN110771127B (zh) 用于区块链网络中一致分布式内存池的方法和系统
CN110708171A (zh) 区块链共识投票方法、装置、设备以及存储介质
KR20190023894A (ko) 전자 투표 시스템 및 방법
CN111523890A (zh) 基于区块链的数据处理方法、装置、存储介质及设备
CN111338608B (zh) 分布式应用开发方法、装置、节点设备及可读存储介质
WO2020155811A1 (fr) Procédé, dispositif et appareil électronique d'exécution de contrat intelligent de chaîne de blocs
US20210089673A1 (en) Information processing apparatus, information processing method, and program
CN112118239A (zh) 区块链共识方法及装置、电子设备、存储介质
JP2022539283A (ja) ブロックチェーンとは異なる形式のストレージに格納されるブロックチェーンデータを検証する方法およびシステム
CN113888164A (zh) 区块链交易池实现方法、装置、计算机设备和存储介质
WO2023020242A1 (fr) Procédé et appareil de traitement de données basés sur une chaîne de blocs, dispositif informatique, support de stockage lisible et produit de programme informatique
CN110990790A (zh) 一种数据处理方法及设备
CN110807209A (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: 19935576

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: 19935576

Country of ref document: EP

Kind code of ref document: A1