A network node control method, system and consensus node based on blockchain

Abstract

This application provides a blockchain-based network node control method, system, and consensus node, relating to the field of computer technology. This method can periodically update the trust value of each network node and use blockchain to ensure the consistency of the trust value list, thereby enabling mutual trust between different network operators and ensuring the unlinkability of network node pseudonyms and the validity of trust assessments. This allows different network operators to collaboratively manage network node pseudonyms and corresponding trust values, and to share information by publishing an "inter-domain pseudonym, trust value" list via blockchain to assist in inter-domain network decision-making, enabling network operators to provide high-quality network services and enhance user experience.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a blockchain-based network node control method, system, and consensus node. Background Art

[0002] Due to their openness, heterogeneity, and fragility, today's networks face various security threats. Understanding the trust status of a network can help network nodes make informed decisions to mitigate potential threats, such as implementing trusted routing through trust-based verification. Therefore, node trust should be assessed and shared across the network. Many trust assessment systems employ centralized architectures to assess trust. However, these systems suffer from the drawback of a single point of failure. Summary of the Invention

[0003] In order to achieve the above-mentioned technical objectives, the present application provides a network node control method, system, consensus node, computer-readable storage medium and computer program product, provides a trust evaluation method for inter-domain network nodes, realizes mutual trust between consensus nodes in different networks, and realizes global anonymous trust evaluation and sharing.

[0004] In the first aspect, a network node control method based on blockchain is provided, wherein the blockchain includes a first consensus node and a second consensus node, the first consensus node corresponds to a first server in a first network, the second consensus node corresponds to a second server in a second network, and the first network and the second network each include at least one network node; the method includes: the first consensus node obtains a first block, the first block includes a first target list, the first target list includes a first target virtual identifier and a first target trust value corresponding to each network node in the first network and the second network, wherein the first target virtual identifier is used to characterize the identity of the network node, the first target virtual identifier is different from the real identity identifier of the network node, and is determined by the first target virtual identifier. A consensus node and a second consensus node are obtained based on the real identity of the network node. A first target trust value is used to represent the trust level of the network node in its network. When a first preset condition is met, the first consensus node updates the trust value of each network node in the first target list to obtain a second target list, and generates a second block based on the second target list, wherein the second block includes the second target list. The first consensus node sends the second block to the second consensus node for verification. The first consensus node receives a first message sent by the second consensus node and stores the second block in the blockchain, wherein the first message indicates that the verification of the second block has passed. Thus, after one consensus node updates the trust value of a network node, another consensus node verifies the updated trust value using the blockchain's PBFT consensus mechanism, thereby ensuring the consistency of the managed list and achieving decentralized list management. This allows mutual trust between consensus nodes, thereby achieving global anonymous trust evaluation and sharing. Furthermore, each consensus node can record the updated list, so that the network nodes corresponding to each consensus node can verify the trust value and make decisions by accessing the blockchain.

[0005] In one possible implementation, the first consensus node obtains the first block, specifically including: the first consensus node determines a first initial list, the first initial list includes the real identity identifier of each network node and the first trust value corresponding to each network node, the first trust value is obtained by the first consensus node and / or the second consensus node encrypting the trust value corresponding to each network node in the first target list; the first consensus node encrypts the real identity identifier of each network node based on the first key to obtain the first virtual identifier corresponding to each network node, and decrypts the first trust value corresponding to each network node based on the second key to obtain the second trust value corresponding to each network node, wherein each first virtual identifier and each The second trust value corresponding to the first virtual identifier constitutes a second initial list; the first consensus node sends the second initial list to the second consensus node, so that the second consensus node encrypts the first virtual identifier corresponding to each network node based on the third key to obtain the first target virtual identifier, and decrypts the second trust value corresponding to each network node based on the fourth key to obtain the first target trust value corresponding to each network node, wherein each first target virtual identifier and the first target trust value corresponding to each first target virtual identifier constitute a first target list; the first consensus node obtains the first target list sent by the second consensus node, generates a first block based on the first target list, and stores the first block in the blockchain. Thus, different consensus nodes generate target lists through a verifiable shuffling algorithm, so that different consensus nodes can trust each other.

[0006] In one possible implementation, the first consensus node updates each network node in the first target list to obtain the second target list, specifically including: the first consensus node obtains behavior data of each network node within a preset time period;

[0007] The first consensus node determines the second target trust value for each network node based on the corresponding behavioral data of each network node, a preset time decay coefficient, and the first target trust value for each network node. The first consensus node updates the first target trust value in the first target list to the second target trust value, thereby obtaining a second target list. Thus, when updating the trust value of a network node, the time decay coefficient is used as a calculation parameter, avoiding errors caused by time decay and improving the accuracy of trust value calculation.

[0008] In a possible implementation, the method further includes: when the second preset condition is met, the first consensus node updates the trust values ​​corresponding to at least two network nodes in each network node in the second target list to a third target trust value to obtain a third target list; the first consensus node obtains a third initial list based on the third target list, the third initial list includes the real identity identifier and the third trust value corresponding to each network node, and the third trust value is obtained based on the first consensus node and / or the second consensus node encrypting the trust value corresponding to each network node in the third target list; the first consensus node encrypts the real identity identifier of each network node based on the fifth key to obtain the second virtual identifier corresponding to each network node, and decrypts the trust value corresponding to each network node in the third target list based on the sixth key to obtain the real identity identifier of each network node. The first consensus node sends the third initial list to the second consensus node, so that the second consensus node encrypts the second virtual identifier corresponding to each network node based on the seventh key to obtain the second target virtual identifier, and decrypts the trust value corresponding to each network node in the third initial list based on the eighth key to obtain the fourth target trust value corresponding to each network node, wherein each second target virtual identifier and each fourth target trust value constitute the fourth target list, and at least two trust values ​​of each fourth target trust value are the same as the third target trust value; the first consensus node obtains the fourth target list sent by the second consensus node, and generates a third block based on the fourth target list, and stores the third block in the blockchain. Thus, when certain conditions are met, the trust value is obfuscated and the virtual identifier is updated, thereby preventing attackers from tracking the activities of network nodes for a long time and improving the security of the network. It is understandable that the second target virtual identifier is different from the first target virtual identifier.

[0009] In one possible implementation, the first consensus node updates the trust values ​​corresponding to at least two network nodes in the second target list to a third target trust value. Specifically, the first consensus node determines a target interval to which the trust values ​​corresponding to the at least two network nodes belong, uses the lower limit of the target interval as the third target trust value, and updates the trust values ​​corresponding to the at least two network nodes to the third target trust value. Thus, trust obfuscation is performed by updating the trust values ​​of at least two network nodes to the same trust value, thereby enhancing the unlinkability between the pseudonyms (i.e., virtual identifiers) and trust values ​​in the list and improving security.

[0010] In one possible implementation, before the first consensus node updates the trust values ​​corresponding to at least two network nodes in the second target list to the third target trust value, the first consensus node further includes: re-determining the trust value of each network node based on a preset time decay coefficient and the trust value of each network node in the second target list. Thus, the trust value of each network node is re-evaluated before trust confusion occurs, thereby reducing the impact of time decay on the trust value and improving data security.

[0011] In a second aspect, a blockchain-based network node control method is provided, wherein the blockchain includes a first consensus node and a second consensus node, the first consensus node corresponds to a first server in a first network, the second consensus node corresponds to a second server in a second network, and the first network and the second network each include at least one network node; the method includes: the second consensus node obtains a second block sent by the first consensus node, the second block includes a second target list, the second target list is obtained by the first consensus node updating the trust value of each network node in the first target list contained in the first block when a first preset condition is met, the first target list includes a first target virtual identifier and a first target trust value corresponding to each network node in the first network and the second network, wherein the first target virtual identifier is used to represent the identity of the network node, the first target virtual identifier is different from the real identity identifier of the network node, and is obtained by the first consensus node and the second consensus node based on the real identity identifier of the network node, and the first target trust value is used to represent the degree of trust of the network node in the network in which it is located; the second consensus node verifies the second block, and when the verification passes, sends a first message to the first consensus node, the first message is used to indicate that the verification of the second block has passed.

[0012] In one possible implementation, before the second consensus node obtains the second block sent by the first consensus node, it also includes: the second consensus node obtains the second initial list sent by the first consensus node, the second initial list includes the first virtual identifier and the second trust value of each network node, the first virtual identifier is obtained by the first consensus node encrypting the real identity identifier of the network node in the first initial list based on the first key, and the second trust value is obtained by the first consensus node decrypting the first trust value corresponding to the network node in the first initial list based on the second key, the first initial list includes the real identity identifier of each network node and the first trust value corresponding to each network node, the first trust value is obtained by encrypting the trust value corresponding to each network node in the first target list by the first consensus node and / or the second consensus node; the second consensus node encrypts the first virtual identifier corresponding to each network node based on the third key to obtain the first target virtual identifier, and decrypts the second trust value corresponding to each network node based on the fourth key to obtain the first target trust value corresponding to each network node, wherein each first target virtual identifier and the first target trust value corresponding to each first target virtual identifier constitute the first target list; the second consensus node sends the first target list to the first consensus node.

[0013] In a possible implementation, the method further includes: the second consensus node obtains a third initial list sent by the first consensus node, the third initial list includes a second virtual identifier and a fourth trust value corresponding to each network node, the second virtual identifier is obtained by the first consensus node encrypting the real identity identifier of the network node based on the fifth key, the fourth trust value is obtained by the first consensus node decrypting the third trust value corresponding to the network node in the third target list based on the sixth key, the third target list includes the real identity identifier and the third trust value corresponding to each network node, the third trust value is obtained by encrypting the trust value corresponding to each network node in the third target list based on the first consensus node and / or the second consensus node, wherein the third target list is the first consensus node when the second preset condition is met, the second virtual identifier is obtained by the first consensus node encrypting the second virtual identifier of the network node based on the fifth key, the fourth trust value is obtained by the first consensus node encrypting the second virtual identifier of the network node based on the sixth key, The trust values ​​corresponding to at least two network nodes in each network node in the target list are updated to the third target trust value; the second consensus node encrypts the second virtual identifier corresponding to each network node based on the seventh key to obtain the second target virtual identifier, and decrypts the trust value corresponding to each network node in the third initial list based on the eighth key to obtain the fourth target trust value corresponding to each network node, wherein each second target virtual identifier and each fourth target trust value constitute a fourth target list, and at least two trust values ​​in each fourth target trust value are the same as the third target trust value; the second consensus node sends the fourth target list to the first consensus node, so that the first consensus node generates a third block based on the fourth target list, and stores the third block in the blockchain.

[0014] In a third aspect, a device control method is provided, which is applied to a first device. The method includes: the first device obtains a target virtual identifier corresponding to the first device based on a target block in the blockchain, where the target block is a second block obtained based on the first aspect or the second aspect; the first device sends a target message to the second device, where the target message includes a target virtual identifier and a target signature, where the target signature is obtained by the first device signing the target message based on its own private key. In this way, when the first device communicates with the second device, the first device can obtain its corresponding pseudonym (i.e., virtual identifier) ​​from the block of the blockchain and carry the pseudonym in the message it sends, so that after the second device obtains the message sent by the first device, it can verify the message based on the pseudonym and then conduct business activities based on the trust value of the device in the block.

[0015] In a fourth aspect, a device control method is provided, which is applied to a second device. The method includes: the second device obtains a target message sent by the first device, the target message including a target virtual identifier and a target signature, the target virtual identifier is the virtual identifier of the first device, and is obtained by the first device based on the target block in the blockchain, the target block is the second block obtained based on the first aspect or the second aspect, and the target signature is obtained by the first device signing the target message based on its own private key; the second device verifies the target signature using the target pseudonym, and after the verification passes, obtains the target trust value corresponding to the target pseudonym from the blockchain using the target pseudonym, and performs business activities based on the target trust value. Exemplarily, the second device can use the target pseudonym to verify the target signature contained in the target message using the ElGamal algorithm.

[0016] In the fifth aspect, a device control apparatus is provided, comprising at least one memory for storing programs; and at least one processor for executing the programs stored in the memory. When the program stored in the memory is executed, the processor is used to execute the method provided in the third aspect, or the method provided in the fourth aspect.

[0017] In the sixth aspect, a consensus node is provided, comprising: at least one memory for storing programs; and at least one processor for executing the programs stored in the memory. When the program stored in the memory is executed, the processor is used to execute the method provided in the first aspect, or to execute the method provided in the second aspect.

[0018] In the seventh aspect, a computer-readable storage medium is provided, which stores a computer program. When the computer program runs on an electronic device, the electronic device executes the method provided in the first aspect, or the method provided in the second aspect, or the method provided in the third aspect, or the method provided in the fourth aspect.

[0019] In the eighth aspect, a computer program product is provided. When the computer program product is run on an electronic device, the electronic device executes the method provided in the first aspect, or the method provided in the second aspect, or the method provided in the third aspect, or the method provided in the fourth aspect.

[0020] It can be understood that the beneficial effects of the second to eighth aspects can be found in the relevant descriptions of the first or third aspects, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 is a schematic diagram of a hybrid network with two anonymous servers and three network nodes provided by an embodiment of the present application;

[0022] Figure 2a This is a schematic diagram of an application scenario of an inter-domain network provided by an embodiment of the present application;

[0023] Figure 2b is a schematic diagram of another application scenario of an inter-domain network in an embodiment of the present application;

[0024] Figure 3 This is a schematic diagram of an architecture for inter-domain pseudonym and trust maintenance provided by an embodiment of the present application;

[0025] Figure 4 This is a flowchart of a blockchain-based network node control method provided in an embodiment of the present application;

[0026] Figure 5 This is a schematic diagram of the structure of a chip provided in an embodiment of the present application. DETAILED DESCRIPTION

[0027] The terms used in the following embodiments are only for the purpose of describing specific embodiments and are not intended to be limiting of the present application. As used in the specification and appended claims of the present application, the singular expressions "one", "a kind of", "said", "above", "the" and "this" are intended to also include expressions such as "one or more", unless there is a clear contrary indication in the context. It should also be understood that in the following embodiments of the present application, "at least one", "one or more" refer to one or more (including two). The term "and / or" is used to describe the association relationship of associated objects, indicating that three relationships can exist; for example, A and / or B can represent: the existence of A alone, the existence of A and B at the same time, and the existence of B alone, where A and B can be singular or plural. The character " / " generally indicates that the related objects before and after are in an "or" relationship.

[0028] References to "one embodiment" or "some embodiments" etc. described in this specification mean that a particular feature, structure or characteristic described in conjunction with the embodiment is included in one or more embodiments of the present application. Thus, the phrases "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. appearing in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized. The term "connected" includes direct and indirect connections, unless otherwise stated.

[0029] In the following, the terms "first" and "second" are used for descriptive purposes only and should not be understood to indicate or imply relative importance or implicitly specify the quantity of the technical features indicated. Therefore, a feature specified as "first" or "second" may explicitly or implicitly include one or more of the features.

[0030] In the embodiments of this application, words such as "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of this application should not be interpreted as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplarily" or "for example" is intended to present the relevant concepts in a concrete manner.

[0031] Generally, trust assessment systems monitor the network activity of nodes associated with their identities to assess their trustworthiness. However, when nodes use long-term identities for network activity, privacy disclosure may occur. Dynamically updated pseudonyms can be used to prevent attackers from tracking a node's network activity based on its identity. However, such trust assessment systems have drawbacks, such as inaccurate assessments caused by pseudonym changes and unlinkability caused by linking trust values ​​before and after the pseudonym change. To ensure both accurate assessments and unlinkability, some trust assessment systems use a trusted execution environment (TEE) to maintain node pseudonyms and trust values. However, TEEs have potential security vulnerabilities, such as side-channel attacks. Some solutions use a trusted third party to manage pseudonyms and trust values, but such a trusted third party may not exist in practice. Other systems use a non-collusive entity to manage node pseudonyms and trust values ​​within a single network. However, the assumption of the existence of such a non-collusive entity may be unreasonable within a single network. Furthermore, most related research focuses on single networks and fails to consider how to support converged or heterogeneous networks containing multiple trust domains.

[0032] Fifth-generation mobile communication technology (5G) enables the interconnection of everything, including various IoT devices, such as vehicles and drones in the Internet of Vehicles (IoV). Mobile IoT devices may roam beyond their carrier's boundaries and connect to other carriers, engaging in cross-domain behavior. When roaming devices connect to their new service carrier, the service carrier, which does not trust them (zero trust), requires verification. Therefore, knowing their inter-domain trust value will help the service carrier implement appropriate security defense adjustments and trust-based cross-domain routing. Malicious network devices within a domain may not cross domains. Evaluating and publishing their trust values ​​can aid in decision-making within the domain, such as trust-based routing and security defense adjustments. With the commercialization of 5G, 6G is envisioned as a large-scale heterogeneous network that integrates different types of networks or subnetworks, such as cellular networks, the Internet, ocean networks, and integrated space-ground networks. Therefore, we anticipate being able to evaluate and publish the intra-domain and inter-domain trust values ​​of network devices within converged networks (6G).

[0033] The standards developed by the Third Generation Partnership Project (3GPP) also address the protection of the long-term international mobile subscriber number (IMSI) of network devices, specifically ensuring identity privacy. There are two ways to obtain the IMSI: an attacker can obtain the IMSI by gaining access to the victim's network channel; or an attacker can disguise themselves as the serving network (SN) and mutually authenticate with the victim device to obtain the IMSI. Methods for protecting the IMSI of a user equipment (UE) when it accesses a serving network primarily utilize public key cryptography, root-key cryptography, identity-based encryption (IBE), and pseudonyms.

[0034] Among them, the IMSI method based on public key encryption mainly includes three methods: (1) Using a global trust root to create a trust chain, allowing the SN to display the certificate to the network device to be connected. After the network device verifies the certificate, it sends the IMSI ciphertext to the SN, and the SN can decrypt and obtain the IMSI for verification. (2) The SN obtains the certificate from the network device's native network (HN) in advance. When the network device accesses, it submits the HN public key so that the SN can locally search for the certificate distributed by the HN; the SN displays the found certificate to the network device, and the network device verifies and encrypts the IMSI to the SN for verification. (3) The HN distributes the SN certificate that the network device may access to the network device in advance. The network device uses the SN public key to encrypt the IMSI to the SN for verification. For method (1), it is difficult to establish a global trust root in a converged network. For method (2), when the SN does not store the certificate distributed by the HN of a certain network device, it means that the network device is locked. For (3), cross-domain behavior is common in a converged network, and the network device may store a large number of certificates. In the root-key encryption method, the network device uses the HN's public key to encrypt the IMSI and send it to the SN. The SN sends the ciphertext to the HN for decryption, and the HN returns the IMSI and verification vector (AV). However, this method requires interaction between the SN and HN every time a network device is connected, which may cause delays.

[0035] In IBE-based methods, it is generally assumed that a secret key generator (PKG) uses the recipient's public and private key pair to calculate the recipient's public and private keys. This allows network devices and SNs to authenticate each other through encryption and signing. However, the PKG can decrypt all ciphertext messages from network devices and SNs, making its trust level too high.

[0036] In the pseudonym-based approach, the HN securely assigns a new pseudonym to the network device. The network device then uses the pseudonym to connect to the SN. The SN then sends an encrypted request for verification to the HN, which then returns a verification vector (AV). However, this approach requires interaction between the SN and the HN once the network device connects, increasing network latency.

[0037] In a converged network, different network operators do not trust each other. In cross-domain scenarios, we expect network nodes to provide their trust values ​​to the roaming network while maintaining node anonymity. When network nodes perform cross-domain network activities, we expect attackers to be unable to track their network activities through their identities, i.e., activity unlinkability. In such a converged network, using a trusted third party to manage the pseudonyms and trust values ​​of all nodes is not feasible, as it is difficult to find such an entity that is fully trusted by all network domains. The use of TEEs also has potential vulnerabilities. Therefore, in the case of mutual distrust among network operators, it is possible to facilitate collaborative management of node pseudonyms and trust values ​​in the converged network under untrusted circumstances among different network operators. The goal of network operator collaboration is to ensure the effectiveness of trust assessment while protecting node identity privacy, especially in cross-domain networks.

[0038] Even if different network operators can collaborate, they may use different trust data for trust assessment, ultimately resulting in them storing and managing different node pseudonyms and trust values. Therefore, effectively ensuring consistency in node pseudonyms and trust values ​​across mutually distrusting operators in a converged network becomes a challenge.

[0039] To address the conflict between trust assessment and identity privacy protection, this solution proposes a method for managing pseudonyms and trust values ​​for network nodes in converged networks (or 6G). In inter-domain networks, network operators collaborate to manage network node pseudonyms and corresponding trust values ​​without relying on a trusted third party to provide high-quality network services. Furthermore, this solution ensures the unlinkability of node pseudonyms and the validity of trust assessments through trust obfuscation and pseudonym updates. After trust assessment and trust obfuscation and pseudonym updates, blockchain is used to ensure the consistency of the trust value list. Furthermore, an inter-domain pseudonym, trust value list is published on the blockchain to share information and assist in decision-making within the inter-domain network. In intra-domain networks, since intra-domain network nodes trust the local network operator, who is responsible for managing the local list of intra-domain pseudonyms, trust values, including trust value updates and list maintenance, the local list provides trust verification for the intra-domain network.

[0040] This solution mainly uses two technologies: verifiable shuffling technology (hereinafter referred to as "Algorithm 1") and Byzantine fault tolerance technology (hereinafter referred to as "Algorithm 2"), which are now introduced as follows:

[0041] (1) Verifiable Shuffling Technology

[0042] The purpose of a mixnet is to make communications difficult to track using multiple anonymous servers. These servers take a list as input; encrypt, decrypt, and permute the list entries; and output a new list. A mixnet ensures that elements in the input list and the output list are unlinkable. The mixnet's shuffling operations primarily include encryption, decryption, and permutation.

[0043] For example, Figure 1 As shown, in list L0, the first column consists of the long-term public key of the network node Composition, where x i It is a network node NE i The second column of L0 consists of the ciphertext of the trust value of the corresponding NE The ciphertext is composed of the long-term secret key z selected by the anonymous server. j Trust value plaintext TV i Encrypted. During the shuffle, anonymous server 1 uses the selected temporary e1 to encrypt the first column of list L0 to obtain Decryption To obtain And perturb the rows of the list containing the encryption and decryption results. Then, it sends the list it created to the next anonymous server 2 for shuffling. Among them, g1 and g2 have been published. Finally, the first column of the output list L2 contains the pseudonyms of all NEs, The second column consists of the corresponding trust values ​​TV i π(i) is the position of the i-th NE in L2.

[0044] To ensure the correctness of shuffling, many verifiable shuffling schemes have been proposed. In these schemes, the anonymous server should usually generate a zero-knowledge proof of the shuffle so that anyone can check whether the shuffle (i.e., encryption, decryption, and permutation) is performed correctly. Algorithm 1 details a verifiable shuffle operation sh(L j-1 ,g j-1 ,e j ,z j ), and then it sends the generated result to the next anonymous server j+1 for shuffling. The generated result includes a proof pf j , to convince anyone that the shuffling is performed correctly. The proof needs to be constructed according to the specific encryption algorithm. If m anonymous servers complete the shuffling, then the final output list L m The elements in the first column are the pseudonyms of the i-th NE, The TV element in the second column i The i-th NE uses the published To calculate its pseudonym and use this pseudonym for network activities. In particular, the i-th NE can use its private key x i and a randomly selected number k to sign the message M, (r = g m k ,s=(H(M)-x i r)k -1 ). Anyone can check g m H(M) =pk π(i) r r s to verify the signature.

[0045] For ease of understanding, the following example describes the verifiable shuffle operation sh(L j-1 ,g j-1 ,e j ,z j As shown in Table 1, in the verifiable shuffle operation sh(L j-1 ,g j-1 ,e j ,z j ), the input is: e j ,z j ,L j-1 , pf j-1 ; Output: L j ,g j ,pf j The execution process is as follows: the anonymous server j receives the proof pf j-1 After that, the proof pf j-1 After verification, use e j Encrypt the received list L j-1 The first element of Then, for L j-1 Decrypt the second column elements to obtain Next, replace the rows of the result list to get a new list L j ;calculate And create a proof pf j , to prove that the above operation is correct. Finally, return L j ,g j ,pf j , and ends.

[0046] Table 1

[0047]

[0048] (2) Byzantine Fault Tolerance Technology

[0049] The consensus mechanism in Practical Byzantine Fault Tolerance (PBFT) mainly includes the stages of block creation, pre-prepare, prepare, and commit.

[0050] The block creation phase primarily involves the next block creator (leader) being confirmed to be responsible for packaging the next block. The pre-preparation phase primarily involves the master node (leader) sending the created block to all consensus nodes. During the preparation phase, consensus nodes first validate the block upon receiving it, then generate and broadcast a prepare message to all consensus nodes. Once a consensus node receives at least 2f (the system consists of 3f + 1 consensus nodes) consistent and valid prepare messages, it prepares to enter the confirmation phase. During the commit phase, when a consensus node begins entering the commit phase, it generates a commit message and announces it to all consensus nodes. Simultaneously, it receives commit messages from other consensus nodes. Once a consensus node receives at least 2f consistent and valid commit messages, it considers the commit phase complete and saves the corresponding block as the next block in the blockchain. Throughout this process, if a non-leader consensus node detects malicious behavior by the leader, such as producing invalid blocks or timing out, it will trigger a view switch to re-elect a new leader.

[0051] For example, this solution provides a method for managing node pseudonyms and trust values. This method utilizes cryptographic techniques (such as verifiable shuffling) to securely manage the pseudonyms and trust values ​​of all nodes in a converged network while ensuring they are unlinkable. This method can be used in both intra-domain and inter-domain trust assessment systems.

[0052] In an intra-domain network, network nodes can trust the local operator agent because they are in the same trusted domain. Therefore, the local operator agent is responsible for evaluating intra-domain node trust and managing intra-domain node pseudonyms and trust values. First, the agent creates an intra-domain list containing <intra-domain pseudonym, trust value> pairs based on the network node's long-term public key. Each network node then obtains public information from the agent to calculate its intra-domain pseudonym and uses this pseudonym for intra-domain network activities. The data collector perceives trust-related data of the network nodes connected to it and shares this data with the agent. After receiving the intra-domain trust data, the agent evaluates the intra-domain trust of each network node and updates the intra-domain trust value list. After several rounds of trust evaluation, the agent re-evaluates the trust of each pseudonym in the list based on time decay and maintains the list through trust obfuscation and pseudonym updates to ensure unlinkability of intra-domain activities.

[0053] In an inter-domain network, operator agents from different networks collaboratively maintain a trust list consisting of <inter-domain pseudonym, trust value> pairs. These operator agents reach blockchain consensus on this list, generated using a verifiable shuffle, to produce the genesis block. In the verifiable shuffle, node pseudonyms appear in the form of ciphertext, which is collaboratively generated by all operator agents using selected ephemeral or temporary keys to encrypt the corresponding node's long-term public key. After reaching consensus on the genesis block, each network node accesses public information from the blockchain to calculate its inter-domain pseudonym and uses this pseudonym for cross-domain network activities. The trust values ​​of nodes in the list are then updated in real time based on their network behavior.

[0054] Furthermore, in the inter-domain network, data collectors can perceive inter-domain trust data and share it to a public cloud storage server. With authorized access to this data, an operator agent (the leader in the PBFT consensus mechanism) evaluates the inter-domain trust of each node and shares the evaluation results with other operator agents through the blocks it creates for verification. Furthermore, the leader agent acts as the next block creator, generating and publishing a block that includes the updated inter-domain trust list with the evaluation results. Other operator agents participate in the PBFT consensus mechanism to verify this block and include it as the next block in the blockchain. Therefore, after each round of inter-domain trust evaluation, the operator agent updates the trust values ​​corresponding to the pseudonyms in the inter-domain list. To prevent attackers from tracking a node's cross-domain activities based on its cross-domain pseudonym, the pseudonym should be changed after several rounds of inter-domain trust evaluation. Each operator agent needs to re-evaluate the trust of each pseudonym in the trust list based on the next block in the backed-up blockchain, using time decay. This obfuscates the trust values ​​to prevent attackers from tracking the old and new pseudonyms of a node through trust value analysis (thus violating unlinkability). After trust obfuscation, the operator agent performs a reverse shuffle operation to obtain a ciphertext list containing the node's long-term public key and obfuscated trust value. The operator agent then uses the newly selected temporary key to encrypt the node's long-term public key via a forward shuffle to update the pseudonym. This creates a new list containing the new pseudonym and obfuscated trust value. After generating the new list, each operator agent should create a block containing this list and treat it as the next block in the blockchain. Each network node can then access public information from the blockchain to calculate its new pseudonym and use it for cross-domain network activities. Inter-domain trust values ​​are then updated based on the behavior corresponding to the new pseudonym.

[0055] For example, Figure 2aThe following illustrates an application scenario of an inter-domain network according to an embodiment of the present application. In this scenario, at least two networks, namely, network 100 and network 200, and cloud server 300, may be included. Network 100 may include four entities, namely, network node (NE) 110, access point (AP) 120, and operator agent (OA) 130; network 200 may also include four entities, namely, NE 210, AP 220, and OA 230.

[0056] In network 100, NE 110 can use pseudonyms to connect to AP 120 to conduct activities, particularly cross-domain activities. NE 110 may engage in malicious behavior and is untrustworthy. In a converged network, trust needs to be assessed and shared to aid decision-making among other network entities. For example, NEs include mobile phones, computers, and other terminal devices.

[0057] In network 100, APs 120 can monitor connected NEs 110. Acting as data collection nodes, APs 120 can share perceived intra-domain trust data for each NE with OAs 130 to assist OAs 130 in subsequent intra-domain trust assessments. They can also share cross-domain trust data with the converged network's shared cloud server 300 for subsequent cross-domain trust assessments. For example, the security status of APs 120 can be checked by OAs 130 or even other OAs, for example, via software-defined networking. For example, APs can include base stations, etc.

[0058] In network 100, OA 130 is deployed by the network operator. It is responsible for evaluating the trust of NEs within a domain (e.g., NE 110 in network 100) and / or NEs between domains (e.g., NE 210 in network 200) based on trust data from AP 120 or server 130; managing a list of <pseudonyms, trust values> for all NEs; and participating in the PBFT consensus mechanism. OA 130 is trusted within its network or domain, but is not trusted by OAs in other domains (e.g., OA 230). Exemplarily, there is at least one OA that does not collude with OAs in other domains. In one example, the operator proxy OA can also be referred to as an operator server.

[0059] The cloud server 300, which may also be referred to as a cloud service provider (CSP), may be, but is not limited to, a cloud located on the Internet or a common cloud of a converged network. It may collect cross-domain trust data provided by different APs (such as AP110 and / or AP210, etc.) from different domains; it allows OAs (such as OA130 and / or OA230) to obtain cross-domain trust data for cross-domain trust evaluation. Exemplarily, the cloud server 300 may honestly execute a predetermined protocol, for example, being interested in sensitive information of each NE, such as real identity, pseudonyms of tracking nodes, or network behavior. In one example, the cloud server 300 may also be referred to as a cloud server.

[0060] It can be understood that the functions or roles of NE210 in network 200 are similar to those of NE110 in network 100, the functions or roles of AP220 in network 200 are similar to those of AP120 in network 100, and the functions or roles of OA230 in network 200 are similar to those of OA130 in network 100. For details, please refer to the description of NE110, AP120 and OA130 in network 100, which will not be repeated here.

[0061] In one example, each network entity in the network may possess a long-term public-private key pair. The network entities in the network may include one or more of a network node (NE), an access node (AP), an operator agent (OA), etc. Furthermore, the server 130 may also possess a long-term public-private key pair.

[0062] In one example, the network 100 can also communicate with the network 200. For example, the OA 130 in the network 100 can communicate with the AO 230 in the network 200.

[0063] For example, Figure 2b This section illustrates another inter-domain network application scenario for an embodiment of the present application. This scenario includes three networks: a cellular mobile communications network, a space-ground integrated network, and the Internet. Each network can include three network entities: network nodes (NEs), access points (APs), and operator proxy APs. Furthermore, the Internet can also include cloud service providers. Each network can communicate with each other.

[0064] For example, Figure 3 A schematic diagram of the architecture for inter-domain pseudonym and trust maintenance is shown. Figure 3 In the example, operator A can Figure 2a For example, the operator of the network 100 shown in FIG. 1 , the blockchain consensus node 1 may be Figure 2a In the network 100 shown in FIG, the operator agent OA130, the data collection node 1 can be Figure 2aIn the network 100 shown in FIG, the access point AP120, the device 1 can be Figure 2a The network node 110 in the network 100 shown in FIG; operator B can be Figure 2a The operator of the network 200 shown in FIG, the blockchain consensus node 2 may be Figure 2a In the network 200 shown in FIG, the operator agent OA230, the data collection node 2 can be Figure 2a In the access point AP220 of the network 200 shown in FIG, the device 2 may be Figure 2a The network node 210 in the network 200 shown in FIG; the data storage node 1 may be Figure 2a The cloud server 300 shown in FIG. Figure 3 In the data collection node 1, the data collection node 1 can sense (also called "acquire") the behavior data of device 1 and upload the sensed data to the data storage node 1. The data collection node 2 can sense (also called "acquire") the behavior data of device 2 and upload the sensed data to the data storage node 1. The blockchain consensus node 1 and / or the blockchain consensus node 2 can obtain the behavior data of device 1 or device 2 from the data storage node 1, and can be responsible for the generation and maintenance of the pseudonym and trust value of device 1 and / or device 2, as well as for reaching a consensus between the blockchain nodes; wherein, after the two reach a consensus, at least one block can be generated, which can contain the correspondence between the pseudonym and the trust value, that is, the <pseudonym, trust value> list. Device 1 and / or device 2 each has a pair of public and private keys (PK i ,SK i ),PK i It is the permanent identity ID of the device. Both can obtain a pseudonym from the block and use the pseudonym to conduct network activities.

[0065] Next, the method for managing pseudonyms and trust values ​​in inter-domain networks provided by this solution is introduced.

[0066] Pseudonym and trust value management in inter-domain networks can include inter-domain list generation, trust value update & inter-domain consensus, and inter-domain list maintenance. During inter-domain list generation, operator agents OAs in different domains collaboratively generate lists to store inter-domain <pseudonym, trust value> pairs through verifiable shuffling. During trust value update & inter-domain consensus, the operator agent OA can perform trust evaluation based on sufficient cross-domain trust data regularly shared by access points APs, only update the trust values ​​in the inter-domain list, and reach consensus on the updated list. After the K2 round of consensus, the operator agent OA can maintain the inter-domain list by trust obfuscation and updating the pseudonyms based on verifiable shuffling to ensure the unlinkability of the pseudonyms, that is, perform inter-domain list maintenance.

[0067] The following describes the inter-domain list generation, trust value update & inter-domain consensus, and inter-domain list maintenance. It can be assumed that each NE in each network has registered and has its own public and private key pair. And all operator agents OA know the long-term public key y of each NE i Each operator agent OA holds its own public and private key pair In addition, at least one operator acting on behalf of the OA will not collude with other operator acting on behalf of the OA.

[0068] (1) Inter-domain list generation

[0069] Inter-domain list generation may include: initial list L0 generation and target list L m generate.

[0070] a) Initial list L0 generation

[0071] m operator agents OA create a list of public keys of n network nodes NE <pseudonym, trust value>, where each network node NE is equipped with a public-private key pair i=1,…n. Different operator agents OA can collaborate to use their respective long-term keys z j To encrypt the initial trust value, for example, the initial trust value (TV) of each network node NE can be pre-set, for example, the initial trust value TV i =0.01.

[0072] In order to avoid the encryption result not being TV i = 0.01, each OA can be required to publish a message to prove that its encryption operation is correct, which can be regarded as a verifiable shuffle variant of the encryption operation only. ID can refer to a pseudonym, and TV can refer to a trust value. In the initial list L0, the pseudonym can be the public key of the network node NE, and the trust value can be the initial trust value TV obtained by using the public keys of m OAs in a pre-set encryption order. i Encrypted, the obtained

[0073] Table 2

[0074]

[0075] In one example, at least one of the m operator agents OA can use the public keys of the m OAs to encrypt the initial trust value TV in sequence based on a pre-set encryption order. i Encrypt and get And send the obtained result to OA1.

[0076] b) Target list L m generate

[0077] Combine Figure 1 , and according to Algorithm 1, OA1 selects a temporary random number e1 and executes sh(L0,g0,e1,z1) to obtain the results L1,g1 and pf1, where g0=g. OA1 broadcasts L1,g1,pf1 and a signature After receiving the information from OA1, OA2 verifies the signature and proof pf1, and executes sh(L1,g1,e2,z2) to obtain the results L2,g2 and pf2. Similarly, OA2 broadcasts its results and signature, and so on, until the above process reaches OA m OA m Verify the received signature and certificate, execute sh(L m-1 ,g m-1 ,e m ,z m ) to obtain the pk π(i) ,TV π(i) >,i=1,…,n list L m , and pf m π(i) is the pseudonym of the i-th NE in the list L m Finally, OA m Announcement L m , g m and pf m In order to publicly verify the shuffle. Anyone (including OA) can check the correctness of the shuffle. Since at least one OA will not collude with other OAs, the attacker cannot link L0 to L m It can be understood that g is a record of the global parameter e, which is mainly used to record the random number e of each OA, for example,

[0078] After verifying the correctness of the shuffle, each OA can calculate L m and g m The root of the constructed Merkle tree. Afterwards, at least one of the OAs can convert the root, L m and g m Packed into a block, this block is considered the genesis block of the blockchain. The i-th NE uses its private key x i and g obtained from the blockchain m Calculate its pseudonym And check the pk by accessing the blockchain π(i) In L mIf it exists, the i-th NE can use this pseudonym to carry out cross-domain network activities; if it does not exist, the i-th NE cannot use this pseudonym to carry out cross-domain network activities.

[0079] (2) Trust value update & inter-domain consensus

[0080] a) Trust value update

[0081] The operator agent OA can evaluate and update the trust value of each NE in real time or periodically. OA can evaluate and update the trust value of each NE in real time or periodically based on the trust data of each NE provided by AP and stored in the server and the trust data of each NE in the latest updated L m Trust value recorded in Calculate the new trust value of each NE.

[0082] In one example, a new trust value of each NE can be calculated based on a preset behavior template. For example, behavior template P = {P N ,P A}, which can be used to evaluate the trust value of the monitored network node. N is a normal behavior template set, P A is an abnormal behavior template set. For the behavior feature set B of the i-th network node, B = {B1,…,B I}, if there is I in the behavior feature set B N Behavioral characteristics and P N Template matching in , and I A Behavior and P A The template matches in , then the trust value of the network node is:

[0083]

[0084] Among them, u π(i) Is the serial number of the last evaluated block in the blockchain. A is the number of normal behaviors, I N is the number of abnormal behaviors, k is a constant, u is the serial number of the block currently under trust evaluation, τ is the parameter that controls time decay, is the trust value of the i-th NE obtained in the last evaluation.

[0085] After obtaining the new trust value, OA can list the target L m The old trust value of each NE in is replaced by the new trust value.

[0086] b) Inter-domain consensus

[0087] Based on the PBFT consensus mechanism, the operator agent OA can reach consensus on the trust evaluation and the updated trust value list. The inter-domain consensus based on PBFT can be divided into the block creation, PrePrepare, Prepare and Commit stages.

[0088] Block production phase: This phase is primarily completed by the Leader consensus node (i.e., the master node). As shown in Table 3, Algorithm 2 illustrates the process of block production by the Leader consensus node. For example, the consensus node can be understood as an operator agent (OA).

[0089] Table 3

[0090]

[0091] In one example, after other consensus nodes receive the block published by the Leader consensus node, they can obtain the trust data TD by accessing the cloud service provider. i (i=1,...,n d ), and calculate the trust evaluation result, and compare the calculated trust evaluation result with the list L m The trust results in the list L are consistent, thereby confirming m Update correctness and correctness of block content.

[0092] PrePrepare phase: In this phase, the Leader consensus node can send the blocks it creates to all consensus nodes.

[0093] Prepare phase: If a consensus node receives a block, it first needs to complete the block verification, then generate and broadcast a Prepare message to all consensus nodes. When a consensus node receives more than 2f (the system contains 3f + 1 = m consensus nodes) consistent and valid Prepare messages, the consensus node is ready to enter the Commit phase.

[0094] Commit Phase: When a consensus node enters the Commit Phase, it generates a Commit message and announces it to all consensus nodes. Simultaneously, the consensus node receives Commit messages from other consensus nodes. Once a consensus node receives more than 2f valid and consistent Commit messages, it considers the Commit Phase complete and saves the corresponding block as the next block in the blockchain.

[0095] Similarly, when a consensus node detects malicious behavior or timeout from a Leader consensus node, it will initiate a viewchange mechanism to reselect a new Leader consensus node.

[0096] (3) Inter-domain list maintenance

[0097] After several rounds of trust evaluation and consensus (e.g., K rounds), the old list can be maintained and modified to prevent attackers from tracking the activities of network nodes for extended periods of time. Between these rounds, only the trust values ​​of network nodes can be updated, without updating their pseudonyms. The reason for not maintaining the old list after every trust evaluation round is to ensure the efficiency of the entire network system. However, K can be set to 1 to ensure the highest degree of unlinkability.

[0098] Inter-domain list maintenance can include three phases: trust obfuscation, pseudonym update, and new list addition. Each phase is described below.

[0099] Trust obfuscation: At this stage, when the old list needs to be maintained, if only the pseudonym of the old list is changed, an attacker may be able to link the two pseudonyms of a network node in the new and old lists through trust value analysis, which undermines the privacy of the network node and the goal of list maintenance.

[0100] In one example, when the probability of at least two pseudonyms in the old list having the same trust value is high, it can make it difficult for an attacker to successfully track the NE's network activity or pseudonyms over a long period of time by analyzing the NE's trust value. Therefore, trust obfuscation can be considered to increase this probability and thus enhance unlinkability.

[0101] Specifically, before trust confusion, due to time decay, the trust value of each network node NE can be re-evaluated:

[0102]

[0103] in, is the trust value of the i-th NE in the old list, u π(i) is the serial number of the last evaluated block in the blockchain, u is the serial number of the block currently being trusted, and τ is the parameter that controls time decay.

[0104] After updating the trust value of each NE according to time decay, trust obfuscation can be performed to enhance the unlinkability of new and old pseudonyms.

[0105] As a possible implementation, at least one interval can be pre-set. When the number of trust values ​​of network nodes NE falling within a certain interval exceeds a preset value, all or most of the trust values ​​in the interval can be adjusted to the same trust value. This ensures that at least two pseudonyms in the list have the same trust value, making it difficult for an attacker to successfully track the network activities or pseudonyms of the NE over a long period of time by analyzing the trust value of the NE. In addition, when the number of trust values ​​of network nodes NE falling within a certain interval does not reach a preset value, the range of the interval can be adjusted so that the number of trust values ​​of network nodes NE falling within the interval reaches the preset value.

[0106] For example, it is assumed that the preset trust value range is from 0 to 1. If xN TV ≥TV π(i) >(x-1)N TV , then all OAs calculate and change TV π(i) =(x-1)N TV , to achieve trust confusion. Among them, N TV is a new unit greater than the trust value unit (e.g., 0.01), and x is an integer. Therefore, after trust obfuscation, the probability that a pseudonym has the same trust value as other pseudonyms increases. Although some trust values ​​and pseudonyms in the list after trust obfuscation may still have a one-to-one correspondence, after multiple rounds of maintenance, the probability that an attacker can always successfully track the NE is significantly reduced, almost to zero.

[0107] It is understandable that in order to quantify the ability of trust obfuscation, we can assume that the trust value of the network node NE follows a Gaussian distribution and consider an extreme case. Before trust obfuscation, the number of pseudonyms with trust values ​​ranging from 0.09 to 1 is expected to be where n is the number of pseudonyms in the list to be maintained and p(t) is the probability density function of the Gaussian distribution. After trust obfuscation, the new expectation is because Anonymity is enhanced. By adjusting N TV To ensure Anonymity can be achieved. After trust confusion, some trust values ​​and pseudonyms in the list may still have a one-to-one correspondence with a very small probability. According to K-anonymity, the probability of tracking a pseudonym is After the R round of maintenance, the probability that the attacker can always track the pseudonym of NE is Therefore, when N TVIf and R are large enough, p will tend to 0, implying that it will be difficult for an attacker to break the unlinkability of pseudonyms or network activities. We reduce the precision of the trust value to achieve stronger unlinkability. It is worth noting that similar results can be obtained when the trust value follows other distributions, because the integration interval becomes larger after trust obfuscation.

[0108] Pseudonym Update: After trust obfuscation, OA can reverse execute the target list L on the obfuscated trust list m Generate to obtain a list containing each NE long-term public key and the corresponding trust value ciphertext To update the pseudonym of each NE, the OA can choose a new temporary private key Then execute the target list L m Generate to get a new list The new list It consists of a new pseudonym and an obfuscated trust value.

[0109] New list added: When each OA gets a new list and new OA can add it to the blockchain. and The Merkle tree root is composed of the hash value of the previous block, the serial number of this block, the Merkle tree root, The block is packaged with the signature of the block content into a block, which is regarded by OA as the next block of the blockchain.

[0110] Therefore, network nodes can share trust values ​​when roaming between different operators, while effectively protecting user privacy and preventing attackers from obtaining the user's real identity through the trust value.

[0111] Compared with related technologies, this solution uses blockchain technology, avoiding the difficulties faced by related technologies, such as obtaining a trusted third party and using TEE to protect user privacy, which may lead to side-channel attacks. At the same time, by using trust value obfuscation, it also prevents attackers from tracking users through the continuity of trust values.

[0112] The above is a method for managing pseudonyms and trust values ​​in inter-domain networks. This method can also be applied to pseudonym and trust value management in intra-domain networks. The details are as follows:

[0113] In intra-domain management, the local operator agent OA creates a list by shuffling to record the intra-domain <pseudonym, trust value> pairs. This process is called intra-domain list generation. Then, the local operator agent OA performs an intra-domain trust value update. Based on the intra-domain trust data provided by the access point AP regularly (for example, every 10 minutes), the local operator agent OA performs a trust evaluation and only updates the trust values ​​of the network nodes in the intra-domain list based on the evaluation results. After K1 rounds of trust value updates, the local operator agent OA can maintain the list. The local operator agent OA can update the intra-domain pseudonyms of network nodes through trust confusion and shuffle-based pseudonym updates. This stage can be called intra-domain list maintenance. These stages are introduced below.

[0114] (1) Generate a list within the domain

[0115] a) Initial list L0 generation

[0116] Since the local operator agent OA in the domain is trustworthy, the local operator agent OA can directly generate the list. The local operator agent OA can create a list of <pseudonym, trust value> involving n local network nodes. The local operator agent OA can use its own long-term key z to encrypt the initial trust value of each network node NE, such as the TV of each NE. i =0.01, and we get E z (TV i ). After that, the local operator agent OA constructs a <y i ,E z (TV i )>,i=1,…,ncomposed of list L0.

[0117] b) Target list L1 generation

[0118] The local operator agent OA can randomly select a short random number e and execute Algorithm 1 to obtain and publish the result L1, g1 = g e Because the local operator agent OA is considered to be trusted within the domain, there is no need for the local operator agent OA to create and publish a message proving the correct operation.

[0119] Similarly, each network node NE can use its private key and the published g1 to calculate its pseudonym and check whether its pseudonym exists in the list. It can then use the pseudonym to conduct intra-domain network activities.

[0120] (2) Trust value update

[0121] The local operator agent OA may perform trust evaluation based on the trust data related to the local network node NE provided by the local AP, and update the trust value of the network node in L1 based on the corresponding pseudonym.

[0122] In one example, a new trust value of each NE can be calculated based on a preset behavior template. For example, behavior template P = {P N ,P A}, which can be used to evaluate the trust value of the monitored network node. N is a normal behavior template set, R A is an abnormal behavior template set. For the behavior feature set B of the i-th network node, B = {B1,…,B I}, if there is I in the behavior feature set B N Behavioral characteristics and P N Template matching in , and I A Behavior and P A The template matches in , then the trust value of the network node is:

[0123]

[0124] Among them, T π(i) Is the time of the last trust evaluation. A is the number of normal behaviors, I N is the number of abnormal behaviors, k is a constant, T is the time of the current trust evaluation, τ is the parameter that controls time decay, is the trust value of the i-th NE obtained in the last evaluation.

[0125] After obtaining the new trust value, OA may replace the old trust value of each NE in the target list L1 with the new trust value.

[0126] (3) Domain list maintenance

[0127] After several rounds of trust evaluation, the local operator agent OA can maintain the list to prevent attackers from tracking network nodes for a long time. Since the trust value decays over time, the local operator agent OA can re-evaluate the trust value of each NE in the list and perform trust obfuscation. Then, the target list L1 generation is reversed on the trust obfuscated list to obtain a list containing the NE's public key and the corresponding trust value ciphertext. Then, the local operator agent OA selects a temporary random number e new , by performing target list L1 generation to update the pseudonym, the process obtains and new list Contains new pseudonyms and obfuscated trust values. Local operator agent OA release and NE can be used Calculate its pseudonym and check Does pk exist in π(i) To conduct network activities within the domain.

[0128] Therefore, when network nodes conduct network activities between the same operator, they can effectively protect the user's privacy and prevent attackers from obtaining the user's real identity through the trust value.

[0129] Based on the above description, this solution has at least the following advantages:

[0130] (1) Decentralization

[0131] This solution allows operator agents to collaboratively manage pseudonym-trust value lists across domains without relying on any fully trusted third party. Each agent's operations, such as shuffling, trust evaluation, trust obfuscation, and pseudonym updates, can be verified by other agents through the blockchain's PBFT consensus mechanism, ensuring the consistency of the managed lists and achieving decentralized list management.

[0132] (2) Sharing of credible information

[0133] Applying blockchain to inter-domain networks, all operator agents store and record a new list of pseudonyms and trust values ​​on the blockchain. This information is publicly accessible, allowing network nodes to verify trust values ​​and make decisions, such as trusted routing, by accessing the blockchain. In intra-domain networks, local operator agents manage a list of pseudonyms and trust values, allowing intra-domain network nodes to access it. This enables trusted information sharing within both intra-domain and inter-domain networks.

[0134] (3) Privacy protection

[0135] This solution allows network nodes to use pseudonyms instead of their real identities in network activities within and between domains. By using pseudonyms, anonymous trust evaluation can be achieved. At the same time, the present invention can also ensure that pseudonyms or activities are unlinkable.

[0136] (4) Application in converged networks

[0137] The operator agents of each network collaborate to maintain a list containing pseudonyms and corresponding trust values. Specifically, when network nodes engage in cross-domain behavior, collaboration between operator agents can resolve issues caused by distrust between network domains, thereby achieving global anonymous trust evaluation and sharing.

[0138] Next, based on the pseudonym and trust value management method for network nodes described above, a blockchain-based network node control method provided by an embodiment of the present application is introduced. It can be understood that this method is another way of expressing the pseudonym and trust value management method for network nodes described above, and the two are combined. This method is proposed based on the pseudonym and trust value management method for network nodes described above. Part or all of the content of this method can be found in the description of the pseudonym and trust value management method for network nodes above.

[0139] See also Figure 4 , Figure 4 This is a flow chart of a network node control method based on blockchain provided by an embodiment of the present application. It is understood that the method can be executed by any device, equipment, platform, or device cluster with computing and processing capabilities. In this method, the blockchain includes a first consensus node and a second consensus node, wherein the first consensus node corresponds to a first server in a first network, and the second consensus node corresponds to a second server in a second network, and each of the first network and the second network includes at least one network node. For example, the first network can be Figure 2a As shown in the network 100, the second network can be Figure 2a In the network 200 shown in FIG, the first consensus node (ie, the first server) can be Figure 2a The operator agent OA130 shown in FIG, the second consensus node (ie, the second server) can be Figure 2a The operator agent OA230 shown in .

[0140] like Figure 4 As shown, the blockchain-based network node control method may include the following steps:

[0141] S401. The first consensus node obtains a first block, which includes a first target list. The first target list includes a first target virtual identifier and a first target trust value corresponding to each network node in the first network and the second network, wherein the first target virtual identifier is used to characterize the identity of the network node. The first target virtual identifier is different from the real identity identifier of the network node and is obtained by the first consensus node and the second consensus node based on the real identity identifier of the network node. The first target trust value is used to characterize the degree of trust of the network node in the network in which it is located.

[0142] Specifically, the first consensus node can obtain the first block from the blockchain. The first block can be the first block in the blockchain, that is, the genesis block, or the block previously generated by the first consensus node, or the block generated by the second consensus node.

[0143] In one example, the first block includes a first target list, and the first target list includes the first target virtual identifier and the first target trust value corresponding to each network node in the first network and the second network, wherein the first target virtual identifier is used to characterize the identity of the network node, and the first target virtual identifier is different from the real identity identifier of the network node, and is obtained by the first consensus node and the second consensus node based on the real identity identifier of the network node, and the first target trust value is used to characterize the degree of trust of the network node in the network in which it is located. Among them, the first target list can be, but is not limited to, generated by the first consensus node and the second consensus node based on the verifiable shuffling algorithm described above (i.e., Algorithm 1). Exemplarily, the first target list can be the target list L described above. m Exemplarily, the first target virtual identifier may be the pseudonym of the network node described above, and the real identity identifier of the network node may be the public key of the network node, etc.

[0144] In one example, when acquiring the first block, the first consensus node may determine a first initial list, which includes the real identity identifiers of each network node and the first trust value corresponding to each network node. The first trust value is obtained by encrypting the trust value corresponding to each network node in the first target list by the first consensus node and / or the second consensus node. Exemplarily, the first initial list may be the initial list L0 described above, and the real identity identifier of the network node may be the public key of the network node. The first trust value corresponding to each network node may be obtained by encrypting the initial trust value of each network node using the public keys of the first consensus node and the second consensus node in sequence based on a pre-set encryption order. Exemplarily, the public key of the first consensus node may be The public key of the second consensus node can be The initial trust value of each network node is TV i , then the first trust value of each network node is

[0145] Then, the first consensus node and the second consensus node can process the first initial list based on the verifiable shuffling algorithm to obtain the first target list. Specifically, the first consensus node can encrypt the real identity identifier of each network node based on the first key to obtain the first virtual identifier corresponding to each network node, and decrypt the first trust value corresponding to each network node based on the second key to obtain the second trust value corresponding to each network node, wherein each first virtual identifier and the second trust value corresponding to each first virtual identifier constitute the second initial list. Exemplarily, the first key can be a temporary random number generated by the first consensus node. Exemplarily, the second key can also be a temporary random number generated by the first consensus node, or the public key of the first consensus node, etc. Exemplarily, the first consensus node can be OA1 described above.

[0146] Then, the first consensus node can send the second initial list to the second consensus node. Afterwards, the second consensus node can encrypt the first virtual identifier corresponding to each network node based on the third key to obtain the first target virtual identifier, and decrypt the second trust value corresponding to each network node based on the fourth key to obtain the first target trust value corresponding to each network node, wherein each first target virtual identifier and the first target trust value corresponding to each first target virtual identifier constitute the first target list. Exemplarily, the third key can be a temporary random number generated by the second consensus node. Exemplarily, the fourth key can also be a temporary random number generated by the second consensus node, or the public key of the second consensus node, etc. Exemplarily, the second consensus node can be the OAm described above.

[0147] Then, the second consensus node may send the first target list generated by it to the first consensus node.

[0148] Finally, the first consensus node can generate a first block based on the first target list and store the first block in the blockchain. For example, the first consensus node and the second consensus node can calculate the first target list (such as the L m ), global parameters related to the first consensus node and the second consensus node (such as the g m ). The first consensus node can then package the root, the first target list, and global parameters related to the first consensus node and the second consensus node into a block, thereby obtaining a first block.

[0149] S402. When the first preset condition is met, the first consensus node updates the trust value of each network node in the first target list to obtain a second target list, and generates a second block based on the second target list, wherein the second block includes the second target list.

[0150] Specifically, when a first preset condition is met, the first consensus node updates the trust value of each network node in the first target list to obtain a second target list, and generates a second block based on the second target list, wherein the second block includes the second target list. Exemplarily, the first preset condition can be a preset duration.

[0151] In one example, the first consensus node can obtain the behavior data of each network node within a preset time period. Exemplarily, the behavior data of each network node within the preset time period can be stored on a cloud server (such as the server 300 described above), so that the first consensus node can obtain the behavior data of each network node within the preset time period from the cloud server.

[0152] Next, the first consensus node can determine the second target trust value corresponding to each network node based on the behavior data corresponding to each network node, the preset time decay coefficient and the first target trust value corresponding to each network node. For example, the second target trust value corresponding to each network node can be determined based on the "Formula 1" described above. Among them, the normal behavior template set P of each network node can be determined based on the behavior template P and the behavior data. N , and abnormal behavior template set P A .

[0153] Finally, after determining the latest trust value of each network node, the first consensus node may update the first target trust value in the first target list to the second target trust value, that is, obtain the second target list.

[0154] Furthermore, after obtaining the second target list, the first consensus node may package the second target list into a second block based on the block manufacturing process described in “Table 3” above.

[0155] S403: The first consensus node sends the second block to the second consensus node.

[0156] Specifically, after the first consensus node packages the second target list into a second block, the first consensus node may send the second block to the second consensus node.

[0157] S404: The second consensus node obtains the second block and verifies the second block.

[0158] Specifically, after obtaining the second block, the second consensus node may verify the second block. For example, the second consensus node may recalculate the trust value of each network node and compare the calculated trust value with the trust value in the second target list included in the second block to determine whether the two are consistent, thereby confirming the correctness of the update of the second target list and the correctness of the content in the second block.

[0159] S405. When the verification is passed, the second consensus node sends a first message to the first consensus node, where the first message is used to indicate that the verification of the second block is passed.

[0160] Specifically, when the verification is passed, the second consensus node may send a first message to the first consensus node indicating that the verification of the second block is passed.

[0161] S406. The first consensus node stores the second block in the blockchain in response to the obtained first message.

[0162] Specifically, after the first consensus node receives the first message sent by the second consensus node, it can store the second block in the blockchain. In this way, each network node can access the block from the blockchain and obtain a list consisting of pseudonyms and trust values. Then, it can check whether its real identity identifier has a corresponding pseudonym (i.e., virtual identifier) ​​in the list. If so, the corresponding network node can use this pseudonym for cross-domain network activities; if not, the corresponding network node cannot use this pseudonym for cross-domain network activities.

[0163] In one example, after the first consensus node stores the second block in the blockchain, the device (such as a network node such as a mobile phone) can obtain the pseudonym and trust value of the device from the blockchain when performing network activities. Afterwards, when sending a message, the device can use its own private key to sign the message and carry a pseudonym in the message. Then, the nodes on the network side (such as base stations, routing devices and other network elements) can use the pseudonym to verify the signature contained in the message sent by the device, and after verification and confirmation, use the pseudonym to obtain the trust value corresponding to the pseudonym from the blockchain, and perform further business activities based on the trust value, such as whether to allow the device to use a certain service. Exemplarily, the nodes on the network side can use the ElGamal algorithm to verify the signature contained in the message sent by the device using the pseudonym.

[0164] Therefore, after a consensus node updates the trust value of a network node, another consensus node verifies the updated trust value using the blockchain's PBFT consensus mechanism, thereby ensuring the consistency of the managed list and achieving decentralized list management. This allows each consensus node to trust each other, thereby achieving global anonymous trust evaluation and sharing. At the same time, each consensus node can record the updated list, so that the network nodes corresponding to each consensus node can verify the trust value and make decisions by accessing the blockchain.

[0165] In one example, when the second preset condition is met, the first consensus node can update the trust values ​​corresponding to at least two network nodes in the second target list to the third target trust value, thereby obtaining a third target list. Exemplarily, the second preset condition can be after K rounds of trust value updates. Exemplarily, this step can be understood as the trust obfuscation phase of the inter-domain list maintenance process described above.

[0166] Then, the first consensus node can obtain a third initial list based on the third target list. The third initial list includes the real identity identifier and the third trust value corresponding to each network node. The third trust value is obtained based on the encryption of the trust value corresponding to each network node in the third target list by the first consensus node and / or the second consensus node. Exemplarily, the first consensus node can reversely process the third target list based on the verifiable shuffling algorithm to obtain the third initial list. Exemplarily, the process of obtaining the first target list from the first initial list can be understood as the process of forward processing the first initial list based on the verifiable shuffling algorithm; the process of obtaining the first initial list from the first target list can be understood as the process of reverse processing the first target list based on the verifiable shuffling algorithm. Exemplarily, the third trust value can be the result of encrypting the trust value in the third target list using the public keys of the first consensus node and the second consensus node.

[0167] Next, the first consensus node can encrypt the real identity of each network node based on the fifth key to obtain the second virtual identity corresponding to each network node, and decrypt the trust value corresponding to each network node in the third target list based on the sixth key to obtain the fourth trust value corresponding to each network node, where each second virtual identity and fourth trust value constitutes the third initial list. Exemplarily, the fifth key can be a temporary random number generated by the first consensus node. Exemplarily, the sixth key can also be a temporary random number generated by the first consensus node, or the public key of the first consensus node. Exemplarily, the first consensus node can be OA1 described above.

[0168] Next, the first consensus node sends the third initial list to the second consensus node.

[0169] Then, the second consensus node encrypts the second virtual identifier corresponding to each network node based on the seventh key to obtain the second target virtual identifier, and decrypts the trust value corresponding to each network node in the third initial list based on the eighth key to obtain the fourth target trust value corresponding to each network node, wherein each second target virtual identifier and each fourth target trust value constitute a fourth target list, and at least two trust values ​​of each fourth target trust value are the same as the third target trust value. Exemplarily, the seventh key can be a temporary random number generated by the second consensus node. Exemplarily, the eighth key can also be a temporary random number generated by the second consensus node, or the public key of the second consensus node, etc. Exemplarily, the second consensus node can be the OAm described above. Exemplarily, the fourth target list can be the one described above.

[0170] Then, the second consensus node may send the fourth target list to the first consensus node. It is understandable that the second target virtual identifier is different from the first target virtual identifier, thereby updating the virtual identifier to improve security.

[0171] Finally, the first consensus node obtains the fourth target list sent by the second consensus node, generates a third block based on the fourth target list, and stores the third block in the blockchain. For example, the first consensus node and the second consensus node can calculate the fourth target list (such as the one described above). ), global parameters related to the first consensus node and the second consensus node (such as the ones described above ). The first consensus node can then package the hash value of the second block, the serial number of the third block, the calculated Merkle tree root, the fourth target list, and global parameters related to the first and second consensus nodes into a single block, thereby obtaining the third block.

[0172] In one example, the first consensus node updates the trust values ​​corresponding to at least two network nodes in each network node in the second target list to a third target trust value. Specifically, the process may include: the first consensus node determines a target interval to which the trust values ​​corresponding to the at least two network nodes belong, and uses the lower limit of the target interval as the third target trust value, and updates the trust values ​​corresponding to the at least two network nodes to the third target trust value. Since the probability that at least two pseudonyms in the old list have the same trust value is high, it is difficult for an attacker to successfully track the network activity or pseudonym of a network node for a long time by analyzing the trust value of the network node. Therefore, trust obfuscation can be performed by updating the trust values ​​of at least two network nodes to the same trust value to enhance the unlinkability between the pseudonyms (i.e., virtual identifiers) and trust values ​​in the list, thereby improving security.

[0173] For example, a target interval can be pre-set. When the number of trust values ​​of network nodes (NEs) falling within the target interval exceeds a preset value, all or most of the trust values ​​in the interval can be adjusted to the same trust value. This ensures that at least two pseudonyms in the list have the same trust value, making it difficult for an attacker to successfully track the network activities or pseudonyms of the NE over a long period of time by analyzing the trust value of the NE.

[0174] In one example, before the first consensus node updates the trust values ​​corresponding to at least two network nodes in each of the network nodes in the second target list to the third target trust value, the first consensus node can re-determine the trust value of each network node based on a preset time decay coefficient and the trust value of each network node in the second target list. Thus, the trust value of each network node can be re-evaluated before trust confusion occurs, thereby reducing the impact of time decay on the trust value and improving data security. Therefore, for example, the first consensus node can re-determine the trust value of each network node based on "Formula 2" described above.

[0175] Based on the method in the above embodiment, the present application embodiment also provides a chip. Figure 5 , Figure 5 This is a schematic diagram of the structure of a chip provided in an embodiment of the present application. Figure 5 As shown, the chip 500 includes one or more processors 501 and an interface circuit 502. Optionally, the chip 500 may also include a bus 503.

[0176] The processor 501 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by an integrated logic circuit of the hardware in the processor 501 or an instruction in the form of software. The above-mentioned processor 501 can be a general-purpose processor, a digital communicator (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component. The various methods and steps disclosed in the embodiments of the present application can be implemented or executed. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The interface circuit 502 can be used for sending or receiving data, instructions or information. The processor 501 can use the data, instructions or other information received by the interface circuit 502 to process, and the processing completion information can be sent out through the interface circuit 502.

[0177] Optionally, the chip also includes a memory, which may include a read-only memory and a random access memory, and provides operating instructions and data to the processor. A portion of the memory may also include non-volatile random access memory (NVRAM). Optionally, the memory stores executable software modules or data structures, and the processor can perform corresponding operations by calling operating instructions stored in the memory (the operating instructions may be stored in the operating system).

[0178] Optionally, the interface circuit 502 may be configured to output the execution result of the processor 501 .

[0179] It should be noted that the corresponding functions of the processor 501 and the interface circuit 502 can be implemented through hardware design, software design, or a combination of hardware and software, which is not limited here.

[0180] It should be understood that each step of the above method embodiment can be completed by a hardware logic circuit or a software instruction in a processor. Figure 2a The described operator agent OA is used to implement the method provided in the embodiment of this application.

[0181] It is understood that the processor in the embodiments of the present application may be a central processing unit (CPU), or may be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. The general-purpose processor may be a microprocessor or any conventional processor.

[0182] The method steps in the embodiments of the present application can be implemented by hardware or by a processor executing software instructions. The software instructions can be composed of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, mobile hard disks, CD-ROMs or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can be located in an ASIC.

[0183] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted via the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid state drive (SSD)).

[0184] It will be understood that the various numerical numbers involved in the embodiments of the present application are merely distinctions for the convenience of description and are not intended to limit the scope of the embodiments of the present application.

Claims

1. A network node control method based on blockchain, characterized in that: The blockchain includes a first consensus node and a second consensus node, the first consensus node corresponds to a first server in a first network, the second consensus node corresponds to a second server in a second network, and the first network and the second network each include at least one network node; The method includes: the first consensus node obtains a first block, the first block includes a first target list, the first target list includes a first target virtual identifier and a first target trust value corresponding to each network node in the first network and the second network, wherein the first target virtual identifier is obtained by the second consensus node encrypting the first virtual identifier corresponding to each network node based on a third key, and is used to represent the identity of the network node, the first target virtual identifier is different from the real identity identifier of the network node, and is obtained by the first consensus node and the second consensus node based on the real identity identifier of the network node, the first target trust value is obtained by the second consensus node decrypting the second trust value corresponding to each network node based on a fourth key, and is used to represent the degree of trust of the network node in the network in which it is located; when the first preset condition is met, the first consensus node updates the trust value of each network node in the first target list to obtain a second target list, and generates a second block based on the second target list, wherein the second block includes the second target list; The first consensus node sends the second block to the second consensus node, so that the second consensus node verifies the second block; The first consensus node obtains a first message sent by the second consensus node, and stores the second block in the blockchain, where the first message is used to indicate that verification of the second block has passed.

2. The method according to claim 1, characterized in that The first consensus node obtains the first block, specifically including: The first consensus node determines a first initial list, where the first initial list includes a real identity identifier of each of the network nodes and a first trust value corresponding to each of the network nodes, where the first trust value is obtained by encrypting the trust value corresponding to each of the network nodes in the first target list by the first consensus node and / or the second consensus node; The first consensus node encrypts the real identity identifiers of each of the network nodes based on the first key to obtain a first virtual identifier corresponding to each of the network nodes, and decrypts the first trust value corresponding to each of the network nodes based on the second key to obtain a second trust value corresponding to each of the network nodes, wherein each of the first virtual identifiers and the second trust value corresponding to each of the first virtual identifiers constitute a second initial list; The first consensus node sends the second initial list to the second consensus node, so that the second consensus node determines a first target list, where the first target list includes a first target virtual identifier corresponding to each of the network nodes and a first target trust value corresponding to the first target virtual identifier; The first consensus node obtains the first target list sent by the second consensus node, generates the first block based on the first target list, and stores the first block in the blockchain.

3. The method according to claim 2, characterized in that The first consensus node updates each network node in the first target list to obtain a second target list, specifically including: The first consensus node obtains behavior data of each of the network nodes within a preset time period; The first consensus node determines a second target trust value corresponding to each of the network nodes based on the behavior data corresponding to each of the network nodes, a preset time decay coefficient, and a first target trust value corresponding to each of the network nodes; The first consensus node updates the first target trust value in the first target list to the second target trust value to obtain the second target list.

4. The method according to claim 3, characterized in that The method further comprises: When the second preset condition is met, the first consensus node updates the trust values ​​corresponding to at least two of the network nodes in the second target list to third target trust values ​​to obtain a third target list; The first consensus node obtains a third initial list based on the third target list, where the third initial list includes a real identity identifier and a third trust value corresponding to each of the network nodes, where the third trust value is encrypted by the first consensus node and / or the second consensus node based on the trust value corresponding to each of the network nodes in the third target list; The first consensus node encrypts the real identity identifier of each of the network nodes based on the fifth key to obtain a second virtual identifier corresponding to each of the network nodes, and decrypts the trust value corresponding to each of the network nodes in the third target list based on the sixth key to obtain a fourth trust value corresponding to each of the network nodes, wherein each of the second virtual identifiers and the fourth trust value constitutes a third initial list; The first consensus node sends the third initial list to the second consensus node, so that the second consensus node encrypts the second virtual identifier corresponding to each of the network nodes based on the seventh key to obtain a second target virtual identifier, and decrypts the trust value corresponding to each of the network nodes in the third initial list based on the eighth key to obtain a fourth target trust value corresponding to each of the network nodes, wherein each of the second target virtual identifiers and each of the fourth target trust values ​​constitutes a fourth target list, and at least two trust values ​​of each of the fourth target trust values ​​are the same as the third target trust value; The first consensus node obtains the fourth target list sent by the second consensus node, generates a third block based on the fourth target list, and stores the third block in the blockchain.

5. The method according to claim 4, characterized in that The first consensus node updates the trust values ​​corresponding to at least two of the network nodes in the second target list to a third target trust value, specifically including: The first consensus node determines a target interval to which the trust values ​​corresponding to the at least two network nodes belong, takes a lower limit value of the target interval as the third target trust value, and updates the trust values ​​corresponding to the at least two network nodes to the third target trust value.

6. The method according to claim 5, characterized in that Before the first consensus node updates the trust values ​​corresponding to at least two of the network nodes in the second target list to the third target trust value, the method further includes: The first consensus node re-determines the trust value of each of the network nodes based on a preset time decay coefficient and the trust value of each of the network nodes in the second target list.

7. A network node control method based on blockchain, characterized in that: The blockchain includes a first consensus node and a second consensus node, the first consensus node corresponds to a first server in a first network, the second consensus node corresponds to a second server in a second network, and the first network and the second network each include at least one network node; The method comprises: The second consensus node obtains a second block sent by the first consensus node, where the second block includes a second target list, and the second target list is obtained by the first consensus node updating the trust value of each network node in the first target list included in the first block when the first preset condition is met. The first target list includes a first target virtual identifier and a first target trust value corresponding to each network node in the first network and the second network, wherein the first target virtual identifier is obtained by the second consensus node encrypting the first virtual identifier corresponding to each network node based on the third key, and is used to represent the identity of the network node. The first target virtual identifier is different from the real identity identifier of the network node, and is obtained by the first consensus node and the second consensus node based on the real identity identifier of the network node. The first target trust value is obtained by the second consensus node decrypting the second trust value corresponding to each network node based on the fourth key, and is used to represent the degree of trust of the network node in the network in which it is located; The second consensus node verifies the second block, and when the verification passes, sends a first message to the first consensus node, where the first message is used to indicate that the verification of the second block passes.

8. The method according to claim 7, characterized in that Before the second consensus node obtains the second block sent by the first consensus node, the process further includes: The second consensus node obtains a second initial list sent by the first consensus node, where the second initial list includes a first virtual identifier and a second trust value of each of the network nodes, the first virtual identifier being obtained by encrypting the real identity identifier of the network node in the first initial list by the first consensus node based on a first key, and the second trust value being obtained by decrypting the first trust value corresponding to the network node in the first initial list by the first consensus node based on the second key, the first initial list including the real identity identifier of each of the network nodes and the first trust value corresponding to each of the network nodes, and the first trust value being obtained by encrypting the trust value corresponding to each of the network nodes in the first target list by the first consensus node and / or the second consensus node; The second consensus node determines a first target list, where the first target list includes a first target virtual identifier corresponding to each of the network nodes and a first target trust value corresponding to the first target virtual identifier; The second consensus node sends the first target list to the first consensus node.

9. The method according to claim 7 or 8, characterized in that The method further comprises: The second consensus node obtains a third initial list sent by the first consensus node, where the third initial list includes a second virtual identifier and a fourth trust value corresponding to each of the network nodes. The second virtual identifier is obtained by encrypting the real identity identifier of the network node by the first consensus node based on the fifth key. The fourth trust value is obtained by decrypting the third trust value corresponding to the network node in the third target list by the first consensus node based on the sixth key. The third target list includes the real identity identifier and the third trust value corresponding to each of the network nodes. The third trust value is encrypted based on the trust value corresponding to each of the network nodes in the third target list by the first consensus node and / or the second consensus node. Wherein, the third target list is obtained by the first consensus node updating the trust values ​​corresponding to at least two of the network nodes in the second target list to the third target trust value when the second preset condition is met; The second consensus node encrypts the second virtual identifier corresponding to each of the network nodes based on the seventh key to obtain a second target virtual identifier, and decrypts the trust value corresponding to each of the network nodes in the third initial list based on the eighth key to obtain a fourth target trust value corresponding to each of the network nodes, wherein each of the second target virtual identifiers and each of the fourth target trust values ​​constitutes a fourth target list, and at least two trust values ​​of each of the fourth target trust values ​​are the same as the third target trust value; The second consensus node sends the fourth target list to the first consensus node, so that the first consensus node generates a third block based on the fourth target list and stores the third block in the blockchain.

10. A device control method, characterized in that: Applied to a first device, the method includes: The first device obtains a target virtual identifier corresponding to the first device based on a target block in the blockchain, where the target block is a second block obtained according to the method of any one of claims 1 to 9; The first device sends a target message to the second device, where the target message includes the target virtual identifier and a target signature, and the target signature is obtained by the first device signing the target message based on its own private key.

11. A device control method, characterized in that: Applied to the second device, the method includes: The second device obtains a target message sent by the first device, where the target message includes a target virtual identifier and a target signature. The target virtual identifier is the virtual identifier of the first device. The first device can obtain the virtual identifier of the first device from a target block in the blockchain. The target block is the second block obtained according to any one of claims 1 to 9. The target signature is obtained by the first device signing the target message based on its own private key. The second device uses the target virtual identifier to verify the target signature, and after the verification is passed, uses the target virtual identifier to obtain a target trust value corresponding to the target virtual identifier from the blockchain, and performs business activities based on the target trust value.

12. A device control device, characterized in that: include: at least one memory for storing a program; At least one processor is configured to execute the program stored in the memory. When the program stored in the memory is executed, the processor is configured to execute the method according to claim 10 or the method according to claim 11.

13. A consensus node, characterized in that: include: at least one memory for storing a program; At least one processor is used to execute the program stored in the memory. When the program stored in the memory is executed, the processor is used to execute the method according to any one of claims 1 to 6, or the method according to any one of claims 7 to 9.

14. A network node control system based on blockchain, characterized in that: The blockchain includes a first consensus node and a second consensus node, the first consensus node corresponds to a first server in a first network, the second consensus node corresponds to a second server in a second network, and the first network and the second network each include at least one network node; The first consensus node is used to execute the method according to any one of claims 1 to 6, and the second consensus node is used to execute the method according to any one of claims 7 to 9.

15. A computer-readable storage medium storing a computer program, wherein when the computer program is executed on an electronic device, the electronic device executes the method according to any one of claims 1 to 6, or the method according to any one of claims 7 to 9, or the method according to claim 10, or the method according to claim 11.

16. A computer program product, characterized in that When the computer program product runs on an electronic device, the electronic device executes the method according to any one of claims 1 to 6, or the method according to any one of claims 7 to 9, or the method according to claim 10, or the method according to claim 11.

Images