# 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
> 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
## Diagram: Blockchain, AI Model Integrity, and Inference Challenges
### Overview
The image presents three interconnected diagrams illustrating challenges in blockchain technology, personalized AI models, and inference security. Each section uses symbolic visuals to represent technical concepts, with captions summarizing key issues.
### Components/Axes
1. **Blockchain Section**
- **Visual Elements**:
- Two clusters of interconnected nodes (orange circles with smaller circles) linked by bidirectional arrows.
- A central hexagonal structure with an oval containing symbols:
- "H" (likely Hyperledger),
- Ethereum diamond,
- Pink circle (possibly a token/coin),
- Blue circle with white dot (node/validator).
- **Caption**: "Blockchain – Lack of Inherent trust"
2. **Personalized AI Model Section**
- **Visual Elements**:
- A network of interconnected nodes (orange circles) with arrows forming a complex graph.
- One node highlighted with a concentric circle (target symbol).
- **Caption**: "Personalized AI Model – model’s integrity and confidentiality issues"
3. **Inference Challenges Section**
- **Visual Elements**:
- A robot face with two Xs for eyes and a warning triangle with an exclamation mark.
- **Caption**: "Detecting changes to the model during inference is challenging."
### Detailed Analysis
- **Blockchain Diagram**:
- The bidirectional arrows between node clusters suggest a decentralized network with mutual validation.
- The central hexagonal structure likely represents a consensus mechanism (e.g., proof-of-work/authority), with symbols denoting specific protocols or assets.
- The lack of "inherent trust" implies reliance on cryptographic verification rather than centralized authority.
- **AI Model Diagram**:
- The dense network of nodes represents data flow or model architecture.
- The highlighted node with a target symbol may indicate a critical component (e.g., model weights) vulnerable to tampering or data leakage.
- Arrows imply dependencies between model components, raising risks of adversarial attacks or bias propagation.
- **Inference Challenges Diagram**:
- The robot’s Xs and warning triangle symbolize threats (e.g., model poisoning, evasion attacks) during inference.
- The static nature of deployed models makes real-time change detection difficult, as noted in the caption.
### Key Observations
- **Blockchain**: Trust is maintained through distributed consensus, not inherent trust in participants.
- **AI Models**: Complex interdependencies increase vulnerability to integrity breaches.
- **Inference**: Static models lack mechanisms to detect adversarial modifications post-deployment.
### Interpretation
The diagrams collectively highlight systemic vulnerabilities in decentralized systems and AI:
1. **Blockchain’s Trust Model**: While decentralization reduces reliance on central authorities, it introduces challenges in resolving disputes or validating malicious actors.
2. **AI Integrity Risks**: Personalized models, often trained on sensitive data, are prone to confidentiality breaches (e.g., membership inference attacks) and adversarial manipulation.
3. **Inference Security**: The absence of dynamic monitoring tools exacerbates risks, as attackers can subtly alter model behavior without detection.
The visual metaphors (e.g., warning triangle, X-marked robot) emphasize the urgency of developing robust frameworks for trust, integrity, and real-time anomaly detection in these domains.
</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
## Flowchart: Secure AI Model Evaluation and Verification Process
### Overview
The diagram illustrates a two-phase process for generating and verifying secure, trustworthy AI model evaluations using zero-knowledge proofs (zk-proofs) and blockchain technology. It emphasizes decentralization, cryptographic verification, and trustless validation.
### Components/Axes
1. **Section A: Generate a Secure and Trusted Evaluation Proof**
- **Components**:
- **Benchmarked Personalized AI Model**: Represented by interconnected nodes with directional arrows (orange).
- **Developer**: A human figure interacting with a locked "zkSNARK" box (blue).
- **zkSNARK**: A cryptographic proof system (blue box with a lock icon).
- **Validated Proof Shared on the Blockchain**: A hexagonal blockchain structure with symbols (H, Ethereum, etc.) and cubes.
- **Flow**:
- AI model → Generation of zk-proofs (locked box) → Validation → Blockchain storage.
2. **Section B: Verifying Model Inference on Decentralized Oracle Networks**
- **Components**:
- **Personalized AI Models in a Decentralized Marketplace**: Two orange AI models feeding into a hexagonal oracle network.
- **Decentralized Oracle Network**: A dense hexagonal network with embedded symbols (H, Ethereum, etc.).
- **zk-Verification**: A CPU-like component with binary code (10100, 11010) and a validation stamp.
- **Blockchain Matching**: A hexagonal blockchain with cubes and a comparison of new vs. validated proofs.
- **Flow**:
- Marketplace models → Oracle network → zk-verification → Blockchain storage and validation.
### Detailed Analysis
- **Section A**:
- The AI model generates zk-proofs via zkSNARK, ensuring privacy and correctness without revealing internal logic.
- The developer interacts with the zkSNARK system, which produces a proof validated and stored on the blockchain.
- Blockchain symbols (H, Ethereum) suggest multi-chain compatibility or interoperability.
- **Section B**:
- AI models deployed in a decentralized marketplace feed into an oracle network for inference.
- The oracle network uses zk-verification (CPU-like component) to validate results cryptographically.
- Validated proofs are matched against prior blockchain entries to ensure consistency and prevent tampering.
### Key Observations
1. **Cryptographic Trust**: zkSNARK and zk-verification ensure proofs are generated and validated without exposing sensitive data.
2. **Decentralization**: Both sections emphasize decentralized systems (oracle networks, blockchain) to avoid single points of failure.
3. **Blockchain as a Ledger**: The hexagonal blockchain structure acts as an immutable record for proofs, with cubes symbolizing data blocks.
4. **Symbolic Representation**:
- **H**: Likely represents Horizen (a blockchain platform).
- **Ethereum**: Indicates compatibility with Ethereum-based systems.
- **Other Symbols**: May denote additional blockchains or cryptographic protocols.
### Interpretation
The diagram outlines a framework for secure AI model evaluation in decentralized environments. By leveraging zk-proofs, the system ensures that AI inferences are both private and verifiable. The blockchain serves as a tamper-proof ledger to store and validate proofs, while decentralized oracle networks enable trustless coordination between AI models and external data sources.
The use of zkSNARK in Section A highlights a focus on privacy-preserving AI, while Section B’s oracle network and zk-verification emphasize scalability and decentralization. The matching of new proofs against prior blockchain entries ensures accountability, preventing malicious actors from submitting invalid results.
This architecture could be critical for applications requiring auditable, secure AI decisions (e.g., finance, healthcare) where trust and transparency are paramount.
</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
## Flowchart: Decentralized AI Marketplace with Zero-Knowledge Proofs
### Overview
The diagram illustrates a decentralized AI marketplace workflow, emphasizing secure data processing, model training, and verification using blockchain and zero-knowledge proofs (zkSNARK). It is divided into two main sections:
1. **A: Generate a secure and trusted evaluation proof** (Steps 1–3)
2. **B: Verifying model inference on decentralized oracle networks using zkSNARK** (Steps 4–14)
---
### Components/Axes
#### Section A: Secure Evaluation Proof Generation
1. **On-Chain Data** → **Data Cleaning** → **Data Normalization** → **Correlation Analysis** → **Personalized AI Model** → **Generation of Zero-Knowledge Proofs**
- **Key Elements**:
- **On-Chain Data**: Represented as stacked database icons.
- **Data Cleaning/Normalization**: Green-bordered rectangle.
- **Correlation Analysis**: Wavy rectangle.
- **Personalized AI Model**: Orange neural network diagram.
- **Zero-Knowledge Proofs**: Locked document icon labeled "zkSNARK."
#### Section B: Model Inference Verification
- **Decentralized Marketplace**:
- **Sellers** (purple figures) and **Buyers** (green figures) interact via blockchain.
- **Blockchain**: Hexagonal structure with cryptocurrency symbols (e.g., Ethereum, Bitcoin).
- **Smart Contract**: Labeled "request" and "result" arrows.
- **Decentralized Oracle Network**:
- **API Providers**: Stacked database icons.
- **Sandboxed Execution (SE)**: Cloud icons with "SE" labels.
- **zk Verification**: Circuit diagram with "zk verification" label.
---
### Detailed Analysis
#### Section A: Secure Evaluation Proof Generation
1. **On-Chain Data** (Step 1): Raw data stored on the blockchain.
2. **Data Cleaning/Normalization** (Step 1): Preprocessing to ensure data quality.
3. **Correlation Analysis** (Step 1): Identifies relationships in the data.
4. **Personalized AI Model** (Step 2): Custom model trained on processed data.
5. **Zero-Knowledge Proofs** (Step 3): Generated by the developer using zkSNARK, validated on-chain.
#### Section B: Model Inference Verification
1. **Decentralized Marketplace** (Steps 5–6):
- Sellers offer AI models; buyers request inference.
- Blockchain validates proofs against previously shared data.
2. **Oracle Network** (Steps 7–14):
- **API Requests/Responses**: On-chain and off-chain data integration.
- **Computation Requests**: Sent to SE nodes for secure execution.
- **zk Verification**: Ensures model inference results are trustworthy without exposing data.
---
### Key Observations
1. **Blockchain Integration**: Central to trust and validation across both sections.
2. **Zero-Knowledge Proofs**: Enable privacy-preserving verification (e.g., zkSNARK).
3. **Decentralized Oracles**: Bridge on-chain and off-chain data for reliable model inputs.
4. **Sandboxed Execution**: Isolates computations to prevent tampering.
---
### Interpretation
The diagram demonstrates a trustless AI ecosystem where:
- **Data Integrity**: On-chain preprocessing ensures reliable training data.
- **Model Privacy**: Zero-knowledge proofs allow verification without exposing proprietary model details.
- **Decentralized Trust**: Oracles and smart contracts eliminate single points of failure, while zkSNARK ensures computational honesty.
- **Marketplace Dynamics**: Sellers and buyers interact via blockchain, with proofs validated against historical data to prevent fraud.
This architecture prioritizes security, transparency, and scalability for decentralized AI services.
</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}\times F^{n^{\prime}}\rightarrow 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)\in F^{n}\times 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\in F^{n}$ with a witness $w\in F^{n^{\prime}}$ such that $(x,w)\in 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\notin 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\leftarrow\mathcal{E}_{\mathcal{A}}(\text{crs})$ based on the output of an adversary $\mathcal{A}$ , which produces a valid argument $(x,\pi)\leftarrow\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
## Screenshot: Ethereum Smart Contract Deployment Log
### Overview
The image shows a terminal/console output from an Ethereum smart contract deployment process. It includes transaction confirmation status, contract deployment details, and verification results. The output is in English with no non-English text present.
### Components/Axes
- **Transaction Status**: "Waiting 2 blocks for transaction 0x7fdca8a958ef7c843a02fbb7fe8bad116b4201579e615d97dbd04b2ef46ec8e2 to be confirmed..."
- **Contract Deployment**: "Deployed FunctionsConsumer contract to: 0xe953b197cCC443e3d8664962C1e1dD4abc33701d"
- **Verification Process**:
- "Verifying contract..."
- "The contract 0xe953b197cCC443e3d8664962C1e1dD4abc33701d has already been verified"
- "Contract verified"
- **Network**: "ethereumSepolia"
### Detailed Analysis
1. **Transaction Confirmation**:
- Transaction ID: `0x7fdca8a958ef7c843a02fbb7fe8bad116b4201579e615d97dbd04b2ef46ec8e2`
- Requires 2 block confirmations
- Status: "to be confirmed..." (pending)
2. **Contract Deployment**:
- Contract Name: `FunctionsConsumer`
- Deployed Address: `0xe953b197cCC443e3d8664962C1e1dD4abc33701d`
- Deployment Status: Confirmed (underlined text indicates success)
3. **Verification Results**:
- Contract address matches deployment address
- Verification Status: Already verified (prevents redundant verification)
- Final Confirmation: "Contract verified"
### Key Observations
- The deployment process follows Ethereum's standard workflow: transaction → deployment → verification
- The "already been verified" message suggests either:
- A check against Etherscan/Etherspot verification status
- A local cache of previously verified contracts
- The use of `ethereumSepolia` indicates this is a testnet deployment, not mainnet
### Interpretation
This log demonstrates a complete smart contract deployment cycle on Ethereum Sepolia testnet. The verification step acts as a safety mechanism to prevent redeployment of already-verified contracts, which is critical for maintaining contract integrity. The underlined "FunctionsConsumer" suggests this might be a hyperlink in the terminal interface (common in IDEs like Remix or VSCode with Ethereum plugins). The transaction ID format confirms this is an Ethereum transaction hash, and the 42-character address format validates it as a valid Ethereum contract address.
The output implies this is likely part of an automated deployment script or manual verification process in a development environment. The use of Sepolia (instead of Goerli or other testnets) suggests the developer is following Ethereum's recommended testnet for EIP-1559 testing or specific project requirements.
</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
## Screenshot: Terminal/Command-Line Interface Interaction
### Overview
The image shows a terminal/command-line interface (CLI) interaction involving blockchain subscription management. Key elements include:
- A warning about `secp256k1` unavailability, reverting to a browser version.
- Creation of a billing subscription (`3053`) and confirmation to fund it with `2 LINK` tokens.
- Subscription details (balance, owner, transaction hash, etc.) displayed in a structured format.
### Components/Text Content
1. **Initial Warning**:
- `secp256k1 unavailable, reverting to browser version`
- Indicates a fallback mechanism for cryptographic operations.
2. **Subscription Creation**:
- `Creating Functions billing subscription...`
- `Created Functions billing subscription: 3053`
3. **Funding Confirmation**:
- Prompt: `Please confirm that you wish to fund Subscription 3053 with 2 LINK from your wallet.`
- User input: `Continue? Enter (y) Yes / (n) No` → `y`
4. **Funding Execution**:
- `Funding subscription 3053 with 2 LINK...`
- Transaction hash: `0x8201e5b295946017ffca3dc688b9c88a79c7140179b328c2fb83fefc446961d5`
5. **Subscription Details**:
- Structured data in a JSON-like format:
```json
Subscription Info: {
balance: '2.0 LINK',
owner: '0x4ec77d7AaB8e69c2A8F7CE3d4106415696279478',
blockedBalance: '0.0 LINK',
proposedOwner: '0x0000000000000000000000000000000000000000',
consumers: ['0xe953b197cCC443e3d8664962C1e1dD4abc33701d'],
flags: '0x0000000000000000000000000000000000000000'
}
```
### Key Observations
- **Transaction Success**: Subscription `3053` was funded with `2 LINK` tokens, as confirmed by the transaction hash.
- **Ownership**: The subscription owner address (`0x4ec...9478`) holds the full balance (`2.0 LINK`), with no blocked or proposed ownership changes.
- **Consumer Address**: A single consumer address (`0xe953...01d`) is listed, suggesting restricted access to the subscription.
- **Flags**: All flags are zeroed out, indicating no special permissions or states are active.
### Interpretation
This interaction demonstrates a blockchain-based subscription system where:
1. **Cryptographic Fallback**: The system defaults to a browser-based cryptographic library (`secp256k1`) when the native library is unavailable, ensuring continuity.
2. **Token-Based Funding**: Subscriptions are monetized using `LINK` tokens (likely Chainlink’s native token), with explicit user confirmation required for transactions.
3. **Ownership Structure**: The owner retains full control over the subscription balance, while consumers are explicitly defined, implying a permissioned access model.
4. **Transparency**: The transaction hash allows verification on a blockchain explorer, ensuring auditability.
The absence of blocked balances or proposed ownership changes suggests a stable, unmodified subscription state post-funding. The single consumer address hints at a controlled deployment, possibly for testing or a specific use case.
</details>
Figure 5: Funding the subscription
<details>
<summary>extracted/6340811/n123.png Details</summary>
### Visual Description
## Terminal Output: Transaction Response Analysis
### Overview
The image shows a terminal/command-line interface displaying a transaction response from a blockchain explorer. The output includes a transaction hash, status indicators, a URL for request exploration, and a JSON-formatted response containing transaction details.
### Components/Axes
- **Status Indicators**: Green checkmarks (✓) denote successful operations.
- **Transaction Hash**: `0xc90a46e4f58a2831b8099e6b0b17009aa906ec2a3aa3184b31703e72cdffefb9`
- **URL**: `https://sepolia.etherscan.io/tx/0xc90a46e4f58a2831b8099e6b0b17009aa906ec2a3aa3184b31703e72cdffefb9`
- **JSON Response**: Contains transaction metadata, costs, and fulfillment status.
### Detailed Analysis
#### Transaction Summary
- **Status**: ✓ Functions request sent! Transaction hash provided.
- **Cost**: `0.20417926` Juel (extremely low value, likely a test transaction).
- **Fulfillment Code**: `0` (successful fulfillment).
#### JSON Response Breakdown
```json
{
"requestId": "0x2afe734c0a40bf743b3994963da56c1677efca2c5ca15410166060b88996aaf7",
"subscriptionId": "3088",
"totalCostInJuels": "204179266937581512n",
"responseBytesHexstring": "0x52657374566c74433a20333632",
"errorString": "",
"returnDataBytesHexstring": "0x",
"fulfillmentCode": "0"
}
```
### Key Observations
1. **Success Indicator**: Green checkmarks confirm successful request and fulfillment.
2. **Test Transaction**: The cost (`0.20417926 Juel`) is negligible, suggesting a testnet environment (e.g., Sepolia).
3. **Empty Data Fields**: `returnDataBytesHexstring` is `"0x"`, indicating no payload returned.
4. **URL Verification**: The provided link allows cross-referencing the transaction on Etherscan.
### Interpretation
This output represents a successful blockchain transaction on the Sepolia testnet. The negligible cost and empty return data suggest it may be a test or debug transaction. The JSON structure aligns with typical blockchain API responses, where `fulfillmentCode: 0` confirms execution success. The absence of errors (`errorString: ""`) and the presence of a valid transaction hash validate the operation's integrity. The URL enables further exploration of the transaction's blockchain context, useful for auditing or development purposes.
</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: Time Distribution Analysis
### Overview
The image contains 12 histograms visualizing time distributions across various computational processes. Each histogram uses a blue bar color scheme with frequency counts on the y-axis and time measurements (in milliseconds) on the x-axis. Titles indicate specific metrics like "Compile Time," "Witness Time," and "Total Time."
---
### Components/Axes
1. **X-Axes**:
- Labeled "Time (ms)" across all charts.
- Ranges vary per metric (e.g., 0.24–0.28 ms for Compile Time, 230–255 ms for Total Time).
2. **Y-Axes**:
- Labeled "Frequency" across all charts.
- Scales range from 0 to ~20 (e.g., 0–12 for Pot Time, 0–20 for Phase Two Initiation Time).
3. **Legends**:
- No explicit legends present; bar colors are uniform (blue) across all charts.
---
### Detailed Analysis
#### Top Row (Left to Right)
1. **Compile Time**
- **X-Axis**: 0.24–0.28 ms
- **Peaks**: ~0.25 ms (frequency ~10), ~0.26 ms (frequency ~4)
- **Tails**: Low frequencies at 0.24 ms and 0.28 ms.
2. **Witness Time**
- **X-Axis**: 0.190–0.220 ms
- **Peaks**: ~0.195 ms (frequency ~10), ~0.205 ms (frequency ~8)
- **Tails**: Gradual decline toward 0.220 ms.
3. **Pot Time**
- **X-Axis**: 3.15–3.45 ms
- **Peaks**: ~3.20 ms (frequency ~12), ~3.25 ms (frequency ~9)
- **Tails**: Sharp drop after 3.30 ms.
#### Middle Row (Left to Right)
4. **Pot Ceremony Time**
- **X-Axis**: 16.8–18.0 ms
- **Peaks**: ~17.0 ms (frequency ~8), ~17.2 ms (frequency ~8)
- **Tails**: Low frequencies at 16.8 ms and 17.8 ms.
5. **Phase Two Initiation Time**
- **X-Axis**: 195–220 ms
- **Peaks**: ~195 ms (frequency ~20), ~200 ms (frequency ~13)
- **Tails**: Sparse data beyond 205 ms.
6. **Z Key Generation Time**
- **X-Axis**: 3.3–3.7 ms
- **Peaks**: ~3.3 ms (frequency ~10), ~3.4 ms (frequency ~9)
- **Tails**: Drop after 3.5 ms.
#### Bottom Row (Left to Right)
7. **Phase Two Ceremony Time**
- **X-Axis**: 2.325–2.525 ms
- **Peaks**: ~2.35 ms (frequency ~9), ~2.425 ms (frequency ~6)
- **Tails**: Gradual decline toward 2.525 ms.
8. **Verification Key Generation Time**
- **X-Axis**: 2.40–2.75 ms
- **Peaks**: ~2.45 ms (frequency ~14), ~2.50 ms (frequency ~11)
- **Tails**: Sharp drop after 2.55 ms.
9. **Proof Generation Time**
- **X-Axis**: 2.50–2.75 ms
- **Peaks**: ~2.55 ms (frequency ~9), ~2.60 ms (frequency ~5)
- **Tails**: Low frequencies at 2.70 ms and 2.75 ms.
#### Final Row (Left to Right)
10. **Verifying Proof Time**
- **X-Axis**: 2.30–2.60 ms
- **Peaks**: ~2.35 ms (frequency ~18), ~2.40 ms (frequency ~13)
- **Tails**: Sparse data at 2.60 ms.
11. **Solidity Verifier Generation Time**
- **X-Axis**: 2.24–2.34 ms
- **Peaks**: ~2.30 ms (frequency ~11), ~2.32 ms (frequency ~10)
- **Tails**: Drop after 2.34 ms.
12. **Total Time**
- **X-Axis**: 230–255 ms
- **Peaks**: ~230 ms (frequency ~17), ~235 ms (frequency ~16)
- **Tails**: Small peak at 255 ms (frequency ~1).
---
### Key Observations
1. **Narrow Distributions**: Most metrics (e.g., Compile Time, Witness Time) show tight clustering around peak values, indicating consistency.
2. **Long-Tail Metrics**: Phase Two Initiation Time and Total Time exhibit longer tails, suggesting occasional outliers or variability.
3. **High-Frequency Peaks**: Metrics like Pot Time (3.20 ms) and Verification Key Generation Time (2.45 ms) have dominant modes.
4. **Anomalies**: The Total Time histogram shows a rare outlier at 255 ms, far from the main cluster.
---
### Interpretation
- **Consistency vs. Variability**: Metrics with narrow distributions (e.g., Compile Time) suggest predictable performance, while those with long tails (e.g., Total Time) indicate potential bottlenecks or external dependencies.
- **Process Hierarchy**: Shorter time metrics (e.g., Witness Time at 0.195 ms) likely represent foundational steps, while longer ones (e.g., Total Time at 230 ms) aggregate multiple processes.
- **Critical Paths**: Phase Two Initiation Time (195–200 ms) and Verification Key Generation Time (2.45 ms) may represent computationally intensive stages requiring optimization.
- **Outlier Implications**: The 255 ms outlier in Total Time could signal edge-case scenarios (e.g., network delays, resource contention) warranting further investigation.
This analysis highlights the importance of optimizing high-frequency peaks and addressing long-tail distributions to improve overall system efficiency.
</details>
Figure 7: Distribution analysis for each phase of zk generation.
<details>
<summary>extracted/6340811/Avg_Time_Gen_Bar.png Details</summary>
### Visual Description
## Bar Chart: Stages of zk Generation
### Overview
The chart visualizes the average time (in seconds) required for various stages of zero-knowledge (zk) generation. The y-axis represents "Average Time (s)" with a scale from 0 to 200, while the x-axis lists 11 distinct stages of the process. The tallest bar corresponds to "phase_two_initiation_time," which dominates the chart, while all other stages have significantly smaller values.
### Components/Axes
- **X-axis (Stages of zk Generation)**:
Labels include:
`compile_time`, `witness_time`, `pot_time`, `pot_ceremony_time`, `phase_two_initiation_time`, `zk_key_generation_time`, `phase_two_ceremony_time`, `verification_key_generation_time`, `proof_generation_time`, `verifying_proof_time`, `solidity_verifier_generation_time`.
- **Y-axis (Average Time (s))**:
Scale ranges from 0 to 200 in increments of 25.
- **Legend**:
No explicit legend is present, but all bars are rendered in a consistent light blue color.
### Detailed Analysis
- **phase_two_initiation_time**:
Dominates the chart with an approximate value of **195–200 seconds** (highest bar, ~10x taller than the next largest).
- **pot_ceremony_time**:
Second-highest at **~15 seconds** (1/13th of the tallest bar).
- **Other stages**:
All remaining stages (`compile_time`, `witness_time`, `pot_time`, `zk_key_generation_time`, `phase_two_ceremony_time`, `verification_key_generation_time`, `proof_generation_time`, `verifying_proof_time`, `solidity_verifier_generation_time`) have values **≤5 seconds**, with most clustered near **1–3 seconds**.
### Key Observations
1. **Outlier Dominance**:
"phase_two_initiation_time" accounts for **~95% of total time**, making it the critical bottleneck.
2. **Symmetry in Minor Stages**:
Stages like `compile_time` and `witness_time` are nearly negligible (≈0.5–1s), while others like `zk_key_generation_time` and `proof_generation_time` cluster around 2–4s.
3. **Scalability Implication**:
The extreme disparity suggests optimization efforts should prioritize reducing "phase_two_initiation_time" to improve overall efficiency.
### Interpretation
The data highlights a stark imbalance in zk generation stages. The "phase_two_initiation_time" is orders of magnitude slower than all other steps, indicating it is the primary constraint on the process. This could stem from computational complexity, resource allocation, or algorithmic inefficiencies in that phase. The uniformity of minor stages suggests they are already optimized or inherently fast. Addressing the bottleneck in "phase_two_initiation_time" would yield the most significant performance gains, aligning with Pareto principles of optimization.
</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
## Line Chart: Stages of zk Generation
### Overview
The chart illustrates the average CPU usage (%) across six stages of zk (zero-knowledge) generation. The data is represented by a single red line, with the y-axis ranging from 20% to 60% and the x-axis listing sequential stages of the process.
### Components/Axes
- **X-axis (Stages of zk Generation)**:
- `compile`
- `phase_two_initiation`
- `power_of_tau`
- `solidity_verifier`
- `verify_proof`
- `z_key`
- **Y-axis (Average CPU Usage %)**:
- Scale: 20% to 60% in 10% increments.
- **Legend**:
- Located in the top-right corner.
- Red line labeled `cpu(%)`.
### Detailed Analysis
- **Data Points**:
- `compile`: ~20.5%
- `phase_two_initiation`: ~64.5% (peak)
- `power_of_tau`: ~52.5%
- `solidity_verifier`: ~51.5%
- `verify_proof`: ~50.5%
- `z_key`: ~51.5%
### Key Observations
1. **Sharp Initial Increase**: CPU usage jumps from ~20.5% (`compile`) to ~64.5% (`phase_two_initiation`), indicating a resource-intensive phase.
2. **Post-Spike Stabilization**: After `phase_two_initiation`, CPU usage drops to ~52.5% (`power_of_tau`) and stabilizes between ~50.5%–52.5% for subsequent stages.
3. **Outlier**: The `compile` stage has the lowest CPU usage (~20.5%), contrasting with the peak at `phase_two_initiation`.
4. **Dip at `verify_proof`**: A slight decrease to ~50.5% suggests potential optimization or lower computational demand in this stage.
### Interpretation
- **Resource Allocation**: The spike at `phase_two_initiation` highlights it as the most CPU-heavy stage, possibly involving complex computations (e.g., cryptographic operations).
- **Efficiency Trends**: The stabilization post-spike implies that later stages are optimized or less computationally demanding.
- **Anomaly**: The `compile` stage’s low CPU usage (~20.5%) may reflect preparatory tasks (e.g., code generation) rather than intensive processing.
- **Process Flow**: The chart suggests a workflow where initial stages require heavy resource allocation, followed by a more balanced distribution in later phases.
### Spatial Grounding
- The legend (`cpu(%)`) is positioned in the top-right corner, matching the red line’s color.
- All data points align with the legend’s label, confirming consistency.
### Trend Verification
- The line slopes upward sharply from `compile` to `phase_two_initiation`, then slopes downward to `power_of_tau`, followed by minor fluctuations. This matches the extracted data points.
### Content Details
- No additional text or embedded diagrams are present.
- All values are approximate, with uncertainty due to the absence of gridline markers for precise readings.
</details>
Figure 9: Average CPU usage for each stage of zk generation.
<details>
<summary>extracted/6340811/New_Memory.png Details</summary>
### Visual Description
## Line Chart: Average Memory Usage (%) Across Stages of zk Generation
### Overview
The chart illustrates the average memory usage (in percentage) across six stages of zero-knowledge (zk) generation. The x-axis represents the stages, while the y-axis shows memory usage from 30.2% to 31.4%. A single red line labeled "memory(%)" tracks the trend.
### Components/Axes
- **X-Axis (Stages of zk Generation)**:
- `compile`
- `phase_two_initiation`
- `power_of_tau`
- `solidity_verifier`
- `verify_proof`
- `z_key`
- **Y-Axis (Average Memory Usage %)**:
- Scale: 30.2% to 31.4% (increments of 0.1%).
- **Legend**:
- Located in the top-right corner.
- Red line corresponds to "memory(%)".
### Detailed Analysis
1. **Compile**:
- Memory usage starts at **~30.1%**, the lowest point on the chart.
2. **Phase_two_initiation**:
- Sharp increase to **~31.4%**, the highest peak.
3. **Power_of_tau**:
- Slight drop to **~31.3%**.
4. **Solidity_verifier**:
- Further decline to **~30.9%**.
5. **Verify_proof**:
- Stabilizes at **~30.9%**.
6. **Z_key**:
- Final peak at **~31.1%**.
### Key Observations
- **Highest Memory Usage**: Occurs at `phase_two_initiation` (~31.4%) and `z_key` (~31.1%).
- **Lowest Memory Usage**: At `compile` (~30.1%).
- **Trend**: Initial spike at `phase_two_initiation`, followed by fluctuations, with a final rise at `z_key`.
### Interpretation
The chart suggests that memory usage is heavily concentrated in the `phase_two_initiation` and `z_key` stages, likely due to computationally intensive operations such as cryptographic proofs or key generation. The `compile` stage uses minimal memory, indicating it involves lighter tasks. The fluctuations between stages highlight varying resource demands, with `solidity_verifier` and `verify_proof` showing relatively stable usage. The final peak at `z_key` underscores its critical role in the zk generation process, possibly involving complex cryptographic computations.
</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
## Line Graph: Time vs. Weight
### Overview
The image depicts a line graph illustrating the relationship between "Weight" (x-axis) and "Time (seconds)" (y-axis). The graph shows a fluctuating blue line with notable peaks and troughs, suggesting variability in time measurements across different weight values. The y-axis ranges from 0 to 5.5 seconds, while the x-axis spans from 0 to 40 units of weight.
### Components/Axes
- **X-axis (Weight)**: Labeled "Weight," with numerical markers at intervals of 5 (0, 5, 10, ..., 40).
- **Y-axis (Time)**: Labeled "Time (seconds)," with markers at 0.5-second intervals (0, 0.5, ..., 5.5).
- **Legend**: Located in the top-right corner, the blue line is explicitly labeled as "Time (seconds)."
- **Line**: A single blue line connects data points across the graph, with no additional series or legends.
### Detailed Analysis
- **Key Data Points**:
- **Peaks**:
- At **Weight = 5**, Time = **4.5 seconds** (highest peak).
- At **Weight = 25**, Time = **5.4 seconds** (absolute maximum).
- At **Weight = 32**, Time = **4.2 seconds** (secondary peak).
- **Troughs**:
- At **Weight = 15**, Time ≈ **3.0 seconds** (lowest point).
- At **Weight = 20**, Time ≈ **3.0 seconds** (another trough).
- At **Weight = 35**, Time ≈ **3.0 seconds** (final trough).
- **General Range**: Time fluctuates between **3.0 seconds** (minimum) and **5.4 seconds** (maximum).
- **Trends**:
- The line exhibits **no consistent upward or downward trend**, with irregular fluctuations.
- Sharp increases occur between **Weight = 5–10** and **Weight = 20–25**, followed by steep declines.
- The highest time (5.4 seconds) occurs at **Weight = 25**, while the lowest (3.0 seconds) is observed at multiple points (15, 20, 35).
### Key Observations
1. **Outliers**: The peak at **Weight = 25** (5.4 seconds) is significantly higher than all other points, suggesting an anomaly or critical threshold.
2. **Pattern**: Time increases sharply at specific weights (e.g., 5, 25) but drops abruptly afterward, indicating possible non-linear relationships.
3. **Consistency**: The lowest time (3.0 seconds) repeats at multiple weights, hinting at a potential optimal range.
### Interpretation
The graph suggests that **time increases unpredictably with weight**, with no clear linear correlation. The sharp peaks at **Weight = 5, 25, and 32** may indicate specific conditions or thresholds where time measurements spike, possibly due to external factors (e.g., equipment limitations, measurement errors). The repeated troughs at **3.0 seconds** could represent a baseline or optimal performance range. The lack of a consistent trend implies that the relationship between weight and time is either non-linear, influenced by confounding variables, or subject to measurement noise. Further investigation into the context of the data (e.g., experimental setup, units of weight) would be necessary to draw definitive conclusions.
</details>
Figure 11: Blockchain and Chainlink overhead time over 39 weights.
<details>
<summary>extracted/6340811/Comparison_1.png Details</summary>
### Visual Description
## Bar Chart: zk Proof Generation vs Verification Time
### Overview
The chart compares two processes: "zk Proof Generation" and "zk Verification", measured by total time in seconds. A third component, "Blockchain + Chainlink Overheads Time", is visually represented as a small red segment within the "zk Verification" bar.
### Components/Axes
- **X-axis**: Labeled "Processes", with two categories:
- "zk Proof Generation" (left)
- "zk Verification" (right)
- **Y-axis**: Labeled "Total Time (seconds)", scaled from 0 to 250 in increments of 50.
- **Legend**: Positioned in the top-right corner, with three entries:
- **Blue**: "zk Proof Generation Time (s)"
- **Green**: "zk Verification Time (s)"
- **Red**: "Blockchain + Chainlink Overheads Time (s)"
### Detailed Analysis
- **zk Proof Generation**:
- Blue bar dominates the chart, reaching approximately **230 seconds**.
- No sub-components or color variations within the bar.
- **zk Verification**:
- Green bar spans ~60 seconds.
- A thin red segment (~5-10 seconds) overlays the top of the green bar, representing overhead time.
- **Legend Alignment**:
- Blue matches the "zk Proof Generation" bar.
- Green matches the "zk Verification" bar.
- Red matches the overhead segment within the green bar.
### Key Observations
1. **Dominance of Proof Generation**: The blue bar is ~3.8x taller than the green bar, indicating proof generation consumes significantly more time.
2. **Minimal Overhead**: The red segment is a small fraction (~8-17%) of the green bar, suggesting blockchain/chainlink overheads are negligible compared to verification time.
3. **Verification Efficiency**: The green bar’s compact size implies verification is relatively fast, but still dwarfed by proof generation.
### Interpretation
The data highlights a stark imbalance in computational effort:
- **Proof Generation** is the primary bottleneck, requiring ~230 seconds per operation.
- **Verification** is efficient but still time-consuming at ~60 seconds, with overheads contributing minimally (~5-10 seconds).
- The red segment’s placement atop the green bar visually emphasizes that overheads are additive but insignificant relative to verification time.
This suggests optimization opportunities for proof generation, while verification remains a secondary concern. The chart underscores the asymmetry in zk-SNARK/STARK workflows, where proof creation is resource-intensive compared to validation.
</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
## Line Graph: Transaction Fee vs. Number of Transactions
### Overview
The graph illustrates the relationship between the number of transactions and the corresponding transaction fee in ETH. The fee remains constant at 0.000574 ETH for the first 5 transactions, then drops to 0.000572 ETH for transactions 6–37. The y-axis ranges from 0.000566 to 0.000580 ETH, with the x-axis spanning 0–37 transactions.
### Components/Axes
- **X-axis (Horizontal)**: Labeled "Number of Transactions," with increments of 5 (0, 5, 10, ..., 35).
- **Y-axis (Vertical)**: Labeled "Transaction Fee (ETH)," with increments of 0.000002 ETH (0.000566, 0.000568, ..., 0.000580).
- **Legend**: Positioned at the top-right corner, indicating an orange line representing "Transaction Fee."
### Detailed Analysis
- **Initial Segment (0–5 transactions)**:
- Transaction fee remains constant at **0.000574 ETH**.
- Data points are evenly spaced along the x-axis, forming a horizontal line.
- **Post-Drop Segment (6–37 transactions)**:
- Fee decreases to **0.000572 ETH** at transaction 6 and remains constant through transaction 37.
- The line is flat, indicating no further changes in fee despite increasing transaction volume.
- **Y-axis Range**:
- The fee never exceeds 0.000574 ETH or drops below 0.000572 ETH.
### Key Observations
1. **Tiered Fee Structure**: The fee decreases by 0.000002 ETH after 5 transactions, suggesting a volume-based discount.
2. **Stability Post-Discount**: No further fee adjustments occur beyond transaction 6, even as the number of transactions increases to 37.
3. **Precision**: All values are exact (e.g., 0.000574 ETH), with no rounding or approximation.
### Interpretation
The graph demonstrates a **tiered pricing model** where transaction fees decrease after a threshold (5 transactions) and stabilize. This could incentivize users to consolidate transactions or reward high-volume activity. The absence of further discounts beyond 6 transactions implies a fixed-rate structure for larger volumes, potentially simplifying cost calculations for users. The flat line post-discount highlights efficiency in fee management for bulk transactions, though it may limit incentives for extremely high-volume users beyond 37 transactions.
</details>
Figure 13: Transaction Fee (ETH) for zk verification.
<details>
<summary>extracted/6340811/LINK_Spent.png Details</summary>
### Visual Description
## Line Graph: LINK Token Spent
### Overview
The image depicts a line graph titled "LINK Token Spent," illustrating the relationship between the number of ZK Verification Requests (x-axis) and the amount of LINK tokens spent (y-axis). The graph shows a fluctuating pattern with notable peaks, dips, and flat regions.
### Components/Axes
- **Title**: "LINK Token Spent" (centered at the top).
- **X-Axis**: "Number of ZK Verification Requests" (horizontal axis, labeled at the bottom). Scale ranges from 0 to 40 in increments of 5.
- **Y-Axis**: "LINK Token Spent" (vertical axis, labeled on the left). Scale ranges from 0.20 to 0.40 in increments of 0.05.
- **Legend**: Not visible in the image.
- **Data Line**: Orange line with circular data points (color matches the legend description).
### Detailed Analysis
- **X-Axis Labels**: Ticks at 0, 5, 10, 15, 20, 25, 30, 35, 40.
- **Y-Axis Labels**: Ticks at 0.20, 0.25, 0.30, 0.35, 0.40.
- **Data Points**:
- **0**: 0.20
- **1–4**: 0.24 (flat)
- **5**: 0.20
- **6**: 0.26
- **7–9**: 0.24 (flat)
- **10–13**: 0.24 (flat)
- **14**: 0.24
- **15–19**: 0.24 (flat)
- **20**: 0.40 (peak)
- **21**: 0.22 (dip)
- **22–24**: 0.40 (peak)
- **25–29**: 0.20 (flat)
- **30**: 0.24
- **31–32**: 0.20 (flat)
- **33–34**: 0.20 (flat)
- **35–36**: 0.24 (peak)
- **37–38**: 0.24 (flat)
- **39–40**: 0.20 (flat)
### Key Observations
1. **Peaks**:
- Two sharp spikes at x=20 and x=24, both reaching 0.40 LINK tokens spent.
- A smaller peak at x=36–37, reaching 0.24 LINK tokens spent.
2. **Dips**:
- A notable dip at x=21 (0.22 LINK tokens spent).
- Flat regions at 0.20 LINK tokens spent (x=25–29, 33–34, 39–40).
3. **Flat Regions**:
- Multiple flat segments (e.g., x=1–4, 7–9, 10–13, 15–19) indicate stable token spending despite varying verification requests.
4. **Trends**:
- The line oscillates between 0.20 and 0.40, with the highest values concentrated around x=20–24 and x=36–37.
### Interpretation
- **High Spending Correlation**: The spikes at x=20 and x=24 suggest a direct relationship between ZK Verification Requests and LINK token expenditure. This could indicate increased computational costs or system inefficiencies during these intervals.
- **Stable Spending**: Flat regions (e.g., x=25–29) imply that token spending remains constant despite fluctuations in verification requests, possibly due to optimized processes or capped resource allocation.
- **Anomalies**: The dip at x=21 (0.22) contradicts the general upward trend, potentially signaling a temporary system adjustment or error.
- **Final Dip**: The drop to 0.20 at x=39–40 may reflect reduced activity or a system reset.
### Spatial Grounding
- The title is centered at the top, with axes labeled on the left (y-axis) and bottom (x-axis). The orange line dominates the center, with data points evenly spaced along the x-axis.
### Conclusion
The graph highlights cyclical patterns in LINK token spending, with peaks likely tied to specific verification request thresholds. Further investigation into the causes of spikes (e.g., system bottlenecks) and flat regions (e.g., efficiency gains) could optimize resource allocation.
</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