Verifiable heterogeneous federated learning system based on zero knowledge proof

Abstract

The invention discloses a verifiable heterogeneous federated learning system based on zero-knowledge proof, and mainly aims to solve the problems of insufficient transparency, verifiability deficiency, vulnerability to data poisoning attack and the like in the existing heterogeneous federated learning. The system is composed of a plurality of client devices with different computing capabilities, data distribution and model architectures, and a block chain verification platform. The client device is responsible for training a local model, converting the model into a standard ONNX format, generating a proof by using a zero-knowledge proof tool, and submitting a model update and the proof to the block chain verification platform. And the block chain verification platform is responsible for verifying zero-knowledge proof, recording model update, constructing a global model and ensuring verifiability and transparency of the global model. According to the method, the privacy of client data is effectively protected, the credibility of the training process is enhanced, the verifiability of a global model is ensured, an enhancement path is provided for decentralized heterogeneous federated learning, and a new development direction of credible federated learning is expanded.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of federated learning and blockchain technology, and particularly relates to a verifiable heterogeneous federated learning system based on zero-knowledge proof. BACKGROUND

[0002] With the development of artificial intelligence technology, data privacy and security issues are increasingly prominent. Federated learning, as a machine learning method to protect data privacy, allows multiple clients to collaboratively train models without sharing raw data. However, traditional federated learning methods usually 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, allowing each client to independently design and train a local private model according to its own conditions. Although HFL improves the flexibility and adaptability of the system, it also introduces new security and privacy challenges, such as model tampering, adversarial sample attacks, and malicious client interference risks. In addition, existing privacy protection methods such as differential privacy and homomorphic encryption mainly focus on preventing the leakage of raw data, and have limited support for the verifiability of the computing process and results, making it difficult to effectively prevent attacks by malicious nodes. SUMMARY

[0003] The present application aims to provide a verifiable heterogeneous federated learning system based on zero-knowledge proof to solve the problems of insufficient transparency, lack of verifiability, and vulnerability to data poisoning attacks in existing heterogeneous federated learning. BRIEF DESCRIPTION OF DRAWINGS

[0004] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can also be obtained by those skilled in the art without creative labor.

[0005] Figure 1 The system architecture diagram provided by the present application;

[0006] Figure 2 The "model export-circuit compilation-proof generation-chain verification" flowchart provided by the present application;

[0007] Figure 3 The pk.key and vk.key generation time comparison chart provided by the present application;

[0008] Figure 4 The proof generation time and total generation time comparison chart provided by the present application. DETAILED DESCRIPTION

[0009] In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular architectures, techniques, etc. in order to provide a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application can be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known methods, devices, circuits, and

[0010] For better understanding, the present embodiment sets forth the prerequisite knowledge of the present embodiment.

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

[0012] Heterogeneous federated learning (HFL) emerges as an important development direction of federated learning. HFL allows each client to design and train a local private model according to its own data characteristics, computing power conditions, and business goals, thereby significantly improving the adaptability and flexibility of federated learning in complex environments. Currently, HFL has shown broad application prospects in practical scenarios such as intelligent medical care, Internet of Things, and financial risk control, which have high requirements for heterogeneity.

[0013] Although heterogeneous federated learning has significant advantages in improving system flexibility, it also introduces many new security and privacy challenges.

[0014] First, due to the diversity of client model architectures, existing security verification and consistency guarantee mechanisms based on the assumption of a unified model cannot be directly migrated, and the system faces security risks such as model tampering, adversarial sample attacks, and malicious client interference. Second, the heterogeneous model structure makes traditional privacy protection methods based on parameter or gradient aggregation no longer applicable, further exacerbating the risk of data privacy leakage. In addition, under the HFL framework, the federated system no longer maintains a unified global model, but instead consists of multiple heterogeneous models that work together to form the federated whole. This feature significantly increases the complexity of model trustworthiness verification in a distributed environment, and effective mechanisms are needed to ensure the reliability and verifiability of the computing results of each heterogeneous model, thereby preventing potential threats to system stability.

[0015] In recent years, researchers have proposed a series of innovative methods to address privacy protection and security challenges in heterogeneous federated learning. For example, Yi et al. promote knowledge fusion among clients by sharing a global homogeneous feature extractor and design an iterative training strategy to achieve effective exchange of global and local knowledge. At the same time, the method introduces a trainable weight vector to dynamically mix features to adapt to the heterogeneity of different client batch data, thereby improving the performance of the model on local data. However, this scheme does not make specific designs for privacy protection of models and data.

[0016] Alam et al. proposed a rolling sub-model extraction mechanism to address the limitations of traditional homogeneous federated learning in low-end device participation and large-scale model training, as well as the irrationality of the existing HFL scheme's 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 protection in terms of privacy protection and result verifiability.

[0017] To further enhance privacy protection capabilities, a decentralized proxy model training framework is proposed in existing technology. This framework uses the knowledge distillation paradigm in mutual learning to enable private models and proxy models to optimize together, and introduces a differential privacy mechanism during training to improve the privacy protection capabilities of private models. However, this method still has deficiencies in verifiability and is difficult to effectively prevent attacks by 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 (FL) in medical, financial, and Internet of Things (IoT) fields, verifiability and transparency have gradually attracted high attention from academia and industry. Although differential privacy (DP), homomorphic encryption (HE), and secure multi-party computation (MPC) have been widely used to protect data privacy during training, these methods mainly focus on preventing the leakage of raw data and provide limited support for the verifiability of the computation process and results, especially in the federated environment. There is still a lack of systematic solutions to prevent malicious clients or servers from misbehaving.

[0019] To this end, the academic community has begun to explore the combination of zero-knowledge proof (ZKP) technology and machine learning to achieve the verifiability of inference and training processes without revealing the model and data. Among them, the ZKML system first proposed a zero-knowledge proof optimization scheme for CNN, GPT and other neural networks, achieving optimal proof efficiency and adaptability through efficient coding of complex operators such as Softmax. In addition, Zero Knowledge Proofs for Verifiable Decentralized AI Pipelines further constructed a general ZKP framework, supporting data operations, memory access, and decision tree inference scenarios, significantly improving the verifiability of decentralized AI pipelines. For deep learning training, zkDL first introduced ZKP into the training stage of neural networks, optimizing the circuit representation of forward and backward propagation, and achieving the verification of the training process of networks with millions of parameters, effectively addressing the challenges of non-arithmetic operations in zero-knowledge circuit design. To address the complexity of large models (such as large language models LLM), zkLLM proposed the tlookup and zkAttn protocols specifically for attention mechanisms and nonlinear operations, achieving efficient zero-knowledge proof support for high-order operations such as Softmax and normalization, and providing a feasible verification path for complex neural network inference.

[0020] Although the above research has greatly promoted the development of ZK and machine learning combined technology in the verifiability of homogeneous model inference and training processes, current solutions generally assume uniform model structures and mainly focus on single model inference or training tasks, and have not fully considered the new challenges brought by the differences in model architecture and personalized data distribution among participants in the heterogeneous federated learning environment. In particular, how to ensure the authenticity, legality, and tamper resistance of the federated training process while supporting clients to independently select private models remains a key scientific problem that needs to be addressed.

[0021] To address this issue, zkFL (Zero-Knowledge Federated Learning) as an existing attempt proposes a federated gradient aggregation scheme based on zero-knowledge proof, which ensures that the aggregator completes the aggregation operation honestly without leaking the client gradient plaintext by generating zero-knowledge proof, and further reduces the verification cost with the help of blockchain. However, zkFL still follows the traditional homogeneous federated learning paradigm, providing only computational verifiability in the aggregation phase, and does not cover the private model update, decentralized collaboration, and global traceable verification requirements in the heterogeneous model scenario. Therefore, to address the shortcomings of existing heterogeneous federated learning methods in privacy protection and verifiability, this paper introduces a zero-knowledge proof mechanism based on the decentralized proxy model framework proposed by Kalra et al., 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 mechanism, but also further enhances the transparency, auditability, and computational correctness of the model training process at the system architecture level, thereby more effectively preventing malicious clients from tampering with models, injecting harmful information, and other security risks.

[0022] Unlike traditional federated learning methods that rely on centralized servers to coordinate the training process, VPFL adopts a completely decentralized system design, significantly reducing the dependence on central nodes and improving the robustness and scalability of the system. At the same time, to address the trust issues in a decentralized environment, this paper verifies the correctness of each round of proxy model calculation, allowing each client to achieve trusted cross-client knowledge sharing and aggregation while maintaining the structure of the local private model, ensuring the training efficiency and security of the system in a heterogeneous environment.

[0023] In summary, the VPFL framework proposed in this paper not only achieves higher security in terms of privacy protection, but also systematically addresses the trustworthiness issue in heterogeneous federated learning from a verification perspective for the first time, making it an important reference 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 solve the reliability problem caused by the lack of trust mechanism in federated learning, this paper introduces blockchain as a global verification and storage platform to realize the verifiable model update between heterogeneous clients. The system constructs a verification process for model calculation correctness and parameter update effectiveness off-chain, and completes the registration, verification and record of update results through on-chain smart contracts, thereby ensuring the integrity, transparency and traceability of the entire training process without relying on a centralized trusted third party.

[0026] Among them, the functions of blockchain include zero-knowledge proof verification and model update hash evidence, effectively decoupling computation and storage, reducing system complexity and on-chain resource consumption. This mechanism ensures that: the proxy model update originates from a legal calculation process, preventing malicious nodes from forging parameters; the federated training process has strong auditability and tamper resistance; and the loosely coupled architecture of "off-chain generation and on-chain verification" significantly reduces on-chain computing load and improves overall system efficiency.

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

[0028] To improve the security and verifiability of federated learning systems in a decentralized environment, this paper introduces zero-knowledge proof (ZKP) technology and constructs a mechanism for verifying model update correctness. Specifically, in each round of training, each client trains a proxy model using the differential privacy mutual learning mechanism for transmission in decentralized federated learning, then generates ZK proof of the correctness of each round of proxy model update off-chain to ensure that the model parameters in the decentralized training environment have not been tampered with and originate from a legal calculation process. This mechanism verifies the correctness of proxy model parameter calculation by verifying public auxiliary data and submits the generated proof to the chain for verification by the smart contract, ensuring that each model update has auditability and traceability, 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 of federated learning in multiple rounds of training, this paper proposes an incremental zero-knowledge proof aggregation mechanism: each round of training only generates a new proof based on the previous round's proof and the current reasoning result; it supports the aggregation and compression of multiple rounds of training proofs, generating smaller and faster-verified composite global proofs.

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

[0032] To support the blockchain-based federated learning framework proposed in this paper, this section briefly introduces several key cryptography and privacy protection technologies involved, including zero-knowledge proof, KZG commitment mechanism, incremental verifiable computation, and differential privacy. These technologies collectively build the foundation of security verification, integrity protection, and privacy protection in the system.

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

[0034] Zero-knowledge proof is a type of cryptographic protocol that allows a prover to demonstrate to a verifier that a certain statement or computation result is correct without revealing the input data or computational details. ZKProof has three core properties: completeness, soundness, and zero-knowledge, enabling high-trust verification while ensuring privacy. In the federated learning framework built in this paper, ZKProof is used to verify the correctness of the proxy model calculation in a decentralized environment, allowing each participant to verify the legitimacy and authenticity of other participants' submitted models without trusting each other, effectively preventing fake updates and training process fraud.

[0035] 2. Incremental Verifiable Computation (IVC)

[0036] Incremental Verifiable Computation (IVC) is a computing outsourcing mechanism that supports phased and multi-round verification. Unlike traditional single-round global verification methods, IVC allows the verifier to only verify the incremental results of each stage, efficiently reasoning out the correctness of the entire computation process. This feature is particularly suitable for federated learning, which is an iterative and distributed training scenario.

[0037] In the system design of this paper, IVC technology is used to build a cross-round model state verification mechanism: a zero-knowledge proof (ZK Proof) is generated for each round of model calculation, and the hash value of the output of the round is used as the public input (PublicInput) for the next round of verification, forming a recursive verification chain connected by hash commitments (Hash Commitments). Specifically, the system uses the sha2 library to generate a chainable and traceable state identifier by hashing the output of each round of model reasoning.

[0038] 3. Differential Privacy (DP)

[0039] Differential privacy is a data privacy protection mechanism that ensures the existence and attributes of individuals are hidden by introducing random noise into the query or published results, so that the change of a single data sample will not significantly affect the output results. DP provides strict mathematical privacy protection for individual data. In the federated learning scenario, noise injection is performed during training to prevent malicious aggregators from inferring user data through model parameters.

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

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

[0042] In this system, differential privacy is mainly applied to the protection of local model parameter updates. The introduction of differential privacy effectively prevents potential reverse attack, i.e., attackers infer the privacy information of local data by analyzing the uploaded parameter changes. At the same time, the system adjusts the noise intensity reasonably to achieve the trade-off between privacy protection and model performance.

[0043] 1. System architecture design

[0044] System architecture overview

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

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

[0047] User interface layer: responsible for presenting task options and privacy policies, receiving user instructions and starting the subsequent training process.

[0048] Agent 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 structure and absorbs agent model feedback using mutual learning mechanism; all forward / backward propagation is performed locally.

[0050] User storage layer: persists original data, model snapshots, and gradient logs in encrypted form, and only provides controlled read access to local computing units.

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

[0052] Zero-knowledge proof layer: Call ezkl to compile the computational graph into a Halo2 constraint circuit, derive the proof key pk and verification key vk; use pk to generate t rounds of unit proof π t , and recursively fold it into the existing promise Get constant size increment to prove π t With the latest global commitment

[0053] Blockchain verification layer: automatically deploy or reuse the verification contract embedded in vk, call verify() on π t Perform aggregate hash consistency and optional round-by-round verification; if verification succeeds, the on-chain status is updated to and record the event<roundID,modelHash,proofHash> ; If verification fails, the entire block is rolled back.

[0054] 2. Heterogeneous Federated Learning Training Module

[0055] 1. Heterogeneous private model settings:

[0056] In the complex heterogeneous environment of federated learning, the i-th user node U i Based on local data D i The unique features of the training model are customized to suit the structure of the training model f i (·;θ i This flexibility enables the system to be compatible with a variety of different model architectures, such as CNNs (convolutional neural networks) that excel at processing image data, the classic image recognition model LeNet5, and multi-layer perceptrons (MLPs), which have a relatively simple structure and perform well in some basic tasks.

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

[0058] In this formula, Indicates that the parameter θ iTo optimize the variables, find the minimum value of the objective function θ i The value of . Represents local data distribution D i Expected calculation on the data distribution D i The random samples (x,y) are statistically averaged. L(f i (x;θ i ),y) is the loss function used to measure the model f i When the parameter is θ i When the prediction result f for input x is i (x;θ i ) and the true label y. For example, the cross entropy loss function commonly used in classification tasks is calculated as Where K is the number of categories, y j is the probability f that the sample actually belongs to the jth class i (x;θ i ) j , is the probability that the model predicts that the sample belongs to the jth class. By continuously adjusting θ i , which minimizes the expectation of the loss function and thus improves the performance of the model on local data.

[0059] 2. Mutual learning mechanism:

[0060] In order to promote knowledge sharing and collaborative 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 i (·;θ i ) is trained, and it also conducts close interactive learning with the proxy model g(x;φ) to optimize the local model through information sharing.

[0061] Specifically, nodes learn from each other by sharing updated information of local models. The loss function used is as follows:

[0062]

[0063] in, Indicates the sum operation of all n nodes participating in federated learning. is the local data distribution D at node i i The expectation is obtained 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 proxy model and the private model. Taking the mean square 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 measure the difference between the prediction results of the two models from different angles. Through multiple rounds of interactive learning, the parameters of the private model f i (·;θ i ) and the proxy model g(x;φ) are constantly adjusted, so that L mutual gradually decreases, thereby achieving the common improvement of the performance of the two models and promoting the effective flow and fusion 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 perturbation before model update. Specifically, parameter perturbation can be achieved through Gaussian mechanism or Laplace mechanism:

[0066] Gaussian mechanism:

[0067] Gaussian mechanism formula: In this formula, is the perturbed parameter θ i is the original model parameter. represents Gaussian noise with mean 0 and covariance σ 2 I, where I is the identity matrix. By adding Gaussian noise to the original parameter, it is difficult for attackers to infer the original private information from the perturbed parameter, thereby achieving privacy protection. For example, assume that the original parameter θ i is a vector, θ i = [θ i1 , θ i2 ,..., θ im ], and the added Gaussian noise is a random vector with the same dimension as θ i , and each element follows a Gaussian distribution with mean 0 and variance σ 2 . In this way, the perturbed parameter hides the true value of the original parameter.

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

[0069] In the framework of federated learning, we design an integrated pipeline of "model export-circuit compilation-proof generation-on-chain verification" to securely and cost-effectively publish the inference results of local heterogeneous neural networks to the blockchain, with ezkl as the core bridge. First, the client converts the trained model into an ONNX graph; ezkl automatically maps this graph to a zero-knowledge circuit using Halo2's low-level primitives (cumulative dot product, cumulative sum / product, element-wise sum and lookup table gates), and generates a verification key (vk) bound only to the circuit structure and a proof key (pk) reserved locally through the setup process. Subsequently, the client constructs a witness combining private weights and inference inputs, calls prove to obtain a zero-knowledge proof (pi), and optionally recursively aggregates multiple pi into a constant-size aggregated proof (Pi*), further compressing the on-chain overhead.

[0070] ezkl also automatically generates an EVM / Move verification contract embedded with vk; after uploading the contract, proof, and public inputs (model hash, input commitment, etc.), the chain only needs to call verify() once to confirm that: ① the inference is performed according to the specified circuit, ② the private weights and data are not leaked, ③ the results are consistent with the declaration. This process encapsulates local models of any structure into composable and trusted black boxes, solving the pain points of traditional inference outsourcing such as untrustworthiness, privacy leakage, and high gas cost, and providing an efficient, verifiable, and on-chain-friendly landing path for heterogeneous federated learning.

[0071] During the federated learning process, the system completes knowledge fusion and privacy protection between heterogeneous models through proxy models. To achieve efficient and trustworthy verification of proxy models on the blockchain, we introduce a zero-knowledge proof (zk-SNARK) compilation mechanism based on ONNX computation graphs, which converts various operators and activation functions of proxy models into corresponding Halo2 constraints to form efficient verification circuits.

[0072] 3.1 ONNX Intermediate Representation and Computation Graph Compilation

[0073] Open Neural Network Exchange (ONNX) as a cross-framework standardized intermediate representation provides a formal basis for the conversion of proxy models to zero-knowledge circuits. ONNX defines model structure in a directed acyclic graph (DAG), where nodes represent specific operators (such as convolution, matrix multiplication, nonlinear activation functions), and edges represent data flow between tensors. Key components include:

[0074] Graph (Computation Graph): Topology of operators, explicitly defining data dependencies between nodes.

[0075] Operator Set: Definition of versioning semantics for operators to ensure consistency across inference frameworks.

[0076] Initializer: Pre-stored static weights of model parameters for direct embedding in ONNX files.

[0077] Metadata: Records dynamic dimensions, node names, and quantization information of model inputs and outputs.

[0078] Due to the advantages of framework independence and static resolvability of ONNX, ezkl can parse the ONNX graph structure statically without runtime environment and automatically map the model calculation logic to Halo2 circuit constraints accurately. Therefore, based on ONNX, the system realizes the formal automatic compilation of proxy models to zero-knowledge proof circuits.

[0079] 3.2 Implementation of zero-knowledge constraints for linear operators in proxy models

[0080] The commonly used fully connected layer and convolution layer in proxy models can be mathematically represented as:

[0081] z = Wx + b

[0082] where W is the weight matrix, x is the input vector, and b is the bias term. In the zero-knowledge proof circuit, the dot product operation can be implemented by accumulating the dot product constraints. Specifically, each input is multiplied by the corresponding weight and accumulated, and then the bias term is added. This constraint can be represented by the following formula:

[0083]

[0084] where: W ji is an element of the weight matrix W; x i is an element of the input vector x; b j is the bias term.

[0085] Nonlinear activation functions such as Softmax and Sigmoid are widely used in proxy models. Taking the Softmax function as an example, its output can be calculated by the following formula:

[0086]

[0087] where: z j is the jth element of the input vector (logit); K is the number of classes.

[0088] To efficiently implement this function in the circuit, we adopt Cumulative Sum Constraint and Exponent Constraint. Specifically, the circuit first computes the exponent value for each element of the input vector, and then normalizes the exponent value through Cumulative Sum Constraint to obtain the correct Softmax output. By this constraint, the circuit verifies the correct execution of the Softmax function while ensuring that the input data privacy is not leaked.

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

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

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

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

[0093] z = x + y

[0094] The formula for the multiplication operation is:

[0095] z = x * y

[0096] These constraints efficiently simulate the regular element-wise operations in the proxy model, making the circuit structure compact and easy to verify efficiently.4.3.3 Lookup Argument for Nonlinear Functions in Proxy Models

[0097] When converting the proxy model into zero-knowledge proof, some complex nonlinear functions (such as Sigmoid, 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] The lookup table (LUT) accelerates function evaluation by pre-computing and storing discrete values of the function. This technique allows the proof system to efficiently handle nonlinear functions without performing complex real-time calculations.

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

[0100] To improve the efficiency of the circuit, when the range of function values is large, the original lookup table T is split into n non-intersecting sub-tables:

[0101]

[0102] This formula shows that the original lookup table T is split into n non-intersecting sub-tables Tj, and the original lookup table T is recovered by merging these sub-tables. Specifically, T is the union of all sub-tables Tj, and each sub-table Tj has no intersection with other sub-tables Tj, i.e., their intersection is the empty set. In this way, each sub-table after splitting 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. When proving, only need to multiply the query pair by the corresponding selector polynomial, which can complete the multi-table matching in a single gate. In circuit verification, the input will be classified by the product of the corresponding selector polynomial to ensure fast lookup verification.

[0106] To protect the privacy of input and output, we use a secure mechanism based on polynomial commitment. For table T, define polynomial:

[0107]

[0108] where || represents the concatenation operation. If (x, y) ∈ T, the prover only needs to prove p(x||y) = 0 without revealing the specific x or y value, thus protecting the privacy of input and output. p(X) is a product function, and each term of the product is the combination of x i and y i in X minus each binary tuple (x i , y i ); (x i , y i ) belongs to the set T, representing the difference between all x t and the corresponding y t . In this way, the lookup constraint not only guarantees the computational efficiency, but also maintains the privacy characteristics of zero-knowledge proof.

[0109] In summary, through the above constraint construction and circuit conversion method, the neural network computing logic of the proxy model (ProxyModel) is efficiently and completely mapped into the zero-knowledge proof circuit, thereby realizing efficient and privacy-protected on-chain trusted verification of 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 computing scenarios such as federated learning or continuous inference, the present scheme proposes a zero-knowledge proof generation, aggregation, and on-chain verification framework led by blockchain miners. The effectiveness of each round of computation will be independently proven by miners using predefined zero-knowledge proof circuits, followed by proof aggregation, and finally recorded on the blockchain for public auditing and verification by users or other stakeholders participating in federated learning.

[0112] Specifically, for any tth round (1≤t≤T) of computation, the following variables are defined: the secret input (Witness) is w t ; the public input or state is x t ; the public output or state update is y t .

[0113] Miners generate the effectiveness proof of the tth round of computation under the chain through the corresponding zero-knowledge proof circuit C and the configuration parameter cfg: π t = GenerateProof(C, cfg, w t , x t , y t )

[0114] For easy on-chain storage and query, the proof generated each round will generate the corresponding metadata structure meta t :

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

[0116] Where the proof hash h t is calculated by the miner through the Keccak256 algorithm:

[0117] h t = Keccak256(π t )

[0118] After completing all T rounds of computation and proof generation, the miners will aggregate the multiple hash values h1, h2,..., h TThe results are concatenated (denoted by ||) and then a SHA-256 hash function is applied to the concatenated results to generate the final aggregated hash value H agg :

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

[0120] Further forming the final aggregated proof structure:

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

[0122] The miner then submits the aggregated proof structure π agg as a trusted record to the blockchain for users to query.

[0123] 5 On-chain verification data packaging of aggregated proof

[0124] In order to submit an aggregated verification request to the blockchain, we design the following call data structure:

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

[0126] Wherein, the key element summary of each round is defined as:

[0127] elem t = {iteration: t, params: cfg, hash: h t} The call data calldata is obtained by encoding 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:

[0130] calldata = encode(CD)

[0131] The data submitted by the miner contains all the key information required for verification, facilitating the automatic execution of the aggregation verification process by the on-chain contract.4.6 Blockchain verification module: miner submission and public auditability of on-chain proof

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

[0133] The specific verification process is described as follows:

[0134] (1) Miner on-chain submission of proof records

[0135] The miner encodes the aggregated proof structure as π agg The blockchain smart contract call data (calldata), constructs the transaction T and submits it to the blockchain network:

[0136]

[0137] Where τ represents the Unix timestamp at the time of aggregated proof submission.

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

[0139] The blockchain network verification nodes strictly examine the data submitted by the miner by executing the verification function in the smart contract during the consensus process. The on-chain contract execution logic includes the following steps:

[0140] Aggregated hash consistency check:

[0141] The verification node recalculates the aggregated hash H ′ agg and verifies its consistency with the aggregated hash H agg submitted by the miner:

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

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

[0144] Proof quantity consistency check:

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

[0146]

[0147] Zero-knowledge proof authenticity verification:

[0148] In the actual deployment environment, the smart contract can further call or be built into the on-chain zero-knowledge proof verifier to confirm 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 of them fails, the contract rejects the transaction and rolls back all state changes.

[0151] (4) Proof public record and user audit mechanism

[0152] The successful aggregated proof data will be recorded on the chain in the form of a blockchain event or persistent storage, ensuring that it can be publicly accessed and audited in the future:

[0153] Federal learning participants can query the aggregated hash H agg , single-round proof hash h t , and corresponding round number, submission timestamp, and other metadata information in real time through a blockchain browser or on-chain public interface, ensuring that the audit process is open and transparent.

[0154] Users can independently recalculate and verify the consistency of off-chain proof hashes and aggregated hashes without accessing or exposing sensitive raw data, ensuring the credibility and effectiveness of off-chain computing processes.

[0155] A specific on-chain event record example is as follows: emit VerificationRecorded(H agg , T, τ)

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

[0157] 5. Experiment

[0158] This experiment focuses on using zero-knowledge proof (zk-SNARK) and incremental zk aggregation technology to improve the privacy protection and efficiency of federated learning models. The experimental framework uses a decentralized ProxyFL (Proxy Federated Learning) architecture and combines differential privacy technology for training. We have verified on the classic MNIST and Fashion-MNIST datasets, tested the effects of different algorithms and model architectures, and ensured data privacy and the security of the verification process through zk-SNARK proof technology.

[0159] 5.1 Experimental Architecture and Dataset

[0160] The experiment employed the decentralized ProxyFL architecture, which aims to decentralized model training on the client side while simultaneously using proxy models for global model aggregation. In this framework, clients train based on local data, protected by differential privacy. The proxy model updates the global model, ensuring data privacy during training. In each round of training, each client trains its own model using its local data. The training set is divided into K equal-sized subsets and distributed to each of the K clients.

[0161] The experimental datasets include: MNIST dataset: contains 28x28 pixel grayscale images of 10 digital categories, and the task is to classify the images into digital categories. Fashion-MNIST dataset: also contains 28x28 pixel grayscale images of 10 categories, and the task is to identify the 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 maintaining the principle of differential privacy. The specific configurations are as follows:

[0165] Differential privacy parameter settings:

[0166] All training uses the Differentially Private Stochastic Gradient Descent (DP-SGD) optimizer. During training, the following key parameters were set to ensure privacy: the noise multiplier σ was set to 1.0; the gradient clipping threshold C was set to 1.0; and each training round used a mini-batch sampled from the dataset using random sampling with replacement, with each sample selected with a fixed probability to ensure compliance with the assumptions of the 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 are structurally peer-to-peer entities, using a decentralized ProxyFL (proxy model federated learning) architecture. This means that clients do not rely on a central server for model synchronization, but instead collaborate on learning through proxy model exchange.

[0169] Data volume per client:

[0170] Each client is assigned 1000 samples, and these samples do not overlap between different clients to build a more challenging non-IID data environment. The data allocation follows a random sampling mechanism to ensure the robustness and reproducibility of experimental results.

[0171] Training Rounds:

[0172] To observe the convergence and performance stability of the model under different training rounds, the experiment adopts four training round configurations: 50 rounds, 100 rounds, 200 rounds, and 300 rounds. In each training round, 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 Proof and Incremental zk Aggregation

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

[0175] As shown in Figure 3 , this graph shows the time required to generate public keys (pk.key) and verification keys (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: As the data volume increases, the pk.key generation time gradually increases. From about 112 seconds for 50 samples to nearly 6000 seconds for 300 samples. vk.key generation time: Compared with pk.key, the vk.key generation time is relatively short, but it also shows a growth trend as the data volume increases. For 300 samples, the vk.key generation time is about 3900 seconds.

[0178] Trend Line Analysis:

[0179] The blue dotted line in the graph represents the pk.key generation time, showing an exponential growth in generation time as the number of samples increases. The orange dotted line represents the vk.key generation time, which shows a growth trend, although not as fast as pk.key, especially when the data volume reaches 300 samples. As Figure 4As shown in the figure, it shows the changes in generating zk-SNARK proof and total generation time under different client training data volume. 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 data volume increases, the time to generate proof also increases significantly. At 50 samples, the time to generate proof is 231 seconds, while at 300 samples, the time increases to 2257 seconds, with a significant increase. Total generation time: The total generation time includes proof generation and other computing operations. With the increase of data volume, the growth of total generation time is more significant, about 934 seconds at 50 samples, and nearly 18000 seconds at 300 samples.

[0182] Trend line analysis:

[0183] The green dotted line in the figure represents the proof generation time, showing that the proof generation time grows in a relatively linear trend as the training data volume increases. The red dotted line represents the total generation time, which shows a more steep growth trend, especially when the data volume reaches 200 and 300, the growth rate accelerates.

[0184] Analysis of experimental results:

[0185] Through these charts, the experimental results show that:

[0186] As the client training data volume increases, the time to generate keys and proofs shows exponential growth, especially the time to generate public keys (pk.key) is most significant.

[0187] The growth of total generation time not only comes from proof generation, but also from other computing processes (such as key generation), especially when the data volume is large, the growth rate of total generation time is more obvious.

[0188] 5.4 Incremental aggregation of zero-knowledge proof and minimum on-chain storage strategy

[0189] To further improve the on-chain resource utilization efficiency of the blockchain federated learning system in large-scale, multi-round reasoning verification scenarios, this research proposes and implements an incremental zero-knowledge proof aggregation mechanism (IncrementalZKAggregation). Unlike the traditional mode of separate on-chain verification after each round of calculation, this mechanism recursively aggregates the zero-knowledge proofs of consecutive rounds off-chain, finally generating a unified, constant-size aggregated proof, achieving "one call to complete multi-round verification" on-chain, significantly reducing on-chain overhead.

[0190] Implementation mechanism and optimization strategy

[0191] Specifically, each federated learning agent node generates a unit zk proof π t after completing each round of inference locally, using private inputs and the model Recursive generation of high-order aggregated proofs round by round with the latest global commitment After multiple rounds of iteration, the system only needs to deploy a unified verification contract (IEZKLVerifier) on-chain once, and call the unique interface function processProof() of the contract, submit the generated final recursive aggregated proof and public input file, to complete the verification of all multi-round inferences on-chain at once.

[0192] Resource optimization and gas consumption evaluation

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

[0194] In the benchmark test, verifying a round of zk-SNARK proof produces a transaction cost of about 561901 gas. This value is then used as the unit cost of the "traditional round-by-round verification" scheme to calculate the cumulative consumption in the multi-round scenario.

[0195] Note:

[0196] G single = 5.61901 x 10 5 gas,

[0197] Then the cumulative consumption of the traditional scheme in N rounds of verification is

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

[0199] The on-chain verification of the optimized aggregated proof only needs

[0200] G agg = 4.6532 x 10 4 gas,

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

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

[0203] According to the formula G grad and G aggIt can be seen that the on-chain gas consumption of traditional round-by-round verification is a linear function of the training rounds N trad , while the consumption of incremental aggregation verification is a constant agg .

[0204] When N = 300, there are

[0205]

[0206] That is, the incremental aggregation verification scheme reduces the on-chain gas cost by more than 3 times. In the high-frequency inference or long-term online training scenario, incremental aggregation verification can significantly suppress the cumulative explosion of blockchain-level cost.

[0207] The traditional scheme needs to upload N single-round proofs. If each proof is gzip compressed, it still needs about 25 kB, so when N = 300, the on-chain calldata size is about 7.3 MB, and 300 transactions are broadcast, which brings a not small burden to the on-chain state and P2P network.

[0208] In contrast, the incremental aggregation verification scheme only uploads one aggregated proof with a size of about 20 kB, and its on-chain storage and network propagation traffic is reduced to

[0209]

[0210] Under the current 30M gas block limit of the Ethereum mainnet, the consumption of 4.86 million gas of the incremental aggregation verification transaction is only 16.2%.

[0211] This means that even if the gas price soars or the block is close to saturation, the aggregation verification transaction can still be easily included, and the disturbance to baseFeePerGas can be ignored. While the traditional scheme will significantly push up the baseFee when submitting hundreds of verification transactions in a short time, causing user cost overflow and block congestion risk.

[0212] At a 20G weigas unit price and an ETH current price of 1800USD: the traditional 300 rounds consume (1.69x10 8 gas) x 20Gwei ≈ 0.337ETH (~ 606USD). The incremental aggregation verification scheme (20.56x10 4 gas) x 20Gwei ≈ 0.00972ETH (~ 17.50USD). The on-chain transaction cost is saved by more than 97.13%. Considering that the on-chain execution cost and energy consumption are approximately proportional, the incremental aggregation verification scheme also significantly reduces carbon emissions, laying a practical foundation for sustainable blockchain computing.

[0213] Through the above experiments and analysis, we can clearly draw the following conclusions: the incremental aggregation verification scheme shows obvious advantages in on-chain resource consumption, and the advantages become more significant with the increase of training rounds, reflecting good scalability; the on-chain storage and network bandwidth overhead are reduced to less than 1% of the traditional scheme, which greatly alleviates the pressure of on-chain data storage and network transmission; the transaction packaging efficiency and block carrying capacity have been significantly improved, which is easier to be accepted and incorporated by miners in the main network environment; it has high advantages in economic cost and environmental benefits, and will greatly reduce economic expenses and environmental burdens in large-scale application environments.

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

[0215] It should be noted that the information interaction, execution process, etc. between the above-mentioned devices / units are based on the same concept as the method embodiment of this application. Their specific functions and technical effects can be found in the method embodiment section and will not be repeated here.

[0216] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by 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 embodiment can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0217] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0218] Those skilled in the art can understand that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be realized in electronic hardware or a combination of computer software and electronic hardware. Whether the functions are realized in hardware or software manner depends on the specific application and design constraints of the technical solution. The skilled person can use different methods to realize the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0219] The above-described embodiments are only used to illustrate the technical solutions of the present application, but not limit the present application; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that the technical solutions recorded in the foregoing embodiments can be modified, or some technical features can be replaced by equivalent replacements; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.

Claims

1. A verifiable heterogeneous federated learning system based on zero-knowledge proof, characterized by: include: Multiple client devices, each with different computing power, data distribution, and model architecture; A blockchain verification platform is used to record and verify the model update and calculation process in the federated learning process; each client device performs the following steps: Local training: training based on local data and private model architecture to generate model updates; Model conversion: convert the local model to the standard ONNX format; Zero-knowledge proof generation: Use zero-knowledge proof tools to convert ONNX format models into verifiable circuits and generate zero-knowledge proofs to prove the correctness and legitimacy of model updates; 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 and non-tampering of the model update; Model Update Recording: If the verification is successful, the model update is recorded on the blockchain and becomes part of the global model; Global model construction: Aggregate model updates from multiple clients to build a global model and ensure the verifiability and transparency of the global model.

2. The system according to claim 1, wherein: 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; Use the EZKL tool to compile the ONNX format model into a Halo2 constraint circuit; generating a verification key and a certification key by the constraint circuit; Use the proof key to prove the model update process and generate zero-knowledge proof; Submit the generated zero-knowledge proof to the blockchain verification platform; The blockchain verification platform uses verification keys to verify zero-knowledge proofs to ensure the authenticity and legitimacy of model updates.

3. The system according to claim 1, wherein: The blockchain verification platform uses smart contracts to automatically execute verification logic, specifically including: Aggregate hash consistency check: Verify whether the aggregate hash submitted by the client is consistent with the hash recorded on the blockchain; Proof quantity consistency check: ensures that the number of proof elements submitted by the client exactly matches the declared number of rounds; Zero-knowledge proof authenticity check: calls the zero-knowledge proof verifier on the chain to confirm the validity of each proof round by round; If all verifications pass, the global model state on the blockchain is updated; if verification fails, the update is rejected and the state is rolled back.

4. The system according to claim 1, wherein: The client device adopts a differential privacy mechanism during local training to prevent privacy leakage during the model update process by adding noise. Specifically, before the model parameters are updated, Gaussian noise or Laplace noise is added to the parameters; The intensity of the noise is controlled by a privacy budget parameter to balance the degree of privacy protection and model performance.

5. The system according to claim 1, wherein: The system also includes an incremental zero-knowledge proof aggregation mechanism for aggregating zero-knowledge proofs from multiple rounds of training to generate aggregated proofs of constant size, reducing on-chain verification complexity and storage overhead. The specific steps include: Hash 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; On-chain, it is only necessary to verify the final aggregation proof to confirm the correctness of all rounds of model updates.

Images