WO2022127424A1 - 区块组头的获取方法及装置，存储介质及电子装置 - Google Patents

区块组头的获取方法及装置，存储介质及电子装置 Download PDF

Info

Publication number
WO2022127424A1
WO2022127424A1 PCT/CN2021/128716 CN2021128716W WO2022127424A1 WO 2022127424 A1 WO2022127424 A1 WO 2022127424A1 CN 2021128716 W CN2021128716 W CN 2021128716W WO 2022127424 A1 WO2022127424 A1 WO 2022127424A1
Authority
WO
WIPO (PCT)
Prior art keywords
block group
node
group header
block
voting
Prior art date
Application number
PCT/CN2021/128716
Other languages
English (en)
French (fr)
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 JP2023537119A priority Critical patent/JP7520237B2/ja
Priority to US18/257,667 priority patent/US20240031151A1/en
Priority to KR1020237022466A priority patent/KR20230112718A/ko
Publication of WO2022127424A1 publication Critical patent/WO2022127424A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • 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
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0639—Performance analysis of employees; Performance analysis of enterprise or organisation operations
    • G06Q10/06393—Score-carding, benchmarking or key performance indicator [KPI] analysis
    • 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
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • 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
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1087—Peer-to-peer [P2P] networks using cross-functional networking aspects
    • H04L67/1093—Some peer nodes performing special functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/46—Secure multiparty computation, e.g. millionaire problem
    • H04L2209/463—Electronic voting

Definitions

  • the present invention relates to the field of communications, and in particular, to a method and device for acquiring a block group header, a storage medium and an electronic device.
  • the blockchain system is a distributed system that can be traced back in history, cannot be tampered with, and solves the problem of multi-party mutual trust.
  • the distributed system is bound to face the problem of consistency, that is, consensus needs to be reached, and the consensus of the distributed system needs to rely on a reliable consensus algorithm, and the common consensus algorithms include the proof-of-work consensus algorithm, the practical Byzantine fault-tolerant algorithm, and the parallel voting proof algorithm. Wait.
  • the blockchain nodes are divided into: accounting nodes, voting nodes and leadership nodes.
  • accounting nodes generates a block and publishes it to the network.
  • the voting node collects the blocks generated by the accounting node and votes, and then summarizes the voting information and sends it to the leader node.
  • the leader node collects the aggregated voting information for statistics, and then The statistical results are written into the block group header, and finally the block group header is published to the network.
  • parallel voting proves that the PPoV consensus algorithm has a low acquisition rate in the process of acquiring block group headers, and no effective solution has been proposed yet.
  • Embodiments of the present invention provide a method and device for obtaining a block group header, a storage medium, and an electronic device, so as to solve one of the related technical problems at least to a certain extent, including parallel voting to prove that the PPoV consensus algorithm is in the process of obtaining a block group.
  • the acquisition rate is not high in the process of the head.
  • a method for obtaining a block group header including: determining whether a target node in a blockchain system satisfies a preset condition, wherein the preset condition is used to indicate at least the following One: the target node has received the block group header and has not received a preset number of legal blocks, and the target node has not received the block group header; after determining that the target node has not received the block group
  • determine the event cause that the target node does not receive the block group header wherein the event cause includes at least one of the following: the target node fails to receive the block group header, the The block chain system does not generate a block group header; according to the event cause, the acquisition method of the block group header that has not been received by the target node is determined.
  • an apparatus for obtaining a block group header including: a first determination module configured to determine whether a target node in the blockchain system satisfies a preset condition, wherein, The preset condition is used to indicate at least one of the following: the target node has received the block group header and has not received a preset number of legal blocks, the target node has not received the block group header; the second The determining module is configured to determine the event cause that the target node has not received the block group header when it is determined that the target node has not received the block group header, wherein the event cause includes at least one of the following : The target node fails to receive the block group header, and the blockchain system does not generate a block group header; the third determination module is set to determine that the target node has not received the block group header according to the event cause. How to obtain the block group header.
  • a computer-readable storage medium is also provided, where a computer program is stored in the computer-readable storage medium, wherein the computer program is configured to execute the above block group when running How to get the header.
  • an electronic device including a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the above-mentioned area through the computer program How to get the block group header.
  • Fig. 1 is the hardware structure block diagram of the computer terminal of the acquisition method of the block group header of the embodiment of the present invention
  • FIG. 2 is a schematic diagram of message passing in a PoV consensus process according to an embodiment of the present invention
  • FIG. 3 is a schematic diagram of a PPoV consensus process according to an embodiment of the present invention.
  • FIG. 4 is a flowchart of a method for obtaining a block group header according to an embodiment of the present invention
  • FIG. 5 is a schematic diagram of a block chain node timeout trigger condition according to an embodiment of the present invention.
  • FIG. 6 is a structural diagram of a timeout processing module of a blockchain node according to an embodiment of the present invention.
  • FIG. 7 is a flowchart of timeout processing of a blockchain node according to an embodiment of the present invention.
  • FIG. 8 is a structural block diagram of an apparatus for acquiring a block group header according to an embodiment of the present invention.
  • FIG. 1 is a hardware structural block diagram of a computer terminal according to a method for acquiring a block group header according to an embodiment of the present invention.
  • the computer terminal may include one or more (only one is shown in FIG.
  • processor 102 may include, but is not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA, etc.
  • the above-mentioned computer terminal may further include a transmission device 106 and an input and output device 108 for communication functions.
  • the structure shown in FIG. 1 is only a schematic diagram, which does not limit the structure of the above-mentioned computer terminal.
  • the computer terminal may also include more or fewer components than those shown in FIG. 1 , or have a different configuration with equivalent or more functions than those shown in FIG. 1 .
  • the memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as computer programs corresponding to the method for obtaining the block group header in the embodiment of the present invention.
  • the processor 102 runs the computer programs stored in the memory 104 , so as to perform various functional applications and data processing, that is, to implement the above method.
  • Memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory.
  • memory 104 may further include memory located remotely from processor 102, which may be connected to a computer terminal through a network. Examples of such networks include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.
  • Transmission means 106 are used to receive or transmit data via a network.
  • the specific example of the above-mentioned network may include a wireless network provided by the communication provider of the computer terminal.
  • the transmission device 106 includes a network adapter (Network Interface Controller, NIC for short), which can be connected to other network devices through a base station so as to communicate with the Internet.
  • the transmission device 106 may be a radio frequency (Radio Frequency, RF for short) module, which is used to communicate with the Internet in a wireless manner.
  • RF Radio Frequency
  • the traditional Proof of Vote (PoV) consensus algorithm has designed a specific role model to classify the nodes in the blockchain network into Certification, Butler, Butler Candidate and General User (Ordinary User) four roles.
  • the candidate stewards can be transformed by ordinary users after applying for joining, and the stewards are elected by the committee members. In the voting stage, each committee member needs to vote for each candidate steward, and the N b nodes with more votes will become the steward nodes.
  • the housekeeper node is mainly responsible for collecting transactions and generating blocks.
  • the consensus process of block generation is jointly carried out by a steward and all members.
  • the steward is called the on-duty steward, and the on-duty steward is determined by the on-duty steward number.
  • N c members in total, namely C1, C2,...,CN c
  • N b stewards namely B1, B2,..., BN b , Fig.
  • FIG. 2 is a schematic diagram of message transfer in the PoV consensus process according to an embodiment of the present invention , in Figure 2, round(r) is the rth round, round(r+1) is the r+1th round, PREPARE is preparation, READY is preparation, COMMIT is submission, Pre-Block is pre-block, Final-Block for the final block.
  • the PoV consensus algorithm divides a round of consensus into four stages: Prepare, Ready, Commit and Confirm.
  • the Confirm stage is the block submission stage and does not need to transmit messages.
  • Each block contains a block header and an indeterminate number of transactions.
  • the on-duty steward takes a certain number of transactions from the transaction pool and packs them to generate a pre-block and sends the pre-block to all members.
  • the difference between the pre-block and the official block is that the pre-block does not have a time stamp, a committee signature and the next on-duty housekeeper number.
  • the committee node needs to verify the block header of the received pre-block and the information contained in the transaction. If the verification passes, it will sign the pre-block header and send the signature to the on-duty steward. After collecting the signatures of committee members exceeding N c /2, the on-duty steward can complete the pre-block and release the official block.
  • the node that receives the newly released block stores the block in the local blockchain and updates the relevant variables including the number of the on-duty housekeeper, thereby replacing the on-duty housekeeper responsible for the next round of consensus.
  • the PoV consensus algorithm selects a node from multiple candidate nodes as the accounting node and generates blocks in each consensus cycle. Therefore, the process of generating blocks is performed serially, which is difficult to support in large-scale clusters. High throughput performance in environments.
  • a block group consists of a block group header and a block group body.
  • Each block group header contains the height and voting result of the current block group, and the block group body contains all the blocks that have passed the vote.
  • each block contains the hash value of the previous block group, the Merkle root, the generator's public key, timestamp and other information and transaction sets.
  • PPoV consensus generally expresses the identities of blockchain nodes as voting nodes, accounting nodes, and leadership nodes.
  • FIG. 3 is a schematic diagram of a PPoV consensus process according to an embodiment of the present invention. Each round of PPoV consensus consists of the following steps:
  • Each accounting node generates a block and publishes it to the network.
  • Each blockchain node collects the blocks generated by all accounting nodes;
  • voting node After the voting node collects the blocks generated by the accounting node in S1, it votes for each block separately and generates a total voting message to send to the leader node.
  • the voting message contains the hash value of each block, as well as the opinions and signatures of whether or not to agree;
  • the leader node collects the voting messages sent by the voting nodes and counts the voting results. When the approval or disapproval of each block exceeds half of the number of voting nodes, the statistical results and all voting messages are stored in the block group header. Then the leader node generates a random number, which is the number of the leader node for the next consensus cycle, and writes it into the block group header. Then publish the block group header to the network;
  • the design of the current PPoV consensus algorithm is not perfect. Considering that in the real environment, the server may fail due to various reasons and cause it to fail to work normally, in the case of multi-node parallel accounting, the traditional PPoV consensus algorithm may be caused by the failure of a small number of accounting nodes, resulting in the area generated by other normal nodes. Blocks also cannot be verified and generated, that is, the traditional PPoV consensus algorithm cannot generate block group headers for some reasons and cannot meet the termination property.
  • FIG. 4 is a flowchart of a method for obtaining a block group header according to an embodiment of the present invention, and the flow includes the following steps:
  • Step S402 determining whether the target node in the blockchain system satisfies a preset condition, wherein the preset condition is used to indicate at least one of the following: the target node has received the block group header and has not received the preset condition The number of legal blocks, the target node did not receive the block group header;
  • Step S404 in the case of determining that the target node has not received the block group header, determine the event cause that the target node has not received the block group header, wherein the event cause includes at least one of the following: the The target node fails to receive the block group header, and the block chain system does not generate a block group header;
  • Step S406 determine how the target node acquires the unreceived block group header.
  • the target node of the blockchain system meets the preset conditions.
  • Two different strategies are formulated according to these two situations. In the case of not receiving the block group header, determine the event cause of not receiving the block group header, and then determine that the target node has not received the block group header according to the event cause. How to get the block group header of .
  • the above technical solution solves the problem that the parallel voting proof PPoV consensus algorithm has a low acquisition rate in the process of acquiring block group headers, and then when acquiring block group headers, different acquisition methods are used according to different event reasons, which improves the performance of the block group header.
  • the fetch rate of block group headers is not limited to the process of acquiring block group headers.
  • Condition 1 The target node has received the block group header and has not received the preset number of legal blocks;
  • Condition 2 The target node has not received Block group header.
  • the target node in the blockchain system needs to judge whether the preset conditions are met. If not, a timeout will be triggered, and the target node will perform the relevant timeout operation. The target node does not receive the block group header.
  • the event cause that the target node does not receive the block group header, wherein the event cause includes at least one of the following: the target node fails to receive the block group header successfully, and the blockchain system If the block group header is not generated, then the blockchain system will determine how the target node obtains the block group header that has not been received according to the cause of the event. For example, a certain accounting node A in the blockchain system does not receive the block group header, so accounting node A will trigger a timeout operation, request its blockchain height from all voting nodes, and maintain the online status of each voting node locally.
  • the accounting node A will then determine the acquisition method according to the event cause.
  • determining the acquisition method of the block group header that has not been received by the target node according to the event cause includes: indicating in the event cause
  • the block group header that has not been successfully received is obtained synchronously from the voting node of the blockchain system.
  • the target node will go to the voting node to request the block group header. Because the voting node is the core consensus point of the blockchain network, it is considered to have the latest If the system generates a block group header, the voting node will definitely receive it during the broadcast of the generated block group header to the blockchain network. For example, if billing node A does not receive the block group header, billing node A will go to voting node B for data synchronization to obtain the block group header.
  • the blockchain height of voting node B is higher than that of billing node A. high.
  • the block chain height is used to indicate the block height.
  • the blockchain height can be understood as a database. Since the blockchain system is a distributed system without a unified database, it can be understood that each blockchain node has a database. The height of the voting node blockchain is higher than that of the local blockchain, which means that the database update degree of the voting node is better than that of the accounting node database. Therefore, in order to obtain the block group header, it is necessary to obtain the block group header from the database with a poor update degree. Data synchronization in a good database.
  • determining the acquisition mode of the block group header that has not been received by the target node according to the event cause includes: indicating in the event cause
  • the voting node is instructed to vote for the received block, and the processing result of the unreceived legal block is set as the target value to indicate the
  • the voting node has no opinion on the unreceived legal block, and obtains the voting result of the voting node; sends the voting result to the rotating accounting node to instruct the rotating accounting node to generate the unreceived to the legal block group header.
  • the accounting node when the accounting node requests the height of its blockchain from all voting nodes, it does not find that the height of the blockchain of the voting node is higher than that of the local blockchain of the accounting node, Therefore, it can be understood that the block chain system does not generate a block group header.
  • all voting nodes are instructed to vote for the blocks received from the accounting nodes, and at the same time, the legal blocks that have not been received will be processed.
  • the result is set as the target value to indicate that the voting node has no opinion on the unreceived block, and the voting node sends all voting results to the rotating accounting node for statistics, so that the rotating accounting node generates a block group head.
  • voting node X, voting node Y, and voting node Z respectively generate a voting information table for the rotating accounting node M, and the rotating accounting node M collects statistics, thereby generating a block group header.
  • the rotating accounting node can only apply for the block group after receiving more than 2N v /3 voting information from the voting nodes. Count each block and generate statistical results. If the number of voting nodes that agree with any legal block exceeds 1N v /3, the rotating accounting node agrees to generate the any legal block. Set its voting result to 1, otherwise the rotating bookkeeping node does not agree to generate any of the legal blocks, and its voting result is set to -1.
  • the N v is the number of the voting nodes in the blockchain system.
  • the existing voting node X, voting node Y, voting node Z, voting node W, and rotating accounting node M can generate statistical results only after receiving the voting information of at least three voting nodes among the four voting nodes. , and any block is allowed to be produced only if at least two of the four voting nodes vote to agree.
  • the rotating checkout node After the rotating accounting node generates a valid block group header, the rotating checkout node broadcasts the generated block group header to all nodes in the blockchain system to instruct all nodes to verify the generated block group header. , when all nodes are verifying, only the block group header that contains more than 2N v /3 votes can pass the verification, and in the case of passing the verification, it will receive the successfully generated block group header.
  • the target node successfully receives the target group header, but does not receive a preset number of legal blocks, it sends an acquisition request to other nodes in the blockchain system, wherein, The acquisition request is used to acquire the legal block from the other node, the other node is a node other than the target node in the blockchain system, and the other node saves the legal block block.
  • accounting node A successfully received the block group header after the PPoV consensus ended, but did not receive enough blocks due to network failure, such as not receiving block b and block c, the accounting node at this time A will broadcast to other nodes in the blockchain network to obtain blocks b and c that have not been received.
  • the PPoV consensus algorithm refers to all the operations performed to generate a block group as one round of consensus.
  • the blocks generated by other normal nodes may not be verified and generated due to the failure of a small number of accounting nodes.
  • accounting nodes rotating accounting nodes and voting nodes.
  • epoch is a consensus round
  • T cut the duration of each consensus round
  • N epoch is the number of consensus rounds that have passed from time t 0 to the current time t:
  • N epoch (tt 0 )%T cut ;
  • FIG. 5 is a schematic diagram of a block chain node timeout triggering condition according to an embodiment of the present invention. If in a round of consensus, the target node block chain system in the block chain system still fails after the deadline T cut of a consensus round epoch. If the submission conditions are met, that is, a qualified block group cannot be generated, a timeout will be triggered, that is, the block group header of the block group of this round of consensus and all valid blocks that have been voted for are not received at the same time.
  • FIG. 6 is a structural diagram of a timeout processing module of a blockchain node according to an embodiment of the present invention; it includes a timing submodule, a vote statistics submodule, a view transformation submodule, and an incentive submodule.
  • the timing sub-module provides the start time t 0 , the end time t and the duration T cut of the current round of consensus.
  • the voting statistics sub-module includes voting operations of voting nodes and statistical operations of rotating accounting nodes. Specifically, all voting nodes perform voting operations after receiving the timeout message and send them to the rotating accounting nodes of the next epoch. If the block that has been received is voted in the normal way, the result of the block that has not been received is set to 0 (no opinion), and its hash value is set to be empty. After receiving more than 2N v /3 votes from voting nodes, the rotating accounting node will count each block in the block group and generate statistical results.
  • the statistical rule is: if any numbered block is If the approval votes obtained by any hash value exceeds N v /3, it can be regarded as agreeing to generate a block, and its voting result is set to 1, otherwise it is regarded as opposing the generation of a block, and its voting result is set to -1 .
  • N v is the number of voting nodes.
  • the view transformation sub-module includes the data synchronization operation of the node and the block group header verification operation.
  • voting nodes are the core consensus nodes of the network, they are considered to have the latest blockchain state. All nodes need to request their blockchain heights from all voting nodes, and maintain the online status of each voting node locally. If there is a voting node whose blockchain height is higher than that of the local blockchain, the node will request a block group higher than the local height to synchronize data.
  • a node receives a new block group header, it needs to verify the list of votes contained in the block group header received after the timeout. Only the block group header that contains more than 2N v /3 votes can pass the verification. , in which the block with more than N v /3 approval votes can pass the vote, otherwise it will be regarded as the vote failed.
  • the incentive sub-module implements the scoring mechanism and the reward mechanism. Specifically, each voting node maintains a list of accounting nodes and scores them. The score for each accounting node represents the degree of trust in the accounting node, and also becomes one of the basis for voting by voting nodes. After each round of term ends, the accounting node will receive the reward from the alliance according to the number of legal blocks and block group headers that have been generated.
  • FIG. 7 shows the timeout processing of a blockchain node according to an embodiment of the present invention. flow chart. Taking the accounting node timeout processing as an example, for general non-incentive scenarios, the specific timeout processing can be divided into two situations:
  • One situation is that the accounting node has received valid block group headers, but not enough valid blocks.
  • the block group header has been generated to indicate that the consensus has been completed, and the failure to receive enough valid blocks may be caused by network failures and other reasons, so it is only necessary to request the missing valid blocks from other nodes.
  • Another situation is that the accounting node does not receive a valid block group header. The reason may be that the rotating accounting node fails, or it may be that the accounting nodes in other parts fail, so enough blocks cannot be generated. The following steps are required at this point:
  • Step 1 The accounting node needs to request its blockchain height from all voting nodes, and maintain the online status of each voting node locally. If there is a voting node whose blockchain height is higher than that of the local blockchain, the node will request a block group higher than the local height to synchronize data, and then end the timeout processing. Otherwise, continue to execute the following timeout operations;
  • Step 2 All voting nodes immediately perform the voting operation. If the block has been received, they will vote in the normal way. For the block that has not been received, set the result to 0 (no opinion), and set its hash value to be empty. The generated vote needs to be sent to the rotating accounting node of the next epoch;
  • Step 3 After receiving more than 2N v /3 votes, the rotating accounting node counts each block in the block group and generates statistical results.
  • the statistical rule is: if any numbered block is If the approval votes obtained by any hash value exceeds N v /3, it can be regarded as agreeing to generate a block, and its voting result is set to 1, otherwise it is regarded as opposing the generation of a block, and its voting result is set to -1 .
  • N v is the number of voting nodes
  • Step 4 If N epoch > 1, that is, if it times out more than twice, the rotating accounting node needs to be replaced. If the number of the accounting node before the timeout is R 0 , the current number R of the rotating accounting node is (R 0 +N epoch -1)% Nw . Among them, N w is the number of accounting nodes;
  • Step 5 All nodes need to verify the list of votes contained in the block group header received after the timeout. Only the block group header containing more than 2N v /3 votes can pass the verification and obtain more than N v /3 votes. Blocks with approval votes can be voted on, otherwise they will be considered as voted failures.
  • the trigger of timeout is also accompanied by a decrease in the revenue of accounting nodes. Details are as follows:
  • the voting proof consensus has designed a scoring mechanism and a reward mechanism.
  • the purpose of accounting nodes participating in elections and generating legal blocks is mainly to obtain accounting fees.
  • the alliance chain system can solve the problem of billing fees by introducing tokens, and the amount unit and conversion of the token corresponds to the real currency amount unit and conversion one-to-one. After the alliance is established, an alliance fund account address will be set up, which corresponds to a real account for depositing funds in the bank in reality.
  • the accounting node with the higher score has a greater probability of getting votes to be elected as the leader node.
  • the leader node that successfully encapsulates the legal block group will receive the corresponding amount of reward according to the number, thereby attracting more people to join the ranks of the accounting nodes, rewarding the behavior of honest work, punishing the behavior of evil, making the system more and more Safe and reliable development.
  • Each voting node will maintain a list of accounting nodes and score them.
  • the scoring rules are:
  • Rule 3 When the accounting node is not online and misses the production block, it will trigger a timeout, and its score will be reduced or even cleared by all voting nodes. If it is zero, it means that when the accounting node comes back online, the points need to be restarted from the beginning.
  • the score of the accounting node in each voting node may be different.
  • the score for each accounting node represents the trust level of the accounting node, and it also becomes one of the basis for voting by the voting node.
  • the bookkeeping nodes will receive rewards from the alliance based on the number of legal blocks and block group headers that have been generated, giving them motivation to apply for elections, work honestly, and stay online for a long time.
  • Embodiment 1 In an incentive-free transfer scenario based on parallel voting proof consensus, it is assumed that user A requests to transfer a sum of funds from his own account to user B's account. If user A has not received the block group containing whether the transfer is successful before Tcut, a timeout will be triggered.
  • the specific processing flow is as follows:
  • the voting node After receiving the timeout request, the voting node immediately performs the voting operation. If the block has been received, it will vote in the normal way. If the block has not been received, the result will be set to 0 (no opinion), and its The hash value is empty. After receiving more than 2N v /3 votes, the rotating bookkeeping node will count each block in the block group and generate statistical results;
  • Embodiment 2 In the scenario of unincentivized identification registration based on the consensus of parallel voting proof, it is assumed that user X requests to register a new identification in the network. If user X has not received the block group containing the identification of whether the registration is successful before Tcut, a timeout will be triggered.
  • the specific processing flow is as follows:
  • the voting node immediately performs the voting operation after receiving the timeout request. If the block has been received, it will vote in the normal way. If the block has not been received, the result will be set to 0 (no opinion), and its The hash value is empty. After receiving more than 2N v /3 votes, the rotating accounting node will count each block in the block group and generate statistical results;
  • this processing rule ensures that a legal block group can inevitably be generated in a consensus round, that is, the accounting node receives to a valid block group header and enough blocks.
  • the traditional PPoV consensus algorithm generates block group headers, the voting nodes cannot perform voting operations because the accounting nodes do not generate enough blocks, so that the leading nodes cannot receive the voting results and cannot generate blocks.
  • the group header, the method of obtaining the block group header during the above-mentioned timeout processing is a supplement and improvement to the traditional PPoV consensus process, which increases the robustness of the blockchain and enables the blockchain network to meet abnormal conditions. Runs normally and produces blocks.
  • This embodiment also provides an apparatus for acquiring a block group header, which is used to implement the above-mentioned embodiment and other implementation manners, which have been described and will not be repeated.
  • the term "module” may be a combination of software and/or hardware that implements a predetermined function.
  • the devices described in the following embodiments are preferably implemented in software, implementations in hardware, or a combination of software and hardware, are also possible and contemplated.
  • FIG. 8 is a structural block diagram of an apparatus for obtaining a block group header according to an embodiment of the present invention, the apparatus includes:
  • the first determination module 82 is configured to determine whether the target node in the blockchain system satisfies a preset condition, wherein the preset condition is used to indicate at least one of the following: the target node has received the block group header And the preset number of legal blocks has not been received, and the target node has not received the block group header;
  • the second determining module 84 is configured to, in the case of determining that the target node has not received the block group header, determine the event cause that the target node has not received the block group header, wherein the event cause includes the following At least one of: the target node has not successfully received the block group header, and the block chain system has not generated a block group header;
  • the third determination module 86 is configured to determine, according to the event cause, the acquisition method of the block group header that has not been received by the target node.
  • the target node of the blockchain system satisfies the preset conditions, and the preset conditions have two cases.
  • One is that the target node has received the block group header but has not received the preset number of legal areas. block, another case is that the target node did not receive the block group header.
  • Two different strategies are formulated according to these two situations. In the case of not receiving the block group header, determine the event cause of not receiving the block group header, and then determine that the target node has not received the block group header according to the event cause. How to get the block group header of .
  • the above technical solution solves the problem that the parallel voting proof PPoV consensus algorithm has a low acquisition rate in the process of acquiring block group headers, and then when acquiring block group headers, different acquisition methods are used according to different event reasons, which improves the performance of the block group header.
  • the fetch rate of block group headers is not limited to the process of acquiring block group headers.
  • condition one the target node has received the block group header and has not received the preset number of legal blocks.
  • Condition 2 The target node does not receive the block group header.
  • the target node in the blockchain system needs to judge whether the preset conditions are met. If not, a timeout will be triggered, and the target node will perform the relevant timeout operation. The target node does not receive the block group header.
  • the event cause that the target node does not receive the block group header, wherein the event cause includes at least one of the following: the target node fails to receive the block group header successfully, and the blockchain system If the block group header is not generated, then the blockchain system will determine how the target node obtains the block group header that has not been received according to the cause of the event. For example, a certain accounting node A in the blockchain system does not receive the block group header, so accounting node A will trigger a timeout operation, request its blockchain height from all voting nodes, and maintain the online status of each voting node locally.
  • the accounting node A will then determine the acquisition method according to the event cause.
  • the third determination module 86 is further configured to synchronize with the voting node of the blockchain system when the event cause indicates that the target node has not successfully received the block group header Get the block group header that was not successfully received.
  • the target node if the target node does not receive the block group header, the target node will go to the voting node to request the block group header. Because the voting node is the core consensus point of the blockchain network, it is considered to have the latest If the system generates a block group header, the voting node will definitely receive it during the broadcast of the generated block group header to the blockchain network. For example, if billing node A does not receive the block group header, billing node A will go to voting node B for data synchronization to obtain the block group header. The blockchain height of voting node B is higher than that of billing node A. high.
  • the block chain height is used to indicate the block height.
  • the blockchain height can be understood as a database. Since the blockchain system is a distributed system without a unified database, it can be understood that each blockchain node has a database. The height of the voting node blockchain is higher than that of the local blockchain, which means that the database update degree of the voting node is better than that of the accounting node database. Therefore, in order to obtain the block group header, it is necessary to obtain the block group header from the database with a poor update degree. Data synchronization in a good database.
  • the third confirmation module 86 is further configured to instruct the voting node to vote on the received block when the cause of the event indicates that the block chain system does not generate a block group header, and to The processing result of the unreceived legal block is set as the target value to indicate that the voting node has no opinion on the unreceived legal block, and the voting result of the voting node is obtained; the voting result is sent to The rotating accounting node to instruct the rotating accounting node to generate the unreceived legal block group header.
  • the accounting node when the accounting node requests the height of its blockchain from all voting nodes, it does not find that the height of the blockchain of the voting node is higher than that of the local blockchain of the accounting node, Therefore, it can be understood that the block chain system does not generate a block group header.
  • all voting nodes are instructed to vote for the blocks received from the accounting nodes, and at the same time, the legal blocks that have not been received will be processed.
  • the result is set as the target value to indicate that the voting node has no opinion on the unreceived block, and the voting node sends all voting results to the rotating accounting node for statistics, so that the rotating accounting node generates a block group head.
  • voting node X, voting node Y, and voting node Z respectively generate a voting information table for the rotating accounting node M, and the rotating accounting node M collects statistics, thereby generating a block group header.
  • the rotating accounting node can only apply for the block group after receiving more than 2N v /3 voting information from the voting nodes. Count each block and generate statistical results. If the number of voting nodes that agree with any legal block exceeds 1N v /3, the rotating accounting node agrees to generate the any legal block. Set its voting result to 1, otherwise the rotating bookkeeping node does not agree to generate any of the legal blocks, and its voting result is set to -1.
  • the N v is the number of the voting nodes in the blockchain system.
  • the existing voting node X, voting node Y, voting node Z, voting node W, and rotating accounting node M can generate statistical results only after receiving the voting information of at least three voting nodes among the four voting nodes. , and any block is allowed to be produced only if at least two of the four voting nodes vote to agree.
  • the rotating checkout node After the rotating accounting node generates a valid block group header, the rotating checkout node broadcasts the generated block group header to all nodes in the blockchain system to instruct all nodes to verify the generated block group header. , when all nodes are verifying, only the block group header that contains more than 2N v /3 votes can pass the verification, and in the case of passing the verification, it will receive the successfully generated block group header.
  • the target node successfully receives the target group header, but does not receive a preset number of legal blocks, it sends an acquisition request to other nodes in the blockchain system, wherein, The acquisition request is used to acquire the legal block from the other node, the other node is a node other than the target node in the blockchain system, and the other node saves the legal block block.
  • accounting node A successfully received the block group header after the PPoV consensus ended, but did not receive enough blocks due to network failure, such as not receiving block b and block c, the accounting node at this time A will broadcast to other nodes in the blockchain network to obtain blocks b and c that have not been received.
  • Embodiments of the present invention further provide a computer-readable storage medium, where a computer program is stored in the computer-readable storage medium, wherein the computer program is configured to execute the steps in any of the above method embodiments when running.
  • the above-mentioned storage medium may be configured to store a computer program for performing the following steps:
  • S1 determine whether the target node in the blockchain system satisfies a preset condition, wherein the preset condition is used to indicate at least one of the following: the target node has received the block group header and has not received the preset number , the target node has not received the block group header;
  • the event cause includes at least one of the following: the target node The node fails to receive the block group header, and the block chain system does not generate the block group header;
  • S3 Determine, according to the event cause, the acquisition method of the target node for the unreceived block group header.
  • the above-mentioned computer-readable storage medium may include, but is not limited to, a USB flash drive, a read-only memory (Read-Only Memory, referred to as ROM for short), a random access memory (Random Access Memory, referred to as RAM for short), a mobile Various media that can store computer programs, such as hard disks, magnetic disks, or optical disks.
  • ROM Read-Only Memory
  • RAM Random Access Memory
  • An embodiment of the present invention also provides an electronic device, comprising a memory and a processor, where a computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any of the above method embodiments.
  • the above-mentioned processor may be configured to perform the following steps through a computer program:
  • S1 determine whether the target node in the blockchain system satisfies a preset condition, wherein the preset condition is used to indicate at least one of the following: the target node has received the block group header and has not received the preset number , the target node has not received the block group header;
  • the event cause includes at least one of the following: the target node The node fails to receive the block group header, and the block chain system does not generate the block group header;
  • S3 Determine, according to the event cause, the acquisition method of the target node for the unreceived block group header.
  • the electronic device may further include a transmission device and an input/output device, wherein the transmission device is connected to the processor, and the input/output device is connected to the processor.
  • modules or steps of the present invention can be implemented by a general-purpose computing device, and they can be centralized on a single computing device or distributed in a network composed of multiple computing devices
  • they can be implemented in program code executable by a computing device, so that they can be stored in a storage device and executed by the computing device, and in some cases, can be performed in a different order than shown here.
  • the described steps, or they are respectively made into individual integrated circuit modules, or a plurality of modules or steps in them are made into a single integrated circuit module to realize.
  • the present invention is not limited to any particular combination of hardware and software.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Development Economics (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Theoretical Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Educational Administration (AREA)
  • Quality & Reliability (AREA)
  • Game Theory and Decision Science (AREA)
  • Tourism & Hospitality (AREA)
  • Operations Research (AREA)
  • Technology Law (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

一种区块组头的获取方法及装置，存储介质及电子装置，其中，上述方法包括：确定区块链系统中的目标节点是否满足预设条件，其中，预设条件用于指示至少以下之一：目标节点已接收到区块组头且没有接收到预设数量的合法区块，目标节点没有收到区块组头(S402)；在确定目标节点没有收到区块组头的情况下，确定目标节点没有收到区块组头的事件原因，其中，事件原因包括以下至少之一：目标节点未成功收到区块组头，区块链系统未产生区块组头(S404)；根据事件原因确定目标节点对没有收到的区块组头的获取方式(S406)。

Description

区块组头的获取方法及装置，存储介质及电子装置
相关申请的交叉引用
本申请基于申请号为202011488871.4、申请日为2020年12月16日的中国专利申请提出，并要求该中国专利申请的优先权，该中国专利申请的全部内容在此引入本申请作为参考。
技术领域
本发明涉及通信领域，具体而言，涉及一种区块组头的获取方法及装置、存储介质及电子装置。
背景技术
区块链系统是一个历史可追溯，不可篡改，解决多方互信问题的分布式系统。而分布式系统必然为面临着一致性问题，即需要达成共识，分布式系统的共识达成需要依靠可靠的共识算法，而常见的共识算法有工作证明共识算法，实用拜占庭容错算法，并行投票证明算法等。
并行投票证明(Parallel Proof of Vote，简称为PPoV)共识算法中，将区块链节点分为：记账节点、投票节点和领导节点。每个记账节点都产生区块发布到网络中，投票节点收集记账节点产生的区块后进行投票，随后将投票信息汇总发给领导节点，领导节点收集汇总后的投票信息进行统计，将统计结果写入到区块组头中，最后将区块组头发布到网络中。
但PPoV共识算法在产生区块组头的过程中，如果存在少量记账节点故障，那么投票节点就会因为收集不到足够的区块无法进行投票操作，从而领导节点收集不到从投票节点发送过来的投票信息而无法产生区块组头。
针对一些技术方案中，并行投票证明PPoV共识算法在获取区块组头的过程中获取率不高等问题，目前尚未提出有效的解决方案。
发明内容
本发明实施例提供了一种区块组头的获取方法及装置、存储介质及电子装置，以至少在一定程度上解决相关的技术问题之一，包括并行投票证明PPoV共识算法在获取区块组头的过程中获取率不高等问题。
根据本发明实施例的一个方面，提供了一种区块组头的获取方法，包括：确定区块链系统中的目标节点是否满足预设条件，其中，所述预设条件用于指示至少以下之一：所述目标节点已接收到区块组头且没有接收到预设数量的合法区块，所述目标节点没有收到区块组头；在确定所述目标节点没有收到区块组头的情况下，确定所述目标节点没有收到区块组头的事件原因，其中，所述事件原因包括以下至少之一：所述目标节点未成功收到所述区块组头，所述区块链系统未产生区块组头；根据所述事件原因确定所述目标节点对没有收到的所述区块组头的获取方式。
根据本发明实施例的另一个方面，还提供了一种区块组头的获取装置，包括：第一确定模块，被设置成确定区块链系统中的目标节点是否满足预设条件，其中，所述预设条件用于指示至少以下之一：所述目标节点已接收到区块组头且没有接收到预设数量的合法区块，所述目标节点没有收到区块组头；第二确定模块，被设置成在确定所述目标节点没有收到区块组头的情况下，确定所述目标节点没有收到区块组头的事件原因，其中，所述事件原因包括以下至少之一：所述目标节点未成功收到所述区块组头，所述区块链系统未产生区块组头；第三确定模块，被设置成根据所述事件原因确定所述目标节点对没有收到的所述区块组头的获取方式。
根据本发明实施例的又一方面，还提供了一种计算机可读的存储介质，该计算机可读的存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行上述区块组头的获取方法。
根据本发明实施例的又一方面，还提供了一种电子装置，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，上述处理器通过计算机程序执行上述区块组头的获取方法。
附图说明
此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示例性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：
图1是本发明实施例的区块组头的获取方法的计算机终端的硬件结构框图；
图2是根据本发明实施例的PoV共识过程消息传递示意图；
图3是根据本发明实施例的PPoV共识过程示意图；
图4是根据本发明实施例的区块组头的获取方法的流程图；
图5是根据本发明实施例的区块链节点超时触发条件示意图；
图6根据本发明实施例的区块链节点的超时处理模块结构图；
图7根据本发明实施例的区块链节点的超时处理流程图；
图8是根据本发明实施例的区块组头的获取装置的结构框图。
具体实施方式
为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。
需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
本申请实施例中所提供的方法实施例可以在计算机终端或者类似的运算装置中执行。以运行在计算机终端上为例，图1是本发明实施例的一种区块组头的获取方法的计算机终端的硬件结构框图。如图1所示，计算机终端可以包括一个或多个(图1中仅示出一个)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)和用于存储数据的存储器104，在一个实施例中，上述计算机终端还可以包括用于通信功能的传输设备106以及输入输出设备108。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述计算机终端的结构造成限定。例如，计算机终端还可包括比图1中所示更多或者更少的组件，或者具有与图1所示等同功能或比图1所示功能更多的不同的配置。
存储器104可用于存储计算机程序，例如，应用软件的软件程序以及模块，如本发明实施例中的区块组头的获取方法对应的计算机程序，处理器102通过运行存储在存储器104内的计算机程序，从而执行各种功能应用以及数据处理，即实现上述的方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至计算机终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
传输装置106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端的通信供应商提供的无线网络。在一个实例中，传输装置106包括一个网络适配器(Network Interface Controller，简称为NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置106可以为射频(Radio Frequency，简称为RF)模块，其用于通过无线方式与互联网进行通讯。
传统的投票证明(Proof of Vote，简称为PoV)共识算法设计了特定的角色模型，将区块链网络内的节点分类为委员(Commissioner)、管家(Butler)、候选管家(Butler Candidate)和普通用户(Ordinary User)四种角色。所述候选管家可由普通用户申请加入后转变而成，管家由委员投票选举产生，在投票阶段，每个委员需要对各个候选管家进行投票，获票数较多的N b个节点将成为管家节点，管家节点主要负责收集事务和产生区块。
在PoV共识算法中，区块产生的共识过程由一个管家和所有委员共同进行，该管家被称为值班管家，值班管家通过值班管家编号确定。假设委员共有N c个，分别为C1,C2,…,CN c，管家有N b个，分别为B1,B2,…,BN b，图2是根据本发明实施例的PoV共识过程消息传递示意图,图二中的round(r)为第r回合，round(r+1)为第r+1回合，PREPARE为预备，READY为准备,COMMIT为提交，Pre-Block为预区块，Final-Block为最终区块。PoV共识算法把一轮共识划分为Prepare、Ready、Commit和Confirm(确认)四个阶段，其中Confirm阶段为区块提交阶段，不需要传递消息。每个区块包含一个区块头和数量不定的事务，在Prepare阶段，值班管家从事务池中取出一定数量的事务并打包产生预区块并将预区块发送给所有委员。预区块和正式区块的区别在于预区块没有时间戳、委员签名和下一个值班管家编号。委员节点需要对接收到的预区块的区块头和事务所包含的信息进行验证，若验证通过则对预区块头进行签名并将签名发送给值班管家。值班管家在收集到超过N c/2的委员签名后即可将预区块补充完整并发布正式区块。接收到该新发布区块的节点将区块存储在本地区块链中，并对包括值班管家编号在内的相关变量进行更新，从而更换负责进行下一轮共识的值班管家。
和大多数共识算法一样，PoV共识算法每个共识周期从多个候选节点中选择一个节点作 为记账节点并产生区块，因此产生区块的过程是串行进行的，难以支持在大规模集群环境下的高吞吐性能。
为了提高PoV的性能，PPoV共识算法基于并行化思想提出了区块组的概念。区块组由区块组头和区块组体组成，每个区块组头中包含当前区块组的高度和投票结果，区块组体则包含所有通过投票的区块集合。其中，每个区块包含前一区块组的hash值、默克尔根、生成者的公钥、时间戳等信息和事务集合。为了便于理解，PPoV共识一般将区块链节点的身份分别表述为投票节点、记账节点和领导节点。图3是根据本发明实施例的PPoV共识过程示意图，每一轮PPoV共识由以下步骤组成：
S1：每一个记账节点均生成一个区块并发布到网络中。每一个区块链节点收集所有记账节点产生的区块；
S2：当投票节点收集完毕S1中记账节点产生的区块后，对每一个区块的分别投票并生成一个总的投票消息发送给领导节点。投票消息中包含每一个区块的hash值、以及是否同意的意见和签名等信息；
S3：领导节点收集投票节点发送来的投票消息并统计投票结果。当满足每一个区块的赞同意见或者反对意见均超过投票节点数量的一半时，将统计结果以及所有的投票消息存放进区块组头。然后领导节点生成一个随机数，即为下一轮共识周期的领导节点编号，并将其写入区块组头。随后将区块组头发布到网络中；
S4：当区块链节点收到所有记账节点产生的区块以及领导节点产生的区块组头后，将其作为一个区块组存储到数据库当中。
然而，目前PPoV共识算法的设计并不完善。考虑到现实环境下服务器可能因为各种原因发生故障导致无法正常工作，因此在多节点并行记账的情况下，传统的PPoV共识算法可能因为其中的少量记账节点故障导致其他正常节点产生的区块也无法被通过验证和产生，即传统PPoV共识算法会因为一些原因无法产生出区块组头，无法满足可终止性。
为了解决上述技术问题，在本实施例中提供了一种区块组头的获取方法，图4是根据本发明实施例的区块组头的获取方法的流程图，该流程包括如下步骤：
步骤S402，确定区块链系统中的目标节点是否满足预设条件，其中，所述预设条件用于指示至少以下之一：所述目标节点已接收到区块组头且没有接收到预设数量的合法区块，所述目标节点没有收到区块组头；
步骤S404，在确定所述目标节点没有收到区块组头的情况下，确定所述目标节点没有收到区块组头的事件原因，其中，所述事件原因包括以下至少之一：所述目标节点未成功收到所述区块组头，所述区块链系统未产生区块组头；
步骤S406，根据所述事件原因确定所述目标节点对没有收到的所述区块组头的获取方式。
通过上述步骤，确定区块链系统的目标节点是否满足预设条件，其预设条件有两种情况，一种情况是目标节点已接收到区块组头而没有接收到预设数量的合法区块，另一种情况是目标节点没有接收到区块组头。根据这两种情况分别制定两种不同的策略，在没有接收到区块组头的情况下，确定没有接收到区块组头的事件原因，然后根据所述事件原因确定目标节点对没有收到的区块组头的获取方式。采用上述技术方案，解决了并行投票证明PPoV共识算法在获取区块组头的过程中获取率不高等问题，进而在获取区块组头的时候，根据不同事件原因采用不同获取方式，提高了区块组头的获取率。
可以理解的是，PPoV共识算法的共识结束条件是要满足两点，条件一：目标节点已接收到区块组头且没有接收到预设数量的合法区块；条件二：目标节点没有收到区块组头。区块链系统中的目标节点要判断是否满足预设条件，若没有满足，则会触发超时，所述目标节点就要进行相关的超时操作，在所述目标节点没有收到区块组头的情况下，确定所述目标节点没有收到区块组头的事件原因，其中，所述事件原因包括以下至少之一：所述目标节点未成功收到区块组头，所述区块链系统未产生区块组头，随后区块链系统会根据所述事件原因确定目标节点对没有收到的区块组头的获取方式。例如，区块链系统某记账节点A没有收到区块组头，所以记账节点A会触发超时操作，向所有投票节点请求其区块链高度，并在本地维护各个投票节点的在线状态，若存在投票节点区块链高度比记账节点A的本地区块链高度高，则说明记账节点A未成功收到区块组头，若没有寻找到，则表明区块链系统未产生区块组头。随后记账节点A会根据所述事件原因确定获取方式。
同时，上述步骤S406有多种实现方式，在一个实施例中，根据所述事件原因确定所述目标节点对没有收到的所述区块组头的获取方式，包括：在所述事件原因指示为所述目标节点未成功收到所述区块组头的情况下，向所述区块链系统的投票节点同步获取未成功接收到的所述区块组头。在本实施例中，目标节点没有接收到区块组头，则目标节点会去向投票节点去请求获得所述区块组头，因为投票节点是区块链网络核心共识点，因此被认为拥有最新的区块链状态，若系统产生了区块组头，在产生的区块组头广播到区块链网络的过程中，投票节点必然会接收。例如，记账节点A没有接收到区块组头，则记账节点A会去向投票节点B去进行数据同步，获取区块组头，其中，投票节点B的区块链高度比记账节点A高。
在一些实例中，向区块链系统的投票节点同步获取未成功接收到的所述区块组头的过程中，需要从比本地记账节点的区块链高度高的投票节点中获取区块组，所述区块链高度用于指示区块高度。在本实施例中，所述区块链高度可以理解成一个数据库，由于区块链系统是一个分布式系统，没有一个统一的数据库，因此可以理解成每个区块链节点都拥有一个数据库，投票节点区块链高度比本地区块链高度高即表示投票节点的数据库更新程度比记账节点数据库的更新程度要好，所以为了获取区块组头，需要从更新程度差的数据库从一个更新程度好的数据库中进行数据同步。
上述步骤S406还有另一种执行方式，在一个实施例中，根据所述事件原因确定所述目标节点对没有收到的所述区块组头的获取方式，包括：在所述事件原因指示为所述区块链系统未产生区块组头的情况下，指示投票节点对于已接收到的区块进行投票，以及将未收到的合法区块的处理结果设置为目标值，以指示所述投票节点对所述未收到的合法区块无意见，得到所述投票节点的投票结果；将所述投票结果发送至轮值记账节点，以指示所述轮值记账节点产生所述未收到的合法区块组头。在本实施例中，可以理解的是，记账节点在向所有投票节点请求其区块链高度的时候，没有找到所述投票节点区块链高度比记账节点的本地区块链高度高，从而可以理解成区块链系统没有产生出区块组头，此时就指示所有的投票节点对于已接收到的来自记账节点的区块进行投票，同时将未收到的合法区块的处理结果设置为目标值，以表明所述投票节点对所述未收到的区块无意见，投票节点将所有的投票结果发送给轮值记账节点进行统计，从而使轮值记账节点产生出区块组头。例如，现有记账节点A，记账节点B，记账节点C，投票节点X，投票节点Y，投票节点Z，轮值记账节点M。当记账节点A没有从投票节点X，投票节点Y，投票节点Z同步到所需区块组头时，投票节点X，投票节点 Y，投票节点Z会对已经接收到的来自记账节点的区块进行正常投票，假设已经接收到来自记账节点A的区块a和来自记账节点B的区块b，则投票节点X，投票节点Y，投票节点Z会对区块a和区块b进行正常的投票，同时将没有接收到的本应由记账C产生的区块c的投票结果设置为0(无意见)。最后投票节点X，投票节点Y，投票节点Z分别产生一张投票信息表给轮值记账节点M，轮值记账节点M进行收集统计，从而产生出区块组头。
在所述轮值记账节点产生所述未收到的合法区块组头的过程中，轮值记账节点只有在接收到超过来自投票节点的2N v/3投票信息后，才能对区块组中的每一个区块进行统计并生成统计结果，若统计到对于任一合法区块的同意意见的投票节点超过1N v/3，则所述轮值记账节点同意产生所述任一合法区块，将其投票结果设置为1，否则轮值记账节点不同意产生所述任一合法区块，将其投票结果设置为-1。所述N v为所述区块链系统中所述投票节点的数量。例如，现有投票节点X，投票节点Y，投票节点Z，投票节点W，轮值记账节点M只有收到这四个投票节点中至少三个投票节点的投票信息以后才可以进行统计生成统计结果，并且任何一个区块只有这四个投票节点中的至少两个投票同意，所述区块才被允许产生。
所述轮值记账节点产生合法区块组头以后，轮值结账节点向所述区块链系统的所有节点广播产生的区块组头，以指示所述所有节点对产生的区块组头进行验证，所有的节点在进行验证的时候，只有包含了超过2N v/3投票的区块组头才可通过验证，并在验证通过的情况下，接收所述成功产生的区块组头。
可以理解的是，若所述目标节点成功的接收到了目标组头，却没有接收到预设数量的合法区块的情况下，向所述区块链系统中的其他节点发送获取请求，其中，所述获取请求用于从所述其他节点获取所述合法区块，所述其他节点为所述区块链系统中除所述目标节点之外的节点，且所述其他节点保存有所述合法区块。例如，记账节点A在PPoV共识结束以后成功的接收到了区块组头，却因为网络故障没有接收到足够多的区块，如没有接收到区块b和区块c，此时记账节点A会向区块链网络中的其他节点去广播获取没有接收到的区块b和区块c。
显然，上述所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。为了更好的理解上述区块组头的获取方法，以下结合实施例对上述过程进行说明，但不用于限定本发明实施例的技术方案，具体地：
PPoV共识算法把产生一个区块组所需执行的所有操作称为一轮共识。在多节点并行记账的情况下，可能因为其中的少量记账节点故障导致其他正常节点产生的区块也无法被通过验证和产生。通过分析，可能对共识过程直接造成影响的只有记账节点、轮值记账节点和投票节点三类节点。假设在一轮共识的开始时间为t 0，epoch为一个共识回合，每个共识回合的时长为T cut，N epoch为从时刻t 0开始直到当前时刻t共经过的共识回合数：
N epoch＝(t-t 0)％T cut；
图5是根据本发明实施例的区块链节点超时触发条件示意图，如果在一轮共识中，区块链系统中的目标节点区块链系统在一个共识回合epoch的截止时间T cut后仍无法满足提交条件，即无法产生合格区块组，则触发超时，即没有同时接收到该轮共识的区块组的区块组头和所有投票通过的合法区块。
图6根据本发明实施例的区块链节点的超时处理模块结构图；包括计时子模块、投票统计子模块、视图变换子模块和激励子模块。
计时子模块提供当前轮共识的开始时间t 0、结束时间t和一轮共识的时长T cut。
投票统计子模块包括投票节点的投票操作和轮值记账节点的统计操作。具体地，所有投票节点在收到超时消息后执行投票操作并发送给下一个epoch的轮值记账节点。若已经接收到的区块则按照正常方式投票，还没有接收到的区块则把结果设置为0(无意见)，并设其hash值为空。轮值记账节点在接收到来自投票节点超过2N v/3的投票后，对区块组中的每一个区块进行统计并生成统计结果，此时统计规则为：若任意一个编号的区块对于任意一个hash值获得的赞同票超过N v/3，即可视为同意产生区块，其将其投票结果置为1，否则被视为反对产生出区块，将其投票结果设置为-1。其中，N v为投票节点的数量。
视图变换子模块包括节点的数据同步操作和区块组头验证操作。具体地，由于投票节点是网络核心共识节点，因此被认为拥有最新的区块链状态。所有节点需要向所有投票节点请求其区块链高度，并在本地维护各个投票节点的在线状态。若存在投票节点区块链高度比本地区块链高度高，则向该节点请求比本地高度高的区块组以同步数据。当节点接收到新的区块组头时，需要对超时后接收到的区块组头中所包含的投票列表进行验证，只有包含了超过2N v/3投票的区块组头才可通过验证，其中获得超过N v/3赞同票的区块可通过投票，否则均被视为投票不通过。
激励子模块实现了评分机制和奖励机制。具体地，每个投票节点都会维护一张记账节点列表并为其评分，对每一位记账节点的评分代表了对此记账节点的信任程度，也成为投票节点投票的依据之一。每轮任期结束后，记账节点会根据已产生的合法区块及区块组头的数量收到联盟给予的酬劳。
为了更好的解释PPoV共识算法在超时以后如何处理，即如何获取缺失的区块组头和区块，以下结合图7来进行说明，图7根据本发明实施例的区块链节点的超时处理流程图。以记账节点超时处理为例，针对一般无激励场景，具体超时处理可以分为两种情况：
一种情况是记账节点已经接收到合法区块组头，但没有接收到足够的合法区块。这种情况下，已经产生区块组头表明共识已经完成，没有接收到足够的合法区块可能是因为网络故障等原因造成，因此只需向其他节点请求缺少的合法区块即可。
另一种情况是记账节点没有接收到合法区块组头，原因可能是因为轮值记账节点发生故障，也可能是因为其他部分的记账节点故障，所以无法产生出足够多的区块。此时需要执行以下步骤：
步骤一：记账节点需要向所有投票节点请求其区块链高度，并在本地维护各个投票节点的在线状态。若存在投票节点区块链高度比本地区块链高度高，则向该节点请求比本地高度高的区块组以同步数据，然后结束超时处理。否则继续执行下列超时操作；
步骤二：所有投票节点立刻执行投票操作，若已经接收到的区块则按照正常方式投票，还没有接收到的区块则把结果设置为0(无意见)，并设其hash值为空。产生的投票需要发送给下一个epoch的轮值记账节点；
步骤三：轮值记账节点在接收到超过2N v/3的投票后，对区块组中的每一个区块进行统计并生成统计结果，此时统计规则为：若任意一个编号的区块对于任意一个hash值获得的赞同票超过N v/3，即可视为同意产生区块，其将其投票结果置为1，否则被视为反对产生出区块，将其投票结果设置为-1。其中，N v为投票节点的数量；
步骤四：若N epoch>1，即超时两次以上，则需更换轮值记账节点，若超时前记账节点的编号为R 0，则当前轮值记账节点的编号R为(R 0+N epoch-1)％N w。其中，N w为记账节点的 数量；
步骤五：所有节点需要对超时后接收到的区块组头中所包含的投票列表进行验证，只有包含了超过2N v/3投票的区块组头才可通过验证，获得超过N v/3赞同票的区块可通过投票，否则均被视为投票不通过。
针对一般有激励场景，在上述基础上，超时的触发还伴随着记账节点收益的降低。详述如下：
投票证明共识设计了评分机制与奖励机制。在有激励场景中，记账节点参与竞选并生成合法区块的目的主要是为了获取记账手续费。联盟链系统可以通过引入代币解决记账手续费问题，代币的金额单位以及换算与现实货币金额单位以及换算一一对应。联盟成立后将设立一个联盟基金账户地址，对应现实中在银行存放基金的一个现实账户。
评分越高的记账节点有更大的概率获得选票当选领导节点。成功封装合法区块组的领导节点将会按照数量获得对应的金额奖励，从而吸引更多的人加入到记账节点行列中，奖励诚实工作的行为，惩罚作恶的行为，使得系统往越来越安全可靠的方向发展。
每个投票节点都会维护一张记账节点列表并为其评分，评分规则为：
规则一：该投票节点每次验证通过一个区块就会给对应的记账节点加分，如果没有验证通过就会给记账节点扣分甚至清零；
规则二：每次验证通过一个区块组头就会给对应的领导节点加分，如果没有验证通过就会给领导节点扣分甚至清零；
规则三：该记账节点不在线而错过生产区块时，会导致触发超时，则其分数会被所有投票节点减分甚至清零，若联盟协议中对离线行为惩罚比较严重而统一设置为清零，则意味着当此记账节点重新上线的时候，需要重新头开始积分。
记账节点在每一个投票节点那里的分数可能不同，对每一位记账节点的评分代表了对此记账节点的信任程度，也成为投票节点投票的依据之一。每轮任期结束后，记账节点会根据已产生的合法区块及区块组头的数量收到联盟给予的酬劳，让他们有动力取应聘竞选，诚实工作，保持长时间在线。
为了更好的理解其超时处理过程，以下结合两个实施例进行具体说明：
实施例一：在基于并行投票证明共识的无激励转账场景中，假设用户A请求从自己的账户转出一笔资金到用户B的账户。若用户A在Tcut前始终未接收到包含转账是否成功的区块组，则触发超时。具体处理流程为：
S1：用户A首先向所有投票节点请求最新区块链高度，若存在投票节点区块链高度比本地区块链高度高，则向该节点请求比本地高度高的区块组并结束超时处理。否则，用户A向所有投票节点和轮值记账节点发起超时请求；
S2：投票节点在收到超时请求后，立刻执行投票操作，若已经接收到的区块则按照正常方式投票，还没有接收到的区块则把结果设置为0(无意见)，并设其hash值为空。轮值记账节点在接收到超过2N v/3的投票后，对区块组中的每一个区块进行统计并生成统计结果；
S3：用户接收到新的区块组头后，验证用户A到用户B的转账事务获得的赞同票数，若超过N v/3则执行转账操作，否则拒绝执行转账操作。
实施例二：在基于并行投票证明共识的无激励标识注册场景中，假设用户X请求在网络中注册一个新的标识。若用户X在Tcut前始终未接收到包含标识是否注册成功的区块组，则 触发超时。具体处理流程为：
S1：用户X首先向所有投票节点请求最新区块链高度，若存在投票节点区块链高度比本地区块链高度高，则向该节点请求比本地高度高的区块组并结束超时处理。否则，用户X向所有投票节点和轮值记账节点发起超时请求；
S2：投票节点在收到超时请求后，立刻执行投票操作，若已经接收到的区块则按照正常方式投票，还没有接收到的区块则把结果设置为0(无意见)，并设其hash值为空。轮值记账节点在接收到超过2N v/3的投票后，对区块组中的每一个区块进行统计并生成统计结果；
S3：用户接收到新的区块组头后，验证用户X的标识注册事务获得的赞同票数，若超过N v/3则将新的标识信息添加到数据库中。
在上述有激励场景和无激励场景的情况下，针对上述记账节点没有满足预设条件，该处理规则保证了在一个共识轮中必然能够产生出一个合法的区块组，即记账节点接收到合法的区块组头和足够多的区块。而传统的PPoV共识算法在产生区块组头的时候，投票节点会因为记账节点没有产生出足够多是区块而无法进行投票操作，从而使领导节点接收不到投票结果而无法产生区块组头，上述超时处理的过程中获取区块组头的方法是对传统PPoV共识过程的补充和完善，增加了区块链的鲁棒性，使区块链网络在遇到异常情况时也能正常运行并产生区块。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例的方法。
在本实施例中还提供了一种区块组头的获取装置，该装置用于实现上述实施例及其他实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的设备较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。
图8是根据本发明实施例的一种区块组头的获取装置的结构框图，该装置包括：
第一确定模块82，被设置成确定区块链系统中的目标节点是否满足预设条件，其中，所述预设条件用于指示至少以下之一：所述目标节点已接收到区块组头且没有接收到预设数量的合法区块，所述目标节点没有收到区块组头；
第二确定模块84，被设置成在确定所述目标节点没有收到区块组头的情况下，确定所述目标节点没有收到区块组头的事件原因，其中，所述事件原因包括以下至少之一：所述目标节点未成功收到所述区块组头，所述区块链系统未产生区块组头；
第三确定模块86，被设置成根据所述事件原因确定所述目标节点对没有收到的所述区块组头的获取方式。
通过本发明，确定区块链系统的目标节点是否满足预设条件，其预设条件有两种情况，一种情况是目标节点已接收到区块组头而没有接收到预设数量的合法区块，另一种情况是目标节点没有接收到区块组头。根据这两种情况分别制定两种不同的策略，在没有接收到区块组头的情况下，确定没有接收到区块组头的事件原因，然后根据所述事件原因确定目标节点 对没有收到的区块组头的获取方式。采用上述技术方案，解决了并行投票证明PPoV共识算法在获取区块组头的过程中获取率不高等问题，进而在获取区块组头的时候，根据不同事件原因采用不同获取方式，提高了区块组头的获取率。
可以理解的是，PPoV共识算法的共识结束条件是要满足两点，所述第一确定模块82中，条件一：目标节点已接收到区块组头且没有接收到预设数量的合法区块；条件二：目标节点没有收到区块组头。区块链系统中的目标节点要判断是否满足预设条件，若没有满足，则会触发超时，所述目标节点就要进行相关的超时操作，在所述目标节点没有收到区块组头的情况下，确定所述目标节点没有收到区块组头的事件原因，其中，所述事件原因包括以下至少之一：所述目标节点未成功收到区块组头，所述区块链系统未产生区块组头，随后区块链系统会根据所述事件原因确定目标节点对没有收到的区块组头的获取方式。例如，区块链系统某记账节点A没有收到区块组头，所以记账节点A会触发超时操作，向所有投票节点请求其区块链高度，并在本地维护各个投票节点的在线状态，若存在投票节点区块链高度比记账节点A的本地区块链高度高，则说明记账节点A未成功收到区块组头，若没有寻找到，则表明区块链系统未产生区块组头。随后记账节点A会根据所述事件原因确定获取方式。
同时，所述第三确定模块86，还被设置成在所述事件原因指示为所述目标节点未成功收到所述区块组头的情况下，向所述区块链系统的投票节点同步获取未成功接收到的所述区块组头。在本实施例中，目标节点没有接收到区块组头，则目标节点会去向投票节点去请求获得所述区块组头，因为投票节点是区块链网络核心共识点，因此被认为拥有最新的区块链状态，若系统产生了区块组头，在产生的区块组头广播到区块链网络的过程中，投票节点必然会接收。例如，记账节点A没有接收到区块组头，则记账节点A会去向投票节点B去进行数据同步，获取区块组头，其中，投票节点B的区块链高度比记账节点A高。
在一些实例中，向区块链系统的投票节点同步获取未成功接收到的所述区块组头的过程中，需要从比本地记账节点的区块链高度高的投票节点中获取区块组，所述区块链高度用于指示区块高度。在本实施例中，所述区块链高度可以理解成一个数据库，由于区块链系统是一个分布式系统，没有一个统一的数据库，因此可以理解成每个区块链节点都拥有一个数据库，投票节点区块链高度比本地区块链高度高即表示投票节点的数据库更新程度比记账节点数据库的更新程度要好，所以为了获取区块组头，需要从更新程度差的数据库从一个更新程度好的数据库中进行数据同步。
所述第三确认模块86，还被设置成在所述事件原因指示为所述区块链系统未产生区块组头的情况下，指示投票节点对于已接收到的区块进行投票，以及将未收到的合法区块的处理结果设置为目标值，以指示所述投票节点对所述未收到的合法区块无意见，得到所述投票节点的投票结果；将所述投票结果发送至轮值记账节点，以指示所述轮值记账节点产生所述未收到的合法区块组头。在本实施例中，可以理解的是，记账节点在向所有投票节点请求其区块链高度的时候，没有找到所述投票节点区块链高度比记账节点的本地区块链高度高，从而可以理解成区块链系统没有产生出区块组头，此时就指示所有的投票节点对于已接收到的来自记账节点的区块进行投票，同时将未收到的合法区块的处理结果设置为目标值，以表明所述投票节点对所述未收到的区块无意见，投票节点将所有的投票结果发送给轮值记账节点进行统计，从而使轮值记账节点产生出区块组头。例如，现有记账节点A，记账节点B，记账节点C，投票节点X，投票节点Y，投票节点Z，轮值记账节点M。当记账节点A没有从投票节 点X，投票节点Y，投票节点Z同步到所需区块组头时，投票节点X，投票节点Y，投票节点Z会对已经接收到的来自记账节点的区块进行正常投票，假设已经接收到来自记账节点A的区块a和来自记账节点B的区块b，则投票节点X，投票节点Y，投票节点Z会对区块a和区块b进行正常的投票，同时将没有接收到的本应由记账C产生的区块c的投票结果设置为0(无意见)。最后投票节点X，投票节点Y，投票节点Z分别产生一张投票信息表给轮值记账节点M，轮值记账节点M进行收集统计，从而产生出区块组头。
在所述轮值记账节点产生所述未收到的合法区块组头的过程中，轮值记账节点只有在接收到超过来自投票节点的2N v/3投票信息后，才能对区块组中的每一个区块进行统计并生成统计结果，若统计到对于任一合法区块的同意意见的投票节点超过1N v/3，则所述轮值记账节点同意产生所述任一合法区块，将其投票结果设置为1，否则轮值记账节点不同意产生所述任一合法区块，将其投票结果设置为-1。所述N v为所述区块链系统中所述投票节点的数量。例如，现有投票节点X，投票节点Y，投票节点Z，投票节点W，轮值记账节点M只有收到这四个投票节点中至少三个投票节点的投票信息以后才可以进行统计生成统计结果，并且任何一个区块只有这四个投票节点中的至少两个投票同意，所述区块才被允许产生。
所述轮值记账节点产生合法区块组头以后，轮值结账节点向所述区块链系统的所有节点广播产生的区块组头，以指示所述所有节点对产生的区块组头进行验证，所有的节点在进行验证的时候，只有包含了超过2N v/3投票的区块组头才可通过验证，并在验证通过的情况下，接收所述成功产生的区块组头。
可以理解的是，若所述目标节点成功的接收到了目标组头，却没有接收到预设数量的合法区块的情况下，向所述区块链系统中的其他节点发送获取请求，其中，所述获取请求用于从所述其他节点获取所述合法区块，所述其他节点为所述区块链系统中除所述目标节点之外的节点，且所述其他节点保存有所述合法区块。例如，记账节点A在PPoV共识结束以后成功的接收到了区块组头，却因为网络故障没有接收到足够多的区块，如没有接收到区块b和区块c，此时记账节点A会向区块链网络中的其他节点去广播获取没有接收到的区块b和区块c。
本发明的实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。
在本实施例的一些实例中，上述存储介质可以被设置为存储用于执行以下步骤的计算机程序：
S1，确定区块链系统中的目标节点是否满足预设条件，其中，所述预设条件用于指示至少以下之一：所述目标节点已接收到区块组头且没有接收到预设数量的合法区块，所述目标节点没有收到区块组头；
S2，在确定所述目标节点没有收到区块组头的情况下，确定所述目标节点没有收到区块组头的事件原因，其中，所述事件原因包括以下至少之一：所述目标节点未成功收到所述区块组头，所述区块链系统未产生区块组头；
S3，根据所述事件原因确定所述目标节点对没有收到的所述区块组头的获取方式。
在一个实施例中，上述计算机可读存储介质可以包括但不限于：U盘、只读存储器(Read-Only Memory，简称为ROM)、随机存取存储器(Random Access Memory，简称为RAM)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。
本实施例中的具体示例可以参考上述实施例及其他实施方式中所描述的示例，本实施例 在此不再赘述。
本发明的实施例还提供了一种电子装置，包括存储器和处理器，该存储器中存储有计算机程序，该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。
在本实施例的一些实例中，上述处理器可以被设置为通过计算机程序执行以下步骤：
S1，确定区块链系统中的目标节点是否满足预设条件，其中，所述预设条件用于指示至少以下之一：所述目标节点已接收到区块组头且没有接收到预设数量的合法区块，所述目标节点没有收到区块组头；
S2，在确定所述目标节点没有收到区块组头的情况下，确定所述目标节点没有收到区块组头的事件原因，其中，所述事件原因包括以下至少之一：所述目标节点未成功收到所述区块组头，所述区块链系统未产生区块组头；
S3，根据所述事件原因确定所述目标节点对没有收到的所述区块组头的获取方式。
在一个实施例中，上述电子装置还可以包括传输设备以及输入输出设备，其中，该传输设备和上述处理器连接，该输入输出设备和上述处理器连接。
本实施例中的具体示例可以参考上述实施例及其他实施方式中所描述的示例，本实施例在此不再赘述。
显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。
以上所述仅为本发明的一些实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

  1. 一种区块组头的获取方法，包括：
    确定区块链系统中的目标节点是否满足预设条件，其中，所述预设条件用于指示至少以下之一：所述目标节点已接收到区块组头且没有接收到预设数量的合法区块，所述目标节点没有收到区块组头；
    在确定所述目标节点没有收到区块组头的情况下，确定所述目标节点没有收到区块组头的事件原因，其中，所述事件原因包括以下至少之一：所述目标节点未成功收到所述区块组头，所述区块链系统未产生区块组头；
    根据所述事件原因确定所述目标节点对没有收到的所述区块组头的获取方式。
  2. 根据权利要求1所述的方法，其中，根据所述事件原因确定所述目标节点对没有收到的所述区块组头的获取方式，包括：
    在所述事件原因指示为所述目标节点未成功收到所述区块组头的情况下，向所述区块链系统的投票节点同步获取未成功接收到的所述区块组头。
  3. 根据权利要求2所述的方法，其中，向所述区块链系统的投票节点同步获取未成功接收到的所述区块组头，包括：
    从所述区块链系统中确认投票节点，其中，所述投票节点区块链高度比所述目标节点区块链高度高，所述区块链高度用于指示区块高度；
    从所述投票节点同步获取比所述目标节点区块链高度高的所述区块组头。
  4. 根据权利要求1所述的方法，其中，根据所述事件原因确定所述目标节点对没有收到的所述区块组头的获取方式，包括：
    在所述事件原因指示为所述区块链系统未产生区块组头的情况下，指示投票节点对于已接收到的区块进行投票，以及将未收到的合法区块的处理结果设置为目标值，以指示所述投票节点对所述未收到的合法区块无意见，得到所述投票节点的投票结果；
    将所述投票结果发送至轮值记账节点，以指示所述轮值记账节点产生所述未产生的合法区块组头。
  5. 根据权利要求4所述的方法，其中，将所述投票结果发送至轮值记账节点，以指示所述轮值记账节点产生所述未产生的合法区块组头，包括：
    对于所述未产生的合法区块组头对应的任一合法区块，如果所述轮值记账节点统计到所述任一合法区块的同意意见的投票节点超过1N v/3，确定所述轮值记账节点同意产生所述任一合法区块，所述N v为所述区块链系统中所述投票节点的数量。
  6. 根据权利要求1所述的方法，其中，根据所述事件原因确定所述目标节点对没有收到的所述区块组头的获取方式之后，所述方法还包括：
    在所述没有收到的所述区块组头已被成功产生的情况下，指示轮值结账节点向所述区 块链系统的所有节点广播成功产生到的区块组头，以指示所述所有节点对所述成功获取到的区块组头进行验证，并在验证通过的情况下，接收所述成功产生到的区块组头。
  7. 根据权利要求1所述的方法，其中，确定区块链系统中的目标节点是否满足预设条件之后，所述方法还包括：
    在确定所述目标节点已接收到区块组头且没有接收到预设数量的合法区块的情况下，向所述区块链系统中的其他节点发送获取请求，其中，所述获取请求用于从所述其他节点获取所述合法区块，所述其他节点为所述区块链系统中除所述目标节点之外的节点，且所述其他节点保存有所述合法区块。
  8. 一种区块组头的获取装置，包括：
    第一确定模块，被设置成确定区块链系统中的目标节点是否满足预设条件，其中，所述预设条件用于指示至少以下之一：所述目标节点已接收到区块组头且没有接收到预设数量的合法区块，所述目标节点没有收到区块组头；
    第二确定模块，被设置成在确定所述目标节点没有收到区块组头的情况下，确定所述目标节点没有收到区块组头的事件原因，其中，所述事件原因包括以下至少之一：所述目标节点未成功收到所述区块组头，所述区块链系统未产生区块组头；
    第三确定模块，被设置成根据所述事件原因确定所述目标节点对没有收到的所述区块组头的获取方式。
  9. 一种计算机可读的存储介质，包括存储的程序，其中，所述程序运行时执行上述权利要求1至7任一项中所述的方法。
  10. 一种电子装置，包括存储器和处理器，其中，所述存储器中存储有计算机程序，所述处理器被设置为通过所述计算机程序执行所述权利要求1至7任一项中所述的方法。
PCT/CN2021/128716 2020-12-16 2021-11-04 区块组头的获取方法及装置，存储介质及电子装置 WO2022127424A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2023537119A JP7520237B2 (ja) 2020-12-16 2021-11-04 ブロックグループヘッダの取得方法及び装置、記憶媒体、並びに電子装置
US18/257,667 US20240031151A1 (en) 2020-12-16 2021-11-04 Obtaining method and apparatus for block group header, storage medium, and electronic device
KR1020237022466A KR20230112718A (ko) 2020-12-16 2021-11-04 블록 그룹 헤더의 획득 방법 및 장치, 저장 매체 및전자 장치

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202011488871.4A CN114638452A (zh) 2020-12-16 2020-12-16 区块组头的获取方法及装置，存储介质及电子装置
CN202011488871.4 2020-12-16

Publications (1)

Publication Number Publication Date
WO2022127424A1 true WO2022127424A1 (zh) 2022-06-23

Family

ID=81945086

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/128716 WO2022127424A1 (zh) 2020-12-16 2021-11-04 区块组头的获取方法及装置，存储介质及电子装置

Country Status (5)

Country Link
US (1) US20240031151A1 (zh)
JP (1) JP7520237B2 (zh)
KR (1) KR20230112718A (zh)
CN (1) CN114638452A (zh)
WO (1) WO2022127424A1 (zh)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109964446A (zh) * 2018-06-08 2019-07-02 北京大学深圳研究生院 一种基于投票的共识方法
CN110868434A (zh) * 2018-08-27 2020-03-06 深圳金刚链计算技术有限公司 一种多层分片架构的区块链共识方法及系统
US20200092085A1 (en) * 2018-09-18 2020-03-19 Nhn Corporation Blockchain system including a distributed network of a plurality of nodes and a method for achieving an agreement between the plurality of nodes executed by processors of the block chain system
WO2020138532A1 (ko) * 2018-12-27 2020-07-02 서강대학교 산학협력단 사물 인터넷 환경을 위한 동적 블라인드 투표기반의 블록체인 합의방법
CN111368008A (zh) * 2020-05-27 2020-07-03 腾讯科技（深圳）有限公司 基于区块链的数据处理方法、装置、设备及可读存储介质
CN111382456A (zh) * 2020-06-01 2020-07-07 腾讯科技（深圳）有限公司 提案消息处理方法、装置、设备以及存储介质
CN112104482A (zh) * 2020-08-11 2020-12-18 佛山赛思禅科技有限公司 一种基于并行投票的共识方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109165945B (zh) 2018-09-07 2021-04-16 腾讯科技（深圳）有限公司 代表节点设备选举方法、装置、计算机设备及存储介质

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109964446A (zh) * 2018-06-08 2019-07-02 北京大学深圳研究生院 一种基于投票的共识方法
CN110868434A (zh) * 2018-08-27 2020-03-06 深圳金刚链计算技术有限公司 一种多层分片架构的区块链共识方法及系统
US20200092085A1 (en) * 2018-09-18 2020-03-19 Nhn Corporation Blockchain system including a distributed network of a plurality of nodes and a method for achieving an agreement between the plurality of nodes executed by processors of the block chain system
WO2020138532A1 (ko) * 2018-12-27 2020-07-02 서강대학교 산학협력단 사물 인터넷 환경을 위한 동적 블라인드 투표기반의 블록체인 합의방법
CN111368008A (zh) * 2020-05-27 2020-07-03 腾讯科技（深圳）有限公司 基于区块链的数据处理方法、装置、设备及可读存储介质
CN111382456A (zh) * 2020-06-01 2020-07-07 腾讯科技（深圳）有限公司 提案消息处理方法、装置、设备以及存储介质
CN112104482A (zh) * 2020-08-11 2020-12-18 佛山赛思禅科技有限公司 一种基于并行投票的共识方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
MIN, XIN-PING ET AL.: "Permissioned Blockchain Dynamic Consensus Mechanism Based Multi-Centers", CHINESE JOURNAL OF COMPUTERS, vol. 41, no. 5, 31 May 2018 (2018-05-31), pages 1005 - 1020, XP055944483 *

Also Published As

Publication number Publication date
JP7520237B2 (ja) 2024-07-22
US20240031151A1 (en) 2024-01-25
JP2023554090A (ja) 2023-12-26
KR20230112718A (ko) 2023-07-27
CN114638452A (zh) 2022-06-17

Similar Documents

Publication Publication Date Title
CN109255713B (zh) 一种区块链网络中某一时间段内记账权的获取方法
CN109559120B (zh) 基于权重的区块链共识方法、系统、存储介质及电子设备
WO2021244208A1 (zh) 区块链的提案消息处理方法、装置、设备以及存储介质
CN112685796B (zh) 一种基于区块链的区块共识方法以及相关设备
CN107301600B (zh) 一种跨链交易的区块链互联网模型的核心构建方法
CN111131209B (zh) 一种改进的高效共识方法、系统、计算机设备及存储介质
CN111106942A (zh) 一种基于ap-pbft算法的区块链信用机制
CN111010278B (zh) 一种基于DPoS高容错分层共识方法
CN111314067B (zh) 区块存储方法、装置、计算机设备及存储介质
CN110796547A (zh) 一种基于联盟区块链的改进的实用拜占庭容错系统
CN112104482B (zh) 一种基于并行投票的共识方法
CN113141414B (zh) 一种cnfs协议中区块链节点的分组多链异步共识方法
CN111682942B (zh) 一种应用于许可链的二元加权拜占庭容错共识方法
WO2021135934A1 (zh) 一种区块链记账方法、装置、节点及存储介质
CN107153646B (zh) 一种数据处理方法和设备
CN112492016B (zh) 一种跨进程可扩展的共识方法及系统
CN109919760A (zh) 基于投票机制的拜占庭容错共识算法
CN113179168A (zh) 一种区块链的跨链交互方法
CN112069259A (zh) 一种基于区块链的多云环境数据存储系统及方法
CN109978528B (zh) 一种可插拔共识协议框架模型、共识协议及其实现方法
CN114936253A (zh) 区块链的共识方法及装置、电子设备、存储介质
WO2022127424A1 (zh) 区块组头的获取方法及装置，存储介质及电子装置
CN114172680A (zh) 一种基于节点信誉机制的区块链系统及其运行方法
CN112511312A (zh) 一种可组装的共识方法及系统
CN116260826A (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: 21905353

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 18257667

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2023537119

Country of ref document: JP

ENP Entry into the national phase

Ref document number: 20237022466

Country of ref document: KR

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 30.10.2023)

122 Ep: pct application non-entry in european phase

Ref document number: 21905353

Country of ref document: EP

Kind code of ref document: A1