2504.04794v1

# Enhancing Trust in AI Marketplaces: Evaluating On-Chain Verification of Personalized AI Models using zk-SNARKs **Authors**: Nishant Jagannath, Christopher Wong, Braden McGrath, MD Farhad Hossain, Asuquo A. Okon, Abbas Jamalipour, Kumudu S. Munasinghe > Nishant.Jagannath@canberra.edu.auSchool of IT and Systems, University of Canberra, ACT, Australia > School of IT and Systems, University of Canberra, ACT, Australia > School of Engineering and Technology, University of New South Wales, ACT, Australia > School of Electrical and Information Engineering, University of Sydney, NSW, Australia Abstract The rapid advancement of artificial intelligence (AI) has brought about sophisticated models capable of various tasks ranging from image recognition to natural language processing. As these models continue to grow in complexity, ensuring their trustworthiness and transparency becomes critical, particularly in decentralized environments where traditional trust mechanisms are absent. This paper addresses the challenge of verifying personalized AI models in such environments, focusing on their integrity and privacy. We propose a novel framework that integrates zero-knowledge succinct non-interactive arguments of knowledge (zk-SNARKs) with Chainlink decentralized oracles to verify AI model performance claims on blockchain platforms. Our key contribution lies in integrating zk-SNARKs with Chainlink oracles to securely fetch and verify external data to enable trustless verification of AI models on a blockchain. Our approach addresses the limitations of using unverified external data for AI verification on the blockchain while preserving sensitive information of AI models and enhancing transparency. We demonstrate our methodology with a linear regression model predicting Bitcoin prices using on-chain data verified on the Sepolia testnet. Our results indicate the framework’s efficacy, with key metrics including proof generation taking an average of 233.63 seconds and verification time of 61.50 seconds. This research paves the way for transparent and trustless verification processes in blockchain-enabled AI ecosystems, addressing key challenges such as model integrity and model privacy protection. The proposed framework, while exemplified with linear regression, is designed for broader applicability across more complex AI models, setting the stage for future advancements in transparent AI verification. 1 Introduction The proliferation of artificial intelligence (AI) has revolutionized the digital landscape, driving a growing demand for personalized, efficient, and reliable AI models. Developing such models, however, is resource-intensive and requires specialized expertise [1]. To bridge this gap, AI marketplaces have emerged as pivotal platforms that facilitate the exchange of personalized AI services. These marketplaces empower developers to monetize their models, providing access to sophisticated AI tools for users who may lack the capacity to develop them independently. A prime example of this trend is the ChatGPT Store [2], which offers diverse AI models tailored to various user needs. By enabling the buying, selling, and sharing of pre-trained AI models, AI marketplaces function much like software app stores but with a focus on AI capabilities rather than applications. <details> <summary>extracted/6340811/Strip-1.png Details</summary>  ### Visual Description ## Diagram: Blockchain, AI Model, and Inference Challenges ### Overview The image presents three separate diagrams illustrating challenges related to blockchain, personalized AI models, and detecting changes during inference. Each diagram is accompanied by a short descriptive title. ### Components/Axes * **Diagram 1 (Left):** * Title: "Blockchain - Lack of Inherent trust" * Components: * A brown network diagram with interconnected nodes. * A black blockchain diagram composed of connected cubes. * A central circle containing various cryptocurrency logos (H, Cardano, Polkadot, Ethereum, IOTA, and another unidentified logo). * A blue curved arrow indicating a relationship between the network diagram and the blockchain diagram. * **Diagram 2 (Center):** * Title: "Personalized AI Model - model's integrity and confidentiality issues" * Components: * A brown network diagram with interconnected nodes and directional arrows. One node is highlighted with a filled center. * **Diagram 3 (Right):** * Title: "Detecting changes to the model during inference is challenging." * Components: * A blue computer monitor icon with a sad face on the screen. * A blue warning triangle icon below the monitor. ### Detailed Analysis or ### Content Details * **Diagram 1:** The brown network diagram on the left is connected to the blockchain diagram via a blue arrow. The blockchain diagram contains a central circle with cryptocurrency logos. * **Diagram 2:** The brown network diagram in the center has several nodes connected by lines with arrows, indicating a flow or relationship between the nodes. * **Diagram 3:** The computer monitor with a sad face and the warning triangle suggest an error or problem during the inference process. ### Key Observations * The diagrams highlight potential issues with blockchain (lack of inherent trust), personalized AI models (integrity and confidentiality), and model inference (detecting changes). * The use of network diagrams in the first two illustrations suggests a focus on interconnected systems and data flow. * The third diagram uses a visual metaphor (sad computer and warning sign) to convey the difficulty of detecting changes during inference. ### Interpretation The image illustrates three distinct challenges in the context of blockchain and AI. The first diagram suggests that blockchain technology may not inherently provide trust, possibly requiring additional mechanisms for verification. The second diagram points to potential integrity and confidentiality issues with personalized AI models, likely related to data privacy and security. The third diagram highlights the difficulty of monitoring and detecting changes in AI models during the inference phase, which could lead to unexpected or undesirable outcomes. The diagrams collectively suggest the need for careful consideration of trust, security, and monitoring when implementing blockchain and AI technologies. </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 ## Diagram: Secure and Trusted Evaluation Proof & Model Inference Verification ### Overview The image presents two diagrams, labeled A and B, illustrating processes related to secure evaluation proof generation and model inference verification on decentralized oracle networks. Diagram A focuses on generating a secure and trusted evaluation proof using zero-knowledge proofs, while diagram B details the verification of model inference on decentralized oracle networks. ### Components/Axes **Diagram A: Generate a secure and trusted evaluation proof** * **Title:** A: Generate a secure and trusted evaluation proof * **Subtitle:** Benchmarked Personalized AI Model * **Process Flow:** * **Step 1 (Left):** A network of interconnected circles with arrows indicating data flow. This represents a "Benchmarked Personalized AI Model." * **Step 2 (Middle):** A "Developer" figure interacts with a "zkSNARK" (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) system, represented by a safe. An arrow indicates the generation of zero-knowledge proofs. A lock icon above the developer and safe suggests security. * **Step 3 (Right):** A document with a stamp, representing a validated proof. * **Step 4 (Far Right):** A blockchain network represented by interconnected cubes, containing various cryptocurrency logos (e.g., Bitcoin "B", Ethereum "E", Cardano "A", etc.). The text indicates that the "Validated Proof" is shared on the blockchain. **Diagram B: Verifying model inference on decentralized oracle networks** * **Title:** B: Verifying model inference on decentralized oracle networks * **Subtitle:** Personalized AI models deployed in a decentralized marketplace * **Process Flow:** * **Step 1 (Left):** A network of interconnected circles, representing "Personalized AI models deployed in a decentralized marketplace." This network is connected to a blockchain network (similar to Diagram A) via a curved arrow. * **Step 2 (Middle):** A "Decentralized oracle network" represented by a network of interconnected circles. Inside the network are the logos of two cryptocurrencies. * **Step 3 (Center):** A "zk-verification" process, depicted as a simplified circuit board with binary code (10100, 11010). An arrow points downwards to a document with a stamp, indicating the result being returned to the blockchain. * **Step 4 (Right):** A blockchain network (similar to Diagram A). * **Step 5 (Far Right):** A dashed box containing two documents, one with a question mark. The text states, "The new proof is matched against the validated proof previously shared on the blockchain." ### Detailed Analysis or Content Details **Diagram A:** * The AI model network consists of approximately 7 circles, with arrows indicating data flow between them. * The "zkSNARK" system is depicted as a safe with a digital display. * The blockchain network consists of 8 cubes interconnected, with cryptocurrency logos inside a central circle. **Diagram B:** * The decentralized oracle network consists of approximately 20 interconnected circles. * The "zk-verification" circuit board has approximately 10 vertical lines and the binary code "10100" and "11010". * The blockchain network consists of 8 cubes interconnected, with cryptocurrency logos inside a central circle. ### Key Observations * Both diagrams utilize blockchain networks as a final step, indicating the importance of blockchain technology in secure evaluation and verification processes. * Zero-knowledge proofs and zk-verification are central to both processes, highlighting the focus on privacy and security. * Diagram B emphasizes the decentralized nature of the oracle network and the marketplace for AI models. ### Interpretation The diagrams illustrate the process of ensuring the security and trustworthiness of AI models and their inferences in decentralized environments. Diagram A focuses on generating a secure evaluation proof using zero-knowledge proofs, ensuring that the evaluation process itself is trustworthy. Diagram B focuses on verifying the inference of AI models on decentralized oracle networks, ensuring that the results are accurate and reliable. The use of blockchain technology in both diagrams provides a transparent and immutable record of the processes, further enhancing trust and security. The diagrams suggest a move towards more secure and decentralized AI systems, where privacy and verifiability 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 ## System Diagram: Decentralized AI Marketplace with zkSNARK ### Overview The image is a system diagram illustrating a decentralized AI marketplace that utilizes zero-knowledge Succinct Non-Interactive Argument of Knowledge (zkSNARK) for secure and trusted model inference on decentralized oracle networks. The diagram is divided into on-chain and off-chain components, showing the flow of data and processes involved in training, validating, and using AI models. ### Components/Axes The diagram includes the following key components: 1. **On-Chain Data (Top-Left)**: Represents the initial data used for training AI models. It includes "Data Cleaning" and "Data Normalization" steps, followed by "Correlation Analysis". 2. **Personalized AI Model (Top-Center)**: Shows the AI model developed from the training data. 3. **Generation of Zero Knowledge Proofs (Top-Right)**: Depicts the process of generating zkSNARK proofs, involving a "Developer" and the "zkSNARK" system. 4. **On-chain/Off-chain Division (Center)**: Separates the on-chain and off-chain processes. 5. **Decentralized AI Marketplace (Left)**: Includes "Sellers" (represented by purple figures) and "Buyers" (represented by green figures). AI models (represented by AI icons) are transferred from sellers to buyers. 6. **Oracle Request (Right-Center)**: Represents a request sent to the oracle network. 7. **Decentralized Oracle Network (Right)**: A network of nodes providing data and computation. Each node is labeled "SE" (Sandboxed Execution). 8. **Computation Request (Right)**: A request for computation sent to the sandboxed execution environment. 9. **API Request (Bottom-Right)**: A request for data from API providers. 10. **API Response (Bottom-Right)**: The data returned from API providers. 11. **Result (Right-Center)**: The result of the computation sent back to the blockchain. 12. **Smart Contract (Center-Right)**: A smart contract on the blockchain that manages the oracle request. 13. **Blockchain (Center)**: Represents the blockchain network. It contains icons representing various cryptocurrencies. 14. **Proof Matching (Bottom-Center)**: Depicts the process of matching the new proof against the validated proof previously shared on the blockchain. The diagram also includes the following text labels: * "A: Generate a secure and trusted evaluation proof" (Bottom-Left) * "B: Verifying model inference on decentralized oracle networks using zkSNARK" (Bottom) * "Validated Proof shared on the blockchain" (Top-Center) * "The new proof is matched against the validated proof previously shared on the blockchain" (Bottom-Center) * "Training Data" (Top-Left) * "request" (Center-Right) * "result" (Center-Right) * "Oracle request" (Center-Right) * "API providers for on-chain and off-chain data" (Bottom-Right) * "zk verification" (Right) ### Detailed Analysis or ### Content Details The diagram illustrates the following flow of information: 1. **Training Data (1)**: On-chain data is cleaned, normalized, and analyzed to create training data. 2. **Personalized AI Model (2)**: The training data is used to develop a personalized AI model. 3. **Zero-Knowledge Proof Generation (3)**: A zkSNARK proof is generated to validate the AI model. 4. **On-Chain/Off-Chain Division (4)**: The validated proof is shared on the blockchain. 5. **Decentralized AI Marketplace (5)**: Sellers offer AI models to buyers. 6. **Oracle Request (6)**: A request is sent to the oracle network via a smart contract. 7. **Decentralized Oracle Network (7)**: The oracle network processes the request. 8. **Computation Request (8)**: A computation request is sent to a sandboxed execution environment. 9. **API Request (9)**: The sandboxed execution environment requests data from API providers. 10. **API Response (10)**: API providers return data. 11. **Result (11)**: The result of the computation is sent back to the blockchain. 12. **Smart Contract (12)**: The smart contract manages the oracle request and result. 13. **Blockchain (13)**: The blockchain stores the validated proof and the results of the computation. 14. **Proof Matching (14)**: The new proof is matched against the validated proof previously shared on the blockchain. ### Key Observations * The diagram highlights the use of zkSNARKs to ensure the integrity and security of AI model inference on decentralized oracle networks. * The separation of on-chain and off-chain processes allows for efficient computation and data storage. * The decentralized AI marketplace enables sellers and buyers to exchange AI models in a secure and transparent manner. * The decentralized oracle network provides access to external data and computation resources. ### Interpretation The diagram illustrates a comprehensive system for secure and trusted AI model inference in a decentralized environment. The use of zkSNARKs ensures that the results of the computation are valid without revealing the underlying data or model. This is crucial for maintaining privacy and security in sensitive applications. The decentralized AI marketplace enables a more open and accessible ecosystem for AI model development and deployment. The integration with decentralized oracle networks allows for access to real-world data and computation resources, enabling a wide range of applications. The system addresses the challenges of trust and security in decentralized AI by leveraging cryptographic techniques and distributed infrastructure. </details> Figure 3: Proposed verification framework. 3 Methodology and System Design This section describes the methodology as shown in Fig. 3 for verifying the performance claims of a personalized AI model without revealing weights and are trained on on-chain and user-specific data to predict Bitcoin prices. The verification process is computed on Chainlink’s decentralised oracle network using zk-SNARKs. We divide the section into two parts and explain these parts with respect to Fig. 3. In Part A, we provide the system overview of our proposed framework. Part B outlines the steps to generate a secure and trusted evaluation proof and Part C describes the verification process for the model inference on a decentralized oracle network using zk-SNARKs. 3.1 System Overview Trust is a major concern for users in the Web3 domain, particularly on the blockchain. Trust issues also extend to the blockchain-enabled AI marketplace, where the credibility of developers’ performance claims for personalized AI models is questioned. The blockchain-enabled AI marketplace combines on-chain and off-chain elements to enhance the verifiability of verifications. The framework represented in Fig. 3 is specifically designed to enable personalized AI model performance verification using zk-SNARKs. The interaction between on-chain smart contracts and off-chain Chainlink oracles is crucial for the functioning of the blockchain-enabled AI marketplace. The interaction guarantees that the data, computation, and proof validation are carried out securely and efficiently. We analyze the on-chain data from external API providers and eliminate inaccurate data points. The data is carefully scaled to uncover and examine the connections between important data points in the model’s output. After the training and testing of the personalized AI model, developers generate zk-SNARK proofs to verify the AI model’s claim without exposing sensitive data such as model weights. These verifiable proofs are shared on the blockchain. Prior to purchasing the personalized AI model, the buyer demands proof to verify the performance claim of the personalized AI model. The decentralized oracle network is used for verification using the Chainlink Functions, as requested by the blockchain. The Chainlink nodes facilitates the coordination of data acquisition from external API providers for on-chain data and the execution of computations. Each node in the Chainlink carries out sandboxed execution of the provided source code to ensure transparency. The aggregated results are sent to the smart contract using Chainlink’s Off-Chain Reporting (OCR) protocol [43]. The smart contract on Sepolia receives the aggregated result and zk-SNARK proof. The blockchain verifies the proof using stored verification keys and updates the state of the blockchain based on the verification outcome. Verified proofs are stored on-chain for future reference, ensuring a transparent and tamper-proof record of all computations. This framework provides a practical approach to verifying personalized AI models. Incorporating zk-SNARK ensures the privacy of model weights during verification, enhancing trust and transparency in AI model marketplaces. The integration of zk-SNARKs into Chainlink functions facilitates secure and reliable data fetching and computation, offering a robust AI model verification framework that can be implemented in real-world scenarios. To summarize the interactions in the proposed verification framework, Fig. 3 represents the framework for verifying personalized AI model performance using zk-SNARKs. In Step 1, The process begins with developers training personalized AI models, followed by data cleaning, normalization, and correlation analysis. In Step 2, developers generate zk-SNARK proofs to verify model performance claims without revealing sensitive data and upload these proofs to the blockchain. In Step 3, buyers initiate verification requests, which the decentralized oracle network processes by fetching data from external APIs and performing zk-SNARK verification in a sandboxed environment. In Step 4, the Chainlink oracles communicates results back to the blockchain smart contract via Chainlink’s Off-Chain Reporting protocol. In Step 5, the blockchain then validates the proofs using stored verification keys and updates the state of the decentralized marketplace, ensuring a transparent and tamper-proof record of all zk-SNARK verifications. 3.2 Generate a Secure and Evaluation Proof 3.2.1 Personalized AI model - Introduction to Personalization Personalized AI models provide customized predictions by utilizing on-chain data and user data. For example, the model can be personalized when predicting Bitcoin prices to consider the user’s unique trading patterns, preferences, and other data points affecting their investment choices. Data Collection: Developers acquire on-chain data in two ways. The first method involves collecting and processing raw on-chain data from the public Bitcoin blockchain. The second method uses external application programming interface (API) providers where the on-chain data is already preprocessed and ready to use. We obtained on-chain data from 2016 to 2023 from API providers such as [44], [45]. With the on-chain data collected from these sources, we categorized and analyzed metrics from each category against Bitcoin’s price. We also use user-specific data such as transaction history and wallet activity. The following metrics are obtained from the on-chain data; block size, block height, transaction count, daily active addresses, miners revenue, miner fees, miner to exchanges, total new addresses, transactions rate, transfers count, hash rate, transactions difficulty, transfer rate, wallets address with greater than 1, 10 and 100 coins, exchange deposits, exchange withdrawals and total addresses. Data Analysis: The on-chain data closely correlating to the bitcoin price are identified. This step involves using a Pearson and Spearman correlation analysis to understand the linear and non-linear relationship between the on-chain datasets and the bitcoin price. The Pearson correlation can be represented by equation (1) $$ r=\frac{\sum_{i=1}^{n}(x_{i}-\bar{x})(y_{i}-\bar{y})}{\sqrt{\sum_{i=1}^{n}(x_{% i}-\bar{x})^{2}\sum_{i=1}^{n}(y_{i}-\bar{y})^{2}}} \tag{1} $$ where: - $x_{i}$ is the $i$ -th data point of features of on-chain data - $y_{i}$ is the $i$ -th data point of bitcoin price - $\bar{x}$ is the mean of the $x$ values - $\bar{y}$ is the mean of $y$ values - $n$ is the total number of data points The Spearman rank correlation coefficient [46] is a nonparametric measurement correlation used to evaluate the monotonic relationship between two variables. $$ \rho=1-\frac{6\sum{d_{i}}^{2}}{n({n}^{2}-1)} \tag{2} $$ In (2), the difference between the ranks of the $i$ -th pair of values is represented by $d_{i}$ and $n$ represents the total number of data points. Pearson correlation coefficients are used to quantify the linear connection between variables. In contrast, Spearman correlation coefficients are only applicable to monotonic connections, in which variables tend to move in the same or opposite direction but not necessarily at the same rate. In a linear relationship, the rate is constant. We re-scale the data between the range [0,1]. The normalization value is calculated using equation (3). $$ z=\frac{x_{i}-\min(x)}{\max(x)-\min(x)} \tag{3} $$ By conducting correlation analysis, we can pinpoint important on-chain metrics that can be incorporated into advanced predictive algorithms. Conversely, we can also identify metrics that could be more relevant and should be considered. Introduction to zk-SNARKs: A zk-SNARK allows a prover to convince a verifier that they know a solution to a computational problem without disclosing the solution itself. These proofs are short and fast to verify, and they do not require ongoing interaction between the prover and the verifier after the initial setup. A zk-SNARK system comprises three core algorithms: Generation (Gen), Prover (P) and Verification (V). Non-Interactive Zero-Knowledge Argument The arithmetic circuits in zk-SNARKs play a critical role in representing the computational problem that the prover aims to demonstrate to the verifier that it has been solved correctly. In the context of the non-interactive zero-knowledge argument, let $C$ be an arithmetic circuit such that $C:F^{n}× F^{n^{\prime}}→ F^{l}$ . Here, $F$ denotes a finite field and $F^{n}$ represents a vector space of dimension $n$ over the finite field $F$ . Similarly, $F^{n^{\prime}}$ and $F^{l}$ indicate vector spaces of dimensions $n^{\prime}$ and $l$ over $F$ , respectively. The NP language $L$ is defined as the set of statements $x$ in $F^{n}$ for which there exists a valid witness $w$ in $F^{n^{\prime}}$ . This is represented by the relation $R$ defined as $R:=\{(x,w)∈ F^{n}× F^{n^{\prime}}\}$ , where $w$ is the witness and $x$ is the statement. A non-interactive zero-knowledge argument for the relation $R$ consists of the triple of polynomial-time algorithms: Generation (Gen), Prover (P), and Verification (V). - Generation (Gen): Produces a common reference string (crs) and a private verification state. $$ (\text{crs})\leftarrow\text{Gen}(1^{n},R) $$ - Prover (P): Produces a proof $\pi$ for a statement $x$ using a witness $w$ . $$ \pi\leftarrow\text{P}(\text{crs},x,w) $$ - Verification (V): Verifies the proof $\pi$ for the statement $x$ . $$ \text{V}(\text{crs},x,\pi)\rightarrow\{0,1\} $$ Properties of zk-SNARKs The following properties [47] must be met by a non-interactive zero-knowledge proof $\pi$ for the relation $R$ : - Completeness: For a statement $x∈ F^{n}$ with a witness $w∈ F^{n^{\prime}}$ such that $(x,w)∈ R$ , the prover acting honestly always produces a valid proof $\pi$ . This proof should be sufficient to convince an honest verifier. The completeness of the non-interactive zero-knowledge proof can be expressed as follows [48]: $$ \Pr\left[\begin{array}[]{c}(\text{crs})\leftarrow\text{Gen}(1^{n},R)\\ \pi\leftarrow\text{P}(\text{crs},x,w)\\ \text{V}(\text{crs},x,\pi)=1\text{ if }(x,w)\in R\end{array}\right]=1 \tag{4} $$ - Soundness: When an adversary attempts to deceive by providing a proof $\pi$ for a false statement $x∉ R$ , the verification algorithm V is designed to have a high probability of rejecting the proof. Any evidence $\pi$ offered by an adversary will be rejected with a high probability due to the soundness requirement, which ensures that $x$ must be in the relation $R$ [28]: $$ \Pr\left[\begin{array}[]{c}(\text{crs})\leftarrow\text{Gen}(1^{n},R)\\ (x,\pi)\leftarrow\mathcal{A}(\text{crs})\\ \text{V}(\text{crs},x,\pi)=1\text{ and }(x,w)\notin R\end{array}\right]\leq% \text{negl}(n) \tag{5} $$ Furthermore, suppose there is an extractor $\mathcal{E}$ that can generate the witness $w←\mathcal{E}_{\mathcal{A}}(\text{crs})$ based on the output of an adversary $\mathcal{A}$ , which produces a valid argument $(x,\pi)←\mathcal{A}(\text{crs})$ : $$ \Pr\left[\begin{array}[]{c}(\text{crs})\leftarrow\text{Gen}(1^{n},R)\\ (x,\pi)\leftarrow\mathcal{A}(\text{crs})\\ w\leftarrow\mathcal{E}_{\mathcal{A}}(\text{crs})\\ \text{V}(\text{crs},x,\pi)=1\text{ and }(x,w)\notin R\end{array}\right]\leq% \text{negl}(n) \tag{6} $$ - Zero-Knowledge: This characteristic ensures that the verifier only gains knowledge of the statement’s truth. In zk-SNARKs, Tau refers to the trusted setup parameter generated during the initial phase, creating a secure cryptographic environment. The Powers of Tau (PoT) ceremony generates these parameters, which are necessary for generating and verifying zk-SNARK proofs, ensuring privacy. In the Phase 2, the crs is further refined to support the specific zk-SNARK application, introducing additional complexity as it tailors the parameters to the operations of the AI model being verified. Together, PoT and Phase 2 form the backbone of the trusted setup, ensuring a robust and reliable foundation for zk-SNARK operations. Without knowing the witness $w$ , the proof or argument $\pi$ for a valid assertion $x$ can be simulated using a polynomial-time procedure known as a simulator. Simulator 1 $(S_{1})$ generates a simulated proof based on the crs and the random Tau parameter. This demonstrates that the proof system can function without accessing private data thus maintaining the zero-knowledge property. Simulator 2 $(S_{2})$ simulates the zk-SNARK proof using the input, output pair and a random Tau. This confirms that the system can generate valid proofs without revealing sensitive information, completing the zero-knowledge simulation. The zero-knowledgeness can be expressed as follows [48]: $$ \Pr\left[\begin{array}[]{c}(\text{crs})\leftarrow\text{Gen}(1^{n},R)\\ (x,w)\leftarrow\mathcal{A}(\text{crs})\\ \pi\leftarrow\text{P}(\text{crs},x,w)\\ \mathcal{A}(\pi)=1\end{array}\right]=\Pr\left[\begin{array}[]{c}(\text{crs},% \tau)\leftarrow S_{1}(1^{n},R)\\ (x,w)\leftarrow\mathcal{A}(\text{crs})\\ \pi\leftarrow S_{2}(\text{crs},x,\tau)\\ \mathcal{A}(\pi)=1\end{array}\right] \tag{7} $$ 3.2.2 Conversion of Linear Regression Model to zk-SNARK Circuit for Validation We use zk-SNARKs to generate verifiable computations on-chain of the model without revealing its weights. The linear regression model is converted into a zk-SNARK circuit to represent the model’s internal operations. The following steps are used in converting the linear regression model into a zk-SNARK circuit: Step 1: Model Representation The developer trains the personalized AI model, specifically a linear regression model that predicts Bitcoin prices based on historical on-chain data. The model takes various features (independent variables) from the on-chain data and user-specific data, such as transaction history and wallet activity of the user, and predicts the price (dependent variable) of Bitcoin. The linear regression model is represented using (8): $$ y=a_{0}+a_{1}x_{1}+a_{2}x_{2}+\ldots+a_{n}x_{n}+C \tag{8} $$ where: - $y$ is the predicted bitcoin price. - $x_{i}$ are the features of on-chain and user-specific data. - $a_{i}$ are the coefficients (weights) learned during training. - $C$ is the intercept. Step 2: Arithmetic Circuit Construction The linear regression model equation is converted into an arithmetic circuit to permit proving zk-SNARK based computational statements. Each mathematical operation in the linear regression model is mapped to a multiplication and addition gate in zk-SNARKs. For example, the operation $a_{1}x_{1}$ is handled by multiplication gates and sum $a_{0}$ + $a_{1}x_{1}$ is handled by addition gates. The final output $y$ is computed by using addition gates adding all terms together. This process transforms the linear regression equation into an arithmetic circuit that is compatible with zk-SNARKs. Step 3: QAP Conversion The models arithmetic circuit are converted into a QAP, providing a framework for zk-SNARKs to check the correctness of the operations in the arithmetic circuit. A QAP for a function $f$ is defined by three sets of polynomials $\{v_{i}(x)\},\{w_{i}(x)\},\{y_{i}(x)\}$ and a target polynomial $t(x)$ . For an arithmetic circuit $C$ with $m$ gates: $$ p(x)=\left(\sum_{i=0}^{m}a_{i}\cdot v_{i}(x)\right)\cdot\left(\sum_{i=0}^{m}a_% {i}\cdot w_{i}(x)\right)-\left(\sum_{i=0}^{m}a_{i}\cdot y_{i}(x)\right) \tag{9} $$ where $t(x)$ divides $p(x)$ and $a_{i}$ represents the coefficients of the polynomials. The QAP introduces constraints that must be satisfied to ensure all operations in the arithmetic circuit are represented correctly in zk-SNARK form. The complexity of these QAP constraints increases with larger number of features in the linear regression model. As the complexity of the AI models increases, it will require more number of gates to represent model internal operations, leading to higher computational resources and longer proof generation times. Step 4: zk-SNARK Proof Generation and Verification The prover generates a proof $\pi$ demonstrating they know $\{a_{i}\}$ satisfying the Quadratic Arithmetic Program (QAP) equations: $$ \pi=(A,B,C) \tag{10} $$ where: $$ A=\sum_{i=0}^{m}a_{i}\cdot g^{v_{i}(s)},\quad B=\sum_{i=0}^{m}a_{i}\cdot g^{w_% {i}(s)},\quad C=\sum_{i=0}^{m}a_{i}\cdot g^{y_{i}(s)} $$ The polynomials ${v_{i}(s)},{w_{i}(s)},{y_{i}(s)}$ represent the QAP for the arithmetic circuit. These polynomials are evaluated at a secret value $s$ . The components of the zk-SNARK proof are represented by $A,B,C$ and the generator of a cryptographic group by $g$ , which is used to generate all the elements of the group through its powers. The verifier checks the proof by ensuring: $$ e(A,B)=e(g,C)\cdot e(g^{t(s)},g) \tag{11} $$ where $e(A,B)$ represents the bilinear pairing function used for verification and $t(s)$ is the target polynomial evaluated at the secret value $s$ . 3.3 Verifying Model Inference on Decentralized Oracle Network Using zk-SNARKs In this paper, we use the Chainlink Decentralized Oracle Network (DON), hereafter referred to as Chainlink oracles, to perform off-chain computations and relay data to the blockchain. The blockchain component in our framework is represented by the Sepolia testnet, which serves as a proxy for a production blockchain environment. Chainlink Functions enable smart contracts to access a computing infrastructure that is trust-minimized. Smart contracts can access on-chain and off-chain data from APIs and perform personalized computations. By seamlessly integrating these functions with the Sepolia testnet, we can efficiently execute zero-knowledge (zk) verification computations on chainlink’s decentralized oracle network, ensuring that verified results are returned to the blockchain. Smart contracts utilize the Chainlink nodes to retrieve data from external APIs by sending requests for source code. Every node in the Chainlink carries out the code within a secure and sandboxed execution, efficiently handling the required computations. The zk-SNARK circuits use the obtained data to perform computations without disclosing confidential details. The process yields zk-SNARK proofs that showcase accurate computation using input data. The results are sent to the Sepolia testnet through smart contracts after completing the necessary proofs. These smart contracts validate the proofs and update the state of the blockchain. Once the results have been verified, they can be easily accessed in other smart contracts, ensuring secure and reliable interactions. 4 Experimental Setup The experimental setup used in our study consists of two phases: the proof generation phase and the proof verification phase. The proof generation phase involves an in-depth exploration of the processing environment and configuration details pertinent to a personalized AI model’s zk proof generation process. The proof verification phase delves into the implementation steps associated with deploying zero-knowledge proof on the blockchain and verifying zero-knowledge proofs using Chainlink oracles. 4.1 Proof Generation Phase The proof generation setup uses an NVIDIA Jetson TX2, a cutting-edge device known for its high computational power and energy efficiency. The specifications of NVIDIA are listed in Table 1. | CPU | 6 ARM Cortex-A57 | | --- | --- | | GPU | 256-core NVIDIA Pascal | | Memory | 8GB LPDDR4 | Table 1: Nvidia Jetson TX2 specifications We selected this device due to its suitability for AI applications, which are known to require significant computational resources. Our objective was to develop zk-SNARK circuits designed to generate zero-knowledge proofs. These circuits are specifically tailored for a linear regression model, utilizing characteristics obtained from the on-chain data of Bitcoin as a CSV file. The linear regression model coefficients, including the model weights, were saved in a JSON file. We used Python scripts to automate the process of generating circuit files. These scripts received the JSON data and produced multiple Circom files, each representing a distinct number of weights. Creating and confirming proofs involves building zk circuits using the Circom programming language, generating witnesses, and then proving and checking the proofs using the Snarkjs library. The automated script managed the complete procedure, encompassing compilation, witness production, contribution to the ceremony, preparation for phase 2, zkey generation, and proof generation and verification. We used the Circom tool to generate a smart contract-based verifier that allows proofs to be verified on the blockchain. Remix was used to deploy the Verifer smart contract on the blockchain. The trusted setup was conducted by a consortium of stakeholders, including model developers, auditors and decentralized oracle providers. This collaborative approach ensures trust in the setup process and mitigates the risk of a single point of failure. 4.2 Proof Verification Phase For this experiment, we chose the Sepolia testnet because it is widely used among developers and one of the few testnets supported by Chainlink. The experimental findings are relevant and applicable to live production settings like the Ethereum main network. We deployed the verifier smart contract on the testnet for zk verification purposes, ensuring the thoroughness of our testing process. We set up Chainlink Functions to integrate the decentralized oracle network to the Sepolia testnet. We cloned the Chainlink Functions starter kit from the official GitHub repository [49]. This configuration offered the essential resources to interact with the blockchain and Chainlink oracle networks. Subsequently, we modified the Functions request configuration file to explicitly define the source code for API calls and perform computations based on the smart contract request. We established the environment variables using encrypted data for access. This process involved establishing the environment variable file’s password and configuring the environment variable by specifying the key and value. We used four keys to setup the experiment: - A private key obtained from the MetaMask wallet. - An Remote Procedure Call (RPC) URL derived from the Alchemy website for the Sepolia testnet. - An API token for GitHub. - An API for the blockchain explorer Etherscan <details> <summary>extracted/6340811/12.png Details</summary>  ### Visual Description ## Console Output: Contract Deployment and Verification ### Overview The image shows a console output log related to the deployment and verification of a smart contract named "FunctionsConsumer" on the Ethereum Sepolia test network. It includes transaction details, contract addresses, and verification status. ### Components/Axes * **Textual Log:** The image consists of a series of text-based messages indicating the progress of contract deployment and verification. * **Transaction Hash:** `0x7fdca8a958ef7c843a02fbb7fe8bad116b4201579e615d97dbd04b2ef46ec8e2` * **Contract Address:** `0xe953b197cCC443e3d8664962C1e1dD4abc33701d` * **Network:** ethereumSepolia ### Detailed Analysis or ### Content Details 1. **Waiting for Confirmation:** The initial message indicates that the system is waiting for 2 blocks to confirm the transaction with hash `0x7fdca8a958ef7c843a02fbb7fe8bad116b4201579e615d97dbd04b2ef46ec8e2`. 2. **Contract Deployment:** The "FunctionsConsumer" contract is deployed to the address `0xe953b197cCC443e3d8664962C1e1dD4abc33701d`. 3. **Contract Verification:** The system initiates the contract verification process. 4. **Verification Status:** The contract at address `0xe953b197cCC443e3d8664962C1e1dD4abc33701d` has already been verified. 5. **Final Deployment Confirmation:** The "FunctionsConsumer" contract is confirmed to be deployed at address `0xe953b197cCC443e3d8664962C1e1dD4abc33701d` on the ethereumSepolia network. ### Key Observations * The contract deployment and verification process appears to be successful. * The same contract address is consistently used throughout the log. * The log confirms the deployment on the ethereumSepolia test network. ### Interpretation The console output demonstrates the successful deployment and verification of the "FunctionsConsumer" smart contract on the Ethereum Sepolia test network. The process involves waiting for transaction confirmation, deploying the contract to a specific address, and verifying the contract's code. The log provides essential information for tracking and confirming the deployment process. </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 ## Terminal Output: Funding a Subscription ### Overview The image shows a terminal output of a process involving funding a subscription with LINK tokens. It includes confirmation prompts, transaction details, and subscription information. ### Components/Axes * **Header**: "secp256k1 unavailable, reverting to browser version" * **Process Messages**: * "Creating Functions billing subscription..." * "Created Functions billing subscription: 3053" * "Please confirm that you wish to fund Subscription 3053 with 2 LINK from your wallet." * "Continue? Enter (y) Yes / (n) No" * User input: "y" * "Funding subscription 3053 with 2 LINK..." * "Subscription 3053 funded with 2 LINK in Tx: 0x8201e5b295946017ffca3dc688b9c88a79c7140179b328c2fb83fefc446961d5" * **Subscription Info**: * balance: '2.0 LINK' * owner: '0x4ec77d7AaB8e69c2A8F7CE3d4106415696279478' * blockedBalance: '0.0 LINK' * proposedOwner: '0x0000000000000000000000000000000000000000' * consumers: ['0xe953b197cCC443e3d8664962C1e1d04abc33701d' ], * flags: '0x0000000000000000000000000000000000000000000000000000000000000000' ### Detailed Analysis or Content Details The process starts with a message indicating that `secp256k1` is unavailable, and the system is reverting to the browser version. A billing subscription is being created, specifically subscription number 3053. The user is prompted to confirm funding the subscription with 2 LINK tokens. The user confirms by entering "y". The system then funds the subscription, and a transaction hash (Tx) is provided: `0x8201e5b295946017ffca3dc688b9c88a79c7140179b328c2fb83fefc446961d5`. The subscription information includes: * A balance of 2.0 LINK. * The owner's address: `0x4ec77d7AaB8e69c2A8F7CE3d4106415696279478`. * A blocked balance of 0.0 LINK. * A proposed owner address of all zeros: `0x0000000000000000000000000000000000000000`. * A list of consumers containing one address: `0xe953b197cCC443e3d8664962C1e1d04abc33701d`. * Flags set to all zeros: `0x0000000000000000000000000000000000000000000000000000000000000000`. ### Key Observations * The `secp256k1` library is unavailable, which might indicate a performance fallback. * The user interaction is minimal, requiring only a "y" to confirm the transaction. * The subscription is funded with 2 LINK tokens. * The proposed owner is set to the zero address, which might indicate that ownership transfer is not currently in progress. * The flags are set to zero, which might indicate default settings or no specific flags being active. ### Interpretation The terminal output shows a successful funding of a subscription (3053) with 2 LINK tokens. The process involves a confirmation step from the user. The subscription information provides details about the current state of the subscription, including the balance, owner, and consumers. The zeroed-out proposed owner and flags might indicate default or inactive states for those parameters. The unavailability of `secp256k1` suggests a fallback mechanism is in place, possibly affecting performance. </details> Figure 5: Funding the subscription <details> <summary>extracted/6340811/n123.png Details</summary>  ### Visual Description ## Screenshot: Blockchain Transaction Confirmation ### Overview The image is a screenshot of a terminal or console output, displaying information about a blockchain transaction. It shows confirmation messages, transaction details, and cost information related to a request. ### Components/Axes * **Header**: "secp256k1 unavailable, reverting to browser version" * **Request Initiation**: "Make request..." * **Confirmation Messages**: * "Functions request sent! Transaction hash 0xc90a46e4f58a2831b8099e6b0b17009aa906ec2a3aa3184b31703e72cdffefb9. Waiting for a response..." * "See your request in the explorer https://sepolia.etherscan.io/tx/0xc90a46e4f58a2831b8099e6b0b17009aa906ec2a3aa3184b31703e72cdffefb9" * "Request 0x2afe734c0a40bf743b3994963da56c1677efca2c5ca15410166060b88996aaf7 successfully fulfilled. Cost is 0.204179266937581512 LINK." * **Response Details**: * "requestId: '0x2afe734c0a40bf743b3994963da56c1677efca2c5ca15410166060b88996aaf7'," * "subscriptionId: 3088," * "totalCostInJuels: 204179266937581512n," * "responseBytesHexstring: '0x526573756c743a2066616c73650a636f6e74726163742074696d65320333632'," * "errorString: ''," * "returnDataBytesHexstring: '0x'," * "fulfillmentCode: 0" ### Detailed Analysis or Content Details * The initial message "secp256k1 unavailable, reverting to browser version" indicates a potential issue with the cryptographic library being used, causing a fallback to a browser-based version. * The transaction hash is "0xc90a46e4f58a2831b8099e6b0b17009aa906ec2a3aa3184b31703e72cdffefb9". * The request was successfully fulfilled. * The cost of the request was 0.204179266937581512 LINK. * The subscription ID is 3088. * The total cost in Juels is 204179266937581512n. * The responseBytesHexstring translates to "Result: false contract time20333632". ### Key Observations * The transaction was successful, as indicated by the "successfully fulfilled" message. * The cost of the transaction is explicitly stated in both LINK and Juels. * The response data provides information about the result of the transaction. ### Interpretation The screenshot provides a detailed log of a blockchain transaction, from initiation to fulfillment. It shows that a request was made, processed, and successfully completed. The information includes the transaction hash, cost, and response data, which are essential for auditing and debugging purposes. The initial message about "secp256k1 unavailable" might indicate a potential performance issue or dependency problem that needs to be addressed. The responseBytesHexstring indicates the result was false, and the contract time is 20333632. </details> Figure 6: Chainlink functions API and computation Output 5 Experimental Results and Analysis <details> <summary>extracted/6340811/Distribution.png Details</summary>  ### Visual Description ## Histogram Grid: Compilation and Verification Time Distributions ### Overview The image presents a grid of 12 histograms, each displaying the distribution of time (in milliseconds) for different stages in a cryptographic process. The stages include compilation, witness generation, proof generation, and other related operations. All histograms share a consistent visual style, using light blue bars with black outlines and gridlines in the background. The y-axis represents frequency, and the x-axis represents time in milliseconds. ### Components/Axes Each histogram has the following components: * **Title:** Indicates the specific stage of the process being measured (e.g., "Distribution of Compile Time"). * **X-axis:** Labeled "Time (ms)" with varying scales depending on the time range for each stage. * **Y-axis:** Labeled "Frequency," indicating the number of occurrences within each time interval. * **Bars:** Light blue bars representing the frequency of times within specific ranges. * **Gridlines:** Light gray gridlines behind the bars to aid in reading values. ### Detailed Analysis Here's a breakdown of each histogram, including approximate values: 1. **Distribution of Compile Time:** * X-axis: 0.24 to 0.28 ms * Peak frequency: Around 9-10, between 0.25 and 0.26 ms. * Frequencies: * 0.24-0.25 ms: ~3 * 0.25-0.26 ms: ~9-10 * 0.26-0.27 ms: ~4 * 0.27-0.28 ms: ~2 2. **Distribution of Witness Time:** * X-axis: 0.190 to 0.220 ms * Peak frequency: Around 8-9, between 0.195 and 0.200 ms. * Frequencies: * 0.190-0.195 ms: ~4 * 0.195-0.200 ms: ~8-9 * 0.200-0.205 ms: ~5 * 0.205-0.210 ms: ~2 * 0.210-0.215 ms: ~2 * 0.215-0.220 ms: ~2 3. **Distribution of Pot Time:** * X-axis: 3.15 to 3.45 ms * Peak frequency: Around 12, between 3.15 and 3.20 ms. * Frequencies: * 3.15-3.20 ms: ~12 * 3.20-3.25 ms: ~7 * 3.25-3.30 ms: ~3 * 3.45-3.50 ms: ~1 4. **Distribution of Pot Ceremony Time:** * X-axis: 16.8 to 18.0 ms * Peak frequency: Around 7-8, between 17.2 and 17.4 ms. * Frequencies: * 16.8-17.0 ms: ~2 * 17.0-17.2 ms: ~7 * 17.2-17.4 ms: ~7-8 * 17.4-17.6 ms: ~6 * 17.8-18.0 ms: ~2 5. **Distribution of Phase Two Initiation Time:** * X-axis: 195 to 220 ms * Peak frequency: Around 18-19, between 195 and 200 ms. * Frequencies: * 195-200 ms: ~18-19 * 200-205 ms: ~13 * 215-220 ms: ~1 6. **Distribution of Z Key Generation Time:** * X-axis: 3.3 to 3.7 ms * Peak frequency: Around 9-10, between 3.3 and 3.4 ms. * Frequencies: * 3.3-3.4 ms: ~9-10 * 3.4-3.5 ms: ~9 * 3.5-3.6 ms: ~5 * 3.7-3.8 ms: ~1 7. **Distribution of Phase Two Ceremony Time:** * X-axis: 2.325 to 2.525 ms * Peak frequency: Around 8-9, between 2.375 and 2.400 ms. * Frequencies: * 2.325-2.350 ms: ~5 * 2.350-2.375 ms: ~7 * 2.375-2.400 ms: ~8-9 * 2.400-2.425 ms: ~4 * 2.425-2.450 ms: ~3 * 2.450-2.475 ms: ~3 * 2.500-2.525 ms: ~1 8. **Distribution of Verification Key Generation Time:** * X-axis: 2.40 to 2.75 ms * Peak frequency: Around 14, between 2.45 and 2.50 ms. * Frequencies: * 2.40-2.45 ms: ~12 * 2.45-2.50 ms: ~14 * 2.50-2.55 ms: ~10 * 2.65-2.70 ms: ~2 * 2.70-2.75 ms: ~1 9. **Distribution of Proof Generation Time:** * X-axis: 2.50 to 2.75 ms * Peak frequency: Around 9, between 2.50 and 2.55 ms. * Frequencies: * 2.50-2.55 ms: ~9 * 2.55-2.60 ms: ~7 * 2.60-2.65 ms: ~5 * 2.70-2.75 ms: ~2 10. **Distribution of Verifying Proof Time:** * X-axis: 2.30 to 2.60 ms * Peak frequency: Around 18, between 2.30 and 2.35 ms. * Frequencies: * 2.30-2.35 ms: ~18 * 2.35-2.40 ms: ~4 * 2.40-2.45 ms: ~3 * 2.55-2.60 ms: ~1 11. **Distribution of Solidity Verifier Generation Time:** * X-axis: 2.24 to 2.34 ms * Peak frequency: Around 7, between 2.28 and 2.30 ms. * Frequencies: * 2.24-2.26 ms: ~2 * 2.26-2.28 ms: ~6 * 2.28-2.30 ms: ~7 * 2.30-2.32 ms: ~6 * 2.32-2.34 ms: ~2 12. **Distribution of Total Time:** * X-axis: 230 to 255 ms * Peak frequency: Around 16-17, between 230 and 235 ms. * Frequencies: * 230-235 ms: ~16-17 * 235-240 ms: ~5 * 250-255 ms: ~1 ### Key Observations * Most distributions are right-skewed, indicating that the majority of operations complete relatively quickly, but there are occasional longer durations. * The "Total Time" distribution has a significantly larger scale on the x-axis compared to the other distributions, reflecting the cumulative nature of the total time. * Some stages, like "Phase Two Initiation Time" and "Verifying Proof Time," show a very sharp peak at the lower end of their time range. ### Interpretation The histograms provide a visual representation of the time taken for various stages in a cryptographic process. The right-skewed distributions suggest that while most operations are efficient, occasional outliers or more complex inputs can lead to longer processing times. The "Total Time" distribution indicates the overall time required for the entire process, and its shape reflects the combined effect of the individual stages. Analyzing these distributions can help identify potential bottlenecks or areas for optimization within the cryptographic workflow. The data suggests that optimizing the "Phase Two Initiation Time" and "Verifying Proof Time" could have a significant impact on overall performance, given their high frequencies at the lower end of their respective time ranges. </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: Average Time for Stages of zk Generation ### Overview The image is a bar chart displaying the average time (in seconds) taken for different stages of zk (zero-knowledge) generation. The x-axis represents the stages, and the y-axis represents the average time. The bars are all light blue. ### Components/Axes * **X-axis:** "Stages of zk Generation". The categories are: * compile\_time * witness\_time * pot\_time * pot\_ceremony\_time * phase\_two\_initiation\_time * z\_key\_generation\_time * phase\_two\_ceremony\_time * verification\_key\_generation\_time * proof\_generation\_time * verifying\_proof\_time * solidity\_verifier\_generation\_time * **Y-axis:** "Average Time (s)". The scale ranges from 0 to 200, with increments of 25. ### Detailed Analysis The bar chart shows the average time for each stage of zk generation. All bars are light blue. * **compile\_time:** Approximately 1 second. * **witness\_time:** Approximately 1 second. * **pot\_time:** Approximately 4 seconds. * **pot\_ceremony\_time:** Approximately 18 seconds. * **phase\_two\_initiation\_time:** Approximately 195 seconds. * **z\_key\_generation\_time:** Approximately 3 seconds. * **phase\_two\_ceremony\_time:** Approximately 2 seconds. * **verification\_key\_generation\_time:** Approximately 3 seconds. * **proof\_generation\_time:** Approximately 3 seconds. * **verifying\_proof\_time:** Approximately 2 seconds. * **solidity\_verifier\_generation\_time:** Approximately 2 seconds. ### Key Observations The "phase\_two\_initiation\_time" stage takes significantly longer than all other stages, with an average time of approximately 195 seconds. All other stages take less than 20 seconds. ### Interpretation The data suggests that the "phase\_two\_initiation\_time" stage is the bottleneck in the zk generation process. Optimizing this stage could significantly reduce the overall time required for zk generation. The other stages have relatively low average times, indicating they are not major contributors to the overall time. </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: Average CPU Usage During zk Generation Stages ### Overview The image is a line chart showing the average CPU usage (%) at different stages of zk (zero-knowledge) generation. The x-axis represents the stages of zk generation, and the y-axis represents the average CPU usage in percentage. The chart displays a single data series representing CPU usage across these stages. ### Components/Axes * **X-axis:** Stages of zk Generation. The stages are: compile, phase\_two\_initiation, power\_of\_tau, solidity\_verifier, verify\_proof, and z\_key. * **Y-axis:** Average CPU Usage (%). The scale ranges from 20% to 60%. * **Legend:** Located in the top-right corner, indicating that the red line represents "cpu(%)". * **Grid:** The chart has a grid for easier reading of values. ### Detailed Analysis The red line represents the CPU usage at each stage. * **compile:** CPU usage starts at approximately 21%. * **phase\_two\_initiation:** CPU usage increases sharply to approximately 64%. * **power\_of\_tau:** CPU usage decreases to approximately 52%. * **solidity\_verifier:** CPU usage remains relatively stable at approximately 52%. * **verify\_proof:** CPU usage decreases to approximately 51%. * **z\_key:** CPU usage increases to approximately 52%. ### Key Observations * The "phase\_two\_initiation" stage has the highest CPU usage. * CPU usage is lowest during the "compile" stage. * There is a significant increase in CPU usage from "compile" to "phase\_two\_initiation". * CPU usage remains relatively stable between "power\_of\_tau" and "solidity\_verifier". * CPU usage decreases at "verify_proof" and then increases slightly at "z_key". ### Interpretation The chart illustrates the computational demands of different stages in zk generation. The "phase\_two\_initiation" stage appears to be the most CPU-intensive, suggesting it involves complex calculations or processes. The relatively low CPU usage during the "compile" stage indicates that this initial step is less demanding. The fluctuations in CPU usage across the other stages likely reflect the varying computational requirements of each process. The data suggests that optimizing the "phase\_two\_initiation" stage could lead to significant improvements in overall zk generation efficiency. </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 During zk Generation Stages ### Overview The image is a line chart showing the average memory usage (%) at different stages of zk (zero-knowledge) generation. The x-axis represents the stages of zk generation, and the y-axis represents the average memory usage in percentage. The chart displays a single data series representing memory usage across these stages. ### Components/Axes * **X-axis:** Stages of zk Generation. The stages are: compile, phase\_two\_initiation, power\_of\_tau, solidity\_verifier, verify\_proof, and z\_key. * **Y-axis:** Average Memory Usage (%). The y-axis ranges from approximately 30.2% to 31.2%. * **Legend:** Located in the top-right corner, it indicates that the red line represents "memory(%)". * **Grid:** The chart has a grid for easier value reading. ### Detailed Analysis The red line represents the memory usage at each stage. * **compile:** The memory usage starts at approximately 30.15%. * **phase\_two\_initiation:** The memory usage increases sharply to approximately 31.3%. * **power\_of\_tau:** The memory usage decreases to approximately 30.75%. * **solidity\_verifier:** The memory usage remains relatively stable at approximately 30.88%. * **verify\_proof:** The memory usage remains relatively stable at approximately 30.92%. * **z\_key:** The memory usage increases to approximately 31.1%. ### Key Observations * The "phase\_two\_initiation" stage has the highest memory usage. * The "compile" stage has the lowest memory usage. * Memory usage increases significantly from "compile" to "phase\_two\_initiation". * Memory usage decreases from "phase\_two\_initiation" to "power\_of\_tau". * Memory usage is relatively stable between "power\_of\_tau" and "verify\_proof". * Memory usage increases again at the "z\_key" stage. ### Interpretation The chart illustrates how memory usage varies across different stages of zk generation. The "phase\_two\_initiation" stage appears to be the most memory-intensive, while the "compile" stage uses the least memory. The trend suggests that memory usage is dynamic and dependent on the specific operations performed at each stage. The initial spike and subsequent stabilization could indicate an initial setup phase followed by more consistent processing. The final increase at the "z\_key" stage might indicate finalization or output operations. </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 Chart: Time vs. Weight ### Overview The image is a line chart showing the relationship between "Weight" on the x-axis and "Time (seconds)" on the y-axis. The chart displays a single data series represented by a light blue line with circular markers. The line fluctuates, indicating variations in time with respect to weight. There are two distinct peaks at Weight values of approximately 5 and 25. ### Components/Axes * **X-axis:** * Label: "Weight" * Scale: 0 to 40, with tick marks at intervals of 5 (0, 5, 10, 15, 20, 25, 30, 35, 40). * **Y-axis:** * Label: "Time (seconds)" * Scale: 3.0 to 5.5, with tick marks at intervals of 0.5 (3.0, 3.5, 4.0, 4.5, 5.0, 5.5). * **Data Series:** * Color: Light Blue * Markers: Circular points along the line. * **Grid:** The chart has a grid background to aid in reading values. ### Detailed Analysis The light blue line represents the time in seconds for different weights. * **Trend:** The line fluctuates, indicating variations in time with respect to weight. * **Data Points:** * Weight 1: Time ~ 3.3 seconds * Weight 2: Time ~ 3.1 seconds * Weight 3: Time ~ 3.2 seconds * Weight 4: Time ~ 3.25 seconds * Weight 5: Time ~ 4.45 seconds * Weight 6: Time ~ 3.3 seconds * Weight 7: Time ~ 3.4 seconds * Weight 8: Time ~ 3.2 seconds * Weight 9: Time ~ 3.05 seconds * Weight 10: Time ~ 3.5 seconds * Weight 11: Time ~ 3.6 seconds * Weight 12: Time ~ 3.1 seconds * Weight 13: Time ~ 3.05 seconds * Weight 14: Time ~ 3.1 seconds * Weight 15: Time ~ 2.95 seconds * Weight 16: Time ~ 2.95 seconds * Weight 17: Time ~ 3.05 seconds * Weight 18: Time ~ 2.95 seconds * Weight 19: Time ~ 3.05 seconds * Weight 20: Time ~ 2.9 seconds * Weight 21: Time ~ 2.85 seconds * Weight 22: Time ~ 3.0 seconds * Weight 23: Time ~ 3.3 seconds * Weight 24: Time ~ 3.0 seconds * Weight 25: Time ~ 5.4 seconds * Weight 26: Time ~ 3.95 seconds * Weight 27: Time ~ 2.9 seconds * Weight 28: Time ~ 2.9 seconds * Weight 29: Time ~ 2.95 seconds * Weight 30: Time ~ 3.15 seconds * Weight 31: Time ~ 3.05 seconds * Weight 32: Time ~ 4.15 seconds * Weight 33: Time ~ 2.95 seconds * Weight 34: Time ~ 2.9 seconds * Weight 35: Time ~ 2.85 seconds * Weight 36: Time ~ 2.95 seconds * Weight 37: Time ~ 2.9 seconds * Weight 38: Time ~ 3.15 seconds * Weight 39: Time ~ 3.2 seconds ### Key Observations * There are two distinct peaks in time at Weight values of approximately 5 and 25. The peak at Weight 25 is significantly higher than the peak at Weight 5. * The time generally fluctuates between 2.85 and 3.6 seconds, except for the two peaks. * The time is relatively stable between weights 15 and 22, hovering around 3 seconds. ### Interpretation The chart suggests that specific weights, around 5 and 25, require significantly more time compared to other weights. The relatively stable time between weights 15 and 22 might indicate a range where the weight has minimal impact on the time taken. The peaks at weights 5 and 25 could be due to factors related to those specific weights, such as increased complexity or resource requirements. Further investigation would be needed to understand the underlying reasons for these peaks. </details> Figure 11: Blockchain and Chainlink overhead time over 39 weights. <details> <summary>extracted/6340811/Comparison_1.png Details</summary>  ### Visual Description ## Bar Chart: Process Time Comparison ### Overview The image is a bar chart comparing the time taken for zk Proof Generation and zk Verification processes. The chart breaks down the total time for each process into its constituent parts: zk Proof Generation Time, zk Verification Time, and Blockchain + Chainlink Overheads Time. ### Components/Axes * **X-axis:** "Processes" with two categories: "zk Proof Generation" and "zk Verification". * **Y-axis:** "Total Time (seconds)" with a scale from 0 to 200 in increments of 50. * **Legend (Top-Right):** * Light Blue: "zk Proof Generation Time (s)" * Light Green: "zk Verification Time (s)" * Light Red: "Blockchain + Chainlink Overheads Time (s)" ### Detailed Analysis * **zk Proof Generation:** * The total time for zk Proof Generation is approximately 225 seconds. * The entire time is attributed to "zk Proof Generation Time (s)" (light blue). * **zk Verification:** * The total time for zk Verification is approximately 62 seconds. * "zk Verification Time (s)" (light green) accounts for approximately 58 seconds. * "Blockchain + Chainlink Overheads Time (s)" (light red) accounts for approximately 4 seconds. ### Key Observations * zk Proof Generation takes significantly longer than zk Verification. * zk Proof Generation time dominates the overall time for the zk Proof Generation process. * zk Verification time is the primary component of the zk Verification process, with a small overhead from Blockchain + Chainlink. ### Interpretation The chart highlights the computational cost difference between generating a zk Proof and verifying it. The generation process is far more time-consuming than the verification process. The overhead associated with Blockchain and Chainlink is minimal compared to the core verification time. This suggests that optimizing the proof generation process would have the most significant impact on overall performance. </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 Chart: Transaction Fee vs. Number of Transactions ### Overview The image is a line chart showing the relationship between the number of transactions (x-axis) and the transaction fee in ETH (y-axis). The transaction fee starts at approximately 0.000574 ETH, decreases slightly around 6-10 transactions, and then stabilizes at approximately 0.000572 ETH for the remaining number of transactions. ### Components/Axes * **X-axis:** Number of Transactions, ranging from 0 to 35 in increments of 5. * **Y-axis:** Transaction Fee (ETH), ranging from 0.000566 to 0.000580 in increments of 0.000002. * **Data Series:** A single data series represented by an orange line with circular markers. ### Detailed Analysis The orange line represents the transaction fee in ETH as a function of the number of transactions. * **Transactions 0-5:** The transaction fee remains relatively constant at approximately 0.000574 ETH. * (0, 0.000574) * (1, 0.000574) * (2, 0.000574) * (3, 0.000574) * (4, 0.000574) * (5, 0.000574) * **Transactions 5-10:** The transaction fee decreases slightly. * (6, 0.000574) * (7, 0.000573) * (8, 0.000573) * (9, 0.000572) * (10, 0.000572) * **Transactions 10-35:** The transaction fee remains constant at approximately 0.000572 ETH. * (11, 0.000572) * (12, 0.000572) * (13, 0.000572) * (14, 0.000572) * (15, 0.000572) * (16, 0.000572) * (17, 0.000572) * (18, 0.000572) * (19, 0.000572) * (20, 0.000572) * (21, 0.000572) * (22, 0.000572) * (23, 0.000572) * (24, 0.000572) * (25, 0.000572) * (26, 0.000572) * (27, 0.000572) * (28, 0.000572) * (29, 0.000572) * (30, 0.000572) * (31, 0.000572) * (32, 0.000572) * (33, 0.000572) * (34, 0.000572) * (35, 0.000572) ### Key Observations * The transaction fee is relatively stable, with a slight decrease occurring between 5 and 10 transactions. * After 10 transactions, the fee remains constant. ### Interpretation The chart suggests that the transaction fee in ETH is not significantly affected by the number of transactions, especially after the initial few transactions. The slight decrease between 5 and 10 transactions could be due to some initial adjustment or optimization in the transaction processing. However, after this initial phase, the fee stabilizes and remains constant, indicating a fixed or predetermined fee structure for a higher number of transactions. This could be due to network congestion, gas prices, or other factors influencing the transaction fee. </details> Figure 13: Transaction Fee (ETH) for zk verification. <details> <summary>extracted/6340811/LINK_Spent.png Details</summary>  ### Visual Description ## Line Chart: LINK Token Spent ### Overview The image is a line chart that depicts the relationship between the number of ZK Verification Requests (x-axis) and the amount of LINK tokens spent (y-axis). The chart shows fluctuations in LINK token spending as the number of verification requests changes. ### Components/Axes * **Title:** LINK Token Spent * **X-axis:** Number of ZK Verification Requests, ranging from 0 to 40 in increments of 5. * **Y-axis:** LINK Spent, ranging from 0.20 to 0.40 in increments of 0.05. * **Data Series:** A single line in gold color represents the LINK token spent for each number of ZK Verification Requests. ### Detailed Analysis The gold line represents the LINK token spent. * **ZK Verification Requests = 0:** LINK Spent ≈ 0.20 * **ZK Verification Requests = 2:** LINK Spent ≈ 0.24 * **ZK Verification Requests = 5:** LINK Spent ≈ 0.24 * **ZK Verification Requests = 6:** LINK Spent ≈ 0.26 * **ZK Verification Requests = 8:** LINK Spent ≈ 0.20 * **ZK Verification Requests = 9:** LINK Spent ≈ 0.24 * **ZK Verification Requests = 11:** LINK Spent ≈ 0.24 * **ZK Verification Requests = 12:** LINK Spent ≈ 0.20 * **ZK Verification Requests = 14:** LINK Spent ≈ 0.24 * **ZK Verification Requests = 15:** LINK Spent ≈ 0.24 * **ZK Verification Requests = 17:** LINK Spent ≈ 0.24 * **ZK Verification Requests = 20:** LINK Spent ≈ 0.22 * **ZK Verification Requests = 22:** LINK Spent ≈ 0.41 * **ZK Verification Requests = 24:** LINK Spent ≈ 0.24 * **ZK Verification Requests = 25:** LINK Spent ≈ 0.41 * **ZK Verification Requests = 26:** LINK Spent ≈ 0.20 * **ZK Verification Requests = 28:** LINK Spent ≈ 0.20 * **ZK Verification Requests = 30:** LINK Spent ≈ 0.20 * **ZK Verification Requests = 31:** LINK Spent ≈ 0.25 * **ZK Verification Requests = 33:** LINK Spent ≈ 0.20 * **ZK Verification Requests = 35:** LINK Spent ≈ 0.24 * **ZK Verification Requests = 36:** LINK Spent ≈ 0.24 * **ZK Verification Requests = 38:** LINK Spent ≈ 0.20 * **ZK Verification Requests = 39:** LINK Spent ≈ 0.24 * **ZK Verification Requests = 40:** LINK Spent ≈ 0.20 ### Key Observations * The LINK token spent is relatively stable around 0.24 for the first 17 ZK Verification Requests, with some dips to 0.20. * There are two significant spikes in LINK token spent at 22 and 25 ZK Verification Requests, reaching approximately 0.41. * After the spikes, the LINK token spent returns to a lower level, fluctuating around 0.20 to 0.25 for the remaining ZK Verification Requests. ### Interpretation The chart suggests that there are specific instances around 22 and 25 ZK Verification Requests where the LINK token consumption is significantly higher than usual. This could be due to more complex or resource-intensive verification processes during those requests. The relatively stable LINK spending for other verification requests indicates a consistent cost for standard verifications. The spikes could be indicative of anomalies or specific types of verification requests that require more LINK tokens. </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