Distributed data security storage system and method based on block chain

Abstract

The invention relates to the technical field of block chains, and discloses a distributed data security storage system and method based on a block chain, and the system comprises a dynamic fragmentation encryption module which can automatically select a fragmentation strategy based on a data sensitivity level; the data sensitivity is set to be S, the data sensitivity level is determined through the following formula: # imgabs0 #, wi is the weight of the ith factor influencing the data sensitivity, fi (D) is the quantized value of the data D under the ith factor, and for low-sensitivity data (S is smaller than or equal to Slow, and Slow is a preset low-sensitivity threshold), ECIES asymmetric encryption and random fragmentation storage are adopted; and high and low sensitive data. Through the dynamic fragmentation encryption module, hierarchical storage and flexible encryption of data are realized, and storage redundancy is reduced; the cross-chain verification engine adopts zero-knowledge proof, and cross-chain verification is safely and efficiently completed; the storage node reputation system is combined with LSTM to predict the node failure probability, and reliable data storage is guaranteed; all work processes are tightly matched, and the whole process ensures data safety and efficient circulation and management.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and more specifically to a distributed data security storage system and method based on blockchain. Background Art

[0002] The core issue is the dramatic growth of data volumes. With the widespread deployment of IoT devices, the advancement of enterprise digital operations, and the emergence of a wide range of new applications, data volumes are expanding at an alarming rate. Against this backdrop, the shortcomings of traditional blockchain storage architectures are becoming increasingly prominent.

[0003] First, there's the issue of storage redundancy. In traditional blockchain architectures, every full node is required to store a complete copy of the data. This model was viable when data volumes were small, but its drawbacks are magnified with today's massive data volumes. For large-scale enterprise data storage and the massive amounts of data records generated by IoT devices, storing a complete copy on every node not only places extremely high demands on the node's storage hardware, requiring vast amounts of disk space to accommodate the data, but also results in a significant waste of storage resources. The duplication of data across numerous nodes leads to significantly higher storage costs, which undoubtedly severely limits the application and expansion of blockchain technology in large-scale data storage scenarios, making it difficult to meet the ever-increasing demand for data storage.

[0004] The existence of storage redundancy further exacerbates the dilemma of encryption strategies. Most current blockchain storage solutions rely on a single encryption algorithm, such as the widely used SHA-256 algorithm. However, different types of data have significantly different security requirements, depending on their application scenarios and sensitivity. In the financial sector, customer financial transaction information and account data are subject to extremely high confidentiality and integrity requirements; any data leak or tampering could result in severe financial losses. In contrast, in public scientific data sharing scenarios, data integrity verification may be more important, with relatively lower requirements for confidentiality. Due to the large volume of data caused by storage redundancy, a single encryption algorithm cannot flexibly adapt to these diverse data security requirements. In some scenarios, insufficient encryption strength may make data vulnerable to attacks and fail to ensure data security. In other scenarios, excessive encryption wastes computing resources and reduces data processing efficiency due to the large amount of encrypted data. This contradiction becomes increasingly prominent as data volumes continue to grow.

[0005] The rigidity of encryption policies interacts with the lack of dynamic access control. Existing blockchains lack a fine-grained permission management mechanism, making it impossible to accurately assign permissions based on different data hierarchies and user roles. For example, in medical data management, a patient's medical records contain multiple levels of content, including basic information, diagnostic records, and imaging data. Different roles, such as doctors, require comprehensive review of medical records for accurate diagnosis and treatment; nurses may only need to view a subset of nursing-related data; and patients themselves may require specific access permissions for certain private data. However, because encryption policies cannot be flexibly adjusted to suit different permissions, existing blockchain storage technologies struggle to implement such complex hierarchical access control. This not only makes it difficult to precisely match the permissions required in complex business scenarios, but also poses the risk of data leakage. Inappropriate permission settings can expose sensitive data to unauthorized personnel. This can also hinder the smooth operation of business processes. For example, doctors cannot access critical diagnostic data in a timely manner due to insufficient permissions, impacting the quality of medical services.

[0006] The lack of dynamic access control further highlights the inefficiency of cross-chain verification in cross-chain scenarios. Data verification between heterogeneous blockchains currently relies primarily on centralized oracles. Due to the lack of effective dynamic access control, data exchange between different blockchains cannot be properly verified based on data sensitivity and access rights. Centralized oracles, as the core of data information transfer and verification, present a significant single point of failure risk. If the centralized oracle server is attacked, experiences hardware failure, or suffers a network outage, the entire cross-chain verification process will immediately come to a standstill. Because all cross-chain data verification relies on this centralized node under the current model, any failure would severely impact interoperability and the stability of data exchange between blockchains. Furthermore, the existence of centralized oracles violates the fundamental principle of blockchain decentralization. Furthermore, due to their centralized processing model, data verification is relatively inefficient and unable to meet the rapidly growing needs of cross-chain services. With the continued growth of data volumes and the increasing frequency of cross-chain services, this inefficient cross-chain verification approach is becoming a bottleneck in the development of blockchain technology.

[0007] Therefore, it is necessary to provide a distributed data security storage system and method based on blockchain to solve the above problems. Summary of the Invention

[0008] In order to overcome the above-mentioned defects of the prior art, the present invention provides a distributed data security storage system and method based on blockchain to solve the problems existing in the above-mentioned background technology.

[0009] The present invention provides the following technical solution: a distributed data security storage system based on blockchain, comprising:

[0010] Dynamic sharding encryption module, which can automatically select sharding strategies based on data sensitivity level; let data sensitivity be S, and determine the data sensitivity level by the following formula:

[0011]

[0012] where w i is the weight of the i-th factor affecting data sensitivity, f i (D) is the quantitative value of data D under the i-th factor,

[0013] For low-sensitivity data (S≤S low , S low For low sensitivity thresholds (preset), ECIES asymmetric encryption + random sharding storage is used; for high and low sensitivity data (S>S high , S high It combines attribute-based encryption (ABE) and threshold sharding (ShamirSecretSharing) and stores shards on different blockchain nodes to achieve "sharding is authorization", so that the shard storage location is dynamically bound to the user's attributes;

[0014] A cross-chain verification engine builds a lightweight cross-chain smart contract cluster to achieve cross-chain synchronization of data fingerprints (MerkleRoot) and verification based on zero-knowledge proofs (zk-SNARKs) without exposing the original data. During the zero-knowledge proof verification process, proof π is generated using π=Prove(x, w), where x is the public input and w is the secret input. During verification, the verification result is returned through Verify(x, π). A "verification chain within a chain" structure is proposed, where the main chain stores verification metadata and the sub-chain stores shard data.

[0015] The storage node reputation system has a dynamic evaluation model, which includes storage stability (assessed by node online rate, assuming the node online time is t online , total duration is total, online rate ), data integrity (using timed PoR verification) and cross-chain response speed, etc., and predict the node failure probability through LSTM neural network. Let the input feature vector be X=[R online , I data , S cross-chain ,…], through the LSTM network P failure =LSTM(X) to get the node failure probability P failure , give priority to high-reputation nodes (i.e. P failure Low nodes) store key shards.

[0016] Furthermore, the data uploading workflow of the system includes:

[0017] After entering the data, sensitivity analysis was performed on the data;

[0018] Based on the sensitivity analysis results, N encrypted fragments are generated through dynamic fragment encryption technology;

[0019] Storage nodes are selected with the help of VRF (Verifiable Random Function) to ensure the geographical distribution of storage nodes.

[0020] Furthermore, the data access workflow of the system is as follows:

[0021] The user submits an attribute certificate;

[0022] The smart contract verifies the user’s attribute certificate;

[0023] After verification, the required shards are reassembled and shard decryption is implemented based on the SGX trusted execution environment.

[0024] Furthermore, the data verification workflow of the system is as follows:

[0025] The system regularly triggers PoRep (proof of storage) challenges;

[0026] Once an abnormal shard is detected, it will be automatically repaired through the cross-chain engine.

[0027] Furthermore, a distributed data security storage method based on blockchain is provided, which is applied to the above system and is characterized by comprising the following steps:

[0028] Data sensitivity analysis steps: Determine the sensitivity level of input data using the formula Calculate data sensitivity S;

[0029] Dynamic shard encryption steps: According to the data sensitivity level, when SS low When S>Shigh, low-sensitivity data is stored using ECIES asymmetric encryption combined with random sharding. When S>Shigh, high-sensitivity data is stored in different blockchain nodes using attribute-based encryption (ABE) combined with threshold sharding (ShamirSecretSharing).

[0030] Storage node selection step: Use VRF (Verifiable Random Function) to select storage nodes with good geographical distribution to store encrypted shards;

[0031] Data access verification step: The user submits the attribute certificate, and after verification by the smart contract, the required shards are reassembled and decrypted in the SGX trusted execution environment;

[0032] Data verification and repair steps: Regularly trigger PoRep (proof of storage) challenges and automatically repair abnormal shards through the cross-chain engine.

[0033] Furthermore, in the data sensitivity analysis step, the data type, application scenario, and possible impact are comprehensively evaluated based on the preset sensitivity level judgment rules to determine the sensitivity level of the data. The evaluation process uses the formula

[0034] Furthermore, in the dynamic shard encryption step, when attribute-based encryption (ABE) is used for highly sensitive data, an encryption key is generated based on the correspondence between user attributes and data access permissions to achieve data encryption and dynamic binding of shard storage locations with user attributes.

[0035] Furthermore, in the storage node selection step, VRF (Verifiable Random Function) generates random and geographically distributed storage node selection results based on parameters such as the storage node's geographical location information, network status, and node load.

[0036] Furthermore, in the data access verification step, when the smart contract verifies the user attribute certificate, it compares it with the preset permission rules to determine whether the user has the permission to access the corresponding data shard.

[0037] Furthermore, in the data verification and repair step, the PoRep (Proof of Storage) challenge sends a verification request to the storage node, compares the data returned by the storage node with the characteristic information of the original data, and detects the integrity of the data and the reliability of the storage node.

[0038] Technical effects and advantages of the present invention:

[0039] This invention comprehensively improves the distributed data storage efficiency of blockchain through multi-dimensional innovation. The dynamic sharding encryption module accurately adapts to data of different sensitivity levels. ECIES asymmetric encryption and random sharding are used for low-sensitivity data to reduce storage resource consumption. For highly sensitive data, attribute-based encryption is combined with threshold sharding and stored according to user attributes, which not only ensures data security but also realizes fine-grained access control, breaks the rigid situation of traditional encryption strategies, and greatly reduces the risk of data leakage. The cross-chain verification engine builds a lightweight smart contract cluster and uses zero-knowledge proof technology to complete cross-chain verification without exposing the original data. The "verification chain in chain" structure optimizes the data verification process, avoids the drawbacks of centralized oracles, and enhances interoperability between blockchains. To improve the stability of data interaction and cross-chain business efficiency, the storage node reputation system uses LSTM neural networks to predict the probability of node failure, evaluates nodes from multiple aspects such as storage stability, data integrity and cross-chain response speed, and gives priority to using high-reputation nodes to store key shards, effectively ensuring data storage reliability. In the data upload, access and verification workflow, all links work closely together, from the sensitivity analysis when the data enters the system to the multiple security measures during storage, access and verification. The whole process ensures data security, efficient storage and circulation, effectively solves the difficult problems of traditional blockchain storage technology in storage redundancy, encryption strategy, access control and cross-chain verification, and promotes the widespread application of blockchain technology in the field of large-scale data storage. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 This is a diagram of the system architecture of the present invention;

[0041] Figure 2 Flow chart of the method of the present invention. DETAILED DESCRIPTION

[0042] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0043] It will be understood that the terms "first," "second," etc. used herein may be used to describe various elements, but unless otherwise specified, these elements are not limited by these terms. These terms are only used to distinguish a first element from another element.

[0044] In order to help those skilled in the art better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without making any creative efforts shall fall within the scope of protection of this application.

[0045] Example 1: Construction and operation of a distributed data security storage system based on blockchain

[0046] Dynamic Sharding Encryption Module: This module is one of the core components of the system and is responsible for selecting appropriate encryption and sharding strategies based on the data sensitivity level. In a practical application scenario, assume there is a medical data storage project whose data types include basic patient information, diagnostic records, imaging data, etc. For basic information, considering that its application scenarios are mainly daily checks by medical staff and patients' own inquiries, although it contains certain personal information, its sensitivity is relatively low; diagnostic records involve professional medical judgments and have high confidentiality requirements; imaging data are usually large in size and may need to be partially shared publicly in certain research scenarios, so its sensitivity requires a comprehensive assessment.

[0047] Data sensitivity calculation: Based on the preset sensitivity level judgment rules, a comprehensive assessment is conducted on factors such as data type, application scenario, and possible impact, and the formula Calculate the data sensitivity S. In the example of medical data, if n = 3, the influencing factors are data type, application scenario, and potential impact. The corresponding weights w1, w2, and w3 can be set according to the actual needs and safety standards of the medical industry, such as w1 = 0.4, w2 = 0.3, and w3 = 0.3. For basic information, quantify the value under the data type factor, where w i is the weight of the i-th factor affecting data sensitivity, f i (D) is the quantized value of data D under the i-th factor. f1(D) is set to 0.3 (because it is general personal information), f2(D) is set to 0.2 (primarily for internal use), and f3(D) is set to 0.2 (relatively small impact after leakage). The sensitivity of the basic information, S, is 0.4 × 0.3 + 0.3 × 0.2 + 0.3 × 0.2 = 0.24. If the low sensitivity threshold, S, is set to 0.3, the basic information is considered low-sensitivity data and is stored using ECIES asymmetric encryption and random sharding.

[0048] Encryption and sharding storage: For low-sensitivity data, such as the basic medical information mentioned above, ECIES asymmetric encryption technology is used. Its encryption speed is fast and efficient, which can reduce storage resource consumption while ensuring a certain level of security. When randomly sharding data, the data is divided into multiple small shards and randomly stored on different blockchain nodes to further disperse storage risks. For highly sensitive data, such as diagnostic records, if the calculated sensitivity S>S high (Assuming S high =0.6), a combination of attribute-based encryption (ABE) and threshold sharding (Shamir Secret Sharing) is employed. Encryption keys are generated based on the correspondence between user attributes and data access permissions. For example, only medical staff with specific medical qualifications and working in specific departments can access certain patients' diagnostic records. ABE encryption incorporates this attribute information into the encryption key, achieving data encryption and dynamic binding of shard storage locations to user attributes. Threshold sharding technology stores data shards across different blockchain nodes. Data can only be restored after a sufficient number of shards have been collected, enhancing data security.

[0049] Cross-chain Verification Engine: In a medical data sharing project involving multiple medical institutions, different medical institutions may use different blockchain systems to store patient data. The cross-chain verification engine builds a lightweight cross-chain smart contract cluster to achieve cross-chain synchronization of data fingerprints (MerkleRoot) and verification based on zero-knowledge proofs (zk-SNARKs), without exposing the original data.

[0050] Zero-knowledge proof verification: Suppose that medical institution A's blockchain system needs to verify the integrity of a patient's data in medical institution B's blockchain system. During the zero-knowledge proof verification process, medical institution B generates proof π using π = Prove(x, w), where x is the public input (such as some public features of the data) and w is the secret input (such as the specific content of the data). Medical institution A returns the verification result through Verify(x, π), determining whether the data is complete and has not been tampered with. This entire process does not require access to medical institution B's original data, thus protecting data privacy.

[0051] "Verification Chain-within-a-Chain" Architecture: The proposed "verification chain-within-a-chain" structure optimizes the data verification process. The main chain stores verification metadata, such as the data's hash value, verification time, and information about the participating nodes; the subchain stores sharded data. In the aforementioned medical data sharing scenario, the main chain records verification-related information for data in each medical institution's blockchain system, while the subchain stores specific patient data shards. This architecture avoids the drawbacks of centralized oracles, enhances interoperability and data exchange stability between blockchains, and improves cross-chain business efficiency.

[0052] Storage node reputation system: In a large-scale blockchain storage network, there are many storage nodes. The storage node reputation system has a dynamic evaluation model to evaluate the reliability of nodes from multiple dimensions.

[0053] Evaluation indicators: The model includes storage stability (assessed by node online rate, assuming the node online time is t online , the total duration is t total , online rate ), data integrity (using timed PoR verification) and cross-chain response speed. For example, the total time of node A in a month is t total =720 hours, online time t online =700 hours, then its online rate Through periodic PoR verification, the integrity of the data stored by the node is checked. If the data returned by the node is inconsistent with the characteristic information of the original data, it is determined that there is a problem with the data integrity. The cross-chain response speed is measured by recording the response time of the node during the cross-chain data interaction process. The shorter the response time, the faster the cross-chain response speed.

[0054] Node failure probability prediction: LSTM neural network is used to predict the node failure probability. Let the input feature vector be X = [R online , I data , S cross-chain ,…], through the LSTM network P failure =LSTM(X) to get the node failure probability P failure , give priority to high-reputation nodes (i.e. P failure The online rate of node A, data integrity assessment results (assuming the data integrity score is 0.9, with a maximum score of 1), cross-chain response speed (assuming the response speed score is 0.8, with a maximum score of 1) are used as input feature vectors. The failure probability P of node A is calculated by the trained LSTM network failure When storing key shards, high-reputation nodes (i.e. P failure Low nodes), effectively ensuring data storage reliability.

[0055] Example 2: System data processing flow

[0056] Data upload workflow: Taking the data upload of a scientific research project as an example, the research team collected a large amount of experimental data and prepared to upload it to the blockchain distributed data security storage system.

[0057] Data sensitivity analysis: First, perform a sensitivity analysis on the input data. Based on the data type (such as experimental raw data, analysis result data, etc.), application scenario (whether it is for internal scientific research use, public sharing, or sharing with cooperative units, etc.), and possible impact (whether data leakage will affect the innovation of scientific research results, whether it will cause intellectual property disputes, etc.), the preset sensitivity level judgment rules and formulas are used. Calculate data sensitivity. Assume that a set of experimental raw data has a calculated sensitivity of S>S high , which is highly sensitive data.

[0058] Dynamic Sharding Encryption: Based on the sensitivity analysis results, dynamic sharding encryption technology is used to generate N encrypted shards. For this highly sensitive experimental raw data, a combination of Attribute-Based Encryption (ABE) and threshold sharding (Shamir Secret Sharing) is used for encryption and sharding. Encryption keys are generated based on the correspondence between the identity attributes of research team members (such as project leaders, researchers, and collaborating unit personnel) and data access rights, enabling data encryption and dynamic binding of shard storage locations to user attributes.

[0059] Storage Node Selection: Storage nodes are selected using a Verifiable Random Function (VRF). VRF generates random and geographically distributed storage node selection results based on parameters such as the storage node's geographic location, network conditions, and node load. For example, multiple nodes located in different regions with stable networks and low loads are selected to store encrypted shards. This improves the security and reliability of data storage and reduces the risk of data loss due to local network failures or node anomalies.

[0060] Data access workflow: A researcher in a scientific research team needs to access experimental data stored in the system.

[0061] Submit attribute certificate: The user submits an attribute certificate, which contains the researcher's identity information, team affiliation, role in the project, and other attribute information.

[0062] Smart Contract Verification: The smart contract verifies the user's attribute certificate and compares it with pre-set permission rules to determine whether the user has permission to access the corresponding data shard. For example, if a researcher in a project only has access to a portion of the experimental analysis results data, the smart contract will confirm whether the researcher can access the currently requested data shard based on the attribute certificate and permission rules.

[0063] Shard decryption and reassembly: After verification, the required shards are reassembled and decrypted within the SGX trusted execution environment. Within the SGX trusted execution environment, data decryption and processing are protected by hardware-level security, preventing data theft or tampering during the decryption process and ensuring secure data access.

[0064] Data verification workflow: The system regularly verifies the data stored in each node to ensure the integrity and reliability of the data.

[0065] PoRep Challenge: The system periodically triggers PoRep (Proof of Storage) challenges, sending verification requests to storage nodes and comparing the data returned by the storage nodes with the characteristics of the original data to test the integrity of the data and the reliability of the storage nodes. For example, once a week, the system sends a verification request to all storage nodes, requiring the nodes to return characteristics such as the hash value of the stored data, which is then compared with the characteristics of the original data stored by the system.

[0066] Abnormal shard repair: Once an abnormal shard is detected, it is automatically repaired by the cross-chain engine. For example, during a verification process, if a hash value mismatch is found in the experimental data shard stored on a certain node, indicating that the data may have been tampered with or damaged, the cross-chain engine will automatically obtain the correct shard data from other backup nodes and repair the abnormal shard to ensure data integrity and availability.

[0067] The technical features of the above-mentioned embodiments can be combined arbitrarily. In order to make the description concise, not all possible combinations of the technical features in the above-mentioned embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0068] The above embodiments merely illustrate several implementations of the present invention, and while their descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art would be able to make numerous variations and improvements without departing from the spirit of the present invention, all of which fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be determined by the appended claims.

[0069] The above are only preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A distributed data security storage system based on blockchain, characterized in that: include: Dynamic sharding encryption module, which can automatically select sharding strategies based on data sensitivity level; let data sensitivity be S, and determine the data sensitivity level by the following formula: where w i is the weight of the i-th factor affecting data sensitivity, f i (D) is the quantitative value of data D under the i-th factor, For low-sensitivity data (S≤S low , S low For low sensitivity thresholds (preset), ECIES asymmetric encryption + random sharding storage is used; for high and low sensitivity data (S>S high , S high It combines attribute-based encryption (ABE) and threshold sharding (ShamirSecretSharing) to store shards on different blockchain nodes, realizing "sharding is authorization" and dynamically binding the shard storage location to the user's attributes. A cross-chain verification engine builds a lightweight cross-chain smart contract cluster to achieve cross-chain synchronization of data fingerprints (MerkleRoot) and verification based on zero-knowledge proofs (zk-SNARKs) without exposing the original data. During the zero-knowledge proof verification process, proof π is generated using π=Prove(x, w), where x is the public input and w is the secret input. During verification, the verification result is returned through Verify(x, π). A "verification chain within a chain" structure is proposed, with the main chain storing verification metadata and the sub-chain storing shard data. The storage node reputation system has a dynamic evaluation model, which includes storage stability (assessed by node online rate, assuming the node online time is t online , the total duration is t total , online rate ), data integrity (using timed PoR verification) and cross-chain response speed, etc., and predict the node failure probability through LSTM neural network. Let the input feature vector be X=[R online , I data , S cross-chain ,…], through the LSTM network P failure =LSTM(X) to get the node failure probability P failure , give priority to high-reputation nodes (i.e. P failure Low nodes) store key shards.

2. The distributed data security storage system based on blockchain according to claim 1, characterized in that: The data upload workflow of the system includes: After entering the data, sensitivity analysis was performed on the data; Based on the sensitivity analysis results, N encrypted fragments are generated through dynamic fragment encryption technology; Storage nodes are selected with the help of VRF (Verifiable Random Function) to ensure the geographical distribution of storage nodes.

3. The distributed data security storage system based on blockchain according to claim 1, characterized in that: The data access workflow of the system is as follows: The user submits an attribute certificate; The smart contract verifies the user’s attribute certificate; After verification, the required shards are reassembled and shard decryption is implemented based on the SGX trusted execution environment.

4. The distributed data security storage system based on blockchain according to claim 1, characterized in that: The data verification workflow of the system is as follows: The system periodically triggers PoRep (Proof of Storage) challenges; Once an abnormal shard is detected, it will be automatically repaired through the cross-chain engine.

5. A distributed data security storage method based on blockchain, applied to the system according to claim 1, characterized in that: The following steps are involved: Data sensitivity analysis steps: Determine the sensitivity level of input data using the formula Calculate data sensitivity S; Dynamic shard encryption steps: According to the data sensitivity level, when SS low When S>Shigh, low-sensitivity data is stored using ECIES asymmetric encryption combined with random sharding. When S>Shigh, high-sensitivity data is stored in different blockchain nodes using attribute-based encryption (ABE) combined with threshold sharding (ShamirSecretSharing). Storage node selection step: Use VRF (Verifiable Random Function) to select storage nodes with good geographical distribution to store encrypted shards; Data access verification step: The user submits the attribute certificate, and after verification by the smart contract, the required shards are reassembled and decrypted in the SGX trusted execution environment; Data verification and repair steps: Regularly trigger PoRep (proof of storage) challenges and automatically repair abnormal shards through the cross-chain engine.

6. The distributed data security storage method based on blockchain according to claim 5, characterized in that: In the data sensitivity analysis step, the data type, application scenario, and possible impact are comprehensively evaluated based on the preset sensitivity level judgment rules to determine the sensitivity level of the data. The evaluation process uses the formula 7. The distributed data security storage method based on blockchain according to claim 5, characterized in that: In the dynamic shard encryption step, when attribute-based encryption (ABE) is used for highly sensitive data, an encryption key is generated based on the correspondence between user attributes and data access permissions to achieve data encryption and dynamic binding of shard storage locations with user attributes.

8. The distributed data security storage method based on blockchain according to claim 5, characterized in that: In the storage node selection step, VRF (Verifiable Random Function) generates random and geographically distributed storage node selection results based on parameters such as the storage node's geographical location information, network status, and node load.

9. The distributed data security storage method based on blockchain according to claim 5, characterized in that: In the data access verification step, when the smart contract verifies the user attribute certificate, it compares it with the preset permission rules to determine whether the user has the permission to access the corresponding data shard.

10. The distributed data security storage method based on blockchain according to claim 5, characterized in that: In the data verification and repair step, the PoRep (Proof of Storage) challenge sends a verification request to the storage node, compares the data returned by the storage node with the characteristic information of the original data, and detects the integrity of the data and the reliability of the storage node.

Images