Blockchain-based data interaction security and privacy protection method and system

Abstract

The application provides a kind of data interaction security privacy protection method and system based on blockchain, which comprises the following steps: deploying blockchain consensus node in cloud to build main chain, and deploying computing node in double-layer trusted execution environment hardware to build sub-chain according to business type.Through cross-chain communication protocol, main chain-sub-chain architecture is established, and cross-chain smart contract is deployed.User data interaction request is received, and access or upload permission is granted after identity verification.Data fingerprint and operation log are generated and organized as Merkle tree structure.Data and log Merkle tree are stored in main chain-sub-chain architecture using DAG-based hierarchical storage architecture.The whole process ensures data security, privacy protection and traceability, and realizes efficient and reliable blockchain data management system.

Description

Technical Field

[0001] This invention belongs to the field of blockchain information protection technology, specifically relating to a blockchain-based method and system for data interaction security and privacy protection. Background Technology

[0002] With the popularization of internet technology and the deepening of informatization, data has become a key element driving economic growth and social development. Against this backdrop, all industries are actively promoting digital transformation, hoping to improve operational efficiency, optimize decision-making processes, and innovate business models through the collection, analysis, and utilization of data.

[0003] Traditional data management systems often employ a centralized architecture. While this architecture offers convenience in management and control, it frequently becomes a bottleneck when faced with large-scale, high-concurrency data interaction demands. Centralized systems are prone to becoming single points of failure; if the central node fails, the security and availability of the entire system will be severely impacted. Secondly, as the value of data becomes increasingly apparent, the demand for data security and privacy protection is growing. However, traditional security measures, such as simple encryption and access control mechanisms, often prove inadequate against complex network attacks and internal threats. Especially in scenarios involving multi-party data collaboration, achieving effective data sharing and utilization while protecting data privacy becomes a difficult balance to strike. Summary of the Invention

[0004] This invention provides a blockchain-based method and system for protecting data privacy during data interaction, in order to solve the problem that traditional data management systems struggle to guarantee data privacy and security during data interaction.

[0005] Firstly, the present invention provides a blockchain-based method for protecting the security and privacy of data interaction, applied to a data interaction management system. The data interaction management system includes a cloud server, a two-layer trusted execution environment (TEX) hardware, and a user-end server. Both the user-end server and the TEX hardware communicate with the cloud server through a secure communication channel created based on an end-to-end encryption mechanism. The method includes the following steps:

[0006] Multiple blockchain consensus nodes are deployed in the cloud server, and a blockchain main chain is built on the cloud server based on all the blockchain consensus nodes;

[0007] Multiple blockchain computing nodes for processing different business types are deployed in the two-layer trusted execution environment hardware. Based on all the blockchain computing nodes and according to the business type, multiple blockchain sub-chains are built in the two-layer trusted execution environment hardware.

[0008] Based on the cross-chain communication protocol, a communication connection is established between all the blockchain sub-chains and the blockchain main chain through the secure communication channel to form a main chain-sub-chain architecture, and cross-chain smart contracts are deployed in the main chain-sub-chain architecture;

[0009] The client server receives data interaction requests from target users and verifies the user authentication identity contained in the data interaction request. The user authentication identity is authenticated and issued by the blockchain computing node.

[0010] If the verification is successful, the target user is granted data access permission or data upload permission in the main chain-sub chain architecture according to the request type of the data interaction request, so that the target user can use the data access permission to access the target data stored in the main chain-sub chain architecture, or use the data upload permission to upload the target data in the main chain-sub chain architecture.

[0011] Generate a data fingerprint of the target data during the data interaction process, combine the data fingerprint and the data interaction request to generate a data operation log of the target data, and organize the data operation log into a log Merkle tree structure;

[0012] A hierarchical storage architecture based on a directed acyclic graph is adopted, in which all the target data and the log Merkle tree structure are stored hierarchically in the main chain-sub-chain architecture.

[0013] Optionally, before receiving the data interaction request from the target user through the client server, the following steps are further included:

[0014] A neural network-based user information processing model is deployed in the two-layer trusted execution environment hardware. The user information processing model includes an information feature extraction module, an information integrity verification module, an information credibility verification module, a user type classification module, and a noise injection module.

[0015] Obtain the user registration request sent by the user to be registered to the main chain-sub chain architecture from the client server;

[0016] Extract user information from the user registration request, input the user information into the user information processing model for information verification, and output the user type of the user to be registered based on the user information that has passed the information verification through the user information processing model;

[0017] Randomly generate a user key for the user to be registered, and store the user key in the main chain-sub chain architecture;

[0018] Based on the user type, a user authentication identity for the user to be registered is generated through the cross-chain smart contract. The user authentication identity is then issued to the user to be registered using the blockchain computing node, thus completing the user registration of the user to be registered in the main chain-sub-chain architecture.

[0019] Optionally, the information feature extraction module is used to extract information field features and information anomaly association features from the user information. The last shared feature layer of the information feature extraction module is connected to the information completeness verification module, the information credibility verification module, and the user type classification module, respectively. The information completeness verification module is used to output the completeness probability of the user information based on the information field features, and the information credibility verification module is used to output the credibility score of the user information based on the information anomaly association features.

[0020] The user information processing model further includes a decision-making unit and a gating unit. The output layer of the information integrity verification module is connected to the decision-making unit, and the output layer of the information credibility verification module is connected to both the decision-making unit and the user type classification module. The output layer of the decision-making unit is connected to the gating unit, and the output layer of the gating unit is connected to the user type classification module. The decision-making unit is used to output the verification result of the user information by combining the integrity probability and the credibility score. The gating unit is used to determine whether to output a module activation signal to the user type classification module based on the verification result. After receiving the module activation signal, the user type classification module is used to identify and output the user type corresponding to the user information by combining the credibility score and the information field features. The output layer of the user type classification module is connected to the noise injection module. The noise injection module is used to inject noise into the output result of the user type classification module based on the Laplace mechanism and according to a preset privacy budget. The information integrity verification module and the information credibility verification module interact with each other through a multi-head attention mechanism.

[0021] Optionally, storing the user key in the main chain-sub chain architecture includes the following steps:

[0022] The user key is divided into n key fragments using the Shamir secret sharing algorithm;

[0023] Each of the aforementioned key fragments is encrypted using a homomorphic encryption algorithm;

[0024] Based on the node status of the blockchain computing nodes, select m blockchain computing nodes as trusted computing nodes, where 2≤m<n;

[0025] The encrypted key fragments are distributed and stored to each of the trusted computing nodes;

[0026] A threshold signature-based key reconstruction protocol is created for all the trusted computing nodes. The key reconstruction protocol constrains that at least t trusted computing nodes need to cooperate to complete the user key reconstruction process, where t≤m.

[0027] Optionally, generating the user authentication identity of the user to be registered based on the user type and through the cross-chain smart contract includes the following steps:

[0028] Execute the cross-chain smart contract based on the user type to generate verifiable credentials for the user to be registered.

[0029] Based on the user information, the user attributes of the user to be registered are generated using an attribute description language that supports the definition of multi-dimensional access strategies, and the attribute encryption of the user attributes is completed using the CP-ABE encryption algorithm.

[0030] The verifiable credentials and the encrypted user attributes are combined to form the user identity of the user to be registered.

[0031] Add an authentication protocol based on zero-knowledge scope proof to the user identity;

[0032] The user key of the user to be registered is reconstructed from the main chain-sub chain architecture, and the user identity is signed using the user key to obtain the user authentication identity of the user to be registered.

[0033] Optionally, the method may further include the following steps:

[0034] The number of user authentication identities generated through the cross-chain smart contract is counted.

[0035] Whenever the number of generated contracts reaches a preset threshold, the contract code of the cross-chain smart contract is subjected to syntax analysis and semantic checks.

[0036] The cross-chain smart contract is updated by combining the analysis and inspection results of the syntax analysis and semantic inspection and by using preset adaptive update rules.

[0037] Optionally, granting the target user data access permission or data upload permission in the main chain-sub chain architecture based on the request type of the data interaction request, so that the target user can use the data access permission to access the target data already stored in the main chain-sub chain architecture, or enable the target user to use the data upload permission to upload the target data in the main chain-sub chain architecture, includes the following steps:

[0038] Determine whether the data interaction request is a data upload request or a data access request;

[0039] If it is the data upload request, then grant the target user data upload permission in the main chain-sub chain architecture, and obtain the target user's target data and the data access policy preset by the target user for the target data;

[0040] If the target data is encrypted by the target user using the user key, the target data and the data access policy are packaged and sent to the blockchain subchain, and the data upload process of the target data is completed through the blockchain computing node;

[0041] If the target data is not encrypted, the target data and the data access policy are packaged and sent to the blockchain main chain, and the data upload process of the target data is completed through the blockchain consensus node;

[0042] If it is the data access request, then the data access permission of the target user is determined and granted based on the user authentication identity of the target user;

[0043] Based on the data access permissions and the data access strategy of the data already stored in the main chain-sub chain architecture, the data storage location of the target data that the target user can access is fed back to the target user.

[0044] Optionally, the two-layer trusted execution environment hardware includes a hardware security module and trusted execution environment hardware.

[0045] In a second aspect, the present invention also provides a blockchain-based data interaction security and privacy protection system, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the blockchain-based data interaction security and privacy protection method as described in the first aspect.

[0046] Thirdly, the present invention also provides a computer-readable storage medium storing instructions, characterized in that, when executed by a processor, the instructions cause the processor to be configured to perform the blockchain-based data interaction security and privacy protection method described in the first aspect.

[0047] The beneficial effects of this invention are:

[0048] This invention employs a main-chain-sub-chain blockchain architecture, effectively addressing the problem of centralized systems becoming easy targets for single-point attacks. By distributing data of different business types across sub-chains, the risk of the overall system being compromised is significantly reduced, improving data security. This invention utilizes a two-layer trusted execution environment (TEA) hardware deployment of blockchain computing nodes, providing an isolated and secure environment for sensitive data processing, effectively preventing unauthorized access or tampering during processing. This hardware-level security significantly enhances the system's ability to resist advanced persistent threats and zero-day vulnerability attacks. Through the deployment of cross-chain communication protocols and cross-chain smart contracts, this invention achieves secure data interaction between different sub-chains, ensuring data isolation while improving the flexibility and efficiency of data utilization. This mechanism is particularly suitable for multi-party data collaboration scenarios, maximizing data value while protecting data privacy. This invention introduces a strict access control mechanism based on user authentication, combined with fine-grained management of data access permissions and data upload permissions, effectively preventing the risk of excessive data access. This not only enhances the system's defense against internal threats but also provides technical assurance for compliant data use. This invention also innovatively introduces the concepts of data fingerprints and data operation logs, organizing them into a Merkle tree structure, which provides reliable technical support for the full lifecycle tracking and auditing of data. Finally, this invention adopts a hierarchical storage architecture based on directed acyclic graphs, which not only improves the efficiency of data storage but also enhances data integrity and traceability. Attached Figure Description

[0049] Figure 1 This is a schematic diagram of the system structure of the data interaction management system in one embodiment of this application.

[0050] Figure 2 This is a flowchart illustrating a blockchain-based data interaction security and privacy protection method in one embodiment of this application.

[0051] Figure 3 This is a schematic diagram of the model structure of the user information processing model in one embodiment of this application. Detailed Implementation

[0052] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0053] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0054] Reference Figure 1 The blockchain-based data interaction security and privacy protection method disclosed in this invention is applied to a data interaction management system. The data interaction management system consists of three main components: a cloud server, a two-layer trusted execution environment hardware, and a user-end server. These components are interconnected through a secure communication channel based on an end-to-end encryption mechanism. The cloud server, as the system's central hub, deploys multiple blockchain consensus nodes and establishes the main blockchain chain, responsible for managing global information and coordinating various subsystems. The two-layer trusted execution environment hardware is the core security component of the system, comprising a hardware security module and the trusted execution environment hardware itself. The hardware security module provides basic hardware-level security protection, while the trusted execution environment hardware provides more advanced security functions. Multiple blockchain computing nodes are deployed in this two-layer structure, organized into multiple blockchain sub-chains according to different business types. Each sub-chain specializes in handling specific types of business logic and data operations, greatly improving the system's parallel processing capabilities and security. The user-end server, as the interface between the user and the system, is responsible for receiving and initially processing user requests. The entire system adopts a layered blockchain architecture of main chain and sub-chains. The main chain is deployed on a cloud server and is responsible for global consensus, while the sub-chains are deployed in a dual-layer trusted execution environment hardware to handle specific business logic. This architecture ensures both overall system consistency and provides sufficient flexibility. For storage, the system uses a layered storage architecture based on a directed acyclic graph (DAG), storing target data and operation logs (organized in a Merkle tree structure) in layers within the main chain-sub-chain architecture, improving data access efficiency and system scalability.

[0055] Reference Figure 2 , Figure 2 This is a flowchart illustrating a blockchain-based data interaction security and privacy protection method in one embodiment. It should be understood that, although... Figure 2 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 2At least some steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed alternately or in turn with other steps or at least a portion of the sub-steps or stages of other steps. For example Figure 2 As shown, the data interaction security and privacy protection method based on blockchain disclosed in this invention specifically includes the following steps:

[0056] S101. Deploy multiple blockchain consensus nodes on a cloud server, and build a blockchain main chain on the cloud server based on all blockchain consensus nodes.

[0057] In this step, a suitable consensus algorithm is first selected, such as Proof-of-Work (PoW), Proof-of-Stake (PoS), or Delegated Proof-of-Stake (DPoS). Taking PoS as an example, each node receives a block-producing weight based on the amount of cryptocurrency it holds and the duration of that holding. Next, blockchain node software, such as Ethereum's Geth or Hyperledger's Fabric, is installed on a cloud server and configured as necessary. Configuration includes setting network parameters, storage paths, and key management. Then, these nodes are launched and allowed to discover and connect to each other, forming a P2P network. After the network is established, the nodes begin generating, verifying, and synchronizing blocks according to the consensus algorithm. For example, in PoS, the node with the highest weight has a higher probability of being selected as a block-producing node, generating a new block and broadcasting it to other nodes for verification. After successful verification, the new block is added to the chain, enabling continuous growth of the blockchain. To ensure security, a multi-signature mechanism can be implemented, requiring each block to be confirmed by at least two-thirds of the nodes before final confirmation. Furthermore, a smart contract deployment and execution environment, such as the Ethereum Virtual Machine (EVM), is also required. This architecture provides a decentralized, immutable, and transparent foundation for data storage and interaction, laying the groundwork for subsequent sub-chains and cross-chain operations. A blockchain main chain built in this way can effectively manage the global state, handle cross-chain interactions, and provide security for the entire system.

[0058] S102. Deploy multiple blockchain computing nodes in a two-layer trusted execution environment hardware to handle different business types, and build multiple blockchain sub-chains in the two-layer trusted execution environment hardware based on all blockchain computing nodes and according to business types.

[0059] A two-layer trusted execution environment typically includes a Hardware Security Module (HSM) and a Trusted Execution Environment (TEE). This environment provides an isolated execution space, protecting sensitive data and computation processes from external interference. Based on this, corresponding blockchain computing nodes are configured according to different business needs (such as financial transactions, medical data sharing, and supply chain management). Each node needs to install specific blockchain software, such as Hyperledger Fabric for high-throughput transactions or Ethereum for complex smart contracts. Next, a separate subchain is created for each business type. For example, a financial transaction subchain might use the PBFT consensus algorithm for fast transaction confirmation, while a medical data sharing subchain might use zero-knowledge proof technology to protect patient privacy. The subchain creation process includes initializing the genesis block, configuring network parameters, and deploying smart contracts.

[0060] Each subchain has its own ledger structure and data model to adapt to specific business needs. To improve performance and privacy, sharding technology can be implemented to distribute different types of transactions across different subchains for processing. Furthermore, cross-chain communication interfaces need to be implemented on each subchain to prepare for subsequent interactions with the main chain. This multi-chain structure significantly improves the system's parallel processing capabilities and scalability while ensuring data isolation and security between different business processes. Each subchain can choose the most suitable consensus mechanism and data structure based on its own business characteristics, thereby maximizing processing efficiency while ensuring security.

[0061] S103. Based on the cross-chain communication protocol and through a secure communication channel, establish communication connections between all blockchain sub-chains and the blockchain main chain to form a main chain-sub-chain architecture, and deploy cross-chain smart contracts in the main chain-sub-chain architecture.

[0062] The first step involves designing and implementing a robust cross-chain communication protocol, such as Hash Time Lock Contracts (HTLC) or a relay chain solution. Taking HTLC as an example, it allows assets to be locked on different chains and ensures the atomicity of cross-chain transactions through hash locks and time locks. Secure communication channels can be established using TLS / SSL protocols, combined with asymmetric encryption and digital signature technologies to ensure the confidentiality and integrity of cross-chain communication. Building upon this, a bridge is created between each sub-chain and the main chain. This bridge is responsible for encoding, decoding, and routing cross-chain messages. For example, when sub-chain A needs to interact with sub-chain B, the message is first transmitted to the main chain and then forwarded to sub-chain B. To improve efficiency, a distributed message queue system, such as Apache Kafka, can be implemented to manage the asynchronous processing of cross-chain messages.

[0063] Next, cross-chain smart contracts are deployed within the main-chain-sub-chain architecture. These contracts need to be able to understand and process data formats and transaction types from different chains. For example, a cross-chain asset transfer contract might include the following logic: verifying asset lock-up proofs on the source chain, minting equivalent assets on the target chain, and recording the state of the cross-chain transaction on the main chain. To handle potential cross-chain transaction failures, a rollback mechanism is also needed to ensure system state consistency. Furthermore, zero-knowledge proof technologies, such as zk-SNARKs, can be introduced to enhance privacy protection in cross-chain transactions. Through this complex cross-chain architecture, the system can achieve seamless interaction between different business domains while maintaining the independence and security of each sub-chain, significantly improving the functionality and flexibility of the entire blockchain network.

[0064] S104. Receive data interaction requests from the target user through the client server and verify the user authentication identity contained in the data interaction request.

[0065] The client-side server needs to implement a secure API interface, supporting HTTPS and two-way authentication to prevent man-in-the-middle attacks and unauthorized access. When a user initiates a data interaction request, the request typically includes the user ID, operation type, target data identifier, and user authentication token. This token is issued by the blockchain computing node during user registration or login, using the JWT (JSON Web Token) format, and contains the user's identity information, permission level, and expiration time. The verification process first parses the JWT token and checks its signature validity (using asymmetric encryption algorithms such as RSA or ECDSA). Then, it verifies whether the token is valid and checks whether the user information it contains matches the user ID in the request. To prevent replay attacks, a nonce value can be added to the token, and it is ensured that this nonce has not been used during verification.

[0066] Next, the client-side server needs to interact with the blockchain network to verify the user's current state and permissions. This can be achieved by calling the user management smart contract on the main chain, which maintains the latest state of all users. For example, it can check whether a user is disabled or whether their permissions have changed. To improve verification efficiency, a distributed caching system (such as a Redis cluster) can be implemented to cache frequently used user authentication information and set reasonable expiration policies. Furthermore, behavioral analysis and risk assessment modules can be introduced to monitor user request patterns and identify potential abnormal behaviors. For example, if a user initiates a large number of requests in a short period, or if the requested data is significantly inconsistent with their historical behavior, the system may require additional authentication steps, such as two-factor authentication. Through this multi-layered, dynamic authentication mechanism, the system can effectively prevent various identity forgery and unauthorized access attacks, while providing a smooth access experience for legitimate users.

[0067] S105. If the verification is successful, grant the target user data access permission or data upload permission in the main chain-sub chain architecture according to the request type of the data interaction request, so that the target user can use the data access permission to access the target data stored in the main chain-sub chain architecture, or use the data upload permission to upload the target data in the main chain-sub chain architecture.

[0068] S106. Generate a data fingerprint of the target data during the data interaction process, combine the data fingerprint and the data interaction request to generate a data operation log of the target data, and organize the data operation log into a log Merkle tree structure.

[0069] Data fingerprints are typically generated using cryptographic hash functions such as SHA-256 or Blake2. For large datasets, block hashing can be used, dividing the data into fixed-size blocks (e.g., 4KB), calculating the hash value for each block, and then combining these hash values ​​to obtain the final data fingerprint. This method not only reduces computational complexity but also supports partial data updates. Data interaction requests usually include information such as operation type (e.g., read, modify, delete), timestamp, and user ID. Combining this information with the data fingerprint allows the construction of a complete data operation log entry. For example, a log entry might contain the following fields: {Operation ID, User ID, Operation Type, Timestamp, Data Fingerprint, Data State Before Operation, Data State After Operation}. To ensure the log's immutability, each log entry can be digitally signed using a user key.

[0070] Organizing these log entries into a Merkle tree structure offers several advantages. A Merkle tree is a binary tree where leaf nodes contain the hash value of the original data, and non-leaf nodes contain the hash values ​​of their children. The root node (Merkle root) represents a summary of the entire dataset. The process of building a Merkle tree is as follows: First, all log entries are arranged chronologically, and the hash value of each entry is calculated to become a leaf node. Then, the hash values ​​of parent nodes are calculated pairwise until the root node is obtained. This structure allows for efficient verification of the integrity of large amounts of data, requiring only O(log n) computational complexity to prove whether a log entry is included in the tree. Furthermore, Merkle trees support incremental updates; when a new log entry is added, only the hash values ​​along the path from the new leaf node to the root node need to be recalculated. To further enhance security, the Merkle root can be periodically (e.g., hourly or daily) recorded on the main chain, so that even if the entire subchain is tampered with, it can be detected through the records on the main chain. Through this sophisticated log management mechanism, the system can accurately track every data operation, providing a reliable basis for subsequent auditing, dispute resolution, and data recovery.

[0071] S107. A hierarchical storage architecture based on directed acyclic graphs is adopted to store all target data and log Merkle tree structures in a main chain-sub-chain architecture.

[0072] Among these, the Directed Acyclic Graph (DAG) structure, compared to traditional linear blockchains, supports parallel processing and higher throughput. In this architecture, each data item or transaction is represented as a node in the DAG, and nodes are connected by edges, representing relationships or dependencies between data. First, the target data is categorized according to business type, timestamp, or other criteria, with each category forming an independent DAG subgraph. For example, financial transaction data might form one subgraph, while user identity information might form another. Each data node contains metadata such as the hash value of the actual data, timestamp, and creator information. For large datasets, IPFS (InterPlanetary File System) can be used to store the actual content, while only IPFS addresses are stored in the DAG. A log Merkle tree structure is also integrated into the DAG, with each Merkle tree root node acting as a special node in the DAG, connected to related data nodes. This design allows for rapid verification of data operation history within a specific time period. To optimize storage and query efficiency, a tiered storage strategy can be implemented. The latest and most frequently accessed data is stored in a fast storage layer (such as SSDs), while historical data is gradually migrated to a slower but higher-capacity storage layer (such as HDDs or cloud storage). This migration process can be automatically triggered and managed through smart contracts.

[0073] In the main-chain-sub-chain architecture, the DAG structure is primarily deployed on the sub-chains to handle specific business data. The sub-chains periodically synchronize their DAG state summaries (such as the hash of the DAG root node at a specific point in time) to the main chain, forming a cross-chain data index. This design ensures both the independence and efficiency of sub-chain data processing while providing global consistency through the main chain. To support efficient data retrieval and verification, the system also needs to implement a complex indexing mechanism. Distributed indexing technologies, such as ElasticSearch clusters, can be used to build multi-dimensional indexes for the nodes in the DAG. Indexes can be based on multiple dimensions such as time, data type, and user ID, supporting complex query requirements. For example, quickly locating all data operations performed by a specific user within a specific time period.

[0074] Furthermore, to address the potential bloat issue of DAGs, a periodic compression mechanism can be implemented. For example, for data nodes older than a certain period, multiple related nodes can be merged into a single aggregation node, while retaining necessary verification information. This compression process requires a consensus mechanism to ensure agreement among all nodes. Regarding data consistency, an eventual consistency model is adopted. When new data or transactions are added to the DAG, they are first quickly confirmed in the local subchain and then gradually propagated to the entire network. By setting an appropriate number of confirmation layers, a balance can be struck between efficiency and security. Through this complex storage architecture based on DAGs, the system can achieve high-throughput, low-latency data management while ensuring data integrity and security. It provides flexible storage and access modes for different types of data and operations, while ensuring global consistency of the entire system through periodic synchronization with the main chain. This design is well-suited for handling large-scale, high-frequency data interaction scenarios, such as complex applications like IoT data collection and financial transaction processing.

[0075] In one implementation, the following steps are included before receiving the data interaction request from the target user through the client server:

[0076] A neural network-based user information processing model is deployed in a two-layer trusted execution environment hardware. The user information processing model includes an information feature extraction module, an information integrity verification module, an information credibility verification module, a user type classification module, and a noise injection module.

[0077] Obtain the user registration request sent by the user to the main chain-sub chain architecture from the client server;

[0078] Extract user information from user registration requests, input the user information into the user information processing model for information verification, and output the user type of the user to be registered based on the user information that has passed the information verification through the user information processing model;

[0079] Randomly generate user keys for users to be registered and store the user keys in the main chain-sub chain architecture;

[0080] Based on user type, a user authentication identity is generated for the user to be registered through a cross-chain smart contract. The user authentication identity is then issued to the user to be registered using blockchain computing nodes, thus completing the user registration of the user to be registered in the main chain-sub-chain architecture.

[0081] In this implementation, the two-layer trusted execution environment typically includes a Hardware Security Module (HSM) and a Trusted Execution Environment (TEE), such as Intel SGX or ARM TrustZone, providing isolated execution spaces. The user information processing model employs a deep neural network architecture, containing multiple functional modules. The information feature extraction module uses a convolutional neural network (CNN) to extract key features of user information; the information integrity verification module utilizes a recurrent neural network (RNN) to check the coherence and completeness of information; the information credibility verification module combines attention mechanisms and graph neural networks (GNNs) to analyze the inherent correlation of information; the user type classification module uses a multilayer perceptron (MLP) for classification; and the noise injection module adds random noise based on differential privacy principles. Model training employs a federated learning method to ensure privacy and security. The deployment process includes model encryption, secure loading, and runtime integrity verification to ensure that the model itself is not tampered with or stolen.

[0082] The user registration process begins with obtaining the registration request from the client server. The client server receives the registration information submitted by the user, including username, password hash, email address, and identity verification, through a secure API interface (such as HTTPS). The server first performs basic format validation and protection measures, such as checking input validity and implementing rate limiting to prevent brute-force attacks. Then, the server encrypts the request (using asymmetric encryption algorithms such as RSA) and adds a digital signature to ensure the confidentiality and integrity of the data during transmission. The request is then sent to the access nodes in the main chain-sub-chain architecture through a predefined secure channel. The access nodes verify the signature and origin of the request, decrypt it, and forward the request content to the appropriate processing module. The entire process employs an asynchronous processing mechanism, using message queues (such as RabbitMQ) to manage a large number of concurrent requests, improving system throughput and response speed.

[0083] Next, user information is extracted from user registration requests and input into the user information processing model for verification. Specifically, regular expressions and specific parsing algorithms are first used to extract structured user information from the requests. The extracted information undergoes preliminary data cleaning and standardization, such as removing extra spaces and standardizing date formats. Then, the processed information is converted into numerical vectors suitable for neural network input, for example, using word embedding techniques to convert text information into dense vectors. These vectors are then sequentially input into various modules of the user information processing model. The model runs in a trusted execution environment to ensure the security of the processing. The information feature extraction module and the integrity verification module process the input in parallel, and then pass the results to the integrity verification module. The integrity verification module integrates the outputs of the first two modules and performs in-depth analysis using a pre-trained knowledge graph. Finally, the user type classification module classifies users based on the outputs of the previous modules and combined with historical data. The entire process uses batch processing to improve efficiency. The verification results include an information integrity score, an integrity score, and a predicted user type, which are used in subsequent decision-making processes.

[0084] Then, a user key is randomly generated and stored in the main-chain-sub-chain architecture. The key generation process uses a cryptographically secure random number generator (CSPRNG), such as the Fortuna algorithm, to generate a high-entropy random byte sequence. This sequence is used as a seed to generate the actual user key pair using a key derivation function (KDF), such as the HKDF. Typically, a public-private key pair (e.g., using the ECC algorithm) and a symmetric encryption key (e.g., AES-256) are generated. To enhance security, Shamir's SecretSharing algorithm is used to divide the private key into multiple shares, each stored on a different sub-chain. Each share is then encrypted using a threshold encryption scheme, ensuring that the complete private key can only be reconstructed under specific conditions (e.g., multi-party authorization). The public key and the encrypted symmetric key are stored directly on the main chain, associated with the user's unique identifier. The entire storage process is implemented through smart contracts, ensuring the atomicity and consistency of operations. This distributed storage scheme improves security while guaranteeing fast access and use of the key when needed.

[0085] Finally, based on user type, a user authentication identity is generated via a cross-chain smart contract and issued to the user using blockchain computing nodes, completing the registration process. Specifically, firstly, an appropriate smart contract template is selected based on the user type. This template predefines the permission and attribute structures for different user types. A unique identity identifier is generated using a Verifiable Random Function (VRF) to ensure its unpredictability. Then, user information, public keys, and permissions are encoded into the contract state. During contract execution, a zero-knowledge proof library is invoked to generate proof of the user's identity, enhancing privacy protection. The generated authentication identity includes a JWT-formatted token containing encrypted user information, permission statements, and an expiration time. The token is signed using the blockchain network's private key to ensure its unforgeability. Finally, the authentication identity is sent to the user through a secure channel, while the hash value of the authentication event is recorded on the main chain for subsequent auditing. The entire process is executed synchronously between the main chain and relevant sub-chains via a cross-chain protocol, ensuring data consistency.

[0086] In one embodiment, reference is made to Figure 3 The user information processing model adopts a deep neural network architecture, comprising multiple functional modules, mainly consisting of an information feature extraction module, an information completeness verification module, an information credibility verification module, a decision unit, a gating unit, a user type classification module, and a noise injection module. The information feature extraction module uses a convolutional neural network (CNN) structure to extract key features from the raw user information. The input to the information feature extraction module is the raw user information, and the output includes information field features and information anomaly correlation features. Information field features reflect the semantic features of each field of the user information, while information anomaly correlation features reflect the abnormal correlation patterns between fields. The specific layer structure is as follows:

[0087] Input layer: Receives raw user information, with dimensions (batch_size, input_length, embedding_dim), where batch_size is the batch size, input_length is the length of the input sequence, and embedding_dim is the embedding dimension of each element.

[0088] The first convolutional layer uses 64 3x1 convolutional kernels with a stride of 1 and "same" padding. This layer is used to capture local features. The convolution operation can be represented as: output = conv(input, kernel) + bias, where conv represents the convolution operation, kernel is the convolutional kernel, and bias is the bias term.

[0089] The first activation layer uses the ReLU (Rectified Linear Unit) activation function, with the formula f(x) = max(0, x). This layer introduces non-linearity, increasing the model's expressive power.

[0090] The first max-pooling layer has a pooling size of 2x1 and a stride of 2. Pooling operations can reduce feature dimensionality and enhance the model's translation invariance.

[0091] The second convolutional layer uses 128 3x1 convolutional kernels, with other settings identical to the first convolutional layer. This layer can capture higher-level features.

[0092] The second activation layer also uses the ReLU activation function.

[0093] Second max pooling layer: Set the same as the first pooling layer.

[0094] The third convolutional layer uses 256 3x1 convolutional kernels, with other settings remaining unchanged. This layer can extract more abstract features.

[0095] Third activation layer: ReLU activation function.

[0096] Global average pooling layer: compresses the feature map into a one-dimensional vector, retaining the average value of each channel.

[0097] The first fully connected layer has an output dimension of 512 and uses the ReLU activation function. Its purpose is to integrate the features extracted earlier.

[0098] The second fully connected layer (shared feature layer) has an output dimension of 256 and uses the ReLU activation function. The output of this layer will serve as the input to subsequent modules, representing information field features and information anomaly correlation features, respectively.

[0099] The information integrity verification module employs a recurrent neural network (RNN) structure, specifically a long short-term memory (LSTM) network. This module receives information field features as input, captures the temporal dependencies between information fields through a recurrent structure, and outputs the integrity probability of the user information to verify its completeness. The specific layer structure is as follows:

[0100] Input layer: Receives information field features, with dimensions (batch_size, sequence_length, feature_dim).

[0101] The first LSTM layer contains 128 hidden units and returns the complete sequence. The core formula of the LSTM unit is as follows:

[0102] f_t=σ(W_f·[h_{t-1},x_t]+b_f)

[0103] i_t=σ(W_i·[h_{t-1},x_t]+b_i)

[0104] o_t=σ(W_o·[h_{t-1},x_t]+b_o)

[0105] c_t=tanh(W_c·[h_{t-1},x_t]+b_c)

[0106] c_t=f_t c_{t-1}+i_t c_t

[0107] h_t=o_t tanh(c_t)

[0108] Where f_t, i_t, and o_t are the forget gate, input gate, and output gate, respectively; c_t is the cell state; h_t is the hidden state; and σ is the sigmoid function. This represents element-wise multiplication.

[0109] The second LSTM layer contains 64 hidden units and also returns the complete sequence. This layer can capture higher-level temporal dependencies.

[0110] Fully connected layer: Output dimension is 1, using the Sigmoid activation function. This layer compresses the LSTM output into a value between 0 and 1, representing the completeness probability.

[0111] The information credibility verification module combines an attention mechanism and a graph neural network (GNN). The attention mechanism weights abnormally correlated features of the information, highlighting important features, while the GNN models the relationship graph between information fields, analyzing inherent correlations, and ultimately outputs a credibility score for the user information, used to evaluate its credibility. The specific layer structure is as follows:

[0112] Graph Construction Layer: Constructs a graph structure based on information anomaly association features. This step transforms user information into a graph form, where nodes represent information fields and edges represent the relationships between fields.

[0113] The first graph convolutional layer has an output dimension of 128 and uses the ReLU activation function. The graph convolution operation can be represented as:

[0114] H^(l+1)=σ(D^(-1 / 2)AD^(-1 / 2)H^(l)W^(l))

[0115] Where A is the adjacency matrix, D is the degree matrix, H^(l) is the node feature of the l-th layer, and W^(l) is the learnable weight matrix.

[0116] The second convolutional layer has an output dimension of 64 and uses the ReLU activation function. This layer can capture higher-order relationships between nodes.

[0117] Global pooling layer: aggregates node features into graph-level features. Commonly used pooling methods include average pooling and max pooling.

[0118] Attention layer: Employs a multi-head attention mechanism with 8 heads, each with a dimension of 32. The formula for calculating multi-head attention is:

[0119] MultiHead(Q,K,V)=Concat(head_1,...,head_h)W^O

[0120] Among them, head_i=Attention(QW_i^Q,KW_i^K,VW_i^V)

[0121] Fully connected layer: Output dimension is 1, using the sigmoid activation function. This layer compresses the output of the attention layer into a value between 0 and 1, representing the confidence score.

[0122] A multi-head attention mechanism is also built between the information integrity verification module and the information credibility verification module to enable information interaction between them. Its structure can be described as follows:

[0123] Input: Feature representations from two modules.

[0124] Linear transformation: converts the input into a query (Q), key (K), and value (V).

[0125] Attention calculation: For each head, calculate the attention weights and aggregate the value vectors.

[0126] Concatenation: Concatenate the outputs of all heads together.

[0127] Linear transformation: Maps the concatenated result to the desired output dimension.

[0128] The decision unit is a multilayer perceptron (MLP) that receives completeness probability and credibility score as input and outputs the verification result of user information. This unit is used to integrate the completeness probability and credibility score to make the final verification decision. The specific layer structure is as follows:

[0129] Input layer: receives completeness probability and credibility score, with a dimension of 2.

[0130] First hidden layer: 32 neurons, using the ReLU activation function. The computation of this layer can be represented as:

[0131] h_1 = ReLU(W_1x + b_1), where x is the input vector, W_1 is the weight matrix, and b_1 is the bias vector.

[0132] The second hidden layer consists of 16 neurons, using the ReLU activation function. The calculation method is similar to the first hidden layer.

[0133] Output layer: 1 neuron, using the sigmoid activation function. Outputs a value between 0 and 1, representing the validation result.

[0134] The gating unit is a simple threshold judgment module that determines whether to activate the user type classification module based on the verification result of the decision unit. Its structure can be described as follows:

[0135] Input: Receive the output value from the decision-making unit.

[0136] Threshold comparison: If the input value is greater than the preset threshold (e.g., 0.5), output 1 (activation signal); otherwise output 0.

[0137] Output: A binary value, where 1 indicates activation and 0 indicates deactivation.

[0138] The user type classification module also adopts an MLP structure. After receiving an activation signal, it combines the credibility score and information field features to classify the user and output the user type. The specific layer structure is as follows:

[0139] Input layer: Receives credibility scores and information field features, with a total dimension of 257 (1+256).

[0140] First hidden layer: 128 neurons, using the ReLU activation function.

[0141] The second hidden layer consists of 64 neurons, using the ReLU activation function.

[0142] Output layer: n neurons (n ​​is the number of user types), using the Softmax activation function. The formula for calculating the Softmax function is:

[0143] softmax(x_i)=exp(x_i) / Σ_jexp(x_j)

[0144] This ensures that the sum of the output values ​​is 1, which can be interpreted as the probability distribution of each user type.

[0145] The noise injection module, based on the Laplace mechanism, adds random noise to the user type classification results according to a preset privacy budget ε to achieve differential privacy protection. This module implements differential privacy protection based on the Laplace mechanism. Its structure can be described as follows:

[0146] Input: Receive user type classification results.

[0147] Noise Generation: Generate random noise following a Laplace distribution Lap(0, 1 / ε), where ε is a preset privacy budget. The probability density function of the Laplace distribution is:

[0148] f(x|μ,b)=(1 / (2b)) exp(-|x-μ| / b)

[0149] Where μ is the position parameter (0 in this example) and b is the scale parameter (1 / ε in this example).

[0150] Noise addition: Adds generated noise to the classification results.

[0151] Output: User type classification results with noise.

[0152] In summary, the data processing flow of the user information processing model is as follows: First, the raw user information is input into the information feature extraction module, which processes it using a CNN to obtain information field features and information anomaly association features. The information field features are simultaneously input into the information completeness verification module and the user type classification module, while the information anomaly association features are input into the information credibility verification module. The information completeness verification module uses an RNN structure to process the information field features and outputs the completeness probability; the information credibility verification module uses a GNN structure to process the information anomaly association features and outputs the credibility score. Simultaneously, the two verification modules interact through a multi-head attention mechanism to enhance feature representation capabilities. The completeness probability and credibility score are input into the decision unit, which outputs the verification results. The verification results are then judged by a gating unit to determine whether to activate the user type classification module. If activated, the user type classification module combines the credibility score and information field features to perform classification and output the user type. Finally, a noise injection module adds random noise to the classification results to obtain the final user type output.

[0153] The model training employs a federated learning approach to protect user privacy. Specifically, multiple participants train the model on local data, exchanging only model parameters and not sharing the original data. The central server aggregates the parameters, updates the global model, and then redistributes it to the participants for the next round of training. The training objective is to minimize the weighted sum of information completeness verification error, information credibility verification error, and user type classification error. To improve model robustness, adversarial training and data augmentation techniques can be used during training. During model inference, the input data is first preprocessed, including data cleaning and standardization. Then, it is processed sequentially through each module, ultimately outputting user types with differential privacy protection. Throughout the process, the model can also output intermediate results such as completeness probability and credibility score, providing more evidence for decision-making. The advantages of this model are: 1) multi-module collaborative processing for comprehensive verification of user information; 2) combination of deep learning and graph structure to improve feature extraction and relationship modeling capabilities; 3) differential privacy mechanism to protect user privacy; 4) federated learning method to achieve distributed training with data remaining locally.

[0154] In one implementation, storing the user key in the main chain-sub chain architecture includes the following steps:

[0155] The user key is divided into n key fragments using the Shamir secret sharing algorithm;

[0156] Each key fragment is encrypted using a homomorphic encryption algorithm;

[0157] Based on the node status of the blockchain computing nodes, select m blockchain computing nodes as trusted computing nodes, where 2≤m<n;

[0158] The encrypted key fragments are distributed and stored to various trusted computing nodes;

[0159] Create a threshold signature-based key reconstruction protocol for all trusted computing nodes. The key reconstruction protocol constrains that at least t trusted computing nodes need to cooperate to complete the user key reconstruction process, where t≤m.

[0160] In this implementation, the Shamir secret sharing algorithm is based on the principle of polynomial interpolation. First, a large prime number p is selected as a finite field. Then, a polynomial f(x) of degree t-1 is randomly generated, where f(0) equals the key to be segmented. Next, n non-zero points x1, x2, ..., xn are selected, and the corresponding f(x1), f(x2), ..., f(xn) are calculated as n key fragments. For example, for a 128-bit key, p can be chosen as a prime number greater than 2^128, and the key can be considered as f(0). A polynomial such as f(x) = k + a1x + a2x^2 + ... + at-1x^(t-1) mod p can be generated, where k is the original key and ai are random coefficients. By calculating f(1), f(2), ..., f(n), n key fragments are obtained. This method ensures that the original key can only be reconstructed when at least t fragments are simultaneously available, greatly enhancing security. Simultaneously, since the size of each fragment is the same as the original key, storage efficiency is also guaranteed.

[0161] Encrypting each key fragment using a homomorphic encryption algorithm allows for specific computational operations on the encrypted data while protecting the key fragments. Commonly used homomorphic encryption algorithms include the Paillier encryption system or the BGV scheme. Taking the Paillier algorithm as an example, first, two large prime numbers p and q are generated, and n = pq and λ = lcm(p-1, q-1) are calculated. A random integer g is chosen such that gcd(L(g^λmodn^2), n) = 1, where L(x) = (x-1) / n. The public key is (n, g), and the private key is λ. The encryption process is c = g^m. r^n mod n^2, where m is the key fragment and r is a random number. This encryption method allows addition operations to be performed without decryption, i.e., E(m1). E(m2) = E(m1 + m2). For each key fragment, a different random number r is used for encryption to further enhance security. Homomorphic encryption not only protects the confidentiality of key fragments but also provides the foundation for subsequent secure computation and key reconstruction.

[0162] Selecting m blockchain computing nodes as trusted computing nodes based on their node status is a crucial step in ensuring the security and efficiency of key management. The selection process considers multiple factors, including node computing power, network connection quality, historical reputation, and current load. Multi-attribute decision-making methods, such as the Analytic Hierarchy Process (AHP) or TOPSIS, can be used to calculate a comprehensive score for each node. For example, a scoring function S = w1C + w2N + w3R + w4L can be defined, where C, N, R, and L represent computing power, network quality, reputation, and load, respectively, and wi represents the corresponding weight. The m nodes with the highest scores are selected as trusted computing nodes. To dynamically adapt to network conditions, a periodic re-evaluation mechanism can be implemented, such as evaluating and adjusting every certain number of blocks. Selecting nodes with a score of 2 ≤ m < n ensures the system's fault tolerance and decentralization, resisting partial node failures or attacks while avoiding single-point control risks.

[0163] Distributing and storing encrypted key fragments across trusted computing nodes is the core step in implementing distributed key management. The distribution process employs a secure multi-party computation protocol, ensuring that each node receives only the specified encrypted fragment and cannot access other fragments or deduce the original key. Specifically, this can be achieved using a combination of Shamir secret sharing and homomorphic encryption. First, each encrypted fragment is further divided using the Shamir scheme, generating multiple sub-fragments. Then, these sub-fragments are sent to different trusted nodes via a secure channel (such as TLS / SSL). Upon receiving a sub-fragment, each node partially decrypts it using its own private key and stores the result in its secure storage area (such as a hardware security module, HSM). To enhance availability, a redundant storage strategy can be implemented, where each fragment is backed up on multiple nodes. Simultaneously, a version control mechanism is implemented to ensure that the fragment versions are consistent across all nodes. This distributed storage scheme significantly improves system security and reliability; even if some nodes are compromised, attackers cannot obtain sufficient information to reconstruct the key.

[0164] Creating a threshold signature-based key reconstruction protocol for all trusted computing nodes is the last line of defense for ensuring secure key use. This protocol, based on an (t, m) threshold scheme, requires at least t nodes to participate in key reconstruction. A specific implementation can combine Shamir's threshold signature scheme with homomorphic encryption. First, a shared public key is generated, with each node holding a portion of the private key. When key reconstruction is needed, a reconstruction request is initiated, including the purpose of the operation, a timestamp, and a random challenge. Participating nodes sign the request using their respective portions of the private key and submit partial decryption results of the encrypted fragments. After collecting at least t valid signatures and partial decryption results, the original key is reconstructed using Lagrange interpolation. The entire process takes place in a secure multi-party computation environment, ensuring that intermediate results are not leaked. Simultaneously, an audit log mechanism is implemented to record detailed information for each reconstruction operation, facilitating subsequent tracking and analysis. This protocol ensures both the security of key reconstruction and provides sufficient flexibility to handle various use cases.

[0165] In one implementation, generating the user authentication identity of a user to be registered based on user type and through a cross-chain smart contract includes the following steps:

[0166] Execute cross-chain smart contracts based on user type to generate verifiable credentials for users to register.

[0167] Based on user information, the system uses an attribute description language that supports multi-dimensional access strategy definition to generate user attributes for users to be registered, and uses the CP-ABE encryption algorithm to encrypt the user attributes.

[0168] The verifiable credentials and encrypted user attributes are combined to form the user identity of the user to be registered.

[0169] Add an authentication protocol based on zero-knowledge scope proofs to user identities;

[0170] The user key of the user to be registered is reconstructed from the main chain-sub chain architecture, and the user identity is signed using the user key to obtain the user authentication identity of the user to be registered.

[0171] In this implementation, executing cross-chain smart contracts based on user type to generate verifiable credentials for users to register is a complex process. First, a corresponding smart contract template is selected from the cross-chain smart contracts based on the user type. This template predefines the permission and attribute structures for different user types. The contract execution environment spans the main chain and related sub-chains, utilizing cross-chain communication protocols such as Hash Time Lock Contracts (HTLC) to ensure data consistency. During contract execution, a Verifiable Random Function (VRF) is invoked to generate a unique credential identifier, ensuring its unpredictability. The credential content includes information such as user type, permission level, and validity period, and is digitally signed using on-chain public key infrastructure (PKI). Finally, the credential content and signature are combined into a verifiable credential, using a standard format such as JSON Web Token (JWT). This credential not only contains user identity information but also allows for cryptographic verification of its authenticity and integrity, significantly enhancing the security and trustworthiness of identity management.

[0172] Based on user information, generating user attributes for registered users using an attribute description language that supports multi-dimensional access policy definitions, and then encrypting these attributes using the CP-ABE encryption algorithm, are key steps in protecting user privacy. First, user attributes are defined using an attribute description language such as XACML, including multi-dimensional information such as identity characteristics, permission levels, and organizational affiliation. For example, an attribute expression like "role:engineer AND clearance:secret AND department:R&D" can be defined. Then, encryption is performed using the CP-ABE (Ciphertext-Policy Attribute-Based Encryption) algorithm. CP-ABE works by embedding the access policy into the ciphertext; only users with a set of attributes that satisfy the policy can decrypt it. Specific steps include: setting global parameters, generating a master key and public key, generating a user key based on the attributes, and finally encrypting the attribute information using the public key and the access policy. This method not only protects the privacy of user attributes but also achieves fine-grained access control, ensuring that only authorized entities can access specific user attribute information.

[0173] Combining verifiable credentials and encrypted user attributes to form a complete and secure user identity for a user to be registered is the process of creating a user identifier. This step first serializes the verifiable credentials and encrypted user attributes generated in the previous two steps, typically using structured data formats such as JSON or Protocol Buffers. Then, a cryptographic hash function (such as SHA-256) is used to calculate the combined hash value of these two data parts, serving as a unique identifier for the user. Next, a data structure containing this identifier, verifiable credentials, and encrypted attribute references is constructed, forming the user's complete identity representation. To enhance security, timestamps and random challenge values ​​can be used to prevent replay attacks. Finally, this identity structure is serialized and signed using a digital signature algorithm (such as ECDSA) to ensure its integrity and non-repudiation. This combination method guarantees the verifiability of identity information, protects the privacy of sensitive attributes, and provides a flexible access control mechanism.

[0174] Adding zero-knowledge proof-based authentication protocols to user identities is a crucial step in enhancing privacy. These protocols allow users to prove they possess certain attributes or meet certain conditions without revealing the specific attribute values. The implementation employs zero-knowledge proof systems such as zk-SNARKs or Bulletproofs. First, a set of assertions is defined, such as "age between 18 and 65 years old" or "credit score above 700." Then, an arithmetic circuit is constructed using these assertions, transforming user attributes into the circuit's input. The prover (user) generates a proof using their private attribute information and the publicly available circuit, which the verifier can verify without knowing the specific attribute values. A concrete implementation can use protocols like Groth16, including setup, proof generation, and verification phases. This approach not only protects user privacy but also significantly reduces the amount of sensitive information that needs to be transmitted and stored, while ensuring the reliability of authentication.

[0175] The final step in completing user registration is to reconstruct the user key of the user to be registered from the main chain-sub chain architecture, and then use the user key to sign the user's identity to obtain the user's authentication identity. First, a key reconstruction protocol is triggered, requiring the collaboration of at least t trusted computing nodes. Each participating node provides its key fragments and partial signatures. The system uses a threshold signature scheme (such as Shamir's threshold scheme) to combine these parts and reconstruct the complete user key. The reconstruction process is carried out in a secure multi-party computation environment to ensure that intermediate results are not leaked. Next, the reconstructed user key is used to digitally sign the previously generated user identity, typically using the Elliptic Curve Digital Signature Algorithm (ECDSA). The signing process involves generating a random number k, calculating a point R = kG on the curve (G is the base point), and then calculating the signature value s = k^-1(H(m) + r). The signature (r, s) modulo n is used, where H(m) is the message hash and r is the x-coordinate of point R. Finally, the signature (r, s) is combined with the user's identity information to form a complete user authentication identity. This process not only ensures the authenticity and integrity of the user's identity but also establishes a binding relationship between the user and their key, providing a solid foundation for subsequent identity authentication and authorization.

[0176] In one embodiment, the method further includes the following steps:

[0177] Count the number of user authentication identities generated through cross-chain smart contracts;

[0178] Whenever the number of generated contracts reaches a preset threshold, the contract code of the cross-chain smart contract is subjected to syntax analysis and semantic checks.

[0179] The analysis results of combining syntactic analysis and semantic checks are used to update the cross-chain smart contract through preset adaptive update rules.

[0180] In this implementation, counting the number of user authentication identities generated through cross-chain smart contracts is a crucial measure for monitoring system performance and security. This process involves setting up a counter mechanism on the main chain and each sub-chain. Whenever a cross-chain smart contract executes and generates a new user authentication identity, the corresponding counter increments. To ensure the accuracy and consistency of the count, a distributed counter technology, such as the HyperLogLog algorithm, is employed, which provides approximately unique counts while maintaining a small memory footprint. In the cross-chain environment, each sub-chain maintains its own local counter and periodically synchronizes the count results to the main chain via a cross-chain communication protocol (such as Hash Time Lock Contract, HTLC). The smart contract on the main chain is responsible for aggregating the count results from all sub-chains and calculating the total number of generated identities. To prevent malicious manipulation of the counter, a multi-signature mechanism is implemented, requiring multiple trusted nodes to jointly verify the count update operation. Furthermore, leveraging the immutability of the blockchain, each count update is recorded as a transaction, ensuring the auditability and transparency of the counting process. This statistical mechanism not only provides real-time monitoring of the system's operational status but also provides crucial data support for subsequent contract optimization and security analysis.

[0181] Whenever the number of generated user authentication identities reaches a preset threshold, performing syntax analysis and semantic checks on the cross-chain smart contract code is a crucial step in ensuring contract security and performance. First, a reasonable threshold is set, such as triggering a check every 10,000 user authentication identities generated. The checking process consists of two main phases: syntax analysis and semantic checking. Syntax analysis uses a lexical analyzer and a parser to convert the contract code into an Abstract Syntax Tree (AST). This process checks whether the code conforms to the syntax rules of smart contract languages ​​(such as Solidity), including variable declarations, function definitions, control structures, etc. Semantic checking delves deeper into the logical correctness and security of the code. It includes type checking, control flow analysis, and data flow analysis. For example, it checks for common problems such as integer overflow, reentrancy vulnerabilities, and uninitialized memory pointers. Furthermore, gas consumption analysis is performed to assess contract execution efficiency. These checks are conducted using static analysis tools such as Mythril or Slither, combined with a custom rule set. The check results are generated in the form of a report, containing detailed descriptions of potential problems and severity ratings. This regular automated inspection mechanism can promptly identify and fix potential problems in contracts, greatly improving the security and reliability of the system.

[0182] The final step in optimizing system performance and security is updating cross-chain smart contracts by combining the analysis results of syntax analysis and semantic checks and using preset adaptive update rules. First, the inspection report is analyzed in depth, categorizing identified issues (such as security vulnerabilities, performance bottlenecks, logical errors, etc.) and ranking them by severity. Then, an update strategy is determined based on preset adaptive update rules. These rules may include: immediately fixing critical security vulnerabilities, optimizing performance issues in the next planned update, and logging and monitoring minor issues. The update process employs smart contract upgrade models, such as proxy models or data separation models, to ensure that the update does not interrupt existing services. In practice, the updated contract is first deployed on a test network for comprehensive testing, including unit testing, integration testing, and stress testing. After passing the tests, a multi-signature mechanism is used to trigger the contract update on the mainnet. During the update process, an event log is used to record each step to ensure traceability. After the update is completed, the system automatically verifies the consistency of the new contract's state and closely monitors it for a period of time. This adaptive update mechanism not only promptly fixes problems but also continuously optimizes contract performance, ensuring the long-term stable operation and security of the system.

[0183] In one implementation, granting a target user data access permission or data upload permission in the main chain-sub chain architecture based on the request type of the data interaction request, so that the target user can use the data access permission to access the target data already stored in the main chain-sub chain architecture, or use the data upload permission to upload the target data in the main chain-sub chain architecture, includes the following steps:

[0184] Determine whether the data interaction request is a data upload request or a data access request;

[0185] If it is a data upload request, grant the target user data upload permission in the main chain-sub chain architecture, and obtain the target user's target data and the data access policy preset by the target user for the target data;

[0186] If the target data is encrypted by the target user using the user key, the target data and data access policy are packaged and sent to the blockchain subchain, and the data upload process of the target data is completed by the blockchain computing node.

[0187] If the target data is not encrypted, the target data and data access policy will be packaged and sent to the blockchain main chain, and the data upload process of the target data will be completed through the blockchain consensus node.

[0188] If it is a data access request, the target user's data access permissions are determined and granted based on the target user's user authentication identity;

[0189] By combining data access permissions and data access policies for data already stored in the main chain-sub-chain architecture, the system provides feedback to the target user on the data storage location of the target data that the target user can access.

[0190] In this implementation, determining whether a data interaction request is a data upload request or a data access request is the first step in processing user requests. This process involves parsing and classifying the received request messages. First, request messages typically use standardized formats, such as JSON or Protocol Buffers, containing fields such as request type, user identifier, and timestamp. The system uses a message parser to extract these fields, paying particular attention to the fields representing the request type. The judgment logic can be based on simple conditional statements, such as checking whether the request type field is equal to a predefined "UPLOAD" or "ACCESS" value. To improve processing efficiency, a hash table can be used to store the mapping between request types and processing functions, achieving fast distribution with O(1) time complexity. In addition, the system also verifies the integrity and validity of the request, including checking digital signatures and verifying timestamps to prevent replay attacks. This judgment process lays the foundation for subsequent permission granting and data processing, ensuring that requests are correctly routed to the appropriate processing modules.

[0191] For data upload requests, granting the target user data upload permissions within the main chain-sub-chain architecture and obtaining the target data and its preset data access policy are crucial steps in the data upload process. First, the system verifies the user's identity and permissions, typically by checking the user's digital certificate or token. Upon successful verification, an authorization transaction is recorded on the main chain, indicating that the user has obtained upload permissions. This transaction includes information such as the user ID, authorization timestamp, and validity period. Next, the system receives the target data and data access policy uploaded by the user. The data may be transmitted as a file or data stream using secure transmission protocols such as HTTPS or SFTP. The data access policy typically employs an Attribute-Based Access Control (ABAC) model, defining who can access the data under what conditions. For example, the policy might specify that "only members of the R&D department with a level greater than 3 can access the data during working hours." The system converts this policy into a machine-readable format, such as XACML, and temporarily stores it along with the data, awaiting subsequent processing.

[0192] If the target data is encrypted by the user using a user key, the target data and data access policy are packaged and sent to the blockchain subchain. The data upload process is completed by the blockchain computing nodes. This step involves a complex process of data encryption, transmission, and storage. First, the system verifies the encryption status of the data, possibly by checking the encryption flag in the data header or attempting to decrypt a small portion of the data. After confirming encryption, the system packages the encrypted data and access policy into a transaction. This transaction includes the hash value of the data, the storage location of the encrypted data (possibly an IPFS address), the hash value of the access policy, etc. Then, the system selects a suitable subchain for upload, based on criteria such as data type and user's department. Once selected, the transaction is sent to the target subchain via a cross-chain communication protocol (such as Hash Time Lock Contract (HTLC)). After receiving the transaction, the computing nodes on the subchain verify its legitimacy and then package the transaction into a block. This process may involve consensus mechanisms such as PoS or DPoS. Finally, the computing nodes update their state, recording the index information of the new data. This method ensures data privacy (because the data is encrypted) while utilizing the efficient processing capabilities of the subchain.

[0193] If the target data is not encrypted, the data and access policy are packaged and sent to the main chain, where the upload process is completed by consensus nodes. This step deals with plaintext data, thus requiring a higher level of security measures. First, the system performs an integrity check on the data and calculates its hash value. Then, the data, access policy, data hash value, and metadata (such as upload time, user ID, etc.) are packaged into a transaction. To protect privacy, zero-knowledge proof technology can be used, allowing verification of certain attributes of the data without exposing the actual content. Next, this transaction is broadcast to the main chain network. Consensus nodes on the main chain (such as those using PoW or PoS mechanisms) verify the legality of the transaction, including checking user permissions and verifying data integrity. After successful verification, the nodes reach a consensus and package the transaction into a new block. Once the block is confirmed, the data is considered securely stored on the blockchain. Finally, the system updates the global state, recording the location and access policy of the new data. While this method may be slower, it provides the highest level of security and immutability.

[0194] If it's a data access request, data access permissions are determined and granted based on the target user's authenticated identity. This process first verifies the user's authentication identity, typically involving checking the validity of digital signatures, tokens, or certificates. The system queries the user's identity information stored on the blockchain to verify the user's claimed identity attributes. Then, the system evaluates the user's access permissions. This is usually based on predefined access control policies, possibly using Role-Based Access Control (RBAC) or a more complex Attribute-Based Access Control (ABAC) model. For example, the system might check attributes such as the user's department, job level, and project participation, and match these with the data access policy. The permission evaluation process may involve complex logical operations, such as "(Job Level > 3 AND Department = 'R&D') OR (Project = 'A' AND Time within Working Hours)". The evaluation result determines the user's actions, such as read-only, edit, or delete. The system then generates an access token containing the scope and validity period of the authorization. This token is signed using the system's private key to ensure its unforgeability. Finally, the system records this authorization operation on the blockchain to ensure auditability.

[0195] Combining data access permissions and access policies for already stored data, the system informs users of the accessible target data storage locations. This step involves data retrieval and location resolution. First, based on the user's access permissions, the system queries data indexes that meet the criteria. This may involve distributed searches across the main chain and multiple sub-chains. For each matching data record, the system checks whether its access policy matches the user's permissions. This process may use smart contracts to execute complex policy evaluation logic. Data items that meet the criteria are added to the results list. For each data item, the system resolves its storage location. This could be a direct storage location on the blockchain (such as a reference to a specific block or transaction) or a reference to an external storage system (such as an IPFS hash). The system may also generate temporary access URLs or tokens, allowing users to directly access the data for a limited time. Finally, the system returns this location information, along with the metadata of each data item (such as title, upload time, file size, etc.), to the user in a structured format (such as JSON). This approach ensures both data access security and provides a flexible data retrieval mechanism.

[0196] The present invention also discloses a blockchain-based data interaction security and privacy protection system, including a memory, a processor, and a computer program stored on the memory and executable on the processor. The system is characterized in that the processor executes the computer program to implement the blockchain-based data interaction security and privacy protection method as described in any of the above embodiments.

[0197] The processor can be a central processing unit (CPU). Of course, depending on the actual use, it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), off-the-shelf programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc., and this application does not limit it.

[0198] The memory can be an internal storage unit of a computer device, such as a hard disk or RAM, or an external storage device, such as a plug-in hard disk, smart memory card (SMC), secure digital card (SD), or flash memory card (FC) provided on the computer device. Furthermore, the memory can be a combination of internal storage units and external storage devices of a computer device. The memory is used to store computer programs and other programs and data required by the computer device. The memory can also be used to temporarily store data that has been output or will be output. This application does not limit this.

[0199] The present invention also discloses a computer-readable storage medium storing instructions that, when executed by a processor, cause the processor to be configured to perform the blockchain-based data interaction security and privacy protection method described in any of the above embodiments.

[0200] The computer program can be stored in a machine-readable medium. The computer program includes computer program code, which can be in the form of source code, object code, executable file, or certain middleware. The machine-readable medium includes any entity or device capable of carrying computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the machine-readable medium includes, but is not limited to, the above-mentioned components.

[0201] The blockchain-based data interaction security and privacy protection method described in the above embodiments is stored in the computer-readable storage medium and loaded and executed on the processor to facilitate the storage and application of the above method.

[0202] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of protection of this application is limited to these examples; under the concept of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of one or more embodiments of this application as described above, which are not provided in detail for the sake of brevity.

[0203] One or more embodiments in this application are intended to cover all such substitutions, modifications, and variations that fall within the broad scope of this application. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments in this application should be included within the protection scope of this application.

Claims

1. A method for protecting security and privacy of data interaction based on blockchain, characterized in that, The application is applied to a data interaction management system, which comprises a cloud server, a double-layer trusted execution environment hardware and a user terminal server, the user terminal server and the double-layer trusted execution environment hardware are in communication connection with the cloud server through a secure communication channel based on an end-to-end encryption mechanism, and the method comprises the following steps: a plurality of blockchain consensus nodes are deployed in the cloud server, and a blockchain main chain is built in the cloud server based on all the blockchain consensus nodes; a plurality of blockchain computing nodes for processing different business types are deployed in the double-layer trusted execution environment hardware, and a plurality of blockchain sub-chains are built in the double-layer trusted execution environment hardware based on all the blockchain computing nodes and according to the business types; communication connections between all the blockchain sub-chains and the blockchain main chain are established based on a cross-chain communication protocol and through the secure communication channel, a main chain-sub chain architecture is formed, and a cross-chain smart contract is deployed in the main chain-sub chain architecture; a data interaction request issued by a target user is received through the user terminal server, and a user authentication identity contained in the data interaction request is verified, the user authentication identity is authenticated and issued by the blockchain computing node; if the verification is passed, data access authority or data upload authority of the target user in the main chain-sub chain architecture is granted according to the request type of the data interaction request, so that the target user accesses the target data stored in the main chain-sub chain architecture by using the data access authority, or the target user uploads target data in the main chain-sub chain architecture by using the data upload authority; a data fingerprint of the target data in the data interaction process is generated, a data operation log of the target data is generated by combining the data fingerprint and the data interaction request, and the data operation log is organized as a log Merkle tree structure; all the target data and the log Merkle tree structure are stored in the main chain-sub chain architecture in a hierarchical storage architecture based on a directed acyclic graph. 2.The method of claim 1, wherein, Before the step of receiving the data interaction request issued by the target user through the user terminal server, the following steps are further included: a user information processing model based on a neural network is deployed in the double-layer trusted execution environment hardware, the user information processing model comprises an information feature extraction module, an information integrity verification module, an information credibility verification module, a user type classification module and a noise injection module; a user registration request issued by a to-be-registered user to the main chain-sub chain architecture is obtained from the user terminal server; user information in the user registration request is extracted, the user information is input into the user information processing model for information verification, and the user type of the to-be-registered user is output by the user information processing model according to the user information that passes the information verification; a user key of the to-be-registered user is randomly generated, and the user key is stored in the main chain-sub chain architecture; Generate a user authentication identity of the to-be-registered user based on the user type and through the cross-chain smart contract, and issue the user authentication identity to the to-be-registered user by the blockchain computing node, thereby completing the user registration of the to-be-registered user in the main chain-sub chain architecture. 3.The method of claim 2, wherein, The information feature extraction module is configured to extract information field features and information abnormal association features from the user information, and a last layer of shared features of the information feature extraction module is connected to the information integrity verification module, the information credibility verification module, and the user type classification module respectively. The information integrity verification module is configured to output a completeness probability of the user information according to the information field features. The information credibility verification module is configured to output a credibility score of the user information according to the information abnormal association features. The user information processing model further comprises a decision unit and a gating unit. An output layer of the information integrity verification module is connected to the decision unit. Output layers of the information credibility verification module are connected to the decision unit and the user type classification module respectively. An output layer of the decision unit is connected to the gating unit. An output layer of the gating unit is connected to the user type classification module. The decision unit is configured to output a verification result of the user information in combination with the completeness probability and the credibility score. The gating unit is configured to determine whether to output a module activation signal to the user type classification module according to the verification result. The user type classification module is configured to identify and output a user type corresponding to the user information in combination with the credibility score and the information field features after receiving the module activation signal. An output layer of the user type classification module is connected to the noise injection module. The noise injection module is configured to inject noise into an output result of the user type classification module based on a Laplace mechanism and according to a preset privacy budget. The information integrity verification module and the information credibility verification module interact with each other through a multi-head attention mechanism. 4.The method of claim 2, wherein, The storing of the user key in the main chain-sub chain architecture comprises the following steps: The user key is divided into n key fragments by using a Shamir secret sharing algorithm; Each key fragment is encrypted by using a homomorphic encryption algorithm; According to the node state of the blockchain computing node, m blockchain computing nodes are selected as trusted computing nodes, 2≤m<n; The encrypted key fragments are distributed and stored in each trusted computing node; A threshold signature-based key reconstruction protocol is created for all trusted computing nodes, which restricts that at least t trusted computing nodes need to cooperate to complete the user key reconstruction process, t≤m. 5.The method of claim 4, wherein, The generation of the user authentication identity of the to-be-registered user based on the user type and through the cross-chain smart contract comprises the following steps: Based on the user type, the cross-chain smart contract is executed to generate a verifiable credential for the to-be-registered user. Based on the user information, a property description language supporting multi-dimensional access strategy definition is used to generate user properties of the to-be-registered user, and a CP-ABE encryption algorithm is used to complete attribute encryption of the user properties; The verifiable credential and the attribute-encrypted user properties are combined into a user identity of the to-be-registered user; An identity authentication protocol based on zero-knowledge range proof is added to the user identity; The user key of the to-be-registered user is reconstructed from the main chain-sub chain architecture, and the user identity is signed by the user key to obtain a user authentication identity of the to-be-registered user.

6. The method of claim 5, wherein, The method further includes the following steps: The number of generated user authentication identities generated by the cross-chain smart contract is counted; Whenever the number reaches a preset number threshold, syntax analysis and semantic checking are performed on the contract code of the cross-chain smart contract; The analysis and checking results of the syntax analysis and the semantic checking are combined, and the cross-chain smart contract is updated through a preset adaptive update rule. 7.The method of claim 4, wherein, The data access permission or data upload permission of the target user in the main chain-sub chain architecture is granted according to the request type of the data interaction request, so that the target user accesses the target data stored in the main chain-sub chain architecture by using the data access permission, or the target user uploads target data in the main chain-sub chain architecture by using the data upload permission, including the following steps: Determine whether the request type of the data interaction request is a data upload request or a data access request; If it is the data upload request, the data upload permission of the target user in the main chain-sub chain architecture is granted, and the target data of the target user and the data access strategy preset by the target user for the target data are obtained; If the target data is encrypted by the user key of the target user, the target data and the data access strategy are packaged and sent to the blockchain sub chain, and the data upload process of the target data is completed by the blockchain computing node; If the target data is not encrypted, the target data and the data access strategy are packaged and sent to the blockchain main chain, and the data upload process of the target data is completed by the blockchain consensus node; If it is the data access request, the data access permission of the target user is determined and granted based on the user authentication identity of the target user; The data storage location of the target data accessible by the target user is fed back to the target user in combination with the data access permission and the data access strategy of the stored data in the main chain-sub chain architecture. 8.The method of claim 1, wherein, The dual-layer trusted execution environment hardware includes a hardware security module and a trusted execution environment hardware. 9.A blockchain-based data interaction security and privacy protection system, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor executes the computer program to implement the blockchain-based data interaction security and privacy protection method according to any one of claims 1-8.

10. A computer-readable storage medium having stored thereon instructions, the computer-readable storage medium comprising: The instructions, when executed by the processor, cause the processor to be configured to perform the blockchain-based data interaction security and privacy protection method according to any one of claims 1-8.

Images