A control method, device, medium, and product for admission control of alliance nodes.

Abstract

This invention discloses a control method, device, medium, and product for admitting alliance nodes. Relating to the field of blockchain technology, the method includes: an alliance group determining a root certificate through alliance consensus; after receiving node information submitted by an alliance node, the alliance group signs the node information using the root certificate to generate a member sub-certificate; the alliance group transmits the issued member sub-certificate to the applying alliance node via a secure digital envelope; when receiving an access request from an alliance node, the peer alliance node reads the node table of the node management smart contract; if simultaneously satisfying the following conditions: the alliance node's static security assessment total coefficient in the node management smart contract's node table is greater than a coefficient threshold, the alliance node passes both active and passive verification, then the alliance group connects the alliance node to the consortium blockchain network.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of computer technology, and in particular to a control method, device, medium and product for admission control of alliance nodes. Background Technology

[0002] Consortium blockchain technology is considered the blockchain technology with the greatest potential for practical application, and can be widely used in various industries such as finance and logistics, with a very broad application prospect. Blockchain-based consensus mechanisms, distributed ledgers, and identity verification technologies can establish trust relationships among all nodes in the network.

[0003] Existing consortium blockchains typically employ the following methods for node admission: Node authentication: Implementing node authentication is a crucial means of preventing unauthorized nodes from accessing the network. Common methods include using cryptographic technologies such as digital certificates and key pairs to verify node identity. Only verified legitimate nodes can join the network. Encrypted communication: By using encrypted communication protocols, the security and privacy of data transmitted between nodes can be ensured, thereby reducing the risk of eavesdropping or tampering by unauthorized nodes. Consensus algorithm: In a distributed network using PBFT as the consensus protocol, dynamic admission of permitted nodes in a permissioned blockchain is achieved.

[0004] The aforementioned existing blockchain node admission scheme has the following problems: Centralized trust issues: The centralized trust issues in node admission mechanisms lead to trust bottlenecks. The node admission process relies excessively on specific individuals or verifiers, which limits the flexibility and diversity of on-chain nodes and makes it difficult to adapt to rapidly changing network environments.

[0005] Risk vulnerability: If the operator of a node does not comply with the regulations and colludes with an illegal node to add the illegal node's information to its node configuration file, then the illegal node can access the blockchain network through this node. Summary of the Invention

[0006] This invention provides a control method, device, medium, and product for admitting alliance nodes, to solve at least one of the above-mentioned problems.

[0007] According to one aspect of the present invention, a method for controlling admission of consortium nodes is provided, comprising: The alliance group determines the root certificate through alliance consensus; After receiving the node information submitted by the alliance node, the alliance group signs the node information through the root certificate and generates member sub-certificates. The alliance will issue member sub-certificates and transmit them to the alliance nodes applying to join via secure digital envelopes. When an access request is received from a consortium node, the consortium node reads the node table of the node management smart contract, wherein the access request is generated based on the member sub-certificate; If, simultaneously, the alliance node is listed in the node table of the node management smart contract, the total static security assessment coefficient of the alliance node is greater than the coefficient threshold, the alliance node passes both active and passive verification, then the alliance group will connect the alliance node to the alliance blockchain network.

[0008] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, which enables the at least one processor to perform the alliance node admission control method according to any embodiment of the present invention.

[0009] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the alliance node admission control method according to any embodiment of the present invention.

[0010] According to another aspect of the present invention, a computer program product is provided, which, when executed by a processor, implements the control method for alliance node admission as described in any of the embodiments of the present invention.

[0011] In this embodiment of the invention, the consortium determines the root certificate through consortium consensus. After receiving node information submitted by consortium nodes, the consortium signs the node information using the root certificate to generate a member sub-certificate. The consortium then transmits the issued member sub-certificate to the applying consortium node via a secure digital envelope. Upon receiving the member sub-certificate, the consortium node generates an access request and sends it to the peer consortium node. When the peer consortium node receives the access request, it reads the node table of the node management smart contract. If, simultaneously, the static security assessment coefficient of the consortium node in the node table of the node management smart contract is greater than the coefficient threshold, and both the active and passive verifications of the consortium node pass, the consortium connects the consortium node to the consortium blockchain network. This consortium node admission method, based on multi-verification of smart contracts, organically integrates static security assessment, active verification, and passive verification through the node management smart contract, forming a closed-loop, automated, and highly reliable consortium node admission system. This solves the problems of decentralized trust and risk vulnerabilities, improves the security and reliability of consortium node admission, and ensures the stable operation of the consortium blockchain network.

[0012] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

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

[0014] Figure 1 This is a flowchart of a control method for admitting alliance nodes in an embodiment of the present invention; Figure 2 This is a schematic diagram of a certificate issuance method in an embodiment of the present invention; Figure 3 This is a schematic diagram of a node management smart contract in an embodiment of the present invention; Figure 4 This is a schematic diagram of the total coefficient of static security assessment in an embodiment of the present invention; Figure 5 This is a flowchart of a node verification process in an embodiment of the present invention; Figure 6 This is a flowchart of another control method for admission of alliance nodes in an embodiment of the present invention; Figure 7 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0015] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0016] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0017] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0018] Example 1 Figure 1 This is a flowchart illustrating a control method for consortium node admission provided in an embodiment of the present invention. This embodiment is applicable to consortium node admission control. The method can be executed by the consortium node admission control device in this embodiment, which can be implemented in software and / or hardware, such as... Figure 1 As shown, the method specifically includes the following steps: S110, the alliance group determines the root certificate through alliance consensus.

[0019] In this embodiment, an effective trust system is the cornerstone of consortium blockchain security. The consortium should clearly define the trust architecture of the consortium blockchain network and decide to introduce a root certificate as the foundation of trust. Specific steps include: Step 1: Organizing a consortium meeting to determine the trust architecture of the consortium blockchain. The necessity of the root certificate is discussed at the meeting to ensure that all members have a consistent understanding of the trust foundation. The model relying on a single CA (Certificate Authority) to issue certificates offline establishes a trust anchor through consortium consensus, avoiding the risk of single points of failure. Step 2: Electing or designating a trusted third-party institution to generate the root certificate through a professional Certificate Authority (CA), ensuring the security and uniqueness of the certificate to prevent forgery or tampering. Step 3: Implementing automated lifecycle management of the root certificate using smart contracts, with subsequent dynamic updates of the certificate through the blockchain consensus mechanism, rather than conventional manual reconfiguration. Step 4: After the root certificate is completed, the consortium securely distributes it to each node member, ensuring that each member can obtain the certificate, and recording the fingerprint, validity period, and other key information of the root certificate in detail in internal documents for future verification.

[0020] This embodiment uses smart contracts to store certificate fingerprints and distribution records on the blockchain, achieving full-process auditability. The CA certificate file issued by the root certificate is pre-configured in the configuration files of the first batch of alliance nodes, ensuring that all nodes can correctly identify and trust the root certificate upon startup.

[0021] The technical solution provided in this embodiment has the advantage of three technical effects: the first advantage is the elimination of single point of failure: the alliance consensus replaces the single CA institution; the second advantage is dynamic scalability: smart contracts support certificate updates in seconds; the third advantage is anti-tampering protection: the on-chain evidence storage mechanism prevents the certificate distribution process from being tampered with.

[0022] In a specific example, such as Figure 2 As shown, Figure 2This diagram illustrates the relationships and content structure between three types of certificates (root certificate, intermediary certificate, and member subcertificates), representing a hierarchical relationship within the digital certificate system (similar to a "trust chain"). The root certificate contains: the name of the root certificate authority, its public key, and its signature. Intermediary certificates are issued by the root certificate authority and can also issue lower-level certificates; their content includes: the holder's (usually the intermediary authority's) name, the public key issuer's (root certificate authority's) name, and a signature associated with the root certificate (used to verify the legitimacy of the intermediary certificate). Member subcertificates are issued by the intermediary certificate authority and are held by consortium nodes; their content includes: the holder's name, the public key issuer's (intermediary certificate authority's) name, and a signature associated with the intermediary certificate (used to verify the legitimacy of node certificates). In short, this is a trust transfer structure of "root → intermediary → node": the root certificate trusts the intermediary certificate, the intermediary certificate trusts the member subcertificate, and ultimately, the trust verification of the member subcertificate is achieved.

[0023] S120, after receiving the node information submitted by the alliance node, the alliance group signs the node information through the root certificate and generates a member sub-certificate.

[0024] In this embodiment, alliance nodes need to fill out a node information application form. The form includes information such as node identity, IP address, operating environment, and hardware configuration to ensure the completeness and accuracy of the information. After receiving the application form, the alliance uses a preset verification mechanism to conduct a preliminary verification, confirming the authenticity of the IP address and the legitimacy of the domain name to prevent the addition of forged nodes. If the verification is successful, a member sub-certificate containing the identity, validity period, and signature is generated using a root certificate digital signature. The member sub-certificate is securely issued to alliance nodes via secure channels such as encrypted email or physical media.

[0025] In a specific example, node information submission and signing includes the following steps: S2.1: Alliance nodes need to fill out a node information application form, which includes important information such as node identity, IP address, operating environment, and hardware configuration to ensure the completeness and accuracy of the information.

[0026] S2.2: After receiving the application form, the alliance group uses a preset verification mechanism to conduct a preliminary verification to confirm the authenticity of the IP address and the legality of the domain name, thereby preventing the addition of forged nodes.

[0027] In this embodiment, node identity can be asymmetrically encrypted. For example, consortium nodes can perform asymmetric encryption using an elliptic curve public-key cryptography algorithm on the node identity information that has passed preliminary verification. The node identity information includes key fields such as node ID, IP address, and hardware fingerprint. It should be noted that the asymmetric encryption method can be as follows: obtain the public key of the target node's valid elliptic curve public-key cryptography algorithm from the consortium root certificate chain; call the public key of the elliptic curve public-key cryptography algorithm to generate encrypted ciphertext: cipher_text=SM2_Encrypt(target_pubKey,node_info); replace the original plaintext information with the ciphertext identity information for subsequent digital signature processes. It should be noted that the private key of the elliptic curve public-key cryptography algorithm can be encrypted using AES-256-GCM and stored in the Hardware Security Module (HSM). Decryption requires activation with a physical key.

[0028] In this embodiment, the node identity needs to be verified during the initial verification. Since the node identity is encrypted in advance, the node identity information needs to be decrypted in advance before the initial verification to facilitate the initial verification.

[0029] S2.3: After initial verification, the alliance uses the root certificate to digitally sign the node information, generating member sub-certificates. This certificate contains node identity information, validity period, signature information, etc., ensuring the immutability of the information.

[0030] S2.4: The alliance will transmit the issued member sub-certificates to applying members via secure digital envelopes, thus ensuring information security during transmission. The digital envelope first encrypts the information using symmetric encryption to form a ciphertext message. Then, the symmetric encryption key is encapsulated using the recipient's public key to form a key ciphertext. This ciphertext message and key ciphertext are transmitted together to the recipient. The recipient first decrypts the digital envelope using their private key to obtain the symmetric key ciphertext, and then uses the symmetric key to decrypt the data. The symmetric key is generated by the node using a block cipher encryption module.

[0031] S2.5: Derivation of the formula for encryption / decryption using block cipher algorithms. It should be noted that the derivation of the encryption / decryption formulas using block cipher algorithms involves multiple basic components and steps such as nonlinear transformations, round functions, key expansion, and reverse order transformations, specifically: S2.5.1: The basic components of a block cipher include block length and key length. Both the block length and key length in block cipher algorithms are 128 bits. The main operations include box transformation, XOR operation, and shift transformation. Box transformation is a non-linear transformation that replaces each byte of the input by looking up a predefined S-box (Substitution Box). The S-box is a fixed byte substitution table that maps input bytes to output bytes. In block cipher algorithms, the S-box is a 16x16 matrix containing fixed byte substitution values. The XOR operation means: if the two values ​​involved in the operation are the same, the result is false (or 0); if the two values ​​are different, the result is true. Shift transformation is a simple encryption technique that encrypts text by shifting letters or numbers by a fixed number of bits.

[0032] S2.5.2: The input to the encryption / decryption process is 128 bits of plaintext data, represented as (X0, X1, X2, X3), where Xi is 32 bits of plaintext data. The output is 128 bits of ciphertext data. The encryption / decryption process requires 32 rounds of non-linear iteration, and each round can use a round function F. The input to the round function F is the first four 32-bit data (Xi, Xi+1, Xi+2, Xi+3) and the round key rki for the current round. For example, it could be: first, keep Xi unchanged, and XOR Xi+1, Xi+2, Xi+3 with the round key rki to obtain a 32-bit data, which is used as the input to the box transform. Then, the input to the box transform is split into four 8-bit data, and the box transform operation is performed on each of them. The outputs of the four box transforms (each output is still 8 bits) are combined into a 32-bit data, which is used as the input to the shift transform. Perform four circular left shift operations, shifting left by 2, 10, 18, and 24 bits respectively, resulting in four 32-bit results. XOR the shifted results, the box transformation output, and the first set of plaintext input Xi to obtain Xi+4. The input for key expansion is a 128-bit initial key, represented as (MK0, MK1, MK2, MK3). The output is the round key for 32 rounds (rki, i=0,1,...,31). In a specific example, the initial key is split into four 32-bit data segments and XORed with the system parameter FK to obtain the round keys (K0, K1, K2, K3). The fifth key is calculated using the first four keys (Ki, i=0,1,2,3), and this process is iterated 32 times to obtain the round keys for 32 rounds. After merging the four 32-bit data (X32, X33, X34, X35) generated by the round function F, a reverse transformation operation is performed to obtain the final 128-bit ciphertext data, namely (X35, X34, X33, X32).

[0033] S2.5.3: The decryption process is the same as the encryption process, except that the order of the keys used is reversed. That is, the first round uses the round key of round 32, the second round uses the round key of round 31, and so on.

[0034] In a specific example, the decryption process is described as follows: Taking the first round of encryption as an example, the box transformation input is: sboxinput = X1⊕X2⊕X3⊕rk0; the box transformation output is: sbox_output = S(each byte of sbox_input); the shift transformation input is: sbox_output; the shift transformation output is: y2, y10, y18, y24 (obtained by cyclically shifting left by 2, 10, 18, and 24 bits respectively); the first round output is: X4 = sbox_output⊕y2⊕y10⊕y18⊕y24⊕X0; the derivation process for subsequent rounds is similar, only the round keys and input data are different.

[0035] In summary, this embodiment implements the encryption and decryption of plaintext data. This lays the foundation for the encryption algorithm of the node admission method under a multi-factor authentication mechanism.

[0036] In this embodiment, dynamic real-time encryption deeply embeds block cipher algorithms into the dynamic communication layer of node access, achieving real-time encryption and tamper-proof transmission of data. By creating a hybrid architecture of elliptic curve public-key cryptography asymmetric encryption (key fields), cryptographic hashing to generate random perturbation factors, and block cipher symmetric encryption (batch data), and by optimizing the round function iteration (e.g., X4=sbox_output⊕y2⊕y10⊕y18⊕y24⊕X0, where ⊕ represents XOR operation) and the key expansion mechanism, throughput is significantly improved by 30%. Optional, also includes: After receiving the member's sub-certificate, the alliance node verifies the member's sub-certificate using the node's private key; After successful verification, the consortium node stores the root certificate, member sub-certificates, and node private key in the consortium node's node configuration file.

[0037] In this embodiment, the alliance node is a node of the alliance node.

[0038] In this embodiment, after submitting and signing the node information, the node is configured and the certificate is installed: S3.1: After receiving the member's sub-certificate, the consortium node first needs to verify the authenticity of the certificate, including verifying the signature and checking the certificate chain, to ensure that there has been no tampering. S3.2: After verification, the member must properly store the root certificate, member sub-certificates, and node private key in the node configuration file in the secure storage area of ​​the consortium node to prevent information leakage. S3.3: Update the consortium node's configuration file to ensure that the configuration information of the root certificate, member sub-certificates, and private key is correctly filled in, so that the node can automatically load these certificates and private keys at startup and run smoothly.

[0039] S130, the alliance will issue member sub-certificates to the alliance nodes applying to join via a secure digital envelope.

[0040] In this embodiment, before attempting to access the network, a requesting consortium node must proactively generate a message containing its own identity information and a random number for verification. At this time, the peer consortium node already possesses the member sub-certificate generated from the consortium blockchain network root certificate. The public key of the member sub-certificate can be used by the requesting consortium node to encrypt the random number and application information.

[0041] S140, when an access request is received from a consortium node, the consortium node on the other end reads the node table of the node management smart contract.

[0042] In this embodiment, after receiving the member sub-certificate, the alliance node generates an access request based on the member sub-certificate and sends the access request to the peer alliance node. The peer alliance node receives the access request submitted by the alliance node and reads the node table of the node management smart contract when it receives the access request.

[0043] In this embodiment, the governance rules of the blockchain system determine which nodes belong to the blockchain system. Each node is assigned a different name and public key. A chain administrator account (which may be one or more chain management accounts depending on the blockchain's consensus mechanism) registers the node information in the node table of the node management smart contract. This node table exists on every node and has the same state, so each node knows which nodes belong to the blockchain. The node service program reads the node table from the node management smart contract. Only nodes in this table can communicate with each other and share blockchain data. Nodes not in the table are prohibited from accessing the blockchain and cannot participate in its operation, thus ensuring the data security of the entire private and consortium blockchain.

[0044] In a specific example, such as Figure 3As shown, each node (e.g., node 1, node 2) has its own configuration file, which includes: the node name (each node has a unique name in the system, such as node1), the node's public key and private key (each node is assigned a public-private key pair for identification, encryption / signing; for example, the public key is used to authenticate requesting nodes, and the private key is stored with the corresponding node owner). The node table in the node management smart contract includes: the node name and the node public key. The node table records information about all legitimate nodes: each row corresponds to a node's "node name + node public key". Nodes in the system (e.g., node1, node2) verify each other's identities through the node table: each node first obtains its own key from the configuration file, and when communicating with other nodes, it queries the other party's public key through the "node table" to confirm that the other party is a legitimate node (preventing unauthorized nodes from accessing the system).

[0045] S150 If, simultaneously, the alliance node is in the node table of the node management smart contract, the total static security assessment coefficient of the alliance node is greater than the coefficient threshold, the alliance node passes the active verification, and the alliance node passes the passive verification, then the alliance group will connect the alliance node to the alliance chain network.

[0046] In this embodiment, the blockchain network consists of multiple nodes. Node admission is implemented using smart contracts. A system contract, namely the node management smart contract, is introduced into the blockchain system design. This system contract manages and records which nodes are present on the blockchain, i.e., the admitted nodes. The node management smart contract records the nodes on the blockchain through a node table.

[0047] In this embodiment, the node management smart contract serves as the decision-making center and execution engine for the entire access control method. It not only records information but also maintains a dynamic node table; all access decisions (allow / deny) are based on the query results of this contract. Furthermore, it can directly trigger and drive subsequent complex verification processes: when a new node requests access, the contract query is a prerequisite for initiating subsequent two-way verification of the encryption algorithm; the contract query acts as the switch to initiate encryption verification. The security assessment coefficient is a key input for the smart contract to make the final decision.

[0048] In a specific example, nodes adjust core data such as identity information, encrypting key fields (e.g., identity information, public key) using elliptic curve public-key cryptography, and generating hash values ​​and dynamic random numbers using cryptographic hashing algorithms to enhance process security. Specifically, hash value generation ensures data integrity, while dynamic random numbers prevent replay attacks. Symmetric encryption algorithms are used to efficiently encrypt batch communication data, establishing a secure channel. Encrypted data is used for security assessments and automated decision-making in smart contracts, ultimately leading to successful network access and secure access completion.

[0049] It should be noted that security verification between nodes is a crucial step in ensuring stable network operation.

[0050] In this embodiment, the security verification between nodes includes: determining whether a node is in the node table, whether the total static security assessment coefficient of a node is greater than the coefficient threshold, active verification, and passive verification.

[0051] The technical solution provided in this embodiment forms a closed loop of "verification-evaluation-decision", which solves the problem of dynamic trust and real-time risk control in a decentralized environment.

[0052] The technical solution provided in this embodiment redefines the role of smart contracts in node admission, elevating them from "storage tools" to the "control core" of the entire system. Through the specific design of "node-managed smart contracts," encryption algorithms, dynamic evaluation, and consensus mechanisms are organically integrated to form a closed-loop, automated, and highly reliable node admission system. This solves the problem of balancing decentralized trust, dynamic risk control, and efficient admission that cannot be addressed by a single technology.

[0053] Optional, also includes: Alliance nodes generate initial verification information.

[0054] The initial verification information includes: an initial random number and the identity information of the alliance node.

[0055] The alliance node uses the node public key in the member subcertificate to encrypt the initial verification information, thus obtaining the first ciphertext.

[0056] The consortium node uses its private key to sign the first ciphertext and sends the signed first ciphertext to the consortium node on the other end. Upon receiving the signed first ciphertext, the consortium node on the other end performs signature authentication based on its public key. If the authentication is successful, it decrypts the first ciphertext based on the private key of the consortium node on the other end to obtain the first random number and the identity information of the consortium node. If the first random number is the same as the initial random number, the active verification is successful.

[0057] In this embodiment, active verification and passive verification include the following steps: S4.1: Before attempting to access the network, a requesting consortium node needs to actively generate a message containing its own identity information and a random number, etc. At this time, the peer consortium node already possesses the member sub-certificate generated by the consortium blockchain network root certificate. The public key of the member sub-certificate can be called by the consortium node to encrypt the random number and application information. For example, the consortium node can use the peer consortium node's public key to encrypt the identity information and the random number; sign the encrypted ciphertext using the consortium node's private key, and finally send the ciphertext to the peer consortium node. S4.2: After receiving the verification information, the peer consortium node first verifies the integrity and signature of the message, then generates passive verification information based on the random number in the message, and encrypts and returns it to the consortium node. For example, after receiving the ciphertext, the peer consortium node uses the public key of the requesting consortium node to perform signature authentication; the peer consortium node uses the public key of the requesting consortium node to verify the signature of the ciphertext; and decrypts the ciphertext using the private key of the peer consortium node, then checks the identity information and random number of the consortium node. S4.3: After receiving the passive verification information, the consortium node performs the corresponding verification and calculation procedures. If the verification information generated by both parties is consistent, the handshake is successful, and both parties confirm that each other is a legitimate consortium node, thus completing secure access. For example, the peer consortium node uses its public key to encrypt the random number; and signs the ciphertext using its private key, then sends it to the consortium node; after receiving the ciphertext, the consortium node uses the public key of the peer consortium node to verify the signature; after successful verification, it decrypts the ciphertext using its private key; the decrypted random number is compared with the random number before sending, and if they match, the handshake is successful.

[0058] Optional, also includes: The peer consortium node generates target verification information based on the initial random number, the consortium node's identity information, and the timestamp.

[0059] In this embodiment, the method for generating target verification information based on an initial random number, identity information, and a timestamp can be as follows: the peer consortium node creates a temporary private key; the peer consortium node concatenates the initial random number and the temporary private key sequentially to obtain a second random number; the peer consortium node performs a hash calculation on the second random number using a cryptographic hash algorithm to obtain a perturbation factor; the peer consortium node performs a bitwise XOR operation on the initial random number and the perturbation factor to obtain a third random number; the peer consortium node generates target verification information based on the third random number, identity information, and timestamp.

[0060] The peer consortium node encrypts the target verification information based on the consortium node's public key to obtain the target ciphertext.

[0061] The peer consortium node generates a digital signature of the target ciphertext based on the peer consortium node's private key.

[0062] In this embodiment, the digital signature of the target ciphertext can be a digital signature generated based on an elliptic curve public key cryptography algorithm.

[0063] The consortium node at the other end generates passive verification information based on the target ciphertext and its digital signature.

[0064] In this embodiment, the passive verification information can be generated by combining the target ciphertext and its digital signature.

[0065] The peer consortium node performs passive verification on the consortium node based on passive verification information.

[0066] In a specific example, the peer consortium node receives the verification information from the consortium node and extracts the initial random number generated by the consortium node (e.g., 0x7A3D9F). The peer consortium node creates a temporary private key (example value: 0xB2E4C1); it concatenates the initial random number and the temporary private key sequentially (forming 0x7A3D9FB2E4C1), performs a hash calculation using a cryptographic hash algorithm, and outputs a 256-bit perturbation factor (example value: 0x8D5F2A...). It then performs a bitwise XOR operation on the initial random number and the perturbation factor to obtain an unpredictable new random number, for example, 0x7A3D9F⊕0x8D5F2A=0xF762B5, resulting in an unpredictable new random number (0xF762B5). A verification data packet is then constructed; Table 1 shows an example of a verification data packet. Table 1 Example of a verification data packet Using the public key of the consortium node, encrypt the data packet using a block cipher algorithm (output ciphertext such as 0x3A9E...D7F1). Using the private key of the consortium node on the other end, generate a signature on the ciphertext (example: 0x5C2B...9A4F). Combine the encrypted data (example value represented by 0x3A9E...D7F1) with the digital signature (example value represented by 0x5C2B...9A4F) and return it as passive verification information.

[0067] In another specific example, the process of generating the perturbation factor is as follows: Two fixed input sources are received: an initial random number and a temporary private key; these are sequentially concatenated to form an input stream. The input stream is hashed, and the output length is fixed at 256 bits (32 bytes). Even small changes in the input can lead to significant differences in the output. By using dual random sources to ensure unpredictability, and generating a unique perturbation factor with each interaction, the ability to effectively defend against replay attacks increases by an order of magnitude.

[0068] In this embodiment, by introducing a password hash algorithm to generate a dynamic perturbation factor, the random number of each verification interaction becomes unpredictable, significantly improving the security performance against replay attacks. Its interception effect is far superior to traditional verification schemes based on static certificates. This greatly enhances the secure access capability of nodes, achieving an order-of-magnitude improvement in anti-replay capability compared to traditional schemes.

[0069] In this embodiment, elliptic curve public-key cryptography (ECC) is responsible for encrypting and signing critical identity information, establishing the starting point for asymmetric trust. The cryptographic hash algorithm ensures data integrity by generating hashes; more importantly, it generates random perturbation factors, injecting dynamic randomness into the verification process, which is crucial for proactive defense. The symmetric encryption algorithm efficiently encrypts batch data transmissions, ensuring the security of the communication channel. These three algorithms are dynamically invoked according to the process stages, forming a secure pipeline of "asymmetric encryption (elliptic curve public-key cryptography) → hashing / randomization (cryptographic hashing) → symmetric encryption," achieving an optimal balance between security and performance.

[0070] Optional, also includes: The peer consortium node obtains relevant information about the consortium node, including: identity security information, environmental security information, and behavioral security information; The peer alliance node determines the total static security assessment coefficient of the alliance node based on identity security information, environmental security information, behavioral security information, identity security weight, environmental security weight, and behavioral security weight.

[0071] In this embodiment, to further enhance the security of node access, the consortium needs to develop a detailed security assessment standard, specifically including: S5.1: Setting standards for security assessment dimensions covering multiple aspects such as node identity authenticity, operating environment security, and network behavior security records, ensuring comprehensiveness and thoroughness. A technical breakdown diagram of the security assessment dimensions is shown below. Figure 4 As shown, in Figure 4In the static security assessment, the overall coefficient is related to identity authenticity, operational environment security, and network behavior security. Identity authenticity accounts for 40%, operational environment security for 30%, and network behavior security for 30%. It should be noted that identity authenticity is related to certificate chain validity and biometric binding; operational environment security is related to the Trusted Execution Environment (TEE), port exposure risks, and malicious process detection; and network behavior security is related to historical consensus compliance rate, abnormal packet entropy values, and neighbor node trust ratings. The assessment tools for the static security assessment's overall coefficient mainly include the following three types: automated scanning: Nessus port detection, TPM / TEE hardware certification; manual review: security policy configuration checklist; and third-party reports: security audits by commercial cryptography testing centers. S5.2: For nodes applying to join, the alliance nodes will systematically collect relevant information and conduct item-by-item reviews according to established assessment standards to ensure the security of each applying alliance node. S5.3: During the evaluation process, the consortium can employ various technical means (such as automated scanning, manual review, and third-party security reports) for cross-validation to improve the accuracy and objectivity of the evaluation results. S5.4: A security evaluation coefficient is calculated based on the comprehensive evaluation results and compared with a preset threshold. If the evaluation coefficient is greater than the threshold, the node is considered to have high security.

[0072] Specifically, the static security assessment coefficient calculation model is as follows: Static security assessment total coefficient = (identity authenticity score × 0.4) + (operational environment security score × 0.3) + (network behavior security score × 0.3). Where: identity authenticity score = certificate chain validity verification result × 0.7 + biometric matching degree × 0.3; operation environment security score = min(TEE status, port exposure risk value, malicious process detection score). Network behavior security score = 100 - Σ(abnormal behavior count × weight factor). Weight factor: if there is data tampering, the weight factor is 10; if there is consensus violation, the weight factor is 5; if there is communication delay, the weight factor is 2. The alliance node admission judgment rules are as follows: if the static security assessment total coefficient ≥ 85, it passes; if the static security assessment total coefficient is between [70, 85), a second assessment is required; if the static security assessment total coefficient < 70, it is rejected. S5.5: Create a new dynamic adjustment algorithm for the weight of the total security assessment coefficient. When the certificate chain verification score is greater than 90, the weight of the identity authentication dimension increases from 40% to 45%. In order to keep the total weight unchanged at 100%, the basic weight of the behavioral security dimension decreases from 30% to 25%.

[0073] The behavioral dimension itself contains a dynamic decay factor (such as penalty points for violations), providing redundant space for weight adjustment. Table 2 shows an example of the adjusted weight structure. Table 2. Example of adjusted weight structure It should be noted that when the identity weight is increased, the behavior weight is simultaneously decreased.

[0074] Example verification: In a financial consortium blockchain test: bank node certificate chain verification = 95 points (greater than 90); identity weight: 40% → 45%; behavior weight: 30% → 25%; original static security assessment total coefficient = 95 × 0.4 + 85 × 0.3 + 70 × 0.3 = 84.5. Since 84.5 is between [70, 85), a secondary assessment is required.

[0075] The new static security assessment total coefficient = 95 × 0.45 + 85 × 0.3 + 70 × 0.25 = 85.75, which is passing. The static security assessment total coefficient increases by 1.25 points (85.75 - 84.5 = 1.25), allowing for a faster pass to the admission threshold (85 points), thus accelerating the admission of high-trust alliance nodes. For example, the environment score of 85 points in the example could be: Min(TEE status score 95, port risk value 90, virus protection score 85), taking the minimum of the three based on the weakest link principle, which is 85 points.

[0076] The technical solution provided in this embodiment can equally reduce all dimensions, weaken the environmental security baseline, lock the environmental weight, and adjust only behavior. By coupling and adjusting identity and behavior weights, it can achieve rapid access for highly trustworthy nodes while maintaining hard environmental security standards, thus optimizing the operational efficiency of the consortium blockchain.

[0077] In this embodiment, a dynamic weight adjustment algorithm (such as identity weight from 40% to 45%) is used to optimize the admission decision in real time, thereby improving the admission efficiency of high-trust nodes by 300% (second-level response).

[0078] In a specific example, such as Figure 5 As shown, the applicant node is the consortium node applying to join. Its information includes: node name, root certificate, member certificate (initially empty), and public key. The end node is a legitimate node already existing in the system (the consortium node on the other end, such as node1). The end node holds its own root certificate, member certificate, and public key. The node table is a list of legitimate nodes in the system, recording the "node name, root certificate, member certificate, and public key" of all nodes (e.g., node1 corresponds to root certificate, member child certificate 1, and public key 1). The applicant node obtains the public key of the end node (e.g., node1) (by retrieving "public key N" from the node information table); the end node obtains the applicant node's public key ("public key 0"). Both parties use each other's public key (combined with a random number) to generate ciphertext S, achieving secure key negotiation or data transmission; simultaneously, they verify each other's legitimate identity (ensuring it is a node within the system) using the root certificate and member certificate in the "node information table."

[0079] In this embodiment, a new dynamic weight adjustment security coefficient evaluation algorithm and method are established, and detailed security evaluation standards are formulated, covering multiple dimensions such as node identity authenticity, operating environment security, and network behavior security records. Node identity authenticity can be determined using a dynamic weight coupling mechanism, operating environment security can be determined using a minimum function based on the bottleneck effect, and the weight factor for network behavior security records can be a real-time decay factor. Various technical means such as automated scanning, manual review, and third-party security reports can be used for evaluation to ensure the accuracy and objectivity of the evaluation results. The weight values ​​are dynamically adjusted, and a comprehensive security evaluation coefficient is calculated based on the evaluation score, and compared with a preset threshold to determine whether a node meets the admission criteria.

[0080] In this embodiment, the verification result serves as the evaluation input, and the evaluation result, in turn, influences the verification strategy, thus achieving a leap from "one-time verification" to "continuous trust".

[0081] Optional, also includes: The chain administrator's node sends a registration transaction to the node management smart contract, requesting to add the target node to the node table of the node management smart contract; After receiving a registration request, the node management smart contract executes the node management smart contract and registers the target node's node name and node public key in the node table.

[0082] In this embodiment, each node requires a configuration file containing its configuration information, including: node name, public / private key pair, and the address of the target node. The public key identifies the node and is publicly available. The private key is stored locally and is confidential information that cannot be disclosed. Both the public and private keys are used during the authentication process. The target node's address is the IP address, domain name, and port of the node the node needs to connect to. The working process of blockchain node access control based on smart contracts is as follows: S6.1: The chain administrator, based on the blockchain governance rules, determines which nodes constitute the entire blockchain system and assigns each node a node name and key pair. The private key of the key is kept by each node. The node name and node private key are placed in the configuration file of the corresponding node. Then, the administrator uses their administrator account to send a registration transaction to the node management smart contract, requesting the addition of a new node (node ​​name: nodem, node public key) to the node table of the node management smart contract. After all nodes' node management smart contracts accept and execute the request, all nodes' node tables will have the same node table record. If multiple nodes need to register, multiple registration node transaction requests can be sent.

[0083] S6.2: After receiving the registration request, the chain administrator's node executes the node management smart contract to register the new node nodem's information (node ​​name and public key) in the node table.

[0084] S6.3: Place the new node m information (node ​​name nodem, public / private key) into node m's configuration file and specify the address of the target node n to be connected. Then, start node m. At this time, node m sends an access request to node n, which needs to carry node m's own node information (node ​​name nodem and public key).

[0085] S6.4: Node n receives an access request from node m, reads the node table of the node management smart contract, and checks whether node m's information (node ​​name and node public key) is in the node table. If not, access is rejected. If it is in the table, the identity of both parties is verified, which can be done using a challenge-and-response method similar to the SSL / TLS protocol. a) Authentication request: Node n wants to verify the identity of node m, so it sends a random challenge or request to the user.

[0086] b) Digital Signature Generation: Node m uses a hash algorithm to hash the challenge string to obtain a digital digest, and then digitally signs the digital digest with its private key. The digital signature is an encrypted result of the private key, used to prove that the data comes from the private key holder and has not been tampered with.

[0087] c) Sending digital signature: Node m sends the digital signature and digital digest to node n.

[0088] d) Verification process: After receiving the digital signature and digest, node n first reads the public key of node m in the node management smart contract node table, uses this public key to decrypt the digital signature, and thus obtains the digital digest generated by node m. Then, it recalculates the digest of the original challenge using the same hash algorithm and compares it with the decrypted digital signature digest.

[0089] e) Compare the digests: If the two digests are the same, then node n can confirm that the digital signature was generated by the private key holder node m and that the data has not been tampered with. Thus, node m's authentication is successful.

[0090] S6.5: If authentication is successful, accept the access request and establish a connection channel between nodes.

[0091] S6.6: Nodes can begin data communication and enter normal working state.

[0092] In this embodiment, a pipeline architecture is created that uses elliptic curve public key cryptography to encrypt key data, a cryptographic hash algorithm to generate random factors, and block ciphers to encrypt batch communication, thereby achieving end-to-end compliance and performance optimization.

[0093] In a specific example, such as Figure 6 As shown, the alliance group is the authority manager, responsible for receiving access requests from new nodes. Node n is an existing legitimate node in the alliance group, acting as the "executor of the access process." The node management smart contract is a "trust list" storing information on all legitimate nodes, including node name and node public key (divided into an "old node table" and an updated "new node table"). New node is an alliance node to be added to the alliance group. The entire joining process is divided into two stages: preliminary preparation and node interaction. Stage 1 includes: A1. The management account initiates a "add new node" request to the node management smart contract, which includes the new node's information (node ​​name, public key). A2. Node n reads the "new node's access parameters" from the node management smart contract (confirming that the new node has been marked as legitimate by the contract). Stage 2 includes: A3. Node n sends an "access request" to the new node (carrying its own certificate and public key, used by the new node to verify its legitimacy). A4. Both parties execute a "mutual verification process" (verifying each other's public key and identity through the node table in the node management smart contract). A5. After successful verification, the new node successfully accesses the system. A6. Node n synchronizes the system's basic data with the new node, completing the initialization of the new node.

[0094] This embodiment provides a consortium node admission method based on encryption algorithms and smart contracts with multiple verification mechanisms. A system contract (node ​​management smart contract) and a node table are established to manage the admitted nodes. This embodiment creates a decentralized, multi-layered dynamic verification system. This system is not a simple aggregation of processes, but a proactive defense system driven by smart contracts, deeply integrated with encryption algorithms, and incorporating dynamic random challenges for sustainable evaluation.

[0095] In this embodiment, smart contracts serve as the rule execution engine of the system, replacing traditional centralized institutions and realizing decentralized automatic scheduling and final arbitration of the verification process.

[0096] In this embodiment, a multi-factor verification mechanism is introduced, including a rigorous submission and signing process for node information, and dual confirmation through both active and passive verification, comprehensively ensuring the authenticity of node identities and the validity of network access requests. Existing consensus nodes vote on or confirm network access applications that pass the security assessment, ensuring that the joining process of new nodes complies with the rules of the consortium blockchain network. Dual random number liveness verification enables dynamic updates of the security coefficient on a minute-by-minute basis. Root certificate sharding management is implemented through smart contract consensus admission (voting by more than 2 / 3 of the nodes).

[0097] In this embodiment, the alliance group determines the root certificate through alliance consensus. After receiving node information submitted by alliance nodes, the alliance group signs the node information using the root certificate to generate a member sub-certificate. The alliance group transmits the issued member sub-certificate to the alliance node applying to join via a secure digital envelope. When receiving an access request from an alliance node, the peer alliance node reads the node table of the node management smart contract. If, simultaneously, the alliance node's static security assessment total coefficient in the node management smart contract's node table is greater than the coefficient threshold, the alliance node passes both active and passive verification, and the alliance group connects the alliance node to the consortium blockchain network. This consortium node admission method based on smart contract multi-verification improves the security and reliability of node admission by introducing a multi-verification mechanism and a dynamic evaluation system, ensuring the stable operation of the consortium blockchain network. Furthermore, the admission process is fully automated, requiring no manual intervention and is extremely efficient.

[0098] Example 2 Figure 7 A schematic diagram of an electronic device 10 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0099] like Figure 7 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0100] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0101] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as the control methods for consortium node admission.

[0102] In some embodiments, the consortium node admission control method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the consortium node admission control method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the consortium node admission control method by any other suitable means (e.g., by means of firmware).

[0103] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0104] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0105] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0106] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0107] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0108] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0109] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0110] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the consortium node admission control method according to any embodiment of the invention.

[0111] In implementing the computer program product, computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0112] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for controlling admission to alliance nodes, characterized in that, include: The alliance group determines the root certificate through alliance consensus; After receiving the node information submitted by the alliance node, the alliance group signs the node information through the root certificate and generates member sub-certificates. The alliance will issue member sub-certificates and transmit them to the alliance nodes applying to join via secure digital envelopes. When an access request is received from a consortium node, the consortium node reads the node table of the node management smart contract, wherein the access request is generated based on the member sub-certificate; If, simultaneously, the alliance node is listed in the node table of the node management smart contract, the total static security assessment coefficient of the alliance node is greater than the coefficient threshold, the alliance node passes both active and passive verification, then the alliance group will connect the alliance node to the alliance blockchain network.

2. The method according to claim 1, characterized in that, Also includes: After receiving the member's sub-certificate, the alliance node verifies the member's sub-certificate using the node's private key; After successful verification, the consortium node stores the root certificate, member sub-certificates, and node private key in the consortium node's node configuration file.

3. The method according to claim 1, characterized in that, Also includes: The alliance node generates initial verification information, which includes: an initial random number and the identity information of the alliance node; The consortium node uses the node's public key in the member's subcertificate to encrypt the initial verification information, thus obtaining the first ciphertext; The alliance node uses its private key to sign the first ciphertext and sends the signed first ciphertext to the peer alliance node. Upon receiving the signed first ciphertext, the peer alliance node performs signature authentication based on its public key. If the authentication is successful, the peer alliance node decrypts the first ciphertext based on its private key to obtain a first random number and the alliance node's identity information. If the first random number is the same as the initial random number, the alliance group determines that the alliance node's active verification has passed.

4. The method according to claim 3, characterized in that, Also includes: The peer consortium node generates target verification information based on the initial random number, the consortium node's identity information, and the timestamp; The peer consortium node encrypts the target verification information based on the consortium node's public key to obtain the target ciphertext; The peer consortium node generates a digital signature of the target ciphertext based on the peer consortium node's private key. The consortium node at the other end generates passive verification information based on the target ciphertext and the digital signature of the target ciphertext; The peer consortium node performs passive verification on the consortium node based on passive verification information.

5. The method according to claim 4, characterized in that, The peer consortium node generates target verification information based on an initial random number, the consortium node's identity information, and a timestamp, including: The peer consortium node creates a temporary private key; The consortium node at the other end concatenates the initial random number with the temporary private key in sequence to obtain the second random number; The consortium node at the other end performs a hash calculation on the second random number using a cryptographic hash algorithm to obtain the perturbation factor; The alliance node at the other end performs a bitwise XOR operation between the initial random number and the perturbation factor to obtain the third random number; The alliance node at the other end generates target verification information based on the third random number, the identity information of the alliance node, and the timestamp.

6. The method according to claim 1, characterized in that, Also includes: The peer consortium node obtains relevant information about the consortium node, including: identity security information, environmental security information, and behavioral security information; The peer alliance node determines the total static security assessment coefficient of the alliance node based on identity security information, environmental security information, behavioral security information, identity security weight, environmental security weight, and behavioral security weight.

7. The method according to claim 1, characterized in that, Also includes: The chain administrator's node sends a registration transaction to the node management smart contract, requesting to add the target node to the node table of the node management smart contract; After receiving a registration request, the node management smart contract executes the node management smart contract and registers the target node's node name and node public key in the node table.

8. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the control method for alliance node admission as described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the control method for admitting alliance nodes as described in any one of claims 1-7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the control method for admission of alliance nodes according to any one of claims 1-7.

Images