Data element privacy protection method based on zero-knowledge machine learning and on-chain verification

Abstract

This paper discloses a data element privacy protection method based on zero-knowledge machine learning and on-chain verification. The method includes: constructing a system model consisting of decentralized applications, contract users, data suppliers, a distributed oracle architecture, and on-chain verification nodes; using ZK-SNARK technology, offloading computationally intensive tasks in the model to off-chain oracles for execution; and based on the zero-knowledge machine learning model on-chain and parameter update algorithm, rapidly synchronizing differentially private model parameters to multiple oracle nodes via a zero-knowledge gossip protocol, and recording the update process of these parameters on the blockchain. Using ZK-SNARK technology, the method offloads model computation tasks to off-chain oracle servers for execution, significantly reducing on-chain computation costs while effectively protecting privacy.

Description

Technical Field

[0001] The present invention belongs to the field of big data security technology, and specifically relates to a data element privacy protection method based on zero-knowledge machine learning and on-chain verification. Background Art

[0002] In the data-driven era, privacy protection has become crucial. With the widespread use of personal, transactional, and commercial data, ensuring that this sensitive data is not leaked during analysis and sharing has become a major, pressing issue. Traditional privacy protection methods, such as data encryption, desensitization, and access control, were widely used in the early days, but their limitations have become increasingly apparent as data demands have become increasingly complex. In machine learning, in particular, data sharing and use often pose risks of privacy breaches, while model training relies on vast amounts of data, leading to an increasingly acute conflict between privacy protection and data availability. At the same time, the integrity and predictive accuracy of machine learning models are also a growing concern. How can model owners prove that their models have been trained in accordance with regulations? More importantly, how can they demonstrate this while ensuring the privacy of the underlying datasets and models?

[0003] The current mainstream solution is zero-knowledge machine learning. Zero-knowledge proof technology can effectively verify the correctness of model predictions without leaking private information. Within the ZK-SNARK framework, the prover uses a given public input (i.e., the basic structure of the model) and private input data (i.e., the model's user data). The verifier can use proof π to verify the integrity of model training or predictions without accessing the private input data. However, to ensure the credibility and transparency of zero-knowledge proofs, especially in multi-party scenarios, relying on a decentralized, immutable platform to maintain trust becomes crucial. Blockchain technology provides an ideal solution. Blockchain not only ensures the trustworthiness of all parties' operations through its decentralized and transparent nature, but also automatically verifies and enforces the zero-knowledge proof process through smart contracts, ensuring that every step complies with pre-defined privacy protection standards. With blockchain, all training processes, model updates, and prediction verifications are publicly and transparently recorded on-chain, enhancing data privacy while also improving the auditability and compliance of the entire system.

[0004] However, while blockchain provides a strong foundation of trust and a robust guarantee mechanism for zero-knowledge proofs, in practice, blockchain technology itself faces a number of challenges. First, on-chain computing resources are insufficient and costly. Every node in a blockchain participates in verification and computation, but these nodes have relatively low computing power, and each computation incurs a computational fee. Second, the security of on-chain and off-chain data transmission. On-chain data can be stolen or tampered with by malicious nodes, and off-chain data can easily leak sensitive information during transmission. Third, on-chain smart contracts lack scalability. Smart contracts face computational and space resource constraints, making it impossible to use machine learning models to complete complex business tasks. Furthermore, the programming language lacks programmability and flexibility. Summary of the Invention

[0005] In view of this, the present invention proposes a data element privacy protection method based on zero-knowledge machine learning and on-chain verification. Through ZK-SNARK technology, the model calculation task is delegated to the off-chain oracle server for execution, which significantly reduces the on-chain computing cost and effectively protects privacy. A zero-knowledge machine learning model chain-up and parameter update algorithm is designed. The model parameters that have undergone differential privacy processing are quickly synchronized to multiple oracle nodes through the zero-knowledge gossip protocol, and the update process of these parameters is recorded in the blockchain to ensure its security and traceability.

[0006] In order to achieve the above object, the present invention provides the following technical solutions:

[0007] The present invention provides a data element privacy protection method based on zero-knowledge machine learning and on-chain verification, comprising:

[0008] Build a system model consisting of decentralized applications, contract users, data providers, distributed oracle architecture, and on-chain verification nodes;

[0009] Through ZK-SNARK technology, computationally intensive tasks in the model are offloaded to off-chain oracles for execution;

[0010] Based on the zero-knowledge machine learning model chain and parameter update algorithm, the model parameters that have undergone differential privacy processing are quickly synchronized to multiple oracle nodes through the zero-knowledge gossip protocol, and the update process of these parameters is recorded in the blockchain.

[0011] Preferably, in the system model:

[0012] Decentralized applications, used to provide services to contract users in the form of smart contracts on the blockchain;

[0013] Contract users, including model trainers and regular users. Regular users use private and real data as input in exchange for decentralized services provided by decentralized applications. Model trainers have the right to use the circuits in zero-knowledge proofs.

[0014] Data providers, which are independent of the blockchain and serve as the source of user and business data, verify the authenticity of data by signing it for users using their private keys. The signed data is then verified using the corresponding public key.

[0015] Oracles use a distributed architecture to proactively obtain data from off-chain data providers based on user contract requests and transmit it to the chain after generating proof using ZK-SNARK.

[0016] On-chain verification nodes are used to verify the proof and model passed into the smart contract.

[0017] Preferably, the trusted data feed process for zero-knowledge off-chain machine learning includes:

[0018] Starting from the request issued by the contract user, a data feed request is triggered by the user contract to request any event to the oracle contract, and then the oracle requests data from the external data source, generates a model proof in the oracle, and then predicts the result of the model, and finally the user gets the return result.

[0019] Preferably, the zero-knowledge off-chain machine learning application process mainly includes the following steps:

[0020] The contract user uses identity authentication information to submit business requests based on the different functions provided by the centralized application. The user's identity and business data are uploaded to the business contract. After receiving the request, the business contract forwards this information to the oracle on the blockchain.

[0021] Within the time specified in the business contract, the contract event trigger automatically starts and requests the oracle to obtain data;

[0022] The oracle requests the user's private data from the data source via HTTP requests carrying the user's identity authentication information;

[0023] The data source verifies the authenticity of the user's identity based on the identity authentication information, signs the user's private data with the private key, and returns the signed data to the oracle;

[0024] The oracle verifies the integrity of the data and desensitizes the data based on the specific business contract model information and circuit information to obtain desensitized data. It then sends the business contract model information, circuit information, desensitized data, and current model parameters to the model contract.

[0025] The model trainer sends a Drequest to the model contract to obtain model information, circuit information, model parameters, and desensitized data;

[0026] The model trainer obtains the data for training and obtains new model parameters. The model trainer generates a public witness and proof of the model using the public parameters. The trainer then generates the verification key and proof key for the model circuit and returns the training results and generated data to the model contract on the blockchain.

[0027] The blockchain's verification nodes regularly and proactively verify the model proof transactions uploaded to the blockchain to determine the valid model parameters and fuse the valid model parameters to obtain new model parameters.

[0028] Repeat the steps of generating circuit proofs again to generate a new set of model proofs for subsequent verification nodes to verify model parameters;

[0029] Once the verification is passed, the machine learning model circuit parameters of the business are recognized by the blockchain and oracle server and can be used by ordinary users for business calls.

[0030] Preferably, when the oracle server updates the model parameters, the user's personal data is converted into a private input witness of the model circuit and a corresponding zero-knowledge proof is generated;

[0031] Verification nodes verify zero-knowledge proofs to ensure the credibility and accuracy of the model reasoning process;

[0032] After the verification node is successfully verified, it is determined that the model inference result is correct and the user's business request can continue to be processed.

[0033] Preferably, the zero-knowledge machine learning model on-chain and parameter update algorithm process includes:

[0034] Model initialization: For each node, call the InitializeModel() subroutine to initialize the model parameters;

[0035] Distributed training: In each training cycle, each node calls the TrainModel() subroutine to update its model parameters;

[0036] Model synchronization and aggregation: Each node calls the SynchronizeModel() subroutine to synchronize its model parameters and obtain the final model parameters, and aggregate the final model parameters of all nodes into a global final model parameter.

[0037] Preferably, the model initialization specifically includes:

[0038] Generate initial model parameters: The central node or a pre-selected trusted node completes the initialization of model parameters. During the initialization process, the initial parameters are generated randomly or set based on prior historical data and existing pre-trained models.

[0039] Generate model proof: Generate zero-knowledge proof related to the initial model parameters through the node;

[0040] Gossip protocol broadcast: Trusted nodes use the Gossip protocol to broadcast the generated initial model parameters, verification keys, and zero-knowledge proofs in a peer-to-peer manner, allowing the initial model parameters and their proofs to quickly cover the entire distributed network.

[0041] Verifying the model proof: After receiving the initial model parameters and zero-knowledge proof, each participating node uses the verification key to verify the received proof. The model parameters that pass the verification are used to initialize the local model. Model parameters that fail the verification are rejected and the relevant exceptions are recorded.

[0042] Initialization completion and consistency assurance: When all nodes successfully verify and accept the initial model parameters, the model initialization process is determined to be completed.

[0043] Preferably, the following steps are performed in each local training process corresponding to the distributed training process:

[0044] Obtain the model circuit structure and initial model parameters through the server node in the blockchain or oracle;

[0045] Use local data to train the model, calculate the gradient of the current model parameters, and update the model parameters based on the calculated gradient and learning rate through the gradient descent algorithm;

[0046] Noise is added to the updated model parameters to ensure differential privacy. A witness is generated using the updated model parameters and the private input. A zero-knowledge proof is generated based on the witness and the public key, completing the training.

[0047] After training is completed, the node uploads the updated model parameters, zero-knowledge proof, and verification key to the blockchain.

[0048] Preferably, during the zero-knowledge machine learning model on-chain and parameter update algorithm process, the distributed model parameter update is performed through the following steps:

[0049] Each node sends its updated model parameters, zero-knowledge proof, verification key, and witness to the network through the oracle contract, and uses the Gossip protocol to propagate them among multiple nodes;

[0050] The receiving node asynchronously receives model parameters and zero-knowledge proofs from other nodes and verifies the received model parameters and zero-knowledge proofs to ensure the legitimacy and reliability of the calculation results;

[0051] If the validation passes, the model parameters are added to a specific set; if the validation fails, they are discarded;

[0052] After each round of synchronization, the node calculates the new global model parameters through the aggregation algorithm based on the model parameters in the specific set;

[0053] The global model parameters are optimized through multiple rounds of iteration. In each round, each node repeats the broadcast, verification, and aggregation steps to gradually enhance the convergence and accuracy of the model and achieve consistency across the entire network.

[0054] When all scheduled iterations are completed, the model parameters of the entire network reach a converged state and form the final global model, ensuring that each node has a consistent and optimized model;

[0055] After the distributed model training synchronization is completed, the system will record the final aggregated model parameters and their corresponding zero-knowledge proof on the blockchain to realize the evidence storage function.

[0056] The present invention has achieved at least the following beneficial effects:

[0057] 1. Through ZK-SNARK technology, model calculation tasks are delegated to off-chain oracle servers for execution, significantly reducing on-chain computing costs and effectively protecting privacy.

[0058] 2. A zero-knowledge machine learning model chain-up and parameter update algorithm was designed. The model parameters that have undergone differential privacy processing were quickly synchronized to multiple oracle nodes through the zero-knowledge gossip protocol, and the update process of these parameters was recorded in the blockchain to ensure its security and traceability. This ensures that the correctness of the model parameters can be verified in the distributed machine learning training of multi-node oracles without leaking training data, preventing security issues such as poisoning attacks.

[0059] 3. Through distributed Oracle technology, ensure that on-chain DApps remain efficient and scalable when processing complex tasks.

[0060] 4. Through zero-knowledge proof and differential privacy technology, the privacy leakage problem of user data during on-chain and off-chain interactions is solved, providing a safe and reliable machine learning solution for privacy-sensitive fields such as medical care and finance.

[0061] Other advantages, objectives and features of the present invention will be described in the following description and will be apparent to those skilled in the art to some extent, or those skilled in the art can be taught from the practice of the present invention. The objectives and other advantages of the present invention can be realized and obtained through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] In order to make the purpose, technical solutions and beneficial effects of the present invention more clear, the present invention provides the following drawings for illustration:

[0063] Figure 1 This is a diagram of the architecture of a zero-knowledge machine learning trusted data feed model in an embodiment of the present invention;

[0064] Figure 2 This is a timing diagram of zero-knowledge machine learning data feeding in an embodiment of the present invention;

[0065] Figure 3 This is a diagram of the zero-knowledge machine learning model on-chain and parameter update architecture in an embodiment of the present invention;

[0066] Figure 4 Schematic diagram of pseudo code of Algorithm 1 in an embodiment of the present invention;

[0067] Figure 5 Schematic diagram of pseudo code of Algorithm 2 in an embodiment of the present invention;

[0068] Figure 6 Schematic diagram of pseudo code of Algorithm 3 in an embodiment of the present invention;

[0069] Figure 7 Schematic diagram of pseudo code of Algorithm 4 in an embodiment of the present invention. DETAILED DESCRIPTION

[0070] The preferred embodiments of the present invention are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are only used to illustrate and explain the present invention, and are not used to limit the present invention.

[0071] The present invention provides a data element privacy protection method based on zero-knowledge machine learning and on-chain verification, which follows the principle of "off-chain computing, on-chain verification". Through ZK-SNARK technology, the model calculation task is decentralized to the off-chain oracle server for execution, which significantly reduces the on-chain computing cost and effectively protects privacy. In addition, in order to ensure that the correctness of the model parameters can be verified in the distributed machine learning training of multi-node oracles without leaking the training data and preventing security issues such as poisoning attacks, we have designed a zero-knowledge machine learning model on-chain and parameter update algorithm, which quickly synchronizes the model parameters that have undergone differential privacy processing to multiple oracle nodes through the zero-knowledge gossip protocol, and records the update process of these parameters in the blockchain to ensure its security and traceability.

[0072] By combining ZK-SNARK and distributed oracle technologies, this paper provides an efficient and secure solution for the integration of blockchain and machine learning. First, through the "off-chain computation, on-chain verification" framework, computationally intensive tasks are moved off-chain for execution, greatly alleviating the pressure on the blockchain's computing resources. Distributed oracle technology ensures that on-chain DApps maintain efficiency and scalability when handling complex tasks. Through zero-knowledge proofs and differential privacy technologies, the privacy leakage of user data during on-chain and off-chain interactions is resolved, providing a secure and reliable machine learning solution for privacy-sensitive fields such as healthcare and finance. The research results of this paper demonstrate the synergistic potential of blockchain technology and machine learning in practical applications, expand the application boundaries of blockchain in the field of intelligent decision-making, and provide a technical foundation for the realization of more powerful smart contracts and decentralized applications.

[0073] The overall architecture of the system model of the solution is as follows Figure 1 As shown in Figure 1, it consists of 8 entities, namely, on-chain verification nodes, decentralized applications (Dapps), contract users, model trainers, oracles, government authorities, and non-authoritative institutions.

[0074] 1) Decentralized applications: providing services in the form of smart contracts on the blockchain.

[0075] 2) Contract Users: Contract users are divided into model trainers and ordinary users. Ordinary users can directly access the decentralized services provided by Dapps, which require their private, real data as input. For privacy reasons, Dapp users want to maintain the privacy of their data while enjoying decentralized services. As with typical blockchains, each DU has one or more public / private key pairs. Model trainers can perform zero-knowledge proofs of circuits.

[0076] 3) Data providers: Data providers include government authorities and non-authoritative agencies. Government agencies refer to authoritative agencies such as hospitals and courts, which can provide very professional and sensitive privacy data; non-authoritative agencies refer to agencies such as factories and weather forecast providers, which can provide non-sensitive data such as business data, while guaranteeing the authenticity of the data. Data providers are independent of the blockchain and are usually the data source that generates user data and business data. It can verify data by signing data for users using its private key. DA also knows when the data was generated and who the data is associated with, but it will never disclose this data to anyone. The signed data can be used by everyone using the corresponding public key pk a For example, a medical examination report is generated and signed by a trusted hospital, and the report is associated with a specific individual. The hospital acts as a DA in this case and is trusted not to disclose the contents of the report to others.

[0077] 4) Oracle: Serving as a bridge between on-chain and off-chain, it provides blockchains with the ability to proactively access data from off-chain sources. It proactively obtains data from data providers and transmits it to the blockchain. While it ensures data security during transmission, it cannot guarantee the reliability of the data at the source. The oracle server receives requests from on-chain user contracts, proactively obtains data from data providers, generates a proof of the data provider's data using ZK-SNARK, and then returns it to the blockchain, ensuring data privacy.

[0078] 5) On-chain verification node: The verification node can be any node on the blockchain. The verifier can verify through verification keys and ZKP. The on-chain node can verify the proof and model passed into the smart contract.

[0079] In a specific embodiment, the system model designs a blockchain-based decentralized insurance contract platform that primarily provides flight insurance services to airline passengers. The platform combines the roles of multiple parties, such as contract users (passengers), model trainers (flight company engineers), data providers (authoritative and non-authoritative institutions), and oracles (which obtain off-chain data and provide privacy protection). The details are as follows:

[0080] a) Decentralized Application: Insurance Contract Dapp

[0081] The Dapp provides flight insurance services, including insurance purchase, compensation cost prediction, and flight risk analysis. Users can conveniently review the risk assessment of their flight through the Dapp and decide whether to purchase insurance based on the results. The Dapp utilizes smart contracts to execute all insurance transactions, including signing the policy and setting the compensation trigger conditions. To ensure the privacy of user data, the Dapp utilizes encryption or zero-knowledge proof technology. Even when user data is used for model training, it is not disclosed to any unauthorized third party. User-provided personal information, flight status, and health status data are encrypted or processed using zero-knowledge proofs when input into the model to ensure data privacy. Throughout the entire process, user data remains protected, preventing any leakage.

[0082] b) Contract User: Passenger

[0083] In this role, the contract user is the airline passenger purchasing insurance. On the platform, passengers enter flight information, personal health status, travel plans, and other data to receive a risk assessment and insurance quote. Because passenger data privacy is paramount, they expect to ensure the security and privacy of their personal data while enjoying decentralized insurance services. Passengers authenticate themselves using public and private keys, ensuring that only authorized users can access their private data and transaction records. After selecting an insurance product, passengers provide the required data (such as personal health status and flight information), and the insurance purchase and claim request are completed on the blockchain through a smart contract, without relying on any central entity. During data transmission and processing, passenger data remains encrypted at all times to ensure effective privacy protection.

[0084] c) Model trainer: flight company engineer

[0085] Airline company employees, acting as model trainers, are responsible for collecting de-identified passenger data (such as flight information and historical insurance claims records) and using this data to train machine learning models used to predict flight risks and insurance claims. Model trainers use zero-knowledge proofs (ZKPs) on the blockchain platform to verify the accuracy of model training and predictions, ensuring that the model output is based on real and unbiased data. The airline company trains risk assessment and claims prediction models based on de-identified data provided by passengers (such as flight delay records and historical accident data). Once model training is complete, the airline company generates a zero-knowledge proof to ensure that the model is trained on compliant and authentic data without leaking passengers' private information. The verified trained model proof is uploaded and verified via a blockchain smart contract, ensuring transparency and compliance throughout the process.

[0086] d) Data providers: authoritative and non-authoritative institutions

[0087] Data providers can be categorized as authoritative or non-authoritative. Authoritative institutions, such as hospitals and health data providers, are responsible for providing sensitive data related to passenger health conditions. Non-authoritative institutions, such as weather forecasting companies and flight data providers, provide real-time flight-related information and weather forecasts. Regardless of the type of institution, the core responsibility of the data provider is to ensure the authenticity and accuracy of the data and to sign the provided data with a private key to verify the legitimacy and credibility of the data source. Specifically, authoritative institutions (such as hospitals) provide passenger health data (such as medical history and fitness to fly) and sign this data with a private key to ensure its authenticity and accuracy. Hospitals do not disclose the passenger's specific health conditions, but instead provide encrypted documentation to ensure passenger privacy. Non-authoritative institutions (such as weather forecasting companies) provide real-time weather information (such as the weather on the flight day and the presence of severe weather). This data is also signed and verified to ensure the credibility of its source. After signing, the data is transmitted to the blockchain through an oracle for use by passengers and model trainers. This encrypted and verified data will be used for risk assessment and insurance compensation calculations, ensuring that the model makes accurate predictions based on real and reliable data while protecting passenger privacy.

[0088] e) Oracle: A bridge between on-chain and off-chain data

[0089] Oracles act as a bridge between on-chain and off-chain data, proactively acquiring data from external data providers (such as weather forecasting companies and airlines) and transmitting it to the blockchain. They provide external data support for blockchain systems, driving model predictions and smart contract execution. Oracles ensure data security during transmission and protect data privacy through zero-knowledge proofs (ZK-SNARKs), but they cannot fully verify the reliability of the data source. Specifically, after receiving a request from a smart contract, the oracle proactively obtains weather, flight information, and other information off-chain and encrypts the data. The oracle then generates a zero-knowledge proof to ensure the privacy and security of the encrypted data before uploading it to the blockchain. While oracles can ensure the security of data transmission, they cannot fully verify the accuracy of the data source, requiring them to establish a trust mechanism with trusted data providers to ensure data reliability.

[0090] f) On-chain verification nodes: validators in the blockchain network

[0091] Validation nodes are key participants in the blockchain network, responsible for verifying model training results, zero-knowledge proofs, and data authenticity. Each node ensures the accuracy and compliance of contract execution by checking smart contract parameters, model update proofs, and data signatures. When a validator receives on-chain information such as the smart contract, model training results, and data signatures, it verifies them using its verification key and zero-knowledge proofs. The validator confirms that the model training and data provision processes comply with regulations and ensures that all operations are conducted in a transparent and tamper-proof environment. If verification succeeds, the node records the transaction and continues on-chain execution. If verification fails, the contract's exception handling mechanism is triggered to ensure system security and reliability.

[0092] In a specific embodiment, the business process of the system includes:

[0093] A. System initialization

[0094] 1. Parameter initialization: Set the global model parameters {θ,info model ,info circuit ,pk a ,sk a}, where θ is the weight parameter of the model, which is used to represent the training status of the model. model Contains the model's input and output formats, model type (for example, regression model, classification model, etc.), and other specific information related to the model architecture. circuit It is the configuration related to the zero-knowledge proof circuit, including: the number and type of public inputs (such as the structural information of the model), the number and type of private inputs (such as user data or training data), the circuit proof logic (that is, how the model verifies the correctness of the input and output), etc. a ,sk a are the signature public key and private key generated by the data source. These global parameters {θ,info model ,info circuit ,pk a These parameters are broadcast and stored on the consortium blockchain and managed through smart contracts. These parameters not only provide shared foundational information for system participants but also ensure trust and transparency. All participants (such as model trainers, data providers, oracles, etc.) can access and use these global parameters to perform related operations (such as data verification, model training and validation, and zero-knowledge proof generation) through smart contracts. Furthermore, the system must ensure the security of these parameters to prevent malicious tampering and data leakage.

[0095] During system initialization, the smart contract defines and deploys basic rules and protocols, ensuring that participants can execute actions according to the pre-set contract terms. For example, data providers can provide encrypted data as required by the contract, while model trainers utilize publicly available model information and circuit configurations for training and generating zero-knowledge proofs. All of these actions are recorded on the blockchain, ensuring transparency and immutability at every step.

[0096] 2. Circuit initialization: Circuit initialization is a crucial step in a zero-knowledge proof system. It ensures that the circuit can correctly verify the validity of the computation process and generate appropriate proof and verification keys. This process involves setting a set of parameters {λ,ξ,pk,vk,C} related to the circuit and executing the following steps:

[0097] Security parameter λ: First, a security parameter λ must be set. This parameter is typically a positive integer representing the desired security level of the zero-knowledge proof system. The security parameter determines the circuit complexity and the strength of the encryption algorithm used. A larger λ generally provides greater security, but also increases computational cost.

[0098] Circuit Setup (λ) → ξ: Using the security parameter λ, a set of basic public parameters ξ is generated on the bilinear group (or other appropriate mathematical structure). These parameters include the key and algorithm required to construct the zero-knowledge proof and provide the basis for subsequent circuit compilation and proof generation. The public parameters ξ are information shared by all participants in the circuit.

[0099] Circuit Compile Compile(ξ,Info circuit )→C: Next, using the generated common parameters ξ and the detailed configuration of the circuit (i.e., Info circuit , including public input, private input, proof logic, etc.) to compile the circuit. This step converts the circuit from an abstract description into executable proof logic through the compilation process, resulting in a circuit description C, which contains specific rules for processing input data and verifying the correctness of the computation.

[0100] Key generation GenKey(C)→(pk,vk): After circuit compilation is complete, keys for generating proofs and verifications need to be generated. Using the key generation algorithm GenKey(C), a proof key pk and a verification key are generated based on the compiled circuit C. The proof key pk is used to generate a zero-knowledge proof, ensuring that the prover can prove that a computation is valid without exposing private data. The verification key vk is used by the verifier to check the validity of the zero-knowledge proof and ensure the correctness of the computation. The proof key vk is typically held by the circuit builder or model trainer, who is responsible for providing the necessary key information when generating the zero-knowledge proof. The verification key pk is typically held by the verifier (such as a verification node in a blockchain network) and is used to verify the validity of the zero-knowledge proof. This key can also be made public so that anyone can verify the authenticity of the computation.

[0101] Circuit Parameters and Key Storage: Once these keys and circuit descriptions are generated, related information (such as ξ, pk, vk, and C) is typically stored on a blockchain or other decentralized storage system. It is crucial for participants (such as model trainers, data providers, etc.) to have access to this information. The public parameters and verification keys of the circuit will ensure that all participants can perform appropriate verification at different stages without exposing sensitive data.

[0102] B. Zero-knowledge off-chain machine learning trusted data feeding process

[0103] In this zero-knowledge off-chain machine learning trusted data feed process, the circuit model has already been initialized and trained, enabling direct model inference. This process begins with a user request, triggering an event from the user contract to the oracle contract, which then sends the data to the oracle server, generating a model proof in the oracle, and finally predicting the result, ultimately returning the result to the user.

[0104] like Figure 2 As shown in the figure, the zero-knowledge chain machine learning application process mainly includes the following steps:

[0105] 1. User request: When a user accesses a decentralized application (Dapp), they submit a business request based on the different functions provided by the Dapp. In the request, the user needs to carry identity authentication information, which may include personal identity ID i , authentication information, and other business-related private data (e.g., health data, flight information, etc.). In this step, the user's identity and business data are uploaded to the business contract. After receiving the request, the business contract forwards this information to the oracle server on the blockchain. Although the user's private data is transmitted here, it is not directly disclosed. Instead, it is processed in a decentralized manner to ensure privacy.

[0106] 2. Oracle obtains data: Within the time specified in the business contract, the contract event trigger will automatically start and request the oracle server to obtain data. The oracle requests the user's private data from the data source through HTTP requests carrying the user's authentication information IDAuthi. The data source may include authoritative institutions such as hospitals and airlines or non-authoritative institutions such as weather forecast companies. The data source will verify the authenticity of the user's identity and use the private key sk a Sign the user's private data. Signature data sig = Sig(IDAuth i ,Hash(data),sk a ), data and pk a Return to the oracle server. The oracle server verifies the integrity of the data and model ) and circuit information (info circuit ) desensitizes the data and obtains the desensitized data m. Then, the oracle will model 、info circuit , m, and the current server model parameter θ1 are sent to the model contract. At this point, the data is still encrypted or desensitized to ensure that user privacy is not exposed.

[0107] 3. Off-chain model training and uploading: The model trainer sends a Drequest to the model contract to obtain model information info model 、Circuit informationinfo circuit , model parameters θ1 and desensitized data m. Convert public data m into private witness of the model circuit Data such as θ1 and m are used as input parameters of Algorithm 1. The model trainer obtains the new model parameters θ2 through data training. The public parameters ξ, θ1 and θ2 are used to generate the model's public witness x, generate proof π2, and then generate the verification key and proof key of the model circuit. The result is returned to the model contract of the blockchain. The verification node of the blockchain will regularly and proactively verify the model proof transaction uploaded to the blockchain. If the result is true, the model inference is correct and the model parameters θ2 are valid. The model parameters are then integrated to obtain new model parameters θ. The previous circuit proof generation steps are repeated to generate a new set of model proofs π2 for subsequent verification nodes to verify the model parameters. Once verified, the machine learning model circuit parameters for the business are recognized by the blockchain and oracle server and can be used by ordinary users.

[0108] 4. Verification and Business Process: When the oracle server updates the model parameters, the user’s personal data is converted into a private input witness of the model circuit And generate the corresponding zero-knowledge proof. The proof will be passed Verification is performed to ensure the credibility and accuracy of the model inference process. After successful verification by the verification node, the model inference results are deemed correct, and the user's business request can continue to be processed. For example, suppose this is a flight delay insurance prediction business. The oracle server inputs real-time flight information and the user's health data into the trained model, and the model returns the probability of flight delay and the insurance compensation amount. If the model inference is successful, the contract will continue the compensation process and pay the corresponding amount to the user. Similarly, for agricultural insurance compensation caused by severe weather, the user's data will be used for model inference to ultimately generate the compensation amount.

[0109] All of these operations are automatically executed through smart contracts, ensuring the decentralization and transparency of business processes. Using blockchain and zero-knowledge proof technology, business contracts ensure that every step is trustworthy, data privacy is protected, and model reasoning is tamper-proof.

[0110] In one specific embodiment, in a centralized oracle architecture, all training data, computing resources, and model updates are managed and executed by a single central node. Therefore, model parameter updates and validation operations throughout the training process are centralized within this node, eliminating the need for inter-node synchronization and requiring no additional algorithms to coordinate parameter updates across multiple nodes. After model training is complete, the central node directly updates the parameters and stores the updated model.

[0111] However, in a distributed oracle architecture, since different nodes have their own independent datasets and each node performs independent training locally, the final model parameters need to be synchronized through an effective parameter update algorithm and merged into a globally consistent model through parameter aggregation. The local training results and updated model parameters of each node must be ensured to be legitimate and consistent through appropriate mechanisms to prevent malicious nodes from tampering with or incorrectly updating the global model.

[0112] To ensure the security and data privacy of the model update process, parameter updates and aggregation operations in a distributed environment require not only the design of effective algorithms to handle parameter synchronization between nodes, but also the integration of privacy protection mechanisms such as zero-knowledge proofs to ensure that the update process of each node is both legal and does not expose sensitive data. In addition, due to the varying training progress of distributed nodes, some nodes may fail to update their model parameters in a timely manner due to network delays or failures. Therefore, the entire system also needs to have a certain degree of fault tolerance and consistency.

[0113] Therefore, in order to achieve the above goals, a zero-knowledge machine learning model chain and parameter update algorithm is proposed to ensure the security, efficiency and consistency of the model training and update process. Figure 3 This algorithm has the following core features and innovations:

[0114] 1. Ensure the correctness and privacy protection of model parameters

[0115] This algorithm incorporates zero-knowledge proof technology to ensure that every update to model parameters is rigorously verified within a multi-node distributed oracle, thereby guaranteeing the correctness of the training process. Throughout the entire process, zero-knowledge proofs verify the legitimacy of training results without revealing the specifics of training data or model parameters. This design protects the privacy of participating nodes while effectively preventing security risks such as poisoning attacks by malicious nodes, ensuring the trustworthiness of the system.

[0116] 2. Prevent poisoning attacks and malicious updates

[0117] By generating and verifying zero-knowledge proofs during the parameter update process, the algorithm can identify and reject erroneous updates or intentional model parameter tampering by malicious nodes, fundamentally eliminating the threat posed by poisoning attacks to the global model. After each node completes local training, the submitted model parameters automatically generate a corresponding zero-knowledge proof. Other nodes verify this proof before synchronizing parameters, ensuring that only legitimate updates affect the global model.

[0118] 3. Distributed synchronization and gossip protocol

[0119] This algorithm achieves rapid distributed synchronization of model parameters through a gossip protocol. In a multi-node environment, each node can gradually synchronize locally trained model parameters and corresponding zero-knowledge proofs to other nodes in a peer-to-peer manner, thus avoiding the single point of failure problem found in traditional centralized architectures. Furthermore, differential privacy processing of model parameters further enhances the privacy protection capabilities of the system during distributed synchronization.

[0120] 4. On-chain records and traceability

[0121] To further enhance security and transparency, the algorithm records the model parameter update process and its corresponding zero-knowledge proof on the blockchain. Leveraging the blockchain's immutability and traceability, the update history of all nodes can be securely stored and verified. This design not only ensures complete transparency of the parameter synchronization process in a distributed environment but also provides technical support for potential subsequent auditing and traceability requirements.

[0122] 5. Global model consistency and security assurance

[0123] After parameter synchronization is complete, each node performs parameter aggregation (such as weighted averaging or other methods) based on the collected model parameters and their zero-knowledge proofs to generate globally consistent model parameters. The combination of blockchain-recorded update history and zero-knowledge proof verification ensures the security, consistency, and legitimacy of global model parameters under multi-node collaboration.

[0124] This algorithm includes the following three sub-processes: model initialization, local model training by the model trainer and uploading the model, and synchronization, update, and aggregation of model parameters.

[0125] Algorithm 1 Main Function ZKML training and synchronization algorithm introduces the whole process (refer to Figure 4 ):

[0126] 1) Model initialization: For each node i, call the InitializeModel() subroutine to initialize the model parameters M i .

[0127] 2) Distributed training: In each training cycle t, each node i calls the TrainModel() subroutine to update its model parameters M i .

[0128] Model synchronization and aggregation: Each node i calls the SynchronizeModel() subroutine to synchronize its model parameters and obtain the final model parameters The final model parameters of all nodes Aggregate into a global final model parameter M*.

[0129] In a specific embodiment, the distributed ZKML model initialization process includes:

[0130] Model initialization is the first step in training a distributed zero-knowledge machine learning (ZKML) system. Its main goal is to ensure that all participating nodes in the network can synchronize consistent and reliable initial model parameters, laying the foundation for the subsequent distributed training process. The specific process is shown in Algorithm 2 (refer to Figure 5 ) includes:

[0131] Generate initial model parameters: Model parameter initialization is performed by the central node or pre-selected trusted nodes. These initial parameters M can be generated randomly or based on prior knowledge (such as historical data) or an existing pre-trained model. The initial model generation process must ensure that it meets the basic requirements of subsequent training and is sufficiently robust.

[0132] Generate Model Proof: To ensure the correctness and privacy of model parameters, the node generates a zero-knowledge proof related to the initial model parameters. Specifically, the node uses private and public inputs (private data E, zero-knowledge circuit initialization parameters ξ, and initial model parameters M) to generate a witness w. This witness and public key pk are then used to generate a zero-knowledge proof π. The specific definition of the circuit is to calculate the model loss value using the model parameters M and private data E. If the required value is met, the model proof is valid.

[0133] Broadcasting through the Gossip protocol: To ensure that all nodes can receive consistent initial model parameters, trusted nodes use the Gossip protocol to broadcast the following: the generated initial model parameters M, verification key vk and zero-knowledge proof π. The Gossip protocol uses a point-to-point propagation method, so that the initial model parameters and their proofs can quickly cover the entire distributed network, while enhancing the fault tolerance of the propagation.

[0134] Verifying the model proof: After receiving the initial model parameters M and the zero-knowledge proof π, each participating node performs the following operations:

[0135] A. Verifying the Zero-Knowledge Proof: Nodes use the verification key vk to verify the received proof π. This verification process relies on the publicly available circuit structure and model parameters M, without requiring access to the private data E. The verification key vk is used to verify the zero-knowledge proof. In this process, participants only know the public dataset, circuit structure, and public witness (model parameters M), without knowing the specific values ​​of the actual user's private data, in order to determine the reliability of the model parameters.

[0136] B. Accept or reject model parameters: The model parameters that pass the verification are accepted and used to initialize the local model M i ; If the verification fails, the node will refuse to accept the parameter and record the relevant exception.

[0137] Initialization completion and consistency assurance: The model initialization process is complete when all nodes successfully verify and accept the initial model parameters M. The combination of zero-knowledge proofs and the gossip protocol ensures the security, consistency, and traceability of the initial model parameters. Each node can be confident in the credibility and legitimacy of the initial model parameters without accessing other nodes' private data.

[0138] In a specific embodiment, in a distributed zero-knowledge machine learning (ZKML) system, local training is an important step in which each participating node independently updates the model parameters based on its own data. This process aims to ensure the credibility and privacy of the training process through zero-knowledge proof technology, while preventing data leakage through differential privacy technology. Figure 3As shown in the figure, during the local training process, the model trainer interacts with the blockchain and oracle nodes to obtain necessary information. After completing the model training, the generated proof and updated model parameters are uploaded to the blockchain for verification and synchronization across the entire network.

[0139] For details, see Algorithm 3. Figure 6 As shown:

[0140] 1. Obtain circuit and model information

[0141] Model trainers obtain the model circuit structure and initial model parameters through the server node in the blockchain or oracle. This information defines the computational process required during training, including the definition of the loss function, the gradient calculation method, and the construction of the zero-knowledge circuit.

[0142] 2. Local gradient calculation and update

[0143] Model Trainer i Using local data i To train the model, you need to calculate the current model parameters M i Gradient The gradient calculation can be expressed as

[0144]

[0145] in, represents the loss function, Represents the current model parameters. Then according to the calculated gradient Update the model parameters M with learning rate η i Specifically This process is called a gradient descent step. The learning rate η is a hyperparameter.

[0146] 3. Differential Privacy Processing

[0147] In order to protect data privacy, the updated model parameters need to add noise N i To ensure differential privacy. Noise N i The generation method of is to follow the Gaussian distribution:

[0148]

[0149] Where Δ is the sensitivity and ∈ is the privacy budget. The model parameters after adding noise are expressed as:

[0150] M′ i =M i +N i

[0151] The purpose of adding noise is to make it difficult for an external attacker to obtain the model parameters M′i , it is difficult to infer the original data E i Specific content, thereby achieving privacy protection.

[0152] 4. Generate zero-knowledge proof

[0153] The model trainer uses the updated model parameters M′ i and private input ξ to generate witness w i :

[0154] w i =GenWitness(M′ i ,ξ)

[0155] Based on the witness w i And public key pk, generate zero-knowledge proof π i :

[0156] π i =Prove(M′ i ,pk,w i )

[0157] This proof ensures the correctness of the training process and parameter updates while hiding the private data content.

[0158] 5. Model proof upload and verification

[0159] After training is completed, the node uploads the following information to the blockchain: the updated model parameters M′ i (Public input), zero-knowledge proof π i , verification key vk. After receiving this data, the blockchain verification node uses the verification key vk to prove zero-knowledge π i To verify:

[0160] A. Verification passed: This indicates that the node's calculation is correct and reliable, and the updated model parameters are recorded and synchronized to the oracle node.

[0161] B. Verification failed: The update of this node is rejected to prevent untrusted data from contaminating the global model.

[0162] 6. Interaction and synchronization

[0163] Through this process, all local node updated model parameters and their proofs are verified and recorded on the blockchain. The verified parameters are synchronized to the distributed network via the oracle contract, ensuring that all nodes in the network can further perform global model aggregation based on the trusted local update results.

[0164] In a specific embodiment, distributed ZKML model parameter update is a key step in achieving global model consistency and optimization, which is mainly completed through repeated iterations of broadcasting, verification, and aggregation, ensuring that the system improves computing efficiency and security while protecting data privacy.

[0165] like Figure 3 As shown, the model parameter M′ i , prove π i , verification key vk and witness w i The data is sent to the oracle node through the oracle contract and propagated across all nodes via the Gossip protocol. T1, T2, and T3 in the diagram represent the Gossip rounds, with these parameters being propagated each time. In distributed machine learning, model synchronization is an iterative process, achieving global model parameter consistency through multiple rounds of broadcasting, receiving, verification, and aggregation.

[0166] For details, refer to Algorithm 4. Figure 7 As shown:

[0167] 1. Parameter broadcasting

[0168] Each node will update its model parameters M′ i 、Zero-knowledge proof π i , verification key vk and witness w i It is sent to the network through the oracle contract and propagated among multiple nodes using the Gossip protocol. The spread of information is based on Figure 3 Rounds T1, T2, and T3 are completed sequentially, with the system randomly selecting the nodes to broadcast each time, ensuring that all nodes in the network have a chance to receive the information. This randomized mechanism effectively avoids network isolation and significantly reduces the risk of single points of failure, thereby improving the robustness and reliability of the entire system.

[0169] 2. Receiving and verifying model parameters

[0170] A. Asynchronous reception: Node P asynchronously receives model parameters and zero-knowledge proofs π from other nodes. The number and time of reception vary depending on network conditions. This flexibility improves the fault tolerance of the system and allows the system to operate normally in a dynamic and uncertain network environment.

[0171] B. Zero-knowledge Verification: Each node strictly verifies the received model parameters and zero-knowledge proof to ensure the legitimacy and reliability of the calculation results. The specific steps of the verification process are as follows:

[0172] IsVali|d j ←Verify(w j ,vk,π j )

[0173] By witnessing i , verification key vk and proof π j , verify whether the model parameters meet the set circuit conditions. If the verification is passed, the model parameters M j ′ will be added to the set R; if the verification fails, the parameter will be discarded, thereby defending against malicious attacks.

[0174] 3. Parameter aggregation

[0175] After each round of synchronization, the node will calculate the new global model parameters through the aggregation algorithm. Common aggregation methods include:

[0176] Simple averaging: The model parameters of all nodes participate in the aggregation with the same weight. The formula is as follows:

[0177]

[0178] This method is computationally simple and suitable for scenarios where the amount of node data and computing power are similar.

[0179] Weighted average: assign weight w to each node based on its characteristics (such as local data volume or computing power) j , perform weighted calculation on the model parameters:

[0180]

[0181] Where: j is the weight of the jth node, which is usually calculated based on the local data volume or computing power of the node. The weight ω j >0. It is the normalization factor of the weight, which is used to ensure the correctness of the calculation results.

[0182] Weighted averaging can more effectively reflect differences in data distribution and computing resources, thereby improving the efficiency and fairness of model training. The aggregated global model parameter M not only more comprehensively integrates the computational results of each node, but also reduces the impact of abnormal nodes on the overall model, ensuring the accuracy and stability of the global model. Over multiple rounds of iteration, continuous optimization of parameter aggregation leads to gradual convergence of the global model, ultimately achieving high-quality distributed machine learning.

[0183] 4. Multi-round iterative synchronization

[0184] The optimization of global model parameters is completed synchronously through N rounds of iterations. In each round of iteration, each node repeats the broadcast, verification, and aggregation steps to gradually enhance the convergence and accuracy of the model and achieve consistency across the entire network. The details are as follows:

[0185] A. Multi-round broadcast: In each round of iteration, each node will update the current model parameter M′ i And zero-knowledge proof π i The information is then propagated to other randomly selected neighboring nodes through the Gossip protocol. This approach ensures that each node has a high probability of receiving model updates from all other nodes, thus avoiding information silos.

[0186] B. Step-by-step Verification: In each round, nodes independently verify the received model parameters and zero-knowledge proofs, and only accept model parameters that pass verification. This mechanism effectively resists attacks by malicious nodes and prevents erroneous parameters from contaminating the global model.

[0187] C. Iterative Aggregation: After each round of synchronization, each node aggregates the model parameters that have passed verification in the current round to generate new global model parameters. This process gradually integrates the computational results of each node, leading to gradual convergence of the global model.

[0188] D. Improved Convergence: Through N rounds of synchronous iteration, the global model parameters in the system will continuously approach the optimal solution. In a distributed environment, multiple rounds of iteration can also effectively alleviate issues caused by network latency or node asynchrony, ensuring the accuracy and consistency of the final results.

[0189] When all scheduled iteration rounds are completed, the model parameters of the entire network reach a converged state and form the final global model, ensuring that each node has a consistent and optimized model.

[0190] 5. Evidence of the final result

[0191] After the distributed model training synchronization is completed, the system records the final aggregated model parameters M and their corresponding zero-knowledge proof π on the blockchain to achieve the evidence storage function. This process not only improves the transparency and trust of the distributed system, but also provides security and traceability for subsequent verification and auditing. The details are as follows:

[0192] A. Model Parameter Storage: The final global model parameters M are aggregated and verified before being uploaded to the blockchain for storage. The blockchain's immutable nature ensures the integrity and reliability of the recorded parameters, preventing parameter contamination caused by malicious modification or system failures.

[0193] B. Zero-knowledge proof storage: A zero-knowledge proof π uploaded along with the model parameters verifies the validity of the parameters and the correctness of the calculation process. Blockchain verification nodes can verify π using the public verification key vk to ensure that the final model meets the specified circuit conditions without accessing the node's private data.

[0194] C. Security and Traceability: The stored model parameters and proofs provide a publicly available, trusted foundation for subsequent use. Whether auditing the distributed system's operational processes or validating model results, the stored proofs provide a reliable data source, enhancing the security and transparency of the system.

[0195] D. Multi-party Verification: Once the evidence is stored on the blockchain, any authorized party can access the relevant records and verify the validity of the model parameters. This mechanism not only enhances the openness of the system but also further improves the level of trust in cross-institutional collaboration.

[0196] Through the blockchain's evidence storage function, every step of distributed model training can be strictly recorded and verified, providing important support for building a secure, transparent and efficient distributed system.

[0197] Finally, it should be noted that the above preferred embodiments are only used to illustrate the technical solutions of the present invention and are not limiting. Although the present invention has been described in detail through the above preferred embodiments, those skilled in the art should understand that various changes can be made in form and details without departing from the scope defined by the claims of the present invention.

Claims

1. A data element privacy protection method based on zero-knowledge machine learning and on-chain verification, characterized in that: include: Build a system model consisting of decentralized applications, contract users, data providers, distributed oracle architecture, and on-chain verification nodes; Through ZK-SNARK technology, computationally intensive tasks in the model are offloaded to off-chain oracles for execution; Based on the zero-knowledge machine learning model chain and parameter update algorithm, the model parameters that have undergone differential privacy processing are quickly synchronized to multiple oracle nodes through the zero-knowledge gossip protocol, and the update process of these parameters is recorded in the blockchain.

2. A data element privacy protection method based on zero-knowledge machine learning and on-chain verification according to claim 1, characterized in that: In the system model: Decentralized applications, used to provide services to contract users in the form of smart contracts on the blockchain; Contract users, including model trainers and regular users. Regular users use private and real data as input in exchange for decentralized services provided by decentralized applications. Model trainers have the right to use the circuits in zero-knowledge proofs. Data providers, which are independent of the blockchain and serve as the source of user and business data, verify the authenticity of data by signing it for users using their private keys. The signed data is then verified using the corresponding public key. Oracles use a distributed architecture to proactively obtain data from off-chain data providers based on user contract requests and transmit it to the chain after generating proof using ZK-SNARK. On-chain verification nodes are used to verify the proof and model passed into the smart contract.

3. The data element privacy protection method based on zero-knowledge machine learning and on-chain verification according to claim 1 is characterized in that: The trusted data feed process for zero-knowledge off-chain machine learning includes: Starting from the request issued by the contract user, a data feed request is triggered by the user contract to request any event to the oracle contract, and then the oracle requests data from the external data source, generates a model proof in the oracle, and then predicts the result of the model, and finally the user gets the return result.

4. The data element privacy protection method based on zero-knowledge machine learning and on-chain verification according to claim 3 is characterized in that: The zero-knowledge off-chain machine learning application process mainly includes the following steps: The contract user uses identity authentication information to submit business requests based on the different functions provided by the centralized application. The user's identity and business data are uploaded to the business contract. After receiving the request, the business contract forwards this information to the oracle on the blockchain. Within the time specified in the business contract, the contract event trigger automatically starts and requests the oracle to obtain data; The oracle requests the user's private data from the data source via HTTP requests carrying the user's identity authentication information; The data source verifies the authenticity of the user's identity based on the identity authentication information, signs the user's private data with the private key, and returns the signed data to the oracle; The oracle verifies the integrity of the data and desensitizes the data based on the specific business contract model information and circuit information to obtain desensitized data. It then sends the business contract model information, circuit information, desensitized data, and current model parameters to the model contract. The model trainer sends a Drequest to the model contract to obtain model information, circuit information, model parameters, and desensitized data; The model trainer obtains the data for training and obtains new model parameters. The model trainer generates a public witness and proof of the model using the public parameters. The trainer then generates the verification key and proof key for the model circuit and returns the training results and generated data to the model contract on the blockchain. The blockchain's verification nodes regularly and proactively verify the model proof transactions uploaded to the blockchain to determine the valid model parameters and fuse the valid model parameters to obtain new model parameters. Repeat the steps of generating circuit proofs again to generate a new set of model proofs for subsequent verification nodes to verify model parameters; Once the verification is passed, the machine learning model circuit parameters of the business are recognized by the blockchain and oracle server and can be used by ordinary users for business calls.

5. The data element privacy protection method based on zero-knowledge machine learning and on-chain verification according to claim 4 is characterized in that: When the oracle server updates the model parameters, the user’s personal data is converted into a private input witness of the model circuit and a corresponding zero-knowledge proof is generated; Verification nodes verify zero-knowledge proofs to ensure the credibility and accuracy of the model reasoning process; After the verification node is successfully verified, it is determined that the model inference result is correct and the user's business request can continue to be processed.

6. The data element privacy protection method based on zero-knowledge machine learning and on-chain verification according to claim 1 is characterized in that: The zero-knowledge machine learning model on-chain and parameter update algorithm process includes: Model initialization: For each node, call the InitializeModel() subroutine to initialize the model parameters; Distributed training: In each training cycle, each node calls the TrainModel() subroutine to update its model parameters; Model synchronization and aggregation: Each node calls the SynchronizeModel() subroutine to synchronize its model parameters and obtain the final model parameters, and aggregate the final model parameters of all nodes into a global final model parameter.

7. A data element privacy protection method based on zero-knowledge machine learning and on-chain verification according to claim 6, characterized in that: Model initialization specifically includes: Generate initial model parameters: The central node or a pre-selected trusted node completes the initialization of model parameters. During the initialization process, the initial parameters are generated randomly or set based on prior historical data and existing pre-trained models. Generate model proof: Generate zero-knowledge proof related to the initial model parameters through the node; Gossip protocol broadcast: Trusted nodes use the Gossip protocol to broadcast the generated initial model parameters, verification keys, and zero-knowledge proofs in a peer-to-peer manner, allowing the initial model parameters and their proofs to quickly cover the entire distributed network. Verifying the model proof: After receiving the initial model parameters and zero-knowledge proof, each participating node uses the verification key to verify the received proof. The model parameters that pass the verification are used to initialize the local model. Model parameters that fail the verification are rejected and the relevant exceptions are recorded. Initialization completion and consistency assurance: When all nodes successfully verify and accept the initial model parameters, the model initialization process is determined to be completed.

8. The data element privacy protection method based on zero-knowledge machine learning and on-chain verification according to claim 6 is characterized in that: Each local training process corresponding to the distributed training process performs the following steps: Obtain the model circuit structure and initial model parameters through the server node in the blockchain or oracle; Use local data to train the model, calculate the gradient of the current model parameters, and update the model parameters based on the calculated gradient and learning rate through the gradient descent algorithm; Noise is added to the updated model parameters to ensure differential privacy. A witness is generated using the updated model parameters and the private input. A zero-knowledge proof is generated based on the witness and the public key, completing the training. After training is completed, the node uploads the updated model parameters, zero-knowledge proof, and verification key to the blockchain.

9. The data element privacy protection method based on zero-knowledge machine learning and on-chain verification according to claim 6 is characterized in that: During the zero-knowledge machine learning model on-chain and parameter update algorithm process, the distributed model parameter update is performed through the following steps: Each node sends its updated model parameters, zero-knowledge proof, verification key, and witness to the network through the oracle contract, and uses the Gossip protocol to propagate them among multiple nodes; The receiving node asynchronously receives model parameters and zero-knowledge proofs from other nodes and verifies the received model parameters and zero-knowledge proofs to ensure the legitimacy and reliability of the calculation results; If the validation passes, the model parameters are added to a specific set; if the validation fails, they are discarded; After each round of synchronization, the node calculates the new global model parameters through the aggregation algorithm based on the model parameters in the specific set; The global model parameters are optimized through multiple rounds of iteration. In each round, each node repeats the broadcast, verification, and aggregation steps to gradually enhance the convergence and accuracy of the model and achieve consistency across the entire network. When all scheduled iterations are completed, the model parameters of the entire network reach a converged state and form the final global model, ensuring that each node has a consistent and optimized model; After the distributed model training synchronization is completed, the system will record the final aggregated model parameters and their corresponding zero-knowledge proof on the blockchain to realize the evidence storage function.

Images