Dynamic privacy protection strategy generation and compliance control method combining blockchain and ai
By combining blockchain and AI, a dynamic privacy protection strategy is constructed, which solves the problem that traditional technologies cannot adapt to the coexistence of multiple chains and cross-chain interaction. It realizes real-time risk assessment and fine-grained authorization control, ensures the security and compliance of privacy data, and supports cross-chain collaboration and regulatory intervention.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- PEOPLES DATA MANAGEMENT (ZHONGWEI CITY) CO LTD
- Filing Date
- 2026-03-12
- Publication Date
- 2026-06-12
Smart Images
Figure CN122197067A_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of cross-domain data privacy protection technology, specifically involving a method for generating and managing dynamic privacy protection strategies by combining blockchain and AI. Background Technology
[0002] With the deep integration and widespread application of big data, artificial intelligence, and blockchain technologies, data has become a key production factor. In highly sensitive sectors such as finance, government affairs, and healthcare, the demand for cross-institutional and cross-domain data sharing and collaboration is growing rapidly. However, the core challenge currently facing us is how to achieve dynamic and refined protection of personal and institutional privacy data, and ensure that the entire process complies with increasingly stringent regulatory laws (such as GDPR and the Personal Data Protection Act).
[0003] The existing technical solutions have the following main shortcomings:
[0004] Static and rigid privacy strategies: Traditional access control and data anonymization strategies are mostly statically preset and cannot be dynamically adjusted according to real-time transaction behavior, contextual risks, and constantly evolving compliance requirements. This "one-size-fits-all" approach either leads to insufficient protection, exposing vulnerabilities in the face of new attacks, or to over-protection, hindering normal business collaboration and lacking adaptability and flexibility.
[0005] Data silos and collaborative failures: While current privacy protection solutions based on a single blockchain (such as ring signatures and zero-knowledge proofs) can provide in-chain privacy, they are ill-suited to the reality of multi-chain coexistence. During cross-chain interactions, privacy policies cannot be synchronized, allowing user behavior profiles to still be reconstructed through correlation analysis, resulting in "privacy leaks." Furthermore, regulatory agencies struggle to effectively track and intervene in cross-chain violations.
[0006] The imbalance between security, privacy, and regulation: Existing solutions often struggle to address all three needs. Strong privacy technologies (such as certain anonymous cryptocurrencies) may lead to a lack of oversight, providing shelter for illicit activities; while "backdoors" or logging systems designed to meet regulatory requirements may introduce single points of failure or become new sources of privacy leaks. There is a lack of a transparent checks and balances mechanism that achieves "default privacy and authorized oversight" at the technical level.
[0007] Management blind spots in the policy lifecycle: The generation, deployment, execution, and updating of privacy policies lack end-to-end security control and auditing. Policy smart contracts themselves may contain vulnerabilities, and manual auditing is inefficient. Policy modifications are often delayed, and the modification process is opaque, making it difficult to trace responsibility and establish a reliable policy evolution trajectory.
[0008] Therefore, the industry urgently needs a new privacy protection framework that can deeply integrate the immutability and traceability of blockchain with the real-time perception and intelligent decision-making capabilities of AI. This framework needs to achieve closed-loop management of the entire process, from data tagging, dynamic risk assessment, intelligent policy generation and execution, to cross-chain collaboration, compliance monitoring and autonomous evolution, so as to build a dynamic, accurate, compliant and trustworthy privacy protection barrier in complex multi-party collaborative environments. Summary of the Invention
[0009] This application provides a method for generating dynamic privacy protection strategies and managing compliance by combining blockchain and AI. It aims to solve the problem that traditional access control and data anonymization strategies are mostly static and preset, making it difficult to adapt to the real-world ecosystem of multiple blockchains.
[0010] A method for generating and managing dynamic privacy protection strategies by combining blockchain and AI, the method comprising:
[0011] S1: Label multi-source data with privacy attributes and store them on the blockchain to build a queryable privacy metadata catalog;
[0012] S2: Based on real-time acquired transaction and behavior data, the AI risk perception module is used to conduct risk assessment and generate privacy protection strategies based on the assessment results;
[0013] S3: Encode the generated privacy protection policy into a smart contract, and combine attribute-based encryption to achieve dynamic permission scheduling and policy execution;
[0014] S4: Continuously detect policy compliance through smart contract fuzz testing and AI compliance monitoring, and trigger a policy correction mechanism when deviations are detected;
[0015] S5: Build a cross-chain privacy collaboration network to achieve policy synchronization and regulatory intervention mechanisms;
[0016] S6: Based on federated learning or multi-agent reinforcement learning, continuously optimize the risk assessment and policy generation model;
[0017] S7: Provides users with a privacy preference management interface and stores the entire operation log on the blockchain for evidence, supporting compliance verification based on zero-knowledge proofs.
[0018] Optionally, S1 includes:
[0019] The data is classified and categorized for privacy attributes using a multimodal AI annotation engine.
[0020] The annotation results are associated with data fingerprints and written into an editable blockchain via smart contracts;
[0021] Authorized editing of on-chain privacy metadata is achieved using attribute-based cryptography and a double-trapdoor chameleon hash function.
[0022] Optionally, in step S2, the AI risk perception module processes blockchain transaction flow data in real time, extracts time-series features and contextual intelligence, outputs risk scores and risk type identifiers, and matches or generates corresponding privacy protection strategies based on a predefined strategy matrix.
[0023] Optionally, S3 includes:
[0024] Compile the strategy description file into an on-chain strategy execution smart contract;
[0025] Verify user attribute permissions through attribute-based encryption, and dynamically distribute or revoke data access and operation permissions.
[0026] Record policy execution events and permission change logs to the blockchain.
[0027] Optionally, S4 includes:
[0028] Perform fuzz testing on strategy smart contracts to detect logical vulnerabilities and compliance deviations;
[0029] The AI module compares transaction behavior with a digital regulatory rule base in real time.
[0030] Upon detecting a deviation, a multi-signature authorization process is initiated, and the policy content is updated via an editable blockchain mechanism.
[0031] Optionally, S5 includes:
[0032] A relay chain architecture is used to synchronize privacy policy states across multiple chains.
[0033] Establish threshold signature monitoring nodes and activate the privacy penetration mechanism when preset compliance conditions are met;
[0034] Record the entire process of regulatory intervention to the regulatory evidence storage chain.
[0035] Optionally, S6 includes:
[0036] Each participating node locally collects data on the effectiveness of the strategy execution and performs differential privacy processing.
[0037] The updated model is aggregated through a federated learning framework and deployed after being verified by on-chain consensus.
[0038] Multi-agent reinforcement learning is used to optimize the policy generation logic.
[0039] Optionally, S7 includes:
[0040] Users declare their privacy preferences using verifiable credentials and store the credential hash on the blockchain for evidence.
[0041] All policy generation, execution, modification, and monitoring events are logged to the audit chain;
[0042] It provides a compliance verification interface based on zero-knowledge proofs, enabling users and regulators to verify the compliance of system behavior.
[0043] Optionally, the privacy protection strategy includes at least one of the following technical implementations: ring signature, stealth address, zero-knowledge proof, Pedersen commitment, and group signature.
[0044] Optionally, the blockchain is an editable blockchain that supports authorized data updates while preserving historical traceability through a double trapdoor chameleon hash function.
[0045] Compared with the prior art, this application has at least the following beneficial effects:
[0046] This application constructs an AI risk perception module based on stream computing, which can analyze transaction flows and behavior sequences in real time, upgrading static rule-driven to dynamic risk-driven. Based on the real-time risk assessment level, it can automatically match or generate privacy protection strategies of different strengths, ranging from basic ring signatures to advanced zero-knowledge proofs, achieving precise protection with "risk self-adaptation" and optimizing system performance and user experience while ensuring security.
[0047] This application combines Attribute-Based Cryptography (ABE) with a double-trapdoor chameleon hash function for privacy metadata catalog management on a blockchain. This allows on-chain data to maintain historical traceability and immutability while supporting attribute-based, fine-grained authorized editing. It satisfies the need for dynamic updates to privacy metadata in response to business and compliance requirements, while also ensuring through cryptographic mechanisms that any modifications are clearly defined in terms of responsibility and auditable in the process. This resolves the contradiction between the "immutability" of blockchain data and the "need for compliance correction" in real-world business operations.
[0048] This application employs a dual-track mechanism of "on-chain strategy contract execution + off-chain AI monitoring," embedding "regulatory privacy" technologies such as group signatures and regulatory-friendly zero-knowledge proofs within the strategy. This provides strong privacy protection during daily operation. Once preset, high-confidence compliance conditions (such as judicial orders or systemic risks) are triggered, a regulatory intervention mechanism can be initiated through a decentralized multi-signature authorization process to conduct a legitimate investigation that penetrates the privacy layer. This design achieves a balance between "protected privacy and penetrable regulation" at the technical level, avoiding the conflict between policy and technology. Attached Figure Description
[0049] Figure 1 A flowchart illustrating a method for generating and managing dynamic privacy protection strategies that combines blockchain and AI, provided as an embodiment of this application. Detailed Implementation
[0050] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments.
[0051] The method for generating and managing dynamic privacy protection strategies that combines blockchain and AI, provided in this application, includes the following steps:
[0052] S1: Multi-source data on-chain and privacy labeling: Multi-source data and its privacy attribute metadata are stored on the blockchain to form a queryable privacy metadata catalog.
[0053] Specifically, this solution requires the construction of a privacy metadata catalog system based on an editable blockchain to receive and structurally describe data to be shared from multiple stakeholders (such as government departments, financial institutions, and commercial platforms). The editable blockchain preferably employs a double trapdoor chameleon hash function as its core data structure, allowing authorized entities to make compliant and controlled modifications to the data catalog entries stored on the chain while retaining complete historical traceability capabilities.
[0054] Before data is uploaded to the blockchain, it needs to undergo standardized preprocessing. Data providers submit raw data (which can be structured data tables, unstructured documents, images, or streaming data) to the system access node via a secure channel. The node first performs a full hash calculation on the data with content agnostic capabilities to generate a data fingerprint. Subsequently, the system calls the integrated multimodal AI annotation engine to perform in-depth analysis of the data content. This engine includes multiple parallel dedicated models: for text data, a named entity recognition model and a text classification model based on the Transformer architecture are used to automatically identify and label entities such as "personal ID number," "mobile phone number," "home address," "financial account," and "medical record," and determine their sensitivity level (such as L1 public, L2 internal, L3 secret, and L4 core confidential) according to a predefined rule set (e.g., referring to the Personal Information Protection Law and GDPR classification); for image or video data, a target detection and scene understanding model based on convolutional neural networks is used to identify whether it contains faces, license plates, or specific scenes, and output the corresponding privacy tags.
[0055] After automatic labeling, a structured privacy attribute description record is generated. This record contains at least the following fields: data fingerprint (corresponding to the original data), data source identifier, data topic description, a set of privacy tags generated by the AI engine (each tag includes a sensitivity category and level), and data creation timestamp. Subsequently, the system triggers a smart contract to write this description record, along with its hash value, into the editable blockchain through a consensus mechanism, forming an immutable and conditionally editable directory entry. During this process, the original data itself is not directly uploaded to the blockchain but is stored off-chain in a controlled storage facility (such as a distributed file system or trusted execution environment), and the on-chain directory entry is anchored to it through the data fingerprint.
[0056] To support fine-grained policy control, the system maintains a global "privacy attribute ontology," which exists as a smart contract on an editable blockchain. This ontology defines all legitimate privacy categories, levels, and their semantic relationships. The output of the AI annotation engine must be mapped to the standard terminology of this ontology to ensure the consistency and understandability of data labels across institutions. All privacy attribute annotation information uploaded to the blockchain collectively constitutes a globally queryable and verifiable privacy metadata directory, providing standardized input for subsequent dynamic policy generation.
[0057] The collaborative editing authorization and execution process based on the double trapdoor chameleon hash function and attribute-based encryption (ABE) is as follows:
[0058] During the encrypted encapsulation phase of editing permissions, when the data provider (i.e., the government department GD) needs to publish or subsequently update a data directory entry m and its privacy attribute tag on the blockchain, the double trapdoor chameleon hash function Hash is first invoked to generate the entry's hash value h, random number r, and temporary trapdoor etd. The hash value h and random number r are then stored on the blockchain after consensus, forming the entry's immutable fingerprint. The crucial temporary trapdoor etd is reserved for future authorized editing.
[0059] GD then defined an access control policy based on its internal data management strategy. This policy associates edit permissions with a series of attributes (e.g., "Department: Audit Bureau" AND "Position: Compliance Officer" AND "Security Level: Advanced"). GD uses a multi-agency attribute-based cryptographic algorithm based on identity ID, with the system's global public parameter GP and the public key set of each attribute authority (AA). and the above access policies ( Taking the original temporary trapdoor etd as input, an encryption operation (Encrypt) is performed on it to generate an encrypted temporary trapdoor ciphertext ctd. This ciphertext ctd is publicly stored on the blockchain or in a publicly accessible storage node. At this point, the original temporary trapdoor etd is securely encapsulated within the ciphertext ctd, and any user can only access it if their attribute key satisfies the policy (…). Only when this condition is met can the ability to decrypt the CTD be obtained.
[0060] During the authorized user decryption and edit request phase, when a government employee (GS) with editing needs requires modifying a directory entry, they first prove the validity of their identity to the system. The Directory Management Department (CMD) maintains a set of valid identities based on a cryptographic accumulator. The GS submits their unique identifier to the CMD. and the corresponding accumulator proof CMD runs the ContainVerify verification algorithm, which uses bilinear pairing operations. verify Check if the identity still exists in the valid identity accumulator. If verification fails, the process terminates; if verification succeeds, it indicates that the GS identity is valid and authorized to proceed with subsequent operations.
[0061] After successful authentication, GS attempts to gain editing capabilities. It submits its attribute private key to the system. The private key is issued by its identity ID and the Authorized Authority (AA) to which it belongs, and is associated with the encryption policy (…). The attributes defined in the document correspond to the system's decryption algorithm, Decrypt, which uses the ciphertext ctd, global parameter GP, and user-defined private key. For input. Internal algorithm checks. Does the corresponding set of attributes satisfy the ciphertext policy? If the conditions are met, the algorithm successfully decrypts and outputs the original temporary trapdoor etd; if not, an error flag is output and the process terminates.
[0062] After successfully obtaining etd, GS sends it along with the new data directory content m' to be submitted to the directory management department (CMD) to initiate a formal edit request;
[0063] During the collaborative editing execution phase of the directory management department, CMD, as the holder of the long-term trapdoor tk, does not immediately execute the edit upon receiving the edit request (etd, m') from GS. Instead, it first verifies the legitimacy of the request. This verification includes confirming whether the etd corresponds to a valid on-chain entry (which can be confirmed through the associated hash value h) and verifying the validity of GS's identity (this step has been completed earlier or is verifiable). After confirming legitimacy, CMD uses the long-term trapdoor tk it holds.
[0064] CMD invokes the collision-finding algorithm Adapt for double-trapdoor chameleon hashing. This algorithm takes a long-term trapdoor tk, the original data m, the new data m', the hash value h stored on-chain, a random number r, and a temporary trapdoor etd provided by GS as input. The algorithm performs internal calculations, the core of which is to use the combined effect of tk and etd to calculate a new random number r', ensuring that the hash value generated by the new data m' and r' under the same hash function is completely identical to the original record h. ;
[0065] After calculating r', CMD broadcasts the new data-random number pair (m', r'). Verification nodes in the network perform CHashCheck verification using the public hash key hk to confirm that (m', r') can generate the same hash value as h recorded on the chain. Once verification is successful, consensus is reached, and the directory entry content stored on the chain is officially updated from m pointed to by (h, r) to m' pointed to by (h, r'). Throughout the process, the hash value h, as a data fingerprint, remains unchanged, maintaining the continuity and traceability of the blockchain history, while content changes are implemented under authorization through a double trapdoor mechanism.
[0066] This process achieves fine-grained, decentralized distribution of temporary trapdoor etd through attribute-based encryption, realizes real-time verification of user identity status through an accumulator mechanism, and finally securely completes the authorized editing of on-chain data through the collaboration of long-term trapdoor tk held by CMD and etd provided by the user, thus meeting the dual requirements of security and controllability in dynamic privacy metadata management.
[0067] S2: Dynamic risk assessment and strategy generation. It uses the AI risk perception module to analyze transaction and behavior data in real time, combines the compliance rule library to dynamically assess the privacy risk level, and generates or matches privacy protection strategies based on the assessment results.
[0068] Specifically, step S2 involves real-time monitoring of on-chain transaction metadata, user behavior sequences, and off-chain contextual information. This is combined with multi-source threat intelligence and a compliance knowledge base to form a quantitative assessment of the current operational privacy risks. This allows for the automated generation or matching of optimal privacy enhancement technologies, constructing an AI risk perception module that runs parallel to the blockchain network. The core of this module is a multi-level risk assessment model. This model first obtains real-time input from multiple data sources: 1) Transaction feature stream: Basic features of the transaction data packets intercepted from blockchain nodes are extracted, such as the address activity of the transaction initiator and receiver, transaction amount, gas consumption, and function signatures of the called contracts; 2) Behavioral sequence: By analyzing the transaction records of specific addresses over time, a time series analysis model is used to construct a behavioral baseline and identify abnormal patterns, such as high-frequency small-amount transfers within a short period, interactions with known mixing service addresses, and sudden deviations in transaction amounts from historical norms; 3) Contextual intelligence: External threat intelligence subscription sources and compliance rule bases are accessed. Threat intelligence includes a list of known malicious addresses and characteristics of ongoing attack patterns (such as dust attacks and ransomware address patterns). The compliance rule library encapsulates rules such as the threshold for reporting large transactions and the control list for cross-border data transfer in the form of built-in logic or updatable scripts.
[0069] These multi-dimensional features are fed into a fusion evaluation engine. This engine employs a hybrid classification and regression model based on deep neural networks. The model is pre-trained to perform two main tasks: first, anomaly detection, identifying abnormal transactions that deviate from normal behavioral patterns through unsupervised or semi-supervised learning; second, risk scoring, which uses supervised learning based on historical attack data labeled with risk levels (such as fraudulent transactions and privacy breaches) to output a comprehensive risk score (e.g., a continuous value from 0 to 1, or a discrete level of "low, medium, high, critical"). The model training process can utilize a federated learning framework, allowing multiple participating institutions to collaboratively update model parameters without sharing the original data, thereby improving the model's generalization ability and timeliness.
[0070] Based on the real-time calculated risk score and specific risk type identifier, the policy generation engine is triggered. This engine maintains a "privacy technology policy matrix," which defines the mapping relationship between different risk scenarios and optimal privacy protection technologies, taking into account the balance between performance overhead and regulatory requirements. The policy generation logic is as follows:
[0071] For low-risk scenarios (such as risk scores below a threshold) (And without any abnormal behavior characteristics): Default or match basic privacy protection strategies, such as automatically applying ring signature technology to ordinary transfer transactions to hide the actual sender of the transaction among a set of decoy addresses; or enabling one-time stealth addresses for simple asset transfers to protect the privacy of the recipient's address. Such strategies provide basic privacy protection while minimizing computational and storage overhead;
[0072] For medium- to high-risk scenarios (such as risk scores between θ1 and θ2, or detection of abnormal amounts or suspicious behavioral patterns): stronger privacy protection mechanisms will be enabled. For example, for transactions involving large asset transfers or sensitive contract calls, the use of zero-knowledge proofs (such as ZK-SNARKs) will be mandatory. Specifically, the transaction initiator must generate a concise, non-interactive proof of the transaction's validity (such as sufficient balance and valid signature) and submit this proof, rather than the transaction details, to the blockchain. Verification nodes only need to verify the proof to confirm the transaction's legitimacy, thus completely hiding sensitive information such as transaction amounts and address relationships. Another approach is to use Pedersen commitments, encrypting the transaction amount as a commitment value and submitting it to the blockchain, while attaching a range proof to ensure the amount is non-negative, thus achieving confidentiality of the transaction content.
[0073] For scenarios requiring regulatory oversight or with extremely high risk (such as a risk score exceeding θ2, a transaction triggering anti-money laundering alerts, or originating from a flagged address of regulatory concern): While applying strong privacy technologies (such as zero-knowledge proofs), a regulatory intervention interface is embedded. One implementation method is to use group signature technology. In this mode, transactions are signed by a specific group representing regulatory agencies or compliance departments. Under normal circumstances, transaction verifiers can only confirm that the signature comes from a legitimate group and cannot trace the specific signer, thus protecting the daily privacy of the transaction initiator. However, when predefined compliance conditions are triggered (such as court orders or breaches of risk thresholds), authorized regulatory nodes (as group administrators) can exercise "open" permissions to reveal the identity of the actual signer of the transaction, thereby penetrating the privacy protection layer for compliance investigations and achieving a balance between "protected privacy and penetrable regulation."
[0074] The generated strategy will be output as a structured strategy description file, which will include at least: the applicable transaction identifier, the recommended or mandatory type of privacy technology (such as "ZK-SNARKs-range proof"), technical parameters (such as the size of the ring in a ring signature, the circuit description of a zero-knowledge proof), and any necessary regulatory additional conditions (such as the associated group signature public key). This strategy description file will be passed to the subsequent smart contract strategy execution module as the direct basis for its deployment and operation.
[0075] The AI risk perception module adopts a real-time processing architecture based on a stream computing framework. This architecture uses Apache Flink as the core computing engine, which is responsible for continuously ingesting transaction data streams from the blockchain network and sequentially completing a series of processes such as raw data parsing, time-series feature engineering, AI model inference, and preliminary risk label generation. Finally, it outputs structured events with risk scores to downstream strategy decision-making.
[0076] The architecture consists of a data access layer, a stream processing layer, a model service layer, and an output layer. In the data access layer, a lightweight adapter is deployed to actively listen for transaction pools and new block events on blockchain nodes (such as Ethereum Geth or Hyperledger FabricPeer nodes) using a publish-subscribe pattern. Once the raw transaction data (including transaction hash, sender / receiver address, amount, input data, timestamp, etc.) is captured, it is immediately serialized into Avro format and pushed to a designated topic in a high-throughput distributed message queue (such as Apache Kafka). This design decouples data production and consumption and provides buffering and replay capabilities for subsequent processing.
[0077] The stream processing layer runs a predefined Flink job. The job's Source operator continuously consumes transaction data streams from a Kafka topic. Once the data stream enters the job, it first passes through a parsing and normalization operator. This operator calls a parsing library corresponding to the blockchain type to decode the transaction's input data. Specifically, for smart contract call transactions, it needs to parse the function signatures and parameters of the calls and uniformly convert non-standard data into internally defined standard transaction objects.
[0078] Subsequently, standard transaction objects flow into the key feature extraction operator. This operator performs two types of feature calculations: 1) Immediate features: extracted directly from the current transaction object, such as transaction amount, gas price, whether a specific contract is invoked, etc.; 2) Time-series window features: this is the core of this architecture. A sliding time window state is maintained for each key monitored address (such as the sender address). Flink's KeyedState and Window API are used to efficiently manage these states. For example, for each address, the operator calculates aggregate metrics such as "total transaction frequency," "total amount," and "number of counterparties" over the past hour, and compares them with a dynamic baseline calculated based on historical data (such as the past 30 days) to generate derived features such as "frequency deviation" and "amount mutation rate." For detecting cross-chain behavior, the operator queries an externally maintained "cross-chain bridge contract address mapping table." If the recipient address or invoked contract address of the current transaction exists in this mapping table, it is marked with the "suspected cross-chain transaction" feature.
[0079] The event stream after feature extraction is passed to the model prediction request building operator. This operator assembles all extracted features into a request object conforming to a preset protocol (such as JSON). Asynchronous I / O is used to communicate with the model service layer to avoid blocking the stream processing pipeline. After sending the request, the operator does not wait for a response but instead passes the original event along with an asynchronous result Future object downstream.
[0080] The model service layer is a self-deployed, horizontally scalable cluster of model inference services. This cluster is built on a high-performance service framework (such as TensorFlowServing or NVIDIA TritonInferenceServer) and loads pre-trained real-time risk assessment models (such as gradient boosting trees or lightweight neural network models). This model takes the feature vectors extracted by the aforementioned stream processing layer as input and outputs a comprehensive risk score and risk category label. The model service receives batch prediction requests from the stream processing layer via gRPC or RESTful interfaces, performs parallel inference using GPU acceleration, and returns the results.
[0081] In the stream processing layer, the asynchronous result receiving operator is responsible for collecting the responses from the model service. It associates and merges the returned risk score with the original event to generate an enhanced risk event. This event is ultimately output by the Sink operator to the downstream system, where it can be written to another Kafka topic, a relational database, or a distributed cache (such as Redis) for the policy generation module to consume in real time.
[0082] To ensure low latency and high availability, this architecture implements the following key designs:
[0083] Event timing and out-of-order handling: The blockchain block timestamp is used as the event time, and a reasonable watermark mechanism is configured to handle minor out-of-order transaction data caused by network latency;
[0084] State Backend and Fault Tolerance: RocksDB is used as Flink's state backend. The state and checkpoints are periodically persisted to a distributed file system (such as HDFS) to ensure that the system can quickly recover from the checkpoint after a failure, thus achieving exactly-once state semantics.
[0085] Dynamic model updates: The model service cluster supports hot reloading of new versions of AI models. Stream processing jobs can dynamically update the requested model version endpoints by monitoring changes in the configuration center (such as ZooKeeper), enabling smooth upgrades and A / B testing of risk assessment models;
[0086] S3: Strategy execution and permission scheduling, which encodes the generated privacy policy into a smart contract, implements fine-grained permission control through attribute-based encryption, and dynamically adjusts data access and operation permissions based on user identity, data attributes and risk level;
[0087] Specifically, S2 compiles and deploys the policy description files generated by S2 into on-chain policy execution smart contracts. These contracts, serving as the core carrier and execution engine of the policy rules, work in conjunction with a permission management system based on multi-agency attribute-based encryption to achieve fine-grained, dynamic scheduling and control of data access and operation permissions.
[0088] When the strategy execution smart contract is deployed, its initialization function receives and stores the hash-verified strategy configuration information. The contract's internal logic mainly includes the following key modules:
[0089] Policy parsing and rule matching module: This module has a built-in lightweight rule engine that can interpret and execute policy rules written in a domain-specific language. Policy rules are typically defined in the form of "IF-THEN". The condition part can include references to transaction context variables (such as msg.sender transaction sender address, tx.value transaction amount), verification of risk labels output by the off-chain AI risk assessment module (obtained through an oracle interface), and query results of on-chain privacy metadata attributes associated with the requested operation (such as data sensitivity level). For example, a rule can be defined as: IF(Operation type == "Data query" AND Target data sensitivity level == "L3 secret level" AND Requester risk label != "High risk") THEN(Allow access and apply ring signature privacy policy);
[0090] Attribute-based permission verification and key distribution module: This module is deeply integrated with the attribute-based encryption system established in step one. When the policy rules determine that a specific privacy operation needs to be performed (such as decrypting a certain encrypted data field or authorizing the generation of a proof key for a zero-knowledge proof), this module will trigger an permission verification and key distribution process;
[0091] First, the contract verifies the validity of the attribute claims provided by the transaction initiator (or designated operation agent). This is typically achieved by requiring the requester to provide a zero-knowledge proof or attribute-based signature proving that it holds the attribute private key that matches the policy requirements, without exposing the private key itself or the specific attribute value.
[0092] After successful verification, if the contract needs to distribute a sensitive parameter (such as a symmetric key fragment required to decrypt a temporary trapdoor etd) to the requester, it will invoke the ciphertext encrypted based on the ciphertext policy attribute stored on-chain. This ciphertext is set during the policy generation phase, and its access policy is consistent with the current dynamic permission requirements. The contract itself does not hold the decryption key, but acts as a trusted intermediary, performing on-chain verification and decryption calculations (or secure multi-party computations in a contract environment that supports privacy computation) on the decryption request (its attribute private key) provided by the user that meets the attribute criteria and the ciphertext. Finally, only when the verification is successful and the contract logic conditions are met will the decrypted plaintext sensitive parameter be returned to the authorized user through a secure channel.
[0093] Policy Execution and State Management Engine: This engine is responsible for coordinating the execution of the specific operations specified by the policy rules. These operations may include:
[0094] Dynamic permission switches: Enable or disable access permissions for a specific address to a specific dataset based on risk level or time conditions. For example, when the AI risk awareness module reports abnormal behavior of an address through an oracle, the contract can automatically call a function to remove that address from an access control list;
[0095] Privacy technology parameter scheduling: Based on the policy, specific privacy protection algorithm parameters are selected and configured for upcoming transactions. For example, the contract can store a "policy-parameter" mapping table, and when the rule matches "enable ZK-SNARKs", a predefined verification key address and circuit hash are automatically appended to the transaction;
[0096] Condition Triggering and Time Locks: Contracts support delayed execution based on events or time. For example, for a "automatic freeze on abnormal transactions" rule, the contract can, upon detecting that a condition is met, not immediately freeze assets, but instead initiate a time lock (e.g., 24 hours). During this period, compliance administrators can conduct manual review and veto the freeze operation via multi-signature. The freeze operation automatically takes effect after the time lock expires.
[0097] The entire process of policy rule evaluation, permission verification results, and final execution operations are permanently recorded on the blockchain as contract event logs, forming an immutable audit trail. Auditors can verify whether the permission status and policy execution at any given time conform to the established rules by replaying transactions and querying the event logs.
[0098] S4: Compliance monitoring and strategy correction. It continuously detects vulnerabilities in strategy contracts by using smart contract fuzz testing technology, and compares transaction behavior with regulatory rules in real time through AI-driven comparison. When deviations are found, a strategy correction mechanism is triggered. The privacy policy is dynamically adjusted and the trajectory is recorded through the authorized update function of the editable blockchain.
[0099] Specifically, the operational mechanism for continuously detecting vulnerabilities in strategy contracts includes:
[0100] Test Case Generation and Mutation: The engine takes the Application Binary Interface (ABI) of the strategy contract and the deployed bytecode as input and first generates a basic transaction sequence. It adopts a hybrid generation strategy: 1) Genetic algorithm mutation based on the idea of AFL (American FuzzyLop), performing bit flipping, arithmetic mutation, and combination with known boundary values on fields such as function parameters, msg.sender, tx.value, and block.timestamp of the transaction call; 2) Generation based on the transaction sequence model, simulating multi-step business scenarios (such as authorization before access, and triggering a freeze after multiple risk level changes), generating complex cross-transaction attack vectors;
[0101] Execution and Anomaly Monitoring: The generated test transaction sequences run in a sandboxed EVM (Ethereum Virtual Machine) or a compatible execution environment. The engine monitors each execution through instrumentation, tracking key metrics: a) code coverage, particularly conditional branches and state variables; b) runtime anomalies, such as gas depletion anomalies, assertion failures, and unauthorized state changes; c) deviations from the expected policy logic, such as low-risk users being wrongly denied access, or high-risk transactions not being properly blocked.
[0102] Vulnerability Diagnosis and Reporting: When a test case triggers an exception or logical deviation, the engine records the complete transaction sequence, final state, and discrepancies. It combines symbolic execution technology to simplify the path conditions that trigger the vulnerability, generating a reproducible vulnerability exploitation report. This report is submitted to the policy management backend, tagging the associated policy contract version and rule fragment.
[0103] Specifically, the AI-driven real-time comparison of transaction behavior with regulatory rules occurs on the mainnet, where the AI compliance monitoring module runs continuously as an off-chain service. It uses the data flow interface of blockchain nodes to capture in real-time the "actual transaction behavior logs" after the execution of the strategy in step three, as well as on-chain state changes.
[0104] Regulatory rule digitization and feature extraction: This module maintains a machine-readable regulatory rule knowledge base. Rules are modeled through ontology, transforming natural language regulations (e.g., "Daily cumulative cross-border transfers exceeding the equivalent of US$50,000 must be reported") into structured logical expressions and computable features. For example, the above rule is transformed into summing the transaction amounts of a specific set of addresses (identified as "cross-border") within a rolling 24-hour window and comparing them to a threshold;
[0105] Real-time comparison and deviation detection: The monitoring module compares the actual transaction flow with a digital rule base in real time. It calculates the "compliance index" for each transaction or address under the relevant rules. When a potential deviation is detected (such as a transaction pattern that happens to circumvent the threshold rules of an existing policy but substantially violates regulatory intent), the module generates a compliance deviation alert. This alert includes a description of the deviation, the transaction involved, the associated current policy ID, and suggested corrective actions (such as adjusting the threshold or adding additional conditions).
[0106] Furthermore, the triggering, approval, and execution of the strategy correction mechanism are as follows:
[0107] Based on the severity, urgency (e.g., whether the vulnerability has been publicly exploited) and scope of impact, the remediation recommendations are prioritized.
[0108] Remediation Solution Generation: For vulnerabilities, remediation solutions may be manually specified after review by security experts, or automatically suggested (e.g., adding require statements for missing checks). For compliance deviations, the AI module can automatically generate parameter adjustment suggestions or logic patches for policy rules based on historical amendment examples and rule semantics.
[0109] Authorization and Approval Process: Any modification to an existing mainnet policy contract must undergo a decentralized authorization and approval process. This system utilizes a multi-signature scheme based on threshold signatures or a DAO governance mechanism. The modification proposal, the associated audit report (details of vulnerabilities or compliance deviations), and the hash of the revised policy code are submitted to an approval committee (composed of compliance officers, security experts, etc.). Committee members sign the proposal using their private keys. When more than a preset threshold of valid signatures (e.g., 3 / 5) is collected, the proposal is authorized.
[0110] Security Update Execution: Upon authorization, the editable blockchain data catalog update mechanism described in S1 is invoked. Specifically, the correction operation is considered an authorized update to the special data catalog entry for the "strategy smart contract" on the chain (whose content is contract bytecode or key rule parameters);
[0111] Based on the correction type, generate the corresponding update content m' (such as new contract code, updated rule parameters);
[0112] Authorized users with the "Policy Administrator" attribute obtain the temporary trapdoor etd for this update through the attribute-based cryptographic authorization mechanism;
[0113] The authorized user collaborates with the directory management service (CMD) that holds the long-term trapdoor tk to execute the Adapt algorithm for double trapdoor chameleon hashing. This algorithm calculates a new random number r' such that the hash value generated by the updated policy content m' and r' is completely consistent with the hash value h recorded in the original policy entry on the chain.
[0114] The updated transaction (m', r') is uploaded to the blockchain after consensus is reached, completing the smooth replacement of the strategy. The hash value h remains unchanged, ensuring the continuity of the strategy version history, and any node can verify the currently effective strategy content through CHashCheck;
[0115] Furthermore, the audit trail is immutable. Key events throughout the monitoring and remediation process, including vulnerability reports, compliance alerts, remediation proposals, multi-signature authorization records, and the final triggered on-chain editing transactions (including the old value m, the new value m', the editor's identity, and the timestamp), are all anchored by their hash values to an immutable blockchain (separable from the main business chain) serving as the audit layer. This forms a complete, reliable, and verifiable "strategy evolution audit trail."
[0116] S5: Cross-chain collaboration and regulatory intervention, building a cross-chain privacy collaboration network to achieve privacy policy synchronization, setting up a weakly centralized regulatory node, and allowing regulatory agencies to authorize intervention in investigations through threshold signature schemes when compliance conditions are met;
[0117] Specifically, in order to achieve privacy policy coordination among heterogeneous blockchain systems and meet legal regulatory requirements under necessary conditions, it is necessary to build a cross-chain privacy collaboration network based on relay chain and state channel technology, and establish a legally constrained weakly centralized regulatory node in this network.
[0118] The construction process of the cross-chain privacy collaboration network is as follows:
[0119] The network adopts a "Hub-and-Spoke" relay chain architecture. A specially constructed privacy policy coordination chain that supports high-concurrency verification serves as the relay chain (Hub), while the participating business blockchains (such as public chains and consortium chains) serve as sidechains (Spoke) connected to the relay chain through light client bridging or state verification contracts.
[0120] Strategy State Synchronization Mechanism: When the strategy execution smart contract in Step 3 undergoes a state change on the main business chain (such as an increase in the risk level of an address or an update to a data access policy), the contract triggers a cross-chain message. This message contains a concise proof of the state change (such as a Merkle proof) and a new policy summary, and is sent to the cross-chain message router contract on the relay chain. After verifying the validity of the proof, the router contract broadcasts the state change event to all registered sidechains that need to monitor such events. The strategy synchronization contract on the receiving sidechain, after verifying the signature message sent by the relay chain, reproduces or maps the corresponding strategy state on its own chain, ensuring that the privacy policy context of the user's cross-chain behavior is synchronized. For high-frequency micropayments or state updates, state channels can be established between the relay chain and sidechains, or between two sidechains, to conduct a large number of strategy synchronization transactions off-chain, submitting only the final state settlement result on-chain.
[0121] Cross-chain privacy transaction execution: When a user needs to execute a privacy transaction involving assets across multiple chains (such as a privacy transfer from chain A to chain B), the transaction initiated on the current chain will be accompanied by a unified privacy policy identifier generated in step two. After the transaction is confirmed on the current chain, its intent and policy requirements are relayed to the target chain via a relay link. Upon receiving the request, the asset custody contract on the target chain first queries the user's latest policy status synchronized through the above mechanism. Then, only under conditions that comply with the policy (such as the user's current risk level allowing cross-chain operations), it will cooperate in executing the corresponding privacy operations (such as generating a stealth address for the recipient on the target chain). Throughout the process, the user's specific transaction details on each chain are still protected by local privacy technologies (such as ring signatures and zero-knowledge proofs), but the policy execution logic achieves cross-chain consistency.
[0122] The design, key management, and intervention process of the weakly centralized supervisory node are as follows:
[0123] Generation and Custody of Regulatory Keys: A threshold signature scheme is used to generate regulatory master key pairs. This scheme divides the regulatory private key into n shares, which are held separately by t (t<=n) different, geographically and organizationally isolated regulatory nodes. No single node or fewer than t nodes can recover the complete regulatory private key. The corresponding regulatory public key is publicly registered on the relay chain. Furthermore, different compliance subkeys can be derived for different types of intervention operations (such as transaction tracing and temporary freezing), and their usage rights can be further constrained through smart contracts (such as specific case numbers and validity periods).
[0124] Triggering and Authorization of Regulatory Intervention: Regulatory intervention cannot be initiated arbitrarily; it must be activated by pre-set compliance triggers. These triggers are encoded in the regulatory intervention smart contract and include: 1) receiving a legally valid judicial assistance document (whose digital digest is verified on-chain via an oracle); 2) the system's own AI risk monitoring module (step four) detects a highly certain pattern of illegal or criminal activity and generates a risk report with a strong chain of evidence, which is then approved by a compliance review committee composed of multiple parties (such as industry associations and lawyers).
[0125] Privacy Penetration and Investigation Execution: Regulatory nodes can only coordinate action after intervention conditions are met and authorization is obtained through t-of-n threshold signatures. For example, tracing the origin of a transaction that uses a stealth address or zero-knowledge proof:
[0126] The regulatory node uses its threshold signature share to collaboratively generate a valid regulatory query instruction, which includes the target transaction hash and authorization proof;
[0127] The instruction is submitted to the regulatory assistance contract deployed on the target business chain. After the threshold signature is verified, this contract calls a special regulatory interface function on the chain;
[0128] This function leverages "backdoors" or regulatory-friendly designs in the underlying privacy technology. For example, if the transaction uses group signatures, the regulatory assistance contract can use the permissions corresponding to the regulatory public key to "open" the signature, revealing the identity of the actual signer. If the transaction uses an auditable privacy algorithm specifically designed for regulation, the contract can output the decrypted plaintext transaction or related information after inputting the regulatory key, which ordinary nodes cannot do.
[0129] The query results (such as the original address and transaction amount) will not be publicly exposed. Instead, they will be re-encrypted and returned only to the receiving address designated by the requesting regulatory agency, and the hash of the query operation will be recorded as evidence.
[0130] All regulatory interventions, from condition triggering, authorization voting, instruction generation to query execution, are mandated to have their key steps and output results (hash values) recorded on a regulatory evidence storage chain. This chain can be an independent partition of a relay chain or a specially constructed permissioned chain. The evidence storage record must include: an intervention case identifier, a summary of the triggering legal or rule clauses, a set of node signatures for authorization voting, a hash of the executed instruction content, the commitment value of the result data, and a timestamp. This forms a complete, non-repudiable, and retrospective (under higher-level authorization) record of regulatory activities, ensuring that regulatory power is not abused.
[0131] S6: Continuous learning and evolution, collecting data on policy execution effects, optimizing the AI model through federated learning or multi-agent reinforcement learning, and deploying the updated model parameters to the blockchain network after consensus verification;
[0132] To achieve the self-optimization and dynamic adaptation capabilities of the privacy protection system, a continuous learning and policy evolution framework based on federated learning and on-chain consensus was also constructed. This framework optimizes the AI risk assessment and policy generation model through distributed collaborative training without aggregating raw sensitive data, and verifies and deploys the updated model through a decentralized mechanism, forming an autonomous, secure and reliable privacy protection intelligent ecosystem.
[0133] The continuous learning and policy evolution framework specifically includes:
[0134] Distributed data collection and effectiveness measurement: Each participating node (such as blockchain nodes of government departments or financial institutions) deploys a local data collection and effectiveness measurement agent. This agent continuously monitors the actual effects of the strategies executed in step three within its local scope and generates encrypted local effectiveness reports. The collected data dimensions include:
[0135] Security performance metrics: Record the number and type of suspected attack transactions that were successfully intercepted, and the number of attack events that were missed (confirmed through post-event analysis or threat intelligence).
[0136] Business impact metrics: Statistics on the number of false alarms (legitimate transactions being rejected or delayed) caused by the strategy and the level of their business impact; records of average transaction latency and additional computing resource consumption caused by strategy execution;
[0137] Contextual features: Record a snapshot of real-time risk features associated with each strategy decision (such as transaction features, user behavior baseline values), but strip away any information that can directly identify individuals or entities;
[0138] These data are standardized and aggregated locally to form periodic local effect statistical vectors, and calibrated differential privacy noise is added to sensitive statistical values (such as the number of interceptions for specific attack types) to further prevent the original data from being inferred from statistical information.
[0139] Model collaborative optimization based on federated learning adopts a horizontal federated learning architecture for periodic training and updating of the model.
[0140] Local training: The central coordinator (which can be a supervisory node or a rotating trusted node) initiates a new round of training tasks, broadcasting the parameters of the current global risk assessment model or policy generation model. This is then distributed to each participating node. Each node uses its recently collected feature data with effect labels (effect labels such as "Was this interception necessary?" or "Was this strategy selection optimal?") as its training set locally. Using the initial weights, perform several rounds of local training (e.g., using stochastic gradient descent) to calculate the local model parameter updates. ;
[0141] Secure parameter aggregation: Nodes do not upload the original gradients or parameters, but instead update the encrypted local parameters. The update, along with proof of the data volume it is based on, is uploaded to a secure multi-party computation platform or a model aggregation server employing homomorphic encryption. This server, in encrypted form, performs a weighted average of the updates from each node (weights are typically based on the data volume or quality of each node) to calculate the aggregated global model update. Subsequently, the server... Decryption (or computation in a secure environment) yields a global update of the plaintext;
[0142] Global model update: The central coordinator will aggregate the global update. Apply the global model parameters from the previous round to generate new candidate global model parameters. ;
[0143] Consensus verification and on-chain deployment of model updates: To ensure the security and credibility of model updates, the deployment of new models must undergo a rigorous on-chain verification process.
[0144] Candidate Model Evaluation and Hash Release: The Central Coordinator Will A comprehensive evaluation was conducted in a separate model testing sandbox isolated from the mainnet environment. The evaluation included: comparisons of performance metrics (such as AUC-ROC, precision, and recall) on standard test sets, changes in computational overhead, and backtesting performance on historical attack data. After evaluation, the coordinator calculated the hash value H( of the candidate model parameters). The model's version description information (including a performance report summary) is submitted as a proposal to the model management smart contract.
[0145] Multi-role consensus verification: The model management contract triggers a multi-signature verification process. A pre-defined set of validators (potentially including representatives from the technical committee, security auditors, and nodes from key participants) will review the proposal. The review includes not only the on-chain performance summary, but some validators can also request to reproduce the evaluation results in a local verification sandbox. Validators vote on whether to approve the model version using their private keys. The proposal is considered approved only when the number of valid signatures collected exceeds a pre-defined threshold (e.g., 5 / 7).
[0146] Secure deployment of model parameters: After the proposal is approved, the model management contract will record the new model version number and its hash value H( And performance commitments. Then, complete model parameters. The model is split into multiple fragments and distributed to a designated set of storage nodes in the network using a threshold secret sharing technique. When any node or user needs the latest model, they can collect a sufficient number of fragments from these storage nodes, reconstruct the complete model parameters locally, and then calculate the hash value and compare it with the H recorded on the chain. The integrity of the model is verified by comparison, which avoids putting the huge model data directly on the chain, while ensuring the trustworthiness and tamper resistance of the model distribution.
[0147] The co-evolution of the strategy generation logic can be achieved using a multi-agent reinforcement learning approach. Each participating node can be considered an agent, operating within its local transaction flow and risk scenario. Its actions involve selecting or generating privacy-preserving strategies, and its reward signal integrates security performance metrics and business impact metrics (after normalization and weighting). Each agent periodically updates its learned strategy value function or strategy network parameters, synchronizing them securely to a global strategy model. The update of this global strategy model also follows the aforementioned "consensus verification and on-chain deployment" process, ensuring that the collective wisdom evolution of strategy generation capabilities occurs within a secure and controllable framework.
[0148] Privacy protection strategies and risk assessment capabilities can be continuously and autonomously optimized in the ever-changing threat environment and business needs. At the same time, the entire evolution process is constrained and audited by blockchain consensus and encryption technology, ensuring its transparency, security and credibility.
[0149] S7: Autonomous control and transparent auditing, providing users with an autonomous identity management interface to define privacy preferences, recording all policy generation, execution and modification on the blockchain for evidence storage, and supporting verification of operational compliance through zero-knowledge proofs;
[0150] Specifically, transparent auditing aims to enable users to proactively manage their own privacy rights and establish a transparent auditing system that can be verified by multiple parties. At the same time, autonomous control empowers users to control their privacy preferences, records all key decisions and operations in an immutable manner, and allows compliance verification without exposing sensitive information through zero-knowledge proof technology.
[0151] Specifically, it includes:
[0152] Based on verifiable credentials, autonomous identity and privacy preference management provides an autonomous identity management client that manages the user's primary identity identifier and a series of verifiable credentials.
[0153] Privacy Preference Statement: Users define their privacy preference rule set through the client. These rules are expressed in a structured policy language, such as: "My transaction history can be used to train anti-fraud models, but must not be associated with my real identity"; or "My health data can only be used for medical research in an anonymized and aggregated state." These rules are encoded into a digital policy file and signed by the user using their identity key to generate a user-signed privacy preference credential.
[0154] Preference credential submission and anchoring: The user submits this signed credential to the system. The system does not store the original preference content, but instead stores the hash value of the credential. It is associated with the user's decentralized identifier (DID) and recorded on a dedicated auditable blockchain (audit chain) for evidence storage. The original credential is kept by the user or stored encrypted in a location designated by the user. When any data processing operation involves the user, the operator must obtain and verify this credential to prove that its operation has been authorized in accordance with the user's statement.
[0155] The immutable and verifiable storage of end-to-end operation logs is mandatory. All critical events and decision points generated from S2 to S6 must generate structured logs and be submitted to the audit chain. These events include, but are not limited to:
[0156] Policy generation event: The risk assessment results output by the AI module and the generated privacy policy description and its hash;
[0157] Policy execution events: permission check results for smart contract execution, application privacy technologies (such as ring signature parameters, verification key ID for zero-knowledge proofs);
[0158] Policy remediation events: Hash of vulnerability reports or compliance alerts that trigger remediation, content of remediation proposals, and multi-signature authorization records;
[0159] Regulatory intervention events: a summary (hash) of the legal basis for the intervention request, a set of authorized signatures, and a hash of the query instruction;
[0160] Data access and usage events: Access requests for user data, the purpose of access, and the identifier of the algorithm model used;
[0161] Each event log contains a timestamp, the relevant transaction hash, the executor or smart contract address, and the commitment value (hash) of the event data. They are organized chronologically and according to business relevance, forming a traceable audit trail with the user DID, data asset ID, or policy ID as the primary key;
[0162] To allow users and regulators to verify the compliance of actions without disclosing sensitive operational details, this solution defines a set of verification protocols based on zero-knowledge proofs.
[0163] Formalizing Verification Statements: Compliance requirements are formalized into statements that need to be verified. For example, a user might want to verify the statement, "All access to my Level 3 sensitive data by the system in the past month has undergone effective risk assessment," without knowing when, by whom, or for what reason. Similarly, a regulator might want to verify, "In the investigation of Case X, all decryption operations on transaction data were authorized with legally required signatures," without disclosing the identities of all signatories.
[0164] Construction of Zero-Knowledge Proof Circuits: For each type of claim, a corresponding zero-knowledge proof circuit is designed. This circuit takes private and public inputs as parameters. Private inputs are detailed, confidential audit log data (such as specific access times, visitor IDs, and transaction amounts); public inputs are public, verifiable claim descriptions (such as "all accesses have undergone risk assessment"), and Merkle roots of relevant event logs anchored to the audit chain.
[0165] The core of the circuit logic is: 1) Prove that the data format of the private input is valid and that its hash value is contained in the set represented by the Merkle root, which is the public input (i.e., the data is actually on the chain); 2) Prove that these private data satisfy all the constraints required by the declaration (such as the risk assessment result field of each access record being "passed").
[0166] Proof generation and verification: A trusted or multi-party collaborative proof generation service, with access to the complete audit log (private input), generates a concise zero-knowledge proof based on the circuit described above. Users or regulators (validators) only need to know the public inputs (claims, Merkle root) and proofs. By running the corresponding verification algorithm, the authenticity of the claim can be confirmed without obtaining any private log details. For example, a user receives a certificate... After the verification was successful, he was convinced that the system had processed his sensitive data in compliance with regulations, but he knew nothing about the details of the processing.
[0167] The user-controllable audit query and complaint mechanism, with the self-management client providing users with an audit query interface, allows users to submit a verification request and specify a compliance statement (such as "My data has not been accessed by any unauthorized party in the past 24 hours"). The system's backend proof generation service generates and returns proof accordingly. If verification fails, or if the user discovers something suspicious through other means, the client supports the user in generating a privacy complaint report. This report includes clues to the suspicious event, relevant preference credentials stored locally by the user, and proof of the failed verification. This report can be encrypted and submitted to the regulatory evidence storage chain or a designated complaint handling smart contract to trigger further investigation.
[0168] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above 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.
Claims
1. A method for generating and managing dynamic privacy protection strategies by combining blockchain and AI, characterized in that: The method includes: S1: Label multi-source data with privacy attributes and store them on the blockchain to build a queryable privacy metadata catalog; S2: Based on real-time acquired transaction and behavior data, the AI risk perception module is used to conduct risk assessment and generate privacy protection strategies based on the assessment results; S3: Encode the generated privacy protection policy into a smart contract, and combine attribute-based encryption to achieve dynamic permission scheduling and policy execution; S4: Continuously detect policy compliance through smart contract fuzz testing and AI compliance monitoring, and trigger a policy correction mechanism when deviations are detected; S5: Build a cross-chain privacy collaboration network to achieve policy synchronization and regulatory intervention mechanisms; S6: Based on federated learning or multi-agent reinforcement learning, continuously optimize the risk assessment and policy generation model; S7: Provides users with a privacy preference management interface and stores the entire operation log on the blockchain for evidence, supporting compliance verification based on zero-knowledge proofs.
2. The method for generating and managing dynamic privacy protection strategies combining blockchain and AI according to claim 1, characterized in that, S1 includes: The data is classified and categorized for privacy attributes using a multimodal AI annotation engine. The annotation results are associated with data fingerprints and written into an editable blockchain via smart contracts; Authorized editing of on-chain privacy metadata is achieved using attribute-based cryptography and a double-trapdoor chameleon hash function.
3. The method for generating and managing dynamic privacy protection strategies combining blockchain and AI according to claim 1, characterized in that, In step S2, the AI risk perception module processes blockchain transaction flow data in real time, extracts temporal features and contextual intelligence, outputs risk scores and risk type identifiers, and matches or generates corresponding privacy protection strategies based on a predefined strategy matrix.
4. The method for generating and managing dynamic privacy protection strategies combining blockchain and AI according to claim 1, characterized in that, S3 includes: Compile the strategy description file into an on-chain strategy execution smart contract; Verify user attribute permissions through attribute-based encryption, and dynamically distribute or revoke data access and operation permissions. Record policy execution events and permission change logs to the blockchain.
5. The method for generating and managing dynamic privacy protection strategies combining blockchain and AI according to claim 1, characterized in that, S4 includes: Perform fuzz testing on strategy smart contracts to detect logical vulnerabilities and compliance deviations; The AI module compares transaction behavior with a digital regulatory rule base in real time. Upon detecting a deviation, a multi-signature authorization process is initiated, and the policy content is updated via an editable blockchain mechanism.
6. The method for generating and managing dynamic privacy protection strategies combining blockchain and AI according to claim 1, characterized in that, S5 includes: A relay chain architecture is used to synchronize privacy policy states across multiple chains. Establish threshold signature monitoring nodes and activate the privacy penetration mechanism when preset compliance conditions are met; Record the entire process of regulatory intervention to the regulatory evidence storage chain.
7. The method for generating and managing dynamic privacy protection strategies combining blockchain and AI according to claim 1, characterized in that, S6 includes: Each participating node locally collects data on the effectiveness of the strategy execution and performs differential privacy processing. The updated model is aggregated through a federated learning framework and deployed after being verified by on-chain consensus. Multi-agent reinforcement learning is used to optimize the policy generation logic.
8. The method for generating and managing dynamic privacy protection strategies combining blockchain and AI according to claim 1, characterized in that, The S7 includes: Users declare their privacy preferences using verifiable credentials and store the credential hash on the blockchain for evidence. All policy generation, execution, modification, and monitoring events are logged to the audit chain; It provides a compliance verification interface based on zero-knowledge proofs, enabling users and regulators to verify the compliance of system behavior.
9. The method for generating and managing dynamic privacy protection strategies combining blockchain and AI according to any one of claims 1-8, characterized in that, The privacy protection strategy includes at least one of the following technical implementation methods: ring signature, stealth address, zero-knowledge proof, Pedersen commitment, and group signature.
10. The method for generating and managing dynamic privacy protection strategies combining blockchain and AI according to any one of claims 1-8, characterized in that, The blockchain is an editable blockchain that supports authorized data updates while preserving historical traceability through a double trapdoor chameleon hash function.