A verifiable heterogeneous federated learning system based on zero-knowledge proofs

Abstract

This invention discloses a verifiable heterogeneous federated learning system based on zero-knowledge proofs, primarily addressing the problems of insufficient transparency, lack of verifiability, and vulnerability to data poisoning attacks in existing heterogeneous federated learning systems. The system consists of multiple client devices with different computing capabilities, data distributions, and model architectures, and a blockchain verification platform. The client devices are responsible for local model training, model conversion to the standard ONNX format, generating proofs using zero-knowledge proof tools, and submitting model updates and proofs to the blockchain verification platform. The blockchain verification platform is responsible for verifying zero-knowledge proofs, recording model updates, constructing a global model, and ensuring its verifiability and transparency. This invention effectively protects client data privacy, enhances the credibility of the training process, ensures the verifiability of the global model, provides an enhanced path for decentralized heterogeneous federated learning, and expands new directions for the development of trusted federated learning.

Description

Technical Field

[0001] This invention relates to the fields of federated learning and blockchain technology, and in particular to a verifiable heterogeneous federated learning system based on zero-knowledge proofs. Background Technology

[0002] With the development of artificial intelligence technology, data privacy and security issues have become increasingly prominent. Federated learning, as a machine learning method that protects data privacy, allows multiple clients to collaboratively train models without sharing the original data. However, traditional federated learning methods typically rely on a unified global model architecture, making it difficult to adapt to differences in computing power, data distribution, and model design requirements among different clients. Heterogeneous Federated Learning (HFL) has emerged to address this, allowing each client to autonomously design and train its own local private model based on its own conditions. While HFL improves the flexibility and adaptability of the system, it also introduces new security and privacy challenges, such as model tampering, adversarial attacks, and interference from malicious clients. Furthermore, existing privacy protection methods, such as differential privacy and homomorphic encryption, mainly focus on preventing the leakage of original data, offering limited support for the verifiability of the computation process and results, and are insufficient to effectively prevent attacks from malicious nodes. Summary of the Invention

[0003] The purpose of this invention is to provide a verifiable heterogeneous federated learning system based on zero-knowledge proofs to solve the problems of insufficient transparency, lack of verifiability, and vulnerability to data poisoning attacks in existing heterogeneous federated learning systems. Attached Figure Description

[0004] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0005] Figure 1 The system architecture diagram provided for this invention;

[0006] Figure 2 The flowchart of "model export - circuit compilation - proof generation - on-chain verification" provided by this invention;

[0007] Figure 3 A comparison chart of the generation times of pk.key and vk.key provided by this invention;

[0008] Figure 4 A comparison chart of proof generation time and total generation time provided by this invention. Detailed Implementation

[0009] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0010] To better understand, this embodiment explains the prerequisite knowledge.

[0011] Traditional federated learning (FL) typically relies on a unified global model, requiring all participants to follow the same model architecture for local training and global updates. However, in practical applications, participants generally differ in terms of computing power, data distribution, and model design requirements, making it difficult for a unified model architecture to meet the actual needs of all nodes.

[0012] Heterogeneous Federated Learning (HFL), as an important development direction of federated learning, has emerged. HFL allows each client to independently design and train its own local private model based on its data characteristics, computing power, and business objectives, thereby significantly improving the adaptability and flexibility of federated learning in complex environments. Currently, HFL has shown broad application prospects in real-world scenarios with high requirements for heterogeneity, such as smart healthcare, the Internet of Things, and financial risk control.

[0013] While heterogeneous federated learning offers significant advantages in enhancing system flexibility, it also introduces numerous new security and privacy challenges.

[0014] First, due to the diverse client model architectures, existing security verification and consistency assurance mechanisms based on unified model assumptions are difficult to directly transfer, leaving the system vulnerable to security risks such as model tampering, adversarial attacks, and malicious client interference. Second, the heterogeneous model structure renders traditional privacy protection methods based on parameter or gradient aggregation inapplicable, further exacerbating the risk of data privacy leaks. Furthermore, under the HFL framework, the federated system no longer maintains a unified global model; instead, multiple heterogeneous models collaborate to form a federated whole. This characteristic significantly increases the complexity of model credibility verification in a distributed environment, necessitating effective mechanisms to ensure the reliability and verifiability of the computational results from each heterogeneous model, thereby preventing potential threats to system stability.

[0015] In recent years, researchers have proposed a series of innovative methods to address the privacy and security challenges in heterogeneous federated learning. For example, Yi et al. promoted knowledge fusion among clients by sharing a globally homogeneous feature extractor and designed an iterative training strategy to achieve effective exchange of global and local knowledge. Simultaneously, this method introduced trainable weight vectors to dynamically mix features to adapt to the heterogeneity of batch data from different clients, thereby improving the model's performance on local data. However, this approach did not specifically address the privacy protection of the model and data.

[0016] Alam et al. addressed the limitations of traditional homogeneous federated learning (HFL) in handling low-end devices and large-scale model training, as well as the irrationality of sub-model extraction mechanisms in existing HFL schemes, proposing a rolling sub-model extraction mechanism. This method alleviates the client drift problem caused by inconsistent model structures by uniformly training different parts of the global model. However, it still lacks systematic guarantees in terms of privacy protection and result verifiability.

[0017] To further enhance privacy protection capabilities, a decentralized proxy model training framework has been proposed in existing technologies. This framework employs the knowledge distillation paradigm from mutual learning, enabling the private model and the proxy model to co-optimize, and introduces a differential privacy mechanism during training to improve the privacy protection capabilities of the private model. However, this method still has shortcomings in verifiability and is difficult to effectively prevent attacks from malicious nodes. If some clients maliciously tamper with model updates or inject harmful information, it may pose a serious threat to the stability and reliability of the global model.

[0018] With the widespread deployment of federated learning in fields such as healthcare, finance, and the Internet of Things, verifiability and transparency issues have gradually attracted significant attention from both academia and industry. Although technologies such as differential privacy (DP), homomorphic encryption (HE), and secure multi-party computation (MPC) have been widely used to protect data privacy during training, these methods primarily focus on preventing the leakage of raw data. Their support for the verifiability of the computation process and results remains relatively limited, especially in terms of how to prevent malicious clients or servers from acting maliciously in a federated environment, where a systematic solution is still lacking.

[0019] To address this, academia has begun exploring the integration of zero-knowledge proof (ZKP) technology with machine learning to achieve verifiability of the reasoning and training processes without revealing the model and data. Among these efforts, the ZKML system pioneered an optimized zero-knowledge proof scheme for various neural networks such as CNN and GPT, achieving superior proof efficiency and adaptability through efficient encoding of complex operators like Softmax. Furthermore, Zero Knowledge Proofs for Verifiable Decentralized AI Pipelines further constructs a general ZKP framework, supporting scenarios such as data manipulation, memory access, and decision tree inference, significantly improving the verifiability of decentralized AI pipelines. For deep learning training, zkDL is the first to introduce ZKP into the training phase of neural networks, achieving verification of the training process for networks with millions of parameters by optimizing the circuit representation of forward and backward propagation, effectively alleviating the challenges of non-arithmic operations in zero-knowledge circuit design. To address the complexity of large models (such as large language models LLM), zkLLM proposes the tlookup and zkAttn protocols specifically for attention mechanisms and nonlinear operations, which provide efficient zero-knowledge proof support for high-order operations such as Softmax and normalization, and provide a feasible verification path for complex neural network inference.

[0020] While the aforementioned research has greatly advanced the verifiability of combining ZK and machine learning techniques in the inference and training processes of homogeneous models, current solutions generally assume a uniform model structure and are primarily geared towards single-model inference or training tasks. They have not fully considered the new challenges arising from the differences in participant model architectures and personalized data distributions in heterogeneous federated learning environments. In particular, how to ensure the authenticity, legitimacy, and tamper resistance of the federated training process while supporting clients' autonomous selection of private models remains a key scientific problem that urgently needs to be addressed.

[0021] To address this issue, zkFL (Zero-Knowledge Federated Learning), as an existing approach, proposes a federated gradient aggregation scheme based on zero-knowledge proofs. By having the aggregator generate zero-knowledge proofs, it ensures honest completion of the aggregation operation without revealing the client's plaintext gradients, and further reduces verification costs using blockchain. However, zkFL still follows the traditional isomorphic federated learning paradigm, providing computational verifiability only during the aggregation phase, and does not cover the needs for private model updates, decentralized collaboration, and globally traceable verification in heterogeneous model scenarios. Therefore, addressing the shortcomings of existing heterogeneous federated learning methods in terms of privacy protection and verifiability, this paper, based on the decentralized proxy model framework proposed by Kalra et al., introduces a zero-knowledge proof mechanism and proposes a zero-knowledge proof-based decentralized proxy model heterogeneous federated learning scheme (Verifiable Proxied Federated Learning, VPFL). This scheme not only inherits the advantages of proxy model collaborative optimization and differential privacy mechanisms, but also further enhances the transparency, auditability, and computational correctness of the model training process at the system architecture level, thereby more effectively preventing security risks such as malicious clients tampering with the model and injecting harmful information.

[0022] Unlike traditional federated learning methods that rely on centralized servers to coordinate the training process, VPFL employs a fully decentralized system design, significantly reducing dependence on central nodes and improving the system's robustness and scalability. Meanwhile, to address trust issues in a decentralized environment, this paper verifies the correctness of each round of proxy model computation. This ensures that each client can achieve reliable cross-client knowledge sharing and aggregation while maintaining its local private model structure, guaranteeing the system's training efficiency and security in heterogeneous environments.

[0023] In summary, the VPFL framework proposed in this paper not only achieves higher security in terms of privacy protection, but also systematically solves the trustworthiness problem in heterogeneous federated learning from a verifiability perspective for the first time, which has important reference value in both theoretical research and practical applications. The main contributions of this scheme include the following three aspects:

[0024] 1. Blockchain-driven trusted federated learning architecture:

[0025] To address the reliability issues arising from the lack of trust mechanisms in federated learning, this paper introduces blockchain as a global verification and storage platform, enabling verifiable model updates among heterogeneous clients. The system constructs an off-chain verification process for the correctness of model computations and the validity of parameter updates, and completes the registration, verification, and recording of update results through on-chain smart contracts. This ensures the integrity, transparency, and traceability of the entire training process without relying on a centralized, trusted third party.

[0026] The blockchain's functions include zero-knowledge proof verification and model update hash storage, effectively decoupling computation and storage, reducing system complexity and on-chain resource consumption. This mechanism ensures that: proxy model updates originate from legitimate computation processes, preventing malicious nodes from forging parameters; the federated training process has strong auditability and tamper resistance; and it adopts a loosely coupled architecture of "off-chain generation and on-chain verification," significantly reducing on-chain computational load and improving overall system efficiency.

[0027] 2. Zero-knowledge proof-driven proxy model: off-chain computation and on-chain verification mechanism.

[0028] To enhance the security and verifiability of federated learning systems in decentralized environments, this paper introduces Zero-Knowledge Proof (ZKP) technology to construct a mechanism for verifying the correctness of model updates. Specifically, in each training round, each client trains a proxy model through a differential privacy mutual learning mechanism for transmission in decentralized federated learning. Then, a ZK proof of the correctness of each round of proxy model updates is generated off-chain to ensure that the model parameters in the decentralized training environment have not been tampered with and originate from legitimate computation processes. This mechanism verifies the correctness of the proxy model parameter calculations by verifying public auxiliary data and submits the generated proof to the blockchain for verification by a smart contract. This ensures that each model update is auditable and traceable, effectively preventing malicious nodes from submitting false parameters or disrupting the federated training process.

[0029] 3. Incremental zero-knowledge proof aggregation mechanism

[0030] To address the computational and storage resource bottlenecks brought about by federated learning during multi-round training, this paper proposes an incremental zero-knowledge proof aggregation mechanism: each round of training recursively generates new proofs based only on the previous round's proof and the current inference result; it supports the aggregation and compression of multi-round training proofs, generating smaller and faster composite global proofs.

[0031] This approach significantly reduces on-chain verification complexity and storage overhead; maintains the continuity and traceability of multi-round training states; and improves system scalability and practical deployment feasibility in large-scale heterogeneous device environments (such as mobile edge computing and IoT nodes).

[0032] To support the blockchain-based trusted federated learning framework proposed in this paper, this section briefly introduces several key cryptographic and privacy protection technologies involved, including zero-knowledge proofs, KZG commitment mechanisms, incremental verifiable computation, and differential privacy. These technologies collectively construct the foundational capabilities for secure verification, integrity assurance, and privacy protection within the system.

[0033] 1. Zero-Knowledge Proof (ZKProof)

[0034] Zero-knowledge proofs are a class of cryptographic protocols that allow provers to demonstrate the correctness of a statement or computation result to verifiers without exposing their input data or computational details. ZKProof possesses three core attributes: completeness, reliability, and zero-knowledge, enabling highly reliable verification while ensuring privacy. In the federated learning framework constructed in this paper, ZKProof is used to verify the correctness of proxy model computations in a decentralized environment. This allows participating parties to verify the legitimacy of models submitted by other participants and the authenticity of their computation processes in a decentralized scenario without trusting each other, thereby effectively preventing forged updates and fraudulent training processes.

[0035] 2. Incremental Verifiable Computation (IVC)

[0036] Incremental Verifiable Computation (IVC) is a computational outsourcing mechanism that supports phased, multi-round verification. Unlike traditional single-round global verification methods, IVC allows verifiers to verify only the incremental results of each phase, thereby efficiently inferring the correctness of the entire computation process. This feature is particularly suitable for iterative, distributed training scenarios such as federated learning.

[0037] In the system design presented in this paper, IVC technology is used to construct a cross-round model state verification mechanism: each round of model computation generates a zero-knowledge proof (ZK Proof), and the hash value of the output of that round is used as the public input for the next round of verification, thus forming a recursive verification chain connected by hash commitments. Specifically, the system uses the sha2 library to perform hash digests on the output of each round of model inference, generating a chain-traceable state identifier.

[0038] 3. Differential Privacy (DP)

[0039] Differential privacy (DP) is a data privacy protection mechanism that introduces random noise into query or published results to ensure that changes in individual data samples do not significantly affect the output, thereby hiding the existence and attributes of individuals. DP provides strict mathematical privacy guarantees for individual data. In federated learning scenarios, noise is injected during training to prevent malicious aggregators from inferring user data from model parameters.

[0040] Given a privacy budget ∈, a randomized algorithm M satisfies ∈-differential privacy if, for any adjacent datasets D and D′, and any measurable set S, the probability of an event occurring is Pr:

[0041] Pr[M(D)∈S]≤e∈·Pr[M(D′)∈S]

[0042] In this system, differential privacy is primarily used to protect the updates of local model parameters. The introduction of differential privacy effectively prevents potential back-inference attacks, where attackers analyze uploaded parameter changes to infer privacy information from local data. Simultaneously, the system achieves a balance between privacy protection and model performance by appropriately adjusting noise levels.

[0043] 1. System Architecture Design

[0044] System Overall Architecture Overview

[0045] like Figure 1 As shown, the privacy-preserving knowledge collaboration system proposed in this paper consists of three parts: a federated learning training domain, a zero-knowledge proof factory, and a blockchain verification domain. The modules are decoupled through standardized interfaces to form a closed loop of "local training → proof generation → on-chain verification".

[0046] In the leftmost federated learning training layer, each participant instantiates four independent but sequentially invoked logic layers. From the outside in, they are:

[0047] User interface layer: responsible for presenting task options and privacy policies, and initiating subsequent training processes after receiving user instructions.

[0048] Proxy Model Layer: Acts as a "knowledge channel" for decentralized heterogeneous federated learning: Maps local predictions to a unified semantic space through differential privacy injection, enabling cross-model distillation and blocking reverse inference.

[0049] Private model layer: Supports user-defined model structures and utilizes a mutual learning mechanism to absorb feedback from proxy models; all forward / backward propagation is executed locally.

[0050] User storage layer: Persists raw data, model snapshots, and gradient logs in encrypted form, and only grants controlled read access to the local computing unit.

[0051] Miner Processing Layer: The blockchain system first elects a miner node for the current block based on the PoS consensus algorithm. This miner is responsible for aggregating and verifying the correctness proofs of the proxy model computation in this round. The elected miner then receives the ONNX computation graph and differential privacy model digest submitted by the client and performs an integrity pre-check off-chain to determine the legality and compliance of data and model updates. After completing the pre-check, the miner incrementally aggregates the zero-knowledge proofs generated from multiple rounds of proxy model computation and publishes a unified verification result on-chain, ensuring efficient verification and consistent state updates across multiple computation rounds.

[0052] Zero-knowledge proof layer: EZKL is called to compile the computation graph into a Halo2 constraint circuit, deriving the proof key pk and the verification key vk; pk is used to generate t-round cells to prove π. t and recursively fold it into existing commitments. Prove the increment of constant magnitude π t With the latest global commitment

[0053] Blockchain verification layer: Automatically deploys or reuses verification contracts embedded in VK, calling verify() to verify π. t Perform aggregate hash consistency and optional round-by-round verification; if verification is successful, the on-chain state is updated to... And record the event<roundID,modelHash,proofHash> If verification fails, the entire block will be rolled back.

[0054] 2. Heterogeneous Federated Learning Training Module

[0055] 1. Heterogeneous private model setting:

[0056] In the complex heterogeneous environment of federated learning, the i-th user node U i Based on local data D i Its unique characteristics allow for the customization of suitable training model structures. i (·;θ i This flexibility allows the system to be compatible with a variety of different model architectures, such as CNNs (Convolutional Neural Networks) which are good at processing image data, the classic image recognition model LeNet5, and the relatively simple multilayer perceptron (MLP) which performs well in some basic tasks.

[0057] The training of the local model aims to continuously optimize the parameters θ i To minimize the model's loss on local data, the optimization objective function is:

[0058] In this formula, Indicated by parameter θ iTo optimize the variables, find the value θ that minimizes the objective function. i The value of . Represents the local data distribution D i Performing expectation calculations on the data distribution D means that the expected value is calculated from the data distribution D. i The statistical average is calculated from a randomly selected sample (x, y). L(f) i (x;θ i (),y) is the loss function, used to measure the model f i With parameter θ i When, the prediction result f for input x i (x;θ i The difference between the label y and the true label y. For example, the cross-entropy loss function, commonly used in classification tasks, is calculated using the following formula: Where K is the number of categories, y j f is the probability f that the sample truly belongs to class j. i (x;θ i ) j θ is the probability that the model predicts a sample belongs to the j-th class. This is achieved by continuously adjusting θ. i This minimizes the expectation of the loss function, thereby improving the model's performance on local data.

[0059] 2. Mutual learning mechanism:

[0060] To promote knowledge sharing and co-evolution among models in federated learning, this module introduces a mutual learning mechanism. Under this mechanism, each user node not only focuses on its own private model f, but also... i (·;θ i The training of the model also involves close interactive learning with the surrogate model g(x; φ), optimizing the local model through information sharing.

[0061] Specifically, nodes learn from each other by sharing updates to their local models, using the following loss function:

[0062]

[0063] in, This indicates a summation operation performed on all n nodes participating in federated learning. The local data distribution D at node i i The expected value is calculated to ensure that the loss calculation is based on the statistical characteristics of the local data. L1 and L2 are loss functions used to measure the difference between the surrogate model and the private model, respectively. Taking mean squared error as an example, for node i, L1(f i (x),g(x))=((f i )-g(x)) 2 ,L2(f i(x),g(x))=((f i )-g(x)) 2 Both methods measure the difference in prediction results between the two models from different perspectives. Through multiple rounds of interactive learning, the private model f is continuously adjusted. i (·;θ i The parameters of L and the surrogate model g(x; φ) make L mutual By gradually reducing the size of the two models, the performance of both models can be improved, promoting the effective flow and integration of knowledge between different models.

[0064] 3. Differential privacy protection embedding

[0065] To prevent the leakage of private information during model training, this module introduces differential privacy perturbations before model updates. Specifically, parameter perturbations can be implemented using Gaussian or Laplacian mechanisms.

[0066] Gaussian mechanism:

[0067] Gaussian mechanism formula: In this formula, These are the parameters after adding the perturbation, θ i These are the original model parameters. This indicates that the mean is 0 and the covariance is σ. 2 Gaussian noise of type I, where I is the identity matrix. By adding Gaussian noise to the original parameters, it becomes difficult for attackers to infer the original private information from the perturbed parameters, thus achieving privacy protection. For example, suppose the original parameters θ i It is a vector, θ i =[θ i1 ,θ i2 ,...,θ im Added Gaussian noise It is a relation to θ i A random vector of the same dimension, each element of which follows a sequence with mean 0 and variance σ. 2 The Gaussian distribution. Thus, the perturbed parameters... This hides the true value of the original parameters.

[0068] 3) Conversion and constraint implementation from surrogate model to zero-knowledge proof circuit

[0069] Within the federated learning framework, we designed an integrated pipeline of "model export - circuit compilation - proof generation - on-chain verification," using ezkl as the core bridge to securely and cost-effectively publish the inference results of local heterogeneous neural networks to the blockchain. First, the client converts the trained model into an ONNX graph. ezkl then uses low-order Halo2 primitives (cumulative dot product, cumulative sum / product, element-wise and lookup gates) to automatically map this graph into a zero-knowledge circuit, generating a verification key (vk) bound only to the circuit structure and a proof key (pk) stored locally through the setup process. Subsequently, the client constructs witnesses by combining private weights and inference inputs, calls prove to obtain a zero-knowledge proof (π), and optionally recursively aggregates multiple πs into a constant-size aggregate proof (Π*), further reducing on-chain overhead.

[0070] ezkl also automatically generates EVM / Move verification contracts embedded with VK. After uploading the contract, proof, and public inputs (model hashes, input commitments, etc.), only one verify() is needed on-chain to confirm: ① the inference executes according to the predetermined circuit, ② private weights and data are not leaked, and ③ the result is consistent with the claim. This process encapsulates local models of arbitrary structures into composable, trustworthy black boxes, solving the pain points of untrustworthiness, privacy leakage, and high gas costs associated with traditional inference outsourcing. It provides an efficient, verifiable, and on-chain-friendly implementation path for heterogeneous federated learning.

[0071] During federated learning, this system utilizes a proxy model to achieve knowledge fusion and privacy protection between heterogeneous models. To enable efficient and reliable verification of the proxy model on the blockchain, we introduce a zero-knowledge proof (zk-SNARK) compilation mechanism based on the ONNX computation graph. Specifically, this mechanism converts various operators and activation functions of the proxy model into corresponding Halo2 constraints to form an efficient verification circuit.

[0072] 3.1 ONNX Intermediate Representation and Computation Graph Compilation

[0073] The Open Neural Network Exchange (ONNX) format, as a standardized intermediate representation across frameworks, provides a formal foundation for the transformation of surrogate models into zero-knowledge circuits. ONNX defines the model structure using a Directed Acyclic Graph (DAG), where nodes represent specific operators (such as convolution, matrix multiplication, and nonlinear activation functions), and edges represent tensor data flows. Its key components include:

[0074] Graph (computation graph): The topological structure of operators, which clarifies the data dependencies between nodes.

[0075] Operator Set: A versioned semantic definition of operators to ensure consistency in cross-framework reasoning.

[0076] Initializer (Static Weights): Pre-stored static weight parameters of the model, making it easy to embed directly into ONNX files.

[0077] Metadata: Records the dynamic dimensions, node names, and quantization information of the model's input and output.

[0078] Due to ONNX's advantages of frame independence and static resolvability, ezkl can statically parse the ONNX graph structure without a runtime environment and automatically map the model's computational logic precisely to Halo2 circuit constraints. Therefore, this system, based on ONNX, implements the formal automatic compilation of surrogate models into zero-knowledge proof circuits.

[0079] 3.2 Implementation of Zero-Knowledge Constraints for Linear Operators in the Proxy Model

[0080] The fully connected layers and convolutional layers commonly used in surrogate models can be mathematically represented as follows:

[0081] z = Wx + b

[0082] Where W is the weight matrix, x is the input vector, and b is the bias term. In zero-knowledge proof circuits, the dot product operation can be implemented using a cumulative dot product constraint. Specifically, each input is multiplied by its corresponding weight and summed, then the bias term is added. This constraint can be expressed by the following formula:

[0083]

[0084] Among them: W ji These are elements of the weight matrix W; x i b are elements of the input vector x; j It is a bias term.

[0085] Non-linear activation functions (such as Softmax and Sigmoid) are widely used in surrogate models. Taking the Softmax function as an example, its output... It can be calculated using the following formula:

[0086]

[0087] Where: z j It is the j-th element (logit) in the input vector; K is the number of categories.

[0088] To efficiently implement this function in the circuit, we employ a Cumulative Sum Constraint and an Exponent Constraint. Specifically, the circuit first calculates the exponent value element-wise on the input vector, then normalizes the exponent value using the Cumulative Sum Constraint, thereby obtaining the correct Softmax output. Through these constraints, the circuit verifies the correct execution of the Softmax function while ensuring the privacy of the input data is not compromised.

[0089] Element-wise operations (such as ReLU, addition, and multiplication) are fundamental and frequently used operation types in surrogate models. For example, the ReLU function is defined as:

[0090] ReLU(x) = max(0, x)

[0091] To achieve this nonlinear operation, ezkl uses lookup tables (LUTs) for efficient computation. The circuit does not need to explicitly calculate the nonlinear formula, but directly maps the input values ​​to a predefined discrete lookup table to obtain the output, thereby ensuring efficient processing of privacy data.

[0092] Element-wise addition and multiplication can be directly implemented using linear constraints:

[0093] z = x + y

[0094] The formula for multiplication is:

[0095] z = x·y

[0096] These constraints efficiently simulate conventional element-wise operations in the surrogate model, resulting in a compact circuit structure that is easy to verify efficiently. 4.3.3 Implementation of Lookup Arguments for Nonlinear Functions in the Surrogate Model

[0097] When converting surrogate models to zero-knowledge proofs, certain complex nonlinear functions (such as Sigmoid and Tanh) are difficult to directly map to simple circuit logic. Therefore, we use a pre-computed lookup table (LUT) to efficiently approximate these functions.

[0098] Lookup tables (LUTs) accelerate function evaluation by pre-compiling and storing the discrete values ​​of a function. This technique allows systems to be proven to efficiently handle nonlinear functions without performing complex real-time computations.

[0099] Suppose the function f: D → R is a nonlinear function that we need to calculate in the circuit, with its domain D and range R. The lookup table can be represented as a mapping set: T = {(x, f(x) | x ∈ D')}. It is a discretized subset of the domain. For input x∈D, we find the nearest discrete point x'∈D', and then use f(x') as an approximation of f(x).

[0100] To improve circuit processing efficiency, when the function's value range is large, the original lookup table T is split into n disjoint sub-tables:

[0101]

[0102] This formula represents splitting the original lookup table T into n disjoint sub-tables Ti, and recovering the original lookup table T by merging these sub-tables. Specifically, T is the union of all sub-tables Ti, and each sub-table Ti has no intersection with any other sub-table Tj, i.e., their intersection is an empty set. In this way, each of the split sub-tables contains a part of the original lookup table, and the sub-tables do not overlap with each other.

[0103] To efficiently locate the corresponding sub-table in the circuit, a selector polynomial is introduced:

[0104]

[0105] Its properties: S i (i)=1 and S i (j) = 0. The proof only requires multiplying the lookup pairs by the corresponding pairs to complete multi-table matching within a single gate. During circuit verification, the inputs are categorized through polynomial products of the corresponding selectors to ensure fast table lookup verification.

[0106] To protect input and output privacy, we employ a security mechanism based on polynomial commitment. For table T, we define the polynomial as follows:

[0107]

[0108] Here, || denotes the concatenation operation. If (x,y)∈T, the prover only needs to prove p(x||y)=0, without revealing the specific values ​​of x or y, thus protecting the privacy of input and output. p(X) is a product function, where each term of the product is X minus each pair (x,y) i ,y i x in ) i and y i Combinations; (x i ,y i ) belongs to set T, representing all x i and the corresponding y i The difference. In this way, the table lookup constraint ensures both computational efficiency and maintains the privacy characteristics of zero-knowledge proofs.

[0109] In summary, through the above-mentioned constraint construction and circuit transformation methods, this system efficiently maps the neural network computation logic of the proxy model to the zero-knowledge proof circuit, thereby achieving efficient and privacy-preserving on-chain trusted verification for cross-framework heterogeneous federated learning.

[0110] 4. Multi-round proof aggregation and verification framework

[0111] To ensure the credibility and transparency of multi-round interactive computation scenarios such as federated learning or continuous reasoning, this solution proposes a zero-knowledge proof generation, aggregation, and on-chain verification framework led by blockchain miners. The validity of each round of computation is generated by miners using predefined zero-knowledge proof circuits to create independent proofs, which are then aggregated and finally recorded on the blockchain for public auditing and verification by users participating in federated learning or other stakeholders.

[0112] Specifically, for any round t (1≤t≤T), the calculation is defined as follows: the secret input (Witness) is w. t Public input or status is x t Public output or status update to y t .

[0113] Miners generate a proof of the validity of the t-th round of computation off-chain using the corresponding zero-knowledge proof circuit C and configuration parameters cfg: π t =GenerateProof(C,cfg,w) t x t y t )

[0114] To facilitate on-chain storage and retrieval, each round of generated proofs will generate a corresponding metadata structure (meta). t :

[0115] meta t ={iteration: t, circuit_params: cfg, proof_bytes: π t proof_hash: h t}

[0116] Among them, prove hash h t Calculated by miners using the Keccak256 algorithm:

[0117] h t =Keccak256(π) t )

[0118] After completing all T rounds of computation and proof generation, the miners use multiple hash values ​​h1, h2, ..., h TThe hashes are concatenated (the symbol || denotes concatenation), and then the SHA-256 hash function is applied to the concatenated result to generate the final aggregate hash value H. agg :

[0119] H agg =SHA256(h1||h2||…||h T )

[0120] This leads to the final aggregate proof structure:

[0121] Π agg ={total_proofs:T,proofs:[meta1, meta2,...meta T ], aggregation_hash: H agg}

[0122] The miners will then aggregate the proof structure π. agg Submitted as a trusted record to the blockchain for users to query.

[0123] 5. On-chain verification data encapsulation for aggregated proofs

[0124] To submit aggregate verification requests to the blockchain, we designed the following call data structure:

[0125] Args = {aggregation_hash: H} agg , total_iterationsT, proof_elements: [elem1, elem2, ..., elem T ], timestamp: ts}

[0126] The key element summary for each round is defined as follows:

[0127] elem t ={iteration: t, params: cfg, hash: h t The `calldata` function is obtained through the on-chain smart contract interface function `verify`.

[0128] CD={contract: "Verifier", method: "verify", args: [Args]}

[0129] The final on-chain call data is as follows:

[0130] calldata = encode(CD)

[0131] The data submitted by miners contains all the key information required for verification, facilitating the automatic execution of the aggregated verification process by the on-chain contract. 4.6 Blockchain Verification Module: Public Auditability of Miner Submissions and On-Chain Proofs

[0132] The blockchain verification module aims to ensure the strict credibility and immutability of aggregated proof records submitted by miners through an on-chain consensus mechanism, while providing a transparent and traceable audit interface to federated learning participants. This module combines zero-knowledge proof technology with the blockchain consensus mechanism to form a highly efficient and reliable multi-round computation process verification scheme.

[0133] The specific verification process is described below:

[0134] (1) Miner's on-chain proof submission record

[0135] Miners encode the aggregation proof structure as π agg The call data of a blockchain smart contract is used to construct transaction T and submit it to the blockchain network:

[0136]

[0137] Where τ represents the Unix timestamp when the aggregate proof is submitted.

[0138] (2) On-chain contract verification logic

[0139] During the consensus process, blockchain network validator nodes rigorously verify the data submitted by miners by executing verification functions within smart contracts. The on-chain contract execution logic includes the following steps:

[0140] Aggregate hash consistency check:

[0141] The verification node recalculates the aggregate hash H ′ agg And verify the aggregate hash H submitted by the miner. agg Consistency:

[0142] H′ agg =SHA256(h1||h2||…||h T )

[0143] The above formula must satisfy H ′ agg =H agg .

[0144] Verification of quantity consistency:

[0145] The contract must ensure that the number of proof elements submitted by the miners exactly matches the number of rounds declared:

[0146]

[0147] Zero-knowledge proof authenticity verification:

[0148] In a real-world deployment environment, smart contracts can further invoke or be embedded in on-chain zero-knowledge proof verifiers to verify the validity of each proof round by round:

[0149]

[0150] If all the above verification logic passes, the contract state is updated and the aggregated proof record is accepted; if any one fails, the contract rejects the transaction and rolls back all state changes.

[0151] (4) Proof of public records and user auditing mechanisms

[0152] Successfully verified aggregated proof data will be recorded on the blockchain as a blockchain event or in persistent storage, ensuring subsequent public access and auditability.

[0153] Federated learning participants can query the aggregate hash H in real time via a blockchain explorer or a public on-chain interface. agg Single-round proof hash h t Including corresponding round numbers, submission timestamps, and other metadata information, to ensure the audit process is open and transparent.

[0154] Users can independently recalculate and verify the consistency between the off-chain proof hashes and the aggregate hashes locally, without accessing or exposing sensitive raw data, to verify the credibility and effectiveness of the off-chain computation process.

[0155] The following is a specific example of on-chain event logging: emit VerificationRecorded(H agg (T, τ)

[0156] In summary, this module achieves the dual goals of privacy protection and process trustworthiness through efficient aggregation of off-chain zero-knowledge proofs and on-chain consensus verification, meeting the stringent requirements for auditing the computation process in federated learning and similar scenarios.

[0157] 5. Experiment

[0158] This experiment focuses on improving the privacy and efficiency of federated learning models using zero-knowledge proofs (zk-SNARK) and incremental zk aggregation techniques. The experimental framework employs a decentralized ProxyFL (proxy federated learning) architecture, combined with differential privacy techniques for training. We validated the model on the classic MNIST and Fashion-MNIST datasets, testing the effectiveness of different algorithms and model architectures, and ensuring data privacy and the security of the validation process through zk-SNARK proof techniques.

[0159] 5.1 Experimental Architecture and Dataset

[0160] The experiment employed a decentralized ProxyFL architecture, designed for decentralized model training on the client side while using a proxy model for global model aggregation. Within this framework, clients train using local data, and privacy is protected through differential privacy techniques. Global model updates are handled by the proxy model, ensuring data privacy is not compromised during training. In each training round, each client trains its model using local data, and the training set is divided into K equal-sized subsets and distributed among the K clients.

[0161] The experimental datasets include: MNIST dataset: 28x28 pixel grayscale images containing 10 digit categories, with the task of classifying digits in the images. Fashion-MNIST dataset: also containing 28x28 pixel grayscale images with 10 categories, with the task of identifying clothing categories in the images.

[0162] 5.2 Experimental Setup and Differential Privacy Configuration

[0163] Experimental configuration and differential privacy mechanism settings

[0164] To evaluate the performance of the proposed method under different configurations, the experiment systematically set multiple parameter combinations while adhering to the differential privacy principle. The specific configurations are as follows:

[0165] Differential privacy parameter settings:

[0166] All training employed the Differential Privacy Stochastic Gradient Descent (DP-SGD) optimizer. During training, the following key parameters were set to ensure privacy protection: the noise multiplier σ was set to 1.0; the gradient clipping threshold C was set to 1.0; and each training round used mini-batch sampling from the dataset, with random sampling with replacement, where each sample was selected with a fixed probability to ensure compliance with the assumptions of differential privacy budget calculation.

[0167] Client quantity setting:

[0168] To simulate distributed training scenarios in various federated learning environments, four clients were set up in the experiment. All clients were peer entities in structure, adopting a decentralized ProxyFL (proxy model federated learning) architecture. That is, the clients do not rely on a central server for model synchronization, but instead cooperate in learning by exchanging proxy models.

[0169] Data volume per client:

[0170] Each client was assigned 1000 samples, with no overlap between different clients, to construct a more challenging non-independent, identically distributed (non-IID) data environment. Data allocation followed a random sampling mechanism to ensure the robustness and reproducibility of the experimental results.

[0171] Number of training rounds:

[0172] To observe the convergence and performance stability of the model under different training epochs, the experiment used four training epoch configurations: 50 epochs, 100 epochs, 200 epochs, and 300 epochs. In each training epoch, each client performs a local training cycle (local epoch) on its private data, and then shares knowledge with other clients through the proxy model.

[0173] 5.3 Zero-knowledge proofs and incremental zk aggregation

[0174] To further improve privacy protection and efficiency, we introduce the zero-knowledge concise non-interactive argument (zk-SNARK) technique to verify the correctness of models without exposing any data. zk-SNARK allows us to verify the validity of data processing procedures and computation results without revealing sensitive data.

[0175] like Figure 3 As shown in the figure, this graph illustrates the time required to generate the public key (pk.key) and verification key (vk.key) under different client training data volumes. The horizontal axis represents the client training data volume in the number of samples (50, 100, 200, 300), and the vertical axis represents the generation time in seconds.

[0176] Generation time analysis:

[0177] pk.key generation time: The generation time of pk.key gradually increases with the amount of data. It increases from approximately 112 seconds with 50 samples to nearly 6000 seconds with 300 samples. vk.key generation time: Compared to pk.key, vk.key has a relatively shorter generation time, but it also shows an increasing trend with the amount of data. For 300 samples, the generation time of vk.key is approximately 3900 seconds.

[0178] Trend line analysis:

[0179] The blue dashed line in the graph represents the generation time of pk.key, showing that the generation time increases exponentially with the number of samples. The orange dashed line represents the generation time of vk.key; although its growth rate is not as fast as pk.key, it also shows an increasing trend, especially when the data volume reaches 300 samples. Figure 4As shown in the figure, this graph illustrates the changes in zk-SNARK proof generation time and total generation time under different client training data volumes. The horizontal axis represents the client training data volume, and the vertical axis represents the generation time, in seconds.

[0180] Generation time analysis:

[0181] Proof generation time: As the amount of data increases, the time to generate the proof also increases significantly. With 50 samples, the proof generation time is 231 seconds, while with 300 samples, this time increases to 2257 seconds, a significant increase. Total generation time: The total generation time includes proof generation and other computational operations. As the amount of data increases, the increase in total generation time is even more significant, approximately 934 seconds with 50 samples, and reaching nearly 18000 seconds with 300 samples.

[0182] Trend line analysis:

[0183] The green dashed line in the graph represents the proof generation time, showing that the proof generation time increases with a relatively linear trend as the amount of training data increases. The red dashed line represents the total generation time, which shows a much steeper growth trend, especially when the amount of data reaches 200 and 300, the growth rate accelerates.

[0184] Analysis based on experimental results:

[0185] These charts demonstrate that:

[0186] As the amount of training data on the client increases, the time required to generate keys and proofs both increase exponentially, especially the time required to generate the public key (pk.key).

[0187] The increase in total generation time is not only due to proof generation, but also affected by other computational processes (such as key generation), especially when the amount of data is large, the increase in total generation time is more obvious.

[0188] 5.4 Incremental Aggregation and Minimal On-Chain Storage Strategy for Zero-Knowledge Proofs

[0189] To further improve the on-chain resource utilization efficiency of blockchain federated learning systems in large-scale, multi-round reasoning and verification scenarios, this study proposes and implements an incremental zero-knowledge proof aggregation mechanism (Incremental ZKAggregation). Unlike the traditional mode of verifying each round of computation separately on-chain, this mechanism recursively aggregates zero-knowledge proofs from multiple consecutive rounds off-chain, ultimately generating a unified, constant-size aggregated proof. This achieves "one-call completion of multiple rounds of verification" on-chain, significantly reducing on-chain overhead.

[0190] Implementation Mechanism and Optimization Strategy

[0191] Specifically, after each federated learning agent node completes each round of inference locally, it uses its private input and model to generate the corresponding unit zk proof of π. t The system then uses an off-chain Halo2 recursive circuit to input the cell proof of the current round and the aggregate commitment of the previous round. Generate higher-order aggregation proofs through round-by-round recursion With the latest global commitment After multiple iterations, the system can eventually complete all multi-round inference verification on the chain in one go by deploying a unified verification contract (IEZKLVerifier) ​​once and calling the contract's unique interface function processProof() to submit the generated final recursive aggregate proof and public input file.

[0192] Resource optimization and gas consumption assessment

[0193] To intuitively quantify the optimization effect of incremental ZK aggregation on on-chain resources, we systematically measured the smart contract verification process in a local Hardhat-EVM environment.

[0194] In benchmark tests, verifying only one round of zk-SNARK proofs incurred a transaction cost of approximately 561,901 gas. This value was subsequently used as the unit cost of the "traditional round-by-round verification" scheme to extrapolate the cumulative cost across multiple rounds.

[0195] remember:

[0196] G single =5.61901×10 5 gas

[0197] The cumulative cost of the traditional solution during N rounds of verification is:

[0198] G tard (N)=N·G single ·

[0199] Optimized Aggregation Proof On-chain verification only requires

[0200] G agg =4.6532×10 4 gas

[0201] This value is independent of the training rounds N.

[0202] Training rounds (N) <![CDATA[Traditional verification G grad > <![CDATA[Incremental Aggregation Verification G agg > Reduction ratio 50 <![CDATA[2.81×10 7 gas]]> <![CDATA[1.20×10 5 gas]]> 99.57％ 100 <![CDATA[5.62×10 7 gas]]> <![CDATA[2.77×10 5 gas]]> 99.51％ 200 <![CDATA[1.12×10 8 gas]]> <![CDATA[1.30×10 6 gas]]> 98.84％ 300 <![CDATA[1.69×10 8 gas]]> <![CDATA[4.86×10 6 gas]]> 97.13％

[0203] From formula G grad With G aggIt can be seen that the on-chain gas consumption of traditional round-by-round verification is a linear function of the number of training rounds N. trad ∈θ(N), while the cost of incremental aggregation verification is a constant G. agg ∈θ(1).

[0204] When N = 300, we have

[0205]

[0206] This incremental aggregation verification scheme reduces on-chain gas costs by more than three times. In high-frequency inference or long-term online training scenarios, incremental aggregation verification can significantly suppress the cumulative explosion of costs at the blockchain level.

[0207] Traditional methods require uploading N single-round proofs. If each proof is gzip compressed, it still requires approximately 25kB. Therefore, when N=300, the on-chain calldata size is approximately 7.3MB, generating 300 transaction broadcasts, which places a significant burden on the on-chain state and the P2P network.

[0208] In contrast, the incremental aggregation verification scheme only uploads one aggregation proof of approximately 20kB in size, reducing its on-chain storage and network propagation traffic to that of traditional schemes.

[0209]

[0210] Under the current 30M gas block limit on the Ethereum mainnet, the 4.86 million gas consumed by incremental aggregation verification transactions accounts for only 16.2%.

[0211] This means that even if gas prices surge or blocks approach saturation, aggregated verification transactions can still be easily included with negligible disturbance to baseFeePerGas. In contrast, traditional solutions significantly increase baseFee when hundreds of verification transactions are submitted in a short period, leading to user cost spillover and block congestion risks.

[0212] Based on a unit price of 20G Weigas and a current ETH price of 1800USD: the cost of a traditional 300-round run is 1.69 × 10 8 Gas) × 20 Gwei ≈ 0.337 ETH (~606 USD). Incremental aggregation verification scheme (20.56 × 10 4 The cost is approximately 0.00972 ETH (~17.50 USD) for gas × 20 Gwei. This represents a saving of over 97.13% in on-chain transaction costs. Considering that on-chain execution costs are approximately proportional to energy consumption, the incremental aggregation verification scheme also significantly reduces carbon emissions, providing practical evidence for sustainable blockchain computing.

[0213] Based on the above experiments and analysis, the following conclusions can be drawn: The incremental aggregation verification scheme exhibits a significant advantage in terms of on-chain resource consumption, which becomes more pronounced with the increase of training rounds, demonstrating good scalability; on-chain storage and network bandwidth costs are reduced to less than 1% of traditional schemes, greatly alleviating the pressure on on-chain data storage and network propagation; transaction packaging efficiency and block carrying capacity are significantly improved, making it easier for miners to accept and incorporate in the mainnet environment; it has a high advantage in terms of economic cost and environmental benefits, and will significantly reduce economic costs and environmental burden in large-scale application environments.

[0214] In conclusion, the incremental aggregation verification scheme not only demonstrates significant optimization effects in theory, but also shows strong engineering applicability and economic rationality in practical blockchain scenarios, providing a feasible implementation path and theoretical support for the integrated application of blockchain and AI.

[0215] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0216] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0217] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0218] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0219] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A verifiable heterogeneous federated learning system based on zero-knowledge proofs, characterized in that, include: Multiple client devices, each with different computing power, data distribution, and model architecture; A blockchain verification platform for recording and verifying model updates and computation processes during federated learning; Each client device performs the following steps: Local training: Training is performed based on local data and a private model architecture to generate model updates; Model conversion: Convert local models to standard ONNX format; Zero-knowledge proof generation: The ONNX format model is converted into a verifiable circuit using a zero-knowledge proof tool, and zero-knowledge proofs are generated to prove the correctness and legality of the model update. Model Update Submission: Submit the model update and zero-knowledge proof to the blockchain verification platform; The blockchain verification platform performs the following steps: Proof verification: Verify the zero-knowledge proof submitted by the client to ensure the authenticity of the model update and that it has not been tampered with; Model update record: If the verification is successful, the model update will be recorded on the blockchain, forming part of the global model; Global model building: Aggregate model updates from multiple clients, build a global model, and ensure the verifiability and transparency of the global model; The zero-knowledge proof tool uses the EZKL zero-knowledge proof system, and the specific steps include: Convert the client's local model to ONNX format; The ONNX format model was compiled into a Halo2 constrained circuit using the EZKL tool; The constraint circuit generates the verification key and the proof key; The model update process is proven using a proof key, generating zero-knowledge proofs; Submit the generated zero-knowledge proof to the blockchain verification platform; The blockchain verification platform uses verification keys to verify zero-knowledge proofs, ensuring the authenticity and legitimacy of model updates; The blockchain verification platform uses smart contracts to automatically execute verification logic, specifically including: Aggregate hash consistency check: Verifies whether the aggregate hash submitted by the client is consistent with the hash recorded on the blockchain; Proof quantity consistency check: Ensure that the number of proof elements submitted by the client exactly matches the number of rounds declared; Zero-knowledge proof authenticity verification: Call the on-chain zero-knowledge proof verifier to verify the validity of each proof round by round; If all verifications pass, the global model state on the blockchain is updated; if verifications fail, the update is rejected and the state is rolled back.

2. The system according to claim 1, characterized in that, The client device employs a differential privacy mechanism during local training, which adds noise to prevent privacy leaks during model updates. Specifically: Before updating the model parameters, add Gaussian noise or Laplace noise to the parameters. The intensity of the noise is controlled by a privacy budget parameter to balance the level of privacy protection with model performance.

3. The system according to claim 1, characterized in that, The system also includes an incremental zero-knowledge proof aggregation mechanism to aggregate zero-knowledge proofs from multiple training rounds to generate a constant-size aggregated proof, reducing on-chain verification complexity and storage overhead. Specific steps include: Perform a hash digest on the zero-knowledge proof generated in each round of training; Recursively aggregate the hash digest of each round with the aggregation commitment of the previous round; The correctness of all rounds of model updates can be confirmed by verifying the final aggregation proof on the blockchain.

Images