# Enhancing Trust in AI Marketplaces: Evaluating On-Chain Verification of Personalized AI Models using zk-SNARKs
**Authors**: Nishant Jagannath, Christopher Wong, Braden McGrath, MD Farhad Hossain, Asuquo A. Okon, Abbas Jamalipour, Kumudu S. Munasinghe
> Nishant.Jagannath@canberra.edu.auSchool of IT and Systems, University of Canberra, ACT, Australia
> School of IT and Systems, University of Canberra, ACT, Australia
> School of Engineering and Technology, University of New South Wales, ACT, Australia
> School of Electrical and Information Engineering, University of Sydney, NSW, Australia
Abstract
The rapid advancement of artificial intelligence (AI) has brought about sophisticated models capable of various tasks ranging from image recognition to natural language processing. As these models continue to grow in complexity, ensuring their trustworthiness and transparency becomes critical, particularly in decentralized environments where traditional trust mechanisms are absent. This paper addresses the challenge of verifying personalized AI models in such environments, focusing on their integrity and privacy. We propose a novel framework that integrates zero-knowledge succinct non-interactive arguments of knowledge (zk-SNARKs) with Chainlink decentralized oracles to verify AI model performance claims on blockchain platforms. Our key contribution lies in integrating zk-SNARKs with Chainlink oracles to securely fetch and verify external data to enable trustless verification of AI models on a blockchain. Our approach addresses the limitations of using unverified external data for AI verification on the blockchain while preserving sensitive information of AI models and enhancing transparency. We demonstrate our methodology with a linear regression model predicting Bitcoin prices using on-chain data verified on the Sepolia testnet. Our results indicate the framework’s efficacy, with key metrics including proof generation taking an average of 233.63 seconds and verification time of 61.50 seconds. This research paves the way for transparent and trustless verification processes in blockchain-enabled AI ecosystems, addressing key challenges such as model integrity and model privacy protection. The proposed framework, while exemplified with linear regression, is designed for broader applicability across more complex AI models, setting the stage for future advancements in transparent AI verification.
1 Introduction
The proliferation of artificial intelligence (AI) has revolutionized the digital landscape, driving a growing demand for personalized, efficient, and reliable AI models. Developing such models, however, is resource-intensive and requires specialized expertise [1]. To bridge this gap, AI marketplaces have emerged as pivotal platforms that facilitate the exchange of personalized AI services. These marketplaces empower developers to monetize their models, providing access to sophisticated AI tools for users who may lack the capacity to develop them independently. A prime example of this trend is the ChatGPT Store [2], which offers diverse AI models tailored to various user needs. By enabling the buying, selling, and sharing of pre-trained AI models, AI marketplaces function much like software app stores but with a focus on AI capabilities rather than applications.
<details>
<summary>extracted/6340811/Strip-1.png Details</summary>
### Visual Description
\n
## Diagram: Security Challenges in Emerging Technologies
### Overview
The image presents a horizontal sequence of three diagrams, each illustrating a security challenge associated with a different emerging technology: Blockchain, Personalized AI Models, and Model Inference. The diagrams are stylized and symbolic, focusing on conveying concepts rather than precise technical details. There is no numerical data present.
### Components/Axes
The image consists of three distinct sections, each with a descriptive title above it.
* **Section 1: Blockchain - Lack of Inherent Trust**
* Features a cluster of orange snowflake-like shapes on the left, connected by curved arrows to a central, dark grey cube structure composed of smaller cubes.
* Within the central cube, there are several circular icons representing different blockchain platforms or components: a large "H", a Bitcoin symbol (₿), Ethereum (⎈), and a red/white/blue circular icon.
* **Section 2: Personalized AI Model – model’s integrity and confidentiality issues**
* Depicts a network of interconnected orange circles.
* Arrows point from some circles to others, indicating data flow or relationships.
* **Section 3: Detecting changes to the model during inference is challenging.**
* Shows a stylized cartoon robot head with "X" marks for eyes and an exclamation mark within a speech bubble. The robot is positioned above a shape resembling a circuit board or a simplified computer.
### Detailed Analysis or Content Details
The image does not contain specific numerical data. The diagrams are conceptual representations.
* **Blockchain:** The snowflake shapes suggest decentralized nodes, while the central cube represents the blockchain itself. The icons within the cube indicate the diversity of blockchain technologies. The arrows suggest data or transactions flowing between nodes and the blockchain.
* **Personalized AI Model:** The interconnected circles represent the complex relationships within a personalized AI model. The arrows indicate the flow of data and the dependencies between different parts of the model.
* **Model Inference:** The robot with "X" eyes and an exclamation mark symbolizes the difficulty in detecting changes or anomalies during the inference phase of a machine learning model.
### Key Observations
The diagrams highlight the inherent security challenges associated with each technology:
* Blockchain: Despite its decentralized nature, trust is not inherent and relies on the integrity of the nodes and the consensus mechanism.
* Personalized AI: The complexity of personalized AI models raises concerns about data integrity and confidentiality.
* Model Inference: Detecting malicious alterations or unexpected behavior during model inference is a significant challenge.
### Interpretation
The image serves as a high-level overview of security concerns in emerging technologies. It suggests that each technology, while offering significant benefits, also introduces new vulnerabilities that need to be addressed. The use of symbolic representations emphasizes the conceptual nature of these challenges rather than specific technical implementations. The image implies a need for robust security measures and ongoing monitoring to mitigate these risks. The progression from Blockchain to AI suggests a growing complexity in security challenges as technologies evolve. The final image of the robot with the warning sign is a stark reminder of the potential consequences of failing to address these issues.
</details>
Figure 1: The importance of personalized AI model verification on blockchain.
Despite the promise of AI marketplaces, the dominance of a few global tech giants in AI technology has raised significant concerns regarding transparency, fairness, and equitable access [3]. Model weights are essential for providing experimental reproducibility and fostering innovation. The push towards commercializing AI models has led to a trend of closed-source models, keeping model weights and other details confidential. This confidentiality is due to the significant investments in data acquisition, computational resources, and algorithmic optimization. Even if developers wish to substantiate the performance claims of their models, publishing these weights could result in the misuse of AI models, leading to advanced cyberattacks or the propagation of disinformation [4]. These limitations hinder the examination of model performance and the verification of any claims regarding their effectiveness.
The problem is exacerbated in AI marketplaces operating in decentralized settings, such as blockchain, where there is no inherent trust among users [5]. This lack of transparency makes it difficult to identify performance characteristics, such as performance claims, in production AI models. Ensuring the integrity and reliability of personalized AI models in these marketplaces is crucial, as providers must guarantee model performance, and consumers seek assurance of quality and value. Currently, methods like SingularityNET’s decentralized reputation system rely on community participation to rate AI services [6]. However, this method lacks the rigour necessary for comprehensive validation. These issues as seen in Fig. 1, highlight the need for a decentralized and transparent verification mechanism that fosters trust.
<details>
<summary>extracted/6340811/Strip-2.png Details</summary>
### Visual Description
\n
## Diagram: Secure and Trusted AI Evaluation & Verification
### Overview
The image presents a two-part diagram illustrating a process for generating secure and trusted evaluation proofs for AI models, and verifying model inference on decentralized oracle networks. Part A focuses on generating a proof, while Part B details the verification process. Both parts utilize visual metaphors of networks and blockchain structures to represent data flow and security.
### Components/Axes
The diagram is divided into two main sections, labeled "A: Generate a secure and trusted evaluation proof" and "B: Verifying model inference on decentralized oracle networks". Each section contains three stages, visually connected by arrows indicating the flow of information. Key components include:
* **Personalized AI Model:** Represented by a network of interconnected nodes with red lines.
* **Developer:** A stick figure icon.
* **Zero-Knowledge Proofs:** Represented by a lock icon.
* **zkSNARK:** A labeled box.
* **Blockchain:** Represented by a cube-like structure with internal symbols.
* **Decentralized Oracle Network:** Represented by a network of interconnected nodes with blue lines.
* **zk-verification:** A labeled box with binary code (10100110110).
* **Question Mark with Checkmarks:** Representing verification status.
### Detailed Analysis or Content Details
**Part A: Generate a secure and trusted evaluation proof**
1. **Benchmarked Personalized AI Model:** A network of approximately 15 nodes connected by red lines. The nodes are circular.
2. **Generation of Zero Knowledge proofs:** A circular icon with a lock inside, positioned above a box labeled "zkSNARK". A "Developer" icon is placed to the left of the box. An arrow points from the AI model to this stage.
3. **Validated Proof shared on the blockchain:** A cube-like structure representing a blockchain, with internal symbols. An arrow points from the "zkSNARK" box to this stage.
**Part B: Verifying model inference on decentralized oracle networks**
1. **Personalized AI models deployed in a decentralized marketplace:** A blockchain structure with internal symbols. An arrow points from this stage to the next.
2. **Decentralized oracle network:** A network of approximately 15 nodes connected by blue lines. The nodes are circular. An arrow points from the blockchain to this stage.
3. **zk-verification:** A box labeled "zk-verification" containing binary code "10100110110". An arrow points from the oracle network to this stage.
4. **The new proof is matched against the validated proof previously shared on the blockchain:** A blockchain structure with internal symbols. A question mark with checkmarks is positioned to the left of the blockchain. An arrow points from the "zk-verification" box to this stage. The text "The result is returned to the blockchain" is positioned below the "zk-verification" box.
### Key Observations
* The diagram emphasizes the use of zero-knowledge proofs (zkSNARKs) for secure AI evaluation.
* The blockchain is presented as a central component for both generating and verifying proofs.
* The use of network diagrams for AI models and oracle networks suggests a distributed and decentralized approach.
* The binary code within the "zk-verification" box indicates a computational process.
### Interpretation
The diagram illustrates a system designed to enhance the trustworthiness of AI models by leveraging zero-knowledge proofs and blockchain technology. The process begins with a benchmarked AI model, generates a proof of its evaluation using zkSNARKs, and stores this proof on the blockchain. Subsequently, when the model is deployed in a decentralized marketplace, its inference is verified against the previously stored proof on the blockchain, ensuring integrity and security. The use of decentralized oracle networks suggests a robust and tamper-proof verification mechanism. The binary code likely represents the cryptographic verification process. The question mark with checkmarks indicates a successful verification outcome. The overall system aims to address concerns about the reliability and transparency of AI models in decentralized environments.
</details>
Figure 2: A high-level overview of the system design.
Technologies like Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge (zk-SNARKs) can help address trust and model privacy issues in this context. zk-SNARKs provide powerful cryptographic proofs that verify the correctness of computations without revealing the underlying data [7]. However, using zk-SNARKs to verify AI models’ integrity and performance claims on blockchain-based marketplaces presents several challenges. Firstly, the compactness of zk-SNARK verification proofs is offset by the substantial resources needed for proof verification, potentially causing bottlenecks [8], especially when the blockchain handles multiple transactions and interactions simultaneously. Secondly, the computational intensity of zk-SNARK proofs involves complex mathematical computations that are both time-consuming and costly in terms of blockchain gas fees on platforms like Ethereum [8]. Furthermore, verifying claims of AI models using zk-SNARKs often requires external data inaccessible within the blockchain [9]. These considerations highlight the need for a decentralized approach that leverages off-chain computation for data collection and verification, and on-chain verification to optimize the performance and scalability of blockchain-based AI marketplaces.
Decentralized oracles are critical in bridging blockchain technology with the external world to validate transactions. They present untapped potential for verifying AI models in marketplaces. By bridging the digital and physical realms, oracles can conduct rigorous assessments of AI models’ claims, ensuring they meet high standards before being made available. This paper explores a novel approach as shown in Fig. 2 that integrates zk-SNARKS on Chainlink’s [10] decentralized oracle network with blockchain to verify AI models. This approach could revolutionize the development and distribution of personalized AI services by enhancing trust in blockchain-enabled AI marketplaces. This approach has practical applications across various sectors that require verifiable computation, such as finance, healthcare, education and supply chain management, where accurate AI model predictions are critical and transparency is paramount. By implementing such a solution, we can create a more open, equitable, and reliable AI marketplace, driving the next wave of advancements in AI technology.
1.1 Contributions
This paper addresses the challenges of secure and efficient verification of personalized AI models in a blockchain-enabled AI marketplace. We present a comprehensive study using zk-SNARKs and Chainlink oracles. The key contributions of this paper are as follows:
- A novel comprehensive framework that leverages decentralized oracles (Chainlink) to validate unverified data from off-chain data sources for zk-SNARK proof verification, ensuring transparent and trustless verification of AI models on blockchain while preserving model privacy.
- A working implementation that integrates zk-SNARKs with Chainlink oracles, demonstrating their practical use in AI model verification scenarios.
- Analysis of the efficiency and resource consumption of zk-SNARK proof generation and verification to identify key areas for optimization.
- Analysis of the computational costs such as transaction fees and LINK token costs associated with zk-SNARK verification’s, providing insights into the costs involved.
This article is organised as follows. Section II provides an overview of relevant work, emphasising current research on verification of AI models in decentralized settings. Section III covers the system architecture and is divided into four subsections: A, B and C. Subsection A describes the method used to generate a secure and evaluation proof. Subsection B describes the method used to verify model inference while subsection C provides an overview of the proposed framework, D describes the proposed system model. Section IV describes the experimental setup, whereas Section V presents the results and their interpretation. Finally, in Section VI, we summarise our findings and conclusions and outline areas for further research.
2 Literature Review
Recent advances in AI models have led to significant progress in various decentralized systems, particularly in the integration of AI with blockchain technology. This development has huge potential for revolutionizing various industries and domains [11]. The benefits of this integration as highlighted by [12] and [13] include improved system performance and a more equitable development of AI. Furthermore, various techniques and applications of decentralized AI, such as decentralized machine learning (ML) frameworks and distributed AI marketplaces are explored in [14].
Traditional trust mechanisms for ensuring the trustworthiness of AI models have been extensively researched, with various approaches proposed. Key issues include transparency and interpretability [15], robustness and fairness [16], uncertainty quantification [17], and causal reasoning [18]. Transparency and interpretability are crucial for building trust in AI models and making the decision-making process understandable to humans. Techniques such as model visualization, saliency maps, Local Interpretable Model-agnostic Explanations (LIME), and SHapley Additive exPlanations (SHAP) support these goals [15]. Robustness and fairness are also vital components of trustworthy AI systems, with techniques like adversarial training and data augmentation enhancing robustness against attacks, while debiasing algorithms and fairness constraints mitigate discriminatory biases [16]. Uncertainty quantification, using methods such as Bayesian neural networks, ensemble methods, and conformal prediction, provides a measure of confidence in AI model predictions, particularly important in critical domains such as healthcare and autonomous systems [17]. Causal reasoning, facilitated by tools such as causal inference, structural causal models, and counterfactual reasoning, is essential for achieving a more interpretable and robust decision-making framework in AI models [18].
Despite these multi-faceted strategies for developing trustworthy centralized AI systems, traditional trust mechanisms often fail to preserve data privacy and confidentiality in decentralized systems, where data is replicated across multiple nodes. In addition, decentralized systems face scalability and performance limitations, making it challenging to handle large-scale applications and high transaction volumes using traditional centralised approaches. Major challenges of traditional trust mechanisms in decentralized environments include the lack of a central authority, identity verification issues, Sybil attacks, scalability and consistency issues, and legal and regulatory uncertainty [19], [20], [21].
The landscape of AI has entered a new era with the advent of blockchain-enabled AI marketplaces. These marketplaces enable individuals and organisations to decentralise AI models’ sharing, trading, and utilisation, in a manner that democratises access to advanced AI technologies [6]. Despite their numerous benefits, decentralized marketplaces present unique challenges for authenticating and verifying AI models. The diversity and volume of AI models exchanged on these platforms render traditional centralised verification and validation processes impractical. Consequently, there is an urgent need for novel approaches to perform these crucial functions efficiently and dependably. The Neuromation platform is an AI marketplace that leverages synthetic data for training models, substantially reducing the time and cost associated with developing AI models. Additionally, they possess a distributed computing platform designed for model training
Chainlink is a pioneering decentralized oracle network that seamlessly connects smart contracts on blockchains with off-chain data and systems [10]. As a secure middleware, it enables blockchain applications to reliably access and leverage real-world information, unlocking a vast array of innovative use cases. At its core, Chainlink employs a decentralized network of independent oracle nodes that retrieve and deliver data to smart contracts, mitigating single points of failure [22]. Through crypto-economic incentives and penalties, it ensures the reliability and correctness of oracles, even against well-resourced adversaries.
Chainlink enhances blockchain scalability and efficiency by enabling secure off-chain computations and data processing, which are then integrated on-chain, facilitating the development of advanced hybrid smart contracts [22]. Through its confidentiality measures and trust minimization achieved via decentralization and cryptographic assurances, Chainlink acts as a secure conduit between blockchains and real-world data, driving the evolution and broader adoption of sophisticated decentralized applications across various sectors [23]. Recent research suggests that the integration of AI and blockchain could be further enhanced with Chainlink [24], which ensures the integrity and transparency of data inputs used in AI models, thereby providing a robust foundation for the ethical and verifiable deployment of AI technologies.
Verification and validation (V&V) are necessary quality assurance procedures for preserving the trust and dependability of AI systems. Verification ensures that the AI model was implemented accurately and behaved as intended per its mathematical description [25]. It is comparable to "building the model properly." Validation, conversely, guarantees that the AI model satisfies the requirements of the context or problem it was designed to solve – it involves "building the right model". Despite their robust capabilities, AI models occasionally generate inaccurate predictions and manifest unintended behaviour.
These risks may be exacerbated in high-stakes domains such as healthcare or finance, where errors may result in severe adverse outcomes, from incorrect medical diagnoses to substantial financial losses. This makes V&V processes essential for the safety and dependability of AI systems, assuring that their decisions are accurate, trustworthy, and dependable [26]. As these models take on increasingly complex duties, their verification and validation become paramount [27]. These procedures are essential for maintaining confidence in AI systems because they help identify and mitigate risks associated with inaccurate predictions or biased outcomes [26].
A key challenge in AI is verifying personalized, closed-source models in a way that safeguards sensitive information, preserves intellectual property, and enhances transparency, as traditional methods often rely on trust or costly re-evaluation. To this end, zero-knowledge proofs have emerged as a powerful tool for privacy-preserving authentication [28]. This cryptographic technique allows one party to prove to another that a given statement is true, without revealing any additional information about the statement. Initially, the zk proofs were designed to be interactive and could not be re-verified multiple times by other validators without creating new interactions. This led to the development of Non-Interactive Zero-knowledge Proofs (NIZKPs) [29], allowing the zero-knowledge proofs to be re-verified by multiple parties.
There are several popular implementations of zero-knowledge proofs, including zk-SNARKs [30], Zero-Knowledge Scalable Transparent Argument of Knowledge (zk-STARKs) [31] and bulletproofs [32]. One of the primary differences between zk-SNARKs, zk-STARKs and bulletproofs is the trusted setup process. An initial trusted setup process is required for zk-SNARKs and it’s not required by zk-STARKs and bulletproofs. zk-STARKs have larger proof sizes, resulting in higher verification costs and storage requirements on the blockchain. Bulletproofs have smaller proof sizes but require interactive verification, which is less practical for decentralized systems. Beyond zero-knowledge proof systems, there exist other cryptographic techniques for verifying computations with privacy guarantees, such as Homomorphic Encryption (HE), Verifiable Computing (VC) [33] and Secure Multiparty Computation (MPC) [34]. While these methods are widely used for general secure computation and data confidentiality, they are not specifically tailored for AI-based tasks.
For this research, we consider zk-SNARKS, despite their reliance on a trusted setup. zk-SNARKs achieves significantly smaller proof sizes compared to zk-STARKs and bulletproofs, resulting in smaller shorter verification times and less gas cost [35]. In the context of personalized AI models, zk-SNARKs can be leveraged to verify the correctness of a model’s predictions without disclosing the underlying model parameters or training data [36]. This is particularly relevant when AI models are deployed in environments handling sensitive user data.
The US Department of Energy implemented a secure neural network verification system using zk-SNARKs for Nuclear Treaty Verification [37]. This proposed system allows to verify the neural network output, input hash and Rivest–Shamir–Adleman (RSA) signature with zk proof, enabling a secure, adaptable way to disclose sensitive data on nuclear materials and facilities. The work by [38] investigates verifiable evaluation attestations using zk-SNARKs, enabling independent validation of model performance claims without exposing the models’ internal weights or outputs. Here the authors employ a "predict, then prove" strategy, where models are converted to a standard format, evaluated on benchmark datasets, and proofs of correct inference are generated. These proofs are aggregated into attestations that can be independently verified.
The authors in [39] presented a practical approach to verify ML model inference for a full-resolution ImageNet model using zk-SNARKs and explore other scenarios such as verifying MLaaS predictions and accuracy. The zk-SNARKs enabled a non-interactive way to verify ML model execution and achieved 79% accuracy. A scheme called zkCNN was proposed to prove the accuracy of a convolution neural network (CNN) model’s predictions using public dataset to others without revealing sensitive information about the model [40].
Based on our literature review, it is evident that technologies like zk-SNARKs can help address trust and AI model privacy issues in this context [37], [38], [39], [40]. However, using zk-SNARKs to verify AI models’ integrity and performance claims on blockchain-based marketplaces presents several challenges. Verifying claims of AI models using zk-SNARKs often requires external data inaccessible within the blockchain [9]. Similar to the work in [40], models can be trained on public datasets and to prove the model accuracy claims, access to high quality public datasets are required. The compactness of zk-SNARK verification proofs is offset by the substantial resources needed for proof verification, potentially causing bottlenecks [8], [41] especially when the blockchain handles multiple transactions and interactions simultaneously. Secondly, the computational intensity of zk-SNARK proofs involves complex mathematical computations that are both time-consuming and costly [42] especially in terms of blockchain gas fees on platforms like Ethereum [8]. These considerations highlight the need for a decentralized approach that leverages off-chain computation for data collection and verification and on-chain zk verification to optimize the performance, scalability and enhancing trust within blockchain-based AI marketplaces.
This paper addresses existing gaps by proposing a novel framework that leverages zk-SNARKs integrated with Chainlink oracles to verify AI model performance claims on blockchain platforms. Our approach allows for the verification of personalized AI models without disclosing sensitive information, preserving intellectual property and enhancing transparency. We demonstrate our approach with a linear regression model predicting Bitcoin prices using on-chain data, verified on the Sepolia testnet.
<details>
<summary>x1.png Details</summary>
### Visual Description
\n
## Diagram: Secure and Trusted AI Evaluation Proof
### Overview
This diagram illustrates a system for generating a secure and trusted evaluation proof for AI models, utilizing blockchain and decentralized oracle networks. It details the flow of data and processes involved in creating, verifying, and deploying AI models in a decentralized marketplace. The diagram is divided into two main sections: "A: Generate a secure and trusted evaluation proof" and "B: Verifying model inference on decentralized oracle networks using zkSNARK".
### Components/Axes
The diagram consists of several interconnected components, visually separated into "On-chain" and "Off-chain" sections. Key components include:
* **On-Chain Data (1):** Represented by a cylinder database.
* **Personalized AI Model (2):** A complex network of nodes.
* **Generation of Zero Knowledge proofs (3):** Includes a developer and a zkSNARK module.
* **Blockchain (4):** A central block structure.
* **Decentralized AI Marketplace (5):** Depicts Sellers and Buyers.
* **Decentralized Oracle Network (7):** A network of nodes labeled "SE" (Sandbox Execution).
* **API providers for on-chain and off-chain data (9):** Represented by a cylinder database.
* **Smart Contract (6 & 12):** A hexagonal shape.
* **Sandbox Execution (8):** A module with a computer icon.
* **Data Cleaning, Data Normalization, Correlation Analysis:** Process blocks.
* **Training Data:** A rectangular block.
* **Validated Proof shared on the blockchain:** An arrow pointing to the blockchain.
* **Oracle request, Computation request, zk verification:** Arrows indicating data flow.
* **Request, Result:** Labels on arrows.
* **The new proof is matched against the validated proof previously shared on the blockchain (14):** Text block.
### Detailed Analysis or Content Details
**Section A: Generate a secure and trusted evaluation proof**
1. **On-Chain Data:** Data is extracted from a cylinder database.
2. **Data Processing:** The data undergoes Data Cleaning, Data Normalization, and Correlation Analysis.
3. **Training Data:** The processed data is used to generate Training Data.
4. **Personalized AI Model:** The Training Data is used to create a Personalized AI Model, represented as a complex network.
5. **Validated Proof:** A Validated Proof is generated from the AI Model and shared on the Blockchain.
**Section B: Verifying model inference on decentralized oracle networks using zkSNARK**
6. **Smart Contract:** A request is sent to the Smart Contract.
7. **Decentralized Oracle Network:** The request is forwarded to the Decentralized Oracle Network, consisting of multiple nodes labeled "SE" (Sandbox Execution).
8. **Sandbox Execution:** Each node performs Sandbox Execution.
9. **API Providers:** The Sandbox Execution utilizes API providers for on-chain and off-chain data.
10. **Result:** A result is generated and sent back to the Smart Contract.
11. **zk Verification:** Zero-Knowledge (zk) verification is performed.
12. **Smart Contract:** The Smart Contract receives the result.
13. **Blockchain:** The result is recorded on the Blockchain.
14. **Verification:** The new proof is matched against the validated proof previously shared on the blockchain.
**Flow of Data:**
* Data flows from On-Chain Data (1) through Data Processing to Training Data.
* Training Data is used to create a Personalized AI Model (2).
* A Validated Proof is generated and shared on the Blockchain (4).
* Requests are sent to the Smart Contract (6).
* The Smart Contract triggers the Decentralized Oracle Network (7).
* The Oracle Network utilizes API providers (9) and Sandbox Execution (8).
* Results are sent back to the Smart Contract (12) and recorded on the Blockchain (13).
* The new proof is verified against the previously validated proof (14).
### Key Observations
* The system leverages both on-chain and off-chain components.
* zkSNARKs are used for privacy-preserving verification.
* The Decentralized Oracle Network provides a secure and reliable way to access external data.
* The Blockchain serves as a trusted source of truth for the validated proof.
* The diagram emphasizes the importance of data cleaning and normalization.
* The "SE" label on the Oracle Network nodes suggests a sandboxed environment for execution.
### Interpretation
This diagram outlines a sophisticated system for deploying and verifying AI models in a decentralized environment. The use of blockchain ensures transparency and immutability, while the Decentralized Oracle Network provides access to real-world data. zkSNARKs enhance privacy by allowing verification without revealing the underlying data or model. The system aims to address the challenges of trust and security in AI, enabling a more reliable and transparent AI marketplace. The separation of on-chain and off-chain components allows for scalability and flexibility. The diagram suggests a focus on creating a secure and trusted evaluation proof, which is crucial for ensuring the integrity of AI models deployed in a decentralized setting. The matching of the new proof against the validated proof is a critical step in maintaining the system's security and reliability. The use of Sandbox Execution indicates a strong emphasis on security and preventing malicious code from affecting the network. The overall architecture promotes a secure, transparent, and verifiable AI ecosystem.
</details>
Figure 3: Proposed verification framework.
3 Methodology and System Design
This section describes the methodology as shown in Fig. 3 for verifying the performance claims of a personalized AI model without revealing weights and are trained on on-chain and user-specific data to predict Bitcoin prices. The verification process is computed on Chainlink’s decentralised oracle network using zk-SNARKs. We divide the section into two parts and explain these parts with respect to Fig. 3. In Part A, we provide the system overview of our proposed framework. Part B outlines the steps to generate a secure and trusted evaluation proof and Part C describes the verification process for the model inference on a decentralized oracle network using zk-SNARKs.
3.1 System Overview
Trust is a major concern for users in the Web3 domain, particularly on the blockchain. Trust issues also extend to the blockchain-enabled AI marketplace, where the credibility of developers’ performance claims for personalized AI models is questioned. The blockchain-enabled AI marketplace combines on-chain and off-chain elements to enhance the verifiability of verifications. The framework represented in Fig. 3 is specifically designed to enable personalized AI model performance verification using zk-SNARKs. The interaction between on-chain smart contracts and off-chain Chainlink oracles is crucial for the functioning of the blockchain-enabled AI marketplace. The interaction guarantees that the data, computation, and proof validation are carried out securely and efficiently. We analyze the on-chain data from external API providers and eliminate inaccurate data points. The data is carefully scaled to uncover and examine the connections between important data points in the model’s output. After the training and testing of the personalized AI model, developers generate zk-SNARK proofs to verify the AI model’s claim without exposing sensitive data such as model weights. These verifiable proofs are shared on the blockchain.
Prior to purchasing the personalized AI model, the buyer demands proof to verify the performance claim of the personalized AI model. The decentralized oracle network is used for verification using the Chainlink Functions, as requested by the blockchain. The Chainlink nodes facilitates the coordination of data acquisition from external API providers for on-chain data and the execution of computations. Each node in the Chainlink carries out sandboxed execution of the provided source code to ensure transparency. The aggregated results are sent to the smart contract using Chainlink’s Off-Chain Reporting (OCR) protocol [43]. The smart contract on Sepolia receives the aggregated result and zk-SNARK proof.
The blockchain verifies the proof using stored verification keys and updates the state of the blockchain based on the verification outcome. Verified proofs are stored on-chain for future reference, ensuring a transparent and tamper-proof record of all computations. This framework provides a practical approach to verifying personalized AI models. Incorporating zk-SNARK ensures the privacy of model weights during verification, enhancing trust and transparency in AI model marketplaces. The integration of zk-SNARKs into Chainlink functions facilitates secure and reliable data fetching and computation, offering a robust AI model verification framework that can be implemented in real-world scenarios.
To summarize the interactions in the proposed verification framework, Fig. 3 represents the framework for verifying personalized AI model performance using zk-SNARKs. In Step 1, The process begins with developers training personalized AI models, followed by data cleaning, normalization, and correlation analysis. In Step 2, developers generate zk-SNARK proofs to verify model performance claims without revealing sensitive data and upload these proofs to the blockchain. In Step 3, buyers initiate verification requests, which the decentralized oracle network processes by fetching data from external APIs and performing zk-SNARK verification in a sandboxed environment. In Step 4, the Chainlink oracles communicates results back to the blockchain smart contract via Chainlink’s Off-Chain Reporting protocol. In Step 5, the blockchain then validates the proofs using stored verification keys and updates the state of the decentralized marketplace, ensuring a transparent and tamper-proof record of all zk-SNARK verifications.
3.2 Generate a Secure and Evaluation Proof
3.2.1 Personalized AI model - Introduction to Personalization
Personalized AI models provide customized predictions by utilizing on-chain data and user data. For example, the model can be personalized when predicting Bitcoin prices to consider the user’s unique trading patterns, preferences, and other data points affecting their investment choices.
Data Collection:
Developers acquire on-chain data in two ways. The first method involves collecting and processing raw on-chain data from the public Bitcoin blockchain. The second method uses external application programming interface (API) providers where the on-chain data is already preprocessed and ready to use. We obtained on-chain data from 2016 to 2023 from API providers such as [44], [45]. With the on-chain data collected from these sources, we categorized and analyzed metrics from each category against Bitcoin’s price. We also use user-specific data such as transaction history and wallet activity. The following metrics are obtained from the on-chain data; block size, block height, transaction count, daily active addresses, miners revenue, miner fees, miner to exchanges, total new addresses, transactions rate, transfers count, hash rate, transactions difficulty, transfer rate, wallets address with greater than 1, 10 and 100 coins, exchange deposits, exchange withdrawals and total addresses.
Data Analysis:
The on-chain data closely correlating to the bitcoin price are identified. This step involves using a Pearson and Spearman correlation analysis to understand the linear and non-linear relationship between the on-chain datasets and the bitcoin price. The Pearson correlation can be represented by equation (1)
$$
r=\frac{\sum_{i=1}^{n}(x_{i}-\bar{x})(y_{i}-\bar{y})}{\sqrt{\sum_{i=1}^{n}(x_{%
i}-\bar{x})^{2}\sum_{i=1}^{n}(y_{i}-\bar{y})^{2}}} \tag{1}
$$
where:
- $x_{i}$ is the $i$ -th data point of features of on-chain data
- $y_{i}$ is the $i$ -th data point of bitcoin price
- $\bar{x}$ is the mean of the $x$ values
- $\bar{y}$ is the mean of $y$ values
- $n$ is the total number of data points
The Spearman rank correlation coefficient [46] is a nonparametric measurement correlation used to evaluate the monotonic relationship between two variables.
$$
\rho=1-\frac{6\sum{d_{i}}^{2}}{n({n}^{2}-1)} \tag{2}
$$
In (2), the difference between the ranks of the $i$ -th pair of values is represented by $d_{i}$ and $n$ represents the total number of data points.
Pearson correlation coefficients are used to quantify the linear connection between variables. In contrast, Spearman correlation coefficients are only applicable to monotonic connections, in which variables tend to move in the same or opposite direction but not necessarily at the same rate. In a linear relationship, the rate is constant.
We re-scale the data between the range [0,1]. The normalization value is calculated using equation (3).
$$
z=\frac{x_{i}-\min(x)}{\max(x)-\min(x)} \tag{3}
$$
By conducting correlation analysis, we can pinpoint important on-chain metrics that can be incorporated into advanced predictive algorithms. Conversely, we can also identify metrics that could be more relevant and should be considered.
Introduction to zk-SNARKs:
A zk-SNARK allows a prover to convince a verifier that they know a solution to a computational problem without disclosing the solution itself. These proofs are short and fast to verify, and they do not require ongoing interaction between the prover and the verifier after the initial setup. A zk-SNARK system comprises three core algorithms: Generation (Gen), Prover (P) and Verification (V).
Non-Interactive Zero-Knowledge Argument
The arithmetic circuits in zk-SNARKs play a critical role in representing the computational problem that the prover aims to demonstrate to the verifier that it has been solved correctly. In the context of the non-interactive zero-knowledge argument, let $C$ be an arithmetic circuit such that $C:F^{n}× F^{n^{\prime}}→ F^{l}$ . Here, $F$ denotes a finite field and $F^{n}$ represents a vector space of dimension $n$ over the finite field $F$ . Similarly, $F^{n^{\prime}}$ and $F^{l}$ indicate vector spaces of dimensions $n^{\prime}$ and $l$ over $F$ , respectively. The NP language $L$ is defined as the set of statements $x$ in $F^{n}$ for which there exists a valid witness $w$ in $F^{n^{\prime}}$ . This is represented by the relation $R$ defined as $R:=\{(x,w)∈ F^{n}× F^{n^{\prime}}\}$ , where $w$ is the witness and $x$ is the statement.
A non-interactive zero-knowledge argument for the relation $R$ consists of the triple of polynomial-time algorithms: Generation (Gen), Prover (P), and Verification (V).
- Generation (Gen): Produces a common reference string (crs) and a private verification state.
$$
(\text{crs})\leftarrow\text{Gen}(1^{n},R)
$$
- Prover (P): Produces a proof $\pi$ for a statement $x$ using a witness $w$ .
$$
\pi\leftarrow\text{P}(\text{crs},x,w)
$$
- Verification (V): Verifies the proof $\pi$ for the statement $x$ .
$$
\text{V}(\text{crs},x,\pi)\rightarrow\{0,1\}
$$
Properties of zk-SNARKs
The following properties [47] must be met by a non-interactive zero-knowledge proof $\pi$ for the relation $R$ :
- Completeness: For a statement $x∈ F^{n}$ with a witness $w∈ F^{n^{\prime}}$ such that $(x,w)∈ R$ , the prover acting honestly always produces a valid proof $\pi$ . This proof should be sufficient to convince an honest verifier. The completeness of the non-interactive zero-knowledge proof can be expressed as follows [48]:
$$
\Pr\left[\begin{array}[]{c}(\text{crs})\leftarrow\text{Gen}(1^{n},R)\\
\pi\leftarrow\text{P}(\text{crs},x,w)\\
\text{V}(\text{crs},x,\pi)=1\text{ if }(x,w)\in R\end{array}\right]=1 \tag{4}
$$
- Soundness: When an adversary attempts to deceive by providing a proof $\pi$ for a false statement $x∉ R$ , the verification algorithm V is designed to have a high probability of rejecting the proof. Any evidence $\pi$ offered by an adversary will be rejected with a high probability due to the soundness requirement, which ensures that $x$ must be in the relation $R$ [28]:
$$
\Pr\left[\begin{array}[]{c}(\text{crs})\leftarrow\text{Gen}(1^{n},R)\\
(x,\pi)\leftarrow\mathcal{A}(\text{crs})\\
\text{V}(\text{crs},x,\pi)=1\text{ and }(x,w)\notin R\end{array}\right]\leq%
\text{negl}(n) \tag{5}
$$
Furthermore, suppose there is an extractor $\mathcal{E}$ that can generate the witness $w←\mathcal{E}_{\mathcal{A}}(\text{crs})$ based on the output of an adversary $\mathcal{A}$ , which produces a valid argument $(x,\pi)←\mathcal{A}(\text{crs})$ :
$$
\Pr\left[\begin{array}[]{c}(\text{crs})\leftarrow\text{Gen}(1^{n},R)\\
(x,\pi)\leftarrow\mathcal{A}(\text{crs})\\
w\leftarrow\mathcal{E}_{\mathcal{A}}(\text{crs})\\
\text{V}(\text{crs},x,\pi)=1\text{ and }(x,w)\notin R\end{array}\right]\leq%
\text{negl}(n) \tag{6}
$$
- Zero-Knowledge: This characteristic ensures that the verifier only gains knowledge of the statement’s truth. In zk-SNARKs, Tau refers to the trusted setup parameter generated during the initial phase, creating a secure cryptographic environment. The Powers of Tau (PoT) ceremony generates these parameters, which are necessary for generating and verifying zk-SNARK proofs, ensuring privacy. In the Phase 2, the crs is further refined to support the specific zk-SNARK application, introducing additional complexity as it tailors the parameters to the operations of the AI model being verified. Together, PoT and Phase 2 form the backbone of the trusted setup, ensuring a robust and reliable foundation for zk-SNARK operations. Without knowing the witness $w$ , the proof or argument $\pi$ for a valid assertion $x$ can be simulated using a polynomial-time procedure known as a simulator. Simulator 1 $(S_{1})$ generates a simulated proof based on the crs and the random Tau parameter. This demonstrates that the proof system can function without accessing private data thus maintaining the zero-knowledge property. Simulator 2 $(S_{2})$ simulates the zk-SNARK proof using the input, output pair and a random Tau. This confirms that the system can generate valid proofs without revealing sensitive information, completing the zero-knowledge simulation. The zero-knowledgeness can be expressed as follows [48]:
$$
\Pr\left[\begin{array}[]{c}(\text{crs})\leftarrow\text{Gen}(1^{n},R)\\
(x,w)\leftarrow\mathcal{A}(\text{crs})\\
\pi\leftarrow\text{P}(\text{crs},x,w)\\
\mathcal{A}(\pi)=1\end{array}\right]=\Pr\left[\begin{array}[]{c}(\text{crs},%
\tau)\leftarrow S_{1}(1^{n},R)\\
(x,w)\leftarrow\mathcal{A}(\text{crs})\\
\pi\leftarrow S_{2}(\text{crs},x,\tau)\\
\mathcal{A}(\pi)=1\end{array}\right] \tag{7}
$$
3.2.2 Conversion of Linear Regression Model to zk-SNARK Circuit for Validation
We use zk-SNARKs to generate verifiable computations on-chain of the model without revealing its weights. The linear regression model is converted into a zk-SNARK circuit to represent the model’s internal operations. The following steps are used in converting the linear regression model into a zk-SNARK circuit:
Step 1: Model Representation
The developer trains the personalized AI model, specifically a linear regression model that predicts Bitcoin prices based on historical on-chain data. The model takes various features (independent variables) from the on-chain data and user-specific data, such as transaction history and wallet activity of the user, and predicts the price (dependent variable) of Bitcoin. The linear regression model is represented using (8):
$$
y=a_{0}+a_{1}x_{1}+a_{2}x_{2}+\ldots+a_{n}x_{n}+C \tag{8}
$$
where:
- $y$ is the predicted bitcoin price.
- $x_{i}$ are the features of on-chain and user-specific data.
- $a_{i}$ are the coefficients (weights) learned during training.
- $C$ is the intercept.
Step 2: Arithmetic Circuit Construction
The linear regression model equation is converted into an arithmetic circuit to permit proving zk-SNARK based computational statements. Each mathematical operation in the linear regression model is mapped to a multiplication and addition gate in zk-SNARKs. For example, the operation $a_{1}x_{1}$ is handled by multiplication gates and sum $a_{0}$ + $a_{1}x_{1}$ is handled by addition gates. The final output $y$ is computed by using addition gates adding all terms together. This process transforms the linear regression equation into an arithmetic circuit that is compatible with zk-SNARKs.
Step 3: QAP Conversion
The models arithmetic circuit are converted into a QAP, providing a framework for zk-SNARKs to check the correctness of the operations in the arithmetic circuit. A QAP for a function $f$ is defined by three sets of polynomials $\{v_{i}(x)\},\{w_{i}(x)\},\{y_{i}(x)\}$ and a target polynomial $t(x)$ .
For an arithmetic circuit $C$ with $m$ gates:
$$
p(x)=\left(\sum_{i=0}^{m}a_{i}\cdot v_{i}(x)\right)\cdot\left(\sum_{i=0}^{m}a_%
{i}\cdot w_{i}(x)\right)-\left(\sum_{i=0}^{m}a_{i}\cdot y_{i}(x)\right) \tag{9}
$$
where $t(x)$ divides $p(x)$ and $a_{i}$ represents the coefficients of the polynomials.
The QAP introduces constraints that must be satisfied to ensure all operations in the arithmetic circuit are represented correctly in zk-SNARK form. The complexity of these QAP constraints increases with larger number of features in the linear regression model. As the complexity of the AI models increases, it will require more number of gates to represent model internal operations, leading to higher computational resources and longer proof generation times.
Step 4: zk-SNARK Proof Generation and Verification
The prover generates a proof $\pi$ demonstrating they know $\{a_{i}\}$ satisfying the Quadratic Arithmetic Program (QAP) equations:
$$
\pi=(A,B,C) \tag{10}
$$
where:
$$
A=\sum_{i=0}^{m}a_{i}\cdot g^{v_{i}(s)},\quad B=\sum_{i=0}^{m}a_{i}\cdot g^{w_%
{i}(s)},\quad C=\sum_{i=0}^{m}a_{i}\cdot g^{y_{i}(s)}
$$
The polynomials ${v_{i}(s)},{w_{i}(s)},{y_{i}(s)}$ represent the QAP for the arithmetic circuit. These polynomials are evaluated at a secret value $s$ . The components of the zk-SNARK proof are represented by $A,B,C$ and the generator of a cryptographic group by $g$ , which is used to generate all the elements of the group through its powers. The verifier checks the proof by ensuring:
$$
e(A,B)=e(g,C)\cdot e(g^{t(s)},g) \tag{11}
$$
where $e(A,B)$ represents the bilinear pairing function used for verification and $t(s)$ is the target polynomial evaluated at the secret value $s$ .
3.3 Verifying Model Inference on Decentralized Oracle Network Using zk-SNARKs
In this paper, we use the Chainlink Decentralized Oracle Network (DON), hereafter referred to as Chainlink oracles, to perform off-chain computations and relay data to the blockchain. The blockchain component in our framework is represented by the Sepolia testnet, which serves as a proxy for a production blockchain environment. Chainlink Functions enable smart contracts to access a computing infrastructure that is trust-minimized. Smart contracts can access on-chain and off-chain data from APIs and perform personalized computations. By seamlessly integrating these functions with the Sepolia testnet, we can efficiently execute zero-knowledge (zk) verification computations on chainlink’s decentralized oracle network, ensuring that verified results are returned to the blockchain.
Smart contracts utilize the Chainlink nodes to retrieve data from external APIs by sending requests for source code. Every node in the Chainlink carries out the code within a secure and sandboxed execution, efficiently handling the required computations. The zk-SNARK circuits use the obtained data to perform computations without disclosing confidential details. The process yields zk-SNARK proofs that showcase accurate computation using input data. The results are sent to the Sepolia testnet through smart contracts after completing the necessary proofs. These smart contracts validate the proofs and update the state of the blockchain. Once the results have been verified, they can be easily accessed in other smart contracts, ensuring secure and reliable interactions.
4 Experimental Setup
The experimental setup used in our study consists of two phases: the proof generation phase and the proof verification phase. The proof generation phase involves an in-depth exploration of the processing environment and configuration details pertinent to a personalized AI model’s zk proof generation process. The proof verification phase delves into the implementation steps associated with deploying zero-knowledge proof on the blockchain and verifying zero-knowledge proofs using Chainlink oracles.
4.1 Proof Generation Phase
The proof generation setup uses an NVIDIA Jetson TX2, a cutting-edge device known for its high computational power and energy efficiency. The specifications of NVIDIA are listed in Table 1.
| CPU | 6 ARM Cortex-A57 |
| --- | --- |
| GPU | 256-core NVIDIA Pascal |
| Memory | 8GB LPDDR4 |
Table 1: Nvidia Jetson TX2 specifications
We selected this device due to its suitability for AI applications, which are known to require significant computational resources. Our objective was to develop zk-SNARK circuits designed to generate zero-knowledge proofs. These circuits are specifically tailored for a linear regression model, utilizing characteristics obtained from the on-chain data of Bitcoin as a CSV file. The linear regression model coefficients, including the model weights, were saved in a JSON file. We used Python scripts to automate the process of generating circuit files. These scripts received the JSON data and produced multiple Circom files, each representing a distinct number of weights.
Creating and confirming proofs involves building zk circuits using the Circom programming language, generating witnesses, and then proving and checking the proofs using the Snarkjs library. The automated script managed the complete procedure, encompassing compilation, witness production, contribution to the ceremony, preparation for phase 2, zkey generation, and proof generation and verification. We used the Circom tool to generate a smart contract-based verifier that allows proofs to be verified on the blockchain. Remix was used to deploy the Verifer smart contract on the blockchain. The trusted setup was conducted by a consortium of stakeholders, including model developers, auditors and decentralized oracle providers. This collaborative approach ensures trust in the setup process and mitigates the risk of a single point of failure.
4.2 Proof Verification Phase
For this experiment, we chose the Sepolia testnet because it is widely used among developers and one of the few testnets supported by Chainlink. The experimental findings are relevant and applicable to live production settings like the Ethereum main network. We deployed the verifier smart contract on the testnet for zk verification purposes, ensuring the thoroughness of our testing process.
We set up Chainlink Functions to integrate the decentralized oracle network to the Sepolia testnet. We cloned the Chainlink Functions starter kit from the official GitHub repository [49].
This configuration offered the essential resources to interact with the blockchain and Chainlink oracle networks. Subsequently, we modified the Functions request configuration file to explicitly define the source code for API calls and perform computations based on the smart contract request. We established the environment variables using encrypted data for access. This process involved establishing the environment variable file’s password and configuring the environment variable by specifying the key and value. We used four keys to setup the experiment:
- A private key obtained from the MetaMask wallet.
- An Remote Procedure Call (RPC) URL derived from the Alchemy website for the Sepolia testnet.
- An API token for GitHub.
- An API for the blockchain explorer Etherscan
<details>
<summary>extracted/6340811/12.png Details</summary>
### Visual Description
\n
## Screenshot: Deployment Confirmation Log
### Overview
This image is a screenshot of a command-line interface (CLI) displaying a log of a smart contract deployment process. The log indicates successful deployment and verification of a contract named "FunctionsConsumer" on the Ethereum Sepolia network.
### Components/Axes
There are no axes or traditional chart components. The content consists of textual output from a deployment script.
### Detailed Analysis or Content Details
The log contains the following information:
1. "Waiting 2 blocks for transaction 0x7fdca895beff7c843a02fbf7febbadd116b4201579e615d097dbd04b2e4f6ec8e2 to be confirmed."
2. "Deployed FunctionsConsumer contract to: 0xe953b197ccC443e3d8664962C1e1d04abc33701d"
3. "Verifying contract..."
4. "The contract 0xe953b197ccC443e3d8664962C1e1d04abc33701d has already been verified"
5. "Contract verified"
6. "FunctionsConsumer contract deployed to 0xe953b197ccC443e3d8664962C1e1d04abc33701d on ethereumSepolia"
The contract address is consistently reported as `0xe953b197ccC443e3d8664962C1e1d04abc33701d`. The network is identified as "ethereumSepolia".
### Key Observations
The log shows a successful deployment and verification process. The message "has already been verified" suggests a previous verification attempt for the same contract.
### Interpretation
The screenshot documents the successful deployment of a smart contract named "FunctionsConsumer" to the Ethereum Sepolia test network. The contract was deployed to the address `0xe953b197ccC443e3d8664962C1e1d04abc33701d` and subsequently verified, indicating that its source code has been confirmed to match the deployed bytecode. This is a standard practice in smart contract development to ensure transparency and security. The "Waiting 2 blocks" message indicates that the transaction requires a certain number of block confirmations to be considered final on the blockchain. The fact that the contract was already verified suggests that this might be a re-deployment or a repeated verification step.
</details>
Figure 4: Oracle functions consumer contract deployed to Sepolia.
Upon configuring the environment variables, the functions consumer contract was successfully deployed to the Sepolia testnet, as shown in Fig. 4, completing the integration with Chainlink oracles.
The consumer contract address is used to create and fund the billing subscription for Chainlink Functions, as shown in Fig. 5 using LINK tokens acquired via the Chainlink Faucet.
The Chainlink’s smart contract requests the nodes to perform zk computations and return the result. The proof size of our model is 806 bytes and the verification key size is 2922 bytes. The script runs the functions in a sandbox environment, as seen in Fig. 5 before making an on-chain transaction to ensure they are correctly configured and the fulfilment costs are estimated before making the request. As shown in Fig. 6, chain data retrieval was implemented by pushing API queries to external API providers for on-chain data utilizing the Chainlink Functions.
<details>
<summary>extracted/6340811/123.png Details</summary>
### Visual Description
\n
## Screenshot: Terminal Output - Subscription Funding Confirmation
### Overview
This image displays a screenshot of a terminal window showing the process of creating and funding a "Functions billing subscription" using the cryptocurrency LINK. The output details the subscription ID, confirmation prompt, funding transaction, and subscription information.
### Components/Axes
The screenshot consists of a series of text-based outputs from a command-line interface. There are no axes or charts present. The key elements are:
* System messages (e.g., "secp256k1 unavailable...")
* Subscription creation messages
* Confirmation prompt
* Funding confirmation message
* Subscription information block (JSON-like format)
### Detailed Analysis or Content Details
The terminal output can be transcribed as follows:
```
secp256k1 unavailable, reverting to browser version
Creating Functions billing subscription...
Created Functions billing subscription: 3053
Please confirm that you wish to fund Subscription 3053 with 2 LINK from your wallet.
Continue? Enter (y) Yes / (n) No
y
Funding subscription 3053 with 2 LINK...
Subscription 3053 funded with 2 LINK in Tx: 0x8201e5b295946017ffca3dc6880c88a79c7140179b328c2fb83fefc446961d5
Subscription Info: {
balance: '2.0 LINK',
owner: '0x4ec77d7aAB8e69c2ABF7CE3d4106415696279478',
blockBalance: '0.0 LINK',
proposedOwner: '0x0000000000000000000000000000000000000000',
consumers: [ '0xe953b197cCC443e3d8664962C1eD04abc33701d' ],
flags: '0x0000000000000000000000000000000000000000000000000000000000000000'
}
```
### Key Observations
* The system initially indicates a fallback to a browser version of secp256k1, suggesting a potential issue with the native library.
* The subscription ID is 3053.
* The subscription was funded with 2 LINK.
* The transaction hash (Tx) is `0x8201e5b295946017ffca3dc6880c88a79c7140179b328c2fb83fefc446961d5`.
* The subscription owner is `0x4ec77d7aAB8e69c2ABF7CE3d4106415696279478`.
* The subscription has a balance of 2.0 LINK and a block balance of 0.0 LINK.
* The proposed owner is the zero address (`0x0000000000000000000000000000000000000000`).
* There is one consumer address: `0xe953b197cCC443e3d8664962C1eD04abc33701d`.
* The flags are set to all zeros.
### Interpretation
This output demonstrates a successful subscription funding process. The user confirmed the funding of subscription 3053 with 2 LINK, and the transaction was completed. The subscription information provides details about the owner, balance, and associated consumer. The initial message about `secp256k1` suggests a potential dependency issue or environment configuration problem, but it did not prevent the subscription from being created and funded. The zero address for `proposedOwner` and all-zero flags are typical default values. The presence of a `consumer` address indicates that this subscription is likely linked to a specific application or service that utilizes the Functions network. The transaction hash allows for verification of the funding on the blockchain.
</details>
Figure 5: Funding the subscription
<details>
<summary>extracted/6340811/n123.png Details</summary>
### Visual Description
\n
## Screenshot: Blockchain Transaction Log
### Overview
This is a screenshot of a command-line interface (CLI) displaying a log of a blockchain transaction. The log details a request sent to a function, the transaction hash, a link to the transaction explorer, and the complete response received, including cost and data.
### Components/Axes
The screenshot displays text-based information. There are no axes or charts. The key elements are:
* **Status Messages:** "secp256k1 unavailable, reverting to browser version", "Functions request sent...", "Request... successfully fulfilled."
* **Transaction Hash:** `0xc90a46e4f58a2831b8099e6b0b17009aa906ec2a3aa3184b31703e72cdffe9b9`
* **Explorer Link:** `https://sepolia.etherscan.io/tx/0xc90a46e4f58a2831b8099e6b0b17009aa906ec2a3aa3184b31703e72cdffe9b9`
* **Request ID:** `0x2afe734c0a40bf743b3994963da56c1677efca2c5a1541016606b88996aaf7`
* **Subscription ID:** `3088`
* **Cost in Jewels:** `204179267581512`
* **Response Bytes Hexstring:** `0x526573756c743a266661c73650a636fee747261637472074696d653a20333632`
* **Error String:** `""` (empty string)
* **Return Data Hexstring:** `0x1`
* **Fulfillment Code:** `0`
### Detailed Analysis or Content Details
The log shows a function request was sent with transaction hash `0xc90a46e4f58a2831b8099e6b0b17009aa906ec2a3aa3184b31703e72cdffe9b9`. The request was successfully fulfilled, costing approximately 204179267581512 Jewels. The response includes a request ID `0x2afe734c0a40bf743b3994963da56c1677efca2c5a1541016606b88996aaf7`, a subscription ID of 3088, and a response bytes hexstring `0x526573756c743a266661c73650a636fee747261637472074696d653a20333632`. The error string is empty, indicating no errors occurred. The return data hexstring is `0x1`, and the fulfillment code is 0.
The initial message "secp256k1 unavailable, reverting to browser version" indicates a fallback mechanism was used due to an issue with the secp256k1 library.
### Key Observations
* The transaction was successful, as indicated by the "successfully fulfilled" message.
* The cost of the transaction is a large number (204179267581512 Jewels), suggesting it might be a complex operation or involve significant data.
* The response bytes hexstring appears to contain a JSON-like structure, starting with "Result:".
* The return data is a single byte with the value 1.
### Interpretation
This log provides a record of a function call on a blockchain (likely Ethereum, given the use of hex addresses and the etherscan link). The transaction involved sending a request, which was processed and returned a result. The cost in Jewels represents the gas used for the transaction. The response data suggests the function returned a value, potentially a status code or a piece of information. The initial message about secp256k1 indicates a potential dependency issue, but the transaction was still able to complete using a fallback mechanism. The link to the explorer allows for further investigation of the transaction details on the blockchain. The data suggests a successful interaction with a smart contract on the Sepolia test network.
</details>
Figure 6: Chainlink functions API and computation Output
5 Experimental Results and Analysis
<details>
<summary>extracted/6340811/Distribution.png Details</summary>
### Visual Description
## Histograms: Distribution of Blockchain Operation Times
### Overview
The image presents a 3x4 grid of histograms, each depicting the distribution of time taken for a specific operation within a blockchain system. The x-axis of each histogram represents time in milliseconds (ms), and the y-axis represents frequency. Each histogram shows the number of occurrences of operations falling within specific time intervals.
### Components/Axes
Each histogram shares the following components:
* **Title:** Indicates the specific operation being measured (e.g., "Distribution of Compile Time").
* **X-axis:** Labeled "Time (ms)". The scale varies for each histogram.
* **Y-axis:** Labeled "Frequency". The scale varies for each histogram.
* **Bars:** Represent the frequency of operations within each time interval.
The specific operations measured are:
1. Compile Time
2. Witness Time
3. Pot Time
4. Pot Ceremony Time
5. Phase Two Initiation Time
6. Z Key Generation Time
7. Phase Two Ceremony Time
8. Verification Key Generation Time
9. Proof Generation Time
10. Verifying Proof Time
11. Solidity Verifier Generation Time
12. Total Time
### Detailed Analysis or Content Details
**Row 1:**
1. **Distribution of Compile Time:** The histogram shows a peak frequency of approximately 9 around 0.26 ms. The distribution appears to be concentrated between 0.24 ms and 0.28 ms.
2. **Distribution of Witness Time:** The histogram peaks at approximately 7 around 0.205 ms. The distribution is relatively narrow, ranging from approximately 0.19 ms to 0.22 ms.
3. **Distribution of Pot Time:** The histogram peaks at approximately 11 around 3.30 ms. The distribution ranges from approximately 3.15 ms to 3.45 ms.
**Row 2:**
4. **Distribution of Pot Ceremony Time:** The histogram peaks at approximately 6 around 17.2 ms. The distribution ranges from approximately 16.8 ms to 18.0 ms.
5. **Distribution of Phase Two Initiation Time:** The histogram peaks at approximately 17.5 around 210 ms. The distribution ranges from approximately 190 ms to 220 ms.
6. **Distribution of Z Key Generation Time:** The histogram peaks at approximately 8 around 3.5 ms. The distribution ranges from approximately 3.3 ms to 3.7 ms.
**Row 3:**
7. **Distribution of Phase Two Ceremony Time:** The histogram peaks at approximately 6 around 2.425 ms. The distribution ranges from approximately 2.325 ms to 2.525 ms.
8. **Distribution of Verification Key Generation Time:** The histogram peaks at approximately 12 around 2.65 ms. The distribution ranges from approximately 2.40 ms to 2.75 ms.
9. **Distribution of Proof Generation Time:** The histogram peaks at approximately 7 around 2.65 ms. The distribution ranges from approximately 2.50 ms to 2.75 ms.
**Row 4:**
10. **Distribution of Verifying Proof Time:** The histogram peaks at approximately 3.5 around 2.45 ms. The distribution ranges from approximately 2.30 ms to 2.60 ms.
11. **Distribution of Solidity Verifier Generation Time:** The histogram peaks at approximately 4 around 2.55 ms. The distribution ranges from approximately 2.40 ms to 2.70 ms.
12. **Distribution of Total Time:** The histogram peaks at approximately 16 around 2.45 ms. The distribution ranges from approximately 2.20 ms to 2.70 ms.
### Key Observations
* **Compile Time** and **Witness Time** have the fastest operation times, measured in milliseconds.
* **Pot Ceremony Time** and **Phase Two Initiation Time** have significantly longer operation times, measured in tens to hundreds of milliseconds.
* **Total Time** has a wider distribution than most other operations, suggesting more variability.
* The distributions are generally unimodal (single peak), indicating a central tendency for each operation's duration.
### Interpretation
The histograms provide insights into the performance characteristics of different operations within a blockchain system. The varying distributions suggest that some operations are more predictable than others. The longer operation times for "Pot Ceremony Time" and "Phase Two Initiation Time" might indicate potential bottlenecks in the system. The wide distribution of "Total Time" suggests that the overall blockchain operation time is influenced by a combination of factors, and its duration can vary considerably.
The data suggests that optimizing the "Pot Ceremony Time" and "Phase Two Initiation Time" could lead to significant improvements in overall blockchain performance. The relatively consistent "Compile Time" and "Witness Time" suggest these operations are well-optimized. The "Total Time" distribution likely reflects the cumulative effect of all these operations, with the longer operations having a greater impact on the overall duration.
</details>
Figure 7: Distribution analysis for each phase of zk generation.
<details>
<summary>extracted/6340811/Avg_Time_Gen_Bar.png Details</summary>
### Visual Description
\n
## Bar Chart: Average Time for zk Generation Stages
### Overview
This image presents a bar chart illustrating the average time (in seconds) taken by different stages of Zero-Knowledge (zk) generation. The x-axis represents the stages, and the y-axis represents the average time. The chart visually compares the duration of each stage, highlighting significant differences in processing time.
### Components/Axes
* **X-axis Title:** "Stages of zk Generation"
* **Y-axis Title:** "Average Time (s)"
* **X-axis Labels (Stages):** compile\_time, witness\_time, pot\_time, pot\_ceremony\_time, phase\_two\_initiation\_time, z\_key\_generation\_time, phase\_two\_ceremony\_time, verification\_key\_generation\_time, proof\_generation\_time, verifying\_proof\_time, solidity\_verifier\_generation\_time
* **Y-axis Scale:** 0 to 200 seconds, with increments of 25 seconds.
* **Bar Color:** Light blue.
### Detailed Analysis
The chart displays the average time for each stage. The trend is highly variable, with some stages taking significantly longer than others.
* **compile\_time:** Approximately 8 seconds.
* **witness\_time:** Approximately 5 seconds.
* **pot\_time:** Approximately 3 seconds.
* **pot\_ceremony\_time:** Approximately 12 seconds.
* **phase\_two\_initiation\_time:** Approximately 185 seconds.
* **z\_key\_generation\_time:** Approximately 8 seconds.
* **phase\_two\_ceremony\_time:** Approximately 2 seconds.
* **verification\_key\_generation\_time:** Approximately 2 seconds.
* **proof\_generation\_time:** Approximately 2 seconds.
* **verifying\_proof\_time:** Approximately 2 seconds.
* **solidity\_verifier\_generation\_time:** Approximately 2 seconds.
### Key Observations
The most time-consuming stage is "phase\_two\_initiation\_time," taking approximately 185 seconds. All other stages take significantly less time, generally under 15 seconds. The stages "phase\_two\_ceremony\_time", "verification\_key\_generation\_time", "proof\_generation\_time", "verifying\_proof\_time", and "solidity\_verifier\_generation\_time" all have very similar, minimal durations (around 2 seconds). The stages "compile\_time", "witness\_time", "pot\_time", and "z\_key\_generation\_time" are also relatively short, ranging from 3 to 12 seconds.
### Interpretation
The data suggests that the "phase\_two\_initiation\_time" is a major bottleneck in the zk generation process. Optimizing this stage could lead to substantial improvements in overall zk generation time. The relatively short durations of the other stages indicate they are less critical for performance optimization. The consistent low times for the final stages (verification, proof generation, solidity verifier) suggest these are efficient processes. The large disparity between the initiation phase and the other stages warrants further investigation to understand the underlying reasons for the difference in processing time. This could be due to computational complexity, data dependencies, or algorithmic inefficiencies within the initiation phase.
</details>
Figure 8: Average time taken for each stage of zk generation.
Our experimental setup aimed to replicate real-life scenarios for deploying and verifying personalized AI models in a blockchain-enabled AI marketplace. Our study is the first to utilize the Chainlink oracle network to compute and evaluate the efficiency of the zk verification for personalized AI models. We used NVIDIA Jetson TX2 to simulate the developer’s process of generating zk-SNARK proofs for their trained personalized AI models before deployment. The zk-SNARK verification was conducted on the Sepolia testnet, and the zk verification computations were performed using Chainlink oracles to ensure secure and reliable verification.
We assess the efficiency and resource consumption of the zk-SNARK generation and verification process for personalized AI models. We also evaluate the overheads introduced by blockchain and Chainlink oracles during the verification process. This study aims to demonstrate the feasibility and effectiveness of using zk-SNARKs and Chainlink oracles to verify personalized AI models securely and efficiently.
The time analysis of zk-SNARK proof generation and verification involved examining various stages as shown in Fig. 7 and Fig. 8 and focusing on their duration and variability using a distribution analysis. The compilation process is the process of converting the linear regression model into an arithmetic circuit for zk-SNARK proof generation. The average time to compile our model is efficient and took approximately 0.256 seconds. Witness time involves creating the internal model values required for zk-SNARK proof generation. This will be used as cryptographic evidence to show the validity of the computations without revealing inputs. The witness time distribution shows low mean value of 0.202 seconds. The Power of Tau (PoT) which is a crucial phase in the zk-SNARK trusted setup process takes an average of 3.21 seconds. During this phase, cryptographic parameters are generated to ensure reliability of the zk-SNARK system, allowing it to produce proofs without revealing private information. The PoT ceremony time process involves multiple participants to contribute randomness to generate the final parameters taking 17.14 seconds. These resulting parameters are known as the common reference string (crs) and are necessary for any zk-SNARK proofs generated by the system.
Phase two initiation time was the most computationally demanding phase taking approximately 197.39 seconds as shown in Fig. 8, this is due to the complex setup of cryptographic parameters for zk-SNARKs. The time required for this stage is heavily contingent on the size and complexity of the personalized AI model in our case a linear regression model being converted into an arithmetic circuit for zk-SNARK proof generation. The complexity of QAP constraints increases with more complex AI models as they have larger number of features. This is also evident in the wide distribution of phase two initiation time, indicating significant differences in processing times adding to the longer proof generation times. The generation of the zk key takes 3.37 seconds indicating that it is relatively efficient once the cryptographic setup is completed. The verification and proof generation times are much faster than earlier stages like PoT and phase two initiation taking 2.59 and 2.45 seconds. This is due to the nature of zk-SNARKs producing succinct cryptographic proofs allowing for quick proof generation and verification irrespective of the complexity of AI models.
<details>
<summary>extracted/6340811/New_CPU.png Details</summary>
### Visual Description
\n
## Line Chart: Average CPU Usage During zk Generation Stages
### Overview
This image presents a line chart illustrating the average CPU usage (%) across different stages of zk (Zero-Knowledge) generation. The x-axis represents the stages, and the y-axis represents the average CPU usage as a percentage. A single data series, labeled "cpu (%)", is plotted as a red line.
### Components/Axes
* **X-axis Title:** Stages of zk Generation
* **Y-axis Title:** Average CPU Usage (%)
* **X-axis Labels (Stages):** compile, phase\_two\_initiation, power\_of\_tau, solidity\_verifier, verify\_proof, z\_key
* **Y-axis Scale:** Ranges from approximately 20% to 65%. The scale is linear with increments of 10%.
* **Legend:** Located in the top-right corner.
* Label: cpu (%)
* Color: Red
### Detailed Analysis
The line representing CPU usage exhibits significant fluctuations across the different stages.
* **compile:** Starts at approximately 22%.
* **phase\_two\_initiation:** Increases sharply to a peak of approximately 64%.
* **power\_of\_tau:** Decreases to approximately 52%.
* **solidity\_verifier:** Decreases slightly to approximately 50%.
* **verify\_proof:** Decreases to approximately 48%.
* **z\_key:** Increases to approximately 44%.
Specifically:
| Stage | Approximate CPU Usage (%) |
| --------------------- | ------------------------- |
| compile | 22 |
| phase\_two\_initiation | 64 |
| power\_of\_tau | 52 |
| solidity\_verifier | 50 |
| verify\_proof | 48 |
| z\_key | 44 |
The line generally slopes downward from "phase\_two\_initiation" to "verify\_proof", then slightly increases at "z\_key".
### Key Observations
* The "phase\_two\_initiation" stage consumes the most CPU resources, peaking at approximately 64%.
* The "compile" stage has the lowest CPU usage, at approximately 22%.
* CPU usage remains relatively stable between "power\_of\_tau", "solidity\_verifier", and "verify\_proof" stages, hovering around 50%.
* There is a noticeable drop in CPU usage from "phase\_two\_initiation" to "power\_of\_tau".
### Interpretation
The chart demonstrates the varying computational demands of different stages within the zk generation process. The high CPU usage during "phase\_two\_initiation" suggests this stage is the most resource-intensive, potentially involving complex calculations or data processing. The relatively lower and stable CPU usage during "power\_of\_tau", "solidity\_verifier", and "verify\_proof" indicates these stages are less computationally demanding. The slight increase in CPU usage during "z\_key" might be due to finalization or output operations.
This information is valuable for optimizing the zk generation process. Identifying the most resource-intensive stages allows for targeted optimization efforts, such as parallelization or algorithm improvements, to reduce overall processing time and resource consumption. The data suggests that focusing on optimizing "phase\_two\_initiation" would yield the most significant performance gains.
</details>
Figure 9: Average CPU usage for each stage of zk generation.
<details>
<summary>extracted/6340811/New_Memory.png Details</summary>
### Visual Description
\n
## Line Chart: Average Memory Usage During zk Generation Stages
### Overview
This line chart depicts the average memory usage (in percentage) across different stages of Zero-Knowledge (zk) generation. The x-axis represents the stages, and the y-axis represents the average memory usage percentage. A single data series, labeled "memory (%)", is plotted as a red line.
### Components/Axes
* **X-axis Title:** "Stages of zk Generation"
* **Y-axis Title:** "Average Memory Usage (%)"
* **Y-axis Scale:** Ranges from approximately 30.2% to 31.2% with increments of 0.2%.
* **X-axis Categories:** "compile", "phase_two_initiation", "power_of_tau", "solidity_verifier", "verify_proof", "z_key"
* **Legend:** Located in the top-right corner.
* "memory (%)" - Represented by a red line.
### Detailed Analysis
The line representing "memory (%)" exhibits fluctuations across the different stages.
* **compile:** Starts at approximately 30.2%.
* **phase_two_initiation:** Increases sharply to a peak of approximately 31.2%.
* **power_of_tau:** Decreases significantly to approximately 30.8%.
* **solidity_verifier:** Decreases slightly to approximately 30.7%.
* **verify_proof:** Increases slightly to approximately 30.8%.
* **z_key:** Increases to approximately 31.0%.
Here's a more detailed breakdown of the approximate values:
| Stage | Memory Usage (%) |
| ---------------------- | ---------------- |
| compile | 30.2 |
| phase_two_initiation | 31.2 |
| power_of_tau | 30.8 |
| solidity_verifier | 30.7 |
| verify_proof | 30.8 |
| z_key | 31.0 |
### Key Observations
* The highest memory usage occurs during the "phase_two_initiation" stage, reaching approximately 31.2%.
* The lowest memory usage is observed during the "compile" stage, at approximately 30.2%.
* The memory usage generally fluctuates, with no consistently increasing or decreasing trend across all stages.
* The "power_of_tau" stage shows a significant drop in memory usage after the peak at "phase_two_initiation".
### Interpretation
The chart illustrates the varying memory demands of different stages within a zk generation process. The peak during "phase_two_initiation" suggests this stage is the most resource-intensive in terms of memory. The subsequent decrease during "power_of_tau" could indicate that this stage involves different computational operations that are less memory-intensive. The relatively stable memory usage during "solidity_verifier" and "verify_proof" suggests these stages have consistent memory requirements. The final increase during "z_key" generation might be due to the finalization or storage of the generated key.
This data is valuable for optimizing the zk generation process. Identifying the stages with high memory usage allows developers to focus on optimizing those specific areas to reduce overall resource consumption. The fluctuations suggest that different stages require different optimization strategies. For example, the "phase_two_initiation" stage might benefit from memory allocation strategies or algorithm improvements, while other stages might require different approaches.
</details>
Figure 10: Average RAM usage for each stage of zk generation.
Looking at the average time for each stage reflected in Fig. 8, it is evident that phase two initiation time stood out as the most time-consuming stage, followed by the power of tau (PoT) and the phase two ceremony. In comparison, compile, witness, and zk key generation times are notably shorter. Overall, zk Proof Generation takes significantly longer, averaging 233.63 seconds, compared to zk Verification, which took 61.50 seconds. We analyzed CPU and memory consumption to understand the resource requirements encountered during the various phases of zk-SNARK proof creation. From Fig. 9, we can see that CPU usage was highest during the Phase Two Initiation and Power of Tau stages, indicating these stages are particularly computationally intensive. Other stages like compile, proof, and verification key generation also showed significant CPU usage but to a lesser extent. Memory usage remained relatively consistent across all stages as seen in Fig. 10 hovering around 30-31%, with slight variations observed during the Phase Two Initiation and Power of Tau stages, which can be attributed to the intensive computations required for phase two and power of tau setup. This indicates that developers will face penalties for higher resource consumption and longer times during the zk-SNARK proof generation phase, especially if their models are complex or inefficient. Therefore, optimizing the proof generation process is crucial to avoid high computational costs and delays.
<details>
<summary>extracted/6340811/Blockchain_Chainlink.png Details</summary>
### Visual Description
\n
## Line Chart: Time vs. Weight
### Overview
The image presents a line chart illustrating the relationship between "Weight" and "Time (seconds)". The chart displays a single data series as a light blue line with marker points. The x-axis represents Weight, ranging from 0 to 40, and the y-axis represents Time in seconds, ranging from 2.5 to 5.5. The chart shows fluctuations in time as weight changes.
### Components/Axes
* **X-axis Label:** Weight
* **Y-axis Label:** Time (seconds)
* **X-axis Range:** 0 to 40
* **Y-axis Range:** 2.5 to 5.5
* **Data Series:** A single light blue line with marker points.
* **Gridlines:** A grid of light gray lines is present to aid in reading values.
### Detailed Analysis
The line chart shows a fluctuating relationship between weight and time. The line begins at approximately (0, 3.2).
Here's a breakdown of approximate data points, noting the visual trend:
* **(0, 3.2):** The line starts at approximately 3.2 seconds.
* **(2, 4.5):** The line sharply increases to approximately 4.5 seconds.
* **(5, 3.2):** The line decreases to approximately 3.2 seconds.
* **(8, 3.6):** The line increases to approximately 3.6 seconds.
* **(12, 3.2):** The line decreases to approximately 3.2 seconds.
* **(15, 3.0):** The line decreases to approximately 3.0 seconds.
* **(18, 3.2):** The line increases to approximately 3.2 seconds.
* **(20, 2.9):** The line decreases to approximately 2.9 seconds.
* **(24, 3.4):** The line increases to approximately 3.4 seconds.
* **(26, 5.3):** The line sharply increases to approximately 5.3 seconds.
* **(28, 3.2):** The line sharply decreases to approximately 3.2 seconds.
* **(30, 3.1):** The line slightly decreases to approximately 3.1 seconds.
* **(32, 4.2):** The line increases to approximately 4.2 seconds.
* **(35, 3.0):** The line decreases to approximately 3.0 seconds.
* **(38, 3.2):** The line increases to approximately 3.2 seconds.
* **(40, 3.4):** The line increases to approximately 3.4 seconds.
The line generally fluctuates between 3.0 and 4.0 seconds for most of the weight range, with two significant peaks at approximately Weight = 2 and Weight = 26.
### Key Observations
* **Peaks:** There are two prominent peaks in the data, one around Weight = 2 and another around Weight = 26. These represent the highest time values observed.
* **Fluctuations:** The line exhibits significant fluctuations, indicating a non-linear relationship between weight and time.
* **Minimum:** The lowest time value is approximately 2.9 seconds, occurring around Weight = 20.
* **Trend:** The overall trend is relatively stable, with fluctuations around a central value.
### Interpretation
The chart suggests that the time taken is sensitive to changes in weight. The peaks at Weight = 2 and Weight = 26 could indicate critical weight values where the process being measured experiences a slowdown or requires more time. The fluctuations suggest that the relationship between weight and time is not constant and may be influenced by other factors not represented in this chart. The data could represent the time taken to complete a task or process as a function of the weight involved. The sharp increase at Weight = 26 is particularly noteworthy and might warrant further investigation to understand the underlying cause. The relatively stable period between weights 12 and 20 suggests a more consistent process within that weight range.
</details>
Figure 11: Blockchain and Chainlink overhead time over 39 weights.
<details>
<summary>extracted/6340811/Comparison_1.png Details</summary>
### Visual Description
\n
## Bar Chart: Comparison of zk Proof Generation and Verification Time
### Overview
This bar chart compares the total time taken for zk Proof Generation versus zk Verification, including associated overheads. The chart uses stacked bars to show the breakdown of time for each process. The y-axis represents "Total Time (seconds)" and the x-axis represents "Processes" with two categories: "zk Proof Generation" and "zk Verification".
### Components/Axes
* **X-axis:** "Processes" with categories: "zk Proof Generation", "zk Verification".
* **Y-axis:** "Total Time (seconds)", ranging from 0 to 220 seconds, with increments of 50 seconds.
* **Legend:** Located in the top-right corner.
* "zk Proof Generation Time (s)" - Light Blue
* "zk Verification Time (s)" - Light Green
* "Blockchain + Chainlink Overheads Time (s)" - Red
* **Bars:** Stacked bars representing the total time for each process, broken down by the legend categories.
### Detailed Analysis
The chart presents two bars, one for "zk Proof Generation" and one for "zk Verification".
**zk Proof Generation:**
* The bar is entirely light blue, indicating that the total time is solely attributed to "zk Proof Generation Time (s)".
* The height of the bar is approximately 210 seconds (± 5 seconds).
**zk Verification:**
* This bar is stacked with three components.
* The bottom portion is light green, representing "zk Verification Time (s)". This portion is approximately 40 seconds (± 2 seconds).
* The top portion is red, representing "Blockchain + Chainlink Overheads Time (s)". This portion is approximately 10 seconds (± 1 second).
* The total height of the bar is approximately 50 seconds (± 3 seconds).
### Key Observations
* zk Proof Generation takes significantly longer than zk Verification. The generation time is roughly 4.2 times longer than the total verification time.
* The majority of the time for zk Verification is spent on the verification process itself, with a smaller portion attributed to blockchain and Chainlink overheads.
* The overhead time for zk Verification is relatively small compared to the verification time.
### Interpretation
The data suggests that zk Proof Generation is a computationally intensive process, requiring substantially more time than zk Verification. This is expected, as generating the proof requires complex calculations, while verification is a relatively simpler process. The small overhead associated with zk Verification indicates that the blockchain and Chainlink integration is efficient. This chart highlights the trade-offs between proof generation and verification in zero-knowledge systems. The significant difference in time could influence the design choices of applications utilizing zk-proofs, potentially favoring scenarios where proofs are generated less frequently and verified more often. The data could be used to optimize the proof generation process or to explore alternative verification methods to reduce overall latency.
</details>
Figure 12: Comparison of time taken for zk proof generation vs zk verification process.
Figures 11 and 12 show that blockchain and Chainlink oracle overhead times were minimal compared to the zk proof generation and verification times, highlighting the efficiency of using Chainlink oracles for decentralized verification. Zk-SNARKs are designed to provide a compact proof that can be verified quickly, regardless of the underlying complexity of the original computation. Chainlink oracle network was utilized to compute zk-SNARK verification and return the result to the blockchain, ensuring that the process is both efficient and secure. Figure 12 demonstrates that the zk verification process is efficient. The users can be assured that AI models are verified securely and efficiently, as Chainlink’s decentralized oracle network adds an extra layer of robustness by eliminating single points of failure. This decentralized verification process ensures that the zk-SNARK proofs are validated in a trust-minimized manner.
The results in Fig. 13 indicate the transaction fees associated with the zk-SNARK verification requests on the Ethereum blockchain. The dataset comprised 39 transactions, each representing a distinct zk verification request. With an average fee of 0.000572 ETH, translating to $1.03 USD for each verification. The transaction fees were relatively consistent across all transactions, with minimal variability.
<details>
<summary>extracted/6340811/Transaction_Fee.png Details</summary>
### Visual Description
\n
## Line Chart: Transaction Fee vs. Number of Transactions
### Overview
The image presents a line chart illustrating the relationship between the number of transactions and the corresponding transaction fee in ETH. The chart displays a decreasing trend in transaction fee initially, followed by a relatively stable period.
### Components/Axes
* **X-axis:** Number of Transactions, ranging from 0 to 35.
* **Y-axis:** Transaction Fee (ETH), ranging from approximately 0.000566 to 0.000580.
* **Data Series:** A single orange line representing the transaction fee.
* **Gridlines:** Horizontal and vertical gridlines are present to aid in reading values.
### Detailed Analysis
The orange line starts at approximately 0.000574 ETH at 0 transactions. It remains relatively constant until around 5 transactions. From 5 to 10 transactions, the line exhibits a sharp decrease, dropping to approximately 0.000571 ETH. After 10 transactions, the line stabilizes and fluctuates slightly around 0.000572 ETH, with minimal variation until 35 transactions, where it remains at approximately 0.000572 ETH.
Here's a breakdown of approximate data points:
* 0 Transactions: 0.000574 ETH
* 5 Transactions: 0.000574 ETH
* 10 Transactions: 0.000571 ETH
* 15 Transactions: 0.000572 ETH
* 20 Transactions: 0.000572 ETH
* 25 Transactions: 0.000572 ETH
* 30 Transactions: 0.000572 ETH
* 35 Transactions: 0.000572 ETH
### Key Observations
The most notable observation is the initial decrease in transaction fee as the number of transactions increases from 5 to 10. After this initial drop, the transaction fee remains remarkably stable, indicating a potential saturation point or a mechanism that regulates fees based on transaction volume. There are no significant outliers or anomalies beyond the initial decrease.
### Interpretation
The data suggests that there's an inverse relationship between the number of transactions and the transaction fee, at least up to a certain point. The initial decrease could be due to network effects or increased efficiency as more transactions are processed. However, the stabilization of the fee after 10 transactions implies that the network has reached a point where further increases in transaction volume do not significantly impact the fee. This could be due to limitations in block size, gas limits, or the fee market dynamics within the Ethereum network. The consistent fee suggests a relatively stable demand and supply balance for block space. The chart provides insight into the fee structure of the Ethereum network and how it responds to changes in transaction volume.
</details>
Figure 13: Transaction Fee (ETH) for zk verification.
<details>
<summary>extracted/6340811/LINK_Spent.png Details</summary>
### Visual Description
\n
## Line Chart: LINK Token Spent vs. Number of ZK Verification Requests
### Overview
The image presents a line chart illustrating the relationship between the number of Zero-Knowledge (ZK) Verification Requests and the amount of LINK token spent. The chart displays a single data series represented by an orange line against a grid background.
### Components/Axes
* **Title:** "LINK Token Spent" - positioned at the top-center of the chart.
* **X-axis:** "Number of ZK Verification Requests" - ranging from 0 to 40, with tick marks at integer values.
* **Y-axis:** "LINK Spent" - ranging from 0.20 to 0.42, with tick marks at 0.20, 0.25, 0.30, 0.35, and 0.40.
* **Data Series:** A single orange line representing the LINK token spent for a given number of ZK verification requests.
* **Grid:** A light gray grid is present in the background to aid in reading values.
### Detailed Analysis
The orange line exhibits a fluctuating pattern. Let's analyze the data points:
* At 0 ZK Verification Requests, approximately 0.22 LINK is spent.
* At 5 ZK Verification Requests, approximately 0.26 LINK is spent.
* At 10 ZK Verification Requests, approximately 0.23 LINK is spent.
* At 15 ZK Verification Requests, approximately 0.24 LINK is spent.
* At 20 ZK Verification Requests, there is a significant peak, with approximately 0.41 LINK spent.
* At 25 ZK Verification Requests, the value drops to approximately 0.21 LINK.
* At 30 ZK Verification Requests, approximately 0.25 LINK is spent.
* At 35 ZK Verification Requests, approximately 0.24 LINK is spent.
* At 40 ZK Verification Requests, approximately 0.20 LINK is spent.
The line generally oscillates between approximately 0.21 and 0.26 LINK spent, with a notable outlier at 20 ZK Verification Requests. The trend is not consistently upward or downward, but rather cyclical with a large spike.
### Key Observations
* **Outlier:** The most significant observation is the peak at 20 ZK Verification Requests, where LINK spent is substantially higher than at any other point.
* **Fluctuation:** The amount of LINK spent fluctuates with the number of ZK verification requests, but the relationship is not linear.
* **Low End:** The lowest values are observed around 25 and 40 ZK Verification Requests.
### Interpretation
The chart suggests that the cost of ZK verification requests, measured in LINK tokens, is generally consistent but can experience significant spikes under certain conditions. The outlier at 20 ZK Verification Requests indicates that a specific number of requests or a particular type of request may be considerably more expensive. This could be due to increased computational complexity, higher gas fees, or other factors influencing the cost of ZK verification.
The cyclical nature of the data suggests that there might be a pattern related to the type or batching of ZK verification requests. Further investigation would be needed to determine the cause of these fluctuations and the reason for the outlier. The data implies that the cost of ZK verification is not predictable and can vary significantly, which is important for users and developers utilizing these services. The chart provides a visual representation of the economic cost associated with ZK verification, which is crucial for understanding the overall efficiency and scalability of the system.
</details>
Figure 14: Amount of LINK token spent for zk verification.
Analyzing transaction fees and LINK token expenditure provide valuable insights into the cost structure of deploying zk-SNARK verifications in a decentralized environment. The consistent transaction fees suggest a predictable cost model, benefiting developers and operators planning to integrate such verifications into their systems. At the time of this writing, the cost of LINK is approximately $14.16 USD per token [50], this translates to a range of $2.83 USD to $5.66 USD per request for a zk verification computation. As seen in Fig. 14, the LINK token expenditure graph further emphasis that the costs associated with chainlink oracle are stable for the verification process.
The transaction fees were plotted against the number of transactions to visualize the fee distribution. In addition to transaction fees, we analyzed the LINK token expenditure for the oracle requests involved in zk-SNARK verification. The analysis included 39 oracle requests for zk verification computations, and the expenditure was plotted against the number of zk verification requests. This graph helped identify the cost distribution across different requests, highlighting any peaks that might indicate higher computational or operational demands. Previous work used selective verification to reduce the number of verifications and hence the overall costs associated [38]. While costs associated are higher than centralized systems due to the decentralized nature of blockchain and oracles, these costs are justified by the added benefits of increased trust and continuous transparency for verification.
6 Discussion
Our analysis in the results section indicates that the speed of proof generation is the main constraint that requires significant resources and is process intensive. This can be attributed to the complexity of creating a QAP from the arithmetic circuit, which introduces arithmetization constraints that are difficult to address. These constraints ensure an accurate polynomial representation of AI model operations, but their complexity increases with model size and feature count. For models more complex than a linear regression model, such as a deep learning network, the number of required gates and constraints can increase exponentially, leading to significant resource consumption, longer proof generation times and could present scalability issues. While our framework shows the feasibility of using zk-SNARK-based verification for a linear regression model on blockchain, further optimization is necessary to improve efficiency of zk-SNARK proof generation enabling the use of more advanced AI models within this framework. Techniques such as proof splitting [51], GPU acceleration [52], and parallel processing [53] of zk-SNARK proofs using tools such as Sonic [54] have shown promise in improving the efficiency and reducing costs for zk-SNARK proof generation.
| Key Attributes | Our Paper | SNNzksNARK [37] | Verifiable Evaluations of ML using zk-SNARKs [38] | Trustless DNN Inference [39] | zkCNN [40] | Secure Machine Learning using Homomorphic Encryption & Verifiable Computing [33] |
| --- | --- | --- | --- | --- | --- | --- |
| Blockchain & Oracle Integration | Yes | No | No | No | No | No |
| Decentralization | Fully decentralized using blockchain and Chainlink decentralized oracle network (DON) | Centralized | Centralized | Centralized; runs inference verification in a centralized MLaaS (Machine Learning-as-a-Service) model | Centralized | Centralized |
| Trust | Completely trustless; leverages blockchain, zk-SNARKs and Chainlink oracles for verifiable computations | Relies on trusted central entities for computation and validation | Partially trustless; ensures correct model inference but still requires trust in model providers not to swap models | Limited trustless; relies on a trusted ML service provider to generate zk-SNARKs proofs | Limited trustless; Relies on the model provider to generate and distribute proofs honestly | Partially trustless; relies on a centralized entity to manage HE-encrypted data |
| Transparency | Fully transparent due to Chainlink oracles and zk-SNARK integration; verifications are stored on-chain | Limited transparency as proofs are stored on a centralized setup; lacks public auditability | Provides transparency in verifiable inference but lacks blockchain immutability; results are not recorded on a auditable ledger | Limited transparency as proofs are not public and depends on centralized storage | Limited Transparency; proofs ensure inference correctness, but they are not publicly auditable | Limited Transparency; does not store the proofs on a publicly verifiable ledger |
| Privacy | Ensures privacy by integrating zk-SNARKs into Chainlink oracles for proof verification | Privacy is protected using zk-SNARKs but trained neural network weights might still be exposed | Strong focus on ML model privacy using zk-SNARKs | Ensures input and model privacy via zk-SNARKs but data exposure risks exist | zkCNN hides CNN weights and input data, ensuring confidential inference verification | Ensures privacy of model inputs and outputs using homomorphic encryption (HE) |
| Evaluation Methodology | Real-world implementation using the NVIDIA Jetson TX2, Sepolia testnet and Chainlink’s DON | Simulated performance evaluation on neural networks; No real-world deployment | Real-world tests using actual ML models and benchmarked proof generation | Simulations for centralized environments; no real-world test | zkCNN is benchmark-tested, lacks practical real-world implementation | Benchmarked three architectures for ML evaluation |
| AI/ML Model Verification | Yes - zk-SNARK proofs verify AI model performance claims without revealing model weights | Yes - Uses zk-SNARKs for verifying neural network execution | Yes, verifies inference correctness using zk-SNARKs without revealing model weights | Yes - Focuses on verifying AI inference correctness | Yes, zkCNN guarantees correct CNN model inference execution | No AI-specific verification |
| Data Verification | Yes - Chainlink oracles fetch and verify off-chain data before model verification | No - explicit data verification mechanism; assumes correct data input | No - Does not use external verification mechanisms; assumes data inputs are correct | No - Does not use external verification mechanisms; assumes data inputs are correct | No - assumes data correctness without independent verification | No external data verification |
| Scalability | Scales efficiently due to use of Chainlink oracles for zk-SNARK computations | More efficient scaling due to centralized environments | Limited scalability; real-time AI model inference verification is computationally expensive | Scales better in centralized MLaaS setups | Highly scalable for CNN-based verifications, not designed for large-scale AI verification | Limited scalability due to high computational costs of homomorphic encryption |
| Efficiency | Comparatively higher computational overhead due to decentralized architecture | More efficient; Highly optimized for single-server performance due to centralized architecture with optimized environments | More efficient than decentralized solutions but less efficient than centralized solutions due to the computationally intensive privacy-preserving inference proofs | More efficient; Optimized for centralized systems with batched proofs | Highly efficient for CNN inferences | Computationally expensive due to homomorphic encryption and verifiable computing overhead |
Table 2: Comparison with the existing verification methods across key attributes.
To our knowledge, none of the above studies has implemented zk-SNARKs on a practical blockchain system and a decentralized oracle network to verify AI models. Direct comparisons to existing non-blockchain zk-SNARK AI verification implementations, such as those in [37], [38], [39], and [40], are challenging due to differences in the underlying systems and AI models tested. While these studies focus on implementing zk-SNARKs in centralized systems, our work integrates zk-SNARKs into a decentralized blockchain and oracle network. Despite the inherent differences in our blockchain-based implementation compared to centralized systems, we can still draw important conclusions based on our results.
Existing verification methods such as HE and VC [33] and implementations of zk-SNARKs such as those in [37], [38], [39] and [40], benefit from optimized environments where data and computational resources are centrally managed. These setups enable faster proof generation and verification by reducing communication overhead and leveraging high-performance infrastructure, such as dedicated servers or centralized cloud systems. The key trade-off in implementing zk-SNARKs in decentralization systems is increased transparency and trust at the cost of increased transaction fees and efficiency compared to centralized systems. Decentralized oracles take longer to fetch and verify data, compute the zk-SNARK proof and the blockchain verification adds further delays due to the decentralized nature of the network both of which slow down the process. While this ensures trustless, transparent verification, it results in reduced efficiency compared to zk-SNARKs implementations on centralized systems for AI verification. The key differences in attributes between our approach and existing verification methods is highlighted in Table 2.
A significant incentive for participants to engage with this framework lies in the model data privacy and trustless verification offered by zk-SNARKs, especially when used in conjunction with blockchain technology and decentralized oracles. The decentralized nature of blockchain and oracles ensures that no single entity controls the data or verification process, enhancing transparency and preventing tampering with transaction records. For developers, the ability to verify AI model performance without exposing proprietary data such as model weights ensures that their intellectual property remains secure, reducing the risk of misuse and unauthorized replication. These guarantees encourage developers to bring innovative AI models to the marketplace with confidence knowing that their investments are safeguarded in a trustless and immutable environment. For buyers, zk-SNARKs and the decentralized infrastructure offer a reliable means to independently verify claims of AI models, ensuring that the claims made by sellers about model performance are accurate and trustworthy. This capability promotes transparency and trust in AI models in blockchain-enabled marketplaces, enabling buyers to make informed decisions based on verifiable evidence of model efficacy, thereby fostering a more trustworthy and equitable ecosystem.
7 Conclusion
This paper presents a novel framework for verifying AI model performance claims on blockchain. Our study indicates that the zk proof generation process is the most time-consuming and computationally intensive stage. Optimizing this stage is crucial for enhancing the overall efficiency of zk-SNARK implementations. The zk Verification process on Chainlink oracles is relatively faster but still significant compared to the overhead time, emphasizing the importance of efficient verification mechanisms.
By using the NVIDIA Jetson TX2 for local proof generation and the Sepolia testnet with Chainlink oracles for decentralized verification, our study demonstrates a robust and feasible approach to securely and transparently verifying personalized AI models using a real-world oracle network and testnet setup. Integrating Chainlink oracles with the Sepolia testnet environment allowed us to replicate real-world conditions, providing insights into the practical challenges and benefits of deploying zk-SNARKs in decentralized settings. This implementation highlights the feasibility of using Chainlink’s decentralized oracle network to handle the computational demands of zk-SNARK verification in real-world applications. The consistent performance and minimal overhead observed during our tests indicate that such a setup can effectively manage the verification of personalized AI models at scale. Furthermore, the scalability of Chainlink oracles ensures that this approach can accommodate increasing verification demands without compromising efficiency.
Our findings highlight the potential of combining zk-SNARKs with decentralized oracle networks to improve the transparency and privacy of AI model verification processes for blockchain in real-world applications. In addition to showing that this framework is technically feasible, this study lays the groundwork for future studies that optimize zk-SNARK proof generation and investigate broader applications of Chainlink oracles for AI verification on blockchain. In future work, we will conduct a comprehensive security evaluation of the proposed framework to address potential vulnerabilities and evaluate its robustness against various attack scenarios. This will ensure that the framework is not only efficient and scalable but also secure, thus increasing its applicability and trustworthiness in blockchain-enabled AI marketplaces.
References
- [1] K. Hao, “The computing power needed to train ai is now rising seven times faster than ever before,” MIT Technology Review, 2019.
- [2] OpenAI, “Introducing the gpt store,” Online, 2024, https://openai.com/blog/introducing-the-gpt-store/.
- [3] G. Zyskind, O. Nathan, and A. S. Pentland, “Decentralizing privacy: Using blockchain to protect personal data,” in 2015 IEEE Security and Privacy Workshops, 2015, pp. 180–184.
- [4] S. Nevo, D. Lahav, A. Karpur, Y. Bar-On, H. A. Bradley, and J. Alstott, Securing AI Model Weights: Preventing Theft and Misuse of Frontier Models. Santa Monica, CA: RAND Corporation, 2024.
- [5] K. K. Sarpatwar, V. S. Ganapavarapu, K. Shanmugam, A. A. U. Rahman, and R. Vaculín, “Blockchain enabled ai marketplace: The price you pay for trust,” 2019 IEEE/CVF Conference on Computer Vision and Pattern Recognition Workshops (CVPRW), pp. 2857–2866, 2019. [Online]. Available: https://api.semanticscholar.org/CorpusID:198908085
- [6] B. Goertzel, S. Giacomelli, D. Hanson, G. Yu, C. Dyer, S. Hommel et al., “Singularitynet: A decentralized, open market and inter-network for ais,” SingularityNET Whitepaper, 2017.
- [7] T. Chen, H. Lu, T. Kunpittaya, and A. Luo, “A review of zk-snarks,” 2023. [Online]. Available: https://arxiv.org/abs/2202.06877
- [8] A. Garoffolo, D. Kaidalov, and R. Oliynykov, “Snarktor: A decentralized protocol for scaling snarks verification in blockchains,” IACR Cryptol. ePrint Arch., vol. 2024, p. 99, 2024. [Online]. Available: https://api.semanticscholar.org/CorpusID:267398902
- [9] K. K. Sarpatwar, R. Vaculín, H. Min, G. Su, F. T. Heath, G. Ganapavarapu, and D. N. Dillenberger, “Towards enabling trusted artificial intelligence via blockchain,” in PADG@ESORICS, 2018. [Online]. Available: https://api.semanticscholar.org/CorpusID:133607734
- [10] S. Nazarov et al., “Chainlink 2.0: Next Steps in the Evolution of Decentralized Oracle Networks,” Chainlink Labs, Tech. Rep., April 2021. [Online]. Available: https://research.chain.link/whitepaper-v2.pdf
- [11] K. Salah, M. H. U. Rehman, N. Nizamuddin, and A. Al-Fuqaha, “Blockchain for ai: Review and open research challenges,” IEEE Access, vol. 7, pp. 10 127–10 149, 2019.
- [12] B. Chavali, S. K. Khatri, and S. A. Hossain, “Ai and blockchain integration,” in 2020 8th International Conference on Reliability, Infocom Technologies and Optimization (Trends and Future Directions)(ICRITO). IEEE, 2020, pp. 548–552.
- [13] G. A. Montes and B. Goertzel, “Distributed, decentralized, and democratized artificial intelligence,” Technological Forecasting and Social Change, vol. 141, pp. 354–358, 2019.
- [14] M. Vincent, A. E. George, T. Christa, and N. Jayapandian, “Systematic review on decentralised artificial intelligence and its applications,” in 2023 International Conference on Innovative Data Communication Technologies and Application (ICIDCA). IEEE, 2023, pp. 241–246.
- [15] R. Upreti, P. G. Lind, A. Elmokashfi, and A. Yazidi, “Trustworthy machine learning in the context of security and privacy,” International Journal of Information Security, pp. 1–28, 2024.
- [16] M. Mylrea and N. Robinson, “Artificial intelligence (ai) trust framework and maturity model: applying an entropy lens to improve security, privacy, and ethical ai,” Entropy, vol. 25, no. 10, p. 1429, 2023.
- [17] M. Abdar, F. Pourpanah, S. Hussain, D. Rezazadegan, L. Liu, M. Ghavamzadeh, P. Fieguth, X. Cao, A. Khosravi, U. R. Acharya et al., “A review of uncertainty quantification in deep learning: Techniques, applications and challenges,” Information fusion, vol. 76, pp. 243–297, 2021.
- [18] J. Pearl and D. Mackenzie, The book of why: The new science of cause and effect. Basic books, 2018.
- [19] Q.-u.-A. Arshad, W. Z. Khan, F. Azam, M. K. Khan, H. Yu, and Y. B. Zikria, “Blockchain-based decentralized trust management in iot: systems, requirements and challenges,” Complex & Intelligent Systems, vol. 9, no. 6, pp. 6155–6176, 2023.
- [20] P. De Filippi, M. Mannan, and W. Reijers, “Blockchain as a confidence machine: The problem of trust & challenges of governance,” Technology in Society, vol. 62, p. 101284, 2020.
- [21] D. El Majdoubi, H. El Bakkali, M. Bensaih, and S. Sadki, “A decentralized trust establishment protocol for smart iot systems,” Internet of Things, vol. 20, p. 100634, 2022.
- [22] S. K. Ezzat, Y. N. Saleh, and A. A. Abdel-Hamid, “Blockchain oracles: State-of-the-art and research directions,” IEEE Access, vol. 10, pp. 67 551–67 572, 2022.
- [23] Y. Zhao, X. Kang, T. Li, C.-K. Chu, and H. Wang, “Toward trustworthy defi oracles: past, present, and future,” IEEE Access, vol. 10, pp. 60 914–60 928, 2022.
- [24] D. Bhumichai, C. Smiliotopoulos, R. Benton, G. Kambourakis, and D. Damopoulos, “The convergence of artificial intelligence and blockchain: the state of play and the road ahead,” Information, vol. 15, no. 5, p. 268, 2024.
- [25] W. L. Oberkampf and C. J. Roy, Verification and Validation in Scientific Computing. Cambridge University Press, 2010.
- [26] C. Rudin, “Stop explaining black box machine learning models for high stakes decisions and use interpretable models instead,” Nature Machine Intelligence, vol. 1, no. 5, pp. 206–215, 2019.
- [27] D. Amodei, C. Olah, J. Steinhardt, P. Christiano, J. Schulman, and D. Mané, “Concrete problems in ai safety,” 2016.
- [28] S. Goldwasser, S. Micali, and C. Rackoff, “The knowledge complexity of interactive proof-systems,” in Symposium on the Theory of Computing, 1985. [Online]. Available: https://api.semanticscholar.org/CorpusID:209402113
- [29] M. Blum, P. Feldman, and S. Micali, “Non-interactive zero-knowledge and its applications,” in Proceedings of the Twentieth Annual ACM Symposium on Theory of Computing, ser. STOC ’88. New York, NY, USA: Association for Computing Machinery, 1988, p. 103–112. [Online]. Available: https://doi.org/10.1145/62212.62222
- [30] N. Bitansky, R. Canetti, A. Chiesa, and E. Tromer, “From extractable collision resistance to succinct non-interactive arguments of knowledge, and back again,” Cryptology ePrint Archive, Paper 2011/443, 2011, https://eprint.iacr.org/2011/443. [Online]. Available: https://eprint.iacr.org/2011/443
- [31] E. Ben-Sasson, I. Bentov, Y. Horesh, and M. Riabzev, “Scalable, transparent, and post-quantum secure computational integrity,” Cryptology ePrint Archive, Paper 2018/046, 2018, https://eprint.iacr.org/2018/046. [Online]. Available: https://eprint.iacr.org/2018/046
- [32] B. Bünz, J. Bootle, D. Boneh, A. Poelstra, P. Wuille, and G. Maxwell, “Bulletproofs: Short proofs for confidential transactions and more,” in 2018 IEEE Symposium on Security and Privacy (SP), 2018, pp. 315–334.
- [33] A. Madi, R. Sirdey, and O. Stan, “Computing neural networks with homomorphic encryption and verifiable computing,” in Applied Cryptography and Network Security Workshops: ACNS 2020 Satellite Workshops, AIBlock, AIHWS, AIoTS, Cloud S&P, SCI, SecMT, and SiMLA, Rome, Italy, October 19–22, 2020, Proceedings. Berlin, Heidelberg: Springer-Verlag, 2020, p. 295–317. [Online]. Available: https://doi.org/10.1007/978-3-030-61638-0_17
- [34] Y. Lindell, “Secure multiparty computation (mpc),” IACR Cryptol. ePrint Arch., vol. 2020, p. 300, 2020. [Online]. Available: https://api.semanticscholar.org/CorpusID:212673511
- [35] T. Xie, J. Zhang, Y. Zhang, C. Papamanthou, and D. X. Song, “Libra: Succinct zero-knowledge proofs with optimal prover computation,” IACR Cryptol. ePrint Arch., vol. 2019, p. 317, 2019. [Online]. Available: https://api.semanticscholar.org/CorpusID:92989590
- [36] T. Chen, H. Lu, T. Kunpittaya, and A. Luo, “A review of zk-snarks,” arXiv preprint arXiv:2202.06877, 2022.
- [37] Z. L. DeStefano, “Snnzksnark an efficient design and implementation of a secure neural network verification system using zksnarks [slides],” 1 2020. [Online]. Available: https://www.osti.gov/biblio/1583147
- [38] T. South, A. Camuto, S. Jain, S. Nguyen, R. Mahari, C. Paquin, J. Morton, and A. Pentland, “Verifiable evaluations of machine learning models using zksnarks,” arXiv preprint arXiv:2402.02675, 2024.
- [39] D. Kang, T. B. Hashimoto, I. Stoica, and Y. Sun, “Scaling up trustless dnn inference with zero-knowledge proofs,” ArXiv, vol. abs/2210.08674, 2022. [Online]. Available: https://api.semanticscholar.org/CorpusID:252918110
- [40] T. Liu, X. Xie, and Y. Zhang, “zkcnn: Zero knowledge proofs for convolutional neural network predictions and accuracy,” Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security, 2021. [Online]. Available: https://api.semanticscholar.org/CorpusID:235349006
- [41] N. Ni and Y. Zhu, “Enabling zero knowledge proof by accelerating zk-snark kernels on gpu,” Journal of Parallel and Distributed Computing, vol. 173, pp. 20–31, 2023. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S0743731522002246
- [42] R. S. Wahby, I. Tzialla, A. Shelat, J. Thaler, and M. Walfish, “Doubly-efficient zksnarks without trusted setup,” 2018 IEEE Symposium on Security and Privacy (SP), pp. 926–943, 2018. [Online]. Available: https://api.semanticscholar.org/CorpusID:549873
- [43] C. Labs, “Off-chain reporting,” 2024, accessed: 2024-07-15. [Online]. Available: https://research.chain.link/ocr.pdf
- [44] The Block, “Ethereum archives,” The Block, (accessed Feb. 6, 2023). [Online]. Available: https://www.theblockcrypto.com/data/on-chain-metrics/ethereum
- [45] Glassnode Studio, “Glassnode studio - on-chain market intelligence.” Glassnode Studio, (accessed Jan. 21, 2023). [Online]. Available: https://studio.glassnode.com
- [46] C. Spearman, “The proof and measurement of association between two things,” The American Journal of Psychology, vol. 100, no. 3/4, pp. 441–471, 1987.
- [47] R. Gennaro, C. Gentry, B. Parno, and M. Raykova, “Quadratic span programs and succinct nizks without pcps,” in Advances in Cryptology – EUROCRYPT 2013, T. Johansson and P. Q. Nguyen, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2013, pp. 626–645.
- [48] A. R. Bernabéu, “Efficient cryptographic techniques for privacy-preserving data aggregation,” Master’s thesis, Universitat Oberta de Catalunya, 2020. [Online]. Available: https://openaccess.uoc.edu/bitstream/10609/120126/6/albertobrTFM0620memory.pdf
- [49] SmartContractKit, “functions-hardhat-starter-kit,” https://github.com/smartcontractkit/functions-hardhat-starter-kit, 2024, accessed: 2024-07-15.
- [50] CoinMarketCap, “Chainlink price today, link to usd live price, marketcap and chart,” https://coinmarketcap.com/currencies/chainlink/, accessed: 04 July 2024.
- [51] H. Qi, Y. Cheng, M. Xu, D. Yu, H. Wang, and W. Lyu, “Split: A hash-based memory optimization method for zero-knowledge succinct non-interactive argument of knowledge (zk-snark),” IEEE Transactions on Computers, vol. 72, pp. 1857–1870, 2023. [Online]. Available: https://api.semanticscholar.org/CorpusID:255624126
- [52] T. Derei, “Accelerating the plonk zksnark proving system using gpu architectures,” 2023. [Online]. Available: https://api.semanticscholar.org/CorpusID:259373697
- [53] T. Lu, C. Wei, R. Yu, Y. Chen, L. xilinx Wang, C. Chen, Z. Wang, and W. Chen, “cuzk: Accelerating zero-knowledge proof with a faster parallel multi-scalar multiplication algorithm on gpus,” IACR Trans. Cryptogr. Hardw. Embed. Syst., vol. 2023, pp. 194–220, 2023. [Online]. Available: https://api.semanticscholar.org/CorpusID:252734156
- [54] M. Maller, S. Bowe, M. Kohlweiss, and S. Meiklejohn, “Sonic: Zero-knowledge snarks from linear-size universal and updatable structured reference strings,” Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, 2019. [Online]. Available: https://api.semanticscholar.org/CorpusID:60442921