Node access method, consensus method, device, electronic device and storage medium

Abstract

The present application provides a node access method, consensus method, device, electronic device and storage medium, the method comprising: obtaining the maximum height Height of the blockchain and the latest whitelist of the consensus network; the whitelist contains the unique identifier of each consensus node in the consensus network; generating its own public key and private key; generating a second selection base according to the Height and the public key; based on the second selection base, determining the target consensus node corresponding to the unique identifier that meets the preset selection criteria from the whitelist; connecting to the target consensus node and sending an access request message to the target consensus node; upon receiving the secure channel establishment information returned by the target consensus node, establishing a secure channel according to the secure channel establishment information. The present application can enable the consensus network to detect and prevent malicious nodes from accessing in the first place, and can also play the role of random load to a certain extent, balance the load of the consensus nodes to a certain extent, and improve the stability of the network.

Description

[0001] This application is a divisional application of Chinese patent application 202011293600.3, filed on November 18, 2020, entitled “Node access method, consensus method, device, electronic device and storage medium”. Technical Field

[0002] The present application relates to the field of blockchain technology, and more specifically, to a node access method, consensus method, device, electronic device, and storage medium. Background Art

[0003] The alliance chain has a certain access mechanism, and the nodes participating in the consensus are also differentiated from ordinary nodes in terms of rights, which reduces the risk of interference from malicious nodes and helps improve the efficiency of consensus.

[0004] At present, the access mechanism of the alliance chain introduces the concept of groups based on identity authentication, which divides the nodes in the blockchain network into different roles such as ordinary nodes, core nodes, consensus nodes, verification nodes, etc., grants different permissions, and assumes different functions.

[0005] Currently, the access mechanism for consortium blockchains generally uses an authentication method based on CA (Certificate Authority) centers and digital certificates. Nodes that can participate in consensus (herein referred to as consensus nodes) form the core consensus network of the blockchain. The CA center issues different digital certificates to nodes with different roles, enabling security measures such as two-way authentication, key agreement, and channel encryption between nodes and the consensus network. This prevents malicious nodes from illegally accessing the blockchain network and even invading the core consensus network.

[0006] However, this access method performs access authentication on relatively fixed verification nodes or CA centers. It has poor defense performance against illegal nodes that attack consensus nodes at a fixed location in the consensus network. In addition, related transactions are concentrated on the verification nodes or CA centers, which can easily lead to excessive load on the verification nodes or CA centers.

[0007] Furthermore, universal digital certificates are purely software-based. Identity authentication based solely on digital certificates can only verify the legitimacy of the digital certificates held by the communicating nodes, but cannot guarantee against duplication or misuse. From a regulatory perspective, this approach also hinders control over consensus nodes and is unsuitable for regulatory needs in specific industries. Furthermore, because the certificates and verification process are not linked to blockchain state information, it cannot verify whether a node is a legitimate, active, and secure node, or a disguised, malicious, or controlled, contaminated node. Therefore, without a customized access mechanism for blockchain networks, not only does it pose security risks to the consensus network, but it also creates difficulties for relevant authorities in regulating the network.

[0008] On the other hand, the consensus mechanism, as one of the core technologies of blockchain, realizes the consistency of data between blockchain network nodes. The rationality of the consensus mechanism is one of the main factors affecting the efficiency and security of blockchain work.

[0009] Consensus mechanisms are a core component of blockchains. Currently, based on node access mechanisms, Byzantine-style consensus algorithms based on BFT (Byzantine Fault Tolerance) have been introduced into the core consensus network of blockchains. This consensus algorithm uses Byzantine voting to reach consensus on proposed blocks, eliminating the computing power required for mining and reducing block generation time and resource consumption. However, the current BFT-based consensus mechanism still has the following issues:

[0010] BFT typically uses a leader mechanism to determine block production rights. The leader is responsible for proposing block proposals in each round, which are then voted on by other consensus nodes. However, the current leader determination mechanism generally uses an algorithm to determine a range. All consensus nodes within this range are considered leader candidates and form a proposal group. Each leader candidate submits a block proposal in this round. Consensus nodes then vote on all proposed block proposals based on a certain priority level to select the block that requires consensus in this round. Only then can the consensus voting phase for this block begin. This undoubtedly increases the difficulty of consensus and reduces consensus efficiency.

[0011] In each round, since each consensus node needs to broadcast its own vote and calculate and process the votes sent by other consensus nodes, as the number of consensus nodes increases, it is easy to cause network storms that block the consensus network, and the computing burden will also increase because each consensus node needs to process messages from all consensus nodes.

[0012] When waiting for votes from other consensus nodes, each consensus node needs to wait for sufficient network delay time to ensure that the status of most consensus nodes in the entire network is synchronized before proceeding to the next step. This synchronous waiting method also hinders improving consensus efficiency. Summary of the Invention

[0013] In order to solve the problem that the threshold control of node access in the existing access mechanism is relatively loose, and the defense performance is poor when illegal nodes attack a consensus node at a fixed position in the consensus network, and it is easy to cause uneven node load in the consensus network, the embodiment of the present application provides a common node admission method, which is applied to common nodes, including:

[0014] Obtain the maximum height Height of the blockchain and the latest whitelist of the consensus network; the whitelist contains the unique identifier of each consensus node in the consensus network; generate its own public key and private key; generate a second selection base according to the Height and the public key; based on the second selection base, determine the target consensus node corresponding to the unique identifier that meets the preset selection criteria from the whitelist; connect to the target consensus node and send an access request message to the target consensus node; when receiving the secure channel establishment information returned by the target consensus node, establish a secure channel according to the secure channel establishment information.

[0015] Through the above implementation process, random access can be achieved by combining the maximum height of the blockchain that reflects the latest status of the blockchain and the public key of the ordinary node. The random access method can prevent illegal nodes from attacking a consensus node at a fixed position in the consensus network in a targeted manner, so that the consensus network can detect and prevent malicious nodes from accessing at the first time. At the same time, it can also play the role of random load to a certain extent, balance the load of the consensus node to a certain extent, and thus improve the stability of the network.

[0016] Furthermore, the generating of the own public key and private key includes: obtaining a second security module configured by a preset access unit from a preset portal site; and generating the own public key and private key using the second security module.

[0017] In the embodiment of the present application, the access unit sets up a second security module and places it on a preset portal site for each ordinary node to obtain. This, on the one hand, can facilitate each ordinary node to obtain the corresponding security module. On the other hand, the second security module generates the public key, private key, and unique identifier, which can effectively prevent the relevant data used for access verification from being copied and misused, thereby effectively raising the entry threshold of the consensus network and ensuring that the consensus nodes in the consensus network are safe and controllable.

[0018] Furthermore, the second security module is a software security module.

[0019] Using a software security module as the second security module can facilitate the acquisition of ordinary nodes. At the same time, because ordinary nodes obtain the second security module from the portal site, it can achieve a certain degree of data separation between the consensus network and ordinary nodes, thereby improving the security of the consensus network.

[0020] Furthermore, the access unit has data reading and writing authority of the second security module.

[0021] It should be understood that the data read and write permissions of the second security module are open to access units, allowing access units to effectively supervise the consensus nodes. For scenarios with high regulatory requirements, this can effectively meet regulatory requirements and improve the security and controllability of the blockchain.

[0022] Furthermore, obtaining the maximum blockchain height Height and the latest consensus network whitelist includes: obtaining the Height and the latest consensus network whitelist from a preset portal site.

[0023] Furthermore, a user name and a password are preset in the common node; the method further comprises: calculating an account factor according to the user name and password; and encrypting the private key using the account factor.

[0024] In this embodiment of the present application, the username and password of a common node can be customized by the user to meet the needs of common business scenarios. Calculating an account factor based on the username and password and then using the account factor to encrypt the private key can improve the security of the private key and reduce the risk of private key leakage.

[0025] Furthermore, based on the second selection cardinality, determining a target consensus node corresponding to a unique identifier that meets a preset selection criterion from the whitelist includes: selecting m candidate consensus nodes from the whitelist whose unique identifiers are closest to the second selection cardinality; 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.

[0026] Furthermore, the method further includes: when connection with the target consensus node fails, re-determining a candidate consensus node from the m candidate consensus nodes as the target consensus node for connection.

[0027] By pre-determining multiple candidate consensus nodes that meet the selection criteria, and then determining a target node to connect to, and if the connection fails, re-selecting a new target consensus node to reconnect to, this can effectively prevent ordinary nodes from being unable to connect to the blockchain again due to a connection failure with a consensus node, thus ensuring the reliability of node access in the blockchain.

[0028] Correspondingly, an embodiment of the present application also provides a method for accessing an ordinary node, which is applied to a consensus node, including: upon receiving an access request message from an ordinary node, verifying the legitimacy of the access request message; upon verifying the legitimacy, establishing a secure channel with the ordinary node; the ordinary node establishes the secure channel with the consensus node through any of the aforementioned methods.

[0029] Furthermore, the access request message includes a hash value of the username and password of the ordinary node; the verification of the legitimacy of the access request message includes: verifying whether the username of the ordinary node is unique in the blockchain; if the username of the ordinary node is unique in the blockchain, and the consensus nodes in the blockchain do not store the username, then the hash value of the username and password is recorded locally in association.

[0030] Furthermore, the access request message also includes a timestamp when the ordinary node requests access; before verifying whether the username of the ordinary node is unique in the blockchain, the method also includes: determining that the time difference between the timestamp and the current time is within a preset range.

[0031] It should be understood that in the case of a malicious attack, a malicious node may have intercepted an earlier access request message to attempt access. In this case, the timestamp carried in the access request message will often differ significantly from the current time. Based on this idea, the above method can effectively prove that the ordinary node is a legitimate and active secure node, thereby effectively preventing malicious intrusions and improving the security of the blockchain.

[0032] Furthermore, the access request message also includes the maximum height Height of the blockchain obtained when the ordinary node requests access; before verifying whether the username of the ordinary node is unique in the blockchain, the method also includes: determining that the difference between the Height and the current maximum height of the blockchain is within a preset range.

[0033] Since the blockchain itself is constantly growing, if a malicious node intercepts an early access request message or randomly generates a height, the deviation between it and the current maximum height of the blockchain will often be large. Therefore, based on this idea, the above method can effectively prove that the ordinary node is a legitimate, active, and secure node, thereby effectively preventing malicious intrusions and improving the security of the blockchain.

[0034] To address the problem of insufficient network security caused by the existing access mechanism, in which the verification process is not associated with blockchain status information, and therefore cannot prove whether the node is a legitimate, active, secure node, or a disguised malicious node or a controlled, contaminated node, an embodiment of the present application provides a common node admission method, which is applied to common nodes and includes:

[0035] Obtain the maximum height Height of the blockchain and the latest whitelist of the consensus network; determine the target consensus node from the whitelist; connect to the target consensus node, and send an access request message containing the Height to the target consensus node, so that the target consensus node can verify the legitimacy of the ordinary node based on the Height; when receiving the secure channel establishment information returned by the target consensus node, establish a secure channel according to the secure channel establishment information; the secure channel establishment information is feedback information sent by the target consensus node after verifying the legitimacy of the ordinary node based on the Height.

[0036] Through the above implementation process, access verification can be implemented in combination with the maximum height of the blockchain that reflects the latest status of the blockchain. Therefore, it is possible to prove that the ordinary node is a legitimate, active, and secure node based on the height. This solves the problem of insufficient network security in the existing access mechanism, in which the verification process is not associated with the blockchain status information, and therefore it is impossible to prove whether the node is a legitimate, active, and secure node, or a disguised malicious node or a controlled contaminated node.

[0037] Furthermore, the method also includes: generating its own public key and private key; determining the target consensus node from the whitelist includes: generating a second selection base according to the Height and the public key; based on the second selection base, determining the target consensus node corresponding to the unique identifier that meets the preset selection criteria from the whitelist.

[0038] Furthermore, the generating of the own public key and private key includes: obtaining a second security module configured by a preset access unit from a preset portal site; and generating the own public key and private key using the second security module.

[0039] Furthermore, the second security module is a software security module.

[0040] Furthermore, the access unit has data reading and writing authority of the second security module.

[0041] An embodiment of the present application also provides an ordinary node access device, which is applied to an ordinary node, including: a first acquisition module, a second generation module and a second connection processing module; the first acquisition module is used to obtain the maximum height Height of the blockchain and the latest white list of the consensus network; the white list contains the unique identifier of each consensus node in the consensus network; the second generation module is used to generate its own public key and private key, and generate a second selection base based on the Height and the public key; the second connection processing module is used to determine, based on the second selection base, the target consensus node corresponding to the unique identifier that meets the preset selection criteria from the white list; connect to the target consensus node, and send an access request message to the target consensus node; when receiving the secure channel establishment information returned by the target consensus node, establish a secure channel according to the secure channel establishment information.

[0042] An embodiment of the present application also provides an ordinary node access device, which is applied to a consensus node and includes: a second verification module and a processing unit; the second verification module is used to verify the legitimacy of the access request message when receiving the access request message sent by the ordinary node; the processing unit is used to establish a secure channel with the ordinary node when verifying the legitimacy.

[0043] An embodiment of the present application also provides an ordinary node access device, which is applied to an ordinary node, including: a second acquisition module and a third connection processing module; the second acquisition module is used to obtain the maximum height Height of the blockchain and the latest whitelist of the consensus network; the third connection processing module is used to determine the target consensus node from the whitelist, connect to the target consensus node, and send an access request message containing the Height to the target consensus node, so that the target consensus node can verify the legitimacy of the ordinary node based on the Height; when receiving the secure channel establishment information returned by the target consensus node, establish a secure channel according to the secure channel establishment information; the secure channel establishment information is feedback information sent by the target consensus node after verifying the legitimacy of the ordinary node based on the Height.

[0044] An embodiment of the present application also provides an electronic device, comprising: a processor, a memory, and a communication bus; the communication bus is used to realize connection and communication between the processor and the memory; the processor is used to execute one or more programs stored in the memory to implement any of the above-mentioned consensus node admission methods or ordinary node admission methods.

[0045] A readable storage medium is also provided in an embodiment of the present application. The readable storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement any of the above-mentioned consensus node admission methods or ordinary node admission methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments of the present application. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without creative work.

[0047] Figure 1 A flowchart of a consensus node admission method provided in an embodiment of the present application;

[0048] Figure 2 A flowchart of a common node admission method provided in an embodiment of the present application;

[0049] Figure 3 A flowchart of another common node admission method provided in an embodiment of the present application;

[0050] Figure 4 A schematic diagram of a consensus process provided in an embodiment of the present application;

[0051] Figure 5 An overall architecture diagram provided in Example 5 of this application;

[0052] Figure 6 A schematic diagram of a consensus mechanism provided in an embodiment of the present application;

[0053] Figure 7 A schematic diagram of the structure of a consensus node admission device applied to a consensus node to be accessed, provided in an embodiment of the present application;

[0054] Figure 8 A schematic diagram of the structure of a consensus node admission device applied to a consensus node provided in an embodiment of the present application;

[0055] Figure 9 A schematic diagram of the structure of a common node admission device applied to a common node provided in an embodiment of the present application;

[0056] Figure 10 A schematic diagram of the structure of a common node admission device applied to a consensus node according to an embodiment of the present application;

[0057] Figure 11A schematic structural diagram of another common node admission device applied to a common node provided in an embodiment of the present application;

[0058] Figure 12 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0059] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0060] Example 1:

[0061] In order to solve the problem that the threshold control of node access in the existing access mechanism is relatively loose, and the defense performance is poor when illegal nodes target attacks on consensus nodes at a fixed position in the consensus network, and it is easy to cause uneven node load in the consensus network, a consensus node access method is provided in an embodiment of the present application.

[0062] See also Figure 1 As shown, Figure 1 A basic flow chart of a consensus node admission method provided in an embodiment of the present application includes:

[0063] S101: The consensus node to be connected generates its own public key, private key and unique identifier.

[0064] It should be noted that in the embodiment of the present application, an access unit can be set up in advance. In the embodiment of the present application, the access unit can be the unit with the highest authority in the blockchain, which can be composed of the security equipment and relevant personnel of the regulatory unit.

[0065] In an embodiment of the present application, a consensus node to be connected that wishes to apply to join the consensus network may first be reviewed by an access unit and then issued a first security module. The first security module may be installed on the consensus node to be connected, thereby generating a public key and private key pair for the consensus node to be connected, and generating its own unique identifier based on the public key.

[0066] In the embodiment of the present application, the access unit may conduct qualification review of the consensus node to be accessed through various methods such as manual review.

[0067] In the embodiment of the present application, the first security module can theoretically be implemented using software or hardware. However, considering that hardware is less susceptible to network attacks than software, it has higher security. Therefore, in the embodiment of the present application, the first security module can be a hardware security module, which is distributed by the access unit to the consensus node to be connected.

[0068] It should be understood that in the embodiments of the present application, the hardware security module can be implemented in the form of UKEY, encryption card, encryption machine, etc., as long as it can store relevant data and support relevant cryptographic algorithms and has data processing capabilities.

[0069] In the embodiment of the present application, the access unit can produce and save a unique root key pair (root public key and root private key), and randomly generate a root signature that can be verified by the root public key for each first security module based on the root public key, and write the root public key and root signature together into the first security module, and distribute them to the consensus node to be accessed, so as to facilitate subsequent verification. For example, the root private key can be used to sign the root public key by random signature to obtain the root signature. That is, SignRoot j =Sign PrikeyRoot (PubkeyRoot), where SignRoot j Indicates the root signature issued to node j, PubkeyRoot is the root public key, Sign PrikeyRoot (PubkeyRoot) represents the use of the root private key to sign PubkeyRoot. Due to the randomness introduced by the signature algorithm, the root signatures obtained by different first security modules are different, but they can all be verified by PubkeyRoot.

[0070] In an embodiment of the present application, the first security module can be installed on the consensus node to be accessed, and after generating the public key and private key pair of the consensus node to be accessed, it can generate a unique identifier of the consensus node to be accessed based on the first root signature therein (for the convenience of distinguishing the description, the root signature in the consensus node to be accessed is referred to as the first root signature in the embodiment of the present application) and the public key of the consensus node to be accessed. Exemplarily, a hash operation can be performed on the public key and the first root signature of the consensus node to be accessed to obtain a unique identifier of the consensus node to be accessed. 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. In addition to this, other calculation methods that can obtain a unique result based on the public key and the first root signature can also be used to obtain a unique identifier, which is not limited in the embodiment of the present application.

[0071] It should be noted that the root public key can be used as key data and configured as non-exportable in the first security module, thereby improving data security.

[0072] In this embodiment of the present application, all data generation and processing processes during the access process of the consensus node to be connected can be completed within the first security module to improve security. In addition, the access unit can have data read and write permissions in the first security module, thereby facilitating the supervision of each consensus node.

[0073] In the embodiments of the present application, the access unit can issue the first security module offline and does not need to directly participate in the operation of the blockchain network, thereby ensuring data security. However, the access unit can regularly obtain the latest status of the blockchain from the blockchain, such as the latest maximum height of the blockchain, the latest whitelist, etc. It should be noted that the whitelist described in the embodiments of the present application is compiled from the information of all consensus nodes in the consensus network, and the information therein includes the unique identifier, network address, communication port, public key, etc. of each consensus node.

[0074] S102: The consensus node to be connected uses a verifiable random function to generate a verifiable random number Vh and a proof Vp of Vh based on its own private key and unique identifier.

[0075] Exemplarily, in an embodiment of the present application, Vh and the proof Vp of Vh can be generated by Vh=VRF_Hash(Prikey, ID) and Vp=VRF_Proof(Prikey, ID); or, Vh and the proof Vp of Vh can be generated by Vh=VRF_Hash(Prikey, Hash(ID)) and Vp=VRF_Proof(Prikey, Hash(ID)); in addition, timestamp information can be combined to further improve security, and Vh and the proof Vp of Vh can be generated by Vh=VRF_Hash(Prikey, Hash(ID|timestamp)) and Vp=VRF_Proof(Prikey, Hash(ID|timestamp)).

[0076] It should be noted that, in the above formulas, Prikey represents the private key, ID represents the unique identifier, “|” is a connection symbol, and “ID|timestamp” represents connecting the ID and timestamp together.

[0077] It should be understood that the function VRF_Hash is the random number generation function of VRF, VRF_Hash(Prikey, X) indicates the generation of the verifiable random number Vh corresponding to X, VRF_Proof is the random number proof generation function of VRF, VRF_Proof(Prikey, X) indicates the generation of the proof corresponding to VRF_Hash(Prikey, X), and Hash(X) indicates the hash operation on X.

[0078] It should be understood that the above are only a few examples of feasible ways to generate Vh and Vp based on one's own private key and unique identifier in the embodiments of this application, but it does not mean that the embodiments of this application are implemented using only the above methods. In fact, in actual application, engineers can design corresponding methods for generating Vh and Vp according to actual needs, and this is not limited in the embodiments of this application.

[0079] S103: Determine a first selection base according to Vh.

[0080] In the embodiment of the present application, Vh is a random number generated based on the unique identifier, and its form is generally similar to the unique identifier. Therefore, in an optional implementation of the embodiment of the present application, Vh can be used as the first selection base. In another optional implementation of the embodiment of the present application, Hash(Vh) can be calculated and used as the first selection base.

[0081] S104: Based on the first selection base and the unique identifier of each consensus node in the consensus network, a target consensus node is selected from the consensus network according to a preset selection criterion.

[0082] In this embodiment of the present application, the selection criteria are pre-set by engineers and adhered to by the entire consensus network. For example, the selection criteria can be set to: the n unique identifiers in the consensus network closest to the first selection cardinality; or, alternatively, the n unique identifiers in the consensus network least close to the first selection cardinality. In this embodiment of the present application, the selection criteria can be set by engineers based on actual needs. Furthermore, the value of n should be an integer constant greater than or equal to 1.

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

[0084] In an embodiment of the present application, when distributing the first security module, the access unit can write a whitelist into the first security module, so that the target consensus node can be determined in the whitelist based on the first selection base.

[0085] S105: Connect to the target consensus node.

[0086] In an embodiment of the present application, the whitelist records the network address and communication port of each consensus node in the consensus network, based on which a connection can be established with the target consensus node.

[0087] In an embodiment of the present application, in order to prevent the situation where the consensus node to be connected cannot attempt to access the consensus network again when the connection with a consensus node fails, in an embodiment of the present application, after the target consensus node fails to connect, a target consensus node that meets the preset selection criteria can be reselected and reconnected, thereby ensuring the reliability of network access.

[0088] For example, in an optional implementation of the embodiment of the present application, n candidate consensus nodes whose unique identifiers are closest to the first selection cardinality can be selected from the consensus network, and then one candidate consensus node can be determined from these n candidate consensus nodes as the target consensus node.

[0089] Then, when the connection with the target consensus node fails, a new candidate consensus node is determined from the n candidate consensus nodes as the target consensus node for connection.

[0090] S106: Send a registration application message containing the public key, Vh and Vp to the target consensus node.

[0091] In order to improve the security of data interaction, the registration application message can be signed with the private key of the consensus node to be connected, and then encrypted with the public key of the target consensus node.

[0092] S107: The target consensus node verifies the legitimacy of Vh based on the public key and Vp in the registration application message.

[0093] It should be understood that based on VRF technology, based on the public key corresponding to the private key used to generate Vp and Vh, and Vp, it is possible to verify whether Vh is randomly generated based on the unique identifier of the consensus node to be accessed, that is, the legitimacy of Vh can be verified. The specific verification process can be found in the VRF technical manual and will not be detailed in this application.

[0094] In this embodiment of the present application, if the registration application message is first signed with the private key of the consensus node to be connected and then encrypted with the public key of the target consensus node, the target consensus node can first use its own private key to decrypt the registration application message, and then verify the signature of the registration application message using the public key in the registration application message. After the verification is successful, the public key in the registration application message and Vp are used to verify the legitimacy of Vh.

[0095] S108: After verification of legality, a first selection base is determined according to Vh.

[0096] In the embodiment of the present application, the method for determining the first selection cardinality should be consistent with the method for determining the consensus node to be identified. For example, if Hash(Vh) is used as the first selection cardinality in the consensus node to be identified, then Hash(Vh) is also calculated in this step to determine the first selection cardinality.

[0097] S109: When the unique identifier of the consensus node and the first selection base satisfy the preset selection criteria, the information of the consensus node to be connected is updated to its own whitelist.

[0098] Under the premise that Vh is legal, since the target consensus node is selected by the consensus node to be connected based on Vh, the first selection cardinality and the unique identifiers of each consensus node in the consensus network are determined according to the preset selection criteria, the unique identifier and first selection cardinality of the target consensus node should meet the preset selection criteria. Based on this, it is possible to verify whether the unique identifier and first selection cardinality of the target consensus node itself meet the preset selection criteria, thereby verifying the randomness of the access of the consensus node to be connected.

[0099] In an embodiment of the present application, when the unique identifier of the consensus node itself and the first selection base meet the preset selection criteria, a registration response message can also be fed back to the consensus node to be connected. The registration response message includes a second root signature that can be verified by the root public key (for ease of expression, the root signature of the consensus node is referred to as the second root signature in this application) and the public key of the consensus node, so that the consensus node to be connected can verify the registration response message.

[0100] In an embodiment of the present application, after receiving the registration response message, the consensus node to be connected can verify the second root signature in the registration response message based on the root public key, and after the verification is passed, calculate the unique identifier of the consensus node that sent the registration response message based on the second root signature and the public key in the registration response message, so as to verify whether the calculated unique identifier of the consensus node is a unique identifier already existing in the consensus network (that is, whether it is unique in the whitelist). If so, the verification is passed, confirming that the registration response message is credible; otherwise, the verification fails.

[0101] In this embodiment of the present application, the registration application message sent by the consensus node to be connected may also include the first root signature of the consensus node to be connected. This allows the target consensus node to calculate the unique identifier of the consensus node to be connected based on the first root signature in the registration application message and the public key of the consensus node to be connected.

[0102] At this point, whether the consensus node to be accessed can be accepted can be further determined by verifying whether the calculated unique identifier of the consensus node to be accessed is unique in the whitelist.

[0103] In addition, the calculated unique identifier of the consensus node to be accessed may be placed in the registration response message and sent back to the consensus node to be accessed, thereby facilitating identity confirmation of the consensus node to be accessed.

[0104] Exemplarily, the consensus node to be accessed may perform the aforementioned process of verifying the registration response message only when it determines that the unique identifier in the registration response message is consistent with its own unique identifier.

[0105] In an embodiment of the present application, after the target consensus node passes the verification, it can also synchronize the registration application message to the other consensus nodes in the consensus network, and the other consensus nodes will also perform verification. After the verification passes, the information of the consensus node to be connected will be updated to its own whitelist, and a registration response message will be fed back.

[0106] At this point, the consensus node to be connected can determine whether its registration is successful based on whether the number of verified registration response messages received is greater than a preset threshold. Registration is considered successful when the number of verified registration response messages received is greater than or equal to the preset threshold. In this way, by notifying the consensus node to be connected of the processing status through feedback from multiple consensus nodes, it can effectively prevent the consensus node to be connected from being misled into connecting to an illegal network, resulting in unnecessary leakage of critical data.

[0107] It should be noted that to improve the security of data exchange, when a consensus node sends back a registration response message, it can first sign the message with its own private key and then encrypt it with the public key of the consensus node to be connected. In this case, after receiving the registration response message, the consensus node to be connected first decrypts it with its own private key and then verifies it by querying the whitelist to obtain the public key of the corresponding consensus node, thereby improving data security.

[0108] It should be understood that, in order to improve security, in the embodiments of the present application, the registration request message may carry a timestamp, and the registration response message is required to carry the same timestamp. Thus, after receiving the registration response message, the consensus node to be connected can verify the consistency of the timestamp to confirm the legitimacy of the registration response message.

[0109] It should be noted that in the embodiments of the present application, when initially building a consensus network, the access unit may pre-distribute a first security module to at least four approved consensus nodes. The first security module contains the root public key and the root signature of each consensus node, which is then installed by each consensus node to generate a public and private key pair and a unique identifier for each consensus node. The information of all initial nodes is then aggregated into an initial whitelist, signed by each first security module, and stored under each consensus node.

[0110] Next, one of the consensus nodes is configured as the startup node, a hardcoded genesis block is created and published to the network, triggering the consensus mechanism to run. It should be noted that the consensus mechanism triggered is the consensus mechanism used in actual applications. This can be an existing consensus mechanism or the consensus mechanism proposed in the subsequent embodiments of this application.

[0111] In this way, the initial consensus network is built. If new consensus nodes need to be added later, access verification can be performed in the same way as described above.

[0112] Through the consensus node access method provided in this embodiment, the consensus node to be accessed can generate a verifiable random number Vh and a proof Vp of Vh through VRF based on its own private key and unique identifier, thereby selecting and accessing the target consensus node based on the random number Vh, and sending a registration application message containing the public key, Vh and Vp of the consensus node to be accessed to the target consensus node, so that the target consensus node can verify the randomness of the random number Vh based on the public key and Vp, and then verify the access randomness based on Vh, thereby ensuring the access randomness of the consensus node to be accessed. The random access method can prevent illegal nodes from attacking a consensus node at a fixed position in the consensus network, so that the consensus network can detect and prevent malicious access in the first time; at the same time, the random access method can also play a role of random load to a certain extent, thereby improving the stability of the network. In addition, the access process of this application is based on the public key, private key and unique identifier, combined with the unique identifier of each consensus node already in the consensus network, and through a verifiable random access method, the consensus network always maintains a secure and controllable state, thereby improving the access threshold of the consensus network.

[0113] In addition, in this embodiment, the access unit can be used to identify the consensus nodes to be accessed, and the security of key data can be ensured by allocating hardware security modules, thereby raising the access threshold of the consensus network and ensuring the security and reliability of the consensus nodes to be accessed in the consensus network as much as possible.

[0114] Example 2:

[0115] In order to solve the problem that the threshold control of node access in the existing access mechanism is relatively loose, and the defense performance is poor when illegal nodes attack the consensus node at a fixed position in the consensus network, and it is easy to cause uneven node load in the consensus network, a common node access method is provided in the embodiment of the present application.

[0116] See also Figure 2 As shown, Figure 2 A basic flow chart of a common node admission method provided in an embodiment of the present application includes:

[0117] S201: Ordinary nodes obtain the maximum height of the blockchain and the whitelist of the latest consensus network.

[0118] In the embodiment of the present application, access units and portal sites may be set up in advance.

[0119] In an embodiment of the present application, the access unit may configure a second security module and place it in the portal site for ordinary nodes to obtain.

[0120] In an embodiment of the present application, the portal site can be configured to only allow periodic random selection of consensus nodes, thereby obtaining non-sensitive information of the blockchain network, including the maximum height of the blockchain and the latest whitelist. It should be noted that the whitelist described in the embodiment of the present application is compiled from the information of all consensus nodes in the consensus network, including the unique identifier, network address, communication port, public key, etc. of each consensus node.

[0121] S202: Generate its own public key and private key.

[0122] In the embodiment of the present application, the common node may obtain the second security module from the portal site, so that the second security module generates the public key and private key of the common node itself.

[0123] To facilitate acquisition by ordinary nodes, in an embodiment of the present application, the second security module may be a software security module.

[0124] In addition, in an embodiment of the present application, the access unit may have data read and write permissions of the second security module, thereby facilitating the supervision of each consensus node.

[0125] In this embodiment of the present application, the user can also customize the username and password of the common node. Based on the username and password, an account factor is calculated and used to encrypt the private key. This improves the security of the private key storage and reduces the risk of private key leakage.

[0126] S203: Generate a second selected base according to the Height and the public key.

[0127] In the embodiment of the present application, a second selection base can be obtained by a hash algorithm. For example, Hash(Height|Pubkey User ) or Hash(Height|Timestamp|Pubkey User )Determine the second selection base.

[0128] It should be noted that Pubkey in the above formula User The public key of the ordinary node.

[0129] It should be understood that the second selected base may be determined by other algorithms besides the hash algorithm, as long as a unique result can be generated based on the Height and the public key.

[0130] S204: Based on the second selection base, a target consensus node corresponding to a unique identifier that meets a preset selection criterion is determined from the whitelist.

[0131] In this embodiment of the present application, the selection criteria are pre-set by engineers and adhered to by the entire consensus network. For example, the selection criteria can be set to: the m unique identifiers in the consensus network closest to the first selection cardinality; or, alternatively, the m unique identifiers in the consensus network least close to the first selection cardinality. In this embodiment of the present application, the selection criteria can be set by engineers based on actual needs. Furthermore, the value of m should be an integer constant greater than or equal to 1.

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

[0133] S205: Connect to the target consensus node and send an access request message to the target consensus node.

[0134] In an embodiment of the present application, the whitelist records the network address and communication port of each consensus node in the consensus network, based on which a connection can be established with the target consensus node.

[0135] In an embodiment of the present application, in order to prevent the situation where an ordinary node cannot try to access the consensus network again when the connection with a consensus node fails, in an embodiment of the present application, after the connection with the target consensus node fails, a target consensus node that meets the preset selection criteria can be reselected and reconnected, thereby ensuring the reliability of network access.

[0136] For example, in an optional implementation of the embodiment of the present application, m candidate consensus nodes whose unique identifiers are closest to the first selection cardinality can be selected from the consensus network, and then one candidate consensus node can be determined from these m candidate consensus nodes as the target consensus node.

[0137] Then, when the connection with the target consensus node fails, a new candidate consensus node is determined from the m candidate consensus nodes as the target consensus node for connection.

[0138] S206: The target consensus node verifies the access request message.

[0139] In this embodiment of the present application, the access request message may contain the username and password of the ordinary node, or a hash of the password, to verify whether the username of the ordinary node is unique within the blockchain. If the username of the ordinary node is unique within the blockchain, and the consensus nodes in the blockchain do not store the username, the username and password, or the hash of the username and password, may be locally associated and recorded. A secure channel may then be established with the ordinary node for communication.

[0140] It should be understood that the target consensus node can determine the uniqueness of the username by querying the username locally and querying other consensus nodes if the username is not found locally.

[0141] In addition, in order to further improve security and defend against malicious intrusions, in an embodiment of the present application, the timestamp of the current time point and / or the obtained Height can be placed in the access request message, so that the target consensus node can determine whether the ordinary node requesting access to the blockchain is safe based on the timestamp and / or Height.

[0142] For example, when the access request message also includes the timestamp of the ordinary node's access request, the target consensus node may first determine whether the time difference between the timestamp and the current time is within a preset range before verifying whether the ordinary node's username is unique in the blockchain. If not, the target consensus node may deny access to the ordinary node and disconnect from it.

[0143] It should be understood that in the case of a malicious attack, a malicious node may intercept an earlier access request message and attempt to access the blockchain. In this case, the timestamp carried in the access request message will often differ significantly from the current time. Therefore, the above timestamp verification method can effectively prove that the ordinary node is a legitimate and active secure node, thereby effectively preventing malicious intrusions and improving the security of the blockchain.

[0144] Similarly, when the access request message also includes a Height, the target consensus node can first determine whether the difference between the Height and the current maximum height of the blockchain is within a preset range before verifying whether the user name of the ordinary node is unique in the blockchain. If it is not within the preset range, the target consensus node can deny access to the ordinary node and disconnect from it.

[0145] Similarly, since the blockchain itself is constantly growing, if a malicious node intercepts an early access request message or randomly generates a height, the deviation from the current maximum height of the blockchain will often be large. Therefore, the above-mentioned height verification method can effectively prove that the ordinary node is a legitimate, active, and secure node, thereby effectively preventing malicious intrusions and improving the security of the blockchain.

[0146] It should be understood that in order to improve the security during data interaction, the access request message can first be signed using the private key of the ordinary node itself, and then encrypted using the public key of the target consensus node.

[0147] The public key of the ordinary node itself is carried in the access request message, so that after receiving the access request message, the target consensus node can first use its own private key to decrypt it, and then use the public key in the access request message to verify whether the signature of the access request message is valid.

[0148] S207: When verifying legitimacy, establish a secure channel with the common node.

[0149] In the embodiment of the present application, any available secure channel establishment method can be used to establish a secure channel.

[0150] For example, after the target consensus node is verified to be legitimate, it can randomly generate a temporary channel key factor KeyFac, sign and encrypt it to obtain a secure channel establishment message, and return it to the ordinary node. The content of the secure channel establishment message mainly includes:

[0151] RespBody=UserID|Timestamp|KeyFac

[0152] ConnResp=Encrypt PubkeyUser (RespBody|Sign PrikeyB (RespBody))

[0153] The target consensus node calculates the channel key Key = Hash(KeyFac|Height|timestamp) and waits for the next communication.

[0154] It should be noted that in the above formulas, UserID is the user name of the common node, and the timestamp is the timestamp carried in the access request message (if the corresponding implementation method is that the access request message does not carry a timestamp, then the timestamp can also be omitted here). PubkeyUser is the public key of the common node, PrikeyB is the private key of the consensus node, and Sign PrikeyB (RespBody) indicates that PrikeyB is used to sign RespBody; Encrypt PubkeyUser (RespBody|Sign PrikeyB (RespBody)) indicates the use of PubkeyUser pair (RespBody|Sign PrikeyB (RespBody)) is encrypted.

[0155] After receiving the secure channel establishment information from the target consensus node, the ordinary node decrypts and verifies the legitimacy of the secure channel establishment information, including: using Prikey User Decrypt the message and verify the signature of the message with PubkeyB of the target consensus node, and verify that the UserID and timestamp in the message are consistent with those sent by itself. User The private key of the ordinary node.

[0156] Ordinary nodes calculate the channel key using the same method as the target consensus node, and all subsequent communications are encrypted with the key to establish a secure channel.

[0157] It should be noted that during the access process of a normal node, the second security module is only required to generate its own public and private keys during the initial access. In subsequent access processes, only the latest height and whitelist are required, and the public and private keys do not need to be regenerated.

[0158] Through the above-mentioned implementation process of the embodiment of the present application, random access can be achieved by combining the maximum height of the blockchain Height that reflects the latest state of the blockchain and the public key of the ordinary node. The random access method can prevent illegal nodes from targetedly attacking a consensus node at a fixed position in the consensus network, so that the consensus network can detect and prevent malicious nodes from accessing at the first time. At the same time, it can also play the role of random load to a certain extent, balance the load of the consensus node to a certain extent, and thus improve the stability of the network.

[0159] In addition, in the embodiments of the present application, Height can also be combined to implement security verification of ordinary nodes, thereby solving the problem of insufficient network security caused by the existing access mechanism, in which the verification process is not associated with the blockchain status information, so it cannot be proved whether the node is a legitimate, active, and secure node, or a disguised malicious node or a controlled contaminated node.

[0160] Example 3:

[0161] In order to solve the problem of insufficient network security caused by the existing access mechanism, in which the verification process is not associated with the blockchain status information, and therefore it cannot be proved whether the node is a legitimate, active, and secure node, or a disguised malicious node or a controlled, contaminated node, a common node access method is provided in an embodiment of the present application.

[0162] See also Figure 3 As shown, the common node admission method includes:

[0163] S301: Ordinary nodes obtain the maximum height of the blockchain and the latest consensus network whitelist.

[0164] Similar to the second embodiment, in this embodiment of the present application, access units and portal sites can be pre-established. The portal site can be configured to only allow periodic random selection of consensus nodes, thereby obtaining non-sensitive information of the blockchain network, including the maximum height of the blockchain and the latest whitelist. The whitelist is compiled from the information of all consensus nodes in the consensus network, including the unique identifier, network address, communication port, public key, etc. of each consensus node.

[0165] S302: Determine the target consensus node from the whitelist.

[0166] Similar to Example 2, in this embodiment of the present application, a common node can obtain a second security module from the portal site, which then generates the common node's own public and private keys. The second security module can be configured by the access unit and placed in the portal site for common nodes to obtain. To facilitate common nodes' access, in this embodiment of the present application, the second security module can be a software security module.

[0167] In this embodiment of the present application, the user can also customize the username and password of the common node. Based on the username and password, an account factor is calculated and used to encrypt the private key. This improves the security of the private key storage and reduces the risk of private key leakage.

[0168] In addition, in an embodiment of the present application, the access unit may have data read and write permissions of the second security module, thereby facilitating the supervision of each consensus node.

[0169] In an embodiment of the present application, the portal site can be configured to only allow periodic random selection of consensus nodes, thereby obtaining non-sensitive information of the blockchain network, including the maximum height of the blockchain and the latest whitelist. It should be noted that the whitelist described in the embodiment of the present application is compiled from the information of all consensus nodes in the consensus network, including the unique identifier, network address, communication port, public key, etc. of each consensus node.

[0170] In an embodiment of the present application, a second selection base can be generated according to the Height and the public key; based on the second selection base, the target consensus node corresponding to the unique identifier that meets the preset selection criteria is determined from the whitelist.

[0171] In this embodiment of the present application, the selection criteria are pre-set by engineers and adhered to by the entire consensus network. For example, the selection criteria can be set to: the m unique identifiers in the consensus network closest to the first selection cardinality; or, alternatively, the m unique identifiers in the consensus network least close to the first selection cardinality. In this embodiment of the present application, the selection criteria can be set by engineers based on actual needs. Furthermore, the value of m should be an integer constant greater than or equal to 1.

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

[0173] S303: Connect to the target consensus node and send an access request message to the target consensus node.

[0174] In an embodiment of the present application, the whitelist records the network address and communication port of each consensus node in the consensus network, based on which a connection can be established with the target consensus node.

[0175] In an embodiment of the present application, in order to prevent the situation where an ordinary node cannot try to access the consensus network again when the connection with a consensus node fails, in an embodiment of the present application, after the connection with the target consensus node fails, a target consensus node that meets the preset selection criteria can be reselected and reconnected, thereby ensuring the reliability of network access.

[0176] S304: The target consensus node verifies whether the difference between the Height in the access request message and the current maximum blockchain height is within a preset range. If so, proceed to step S305; otherwise, terminate.

[0177] Since the blockchain itself is constantly growing, if a malicious node intercepts an early access request message or randomly generates a height, the deviation between it and the current maximum height of the blockchain will often be large. Therefore, the above-mentioned height verification method can effectively prove that the ordinary node is a legitimate, active, and secure node, thereby effectively preventing malicious intrusions and improving the security of the blockchain.

[0178] In the embodiment of the present application, the access request message may also include a timestamp, so that the identity of the common node can be further verified by timestamp verification. For details, please refer to the relevant introduction in the second embodiment.

[0179] Furthermore, in this embodiment of the present application, the access request message also includes the username and password of the common node, or a hash of the password, thereby verifying whether the common node's username is unique within the blockchain. If the common node's username is unique within the blockchain, and the consensus nodes in the blockchain do not store the username, the username and password, or the hash of the username and password, can be locally associated and recorded. Furthermore, a secure channel can be established with the common node for communication.

[0180] Through the method of this embodiment, access verification can be implemented in combination with the maximum height of the blockchain Height that reflects the latest status of the blockchain, so that the ordinary node can be proved to be a legitimate, active, and secure node based on the Height, thereby solving the problem of insufficient network security caused by the existing access mechanism, in which the verification process is not associated with the blockchain status information, and therefore it cannot be proved whether the node is a legitimate, active, and secure node, or a disguised malicious node or a controlled contaminated node.

[0181] It should be understood that the solution of Example 1 can raise the entry threshold of consensus nodes and improve the security and controllability of the consensus network composed of consensus nodes. The methods of Example 2 or Example 3 can improve the security of ordinary nodes accessing the blockchain. Therefore, in the embodiments of this application, the solutions of Example 1 and Example 2 can be used simultaneously, or the solutions of Example 1 and Example 3 can be used simultaneously to achieve better implementation effects.

[0182] When the solutions of Example 1 and Example 2 are used simultaneously, or when the solutions of Example 1 and Example 3 are used simultaneously, the consensus node can be configured to not be allowed to initiate application transactions, and only ordinary users can initiate application transactions (such as registering digital assets, asset transactions, etc.). In this way, by distinguishing the permissions of consensus nodes and ordinary nodes, the business responsibilities of the core and application parts of the blockchain can be securely isolated and controlled, reducing the risk of malicious node impersonation and interference.

[0183] Example 4:

[0184] In order to alleviate the problem of low efficiency in the existing consensus mechanism, an embodiment of the present application provides a consensus method applied to a consensus network.

[0185] See also Figure 4 As shown, the consensus method includes:

[0186] S401: The leader node of this round initiates the first proposal and broadcasts it to all consensus nodes in the consensus network.

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

[0188] S402: Each consensus node in the consensus network performs a threshold signature on the first proposal and sends the signature result to the leader node of the next round.

[0189] S403: The leading node of the next round forms an aggregate signature with the threshold signatures of each consensus node, and determines the leading node of the next round.

[0190] In the embodiment of the present application, the leader node of the next round can be determined randomly from the consensus nodes in the consensus network. By randomly determining the leader node of the next round from the consensus nodes in the consensus network, interference caused by the leader node being predicted can be avoided, thereby improving the security of the consensus network.

[0191] For example, a third selection base may be determined based on the aggregate signature, and the consensus node whose threshold signature is closest to the third selection base may be determined as the leader node for the next round.

[0192] In this way, since the leader node of the next round is determined based on the threshold signature and the third selection base, that is, the leader node of the next round is selected from the consensus nodes that have voted, this can effectively avoid the risk of empty election and improve the reliability of the consensus mechanism operation.

[0193] S404: In the next round, the leader node initiates a second proposal and broadcasts it to all consensus nodes in the consensus network.

[0194] In the embodiment of the present application, the second proposal includes the newly proposed block, the aggregate signature, and the leader node of the next round.

[0195] S405: Each consensus node in the consensus network verifies the legitimacy of the aggregate signature and, if the verification is successful, feeds back the verification result to the leader node of the next round.

[0196] In an embodiment of the present application, after each consensus node performs a threshold signature on the first proposal, it can use a verifiable random function to generate its own verifiable random number Vh and proof Vp of Vh, and send Vh and Vp to the leader node of the next round.

[0197] For example, assume that this round is round n, and the threshold signature result of each consensus node for the first proposal is V j*n , j*n represents the jth consensus node in round n. Each consensus node can independently calculate the following VRF data (denoted as Vrf j*n ):

[0198] Vh j*n=VRF_Hash(Prikey j , Hash(Pn))

[0199] Vp j*n =VRF_Proof(Prikey j , Hash(Pn))

[0200] Where, Prikey j To calculate the private key of the j-th consensus node for the VRF data, Pn is the first proposal of round n.

[0201] Then, in another feasible implementation of the embodiment of the present application, a third selection base can be determined based on the aggregate signature, and the consensus node whose Vh is closest to the third selection base can be determined as the leader node for the next round.

[0202] For example, assuming that this round is round n, Hash(QC n ) as the third choice base, and Hash(QC n ) is used as the benchmark to find the closest consensus node in the Vh sent by each node as the leader node for the next round. n is the aggregate signature of round n.

[0203] Then, in the next round, when the leader node broadcasts to all consensus nodes in the consensus network, QC n , Vrf determined as the leader node in the next round j*n Sent to the consensus node. Because QC n It is the result of the aggregation of threshold signatures of each consensus node, so each consensus node can verify QC n Therefore, each consensus node can verify the legitimacy of QC n The legitimacy is verified and the public key of the next round leader node can be obtained by searching the whitelist, so that the Vrf of the next round leader node can be verified based on the public key. j*n The Vp in the next round verifies the Vh of the leader node in the next round, thereby verifying the Vrf of the leader node in the next round. j*n randomness.

[0204] After the verification is passed, each consensus node can then proceed to step S405. If the verification fails, in an optional implementation of the embodiment of the present application, the next round leader node can be notified to re-determine the next round leader node, or the next round leader node can be used as the next round leader node, thereby ensuring the normal operation of the entire consensus mechanism.

[0205] It should be understood that in the embodiment of the present application, except for the first and second rounds, the leaders of each other round can be determined in the above manner. The leader nodes of the first and second rounds can be designated by engineers.

[0206] S406: In the next round, when the leader node determines that the number of consensus nodes that have passed verification has reached a preset threshold, the leader node submits the first proposal to the database for storage.

[0207] It should be noted that in the embodiment of the present application, there is only one leader node in each round. In this way, only one leader node is confirmed in each round, which can simplify the consumption of voting and improve the efficiency of consensus.

[0208] It should be understood that, in fact, the leader node of each round except the first and second rounds will simultaneously perform the above-mentioned tasks of the leader node of this round, the leader node of the next round, and the leader node of the next round. That is, in the embodiment of the present application, the leader node of each round except the first and second rounds will not only serve as the leader node of this round, thereby proposing the blocks required for determination in this round and determining the leader node of the next round; it will also serve as the leader node of the next round, forming an aggregate signature from the threshold signatures of the blocks proposed by the leader node of the previous round; it will also serve as the leader node of the next round, verifying the legitimacy of the aggregate signatures of the blocks proposed by the leader nodes of the previous two rounds. When the number of consensus nodes that pass the verification reaches a preset threshold, the proposal of the block is submitted to the database for storage.

[0209] Furthermore, since the leader node of each round, except for the first and second rounds, simultaneously performs the tasks of the leader node of the current round, the leader node of the next round, and the leader node of the next round, the content processed by the leader node of a round may simultaneously include two actions: submitting the proposals of the leader nodes of the previous two rounds to the database, and forming an aggregate signature from the threshold signatures of the proposal of the leader node of the previous round. Consequently, two proposals may be stored in memory simultaneously. Therefore, to facilitate the distinction of the proposals to be submitted to the database by the leader node of the next round in step S406, in an embodiment of the present application, after verifying the legitimacy of the aggregate signature in step S405, the status of the first proposal in memory can be updated (for example, a flag indicating that the first proposal in memory has passed verification is set on the first proposal in memory), thereby allowing the leader node of the next round to submit the first proposal to the database for storage based on the status of the proposal.

[0210] It should be noted that in the embodiment of the present application, for the leading nodes of the first round and the second round, the engineer can configure a consensus node as the starting node (i.e., the leading node of the first round), and specify that the leading node of the second round still points to itself, thereby starting the consensus mechanism.

[0211] Through the solution of the embodiment of the present application, only three rounds are needed to complete the confirmation of the block, and the consensus efficiency is higher. In addition, in the embodiment of the present application, the votes of the consensus nodes in each round are directly sent to the leader node in the next round, so that in each round, multiple rounds of block confirmation processes can be executed in parallel, thereby improving the consensus efficiency. At the same time, since the consensus node sends the vote to the leader node of the next round and no longer returns it to the leader node of the current round, this can reduce the complexity of communication while avoiding the risk of malicious interference from malicious nodes outside the consensus network against the Leader, thereby improving the reliability of the network.

[0212] Embodiment 5:

[0213] This embodiment further illustrates the solution of the present application based on the above embodiments.

[0214] The overall architecture of the embodiment of this application can be found in Figure 5 As shown in Figure 1, the blockchain system consists of two sides: the service side and the user side. The service side consists of an access unit, a security module, and a blockchain service network based on the access mechanism. The user side is a common node. On the service side, only the blockchain service network provides services to the user side, such as user access, transactions, and queries.

[0215] in:

[0216] The access unit is established by a professional security company or regulatory department. Its role is to provide hardware security modules (i.e. the first security module, which can be in the form of UKEY, encryption machine, encryption card, etc.) for the consensus nodes in the blockchain service network, and provide software security modules (i.e. the second security module) for the portal site of the blockchain service.

[0217] The hardware security module is issued by the access unit to the consensus node in the blockchain network and is used for identity authentication, secure registration and secure communication when the consensus node accesses the consensus network.

[0218] The software security module is issued to ordinary nodes by the access unit through the portal site and is used for identity authentication and secure communication when ordinary nodes access the blockchain network.

[0219] Consensus nodes are a fundamental component of the blockchain service network. They are jointly established by organizations seeking to join the consensus network. Each node must be equipped with a hardware security module to be recognized by other nodes in the network. Consensus nodes are responsible for processing transactions and blockchain status that require on-chain transmission within the consensus network. Their responsibilities are limited to maintaining consensus on data and system configuration within the blockchain network and providing blockchain-related services to regular nodes. Therefore, consensus nodes are prohibited from initiating transactions on behalf of or impersonating regular nodes; otherwise, they will not be recognized.

[0220] The portal, established by the blockchain service provider as the first stop for ordinary nodes to access the blockchain network, is required to import and store the software security module and necessary publicly available information about the consensus network issued by the access unit. It then connects to the blockchain consensus network as an ordinary node. It provides ordinary nodes with the necessary information and software security module for accessing the blockchain network.

[0221] Ordinary nodes need to install a software security module, connect to the consensus node, and register on the blockchain before they can access related services on the blockchain and perform transactions at the blockchain application layer, such as user registration, asset registration, query, and transaction.

[0222] A specific optional implementation method is described in detail below:

[0223] In the initial phase, the service side must first establish access units and produce sufficient hardware security modules and software security modules. On this basis, sufficient consensus nodes will install the hardware security modules and connect to each other to establish an initial consensus network, produce a genesis block, and start the consensus mechanism.

[0224] After the initial consensus network is up and running, a portal site will need to be established. This portal site and access units will be able to access the consensus network and regularly obtain non-critical information from the consensus network. The portal site and consensus network will form the initial blockchain service network.

[0225] Institutions that need to join the consensus network and participate in the consensus can establish their own nodes and obtain hardware security modules from access units to access the consensus network.

[0226] Ordinary nodes obtain the information and software security modules required to access the network through the portal site, connect to the blockchain network after installation, initiate transaction requests to the consensus network, synchronize the transaction requests to the transaction pool of each node between consensus nodes, and then complete the transaction chain process through the consensus mechanism.

[0227] The specific processing procedures for each link are as follows:

[0228] 1) Establishment of access mechanism and consensus network:

[0229] It includes two stages: initial network establishment and consensus node admission registration:

[0230] a) Initial network establishment

[0231] Here’s how to do it:

[0232] i. Establish an access unit, generate and save a unique security root key pair (root private key PrikeyRoot and root public key PubkeyRoot) in the access unit.

[0233] ii. Production security module: The access unit provides a hardware security module for nodes that need to join the consensus network. The module can be in the form of UKEY, encryption card, encryption machine, etc.

[0234] It should be noted that the hardware security module has the relevant capabilities of key generation and cryptographic operations, and key data cannot be exported from the hardware security module in plain text.

[0235] For each hardware security module, the access unit independently signs the public key PubkeyRoot to obtain the root signature SignRoot j =Sign PrikeyRoot (PubkeyRoot)(Note: SignRoot j Indicates the root signature issued to consensus node j, Sign PrikeyRoot (PubkeyRoot) indicates that PrikeyRoot is used to sign PubkeyRoot. Due to the randomness introduced by the signature algorithm, the root signature obtained by different hardware security modules is different, but they can all be verified by PubkeyRoot. It is written into the hardware security module together with PubkeyRoot. However, PubkeyRoot, as key data, cannot be exported from the hardware security module.

[0236] iii. Install a hardware security module: Each consensus node must install a hardware security module issued by the access unit.

[0237] It should be noted that when each consensus node is initialized, the hardware security module will independently and randomly generate a public and private key pair (private key Prikey j and the public key Pubkey j , subscript j indicates the jth consensus node) and is stored in the hardware security module, where Prikey j Critical data cannot be exported from the hardware security module.

[0238] It should also be noted that each consensus node calculates its own ID j =Hash(SignRootj |Pubkey j ), as the unique identifier of the consensus node.

[0239] It should be noted that ID j Represents the unique identifier of the j-th consensus node.

[0240] iv. Establish an initial consensus network: A group of initial consensus nodes (at least 4 consensus nodes) equipped with hardware security modules are connected into a network.

[0241] The information of all initial consensus nodes is summarized into an initial whitelist (referred to as WList), which is signed by each hardware security module and saved under each initial consensus node. The information of each consensus node in WList must at least include: the unique identification ID of the consensus node j , network address, communication port Port, public key Pubkey j and other information.

[0242] Configure a node in the initial network as the startup node, create a hard-coded genesis block and publish it to the initial consensus network to trigger the operation of the consensus mechanism. (For the operation of the consensus mechanism, please refer to the description of the consensus mechanism below)

[0243] v. Network status update: After the initial network is started, access units and portal sites can regularly obtain the latest whitelist (denoted as WList) and other non-critical information related to the blockchain status from the consensus network to provide necessary information for new nodes to join.

[0244] b) Consensus node admission registration:

[0245] Here’s how to do it:

[0246] i. Obtaining a hardware security module: After the initial consensus network is established, when the consensus node to be connected (denoted as A) needs to apply for registration to join the consensus network, node A needs to apply to the access unit and obtain a newly produced hardware security module (which contains PubkeyRoot and SignRoot A ) and the latest whitelist WList. SignRoot A is the root signature generated for node A.

[0247] ii. Install the hardware security module: When node A is initialized, the hardware security module generates its own public and private key pair (private key Prikey A and the public key Pubkey A ) and ID A ID A For the generation method of ID, please refer to the previous article j shown.

[0248] iii. Random access to the consensus network: Node A calculates and prepares the data required for connection through the hardware security module, and attempts to randomly access the consensus network. This includes:

[0249] Generate a set of verifiable random numbers:

[0250] Vh A =VRF_Hash(Prikey A ,Hash(ID A |Timestamp))

[0251] Vp A =VRF_Proof(Prikey A ,Hash(ID A |Timestamp))

[0252] Calculate Hash(Vh A ), and use this result to find the three closest node IDs in the whitelist WList, try to connect in turn and initiate a registration application.

[0253] If the connection fails, repeat the current step (iii) L times (L is a preset constant). If none of the steps are successful, abandon the current operation.

[0254] iv. Generate a registration application: After node A successfully connects to a consensus node (denoted as B), it generates and sends a registration application message:

[0255] The content of the registration application message mainly includes:

[0256] RegBody=SignRoot A |Pubkey A |Timestamp|Vh A |Vp A

[0257] RegReq=Encrypt PubkeyB (RegBody|Sign PrikeyA (RegBody))

[0258] It should be noted that “|” is a connection symbol, Sign is a signature function, Sign X () indicates that the content in the brackets is signed with X, Encrypt is the encryption function, Encrypt X () indicates that the content in the brackets is encrypted with X.

[0259] It should also be noted that the registration application message is signed with the private key of node A and then encrypted with the public key of node B.

[0260] v. Verify the registration application: After receiving the registration application message from node A, node B performs the following verification:

[0261] Use Prikey B Decrypt the message and use the Pubkey in the message A Verify the signature of a message. B is the private key of node B.

[0262] Verifying SignRoot with PubkeyRoot in Hardware Security Module A The legality of node A is calculated. If it is legal, the ID of node A is calculated. A =Hash(SignRoot A |Pubkey A ).

[0263] Using Pubkey A 、Vp A Verify Vh A The VRF validity, legal calculation Hash (Vh A ) and verify access randomness based on the whitelist.

[0264] Verifying access randomness based on the whitelist includes: verifying the unique ID of node B B Is it in the whitelist and Hash(Vh A ) is one of the three closest unique identifiers. If so, the verification passes; otherwise, the verification fails.

[0265] vi. Synchronous registration application: After node B completes the verification, it synchronizes the relevant information of node A to other consensus nodes and updates the whitelist under this node.

[0266] vii. Response to registration application: All nodes, including node B, that have verified and processed node A's registration application generate and send a registration response message to node A and update their own whitelist WList:

[0267] The content of the registration response message mainly includes:

[0268] RespBody=ID A |SignRoot j |Pubkey j Timestamp

[0269] RegResp=Encrypt PubkeyA (RespBody|Sign Prikeyj (RespBody))

[0270] Note: The registration response message is signed with the private key of this node and then encrypted with the public key of node A.

[0271] viii. Confirming successful registration: Node A verifies and processes the received response message as follows:

[0272] Use Prikey A Decrypt the message and use the Pubkey in the message j Verify the signature of the message, ID A It should be consistent with your own ID, and the timestamp should be consistent with the registration request message.

[0273] Verifying SignRoot with PubkeyRoot in Hardware Security Module j The legality of node j is calculated. If it is legal, the ID of node j is calculated. j =Hash(SignRoot j |Pubkey j ) to verify whether the information is consistent with the whitelist.

[0274] If the verification is successful, the relevant information including the whitelist under node A will be updated. When the number of response messages received reaches a certain threshold, the registration is confirmed to be successful.

[0275] 2) Random access of ordinary users:

[0276] Ordinary users do not participate in consensus and can access the blockchain network by simply installing the software security module. The implementation method is as follows:

[0277] i. Establishing a portal site: When initializing the portal site, it must import the software security module provided by the access authority and access the consensus network. The portal site is only allowed to periodically randomly select consensus nodes to obtain non-sensitive information from the blockchain network. Non-sensitive information includes at least the maximum blockchain height (Height) and the latest whitelist of consensus nodes (WList). Furthermore, all other application requests from the portal site will not be accepted by the consensus network.

[0278] ii. Obtaining the software security module: If a common node (referred to as User) is connecting for the first time, it is necessary to obtain the software security module (including PubkeyRoot and SignRoot) from the portal site. soft , SignRoot soft The generation method can be found in the previous section about SignRoot j Description), the latest whitelist WList, and the maximum blockchain height Height. If this is not the first time, only WList and Height are required.

[0279] iii. Install software security module:

[0280] During user initialization, the software security module calculates the user's account factor, Userkey, based on the user's customized username, UserID, and password, Passwd. For example, Userkey = Hash(UserID | Passwd). Neither UserID nor Passwd need to be saved; they are managed by the user.

[0281] The software security module randomly generates the user's public and private key pair (private key Prikey User and the public key Pubkey User ), where Prikey User It needs to be encrypted with Userkey and saved for management.

[0282] iv. Random access network:

[0283] User calculates a hash value related to the current state of the blockchain: H = Hash(Height|Timestamp|Pubkey User )

[0284] Find the IDs of the three consensus nodes closest to H in the whitelist WList and try to connect to them in sequence. If the connection fails, repeat the current step (iv) L times (L is a pre-set constant). If none of them succeed, abandon the operation.

[0285] v. Request access: After successfully connecting to the consensus node (denoted as B), the User generates and sends an access request message.

[0286] The content of the access request message mainly includes:

[0287] ConnBody=Height|Timestamp|Pubkey User |UserID|Hash(Passwd)

[0288] ConnReq=Encrypt PubkeyB (ConnBody|Sign PrikeyUser (RegBody))

[0289] Note: The access request message is signed with the User's private key and then encrypted with the public key of Node B.

[0290] vi. Verify the access request: After receiving the access message, Node B performs the following processing:

[0291] Use Prikey B Decrypt the message and use the Pubkey in the message User Verify the signature of a message.

[0292] Verify that the height and timestamp are within a reasonable range. If so, proceed to the next step; otherwise, access is not allowed.

[0293] Verify the UserID and Hash (Passwd) in the consensus network. The UserID must be unique in the consensus network and correspond to the Hash (Passwd). If the local node does not have a record, it will randomly query multiple consensus nodes. If none of the consensus nodes have it, the UserID and Hash (Passwd) will be added to the local record and synchronized to other consensus nodes.

[0294] vii. Establishing a secure channel: After the access verification is passed, a temporary secure channel is established between the user and the consensus node to complete the following interaction:

[0295] After verification, Node B randomly generates a temporary channel key factor KeyFac, signs and encrypts it, and returns it to the User. The secure channel establishment information mainly includes:

[0296] RespBody=UserID|Timestamp|KeyFac

[0297] ConnResp=Encrypt PubkeyUser (RespBody|Sign PrikeyB (RespBody))

[0298] Node B calculates the channel key Key = Hash (KeyFac | Height | timestamp) and waits for the next communication.

[0299] After receiving the response message from node B, User decrypts and verifies the legitimacy of the message, including: using Prikey User Decrypt the message and use the Pubkey of node B B Verify the signature of the message, verify whether the UserID in the message is consistent with your own, and verify whether the timestamp is consistent with the access request message sent by yourself. If they are consistent, the verification is successful. If not, the establishment of the secure channel can be terminated.

[0300] User calculates the channel key Key using the same method as node B, and all subsequent communications are encrypted using the Key.

[0301] 3) Initiate application transactions

[0302] In this embodiment of the application, consensus nodes are not allowed to initiate application transactions. Only ordinary nodes have this permission (such as registering digital assets, asset transactions, etc.). When a transaction needs to be initiated, ordinary nodes need to send the transaction to the consensus node for processing and obtain the processing results. The implementation method is as follows:

[0303] i. Network Access: A regular node (denoted as User) randomly accesses the blockchain service network, establishes a secure channel with a consensus node (denoted as B), and queries the user's private state information on the blockchain (such as account balances, transaction records, etc., which may vary depending on the application). Because transaction messages are typically quite extensive, all messages in the following communication interactions are encrypted using the secure channel key.

[0304] ii. Initiate a transaction: After successfully accessing the network, a transaction message is generated and sent to node B based on the user's private status information and actual needs.

[0305] The transaction message content mainly includes: message ID (calculated from UserID, current timestamp and other information), transaction list, and message signature.

[0306] The transaction list can contain multiple transactions, and each transaction contains at least the transaction details and the current timestamp.

[0307] iii. Transaction processing: After receiving the transaction message initiated by the user, Node B verifies whether the transaction content, including the timestamp, is valid. Once verified, it is synchronized to the transaction pool of all other consensus nodes for subsequent consensus processing.

[0308] iv. Processing status query: After the transaction message is sent, the user can query the transaction processing status at any other node in the random access consensus network.

[0309] 4) Consensus mechanism and blockchain formation:

[0310] After ordinary users' transactions are submitted to the consensus network, the transaction pools of each consensus node will be synchronized, and then the verification and consensus mechanism will be used to determine whether the transaction can eventually be put on the chain.

[0311] The consensus mechanism uses a chained round-by-round processing method based on leader nodes and voting. In each round, the only leader among the consensus nodes extracts valid transactions from the transaction pool, combines them with the blockchain status information to package them into a new block, and initiates a block proposal to broadcast to other consensus nodes. All consensus nodes then conduct three rounds of voting and processing, ultimately finalizing the status of the new block on the chain. The implementation method is as follows:

[0312] See Figure 6 As shown, the consensus mechanism includes:

[0313] a) Genesis block generation and consensus process:

[0314] The genesis block is a hard-coded fixed block, and the block proposal will specify that the leader of the next round will still be itself.

[0315] i. After the initial blockchain network is built, the initial state of the blockchain does not have any blocks. At this time (recorded as round 0), configure a consensus node (with Figure 6 Taking node 1 as an example, it acts as the starting node and creates a hard-coded fixed block as the genesis block. The Leader (denoted as L1) of the next round (i.e., round 1) still points to itself, writes the genesis block and L1 together into a proposal (denoted as P0), and broadcasts it to all consensus nodes.

[0316] ii. Each consensus node (denoted as node j) verifies the received proposal P0 (including the verification of the genesis block and L1), and then makes a threshold signature on P0 to obtain a vote (denoted as V j*0 ), and calculate VRF data independently (denoted as Vrf j*0 ),include:

[0317] Vh j*0 =VRF_Hash(Prikey j , Hash(P0))

[0318] Vp j*0 =VRF_Proof(Prikey j , Hash(P0))

[0319] Each node will V j*0 and Vrf j*0 Sent to the Leader (L1) of round 1, that is, sent back to node 1.

[0320] It should be noted that j*0 represents node j in round 0, j*1 represents node j in round 1, and so on.

[0321] iii. The leader in round 1 receives enough V from each node j*0 and Vrf j*0 Afterwards, the votes are verified and counted to generate proposals for the next round, including:

[0322] According to the threshold signature method, the vote V j*0 Make an aggregate signature (denoted as QC0), and QC0 will be used as the announcement result of P0's voting statistics.

[0323] Calculate Hash(QC0) and use Hash(QC0) as the benchmark to calculate the Vrf sent by each node. j*0 Find the closest one. Vrf sent by node k k*0 For example, node k is determined as the leader (denoted as L2) of the next round (ie, round 2).

[0324] The relevant data (including at least: QC0, L2+Vrf k*0 , and a new block generated by several transactions taken from the transaction pool) to generate a new proposal (denoted as P1) and broadcast it to all consensus nodes.

[0325] iv. Each consensus node verifies and processes the relevant data received:

[0326] Verify the legitimacy of QC0. Since QC0 is the result of threshold signature aggregation by each consensus node, each consensus node can verify the legitimacy of QC0.

[0327] Find the public key of the corresponding node k in the whitelist through L2 and verify Vrf k*0 , confirming that the selection of the Leader for the next round is random based on the latest state of the blockchain.

[0328] Verify the legitimacy of the blocks in P1.

[0329] After all the above verifications are passed, the status of the proposal P0 in the node's local memory is changed to the "ready to submit" state. Generate a vote for the previous voting result QC0 (denoted as VQC j*0 ), vote V on the new proposal P1 j*1 and VRF data Vrf j*1 , sent to the verified next round Leader, L2.

[0330] v. The Leader of round 2 receives enough VQCs from each node j*0 、V j*1 and Vrf j*1 Afterwards, similar to the previous process, verification is completed and votes are counted to generate proposals for the next round, including:

[0331] Vote for j*1 The aggregate signature is QC1, and the vote for QC0 in the previous round results in the aggregate signature CQC0. CQC0 indicates that P0 has been proven to have a legal number of nodes whose memory status has been updated (CQC0 serves as a sign that P0 has been finally confirmed).

[0332] Calculate Hash (QC1) and find the next round leader (taking node i as an example, denoted as L3)

[0333] Related data (including at least: CQC0, QC1, L3+Vrf i*1 , and a new block generated by several transactions taken from the transaction pool) to generate a new proposal (denoted as P2) and broadcast it to all nodes.

[0334] vi. After receiving the proposal P2, each node proceeds similarly to step iv. According to CQC0, it submits it together with P0 to the local database for persistent storage.

[0335] b) The general process of block generation and consensus

[0336] vii. After the genesis block consensus, the general process of block generation and consensus is similar to that of round 2, as shown in round n in the figure.

[0337] According to the solution of this embodiment, at least the following effective effects are achieved:

[0338] 1. Through a secure access mechanism based on security modules and random access methods, the consensus network can raise the entry threshold, ensure the security and controllability of newly joined consensus nodes, and meet regulatory requirements; and newly joined ordinary nodes can also confirm that the network they are connected to is reliable and trustworthy.

[0339] 2. By installing hardware security modules and software security modules on consensus nodes and ordinary users respectively, consensus nodes and ordinary users are differentiated in terms of permissions, so that the business responsibilities of the core and application parts of the blockchain are securely isolated and controlled, reducing the risk of malicious nodes impersonating and interfering.

[0340] 3. The consensus mechanism uses a verifiable random determination mechanism for each round based on blockchain state and VRF. The uniqueness of the Leader in each round simplifies voting and improves consensus efficiency. The randomness of Leader determination prevents interference caused by Leader prediction, improving the security of the blockchain network. Determining the Leader for the next round from the voting nodes avoids the risk of an empty selection and improves the reliability of the consensus mechanism.

[0341] 4. In the consensus mechanism, each round of votes is directly sent to the Leader of the next round, which reduces the complexity of communication and the risk of malicious interference from malicious nodes outside the consensus network against the Leader, thereby improving the reliability of the blockchain network.

[0342] 5. In addition, a block only requires three rounds from proposal to finalization, which improves consensus efficiency.

[0343] Example 6:

[0344] Based on the same inventive concept, the present application also provides two consensus node admission devices and three common node admission devices. Figures 7 to 11 As shown, Figure 7 and Figure 8 The consensus node admission devices 100 and 200 are shown, which correspond to the operations performed by the consensus node to be accessed and the target consensus node in the method shown in the first embodiment, respectively. Figure 9 and Figure 10 The common node admission devices 300 and 400 are shown, which correspond to the operations performed by the common node and the target consensus node in the method shown in the second embodiment, respectively. Figure 11 The diagram shows a common node admission apparatus 500 corresponding to the operations performed by a common node in the method shown in the third embodiment.

[0345] It should be understood that the specific functions of the consensus node admission devices 100 and 200, and the ordinary node admission devices 300, 400, and 500 can be found in the description above. To avoid repetition, detailed descriptions are appropriately omitted here. The consensus node admission devices 100 and 200, and the ordinary node admission devices 300, 400, and 500 include at least one software function module that can be stored in a memory in the form of software or firmware or solidified in the operating system of the consensus node admission devices 100 and 200, and the ordinary node admission devices 300, 400, and 500. Specifically:

[0346] See also Figure 7 As shown, the consensus node admission device 100 is applied to the consensus node to be connected, and includes: a first generation module 101, a determination module 102 and a first connection processing module 103.

[0347] The first generation module 101 is configured to generate its own public key, private key, and unique identifier, and to generate a verifiable random number Vh and a proof Vp of Vh using a verifiable random function VRF based on the private key and the unique identifier;

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

[0349] The first connection processing module 103 is used to connect to 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 can verify the consensus node to be connected based on the public key and the Vp.

[0350] In the embodiment of the present application, the first generation module 101 is specifically used to install the first security module reviewed and allocated by the preset access unit, use the first security module to generate its own public key and private key, and generate its own unique identifier based on the public key.

[0351] In the embodiment of the present application, the access unit has data reading and writing permissions of the first security module.

[0352] In an embodiment of the present application, the first security module is a hardware security module.

[0353] In an embodiment of the present application, the determination module 102 is also used to obtain a root public key and a first root signature that can be verified by the root public key from the access unit before generating its own unique identifier based on the public key; correspondingly, the determination module 102 generates its own unique identifier based on the public key specifically including: calculating the first root signature and its own public key to obtain the unique identifier.

[0354] In an embodiment of the present application, the determination module 102 is specifically configured to select, from the consensus network, n candidate consensus nodes whose unique identifiers are closest to the first selection cardinality; wherein n is a preset positive integer greater than or equal to 1; and determine, from the n candidate consensus nodes, one candidate consensus node as the target consensus node.

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

[0356] In an embodiment of the present application, the determination module 102 is further used to verify the registration response message when receiving the registration response message for the registration application message; when the number of received registration response messages that pass the verification is greater than or equal to a preset number threshold, determine that the registration is successful.

[0357] In an embodiment of the present application, a root public key is pre-acquired in the consensus node to be accessed; the registration response message includes a second root signature that can be verified by the root public key and the public key of the consensus node that sends the registration response message; the determination module 102 is specifically used to use the root public key to verify the second root signature in the registration response message; when the verification is successful, the public key and the second root signature of the consensus node are used to calculate the unique identifier of the consensus node; check whether the calculated unique identifier of the consensus node is a unique identifier already existing in the consensus network; if so, the verification is successful; otherwise, the verification fails.

[0358] In an embodiment of the present application, the registration application message includes a first root signature; the registration response message also includes: the consensus node that sends the registration response message, the unique identifier of the consensus node to be accessed calculated based on the public key in the registration application message and the first root signature; the determination module 102 is also used to determine that the unique identifier in the registration response message is consistent with its own unique identifier before using the root public key to verify the second root signature in the registration response message.

[0359] See also Figure 8 As shown, a consensus node admission device 200 is applied to a consensus node and includes: a receiving module 201, a first verification module 202 and a processing module 203.

[0360] The receiving module 201 is configured to receive a registration application message sent by a consensus node to be accessed; the registration application message includes the public key of the consensus node to be accessed, a verifiable random number Vh, and a certificate Vp of Vh;

[0361] The first verification module 202 is used to verify the legitimacy of Vh based on the public key and Vp of the consensus node to be accessed;

[0362] The processing module 203 is configured to determine a first selection base according to Vh after verification of legitimacy, and update the information of the consensus node to be connected to its own whitelist when the unique identifier of the consensus node itself and the first selection base meet a preset selection criterion.

[0363] In an embodiment of the present application, the processing module 203 is also used to, when the unique identifier of the consensus node itself and the first selection base meet the preset selection criteria, feedback a registration response message to the consensus node to be accessed, wherein the registration response message includes a second root signature that can be verified by the root public key and the public key of the consensus node, so that the consensus node to be accessed can verify the registration response message.

[0364] In an embodiment of the present application, the registration application message includes the first root signature of the consensus node to be accessed; the processing module 203 is further used to calculate the unique identifier of the consensus node to be accessed based on the first root signature and public key in the registration application message before feeding back a registration response message to the consensus node to be accessed; and put the calculated unique identifier of the consensus node to be accessed into the registration response message.

[0365] See also Figure 9 As shown, a common node admission device 300 is applied to a common node and includes: a first acquisition module 301, a second generation module 302, and a second connection processing module 303.

[0366] The first acquisition module 301 is used to obtain the maximum height of the blockchain and the latest whitelist of the consensus network; the whitelist contains the unique identifier of each consensus node in the consensus network;

[0367] The second generating module 302 is configured to generate its own public key and private key, and generate a second selected base according to the Height and the public key;

[0368] The second connection processing module 303 is used 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; connect to the target consensus node and send an access request message to the target consensus node; and establish a secure channel according to the secure channel establishment information when receiving the secure channel establishment information returned by the target consensus node.

[0369] In the embodiment of the present application, the second generating module 302 is specifically configured to obtain a second security module configured by a preset access unit from a preset portal site; and use the second security module to generate its own public key and private key.

[0370] In the embodiment of the present application, the second security module is a software security module.

[0371] In the embodiment of the present application, the access unit has data reading and writing permissions of the second security module.

[0372] In the embodiment of the present application, the first acquisition module 301 is specifically configured to acquire the Height and the latest consensus network whitelist from a preset portal site.

[0373] In the embodiment of the present application, a user name and password are preset in the common node; the second generating module 302 is further configured to calculate an account factor based on the user name and password, and use the account factor to encrypt the private key.

[0374] In an embodiment of the present application, the second connection processing module 303 is specifically used to select m candidate consensus nodes whose unique identifiers are closest to the second selection cardinality from the whitelist; m is a preset positive integer greater than or equal to 1; and determine one candidate consensus node from the m candidate consensus nodes as the target consensus node.

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

[0376] See also Figure 10 As shown, a common node admission device 400 is applied to a consensus node and includes: a second verification module 401 and a processing unit 402.

[0377] The second verification module 401 is configured to verify the legitimacy of an access request message when receiving the access request message from a common node;

[0378] The processing unit 402 is configured to establish a secure channel with the common node when verifying legitimacy.

[0379] In an embodiment of the present application, the access request message includes a hash value of the username and password of the ordinary node; the second verification module 401 is specifically used to verify whether the username of the ordinary node is unique in the blockchain, and if it is unique, determine that the access request message is legal.

[0380] In an embodiment of the present application, the access request message also includes a timestamp when the ordinary node requests access; the second verification module 401 is also used to determine whether the time difference between the timestamp and the current time is within a preset range before verifying whether the username of the ordinary node is unique in the blockchain.

[0381] In an embodiment of the present application, the access request message also includes the maximum height Height of the blockchain obtained when the ordinary node requests access; the second verification module 401 is also used to determine whether the difference between the Height and the current maximum height of the blockchain is within a preset range before verifying whether the username of the ordinary node is unique in the blockchain.

[0382] See also Figure 11 As shown, a common node admission device 500 is applied to a common node and includes: a second acquisition module 501 and a third connection processing module 502.

[0383] The second acquisition module 501 is used to obtain the maximum height of the blockchain and the latest whitelist of the consensus network;

[0384] The third connection processing module 502 is used to determine the target consensus node from the whitelist, connect to the target consensus node, and send an access request message containing the Height to the target consensus node, so that the target consensus node can verify the legitimacy of the ordinary node based on the Height; when receiving the secure channel establishment information returned by the target consensus node, establish a secure channel according to the secure channel establishment information; the secure channel establishment information is feedback information sent by the target consensus node after verifying the legitimacy of the ordinary node based on the Height.

[0385] In this embodiment of the present application, the third connection processing module 502 is further configured to generate its own public key and private key. The third connection processing module 502 is specifically configured to generate a second selection base based on the Height and the public key; based on the second selection base, determine from the whitelist the target consensus node corresponding to the unique identifier that meets the preset selection criteria.

[0386] In the embodiment of the present application, the third connection processing module 502 is specifically configured to obtain a second security module configured by a preset access unit from a preset portal site; and use the second security module to generate its own public key and private key.

[0387] In the embodiment of the present application, the second security module is a software security module.

[0388] In the embodiment of the present application, the access unit has data reading and writing permissions of the second security module.

[0389] In addition, a consensus network is provided in the embodiments of the present application, corresponding to the method shown in the fourth embodiment.

[0390] The consensus network includes a plurality of consensus nodes, wherein the consensus nodes include 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;

[0391] The current round leader node is used to initiate a first proposal and broadcast it to all consensus nodes in the consensus network; the first proposal includes the proposed block and the proposed next round leader node;

[0392] Each consensus node in the consensus network is used to perform a threshold signature on the first proposal and send the signature result to the next round leader node;

[0393] The next round leader node is used to form an aggregate signature from the threshold signatures of each consensus node and determine the next round leader node;

[0394] The next-round leader node is further configured to initiate a second proposal and broadcast it to all consensus nodes in the consensus network; the second proposal includes the newly proposed block, the aggregate signature, and the next-round leader node;

[0395] Each consensus node in the consensus network is also used to verify the legitimacy of the aggregate signature and, if the verification is successful, feedback the verification result to the next round leader node;

[0396] The leader node in the next round is used to submit the first proposal to the database for storage when it is determined that the number of consensus nodes that have passed the verification has reached a preset threshold.

[0397] It should be noted that each node in the consensus network can be implemented by one or more electronic devices.

[0398] In the embodiment of the present application, there is only one leader node in each round.

[0399] In an embodiment of the present application, the next-round leader node is specifically used to randomly determine the next-round leader node from the consensus nodes in the consensus network.

[0400] In an embodiment of the present application, the next round leader node is specifically used to determine a third selection base based on the aggregate signature; and determine the consensus node whose threshold signature is closest to the third selection base as the next round leader node.

[0401] In an 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 respectively use a verifiable random function to generate its own verifiable random number Vh and a proof Vp of Vh, and send Vh and Vp to the next round leader node.

[0402] In an embodiment of the present application, the second proposal also includes: the Vp and Vh of the leader node of the next round; each consensus node is also used to obtain the public key of the leader node of the next round, and verify the Vh of the leader node of the next round based on the public key and the Vp of the leader node of the next round.

[0403] It should be understood that, for the sake of brevity, some of the contents described in Embodiments 1 to 4 will not be repeated in this embodiment.

[0404] Embodiment seven:

[0405] This embodiment provides an electronic device, which can be seen in Figure 12 As shown, it includes a processor 1201, a memory 1202 and a communication bus 1203. Among them:

[0406] The communication bus 1203 is used to implement connection and communication between the processor 1201 and the memory 1202 .

[0407] The processor 1201 is used to execute one or more programs stored in the memory 1202 to implement the consensus node access method implemented by the consensus node to be accessed or the target consensus node in the above-mentioned embodiment 1, or to implement the ordinary node access method implemented by the ordinary node or the target consensus node in the above-mentioned embodiment 2 / embodiment 3.

[0408] I understand. Figure 12 The structure shown is only for illustration, and the electronic device may also include Figure 12 More or fewer components than shown, or with Figure 12 The different configurations shown are not limited in the embodiments of this application.

[0409] The electronic device in the embodiments of the present application can be implemented by devices such as servers, mobile terminals, fixed terminals, etc.

[0410] This embodiment also provides a readable storage medium, such as a floppy disk, an optical disk, a hard disk, a flash memory, a USB flash disk, an SD (Secure Digital Memory Card) card, an MMC (Multimedia Card), etc., in which one or more programs for implementing the above steps are stored. These one or more programs can be executed by one or more processors to implement the consensus node admission method implemented by the consensus node to be accessed or the target consensus node in the above embodiment 1, or to implement the ordinary node admission method implemented by the ordinary node or the target consensus node in the above embodiment 2 / embodiment 3. No further details will be given here.

[0411] In the embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some communication interface, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0412] In addition, the units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple 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.

[0413] Furthermore, the functional modules in each embodiment of the present application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0414] In this document, relational terms such as first and second, etc. are used merely to distinguish one entity or operation from another entity or operation, but do not necessarily require or imply any actual relationship or order between these entities or operations.

[0415] As used herein, a plurality refers to two or more than two.

[0416] The above description is merely an embodiment of the present application and is not intended to limit the scope of protection of the present application. For those skilled in the art, various modifications and variations of the present application are possible. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. A common node admission method, characterized in that: Applicable to common nodes, including: Obtain the maximum height of the blockchain and the latest whitelist of the consensus network; the whitelist contains the unique identifier of each consensus node in the consensus network; Generate its own public key and private key; Generate a second selected base according to the Height and the public key; Based on the second selection base, determining the target consensus node corresponding to the unique identifier that meets the preset selection criteria from the whitelist; Connecting to the target consensus node and sending an access request message to the target consensus node; When receiving the secure channel establishment information returned by the target consensus node, a secure channel is established according to the secure channel establishment information.

2. The common node admission method according to claim 1, wherein: The generating of the public key and private key thereof includes: Obtaining a second security module configured by a preset access unit from a preset portal site; The second security module is used to generate its own public key and private key.

3. The common node admission method according to claim 2, wherein: The second security module is a software security module.

4. The common node admission method according to claim 2, wherein: The access unit has data reading and writing authority of the second security module.

5. The common node admission method according to claim 1, wherein: The process of obtaining the maximum blockchain height and the latest consensus network whitelist includes: Obtain the Height and the latest consensus network whitelist from a preset portal site.

6. The common node admission method according to claim 1, wherein: The common node is preset with a user name and password; The method further comprises: Calculate an account factor based on the user name and password; The private key is encrypted using the account factor.

7. The common node admission method according to any one of claims 1 to 6, characterized in that: Determining, based on the second selection base, from the whitelist a target consensus node corresponding to a unique identifier that meets a preset selection criterion, including: Select m candidate consensus nodes from the whitelist whose unique identifiers are closest to the second selection cardinality; m is a preset positive integer greater than or equal to 1; From the m candidate consensus nodes, one candidate consensus node is determined as the target consensus node.

8. The common node admission method according to claim 7, characterized in that: The method further comprises: When the connection with the target consensus node fails, a new candidate consensus node is determined from the m candidate consensus nodes as the target consensus node for connection.

9. A common node admission method, characterized in that: Applied to consensus nodes, including: Upon receiving an access request message from a common node, verifying the legitimacy of the access request message; When verifying legitimacy, a secure channel is established with the ordinary node; wherein, the ordinary node establishes the secure channel with the consensus node through the method according to any one of claims 1-8.

10. The common node admission method according to claim 9, characterized in that: The access request message includes a hash value of the username and password of the common node; The verifying the legitimacy of the access request message includes: Verify whether the username of the ordinary node is unique in the blockchain; If the user name of the ordinary node is unique in the blockchain, and when it is unique, the access request message is determined to be legal.

11. The common node admission method according to claim 10, wherein: The access request message also includes a timestamp when the ordinary node requests access; Before verifying whether the username of the common node is unique in the blockchain, the method further includes: It is determined that the time difference between the timestamp and the current time is within a preset range.

12. The common node admission method according to claim 10, wherein: The access request message also includes the maximum height of the blockchain obtained when the ordinary node requests access; Before verifying whether the username of the common node is unique in the blockchain, the method further includes: Determine whether the difference between the Height and the current maximum height of the blockchain is within a preset range.

13. A common node admission method, characterized in that: Applicable to common nodes, including: Get the maximum height of the blockchain and the whitelist of the latest consensus network; Determine the target consensus node from the whitelist; Connecting to the target consensus node and sending an access request message including the Height to the target consensus node, so that the target consensus node can verify the legitimacy of the ordinary node based on the Height; When receiving the secure channel establishment information returned by the target consensus node, establishing a secure channel according to the secure channel establishment information; the secure channel establishment information is feedback information sent by the target consensus node after verifying the legitimacy of the ordinary node based on the Height; The method further comprises: generating its own public key and private key; Determining the target consensus node from the whitelist includes: Generate a second selected base according to the Height and the public key; Based on the second selection base, a target consensus node corresponding to the unique identifier that meets a preset selection criterion is determined from the whitelist.

14. The common node admission method according to claim 13, wherein: The generating of the public key and private key thereof includes: Obtaining a second security module configured by a preset access unit from a preset portal site; The second security module is used to generate its own public key and private key.

15. The common node admission method according to claim 14, characterized in that: The second security module is a software security module.

16. The common node admission method according to claim 14, wherein: The access unit has data reading and writing authority of the second security module.

17. A common node admission device, characterized in that: Applied in a common node, it includes: a first acquisition module, a second generation module, and a second connection processing module; The first acquisition module is used to obtain the maximum height of the blockchain and the latest whitelist of the consensus network; the whitelist contains the unique identifier of each consensus node in the consensus network; The second generating module is configured to generate its own public key and private key, and generate a second selected base according to the Height and the public key; The second connection processing module is used to determine, from the whitelist, a target consensus node corresponding to a unique identifier that meets a preset selection criterion based on the second selection base; connect to the target consensus node and send an access request message to the target consensus node; and establish a secure channel according to the secure channel establishment information when receiving the secure channel establishment information returned by the target consensus node.

18. A common node admission device, characterized in that: Applied to the consensus node, including: a second verification module and a processing unit; The second verification module is configured to verify the legitimacy of the access request message when receiving the access request message sent by the ordinary node; The processing unit is configured to establish a secure channel with the ordinary node when verifying legitimacy; wherein the ordinary node establishes the secure channel with the consensus node through the method according to any one of claims 1 to 8.

19. A common node admission device, characterized in that: Applied to ordinary nodes, including: a second acquisition module and a third connection processing module; The second acquisition module is used to obtain the maximum height of the blockchain and the latest whitelist of the consensus network; The third connection processing module is configured to determine a target consensus node from the whitelist, connect to the target consensus node, and send an access request message containing the Height to the target consensus node, so that the target consensus node can verify the legitimacy of the ordinary node based on the Height; upon receiving the secure channel establishment information returned by the target consensus node, establish a secure channel according to the secure channel establishment information; the secure channel establishment information is feedback information sent by the target consensus node after verifying the legitimacy of the ordinary node based on the Height; The third connection processing module is further configured to generate its own public key and private key; The third connection processing module is specifically used to: generate a second selection base according to the Height and the public key; and based on the second selection base, determine the target consensus node corresponding to the unique identifier that meets the preset selection criteria from the whitelist.

20. An electronic device, characterized in that: include: processor, memory, and communication bus; The communication bus is used to realize the connection and 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 according to any one of claims 1 to 16.

21. A readable storage medium, characterized in that The readable storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement the method according to any one of claims 1 to 16.

Images