Method for cross-domain training and privacy protection of ai model combining blockchain and homomorphic encryption

Abstract

This application discloses a method for cross-domain training and privacy protection of AI models that integrates blockchain and homomorphic encryption. The method includes: S1, system initialization: constructing a permissioned consortium blockchain network; S2, each participating node trains its model locally using its private data; S3, the consortium blockchain performs consensus verification on the hash of the uploaded ciphertext parameters through a smart contract, and dynamically groups the verified participating nodes; S4, the aggregation node obtains the corresponding ciphertext parameters based on the grouping information and generates global encrypted model parameters; S5, each participating node obtains the global encrypted model parameters from the consortium blockchain. This application replaces centralized servers by constructing a permissioned consortium blockchain network, utilizing its distributed ledger, smart contracts, and consensus mechanism to eliminate single points of failure and trust bottlenecks.

Description

Technical Field

[0001] This application belongs to the field of artificial intelligence and information security technology, specifically involving a method for cross-domain training and privacy protection of AI models that integrates blockchain and homomorphic encryption. Background Technology

[0002] With the rapid development of artificial intelligence technology, especially in fields such as healthcare, finance, and the Internet of Things, collaborative training using multi-source data has become a key path to improve model performance. However, in practical applications, cross-institutional and cross-domain collaborative training faces multiple severe challenges, creating a contradiction between "data silos" and "privacy protection."

[0003] First, data privacy and security regulations (such as GDPR and HIPAA) strictly limit the direct sharing and transfer of raw data. Due to concerns about trade secrets and user privacy, participating parties cannot centralize their local data to a central server. While traditional federated learning frameworks allow data to remain on-premises, they still rely on a centralized coordination server to aggregate model updates. This central server becomes a single point of failure and a bottleneck of trust; if attacked or maliciously manipulated, it could cause the entire training process to collapse, model leaks, or be subjected to malicious parameter poisoning attacks.

[0004] Secondly, existing privacy protection technologies have limitations. While homomorphic encryption can support computation on ciphertext, traditional schemes have enormous computational overhead, making them difficult to apply directly to training deep neural networks with large parameter scales. Furthermore, key management is complex, lacking effective distributed key generation, backup, and rotation mechanisms. Differential privacy techniques add noise to the model to protect privacy, but this often comes at the cost of model accuracy, and it is difficult to precisely balance privacy budgets and model utility in complex cross-domain training.

[0005] Furthermore, there is a lack of transparent and credible incentive mechanisms and audit traceability capabilities. Existing solutions struggle to objectively and automatically quantify the contributions of each participant and thus provide fair incentives. The training process is opaque, allowing participants to submit low-quality data or malicious parameters undetected. Moreover, in the event of model performance anomalies or security incidents, it is difficult to quickly and accurately identify and address the responsible party.

[0006] Therefore, there is an urgent need for a method that can deeply integrate privacy computing and distributed trust mechanisms to achieve efficient, reliable, incentivized, auditable, and dynamic node management-supported cross-domain training of AI models while ensuring data privacy and security. Summary of the Invention

[0007] This application provides a method for cross-domain training and privacy protection of AI models that integrates blockchain and homomorphic encryption. It aims to address the problems of strict data privacy and security regulations in existing technologies, limitations of existing privacy protection technologies, and the lack of transparent and trustworthy incentive mechanisms and audit traceability capabilities.

[0008] A method for cross-domain training and privacy protection of AI models that integrates blockchain and homomorphic encryption, the method comprising:

[0009] S1. System Initialization: Construct a permissioned consortium blockchain network containing multiple participating nodes; configure homomorphic encryption key pairs for each participating node, including a public key and a private key; and deploy smart contracts on the consortium blockchain to define training rules, perform verification, and provide incentives.

[0010] S2, Local Encrypted Training and On-Chain Notification: Each participating node trains the model locally based on its private data to obtain local model parameters; each node uses its own homomorphic encryption public key configured in S1 to encrypt the local model parameters to generate ciphertext model parameters; the hash value of the ciphertext model parameters is used as a submission credential and uploaded to the consortium chain built by S1 for notification by the on-chain smart contract.

[0011] S3. On-chain verification and dynamic task orchestration: The consortium blockchain uses the smart contract to perform consensus verification on the submission credentials of each node uploaded in S2; for nodes that pass verification, they are dynamically grouped according to a preset strategy to form at least one aggregated task unit, and the grouping information is recorded on the chain.

[0012] S4. Secure Ciphertext Aggregation: The selected aggregation node obtains the ciphertext model parameters of the corresponding node based on the on-chain grouping information generated in S3; based on the additive homomorphism of homomorphic encryption, the ciphertext model parameters are weighted and averaged in the ciphertext state to generate global encryption model parameters; the hash value of the global encryption model parameters is uploaded to the consortium blockchain for evidence storage.

[0013] S5. Model Update and On-Chain Incentives: Each participating node obtains the global encrypted model parameters generated in S4 from the consortium blockchain, decrypts them using its own homomorphic encryption private key configured in S1, and updates its local model accordingly; each node evaluates the performance of the updated model locally and submits the digitally signed evaluation results to the consortium blockchain; the smart contract automatically calculates and distributes incentives based on the evaluation results submitted by each node.

[0014] S6. Full-process auditing and anomaly handling: All key operation records and state changes generated in S2 to S5 are recorded in the consortium blockchain in a full and tamper-proof manner to form an audit log; by analyzing the audit log, abnormal behavior is detected, traced back to the specific participating node, and the smart contract is triggered to execute the preset penalty rules;

[0015] S7. Node Dynamic Management: Participating nodes apply to exit through on-chain transactions, and the smart contract freezes their permissions and completes incentive liquidation; new nodes join the consortium blockchain network after completing on-chain identity authentication and staking, and synchronize the current training status and model parameters from the chain to participate in subsequent training.

[0016] Optionally, configuring a homomorphic encryption key pair for each participating node in S1 specifically includes: generating a global homomorphic encryption public key using an identity-based encryption architecture or a distributed key generation protocol;

[0017] Each participating node uses its unique digital identity on the consortium blockchain as its encrypted identifier;

[0018] When a participating node needs to decrypt data, it requests a private key fragment from a key generation committee composed of multiple authoritative nodes and combines them to generate its complete personal homomorphic decryption private key.

[0019] Optionally, S1 further includes deploying a training protocol smart contract on the consortium blockchain, wherein the training protocol smart contract programs and stores the model structure, training hyperparameters, aggregation algorithm and incentive rules.

[0020] Optionally, the local training of the model in S2 specifically includes: each participating node performing model training in a local sandbox computing environment that is isolated from the network, memory, and processes, strictly following the training hyperparameter constraints synchronized from the consortium blockchain.

[0021] Optionally, the consensus verification in S3 specifically includes checking at least one of the following through a smart contract: whether the training hyperparameters declared in the metadata submitted by the participating nodes conform to the agreement of the on-chain training protocol;

[0022] Is the submission time within the specified parameter submission time window?

[0023] Is this the first submission from the participating node in the current training round?

[0024] Optionally, the dynamic grouping in S3 is executed according to a pre-set grouping strategy function on the chain, and the grouping strategy is based on at least one of the following dimensions: the data domain label of the participating node, historical contribution, or network topology location.

[0025] Optionally, the aggregation node in S4 is an aggregation committee member dynamically elected by an on-chain smart contract in each training round.

[0026] Optionally, the step of uploading the signed evaluation result to the blockchain after evaluating the model performance locally in S5 specifically includes: each participating node conducting the evaluation locally according to a predefined unified evaluation protocol on the blockchain;

[0027] Generate and submit verifiable evaluation proofs, which are implemented based on remote proofs or zero-knowledge proofs generated in a trusted execution environment.

[0028] Optionally, the automatic execution of incentive distribution based on the evaluation results in S5 specifically includes: the smart contract calculating the contribution score of each participating node based on the evaluation results submitted by each participating node, historical contribution records, and compliance verification results;

[0029] Reward tokens are automatically allocated from the incentive pool based on the relative contribution ratio of each participating node.

[0030] Optionally, the addition of a new node in S7 specifically includes: after a new node completes on-chain registration and staking, it needs to go through a probationary period; during the probationary period, its model update weight is restricted and it is not selected as an aggregation node; after the probationary period ends, if its behavior meets the requirements, the smart contract will automatically upgrade it to a formal node with full permissions.

[0031] Compared with the prior art, this application has at least the following beneficial effects:

[0032] This application replaces centralized servers by constructing a permissioned consortium blockchain network. Utilizing its distributed ledger, smart contracts, and consensus mechanisms, it eliminates single points of failure and trust bottlenecks. All training rules, contribution records, and state changes are automatically executed and stored through on-chain smart contracts, ensuring the training process is open, transparent, immutable, and verifiable, thus establishing a trustworthy collaborative foundation with multi-party participation.

[0033] This application integrates a homomorphic encryption system based on identity-based encryption (IBE) or distributed key generation (DKG). Local model parameters are encrypted at the node level, and aggregation nodes can only perform weighted average calculations in the encrypted state, without needing to decrypt the original parameters of any participant throughout the process. Combined with secure key management, backup, and rotation protocols, it fundamentally prevents the leakage of training data and intermediate model parameters, meeting stringent privacy compliance requirements.

[0034] This application significantly reduces the computation and communication overhead in the ciphertext state by designing a hierarchical key system, adopting an efficient encryption algorithm that supports additive homomorphism (such as Paillier), and combining batch processing optimization and parallel processing technology, making privacy-preserving cross-domain training of deep neural networks feasible in practical application scenarios.

[0035] This application establishes a contribution measurement model through on-chain smart contracts and automatically calculates contribution scores based on node-local evaluation results (supplemented by TEEs or verifiable proofs using zero-knowledge proofs). The contract automatically allocates incentive tokens according to predefined rules, achieving programmatic fairness and real-time settlement in the incentive process, effectively stimulating the participation of all parties and improving the quality of contributions. Attached Figure Description

[0036] Figure 1 A flowchart illustrating a method for cross-domain training and privacy protection of AI models that integrates blockchain and homomorphic encryption, provided as an embodiment of this application. Detailed Implementation

[0037] 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.

[0038] The method for cross-domain training and privacy protection of AI models that integrates blockchain and homomorphic encryption provided in this application includes the following steps:

[0039] S1. System Initialization and Identity Registration: Participating organizations join the consortium blockchain network as nodes and deploy smart contracts for managing training protocols, access control, and incentives; each node generates and distributes homomorphic encrypted public and private key pairs and uploads the public key to the blockchain;

[0040] Specifically, S1 includes the following steps:

[0041] S1.1: Consortium Blockchain Network Construction and Identity Access. Participating organizations, as physically dispersed independent entities, jointly establish a permissioned consortium blockchain network. Each participating organization will run one or more blockchain nodes, which can be categorized according to their functions as training nodes, verification nodes, and aggregation nodes. Upon joining the network, each node must complete identity authentication through a pre-established access committee or a multi-party negotiated voting mechanism and obtain a digital certificate issued by the Certification Authority (CA). This digital certificate serves as the node's unique identifier (DID) on the chain, used for signing transactions, participating in consensus, and verifying permissions. The network's underlying architecture employs a consortium blockchain framework that supports efficient consensus algorithms (such as Practical Byzantine Fault Tolerance (PBFT) or its variants) to ensure the finality and efficiency of transaction confirmation.

[0042] S1.2: Layered key system generation and secure distribution. Each participating node needs to generate two sets of asymmetric key pairs, specifically including:

[0043] Blockchain transaction key pairs: used to digitally sign on-chain transactions (such as uploading parameters or calling contracts) to ensure non-repudiation. The public key is registered in the on-chain identity contract, and the private key is stored by the node's local secure hardware module (HSM) or encryption device.

[0044] Homomorphic encryption key pairs: used to protect model parameter privacy. Nodes generate public-private key pairs using encryption algorithms that support additive homomorphism (such as the Paillier encryption algorithm or a fully homomorphic modular component encryption scheme based on the Chinese Remainder Theorem). , Among them, the public key The private key is publicly uploaded to a specific smart contract on the blockchain for use by other nodes or aggregators when encrypting data. It is strictly stored locally on the node and will never be leaked or uploaded to the chain, and is used to decrypt the ciphertext aggregation results for this node;

[0045] To support secure aggregate decryption, a distributed key generation (DKG) protocol can be introduced to share fragments of a globally homomorphic decryption private key among multiple aggregation nodes, thereby achieving threshold decryption and avoiding single-point power overload.

[0046] Furthermore, to address the security, reliability, and recoverability requirements of homomorphic encryption key lifecycle management in cross-domain collaborative training environments, this solution designs a complete key security distribution, backup, and active rotation protocol, as follows:

[0047] Identity-Based Master Key Generation and Distribution: To simplify public key management and achieve identity-based direct encryption, this protocol employs an Identity-Based Encryption (IBE) architecture or a Distributed Key Generation (DKG) protocol to generate the system's master homomorphic key pair. Specifically:

[0048] Establish a Key Generation Center (KGC) or a committee composed of multiple authoritative nodes to execute a secure Distributed Key Generation (DKG) protocol. After the protocol is completed, all authoritative nodes jointly hold a globally homomorphic public key PK, while the corresponding globally shared master private key MSK is distributed among the authoritative nodes in a secret manner; that is, each authoritative node j holds a fragment of the master private key. Any set of authoritative nodes that reaches the threshold value t (e.g., t-out-of-n) can jointly recover or use MSK, but a single node or fewer than t nodes cannot obtain any information from MSK;

[0049] Each training node i is identified by its unique, verifiable digital identity registered on the consortium blockchain. (Such as the DID document hash) serves as its "identity". Based on the global public key PK, any node or aggregation server can directly use it. As the "public key", it is used to encrypt messages sent to node i or intermediate ciphertext results that need to be decrypted by node i, generating ciphertext C=Enc(PK, (message);

[0050] When node i needs to be decrypted To obtain the ciphertext of the target, it must initiate a private key generation request to the key generation committee. Any t authoritative nodes in the committee shard the key using their respective master private keys. and the requester It independently computes and returns a private key fragment. After node i collects at least t valid private key fragments, it can combine them into its complete personal homomorphic decryption private key using a specific algorithm (such as Lagrange interpolation). This process ensures that the master private key (MSK) never appears incompletely in any single location, and that the personal private key... Generate only when needed;

[0051] Key security backup and recovery, to prevent the storage of personal homomorphic decryption private keys locally on nodes. The loss of keys prevents them from participating in subsequent training or decrypting historical aggregation results, so a distributed key backup and recovery mechanism is introduced.

[0052] Node i generates its full private key for the first time. Then, immediately use a secret-sharing algorithm (such as Shamir's SecretSharing) to... Split into m partitions (m>t);

[0053] Node i distributes these shards to m pre-designated backup nodes (which can be other trusted nodes in the consortium blockchain or dedicated custodian nodes) via a secure channel (e.g., using the public key of the backup nodes). Each backup node stores one shard.

[0054] When node i's private key is accidentally lost, it can request the recovery of its private key fragments from at least t backup nodes. After verifying the requesting node's identity and recovery permissions (which can be determined through the authorization status recorded in the on-chain smart contract), the backup nodes return encrypted private key fragments. Once node i has collected enough fragments, it can reconstruct its private key. ;

[0055] Active key rotation is triggered when a potential security threat is detected (such as a node being suspected of being compromised), the predetermined key update cycle is reached, or a node leaves / joins.

[0056] Triggering and Announcement: The Key Management Committee or a voting mechanism via on-chain smart contracts will reach a consensus on key rotation. New rotation identifier. The rotation start timestamp is broadcast to the entire network and recorded on the blockchain;

[0057] New Key Generation: The key generation committee executes a new round of the DKG protocol to generate a new round of global public keys. and distributed master private key sharding . It was publicly released;

[0058] Progressive ciphertext migration and decryption: a. For new data: From the moment the rotation takes effect, all newly generated ciphertext of model parameters to be aggregated will use the new public key. and the identity of the recipient Encrypt;

[0059] b. For historical data: During the transition period, the aggregation server may simultaneously hold the old public key. and new public key The encryption parameters. When node i needs to decrypt an aggregation result encrypted with the old public key, it still needs to use its old private key. Therefore, for a period of time after the rotation is triggered, the key generation committee retains the right to fragment the old master's private key. Access to the old private key in response to node requests. The generation request (if regeneration is required);

[0060] c. Key splitting: After the round, node i will simultaneously possess... (Used to decrypt ciphertext of historical cycles) and (Used to decrypt ciphertext for a new round). By binding the ciphertext to the round identifier epoch, the node can automatically select the correct private key for decryption;

[0061] Secure destruction of old keys: After the transition period, all nodes and backup nodes securely erase the private keys from the old rounds via on-chain instructions. And all its fragments. Members of the key generation committee securely destroy the old master private key fragments. Complete the key rotation;

[0062] By combining the concepts of DKG, IBE, secret sharing, and an explicit rotating state machine, a balance is achieved between centralized management of homomorphic encryption keys and distributed trust. This simplifies public key distribution (based on identity), protects the master key (through threshold distribution), provides recovery capabilities for lost keys, and supports secure key rotation without affecting business continuity.

[0063] S1.3: Deployment and solidification of training protocol smart contracts. A set of core smart contracts is deployed on the consortium blockchain to programmatically and publicly disclose all training rules. These contracts mainly include:

[0064] Registration Management Contract: Manages the identity information, status (active / frozen / exited), and public keys of participating nodes. ;

[0065] Training Protocol Notification Contract: This contract stores the metadata of this cross-domain training task on the blockchain in a structured format. Specifically, it includes: the agreed-upon neural network model structure (e.g., layer type and size); global training hyperparameters (learning rate, number of iterations, target accuracy); data format specifications; the algorithm formula for aggregating model parameters (e.g., FedAvg); and detailed incentive mechanisms based on contribution (e.g., a token reward function based on accuracy improvement).

[0066] Contribution Record Contract: Used to record contribution credentials such as parameter hashes and evaluation results submitted by each node in each round during the training process, providing an immutable audit chain for subsequent incentive calculations;

[0067] S2. Local Model Training and Parameter Encryption: Each node performs data preprocessing locally and trains the model using the local data; the trained local model weight parameters are encrypted using the homomorphic encryption public key to generate ciphertext parameters; the hash value of the ciphertext parameters is calculated and uploaded to the blockchain for evidence storage.

[0068] Specifically, S2 includes the following steps:

[0069] Local data preprocessing and compliance self-checking: Before starting local training, each participating node i must first check its private dataset. Standardization and compliance verification are carried out, specifically including:

[0070] Data cleaning and formatting: Based on the data format specifications agreed upon in the on-chain training protocol's notarization contract, the data is cleaned and formatted... Perform necessary cleaning (such as handling missing values ​​and outliers), label alignment, and format standardization to generate a standardized dataset that meets the model input requirements. ;

[0071] De-identification of privacy-sensitive information: using technical means to de-identify... The direct identifiers (such as ID numbers and names) and quasi-identifiers in the dataset undergo generalization, suppression, or replacement processing. The techniques include, but are not limited to, k-anonymization, l-diversity, and differential privacy noise injection. The processed dataset is denoted as... This ensures that specific individuals cannot be directly identified from the reverse process.

[0072] Compliance Commitment Generation: Node i needs to generate a compliance statement regarding the data preprocessing process's compliance with established standards and privacy policies. The statement It can include information such as the name of the de-identification algorithm used, the hash of key parameters, and the data size, and use the node's blockchain transaction private key to sign and generate a digital signature. . and This will be submitted to the blockchain along with the model parameters in subsequent steps as part of the metadata, for post-audit verification.

[0073] Local model training and parameter extraction, with each node based on the preprocessed local dataset. Independently perform model training tasks:

[0074] Model loading and initialization: Node i obtains the initial global model architecture defined by the training protocol from the blockchain. The model and its weight parameters (randomly initialized parameters for the first round; parameters decrypted from the previous round's aggregated global model) are then loaded into the local training environment.

[0075] Constrained local training: node i in The model is trained strictly according to the optimization algorithms (such as SGD, Adam), learning rate, batch size, and local epochs specified in the on-chain contract. The training process is completed in a local, closed environment, generating an updated local model. This phase prohibits any action that involves transmitting raw data or intermediate features externally.

[0076] Specifically, the process of constrained local training includes:

[0077] The training procedure is fixed on-chain and internalized locally. Before training begins, the global training protocol smart contract has clearly defined the set of machine learning hyperparameters that must be used in this round of training. This set At least including:

[0078] Optimization algorithm identifier and parameters: For example, specify "Stochastic Gradient Descent (SGD)" with a momentum coefficient. Alternatively, specify "Adaptive Moment Estimation (Adam)" and include a first-order moment estimate of the decay rate. Second-order moment estimation of attenuation rate and stabilization constant ;

[0079] Learning rate strategy: Specify the initial learning rate Learning rate decay schedulers (such as exponential decay and cosine annealing) and their parameters;

[0080] Batch size: Defines the size B of the data subset used for each parameter update during local training;

[0081] Local iteration rounds: Specifies the number of times, E, the local dataset must be fully traversed within each training cycle;

[0082] Each participating node i must first synchronize and verify the blockchain when starting its local training program. The state of the smart contract. The local training engine does not allow manual modification. The permissions and configuration interface are forcibly bound to those obtained from the blockchain. The training engine loads the initial model. Then, strictly follow Constraints, in the local dataset The process involves a forward propagation, loss calculation, backpropagation, and parameter update loop. Any deviation... Configuring training behaviors (such as unauthorized changes to the optimizer or learning rate) will affect the parameters of the final generated local model. Unable to pass the format and validity verification of subsequent on-chain submissions;

[0083] A closed sandbox training environment is constructed, and the training process is executed in a strictly isolated local sandbox computing environment, which implements the following security policies:

[0084] Network isolation: During training tasks, the sandbox environment actively cuts off or blocks all outgoing network connections except for necessary transaction communications with blockchain nodes (such as downloading models and submitting commitments) through host firewall policies. Specifically, it blocks any unauthorized data packet transmissions to external IP addresses or domains.

[0085] Memory and process isolation: The training process runs in a separate, controlled container (such as a Docker container) or virtual machine. This environment can only access the specified data directory. And model files. All intermediate variables generated during training, including but not limited to activation values ​​(feature maps), gradient tensors, intermediate loss values, etc., are strictly confined to a sandbox environment and are automatically zeroed and released by the system after the training round ends. Operating system-level permission control ensures that the training process cannot initiate operations such as writing files to external storage or cross-process communication;

[0086] No covert channel design: The code implementation of the training program must undergo security review to prevent leakage of information about computation time, cache state, power consumption side channels, or any other covert channels. The training log should only output aggregated statistical information that does not involve any features of the original data samples or individual data points, such as the average loss value for this round.

[0087] For compliance verification, nodes can generate lightweight proofs of execution trajectory during training to provide post-audit or selective verification. For example, the training engine can record a sequence of loss values ​​at key checkpoints and generate a cryptographic commitment (such as a Merkle root hash) based on this. This commitment is then linked to the final parameters. Submitted together. Any validator can leverage the publicly available model architecture and input data size to replay a very small-scale "validation forward propagation," probabilistically verifying that the training process executes as expected by comparing commitments, without exposing real data;

[0088] Parameterization and Sequencing: After training, node i extracts the model. All trainable weight parameters, and serialize them into a high-dimensional floating-point vector or tensor. To facilitate subsequent homomorphic encryption operations, it is usually necessary to... Flattened into a one-dimensional vector, and possibly scaled or converted to a fixed point value to suit the plaintext space requirements of homomorphic encryption algorithms;

[0089] Homomorphic encryption and on-chain notarization of parameters are used to protect... To protect privacy, node i needs to encrypt the data and submit an immutable submission credential to the blockchain:

[0090] Homomorphic encryption operation: Node i uses its own currently valid homomorphic encryption public key. (The key corresponding to the current training round) to the local model parameter vector Encryption is performed. The encryption process targets... Each scalar parameter (or parameter block) in the process is processed independently to generate the corresponding ciphertext parameters, ultimately forming an encrypted parameter vector. To ensure the correctness of subsequent aggregation calculations, the encryption process must strictly follow the operating specifications of the selected homomorphic encryption scheme (such as Paillier) to guarantee the homomorphism of addition;

[0091] Generate submission credentials: Calculate the encryption parameter vector cryptographic hash value, such as The hash value can be a collision-resistant hash function such as SHA-256. Serves as a unique digital fingerprint for the parameters of the encrypted model;

[0092] Constructing and submitting a transaction on the blockchain: Node i constructs a blockchain transaction that invokes a specific "parameter commit" smart contract. The transaction payload must contain at least: a node identity identifier. Training round number, compliance statement signature And the hash value of the parameter that serves as the core submission credential. Note: The encrypted parameters at this point are very large. The transaction itself is not directly stored on the blockchain to avoid causing congestion on the blockchain network. The transaction is broadcast to the network after being signed by the node's private key.

[0093] On-chain verification and commitment recording: After receiving a transaction, the verification nodes in the blockchain network verify its signature validity, node identity and permissions, and round matching. Once verification is successful, the smart contract will ( ,round, This is recorded in the on-chain state as a public commitment from node i that it has completed this round of local training and generated specific cryptographic parameters. (Ciphertext) It is then temporarily stored via a peer-to-peer (P2P) network, the InterPlanetary File System (IPFS), or a designated high-bandwidth storage layer, and available for aggregation nodes to retrieve on demand. Its integrity can be verified by comparing it with the data stored on the chain. Verification is required;

[0094] S3, Cross-domain parameter on-chain and consensus verification: Each node uploads the encrypted ciphertext parameters to the blockchain through transactions. The verification nodes in the blockchain network use smart contracts to verify the compliance of the parameter submission behavior. The smart contracts dynamically group the verified encrypted parameters according to a preset strategy.

[0095] S3 achieves state consensus within the consortium blockchain network using the privacy-preserving model parameters generated by each participant in a trustworthy, verifiable, and efficient manner. It also performs structured preprocessing for subsequent cross-domain secure aggregation, specifically including the following processes:

[0096] S3.1: On-chain storage and indexing of encrypted parameters. After completing local training and parameter encryption, each participating node must submit proof of the encrypted parameters to the blockchain network. The specific process is as follows:

[0097] Constructing a structured evidence storage transaction: Node i creates a transaction pointing to the "Federated Learning Coordinator" smart contract. The input data for this transaction includes:

[0098] Sender identity: The authoritative identity identifier of the node. ;

[0099] Training context: The current global training epoch number;

[0100] Data fingerprint: Locally encrypted parameter vector cryptographic hash value This serves as a commitment to the uniqueness and integrity of data;

[0101] Storage locator: a data block in an off-chain distributed storage network. Content identifier ;

[0102] Verifiable Declaration: A signed package containing metadata such as local training hyperparameter snapshots and data preprocessing compliance declaration hashes. Use node i's blockchain private key to sign;

[0103] Transaction propagation and initial verification: Node i broadcasts the signed transaction to the P2P network. Upon receiving the transaction, the verification nodes in the network first perform basic verification, including: the validity of the digital signature, Whether it is a registered active training node and whether the epoch matches the current active training rounds on the chain. This stage does not involve... Its own handling;

[0104] S3.2: Based on the smart contract's parameter submission compliance consensus verification, transactions that pass the initial verification will be packaged into candidate blocks, triggering the verification logic of the "Federated Learning Coordinator" smart contract. The contract performs the following automated checks, forming the basis for decentralized consensus:

[0105] Format and policy compliance verification:

[0106] Contract Inspection Are the training hyperparameters (such as learning rate and batch size) in the code consistent with the on-chain training protocol? The parameters specified in the document are completely consistent with those specified in the document, or fall within the allowed fluctuation range.

[0107] verify Does the data preprocessing method declared in the document comply with...? The stipulated privacy compliance terms (e.g., whether the specified differential privacy algorithm and parameters are used);

[0108] Submission timeliness and uniqueness verification:

[0109] The contract checks whether the current block timestamp is within the commit time window specified by the parameters of the epoch round. Submissions that time out will be rejected.

[0110] The contract maintains a mapping table of nodes that have committed in this round, ensuring that each Only one successful submission is allowed within this epoch to prevent replay attacks or duplicate calculations.

[0111] Off-chain storage commitment verification:

[0112] The contract can call a pre-compiled "store verification" contract interface, passing in... This involves obtaining a snapshot of the content's current state (e.g., storage provider, storage time, number of replicas) in an off-chain storage network (such as IPFS). By comparing this snapshot with a preset minimum storage requirement (e.g., number of replicas ≥ 3), the likelihood of data availability is indirectly verified.

[0113] On-chain verification results and state updates: Only after all the above checks pass will the smart contract update node i's current commit record to the on-chain state. The record content must include at least: ( This state update signifies that the entire network has reached an immutable consensus on the fact that "node i has compliantly completed this round of local training and submitted the parameters for the specified hash." If any check fails, the transaction will be rolled back, the state will remain unchanged, and the node will be notified via the event log.

[0114] S3.3: On-chain dynamic parameter grouping and aggregation task orchestration. After the parameter submission window closes, the smart contract automatically performs pre-aggregation grouping preparation. This process dynamically generates aggregation task units according to a preset strategy.

[0115] Grouping strategy configuration: Training protocol The `GroupingPolicy` function is defined in the code. This policy can be based on one or more of the following dimensions:

[0116] Data domain (Domain-based): Grouping nodes according to the data domain labels declared during node registration (such as "medical imaging", "financial risk control", "IoT sensors") to achieve rapid fusion of prior knowledge of models within the domain;

[0117] Contribution-based evaluation: Calculate the contribution score of a node based on the quality of model updates in historical training rounds (such as the magnitude of loss reduction or the improvement of test set accuracy) or the amount of data, and mix and group nodes of different contribution levels to balance the global model convergence speed and fairness.

[0118] Network topology-based: Considering the network latency and geographical location of nodes, adjacent nodes are grouped together to reduce data transmission latency across the wide area network in the subsequent aggregation phase.

[0119] Dynamic grouping execution: The contract reads all records with status="committed" in this round and lists the nodes. Take the necessary metadata as input and call the GroupingPolicy function. The function outputs a series of non-overlapping grouped sets. each Includes a set of node IDs and their corresponding List. For example, grouping might be generated: (Medical Imaging Group) (Financial Risk Control Group);

[0120] Aggregated task publishing: For each generated The smart contract automatically creates and publishes an aggregated task order. The work order records the grouping information, aggregation algorithm (such as FedAvg), eligibility requirements for aggregation nodes (such as needing to hold a homomorphic public key), and task deadline. This work order is issued as an on-chain event, awaiting acceptance by eligible aggregation nodes.

[0121] S4. Secure Aggregation and Privacy-Preserving Computation: Aggregation nodes obtain the encrypted parameters within the group from the blockchain, and based on the additive homomorphic property of homomorphic encryption, perform weighted average calculation directly in the ciphertext state to generate global encrypted model parameters; the aggregated ciphertext model parameters and their hash values ​​are uploaded to the blockchain;

[0122] S4 specifically includes the following steps:

[0123] S4.1: Selection and authorization of aggregation nodes. The aggregation operation is not executed by a single fixed node, but through a dynamic rotating committee mechanism to enhance the decentralization and anti-collusion capabilities of the system.

[0124] Committee Election: After the parameter submission phase of each training epoch, the on-chain smart contract elects an aggregation committee of M nodes from all online and reputable nodes using a preset algorithm (such as random sampling based on Proof-of-Stake (PoS), reputation ranking, or Verifiable Random Function-VRF). The number of M is set according to the safety threshold and efficiency requirements (e.g., M=5);

[0125] Task allocation and key synchronization: The smart contract will synchronize the aggregated task work orders generated in step three. Assigned to Committee members negotiate or obtain the globally homomorphic encrypted public key required to execute this round of aggregation either through an off-chain secure channel (such as using their respective identity public keys for encrypted communication) or from on-chain. (If identity-based encryption is used), and synchronize the algorithm details;

[0126] Aggregate Execution Commitment: Committee members must deposit a certain amount of security deposit into the smart contract and submit a commitment to honestly execute the aggregated tasks. Any member's unjustified withdrawal or subsequent evidence of wrongdoing will result in the forfeiture of the security deposit.

[0127] S4.2: Secure Acquisition and Verification of Ciphertext Parameters. Before executing aggregation, the aggregation node (committee member) must securely acquire and verify the ciphertext parameters within its task group.

[0128] Off-chain acquisition based on CID: Aggregator nodes based on Recorded in The list initiates a retrieval request to the decentralized storage network to obtain encrypted parameters. ;

[0129] On-chain hash integrity verification: For each obtained The aggregation node calculates its hash. Subsequently, the node queries the blockchain for data submitted by node i and verified through consensus. Only when Only then does the aggregation node confirm the obtained ciphertext. Complete and error-free, it can participate in subsequent aggregations. This step binds the availability of off-chain data with the integrity commitment on-chain, preventing man-in-the-middle tampering;

[0130] S4.3: Secure aggregation computation under homomorphic encryption: After confirming that all required ciphertext parameters are complete and correct, the aggregation node performs weighted average calculation in the ciphertext state;

[0131] Weight determination: parameters for each local model Aggregate weights According to the training protocol Confirmed. Typically, ,in Let N be the local data volume of node i (this information can be committed to by the node in its compliance statement and verified by zero-knowledge proof), and let N be the sum of the data volumes of all nodes in the current group. Weights must be publicly determined before aggregation or can be derived from publicly available information.

[0132] Ciphertext scalar multiplication and addition: Utilizing the additive homomorphic property of the adopted homomorphic encryption scheme (such as Paillier), i.e., satisfying... and (For plaintext integer k), the aggregation node performs the following calculations:

[0133] Ciphertext weighting: For each Calculate its weighted ciphertext In practice, due to Typically, these are floating-point numbers and need to be converted to a fixed-point representation supported by the plaintext space of the homomorphic encryption scheme (e.g., multiplying by a large integer L and then rounding down). ), then calculate ;

[0134] Ciphertext Summation: Calculate the product of all weighted ciphertexts. According to the homomorphic property, That is, the weighted average result. (Consider the scaling factor L) ciphertext;

[0135] Batch processing and computation optimization: To address the computational challenges posed by the massive number of parameters in deep neural networks (potentially tens or hundreds of millions), batch processing homomorphic operations are employed. The model parameter vector is divided into smaller batches, and the aforementioned weighted summation operations are performed independently on each batch, fully utilizing the parallel computing capabilities of modern processors (such as SIMD instruction sets). Furthermore, for schemes like Paillier, the base of the modular exponentiation operation can be pre-calculated and reused to accelerate the process. Calculation;

[0136] S4.4: Generation and Verifiability Proof of Aggregation Results. After completing the ciphertext aggregation calculation, the aggregation node needs to generate the aggregation result and a verifiable proof.

[0137] Converged ciphertext result: The final converged ciphertext vector is obtained. (Composed of multiple ciphertext components);

[0138] Generate verifiable aggregation proofs: to prove that the aggregation computation was performed correctly (i.e., it did indeed use proofs verified on-chain). And according to the public weight (Calculation), the aggregation node needs to generate an aggregation correctness proof. This proof can be achieved through one or more combinations of the following methods:

[0139] Cryptographic commitment: Before starting computation, the aggregating node verifies the obtained... and determined weights Generate a Merkle tree commitment After the calculation is completed, for Generate commitments Then, proofs are generated using zero-knowledge proof techniques (such as a small-scale circuit of zk-SNARK). ,prove Indeed, it is made by The inputs promised in the middle are calculated using the correct homomorphic weighted average;

[0140] Multi-signature threshold result: Within the aggregation committee, each member independently performs the aggregation calculation and obtains its own result. Since the calculation is deterministic, all honest members should get the same result. Committee members... The hash value is used for threshold signing (such as using BLS signature aggregation), ultimately producing an aggregation result signature endorsed by a majority of committee members. Any validator can verify the signature to be certain that the result was produced by an honest majority.

[0141] Result encapsulation: The aggregation node will ( , Pack and calculate hash ;

[0142] Aggregation results are stored on-chain and synchronized with the status; transaction submission: any member of the aggregation committee or a designated coordinator will ( , , As the payload, it constructs transactions and submits them to the blockchain. Among these, the large volume... It itself is not on the blockchain, but is stored on an off-chain storage network, and its... Please submit them together as well;

[0143] Smart contract verification and logging: Relevant smart contract verification The validity of the aggregation. After successful verification, the contract records the aggregation result of this round on the chain and updates the status to: ( Simultaneously, the contract triggers an event to notify all participating nodes within the group that aggregation is complete and downloads are available. Proceed to the next round of training;

[0144] Aggregation Node Incentives: The smart contract distributes reward tokens to committee members who successfully complete the aggregation task and submit valid proof, according to a predefined incentive mechanism.

[0145] S5. Model Update and Incentive Mechanism Execution: Each node downloads the global encrypted model parameters from the blockchain, decrypts them using its own homomorphic encrypted private key, and updates the local model; Each node evaluates the model performance locally and uploads the signed evaluation results to the blockchain; The smart contract automatically distributes incentives based on the evaluation results and contribution.

[0146] Specifically, S5 includes the following steps:

[0147] S5.1: Securely obtain and decrypt global model updates. After the global aggregation of blockchain state confirmation is completed, each participating node performs the following operations to update its local model:

[0148] Authorized retrieval and integrity verification:

[0149] Node i queries the smart contract to obtain the latest global model ciphertext. Corresponding content identifier and its hash commitment ;

[0150] Node i uses Retrieve encrypted data block C' from a decentralized storage network;

[0151] Local computation and with the records on the chain Comparison, only when Only then can the node confirm that the acquired data is complete, has not been tampered with, and is a reliable aggregation result;

[0152] Privacy Decryption and Model Reconstruction:

[0153] Node i uses its strictly localized homomorphic decryption private key. ,right Perform the decryption operation to obtain the plaintext global model update parameters. ;

[0154] For scenarios with higher security requirements, distributed threshold decryption can be used, where node i holds the key. This is only a fragment of the private key used for global decryption. During decryption, node i needs to collaborate with other nodes, each using its own private key fragment. Partial decryption is performed to generate partial decryption results. After collecting a sufficient number (reaching a threshold) of valid partial decryption results, the complete plaintext can be synthesized. This mechanism avoids the risk of a single point of contact holding the complete decryption key;

[0155] The node will decrypt the obtained Load the updated model into the local model architecture, replace the old parameters, and complete the local model update. This updated model will serve as the starting point for the next round of training or local inference tasks.

[0156] S5.2: Locally validated model performance evaluation and trusted on-chain verification quantify the contribution of nodes to this round of updates and serve as the basis for incentive allocation. Nodes must evaluate the updated model locally. The key challenge lies in ensuring the authenticity and reliability of the evaluation results and preventing nodes from making false claims.

[0157] Standardized local evaluation: A unified evaluation protocol is predefined in the smart contract. Specify the metadata (such as data distribution description, sample number hash) or generation rules of the standard validation set V used for evaluation, as well as the evaluation metrics (such as classification accuracy Acc, loss value Loss, F1 score, etc.).

[0158] Node i locally according to Load or generate validation sets (Ensure it is identically distributed to the standard set), and use the updated model to perform inference on it, calculating the values ​​of each evaluation index. ;

[0159] Generate verifiable evaluation commitments:

[0160] To prove that the evaluation was performed according to regulations and that the results are genuine, a node needs to generate a verifiable evaluation certificate. This can be achieved in one or more of the following ways:

[0161] Proof based on a Trusted Execution Environment (TEE): The evaluation process is completed within a TEE (such as Intel SGX). The TEE generates a remote proof. It declares the metrics of the evaluation code running internally and outputs the evaluation results signed with the TEE private key. This signature can be verified using the TEE public key corresponding to the on-chain contract;

[0162] Concise verification based on zero-knowledge proof: Nodes will evaluate computations (model forward propagation in...) The computations on the above are compiled into a circuit to generate a zero-knowledge proof. This demonstrates that they have mastered the evaluation inputs (model parameters, validation set data) and outputs. And the calculation process is consistent with without revealing Specific data. This provides the strongest privacy protection;

[0163] Trustworthy evaluation based on oracle networks: Nodes will update the model parameters The results are submitted to a decentralized oracle network. Oracle nodes independently run evaluations on a standard and publicly available test set. The results from multiple nodes are then aggregated (e.g., by taking the median) before the final result is submitted. On-chain. This method shifts the computational burden and trust to the oracle network;

[0164] The evaluation results are stored on the blockchain: Node i constructs an evaluation submission transaction, which includes: ,epoch,evaluation results and the corresponding proof ;

[0165] Smart contract verification The validity of the verification. Once verified, it will... Recorded on the chain and associated with the current training record of node i;

[0166] S5.3: Smart contract-driven contribution assessment and automatic incentive distribution. After all nodes submit the assessment results or the assessment deadline is reached, the smart contract automatically executes the contribution calculation and incentive distribution.

[0167] Multidimensional contribution measurement model:

[0168] The contract encodes a contribution scoring function. The input to this function It is a state vector, which includes, but is not limited to:

[0169] This round of model quality improvement includes: for example... (The improvement compared to the node's own performance in the previous round), or the ratio to the global average improvement;

[0170] Historical contribution accumulation: a weighted sum of contributions from past rounds, reflecting long-term value;

[0171] Data compliance and process verification results: Zero-knowledge proof verification results from S5.2, data volume commitment. ;

[0172] Participation stability: such as consecutive rounds of participation and on-time submission rate;

[0173] This function calculates a scalar contribution score for each node. ;

[0174] Incentive pool allocation and token distribution: Each training task cycle has a total incentive pool RewardPool(epoch), and the funds may come from the task initiator's prepayment, system inflation, or penalty income from previous steps;

[0175] The smart contract distributes rewards according to the relative contribution of each node. The reward that node i should receive is:

[0176] The contract will automatically calculate The token amount is transferred from the escrow account to node i's registered address. The entire process requires no human intervention, and fairness is guaranteed by pre-defined contract logic.

[0177] Penalty and Arbitration Mechanism: For nodes that fail to submit valid evaluation proof, whose evaluation results are found to be falsified (such as being seriously inconsistent with the results of other nodes or oracles), or who are proven to have engaged in malicious behavior in previous steps, the smart contract will enforce penalties.

[0178] Penalties include, but are not limited to: withholding the current round's rewards, deducting a portion of the pledged margin, lowering credit score, and suspending eligibility for future participation. Penalties may be injected into the incentive pool or the system's insurance fund.

[0179] Establish an on-chain governance arbitration contract that allows nodes to object to evaluation or incentive results, and have a jury composed of randomly selected nodes or a designated governance committee vote to decide the outcome.

[0180] S6. Audit and Traceability Mechanism: The entire process of parameter submission, aggregation calculation, and evaluation results during training is recorded on the blockchain; abnormal behavior is detected by analyzing the on-chain records and traced back to the specific participating nodes, and penalties are implemented in conjunction with smart contracts.

[0181] Specifically, S6 includes the following steps:

[0182] S6.1: Structured recording of the entire on-chain audit log. All key operations and state changes are persisted on the blockchain in structured data form, forming an immutable audit trail. This audit system records the following core dimensions:

[0183] Operation Event Log: Records all key actions that occur through specific events emitted by smart contracts. These events include timestamps, executor identities (IDs), and hashes of relevant parameters. Main event types include:

[0184] ModelUpdateCommitted: The node commits the hash of the locally encrypted parameters.

[0185] ShardAggregationCompleted: The ShardAggregation Subcommittee completed and submitted the ShardAggregation results and proof.

[0186] GlobalAggregationCompleted: The global aggregation coordinator submits a complete global model update;

[0187] EvaluationSubmitted: The node submits its local evaluation results and proof.

[0188] RewardDistributed / PenaltyExecuted: Smart contracts distribute rewards or execute penalties;

[0189] State snapshot storage: Key state variables of the smart contract are snapshotted after key phases of each training round. These states include:

[0190] List of participating nodes and their status (committed / not committed) for each round;

[0191] Composition of the Aggregation Committee and its subcommittees;

[0192] The hash of the final global model update in this round ;

[0193] The set of evaluation results for all nodes and contribution score ;

[0194] Credentials and Proof Storage: All cryptographic credentials used to verify the correctness of the process are stored in the form of call data or event logs, including:

[0195] Zero-knowledge proofs submitted by nodes (or its hash);

[0196] Proof of correctness of aggregation submitted by the aggregation committee Or threshold signature;

[0197] Evaluation proof submitted by the node ;

[0198] Audit Index Construction: To facilitate efficient traceability, the smart contract maintains a composite index with the training epoch and node ID as keys. Any regulator or participant can use this index to quickly retrieve all relevant operation records, state changes, and submitted credentials of a specific node in a specific epoch, thereby reconstructing its complete behavioral sequence.

[0199] S6.2: Triggering and multi-dimensional analysis of abnormal behavior detection. The system analyzes the audit data recorded on the chain through preset abnormal detection rules and extensible analysis modules to discover potential malicious behavior.

[0200] Global anomaly detection based on model performance: After each round of training, the smart contract or a designated "monitoring oracle" analyzes all on-chain evaluation results. ;

[0201] Example of triggering condition: Global performance degradation: The average evaluation metric (such as average accuracy) of the global model in this round decreases significantly compared to the previous round (the decrease exceeds the threshold). ), and the statistical test is significant;

[0202] Outliers in the evaluation results: The evaluation result of a node i If the results of the other vast majority of nodes show statistically significant anomalies (e.g., extreme outliers detected using Z-score or IQR methods), it may indicate that the node used an atypical local validation set or fabricated the results.

[0203] Once triggered, the system will automatically mark that round as "pending investigation" and initiate the tracing process;

[0204] Real-time behavior analysis based on process consistency: Anomalies are detected during training by analyzing the sequence of operational events and state consistency.

[0205] Violation of protocol order: For example, a node attempts to participate in the aggregation vote before completing its local training submission; or the aggregation committee releases the final result before collecting all the necessary proofs;

[0206] Abnormal timing behavior: The timing of node parameter submissions deviates significantly from the normal distribution (e.g., submissions made very shortly after the deadline may be forged), or the aggregation calculation takes much less time than expected (maybe no actual calculations were performed).

[0207] Invalid or contradictory credentials: Zero-knowledge proofs submitted by nodes Verification failed; or the node committed to a certain amount of local data. There is a huge and inexplicable deviation from its historical submission pattern;

[0208] S6.3: Precise traceability and responsibility identification. When an anomaly is detected, the system initiates a traceability process with the goal of locating the root cause and the responsible party.

[0209] Parameter traceability based on differential analysis: When a model is suspected of degrading due to malicious parameter updates, an authorized agency (such as a regulator or arbitration commission) can initiate a traceability request.

[0210] The smart contract will provide the encrypted parameters submitted by all participating nodes in the questionable rounds. Off-chain storage locators And the corresponding aggregation path (such as sharded aggregation records);

[0211] By employing authorized decryption or secure multi-party computation, the aggregation process can be replayed in a controlled environment, allowing for the calculation of the "contribution impact" or "destructive score" of each node's update on the final global model. For example, the positive or negative impact of an update can be assessed by calculating the change in global model performance after removing it from the aggregation. This analysis can pinpoint the nodes that provide the "poisoning" update.

[0212] Behavioral graph analysis and association tracing: The system can construct a "behavioral graph" of nodes, taking the behavior of nodes in multiple rounds of training (timeliness of submission, validity of proof, consistency of evaluation results, reward / penalty history) as node attributes, and the collaborative relationship between nodes (such as belonging to the same aggregate subcommittee) as edges;

[0213] When an anomalous behavior is detected (such as model poisoning), graph analysis algorithms (such as community detection and influence propagation models) can be used to identify whether a malicious node alliance exists, or to identify other nodes most affected by the anomalous node. This helps in discovering coordinated attack patterns;

[0214] S6.4: The smart contract automatically executes tiered penalties. After the responsibility is traced and confirmed, the smart contract will automatically execute the corresponding penalties according to the predefined "violation-penalty" mapping rules.

[0215] Penalty rule encoding: A penalty policy function is encoded in the smart contract. This function determines the penalty based on the type and severity of the violation, as well as the node's historical violation records.

[0216] Tiered penalties may include: Economic penalties: Immediate forfeiture of part or all of the node's rewards for this round. A portion of the pledged collateral deposit is deducted. The confiscated funds are injected into the system's insurance fund or compensation pool.

[0217] Reputation downgrade: Significantly reduces the node's reputation score. This will directly affect its future selection as an aggregation node, its allocation of high weight, and its priority in accepting orders;

[0218] Eligibility restrictions: suspend the node's eligibility to participate in future N rounds of training, or permanently blacklist it;

[0219] Model Reset: In extreme cases, if it is confirmed that the data or behavior of a certain node has seriously polluted the global model, the smart contract can authorize the initiation of a "model rollback" round, remove the node's contribution in all affected rounds, and recalculate the model state based on the records of the remaining honest nodes (requires an additional backup mechanism).

[0220] Appeals and Arbitration: To ensure fairness, an appeal channel is established. Penalized nodes can provide additional evidence to appeal to the "Arbitration Contract." Arbitration is conducted by other randomly selected nodes or a designated governance committee, with a final decision made through voting.

[0221] S7. Dynamic Exit and Node Management: Participating nodes can apply to exit, and the smart contract freezes their permissions and liquidates their incentives; new nodes join after identity verification and staking, synchronize the current global model from the blockchain, and participate in subsequent training.

[0222] Specifically, a node's request to leave includes the following steps:

[0223] The node i sends a signed exit request transaction to the smart contract, declaring its intention to exit and the target exit round Epoch_exit (usually after the current or next complete training round ends).

[0224] Upon receiving the request, the smart contract immediately marks node i's status as "exiting" and freezes some of its critical permissions:

[0225] New task participation is prohibited: Nodes will be unable to be selected for subsequent rounds of the aggregation committee or subcommittee;

[0226] Restricted submission capability: In After that, the node is unable to submit new local parameters or evaluation results;

[0227] Pledged assets are locked: the pledged margin and unclaimed incentives are temporarily locked and will be processed after liquidation.

[0228] Upon completion of obligations and incentive settlement, the smart contract checks whether node i has any outstanding obligations: For ongoing aggregation tasks: if node i is a member of an active aggregation committee, the contract will force it to complete the current round of aggregation tasks, or trigger the committee reorganization mechanism (replacing it from a backup node). If a node abnormally exits before task completion, it will be considered a breach of contract and subject to a penalty.

[0229] Evaluation proofs to be verified: If a node has submitted an evaluation result but the proof has not yet been verified, the contract will accelerate the verification process;

[0230] Incentives and Staking Liquidation: All incentives due to contract computation node i up to Epoch_exit: For completed and verified training rounds, all rewards are distributed according to contribution.

[0231] For rounds that are ongoing and where nodes have submitted valid parameters, a portion of the rewards will be distributed proportionally or according to predefined rules based on the contribution credentials submitted (such as parameter hashes and evaluation proofs).

[0232] After deducting potential losses to the system due to its exit (such as the cost of triggering a reorganization of the aggregation committee) and historical violation penalties, the remaining incentive and pledge margin balance will be transferred to the designated account of node i.

[0233] Privacy data secure erasure and model contribution isolation, local data and key destruction: After exiting, node i should securely erase all task-related privacy data locally, including original training data, intermediate model parameters, homomorphic encrypted private key fragments, etc. It is recommended to submit proof of secure erasure to the contract via remote proof (such as TEE attestation);

[0234] On-chain contribution record archiving and de-identification: Node i's historical contribution records (such as hashes of submissions in each round and evaluation results) will be retained on the blockchain for auditing, but its identity will be de-identified. These records can be decoupled and replaced with an unassociated pseudonym to protect the long-term privacy of the exiting node;

[0235] Global model contribution isolation: To prevent exiting nodes from using previously participated global model versions for privacy-preserving inference attacks, a model contribution forgetting mechanism can be introduced. In subsequent global model updates, differential privacy noise injection or secure multi-party computation is used to gradually dilute and cover the contribution impact of exiting nodes in historical models, making them impossible to trace back.

[0236] After completing all the above steps, the smart contract updates the state of node i to "exited", releases all on-chain resources it occupies (such as registry entries), and triggers an exit completion event.

[0237] The exit record of node i (including exit time, liquidation details, and final state) is permanently archived in a separate historical storage area of ​​the blockchain for future auditing.

[0238] Additionally, S7 features a new node addition and rapid synchronization process, which includes the following steps:

[0239] Pre-qualification and on-chain registration: Potential new node j must first pass a decentralized identity authentication and reputation assessment protocol. This protocol may involve:

[0240] Submit identity credentials endorsed by a trusted third party (such as a CA authority or other well-known nodes);

[0241] Complete a standardized "trial task" on the test network to demonstrate its computing power, network stability and compliance, and generate an initial reputation score;

[0242] After successful authentication, node j sends a registration request to the smart contract, submitting its public key information, resource claims (such as storage and computing power), and data domain label. The contract assigns it a unique identifier. And record the initial credit score. ;

[0243] Security staking and protocol commitments: New node j must stake a certain amount of tokens as collateral according to system rules. The staking amount is dynamically linked to the initial reputation score and declared resource level (the higher the reputation score, the lower the required staking may be).

[0244] Node j needs to sign and confirm, and commit to complying with the training protocol on the blockchain. and all system rules. This commitment serves as the basis for future accountability;

[0245] State synchronization and model initialization, training context synchronization: The smart contract provides node j with the complete context of the current task, including: the latest training protocol. Current active rounds , The hash of the aggregation results of historical rounds (used to verify the integrity of the chain);

[0246] Secure Acquisition of Global Model: Node j retrieves the latest global model ciphertext from the blockchain. After downloading and verifying the storage locator CID and its hash, a secure initialization decryption request is initiated.

[0247] Method 1 (Master Key System): If the system uses Identity-Based Encryption (IBE), node j uses its... Request the private key from the key generation committee, and then decrypt;

[0248] Method 2 (Threshold Decryption): Node j joins a threshold decryption group and collaborates with other nodes to decrypt;

[0249] Method 3 (Re-encryption): Existing nodes or dedicated services use proxy re-encryption technology to... Convert it into ciphertext under node j's public key, and decrypt it independently;

[0250] Local environment initialization: Node j loads the decrypted global model parameters to the local machine, configures the training environment, and prepares local data according to the protocol;

[0251] To mitigate the risks that new nodes may bring (such as malicious joining or insufficient ability), an internship period (such as the first N training rounds) is set up.

[0252] During the probationary period: Contribution weight is limited: The weight of local updates in the aggregation may be capped (e.g., not exceeding 50% of the average weight), or additional verification may be required;

[0253] Restricted access: Typically not selected for the aggregation committee;

[0254] Enhanced monitoring: Their behavior is monitored more closely, and any anomalies may result in immediate suspension of participation and investigation;

[0255] After the internship period, if the performance (such as submission on time rate, calculation accuracy, and model improvement contribution) meets the requirements, the smart contract will automatically upgrade the person to a formal node and unlock all permissions and weights.

[0256] The system is dynamically adjusted. When a new node is added, the grouping policy and aggregation committee election algorithm in the smart contract should automatically take the new node into account and dynamically adjust to optimize the overall system performance and security.

[0257] 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 cross-domain training and privacy protection of AI models integrating blockchain and homomorphic encryption, characterized in that, The method includes: S1. System Initialization: Construct a permissioned consortium blockchain network containing multiple participating nodes; configure homomorphic encryption key pairs for each participating node, including a public key and a private key; and deploy smart contracts on the consortium blockchain to define training rules, perform verification, and provide incentives. S2, Local Encrypted Training and On-Chain Notification: Each participating node trains the model locally based on its private data to obtain local model parameters; each node uses its own homomorphic encryption public key configured in S1 to encrypt the local model parameters to generate ciphertext model parameters; the hash value of the ciphertext model parameters is used as a submission credential and uploaded to the consortium chain built by S1 for notification by the on-chain smart contract. S3. On-chain verification and dynamic task orchestration: The consortium blockchain uses the smart contract to perform consensus verification on the submission credentials of each node uploaded in S2; for nodes that pass verification, they are dynamically grouped according to a preset strategy to form at least one aggregated task unit, and the grouping information is recorded on the chain. S4. Secure Ciphertext Aggregation: The selected aggregation node obtains the ciphertext model parameters of the corresponding node based on the on-chain grouping information generated in S3; based on the additive homomorphism of homomorphic encryption, the ciphertext model parameters are weighted and averaged in the ciphertext state to generate global encryption model parameters; the hash value of the global encryption model parameters is uploaded to the consortium blockchain for evidence storage. S5. Model Update and On-Chain Incentives: Each participating node obtains the global encrypted model parameters generated in S4 from the consortium blockchain, decrypts them using its own homomorphic encryption private key configured in S1, and updates its local model accordingly; each node evaluates the performance of the updated model locally and submits the digitally signed evaluation results to the consortium blockchain; the smart contract automatically calculates and distributes incentives based on the evaluation results submitted by each node. S6. Full-process auditing and anomaly handling: All key operation records and state changes generated in S2 to S5 are recorded in the consortium blockchain in a full and tamper-proof manner to form an audit log; by analyzing the audit log, abnormal behavior is detected, traced back to the specific participating node, and the smart contract is triggered to execute the preset penalty rules; S7. Node Dynamic Management: Participating nodes apply to exit through on-chain transactions, and the smart contract freezes their permissions and completes incentive liquidation; new nodes join the consortium blockchain network after completing on-chain identity authentication and staking, and synchronize the current training status and model parameters from the chain to participate in subsequent training.

2. The method for cross-domain training and privacy protection of AI models integrating blockchain and homomorphic encryption as described in claim 1, characterized in that, The configuration of homomorphic encryption key pairs for each participating node in S1 specifically includes: generating a global homomorphic encryption public key using an identity-based encryption architecture or a distributed key generation protocol; Each participating node uses its unique digital identity on the consortium blockchain as its encrypted identifier; When a participating node needs to decrypt data, it requests a private key fragment from a key generation committee composed of multiple authoritative nodes and combines them to generate its complete personal homomorphic decryption private key.

3. The method for cross-domain training and privacy protection of AI models integrating blockchain and homomorphic encryption as described in claim 2, characterized in that, S1 also includes deploying a training protocol smart contract on the consortium blockchain. The training protocol smart contract programs and stores the model structure, training hyperparameters, aggregation algorithm, and incentive rules.

4. The method for cross-domain training and privacy protection of AI models integrating blockchain and homomorphic encryption as described in claim 1, characterized in that, The local training of the model mentioned in S2 specifically includes: each participating node performing model training in a local sandbox computing environment that is isolated from the network, memory, and processes, strictly following the training hyperparameter constraints synchronized from the consortium blockchain.

5. The method for cross-domain training and privacy protection of AI models integrating blockchain and homomorphic encryption as described in claim 1, characterized in that, The consensus verification described in S3 specifically includes checking at least one of the following through a smart contract: whether the training hyperparameters declared in the metadata submitted by the participating nodes conform to the agreement of the on-chain training protocol; Is the submission time within the specified parameter submission time window? Is this the first submission from the participating node in the current training round? 6. The method for cross-domain training and privacy protection of AI models integrating blockchain and homomorphic encryption according to claim 1, characterized in that, The dynamic grouping in S3 is executed according to the pre-set grouping strategy function on the chain. The grouping strategy is based on at least one of the following dimensions: the data domain label of the participating node, historical contribution, or network topology location.

7. The method for cross-domain training and privacy protection of AI models integrating blockchain and homomorphic encryption as described in claim 1, characterized in that, The aggregation node in S4 is a member of the aggregation committee dynamically elected by on-chain smart contracts in each training round.

8. The method for cross-domain training and privacy protection of AI models integrating blockchain and homomorphic encryption as described in claim 1, characterized in that, The step of uploading the signed evaluation result to the blockchain after evaluating the model performance locally in S5 specifically includes: each participating node performing the evaluation locally according to the unified evaluation protocol predefined on the blockchain. Generate and submit verifiable evaluation proofs, which are implemented based on remote proofs or zero-knowledge proofs generated in a trusted execution environment.

9. The method for cross-domain training and privacy protection of AI models integrating blockchain and homomorphic encryption as described in claim 1, characterized in that, The automatic incentive distribution based on the evaluation results in S5 specifically includes: the smart contract calculating the contribution score of each participating node based on the evaluation results, historical contribution records, and compliance verification results submitted by each participating node; Reward tokens are automatically allocated from the incentive pool based on the relative contribution ratio of each participating node.

10. The method for cross-domain training and privacy protection of AI models integrating blockchain and homomorphic encryption according to claim 1, characterized in that, The addition of new nodes as described in S7 specifically includes: after a new node completes on-chain registration and staking, it needs to go through a probationary period; during the probationary period, its model update weight is restricted and it will not be selected as an aggregation node; after the probationary period ends, if its behavior meets the requirements, the smart contract will automatically upgrade it to a formal node with full permissions.

Images