An electric power internet of things edge security interaction method

Abstract

The application discloses a power Internet of Things edge security interaction method, which comprises the following steps: taking an initial interaction request initiated by a request security domain to a response security domain as a processing object, building a cross-domain interaction basic framework through a HotStuff consensus control center, fusing node historical trust data and authentication information of a trusted identity basic trust facility, and constructing a multi-dimensional security protection strategy covering identity authentication, permission control and data encryption; taking the multi-dimensional security protection strategy as a processing object, executing a cross-domain interaction process based on a HotStuff consensus mechanism, generating a quantitative trust evaluation result through a hierarchical model of distributed trust calculation, joint trust calculation, total trust degree calculation, link reliability calculation and fuzzy trust calculation; when the trust evaluation result meets a security threshold, executing an interaction operation, performing coordinate fuzzification processing on the physical position of the accessed resource to hide the real address, and generating a performance check report through communication overhead and false alarm rate indicators after the interaction is completed.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a method for edge security interaction in the power Internet of Things. Background Technology

[0002] With the construction of new power systems, the power Internet of Things (IoT) has experienced large-scale development. A large number of distributed energy devices, microgrids, energy storage devices, and other multi-dimensional terminal devices have been connected to the distribution network, leading to a sharp increase in the demand for edge computing and cloud-edge interaction. These devices need to frequently exchange energy information and status data in cross-domain environments. Since the security and stability of the power system are directly related to the reliability of energy supply, cross-domain secure interaction has become a key challenge for the development of the power IoT.

[0003] Currently, network security protection in traditional power systems primarily relies on boundary isolation, using firewalls and vertical encryption authentication to build a security framework. However, this centralized protection model struggles to meet the rapid access needs of distributed terminal devices and lacks sufficient support for dynamic security interactions in cross-domain asynchronous environments, resulting in issues such as high response latency and poor adaptability to differentiated services.

[0004] In terms of consensus mechanisms and trust management, existing technologies have obvious limitations: some consensus algorithms (such as Proof-of-Work, PoW) consume a lot of computing resources and are not suitable for the energy efficiency requirements of power systems; although algorithms such as Practical Byzantine Fault Tolerance (PBFT) can achieve consensus, they suffer from high communication overhead and high latency, making it difficult to cope with real-time interactions of large-scale terminals; at the same time, traditional trust assessment methods mostly rely on single-dimensional interaction data and lack comprehensive consideration of node historical behavior, link reliability, and cross-domain cooperation relationships, resulting in insufficient accuracy and robustness of trust assessment and inability to effectively resist attacks from malicious nodes or risks such as information spoofing and hijacking. Summary of the Invention

[0005] This application provides a power Internet of Things edge security interaction method to solve or mitigate the technical defects in the prior art.

[0006] This application provides a method for edge security interaction in the power Internet of Things, which includes:

[0007] Step 1: Taking the initial interaction request initiated by the request security domain to the response security domain as the processing object, a cross-domain interaction basic framework is built through the HotStuff consensus control center. The historical trust data of the nodes and the authentication information of the trusted identity basic trust infrastructure are integrated to build a multi-dimensional security protection strategy covering identity verification, access control and data encryption.

[0008] Step 2: Taking multi-dimensional security protection strategies as the processing object, execute cross-domain interaction process based on HotStuff consensus mechanism, and generate quantitative trust assessment results through a hierarchical model of distributed trust computation, joint trust computation, total trust degree computation, link reliability computation and fuzzy trust computation.

[0009] Step 3: Using the trust assessment result as the processing object, when the trust assessment result meets the security threshold, perform interactive operations, perform coordinate fuzzing on the physical location of the accessed resource to hide the real address, and generate a performance verification report based on communication overhead and false alarm rate indicators after the interaction is completed.

[0010] Optionally, step 1 specifically includes:

[0011] Step 11: Taking the initial interaction request initiated by the request security domain as the processing object, add the interaction type, resource requirements and digital signature identifier, and send it to the response security domain through the edge gateway to generate an identifiable interaction request;

[0012] Step 12: Using the distributed node architecture of the HotStuff consensus control center as the processing object, define the roles, permissions, and communication protocols of the requester, responder, and consensus nodes, build a cross-domain interaction framework for the three parties, and generate an interaction framework rule set.

[0013] Step 13: Using the generated interaction framework rule set as the processing object, integrate the trust value data of the node's historical interactions with the digital certificate authentication results of the trusted identity infrastructure to generate a multi-dimensional security protection strategy.

[0014] Optionally, step 2, "cross-domain secure interaction based on the HotStuff consensus mechanism," includes:

[0015] Step 21: Using the event-driven framework of the HotStuff consensus algorithm as the processing object, deploy three asynchronous threads for request processing, response feedback, and consensus events to achieve parallel communication and event synchronization between nodes in different domains and generate an asynchronous interaction mechanism;

[0016] Step 22: Using an asynchronous interaction mechanism as the processing object, generate a fast consensus result through a four-stage chain voting process of pre-preparation, preparation, pre-commitment, and submission.

[0017] Optionally, step 22 specifically includes:

[0018] Step 221: Using the asynchronous interaction mechanism as the processing object, the legality of the interaction request is verified in the pre-preparation phase, a proposal containing request details is generated and broadcast to all consensus nodes to obtain the pre-prepared proposal;

[0019] Step 222: Taking the pre-prepared proposal as the processing object, during the preparation phase, each node verifies the consistency of the proposal and returns the voting results. When the number of nodes that approve the proposal exceeds the preset proportion, a consensus for the preparation phase is generated.

[0020] Step 223: Taking the consensus of the preparation phase as the processing object, the master node summarizes the results in the pre-commit phase to form a temporary consensus and broadcasts it for secondary confirmation to obtain the pre-commit consensus;

[0021] Step 224: Taking the pre-commit consensus as the processing object, after the nodes finally confirm the consensus during the submission phase when the preset proportion is exceeded, an immutable final consensus result is generated.

[0022] Optionally, the "distributed trust computation" in step 2 includes:

[0023] Step 51: Using the node's historical interaction records as the processing object, calculate the probability of successful interaction and the probability of failed interaction using a Bayesian probability model to generate an interaction probability set;

[0024] Step 52: Using the interaction probability set as the processing object, introduce a dynamic penalty factor for malicious nodes and generate a dynamic penalty factor value;

[0025] Step 53: Using the interaction probability set and dynamic penalty factor as the processing objects, generate node direct trust values ​​through direct trust values.

[0026] Optionally, the "joint trust computation" in step 2 includes:

[0027] Step 61: Using the neighbor list of a node as the processing object, select single-hop nodes with trust values ​​exceeding the preset trust threshold to form an initial trust set, remove unstable nodes with historical trust jitter rates exceeding the preset jitter threshold, and generate a stable neighbor set.

[0028] Step 62: Using the stable neighbor set as the processing object, calculate the single-hop joint trust using the weighted average algorithm to generate the initial joint trust value;

[0029] Step 63: Using the initial joint trust value as the processing object, remove outliers using the sliding window algorithm to generate a smoothed joint trust value.

[0030] Optionally, the "total trust calculation" in step 2 includes:

[0031] Step 71: Using the node's direct trust value, the joint trust value generated in Step 6, and the trust level of the trusted identity infrastructure as the processing objects, set weight coefficients and generate a weight configuration set;

[0032] Step 72: Using the weight configuration set as the processing object, perform weighted fusion based on the total trust level to generate a fused trust value;

[0033] Step 73: Using the merged trust value as the processing object, map it to the preset trust evaluation range and verify its rationality to generate the final total trust evaluation value.

[0034] Optionally, the "link reliability calculation" in step 2 includes:

[0035] Step 81: Using the round-trip transmission time and packet loss rate of the historical interactions between nodes with a preset number of times as the processing object, calculate the average transmission delay and stability coefficient, and generate a set of link performance parameters;

[0036] Step 82: Using the link performance parameter set as the processing object, generate a link reliability score through reliability calculation;

[0037] Step 83: Using the link reliability score as the processing object, when the score is lower than the preset link reliability threshold, link switching is triggered to generate the optimal communication path.

[0038] Optionally, the "fuzzy trust calculation" in step 2 includes:

[0039] Step 91: Using the total trust assessment value and link reliability score as the processing objects, the Mamdani fuzzy inference mapping is used to map them into a "high / medium / low trust" fuzzy set, generating a fuzzy feature set;

[0040] Step 92: Using the fuzzy feature set as the processing object, calculate the membership degree based on the triangular membership function, establish the inference rule of "high total trust degree and reliable link → high trust level", and generate fuzzy inference results;

[0041] Step 93: Using the fuzzy inference result as the processing object, the centroid method is used to defuzzify it and generate a quantified fuzzy trust evaluation value.

[0042] Optionally, step 3 specifically includes:

[0043] Step 31: Using the trust assessment result as the processing object, when the result reaches the preset security threshold, start end-to-end encrypted transmission and generate encrypted interactive data stream;

[0044] Step 32: Using the physical coordinates of the accessed resource as the processing object, perform fuzzing processing through random offset to generate virtual coordinates that hide the real location;

[0045] Step 33: Using encrypted interactive data streams and virtual coordinates as the processing objects, after the interaction is completed, calculate the communication overhead and false alarm rate indicators, and generate a performance verification report.

[0046] The power Internet of Things (IoT) edge security interaction method provided in this application has the following technical advantages:

[0047] By adopting the HotStuff consensus mechanism, its low latency and high throughput characteristics enable rapid consensus in highly asynchronous cross-domain environments, solving the problems of high communication overhead and high latency associated with traditional consensus algorithms (such as PBFT). This allows for efficient adaptation to the access needs of large-scale terminal devices, enhancing real-time interaction capabilities between devices in different domains. Furthermore, HotStuff's rapid decision-making and early termination mechanisms reduce the number of message passes and waiting time, further improving cross-domain communication performance.

[0048] By employing distributed trust computation (combining Bayesian models and penalty factors), joint trust computation (integrating single-hop neighbor trust values), total trust calculation (fusing multi-dimensional trust weights), link reliability calculation, and fuzzy trust computation, a multi-dimensional comprehensive trust assessment system was constructed, addressing the problems of traditional trust assessment methods being too simplistic and incomplete. This hierarchical computation approach accurately reflects node behavior, link status, and cross-domain collaboration relationships, effectively resisting malicious node attacks and information spoofing risks, and improving the reliability of trust assessment.

[0049] Secure authentication is achieved through a trusted identity infrastructure, combined with fuzzing to hide the location of accessed resources. This ensures secure interaction while protecting data privacy, overcoming the shortcomings of traditional boundary protection models in terms of privacy protection. Furthermore, the integration of the HotStuff consensus control center and trust computing mechanism constructs a dynamic security protection strategy, enhancing the isolation and boundary protection capabilities between security domains.

[0050] In summary, this method comprehensively addresses the efficiency, security, and adaptability issues in cross-domain interactions of the power Internet of Things through an efficient consensus mechanism, multi-dimensional trust assessment, and privacy-preserving design, providing reliable support for the secure collaboration of large-scale distributed devices. Attached Figure Description

[0051] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0052] Figure 1 This is a flowchart illustrating a power Internet of Things (IoT) edge security interaction method according to an embodiment of this application. Detailed Implementation

[0053] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0054] like Figure 1 As shown in the figure, an embodiment of this application provides a power Internet of Things (IoT) edge security interaction method, which includes:

[0055] Step 1: Taking the initial interaction request initiated by the request security domain to the response security domain as the processing object, a cross-domain interaction basic framework is built through the HotStuff consensus control center. The historical trust data of the nodes and the authentication information of the trusted identity basic trust infrastructure are integrated to build a multi-dimensional security protection strategy covering identity verification, access control and data encryption.

[0056] Step 2: Taking multi-dimensional security protection strategies as the processing object, execute cross-domain interaction process based on HotStuff consensus mechanism, and generate quantitative trust assessment results through a hierarchical model of distributed trust computation, joint trust computation, total trust degree computation, link reliability computation and fuzzy trust computation.

[0057] Step 3: Using the trust assessment result as the processing object, when the trust assessment result meets the security threshold, perform interactive operations, perform coordinate fuzzing on the physical location of the accessed resource to hide the real address, and generate a performance verification report based on communication overhead and false alarm rate indicators after the interaction is completed.

[0058] Optionally, step 1 specifically includes:

[0059] Step 11: Taking the initial interaction request initiated by the request security domain as the processing object, add the interaction type, resource requirements and digital signature identifier, and send it to the response security domain through the edge gateway to generate an identifiable interaction request;

[0060] Step 12: Using the distributed node architecture of the HotStuff consensus control center as the processing object, define the roles, permissions, and communication protocols of the requester, responder, and consensus nodes, build a cross-domain interaction framework for the three parties, and generate an interaction framework rule set.

[0061] Step 13: Using the generated interaction framework rule set as the processing object, integrate the trust value data of the node's historical interactions with the digital certificate authentication results of the trusted identity infrastructure to generate a multi-dimensional security protection strategy.

[0062] Preferably, step 11 is implemented as follows: taking the initial interaction request initiated by the request security domain as the processing object, firstly, the request content is structured and parsed to extract the core operation intent and map it to a preset interaction type system (such as data query, control command, resource call, etc.). At the same time, based on the operation complexity and resource consumption involved in the request, resource requirement parameters (such as required computing power, bandwidth, response time) are quantified and generated. Next, a digital signature mechanism based on the SM2 asymmetric encryption algorithm is used to sign the interaction type, resource requirement, and request timestamp using the requester's private key to generate a tamper-proof digital signature identifier, which is then embedded in the request header. Subsequently, the signed request is sent to the edge gateway, which verifies the request format (such as field integrity and signature format validity) and determines the target node of the response security domain through a preset inter-domain routing table to complete cross-domain forwarding. Finally, an identifiable interaction request containing "interaction type field + resource requirement parameters + digital signature + timestamp" is generated, which can be verified by the responder to verify the authenticity of the source and the integrity of the content.

[0063] Preferably, step 12 is implemented as follows: Taking the distributed node architecture of the HotStuff consensus control center (composed of request node clusters, response node clusters, and consensus node clusters, using a star-mesh hybrid network topology) as the processing object, firstly, the role permissions are refined based on the zero-trust architecture: request nodes only have the right to initiate interactions and receive results, and must be authenticated before they can access the network; response nodes have the right to access resources and generate responses, and their permission scope is bound to the request type (e.g., read permissions for data queries and limited write permissions for control commands); consensus nodes are responsible for voting and generating consensus results, can only process encrypted consensus messages, and use Byzantine tolerance. The system first limits the influence of a single node by implementing an error mechanism. Secondly, it defines an encrypted communication protocol based on TLS 1.3, specifying message format (including header checksum, body encryption area, and tail MAC code), interaction sequence (request-response-confirmation three-phase handshake), and a timeout retransmission mechanism (dynamic timeout threshold adjusted based on historical communication latency). Based on this, a three-party collaborative framework is built: after a requesting node initiates a request, a temporary consensus group is formed by three randomly selected consensus nodes; the responding node's response must be verified by the consensus group before execution. Finally, an interaction framework rule set is generated, including a role and permission matrix, communication protocol specifications, and consensus group election rules, ensuring controllable permissions and traceable processes for inter-domain interactions.

[0064] Preferably, step 13 is specifically implemented as follows: taking the interaction framework rule set as the processing object, firstly, the historical interaction data of the nodes is cleaned and features are extracted to generate a trust feature vector containing indicators such as interaction success rate, average response latency, and number of abnormal behaviors. The recent trust trend of the nodes is calculated using a sliding window algorithm. At the same time, the trusted identity infrastructure interface is called to obtain authentication information such as the revocation status of the node's digital certificate, certificate validity period, and the credibility of the issuing authority. The certificate chain is verified layer by layer to confirm the legitimacy of the identity and generate an identity authentication result. The recent trust trend of the nodes and the identity authentication result are used as inputs, and a weighted fusion algorithm is adopted (where the weight of historical trust data varies with time). Dynamic decay (with the weight of the latest interaction record increased by 20% to enhance timeliness) constructs a multi-dimensional security protection strategy—at the identity verification layer, two-factor authentication is implemented by combining digital certificates and dynamic trust values, triggering secondary verification when the certificate is valid but the trust value is below the threshold; at the access control layer, the scope of operation permissions is dynamically adjusted based on the trust level (e.g., high-trust nodes can directly execute query operations, while low-trust nodes require additional consensus confirmation); at the data encryption layer, the encryption algorithm strength is adaptively selected based on the trust difference between the two parties (the smaller the trust difference, the more efficient lightweight encryption is used), ultimately generating a dynamically adjustable set of security policies to achieve linked protection of "identity-access-encryption".

[0065] Optionally, step 2, "cross-domain secure interaction based on the HotStuff consensus mechanism," includes:

[0066] Step 21: Using the event-driven framework of the HotStuff consensus algorithm as the processing object, deploy three asynchronous threads for request processing, response feedback, and consensus events to achieve parallel communication and event synchronization between nodes in different domains and generate an asynchronous interaction mechanism;

[0067] Step 22: Using an asynchronous interaction mechanism as the processing object, generate a fast consensus result through a four-stage chain voting process of pre-preparation, preparation, pre-commitment, and submission.

[0068] Preferably, step 21 is implemented as follows: taking the event-driven framework of the HotStuff consensus algorithm as the processing object, firstly, the core event types of the framework (including interactive request events, node response events, and consensus state change events) are parsed, and thread resources are dynamically allocated based on the computing power of the edge nodes—the request processing thread focuses on receiving and parsing interactive requests from the request security domain, extracting key fields such as request identifier, operation type, and security level, and generating structured request event packages; the response feedback thread listens to the node responses in the response security domain in real time, performs format verification and signature verification on the response content, encapsulates the valid responses into response event packages, and marks the processing status; the consensus event thread is responsible for coordinating the event flow of the first two threads, maintaining a global event queue, and dynamically adjusting the event priority by timestamp sorting and security level weighting (e.g., control instructions with high security levels take precedence over ordinary data queries). To enable parallel communication between nodes in different domains, a lock-free queue based on shared memory is used to transmit event packets between threads. Each event packet carries a unique sequence identifier and an inter-domain encrypted certificate to ensure traceability of identity during cross-domain transmission. At the same time, an event synchronization trigger is introduced. When the request processing thread generates a request event packet, it automatically triggers the pre-verification process of the consensus event thread. When the response feedback thread receives the response, it triggers the consensus state update. This ultimately forms a three-in-one asynchronous interaction mechanism of "request parsing - response listening - consensus coordination". This mechanism reduces the event processing latency of nodes in different domains by more than 30% through thread parallelism and dynamic priority scheduling.

[0069] Preferably, step 22 is implemented as follows: Using the asynchronous interaction mechanism as the processing object, a pre-preparation phase is initiated first: the master node extracts the highest-priority request event packet from the event queue of the asynchronous interaction mechanism, verifies the legality of the request based on the multi-dimensional security protection strategy generated in step 1 (including the validity of the requester's identity certificate, the matching degree of operation permissions, and the integrity of data encryption), and after passing the verification, packages the request details, master node signature, and timestamp into a pre-prepared proposal, and sends it to all consensus nodes using a sharding broadcast mechanism (i.e., grouped by node region, each group receives different shards of the complete proposal, and restores them through distributed splicing to reduce the transmission pressure on a single node). After the pre-prepared proposal is generated, without waiting for all nodes to complete receiving, the preparation phase is immediately initiated: nodes that have received the complete proposal perform local verification of the proposal (including comparison with their own stored interaction rule set and signature chain verification), and after passing the verification, generate a voting message containing the node ID and verification result, and broadcast it to other nodes; simultaneously, each node maintains a voting counter to count the number of received votes of the same type in real time. When the number of votes from nodes exceeds a preset proportion, a preparation phase consensus report is automatically generated and the temporary validity of the current proposal is marked. After the consensus report is generated in the preparation phase, the pre-commit phase starts simultaneously: the master node summarizes the consensus reports from all nodes in the preparation phase, selects the proposals that have been unanimously approved, supplements them with the master node's secondary signature to form a temporary consensus package, and uses incremental broadcasting to send only the differences from the previous proposal, reducing the amount of data transmission; each node receives the temporary consensus package and verifies its integrity, and returns a confirmation message upon approval; the master node calculates the confirmation ratio to generate the pre-commit consensus. Finally, the commit phase begins: the master node packages the pre-commit consensus with the confirmation messages from all nodes to form an immutable block, associates it with the previous consensus results through a chained storage structure, and generates a final consensus certificate containing a complete interaction log, node signature set, and timestamp; at the same time, a network-wide broadcast mechanism is triggered to synchronize the final consensus certificate to all nodes in the request security domain and the response security domain. After each node verifies the consistency between the block hash value and the signature chain, it updates its local consensus ledger and marks the interaction request as "consensus achieved," ultimately forming an immutable consensus result with Byzantine fault tolerance, ensuring the final consistency and traceability of cross-domain interactions.

[0070] Optionally, step 22 specifically includes:

[0071] Step 221: Using the asynchronous interaction mechanism as the processing object, the legality of the interaction request is verified in the pre-preparation phase, a proposal containing request details is generated and broadcast to all consensus nodes to obtain the pre-prepared proposal;

[0072] Step 222: Taking the pre-prepared proposal as the processing object, during the preparation phase, each node verifies the consistency of the proposal and returns the voting results. When the number of nodes that approve the proposal exceeds the preset proportion, a consensus for the preparation phase is generated.

[0073] Step 223: Taking the consensus of the preparation phase as the processing object, the master node summarizes the results in the pre-commit phase to form a temporary consensus and broadcasts it for secondary confirmation to obtain the pre-commit consensus;

[0074] Step 224: Taking the pre-commit consensus as the processing object, after the nodes finally confirm the consensus during the submission phase when the preset proportion is exceeded, an immutable final consensus result is generated.

[0075] Preferably, step 221 is implemented as follows: taking the asynchronous interaction mechanism as the processing object, firstly, the request event packet to be processed is extracted from the event queue of the asynchronous interaction mechanism. Based on the authentication rules (such as the validity period of the requester's digital certificate, the matching degree between operation permissions and request type) and data integrity verification standards (such as the comparison of request content hash values) in the multi-dimensional security protection strategy, the legality of the request is verified layer by layer. After the verification is passed, the master node packages the core operation intent of the request, the resource identifiers involved, the security level, the master node's digital signature, and the precise timestamp to generate a structured pre-prepared proposal. In order to reduce the pressure of cross-domain transmission, a "load-aware block broadcasting" mechanism is adopted - the proposal is divided into blocks according to the real-time load (CPU utilization, bandwidth usage) of the consensus nodes, and the complete block is sent to the low-load nodes first. The high-load nodes receive the compressed block (which is subsequently supplemented as needed). Finally, all consensus nodes splice together to obtain the complete pre-prepared proposal.

[0076] Preferably, step 222 is implemented as follows: taking the pre-prepared proposal as the processing object, each consensus node first verifies the integrity of the proposal's signature chain (the matching degree between the master node's signature and the preset public key) and the consistency of its content (comparing it with the operation specifications in the locally cached interaction framework rule set, such as whether the resource access scope is compliant); the node that passes the verification generates a voting message containing its own ID, verification result (pass / fail), and node signature, and broadcasts it to other nodes through an encrypted P2P channel (using session key encryption to prevent the vote from being tampered with); each node maintains a "weighted voting counter", assigns different weights according to the node's historical consensus contribution (such as the accuracy rate of the past 30 consensuses), and calculates the weighted sum of valid votes in real time. When the weighted pass ratio exceeds a preset threshold, a preparation stage consensus containing the voting node ID, weighted pass ratio, timestamp, and collective signature of the nodes is automatically generated. This consensus adopts a chain storage structure and is associated with the pre-prepared proposal to form a traceable consensus chain.

[0077] Preferably, step 223 is implemented as follows: taking the consensus of the preparation phase as the processing object, the master node extracts the consensus records of all nodes in the preparation phase from the distributed ledger, and filters out the core content that has been consistently passed (such as the legality conclusion of the request and the boundary of the operation permission) through consensus hash comparison; cross-validates these contents with the key information of the pre-prepared proposal (request identifier, resource requirements) to ensure that there is no tampering and forms a temporary consensus package, and supplements the master node with the secondary signature and version number; in order to improve the efficiency of cross-domain synchronization, a "difference broadcast" mechanism is adopted - only sending the difference fields from the previous consensus (such as the newly added voting results and permission adjustment items) to each node, and the node quickly restores the complete temporary consensus through local caching after receiving it; each node verifies the signature validity and content logic of the temporary consensus package, and returns a secondary confirmation message containing its own ID and confirmation signature after passing the verification. The master node summarizes these messages to generate a pre-commit consensus, which is accompanied by a "consensus progress tag" (marking the completed verification link) to accelerate the subsequent process.

[0078] Preferably, step 224 is implemented as follows: taking the pre-commit consensus as the processing object, the master node packages the pre-commit consensus with the secondary confirmation messages of all nodes to generate a submission proposal containing the complete consensus chain (hash values ​​and signature sets of each stage of pre-preparation-pre-commit); the proposal is sent to all nodes in the network using the "Byzantine fault-tolerant broadcast" mechanism to ensure that information synchronization can still be completed even if there are a few malicious nodes; each node performs final verification of the submission proposal, focusing on verifying the logical coherence of the consensus at each stage (such as whether the proposal passed in the preparation stage is consistent with the content of the pre-commit consensus) and the integrity of the signature chain; when the master node counts that more than a preset proportion of nodes return "final confirmation" messages (including node signatures and verification timestamps), the submission proposal is written into an immutable distributed block, and the public key hashes and Merkle root values ​​of all confirming nodes are embedded in the block header; finally, a final consensus result containing the block index, consensus result, and complete signature chain is generated and synchronized to the core nodes of the request security domain and the response security domain to complete the consensus closed loop of cross-domain interaction.

[0079] Optionally, the "distributed trust computation" in step 2 includes:

[0080] Step 51: Using the node's historical interaction records as the processing object, calculate the probability of successful interaction and the probability of failed interaction using a Bayesian probability model to generate an interaction probability set;

[0081] Step 52: Using the interaction probability set as the processing object, introduce a dynamic penalty factor for malicious nodes and generate a dynamic penalty factor value;

[0082] Step 53: Using the interaction probability set and dynamic penalty factor as the processing objects, generate node direct trust values ​​through direct trust values.

[0083] Preferably, step 51 is implemented as follows: taking the node's historical interaction records as the processing object, the records are first cleaned in multiple dimensions—removing instantaneous failures caused by network fluctuations (such as a single timeout without response but subsequent success) and records with format errors (such as incomplete signatures), retaining valid interaction records; classifying by interaction type (such as data query, control command execution, resource call), extracting the number of successes, failures, average response time, and the results of the last 3 interactions for each type of interaction, generating a categorized interaction record set; based on the Bayesian probability model, taking the categorized interaction record set as input, first calculating the prior probability of success for each type of interaction (based on the proportion of historical total successes), then combining the interaction trend of the past 7 days (such as the slope of success rate increase / decrease) to calculate the likelihood probability, and fusing to obtain the posterior success interaction probability; similarly, calculating the failure interaction probability by the proportion of failures and the recent failure frequency, finally generating an interaction probability set divided by interaction type, which can reflect the interaction reliability of nodes in different scenarios.

[0084] Preferably, step 52 is implemented as follows: taking the interaction probability set as the processing object, firstly, nodes whose failure interaction probability exceeds a preset threshold three times consecutively are selected from the set, and the malicious behavior type (active attack type / passive anomaly type) is determined by combining the node behavior log (such as whether there is a forged response signature or repeated sending of invalid requests); for active attack type nodes (such as forged data response), a basic penalty coefficient is set and increases with the number of attacks (the coefficient is 0.3 for the first attack and increases to 0.5 for the second attack); for passive anomaly type nodes (such as failure caused by continuous network instability), the basic coefficient is 0.1, and the coefficient doubles if the anomaly lasts for more than 24 hours; finally, the basic coefficient is weighted and integrated with the duration of malicious behavior and the scope of influence (such as the number of affected nodes) to generate a dynamic penalty factor value that changes dynamically with the node behavior, so as to achieve precise punishment of malicious nodes.

[0085] Preferably, step 53 is implemented as follows: taking the interaction probability set and the dynamic penalty factor value as the processing objects, firstly, the successful interaction probability and the failed interaction probability in the interaction probability set are normalized to eliminate the difference in the scale of different interaction types and generate a standardized probability value; then, the standardized success probability is multiplied by (1 - the dynamic penalty factor value), and the standardized failure probability is multiplied by the dynamic penalty factor value, and the preliminary trust value is calculated by the difference between the two; to enhance the timeliness of the trust value, a time decay coefficient is introduced (the weight of recent interactions is higher than that of distant interactions) to perform weighted correction on the preliminary trust value; finally, the corrected trust value is mapped to the [0,1] interval to generate a node direct trust value that can reflect the current trust level of the node in real time. This value not only reflects the overall trend of historical interactions, but also can quickly respond to the malicious behavior of the node through the penalty factor to achieve dynamic trust assessment.

[0086] Optionally, the "joint trust computation" in step 2 includes:

[0087] Step 61: Using the neighbor list of a node as the processing object, select single-hop nodes with trust values ​​exceeding the preset trust threshold to form an initial trust set, remove unstable nodes with historical trust jitter rates exceeding the preset jitter threshold, and generate a stable neighbor set.

[0088] Step 62: Using the stable neighbor set as the processing object, calculate the single-hop joint trust using the weighted average algorithm to generate the initial joint trust value;

[0089] Step 63: Using the initial joint trust value as the processing object, remove outliers using the sliding window algorithm to generate a smoothed joint trust value.

[0090] Preferably, step 61 is implemented as follows: taking the node's neighbor list as the processing object, firstly, extract the identifiers, historical trust value sequences (trust values ​​of the last 30 interactions), and interaction frequencies (average number of interactions per day) of all single-hop neighbor nodes from the list; dynamically set the trust threshold based on the overall network security level—the threshold is increased by 20% when the network is in a high-risk state and decreased by 10% when it is in a low-risk state, and neighbor nodes whose trust values ​​exceed the threshold three times in a row are selected to form an initial trust set; then, calculate the historical trust jitter rate of each node in the initial trust set, that is, the ratio of the standard deviation to the mean of the trust values ​​within the sliding window (the window size is dynamically adjusted with the interaction frequency, and the window is larger for nodes with frequent interactions), and remove nodes whose jitter rate exceeds the preset jitter threshold (such nodes have drastic fluctuations in trust value and poor stability); finally, generate a stable neighbor set composed of high-trust, low-fluctuation nodes. This set is evaluated by dynamic thresholds and adaptive jitter rates to ensure that the included neighbor nodes have both reliability and stability.

[0091] Preferably, step 62 is implemented as follows: taking a stable set of neighbors as the processing object, firstly, a weight is assigned to each neighbor node in the set—based on the interaction frequency between nodes (the more frequent the interaction, the higher the weight, up to a maximum of 0.3), the historical consensus accuracy of the neighbor node (the proportion of correct decisions when participating in consensus, weighted at 0.5), and the resource contribution of the neighbor node (such as the computing power support provided, weighted at 0.2), and a comprehensive weight of each node is generated through normalization; then, the current trust value of each neighbor node is multiplied by the corresponding comprehensive weight, the sum is divided by the total weight, and the initial value of the single-hop joint trust is calculated; to avoid individual high-weight nodes dominating the results, a "weight capping mechanism" is introduced (the weight of a single node does not exceed 0.2), ensuring that the calculation results reflect the trust status of most neighbors in a balanced way, and finally generating an initial joint trust value, which integrates the multi-dimensional performance of the neighbor nodes and is more valuable than simple averaging.

[0092] Preferably, step 63 is implemented as follows: taking the initial joint trust value as the processing object, firstly, a sliding window is set (the window length is automatically adjusted based on the frequency of change of the initial joint trust value; when the change is drastic, the window shrinks to 3 values, and when it is stable, it expands to 7 values), and the continuously generated initial joint trust values ​​are included in the window in chronological order; outliers in the window are identified by the "3σ criterion", that is, values ​​that deviate from the window mean by more than 3 times the standard deviation, which are determined to be anomalies caused by sudden interference; after removing outliers, the remaining values ​​are averaged using time decay (the weight of recent values ​​is 1.5 times that of distant values) to generate a smoothed joint trust value; at the same time, a "trust trend verification" is introduced. If the deviation of the smoothed value from the previous value exceeds 5%, a secondary verification is triggered (recalculating the weights of neighboring nodes) to ensure the robustness of the result; the finally generated smoothed joint trust value not only filters out instantaneous interference but also retains the trust change trend, and can better reflect the true state of group trust.

[0093] Optionally, the "total trust calculation" in step 2 includes:

[0094] Step 71: Using the node's direct trust value, the joint trust value generated in Step 6, and the trust level of the trusted identity infrastructure as the processing objects, set weight coefficients and generate a weight configuration set;

[0095] Step 72: Using the weight configuration set as the processing object, perform weighted fusion based on the total trust level to generate a fused trust value;

[0096] Step 73: Using the merged trust value as the processing object, map it to the preset trust evaluation range and verify its rationality to generate the final total trust evaluation value.

[0097] Preferably, step 71 is implemented as follows: taking the node direct trust value, the joint trust value generated in step 6, and the trust level of the trusted identity infrastructure as the processing objects, firstly, the characteristic differences among the three are analyzed—the node direct trust value reflects the real-time reliability of historical interactions between nodes, the joint trust value reflects the comprehensive evaluation of the group's neighbors, and the trust level of the trusted identity infrastructure represents the underlying reliability of the authoritative institution's certification; the initial weights are dynamically allocated based on the security level of the interaction scenario (e.g., in high-security control command interactions, the trust level of the trusted identity infrastructure is set to 0.4, the direct trust value to 0.35, and the joint trust value to 0.25; in ordinary data query scenarios, the weight of the direct trust value is increased to 0.4); then, a "trust stability coefficient" is introduced, adding a weight compensation of 0.05 for trust values ​​with small recent fluctuations (e.g., the direct trust value has a change rate of <5% for 5 consecutive times), and reducing the weight of trust values ​​with large fluctuations by 0.03, finally generating a weight configuration set containing dynamic adjustment rules and specific coefficients, which can adapt to the trust evaluation needs of different scenarios.

[0098] Preferably, step 72 is implemented as follows: taking the weight configuration set as the processing object, firstly, extract the dynamic weight coefficients and each trust value (direct trust value of nodes, joint trust value, and trust degree of trusted identity facilities) in the set, and standardize each trust value (mapped to the [0,1] interval); adopt the "weighted fusion + cross-validation" mechanism, first multiply each trust value with the corresponding weight and then sum them to obtain the preliminary fusion value; then correct the preliminary fusion value through cross-validation (e.g., the deviation rate between the direct trust value and the joint trust value must be <10%, otherwise the weight of the deviation item is finely adjusted a second time); to avoid a single high weight value dominating the result, a "weight balancing factor" is set - when the weight of a certain trust value is >0.5, its weight is automatically reduced by 0.1 and evenly distributed to the other two items, finally generating a fusion trust value that takes into account the multi-dimensional trust characteristics. This value reflects the guidance of the weight configuration and ensures the balance of the result through the verification mechanism.

[0099] Preferably, step 73 is implemented as follows: taking the fused trust value as the processing object, it is first mapped to a preset trust evaluation interval (e.g., [0,0.3) for low trust, [0.3,0.7) for medium trust, and [0.7,1] for high trust), and the interval boundary matching degree during mapping is recorded (e.g., the distance between the fused trust value and the midpoint of the interval; the closer the distance, the higher the matching degree); then, a reasonableness check is performed, comparing the changing trend of the last 3 fused trust values—if the current value deviates from the previous average by more than 20%, a backtracking check is initiated (recalculating the weight configuration set and fusion process) to check for any abnormal interference; after the check passes, the final total trust evaluation value is generated by combining the interval label and the matching degree (e.g., when the high trust interval is and the matching degree is greater than 0.8, the evaluation value is accompanied by a "strongly trustworthy" label). This evaluation value not only includes quantitative results, but also enhances the interpretability of the trust evaluation through trend check and labeling.

[0100] Optionally, the "link reliability calculation" in step 2 includes:

[0101] Step 81: Using the round-trip transmission time and packet loss rate of the historical interactions between nodes with a preset number of times as the processing object, calculate the average transmission delay and stability coefficient, and generate a set of link performance parameters;

[0102] Step 82: Using the link performance parameter set as the processing object, generate a link reliability score through reliability calculation;

[0103] Step 83: Using the link reliability score as the processing object, when the score is lower than the preset link reliability threshold, link switching is triggered to generate the optimal communication path.

[0104] Preferably, step 81 is implemented as follows: taking the round-trip transmission time and packet loss rate of historical interactions between nodes with a preset number of interactions (e.g., the most recent 50 interactions) as the processing object, the original data is first subjected to layered cleaning—extreme values ​​caused by instantaneous network storms (e.g., records with round-trip times exceeding 3 times the average) are removed, and valid interaction samples are retained; an "adaptive sliding window" (the window size is dynamically adjusted according to the interaction frequency, with a high-frequency interaction window set to 20 times and a low-frequency window set to 10 times) is used to calculate the average transmission delay, and the weight of recent data within the window is 1.2 times that of older data to enhance timeliness; the stability coefficient is calculated by the ratio of the standard deviation of the round-trip time within the window to the mean (the smaller the value, the more stable the link); at the same time, the packet loss rate is weighted and statistically analyzed, with the packet loss records of the most recent 10 interactions accounting for 60% of the weight and earlier records accounting for 40%, generating a set of link performance parameters including average transmission delay, stability coefficient, and weighted packet loss rate. This set, through dynamic windowing and layered cleaning, filters out accidental interference while retaining the true performance characteristics of the link.

[0105] Preferably, step 82 is implemented as follows: taking the link performance parameter set as the processing object, firstly, the average transmission delay, stability coefficient, and weighted packet loss rate in the parameter set are standardized (mapped to the [0,1] interval, where the smaller the delay, the smaller the stability coefficient, and the smaller the packet loss rate, the higher the corresponding standardized value); dynamically allocate weights based on the interaction type—for real-time control command interactions (such as switch operations), the average transmission delay weight is set to 0.4, the stability coefficient to 0.3, and the packet loss rate to 0.3; for non-real-time data interactions (such as log uploads), the packet loss rate weight is reduced to 0.2, and the stability coefficient is increased to 0.4; a "burst penalty factor" is introduced, if a sudden increase in packet loss rate occurs in the last 3 interactions (single increase > 20%), the current score is reduced by 5%; the standardized parameters are multiplied by their corresponding weights and summed to obtain a link reliability score of 0-100 points. The higher the score, the more reliable the link. This score achieves accurate quantification of the dynamic performance of the link through scenario-based weights and burst penalties.

[0106] Preferably, step 83 is implemented as follows: taking the link reliability score as the processing object, when the score is lower than the preset link reliability threshold (e.g., 60 points), the link switching mechanism is triggered; from the node's pre-stored candidate path pool (containing 3-5 links with different routes), paths with the current reliability score exceeding the threshold and a load rate (used bandwidth / total bandwidth) < 70% are selected; the candidate paths are sorted using a "two-factor sorting method"—the primary factor is the reliability score (weight 0.6), and the secondary factor is the historical switching success rate (weight 0.4), and the path with the highest overall ranking is selected as the optimal communication path; during the switching process, a "seamless transition mechanism" is enabled, maintaining short-term communication (approximately 200ms) on the original path while establishing a connection on the new path to avoid data interruption; finally, a switching report containing the optimal path identifier, switching time, and a performance comparison of the old and new paths is generated. This mechanism, through load awareness and seamless transition, reduces the risk of interaction interruption while ensuring reliability.

[0107] Optionally, the "fuzzy trust calculation" in step 2 includes:

[0108] Step 91: Using the total trust assessment value and link reliability score as the processing objects, the Mamdani fuzzy inference mapping is used to map them into a "high / medium / low trust" fuzzy set, generating a fuzzy feature set;

[0109] Step 92: Using the fuzzy feature set as the processing object, calculate the membership degree based on the triangular membership function, establish the inference rule of "high total trust degree and reliable link → high trust level", and generate fuzzy inference results;

[0110] Step 93: Using the fuzzy inference result as the processing object, the centroid method is used to defuzzify it and generate a quantified fuzzy trust evaluation value.

[0111] Preferably, step 91 is implemented as follows: taking the total trust assessment value and the link reliability score as the processing objects, the total trust assessment value is first divided into intervals according to a preset grading standard (such as low, medium, and high). Each interval corresponds to a different fuzzy subset (such as "low trust", "medium trust", and "high trust"). A boundary transition range is defined for each subset (such as "medium trust" including transition values ​​close to the low and high intervals). Similarly, the link reliability score is divided into three fuzzy subsets: "low reliability", "medium reliability", and "high reliability", with the same transition range set. The membership function of Mamdani fuzzy inference is used to calculate the membership degree of the total trust assessment value to each trust subset (such as a certain assessment value may belong to "medium trust" 60% and "high trust" 40%), and the membership degree of the link reliability score to each reliability subset. These membership degrees are combined with the corresponding fuzzy subset labels to generate a fuzzy feature set containing two-dimensional fuzzy features. This set breaks through the rigid classification of either / or and can reflect the comprehensive state of trust and link more delicately.

[0112] Preferably, step 92 is specifically implemented as follows: taking the fuzzy feature set as the processing object, firstly, the membership degree value of each fuzzy feature is calculated based on the triangular membership degree function (e.g., the membership degree of "high trust" is 0.8, and the membership degree of "high reliability" is 0.7). The higher the value, the more significant the feature. According to the security requirements of edge interaction of the power Internet of Things, multiple sets of inference rules are established. In addition to "high total trust and reliable link → high trust level", rules covering the entire combination are also included, such as "medium total trust and medium link reliability → medium trust level", "low total trust or low link reliability → low trust level", and "high total trust but low link reliability → medium-low trust level". The membership degree values ​​in the fuzzy feature set are substituted into the rule base, and the trigger strength of each rule is calculated using the "smallest and largest" method (e.g., the smallest membership degree in the antecedent of the rule is used as the trigger strength of the rule). The rule combination with the highest trigger strength and its corresponding output fuzzy subset (e.g., "high trust level") are selected to generate the fuzzy inference result. This result realizes flexible inference in complex scenarios through multi-rule coverage.

[0113] Preferably, step 93 is implemented as follows: taking the fuzzy inference result as the processing object, firstly, extract the output fuzzy subsets (such as "high trust level" and "medium trust level") and their corresponding trigger strengths (i.e., membership degrees) from the result; use the centroid method to defuzzify these fuzzy subsets, multiply the center value of each fuzzy subset (such as 0.8 for "high trust level" and 0.5 for "medium trust level") by the trigger strength, sum them, and then divide by the sum of the trigger strengths to obtain a precise quantified value; to ensure that the result fits the actual interaction scenario, a "security coefficient correction" is introduced—for interactions involving the control of key equipment, the quantified value is slightly adjusted upward (such as +0.1) to increase the security threshold, while the original value is maintained for ordinary data transmission; the final generated quantified fuzzy trust evaluation value retains the flexibility of fuzzy inference and satisfies the operability of security decision-making through precise quantification, realizing a seamless conversion from qualitative analysis to quantitative evaluation.

[0114] Optionally, step 3 specifically includes:

[0115] Step 31: Using the trust assessment result as the processing object, when the result reaches the preset security threshold, start end-to-end encrypted transmission and generate encrypted interactive data stream;

[0116] Step 32: Using the physical coordinates of the accessed resource as the processing object, perform fuzzing processing through random offset to generate virtual coordinates that hide the real location;

[0117] Step 33: Using encrypted interactive data streams and virtual coordinates as the processing objects, after the interaction is completed, calculate the communication overhead and false alarm rate indicators, and generate a performance verification report.

[0118] Preferably, step 31 is implemented as follows: taking the trust assessment result as the processing object, the result is first compared with a preset dynamic security threshold (this threshold is adjusted according to the real-time risk level of the power Internet of Things, such as when the system detects a network attack, the threshold is automatically increased by 10%); when the result reaches the threshold, the end-to-end encryption mechanism is triggered to generate a one-time session key (using a key derivation algorithm based on node identity and current timestamp to avoid key duplication); the session key is used to encrypt the interactive data in segments (each 1MB of data is a segment, and each segment is attached with an independent check code), and the interactive instruction type in the data header is processed using a reversible obfuscation algorithm; after encryption, each encrypted segment is numbered in sequence and inter-segment association information is attached to generate a complete encrypted interactive data stream. This data stream achieves anti-interception and anti-tampering capabilities for data transmission through layered encryption and dynamic keys.

[0119] Preferably, step 32 is implemented as follows: taking the physical coordinates of the accessed resource as the processing object, firstly, the precise latitude and longitude values ​​of the coordinates are extracted, and a random offset range is determined based on the security level of the resource (e.g., the offset range for special-grade protected resources is 500-1000 meters, and for ordinary resources it is 100-300 meters); an offset is generated within this range using a Gaussian distribution random algorithm (ensuring that the offset value is more likely to be distributed in the middle of the range, reducing the risk of exposure of extreme values), and the original coordinates are offset; to avoid the virtual coordinates exposing the real location in multiple interactions, a new random seed is generated for each interaction, and the offset direction is dynamically adjusted with the timestamp (e.g., offset eastward on even seconds, offset westward on odd seconds); the offset coordinates are format-converted (e.g., converted to the UTM coordinate system and truncated to three decimal places), and a virtual coordinate that hides the real location is generated. This coordinate, through dynamic range and probabilistic offset, ensures the accuracy requirements of interactive positioning while preventing the physical location of the resource from being reverse-engineered.

[0120] Preferably, step 33 is implemented as follows: taking the encrypted interactive data stream and virtual coordinates as the processing objects, the start time of data transmission, the transmission delay of each segment of encrypted data, and the number of retransmissions are recorded in real time during the interaction, and the total communication overhead (including the weighted sum of transmission time, bandwidth usage, and retransmission consumption) is calculated; after the interaction is completed, anomaly detection is performed on the log of this interaction, and the ratio of the number of interception events triggered by the security policy to the actual malicious behavior is calculated to generate a false alarm rate index; the communication overhead and false alarm rate are compared and analyzed with the preset performance benchmark value (based on the average value of similar historical interactions), and anomalies exceeding the benchmark value are marked and their causes are analyzed (such as abnormal overhead may be caused by link switching); finally, a performance verification report containing quantitative indicators, anomaly analysis, and optimization suggestions is generated. This report provides data support for subsequent security policy adjustments and achieves a dynamic balance between security and performance.

[0121] Preferably, step 31 is implemented as follows: taking the trust assessment result as the processing object, firstly, the "dynamic threshold decision engine" is started. This engine integrates a real-time attack feature library (recording the attack types and frequencies detected in the past 24 hours) and the node importance level (such as control nodes, collection nodes, and forwarding nodes) to generate differentiated security thresholds for different node types. Control nodes, due to their involvement in power scheduling, have a threshold 15% higher than collection nodes, and for each detected targeted attack on this node, the threshold temporarily increases by 5% (lasting 1 hour). When the trust assessment result exceeds the corresponding threshold, the "adaptive encryption suite" is triggered. First, device authentication based on Physically Unclonable Functions (PUF) is performed to ensure that both communicating parties are legitimate physical nodes and not forged terminals. After authentication is successful... The encryption strategy is selected based on the sensitivity level of the interactive data (e.g., device control commands are the highest level, and environmental monitoring data is the ordinary level): the highest level data adopts a combination mode of "post-quantum encryption algorithm + one-time pad" (resistant to quantum computing cracking), and the ordinary level data adopts the national cryptographic SM4 algorithm (balancing efficiency and security); to solve the key distribution problem, an "edge node group key negotiation" mechanism is introduced, in which three trusted edge nodes jointly generate session key fragments, and the two parties in the interaction need to collect at least two fragments to restore the key; when encrypting the data stream, a random perturbation value based on a chaotic sequence is inserted every 128 bytes, making the ciphertext more closely resemble random noise in statistical characteristics. The final encrypted interactive data stream can not only resist traditional attacks, but also has the ability to resist quantum computing and side-channel analysis.

[0122] Preferably, step 32 is specifically implemented as follows: taking the physical coordinates of the accessed resource as the processing object, a "coordinate privacy protection model" is first constructed. This model includes the physical security radius of the resource (set according to the equipment protection level, such as 500 meters for substations and 50 meters for smart meters) and spatiotemporal correlation constraints (the virtual coordinates of resources in the same area must maintain a reasonable relative position); a dual protection mechanism of "differential privacy + blockchain notarization" is adopted: the first step injects Laplace noise into the original coordinates, and the noise intensity is positively correlated with the security radius (the larger the security radius, the higher the noise intensity), ensuring that the probability of the real coordinates falling within the security radius around the virtual coordinates is not less than 95%; the second step, through "coordinate fragmentation" processing, splits the virtual coordinates into longitude fragments, latitude fragments, and... The verification fragments are stored in three different edge node blockchains. The fragments can only be temporarily aggregated to restore the virtual coordinates when both parties provide valid digital certificates. To prevent time-series analysis attacks, a "dynamic coordinate evolution" mechanism is introduced: different noise generation seeds are used for the same resource at different time periods (e.g., every hour), causing the virtual coordinates to drift irregularly, but the drift range is always constrained by the security radius. The generated virtual coordinates are attached with a "privacy budget" label, which records the number of times the coordinates have been queried. When the number reaches a threshold (e.g., 10 times), the coordinates automatically expire and a new virtual coordinate is generated. Budget control avoids coordinate leakage caused by multiple queries. The final generated virtual coordinates can meet the positioning needs of cross-domain interaction and ensure that attackers cannot deduce the real location of the resource through the coordinates.

[0123] Preferably, step 33 is implemented as follows: Taking the encrypted interactive data stream and virtual coordinates as the processing objects, a "full-link performance probe" is first deployed to record key indicators at the source node, relay node, and destination node of data transmission: the source node records encryption time (classified by encryption algorithm type, such as post-quantum encryption time, SM4 encryption time) and data compression rate; the relay node records forwarding latency and routing hop count; the destination node records decryption time and data verification success rate; these indicators are summarized through a distributed time-series database to calculate the "three-dimensional evaluation value" of communication overhead—time overhead (total transmission latency), computational overhead (total encryption and decryption time), and network overhead (total data transmission volume); in terms of security indicators, an "attack simulation verification" mechanism is introduced, injecting forged data packets into the interactive link through honeypot nodes, and statistically analyzing the system's response to the forged packets. By combining the recognition rate and interception response time with false interception records from normal interactions, a more accurate false alarm rate is generated (false alarm rate = number of falsely intercepted legitimate packets / (number of falsely intercepted legitimate packets + number of correctly intercepted attack packets)). To achieve a dynamic balance between performance and security, a "self-optimizing decision tree" is designed to automatically adjust parameters based on performance verification results: when encryption time accounts for more than 30% of the total overhead, the encryption algorithm is automatically downgraded for non-critical data; when the false alarm rate exceeds 5%, the feature weights of the anomaly detection model are updated. The final performance verification report includes a closed-loop analysis of "indicators-model-optimization," which not only presents the quantitative results of this interaction but also outputs parameter adjustment suggestions for the next interaction (such as recommended encryption algorithms, virtual coordinate update cycles, etc.). The hash value of the report is written to the blockchain for immutable evidence storage, providing a reliable basis for subsequent security strategy iterations.

[0124] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A power Internet of Things edge security interaction method, characterized in that, Comprise the following steps: Step 1: Take the initial interaction request initiated by the request security domain to the response security domain as the processing object, build a cross-domain interaction basic framework through the HotStuff consensus control center, fuse the historical trust data of the nodes and the authentication information of the trusted identity basic trust facility, and construct a multi-dimensional security protection strategy covering identity verification, permission control and data encryption; Step 2: Take the multi-dimensional security protection strategy as the processing object, execute the cross-domain interaction process based on the HotStuff consensus mechanism, generate a quantitative trust evaluation result through the hierarchical model of distributed trust calculation, joint trust calculation, total trust degree calculation, link reliability calculation and fuzzy trust calculation; Step 3, specifically comprising: Step 31: Take the trust evaluation result as the processing object, start end-to-end encrypted transmission when the result reaches the preset security threshold, and generate encrypted interaction data stream; Step 32: Take the physical coordinates of the accessed resource as the processing object, first build a "coordinate privacy protection model", which includes the physical security radius of the resource and the spatiotemporal correlation constraint; A dual protection mechanism of "differential privacy + blockchain storage": first, inject Laplace noise into the original coordinates, and the noise intensity is positively correlated with the security radius; The second step is to process the virtual coordinates by "coordinate fragmentation", which are divided into longitude fragments, latitude fragments and verification fragments, respectively stored in three different edge node blockchains, and only when both parties provide legal digital certificates, the virtual coordinates can be temporarily aggregated and restored; Introduce the "coordinate dynamic evolution" mechanism: the same resource uses different noise generation seeds in different time periods, so that the virtual coordinates show irregular drift, but the drift range is always constrained by the security radius; The generated virtual coordinates are attached with a "privacy budget" label, which records the number of times the coordinates have been queried, and when the number of times reaches the threshold, a new virtual coordinate is generated, and the final virtual coordinate can meet the positioning needs of cross-domain interaction and ensure that attackers cannot backtrack the real location of the resource through the coordinates; Step 33: Take the encrypted interaction data stream and virtual coordinates as the processing object, and after the interaction is completed, count the communication overhead and false positive rate indicators to generate a performance verification report.

2. The method of claim 1, wherein, The step 1 specifically comprises: Step 11: Take the initial interaction request initiated by the request security domain as the processing object, add interaction type, resource demand and digital signature identification, and send it to the response security domain through the edge gateway to generate an interaction request with identification; Step 12: Take the distributed node architecture of the HotStuff consensus control center as the processing object, define the role permissions and communication protocols of the request party, the response party and the consensus node, build a cross-domain interaction framework for three-party cooperation, and generate an interaction framework rule set; Step 13: Take the generated interaction framework rule set as the processing object, fuse the trust value data of the historical interaction of the nodes and the digital certificate authentication result of the trusted identity basic trust facility, and generate a multi-dimensional security protection strategy.

3. The method of claim 1, wherein, The step 2 "cross-domain security interaction based on HotStuff consensus mechanism" comprises: Step 21: In the event-driven framework of the HotStuff consensus algorithm, deploy three asynchronous threads of request processing, response feedback, and consensus events to realize parallel communication and event synchronization of heterogeneous nodes, and generate an asynchronous interaction mechanism. Step 22: In the asynchronous interaction mechanism, generate a fast consensus result through four-stage chain voting of pre-preparation, preparation, pre-commitment, and commitment.

4. The method of claim 3, wherein, The step 22 specifically includes: Step 221: In the asynchronous interaction mechanism, verify the legality of the interaction request in the pre-preparation stage, generate a proposal containing request details, and broadcast it to all consensus nodes to obtain a pre-preparation proposal; Step 222: In the pre-preparation proposal, verify the consistency of the proposal by each node in the preparation stage and return the voting result, and generate a preparation stage consensus when more than a preset proportion of nodes approve; Step 223: In the preparation stage consensus, the main node summarizes the results to form a temporary consensus in the pre-commitment stage and broadcasts a second confirmation to obtain a pre-commitment consensus; Step 224: In the pre-commitment consensus, when more than a preset proportion of nodes finally confirm, generate an unforgeable final consensus result.

5. The method of claim 1, wherein, The "distributed trust calculation" in the step 2 includes: Step 51: In the node historical interaction record, calculate the success interaction probability and failure interaction probability using the Bayesian probability model to generate an interaction probability set; Step 52: In the interaction probability set, introduce a dynamic penalty factor for malicious nodes to generate a dynamic penalty factor value; Step 53: In the interaction probability set and the dynamic penalty factor value, generate a node direct trust value through a direct trust value.

6. The method of claim 1, wherein, The "joint trust calculation" in the step 2 includes: Step 61: In the node's neighbor list, filter single-hop nodes with trust values exceeding a preset trust threshold to form an initial trust set, and remove unstable nodes with historical trust fluctuation rates exceeding a preset fluctuation threshold to generate a stable neighbor set; Step 62: In the stable neighbor set, calculate the single-hop joint trust using a weighted average algorithm to generate an initial joint trust value; Step 63: In the initial joint trust value, remove outliers through a sliding window algorithm to generate a smoothed joint trust value.

7. The method of claim 1, wherein, The "total trust degree calculation" in the step 2 includes: Step 71: In the node direct trust value, the joint trust value generated in step 6, and the trust degree of the trusted identity basic trust facility, set a weight coefficient to generate a weight configuration set; Step 72: In the weight configuration set, perform weighted fusion through the total trust degree to generate a fused trust value; Step 73: In the fused trust value, map it to a preset trust evaluation interval and verify its rationality to generate a final total trust degree evaluation value.

8. The method of claim 1, wherein, The "link reliability calculation" in the step 2 includes: Step 81: In the round-trip transmission time and packet loss rate of the historical interaction between nodes for a preset number of times, calculate the average transmission delay and stability coefficient to generate a link performance parameter set; Step 82: In the link performance parameter set, generate a link reliability score through reliability calculation; Step 83: Taking the link reliability score as the processing object, triggering the link switching when the score is lower than the preset link reliability threshold, and generating the optimal communication path.

9. The method of claim 1, wherein, The "fuzzy trust calculation" in the step 2 includes: Step 91: Taking the total trust evaluation value and the link reliability score as the processing objects, mapping to the "high / medium / low trust" fuzzy set through the Mamdani fuzzy reasoning, and generating the fuzzy feature set; Step 92: Taking the fuzzy feature set as the processing object, calculating the membership based on the triangular membership function, establishing the "high total trust degree and reliable link→high trust level" reasoning rule, and generating the fuzzy reasoning result; Step 93: Taking the fuzzy reasoning result as the processing object, de-fuzzifying by using the barycenter method, and generating the quantized fuzzy trust evaluation value.

Images