Automatic data compliance checking and tracking system based on intelligent contract

Abstract

The invention discloses an automatic data compliance check tracking system based on a smart contract, and relates to the technical field of data check, and the system comprises the steps: building a hierarchical mapping database of domain classification samples and compliance check depth; deploying a field identification engine, and analyzing the data packet information according to the field identification engine to determine a field type; identifying a compliance check depth corresponding to the domain type based on the hierarchical mapping database, and loading a corresponding check rule cluster from an intelligent contract strategy library according to the compliance check depth; and performing compliance check according to the check rule cluster, and recording a compliance check state to perform blockchain upchain storage. The technical problems that in the prior art, the execution efficiency of a data compliance check process is low, and traceability cannot be achieved are solved, and the technical effects that the compliance check efficiency and accuracy are improved, and the check process is credible and traceable are achieved.

Description

Technical Field

[0001] The present invention relates to the technical field of data inspection, and particularly to an automated data compliance inspection and tracking system based on smart contracts. Background Art

[0002] With the diversification of data types, the complexity of transmission protocols, and the dynamism of usage scenarios, traditional data compliance inspection methods have become difficult to meet the requirements of modern data management. Most existing data compliance inspections rely on static rules or manual intervention, resulting in low execution efficiency of the compliance inspection process. At the same time, the compliance inspection process lacks standardized records and a complete tracking mechanism, leading to problems in aspects such as post-event traceability and making it difficult to achieve transparent supervision of the entire process. Summary of the Invention

[0003] This application provides an automated data compliance inspection and tracking system based on smart contracts, which is used to solve the technical problems of low execution efficiency of the data compliance inspection process and inability to achieve traceability in the prior art.

[0004] In view of the above problems, this application provides an automated data compliance inspection and tracking system based on smart contracts.

[0005] This application provides an automated data compliance inspection and tracking system, and the system includes:

[0006] A hierarchical mapping establishment module, used to establish a hierarchical mapping database of domain classification samples and compliance inspection depths; a domain identification module, used to deploy a domain identification engine to determine the domain type according to the analysis of data packet information by the domain identification engine; a contract rule loading module, used to identify the compliance inspection depth corresponding to the domain type based on the hierarchical mapping database, and load the corresponding inspection rule cluster from the smart contract policy library according to the compliance inspection depth; a compliance inspection execution module, used to perform compliance inspections according to the inspection rule cluster, record the compliance inspection status, and store it on the blockchain.

[0007] One or more technical solutions provided in this application have at least the following technical effects or advantages:

[0008] This application establishes a hierarchical mapping database for domain classification samples and compliance check depths; deploys a domain recognition engine to determine the domain type by parsing the data packet information according to the domain recognition engine; identifies the compliance check depth corresponding to the domain type based on the hierarchical mapping database, and loads the corresponding check rule cluster from the smart contract policy library according to the compliance check depth; performs compliance checks according to the check rule cluster, and records the compliance check status for blockchain storage. The present invention solves the technical problems of low execution efficiency and inability to achieve traceability in the data compliance check process in the prior art. By constructing a hierarchical mapping database, intelligent domain recognition, dynamically loading check rules based on smart contracts, and combining blockchain storage of compliance status, the technical effects of improving compliance check efficiency, accuracy, and the credibility and traceability of the check process are achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the following drawings are only some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0010] Figure 1 Structural schematic diagram of an automated data compliance check and tracking system based on smart contracts provided by an embodiment of this application;

[0011] Figure 2 Structural schematic diagram of a hierarchical mapping establishment module in an automated data compliance check and tracking system based on smart contracts provided by an embodiment of this application.

[0012] Explanation of reference numerals: Hierarchical mapping establishment module 11, domain recognition module 12, contract rule loading module 13, compliance check execution module 14. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0013] This application provides an automated data compliance check and tracking system based on smart contracts to solve the technical problems of low execution efficiency and inability to achieve traceability in the data compliance check process in the prior art. By constructing a hierarchical mapping database, intelligent domain recognition, dynamically loading check rules based on smart contracts, and combining blockchain storage of compliance status, the technical effects of improving compliance check efficiency, accuracy, and the credibility and traceability of the check process are achieved.

[0014] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in the present application without creative efforts belong to the scope of protection of the present application.

[0015] It should be noted that any variations of the terms "including" and "having" are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or modules that are not clearly listed or are inherent to these processes, methods, products, or devices.

[0016] Embodiment 1, as Figure 1 shown, the embodiment of the present application provides an automated data compliance check and tracking system based on smart contracts. The system includes:

[0017] A hierarchical mapping establishment module 11 for establishing a hierarchical mapping database of domain classification samples and the depth of compliance checks.

[0018] In the embodiment of the present application, during the process of the hierarchical mapping establishment module 11 establishing a hierarchical mapping database of domain classification samples and the depth of compliance checks, first, collect compliance operation process samples corresponding to each domain to form representative domain classification samples, which are used to reflect typical compliance behaviors in different industries or business scenarios; secondly, extract key compliance fields from the collected operation processes to construct compliance field samples, which cover feature contents closely related to compliance such as data types, sensitivity levels, operation nodes, etc.; finally, conduct in-depth analysis on the compliance field samples, evaluate the depth of compliance checks required for each domain, and based on the corresponding relationship of "domain classification sample - check depth", finally establish a hierarchical mapping database.

[0019] Furthermore, as Figure 2 shown, in the system provided by the embodiment of the application, the hierarchical mapping establishment module 11 further includes:

[0020] A compliance process sample collection unit for collecting compliance operation process samples corresponding to each domain in the domain classification samples; a compliance field extraction unit for extracting compliance field samples of the compliance operation process samples corresponding to each domain; a check depth association mapping unit for conducting check depth analysis on the compliance field samples, outputting the depth of compliance checks corresponding to each domain in the domain classification samples, and outputting the hierarchical mapping database according to the corresponding relationship between the domain classification samples and the depth of compliance checks.

[0021] In the embodiment of the present application, first, the compliance process sample collection unit adopts an operation log analysis method to collect key data processing processes in different fields from the actual business system, such as operation paths of data collection, transmission, storage, and sharing. By analyzing the operation behavior sequences recorded in the logs, the typical compliance operation processes in each industry or field are restored, thereby constructing a representative domain classification operation process sample set.

[0022] Secondly, the compliance field extraction unit uses a rule-based field recognition method, relying on a preset sensitive field rule library (such as matching rules for identifying characteristic fields such as ID numbers, contact information, and location information), to extract data fields related to compliance control from the collected operation process samples. These fields are identified as compliance field samples, including basic attributes such as their field types, sensitivity levels, and format characteristics, providing a structured input for subsequent analysis.

[0023] Subsequently, the inspection depth correlation mapping unit conducts an in-depth analysis of the compliance field samples. In this process, for each field, M compliance inspection depth samples corresponding to it are obtained. These samples are from the field feature analysis results of different compliance operation processes, and the difference in the number of samples between fields is ensured to be controlled within a preset statistical variance threshold to ensure the representativeness and stability of the analysis results; subsequently, the mean value of these M inspection depth values is calculated, and the obtained average value is used as the compliance inspection depth output for this field. Finally, based on the corresponding relationship between each field and its average inspection depth, the construction of a hierarchical mapping database is completed.

[0024] Furthermore, in the system provided by the application embodiment, the inspection depth correlation mapping unit further includes:

[0025] The depth sample acquisition subunit is used to obtain M compliance inspection depths corresponding to each field, where M is the corresponding number of samples, and the variance of the corresponding number of samples between each field is less than a preset threshold; the inspection depth output subunit is used to calculate the compliance mean value according to the M compliance inspection depths and output the mean inspection depth, and output the mean inspection depth as the compliance inspection depth corresponding to the field.

[0026] In the embodiment of the present application, first, the deep sample acquisition subunit applies a scoring mapping method to the compliance field samples extracted in each field, and maps the attributes of each field (such as sensitivity level, field format complexity, field type) to a corresponding numerical score. For example, set "high-sensitivity field" to 3 points and "structured field" to 1 point, and convert each field into a compliance check depth score value according to this rule. Then, count this score by field to obtain M score samples under each field. To ensure the comparability of the score samples in different fields, calculate the variance of the sample numbers in each field. If the number of samples in a certain field is too small or the difference is too large, it will not be included in the analysis to ensure that the obtained deep samples are representative. Finally, through this step, a set of M compliance check depth score values corresponding to each field is obtained.

[0027] Next, the check depth output subunit uses the arithmetic mean method, that is, simply sums the M score values obtained in each field and then divides by M to calculate a mean check depth, which is used to represent the compliance review intensity of this field. The larger this value is, the more complex or risky the compliance fields in this field are, and more complex check rules should be adapted. Finally, output this mean check depth as the representative check depth of the current field.

[0028] Furthermore, in the system provided by the embodiment of the application, the check depth association mapping unit further includes:

[0029] The field attribute annotation subunit is used to annotate the field type, field sensitivity level, field format complexity, and compliance association degree of the compliance field samples; the deep feature weight calculation subunit is used to perform feature quantization according to the field type, field sensitivity level, field format complexity, and compliance association degree, output a deep feature vector, calculate the weights of the deep feature vector, and output the compliance check depth corresponding to each field.

[0030] In the embodiment of the present application, in the field attribute annotation subunit, a predefined rule matching method is used to annotate the attributes of each compliance field sample. Specifically, according to the pre-constructed rule dictionary, identify the field name, field content features, and field usage. For example, when the field name is "ID number" or contains an obvious identity identification format (such as 18 digits, including a check digit), it is identified as a "text type" field, the sensitivity level is marked as "high", the format complexity is marked as "medium" (because its format has a fixed structure but is not difficult to identify), and the compliance association degree is marked as "high". Another example is that the field "transaction serial number" is identified as "structured numerical type", the sensitivity level is "medium", the format complexity is "low", and the compliance association degree is "medium". Through this matching method based on field features and the rule library, an annotation result containing four attribute information is output for each field, forming a field attribute set with clear structure and available for subsequent calculations.

[0031] In the deep feature weight calculation subunit, the linear weighted scoring method is used to quantify and calculate the above field attributes to generate the compliance check depth that can be used for statistical analysis. Specifically, each type of field attribute is converted into a score. In the field type, "text type" is assigned 1 point, and "structured" is assigned 2 points; in the field sensitivity level, "low" is 1 point, "medium" is 2 points, and "high" is 3 points; in the format complexity, "low" is 1 point, "medium" is 2 points, and "high" is 3 points; in the compliance correlation degree, "low" is 1 point, "medium" is 2 points, and "high" is 3 points. Suppose the annotation result of a certain field is "text type, high sensitivity, medium complexity, high compliance correlation", then its original vector is [1, 3, 2, 3]. Weight coefficients are set for each attribute dimension. For example, the field type weight is 0.1, the sensitivity level is 0.4, the format complexity is 0.2, and the compliance correlation degree is 0.3. Through weighted calculation, 1×0.1 + 3×0.4 + 2×0.2 + 3×0.3 = 2.6, and this result is the compliance check depth corresponding to this field. For each field, the check depth is calculated respectively using the above method, and the final compliance check depth of this field is determined through the set policy (such as selecting the maximum value, weighted representative field, etc.).

[0032] Finally, according to the calculation results of the field attributes in each field, the compliance check depth corresponding to each field is output.

[0033] The field identification module 12 is used to deploy the field identification engine and determine the field type according to the parsed data packet information by the field identification engine.

[0034] In the embodiment of the present application, the field identification module 12 is used to deploy the field identification engine and perform multi-dimensional parsing on the received data packet information through this engine, so as to determine the business field type to which the data belongs and provide a classification basis for the subsequent compliance check process. Specifically, this module calls the field identification engine to perform operations such as protocol parsing, IP location parsing, and content scanning on the data packet. Among them, protocol parsing is used to extract the key field information in the communication protocol, IP location parsing is used to determine the geographical location of the data source, and content scanning is used to identify the keyword tags in the data. According to the above parsing results, field feature fields are extracted and used as classification variables for identification and judgment, and finally the field type to which the data belongs is determined.

[0035] Furthermore, in the system provided by the embodiment of the application, the field identification module 12 further includes:

[0036] A data packet protocol parsing unit for protocol parsing, IP address parsing, and content scanning of the data packet information according to the domain recognition engine, where the protocol parsing includes parsing fields in the HTTP request protocol, the IP address parsing includes parsing the location address, and the content scanning includes identifying content keyword tags; a domain feature recognition unit for obtaining domain feature fields according to the output result of the data packet protocol parsing unit, and performing identification and classification using the domain feature fields as classification variables to determine the domain type.

[0037] In the embodiment of the present application, first, the data packet protocol parsing unit analyzes and processes the communication protocol content in the data packet through a field structure parsing method, and focuses on parsing the HTTP request protocol. Key fields such as the request path, request method, and request header information in the data packet are extracted, and through formatted parsing, the business keywords and request behaviors in the URL path are identified. For example, the appearance of " / claim / submit" in the request path may indicate an insurance claim business, belonging to the financial field. The protocol field feature information representing the request intention is output in this step.

[0038] Next, the data packet protocol parsing unit continues to process the source IP address of the data packet, adopts an IP address location recognition method, and determines the source area or the affiliated network institution of the data packet by querying the built-in geographical IP database. For example, if the IP address corresponds to a dedicated address segment belonging to a medical institution or a specific government affairs system, it is inferred that the data comes from the medical or government affairs system. The territorial label information of the data source is output in this step, which is used to assist in the judgment of industry attribution.

[0039] Subsequently, the data packet protocol parsing unit performs a scanning operation on the text content or parameter information in the data packet, adopts a keyword tag matching method, and identifies whether the data contains words highly relevant to a specific domain. According to a preset keyword library, for example, the medical field includes "prescription", "diagnosis", "medical insurance number", and the financial field includes "account balance", "transfer amount", etc., the data content is compared item by item. When a specific keyword appears frequently, it is recorded as the content semantic tag of a specific domain.

[0040] After completing the extraction of the above three pieces of information, the domain feature recognition unit combines the protocol fields, territorial tags, and content tags according to the output result of the data packet protocol parsing unit to form a set of domain feature fields. This unit adopts a classification method based on rule matching and makes a comprehensive judgment on these features according to the preset classification rules. For example, when the protocol path involves " / patient / record", the territorial location is "regional hospital network segment", and the content contains the keyword "diagnosis conclusion", the matching rule identifies it as the "medical field". In this way, the domain feature recognition unit completes the classification of the data belonging to the industry or business type.

[0041] Finally, the domain feature recognition unit outputs a clear domain type label, such as "medical", "finance", "government affairs" or "e-commerce". This recognition result will be used as the key basis for the subsequent module to load the compliance check rule cluster and set the check depth, ensuring that the entire compliance check process has the ability of pre-classification and accurate adaptation.

[0042] The contract rule loading module 13 is used to identify the compliance check depth corresponding to the domain type based on the hierarchical mapping database, and load the corresponding check rule cluster from the smart contract policy library according to the compliance check depth.

[0043] In the embodiment of the present application, first, the contract rule loading module 13 identifies the compliance check depth corresponding to the domain type of the current data based on the hierarchical mapping database query method. A corresponding relationship between different domain types and the required check depth has been established in advance in the hierarchical mapping database. The check depth is represented in numerical form and is used to reflect the check intensity and scope required by the domain in terms of data compliance. For example, the medical domain may correspond to a check depth of 3, indicating that rules of medium complexity such as field sensitivity, authorization information, and desensitization processing need to be covered; while the financial domain may correspond to a check depth of 4, and more stringent compliance requirements such as transaction chain integrity and fund flow audit need to be covered.

[0044] Then, the hierarchical rule index calling method is adopted to call the corresponding level of check rule cluster from the smart contract policy library according to the above check depth. The smart contract policy library is divided into multiple rule clusters by level, and each level is stored as an independent smart contract instance, with characteristics such as automatic execution, result traceability, and content immutability. The rule cluster contains compliance check rule entries matching this depth level. For example, the rule cluster corresponding to the depth level 3 contains rule entries such as field encryption compliance and access permission consistency. According to the current depth value, the rule cluster contract corresponding to it is accurately loaded to ensure that the most suitable rule set is called by the subsequent compliance check execution module.

[0045] Finally, the contract rule loading module 13 loads the check rule cluster that matches the domain and compliance requirements of the current data.

[0046] Furthermore, the system provided by the embodiment of the application is also used for:

[0047] The smart contract policy library includes multiple levels of check rule clusters. The check scope and complexity of each level of check rule cluster are different, and each level of check rule cluster is stored as an independent smart contract.

[0048] In the embodiment of the present application, in order to realize dynamic matching and automatic loading of compliance check rules, a smart contract policy library is set, and the corresponding check rule cluster is loaded from the policy library according to the identified compliance check depth through the contract rule loading module 13. The smart contract policy library adopts a hierarchical structure design, including multiple levels of check rule clusters, each level corresponds to different business compliance requirements, and has clear hierarchical division and independent execution capabilities.

[0049] First, through the deep index matching method, according to the field type identified by the previous module and the corresponding compliance check depth, the current rule level to be loaded is determined. For example, if the current data comes from the financial field, the corresponding check depth is 4, then the 4th level rule cluster in the policy library needs to be called. The compliance check depth is a key parameter to measure the breadth and complexity of the check. The higher the value, the more comprehensive the required compliance review and the more rigorous the rule logic.

[0050] Then, the rule retrieval operation is performed in the smart contract policy library. The policy library pre-builds a multi-level inspection rule cluster. For example, from level 1 to level 5, each level encapsulates compliance rule entries of different complexity and scope: level 1 may only include basic field integrity verification and format checking, level 3 may add data access permission verification and user identity verification, and level 5 may include cross-border data flow audits, authorization chain traceability, multi-level data desensitization and regulatory compliance checks. Each level of rule cluster is not only different in inspection scope and complexity, but also stored and managed as an independent smart contract. Smart contracts have technical advantages such as automatic execution, on-chain verification and non-tamperability, which can ensure the safety and reliability of the rule loading process and support subsequent automatic triggering and execution.

[0051] Finally, based on the inspection depth, the inspection rule cluster of the corresponding level is loaded from the smart contract strategy library.

[0052] The compliance check execution module 14 is used to perform compliance checks according to the inspection rule cluster and record the compliance check status for storage on the blockchain.

[0053] In the embodiment of the present application, the compliance check execution module 14 is used to perform compliance checks on data according to the loaded inspection rule cluster, and store the final inspection status on the blockchain. The whole process includes four steps: rule risk assessment, priority sorting, inspection execution and result on the blockchain, ensuring that the inspection process is efficient, accurate and traceable.

[0054] Specifically, first, a feature-weighted scoring method is adopted to evaluate the risk level of each inspection rule. Each rule is scored from three aspects: data sensitivity (for example, assigning 3 points if it involves ID numbers or financial information), severity of violation consequences (for example, assigning 3 points if violation will lead to data leakage or legal liability), and criticality of business processes (for example, assigning 3 points if it is related to core transaction logic). The three scores are combined and calculated according to preset weights (for example, sensitivity 0.4, consequence 0.4, criticality 0.2) to obtain a total score, which is used as the risk level indicator of the rule to measure its priority in the entire rule set.

[0055] Subsequently, a descending sorting method based on risk values is used to sort the rule cluster in descending order according to the risk level indicator, generating an ordered execution sequence. For example, if the scores of three rules are 4.5, 3.2, and 2.0 respectively, the execution order is the one with the highest risk value first, that is, the order is: Rule 1, Rule 2, Rule 3. This process ensures that high-risk rules are preferentially triggered for inspection, thereby preferentially identifying potential serious violation risks.

[0056] Then, compliance checks are performed on the data item by item according to the sorting result, using the rule condition matching method to compare the logical conditions in the rule with the data to be detected one by one. For example, checking whether the fields are desensitized, whether the user permissions meet the access requirements, and whether there is illegal cross-border transmission. After each rule is executed, information such as the judgment result (passed / failed), triggered fields, and reasons for failure of the rule is recorded to gradually build the compliance check status of the current data.

[0057] Finally, the final compliance check status is processed and stored on the blockchain through the blockchain evidence storage method. The inspection results (such as overall compliance status, failed rule numbers, timestamps, data identifiers, etc.) are encapsulated into a standard data structure and written into the blockchain network. Due to the characteristics of the blockchain, such as immutability, time orderliness, and full-chain traceability, the execution process and results of each inspection can be traced and verified, providing reliable support for data compliance.

[0058] Furthermore, in the system provided by the application embodiment, the compliance check execution module 14 further includes:

[0059] A rule risk level analysis unit for analyzing the risk level of the inspection rule cluster to obtain a risk level indicator; a rule execution sequence sorting unit for sorting the inspection rule cluster in descending order according to the size of the risk level indicator in sequence, outputting an inspection rule cluster sequence, and performing compliance checks according to the inspection rule cluster sequence.

[0060] In the embodiment of the present application, first, the rule risk level analysis unit uses the feature weight scoring method to analyze the risk level of each rule in the inspection rule cluster. Specifically, each rule is scored from three dimensions. One is data sensitivity. For example, if a rule involves highly sensitive fields such as ID numbers, bank accounts, and health information, the score is 3 points. The second is the severity of the violation consequence. For example, if a rule violation may lead to serious consequences such as data leakage and regulatory penalties, the score is 3 points. The third is business criticality. For example, if a rule is associated with key business processes such as user authentication and fund transfer, the score is 3 points. The scores of each dimension are weighted and calculated according to a preset weight (for example, sensitivity 0.4, consequence 0.4, criticality 0.2) to obtain a numerical risk level indicator. This indicator is used to measure the relative risk level of each rule in the compliance inspection and provide a basis for subsequent sorting.

[0061] Then, the rule execution sequence sorting unit uses the numerical descending sorting method to sort the risk level indicators of the aforementioned rules. All rules are arranged from high to low according to the risk indicators to generate an ordered inspection rule cluster sequence. For example, if the risk values of three rules are 4.5, 3.8, and 2.2 respectively, the execution order after sorting is the first rule is 4.5, the second is 3.8, and the third is 2.2. This sorting process ensures that in subsequent compliance inspections, rules with higher risk levels are preferentially executed, thus achieving the goal of risk-first processing and pre-identification of key risks.

[0062] Finally, the compliance inspection is performed according to the inspection rule cluster sequence, and logical judgments and compliance verifications are performed on the data to be inspected one by one.

[0063] Furthermore, in the system provided by the application embodiment, the rule execution sequence sorting unit is further used for:

[0064] The dependency rule extraction subunit is used to perform dependency analysis on the rule relationships of the inspection rule cluster to obtain dependency inspection rules, where the dependency analysis includes precondition dependency, data dependency, and time dependency; the dependency sequence update subunit is used to update the inspection rule cluster sequence according to the sequence relationship of the dependency inspection rules.

[0065] In the embodiment of the present application, first, the dependency rule extraction subunit adopts the rule semantic relationship matching method to perform dependency analysis on the rule pairs in the sorted inspection rule cluster. Specifically, the rule preconditions, input fields and execution timing labels are extracted from the rule definition, and compared item by item to identify three types of dependencies: precondition dependency, data dependency and time dependency. Among them, precondition dependency, by analyzing whether the enabling condition field of the rule depends on the execution results of other rules, for example, the trigger condition of rule B is "the execution result of rule A is true", at this time, mark A→B as a pre-dependency relationship; data dependency, by checking whether the rule input field is derived from the output field of other rules, such as rule C needs to read the "user area identification" extracted from rule D, then mark it as D→C data dependency; time dependency, by judging whether the rule contains explicit execution order requirements, for example, rule E needs to be completed before rule F, usually marked by "execution order number" or "effective time window" in the rule definition. Through the above analysis, a rule dependency set containing multiple directed edges is constructed, and a set of dependency check rule pairs containing sequential execution constraints are output as the input basis for subsequent updates.

[0066] The dependency sequence update subunit then uses a topological sorting method to optimize the structure of the original rule execution sequence. Specifically, the rules are regarded as nodes in the graph, and the dependencies are regarded as directed edges to construct a dependency graph. Then a topological sorting algorithm (such as DFS topological traversal) is applied to rearrange the rule execution order without breaking the original high-risk priority sorting structure. For example, if the risk value of rule A is higher, but there is a dependency relationship from B to A, the order is adjusted so that B is executed before A, forming a new rule sequence: B→A→other rules. To avoid conflicts, the original risk level order is retained as an auxiliary weight during the sorting process to ensure that the higher risk ones are prioritized among multiple sorting results that meet the dependency conditions.

[0067] Finally, an updated inspection rule cluster sequence that takes into account both risk levels and dependencies is output. This sequence not only meets the principle of high-risk priority execution, but also strictly follows the logical constraints between rules, providing a reliable sequential basis for the accurate execution of subsequent compliance checks.

[0068] Furthermore, the system provided in the application embodiment is also used for:

[0069] The rule execution sequence sorting unit is further used to perform dependency analysis on the rule relationship of the inspection rule cluster, obtain non-dependency inspection rules, and execute the non-dependency inspection rules in parallel to update the inspection rule cluster sequence.

[0070] In the embodiment of the present application, when the rule execution sequence sorting unit performs dependency analysis on the rule relationships of the inspection rule cluster, it first uses a directed graph modeling method to structurally express the logical dependencies between the rules. Specifically, each inspection rule is abstracted as a node in the graph, and directed edges are established based on the existing prerequisite dependencies (such as a rule depending on the judgment result of another rule), data dependencies (such as the fields required by a rule being output by other rules), and time dependencies (such as requiring a rule to be executed before another rule) between the rules, constructing a rule dependency graph. In this graph, the direction of the edge represents the dependency relationship. For example, an edge pointing from rule A to rule B indicates that rule B depends on the execution result of rule A.

[0071] Next, traverse and analyze the dependency graph, and use the in-degree statistics method to identify the rules with no dependencies currently. In graph theory, an in-degree of 0 means that a node has no other nodes pointing to it, that is, no other rules form dependencies on it. By traversing the number of incoming edges of all nodes in the graph, all rules with an in-degree of 0 are extracted as inspection rules without dependencies. These rules can be independently executed in the current stage without affecting the logical judgment or input source of other rules.

[0072] Subsequently, a multi-threaded concurrent execution method is used to batch process the above inspection rules without dependencies. An independent thread or task queue is assigned to each rule without dependencies, and the compliance judgment process is started in parallel. Each rule judges the data to be inspected according to its logical conditions, such as field desensitization format verification, whether the permission value is legal, whether the access path is compliant, etc., and generates an execution result in an independent execution environment. Since there is no sequence relationship between the rules without dependencies, they can be safely executed in parallel, significantly shortening the execution time, especially when the number of rules is large or the processing logic is complex.

[0073] After completing the parallel execution, the inspection rule cluster sequence is updated through the status marking update method. All the rules without dependencies that have completed execution are marked with status or removed from the current execution sequence, and the rules that have not been processed and still have dependency relationships are retained as the input objects for the next round of execution. This update ensures that the system always makes the next judgment around the uncompleted rules with satisfied dependencies, forming an efficient inspection rhythm in stages and batches.

[0074] Finally, through this process, the inspection rules without dependencies that are executed in parallel are obtained, and the inspection rule cluster sequence is updated after the execution is completed, forming a rule subset that only contains the rules that have not been executed or still have dependency relationships, laying a foundation for the subsequent orderly execution.

[0075] Furthermore, in the system provided by the application embodiment, the compliance inspection execution module 14 further includes:

[0076] A storage subunit is configured to store data with a passed compliance check status to a first blockchain and store data with a failed compliance check status to a second blockchain.

[0077] In an embodiment of the present application, to achieve the trustworthy classification storage and differential management of compliance check results, a storage subunit is set up to store data to different blockchain structures according to the compliance check status, that is, store data with a passed compliance check status to the first blockchain and store data with a failed status to the second blockchain. This process includes three steps: status identification, chain target matching, and data uploading to the chain, ensuring the accuracy, integrity, and traceability of data deposition.

[0078] Specifically, first, the storage subunit uses a result status classification method to identify the check status output by the compliance check execution module. After the check is completed, a summary judgment is made based on the execution results of each rule. If all rules pass, the data is marked as having a "passed" compliance check status; if there is any key rule that fails, the data is marked as having a "failed" compliance check status. This status identifier will be used as the basis for subsequent data storage path selection to ensure that the on-chain records correspond one-to-one with the check results.

[0079] Subsequently, the storage subunit applies a chain path mapping mechanism to map the data to the corresponding blockchain according to the check status. Among them, the first blockchain is used to record the data that has passed the check, which has characteristics such as public verifiability and fast response, and is suitable for daily business queries and data trustworthy proof; while the second blockchain is used to record the data that has failed the check, which has higher access control permissions and is used for internal risk control, audit accountability, and rectification process tracking. This blockchain hierarchical structure enables permission isolation and audit controllability in the storage strategy for different types of data.

[0080] Finally, the storage subunit uses a blockchain writing method to upload the data to the chain. For data with a "passed" status, fields such as data identifier, check time, rule version, and passed conclusion are encapsulated into transaction information and written to the first blockchain; for data with a "failed" status, information such as violation fields, failed rule numbers, reasons for violations, and original data fragments are encapsulated and written to the second blockchain. All writing processes go through hash digest calculation, digital signature, and timestamp recording to ensure the integrity, anti-tampering property, and traceability of the data on the chain.

[0081] In an embodiment of the present application, in summary, the embodiment of the present application has at least the following technical effects:

[0082] This application establishes a hierarchical mapping database for domain classification samples and compliance check depths; deploys a domain recognition engine to determine the domain type by parsing the data packet information according to the domain recognition engine; based on the hierarchical mapping database, identifies the compliance check depth corresponding to the domain type, and loads the corresponding check rule cluster from the smart contract policy library according to the compliance check depth; performs compliance checks according to the check rule cluster, and records the compliance check status for blockchain storage. The present invention solves the technical problems of low execution efficiency and inability to achieve traceability in the data compliance check process in the prior art. By constructing a hierarchical mapping database, intelligent domain recognition, dynamically loading check rules based on smart contracts, and combining blockchain storage of compliance status, the technical effects of improving the efficiency, accuracy of compliance checks, and the trustworthiness and traceability of the check process are achieved.

[0083] It should be noted that the above sequence of embodiments of this application is only for description and does not represent the superiority or inferiority of the embodiments. And the above description of specific embodiments of this specification has been made. The processes depicted in the drawings do not necessarily require the specific order and continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0084] The above are only the preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of this application shall be included within the protection scope of this application.

[0085] This specification and the drawings are only exemplary descriptions of this application and are considered to have covered any and all modifications, variations, combinations, or equivalents within the scope of this application. Obviously, those skilled in the art can make various changes and modifications to this application without departing from the scope of this application. Thus, if these modifications and variations of this application fall within the scope of this application and its equivalent technologies, this application is intended to include these changes and modifications.

Claims

1. An automated data compliance check and tracking system based on smart contracts, characterized in that, The system includes: A hierarchical mapping establishment module, configured to establish a hierarchical mapping database of domain classification samples and compliance check depths; A domain identification module, configured to deploy a domain identification engine, and determine the domain type according to the parsed data packet information by the domain identification engine; A contract rule loading module, configured to identify the compliance check depth corresponding to the domain type based on the hierarchical mapping database, and load the corresponding check rule cluster from the smart contract policy library according to the compliance check depth; A compliance check execution module, configured to perform a compliance check according to the check rule cluster, and record the compliance check status for blockchain on-chain storage.

2. The automated data compliance check and tracking system based on smart contract according to claim 1, wherein The hierarchical mapping establishment module includes: A compliance process sample collection unit, configured to collect compliance operation process samples corresponding to each domain in the domain classification samples; A compliance field extraction unit, configured to extract compliance field samples of the compliance operation process samples corresponding to each domain; An inspection depth association mapping unit, configured to perform an inspection depth analysis on the compliance field samples, output the compliance check depths corresponding to each domain in the domain classification samples, and output the hierarchical mapping database according to the corresponding relationship between the domain classification samples and the compliance check depths.

3. The automated data compliance check and tracking system based on a smart contract according to claim 2, characterized in that, The inspection depth association mapping unit includes: A depth sample acquisition subunit, configured to acquire M compliance check depths corresponding to each domain, where M is the corresponding sample quantity, and the variance of the sample quantities corresponding to each domain is less than a preset threshold; An inspection depth output subunit, configured to calculate a compliance mean value according to the M compliance check depths, output the mean inspection depth, and output the mean inspection depth as the compliance check depth corresponding to the corresponding domain.

4. The automated data compliance check and tracking system based on smart contract according to claim 2, wherein The inspection depth association mapping unit includes: A field attribute annotation subunit, configured to annotate the field type, field sensitivity level, field format complexity, and compliance association degree of the compliance field samples; A depth feature weight calculation subunit, configured to perform feature quantization according to the field type, field sensitivity level, field format complexity, and compliance association degree, output a depth feature vector, calculate the weight of the depth feature vector, and output the compliance check depths corresponding to each domain.

5. The automated data compliance check and tracking system based on smart contracts according to claim 1, wherein The domain identification module includes: A data packet protocol parsing unit, configured to perform protocol parsing, IP address parsing, and content scanning on the data packet information according to the domain identification engine, where the protocol parsing includes parsing the fields in the HTTP request protocol, the IP address parsing includes parsing the location address, and the content scanning includes identifying content keyword tags; A domain feature identification unit, configured to obtain domain feature fields according to the output result of the data packet protocol parsing unit, and perform identification and classification with the domain feature fields as classification variables to determine the domain type.

6. The automated data compliance check and tracking system based on smart contracts according to claim 1, characterized in that The smart contract policy library includes multiple levels of check rule clusters, the check scopes and complexities of each level of check rule clusters are different, and each level of check rule cluster is stored as an independent smart contract.

7. The automated data compliance check and tracking system based on a smart contract according to claim 1, wherein The compliance check execution module includes: A rule risk level analysis unit, configured to perform a risk level analysis on the check rule cluster to obtain a risk level index; A rule execution sequence sorting unit is used to sort the inspection rule clusters in descending order according to the magnitudes of the risk level indicators, output an inspection rule cluster sequence, and perform compliance inspections according to the inspection rule cluster sequence.

8. The automated data compliance check and tracking system based on smart contracts according to claim 7, wherein The rule execution sequence sorting unit includes: A dependency rule extraction subunit is used to perform dependency analysis on the rule relationships of the inspection rule clusters to obtain dependency inspection rules, where the dependency analysis includes precondition dependency, data dependency, and time dependency; A dependency sequence update subunit is used to update the inspection rule cluster sequence according to the sequential relationship of the dependency inspection rules.

9. The automated data compliance check and tracking system based on smart contracts according to claim 7, characterized in that, The rule execution sequence sorting unit is also used to perform dependency analysis on the rule relationships of the inspection rule clusters to obtain non-dependency inspection rules, and update the inspection rule cluster sequence by executing the non-dependency inspection rules in parallel.

10. The automated data compliance check and tracking system based on a smart contract according to claim 1, wherein, The compliance inspection execution module further includes: A storage subunit is used to store the data with a passed compliance inspection status to the first blockchain and store the data with a failed compliance inspection status to the second blockchain.

Images