A blockchain-based business sensitive data management and control system

Abstract

The application belongs to the technical field of sensitive data management and control, and particularly relates to a business sensitive data management and control system based on a block chain, wherein the system comprises an architecture definition module, a ledger segmentation design module, a sub-ledger consensus construction module, a cross-business domain data interaction module, a sensitive data node allocation module and a ledger fault tolerance module. The scheme realizes local encrypted storage of sensitive data original text and operation logs of the sub-ledger by constructing a double-layer segmented architecture of the main ledger and the sub-ledger, combining cloud network fusion technology, completing sensitivity evaluation through feature selection and a machine learning model, preferentially allocating high-frequency data to near-main-ledger nodes according to data heat, preferentially allocating new data to low-load nodes according to node load, obtaining an optimal node load allocation scheme through a genetic algorithm when there is no low-load node, realizing dynamic expansion and merging of the sub-ledger, reducing data migration cost during business domain expansion, and guaranteeing uninterrupted sensitive data access services.

Description

Technical Field

[0001] This invention relates to the field of sensitive data management technology, specifically to a blockchain-based business sensitive data management system. Background Technology

[0002] A blockchain-based business sensitive data management system is a system that uses blockchain technology to dynamically manage business sensitive data.

[0003] Among existing approximate solutions, such as CN112134906B, a method for identifying and dynamically managing sensitive data in network traffic, this solution addresses the technical problems of traditional pattern matching detection of sensitive and malicious information in network traffic. These problems include low matching efficiency, large memory consumption, unstable matching, and low accuracy. Furthermore, the matching speed decreases as more pattern matching rules are added, leading to the inability to identify sensitive information in a timely and effective manner, which makes the system vulnerable to intrusion or even crashes. The solution first captures high-speed network traffic and divides it into multiple identification queues. It then identifies the Hypertext Transfer Protocol, private protocols, and encryption protocols to which the sub-network traffic belongs and parses and decodes them separately. Finally, it uses a pattern matching algorithm... By establishing multiple pattern matching automata for initial matching and secondary matching of untagged strings and sensitive strings, performing virus detection and removal before matching, dynamically correcting the pattern matching automata, and filtering and task allocation based on matching quality and speed, this approach achieves the technical effects of fast matching speed and high identification accuracy of sensitive and malicious information, reduced memory usage, rapid response to changes in pattern sets, effective blocking of sensitive and malicious information, prevention of system intrusion, and improved system security. However, it still suffers from the contradiction of traditional centralized ledger data disclosure leading to leakage and fragmented privacy protection, as well as the technical problem of insufficient full lifecycle management of sensitive data.

[0004] Furthermore, for example, CN114372098B, a platform and method for privacy data protection and data mining in power data platforms based on privileged account management, addresses the difficulty in simultaneously protecting privacy data and maximizing data mining value in power data platforms. It also addresses the challenges posed by privileged accounts leading to sensitive data leaks, insufficient security of existing anonymization algorithms, high computational overhead of homomorphic encryption, and the high computational demands and imperfect model update mechanisms of federated learning. The solution employs a platform that includes subsystems for privileged account management, sensitive data discovery and visualization analysis, and data security control and auditing. This is achieved through multi-method authentication, full account lifecycle management, and risk account management. The technical means of scanning and approval, sample data extraction and secure processing, local mining of full data in the power data platform, data replacement to retain core value, full lifecycle auditing of operations, and dual review of results have achieved the technical effects of fully protecting privacy data without reducing the value of power data mining, effectively preventing the theft of sensitive data caused by the leakage of privileged accounts, expanding the scope of data mining, improving mining accuracy, and achieving secure data sharing. However, there are still technical problems such as overload of popular nodes and idleness of unpopular nodes caused by traditional sensitive data load distribution methods, abuse of permissions of fixed node groups, and high data migration costs when expanding business domains. Summary of the Invention

[0005] To address the aforementioned issues and overcome the shortcomings of existing technologies, this invention provides a blockchain-based business sensitive data management system. Addressing the contradiction between the traditional centralized ledger approach—where data disclosure leads to leaks and privacy protection is fragmented—and the inadequacy of full lifecycle management of sensitive data, this solution constructs a two-tiered segmented architecture of a main ledger and sub-ledgers. Employing a ledger segmentation design method, it divides business domain sub-ledgers according to the enterprise's organizational structure, business lines, and sensitivity levels. Sensitivity assessment is completed using ANOVA feature selection and the SHAP model. Combined with cloud-network convergence technology, the main nodes of each business domain form a main ledger cluster. This enables local encrypted storage of the original text of sensitive data and operation logs in the sub-ledgers, while the main ledger only stores cross-domain shared information. This system maintains both local sensitive data privacy protection and system-level data consistency while ensuring cross-departmental collaborative sharing of business sensitive data. Full lifecycle management of sensitive data; addressing the technical issues of overloaded popular nodes, idle unpopular nodes, abuse of permissions in fixed node groups, and high data migration costs during business domain expansion caused by traditional sensitive data load distribution methods, this solution adopts a sensitive data node allocation method. First, high-frequency data is allocated to nodes closer to the main ledger based on data popularity. Then, new data is allocated to low-load nodes based on node load. When there are no low-load nodes, the optimal node load distribution scheme is obtained through a genetic algorithm. Combined with the VRF random node allocation mechanism and consistent hash mapping rules, and ledger fault tolerance methods to achieve dynamic expansion and merging of sub-ledgers and master node election and replacement in case of failure, this solution not only avoids node load imbalance and prevents the risk of permission abuse, but also ensures the unique ownership of sensitive data, reduces data migration costs during business domain expansion, and ensures uninterrupted access to sensitive data services.

[0006] The technical solution adopted by the present invention is as follows: The present invention provides a blockchain-based business sensitive data management and control system, which includes an architecture definition module, a ledger segmentation design module, a sub-ledger consensus construction module, a cross-business domain data interaction module, a sensitive data node allocation module, and a ledger fault tolerance module;

[0007] The architecture definition module constructs a two-layer ledger structure consisting of a main ledger and sub-ledgers. The main ledger is responsible for cross-business domain operation collaboration, while the sub-ledgers are responsible for storing sensitive data and verifying permissions within their respective business domains. By constructing a two-layer segmented architecture that combines a system-level main ledger with business domain-level sub-ledgers, a sensitive data management system that combines global consensus with local autonomy is formed.

[0008] The ledger segmentation design module adopts a ledger segmentation design method, deploying master nodes, verification nodes, and light nodes in each business domain. It uses cloud-network convergence technology, with the master nodes of each business domain forming a node cluster of the master ledger to realize data interaction between the master ledger and sub-ledgers. The master nodes are used for sensitive data management in the business domain, and the verification nodes are used for compliance auditing in the business domain. Local sensitive data access permission verification is completed through Byzantine fault-tolerant consensus.

[0009] The subledger consensus building module determines the local consensus process of the subledger. After the light node generates sensitive data, it encrypts and stores the sensitive data in the subledger, generates an operation log and broadcasts it to the subledger. The verification node verifies the authenticity of the sensitive data and the compliance of the access permissions to the sensitive data.

[0010] When a request for cross-domain access to sensitive data is received, the requesting party's sub-ledger uploads the requester's authorization certificate to the main ledger. The main ledger then notifies the verification node of the requested party's sub-ledger to verify the requester's access permissions. R business domain master nodes are randomly selected from the main ledger's node cluster to participate in the cross-domain access approval process. The cross-domain data access approval result is synchronized to the sub-ledgers corresponding to the selected R business domain master nodes. The requested party's sub-ledger only pushes sensitive data within the authorized scope to the requester and reports the authorization process back to the main ledger for record-keeping.

[0011] The sensitive data node allocation module adopts a sensitive data node allocation method to balance the load of light nodes and data access efficiency, and solves the technical problems of overload of popular nodes and idleness of unpopular nodes caused by traditional fixed allocation.

[0012] The ledger fault tolerance module uses a ledger fault tolerance method to realize the dynamic expansion and merging of sub-ledgers.

[0013] Furthermore, the specific operation steps of the ledger segmentation design method are as follows:

[0014] Step A1: Business domain segmentation. Specifically, this involves classifying the sensitivity levels of all sensitive data across the enterprise. Using the enterprise's organizational structure and business lines as boundaries, and combining these sensitivity levels, the entire enterprise's data domain is divided into N independent business domain sub-ledgers. Each sub-ledger corresponds to one business domain and the sensitive data associated with that business domain. The specific steps for classifying the sensitivity levels are as follows:

[0015] Step A11: Static evaluation, specifically, using the ANOVA feature selection algorithm to screen out the core attributes in sensitive data that have a significant impact on risk, and generating inherent static scores;

[0016] Step A12: Dynamic evaluation, specifically, combining business domain scenarios and access permission rules, using the SHAP machine learning model to analyze sensitive data interaction behavior, correcting the inherent static score, and finally outputting a risk level adaptation score.

[0017] Step A2: Sub-ledger node configuration, specifically, deploying 3 types of nodes in each business domain, including a unique master node, a verification node, and a light node;

[0018] Step A3: Sub-ledger storage data, specifically, the original text and operation logs of sensitive data generated by a business domain are only kept locally in the sub-ledger and are not uploaded to the main ledger;

[0019] Step A4: Cluster integration. Specifically, the data stored in the main ledger includes metadata identifiers shared across business domains, hash values ​​of sub-ledgers, cross-domain data access approval results, and network-wide consensus rules. The metadata identifiers include data type, data digest, and access permissions. The main ledger adopts a VRF random node allocation mechanism to avoid the risk of permission abuse caused by fixed node groups. A consistent hashing algorithm is used to formulate the mapping rules of metadata identifiers from the main ledger to the sub-ledgers, ensuring that sensitive data has a unique ownership and that the data migration cost is minimized when business domains are expanded.

[0020] Furthermore, the sensitive data node allocation method specifically includes the following steps:

[0021] Step B1: Prioritize data popularity. Specifically, collect the access frequency of sensitive data on each light node. The sub-ledger of each business domain will allocate frequently accessed sensitive data to the light node closest to the main ledger to reduce access latency.

[0022] Step B2: Node load priority. Specifically, a storage threshold is preset, and the CPU utilization and storage usage of each light node are monitored in real time to obtain load data. Newly generated sensitive data is preferentially allocated to light nodes with a load rate lower than the storage threshold to avoid node overload.

[0023] Step B3: When there are no light nodes with a load rate lower than the storage threshold in the sub-ledger, a genetic algorithm is used to calculate the optimal node allocation scheme based on the risk level adaptation score, the load data, and the access frequency. The adaptation calculation formula is as follows: ;

[0024] In the formula, Indicates compatibility. , and All represent weighting coefficients. This represents the frequency of visits after weighted average. This represents the highest load data for all light nodes. This represents the minimum load data for all light nodes. This represents the average load data for all light nodes. Indicates the first Frequency of access to sensitive data Indicates the first The load data of the light node corresponding to each sensitive data point. Indicates the first Risk level matching score for sensitive data This indicates a constraint condition.

[0025] Furthermore, the specific operation steps of the ledger fault tolerance method are as follows:

[0026] Step C1: Sub-ledger fault tolerance handling. Specifically, when the primary node of the sub-ledger fails, the verification node elects a new primary node from the sub-ledger and synchronizes the fault information and the identity of the new primary node to the primary ledger for record-keeping, ensuring that access to sensitive data in this business domain is not interrupted.

[0027] Step C2: Dynamic expansion and merging of the ledger. Specifically, a preset access threshold is set. When the amount of data in a business domain exceeds the access threshold, the main ledger triggers an expansion operation. The atomic ledger of the business domain is split into two new sub-ledgers through a sharding algorithm. When business integration requires merging business domains, the main ledger first locks the relevant sub-ledgers and suspends cross-domain writes. Subsequently, the main ledger synchronizes and verifies the sensitive data and access permissions of the sub-ledgers to avoid cross-domain data access interruption.

[0028] The beneficial effects achieved by the present invention using the above solution are as follows:

[0029] (1) In response to the contradiction between the disclosure of data and the fragmentation of privacy protection in traditional centralized ledgers, as well as the problem of insufficient control over the entire life cycle of sensitive data, this solution constructs a two-layer segmented architecture of main ledger and sub-ledger. It adopts the ledger segmentation design method, divides the business domain sub-ledger according to the enterprise's organizational structure, business lines and sensitivity levels, completes the sensitivity assessment through ANOVA feature selection and SHAP model, and combines cloud network convergence technology. The main nodes of each business domain form a main ledger cluster, realizes local encrypted storage of sensitive data original text and operation logs in the sub-ledger, and the main ledger only stores cross-domain shared information. Under the premise of ensuring the ability of cross-departmental business sensitive data collaborative sharing, it maintains the privacy protection of local sensitive data and the consistency of system-level data, and realizes the full life cycle control of sensitive data.

[0030] (2) In response to the technical problems caused by the traditional sensitive data load distribution method, such as overload of popular nodes, idleness of unpopular nodes, abuse of permissions of fixed node groups, and high data migration costs when expanding business domains, this solution adopts a sensitive data node allocation method. First, high-frequency data is allocated to the node closest to the main ledger based on data popularity. Then, new data is allocated to low-load nodes based on node load. When there are no low-load nodes, the optimal node load distribution scheme is obtained through genetic algorithm. Combined with VRF random node allocation mechanism and consistent hash mapping rules, and ledger fault tolerance method, dynamic expansion and merging of sub-ledgers and election and replacement of the main node in case of failure are realized. This not only avoids node load imbalance and prevents the risk of permission abuse, but also ensures that sensitive data belongs to the only entity, reduces the data migration cost when expanding business domains, and ensures that sensitive data access services are not interrupted. Attached Figure Description

[0031] Figure 1 A module connection diagram of a blockchain-based business sensitive data management system provided by the present invention;

[0032] Figure 2 A flowchart illustrating the ledger segmentation design method provided by this invention;

[0033] Figure 3 This is a flowchart illustrating the ledger fault-tolerance method provided by the present invention.

[0034] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used together with the embodiments of the invention to explain the invention and do not constitute a limitation thereof. Detailed Implementation

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

[0036] Example 1: See Figures 1 to 3 This embodiment provides a blockchain-based business sensitive data management and control system, which includes an architecture definition module, a ledger segmentation design module, a sub-ledger consensus construction module, a cross-business domain data interaction module, a sensitive data node allocation module, and a ledger fault tolerance module.

[0037] The architecture definition module constructs a two-layer ledger structure consisting of a main ledger and sub-ledgers. The main ledger is responsible for cross-business domain operation collaboration, while the sub-ledgers are responsible for storing sensitive data and verifying permissions within their respective business domains. By constructing a two-layer segmented architecture that combines a system-level main ledger with business domain-level sub-ledgers, a sensitive data management system that combines global consensus with local autonomy is formed.

[0038] The ledger segmentation design module adopts a ledger segmentation design method, deploying master nodes, verification nodes, and light nodes in each business domain. It uses cloud-network convergence technology, with the master nodes of each business domain forming a node cluster of the master ledger to realize data interaction between the master ledger and sub-ledgers. The master nodes are used for sensitive data management in the business domain, and the verification nodes are used for compliance auditing in the business domain. Local sensitive data access permission verification is completed through Byzantine fault-tolerant consensus.

[0039] The subledger consensus building module determines the local consensus process of the subledger. After the light node generates sensitive data, it encrypts and stores the sensitive data in the subledger, generates an operation log and broadcasts it to the subledger. The verification node verifies the authenticity of the sensitive data and the compliance of the access permissions to the sensitive data.

[0040] When a request for cross-domain access to sensitive data is received, the requesting party's sub-ledger uploads the requester's authorization certificate to the main ledger. The main ledger then notifies the verification node of the requested party's sub-ledger to verify the requester's access permissions. R business domain master nodes are randomly selected from the main ledger's node cluster to participate in the cross-domain access approval process. The cross-domain data access approval result is synchronized to the sub-ledgers corresponding to the selected R business domain master nodes. The requested party's sub-ledger only pushes sensitive data within the authorized scope to the requester and reports the authorization process back to the main ledger for record-keeping.

[0041] The sensitive data node allocation module adopts a sensitive data node allocation method to balance the load of light nodes and data access efficiency, and solves the technical problems of overload of popular nodes and idleness of unpopular nodes caused by traditional fixed allocation.

[0042] The ledger fault tolerance module uses a ledger fault tolerance method to realize the dynamic expansion and merging of sub-ledgers.

[0043] Example 2: See Figures 1 to 2 This embodiment is based on the above embodiment, and the specific operation steps of the ledger segmentation design method are as follows:

[0044] Step A1: Business domain segmentation. Specifically, this involves classifying the sensitivity levels of all sensitive data across the enterprise. Using the enterprise's organizational structure and business lines as boundaries, and combining these sensitivity levels, the entire enterprise's data domain is divided into N independent business domain sub-ledgers. Each sub-ledger corresponds to one business domain and the sensitive data associated with that business domain. The specific steps for classifying the sensitivity levels are as follows:

[0045] Step A11: Static evaluation, specifically, using the ANOVA feature selection algorithm to screen out the core attributes in sensitive data that have a significant impact on risk, and generating inherent static scores;

[0046] Step A12: Dynamic evaluation, specifically, combining business domain scenarios and access permission rules, using the SHAP machine learning model to analyze sensitive data interaction behavior, correcting the inherent static score, and finally outputting a risk level adaptation score.

[0047] Step A2: Sub-ledger node configuration, specifically, deploying 3 types of nodes in each business domain, including a unique master node, a verification node, and a light node;

[0048] Step A3: Sub-ledger storage data, specifically, the original text and operation logs of sensitive data generated by a business domain are only kept locally in the sub-ledger and are not uploaded to the main ledger;

[0049] Step A4: Cluster integration. Specifically, the data stored in the main ledger includes metadata identifiers shared across business domains, hash values ​​of sub-ledgers, cross-domain data access approval results, and network-wide consensus rules. The metadata identifiers include data type, data digest, and access permissions. The main ledger adopts a VRF random node allocation mechanism to avoid the risk of permission abuse caused by fixed node groups. A consistent hashing algorithm is used to formulate the mapping rules of metadata identifiers from the main ledger to the sub-ledgers, ensuring that sensitive data has a unique ownership and that the data migration cost is minimized when business domains are expanded.

[0050] Example 3: See Figures 1 to 2 This embodiment is based on the above embodiment, and the sensitive data node allocation method specifically includes the following steps:

[0051] Step B1: Prioritize data popularity. Specifically, collect the access frequency of sensitive data on each light node. The sub-ledger of each business domain will allocate frequently accessed sensitive data to the light node closest to the main ledger to reduce access latency.

[0052] Step B2: Node load priority. Specifically, a storage threshold is preset, and the CPU utilization and storage usage of each light node are monitored in real time to obtain load data. Newly generated sensitive data is preferentially allocated to light nodes with a load rate lower than the storage threshold to avoid node overload.

[0053] Step B3: When there are no light nodes with a load rate lower than the storage threshold in the sub-ledger, a genetic algorithm is used to calculate the optimal node allocation scheme based on the risk level adaptation score, the load data, and the access frequency. The adaptation calculation formula is as follows: ;

[0054] In the formula, Indicates compatibility. , and All represent weighting coefficients. This represents the frequency of visits after weighted average. This represents the highest load data for all light nodes. This represents the minimum load data for all light nodes. This represents the average load data for all light nodes. Indicates the first Frequency of access to sensitive data Indicates the first The load data of the light node corresponding to each sensitive data point. Indicates the first Risk level matching score for sensitive data This indicates a constraint condition.

[0055] Example 4: See Figures 1 to 3 This embodiment is based on the above embodiment, and the specific operation steps of the ledger fault tolerance method are as follows:

[0056] Step C1: Sub-ledger fault tolerance handling. Specifically, when the primary node of the sub-ledger fails, the verification node elects a new primary node from the sub-ledger and synchronizes the fault information and the identity of the new primary node to the primary ledger for record-keeping, ensuring that access to sensitive data in this business domain is not interrupted.

[0057] Step C2: Dynamic expansion and merging of the ledger. Specifically, a preset access threshold is set. When the amount of data in a business domain exceeds the access threshold, the main ledger triggers an expansion operation. The atomic ledger of the business domain is split into two new sub-ledgers through a sharding algorithm. When business integration requires merging business domains, the main ledger first locks the relevant sub-ledgers and suspends cross-domain writes. Subsequently, the main ledger synchronizes and verifies the sensitive data and access permissions of the sub-ledgers to avoid cross-domain data access interruption.

[0058] Example 5: See Figures 1 to 3 This embodiment is based on the above embodiment. The light node refers to the terminal that generates and uses sensitive data. In this embodiment, the light node specifically refers to the employee's office computer.

[0059] Example 6: See Figures 1 to 3The only difference between this embodiment and the previous embodiment is the light node. In this embodiment, the light node specifically refers to the business system server.

[0060] Example 7: See Figures 1 to 3 This embodiment is based on the above embodiment, and the request for cross-domain access to sensitive data specifically refers to the sales domain needing to access customer payment data from the financial domain.

[0061] Example 8: See Figures 1 to 3 This embodiment is based on the above embodiment, wherein the R business domain master nodes are R=2*F+1, F is the number of sub-ledger fault-tolerant nodes, and F=3.

[0062] Example 9: See Figures 1 to 3 This embodiment is based on the above embodiment, wherein the entire enterprise data domain is divided into N independent business domain sub-ledgers, where N=8.

[0063] Example 10: See Figures 1 to 3 This embodiment is based on the above embodiment, and in step B2, the storage threshold is 60%.

[0064] Example 11: See Figures 1 to 3 This embodiment is based on the above embodiment. In step C2, the access threshold is that the TPS (Transactions Per Second) of the sub-ledger is >800.

[0065] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0066] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

[0067] The present invention and its embodiments have been described above. This description is not restrictive, and the accompanying drawings are only one embodiment of the present invention; the actual structure is not limited thereto. In conclusion, if those skilled in the art are inspired by this description and design similar structures and embodiments without departing from the spirit of the invention, such designs should fall within the protection scope of the present invention.

Claims

1. A blockchain-based business sensitive data management and control system, characterized in that, It includes an architecture definition module, a ledger segmentation design module, a sub-ledger consensus building module, a cross-business domain data interaction module, a sensitive data node allocation module, and a ledger fault tolerance module; The architecture definition module constructs a two-layer ledger structure consisting of a main ledger and sub-ledgers. The main ledger is responsible for cross-business domain operation collaboration, while the sub-ledgers are responsible for storing sensitive data and verifying permissions within their respective business domains. The ledger segmentation design module adopts a ledger segmentation design method, deploying master nodes, verification nodes, and light nodes in each business domain. It uses cloud-network convergence technology, with the master nodes of each business domain forming a node cluster of the master ledger to realize data interaction between the master ledger and sub-ledgers. The master nodes are used for sensitive data management in the business domain, and the verification nodes are used for compliance auditing in the business domain. Local sensitive data access permission verification is completed through Byzantine fault-tolerant consensus. The subledger consensus building module encrypts and stores sensitive data in the subledger after the light node generates sensitive data, generates an operation log and broadcasts it to the subledger, and the verification node verifies the authenticity of the sensitive data and the compliance of the access permissions to the sensitive data. When a request for cross-domain access to sensitive data is received, the requesting party's sub-ledger uploads the requester's authorization certificate to the main ledger. The main ledger then notifies the verification node of the requested party's sub-ledger to verify the requester's access permissions. R business domain master nodes are randomly selected from the main ledger's node cluster to participate in the cross-domain access approval process. The cross-domain data access approval result is synchronized to the sub-ledgers corresponding to the selected R business domain master nodes. The requested party's sub-ledger only pushes sensitive data within the authorized scope to the requester and reports the authorization process back to the main ledger for record-keeping. The sensitive data node allocation module employs a sensitive data node allocation method to balance the load of lightweight nodes with data access efficiency. The ledger fault tolerance module uses a ledger fault tolerance method to realize the dynamic expansion and merging of sub-ledgers.

2. The business-sensitive data management system based on blockchain according to claim 1, characterized in that, The specific steps of the ledger segmentation design method are as follows: Step A1: Business domain segmentation. Specifically, this involves classifying the sensitivity levels of all sensitive data across the enterprise. Using the enterprise's organizational structure and business lines as boundaries, and combining these sensitivity levels, the entire enterprise's data domain is divided into N independent business domain sub-ledgers. Each sub-ledger corresponds to one business domain and the sensitive data associated with that business domain. The specific steps for classifying the sensitivity levels are as follows: Step A11: Static evaluation, specifically, using the ANOVA feature selection algorithm to screen out the core attributes in sensitive data that have a significant impact on risk, and generating inherent static scores; Step A12: Dynamic evaluation, specifically, combining business domain scenarios and access permission rules, using the SHAP machine learning model to analyze sensitive data interaction behavior, correcting the inherent static score, and finally outputting a risk level adaptation score. Step A2: Sub-ledger node configuration, specifically, deploying 3 types of nodes in each business domain, including a unique master node, a verification node, and a light node; Step A3: Sub-ledger storage data, specifically, the original text and operation logs of sensitive data generated by a business domain are only kept locally in the sub-ledger and are not uploaded to the main ledger; Step A4: Cluster integration, specifically, the data stored in the main ledger includes metadata identifiers shared across business domains, hash values ​​of sub-ledgers, approval results for cross-domain data access, and consensus rules across the entire network. The metadata identifiers include data type, data digest, and access permissions. The main ledger adopts a VRF random node allocation mechanism and uses a consistent hashing algorithm to formulate mapping rules for metadata identifiers from the main ledger to sub-ledgers.

3. The business-sensitive data management and control system based on blockchain according to claim 2, characterized in that, The method for allocating sensitive data nodes specifically includes the following steps: Step B1: Prioritize data popularity. Specifically, collect the access frequency of sensitive data for each light node, and assign frequently accessed sensitive data to the light node closest to the main ledger in each business domain's sub-ledger. Step B2: Node load priority, specifically, preset storage threshold, monitor the CPU utilization and storage utilization of each light node in real time to obtain load data, and prioritize the allocation of newly generated sensitive data to light nodes with load rates lower than the storage threshold; Step B3: When there are no light nodes with a load rate lower than the storage threshold in the sub-ledger, the optimal node allocation scheme is dynamically output by using a genetic algorithm based on the risk level adaptation score, the load data, and the access frequency.

4. A business-sensitive data management and control system based on blockchain according to claim 3, characterized in that, The specific steps of the ledger fault tolerance method are as follows: Step C1: Sub-ledger fault tolerance handling, specifically, when the primary node of the sub-ledger fails, the verification node elects a new primary node from the sub-ledger and simultaneously synchronizes the fault information and the identity of the new primary node to the primary ledger for record-keeping. Step C2: Dynamic expansion and merging of the ledger. Specifically, a preset access threshold is set. When the amount of data in the business domain exceeds the access threshold, the main ledger triggers an expansion operation. The atomic ledger of the business domain is split into two new sub-ledgers through a sharding algorithm. When business integration requires merging business domains, the main ledger first locks the relevant sub-ledgers and suspends cross-domain writes. Then, the main ledger synchronizes and verifies the sensitive data and access permissions of the sub-ledgers.

Images