WO2022217807A1 - 区块链共识节点选择方法、装置、计算机设备和存储介质 - Google Patents

区块链共识节点选择方法、装置、计算机设备和存储介质 Download PDF

Info

Publication number
WO2022217807A1
WO2022217807A1 PCT/CN2021/114421 CN2021114421W WO2022217807A1 WO 2022217807 A1 WO2022217807 A1 WO 2022217807A1 CN 2021114421 W CN2021114421 W CN 2021114421W WO 2022217807 A1 WO2022217807 A1 WO 2022217807A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
verification
information
nodes
candidate
Prior art date
Application number
PCT/CN2021/114421
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 广东电网有限责任公司
Publication of WO2022217807A1 publication Critical patent/WO2022217807A1/zh

Links

Images

Classifications

    • 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/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • 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/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • 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/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
    • 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

Definitions

  • the present application relates to the field of blockchain technology, and in particular, to a method, device, computer equipment and storage medium for selecting a blockchain consensus node.
  • the blockchain is a decentralized distributed system, and all nodes in the network jointly maintain a public ledger that holds all the data in the network, so the consensus algorithm is the core of the blockchain. Its function is to fairly select the designated node to package the transaction into a block, and add the block to the blockchain. Other nodes in the network agree with this operation, so that all nodes in the blockchain network maintain the same consistency.
  • the consensus algorithm allows the blockchain to run stably without a central authority, so its security directly determines the security of the blockchain system.
  • the method of selecting consensus node members is usually adopted, and the nodes in the consensus node members are responsible for the generation of blocks for a certain period of time, and other nodes agree with and follow the block results generated by the consensus node members.
  • the selection method of consensus nodes is usually through DPoS (Delegated Proof of Stake) or PBFT (Practical Byzantine Fault Tolerance, practical Byzantine Fault Tolerance).
  • DPoS Delegated Proof of Stake
  • PBFT Practical Byzantine Fault Tolerance, practical Byzantine Fault Tolerance
  • the current blockchain consensus node selection method has the defect of low security.
  • a blockchain consensus node selection method applied to nodes in a blockchain network, the method comprising:
  • the blockchain task start signal In response to the blockchain task start signal, generate verification information corresponding to the node, and broadcast the verification information to other nodes in the blockchain network; the verification information is based on a preset verifiable random function and the node The node information is obtained;
  • the node is determined to be a candidate node; the first verification pass information is that the other nodes under the first verification condition The information returned when the verification information is verified;
  • the second verification pass information returned from the set number of candidate nodes among the other candidate nodes is received, it is determined that this candidate node is the master node of this round of blockchain tasks; the second verification pass information is the other The information returned when the candidate node verifies the verification information successfully under the second verification condition.
  • the generating the verification information corresponding to the node includes:
  • the health value corresponding to this node is based on the node information of this node and the degree of participation of this node in each round of blockchain tasks and sending messages are consistent degree obtained;
  • the verification information is obtained.
  • the preset verifiable random function includes a hash generation function and a proof generation function
  • the hash output value and the proof value corresponding to the node are obtained, including:
  • the output result is used as the hash output value, and the private key is input into the certificate generation function to obtain the certificate value output by the certificate generation function.
  • the obtaining the health value corresponding to the node includes:
  • the current node is a candidate node in the previous round of blockchain tasks, and the current node has sent the same consensus information to other nodes in the previous round of blockchain tasks, and the consensus information is the same as the final consensus If the results are consistent, according to the health value function of the first candidate node and the health value of the previous round corresponding to the current node, the health value corresponding to the current node in the current round of blockchain tasks is obtained;
  • the current node is a candidate node in the previous round of blockchain tasks, and the current node does not send the consensus information and/or the The consensus information of the node is inconsistent with the final consensus result and/or the node sends different consensus information to different other nodes, according to the health value function of the second candidate node and the corresponding upper node of the node.
  • One round of health value get the health value corresponding to the node described in the current round of blockchain tasks;
  • the current node is the master node in the previous round of blockchain tasks, and the current node generates new blocks in the previous round of blockchain tasks, according to the health value function of the first master node and the The health value of the previous round corresponding to the node is obtained, and the health value corresponding to the node described in the current round of blockchain tasks is obtained;
  • the health value corresponding to the current node in the current round of blockchain tasks is obtained.
  • the preset verifiable random function includes a hash verification function and a proof verification function
  • the method also includes:
  • the verification information includes the digital signature, hash output value, proof value and health value corresponding to the other nodes;
  • the hash verification function and the proof verification function determine whether the hash output value and the proof value corresponding to the other nodes are correct
  • the digital signature corresponding to the other node If the digital signature corresponding to the other node is correct, the hash output value and the proof value corresponding to the other node are correct, and the health value corresponding to the other node is greater than or equal to the preset health value threshold, determine the The other nodes mentioned above pass the verification;
  • the first verification pass information is generated and returned to the other nodes, so that the other nodes can receive at least one of the first verification pass information and the other
  • the digital signature corresponding to the node generates the corresponding first confirmation information and sends it to the node
  • the first confirmation information sent by the other nodes and determine whether at least one first verification pass information in the first confirmation information is correct and whether the digital signatures corresponding to the other nodes are correct; if the at least one first verification information is correct When the information is correct and the digital signature corresponding to the other node is correct, the first state change confirmation information is sent to the other node, so that the other node determines that the other node is a candidate according to the first state change confirmation information node.
  • determining the current node as a candidate node includes:
  • the method further includes:
  • the method further includes:
  • the verification information includes the corresponding digital signature, hash output value, proof value and health value of the other candidate node;
  • the hash verification function and the proof verification function determine whether the hash output value and the proof value corresponding to the at least one other candidate node are correct
  • the hash output value corresponding to the at least one other candidate node and the proof value are correct, obtain the corresponding data of each other candidate node in the at least one other candidate node health value;
  • the second verification passing information is generated and sent to the other candidate nodes that have passed the verification, so that the other candidate nodes can receive at least one of the second verification passing information, generate the corresponding second confirmation information and send it to the node;
  • determining that the candidate node is the master node of the current round of blockchain tasks includes:
  • the method further includes:
  • a block chain consensus node selection device applied to nodes in a block chain network, the device includes:
  • the first broadcast module is used to generate verification information corresponding to the node in response to the blockchain task start signal, and broadcast the verification information to other nodes in the blockchain network; the verification information is based on a preset The verifiable random function and the node information of this node are obtained;
  • the first determination module is configured to determine that this node is a candidate node if the first verification pass information returned from a set number of nodes in the other nodes is received; the first verification pass information is that the other nodes are in the information returned when the verification information is verified under the verification conditions;
  • a second broadcast module configured to broadcast the verification information to other candidate nodes in the blockchain network
  • the second determination module is configured to determine that the candidate node is the master node of the current round of blockchain tasks if the second verification pass information returned from the set number of candidate nodes among the other candidate nodes is received; the second The verification pass information is the information returned by the other candidate nodes when the verification information passes the verification under the second verification condition.
  • a computer device includes a memory and a processor, the memory stores a computer program, and the processor implements the steps of the above method when the processor executes the computer program.
  • the above-mentioned blockchain consensus node selection method, device, computer equipment and storage medium by broadcasting the verification information of this node to other nodes in the blockchain when a node change is required, and setting it in the received other nodes
  • the node is determined to be a candidate node; when the node is a candidate node, the verification information of the candidate node is broadcast to multiple candidate nodes in the candidate node set, and after receiving information from other nodes
  • the candidate node is determined to be the master node.
  • this scheme uses verification information based on various node information and verifiable random functions to perform multiple rounds of verification, which improves the randomness of node selection. Network attacks through prediction nodes are prevented, thereby achieving the effect of improving node security.
  • 1 is an application environment diagram of a method for selecting a blockchain consensus node in one embodiment
  • FIG. 2 is a schematic flowchart of a method for selecting a blockchain consensus node in one embodiment
  • FIG. 3 is a schematic flowchart of a method for selecting a blockchain consensus node in another embodiment
  • FIG. 4 is a schematic flowchart of a candidate node selection step in one embodiment
  • FIG. 5 is a schematic flowchart of data interaction in a candidate node selection step in one embodiment
  • FIG. 6 is a schematic flowchart of a master node selection step in one embodiment
  • FIG. 8 is a structural block diagram of an apparatus for selecting a blockchain consensus node in one embodiment
  • Figure 9 is a diagram of the internal structure of a computer device in one embodiment.
  • the blockchain consensus node selection method provided in this application can be applied to the application environment shown in FIG. 1 .
  • the server 102 and the server 104 may be nodes set in the same blockchain, the server 102 may be a node, and the server 104 may be formed by a server cluster composed of multiple nodes.
  • Server 102 communicates with server 104 over a network.
  • the server 102 can obtain the verification information corresponding to the node of the server 102 when a node needs to be selected in the blockchain, for example, when the blockchain task is started, and broadcast the verification information to other nodes in the server 104, and the other nodes in the server 104 verify the verification information.
  • the first verification pass information can be returned to the server 102 to obtain the first verification result.
  • the server 102 When the first verification result meets the preset candidate node selection conditions, for example, when the number of nodes sending the information reaches the set number , determine that the node of the server 102 is a candidate node, and broadcast the above-mentioned verification information to other candidate nodes in the candidate node set, such as other candidate nodes in the server 104, other candidate nodes can use the second verification condition to verify that the above-mentioned verification information passes after passing , returns the second verification pass information to the candidate node of the server 102, and the server 102 obtains the second verification result based on the second verification pass information.
  • the server 102 and the server 104 may be implemented by an independent server or a server cluster composed of multiple servers.
  • a method for selecting a blockchain consensus node is provided, which is described by taking the method applied to the server in FIG. 1 as an example, including the following steps:
  • Step S202 in response to the blockchain task start signal, generate verification information corresponding to the node, and broadcast the verification information to other nodes in the blockchain network; the verification information is based on a preset verifiable random function and the node's Node information is obtained.
  • both the server 102 and the server 104 may be nodes set in the same blockchain
  • the server 102 may be a node in the above-mentioned blockchain
  • the server 104 may be composed of servers corresponding to multiple nodes in the blockchain
  • the server 102 is taken as the node as an example. Consensus is usually required in the blockchain, so that a master node is selected from each node in the blockchain to perform blockchain tasks, such as being responsible for tasks such as block generation, verification, and submission.
  • a node consensus process needs to be performed.
  • the server 102 can generate the verification information of the node corresponding to the server 102 when detecting the blockchain task start signal, and broadcast the verification information to the block where the node is located.
  • At least one other node in the chain sends the verification information to at least one other node in the server 104, and the at least one other node can each receive the verification information sent by the server 102, and verify the verification information according to the first verification condition, and It is determined whether information needs to be returned to the above-mentioned server 102 according to the verification result. For example, when the above-mentioned verification is passed, each other node can return the first verification pass information to the server 102 .
  • the above verification information may be obtained based on a preset verifiable random function and node information corresponding to this node.
  • generating the verification information corresponding to the current node includes: obtaining the hash output value and the proof value corresponding to the current node according to a preset verifiable random function; obtaining the health value corresponding to the current node and the corresponding The public key and the digital signature corresponding to this node; the health value is obtained based on the node information of this node and the participation of this node in each round of blockchain tasks and the consistency of sending messages; according to the health value, current time, public key, The hash output value and the proof value are encrypted by digital signature to obtain verification information.
  • the server 102 may calculate and obtain the hash output value and the proof value of the node corresponding to the server 102 based on a preset verifiable random function.
  • the verifiable random function can be a function used for verification, which can generate a specific output according to a specific input, and the output can be verified as a set of functions generated by a certain node.
  • the role of the verifiable random function is: Verify that a random number is indeed generated by the node that issued the random number.
  • the server 102 can also obtain the health value corresponding to the node, the public key corresponding to the node, and the digital signature corresponding to the node, and according to the health value; the sending time of the verification information, that is, the current time; the public key of the node; the calculated The hash output value and the proof value are then encrypted by the digital signature of the node to obtain the verification information.
  • the health value can be embedded in each node through a smart contract and invoked through a consensus protocol.
  • the health value of a node can be based on the node information of the node and the participation of the node in each round of blockchain tasks and the message sent.
  • the current time can be the time when the above verification information is sent;
  • the public key can be the public key corresponding to the node, and the public key is the key used with the private key algorithm
  • the non-secret half of the pair, the public key and the private key are a key pair (that is, a public key and a private key) obtained through an algorithm, one of which is disclosed to the outside world, called the public key; the other is reserved for itself, Known as the private key, the key pair obtained through this algorithm is guaranteed to be unique in the world.
  • this key pair if a piece of data is encrypted with one of the keys, it must be decrypted with the other key. If the data is encrypted with the public key, it must be decrypted with the private key.
  • the hash output value and the proof value can be the values calculated by the preset verifiable random function to confirm that the information is indeed generated by a certain node;
  • the digital signature can be the corresponding value of the node Digital signature, a digital signature is a digital string that can only be generated by the sender of the information and cannot be forged by others. This digital string is also an effective proof of the authenticity of the information sent by the sender of the information. It is realized by the technology in the field of public key encryption. , used to identify digital information. Specifically, the format of the verification information can be as follows:
  • Step S204 if the first verification pass information returned from a set number of nodes in other nodes is received, determine that this node is a candidate node; the first verification pass information is when other nodes pass the verification of the verification information under the first verification condition. information returned.
  • the verification information may be information generated by the node corresponding to the server 102 for node verification, at least one other node in the server 104 may receive the verification information sent from the above-mentioned server 102, and each other node may be based on the first verification information.
  • the condition verifies the verification information, and determines whether the information needs to be returned to the server 102 according to the verification result.
  • the first verification condition may be a verification condition determined based on a digital signature, a hash output value, a certification value, and a health value.
  • the server 102 may receive the first verification pass information returned by at least one other node for the above verification information, and obtain the first verification result based on the received first verification pass information.
  • the first verification pass information may be information generated based on the node information of other nodes that send the verification pass information, and is used to notify the server 102 that the current node has passed the verification.
  • the above-mentioned first verification pass information may include multiple pieces, and the server 102 may obtain the first verification result based on the number of the first verification pass information, and judge the first verification result. If the first verification result meets the preset candidate node selection condition, For example, if the number of nodes sending the first verification passing information reaches the set number, the server 102 may determine that the node is a candidate node.
  • the preset candidate node condition may be a condition formed based on quantity, and the server 102 may determine whether to pass the verification according to the quantity of the received first verification passing information, so as to make the current node a candidate node, for example, when the server 102 receives When the quantity of the first verification passing information is sufficient, the current node can be determined as a candidate node.
  • the format of the above-mentioned first verification pass information may be as follows: ⁇ verify-pass, T, >sig k ; where T represents the time stamp of the returned message to the verified node i by the node verification pass, and sig k represents the verification pass The digital signature of the node to prove that the message was indeed sent by the node.
  • Step S206 broadcasting the verification information to other candidate nodes in the blockchain network.
  • the current node may be a node in the server 102, and the candidate node may be a node whose first verification result meets the preset candidate node selection condition.
  • the candidate node may be added to the candidate node set , the candidate node set includes multiple candidate nodes; and the master node of the current round of blockchain tasks can be selected from the candidate node set.
  • the node of the server 102 After the node of the server 102 becomes a candidate node, it can broadcast the verification information corresponding to the candidate node to at least one other candidate node in the candidate node set where the candidate node is located, that is, other candidate nodes in the blockchain. Authentication information sent by the server 102 .
  • Step S208 if the second verification pass information returned from the set number of candidate nodes in other candidate nodes is received, determine that this candidate node is the master node of this round of blockchain tasks; the second verification pass information is that other candidate nodes are in The information returned when the verification information is verified under the second verification condition.
  • the verification information received by other candidate nodes may include verification information sent by one or more candidate nodes, and the other candidate nodes may verify the received verification information, for example, by verifying through the second verification condition, and determine according to the verification result.
  • the verification information for example, when the verification fails, other candidate nodes can directly delete the verification information; when the verification passes, the other candidate nodes can send the second verification pass information to the candidate nodes of the server 102 .
  • the second verification condition may be based on the digital signatures of all verified candidate nodes, the hash output values of all verified candidate nodes, and all verified candidate nodes. The proof value of the node and the health value of all verified candidate nodes are obtained.
  • the second verification pass information may be sent to the server 102.
  • the information of the node and the digital signature of the other candidate nodes themselves are obtained.
  • the second verification result meets the preset master node selection condition, For example, the number of candidate nodes that send the second verification pass information reaches the set number, and the server 102 can determine that this candidate node is the master node of this round of blockchain tasks, so that all transactions can be packaged into blocks, and the blocks can be added to the blockchain and other operations.
  • the second verification result may be obtained based on the quantity of the second verification passing information received by the server 102
  • the preset master node selection condition may be a condition based on the quantity, for example, when the number of the second verification passing information is sufficient, the server 102 It can be determined that this candidate node is the master node in this round of blockchain tasks.
  • the verification information of this node is broadcast to other nodes in the blockchain, and the first number returned by the set number of nodes in other nodes is received.
  • the verification information is passed, it is determined that this node is a candidate node; when this node is a candidate node, the verification information of this candidate node is broadcast to multiple candidate nodes in the candidate node set, and the set number of received from other candidate nodes is received.
  • the candidate node is determined to be the master node.
  • this scheme uses verification information based on various node information and verifiable random functions to perform multiple rounds of verification, which improves the randomness of node selection. Network attacks through prediction nodes are prevented, thereby achieving the effect of improving node security.
  • obtaining the hash output value and the proof value corresponding to the node according to a preset verifiable random function includes: obtaining the private key corresponding to the node; inputting the private key into the hash generation function, and obtaining the hash value.
  • the output result of the desired generation function if the output result is within the preset threshold range, the output result is used as the hash output value, and the private key is input into the certificate generation function to obtain the certificate value output by the certificate generation function.
  • the above-mentioned preset verifiable random function includes a generation function
  • the generation function includes a hash generation function and a proof generation function.
  • the hash generation function can be used to calculate the hash output value
  • the proof generation function can be used to calculate the proof value.
  • the server 102 can obtain the hash output value and the proof value corresponding to the node by using the above-mentioned hash generating function and proof generating function.
  • the server 102 can obtain the private key corresponding to the node, wherein the private key can be the secret half of the key pair used with the public key algorithm, and the following conditions are met: the public key and the private key appear in pairs; the public key is called The public key, which only one knows is called the private key; the data encrypted with the public key can only be decrypted by the corresponding private key; the data encrypted with the private key can only be decrypted by the corresponding public key; if it can be decrypted with the public key, it must be the corresponding If it can be decrypted with the private key, it must be encrypted with the corresponding public key.
  • the server 102 may input the above-mentioned private key into the hash generation function, and obtain the output result of the hash generation function. For example, the server 102 can use the candidate node C i to calculate the hash output value R i of the candidate node through the hash generating function in the above-mentioned verifiable random function.
  • the server 102 can judge the output result.
  • the server 102 can input the private key into the certificate generation function, and obtain the certificate value output by the certificate generation function. For example, the server 102 may obtain the proof value P i using the proof generation function when R i is within a set threshold range.
  • the server 102 can also publish the calculated R i and P i values to other nodes in the entire network, and at the same time send a digital signature encrypted request verification message to the nodes in the entire network, so that other nodes can verify.
  • the server 102 can also obtain the health value of the node by using a preset function.
  • obtaining the health value corresponding to the current node includes: if the current node was a candidate node in the previous round of blockchain tasks, and the current node sent the same message to other nodes in the previous round of blockchain tasks Consensus information and the consensus information is consistent with the final consensus result, according to the health value function of the first candidate node and the health value of the previous round corresponding to this node, the health value corresponding to this node in this round of blockchain tasks is obtained; It is a candidate node in one round of blockchain tasks, and this node does not send consensus information to other nodes in the previous round of blockchain tasks and/or the consensus information of this node is inconsistent with the final consensus result and/or this node is directed to a different The other nodes of the node send different consensus information, and according to the health value function of the second candidate node and the health value of the previous round corresponding to this node, the health value corresponding to
  • the current round area is obtained.
  • the health value corresponding to this node in the blockchain task if this node was the master node in the previous round of blockchain tasks, and this node did not generate new blocks and/or sent to different other blockchain tasks in the previous round of blockchain tasks Nodes send different consensus information, and according to the health value function of the second master node and the health value of the previous round corresponding to this node, the health value corresponding to this node in this round of blockchain tasks is obtained.
  • the blockchain task may include multiple rounds of tasks, and nodes may be selected for each round of tasks to obtain the master node corresponding to the round of tasks. Since the verifiable random function cannot complete a fixed number of lottery tasks, the threshold of the lottery can only be set according to the weights of all nodes in the system. Therefore, the present invention introduces the health value as the weight of the nodes, and determines the lottery according to the distribution of the health value. quantity. That is, each node can have a corresponding health value.
  • the server 102 can obtain the status of the current node in the previous round of blockchain tasks, including candidate nodes and master nodes.
  • this node is a candidate node in the previous round of blockchain tasks, and this node sent the same consensus information to other nodes in the previous round of blockchain tasks, and the consensus information is consistent with the final consensus result, then this node
  • the health value of the node can be increased.
  • the server 102 can obtain the health value corresponding to this node in the current round of blockchain tasks according to the health value of the previous round corresponding to the node through the health value function of the first candidate node.
  • the server 102 detects that this node is a candidate node in the previous round of blockchain tasks, and this node includes one of the following actions in the previous round of tasks: sending consensus information to other nodes, the sent consensus information and the final consensus result Inconsistent, send different consensus information to different other nodes; then the server 102 can determine that this node needs to reduce the health value, and the server 102 can use the health value of the second candidate node to use the health value of the previous round corresponding to this node to obtain the current round.
  • the second candidate node health value function may be formed by a function group consisting of multiple functions. Specifically, when this node is a candidate node in the previous round of tasks, its corresponding candidate node health value function can be as follows:
  • H i can be the health value of the node
  • t can be the number of rounds of the blockchain task
  • k can be the value set by the system.
  • a candidate node participates in the consensus process, but the message sent is inconsistent with the final result, its health value will also decrease. If it is detected that the same consensus node has sent different information lists, the node will be regarded as a malicious node, its health value will be reduced to 0, and it will be removed from the current candidate node set.
  • the server 102 can use the health value function of the first master node and the corresponding upper node of this node.
  • One round of health value get the health value corresponding to this node in the current round of tasks, for example, input the health value of the previous round into the health value of the first master node above to get the health value of this round.
  • the server 102 detects that this node is the master node in the previous round of blockchain tasks, and this node includes one of the following actions in the previous round of tasks: not generating new blocks, sending different consensus information to different other nodes ; then the server 102 can obtain the health value corresponding to this node in the current round of tasks according to the health value function of the second master node and the health value of the previous round corresponding to this node.
  • the second master node health value function may be a function group composed of multiple functions.
  • the specific functional form of the above-mentioned master node health value function can be as follows:
  • the health value of the master node will increase accordingly, but the health value will not exceed the system.
  • Set the threshold to 1. If the current view number where the master node is located has not changed, the growth rate of the health value of the master node will be slower.
  • the view change protocol is triggered to select the master node for a new round of views. If the master node does not generate a new block or respond to the client's request during the view process, the health value will drop. If the master node sends different information to other candidate nodes, the health value of the master node will be directly reduced to 0, the master node will be kicked out of the candidate node set, and the view change protocol will be triggered to replace the master node and view.
  • the server 102 can use the hash generation function and the proof generation function to obtain the corresponding hash output value and proof value of the node for node verification; and use the candidate node health value function and the master node health value function , get the health value of this node in each round of tasks, and can increase the health value of actively participating nodes, and reduce the health value of malicious nodes or passive nodes, thereby improving the security of the node.
  • it also includes: acquiring verification information sent by other nodes; the verification information includes digital signatures, hash output values, proof values, and health values corresponding to other nodes; Whether the hash output value and proof value corresponding to the node are correct; if the digital signature corresponding to other nodes is correct, the hash output value and proof value corresponding to other nodes are correct, and the health value corresponding to other nodes is greater than or equal to the preset health value threshold , determine that other nodes have passed the verification; according to the digital signature corresponding to this node and the current time, generate the first verification pass information and return it to other nodes, so that other nodes can receive at least one first verification pass information and the corresponding information of other nodes.
  • the above-mentioned preset verifiable random function may include a hash verification function and a proof verification function.
  • the hash verification function can be used to verify the above-mentioned hash output value
  • the proof verification function can be used to verify the above-mentioned proof value.
  • other nodes in the blockchain can also participate in the selection of candidate nodes, and the server 102 can also verify other nodes.
  • the server 102 may obtain verification information sent by other nodes, where the verification information includes digital signatures, hash output values, certification values, and health values of other nodes.
  • the server 102 can verify the verification information of the above-mentioned other nodes, and the verification steps are as follows: after receiving the request verification message from other nodes, it needs to verify whether the signature is correct, verify whether the values of R i and P i are correct, and check the health of the node Whether the value reaches the threshold A.
  • the server 102 may determine that the other nodes pass the verification, and when After the server 102 determines that the node has passed the verification, it can generate the corresponding first verification pass information according to the digital signature corresponding to the node and send it to the above-mentioned other nodes that have passed the verification. For example, after passing the above verification, the verification node will return a verification The passed message is sent to node C i . If the verification fails, no message is returned.
  • the format of the verification pass message is: ⁇ verify-pass, T, > sig k ; where T represents the timestamp of the node verification pass returning the message to the verified node i, and sig k represents the digital signature of the verification node to prove this
  • T represents the timestamp of the node verification pass returning the message to the verified node i
  • sig k represents the digital signature of the verification node to prove this
  • the message is indeed sent by that node.
  • the other node may generate the first confirmation information and send it to the current node according to the received at least one first verification passing information and the digital signature of the other node.
  • the server 102 After receiving the first confirmation information sent by the other node, the server 102 can judge whether at least one first verification passing information in the first confirmation information is correct, and judge whether the digital signature of the other node is correct, if the above at least one If the first verification pass information is correct and the digital signature is correct, the server 102 can send the first state change confirmation information to other nodes, and the other nodes can receive the first state change confirmation information and confirm that the other nodes are candidate nodes. Specifically, at this stage, after the node receives the confirmation message from the verified node, it needs to verify the correctness of all messages in the ⁇ message set and verify whether the signature of node i is correct. After the verification is passed, the node confirms the verified The node has obtained the consensus of most nodes in the network, records the state change of the verified node in the local log, and sends a confirmation message back to the verified node.
  • the server 102 can determine whether a node in the blockchain can become a candidate node through the verification through multi-stage verification, which improves the security of the node.
  • determining the current node as a candidate node includes: receiving the first verification pass information returned by other nodes, and obtaining the first verification pass information. The number of passed information; if the ratio of the number of first verification passed information to the number of nodes in the blockchain is greater than the first preset ratio, the node is determined to be a candidate node.
  • the server 102 may determine the first verification result according to the first verification pass information returned by other nodes. For example, the server 102 may receive a first verification pass message sent from a plurality of other nodes, and each first verification pass message may be based on the digital signature of the node that sends the information and the time at which the first verification pass message is sent. Poke to get. That is, each first verification passing information is unique to its sending node. The server 102 may receive multiple pieces of first verification passing information, and obtain the sum of the received first verification passing information as the first verification result.
  • the server 102 may also use the above-mentioned first verification result to determine whether the current node is a candidate node. For example, the server 102 may use the quantity of the first verification passing information sent by the above-mentioned other nodes as the above-mentioned first verification result. And the server 102 can also determine whether the node is a candidate node based on the first verification result. For example, the server 102 can detect the number of the first verification passing information in the first verification result, and if it is greater than a certain number, it is determined that the first verification result is passed.
  • the server 102 can calculate the number of the first verification passing information and the block The ratio of the number of nodes in the chain, if the ratio is greater than the first preset ratio, it means that most of the nodes in the blockchain agree that this node becomes a candidate node, and the server 102 can determine this node as a candidate node.
  • the server 102 After the server 102 determines that the node is a candidate node, it can send state change information to other nodes, so that other nodes update their own states. For example, in one embodiment, after determining that the present node is a candidate node, the method further includes: sending first confirmation information generated according to the first verification pass information and the digital signature corresponding to the present node to other nodes; obtaining other nodes based on the first confirmation The first state change confirmation information returned by the information confirms that the state of the current node is changed to a candidate node. In this embodiment, after the server 102 determines that the node is a candidate node, the server 102 can generate the first confirmation information according to the above-mentioned first verification passing information and the digital signature corresponding to the node.
  • the verification pass information forms a set, which is encrypted with its own digital signature to form the first confirmation information.
  • the server 102 can send the above-mentioned first confirmation information to other nodes. After receiving the first confirmation information, the other nodes need to verify the correctness of all messages in the ⁇ message set and verify whether the signature of node i is correct.
  • the node confirms that the verified node has obtained the consensus of most nodes in the network, records the status change of the verified node in the local log, and sends a confirmation message back to the verified node.
  • the server 102 may also obtain the first state change confirmation information returned by at least one other node based on the above-mentioned first confirmation information, so as to make the other nodes confirm that the current node is changed to a candidate node.
  • the node Ci of the server 102 receives the first verification pass messages from other nodes in the network, and collects and packages these messages.
  • the node Ci receives the verification pass messages from f+1 different candidate nodes, it means that The node obtains the consent of other nodes to select it as a candidate node, and records this status in its own local log.
  • f is the preset number of fault tolerance in the system.
  • the node joins the candidate node set and will return a first confirmation message to all other nodes.
  • the format of the message is: ⁇ confirm, T, ⁇ >sig i ; wherein, ⁇ is the verification node i received from more than f+1 A set of verification pass messages for different candidate nodes.
  • this node receives the confirmation status change information from other nodes, it officially becomes the selected node and assumes its role in this stage of the system.
  • the server 102 can confirm whether the node is a candidate node based on the three-phase verification protocol, thereby improving the security of the node.
  • the method further includes: obtaining verification information sent by at least one other candidate node within a preset time; the verification information includes the digital signature, hash output value, proof value and health value corresponding to the other candidate nodes; The verification function and the proof verification function are used to determine whether the hash output value and the proof value corresponding to at least one other candidate node are correct; if the digital signature corresponding to at least one other candidate node is correct, the hash output value corresponding to at least one other candidate node and Prove that the value is correct, obtain the health value corresponding to each other candidate node in at least one other candidate node; take the other candidate node with the highest health value as the node that passed the verification; according to the digital signature corresponding to this node, the current time, at least one other candidate node Node information of the node, generate the second verification pass information and send it to other candidate nodes that have passed the verification, so that other candidate nodes can generate the corresponding second confirmation information according to the received at least one second verification pass information and send it to this
  • the server 102 that becomes the candidate node may also perform verification for other candidate nodes, so as to complete the selection of the master node.
  • the candidate node of the server 102 can obtain the verification information sent by at least one other candidate node within a preset time, wherein the verification information of the other candidate node includes the digital signature corresponding to the other candidate node, the hash output value corresponding to the other candidate node, and the other candidate nodes.
  • the proof value corresponding to the node and the health value corresponding to other candidate nodes For example, when the candidate node receives the verification information sent by the first other candidate node, the timer T p can be started. During this time period, the candidate node can continue to receive verification information sent by other candidate nodes. When it stops, no more verification information is received, and the verification information of other candidate nodes received starts to be verified.
  • the server 102 can judge whether the received hash output value and the proof value corresponding to at least one other candidate node are correct according to the hash verification function and the proof verification function in the preset verifiable random function;
  • the functional form of the proof verification function can be as follows: VRF_Verify(PK, M, P); where PK is the public key of the verified node, P is the proof value published by the verified node, R is the hash output calculated by the verified node published by itself; M is a fixed value set by the system.
  • the randomness of the verifiable random function means that the output R of VRF_Hash and the random number are indistinguishable without a given proof P.
  • security can be guaranteed without exposing private information.
  • the preset verifiable random function shown has the following characteristics: for different inputs, the output values are random and uniformly distributed within the range of values; for the same input, the output it obtains must be the same.
  • the server 102 After the server 102 judges the received verification information of other candidate nodes, if it detects that the digital signature in the verification information of the candidate node is incorrect, the server 102 can directly delete the verification information; if the server 102 detects the above verification If the hash output value or the proof value in the information is incorrect, the server 102 can directly delete the verification information. If the server 102 detects that the above-mentioned digital signature, hash output value and certification value are all correct, the server 102 can obtain the received health value corresponding to each other candidate node, and can use the other candidate node with the highest health value as the one that has passed the verification. node.
  • the server 102 can determine that the node is a node that has passed the verification; if the server 102 receives more than one verification message of the other candidate nodes, the server 102 can compare the For each health value in the received verification information, other candidate nodes corresponding to the verification information with the largest health value are regarded as the nodes that have passed the verification.
  • the server 102 can generate the second verification pass information according to the digital signature corresponding to the node, the current time, and the node information of at least one other candidate node, and send the second verification pass information to the pass verification node.
  • the other candidate nodes after receiving the second verification pass information, the other candidate nodes may generate corresponding second confirmation information based on at least one second verification pass information and send it to the node of the server 102 .
  • the nodes have a total of C1-C7 nodes
  • the node of the server 102 is C1
  • the server 102 receives the verification information of C2 and C3, and finally selects C3 as the node that passes the verification, that is, the server 102 selects C3 as the node.
  • the server 102 will return the second verification pass information to the node C3, and the format of the second verification pass information is: ⁇ verify, T, m, ⁇ >sig k ; wherein, T represents that the node verification passes the return message to the verified
  • T represents that the node verification passes the return message to the verified
  • m represents the proof message digest of the candidate node selection C3 of the server 102
  • ⁇ represents the set of request messages received by this candidate node
  • sig k represents the digital signature of this candidate node to prove this The message is indeed sent by this node and cannot be tampered with by others.
  • the server 102 may also receive second confirmation information returned by other candidate nodes according to the foregoing second verification pass information, where the second confirmation information may include a set of all second verification pass information received by the other candidate nodes and the candidate node's digital signature, the server 102 can judge whether the node information of at least one other candidate node in the second confirmation information is correct, and whether the digital signature corresponding to the other candidate nodes is correct, if the node information is correct and the digital signature is correct, the server 102 can send The other candidate node sends the second state change confirmation information, so that after receiving the second state change confirmation information, the other candidate node determines that the other candidate node is the master node in the current round of tasks of the blockchain.
  • the second confirmation information may include a set of all second verification pass information received by the other candidate nodes and the candidate node's digital signature
  • the server 102 when the server 102 receives the second confirmation information sent by other candidate nodes, it can verify that in the second confirmation information, all the second verification pass information in the set formed by all the second verification pass information received by the other node are correct and verify whether the digital signature of the other candidate node is correct. After the verification is passed, the server 102 can determine that the other candidate node has obtained the consensus of most nodes in the network, and the server 102 can record the state change of the master node in the local log , at the same time switch to the view number where the current master node is located, send a confirmation message, such as the second state change confirmation message, and return it to the verified node.
  • a confirmation message such as the second state change confirmation message
  • the server 102 can determine whether a node in the blockchain can become a master node through verification through multi-stage verification, which improves the security of the node.
  • determining that the candidate node is the master node of the current round of blockchain tasks includes: receiving the return from other candidate nodes If the ratio of the number of second verification passing information to the number of nodes in the candidate node set is greater than the second preset ratio, the node is determined to be the master node.
  • the server 102 serving as a candidate node can send the verification information of the candidate node to other candidate nodes, and the other candidate nodes can verify the verification information of the candidate node, and return to the candidate node after the verification is passed. Since there may be multiple other candidate nodes, there may be multiple pieces of second verification pass information received by this candidate node, and the server 102 may obtain the number of received second verification pass information as the number of the above-mentioned first verification pass information. Two verification results. The server 102 can also use the received second verification result to determine whether the candidate node is the master node.
  • the second verification result includes the number of the second verification passing information received by the server 102, and the server 102 may compare the received second verification passing information with all the candidate nodes in the current round of tasks in the blockchain Comparing the number of nodes of the candidate nodes in the formed candidate node set, if the ratio of the number of the second verification passing information to the number of nodes in the candidate node set is greater than the second preset ratio, the server 102 may determine that this node is the master node. For example, in this step, all candidate nodes that meet the VRF output conditions and send the verification information will receive the second verification pass information from other candidate nodes. For example, the server 102 will receive the information sent by other candidate nodes.
  • the second verification pass information, the server 102 can collect and package the information.
  • the server 102 When the server 102 receives the second verification pass information relative to different candidate nodes exceeding 2/3 of the total number of candidate nodes, it means that the candidate nodes of the server 102 have obtained a large number of Some nodes agree to be the master node, and the server 102 can record this status in the local log, switch to the view of the elected master node, and modify the view number.
  • the server 102 may send confirmation information to other candidate nodes.
  • the method further includes: sending the second confirmation information generated according to the second verification pass information and the digital signature corresponding to the current node to other candidate nodes; obtaining other candidate nodes based on the first verification information.
  • the second state change confirmation message returned by the second confirmation message confirms that the state of the current node is changed to the master node.
  • the server 102 after the server 102 determines that the candidate node is the master node, it can form a set of verification pass information according to all the received second verification pass information, and form a set of verification pass information according to the set and the digital signature of the candidate node of the server 102.
  • the second confirmation information is sent to other candidate nodes.
  • the server 102 as the master node can return a confirmation message, such as the second confirmation message, to all other candidate nodes, the format of the message is: ⁇ confirm, T, ⁇ >sig P ; wherein, ⁇ is received by the master node i
  • the set of verification passing messages from other different nodes, sig P is the digital signature of the node.
  • other candidate nodes After receiving the second confirmation information, other candidate nodes can detect the correctness of all the second verification information in the above set, and verify whether the digital signature of the master node that sent the second confirmation information is correct.
  • the candidate node may return the second state change confirmation information to the server 102, and the server 102 may obtain the second state change confirmation information returned by at least one other candidate node based on the second confirmation information, confirming that the state of the current node is changed to the master node, and the server 102 is in
  • After receiving the confirmation status change information from other candidate nodes it officially becomes the master node, assumes its role in this stage of the system, and begins to process incoming requests in the system.
  • the server 102 can confirm whether the current node is the master node based on the three-stage verification protocol, thereby improving the security of the node.
  • FIG. 3 is a schematic flowchart of a method for selecting a blockchain consensus node in another embodiment. It includes the following process: the blockchain system sets the VRF (Verifiable Random Function) output threshold for the first round of candidate node set election, uses the threshold to extract the consensus node committee set from the blockchain system, collects the above candidate node set, and From the candidate node set, the master node of the current round of tasks is selected from the candidate nodes by measuring the health value of the node and the VRF value.
  • FIG. 4 is a schematic flowchart of a candidate node selection step in one embodiment.
  • All nodes in the system use their own private key and random number seed to calculate the local VRF output, that is, use the preset verifiable random function for calculation to obtain the VRF hash output value and VRF proof value. If the calculated hash output value and If the proof value is within the preset threshold range, the node broadcasts its own hash output value and proof value to other nodes, waiting for the whole network to exceed f+1 (f is the fault tolerance number set in the blockchain system) After the consensus of each node is confirmed, it is added to the consensus node committee set, that is, the above-mentioned candidate node set.
  • the verification process of the candidate node may be shown in FIG. 5 , which is a schematic flowchart of data interaction in the candidate node selection step in one embodiment.
  • the candidate node C i uses the VRF_hash(SK, ⁇ ) function in the verifiable random function to calculate the VRF hash output R i of this node. If R i is within the threshold range set by the system, Then the node obtains its own proof value Pi through the proof function VRF_proof(SK, M), and then the node C i publishes the calculated Ri and Pi values to other nodes in the whole network, and sends the request encrypted by the digital signature at the same time. The verification message is sent to the nodes of the whole network. In the verification phase, there are two steps of verification and verification collection.
  • the verification step after receiving the request verification message from the node C i , other nodes need to: verify whether the signature is correct; verify whether the values of R i and P i are correct; check whether the health score of the node reaches the threshold A; After the verification is passed, the verification node will return a verification passed message to the node C i . If the verification fails, no message is returned.
  • the verification collection stage node C i receives verification pass messages from other nodes in the network, and collects and packages these messages.
  • node C i When node C i receives verification pass messages from f+1 different candidate nodes, it means that the The node obtains the approval of other nodes to select it as a candidate node, and records this status in its own local log, the node joins the candidate node set and returns a confirmation message to all other nodes.
  • the confirmation phase it is divided into two steps: confirmation and confirmation collection.
  • the confirmation step includes: after other nodes in the network receive the confirmation message from the verified node, it is necessary to verify the correctness of all messages in the ⁇ message set and verify whether the signature of node i is correct, and after the verification is passed, the node confirms the verified.
  • the node has obtained the consensus of most nodes in the network, records the state change of the verified node in the local log, and sends a confirmation message back to the verified node.
  • the confirmation collection step includes: after the verified node receives the confirmation state change message from other nodes, it officially becomes a candidate node and assumes its role in this stage of the system.
  • FIG. 6 is a schematic flowchart of the selection step of the master node in one embodiment.
  • the master node is generated in the candidate node set.
  • the candidate node starts the second round of VRF calculation. If the calculated hash output meets the requirements of becoming the master node output threshold, the node broadcasts its own VRF output and Proof, requesting authentication from other nodes in the candidate node set.
  • the verification process of the master node can be shown in FIG. 7 , which is a schematic flowchart of data interaction in the selection step of the master node in one embodiment. Including the request phase, the verification phase and the confirmation phase.
  • the verification phase there are two steps of verification and verification collection.
  • the verification step when the other candidate nodes receive the first verification request message, they start the timer T p , and when the timer stops, they no longer receive any verification request messages, and begin to verify the received verification request messages.
  • the process needs: check whether the signatures of all verified nodes are correct, if not, delete the message directly; check whether the values of R p and P p sent by the verified node are correct, if not, delete the message directly; compare the timer
  • the health score value of all the verified nodes received during the time period, and the node with the highest health score is selected as the master node.
  • the C3-C7 verification nodes finally select C1 as the master node, and will return a verification message to the node C1.
  • all candidate master nodes that meet the VRF output conditions and send a request verification message will receive verification pass messages from other candidate nodes, and collect and package these messages.
  • the node receives more than 2/ If the verification messages of three different candidate nodes are passed, it means that the node has obtained the approval of most nodes to be selected as the master node, and records this status in its own local log, switches to the view of its elected master node, and modifies the view number. .
  • the master node then returns an acknowledgment message to all other candidate nodes.
  • the confirmation phase it includes two steps of confirmation and confirmation collection.
  • the confirmation step after receiving the confirmation message from the C1 node, other candidate nodes need to verify the correctness of all messages in the ⁇ message set and verify whether the signature of the master node P is correct. After the verification is passed, the node confirms that the C1 node has obtained the The consensus of most nodes in the network records the state change of the master node in the local log, switches to the view number where the current master node is located, and sends a confirmation message back to the verified node.
  • the confirmation collection step after the verified node receives the confirmation status change message from other nodes, it officially becomes the master node, assumes its role in this phase of the system, and starts to process incoming requests in the system.
  • the nodes in the blockchain system use a verifiable random function to randomly select all nodes, and malicious nodes cannot predict the number of the next master node in advance according to a specific rule. Compared with the node selection method in the prior art , which is more random, thereby improving the security of the node.
  • steps in the flowcharts of FIGS. 2-7 are sequentially displayed according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, the execution of these steps is not strictly limited to the order, and these steps may be performed in other orders. Moreover, at least a part of the steps in FIG. 2-FIG. 7 may include multiple steps or multiple stages, and these steps or stages are not necessarily executed and completed at the same time, but may be executed at different times. The order of execution is also not necessarily sequential, but may be performed alternately or alternately with other steps or at least a portion of the steps or stages within the other steps.
  • a block chain consensus node selection device including: a first broadcast module 500, a first determination module 502, a second broadcast module 504, and a second determination module 506, in:
  • the first broadcasting module 500 is used to generate verification information corresponding to the node in response to the blockchain task start signal, and broadcast the verification information to other nodes in the blockchain network; the verification information is based on a preset verifiable random number The function and the node information of this node are obtained.
  • the first determination module 502 is configured to determine that this node is a candidate node if the first verification pass information returned from a set number of nodes in other nodes is received; Verification information The information returned when the verification is passed.
  • the second broadcasting module 504 is configured to broadcast the verification information to other candidate nodes in the blockchain network.
  • the second determination module 506 is configured to determine that the candidate node is the master node of the current round of blockchain tasks if the second verification pass information returned from a set number of candidate nodes among other candidate nodes is received; the second verification pass information It is the information returned when other candidate nodes pass the verification of the verification information under the second verification condition.
  • the above-mentioned first broadcasting module 500 is specifically configured to obtain, according to a preset verifiable random function, the hash output value and the proof value corresponding to the node; obtain the health value corresponding to the node and the public value corresponding to the node. key and the digital signature corresponding to this node; the health value is obtained based on the node information of this node and the degree of participation of this node in each round of blockchain tasks and the consistency of sending messages; according to the health value, current time, public key, hash The output value and the proof value are encrypted by digital signature to obtain verification information.
  • the above-mentioned first broadcast module 500 is specifically configured to obtain the private key corresponding to the node; input the private key into the hash generation function, and obtain the output result of the hash generation function; if the output result is in the preset Within the threshold range, the output result is used as the hash output value, and the private key is input into the proof generation function to obtain the proof value output by the proof generation function.
  • the above-mentioned first broadcast module 500 is specifically used if the node is a candidate node in the previous round of blockchain tasks, and the node sends the same message to other nodes in the previous round of blockchain tasks Consensus information and the consensus information is consistent with the final consensus result, according to the health value function of the first candidate node and the health value of the previous round corresponding to this node, the health value corresponding to this node in this round of blockchain tasks is obtained; It is a candidate node in one round of blockchain tasks, and this node does not send consensus information to other nodes in the previous round of blockchain tasks and/or the consensus information of this node is inconsistent with the final consensus result and/or this node is directed to a different The other nodes of the node send different consensus information, and according to the health value function of the second candidate node and the health value of the previous round corresponding to this node, the health value corresponding to this node described in the current round of blockchain tasks is obtained; A round of blockchain tasks is the master node, and
  • the current round area is obtained.
  • the health value corresponding to this node in the blockchain task if this node was the master node in the previous round of blockchain tasks, and this node did not generate new blocks and/or sent to different other blockchain tasks in the previous round of blockchain tasks Nodes send different consensus information, and according to the health value function of the second master node and the health value of the previous round corresponding to this node, the health value corresponding to this node in this round of blockchain tasks is obtained.
  • the above device further includes: a first verification module, configured to obtain verification information sent by other nodes; the verification information includes digital signatures, hash output values, certification values, and health values corresponding to other nodes; Verification function and proof verification function, to judge whether the hash output value and proof value corresponding to other nodes are correct; if the digital signature corresponding to other nodes is correct, the hash output value and proof value corresponding to other nodes are correct, and the health corresponding to other nodes is correct The value is greater than or equal to the preset health value threshold, and other nodes are determined to pass the verification; according to the digital signature corresponding to this node and the current time, the first verification pass information is generated and returned to other nodes, so that other nodes can receive at least one Once the verification information and the digital signatures corresponding to other nodes are passed, the corresponding first confirmation information is generated and sent to the node; the first confirmation information sent by other nodes is obtained, and it is determined whether at least one of the first verification information in the first confirmation information is passed.
  • the above-mentioned first determining module 502 is specifically configured to receive the first verification passing information returned by other nodes, and obtain the quantity of the first verification passing information; If the ratio of the number of nodes is greater than the first preset ratio, the node is determined to be a candidate node.
  • the above-mentioned apparatus further includes: a first confirmation module, configured to send the first confirmation information generated according to the first verification pass information and the digital signature corresponding to the current node to at least one other node; obtain at least one other node based on The first state change confirmation information returned by the first confirmation information confirms that the state of the current node is changed to a candidate node.
  • a first confirmation module configured to send the first confirmation information generated according to the first verification pass information and the digital signature corresponding to the current node to at least one other node; obtain at least one other node based on The first state change confirmation information returned by the first confirmation information confirms that the state of the current node is changed to a candidate node.
  • the above device further includes: a second verification module, configured to obtain verification information sent by at least one other candidate node within a preset time; the verification information includes digital signatures and hash output values corresponding to the other candidate nodes , proof value and health value; according to the hash verification function and the proof verification function, determine whether the hash output value and proof value corresponding to at least one other candidate node are correct; if the digital signature corresponding to at least one other candidate node is correct, at least one other The hash output value and the proof value corresponding to the candidate node are correct, and the health value corresponding to each other candidate node in at least one other candidate node is obtained; the other candidate node with the highest health value is regarded as the node that has passed the verification; according to the number corresponding to this node Signature, current time, node information of at least one other candidate node, generate second verification pass information and send it to other candidate nodes that pass the verification, so that other candidate nodes can generate corresponding The second confirmation information is sent to this node; the verification information includes
  • the above-mentioned second determination module 506 is specifically configured to receive the second verification passing information returned by other candidate nodes, and obtain the quantity of the second verification passing information; If the ratio of the number of nodes is greater than the second preset ratio, it is determined that this node is the master node.
  • the above device further includes: a second confirmation module, configured to send the second confirmation information generated according to the second verification pass information and the digital signature corresponding to the current node to other candidate nodes; obtain other candidate nodes based on the second confirmation information.
  • the second state change confirmation message returned by the confirmation message confirms that the state of the current node is changed to the master node.
  • Each module in the above-mentioned block chain consensus node selection device can be implemented in whole or in part by software, hardware and combinations thereof.
  • the above modules can be embedded in or independent of the processor in the computer device in the form of hardware, or stored in the memory in the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.
  • a computer device is provided, and the computer device may be a server, and its internal structure diagram may be as shown in FIG. 9 .
  • the computer device includes a processor, memory, and a network interface connected by a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities.
  • the memory of the computer device includes a non-volatile storage medium, an internal memory.
  • the nonvolatile storage medium stores an operating system, a computer program, and a database.
  • the internal memory provides an environment for the execution of the operating system and computer programs in the non-volatile storage medium.
  • the computer device's database is used to store node data.
  • the network interface of the computer device is used to communicate with an external terminal through a network connection.
  • the computer program when executed by the processor, implements a method for selecting a blockchain consensus node.
  • FIG. 9 is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer equipment to which the solution of the present application is applied. Include more or fewer components than shown in the figures, or combine certain components, or have a different arrangement of components.
  • a computer device including a memory and a processor, a computer program is stored in the memory, and the processor implements the above method for selecting a blockchain consensus node when executing the computer program.
  • a computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a processor, the above-mentioned method for selecting a blockchain consensus node is implemented.
  • Non-volatile memory may include read-only memory (Read-Only Memory, ROM), magnetic tape, floppy disk, flash memory, or optical memory, and the like.
  • Volatile memory may include random access memory (RAM) or external cache memory.
  • RAM can be in various forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM), and the like.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Power Engineering (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Storage Device Security (AREA)

Abstract

本申请涉及一种区块链共识节点选择方法、装置、计算机设备和存储介质。通过将本节点的验证信息广播至区块链中的其他节点，接收到设定数量的第一验证通过信息时，确定本节点为候选节点；当本节点为候选节点时，将本候选节点验证信息广播至候选节点集中的多个候选节点，接受到设定数量的第二验证通过信息时，则确定本候选节点为主节点。相较于传统的通过代理权益证明或实用拜占庭容错算法进行节点选取，本方案通过利用基于多种节点信息以及可验证随机函数形成的验证信息，进行多轮验证，提高了节点选择的随机性，阻止了通过预测节点进行的网络攻击，从而实现提高节点安全性的效果。

Description

区块链共识节点选择方法、装置、计算机设备和存储介质 技术领域
本申请涉及区块链技术领域，特别是涉及一种区块链共识节点选择方法、装置、计算机设备和存储介质。
背景技术
区块链是一个去中心化的分布式系统，由网络中的所有节点共同维护一个持有该网络中所有数据的公共账本，因此共识算法是区块链的核心。它的作用是公平地选出指定的节点把交易打包成区块，并将区块加入区块链，网络中的其它节点都认同该操作，从而使区块链网络中所有节点一致性维护同一条链，共识算法让区块链可以在无需中央机构的环境下稳定的运行，因此它的安全性直接决定了区块链系统的安全性。
随着区块链网络中的节点和交易量越来越多，达成共识的速度和事务处理的速度都会随着节点数量的增多而减慢，因此采用固定的共识算法不适用与现阶段各行业的区块链应用，目前通常采用的是选取共识节点委员的方法，让共识节点委员中的节点负责某段时间区块的产生，其它节点认同且跟随共识节点委员产生的区块结果。目前对于共识节点的选取方式通常是通过DPoS(Delegated Proof of Stake，代理权益证明)或PBFT(Practical Byzantine Fault Tolerance，实用拜占庭容错算法)进行，然而，通过上述方式进行节点选取，容易让攻击者展开网络攻击，破坏区块链节点的一致性。
因此，目前的区块链共识节点选择方法存在安全性不高的缺陷。
发明内容
基于此，有必要针对上述技术问题，提供一种能够提高节点安全性的区块链共识节点选择方法、装置、计算机设备和存储介质。
一种区块链共识节点选择方法，应用于区块链网络中的节点，所述方法包括：
响应于区块链任务启动信号，生成本节点对应的验证信息，并将所述验证信息广播至所述区块链网络中的其他节点；所述验证信息基于预设可验证随机函数以及本节点的节点信息得到；
若接收到来自所述其他节点中设定数量的节点返回的第一验证通过信息，确定本节点为候选节点；所述第一验证通过信息为所述其他节点在第一验证条件下对所述验证信息验证通过时返回的信息；
将所述验证信息广播至所述区块链网络中的其他候选节点；
若接收到来自所述其他候选节点中设定数量的候选节点返回的第二验证通过信息，确定本候选节点为本轮区块链任务的主节点；所述第二验证通过信息为所述其他候选节点在第二验证条件下对所述验证信息验证通过时返回的信息。
在其中一个实施例中，所述生成本节点对应的验证信息，包括：
根据预设可验证随机函数，获取本节点对应的哈希输出值以及证明值；
获取本节点对应的健康数值、本节点对应的公钥以及本节点对应的数字签名；所述健康数值基于本节点的节点信息以及本节点在每轮区块链任务中的参与度以及发送消息一致度得到；
根据所述健康数值、当前时间、所述公钥、所述哈希输出值以及所述证明值，并通过所述数字签名进行加密，得到所述验证信息。
在其中一个实施例中，所述预设可验证随机函数包括哈希生成函数以及证明生成函数；
所述根据预设可验证随机函数，获取本节点对应的哈希输出值以及证明值，包括：
获取本节点对应的私钥；
将所述私钥输入所述哈希生成函数，获取所述哈希生成函数的输出结果；
若所述输出结果在预设阈值范围内，将所述输出结果作为所述哈希输出值，并将所述私钥输入所述证明生成函数，获取所述证明生成函数输出的证明值。
在其中一个实施例中，所述获取本节点对应的健康数值，包括：
若所述本节点在上一轮区块链任务中为候选节点，且所述本节点在所述上一轮区块链任务中向其他节点发送了相同共识信息且所述共识信息与最终共识结果一致，根据第一候选节点健康数值函数以及所述本节点对应的上一轮健康数值，得到本轮区块链任务中所述本节点对应的健康数值；
若所述本节点在上一轮区块链任务中为候选节点，且所述本节点在所述上一轮区块链任务中不向所述其他节点发送所述共识信息和/或所述本节点的共识信息与所述最终共识结果不一致和/或所述本节点向不同的所述其他节点发送不同的所述共识信息，根据第二候选节点健康数值函数以及所述本节点对应的上一轮健康数值，得到本轮区块链任务中所述本节点对应的健康数值；
若所述本节点在上一轮区块链任务中为主节点，且所述本节点在所述上一轮区块链任务中产生新区块，根据第一主节点健康数值函数以及所述本节点对应的上一轮健康数值，得到本轮区块链任务中所述本节点对应的健康数值；
若所述本节点在上一轮区块链任务中为主节点，且所述本节点在所述上一轮区块链任务中未产生新区 块和/或向不同的其他节点发送不同的共识信息，根据第二主节点健康数值函数以及所述本节点对应的上一轮健康数值，得到本轮区块链任务中所述本节点对应的健康数值。
在其中一个实施例中，所述预设可验证随机函数包括哈希验证函数以及证明验证函数；
所述方法还包括：
获取所述其他节点发送的验证信息；所述验证信息包括所述其他节点对应的数字签名、哈希输出值、证明值以及健康数值；
根据所述哈希验证函数以及所述证明验证函数，判断所述其他节点对应的哈希输出值以及证明值是否正确；
若所述其他节点对应的所述数字签名正确、所述其他节点对应的哈希输出值和所述证明值正确、以及所述其他节点对应的健康数值大于或等于预设健康数值阈值，确定所述其他节点通过验证；
根据所述本节点对应的数字签名以及当前时间，生成第一验证通过信息并返回至所述其他节点，以使所述其他节点根据接收到的至少一个所述第一验证通过信息以及所述其他节点对应的数字签名，生成对应的第一确认信息并发送至本节点；
获取所述其他节点发送的第一确认信息，判断所述第一确认信息中的至少一个第一验证通过信息是否正确以及所述其他节点对应的数字签名是否正确；若所述至少一个第一验证通过信息正确且所述其他节点对应的数字签名正确，向所述其他节点发送第一状态更改确认信息，以使所述其他节点根据所述第一状态更改确认信息，确定所述其他节点为候选节点。
在其中一个实施例中，所述若接收到来自所述其他节点中设定数量的节点返回的第一验证通过信息，确定本节点为候选节点，包括：
接收所述其他节点返回的第一验证通过信息，获取所述第一验证通过信息的数量；
若所述第一验证通过信息的数量与所述区块链中的节点数量的比值大于第一预设比值，确定本节点为候选节点；
所述确定本节点为候选节点之后，还包括：
向所述其他节点发送根据所述第一验证通过信息以及本节点对应的数字签名生成的第一确认信息；
获取所述其他节点基于所述第一确认信息返回的第一状态更改确认信息，确认本节点的状态更改为候选节点。
在其中一个实施例中，所述方法还包括：
在预设时间内，获取至少一个其他候选节点发送的验证信息；所述验证信息包括所述其他候选节点对 应的数字签名、哈希输出值、证明值以及健康数值；
根据所述哈希验证函数以及所述证明验证函数，判断所述至少一个其他候选节点对应的哈希输出值以及证明值是否正确；
若所述至少一个其他候选节点对应的数字签名正确、所述至少一个其他候选节点对应的哈希输出值和所述证明值正确，获取所述至少一个其他候选节点中每个其他候选节点对应的健康数值；
将健康数值最高的其他候选节点作为验证通过的节点；
根据所述本节点对应的数字签名、当前时间、所述至少一个其他候选节点的节点信息，生成第二验证通过信息并发送至通过验证的其他候选节点，以使所述其他候选节点根据接收到的至少一个所述第二验证通过信息，生成对应的第二确认信息并发送至本节点；
获取所述其他候选节点发送的第二确认信息，判断所述第二确认信息中的至少一个其他候选节点的节点信息是否正确以及所述其他候选节点对应的数字签名是否正确；若所述节点信息正确且所述其他候选节点对应的数字签名正确，向所述其他候选节点发送第二状态更改确认信息，以使所述其他候选节点根据所述第二状态更改确认信息，确定所述其他候选节点为主节点。
在其中一个实施例中，所述若接收到来自所述其他候选节点中设定数量的候选节点返回的第二验证通过信息，确定本候选节点为本轮区块链任务的主节点，包括：
接收所述其他候选节点返回的第二验证通过信息，获取所述第二验证通过信息的数量；
若所述第二验证通过信息的数量与所述候选节点集中的节点数量的比值大于的第二预设比值，确定本节点为主节点；
所述确定本节点为主节点之后，还包括：
向所述其他候选节点发送根据所述第二验证通过信息以及本节点对应的数字签名生成的第二确认信息；
获取所述其他候选节点基于所述第二确认信息返回的第二状态更改确认信息，确认本节点的状态更改为主节点。
一种区块链共识节点选择装置，应用于区块链网络中的节点，所述装置包括：
第一广播模块，用于响应于区块链任务启动信号，生成本节点对应的验证信息，并将所述验证信息广播至所述区块链网络中的其他节点；所述验证信息基于预设可验证随机函数以及本节点的节点信息得到；
第一确定模块，用于若接收到来自所述其他节点中设定数量的节点返回的第一验证通过信息，确定 本节点为候选节点；所述第一验证通过信息为所述其他节点在第一验证条件下对所述验证信息验证通过时返回的信息；
第二广播模块，用于将所述验证信息广播至所述区块链网络中的其他候选节点；
第二确定模块，用于若接收到来自所述其他候选节点中设定数量的候选节点返回的第二验证通过信息，确定本候选节点为本轮区块链任务的主节点；所述第二验证通过信息为所述其他候选节点在第二验证条件下对所述验证信息验证通过时返回的信息。
一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现上述的方法的步骤。
一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述的方法的步骤。
上述区块链共识节点选择方法、装置、计算机设备和存储介质，通过在需要进行节点变更时，将本节点的验证信息广播至区块链中的其他节点，并在接收到其他节点中设定数量的节点返回的第一验证通过信息时，确定本节点为候选节点；当本节点为候选节点时，将本候选节点验证信息广播至候选节点集中的多个候选节点，并在接收到来自其他候选节点中设定数量的候选节点返回的第二验证通过信息时，则确定本候选节点为主节点。相较于传统的通过代理权益证明或实用拜占庭容错算法进行节点选取，本方案通过利用基于多种节点信息以及可验证随机函数形成的验证信息，进行多轮验证，提高了节点选择的随机性，阻止了通过预测节点进行的网络攻击，从而实现提高节点安全性的效果。
附图说明
图1为一个实施例中区块链共识节点选择方法的应用环境图；
图2为一个实施例中区块链共识节点选择方法的流程示意图；
图3为另一个实施例中区块链共识节点选择方法的流程示意图；
图4为一个实施例中候选节点选择步骤的流程示意图；
图5为一个实施例中候选节点选择步骤数据交互的流程示意图；
图6为一个实施例中主节点选择步骤的流程示意图；
图7为一个实施例中主节点选择步骤数据交互的流程示意图；
图8为一个实施例中区块链共识节点选择装置的结构框图；
图9为一个实施例中计算机设备的内部结构图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。
本申请提供的区块链共识节点选择方法，可以应用于如图1所示的应用环境中。其中，服务器102以及服务器104可以是设置于同一区块链中的节点，服务器102可以是一个节点，服务器104可以是由多个节点组成的服务器集群形成。服务器102通过网络与服务器104进行通信。服务器102可以在区块链中需要选取节点时，例如区块链任务启动时，获取服务器102节点对应的验证信息，并将验证信息广播至服务器104中的其他节点，服务器104中的其他节点验证上述验证信息通过后，可以向服务器102返回第一验证通过信息，从而得到第一验证结果，当第一验证结果符合预设候选节点选择条件时，例如发送该信息的节点数量达到设定数量时，确定服务器102的节点为候选节点，并将上述验证信息广播至候选节点集中的其他候选节点，如服务器104中的其他候选节点，其他候选节点可以在利用第二验证条件验证上述验证信息通过后，向服务器102的候选节点返回第二验证通过信息，服务器102基于第二验证通过信息得到第二验证结果，若第二验证结果符合主节点选择条件，例如发送该信息的候选节点数量达到设定数量时，则确定服务器102的候选节点为本轮区块链任务的主节点。其中，服务器102以及服务器104可以用独立的服务器或者是多个服务器组成的服务器集群来实现。
在一个实施例中，如图2所示，提供了一种区块链共识节点选择方法，以该方法应用于图1中的服务器为例进行说明，包括以下步骤：
步骤S202，响应于区块链任务启动信号，生成本节点对应的验证信息，并将验证信息广播至所述区块链网络中的其他节点；验证信息基于预设可验证随机函数以及本节点的节点信息得到。
其中，服务器102以及服务器104均可以是设置于同一区块链中的节点，服务器102可以是一个上述区块链中的一个节点，服务器104可以是由区块链中多个节点对应的服务器组成的服务器集群形成，本实施例以服务器102为本节点为例。区块链中通常需要进行共识，从而从区块链中的各个节点中选取一个主节点进行区块链任务，例如负责区块的产生、验证和提交等任务。在区块链任务启动时，需要进行节点共识过程，服务器102可以在检测到区块链任务启动信号时，生成服务器102对应的本节点的验证信息，并将验证信息广播至本节点所在区块链中的至少一个其他节点，例如将验证信息发送至服务器104中的至少一个其他节点，上述至少一个其他节点可以各自接收服务器102发送的验证信息，并根据第一验证条件验证该验证信息，并根据验证的结果确定是否需要向上述服务器102返回信息，例如当上述验证通过时，各 个其他节点可以向服务器102返回第一验证通过信息。其中，上述验证信息可以基于预设可验证随机函数以及本节点对应的节点信息得到。
例如，在一个实施例中，生成本节点对应的验证信息，包括：根据预设可验证随机函数，获取本节点对应的哈希输出值以及证明值；获取本节点对应的健康数值、本节点对应的公钥以及本节点对应的数字签名；健康数值基于本节点的节点信息以及本节点在每轮区块链任务中的参与度以及发送消息一致度得到；根据健康数值、当前时间、公钥、哈希输出值以及证明值，并通过数字签名进行加密，得到验证信息。本实施例中，服务器102可以基于预设可验证随机函数，计算得到服务器102对应的本节点的哈希输出值以及证明值。其中，可验证随机函数可以是一种用于进行验证的函数，可以根据特定输入产生特定输出，且该输出可以被验证确实是某个节点产生的一组函数，可验证随机函数的作用是：验证某个随机数确实是由发布该随机数的节点产生的。服务器102还可以获取本节点对应的健康数值、本节点对应的公钥以及本节点对应的数字签名，并根据健康数值；验证信息的发送时间，即当前时间；本节点的公钥；计算得到的哈希输出值和证明值，再通过本节点的数字签名进行加密，得到所述验证信息。其中，健康数值可以通过智能合约嵌入在每个节点中，通过共识协议进行调用，节点的健康数值可以基于本节点的节点信息以及本节点在每轮区块链任务中的参与度和发送消息一致度得到，具体可以通过预设的健康数值函数计算能得到；当前时间可以是上述验证信息发送的时间；公钥可以是本节点对应的公钥，公钥是与私钥算法一起使用的密钥对的非秘密一半，公钥和私钥是通过一种算法得到的一个密钥对(即一个公钥和一个私钥)，其中的一个向外界公开，称为公钥；另个自己保留，称为私钥，通过这种算法得到的密钥对能保证在世界范围内是唯一的。使用这个密钥对的时候,如果用其中一个密钥加密一段数据，必须用另一个密钥解密，如用公钥加密数据就必须用私钥解密，如果用私钥加密也必须用公钥解密，否则解密将不会成功；哈希输出值和证明值可以是通过预设可验证随机函数计算得到的数值，用于确定信息确实是由某个节点产生的；数字签名可以是本节点对应的数字签名，数字签名是只有信息的发送者才能产生的别人无法伪造的一段数字串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明，使用公钥加密领域的技术实现，用于鉴别数字信息。具体地，验证信息的格式可以如下所示：
<request，R i，P i，T，PK i>sig i；其中，T表示节点C i发送验证请求的时间戳，PK i表示该节点的公钥，sig i表示该节点C i的数字签名。
步骤S204，若接收到来自其他节点中设定数量的节点返回的第一验证通过信息，确定本节点为候选节点；第一验证通过信息为其他节点在第一验证条件下对验证信息验证通过时返回的信息。
其中，验证信息可以是服务器102对应的本节点生成的用于进行节点验证的信息，服务器104中的至 少一个其他节点可以接收来自上述服务器102发送的验证信息，且各个其他节点可以基于第一验证条件验证该验证信息，并根据验证的结果确定是否需要向服务器102返回信息，例如，验证不通过时，不返回信息，验证通过时，向服务器102返回第一验证通过信息。其中，第一验证条件可以是基于数字签名、哈希输出值、证明值以及健康数值的数值确定的验证条件。服务器102可以接收至少一个其他节点针对上述验证信息返回的第一验证通过信息，并基于接收到的第一验证通过信息得到第一验证结果。其中，第一验证通过信息可以是基于发送该验证通过信息的其他节点基于其节点信息生成的信息，用于通知服务器102的本节点验证通过。上述第一验证通过信息可以包含多个，服务器102可以基于第一验证通过信息的数量得到第一验证结果，并对第一验证结果进行判断，若第一验证结果符合预设候选节点选择条件，例如发送该第一验证通过信息的节点数量达到设定数量，则服务器102可以确定本节点为候选节点。例如，预设候选节点条件可以是基于数量形成的条件，服务器102可以根据接收到的第一验证通过信息的数量，确定是否通过验证，从而令本节点成为候选节点，例如当服务器102接收到的第一验证通过信息的数量足够多时，可以确定本节点为候选节点。具体地，上述第一验证通过信息的格式可以如下所示：<verify-pass，T，＞sig k；其中，T表示节点验证通过返回消息给被验证节点i的时间戳，sig k表示该验证节点的数字签名，用以证明这个消息确实是由该节点发送的。
步骤S206，将所述验证信息广播至所述区块链网络中的其他候选节点。
其中，本节点可以是服务器102中的节点，候选节点可以是上述第一验证结果符合预设候选节点选择条件的节点，服务器102的本节点成为候选节点时，可以将本候选节点加入候选节点集，候选节点集中包括多个候选节点；且本轮区块链任务的主节点可以从候选节点集中选取得到。服务器102的节点成为候选节点后，可以将本候选节点对应的验证信息广播至本候选节点所在候选节点集中的至少一个其他候选节点，即区块链中的其他候选节点，其他候选节点可以接收来自服务器102发送的验证信息。
步骤S208，若接收到来自其他候选节点中设定数量的候选节点返回的第二验证通过信息，确定本候选节点为本轮区块链任务的主节点；第二验证通过信息为其他候选节点在第二验证条件下对验证信息验证通过时返回的信息。
其中，其他候选节点接收的验证信息可以包含一个或多个候选节点发送的验证信息，其他候选节点可以对接收到的验证信息进行验证，例如通过第二验证条件进行验证，并根据验证的结果确定对验证信息的处理，例如，当验证不通过时，其他候选节点可以直接将该验证信息删除；当验证通过时，其他候选节点可以向上述服务器102的候选节点发送第二验证通过信息。其中，由于其他候选节点接收到的验证信息可以包括多个，第二验证条件可以是基于所有被验证的候选节点的数字签名、所有被验证的候选节点的哈希输出值、所有被验证的候选节点的证明值以及所有被验证的候选节点的健康数值的高低得到。
当候选节点集中的其他候选节点对服务器102的候选节点的验证信息验证通过时，可以向服务器102 发送第二验证通过信息，第二验证通过信息包括发送该验证通过信息的其他候选节点验证的所有节点的信息以及该其他候选节点自身的数字签名得到。服务器102接收到的第二验证通过信息可以有多个，服务器102可以根据接收到的第二验证通过信息的数量，得到第二验证结果，当第二验证结果符合预设主节点选择条件时，例如发送该第二验证通过信息的候选节点数量达到设定数量，服务器102可以确定本候选节点为本轮区块链任务的主节点，从而可以进行将所有交易打包成区块，将区块添加到区块链上等操作。其中，第二验证结果可以基于服务器102接收到的第二验证通过信息的数量得到，预设主节点选择条件可以是基于数量的条件，例如，当第二验证通过信息的数量足够多时，服务器102可以确定本候选节点为本轮区块链任务中的主节点。
上述区块链共识节点选择方法中，通过在需要进行节点变更时，将本节点的验证信息广播至区块链中的其他节点，并在接收到其他节点中设定数量的节点返回的第一验证通过信息时，确定本节点为候选节点；当本节点为候选节点时，将本候选节点验证信息广播至候选节点集中的多个候选节点，并在接收到来自其他候选节点中设定数量的候选节点返回的第二验证通过信息时，则确定本候选节点为主节点。相较于传统的通过代理权益证明或实用拜占庭容错算法进行节点选取，本方案通过利用基于多种节点信息以及可验证随机函数形成的验证信息，进行多轮验证，提高了节点选择的随机性，阻止了通过预测节点进行的网络攻击，从而实现提高节点安全性的效果。
在一个实施例中，根据预设可验证随机函数，获取本节点对应的哈希输出值以及证明值，包括：获取本节点对应的私钥；将私钥输入所述哈希生成函数，获取哈希生成函数的输出结果；若输出结果在预设阈值范围内，将输出结果作为哈希输出值，并将私钥输入所述证明生成函数，获取证明生成函数输出的证明值。
本实施例中，上述预设可验证随机函数包括生成函数，生成函数中包含哈希生成函数以及证明生成函数。其中哈希生成函数可以用于计算哈希输出值、证明生成函数可以用于计算证明值。服务器102可以利用上述哈希生成函数以及证明生成函数得到本节点对应的哈希输出值以及证明值。服务器102可以获取本节点对应的私钥，其中，私钥可以是与公钥算法一起使用的密钥对的秘密一半，并且满足以下条件：公钥和私钥成对出现；公开的密钥叫公钥，只有自己知道的叫私钥；用公钥加密的数据只有对应的私钥可以解密；用私钥加密的数据只有对应的公钥可以解密；如果可以用公钥解密，则必然是对应的私钥加的密；如果可以用私钥解密，则必然是对应的公钥加的密。服务器102可以将上述私钥输入哈希生成函数，并获取哈希生成函数的输出结果。例如，服务器102可以利用本候选节点C i，通过上述可验证随机函数中的哈希生成函数计算本候选节点的哈希输出值R i。其中，哈希生成函数的具体函数形式可以如下所示： R＝VRF_HasH(SK，M)；其中，SK是节点的私钥，M是系统设定的一个固定值，R为哈希生成值。服务器102可以对输出结果进行判断，若本候选节点的哈希输出值R i在预设阈值范围内，则服务器102可以将私钥输入证明生成函数，并获取证明生成函数输出的证明值。例如，服务器102可以在当R i在设定的阈值范围内时，利用证明生成函数得到证明值P i。其中，证明生成函数的具体函数形式可以如下所示：P＝VRF_Proof(SK，M)；其中SK是节点的私钥，M是系统设定的一个固定值，P为证明值。另外，服务器102还可以将计算出的R i和P i值公布给全网中的其它节点，同时发送经过数字签名加密的请求验证消息给全网的节点，令其他节点进行验证。
另外，服务器102还可以利用预设的函数获取节点的健康数值。在一个实施例中，获取本节点对应的健康数值，包括：若本节点在上一轮区块链任务中为候选节点，且本节点在上一轮区块链任务中向其他节点发送了相同共识信息且共识信息与最终共识结果一致，根据第一候选节点健康数值函数以及本节点对应的上一轮健康数值，得到本轮区块链任务中本节点对应的健康数值；若本节点在上一轮区块链任务中为候选节点，且本节点在上一轮区块链任务中不向其他节点发送共识信息和/或本节点的共识信息与最终共识结果不一致和/或本节点向不同的其他节点发送不同的共识信息，根据第二候选节点健康数值函数以及本节点对应的上一轮健康数值，得到本轮区块链任务中所述本节点对应的健康数值；若本节点在上一轮区块链任务中为主节点，且本节点在上一轮区块链任务中产生新区块，根据第一主节点健康数值函数以及本节点对应的上一轮健康数值，得到本轮区块链任务中本节点对应的健康数值；若本节点在上一轮区块链任务中为主节点，且本节点在上一轮区块链任务中未产生新区块和/或向不同的其他节点发送不同的共识信息，根据第二主节点健康数值函数以及本节点对应的上一轮健康数值，得到本轮区块链任务中本节点对应的健康数值。
本实施例中，区块链任务可以包括多轮任务，每一轮任务均可以进行节点选取，以得到该轮任务对应的主节点。由于可验证随机函数并不能完成固定数量的抽签任务，只能根据系统中所有节点的权重设定抽签的阈值，因此本发明引入了健康数值作为节点的权重，根据健康数值的分布情况来决定抽签的数量。即各个节点均可以有对应的健康数值。服务器102可以获取本节点在上一轮区块链任务中的状态，包括候选节点和主节点等。若本节点在上一轮区块链任务中为候选节点，且本节点在上一轮区块链任务中向其他节点发送了相同共识信息，并且该共识信息与最终共识结果一致，则本节点的健康数值可以增加，例如服务器102可以通过第一候选节点健康数值函数，根据本节点对应的上一轮健康数值，得到本轮区块链任务中本节点对应的健康数值。
若服务器102检测到本节点在上一轮区块链任务中为候选节点，且本节点在上一轮任务中包含下列一 项行为：向其他节点发送共识信息、发送的共识信息与最终共识结果不一致、向不同的其他节点发送不同的共识信息；则服务器102可以确定本节点需要降低健康数值，服务器102可以通过第二候选节点健康函数，利用本节点对应的上一轮健康数值，得到本轮任务中本节点对应的健康数值。其中，第二候选节点健康数值函数可以是由多个函数组成的函数组形成。具体地，当本节点在上一轮任务中为候选节点时，其对应的候选节点健康数值函数可以如下所示：
Figure PCTCN2021114421-appb-000001
其中，H i可以是节点的健康数值，t可以是区块链任务的轮数，k可以是系统设定的值。由上述函数可知，对于候选节点而言，如果在当前视图的第t轮共识过程中向其他节点发送了相同的消息并且与最终共识结果一致，则该节点的健康数值会缓慢增加，但同样不会超过系统设定的阈值1。随着同一视图下共识次数的增多，健康数值增加的速度也会下降；如果候选节点在某轮没有参与共识过程，即不发送任何消息给其它节点，则其健康数值会按一定比例降低。如果候选节点参与了共识过程，但是发送的消息与最终结果不一致，则其健康数值也会降低。如果检测到同一共识节点发送了不同的信息列表，则该节点将被视为恶意节点，其健康数值降为0，并将其从当前的候选节点集中删除。
若服务器102检测到本节点在上一轮任务中为主节点，且本节点在上一轮任务中有产生新的区块，服务器102可以利用第一主节点健康数值函数以及本节点对应的上一轮健康数值，得到本轮任务中本节点对应的健康数值，例如将上一轮的健康数值输入至上述第一主节点健康数值中，得到本轮的健康数值。
若服务器102检测到本节点在上一轮区块链任务中为主节点，且本节点在上一轮任务中包含下列一项行为：不产生新区块、向不同的其他节点发动不同的共识信息；则服务器102可以根据第二主节点健康数值函数，以及本节点对应的上一轮健康数值，得到本轮任务中本节点对应的健康数值。其中，第二主节点健康数值函数可以是由多个函数组成的函数组。具体地，上述主节点健康数值函数的具体函数形式可以如下所示：
Figure PCTCN2021114421-appb-000002
由上述函数可知，对于主节点来说，在当前主节点参与的当前视图第t轮共识过程中如果有新区块产生，那么该主节点的健康数值会相应增加，但健康数值不会超过系统所设定的阈值1。如果主节点所在的当前视图号一直没有更改，则该主节点健康数值的增长速度会变慢，为了避免系统的集中化处理，当健康数值为1且该主节点打包的区块数量达到阈值时会触发视图更改协议，选择新一轮视图的主节点。若该主节点所在视图过程中没有产生新区块或者不响应客户端的请求，健康数值会下降。如果主节点向其它候选节点发送了不同的信息，那么主节点的健康数值将直接降为0，将该主节点踢出候选节点集，同时触发视图更改协议，更换主节点和视图。
通过上述实施例，服务器102可以利用哈希生成函数以及证明生成函数，得到本节点对应的哈希输出值以及证明值，用于进行节点验证；并利用候选节点健康数值函数以及主节点健康数值函数，得到本节点在每轮任务的健康数值，并且可以对积极参与的节点增加健康数值，对恶意节点或消极节点降低健康数值，从而提高了节点的安全性。
在一个实施例中，还包括：获取其他节点发送的验证信息；验证信息包括其他节点对应的数字签名、哈希输出值、证明值以及健康数值；根据哈希验证函数以及证明验证函数，判断其他节点对应的哈希输出值以及证明值是否正确；若其他节点对应的数字签名正确、其他节点对应的哈希输出值和证明值正确、以及其他节点对应的健康数值大于或等于预设健康数值阈值，确定其他节点通过验证；根据本节点对应的数字签名以及当前时间，生成第一验证通过信息并返回至其他节点，以使其他节点根据接收到的至少一个第一验证通过信息以及其他节点对应的数字签名，生成对应的第一确认信息并发送至本节点；获取其他节点发送的第一确认信息，判断第一确认信息中的至少一个第一验证通过信息是否正确以及其他节点对应的数字签名是否正确；若至少一个第一验证通过信息正确且其他节点对应的数字签名正确，向其他节点发送第一状态更改确认信息，以使其他节点根据第一状态更改确认信息，确定其他节点为候选节点。
本实施例中，上述预设可验证随机函数可以包括哈希验证函数以及证明验证函数。其中，哈希验证函数可以用于验证上述哈希输出值，证明验证函数可以用于验证上述证明值。上述候选节点的选取过程中，区块链中的其他节点也可以参与候选节点的选取，并且服务器102也可以对其他节点进行验证。服务器102可以获取其他节点发送的验证信息，验证信息包括其他节点的数字签名、哈希输出值、证明值以及健康数值。服务器102可以对上述其他节点的验证信息进行验证，验证步骤如下：接受到来自其他节点的请求验证消息后，需要验证签名是否正确、验证R i，P i的值是否正确以及检查该节点的健康数值是否达到阈值A。若上述其他节点的数字签名正确、其他节点对应的哈希输出值和证明值正确、以及其他节点对应的健康数值大于或等于预设健康数值阈值，则服务器102可以确定该其他节点通过验证，当服务器102确定节点通 过验证后，可以根据本节点对应的数字签名，生成对应的第一验证通过信息并发送至通过验证的上述其他节点，例如，经过上述的验证通过后，验证节点将返回一个验证通过的消息给节点C i。若验证不通过则不返回消息。验证通过消息的格式为：<verify-pass，T，＞sig k；其中，T表示节点验证通过返回消息给被验证节点i的时间戳，sig k表示该验证节点的数字签名，用以证明这个消息确实是由该节点发送的。其他节点可以在接收到本节点发送的第一验证通过信息后，根据接收到的至少一个第一验证通过信息以及该其他节点的数字签名，生成第一确认信息发送至本节点。
服务器102在接收到其他节点发送的第一确认信息后，可以对第一确认信息中的至少一个第一验证通过信息是否正确进行判断，以及判断该其他节点的数字签名是否正确，若上述至少一个第一验证通过信息均正确，以及数字签名正确，则服务器102可以向其他节点发送第一状态更改确认信息，其他节点可以接收该第一状态更改确认信息，确认该其他节点为候选节点。具体地，在此阶段，本节点接收到来自被验证节点的确认消息后，需要验证Ψ消息集合中所有消息的正确性并验证节点i的签名是否正确，在验证通过后本节点确认该被验证节点已获得网络中大多数节点的共识，在本地日志中记录该被验证节点的状态更改，更发送一条确认消息返回给被验证节点。
通过本实施例，服务器102可以通过多段验证确定区块链中的节点是否可以通过验证成为候选节点，提高了节点的安全性。
在一个实施例中，若接收到来自其他节点中设定数量的节点返回的第一验证通过信息，确定本节点为候选节点，包括：接收其他节点返回的第一验证通过信息，获取第一验证通过信息的数量；若第一验证通过信息的数量与区块链中的节点数量的比值大于第一预设比值，确定本节点为候选节点。
本实施例中，服务器102可以根据其他节点返回的第一验证通过信息，确定第一验证结果。例如，服务器102可以接收来自多个其他节点发送的第一验证通过消息，每个第一验证通过信息可以根据发送该信息的其他节点基于该节点的数字签名以及发送该第一验证通过信息的时间戳得到。即每个第一验证通过信息对于其发送节点是唯一的。服务器102可以接收多个第一验证通过信息，并获取接收到的第一验证通过信息的和数量，作为第一验证结果。
服务器102还可以利用上述第一验证结果，确定本节点是否为候选节点。例如，服务器102可以将上述其他节点发送的第一验证通过信息的数量作为上述第一验证结果。并且服务器102还可以基于第一验证结果判断本节点是否为候选节点。例如，服务器102可以检测第一验证结果中的第一验证通过信息的数量，若大于一定数量，则确定第一验证结果通过，具体地，服务器102可以计算第一验证通过信息的数量与区块链中的节点数量的比值，若该比值大于第一预设比值，则说明区块链中大多数节点同意本节点成为候选 节点，服务器102可以确定本节点为候选节点。
当服务器102确定本节点为候选节点后，可以向其他节点发送状态更改信息，使得其他节点更新自身的状态。例如，在一个实施例中，确定本节点为候选节点之后，还包括：向其他节点发送根据第一验证通过信息以及本节点对应的数字签名生成的第一确认信息；获取其他节点基于第一确认信息返回的第一状态更改确认信息，确认本节点的状态更改为候选节点。本实施例中，服务器102可以在确定本节点为候选节点后，根据上述第一验证通过信息以及本节点对应的数字签名，生成第一确认信息，例如，服务器102可以将接收到的所有第一验证通过信息形成集合，利用自身的数字签名进行加密后形成第一确认信息。服务器102可以将上述第一确认信息发送至其他节点，其他节点在接收到该第一确认信息后，需要验证Ψ消息集合中所有消息的正确性并验证节点i的签名是否正确，在验证通过后节点确认该被验证节点已获得网络中大多数节点的共识，在本地日志中记录该被验证节点的状态更改，更发送一条确认消息返回给被验证节点。
服务器102还可以获取至少一个其他节点基于上述第一确认信息返回的第一状态更改确认信息，从而令其他节点确认本节点更改为候选节点。具体地，服务器102的节点Ci接收到来自网络中其它节点的第一验证通过消息，并将这些消息收集打包，当节点Ci收到来自f+1个的不同候选节点的验证通过消息，则表示该节点得到了其它节点同意其选取为候选节点，并将此状态记录在自己的本地日志中。其中，f为系统中预设的容错数量。节点加入候选节点集并将返回一条第一确认消息给其它所有节点，该消息的格式为：<confirm，T，ψ>sig i；其中，Ψ为被验证节点i接收到的来自超过f+1个的不同候选节点的验证通过消息的集合。当本节点接收到来自其他节点的确认状态更改信息后，正式成为获选节点，承担其在该系统中此阶段任务的角色。
通过上述实施例，服务器102可以基于三阶段的验证协议确认本节点是否为候选节点，从而提高了节点的安全性。
在一个实施例中，还包括：在预设时间内，获取至少一个其他候选节点发送的验证信息；验证信息包括其他候选节点对应的数字签名、哈希输出值、证明值以及健康数值；根据哈希验证函数以及证明验证函数，判断至少一个其他候选节点对应的哈希输出值以及证明值是否正确；若至少一个其他候选节点对应的数字签名正确、至少一个其他候选节点对应的哈希输出值和证明值正确，获取至少一个其他候选节点中每个其他候选节点对应的健康数值；将健康数值最高的其他候选节点作为验证通过的节点；根据本节点对应的数字签名、当前时间、至少一个其他候选节点的节点信息，生成第二验证通过信息并发送至通过验证的其他候选节点，以使其他候选节点根据接收到的至少一个第二验证通过信息，生成对应的第二确认信息并 发送至本节点；获取其他候选节点发送的第二确认信息，判断第二确认信息中的至少一个其他候选节点的节点信息是否正确以及其他候选节点对应的数字签名是否正确；若节点信息正确且其他候选节点对应的数字签名正确，向其他候选节点发送第二状态更改确认信息，以使其他候选节点根据第二状态更改确认信息，确定其他候选节点为主节点。
本实施例中，成为候选节点的服务器102也可以为其他候选节点进行验证，从而完成主节点的选取。服务器102的候选节点可以在预设时间内获取至少一个其他候选节点发送的验证信息，其中其他候选节点的验证信息包括其他候选节点对应的数字签名、其他候选节点对应的哈希输出值、其他候选节点对应的证明值以及其他候选节点对应的健康数值。例如，当本候选节点接收到第一个其他候选节点发送的验证信息时，可以启动计时器T p，在此时间段内，本候选节点可以持续接收其他候选节点发送的验证信息，在计时器停止时不再接收任何验证信息，并开始对接收到的其他候选节点的验证信息进行验证。
在验证阶段，服务器102可以根据预设可验证随机函数中的哈希验证函数以及证明验证函数，判断接收到的至少一个其他候选节点对应的哈希输出值以及证明值是否正确；具体地，哈希验证函数的函数形式可以如下所示：R＝VRF_P2H(P)；证明验证函数的函数形式可以如下所示：VRF_Verify(PK，M，P)；其中，PK为被验证节点的公钥，P为被验证节点公布的证明值，R为被验证节点公布出的自己计算出的哈希输出；M为系统设定的固定数值。其中，可验证随机函数的随机性指的是，在不给定证明P的情况下，VRF_Hash的输出R与随机数两者之间是不可区分的，通过上述函数组，可保证安全不暴露私钥的前提下验证某一个随机输出确实是有特定节点生成的。并且，所示预设可验证随机函数具有以下特点：对于不同的输入，输出的值是随机的，并且均匀分布在值域范围内；对于相同的输入，它得到的输出一定是相同的。
服务器102对上述接收到的其他候选节点的验证信息进行判断后，若检测到该候选节点的验证信息中的数字签名不正确，服务器102可以直接将该验证信息删除；若服务器102检测到上述验证信息中的哈希输出值或证明值不正确，则服务器102可以直接将该验证信息删除。若服务器102检测到上述数字签名、哈希输出值以及证明值均正确，则服务器102可以获取接收到的各个其他候选节点对应的健康数值，并且可以将健康数值最高的其他候选节点作为验证通过的节点。例如，若服务器102接收到的其他候选节点的验证信息只有一个，则服务器102可以确定该节点为通过验证的节点；若服务器102接收到的其他候选节点的验证消息大于一个，则服务器102可以对比每个接收到的验证信息中的健康数值，将健康数值最大的验证信息对应的其他候选节点作为通过验证的节点。
服务器102在确定了通过验证的节点后，可以根据本节点对应的数字签名、当前时间、至少一个其他 候选节点的节点信息，生成第二验证通过信息，并将第二验证通过信息发送至通过验证的其他候选节点，接收到第二验证通过信息后的其他候选节点可以基于至少一个第二验证通过信息，生成对应的第二确认信息发送至服务器102的节点。例如，假设在上述验证中，节点一共有C1-C7节点，服务器102的节点为C1，服务器102接收到了C2、C3的验证信息，并最终选择C3作为通过验证的节点，即服务器102选择C3作为主节点，则服务器102会返回第二验证通过信息至节点C3，第二验证通过信息的格式为：<verify，T，m，Ф>sig k；其中，T表示节点验证通过返回消息给被验证的其他候选节点i的时间戳，m表示服务器102的候选节点选择C3的证明消息摘要，Φ表示本候选节点收到的请求消息的集合，sig k表示本候选节点的数字签名，用以证明这个消息确实是由该节点发送的，且他人不能篡改。
服务器102还可以接收其他候选节点根据上述第二验证通过信息返回的第二确认信息，其中第二确认信息中可以包括该其他候选节点接收到的所有第二验证通过信息的集合以及该候选节点的数字签名，服务器102可以判断第二确认信息中的至少一个其他候选节点的节点信息是否正确，以及其他候选节点对应的数字签名是否正确，若节点信息均正确且数字签名正确，则服务器102可以向该其他候选节点发送第二状态更改确认信息，使得该其他候选节点在接收到该第二状态更改确认信息后，确定该其他候选节点在本区块链的本轮任务中为主节点。例如，当服务器102接收到其他候选节点发送的第二确认信息时，可以验证第二确认信息中，该其他节点接收到的所有第二验证通过信息形成的集合中所有第二验证通过信息的正确性，并验证该其他候选节点的数字签名是否正确，验证通过后，服务器102可以确定该其他候选节点获得了网络中大多数节点的共识，服务器102可以在本地日志中记录该主节点的状态更改，同时切换到当前主节点所在的视图号，发送一条确认消息，例如第二状态更改确认信息，返回给被验证的节点。
通过本实施例，服务器102可以通过多段验证确定区块链中的节点是否可以通过验证成为主节点，提高了节点的安全性。
在一个实施例中，若接收到来自其他候选节点中设定数量的候选节点返回的第二验证通过信息，确定本候选节点为本轮区块链任务的主节点，包括：接收其他候选节点返回的第二验证通过信息，获取第二验证通过信息的数量；若第二验证通过信息的数量与候选节点集中的节点数量的比值大于的第二预设比值，确定本节点为主节点。
本实施例中，作为候选节点的服务器102，可以向其他候选节点发送本候选节点的验证信息，其他候选节点可以在对本候选节点的验证信息进行验证，并在验证通过后，向本候选节点返回第二验证通过信息，由于其他候选节点可以有多个，因此本候选节点接收到的第二验证通过信息可以有多个，服务器102可以获取接收到的第二验证通过信息的数量，作为上述第二验证结果。服务器102还可以利用接收到的第二验 证结果确定本候选节点是否为主节点。例如，第二验证结果中包括服务器102接收到的第二验证通过信息的数量，服务器102可以将接收到的第二验证通过信息的数量与本区块链中的由本轮任务的所有候选节点组成的候选节点集中的候选节点的节点数量比较，若第二验证通过信息的数量与候选节点集中的节点数量的比值大于第二预设比值，则服务器102可以确定本节点为主节点。例如，在这一步骤，所有通过计算出符合VRF输出条件并发送了验证信息的候选节点，将接收到来自其他候选节点的第二验证通过信息，例如服务器102接收会接收到其他候选节点发送的第二验证通过信息，服务器102可以将这些信息收集打包，当服务器102接收到相对于超过候选节点总数2/3的不同候选节点的第二验证通过信息时，则表示服务器102的候选节点得到大部分节点同意其作为主节点，服务器102可以将此状态记录在本地日志中，切换到自己当选主节点的视图，修改视图号。
在服务器102确定本节点为主节点后，可以向其他候选节点发送确认信息。例如，在一个实施例中，确定本节点为主节点之后，还包括：向其他候选节点发送根据第二验证通过信息以及本节点对应的数字签名生成的第二确认信息；获取其他候选节点基于第二确认信息返回的第二状态更改确认信息，确认本节点的状态更改为主节点。本实施例中，服务器102确定本候选节点为主节点后，可以根据接收到的所有第二验证通过信息，形成验证通过信息的集合，并根据该集合以及服务器102的候选节点的数字签名，形成第二确认信息，发送至其他候选节点。例如，作为主节点的服务器102可以返回一条确认消息，例如第二确认信息，给其它所有候选节点，该消息的格式为：<confirm，T，ψ>sig P；其中，Ψ为主节点i接收到的来自其它个不同节点的验证通过消息的集合，sig P为该节点的数字签名。其他候选节点接收到第二确认信息后，可以检测上述集合中的所有第二验证通过信息的正确性，并验证发送该第二确认信息的主节点的数字签名是否正确，在验证通过后，其他候选节点可以向服务器102返回第二状态更改确认信息，服务器102可以获取至少一个其他候选节点基于第二确认信息返回的第二状态更改确认信息，确认本节点的状态更改为主节点，服务器102在收到来自其他候选节点的确认状态更改信息后，正式成为主节点，承担其在该系统中此阶段任务的角色，开始处理系统中到来的请求。
通过上述实施例，服务器102可以基于三阶段的验证协议确认本节点是否为主节点，从而提高了节点的安全性。
在一个实施例中，如图3所示，图3为另一个实施例中区块链共识节点选择方法的流程示意图。包括以下流程：区块链系统设置第一轮候选节点集选举的VRF(可验证随机函数)输出阈值，利用该阈值从区块链系统中抽取共识节点委员集，集上述的候选节点集，并从候选节点集中，通过节点的健康数值和VRF值的衡量，从候选节点中选取得到本轮任务的主节点。具体地，如图4所示，图4为一个实施例中候选节 点选择步骤的流程示意图。系统中的所有节点利用自己的私钥和随机数种子计算本地VRF输出，即利用预设可验证随机函数进行计算，得到VRF哈希输出值和VRF证明值，若计算出的哈希输出值和证明值均在预设阈值范围内，则该节点将自己的哈希输出值和证明值广播至其他节点，等待全网中超过f+1(f为区块链系统中设定的容错数量)个节点的一致性确认共识后加入共识节点委员集，即上述候选节点集。候选节点的验证过程可以如图5所示，图5为一个实施例中候选节点选择步骤数据交互的流程示意图。包括请求阶段、验证阶段以及确认阶段。如图5，在请求阶段，候选节点C i利用可验证随机函数中的VRF_hash(SK，α)函数计算出本节点的VRF哈希输出R i，若R i在系统设定的阈值范围内，则该节点通过证明函数VRF_proof(SK，M)得到自己证明值P i，然后节点C i将计算出的R i和P i值公布给全网中的其它节点，同时发送经过数字签名加密的请求验证消息给全网的节点。在验证阶段，包括验证和验证收集两个步骤。在验证步骤中，其它节点接受到来自节点C i的请求验证消息后，需要：验证签名是否正确；验证R i，P i的值是否正确；检查该节点的健康分数是否达到阈值A；经过上述的验证通过后，验证节点将返回一个验证通过的消息给节点C i。若验证不通过则不返回消息。在验证收集阶段，节点C i接收到来自网络中其它节点的验证通过消息，并将这些消息收集打包，当节点C i收到来自f+1个的不同候选节点的验证通过消息，则表示该节点得到了其它节点同意其选取为候选节点，并将此状态记录在自己的本地日志中，节点加入候选节点集并将返回一条确认消息给其它所有节点。
在确认阶段，分为确认和确认收集两个步骤。其中，确认步骤包括：网络中其它节点接收到来自被验证节点的确认消息后，需要验证Ψ消息集合中所有消息的正确性并验证节点i的签名是否正确，在验证通过后节点确认该被验证节点已获得网络中大多数节点的共识，在本地日志中记录该被验证节点的状态更改，更发送一条确认消息返回给被验证节点。确认收集步骤包括：被验证节点收到来自其它节点的确认状态更改消息后，正式成为候选节点，承担其在该系统中此阶段任务的角色。
候选节点集选取完成后，系统可以继续进行主节点的选取，如图6所示，图6为一个实施例中主节点选择步骤的流程示意图。主节点在候选节点集中产生，候选节点选取完成后，候选节点开始进行第二轮的VRF计算，若计算出的哈希输出符合成为主节点输出阈值的要求，则该节点广播自己的VRF输出和证明，向候选节点集中其它节点请求认证。主节点的验证过程可以如图7所示，图7为一个实施例中主节点选择步骤数据交互的流程示意图。包括请求阶段、验证阶段以及确认阶段。其中，在请求阶段，如图7，假设候选节点C1，C2都利用可验证随机函数中的VRF_Hash(SK，M)函数计算出的VRF哈希输出R p都在系统设定的阈值范围内，则这两个节点通过证明函数VRF_Proof(SK，M)得到自己证明值P i，然后C1，C2发送经过数字签名加密的请求验证消息给共识委员节点，即候选节点。
在验证阶段，包括验证和验证收集两个步骤。在验证步骤中，其它候选节点在接收到第一个验证请求消息时，启动计时器T p，在计时器停止时不再接收任何请求验证消息，开始对接收到的请求验证消息进行验证，验证过程需要：检查所有被验证节点的签名是否正确，若不正确直接将此消息删除；检查被验证节点发送的R p，P p的值是否正确，若不正确直接将此消息删除；比较计时器时间段内所有收到的被验证节点的健康分数值，选择健康分数最高的节点为主节点。假设在上述验证中，C3-C7验证节点最后选择了C1作为主节点，则将返回一个验证通过的消息给节点C1。在验证收集步骤，所有通过计算出符合VRF输出条件并发送了请求验证消息的候选主节点将接收到来自其它候选节点的验证通过消息，并将这些消息收集打包，当节点收到来自超过2/3个不同候选节点的验证通过消息，则表示该节点得到了大部分节点同意其选取为主节点，并将此状态记录在自己的本地日志中，切换到自己当选主节点的视图，修改视图号。然后主节点该消息返回一条确认消息给其它所有候选节点。
在确认阶段，包括确认和确认收集两个步骤。在确认步骤中，其它候选节点接收到来自C1节点的确认消息后，需要验证Ψ消息集合中所有消息的正确性并验证主节点P的签名是否正确，在验证通过后节点确认该C1节点已获得网络中大多数节点的共识，在本地日志中记录该主节点的状态更改，同时切换到当前主节点所在的视图号，发送一条确认消息返回给被验证节点。确认收集步骤中，被验证节点收到来自其它节点的确认状态更改消息后，正式成为主节点，承担其在该系统中此阶段任务的角色，开始处理系统中到来的请求。
通过本实施例，区块链系统中的节点采用可验证随机函数在所有节点中进行随机选择，恶意节点不能根据特定规律提前预测下一个主节点的编号，相比现有技术中节点的选择方法，更具有随机性，从而提高了节点的安全性。
应该理解的是，虽然图2-图7的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2-图7中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。
在一个实施例中，如图8所示，提供了一种区块链共识节点选择装置，包括：第一广播模块500、第一确定模块502、第二广播模块504和第二确定模块506，其中：
第一广播模块500，用于响应于区块链任务启动信号，生成本节点对应的验证信息，并将验证信息广播至所述区块链网络中的其他节点；验证信息基于预设可验证随机函数以及本节点的节点信息得到。
第一确定模块502，用于若接收到来自其他节点中设定数量的节点返回的第一验证通过信息，确定本节点为候选节点；第一验证通过信息为其他节点在第一验证条件下对验证信息验证通过时返回的信息。
第二广播模块504，用于将所述验证信息广播至所述区块链网络中的其他候选节点。
第二确定模块506，用于若接收到来自其他候选节点中设定数量的候选节点返回的第二验证通过信息，确定本候选节点为本轮区块链任务的主节点；第二验证通过信息为其他候选节点在第二验证条件下对验证信息验证通过时返回的信息。
在一个实施例中，上述第一广播模块500，具体用于根据预设可验证随机函数，获取本节点对应的哈希输出值以及证明值；获取本节点对应的健康数值、本节点对应的公钥以及本节点对应的数字签名；健康数值基于本节点的节点信息以及本节点在每轮区块链任务中的参与度以及发送消息一致度得到；根据健康数值、当前时间、公钥、哈希输出值以及证明值，并通过数字签名进行加密，得到验证信息。
在一个实施例中，上述第一广播模块500，具体用于获取本节点对应的私钥；将私钥输入所述哈希生成函数，获取哈希生成函数的输出结果；若输出结果在预设阈值范围内，将输出结果作为哈希输出值，并将私钥输入所述证明生成函数，获取证明生成函数输出的证明值。
在一个实施例中，上述第一广播模块500，具体用于若本节点在上一轮区块链任务中为候选节点，且本节点在上一轮区块链任务中向其他节点发送了相同共识信息且共识信息与最终共识结果一致，根据第一候选节点健康数值函数以及本节点对应的上一轮健康数值，得到本轮区块链任务中本节点对应的健康数值；若本节点在上一轮区块链任务中为候选节点，且本节点在上一轮区块链任务中不向其他节点发送共识信息和/或本节点的共识信息与最终共识结果不一致和/或本节点向不同的其他节点发送不同的共识信息，根据第二候选节点健康数值函数以及本节点对应的上一轮健康数值，得到本轮区块链任务中所述本节点对应的健康数值；若本节点在上一轮区块链任务中为主节点，且本节点在上一轮区块链任务中产生新区块，根据第一主节点健康数值函数以及本节点对应的上一轮健康数值，得到本轮区块链任务中本节点对应的健康数值；若本节点在上一轮区块链任务中为主节点，且本节点在上一轮区块链任务中未产生新区块和/或向不同的其他节点发送不同的共识信息，根据第二主节点健康数值函数以及本节点对应的上一轮健康数值，得到本轮区块链任务中本节点对应的健康数值。
在一个实施例中，上述装置还包括：第一验证模块，用于获取其他节点发送的验证信息；验证信息包括其他节点对应的数字签名、哈希输出值、证明值以及健康数值；根据哈希验证函数以及证明验证函数， 判断其他节点对应的哈希输出值以及证明值是否正确；若其他节点对应的数字签名正确、其他节点对应的哈希输出值和证明值正确、以及其他节点对应的健康数值大于或等于预设健康数值阈值，确定其他节点通过验证；根据本节点对应的数字签名以及当前时间，生成第一验证通过信息并返回至其他节点，以使其他节点根据接收到的至少一个第一验证通过信息以及其他节点对应的数字签名，生成对应的第一确认信息并发送至本节点；获取其他节点发送的第一确认信息，判断第一确认信息中的至少一个第一验证通过信息是否正确以及其他节点对应的数字签名是否正确；若至少一个第一验证通过信息正确且其他节点对应的数字签名正确，向其他节点发送第一状态更改确认信息，以使其他节点根据第一状态更改确认信息，确定其他节点为候选节点。
在一个实施例中，上述第一确定模块502，具体用于接收其他节点返回的第一验证通过信息，获取第一验证通过信息的数量；若第一验证通过信息的数量与区块链中的节点数量的比值大于第一预设比值，确定本节点为候选节点。
在一个实施例中，上述装置还包括：第一确认模块，用于向至少一个其他节点发送根据第一验证通过信息以及本节点对应的数字签名生成的第一确认信息；获取至少一个其他节点基于第一确认信息返回的第一状态更改确认信息，确认本节点的状态更改为候选节点。
在一个实施例中，上述装置还包括：第二验证模块，用于在预设时间内，获取至少一个其他候选节点发送的验证信息；验证信息包括其他候选节点对应的数字签名、哈希输出值、证明值以及健康数值；根据哈希验证函数以及证明验证函数，判断至少一个其他候选节点对应的哈希输出值以及证明值是否正确；若至少一个其他候选节点对应的数字签名正确、至少一个其他候选节点对应的哈希输出值和证明值正确，获取至少一个其他候选节点中每个其他候选节点对应的健康数值；将健康数值最高的其他候选节点作为验证通过的节点；根据本节点对应的数字签名、当前时间、至少一个其他候选节点的节点信息，生成第二验证通过信息并发送至通过验证的其他候选节点，以使其他候选节点根据接收到的至少一个第二验证通过信息，生成对应的第二确认信息并发送至本节点；获取其他候选节点发送的第二确认信息，判断第二确认信息中的至少一个其他候选节点的节点信息是否正确以及其他候选节点对应的数字签名是否正确；若节点信息正确且其他候选节点对应的数字签名正确，向其他候选节点发送第二状态更改确认信息，以使其他候选节点根据第二状态更改确认信息，确定其他候选节点为主节点。
在一个实施例中，上述第二确定模块506，具体用于接收其他候选节点返回的第二验证通过信息，获取第二验证通过信息的数量；若第二验证通过信息的数量与候选节点集中的节点数量的比值大于的第二预设比值，确定本节点为主节点。
在一个实施例中，上述装置还包括：第二确认模块，用于向其他候选节点发送根据第二验证通过信息以及本节点对应的数字签名生成的第二确认信息；获取其他候选节点基于第二确认信息返回的第二状态更改确认信息，确认本节点的状态更改为主节点。
关于区块链共识节点选择装置的具体限定可以参见上文中对于区块链共识节点选择方法的限定，在此不再赘述。上述区块链共识节点选择装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。
在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图9所示。该计算机设备包括通过系统总线连接的处理器、存储器和网络接口。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储节点数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种区块链共识节点选择方法。
本领域技术人员可以理解，图9中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现上述的区块链共识节点选择方法。
在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述的区块链共识节点选择方法。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-Only Memory，ROM)、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器(Random Access Memory，RAM)或外部高速缓冲存储器。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器(Static Random Access Memory，SRAM)或动态随机存取存储 器(Dynamic Random Access Memory，DRAM)等。
以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (11)

  1. 一种区块链共识节点选择方法，其特征在于，应用于区块链网络中的节点，所述方法包括：
    响应于区块链任务启动信号，生成本节点对应的验证信息，并将所述验证信息广播至所述区块链网络中的其他节点；所述验证信息基于预设可验证随机函数以及本节点的节点信息得到；
    若接收到来自所述其他节点中设定数量的节点返回的第一验证通过信息，确定本节点为候选节点；所述第一验证通过信息为所述其他节点在第一验证条件下对所述验证信息验证通过时返回的信息；
    将所述验证信息广播至所述区块链网络中的其他候选节点；
    若接收到来自所述其他候选节点中设定数量的候选节点返回的第二验证通过信息，确定本候选节点为本轮区块链任务的主节点；所述第二验证通过信息为所述其他候选节点在第二验证条件下对所述验证信息验证通过时返回的信息。
  2. 根据权利要求1所述的方法，其特征在于，所述生成本节点对应的验证信息，包括：
    根据预设可验证随机函数，获取本节点对应的哈希输出值以及证明值；
    获取本节点对应的健康数值、本节点对应的公钥以及本节点对应的数字签名；所述健康数值基于本节点的节点信息以及本节点在每轮区块链任务中的参与度以及发送消息一致度得到；
    根据所述健康数值、当前时间、所述公钥、所述哈希输出值以及所述证明值，并通过所述数字签名进行加密，得到所述验证信息。
  3. 根据权利要求2所述的方法，其特征在于，所述预设可验证随机函数包括哈希生成函数以及证明生成函数；
    所述根据预设可验证随机函数，获取本节点对应的哈希输出值以及证明值，包括：
    获取本节点对应的私钥；
    将所述私钥输入所述哈希生成函数，获取所述哈希生成函数的输出结果；
    若所述输出结果在预设阈值范围内，将所述输出结果作为所述哈希输出值，并将所述私钥输入所述证明生成函数，获取所述证明生成函数输出的证明值。
  4. 根据权利要求2所述的方法，其特征在于，所述获取本节点对应的健康数值，包括：
    若所述本节点在上一轮区块链任务中为候选节点，且所述本节点在所述上一轮区块链任务中向其他节点发送了相同共识信息且所述共识信息与最终共识结果一致，根据第一候选节点健康数值函数以及所述本节点对应的上一轮健康数值，得到本轮区块链任务中所述本节点对应的健康数值；
    若所述本节点在上一轮区块链任务中为候选节点，且所述本节点在所述上一轮区块链任务中不向所述其他节点发送所述共识信息和/或所述本节点的共识信息与所述最终共识结果不一致和/或所述本节点向不 同的所述其他节点发送不同的所述共识信息，根据第二候选节点健康数值函数以及所述本节点对应的上一轮健康数值，得到本轮区块链任务中所述本节点对应的健康数值；
    若所述本节点在上一轮区块链任务中为主节点，且所述本节点在所述上一轮区块链任务中产生新区块，根据第一主节点健康数值函数以及所述本节点对应的上一轮健康数值，得到本轮区块链任务中所述本节点对应的健康数值；
    若所述本节点在上一轮区块链任务中为主节点，且所述本节点在所述上一轮区块链任务中未产生新区块和/或向不同的其他节点发送不同的共识信息，根据第二主节点健康数值函数以及所述本节点对应的上一轮健康数值，得到本轮区块链任务中所述本节点对应的健康数值。
  5. 根据权利要求2所述的方法，其特征在于，所述预设可验证随机函数包括哈希验证函数以及证明验证函数；
    所述方法还包括：
    获取所述其他节点发送的验证信息；所述验证信息包括所述其他节点对应的数字签名、哈希输出值、证明值以及健康数值；
    根据所述哈希验证函数以及所述证明验证函数，判断所述其他节点对应的哈希输出值以及证明值是否正确；
    若所述其他节点对应的所述数字签名正确、所述其他节点对应的哈希输出值和所述证明值正确、以及所述其他节点对应的健康数值大于或等于预设健康数值阈值，确定所述其他节点通过验证；
    根据所述本节点对应的数字签名以及当前时间，生成第一验证通过信息并返回至所述其他节点，以使所述其他节点根据接收到的至少一个所述第一验证通过信息以及所述其他节点对应的数字签名，生成对应的第一确认信息并发送至本节点；
    获取所述其他节点发送的第一确认信息，判断所述第一确认信息中的至少一个第一验证通过信息是否正确以及所述其他节点对应的数字签名是否正确；若所述至少一个第一验证通过信息正确且所述其他节点对应的数字签名正确，向所述其他节点发送第一状态更改确认信息，以使所述其他节点根据所述第一状态更改确认信息，确定所述其他节点为候选节点。
  6. 根据权利要求5所述的方法，其特征在于，所述若接收到来自所述其他节点中设定数量的节点返回的第一验证通过信息，确定本节点为候选节点，包括：
    接收所述其他节点返回的第一验证通过信息，获取所述第一验证通过信息的数量；
    若所述第一验证通过信息的数量与所述区块链中的节点数量的比值大于第一预设比值，确定本节点为 候选节点；
    所述确定本节点为候选节点之后，还包括：
    向所述其他节点发送根据所述第一验证通过信息以及本节点对应的数字签名生成的第一确认信息；
    获取所述其他节点基于所述第一确认信息返回的第一状态更改确认信息，确认本节点的状态更改为候选节点。
  7. 根据权利要求5所述的方法，其特征在于，所述方法还包括：
    在预设时间内，获取至少一个其他候选节点发送的验证信息；所述验证信息包括所述其他候选节点对应的数字签名、哈希输出值、证明值以及健康数值；
    根据所述哈希验证函数以及所述证明验证函数，判断所述至少一个其他候选节点对应的哈希输出值以及证明值是否正确；
    若所述至少一个其他候选节点对应的数字签名正确、所述至少一个其他候选节点对应的哈希输出值和所述证明值正确，获取所述至少一个其他候选节点中每个其他候选节点对应的健康数值；
    将健康数值最高的其他候选节点作为验证通过的节点；
    根据所述本节点对应的数字签名、当前时间、所述至少一个其他候选节点的节点信息，生成第二验证通过信息并发送至通过验证的其他候选节点，以使所述其他候选节点根据接收到的至少一个所述第二验证通过信息，生成对应的第二确认信息并发送至本节点；
    获取所述其他候选节点发送的第二确认信息，判断所述第二确认信息中的至少一个其他候选节点的节点信息是否正确以及所述其他候选节点对应的数字签名是否正确；若所述节点信息正确且所述其他候选节点对应的数字签名正确，向所述其他候选节点发送第二状态更改确认信息，以使所述其他候选节点根据所述第二状态更改确认信息，确定所述其他候选节点为主节点。
  8. 根据权利要求7所述的方法，其特征在于，所述若接收到来自所述其他候选节点中设定数量的候选节点返回的第二验证通过信息，确定本候选节点为本轮区块链任务的主节点，包括：
    接收所述其他候选节点返回的第二验证通过信息，获取所述第二验证通过信息的数量；
    若所述第二验证通过信息的数量与所述候选节点集中的节点数量的比值大于的第二预设比值，确定本节点为主节点；
    所述确定本节点为主节点之后，还包括：
    向所述其他候选节点发送根据所述第二验证通过信息以及本节点对应的数字签名生成的第二确认信息；
    获取所述其他候选节点基于所述第二确认信息返回的第二状态更改确认信息，确认本节点的状态更改为主节点。
  9. 一种区块链共识节点选择装置，其特征在于，应用于区块链网络中的节点，所述装置包括：
    第一广播模块，用于响应于区块链任务启动信号，生成本节点对应的验证信息，并将所述验证信息广播至所述区块链网络中的其他节点；所述验证信息基于预设可验证随机函数以及本节点的节点信息得到；
    第一确定模块，用于若接收到来自所述其他节点中设定数量的节点返回的第一验证通过信息，确定本节点为候选节点；所述第一验证通过信息为所述其他节点在第一验证条件下对所述验证信息验证通过时返回的信息；
    第二广播模块，用于将所述验证信息广播至所述区块链网络中的其他候选节点；
    第二确定模块，用于若接收到来自所述其他候选节点中设定数量的候选节点返回的第二验证通过信息，确定本候选节点为本轮区块链任务的主节点；所述第二验证通过信息为所述其他候选节点在第二验证条件下对所述验证信息验证通过时返回的信息。
  10. 一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至8中任一项所述的方法的步骤。
  11. 一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至8中任一项所述的方法的步骤。
PCT/CN2021/114421 2021-04-13 2021-08-25 区块链共识节点选择方法、装置、计算机设备和存储介质 WO2022217807A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110395307.6 2021-04-13
CN202110395307.6A CN113301114B (zh) 2021-04-13 2021-04-13 区块链共识节点选择方法、装置、计算机设备和存储介质

Publications (1)

Publication Number Publication Date
WO2022217807A1 true WO2022217807A1 (zh) 2022-10-20

Family

ID=77319828

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/114421 WO2022217807A1 (zh) 2021-04-13 2021-08-25 区块链共识节点选择方法、装置、计算机设备和存储介质

Country Status (2)

Country Link
CN (1) CN113301114B (zh)
WO (1) WO2022217807A1 (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113301114B (zh) * 2021-04-13 2022-03-04 广东电网有限责任公司 区块链共识节点选择方法、装置、计算机设备和存储介质
CN113922953B (zh) * 2021-09-30 2023-07-21 联想(北京)有限公司 一种数据处理方法及装置
CN114362930A (zh) * 2021-12-09 2022-04-15 重庆海尔制冷电器有限公司 区块链共识方法及计算机可读存储介质
CN114338107A (zh) * 2021-12-17 2022-04-12 中寰卫星导航通信有限公司 一种安全控制方法及装置
CN115242497B (zh) * 2022-07-21 2023-06-09 深圳力维信息技术有限公司 一种基于区块链的数据防篡改方法及系统
CN117614611B (zh) * 2024-01-24 2024-04-12 苏州元脑智能科技有限公司 一种区块链共识方法、系统和存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190327084A1 (en) * 2018-04-19 2019-10-24 Electronics And Telecommunications Research Institute Method for selecting consensus node using nonce and method and apparatus for generating blockchain using the same
CN110784346A (zh) * 2019-10-18 2020-02-11 深圳供电局有限公司 一种基于信誉值的pbft共识系统及方法
CN112102033A (zh) * 2020-09-03 2020-12-18 西安电子科技大学 基于区块链的电力分布式交易嵌套共识方法、系统及应用
CN112257095A (zh) * 2020-11-23 2021-01-22 中电万维信息技术有限责任公司 一种联盟链共识节点的选择方法
CN113301114A (zh) * 2021-04-13 2021-08-24 广东电网有限责任公司 区块链共识节点选择方法、装置、计算机设备和存储介质

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11244059B2 (en) * 2018-05-17 2022-02-08 International Business Machines Corporation Blockchain for managing access to medical data
CN110351133B (zh) * 2019-06-28 2021-09-17 创新先进技术有限公司 用于区块链系统中的主节点切换处理的方法及装置
CN110599173B (zh) * 2019-09-20 2021-08-17 腾讯科技（深圳）有限公司 区块链的共识节点确定方法、装置、设备及存储介质
CN116366302A (zh) * 2020-11-18 2023-06-30 北京数码视讯科技股份有限公司 节点准入方法、共识方法、装置、电子设备及存储介质
CN112564902A (zh) * 2020-12-09 2021-03-26 苏州市星际云通区块链科技有限公司 一种区块链上可验证随机函数的共识方法及其系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190327084A1 (en) * 2018-04-19 2019-10-24 Electronics And Telecommunications Research Institute Method for selecting consensus node using nonce and method and apparatus for generating blockchain using the same
CN110784346A (zh) * 2019-10-18 2020-02-11 深圳供电局有限公司 一种基于信誉值的pbft共识系统及方法
CN112102033A (zh) * 2020-09-03 2020-12-18 西安电子科技大学 基于区块链的电力分布式交易嵌套共识方法、系统及应用
CN112257095A (zh) * 2020-11-23 2021-01-22 中电万维信息技术有限责任公司 一种联盟链共识节点的选择方法
CN113301114A (zh) * 2021-04-13 2021-08-24 广东电网有限责任公司 区块链共识节点选择方法、装置、计算机设备和存储介质

Also Published As

Publication number Publication date
CN113301114B (zh) 2022-03-04
CN113301114A (zh) 2021-08-24

Similar Documents

Publication Publication Date Title
WO2022217807A1 (zh) 区块链共识节点选择方法、装置、计算机设备和存储介质
US20220385460A1 (en) Systems and methods for selecting and utilizing a committee of validator nodes in a distributed system
US11128522B2 (en) Changing a master node in a blockchain system
CN111131209B (zh) 一种改进的高效共识方法、系统、计算机设备及存储介质
KR102578019B1 (ko) 블록체인 기반 데이터 검출 방법 및 디바이스, 및 컴퓨터 판독가능 저장 매체
Hassanzadeh-Nazarabadi et al. Lightchain: A dht-based blockchain for resource constrained environments
Hassanzadeh-Nazarabadi et al. LightChain: Scalable DHT-based blockchain
Yadav et al. A comparative study on consensus mechanism with security threats and future scopes: Blockchain
JP7198371B2 (ja) ブロックチェーンネットワークにおいてロールベース合意プロトコルを使用してリーダーノードを選出する方法
CN111314067A (zh) 区块存储方法、装置、计算机设备及存储介质
JP5801482B2 (ja) キーバリューストレージに対するデータの保存および読み出しを行う方法およびシステム
CN114139203B (zh) 基于区块链的异构身份联盟风险评估系统、方法及终端
GB2579635A (en) A node testing method and apparatus for a blockchain system
CN112116349B (zh) 面向高吞吐率的图式账本的随机化共识方法和装置
CN112395113B (zh) 实用拜占庭容错共识方法及装置、可读存储介质
CN113837758A (zh) 一种区块链系统的共识方法及装置
WO2019243816A1 (en) Leader selection for permissioned blockchain
CN110990790B (zh) 一种数据处理方法及设备
Han et al. Analysing and improving shard allocation protocols for sharded blockchains
CN113609231B (zh) 一种维护区块链系统的网络架构信息的方法和装置
CN115022326A (zh) 基于协同过滤推荐的区块链拜占庭容错共识方法
Drakatos et al. Adrestus: Secure, scalable blockchain technology in a decentralized ledger via zones
Drakatos et al. Rapid Blockchain Scaling with Efficient Transaction Assignment
CN117473557B (zh) 一种可信设置方法及装置
An et al. Research on Byzantine Fault Tolerant algorithm based on Node Weights

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21936679

Country of ref document: EP

Kind code of ref document: A1