CN116366302A

CN116366302A - Node admittance method, consensus method, device, electronic equipment and storage medium

Info

Publication number: CN116366302A
Application number: CN202310202268.2A
Authority: CN
Inventors: 魏晔; 郑力铮; 刘利华; 汤俊峰
Original assignee: Sumavision Technologies Co Ltd
Current assignee: Sumavision Technologies Co Ltd
Priority date: 2020-11-18
Filing date: 2020-11-18
Publication date: 2023-06-30
Also published as: CN116260645A; CN116208344A; CN112491845A; CN112491845B

Abstract

The application provides a node admittance method, a node admittance device, an electronic device and a storage medium, wherein the node admittance method comprises the following steps: generating a public key, a private key and a unique identifier of the node to be accessed; generating a certification Vp capable of verifying the random numbers Vh and Vh by adopting VRF according to the private key and the unique identifier; determining a first selection base according to the Vh; based on the first selection base number and the unique identification of each consensus node in the consensus network, selecting a target consensus node according to a preset selection standard, connecting the target consensus node, and sending a registration application message containing a public key, vh and Vp to verify the target consensus node to be accessed according to the public key and the Vp. In this way, the random access mode can avoid the illegal node from pertinently attacking a consensus node at a certain fixed position in the consensus network; meanwhile, the random access mode can play a role of random load to a certain extent, so that the stability of the network is improved.

Description

Node admittance method, consensus method, device, electronic equipment and storage medium

The present application is a divisional application of chinese patent application 202011293600.3 entitled "node admittance method, consensus method, apparatus, electronic device and storage medium" filed on 11/18/2020.

Technical Field

The present application relates to the field of blockchain technologies, and in particular, to a node admittance method, a node admittance device, an electronic device and a storage medium.

Background

The alliance chain has a certain admittance mechanism, and nodes participating in consensus are also distinguished from common nodes in terms of rights, so that the risk of interference of malicious nodes is reduced, and the efficiency of consensus is improved.

At present, an admission mechanism of a alliance chain introduces a group concept based on identity authentication, and nodes in a blockchain network are divided into different roles such as a common node, a core node, a consensus node, a verification node and the like, so that different authorities are given and different functions are born.

Currently, the admission mechanism of the alliance chain generally adopts an authentication mode based on a CA (Certificate Authority) center and a digital certificate, and a block chain core consensus network is constructed between nodes capable of participating in consensus (called consensus nodes for short herein). Different digital certificates are issued to nodes with different roles through a CA center, so that security measures such as bidirectional authentication, key negotiation, channel encryption and the like can be realized between the nodes and the consensus network, and malicious nodes are prevented from illegally accessing the blockchain network and even invading the core consensus network.

However, in the admission mode, admission authentication is performed on some relatively fixed verification nodes or CA centers, so that when an illegal node pertinently attacks a consensus node at a certain fixed position in the consensus network, the protection performance is poor, and related transactions are concentrated on the verification nodes or CA centers, so that overload of the verification nodes or CA centers is easily caused.

In addition, the universal digital certificate is in a pure software form, and identity authentication which only depends on the digital certificate can only prove that the digital certificate held by the nodes of the two parties of communication interaction is legal, and cannot guarantee whether the digital certificate is copied and faked. From a regulatory point of view, such a form is also disadvantageous for control of the consensus node and is not suitable for regulatory needs in a particular industry. Moreover, because the certificates and verification process are not associated with blockchain state information, it cannot be demonstrated whether the node is a legitimate active secure node, a masquerading malicious node, or a controlled contaminated node. Thus, without the customized admission mechanism for the blockchain network, not only would the security risk be brought to the blockchain consensus network, but also the related departments would be made difficult in supervising the blockchain network.

On the other hand, the consensus mechanism as one of the blockchain core technologies realizes the consistency of data among the blockchain network nodes, and the rationality of the consensus mechanism is one of main factors influencing the working efficiency and the safety of the blockchain.

The consensus mechanism is one of the core links of the blockchain. Currently, on the premise of a node admittance mechanism, a BFT (Byzantine Fault Tolerance, bayesian fault tolerance) -based Bayesian consensus algorithm is introduced in a consensus network of a blockchain core. The proposed blocks are consensus in the consensus network in a Bayesian and preemptive voting mode, so that the calculation power consumption required by mining is saved, and the block-out time and the consumption of resources are reduced. However, the following problems still exist in the current BFT-based consensus mechanism:

for the decision method of the block out weight, the BFT usually adopts a Leader (Leader) mechanism, and the Leader is responsible for proposing the block proposal of each round and then handing over to other consensus nodes for voting. However, the current Leader determining mechanism generally adopts a method that a range is determined by a certain algorithm, all consensus nodes in the range are used as Leader candidates to form a proposal group, each Leader candidate can propose a block proposal in the present round, each consensus node votes on all proposed block proposals according to a certain priority, a block needing consensus in the present round is selected, and then a consensus voting stage of the block can be entered. This, of course, increases the difficulty of consensus and reduces consensus efficiency.

In each round, each consensus node is required to broadcast its own vote and calculate and process votes sent by other consensus nodes, so as the number of consensus nodes increases, network storm is easy to block the consensus network, and the calculation burden is increased due to the information of all the consensus nodes which each consensus node is required to process.

Each consensus node needs to wait for enough network delay time to ensure that the states of most consensus nodes in the whole network can be kept synchronous before entering the next processing when waiting for voting from other consensus nodes. This way of synchronized waiting also poses an obstacle to improving consensus efficiency.

Disclosure of Invention

In order to solve the problem that in the existing admission mechanism, threshold control of node admission is loose, and in the case that an illegal node pertinently attacks a consensus node at a certain fixed position in a consensus network, the defense performance is poor, and uneven load of the node in the consensus network is easily caused, the embodiment of the application provides a consensus node admission method, which is applied to the node to be accessed and comprises the following steps:

generating a public key, a private key and a unique identifier of the self; generating a verifiable random number Vh and a certification Vp of the Vh by adopting a verifiable random function according to the private key and the unique identifier; determining a first selection base according to the Vh; selecting a target consensus node from the consensus network according to a preset selection standard based on the first selection base and the unique identification of each consensus node in the consensus network; and connecting the target consensus node, and sending a registration application message containing the public key, the Vh and the Vp to the target consensus node so that the target consensus node can verify the to-be-accessed consensus node according to the public key and the Vp.

Through the implementation process, the node to be accessed generates the proof Vp capable of verifying the random numbers Vh and Vh through the VRF (Verifiable Random Function ) according to the private key and the unique identifier of the node to be accessed, so that the target node to be accessed is selected and accessed based on the random numbers Vh, and a registration application message containing the public key of the node to be accessed, the Vh and the Vp is sent to the target node to be accessed, so that the target node to be accessed can verify the randomness of the random numbers Vh according to the public key and the Vp, and further verify the access randomness according to the Vh, and the access randomness of the node to be accessed is ensured. The random access mode can avoid that an illegal node pertinently attacks a consensus node at a certain fixed position in the consensus network, so that the consensus network can discover and prevent malicious access at the first time; meanwhile, the random access mode can play a role of random load to a certain extent, so that the stability of the network is improved. In addition, in the admittance process, based on the public key, the private key and the unique identifier, the unique identifier of each existing consensus node in the consensus network is combined, and the consensus network is enabled to always maintain a safe and controllable state in a verifiable random access mode, so that the admittance threshold of the consensus network is improved.

Further, the generating the self public key, private key and unique identification includes: installing a first security module audited and distributed by a preset admittance unit; and generating a public key and a private key of the first security module by adopting the first security module, and generating a unique identifier of the first security module according to the public key.

In the embodiment of the application, the first security module is audited and issued by a preset admittance unit, and the public key, the private key and the unique identifier are generated by the first security module to replace the CA center and the digital certificate, so that whether the first security module is issued or not needs to be audited by the admittance unit, and the legitimacy of the node to be accessed to the consensus can be ensured. The first security module is used for generating the public key, the private key and the unique identifier, so that the related data for performing admission verification can be effectively prevented from being copied and impoved, the admission threshold of the consensus network can be effectively improved, and the safety and controllability of the consensus nodes in the consensus network are ensured.

Further, the admission unit has data read-write authority of the first security module.

It should be understood that the data read-write permission of the first security module is open to the admission unit, so that the admission unit can effectively supervise the consensus node. For the scene with higher supervision requirements (such as the application of the blockchain in banking and monetary business and the like), the supervision requirements can be effectively met, and the safety and controllability of the blockchain are improved.

Further, the first security module is a hardware security module.

Compared with a software security module, the hardware security module is not attached to a network, so that the hardware security module has higher security and is not easy to attack by the network, and the security of data in the consensus node can be improved.

Further, before generating the unique identity of itself from the public key, the method further comprises: obtaining a root public key and a first root signature verifiable by the root public key from the admission unit; correspondingly, the generating the unique identifier of the self according to the public key comprises: and calculating the first root signature and the self public key to obtain the unique identifier.

Through the implementation process, the unique identifier of the to-be-accessed consensus node is associated with the first root signature and the public key of the first root signature. The first signature is data which are acquired by all consensus nodes from an admission unit, and a public key of the consensus node to be accessed is concurrent to a target consensus node in a first registration application message. In this way, the target consensus node can calculate the unique identifier of the consensus node to be accessed, so that the unique identifier of the unique identifier in the consensus network is verified, and the target consensus node can return the calculated unique identifier, so that the consensus node to be accessed realizes further verification, thereby avoiding the condition that the consensus node to be accessed is attracted by malicious nodes, and further improving the safety of the whole admission verification process.

Further, selecting a target consensus node from the consensus network according to a preset selection standard based on the first selection base and a unique identifier of each consensus node in the consensus network, including: selecting n candidate consensus nodes with unique identifiers closest to the first selection base from a consensus network; n is a preset positive integer greater than or equal to 1; and determining one candidate consensus node from the n candidate consensus nodes as the target consensus node.

Further, the method further comprises: and when the connection with the target consensus node fails, one candidate consensus node is redetermined from the n candidate consensus nodes and is used as the target consensus node for connection.

A plurality of candidate consensus nodes meeting selection criteria are predetermined, then one target node is determined to be connected, and when the connection fails, a new target consensus node can be selected again to be connected again. Therefore, when a certain consensus node fails in connection, the to-be-accessed consensus node cannot try to access the consensus network again, and the reliability of network access is ensured.

Further, the method further comprises: when receiving a registration response message aiming at the registration application message, verifying the registration response message; and when the number of the received registration response messages passing the verification is greater than or equal to a preset number threshold, determining that the registration is successful.

In the embodiment of the application, the target consensus node can send the registration application message to each consensus node in the consensus network to perform verification together, and each consensus node can return the registration response message after the verification is passed. Therefore, the processing state is notified to the to-be-accessed consensus node in a feedback mode of the multiple consensus nodes, and unnecessary leakage of key data caused by misleading of the to-be-accessed consensus node to access an illegal network can be effectively avoided.

Further, a root public key is obtained in advance in the consensus node to be accessed; the registration response message comprises a second root signature which can be verified by the root public key and a public key of a consensus node which sends the registration response message;

the verifying the registration response message when receiving the registration response message for the registration application message includes: verifying a second root signature in the registration response message using the root public key; when verification passes, calculating the unique identifier of the consensus node by adopting the public key of the consensus node and the second root signature; checking whether the calculated unique identifier of the consensus node is the unique identifier existing in the consensus network; if yes, verifying to pass; otherwise, the verification is not passed.

Through the implementation process, verification of the second root signature in the registration response message is realized based on the root public key, so that when verification passes, the unique identifier of the consensus node is obtained based on the second root signature and the public key of the consensus node, and further validity confirmation is performed based on the uniqueness of the unique identifier in the consensus network. Therefore, the network security can be effectively improved, and the risk that the node to be accessed to the consensus is misled to access the illegal network is reduced.

Further, the registration application message includes a first signature; the registration response message further includes: the consensus node sending the registration response message calculates the unique identifier of the consensus node to be accessed according to the public key and the first root signature in the registration application message; before the verification of the second root signature in the registration response message by using the root public key, the method further comprises: and determining that the unique identification in the registration response message is consistent with the unique identification of the registration response message.

In the embodiment of the application, the unique identifier of the to-be-accessed consensus node is calculated based on the first root signature and the public key of the to-be-accessed consensus node. If the consensus node sending the registration response message is a real consensus node in the consensus network, it must be able to verify correctly to obtain the first root signature, thus obtaining the correct unique identification of the consensus node to be accessed. Therefore, the node to be accessed can effectively verify the reliability of the node sending the registration response message by verifying the consistency of the unique identifier in the registration response message and the unique identifier of the node to be accessed, thereby further improving the security of the network.

Correspondingly, the embodiment of the application also provides a method for admitting the consensus node, which is applied to the consensus node and comprises the following steps: receiving a registration application message sent by a consensus node to be accessed; the registration application message contains a public key of the to-be-accessed consensus node, a verifiable random number Vh and a proof Vp of the Vh; verifying the validity of the Vh according to the public key of the consensus node to be accessed and Vp; after verification is legal, determining a first selection base according to the Vh; and when the unique identification of the consensus node and the first selection base meet the preset selection standard, updating the information of the consensus node to be accessed into a white list of the consensus node.

The public key based on the to-be-accessed public key of the public node can verify the validity of the random number Vh. On the premise that the Vh is legal, the unique identification of the present consensus node and the first selection base number should meet the preset selection standard because the present consensus node is selected by the to-be-accessed consensus node determining the first selection base number based on the Vh and the unique identification of each consensus node in the consensus network according to the preset selection standard. Based on the method, whether the unique identification and the first selection base number of the consensus node meet preset selection standards can be verified, so that the access randomness of the consensus node to be accessed is verified. And when the authentication is passed, namely the unique identification and the first selection base number of the self-consensus node meet the preset selection standard, updating the information of the to-be-accessed consensus node into the self white list, and allowing the to-be-accessed consensus node to be accessed. According to the scheme, by means of random access, the illegal node can be effectively prevented from pertinently attacking a certain consensus node at a fixed position in the consensus network, so that the consensus network can discover and prevent malicious access at the first time; meanwhile, the random access mode can play a role of random load to a certain extent, so that the stability of the network is improved. In addition, the embodiment of the application combines the unique identification of the consensus node, and enables the consensus network to always maintain a safe and controllable state in a verifiable random access mode, thereby improving the admission threshold of the consensus network.

Further, when the unique identification of the consensus node itself and the first selection base meet a preset selection criterion, the method further comprises: and feeding back a registration response message to the to-be-accessed consensus node, wherein the registration response message comprises a root signature which can be verified by a root public key and the public key of the consensus node so as to enable the to-be-accessed consensus node to verify the registration response message.

Further, the registration application message includes a first root signature of the node to be accessed; before feeding back the registration response message to the to-be-accessed consensus node, the method further comprises: according to the first signature and the public key in the registration application message, calculating to obtain the unique identifier of the to-be-accessed consensus node; and placing the calculated unique identifier of the node to be accessed into the registration response message.

The embodiment of the application also provides a consensus node admittance device which is applied to the consensus node to be accessed and comprises the following steps: the device comprises a first generation module, a determination module and a first connection processing module; the first generation module is used for generating a public key, a private key and a unique identifier of the first generation module, and generating a verifiable random number Vh and a certification Vp of the Vh by adopting a verifiable random function VRF according to the private key and the unique identifier; the determining module is used for determining a first selection base number according to the Vh, and selecting a target consensus node from the consensus network according to a preset selection standard based on the first selection base number and the unique identification of each consensus node in the consensus network; the first connection processing module is configured to connect the target consensus node, and send a registration application message including the public key, the Vh and the Vp to the target consensus node, so that the target consensus node verifies the to-be-accessed consensus node according to the public key and the Vp.

The embodiment of the application also provides a consensus node access device, which is applied to the consensus node and comprises the following steps: the device comprises a receiving module, a first verification module and a processing module; the receiving module is used for receiving a registration application message sent by a consensus node to be accessed; the registration application message contains a public key of the to-be-accessed consensus node, a verifiable random number Vh and a proof Vp of the Vh; the first verification module is used for verifying the validity of the Vh according to the public key of the to-be-accessed consensus node and Vp; and the processing module is used for determining a first selection base number according to the Vh after the authentication is legal, and updating the information of the to-be-accessed consensus node into a white list of the to-be-accessed consensus node when the unique identification of the consensus node and the first selection base number meet the preset selection standard.

The embodiment of the application also provides electronic equipment, which comprises: a processor, a memory, and a communication bus; the communication bus is used for realizing connection communication between the processor and the memory; the processor is configured to execute one or more programs stored in the memory to implement any of the above-described common node admission methods or common node admission methods.

The embodiment of the application also provides a readable storage medium, which stores one or more programs, and the one or more programs can be executed by one or more processors to implement any one of the above common node admittance method or the common node admittance method.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the embodiments of the present application will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present application and should not be considered as limiting the scope, and other related drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

Fig. 1 is a flow chart of a method for admitting a consensus node according to an embodiment of the present application;

fig. 2 is a flow chart of a general node admittance method provided in the embodiment of the present application;

fig. 3 is a flow chart of another general node admittance method according to the present embodiment;

fig. 4 is a schematic flow chart of a consensus method provided in an embodiment of the present application;

FIG. 5 is a diagram of an overall architecture provided in a fifth embodiment of the present application;

FIG. 6 is a schematic diagram of a consensus mechanism provided in an embodiment of the present application;

fig. 7 is a schematic structural diagram of a consensus node admittance device applied to a consensus node to be accessed according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of a consensus node admission device applied to a consensus node according to an embodiment of the present application;

fig. 9 is a schematic structural diagram of a general node admission device applied to a general node according to an embodiment of the present application;

fig. 10 is a schematic structural diagram of a common node admittance device applied to a consensus node according to an embodiment of the present application;

fig. 11 is a schematic structural diagram of another general node admission device applied to a general node according to an embodiment of the present application;

fig. 12 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application.

Embodiment one:

in order to solve the problems that in the existing admittance mechanism, threshold control of node admittance is loose, and the defending performance is poor for the condition that illegal nodes pertinently attack a common node at a certain fixed position in a common network, and uneven load of the node in the common network is easily caused, the embodiment of the application provides a common node admittance method.

Referring to fig. 1, fig. 1 is a basic flow diagram of an admission method of a consensus node provided in an embodiment of the present application, including:

s101: the node to be accessed to be identified generates own public key, private key and unique identification.

It should be noted that, in the embodiment of the present application, an admission unit may be set up in advance. In the embodiment of the application, the admittance unit may be a unit with the highest authority of the blockchain, and the admittance unit may be jointly formed by security devices of a supervision unit and related personnel.

In the embodiment of the application, the node to be accessed to the consensus applies for joining the consensus network, and can be checked by the admission unit first, so as to allocate the first security module. The first security module may be installed on the node to be accessed, so that a public key and a private key pair of the node to be accessed are generated through the first security module, and a unique identifier of the node to be accessed is generated according to the public key.

In the embodiment of the application, the admission unit can conduct qualification audit of the consensus node to be accessed through various modes such as manual operation.

In the embodiment of the application, the first security module is theoretically implemented by software or hardware, but the security is higher considering that the hardware is not easy to be attacked by the network relative to the software. In this embodiment, the first security module may be a hardware security module, and is distributed to the node to be accessed by the admission unit.

It should be understood that, in the embodiment of the present application, the hardware security module may be implemented in the form of UKEY, an encryption card, an encryption machine, etc., so long as it can store relevant data and support relevant cryptographic algorithms, and has a data processing capability.

In the embodiment of the application, the admission unit can produce and store a unique root key pair (a root public key and a root private key), randomly generate a root signature which can be verified by the root public key for each first security module based on the root public key, write the root public key and the root signature into the first security module together, and allocate the root public key and the root signature to the consensus node to be accessed, so that the method is convenient to use in subsequent verification. For example, the root private key may be used to sign the root public key by means of a random signature, so as to obtain a root signature. I.e. Signroot _j ＝Sign _PrikeyRoot (PubkeyRoot) in the formula, signroot _j Representing the root signature issued to node j, pubkeyRoot being the root public key, sign _PrikeyRoot The (PubkeyRoot) token signs the PubkeyRoot by adopting a root private key, and the root signatures obtained by different first security modules are different due to randomness introduced by a signature algorithm, but can be verified by the PubkeyRoot.

In this embodiment of the present application, after the first security module is installed on the to-be-accessed consensus node and generates the public key and the private key pair of the to-be-accessed consensus node, the unique identifier of the to-be-accessed consensus node can be generated according to the first root signature (for convenience of distinguishing and description, the root signature in the to-be-accessed consensus node is recorded as the first root signature) and the public key of the to-be-accessed consensus node. For example, a hash operation may be performed on the public key of the to-be-accessed consensus node and the first root signature, so as to obtain the unique identifier of the to-be-accessed consensus node. It should be understood that the hash operation is only an optional way to calculate the unique identifier in the embodiment of the present application, and other operation ways that can obtain the unique result based on the public key and the first root signature may be used to obtain the unique identifier, which is not limited in the embodiment of the present application.

It should be noted that the root public key may be configured as key data, which is not derivable in the first security module, thereby improving data security.

In the embodiment of the application, each data generation and processing process in the access process of the to-be-accessed consensus node can be completed in the first security module so as to improve security. In addition, the admission unit can have the data read-write authority of the first security module, so that supervision on all consensus nodes is facilitated.

In the embodiment of the application, the admission unit can issue the first security module offline without directly participating in the operation of the blockchain network, so that the data security is ensured. However, the admission unit may periodically obtain the latest state of the blockchain from the blockchain, such as the latest blockchain maximum height, the latest whitelist, etc. of the blockchain. It should be noted that, the whitelist in the embodiment of the present application is summarized by information of all the consensus nodes in the consensus network, where the information includes unique identifiers of all the consensus nodes, network addresses, communication ports, public keys, and the like.

S102: and the node to be accessed generates a verifiable random number Vh and a certification Vp of the Vh by adopting a verifiable random function according to the private key and the unique identifier of the node to be accessed.

Illustratively, in the present embodiment, vh and Proof Vp of the Vh may be generated by vh=vrf_hash (price, ID) and vp=vrf_proof (price, ID); alternatively, vh and the Proof Vp of the Vh may be generated by vh=vrf_hash (Hash (ID)) and vp=vrf_proof (Hash (ID)); in addition, the security can be further improved by combining the time stamp information, and Vh and the Proof Vp of the Vh are generated by vh=vrf_hash (Prikey, hash (id|time stamp)) and vp=vrf_proof (Prikey, hash (id|time stamp)).

In the above formulae, prikey represents a private key, ID represents a unique identifier, "|" is a connection symbol, and "id|timestamp" represents that ID and timestamp are connected together.

It should be understood that the function vrf_hash is a random number generation function of VRF, vrf_hash (Prikey, X) is a corresponding verifiable random number Vh indicating generation of X, vrf_proof is a random number Proof generation function of VRF, vrf_proof (Prikey, X) is a Proof indicating generation of vrf_hash (Prikey, X), and Hash (X) indicates Hash operation on X.

It should be understood that the foregoing are only a few possible ways of generating Vh and Vp from their own private keys and unique identifiers as illustrated in the embodiments of the present application, but are not representative of the ways that may be implemented in the embodiments of the present application. In fact, in the practical application process, engineers may design the corresponding manner of generating Vh and Vp according to actual needs, which is not limited in the embodiments of the present application.

S103: the first selection base is determined from Vh.

In the present embodiment, vh is a random number generated from a unique identifier, which is typically relatively close in form to the unique identifier. Thus, in an alternative implementation of the embodiments of the present application, the Vh may be used as the first selection base. In yet another alternative in the embodiment of the present application, hash (Vh) may be calculated, with Hash (Vh) as the first selection base.

S104: and selecting a target consensus node from the consensus network according to a preset selection standard based on the first selection base and the unique identification of each consensus node in the consensus network.

In the embodiment of the present application, the selection criteria are criteria that are preset by an engineer and are commonly observed by the entire consensus network. Illustratively, the selection criteria may be set as: n unique identifications closest to the first selection base in the consensus network; alternatively, there may be n unique identifications in the consensus network that are least close to the first selection base. In the embodiment of the application, the selection criteria can be set by engineers according to actual needs. The value of n should be an integer constant value of 1 or more.

It should be understood that in the embodiment of the present application, there may be only one, but there may also be multiple, determined target consensus nodes.

In this embodiment of the present application, when the first security module is dispatched, the admission unit may write the whitelist into the first security module, so that the target consensus node may be determined in the whitelist based on the first selection base.

S105: and connecting the target consensus nodes.

In the embodiment of the application, the white list records the network address and the communication port of each consensus node in the consensus network, so that the connection with the target consensus node can be established.

In the embodiment of the application, in order to prevent the situation that when the connection with a certain consensus node fails, the to-be-accessed consensus node cannot try to access the consensus network again, in the embodiment of the application, after the connection of the target consensus node fails, the target consensus node meeting the preset selection standard can be reselected to be connected again, so that the reliability of network access is ensured.

In an alternative implementation manner of the embodiment of the present application, n candidate consensus nodes with unique identifiers closest to the first selection base may be selected from the consensus network, and then one candidate consensus node is determined as the target consensus node from the n candidate consensus nodes.

Then, when the connection with the target consensus node fails, one candidate consensus node is redetermined from n candidate consensus nodes and is used as the target consensus node for connection.

S106: and sending a registration application message containing the public key, the Vh and the Vp to the target consensus node.

In order to improve the security in the data interaction process, the registration application message can be signed by the private key of the to-be-accessed consensus node, and then encrypted by the public key of the target consensus node.

S107: the target consensus node verifies the validity of Vh according to the public key and Vp in the registration application message.

It should be appreciated that based on the VRF technique, based on generating the public keys corresponding to the private keys of Vp and Vh, and Vp, it may be verified whether Vh is randomly generated based on the unique identifier of the node to be accessed, i.e. the validity of Vh may be verified. The specific verification process can be referred to the VRF technical manual, and will not be described in detail in this application.

In this embodiment of the present application, if the registration application message is signed with the private key of the node to be accessed, and then encrypted with the public key of the target node, the target node may decrypt the registration application message with its private key, and then verify the signature for verifying the registration application message with the public key in the registration application message. After the verification is passed, the public key and Vp in the registration application message are adopted to verify the validity of the Vh.

S108: after verifying the legitimacy, determining a first selection base according to Vh.

In the embodiment of the application, the determination manner of the first selection base is consistent with the determination manner in the consensus node to be identified. For example, when Hash (Vh) is used as the first selection base in the consensus node to be identified, hash (Vh) is also calculated in this step, so as to determine the first selection base.

S109: and when the unique identification and the first selection base number of the consensus node meet the preset selection standard, updating the information of the consensus node to be accessed into the white list of the consensus node.

On the premise that the Vh is legal, the target consensus node is selected by determining a first selection base number and unique identifiers of the consensus nodes in the consensus network based on the Vh by the to-be-accessed consensus node according to a preset selection standard, so that the unique identifiers of the target consensus node and the first selection base number meet the preset selection standard. Based on the method, whether the unique identification and the first selection base number of the target consensus node meet preset selection standards or not can be verified, so that the access randomness of the to-be-accessed consensus node is verified.

In this embodiment of the present application, when the unique identifier of the consensus node and the first selection base meet a preset selection criterion, a registration response message may also be fed back to the to-be-accessed consensus node, where the registration response message includes a second root signature (for convenience in description, the root signature of the consensus node is referred to as a second root signature) that may be verified by a root public key, and a public key of the consensus node, so that the to-be-accessed consensus node verifies the registration response message.

In the embodiment of the application, after receiving the registration response message, the to-be-accessed consensus node can verify the second root signature in the registration response message according to the root public key, calculate the unique identifier of the consensus node sending the registration response message according to the second root signature and the public key in the registration response message after the verification is passed, so as to verify whether the calculated unique identifier of the consensus node is the unique identifier existing in the consensus network (namely, whether the unique identifier is unique in a white list), if so, the verification is passed, and the registration response message is confirmed to be credible; otherwise, the verification is not passed.

In this embodiment of the present application, the registration application message sent by the node to be accessed may further include a first root signature of the node to be accessed. Therefore, the target consensus node can calculate and obtain the unique identifier of the consensus node to be accessed according to the first signature in the registration application message and the public key of the consensus node to be accessed.

At this time, whether the node to be accessed can be accepted can be further determined by verifying whether the calculated unique identifier of the node to be accessed is unique in the white list.

In addition, the unique identifier of the to-be-accessed consensus node obtained through calculation can be put into the registration response message and is sent to the to-be-accessed consensus node, so that the to-be-accessed consensus node can conveniently confirm the identity.

For example, the node to be accessed may perform the foregoing process of verifying the registration response message when it is determined that the unique identifier in the registration response message is identical to the unique identifier of the node to be accessed.

In this embodiment of the present application, after the verification is passed, the target consensus node may synchronize the registration application message to the rest of the consensus nodes in the consensus network, and the rest of the consensus nodes also perform verification, and after the verification is passed, update the information of the to-be-accessed consensus node to its own white list, and feed back the registration response message.

At this time, the node to be accessed can determine whether the registration of the node to be accessed is successful according to whether the number of the received registration response messages passing the verification is larger than a preset number threshold value. And when the number of the received registration response messages passing the verification is greater than or equal to a preset number threshold, determining that the registration is successful. Therefore, the processing state is notified to the to-be-accessed consensus node in a feedback mode of the multiple consensus nodes, and unnecessary leakage of key data caused by misleading of the to-be-accessed consensus node to access an illegal network can be effectively avoided.

In order to improve security in the data interaction process, when the common node feeds back the registration response message, the common node may sign the registration response message by using its own private key, and then encrypt the registration response message by using the public key of the to-be-accessed common node. At this time, after receiving the registration response message, the node to be accessed adopts the private key to decrypt, and then obtains the public key of the corresponding node to verify through inquiring the white list, thereby improving the data security.

It should be understood that, in order to improve security, in the embodiment of the present application, the registration application message may carry a timestamp, and it is required that the registration response message also carries the timestamp. Therefore, after receiving the registration response message, the node to be accessed can verify the consistency of the time stamp, thereby realizing the validity confirmation of the registration response message.

It should be noted that, in this embodiment of the present application, when the consensus network is initially constructed, the admission unit may send the first security module to at least 4 consensus nodes passing the audit in advance, where the first security module is written with a root public key and a root signature of each consensus node, so that each consensus node may install the root public key and the root signature, and generate a public key and a private key pair of each consensus node, and a unique identifier. And then summarizing the information of all the initial nodes into an initial white list, signing by each first security module, and storing the signed information under each consensus node.

Then, one of the consensus nodes is configured as a starting node, a hard-coded creation block is created and issued into the network, and the operation of the consensus mechanism is triggered. It should be noted that the triggered consensus mechanism is a consensus mechanism adopted in the actual application process. The existing consensus mechanism may be adopted, or the consensus mechanism proposed in the subsequent embodiments of the present application may be adopted.

Thus, the initial consensus network is built, and then if a new consensus node needs to be added, the admission verification can be performed according to the mode.

According to the public key and the unique identifier, the to-be-accessed consensus node can generate the proof Vp capable of verifying the random numbers Vh and Vh through the VRF, so that the target consensus node is selected and accessed based on the random numbers Vh, and a registration application message containing the public key of the to-be-accessed consensus node, the Vh and the Vp is sent to the target consensus node, so that the target consensus node can verify the randomness of the random numbers Vh according to the public key and the Vp, and further verify the access randomness according to the Vh, and the access randomness of the to-be-accessed consensus node is ensured. The random access mode can avoid that an illegal node pertinently attacks a consensus node at a certain fixed position in the consensus network, so that the consensus network can discover and prevent malicious access at the first time; meanwhile, the random access mode can play a role of random load to a certain extent, so that the stability of the network is improved. In addition, in the admittance process, based on the public key, the private key and the unique identifier, the unique identifier of each existing consensus node in the consensus network is combined, and the consensus network is enabled to always maintain a safe and controllable state in a verifiable random access mode, so that the admittance threshold of the consensus network is improved.

In addition, in this embodiment, the identification of the to-be-accessed consensus node may be performed through the admission unit, and the security of the key data may be ensured by allocating the hardware security module, so as to improve the admission threshold of the consensus network, and ensure the security and reliability of the to-be-accessed consensus node accessing the consensus network as much as possible.

Embodiment two:

in order to solve the problems that in the existing admittance mechanism, threshold control of node admittance is loose, and in addition, for the condition that an illegal node pertinently attacks a consensus node at a certain fixed position in a consensus network, the defending performance is poor, and uneven load of the node in the consensus network is easily caused, the embodiment of the application provides a common node admittance method.

Referring to fig. 2, fig. 2 is a basic flow diagram of a general node admittance method provided in an embodiment of the present application, including:

s201: the common node obtains the blockchain maximum Height and the whitelist of the latest consensus network.

In the embodiment of the application, the admission unit and the portal site can be pre-established.

In the embodiment of the application, the admission unit may configure the second security module and place the second security module in the portal site for the common node to acquire.

In embodiments of the present application, the portal site may be configured to allow only regular random access to consensus nodes, thereby obtaining non-sensitive information of the blockchain network, including blockchain maximum Height and the latest whitelist. It should be noted that, the whitelist in the embodiment of the present application is summarized by information of all the consensus nodes in the consensus network, where the information includes unique identifiers of all the consensus nodes, network addresses, communication ports, public keys, and the like.

S202: generating a public key and a private key of the self.

In the embodiment of the application, the common node can acquire the second security module from the portal site, so that the second security module generates the public key and the private key of the common node.

In order to facilitate the acquisition of the common node, in the embodiment of the present application, the second security module may be a software security module.

In addition, in the embodiment of the application, the admission unit can have the data read-write authority of the second security module, so that supervision on each consensus node is facilitated.

In the embodiment of the application, the user name and the password of the common node can be customized by a user. Thus, an account factor is calculated based on the user name and password, and the private key is encrypted using the account factor. Therefore, the preservation security of the private key can be improved, and the risk possibly brought by the leakage of the private key is reduced.

S203: a second selection radix is generated from the Height and the public key.

In the embodiment of the application, a second selection base can be obtained through a hash algorithm. For example, the data may be obtained by Hash (height|pubkey _User ) Or Hash (height|timestamp|pubkey) _User ) A second selection base is determined.

Note that, in the above description, pubkey _User Is the public key of the common node.

It should be appreciated that the determination of the second selection base may be accomplished by other algorithms than hashing, as long as a uniquely determined result is generated from the Height and public key.

S204: and determining the target consensus node corresponding to the unique identifier meeting the preset selection standard from the white list based on the second selection base.

In the embodiment of the present application, the selection criteria are criteria that are preset by an engineer and are commonly observed by the entire consensus network. Illustratively, the selection criteria may be set as: m unique identifiers closest to the first selection base in the consensus network; alternatively, there may be m unique identifications in the consensus network that are least close to the first selection base. In the embodiment of the application, the selection criteria can be set by engineers according to actual needs. The value of m should be an integer constant value of 1 or more.

S205: and connecting the target consensus node and sending an access request message to the target consensus node.

In the embodiment of the application, in order to prevent the situation that when the connection with a certain consensus node fails, the common node cannot try to access the consensus network again, in the embodiment of the application, after the connection of the target consensus node fails, the target consensus node meeting the preset selection standard can be reselected to be connected again, so that the reliability of network access is ensured.

In an alternative implementation manner of the embodiment of the present application, first, m candidate consensus nodes with unique identifiers closest to the first selection base may be selected from the consensus network, and then, one candidate consensus node is determined as the target consensus node from the m candidate consensus nodes.

Then, when the connection with the target consensus node fails, one candidate consensus node is redetermined from m candidate consensus nodes and is used as the target consensus node for connection.

S206: the target consensus node validates the access request message.

In the embodiment of the application, the access request message may contain the user name and the password or the hash value of the password of the common node, so that whether the user name of the common node is unique in the blockchain can be verified. If the user name of the common node is unique in the blockchain and the user name is not stored in each consensus node in the blockchain, the user name and the password can be locally associated and recorded, or the hash value of the user name and the password can be associated and recorded. And further establishes a secure channel with the ordinary node for communication.

It should be appreciated that the target consensus node may implement the determination of the uniqueness of the user name by querying the user name locally and querying the remaining consensus nodes when not locally.

In addition, in order to further improve security and defend against malicious intrusion, in the embodiment of the present application, a timestamp of a current time point and/or an acquired Height may be put in the access request message, so that the target consensus node may determine whether a common node requesting to access the blockchain is secure based on the timestamp and/or the Height.

For example, when the access request message further includes a time stamp when the common node requests access, the target consensus node may first determine that a time difference between the time stamp and the current time is within a preset range before verifying whether the user name of the common node is unique in the blockchain. If the access request is not within the preset range, the access of the common node can be refused, and the connection with the common node is disconnected.

It should be appreciated that for a malicious attack, a malicious node may have intercepted some access request message early in the process to attempt access. The time stamp carried in the access request message tends to be quite different from the current time. Therefore, the common node can be effectively proved to be a legal active safety node by the mode of time stamp verification, so that malicious invasion is effectively defended, and the safety of the blockchain is improved.

Similarly, when the access request message further includes a Height, the target consensus node may determine that the difference between the Height and the maximum Height of the current blockchain is within a preset range before verifying whether the user name of the common node is unique in the blockchain. If the access request is not within the preset range, the access of the common node can be refused, and the connection with the common node is disconnected.

Similarly, because the blockchain itself is growing continuously, if a malicious node intercepts an early access request message, or a randomly generated Height, then the deviation from the maximum Height of the current blockchain tends to be large. Therefore, the method for verifying through Height can effectively prove that the common node is a legal active security node, thereby effectively defending malicious invasion and improving the security of the blockchain.

It should be appreciated that, to improve security in the data interaction process, the access request message may be signed with the private key of the common node itself, and then encrypted with the public key of the target consensus node.

The public key of the common node is carried in the access request message, so that the target consensus node can firstly use the private key of the target consensus node to decrypt after receiving the access request message, and then use the public key in the access request message to verify whether the signature of the access request message is valid.

S207: and when the verification is legal, establishing a secure channel with the common node.

In the embodiment of the application, any available secure channel establishment mode may be used to establish the secure channel.

For example, after the target consensus node verifies that the target consensus node is legal, the target consensus node can randomly generate a temporary channel key factor KeyFac, sign and encrypt the temporary channel key factor KeyFac to obtain security channel establishment information, and return the security channel establishment information to the common node. The content of the security channel setup information mainly includes:

respbody=userid|timestamp|keyfac

ConnResp＝Encrypt _PubkeyUser (RespBody|Sign _PrikeyB (RespBody))

The target consensus node calculates a channel Key key=hash (keyfac|height|timestamp) and waits for the next communication.

In the foregoing formulae, the UserID is the user name of the common node, and the timestamp is the timestamp carried in the access request message (if the embodiment of the access request message does not carry the timestamp, the timestamp may not be added here). Pubkey user is the public key of the common node, prikeyB is the private key of the consensus node, sign _PrikeyB (RespBody) means that the RespBody is signed with PrikeyB; encrypt (r) _PubkeyUser (RespBody|Sign _PrikeyB (RespBody)) means that the Pubkeyuser pair (RespBody|Sign) is used _PrikeyB (RespBody)) are encrypted.

After receiving the security channel establishment information of the target consensus node, the common node decrypts and verifies the validity of the security channel establishment information, and the method comprises the following steps: by Prikey _User Decrypting the message, verifying the signature of the message by using Pubkey B of the target consensus node, and verifying that the UserID and the timestamp in the message are consistent with the sent user. Wherein, prikey _User Is the private key of the common node.

The common node calculates a channel Key by using the same method as the target consensus node, and the subsequent communication is encrypted by using the Key, so that a safety channel is established.

It should be noted that, in the access process of the common node, the second security module needs to be acquired and the public key and the private key of the second security module need to be generated only when the second security module is accessed for the first time. In the subsequent access process, only the latest Height and the latest white list are acquired, and the public key and the private key are not regenerated.

Through the implementation process of the embodiment of the application, random access can be realized by combining the maximum Height of the blockchain reflecting the latest state of the blockchain with the public key of the common node, and the random access mode can avoid that an illegal node pertinently attacks a consensus node at a certain fixed position in the consensus network, so that the consensus network can discover and prevent malicious nodes from accessing in the first time, and meanwhile, the random load can be played to a certain extent, and the load of the consensus node is balanced to a certain extent, thereby improving the stability of the network.

In addition, the security verification of the common node can be realized by combining with the Height, so that the problem of insufficient network security caused by the fact that the node is a legal active security node or a disguised malicious node or a controlled pollution node cannot be proved because the verification process is not associated with the blockchain state information in the existing access mechanism is solved.

Embodiment III:

in order to solve the problem that in the existing admittance mechanism, the verification process is not associated with the blockchain state information, so that whether the node is a legal active safety node or a disguised malicious node or a controlled pollution node cannot be proved, and the network security is insufficient, the embodiment of the application provides a common node admittance method.

Referring to fig. 3, the general node admittance method includes:

s301: the common node obtains the blockchain maximum Height and the whitelist of the latest consensus network.

Similar to the embodiments, in the embodiments of the present application, the admission units and portal sites may be pre-established. The portal site may be configured to allow only regular random access to consensus nodes to obtain non-sensitive information for the blockchain network, including blockchain maximum Height and up-to-date whitelists. The white list is summarized by the information of all the consensus nodes in the consensus network, wherein the information comprises the unique identification, network address, communication port, public key and the like of each consensus node.

S302: and determining the target consensus node from the white list.

Similar to the embodiment, in the embodiment of the present application, the common node may acquire the second security module from the portal site, so that the public key and the private key of the common node are generated by the second security module. The second security module may be configured by an admission unit and placed into the portal site for acquisition by the ordinary node. In order to facilitate the acquisition of the common node, in the embodiment of the present application, the second security module may be a software security module.

In the embodiment of the application, the second selection radix may be generated according to the Height and the public key; and determining the target consensus node corresponding to the unique identifier meeting the preset selection standard from the white list based on the second selection base.

S303: and connecting the target consensus node and sending an access request message to the target consensus node.

S304: the target consensus node verifies whether the difference between the Height in the access request message and the current maximum Height of the blockchain is within a preset range. If yes, go to step S305, otherwise, end.

Since the blockchain itself is growing continuously, if a malicious node intercepts an early access request message, or a randomly generated Height, its deviation from the maximum Height of the current blockchain tends to be large. Therefore, the method for verifying through Height can effectively prove that the common node is a legal active security node, thereby effectively defending malicious invasion and improving the security of the blockchain.

In the embodiment of the application, the access request message may also have a timestamp, so that the identity of the common node may be further verified by means of timestamp verification. For details, reference may be made to the description of the second embodiment.

In addition, in the embodiment of the application, the access request message also has the user name and the password or the hash value of the password of the common node, so that whether the user name of the common node is unique in the blockchain can be verified. If the user name of the common node is unique in the blockchain and the user name is not stored in each consensus node in the blockchain, the user name and the password can be locally associated and recorded, or the hash value of the user name and the password can be associated and recorded. And further establishes a secure channel with the ordinary node for communication.

By means of the method, admission verification can be achieved by combining the maximum Height of the blockchain reflecting the latest state of the blockchain, so that the common node can be proved to be a legal active safety node based on the Height, and the problem that in an existing admission mechanism, the node cannot be proved to be the legal active safety node or a disguised malicious node or a controlled pollution node because the node is not associated with blockchain state information in the verification process is solved.

It should be understood that, by the scheme of the first embodiment, the admission threshold of the consensus node can be improved, and the security and the supervision of the consensus network formed by the consensus node can be improved. And the safety of the common node accessing the blockchain can be improved by the mode of the second embodiment or the third embodiment. Therefore, in the embodiment of the application, the first embodiment and the second embodiment can be adopted at the same time, or the first embodiment and the third embodiment can be adopted at the same time, so that a better implementation effect is achieved.

When the first embodiment and the second embodiment are adopted at the same time, or the first embodiment and the third embodiment are adopted at the same time, the common node can be configured to not allow the initiation of the application transaction, and only the common user can initiate the application transaction (such as registering digital assets, asset transaction, etc.), so that the common node and the common node are subjected to authority distinction, thereby ensuring that the business undertaking of the blockchain core and the application part is safely isolated and controlled, and reducing the risk of impersonation and interference of malicious nodes.

Embodiment four:

in order to alleviate the problem of inefficiency in the existing consensus mechanism, the embodiment of the application provides a consensus method applied to a consensus network.

Referring to fig. 4, the consensus method includes:

s401: the round leader node initiates a first proposal and broadcasts to all consensus nodes in the consensus network.

It should be noted that, in the embodiment of the present application, the first proposal includes the block proposed by the current round leader node and the next round leader node of the proposal.

S402: each consensus node in the consensus network performs threshold signature on the first proposal and sends the signature result to the leading node of the next round.

S403: the next round leader node forms the threshold signature of each consensus node into an aggregate signature, and determines the next round leader node.

In the embodiment of the application, the next round leader node can be determined from all consensus nodes in the consensus network in a random mode. And the leading node of the next round is determined from all the consensus nodes in the consensus network randomly, so that the leading node is prevented from being predicted to be interfered, and the safety of the consensus network is improved.

For example, the third selection base may be determined according to the aggregate signature, and the consensus node with the threshold signature closest to the third selection base may be determined to be the leading node of the next round.

In this way, the threshold signature and the third selection base determine the leading node of the next round, that is, the leading node of the next round is selected from the voted consensus nodes, so that the empty selection risk can be effectively avoided, and the running reliability of the consensus mechanism is improved.

S404: the next round leader node initiates a second proposal and broadcasts to all consensus nodes in the consensus network.

In the embodiment of the application, the second proposal comprises a block of the new proposal, an aggregate signature and a leading node of the next round.

S405: and each consensus node in the consensus network verifies the validity of the aggregate signature, and when the verification passes, the verification result is fed back to the next round leader node.

In this embodiment of the present application, after the first proposal is subjected to the threshold signature by each consensus node, a verifiable random function may be respectively used to generate a verifiable random number Vh and a proof Vp of the Vh, and the Vh and Vp may be sent to the next round leader node.

Exemplary, assuming the present round is round n, the threshold signature result of each consensus node for the first proposal is noted as V _j*n J x n represents the j-th consensus node in round n. Each consensus node can independently calculate the following VRF data (noted VRF _j*n )：

Vh _j*n ＝VRF_Hash(Prikey _j ，Hash(Pn))

Vp _j*n ＝VRF_Proof(Prikey _j ，Hash(Pn))

In the formula, prikey _j To calculate the private key of the jth consensus node of the VRF data, pn is the first proposal for round n.

Then, in another possible implementation manner of the embodiment of the present application, a third selection base may be determined according to the aggregated signature, and a consensus node with Vh being the closest to the third selection base is determined to be a leading node of the next round.

For example, assuming that the present round is round n, a Hash (QC _n ) As a third selection radix, and with Hash (QC _n ) The closest 1 consensus node is found in the Vh sent by each node as the reference and is used as the leading node of the next round. Wherein QC _n An aggregate signature for round n.

Then, when the next round leader node broadcasts to all consensus nodes in the consensus network, QC is determined _n Vrf determined as the leading node of the next round _j*n And transmitted to the consensus node. Because of QC _n Is the result of threshold signature aggregation of each consensus node, so each consensus node can verify QC _n Is the legitimacy of (2). Thus, each consensus node can perform QC _n The validity verification is carried out, and the public key of the leading node of the next round can be obtained by searching the white list, so that the Vrf of the leading node of the next round can be based on the public key _j*n Vp of the further round of leader node, thereby verifying Vrf of the further round of leader node _j*n Is a random nature of (c).

After the verification is passed, each consensus node may execute step S405. If the verification is not passed, in an optional implementation manner of the embodiment of the present application, the lower round leader node may be notified to redetermine the next round leader node, or the lower round leader node may be used as the next round leader node, so as to ensure normal operation of the entire consensus mechanism.

It should be appreciated that in embodiments of the present application, the leader of each of the other rounds may be determined in the manner previously described, except for the first round and the second round. While the leader nodes of the first and second rounds may be specified by the engineer.

S406: and the leading node of the next round submits the first proposal to the database for storage when determining that the number of the authenticated consensus nodes reaches a preset threshold.

It should be noted that in the embodiment of the present application, there is one and only one leader node for each round. Thus, only one leader node is confirmed in each round, so that voting consumption can be simplified, and consensus efficiency can be improved.

It should be understood that in fact, the leader node of each of the rounds except the first and second rounds will perform the above-described operations of the present round leader node, the next round leader node, and the next round leader node at the same time. That is, in the embodiment of the present application, the leader node of each round except the first round and the second round is used as the leader node of the round, so as to propose the block to be determined in the round, and determine the leader node of the next round; meanwhile, the node is used as a leader node of the lower round, and the threshold signature of each consensus node aiming at the block proposed by the leader node of the upper round forms an aggregate signature; and meanwhile, the method is also used as a leading node of the next round, and aiming at the block proposed by the leading node of the previous round, the validity of the aggregate signature is verified, and when the number of the common nodes passing verification reaches a preset threshold, the proposal of the block is submitted to a database for storage.

Furthermore, since each of the leader nodes of the rounds except the first round and the second round perform the above-described operations of the leader node of the present round, the leader node of the next round, and the leader node of the next round at the same time, there may be two actions of submitting the proposals of the leader nodes of the previous round to the database at the same time and forming the aggregate signature by the threshold signature of the proposals of the leader node of the previous round at the same time in the content processed by the leader node of one round. Therefore, in order to facilitate the distinguishing of the proposal to be submitted to the database by the next round leader node in step S406, in the embodiment of the present application, after verifying the validity of the aggregate signature in step S405, the state of the first proposal in the memory may be updated (for example, a flag identifying that the verification is passed is set for the first proposal in the memory), so that the next round leader can submit the first proposal to the database according to the state of the proposal for saving.

It should be noted that, in the embodiment of the present application, for the leader nodes of the first round and the second round, an engineer may configure one consensus node as a start node (i.e., the leader node of the first round), and designate that the leader node of the second round still points to itself, so as to start the consensus mechanism.

By the scheme of the embodiment of the application, the block can be confirmed only by three rounds, and the consensus efficiency is higher. In addition, in the embodiment of the present application, the vote of the consensus node in each round is directly sent to the leader node in the determined next round, so that in each round, a plurality of block confirmation processes can be executed in parallel, and the consensus efficiency can be improved. Meanwhile, the consensus node sends the votes to the Leader node of the next round, and the votes are not returned to the Leader node of the round, so that the risk of malicious interference of a malicious node outside the consensus network on a Leader is avoided while the communication complexity is reduced, and the reliability of the network is improved.

Fifth embodiment:

the present embodiment further illustrates the solution of the present application based on the foregoing embodiments.

The overall architecture of the embodiment of the present application may be shown in fig. 5, including a service side and a user side. The service side consists of an access unit, a security module and a block chain service network based on an access mechanism, and the user side is a common node. The service side only provides related services such as user access, transaction, inquiry and the like for the user side by the blockchain service network.

Wherein:

the admission unit is responsible for establishment by a professional security company or a supervision department, and is used for providing a hardware security module (namely a first security module, which can be in the form of a UKEY, an encryption machine, an encryption card and the like) for a consensus node in the blockchain service network and providing a software security module (namely a second security module) for a portal site of the blockchain service.

And the hardware security module is issued to a consensus node in the blockchain network by an admission unit and is used for carrying out identity authentication, security registration and security communication when the consensus node is accessed to the consensus network.

And the software security module is issued to the common node by the access unit through the portal site and is used for participating in identity authentication and security communication when the common node accesses the blockchain network.

Consensus nodes are the basic components of a blockchain service network. The establishment is commonly responsible for the mechanisms which need to join the consensus network to participate in the consensus, and each node must install a hardware security module to be approved by other nodes in the network. The consensus node is responsible for handling various transactions requiring uplink and state of the blockchain in the consensus network, and the service scope of the responsible is limited to maintaining the consensus of data and system configuration in the blockchain network and providing blockchain related services for the common node. Thus, the consensus node is not allowed to initiate transactions, such as transactions, instead of or in addition to impersonating a common node, or is not approved.

The portal site is used as a first station of the common node access blockchain network, is responsible for establishment by a blockchain service provider, needs to import and store the software security module issued by the admission unit and the relevant necessary public information of the consensus network, and is accessed into the consensus network of the blockchain by the identity of the common node. Necessary information and software security modules for providing access to a common node and for accessing a blockchain network.

The common node can access the related services on the blockchain after accessing and registering the blockchain through the consensus node under the condition of installing the software security module, and can perform transactions of the blockchain application layer, such as: user registration, asset registration, querying, trading, etc.

A specific alternative embodiment is described in detail below:

in the initial stage, the service side firstly needs to establish an admission unit and produce enough hardware security modules and software security modules in the initial stage. On the basis, enough consensus nodes are used for installing and interconnecting hardware security modules, an initial consensus network is established, and an creation block is produced and a consensus mechanism is started to operate.

After the initial consensus network starts to operate, portal sites are required to be established, the portal sites and the admission units can access the consensus network, and non-key information of the blockchain network is obtained from the consensus network regularly. An early blockchain service network is built from portals and consensus networks.

The method has the advantages that a consensus network is needed to be added, a mechanism participating in the consensus is needed, an own node can be established, and a hardware security module is obtained from an admission unit and is accessed to the consensus network.

The common node acquires information and a software security module required by an access network through a portal site, accesses a blockchain network after installation, initiates a transaction request to a consensus network, synchronizes transaction pools of nodes among the consensus nodes, and further completes a transaction uplink process through a consensus mechanism.

The specific processing flow of each link is as follows:

1) Establishment of admission mechanism and consensus network:

the method comprises two stages of initial network establishment and consensus node admission registration:

a) Initial network establishment

The implementation method comprises the following steps:

i. an admission unit is established, and a unique secure root key pair (a root private key and a root public key PubkeyRoot) is produced and stored in the admission unit.

Production of a security module: the admission unit provides a hardware security module for the nodes needing to join the consensus network, and the form of the admission unit can be UKEY, an encryption card, an encryption machine and the like.

It should be noted that the hardware security module has related capabilities such as key generation and cryptographic operation, and the key data cannot be exported from the hardware security module in a plaintext form.

For each hardware security module, the admission unit independently signs the public key PubKeyRoot to obtain a root signature SignRoot _j ＝Sign _PrikeyRoot (PubkeyRoot) (note: signroot) _j Representing the root signature issued to consensus node j, sign _PrikeyRoot (PubkeyRoot) means signing PubkeyRoot with PrikeyRoot. Because of the randomness introduced by the signature algorithm, the root signatures obtained by different hardware security modules are different, but can be verified by PubKeyroot), and PubKeyroot is the same as that of PubKeyrootWriting to the hardware security module. Wherein PubkeyRoot as key data cannot be exported to the hardware security module.

installing a hardware security module: each consensus node needs to be correspondingly provided with a hardware security module issued by an admission unit.

It should be noted that, when each consensus node is initialized, the hardware security module generates a public-private key pair (private key _j And public key Pubkey _j Subscript j denotes the jth consensus node) and is stored in the hardware security module, wherein Prikey _j The hardware security module cannot be exported as critical data.

The consensus nodes calculate their own IDs _j ＝Hash(SignRoot _j |Pubkey _j ) As a unique identification of the consensus node.

Note that ID _j Representing the unique identity of the jth consensus node.

Establishing an initial consensus network: the network is formed by a set of initial consensus nodes (minimum of 4 consensus nodes) with hardware security modules installed.

And (3) summarizing the information of all the initial consensus nodes into an initial white list (denoted as WList), signing by each hardware security module, and storing the signature under each initial consensus node. The information of each consensus node in WList at least includes: unique identification ID of consensus node _j Network address, port of communication, public key Pubkey _j Etc.

And configuring one node in the initial network as a starting node, creating a hard-coded creation block, and releasing the hard-coded creation block into the initial consensus network to trigger the running of a consensus mechanism. (the operation of the consensus mechanism can be found in the description of the consensus mechanism below)

Network status update: after the initial network starts to operate, the admission unit and the portal site can periodically acquire non-key information related to the state of the blockchain such as the latest white list (denoted as WList) from the consensus network, and the non-key information is used for providing necessary information for the joining of new nodes.

b) The consensus node admittance registration:

the implementation method comprises the following steps:

i. and acquiring a hardware security module: after the initial consensus network is established, when a node to be accessed (marked as A) needs to apply for registration to join the consensus network, the node A needs to apply for an admission unit and acquire a newly produced hardware security module (comprising pubkey root and Signroot _A ) And the latest whitelist WList. Signroot _A Is the root signature generated for node a.

installing a hardware security module: when the node A is initialized, the hardware security module generates a public and private key pair (private key _A And public key Pubkey _A ) And ID _A 。ID _A Reference to the generation mode of (a) preamble ID _j As shown.

Random access consensus network: node a calculates and prepares data needed for connection through the hardware security module and attempts random access to the consensus network in this way. Comprising the following steps:

generating a set of verifiable random numbers:

Vh _A ＝VRF_Hash(Prikey _A ，Hash(ID _A timestamp)

Vp _A ＝VRF_Proof(Prikey _A ，Hash(ID _A Timestamp)

Computing Hash (Vh _A ) And finding the nearest 3 node IDs in the white list WList according to the result, sequentially trying to connect and initiating a registration application.

If the connection fails, repeating the current step (iii) for L times (L is a preset constant), and if the connection fails, giving up the operation.

iv, generating a registration application: after the node A is successfully connected to a certain consensus node (marked as B), generating and sending out a registration application message:

the content of the registration application message mainly comprises:

RegBody＝SignRoot _A |Pubkey _A time stamp Vh _A |Vp _A

RegReq＝Encrypt _PubkeyB (RegBody|Sign _PrikeyA (RegBody))

Note that "|" is a connection symbol, sign is a signatureFunction, sign _X () Characterization by X signing the content in brackets, encrypt as encryption function _X () The characterization encrypts the content in brackets with X.

It should be noted that, after signing with the private key of node a, the registration application message is encrypted with the public key of node B.

v. validating the registration application: after receiving the registration application message of the node A, the node B performs the following verification:

by Prikey _B Decrypting the message and using the Pubkey in the message _A The signature of the message is verified. Prikey _B Is the private key of the node B.

Verification of SignRoot with PubKeyRoot in hardware Security Module _A If the validity of the node A is legal, the ID of the node A is calculated _A ＝Hash(SignRoot _A |Pubkey _A )。

By Pubkey _A 、Vp _A Validating Vh _A Is valid, and if legal, calculates Hash (Vh _A ) And verifies the access randomness according to the white list.

Verifying access randomness from the whitelist includes: verifying unique identification ID of node B _B Whether or not to be white list and Hash (Vh _A ) One of the closest 3 unique identifications. If yes, the verification is passed, otherwise, the verification is not passed.

Synchronous registration application: after the verification of the node B is completed, the related information of the node A is synchronized to other consensus nodes, and the white list under the node A is updated.

Responding to the registration application: all nodes which verify the registration application of the node A, including the node B, generate and send registration response messages to the node A, and update the white list WList of the nodes:

The content of the registration response message mainly includes:

RespBody＝ID _A |SignRoot _j |Pubkey _j time stamp

RegResp＝Encrypt _PubkeyA (RespBody|Sign _Prikeyj (RespBody))

Description: the registration response message is encrypted by the public key of the node A after being signed by the private key of the node A.

Confirm registration success: the node a performs the following verification and processing on the received response message:

by Prikey _A Decrypting the message and using the Pubkey in the message _j Verifying the signature of a message, ID _A Should be consistent with its own ID and the timestamp should be consistent with the registration request message.

Verification of SignRoot with PubKeyRoot in hardware Security Module _j If the validity of the node j is legal, the ID of the node j is calculated _j ＝Hash(SignRoot _j |Pubkey _j ) And verifying whether the information is consistent with the information of the white list.

If the verification is passed, updating the relevant information including the white list under the node A. And when the number of the received response messages reaches a certain threshold value, confirming that the self registration is successful.

2) Random access of normal users:

the common users do not participate in consensus, and can access the blockchain network only after installing the software security module. The implementation method comprises the following steps:

i. establishing a portal site: when the portal site is initialized, a software security module provided by an admission unit needs to be imported and used for accessing the consensus network. Portal sites are only allowed to randomly select consensus nodes at regular intervals to acquire non-sensitive information of the blockchain network. The non-sensitive information includes at least the blockchain maximum Height and the whitelist WList of the most recent consensus nodes. In addition, none of the other application requests of the portal are accepted by the consensus network.

Acquiring a software security module: if a common node (denoted as User) is the first connection, a software security module (including PubkeyRoot and SignRoot) needs to be obtained from the portal site _soft ，SignRoot _soft The generation of (a) can be seen in the preamble for Signroot _j Is described in (c), a latest whitelist WList, and a blockchain maximum Height. If not the first time, only WList and Height need to be obtained.

installing a software security module:

when the User is initialized, the software security module calculates an account factor Userkey of the User according to the User name UserID and the password Passwd defined by the User. Such as: userkey=hash (userid|passwd). The User name UserID and the password Passwd do not need to be saved and are managed by the User.

The software security module randomly generates a public-private key pair (private key Prikey of the user _User And public key Pubkey _User ) Wherein Prikey _User And the storage management is carried out after the encryption by using a Userkey.

Random access network:

user computes a hash value associated with the current state of the blockchain: h=hash (height|timestamp|pubkey) _User )

The IDs of the 3 nearest consensus nodes to H are found in the whitelist WList, and the connection is attempted in turn. If the connection fails, repeating the current step (iv) L times, and if the connection is unsuccessful (L is a preset constant), discarding the operation.

Requesting access: after the connection consensus node (denoted as B) succeeds, the User generates and sends out an access request message.

The content of the access request message mainly comprises:

connbody=height|timestamp|pubkey _User |UserID|Hash(Passwd)

ConnReq＝Encrypt _PubkeyB (ConnBody|Sign _PrikeyUser (RegBody))

Description: after the access request message is signed by the private key of User, it is encrypted by the public key of node B.

validating the access request: after receiving the access message, the node B performs the following processing:

by Prikey _B Decrypting the message and using the Pubkey in the message _User The signature of the message is verified.

It is verified whether both the Height and the timestamp are within a reasonable range. If yes, the next step is carried out, otherwise, the access is not allowed.

Verifying userids, hashes (Passwd) in the consensus network requires that userids be unique in the consensus network and correspond to hashes (Passwd). When the local node does not have a record, the local node queries a plurality of consensus nodes randomly, and when the consensus nodes do not have the record, the user ID and the Hash (Passwd) are correspondingly added to the local record and are synchronized to other consensus nodes.

Establishing a secure channel: after the access verification is passed, a temporary security channel is established between the User and the consensus node so as to complete the following interaction behavior:

after verification, the node B randomly generates a temporary channel key factor KeyFac, signs and encrypts the temporary channel key factor KeyFac and returns the temporary channel key factor KeyFac to a User, and the security channel establishment information content mainly comprises:

Respbody=userid|timestamp|keyfac

ConnResp＝Encrypt _PubkeyUser (RespBody|Sign _PrikeyB (RespBody))

The node B calculates a channel Key key=hash (keyfac|height|timestamp) and waits for the next communication.

After receiving the response message of the node B, the User decrypts and verifies the legality of the message, including: by Prikey _User Decrypt the message and use the Pubkey of node B _B And verifying the signature of the message, verifying whether the UserID in the message is consistent with the user, and verifying whether the timestamp is consistent with the access request message sent by the user. If the two paths are consistent, the verification is passed, and if the two paths are inconsistent, the establishment of the safety channel can be ended.

The User calculates the channel Key in the same way as the node B, and the subsequent communications are encrypted with the Key.

3) Initiating an application transaction

In the embodiment of the application, the consensus node does not allow the initiation of the application transaction, and only the common node has the authority (such as registering digital assets, asset transactions, etc.). When a transaction needs to be initiated, the common node needs to send the transaction to the consensus node for processing, and the processing result is obtained. The implementation method comprises the following steps:

i. access network: the common node (denoted as User) randomly accesses the blockchain service network, establishes a secure channel with a certain consensus node (denoted as B), and inquires private state information (such as account balance, transaction bill, etc., which may be different according to the application things) of the User in the blockchain. Since the content of the transaction message is usually relatively large, the message is encrypted by the key of the secure channel in the following communication interaction process.

initiating a transaction: and after the network is successfully accessed, generating a transaction message according to the private-state information of the User and the actual requirement, and sending the transaction message to the node B.

The transaction message content mainly comprises: message ID (calculated from UserID, current timestamp, etc.), transaction list, message signature.

The transaction list may include a plurality of transactions, each of which includes at least a transaction specific content and a current timestamp.

iii, processing the transaction: after receiving the transaction message initiated by the User, the node B verifies whether the transaction content including the time stamp is valid. After passing the verification, the transaction pool is synchronized to all other consensus nodes for the next consensus processing.

Processing a status query: after the User sends out the transaction message, the state of the transaction can be queried at any other node in the random access consensus network.

4) Consensus mechanism and blockchain formation:

after the common user transaction is submitted to the consensus network, the transaction pools of the consensus nodes are synchronized, and then whether the transaction can be finally uplink or not is determined through a verification and consensus mechanism.

The process of the consensus mechanism adopts a chained round processing method based on Leader nodes (Leader) and voting, each round takes out effective matters from a transaction pool by a unique Leader in the consensus node, packages the effective matters into a new block by combining state information of a block chain, initiates a block proposal to broadcast the new block to other consensus nodes, and then carries out three rounds of voting and processing by all the consensus nodes, and finally determines the state of the new block on the chain. The implementation method comprises the following steps:

As can be seen in fig. 6, the consensus mechanism includes:

a) Generation and consensus process of the creation block:

the creation block is a hard-coded fixed block, and the Leader of the next round is still specified in the block proposal.

i. After the initial blockchain network is built, the initial state of the blockchain is not provided with any blocks. At this time (denoted as round 0), a certain common node (for example, node 1 in fig. 6) is configured as an initiating node, a hard-coded fixed block is created as an originating block, a Leader (denoted as L1) of the next round (i.e., round 1) still points to itself, the originating block and L1 are written together into a proposal (denoted as P0), and a broadcast is sent to all the common nodes.

After each consensus node (denoted node j) verifies the received proposal P0 (including verification of the generation block and L1), a threshold signature is applied to P0 to obtain a vote (denoted V _j*0 ) And independently calculate VRF data (denoted VRF) _j*0 ) Comprising:

Vh _j*0 ＝VRF_Hash(Prikey _j ，Hash(P0))

Vp _j*0 ＝VRF_Proof(Prikey _j ，Hash(P0))

each node will V _j*0 And Vrf _j*0 The Leader (L1) sent to round 1 is sent back to node 1.

Note that j 0 characterizes node j in round 0, j 1 characterizes node j in round 1, and so on.

The Leader of round 1 receives enough V's from each node _j*0 And Vrf _j*0 Afterwards, the votes are verified and counted, and a proposal of the next round is generated, which comprises the following steps:

Voting V by threshold signature method _j*0 Making an aggregate signature (noted QC) ₀ )，QC ₀ Will be the advertising result of the voting statistics of P0.

Computing Hash (QC) ₀ ) And by means of Hash (QC ₀ ) Vrf sent at each node as a benchmark _j*0 The closest 1 is found. Vrf from node k _k*0 For example, node k is determined as the Leader (denoted as L2) for the next round (i.e., round 2).

Correlation data (at least including: QC) ₀ 、L2+Vrf _k*0 And a new block generated with several transactions fetched from the transaction pool) to generate a new proposal (denoted P1), broadcast to all consensus nodes.

Each consensus node verifies and processes the received relevant data:

verification of QC ₀ Is the legitimacy of (2). Due to QC ₀ The result of threshold signature aggregation is carried out by each consensus node, so that each consensus node can verify QC ₀ Is the legitimacy of (2).

Verifying Vrf by finding the public key of the corresponding node k in the whitelist by L2 _k*0 The selection of the acknowledge down round header is randomly selected based on the latest state of the blockchain.

And verifying the validity of the block in P1.

After passing the verification, the state of the proposal P0 in the local memory of the node is modified into a state of 'ready to commit'. Generating a result QC of previous voting ₀ Voting (noted as VQC) _j*0 ) Voting V on New proposal P1 _j*1 And VRF data Vrf _j*1 And issuing the verified lower round Leader and L2.

v. the Leader of round 2 receives enough VQCs from each node _j*0 、V _j*1 And Vrf _j*1 Thereafter, a similar previous process completes the verification and statistics of the votes, generating a proposal for the next round, including:

to vote V _j*1 The polymerization signature is QC ₁ For the previous round QC ₀ Is voted to obtain an aggregate signature CQC ₀ ，CQC ₀ Nodes indicating that P0 may have been demonstrated to have a memory state update reach quorum (CQC ₀ As a flag that P0 is ultimately acknowledged).

Computing Hash (QC) ₁ ) And find the lower round Leader (taking node i as an example, denoted as L3)

Related data (at least including: CQC) ₀ 、QC ₁ 、L3+Vrf _i*1 And a new block generated with several transactions fetched from the transaction pool) to generate a new proposal (denoted P2), broadcast to all nodes.

Processing method similar to step iv after each node receives proposal P2 according to CQC ₀ Then it will be submitted to the local database for persistent saving along with P0.

b) General procedure for Generation and consensus of blocks

After creating the block consensus, the general process of block generation and consensus is similar to the process of round 2, shown as round n.

According to the scheme of the embodiment, at least the following effective effects are achieved:

1. The access threshold can be improved through a safety access mechanism based on a safety module and a random access method, so that the safety and controllability of newly added consensus nodes are ensured, and the requirement of supervision is met; and the newly added common node can also confirm that the network accessed by the node is reliable and reliable.

2. The hardware security module and the software security module are respectively installed on the consensus node and the common user, so that the consensus node and the common user are distinguished in authority, the business of a blockchain core and an application part is subjected to security isolation and control, and the risk of impersonation and interference of malicious nodes is reduced.

3. The consensus mechanism realizes a verifiable random determination mechanism per round based on the blockchain state and the VRF, wherein: the only Leader of each round simplifies the voting consumption and improves the consensus efficiency; the randomness determined by the Leader avoids interference caused by predicting the Leader, and improves the safety of the block chain network; and the next round Leader is determined from the nodes for voting, so that the empty selection risk is avoided, and the running reliability of the consensus mechanism is improved.

4. Each round of voting in the consensus mechanism is directly sent to the next round of Leader, so that the communication complexity is reduced, the risk of malicious interference of malicious nodes outside the consensus network on the Leader is reduced, and the reliability of the blockchain network is improved.

5. Furthermore, only three rounds are needed for one block from proposal to determination, thus improving consensus efficiency.

Example six:

based on the same inventive concept, the embodiment of the application also provides two common node admittance devices and three common node admittance devices. Referring to fig. 7 to 11, fig. 7 and 8 show common

node admittance apparatuses

100 and 200 corresponding to operations performed by a to-be-accessed common node and a target common node in the method shown in the first embodiment, fig. 9 and 10 show common

node admittance apparatuses

300 and 400 corresponding to operations performed by a common node and a target common node in the method shown in the second embodiment, respectively, and fig. 11 shows a common node admittance apparatus 500 corresponding to operations performed by a common node in the method shown in the third embodiment.

It should be understood that the specific functions of the common

node admission apparatuses

100 and 200, and the common

node admission apparatuses

300, 400, and 500 may be referred to the above description, and detailed descriptions are appropriately omitted herein to avoid redundancy. The common

node admission devices

100 and 200, the common

node admission devices

300, 400 and 500 comprise at least one software functional module that can be stored in a memory in the form of software or firmware or cured in the operating system of the common

node admission devices

100 and 200, the common

node admission devices

300, 400 and 500. Specifically:

Referring to fig. 7, the consensus node admission device 100 is applied to a consensus node to be accessed, and includes: a first generation module 101, a determination module 102 and a first connection processing module 103. Wherein:

the first generation module 101 is configured to generate a public key, a private key, and a unique identifier of the first generation module, and generate a verifiable random number Vh and a proof Vp of the Vh by using a verifiable random function VRF according to the private key and the unique identifier;

the determining module 102 is configured to determine a first selection base according to the Vh, and select a target consensus node from the consensus network according to a preset selection criterion based on the first selection base and a unique identifier of each consensus node in the consensus network;

the first connection processing module 103 is configured to connect the target consensus node, and send a registration application message including the public key, the Vh and the Vp to the target consensus node, so that the target consensus node verifies the to-be-accessed consensus node according to the public key and the Vp.

In this embodiment of the present application, the first generating module 101 is specifically configured to install a first security module audited and allocated by a preset admittance unit, generate a public key and a private key of the first security module by using the first security module, and generate a unique identifier of the first security module according to the public key.

In this embodiment of the present application, the admission unit has data read-write authority of the first security module.

In this embodiment of the present application, the first security module is a hardware security module.

In this embodiment, the determining module 102 is further configured to obtain, from the admission unit, a root public key and a first root signature that can be verified by the root public key before generating the unique identifier of the root public key according to the public key; correspondingly, the determining module 102 generates the unique identifier of the determining module according to the public key specifically includes: and calculating the first root signature and the self public key to obtain the unique identifier.

In this embodiment of the present application, the determining module 102 is specifically configured to select, from a consensus network, n candidate consensus nodes whose unique identifiers are closest to the first selection base; n is a preset positive integer greater than or equal to 1; and determining one candidate consensus node from the n candidate consensus nodes as the target consensus node.

In this embodiment of the present application, the first connection processing module 103 is further configured to, when connection with the target consensus node fails, re-determine one candidate consensus node from the n candidate consensus nodes as the target consensus node for connection.

In this embodiment of the present application, the determining module 102 is further configured to, when receiving a registration response message for the registration application message, verify the registration response message; and when the number of the received registration response messages passing the verification is greater than or equal to a preset number threshold, determining that the registration is successful.

In the embodiment of the application, a root public key is obtained in advance in the to-be-accessed consensus node; the registration response message comprises a second root signature which can be verified by the root public key and a public key of a consensus node which sends the registration response message; the determining module 102 is specifically configured to verify a second root signature in the registration response message using the root public key; when verification passes, calculating the unique identifier of the consensus node by adopting the public key of the consensus node and the second root signature; checking whether the calculated unique identifier of the consensus node is the unique identifier existing in the consensus network; if yes, verifying to pass; otherwise, the verification is not passed.

In this embodiment of the present application, the registration application message includes a first signature; the registration response message further includes: the consensus node sending the registration response message calculates the unique identifier of the consensus node to be accessed according to the public key and the first root signature in the registration application message; the determining module 102 is further configured to determine that the unique identifier in the registration response message is consistent with the unique identifier of the second signature before verifying the second signature in the registration response message using the root public key.

Referring to fig. 8, a consensus node admission device 200 is applied to a consensus node, and includes: a receiving module 201, a first verifying module 202 and a processing module 203. Wherein:

the receiving module 201 is configured to receive a registration application message sent by a node to be accessed; the registration application message contains a public key of the to-be-accessed consensus node, a verifiable random number Vh and a proof Vp of the Vh;

the first verification module 202 is configured to verify the validity of the Vh according to the public key of the node to be accessed and Vp;

the processing module 203 is configured to determine a first selection base according to the Vh after verifying that the node is legal, and update the information of the node to be accessed to a white list of the node when the unique identifier of the node and the first selection base meet a preset selection standard.

In this embodiment of the present application, the processing module 203 is further configured to, when the unique identifier of the consensus node and the first selection base meet a preset selection criterion, feed back a registration response message to the to-be-accessed consensus node, where the registration response message includes a second root signature that can be verified by a root public key, and a public key of the consensus node, so that the to-be-accessed consensus node verifies the registration response message.

In this embodiment of the present application, the registration application message includes a first root signature of the to-be-accessed consensus node; the processing module 203 is further configured to calculate, before feeding back a registration response message to the to-be-accessed consensus node, a unique identifier of the to-be-accessed consensus node according to a first root signature and a public key in the registration application message; and placing the calculated unique identifier of the node to be accessed into the registration response message.

Referring to fig. 9, a general node admission apparatus 300, applied to a general node, includes: a first acquisition module 301, a second generation module 302 and a second connection processing module 303. Wherein:

the first obtaining module 301 is configured to obtain a blockchain maximum Height and a whitelist of a latest consensus network; the white list comprises unique identifiers of all consensus nodes in the consensus network;

the second generation module 302 is configured to generate a public key and a private key of the second generation module, and generate a second selection base according to the Height and the public key;

the second connection processing module 303 is configured to determine, based on the second selection base, a target consensus node corresponding to a unique identifier that meets a preset selection criterion from the whitelist; connecting the target consensus node and sending an access request message to the target consensus node; and when receiving the security channel establishment information returned by the target consensus node, establishing a security channel according to the security channel establishment information.

In this embodiment of the present application, the second generating module 302 is specifically configured to obtain a second security module configured by a preset admittance unit from a preset portal site; and generating a public key and a private key of the second security module by adopting the second security module.

In this embodiment of the present application, the second security module is a software security module.

In this embodiment of the present application, the admission unit has data read-write authority of the second security module.

In this embodiment of the present application, the first obtaining module 301 is specifically configured to obtain the Height and the whitelist of the latest consensus network from a preset portal site.

In the embodiment of the application, a user name and a password are preset in the common node; the second generation module 302 is further configured to calculate an account factor according to the user name and the password, and encrypt the private key using the account factor.

In this embodiment of the present application, the second connection processing module 303 is specifically configured to select, from the whitelist, m candidate consensus nodes with unique identifiers closest to the second selection base; m is a preset positive integer greater than or equal to 1; and determining one candidate consensus node from the m candidate consensus nodes as the target consensus node.

In this embodiment of the present application, the second connection processing module 303 is further configured to, when connection with the target consensus node fails, re-determine one candidate consensus node from the m candidate consensus nodes as the target consensus node for connection.

Referring to fig. 10, a general node admittance apparatus 400 is applied to a common node, and includes: a second authentication module 401 and a processing unit 402. Wherein:

the second verification module 401 is configured to verify, when receiving an access request message sent by a common node, validity of the access request message;

the processing unit 402 is configured to establish a secure channel with the common node when the authentication is legal.

In this embodiment of the present application, the access request message includes a hash value of a user name and a password of the common node; the second verification module 401 is specifically configured to verify whether the user name of the common node is unique in the blockchain, and determine that the access request message is legal when the user name is unique.

In this embodiment of the present application, the access request message further includes a timestamp when the common node requests access; the second verification module 401 is further configured to determine that a time difference between the timestamp and the current time is within a preset range before verifying whether the user name of the common node is unique in the blockchain.

In this embodiment of the present application, the access request message further includes a maximum Height of the blockchain obtained when the common node requests access; the second verification module 401 is further configured to determine that a difference between the Height and a maximum Height of the current blockchain is within a preset range before verifying whether the user name of the common node is unique in the blockchain.

Referring to fig. 11, a general node admission apparatus 500, applied to a general node, includes: a second acquisition module 501 and a third connection processing module 502. Wherein:

the second obtaining module 501 is configured to obtain a blockchain maximum Height and a whitelist of the latest consensus network;

the third connection processing module 502 is configured to determine a target consensus node from the white list, connect the target consensus node, and send an access request message including the Height to the target consensus node, so that the target consensus node verifies the validity of the common node based on the Height; when receiving the safety channel establishment information returned by the target consensus node, establishing a safety channel according to the safety channel establishment information; the safety channel establishment information is feedback information sent by the target consensus node after the common node is verified to be legal based on the Height.

In this embodiment of the present application, the third connection processing module 502 is further configured to generate a public key and a private key of the third connection processing module. The third connection processing module 502 is specifically configured to generate a second selection radix according to the Height and the public key; and determining the target consensus node corresponding to the unique identifier meeting the preset selection standard from the white list based on the second selection base.

In this embodiment of the present application, the third connection processing module 502 is specifically configured to obtain a second security module configured by a preset admission unit from a preset portal site; and generating a public key and a private key of the second security module by adopting the second security module.

In addition, in the embodiment of the application, a consensus network is also provided, which corresponds to the method shown in the fourth embodiment.

The consensus network comprises a plurality of consensus nodes, wherein the consensus nodes comprise a current round leader node, a next round leader node proposed by the current round leader node and a next round leader node proposed by the next round leader node;

The round leader node is used for initiating a first proposal and broadcasting the first proposal to all consensus nodes in the consensus network; the first proposal comprises a proposed block and a proposed next round leader node;

each consensus node in the consensus network is used for carrying out threshold signature on the first proposal and sending a signature result to the next round leader node;

the lower round leader node is used for forming an aggregate signature from the threshold signatures of all the consensus nodes and determining a next round leader node;

the lower round leader node is further used for initiating a second proposal and broadcasting the second proposal to all consensus nodes in the consensus network; the second proposal comprises a new proposal block, the aggregate signature and the turn-down leader node;

each consensus node in the consensus network is further used for verifying the validity of the aggregate signature, and when verification passes, a verification result is fed back to the next round leader node;

and the next round leader node is used for submitting the first proposal to a database for storage when the number of the identified consensus nodes reaches a preset threshold value.

It should be noted that each node in the consensus network may be implemented by one or more electronic devices.

In the embodiment of the application, there is one and only one leader node for each round.

In this embodiment of the present application, the lower round leader node is specifically configured to randomly determine the lower round leader node from among all consensus nodes in the consensus network.

In this embodiment of the present application, the lower round leader node is specifically configured to determine a third selection radix according to the aggregate signature; and determining the consensus node with the closest threshold signature to the third selection base as the leading node of the next round.

In this embodiment of the present application, after each consensus node in the consensus network performs a threshold signature on the first proposal, each consensus node is further configured to generate a verifiable random number Vh and a proof Vp of the Vh by using a verifiable random function, and send the Vh and Vp to the lower round leader node.

In an embodiment of the present application, the second proposal further includes: vp and Vh of the next round leader node; each consensus node is further configured to obtain a public key of the further-down round leader node, and verify Vh of the further-down round leader node based on the public key and Vp of the further-down round leader node.

It should be understood that, for simplicity of description, the descriptions of the first to fourth embodiments are omitted in this embodiment.

Embodiment seven:

the present embodiment provides an electronic device, which may be seen in fig. 12, comprising a processor 1201, a memory 1202 and a communication bus 1203. Wherein:

the communication bus 1203 is used to enable coupled communication between the processor 1201 and the memory 1202.

The processor 1201 is configured to execute one or more programs stored in the memory 1202 to implement a common node admission method implemented by a to-be-accessed common node or a target common node in the first embodiment or implement a common node admission method implemented by a common node or a target common node in the second/third embodiments.

It will be appreciated that the configuration shown in fig. 12 is merely illustrative, and that the electronic device may also include more or fewer components than shown in fig. 12, or have a different configuration than shown in fig. 12, without limitation in the embodiments of the present application.

The electronic device in the embodiment of the application may be implemented by a device such as a server, a mobile terminal, a fixed terminal, or the like.

The present embodiment also provides a readable storage medium, such as a floppy disk, an optical disk, a hard disk, a flash memory, a usb disk, an SD (Secure Digital Memory Card, secure digital Card) Card, an MMC (Multimedia Card) Card, or the like, in which one or more programs for implementing the above steps are stored, and the one or more programs may be executed by one or more processors, so as to implement the method for admitting a common node implemented by the to-be-accessed common node or the target common node in the first embodiment, or implement the method for admitting a common node implemented by the common node or the target common node in the second/third embodiments. And will not be described in detail herein.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other manners. The above-described apparatus embodiments are merely illustrative, for example, the division of the units is merely a logical function division, and there may be other manners of division in actual implementation, and for example, multiple units or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be through some communication interface, device or unit indirect coupling or communication connection, which may be in electrical, mechanical or other form.

Further, the units described as separate units may or may not be physically separate, and units displayed as units may or may not be physical units, may be located in one place, or may be distributed over a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

Furthermore, functional modules in various embodiments of the present application may be integrated together to form a single portion, or each module may exist alone, or two or more modules may be integrated to form a single portion.

In this document, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions.

Herein, a plurality refers to two or more.

The foregoing is merely exemplary embodiments of the present application and is not intended to limit the scope of the present application, and various modifications and variations may be suggested to one skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the present application should be included in the protection scope of the present application.

Claims

1. The access method of the consensus node is characterized by being applied to the consensus node to be accessed and comprising the following steps:

generating a public key, a private key and a unique identifier of the self;

generating a verifiable random number Vh and a proof Vp of the Vh by adopting a verifiable random function VRF according to the private key and the unique identifier;

determining a first selection base according to the Vh;

selecting a target consensus node from the consensus network according to a preset selection standard based on the first selection base and the unique identification of each consensus node in the consensus network;

And connecting the target consensus node, and sending a registration application message containing the public key, the Vh and the Vp to the target consensus node so that the target consensus node can verify the to-be-accessed consensus node according to the public key and the Vp.

2. The method for admitting a consensus node according to claim 1, wherein said generating a public key, a private key and a unique identification of itself comprises:

installing a first security module audited and distributed by a preset admittance unit;

and generating a public key and a private key of the first security module by adopting the first security module, and generating a unique identifier of the first security module according to the public key.

3. The method of admittance of a consensus node according to claim 2, characterized in that said admittance unit has data read-write rights of said first security module.

4. The consensus node admission method according to claim 2, wherein the first security module is a hardware security module.

5. The consensus node admission method according to claim 2, wherein before generating the unique identity of itself from the public key, the method further comprises:

obtaining a root public key and a first root signature verifiable by the root public key from the admission unit;

Correspondingly, the generating the unique identifier of the self according to the public key comprises:

and calculating the first root signature and the self public key to obtain the unique identifier.

6. The consensus node admission method according to claim 1, wherein selecting a target consensus node from the consensus network according to a preset selection criterion based on the first selection base and a unique identification of each consensus node in the consensus network comprises:

selecting n candidate consensus nodes with unique identifiers closest to the first selection base from a consensus network; n is a preset positive integer greater than or equal to 1;

and determining one candidate consensus node from the n candidate consensus nodes as the target consensus node.

7. The consensus node admission method as in claim 6, wherein the method further comprises:

and when the connection with the target consensus node fails, one candidate consensus node is redetermined from the n candidate consensus nodes and is used as the target consensus node for connection.

8. The consensus node admission method according to any of claims 1-7, wherein the method further comprises:

When receiving a registration response message aiming at the registration application message, verifying the registration response message;

and when the number of the received registration response messages passing the verification is greater than or equal to a preset number threshold, determining that the registration is successful.

9. The method for admitting a consensus node according to claim 8, wherein a root public key is obtained in advance in said consensus node to be accessed; the registration response message comprises a second root signature which can be verified by the root public key and a public key of a consensus node which sends the registration response message;

the verifying the registration response message when receiving the registration response message for the registration application message includes:

verifying a second root signature in the registration response message using the root public key;

when verification passes, calculating the unique identifier of the consensus node by adopting the public key of the consensus node and the second root signature;

checking whether the calculated unique identifier of the consensus node is the unique identifier existing in the consensus network;

if yes, verifying to pass; otherwise, the verification is not passed.

10. The consensus node admission method as in claim 9, wherein the registration application message includes a first root signature; the registration response message further includes: the consensus node sending the registration response message calculates the unique identifier of the consensus node to be accessed according to the public key and the first root signature in the registration application message;

Before the verification of the second root signature in the registration response message by using the root public key, the method further comprises:

and determining that the unique identification in the registration response message is consistent with the unique identification of the registration response message.

11. The method for admitting the consensus node is characterized by comprising the following steps of:

receiving a registration application message sent by a consensus node to be accessed; the registration application message contains a public key of the to-be-accessed consensus node, a verifiable random number Vh and a proof Vp of the Vh;

verifying the validity of the Vh according to the public key of the consensus node to be accessed and Vp;

after verification is legal, determining a first selection base according to the Vh;

and when the unique identification of the consensus node and the first selection base meet the preset selection standard, updating the information of the consensus node to be accessed into a white list of the consensus node.

12. The consensus node admission method according to claim 11, wherein when the unique identification of the consensus node itself and the first selection base meet a preset selection criterion, the method further comprises:

and feeding back a registration response message to the to-be-accessed consensus node, wherein the registration response message comprises a second root signature which can be verified by a root public key and the public key of the consensus node so as to enable the to-be-accessed consensus node to verify the registration response message.

13. The method for admitting a consensus node according to claim 12, wherein said registration application message comprises a first root signature of said consensus node to be accessed; before feeding back the registration response message to the to-be-accessed consensus node, the method further comprises:

according to the first signature and the public key in the registration application message, calculating to obtain the unique identifier of the to-be-accessed consensus node;

and placing the calculated unique identifier of the node to be accessed into the registration response message.

14. An access device for a consensus node, which is characterized by being applied to the consensus node to be accessed and comprising: the device comprises a first generation module, a determination module and a first connection processing module;

the first generation module is used for generating a public key, a private key and a unique identifier of the first generation module, and generating a verifiable random number Vh and a certification Vp of the Vh by adopting a verifiable random function VRF according to the private key and the unique identifier;

the determining module is used for determining a first selection base number according to the Vh, and selecting a target consensus node from the consensus network according to a preset selection standard based on the first selection base number and the unique identification of each consensus node in the consensus network;

The first connection processing module is configured to connect the target consensus node, and send a registration application message including the public key, the Vh and the Vp to the target consensus node, so that the target consensus node verifies the to-be-accessed consensus node according to the public key and the Vp.

15. A consensus node admission device, characterized in that it is applied in a consensus node, comprising: the device comprises a receiving module, a first verification module and a processing module;

the receiving module is used for receiving a registration application message sent by a consensus node to be accessed; the registration application message contains a public key of the to-be-accessed consensus node, a verifiable random number Vh and a proof Vp of the Vh;

the first verification module is used for verifying the validity of the Vh according to the public key of the to-be-accessed consensus node and Vp;

and the processing module is used for determining a first selection base number according to the Vh after the authentication is legal, and updating the information of the to-be-accessed consensus node into a white list of the to-be-accessed consensus node when the unique identification of the consensus node and the first selection base number meet the preset selection standard.

16. An electronic device, comprising: a processor, a memory, and a communication bus;

The communication bus is used for realizing connection communication between the processor and the memory;

the processor is configured to execute one or more programs stored in the memory to implement the method of any one of claims 1 to 13.

17. A readable storage medium storing one or more programs executable by one or more processors to implement the method of any of claims 1-13.