Consensus method, consensus network, electronic device and readable storage medium

Abstract

The application provides a consensus method, a consensus network, an electronic device and a readable storage medium. The method comprises the following steps: a current round leader node initiates a first proposal and broadcasts the first proposal to all consensus nodes in a consensus network; the first proposal comprises a proposed block and a proposed next round leader node; all consensus nodes in the consensus network perform threshold signature on the first proposal, and send the signature result to the next round leader node; the next round leader node forms an aggregated signature by threshold signature, and determines a next next round leader node; the next round leader node initiates a second proposal and broadcasts the second proposal to all consensus nodes; all consensus nodes verify the legitimacy of the aggregated signature, and feed back the verification result to the next next round leader node when the verification is passed; and the next next round leader node submits the first proposal to a database for storage when it is determined that the number of consensus nodes that pass the verification reaches a preset threshold. The application can reduce the communication complexity and improve the reliability of the network.

Description

[0001] This application is a divisional application of Chinese Patent Application No. 202011293600.3, filed on November 18, 2020, entitled “Node Admission Method, Consensus Method, Apparatus, Electronic Device and Storage Medium”. Technical Field

[0002] This application relates to the field of blockchain technology, and more specifically, to a consensus method, a consensus network, an electronic device, and a readable storage medium. Background Technology

[0003] Consortium blockchains have certain access control mechanisms, and nodes participating in consensus are distinguished from ordinary nodes in terms of rights, thereby reducing the risk of interference from malicious nodes and helping to improve the efficiency of consensus.

[0004] Currently, the access mechanism of consortium blockchains introduces the concept of a group based on identity authentication, which divides the nodes in the blockchain network into different roles such as ordinary nodes, core nodes, consensus nodes, and verification nodes, assigning them different permissions and undertaking different functions.

[0005] Currently, consortium blockchains generally employ access control mechanisms based on authentication methods using CA (Certificate Authority) centers and digital certificates. The nodes participating in consensus (referred to as consensus nodes in this article) form the core consensus network of the blockchain. By issuing different digital certificates to nodes with different roles through the CA center, security measures such as two-way authentication, key negotiation, and channel encryption can be implemented between nodes and the consensus network, preventing malicious nodes from illegally accessing the blockchain network or even intruding into the core consensus network.

[0006] However, this admission method performs admission authentication on relatively fixed verification nodes or CA centers. It is not effective in defending against targeted attacks by illegal nodes on a fixed consensus node in the consensus network. Furthermore, the concentration of related transactions on verification nodes or CA centers can easily lead to excessive load on these nodes or CA centers.

[0007] Furthermore, universal digital certificates are purely software-based. Identity authentication relying solely on digital certificates can only prove the legitimacy of the certificates held by the communicating nodes, but cannot guarantee against copying or misuse. From a regulatory perspective, this approach is also detrimental to the control of consensus nodes and unsuitable for the regulatory needs of specific industries. Moreover, because the certificate and verification process are not linked to blockchain state information, it cannot prove whether a node is a legitimate, active, and secure node, or a disguised malicious node or a controlled, polluted node. Therefore, without a customized access mechanism for blockchain networks, not only will security risks to the blockchain consensus network be introduced, but it will also create difficulties for relevant departments in regulating blockchain networks.

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

[0009] Consensus mechanisms are one of the core components of blockchain. Currently, under the premise of node admission mechanisms, Byzantine-based consensus algorithms based on BFT (Byzantine Fault Tolerance) have been introduced into the core consensus network of the blockchain. This means that consensus on proposed blocks is reached through Byzantine voting within the consensus network, eliminating the computational power required for mining and thus reducing block generation time and resource consumption. However, the current BFT-based consensus mechanism still has the following problems:

[0010] For determining block production rights, BFT typically employs a Leader mechanism, where the Leader proposes a block for each round, which is then voted on by other consensus nodes. However, current Leader determination mechanisms generally use an algorithm to define a range, forming a proposal group with all consensus nodes within that range as Leader candidates. Each candidate proposes a block in each round, and the consensus nodes then vote on all proposed blocks according to a certain priority to select the block requiring consensus in that round before proceeding to the consensus voting stage. This undoubtedly increases the difficulty of consensus and reduces its efficiency.

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

[0012] Each consensus node needs to wait for sufficient network latency while waiting for votes from other consensus nodes to ensure that the state of most consensus nodes across the network remains synchronized before proceeding to the next step. This synchronous waiting method also hinders the improvement of consensus efficiency. Summary of the Invention

[0013] To alleviate the inefficiency of existing consensus mechanisms, this application provides a consensus method applied in a consensus network, including:

[0014] The current leader node initiates a first proposal and broadcasts it to all consensus nodes in the consensus network. The first proposal includes a proposed block and a proposed next-round leader node. Each consensus node in the consensus network performs a threshold signature on the first proposal and sends the signature result to the next-round leader node. The next-round leader node combines the threshold signatures of each consensus node into an aggregate signature and determines the next-next-round leader node. The next-round leader node initiates a second proposal and broadcasts it to all consensus nodes in the consensus network. The second proposal includes a new proposed block, the aggregate signature, and the next-next-round leader node. Each consensus node in the consensus network verifies the legality of the aggregate signature and, upon successful verification, sends the verification result back to the next-next-round leader node. When the number of consensus nodes that have passed verification reaches a preset threshold, the next-next-round leader node submits the first proposal to the database for storage.

[0015] The above-described process requires only three rounds to complete block confirmation, resulting in higher consensus efficiency. Furthermore, in this embodiment, the votes of the consensus nodes in each round are directly sent to the designated leader node for the next round. This allows multiple rounds of block confirmation to be executed in parallel within each round, further improving consensus efficiency. Simultaneously, since the consensus nodes send their votes to the leader node for the next round instead of returning them to the leader node for the current round, communication complexity is reduced, and the risk of malicious interference from external nodes targeting the leader is avoided, thus improving network reliability.

[0016] Furthermore, there is one and only one leader node in each round.

[0017] Only one leader node is confirmed in each round, which further simplifies the voting process and improves the efficiency of consensus.

[0018] Furthermore, determining the next-next-round leader node includes: randomly determining the next-next-round leader node from among the consensus nodes in the consensus network.

[0019] By randomly determining the next leader node from among the consensus nodes in the consensus network, interference caused by prediction of the leader node can be avoided, thus improving the security of the consensus network.

[0020] Further, randomly determining the next-round leader node from among the consensus nodes in the consensus network includes: determining a third selection cardinality based on the aggregated signature; and determining the consensus node whose gate limit signature is closest to the third selection cardinality as the next-round leader node.

[0021] Since the next-next leader node is determined based on threshold signatures and a third choice cardinality, meaning the next-next leader node is selected from the consensus nodes that have already voted, this effectively avoids the risk of empty election and improves the reliability of the consensus mechanism.

[0022] Furthermore, after each consensus node in the consensus network performs threshold signature on the first proposal, the method further includes: each consensus node generates its own verifiable random number Vh and a proof Vp of Vh using a verifiable random function, and sends Vh and Vp to the next-round leader node.

[0023] Furthermore, the second proposal also includes: the Vp and Vh of the next-next-round leader node; the method further includes: each consensus node obtaining the public key of the next-next-round leader node, and verifying the Vh of the next-next-round leader node based on the public key and the Vp of the next-next-round leader node.

[0024] The above implementation achieves a verifiable random determination mechanism for each round, making the randomness of the leader node determined in each round verifiable. This further reduces the risk of malicious nodes outside the consensus network maliciously interfering with the leader and improves the reliability of the network.

[0025] This application embodiment also provides a consensus network including multiple consensus nodes, including a current round leader node, a next round leader node proposed by the current round leader node, and a next-next-round leader node proposed by the next round leader node; 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 a proposed block and a proposed next round leader node; each consensus node in the consensus network is used to perform threshold signing on the first proposal and send the signing result to the next round leader node; the next round leader node is used to form an aggregate signature from the threshold signatures of each consensus node and determine the next-next-round leader node; the next round leader node is also used to initiate a second proposal and broadcast it to all consensus nodes in the consensus network; the second proposal includes a newly proposed block, the aggregate signature, and the next-next-round leader node; each consensus node in the consensus network is also used to verify the legality of the aggregate signature and, when the verification is successful, to feed back the verification result to the next-next-round leader node; the next-next-round leader node is used to submit the first proposal to a database for storage when the number of consensus nodes that have passed the verification reaches a preset threshold.

[0026] Furthermore, there is one and only one leader node in each round.

[0027] This application also provides an electronic device, including: a processor, a memory, and a communication bus; the communication bus is used to realize the 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.

[0028] This application also provides a readable storage medium that stores one or more programs that can be executed by one or more processors to implement any of the consensus node admission methods or ordinary node admission methods described above. Attached Figure Description

[0029] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0030] Figure 1 A flowchart illustrating a consensus node admission method provided in an embodiment of this application;

[0031] Figure 2A flowchart illustrating a common node admission method provided in an embodiment of this application;

[0032] Figure 3 A flowchart illustrating another common node admission method provided in this application embodiment;

[0033] Figure 4 A flowchart illustrating a consensus method provided in an embodiment of this application;

[0034] Figure 5 An overall architecture diagram is provided in Embodiment 5 of this application;

[0035] Figure 6 This application provides a schematic diagram of a consensus mechanism;

[0036] Figure 7 This application provides a schematic diagram of a consensus node admission device applied to a consensus node to be accessed;

[0037] Figure 8 A schematic diagram of a consensus node admission device applied in a consensus node is provided in an embodiment of this application;

[0038] Figure 9 This application provides a schematic diagram of the structure of a common node admission device applied to a common node in an embodiment of the present application;

[0039] Figure 10 A schematic diagram of a common node admission device applied in a consensus node is provided in an embodiment of this application;

[0040] Figure 11 A schematic diagram of another ordinary node admission device applied in ordinary nodes provided in the embodiments of this application;

[0041] Figure 12 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0042] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0043] Example 1:

[0044] To address the issues of loose threshold control for node admission in existing admission mechanisms, poor defense against targeted attacks by illegitimate nodes on a fixed consensus node in the consensus network, and uneven node load in the consensus network, this application provides a consensus node admission method.

[0045] See Figure 1 As shown, Figure 1 This is a basic flowchart illustrating a consensus node admission method provided in this application embodiment, including:

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

[0047] It should be noted that, in this embodiment of the application, an access unit can be pre-established. In this embodiment, the access unit can be the unit with the highest authority on the blockchain, which can be composed of security equipment and relevant personnel from a regulatory body.

[0048] In this embodiment, a consensus node seeking to join the consensus network can first be reviewed by an access authority, which will then assign it a first security module. The first security module can be installed on the consensus node to generate its own public and private key pair, and generate its own unique identifier based on the public key.

[0049] In this application embodiment, the access unit can conduct qualification verification of the consensus node to be connected through various methods such as manual verification.

[0050] In this embodiment, the first security module can theoretically be implemented using either software or hardware. However, considering that hardware is less susceptible to network attacks and offers higher security compared to software, in this embodiment, the first security module can be a hardware security module, which is dispatched by the access authority to the consensus node to be connected.

[0051] It should be understood that, in the embodiments of this application, the hardware security module can be implemented in the form of a U-key, encryption card, encryption machine, etc., as long as it can store relevant data, support relevant cryptographic algorithms, and have data processing capabilities.

[0052] In this embodiment, the admitting entity can generate and store 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. The root public key and root signature are then written together into the first security module and distributed to the consensus nodes to be connected, facilitating subsequent verification. For example, the root public key can be signed using a random signature method with the root private key to obtain the root signature, i.e., SignRoot. j =Sign PrikeyRoot (PubkeyRoot), where SignRoot j This represents the root signature issued to node j, where PubkeyRoot is the root public key, and Sign is the root signature. PrikeyRoot(PubkeyRoot) indicates that PubkeyRoot is signed using the root private key. Due to the randomness introduced by the signature algorithm, different first security modules will obtain different root signatures, but all of them can be verified by PubkeyRoot.

[0053] In this embodiment, the first security module, after being installed on the consensus node to be connected and generating its own public and private key pair, can generate a unique identifier for the consensus node to be connected based on the first root signature (for ease of distinction, the root signature in the consensus node to be connected is referred to as the first root signature in this embodiment) and the public key of the consensus node to be connected. For example, a hash operation can be performed on the public key and the first root signature of the consensus node to be connected to obtain the unique identifier. It should be understood that hash operation is only one optional method for calculating the unique identifier in this embodiment. Other methods that can obtain a unique result based on the public key and the first root signature can also be used to obtain the unique identifier, and this embodiment does not limit the specific methods used.

[0054] It is important to note that the root public key can be used as critical data and configured to be non-exportable in the first security module, thereby improving data security.

[0055] In this embodiment, all data generation and processing steps during the consensus node admission process can be completed within the first security module to improve security. Furthermore, the admitting entity can have read and write permissions to the first security module, thereby facilitating the monitoring of each consensus node.

[0056] In this embodiment, the access unit can issue the first security module offline without directly participating in the operation of the blockchain network, thereby ensuring data security. However, the access unit can periodically obtain the latest state of the blockchain, such as the latest maximum blockchain height and the latest whitelist. It should be noted that the whitelist mentioned in this embodiment is compiled from the information of all consensus nodes in the consensus network, including the unique identifier, network address, communication port, and public key of each consensus node.

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

[0058] For example, in the embodiments of this application, Vh and its proof Vp can be generated by Vh = VRF_Hash(Prikey, ID) and Vp = VRF_Proof(Prikey, ID); or, Vh and its proof Vp 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 its proof Vp can be generated by Vh = VRF_Hash(Prikey, Hash(ID|timestamp)) and Vp = VRF_Proof(Prikey, Hash(ID|timestamp)).

[0059] It should be noted that in the above formulas, Prikey represents the private key, ID represents the unique identifier, "|" is the concatenation symbol, and "ID|timestamp" means concatenating the ID and the timestamp together.

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

[0061] It should be understood that the above are merely examples of several feasible methods for generating Vh and Vp based on one's own private key and unique identifier in the embodiments of this application, but do not mean that only the aforementioned methods can be used in the embodiments of this application. In fact, in practical applications, engineers can design corresponding methods for generating Vh and Vp according to actual needs, and there are no restrictions in the embodiments of this application.

[0062] S103: Determine the first selection base number based on Vh.

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

[0064] S104: Based on the first selection base and the unique identifier of each consensus node in the consensus network, select the target consensus node from the consensus network according to the preset selection criteria.

[0065] In this embodiment, the selection criterion is a standard pre-set by the engineer and followed by the entire consensus network. For example, the selection criterion can be set as: the n unique identifiers in the consensus network closest to the first selection cardinality; or, it can be the n unique identifiers in the consensus network least close to the first selection cardinality. In this embodiment, the selection criterion can be set by the engineer according to actual needs. Furthermore, the value of n should be a constant integer greater than or equal to 1.

[0066] It should be understood that, in the embodiments of this application, there may be only one target consensus node, or there may be multiple nodes.

[0067] In this embodiment of the application, when distributing the first security module, the access unit can write the whitelist into the first security module, so that the target consensus node can be determined from the whitelist based on the first selection base.

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

[0069] In this embodiment of the application, the whitelist records the network address and communication port of each consensus node in the consensus network, thereby enabling the establishment of a connection with the target consensus node.

[0070] In this embodiment of the application, in order to prevent the consensus node to be connected from being unable to re-attempt to access the consensus network when a connection with a certain consensus node fails, this embodiment of the application can re-select a target consensus node that meets the preset selection criteria after the target consensus node connection fails, thereby ensuring the reliability of network access.

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

[0072] Next, if the connection with the target consensus node fails, a new candidate consensus node is selected from the n candidate consensus nodes to be connected to as the target consensus node.

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

[0074] To improve security during 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.

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

[0076] It should be understood that, based on VRF technology, using 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 connected, 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 elaborated upon in this application.

[0077] In this embodiment, 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 decrypt the registration application message using its own private key, and then verify the signature of the registration application message using the public key in the registration application message. After successful verification, the legality of Vh is verified using the public key and Vp in the registration application message.

[0078] S108: After verifying the validity, determine the first selection base number based on Vh.

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

[0080] S109: When the unique identifier and first selection base of a consensus node meet the preset selection criteria, update the information of the consensus node to be connected to its own whitelist.

[0081] Provided that Vh is valid, since the target consensus node is selected by the consensus node to be connected based on Vh, which determines the first selection base, and the unique identifiers of each consensus node in the consensus network according to preset selection criteria, the unique identifier and the first selection base of the target consensus node should satisfy the preset selection criteria. Based on this, it is possible to verify whether the unique identifier and the first selection base of the target consensus node itself satisfy the preset selection criteria, thereby verifying the randomness of the connection of the consensus node to be connected.

[0082] In this embodiment of the application, when the unique identifier of the consensus node itself and the first selection base satisfy the preset selection criteria, a registration response message can also be sent back to the consensus node to be connected. The registration response message contains a second root signature that can be verified by the root public key (for ease of description, 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.

[0083] In this embodiment of the application, after receiving the registration response message, the consensus node to be connected can verify the second signature in the registration response message according to the root public key. After the verification is successful, it can calculate the unique identifier of the consensus node that sent the registration response message according to the second signature and the public key in the registration response message. Thus, it can verify whether the calculated unique identifier of the consensus node is a unique identifier that already exists in the consensus network (i.e., whether it is unique in the whitelist). If so, the verification is successful and the registration response message is confirmed to be trustworthy; otherwise, the verification fails.

[0084] In this embodiment, the registration request message sent by the consensus node to be connected may also contain the first 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 signature in the registration request message and the public key of the consensus node to be connected.

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

[0086] In addition, the unique identifier of the consensus node to be connected, which is calculated, can be included in the registration response message and sent back to the consensus node to be connected, thereby facilitating the identity verification by the consensus node to be connected.

[0087] For example, a consensus node to be connected can perform the aforementioned verification process of the registration response message only when it determines that the unique identifier in the registration response message matches its own unique identifier.

[0088] In this embodiment of the 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, so that the other consensus nodes can also perform the verification. After the verification is passed, the information of the consensus node to be connected is updated to its own whitelist, and a registration response message is sent back.

[0089] At this point, the consensus node to be connected can determine whether its registration has been successful based on whether the number of received verified registration response messages exceeds a preset threshold. Registration is considered successful when the number of received verified registration response messages is greater than or equal to the preset threshold. This multi-consensus node feedback mechanism effectively prevents the consensus node to be connected from being misled into connecting to an unauthorized network, thus avoiding unnecessary leakage of critical data.

[0090] It should be noted that, to enhance security during data interaction, consensus nodes can first sign the registration response message using their own private key, and then encrypt it using the public key of the consensus node to be joined. Upon receiving the registration response message, the consensus node to be joined will first decrypt it using its own private key, and then obtain the corresponding consensus node's public key by querying a whitelist for verification, thereby improving data security.

[0091] It should be understood that, for enhanced security, in this embodiment, the registration application message may carry a timestamp, and the registration response message is also required to carry this timestamp. Thus, upon receiving the registration response message, the consensus node seeking to join can verify the consistency of the timestamp, thereby confirming the legitimacy of the registration response message.

[0092] It should be noted that, in this embodiment of the application, during the initial construction of the consensus network, the access unit can 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 installed by each consensus node to generate a public and private key pair and a unique identifier for each node. Then, the information of all initial nodes is aggregated into an initial whitelist, which is signed by each first security module and stored under each consensus node.

[0093] Then, one of the consensus nodes is configured as the initiating node, creating a hard-coded genesis block and publishing it to the network, triggering the consensus mechanism to run. It should be noted that the triggered consensus mechanism is the one used in actual applications. Existing consensus mechanisms or those proposed in subsequent embodiments of this application can be used.

[0094] In this way, the initial consensus network is set up. If new consensus nodes need to be added later, admission verification can be performed in the manner described above.

[0095] The consensus node admission method provided in this embodiment allows a node seeking to join the consensus network to generate a verifiable random number Vh and a proof Vp for Vh using its private key and unique identifier via VRF. Based on the random number Vh, the node selects and joins the target consensus node and sends a registration application message containing the node's public key, Vh, and Vp to the target consensus node. This allows the target consensus node to verify the randomness of the random number Vh using the public key and Vp, and further verify the randomness of the access based on Vh, thus ensuring the randomness of the node's access. This random access method prevents malicious nodes from targeting a fixed node in the consensus network, allowing the network to detect and block malicious access immediately. Simultaneously, random access also provides a degree of randomized load balancing, improving network stability. Furthermore, the admission process in this application, based on the public key, private key, and unique identifier, combined with the unique identifiers of existing consensus nodes in the network, uses a verifiable random access method to maintain the consensus network in a secure and controllable state, raising the entry threshold for the consensus network.

[0096] Furthermore, in this embodiment, the consensus nodes to be connected can be identified through the admission unit, and the security of critical data can be ensured by allocating hardware security modules, thereby raising the admission threshold of the consensus network and ensuring the security and reliability of the consensus nodes to be connected to the consensus network as much as possible.

[0097] Example 2:

[0098] To address the issues of loose node admission threshold control in existing admission mechanisms, poor defense against targeted attacks by illegal nodes on a fixed consensus node in the consensus network, and uneven node load in the consensus network, this application provides a common node admission method.

[0099] See Figure 2 As shown, Figure 2 This is a basic flowchart illustrating a common node admission method provided in this application embodiment, including:

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

[0101] In this embodiment of the application, access units and portal sites can be pre-established.

[0102] In this embodiment of the application, the access unit can configure a second security module and place it in the portal site for ordinary nodes to access.

[0103] In this embodiment, the portal site can be configured to only periodically and randomly select consensus nodes to obtain non-sensitive information about the blockchain network, including the maximum blockchain height and the latest whitelist. It should be noted that the whitelist described in this embodiment is compiled from information about all consensus nodes in the consensus network, including each consensus node's unique identifier, network address, communication port, public key, etc.

[0104] S202: Generate your own public and private keys.

[0105] In this embodiment, a regular node can obtain a second security module from the portal site, and the second security module can then generate the regular node's own public and private keys.

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

[0107] Furthermore, in this embodiment of the application, the access unit may have data read and write permissions for the second security module, thereby facilitating the supervision of each consensus node.

[0108] In this embodiment, the user can also customize the username and password of the ordinary node. Based on this username and password, an account factor is calculated, and this account factor is used to encrypt the private key. This improves the security of private key storage and reduces the risks that may arise from private key leakage.

[0109] S203: Generate a second choice radix based on Height and the public key.

[0110] In this embodiment of the application, a second choice base can be obtained through a hash algorithm. For example, it can be obtained using Hash(Height|Pubkey). User ) or Hash(Height|Timestamp|Pubkey) User The second choice base number is determined.

[0111] It should be noted that Pubkey in the above formula User This is the public key of the ordinary node.

[0112] It should be understood that the determination of the second choice radix can be achieved not only through hash algorithms, but also through other algorithms, as long as a unique result can be generated based on the height and the public key.

[0113] S204: 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.

[0114] In this embodiment, the selection criterion is a standard pre-set by the engineer and followed by the entire consensus network. For example, the selection criterion can be set as: the m unique identifiers in the consensus network closest to the first selection cardinality; or, it can be the m unique identifiers in the consensus network least close to the first selection cardinality. In this embodiment, the selection criterion can be set by the engineer according to actual needs. Furthermore, the value of m should be a constant integer greater than or equal to 1.

[0115] It should be understood that, in the embodiments of this application, there may be only one target consensus node, or there may be multiple nodes.

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

[0117] In this embodiment of the application, the whitelist records the network address and communication port of each consensus node in the consensus network, thereby enabling the establishment of a connection with the target consensus node.

[0118] In this embodiment of the application, in order to prevent ordinary nodes from being unable to re-attempt access to the consensus network when a connection with a certain consensus node fails, this embodiment of the application can re-select a target consensus node that meets the preset selection criteria after the target consensus node connection fails, thereby ensuring the reliability of network access.

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

[0120] Next, if the connection with the target consensus node fails, a new candidate consensus node is selected from the m candidate consensus nodes to be used as the target consensus node for connection.

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

[0122] In this embodiment, the access request message may contain the username and password, or the hash value of the password, of the ordinary node, thereby 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 none of the consensus nodes in the blockchain have stored the username, then the username and password, or the hash value of the username and password, can be associated and recorded locally. Furthermore, a secure channel can be established with the ordinary node for communication.

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

[0124] Furthermore, to further enhance security and defend against malicious intrusion, in this embodiment of the application, the timestamp of the current time and / or the obtained height can be included in the access request message, so that the target consensus node can determine whether the ordinary node requesting access to the blockchain is secure based on the timestamp and / or height.

[0125] For example, when the access request message also includes the timestamp of the ordinary node's access request, the target consensus node can 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 it is not within the preset range, then the ordinary node's access can be rejected, and its connection can be disconnected.

[0126] It should be understood that in the event of a malicious attack, a malicious node might intercept an earlier access request message and attempt to gain access. The timestamp carried in that access request message would often differ significantly from the current time. Therefore, the timestamp verification method described above can effectively prove that the ordinary node is a legitimate, active, and secure node, thereby effectively defending against malicious intrusions and improving the security of the blockchain.

[0127] Similarly, when the access request message also includes a height, the target consensus node can 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. If it is not within the preset range, then the ordinary node's access can be rejected and its connection can be disconnected.

[0128] Similarly, because the blockchain itself is constantly evolving, if a malicious node intercepts an early access request message or a randomly generated height, the deviation between that height and the current maximum blockchain height will often be significant. Therefore, the height verification method described above can effectively prove that the ordinary node is a legitimate, active, and secure node, thereby effectively defending against malicious intrusions and improving blockchain security.

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

[0130] The access request message carries the public key of the ordinary node itself. After receiving the access request message, the target consensus node can first decrypt it using its own private key, and then use the public key in the access request message to verify whether the signature of the access request message is valid.

[0131] S207: When the verification is valid, establish a secure channel with the ordinary node.

[0132] In the embodiments of this application, any available secure channel establishment method can be used to establish the secure channel.

[0133] For example, after verifying legitimacy, the target consensus node can randomly generate a temporary channel key factor (KeyFac), sign and encrypt it to obtain the secure channel establishment information, which is then returned to the ordinary node. The secure channel establishment information mainly includes:

[0134] RespBody = UserID|Timestamp|KeyFac

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

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

[0137] It should be noted that in the above formulas, UserID is the username of the ordinary node, and the timestamp is the timestamp carried in the access request message (if the implementation does not include a timestamp in the access request message, then the timestamp can be omitted here). PubkeyUser is the public key of the ordinary node, PrikeyB is the private key of the consensus node, and Sign... PrikeyB (RespBody) indicates that the RespBody is signed using PrikeyB; Encrypt PubkeyUser (RespBody|Sign PrikeyB (RespBody) indicates that PubkeyUser is used to match (RespBody|Sign) PrikeyB (RespBody) is encrypted.

[0138] After receiving the secure channel establishment information from the target consensus node, a regular node decrypts and verifies the legitimacy of the secure channel establishment information, including using Prikey. UserThe message is decrypted, and its signature is verified using the target consensus node's PubkeyB. The UserID and timestamp in the message are also verified to match those sent by the target node. (PubkeyB is mentioned here, but its relevance to the message is unclear.) User This is the private key of the ordinary node.

[0139] Ordinary nodes calculate the channel key Key using the same method as the target consensus node, and all subsequent communications are encrypted using the Key, thereby establishing a secure channel.

[0140] It should be noted that during the initial connection process for a regular node, it is only necessary to obtain the second security module and generate its own public and private keys. In subsequent connection processes, only the updated Height and whitelist are needed; the public and private keys do not need to be regenerated.

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

[0142] Furthermore, in this embodiment, Height can be combined to implement security verification of ordinary nodes, thereby solving the problem that in the existing access mechanism, the verification process is not associated with blockchain state information, so it cannot prove whether the node is a legitimate, active, secure node, or a disguised malicious node or a controlled polluted node, resulting in insufficient network security.

[0143] Example 3:

[0144] To address the problem that existing access control mechanisms fail to link the verification process with blockchain state information, thus failing to prove whether a node is a legitimate, active, secure node, a disguised malicious node, or a controlled polluting node, resulting in insufficient network security, this application provides a method for ordinary node access control.

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

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

[0147] Similar to Embodiment 2, in this embodiment, access units and portal sites can be pre-established. The portal site can be configured to only allow periodically, randomly selected consensus nodes to obtain non-sensitive information about the blockchain network, including the maximum blockchain height and the latest whitelist. The whitelist is compiled from information on all consensus nodes in the consensus network, including each node's unique identifier, network address, communication port, public key, etc.

[0148] S302: Identify the target consensus node from the whitelist.

[0149] Similar to Embodiment 2, in this embodiment, ordinary nodes can obtain the second security module from the portal site, which then generates the ordinary node's own public and private keys. The second security module can be configured by the access authority and placed in the portal site for ordinary nodes to access. To facilitate access by ordinary nodes, in this embodiment, the second security module can be a software security module.

[0150] In this embodiment, the user can also customize the username and password of the ordinary node. Based on this username and password, an account factor is calculated, and this account factor is used to encrypt the private key. This improves the security of private key storage and reduces the risks that may arise from private key leakage.

[0151] Furthermore, in this embodiment of the application, the access unit may have data read and write permissions for the second security module, thereby facilitating the supervision of each consensus node.

[0152] In this embodiment, the portal site can be configured to only periodically and randomly select consensus nodes to obtain non-sensitive information about the blockchain network, including the maximum blockchain height and the latest whitelist. It should be noted that the whitelist described in this embodiment is compiled from information about all consensus nodes in the consensus network, including each consensus node's unique identifier, network address, communication port, public key, etc.

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

[0154] In this embodiment, the selection criterion is a standard pre-set by the engineer and followed by the entire consensus network. For example, the selection criterion can be set as: the m unique identifiers in the consensus network closest to the first selection cardinality; or, it can be the m unique identifiers in the consensus network least close to the first selection cardinality. In this embodiment, the selection criterion can be set by the engineer according to actual needs. Furthermore, the value of m should be a constant integer greater than or equal to 1.

[0155] It should be understood that, in the embodiments of this application, there may be only one target consensus node, or there may be multiple nodes.

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

[0157] In this embodiment of the application, the whitelist records the network address and communication port of each consensus node in the consensus network, thereby enabling the establishment of a connection with the target consensus node.

[0158] In this embodiment of the application, in order to prevent ordinary nodes from being unable to re-attempt access to the consensus network when a connection with a certain consensus node fails, this embodiment of the application can re-select a target consensus node that meets the preset selection criteria after the target consensus node connection fails, thereby ensuring the reliability of network access.

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

[0160] Because the blockchain itself is constantly evolving, if a malicious node intercepts an early access request message or a randomly generated height, the deviation between that height and the current maximum blockchain height will often be significant. Therefore, the height verification method described above can effectively prove that the ordinary node is a legitimate, active, and secure node, thereby effectively defending against malicious intrusions and improving blockchain security.

[0161] In this embodiment, the access request message may also include a timestamp, which allows for further verification of the identity of the ordinary node through timestamp verification. For details, please refer to the relevant description in Embodiment 2.

[0162] Furthermore, in this embodiment, the access request message also includes the username and password, or the hash value of the password, of the ordinary node, thereby 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 none of the consensus nodes in the blockchain store the username, then the username and password, or the hash value of the username and password, can be associated and recorded locally. A secure channel can then be established to communicate with the ordinary node.

[0163] This embodiment combines the maximum height of the blockchain, which reflects the latest state of the blockchain, to achieve access verification. This allows the verification of a regular node as a legitimate, active, and secure node based on the height. This addresses the problem in existing access mechanisms where the verification process is not linked to blockchain state information, thus failing to prove whether a node is a legitimate, active, and secure node, or a disguised malicious node or a controlled polluted node, leading to insufficient network security.

[0164] It should be understood that the scheme in Embodiment 1 can raise the entry threshold for consensus nodes and improve the security and regulatory oversight of the consensus network formed by these nodes. Embodiments 2 or 3, on the other hand, can improve the security of ordinary nodes accessing the blockchain. Therefore, in this application, embodiments 1 and 2, or embodiments 1 and 3, can be used simultaneously to achieve better results.

[0165] When implementing the solution using both Embodiment 1 and Embodiment 2, or both Embodiment 1 and Embodiment 3, consensus nodes can be configured to not initiate application transactions, and only ordinary users can initiate application transactions (such as registering digital assets, asset trading, etc.). In this way, by distinguishing the permissions of consensus nodes and ordinary nodes, the business operations of the blockchain core and application parts can be securely isolated and controlled, reducing the risk of malicious nodes impersonating and interfering.

[0166] Example 4:

[0167] To alleviate the inefficiency of existing consensus mechanisms, this application provides a consensus method applied in consensus networks.

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

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

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

[0171] 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.

[0172] S403: The next leader node will aggregate the threshold signatures of each consensus node into an aggregate signature and determine the next leader node.

[0173] In this embodiment, the next-round leader node can be determined randomly from among the consensus nodes in the consensus network. By randomly determining the next-round leader node from among the consensus nodes in the consensus network, interference caused by predicting the leader node can be avoided, thus improving the security of the consensus network.

[0174] For example, the third choice cardinality can be determined based on the aggregated signature, and the consensus node whose door limit signature is closest to the third choice cardinality can be determined as the leader node for the next round.

[0175] In this way, since the next round leader node is determined based on threshold signature and third selection cardinality, that is, the next round leader node is selected from the consensus nodes that have already voted, the risk of empty election can be effectively avoided, and the reliability of the consensus mechanism operation can be improved.

[0176] S404: The next leader node initiates a second proposal and broadcasts it to all consensus nodes in the consensus network.

[0177] In this application embodiment, the second proposal includes a newly proposed block, an aggregate signature, and a next-next-round leader node.

[0178] S405: Each consensus node in the consensus network verifies the legality of the aggregated signature, and when the verification is successful, it reports the verification result to the leader node in the next round.

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

[0180] For example, assuming this round is round n, let V be the threshold signature result of each consensus node for the first proposal. j*n Let j*n represent the j-th consensus node in round n. Each consensus node can independently compute the following VRF data (denoted as Vrf). j*n ):

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

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

[0183] In the formula, Prikey j To compute the private key of the j-th consensus node for this VRF data, Pn is the first proposal in round n.

[0184] Then, in another feasible embodiment of this 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.

[0185] For example, assuming this round is round n, we can calculate Hash(QC). n ) as the third choice base, and Hash(QC) as the base. n Based on the consensus statement, the node with the closest consensus value (Vh) among all nodes is selected as the leader node for the next round. Among these, QC... n The aggregate signature for round n.

[0186] Then, when the leader node broadcasts to all consensus nodes in the consensus network in the next round, QC will be... n The Vrf that is determined to be the leader node in the next round j*n Send to the consensus node. Because of QC. n It is the result of the aggregation of threshold signatures from each consensus node, so each consensus node can verify QC. n The legitimacy of QC. Therefore, each consensus node can verify the legitimacy of QC. n After performing legitimacy verification, the public key of the next-round leader node can be obtained by searching the whitelist. Based on this public key, the VRF of the next-round leader node can be implemented. j*n The Vp in the middle verifies the Vh of the next leader node, thereby verifying the Vrf of the next leader node. j*n The randomness.

[0187] After successful verification, each consensus node can execute step S405. If verification fails, in an optional embodiment of this application, the next-round leader node can be notified to re-determine the next-next-round leader node, or the previous-round leader node can be used as the next-next-round leader node, thereby ensuring the normal operation of the entire consensus mechanism.

[0188] It should be understood that, in this embodiment of the application, the leader for each round except the first and second rounds can be determined in the manner described above. The leader nodes for the first and second rounds can be designated by the engineer.

[0189] 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, it will submit the first proposal to the database for storage.

[0190] It should be noted that in this embodiment, there is exactly one leader node in each round. This simplifies the voting process and improves consensus efficiency by confirming only one leader node per round.

[0191] It is important to understand that, in fact, the leader node in each round except the first and second rounds simultaneously performs the work of the current round leader node, the next round leader node, and the next-next round leader node. That is, in this embodiment, the leader node in each round except the first and second rounds acts as the current round leader node, proposing the blocks to be determined in this round and determining the next round leader node; it also acts as the next round leader node, forming an aggregate signature from the threshold signatures of the blocks proposed by the previous round leader node; and it also acts as the next-next round leader node, verifying the legality of the aggregate signatures of the blocks proposed by the leaders of the previous two rounds. When the number of consensus nodes that pass the verification reaches a preset threshold, the block proposal is submitted to the database for storage.

[0192] Furthermore, since the leader node in each round, except for the first and second rounds, simultaneously executes the work of the current round leader node, the next round leader node, and the next-next round leader node, the content processed by a leader node in a single round may simultaneously involve two actions: submitting the proposals from the previous two rounds' leader nodes to the database, and forming an aggregate signature from the threshold signatures of the previous round leader node's proposals. Consequently, two proposals may exist simultaneously in memory. Therefore, to facilitate the differentiation of the proposal to be submitted to the database by the next-next round leader node in step S406, in this embodiment, after verifying the legality of the aggregate signature in step S405, the state of the first proposal in memory can be updated (e.g., setting a flag indicating successful verification for the first proposal in memory), thereby enabling the next-next round leader to submit the first proposal to the database for storage based on its status.

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

[0194] The scheme implemented in this application allows for block confirmation to be completed in just three rounds, resulting in higher consensus efficiency. Furthermore, in this embodiment, the votes of consensus nodes in each round are directly sent to the designated leader node for the next round. This allows multiple rounds of block confirmation processes to be executed in parallel within each round, thereby improving consensus efficiency. Simultaneously, since the consensus node sends its vote to the leader node for the next round instead of returning it to the leader node for the current round, communication complexity is reduced, and the risk of malicious interference from external nodes targeting the leader is avoided, thus improving network reliability.

[0195] Example 5:

[0196] This embodiment provides further examples and explanations of the solution proposed in this application, based on the foregoing embodiments.

[0197] The overall architecture of the embodiments in this application can be found in [reference]. Figure 5 As shown, it includes both a service side and a user side. The service side consists of access-granting entities, a security module, and a blockchain service network based on an access mechanism, while the user side consists of ordinary nodes. The service side only provides relevant services to the user side through the blockchain service network, such as user access, transactions, and queries.

[0198] in:

[0199] The approved entities are established by professional security companies or regulatory authorities. Their role is to provide hardware security modules (i.e., the first security module, which can take the form of U-keys, encryption machines, encryption cards, etc.) for consensus nodes in the blockchain service network, and software security modules (i.e., the second security module) for the blockchain service portal site.

[0200] The hardware security module is issued by the access authority to the consensus nodes in the blockchain network. It is used for identity authentication, secure registration and secure communication when the consensus nodes access the consensus network.

[0201] The software security module is distributed to ordinary nodes by the access authority through the portal site. It is used by ordinary nodes to participate in identity authentication and secure communication when accessing the blockchain network.

[0202] Consensus nodes are a fundamental component of a blockchain service network. They are jointly established by institutions that need to join the network and participate in consensus. Each node must install a hardware security module to be recognized by other nodes in the network. Consensus nodes are responsible for handling various transactions that need to be recorded on the blockchain and managing the blockchain's state. Their scope of responsibility is limited to maintaining consensus on data and system configuration within the blockchain network and providing blockchain-related services to ordinary nodes. Therefore, consensus nodes are not allowed to impersonate ordinary nodes to initiate transactions; otherwise, they will not be recognized.

[0203] The portal site, serving as the first point of access for ordinary nodes to the blockchain network, is established by the blockchain service provider. It needs to import and store the software security modules issued by the access grantor and other necessary publicly available information related to the consensus network, and then connect to the blockchain's consensus network as an ordinary node. It provides ordinary nodes with the necessary information and software security modules required for accessing the blockchain network.

[0204] Ordinary nodes need to install the software security module and then connect to and register on the blockchain through the consensus node before they can access relevant services on the blockchain and perform blockchain application layer transactions, such as user registration, asset registration, querying, and trading.

[0205] Below, we will describe in detail one specific optional implementation method:

[0206] In the initial phase, the server first needs to establish access units and produce a sufficient number of hardware and software security modules. Based on this, enough consensus nodes install the hardware security modules and interconnect to establish an initial consensus network, produce the genesis block, and initiate the consensus mechanism for operation.

[0207] After the initial consensus network is launched, a portal site needs to be established. Both the portal site and authorized entities can access the consensus network and periodically obtain non-critical information about the blockchain network from it. The initial blockchain service network is constructed by the portal site and the consensus network.

[0208] Organizations that need to join the consensus network and participate in the consensus process can establish their own nodes and obtain hardware security modules from authorized entities to access the consensus network.

[0209] Ordinary nodes obtain the information and software security modules required to access the network through the portal site, install them, access the blockchain network, initiate transaction requests to the consensus network, synchronize them to the transaction pools of each node, and then complete the process of putting the transaction on the chain through the consensus mechanism.

[0210] The specific processing flow for each step is as follows:

[0211] 1) Establishment of access mechanisms and consensus networks:

[0212] It includes two phases: initial network establishment and consensus node admission and registration.

[0213] a) Initial network establishment

[0214] The implementation method is as follows:

[0215] i. Establish an access unit, and produce and store a unique security root key pair (root private key PrikeyRoot and root public key PubkeyRoot) within the access unit.

[0216] ii. Production security module: The access unit provides hardware security modules for nodes that need to join the consensus network. These modules can take the form of a U-key, encryption card, encryption machine, etc.

[0217] It is important to note that the hardware security module has capabilities such as key generation and cryptographic operations, and critical data cannot be exported from the hardware security module in plaintext.

[0218] 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 This represents the root signature issued to consensus node j, denoted as Sign. PrikeyRoot (PubkeyRoot) indicates that PubkeyRoot is signed using PubkeyRoot. Due to the randomness introduced by the signature algorithm, different hardware security modules will obtain different root signatures, but all can be verified by PubkeyRoot. PubkeyRoot is written into the hardware security module along with PubkeyRoot. PubkeyRoot, as critical data, cannot be exported from the hardware security module.

[0219] iii. Install hardware security modules: Each consensus node must install a hardware security module issued by the admitting entity.

[0220] It should be noted that during the initialization of each consensus node, the hardware security module independently and randomly generates a public-private key pair (private key Prikey). j and public key Pubkey j (where the subscript j represents the j-th consensus node), and is stored within the hardware security module, where Prikey j Hardware security modules must not export critical data.

[0221] It should also be noted that each consensus node calculates its own ID. j =Hash(SignRoot)j Pubkey j (), serving as the unique identifier for consensus nodes.

[0222] It should be noted that ID j This represents the unique identifier of the j-th consensus node.

[0223] iv. Establishing the initial consensus network: A network is formed by connecting a group of initial consensus nodes (at least 4 consensus nodes) with hardware security modules installed.

[0224] Information from all initial consensus nodes is aggregated into an initial whitelist (denoted as WList), which is then signed by each hardware security module and stored under each initial consensus node. The information for each consensus node in the WList must include at least: the unique identifier ID of the consensus node. j Network address, communication port, public key (Pubkey) j Information such as...

[0225] Configure one node in the initial network as the initiating node, create a hard-coded genesis block, publish it to the initial consensus network, and trigger the consensus mechanism to run. (For details on the consensus mechanism, please refer to the explanation below.)

[0226] v. Network Status Update: After the initial network starts running, authorized entities and portal sites can periodically obtain non-critical information related to the blockchain status, such as the latest whitelist (denoted as WList), from the consensus network to provide necessary information when new nodes join.

[0227] b) Consensus node admission and registration:

[0228] The implementation method is as follows:

[0229] i. Obtaining the Hardware Security Module: After the initial consensus network is established, when a consensus node (denoted as A) needs to register to join the consensus network, node A must apply to the access authority and obtain the newly produced hardware security module (which includes PubkeyRoot and SignRoot). A And the latest whitelist WList. SignRoot A This is the root signature generated for node A.

[0230] ii. Install the hardware security module: During node A initialization, the hardware security module generates its own public-private key pair (private key Prikey). A and public key Pubkey A ) and ID A ID A For the generation method, please refer to the previous text on ID. j As shown.

[0231] iii. Random Access to the Consensus Network: Node A calculates and prepares the necessary data for connection using a hardware security module, and then attempts to randomly access the consensus network. This includes:

[0232] Generate a set of verifiable random numbers:

[0233] Vh A =VRF_Hash(Prikey) A Hash(ID) A |timestamp))

[0234] Vp A =VRF_Proof(Prikey) A Hash(ID) A |timestamp))

[0235] Calculate Hash(Vh) A Based on this result, the system finds the three closest node IDs in the whitelist WList, and attempts to connect to and initiate registration requests in turn.

[0236] If the connection fails, repeat the current step (iii) L times (L is a pre-set constant). If it still fails, abandon the operation.

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

[0238] The registration application message mainly includes:

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

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

[0241] It should be noted that "|" is the concatenation symbol, and Sign is the signature function. X () indicates that the content within the parentheses is signed with X, and Encrypt is the encryption function. X () indicates that the content within the parentheses is encrypted with X.

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

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

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

[0245] Verify SignRoot using PubkeyRoot in the hardware security module. A If the node is valid, calculate the ID of node A. A =Hash(SignRoot) A Pubkey A ).

[0246] Use Pubkey A Vp A Verify Vh A The validity of the VRF is determined; if valid, a hash(Vh) is calculated. A And verify the randomness of access based on the whitelist.

[0247] The randomness of access verification based on the whitelist includes: the unique identifier ID of verification node B. B Is it in the whitelist related to Hash(Vh)? A The closest one of the three unique identifiers. If it is, the verification passes; otherwise, the verification fails.

[0248] vi. Synchronize Registration Application: After node B completes the verification, it synchronizes the relevant information of node A with other consensus nodes and updates the whitelist under this node.

[0249] vii. Responding to Registration Requests: All nodes, including node B, that have processed node A's registration request generate and send a registration response message to node A, and update their own whitelist WList.

[0250] The registration response message mainly includes:

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

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

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

[0254] viii. Confirm successful registration: Node A performs the following verification and processing on the received response message:

[0255] Use Prikey A Decrypt the message and use the Pubkey in the message. j Verify the message signature, ID A It should match your own ID, and the timestamp should match the one in the registration request message.

[0256] Verify SignRoot using PubkeyRoot in the hardware security module. j If the node is valid, calculate the ID of node j. j =Hash(SignRoot) j Pubkey j This verifies whether the information matches the whitelist.

[0257] If verification passes, update the relevant information under node A, including the whitelist. When the number of received response messages reaches a certain threshold, the registration is considered successful.

[0258] 2) Random access for ordinary users:

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

[0260] i. Establishing a Portal Site: During portal site initialization, a software security module provided by the access authority needs to be imported to connect to the consensus network. The portal site is only allowed to periodically and randomly select consensus nodes to obtain non-sensitive information from the blockchain network. This non-sensitive information includes at least the maximum blockchain height (Height) and the latest whitelist (WList) of consensus nodes. Furthermore, other application requests from the portal site will not be accepted by the consensus network.

[0261] ii. Obtaining the software security module: For ordinary nodes (denoted as User), if it is the first connection, the software security module needs to be obtained from the portal site (which includes PubkeyRoot and SignRoot). soft SignRoot soft For the generation method, please refer to the previous section on SignRoot. j (Description of WList and maximum blockchain height). If this is not your first time, you only need to obtain WList and Height.

[0262] iii. Install software security modules:

[0263] During user initialization, the software security module calculates the user's account factor, Userkey, based on the user-defined username (UserID) and password (Passwd). For example: Userkey = Hash(UserID|Passwd). Neither the username (UserID) nor the password (Passwd) needs to be stored; they are managed by the user themselves.

[0264] The software security module randomly generates a user's public / private key pair (private key Prikey). User and public key Pubkey User ), where Prikey User It needs to be encrypted with a Userkey before being saved and managed.

[0265] iv. Random access network:

[0266] User calculates a hash value associated with the current state of the blockchain: H = Hash(Height | Timestamp | Pubkey) User )

[0267] Find the three consensus node IDs in the whitelist WList that are closest to H, and attempt to connect to them in turn. If the connection fails, repeat the current step (iv) L times (L is a pre-set constant). If all attempts fail, abandon the operation.

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

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

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

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

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

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

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

[0275] Verify that both the height and timestamp are within a reasonable range. If yes, proceed to the next step; otherwise, access is not permitted.

[0276] In the consensus network, UserID and Hash(Passwd) are verified. UserID must be unique within the consensus network and correspond to Hash(Passwd). If the local node does not have a record, it randomly queries multiple consensus nodes. If none of the consensus nodes have a record, the UserID and Hash(Passwd) are added to the local record and synchronized with other consensus nodes.

[0277] vii. Establish a secure channel: After successful access verification, a temporary secure channel must be established between the User and the consensus node to complete the subsequent interaction:

[0278] After successful 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:

[0279] RespBody = UserID|Timestamp|KeyFac

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

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

[0282] After receiving the response message from node B, the user decrypts and verifies the message's validity, including using Prikey. User Decrypt the message and use node B's Pubkey. B Verify the message signature, check if the UserID in the message matches your own, and verify if the timestamp matches the one in your access request message. If they match, the verification passes; otherwise, the establishment of the secure channel can be terminated.

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

[0284] 3) Initiate application transaction

[0285] In this embodiment, consensus nodes are not allowed to initiate application transactions; only ordinary nodes have this permission (e.g., registering digital assets, asset transactions, etc.). When a transaction needs to be initiated, an ordinary node needs to send the transaction to the consensus node for processing and obtain the processing result. The implementation method is as follows:

[0286] i. Network Access: A regular node (denoted as User) randomly accesses the blockchain service network and establishes a secure channel with a consensus node (denoted as B). It then queries User's private state information in the blockchain (such as account balance, transaction records, etc., which may vary depending on the application). Since transaction messages typically contain a lot of information, all messages in the following communication process are encrypted using the secure channel's key.

[0287] ii. Initiate a transaction: After successfully accessing the network, generate a transaction message based on the User's private state information and actual needs, and send it to node B.

[0288] The main contents of a transaction message include: message ID (calculated from UserID, current timestamp, etc.), transaction list, and message signature.

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

[0290] iii. Transaction Processing: After receiving the transaction message initiated by User, Node B verifies the validity of the transaction content, including the timestamp. If the verification is successful, it synchronizes the transaction to the transaction pools of all other consensus nodes for subsequent consensus processing.

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

[0292] 4) Consensus mechanisms and the formation of blockchain:

[0293] After a regular user submits a transaction to the consensus network, the transaction pools of each consensus node will be synchronized, and then the verification and consensus mechanism will determine whether the transaction can eventually be recorded on the blockchain.

[0294] The consensus mechanism employs a chain-like, round-based processing method based on a leader node and voting. In each round, the unique leader among the consensus nodes retrieves valid transactions from the transaction pool, combines them with the blockchain's state information to package them into a new block, and initiates a block proposal broadcast to other consensus nodes. All consensus nodes then engage in three rounds of voting and processing to ultimately determine the new block's state on the chain. The implementation method is as follows:

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

[0296] a) The generation and consensus process of the genesis block:

[0297] The genesis block is a fixed block that is hard-coded, and the block proposal specifies that the next leader will still be itself.

[0298] i. After the initial blockchain network is built, the initial state of the blockchain has no blocks. At this point (referred to as round 0), a consensus node is configured (using...). Figure 6 Taking node 1 as an example, it acts as the starting node, creating a hard-coded fixed block as the genesis block. In the next round (i.e., round 1), the leader (denoted as L1) still points to itself, and writes the genesis block and L1 together into the proposal (denoted as P0), which is then broadcast to all consensus nodes.

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

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

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

[0302] Each node will V j*0 and Vrf j*0 Send it to Leader (L1) of round 1, which is to send it back to node 1.

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

[0304] iii. In round 1, the Leader receives enough V messages from each node. j*0 and Vrf j*0 Then, the votes are verified and tallied to generate proposals for the next round, including:

[0305] Voting V will be processed using a threshold signature method. j*0 Create an aggregate signature (denoted as QC0), and QC0 will serve as the announcement result of the voting statistics for P0.

[0306] Calculate Hash(QC0), and use Hash(QC0) as the basis for Vrf sent from each node. j*0 Find the closest one. The VRF sent by node k. k*0 For example, node k is determined as the Leader of the next round (i.e., round 2) (denoted as L2).

[0307] Include relevant data (at least: QC0, L2+Vrf) k*0 After signing the new block (which is generated by taking several transactions from the transaction pool) a new proposal (denoted as P1) is generated and broadcast to all consensus nodes.

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

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

[0310] Verify the VRF by finding the public key of the corresponding node k in the whitelist using L2. k*0 This confirms that the selection of the Leader in the next round is randomized based on the latest state of the blockchain.

[0311] Perform a validity verification on the blocks in P1.

[0312] After all the above verifications pass, the state of proposal P0 in the node's local memory is changed to "ready to commit". A vote (denoted as VQC) is generated for the previous voting result QC0. j*0 V) on the new proposal P1 j*1 and VRF data Vrf j*1 Send it to the verified next-round Leader, L2.

[0313] v. In round 2, the Leader receives enough VQCs from each node. j*0 V j*1 and Vrf j*1 Afterwards, similar to the previous process, verification and vote counting are completed, and proposals for the next round are generated, including:

[0314] V vote j*1 The aggregate signature is QC1. The vote on QC0 in the previous round results in the aggregate signature CQC0. CQC0 indicates that P0 can be proven to have reached the quorum of nodes that have updated their memory state (CQC0 serves as the mark that P0 is finally confirmed).

[0315] Calculate Hash(QC1) and find the Leader for the next round (for example, node i, denoted as L3).

[0316] Relevant data (including at least: CQC0, QC1, L3+Vrf) i*1 After signing the new block (which is generated from several transactions taken from the transaction pool) a new proposal (denoted as P2) is generated and broadcast to all nodes.

[0317] vi. After each node receives proposal P2, it will process it in a similar manner to step iv. According to CQC0, it will submit it along with P0 to the local database for persistent storage.

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

[0319] 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.

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

[0321] 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 comply with regulatory requirements; while newly joined ordinary nodes can also confirm that the network they are joining is reliable and trustworthy.

[0322] 2. By installing hardware security modules and software security modules on consensus nodes and ordinary users respectively, the permissions of consensus nodes and ordinary users are differentiated, thereby ensuring the secure isolation and control of the business operations of the core and application parts of the blockchain, and reducing the risk of malicious nodes impersonating and interfering.

[0323] 3. The consensus mechanism achieves a verifiable random determination mechanism for each round based on blockchain state and VRF. Specifically: the uniqueness of the Leader in each round simplifies the voting process and improves the efficiency of consensus; the randomness of the Leader determination avoids interference caused by prediction, thus improving the security of the blockchain network; and determining the next Leader from the voting nodes avoids the risk of empty elections, thereby improving the reliability of the consensus mechanism.

[0324] 4. In the consensus mechanism, each round's vote is directly sent to the Leader for the next round. This reduces communication complexity and the risk of malicious nodes outside the consensus network interfering with the Leader, thereby improving the reliability of the blockchain network.

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

[0326] Example 6:

[0327] Based on the same inventive concept, this application also provides two consensus node admission devices and three ordinary node admission devices in its embodiments. Please refer to... Figures 7 to 11 As shown, Figure 7 and Figure 8 The diagram shows consensus node admission devices 100 and 200, respectively, corresponding to the operations performed by the consensus node to be accessed and the target consensus node in the method shown in Embodiment 1. Figure 9 and Figure 10 The diagram shows ordinary node admission devices 300 and 400, corresponding to the operations performed by ordinary nodes and target consensus nodes in the method shown in Embodiment 2, respectively. Figure 11 A normal node admission device 500 is shown that corresponds to the operation performed by a normal node in the method shown in Embodiment 3.

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

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

[0330] The first generation module 101 is used 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.

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

[0332] The first connection processing module 103 is used to connect to the target consensus node and send a registration application message containing the public key, the Vh and the Vp to the target consensus node so that the target consensus node can verify the consensus node to be connected based on the public key and the Vp.

[0333] In this embodiment of the application, the first generation module 101 is specifically used to install a first security module that has been reviewed and allocated by a preset access unit, generate its own public key and private key using the first security module, and generate its own unique identifier based on the public key.

[0334] In this embodiment of the application, the access unit has data read and write permissions for the first security module.

[0335] In this embodiment of the application, the first security module is a hardware security module.

[0336] In this embodiment of the application, the determining module 102 is further configured 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 determining module 102 generating its own unique identifier based on the public key specifically includes: calculating the first root signature and its own public key to obtain the unique identifier.

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

[0338] In this embodiment of the 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.

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

[0340] In this embodiment, the consensus node to be connected has a root public key pre-obtained; 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 sent the registration response message; the determining module 102 is specifically used to verify the second root signature in the registration response message using the root public key; when the verification is successful, the consensus node's unique identifier is calculated using the consensus node's public key and the second root signature; the unique identifier of the consensus node is verified to be an existing unique identifier in the consensus network; if so, the verification is successful; otherwise, the verification fails.

[0341] In this embodiment of the application, the registration application message contains a first signature; the registration response message further includes: a unique identifier of the consensus node to be connected, calculated by the consensus node that sent the registration response message based on the public key in the registration application message and the first signature; the determining module 102 is further configured to determine that the unique identifier in the registration response message is consistent with its own unique identifier before verifying the second signature in the registration response message using the root public key.

[0342] See Figure 8 As shown, a consensus node admission device 200, applied in a consensus node, includes: a receiving module 201, a first verification module 202, and a processing module 203. Wherein:

[0343] The receiving module 201 is used to receive a registration application message sent by the consensus node to be connected; the registration application message contains the public key of the consensus node to be connected, a verifiable random number Vh, and a proof Vp of Vh;

[0344] 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 connected;

[0345] The processing module 203 is used to determine a first selection base number based on Vh after verifying 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 number meet the preset selection criteria.

[0346] In this embodiment of the application, the processing module 203 is further configured to, when the unique identifier of the consensus node itself and the first selection base satisfy the preset selection criteria, send a registration response message to the consensus node to be connected. The registration response message contains 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 connected can verify the registration response message.

[0347] In this embodiment of the application, the registration application message contains the first signature of the consensus node to be connected; the processing module 203 is further configured to calculate the unique identifier of the consensus node to be connected based on the first signature and public key in the registration application message before sending a registration response message to the consensus node to be connected; and to put the calculated unique identifier of the consensus node to be connected into the registration response message.

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

[0349] The first acquisition module 301 is used to acquire 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;

[0350] The second generation module 302 is used to generate its own public key and private key, and generate a second selection base number based on the Height and the public key;

[0351] The second connection processing module 303 is used to determine, based on the second selection base number, 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; and establish a secure channel according to the secure channel establishment information returned by the target consensus node when receiving the secure channel establishment information.

[0352] In this embodiment of the application, the second generation module 302 is specifically used to obtain a second security module configured by a preset access unit from a preset portal site; and to generate its own public key and private key using the second security module.

[0353] In this embodiment of the application, the second security module is a software security module.

[0354] In this embodiment of the application, the access unit has data read and write permissions for the second security module.

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

[0356] In this embodiment of the application, the ordinary node is preset with a username and password; the second generation module 302 is further configured to calculate an account factor based on the username and password, and use the account factor to encrypt the private key.

[0357] In this embodiment of the application, the second connection processing module 303 is specifically used to select m candidate consensus nodes from the whitelist whose unique identifiers are closest to the second selection base number; where 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.

[0358] In this embodiment of the 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.

[0359] See Figure 10 As shown, a common node admission device 400, applied in a consensus node, includes: a second verification module 401 and a processing unit 402. Wherein:

[0360] The second verification module 401 is used to verify the legality of the access request message when it receives an access request message from a normal node;

[0361] The processing unit 402 is used to establish a secure channel with the ordinary node when verifying legitimacy.

[0362] In this embodiment of the application, the access request message contains the 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, to determine that the access request message is legitimate.

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

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

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

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

[0367] 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 security channel establishment information returned by the target consensus node, a security channel is established according to the security channel establishment information; the security channel establishment information is the feedback information sent by the target consensus node after verifying the legitimacy of the ordinary node based on the height.

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

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

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

[0371] In this embodiment of the application, the access unit has data read and write permissions for the second security module.

[0372] In addition, this application also provides a consensus network, which corresponds to the method shown in Embodiment 4.

[0373] The consensus network includes multiple consensus nodes, which include the current round leader node, the next round leader node proposed by the current round leader node, and the next round leader node proposed by the next round leader node.

[0374] 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;

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

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

[0377] The next-round leader node is also used to initiate a second proposal and broadcast it to all consensus nodes in the consensus network; the second proposal includes a new proposed block, the aggregate signature, and the next-round leader node.

[0378] Each consensus node in the consensus network is also used to verify the legality of the aggregated signature, and when the verification is successful, to report the verification result to the next-next-round leader node;

[0379] The next round leader node is used to submit the first proposal to the database for storage when the number of consensus nodes that have passed verification reaches a preset threshold.

[0380] It should be noted that each node in a consensus network can be implemented through one or more electronic devices.

[0381] In the embodiments of this application, there is one and only one leader node in each round.

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

[0383] In this embodiment of the application, the next-round leader node is specifically used to determine a third selection base based on the aggregated signature; and to determine the consensus node whose door limit signature is closest to the third selection base as the next-round leader node.

[0384] In this embodiment of the application, after each consensus node in the consensus network performs threshold signature on the first proposal, each consensus node is further configured to generate its own verifiable random number Vh and a proof Vp of Vh using a verifiable random function, and send Vh and Vp to the next-round leader node.

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

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

[0387] Example 7:

[0388] This embodiment provides an electronic device, which can be found in [reference]. Figure 12 As shown, it includes a processor 1201, a memory 1202, and a communication bus 1203. Wherein:

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

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

[0391] Understandable. Figure 12 The structure shown is for illustrative purposes only; the electronic device may also include components that are more advanced than those shown. Figure 12 The more or fewer components shown, or having the same Figure 12 The different configurations shown are not limited in this application embodiment.

[0392] The electronic devices in the embodiments of this application can be implemented using devices such as servers, mobile terminals, and fixed terminals.

[0393] This embodiment also provides a readable storage medium, such as a floppy disk, optical disk, hard disk, flash memory, USB flash drive, SD (Secure Digital Memory Card), MMC (Multimedia Card), etc. This readable storage medium stores one or more programs that implement the above steps. These 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 Embodiment 1, or to implement the ordinary node admission method implemented by the ordinary node or the target consensus node in Embodiments 2 / 3. Further details will not be provided here.

[0394] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0395] Furthermore, the units described as separate components may or may not be physically separate. 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 can be selected to achieve the purpose of this embodiment according to actual needs.

[0396] Furthermore, the functional modules in the various embodiments of this 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.

[0397] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.

[0398] In this article, "multiple" refers to two or more.

[0399] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A consensus method, characterized by, Applied to a consensus network, comprising: A current round leader node initiates a first proposal and broadcasts it to all consensus nodes in the consensus network; the first proposal includes a proposed block and a proposed next round leader node; Each consensus node in the consensus network threshold signs the first proposal and sends the signature result to the next round leader node; The next round leader node forms an aggregated signature from the threshold signatures of each consensus node and determines a next next round leader node; The next round leader node initiates a second proposal and broadcasts it to all consensus nodes in the consensus network; the second proposal includes a newly proposed block, the aggregated signature, and the next next round leader node; Each consensus node in the consensus network verifies the legitimacy of the aggregated signature, and if the verification is passed, feeds back the verification result to the next next round leader node; When the number of consensus nodes that pass the verification reaches a preset threshold, the next next round leader node submits the first proposal to a database for storage; After each consensus node in the consensus network threshold signs the first proposal, the method further comprises: Each consensus node respectively generates a verifiable random number Vh and a proof Vp of the Vh using a verifiable random function, and sends the Vh and Vp to the next round leader node.

2. The consensus method of claim 1, wherein, There is only one leader node per round.

3. The consensus method of claim 1, wherein, The determination of the next next round leader node comprises: Randomly determining the next next round leader node from each consensus node in the consensus network.

4. The consensus method of claim 3, wherein, Randomly determining the next next round leader node from each consensus node in the consensus network comprises: Determining a third selection base according to the aggregated signature; Determining the consensus node with the threshold signature closest to the third selection base as the next next round leader node.

5. The consensus method of claim 1, wherein, The second proposal further includes the Vp and Vh of the next next round leader node; the method further comprises: Each consensus node obtains the public key of the next next round leader node, and verifies the Vh of the next next round leader node based on the public key and the Vp of the next next round leader node.

6. A consensus network, characterized by, The consensus network includes a plurality of consensus nodes, including a current round leader node, a next round leader node proposed by the current round leader node, and a next next round leader node proposed by the next round leader node; The current round leader node is configured to initiate a first proposal and broadcast it to all consensus nodes in the consensus network; the first proposal includes a proposed block and a proposed next round leader node; Each consensus node in the consensus network is configured to threshold sign the first proposal and send the signature result to the next round leader node; and after each consensus node in the consensus network threshold signs the first proposal, each consensus node is further configured to respectively generate a verifiable random number Vh and a proof Vp of the Vh using a verifiable random function, and send the Vh and Vp to the next round leader node; The next round leader node is configured to form an aggregated signature from the threshold signatures of each consensus node and determine a next next round leader node; The next round leader node is further configured to initiate a second proposal and broadcast the second proposal to all consensus nodes in the consensus network, wherein the second proposal comprises a newly proposed block, the aggregated signature, and a next round leader node; Each consensus node in the consensus network is further configured to verify the legality of the aggregated signature, and feed back a verification result to the next round leader node if the verification is passed; The next round leader node is configured to submit the first proposal to a database for storage if it is determined that the number of consensus nodes passing the verification reaches a preset threshold.

7. The consensus network of claim 6, wherein, There is only one leader node in each round.

8. An electronic device, comprising: The method comprises the following steps: a processor, a memory, and a communication bus; The communication bus is configured to realize 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 5.

9. A readable storage medium, characterized by, The readable storage medium stores one or more programs, which can be executed by one or more processors to implement the method according to any one of claims 1 to 5.

Images