From Verifiable AI to Composable AI - A Reflection On the Use Cases of ZKML

1.3 Discussion of Different Use Cases Based on the Need for Verifiable AI

1.3.1 Use cases that may not require verifiable AI

In Rocky Bot's scenario, users may not need to verify the ML computation process.

First, users lack professional knowledge and are completely unable to perform real verification. Even with verification tools, users will only see that they pressed a button and a pop-up told them the AI service was indeed generated by a certain model. They don't know if it's true behind the scenes.

Second, users have no need to verify because they value the ROI of the AI. When ROI is low, users will migrate, as they will always choose the model with the best results. In short, when users care about the final outcome of the AI, verifying the process may be meaningless because users only need to migrate to the service with the best results.

One possible solution is for AI to only act as an advisor, while users execute trades independently. After users input their trading goals to AI, it calculates off-chain and returns the best trading path/direction to users who don't need to verify the underlying model since they just need to choose the product with the highest returns.

A potentially dangerous yet highly possible situation arises when individuals show complete disregard for custody of their own assets and do not value the AI computation process. When an automated money making robot appears, people may be willing to put money in it, just like depositing tokens into a CEX or traditional bank for wealth management. Because people don't care about the mechanism behind it, they only care about how much profit they receive in the end, or even just how much profit the project claims they have earned. This kind of service may also quickly gain a large number of users, and even iterate faster than projects using verifiable AI.

If AI is not involved in triggering on-chain state changes at all, and only fetches on-chain data and preprocesses it for users, then there is also no need to generate ZKPs for computation. We can call this type of application as “data service”, here are some examples:

• The chatbox provided by Mestis a typical data service. Users can inquire about their on-chain data through QA, such as asking how much they have spent on NFTs.
• ChainGPTis a multi-functional AI assistant. It can interpret smart contracts for you before trading, revealing whether you are trading in the right pool, and whether the transaction is prone to front running. ChainGPT also plans to offer services like AI news recommendations and publishing AIGC NFTs.
• RSS3provides AIOP, allowing users to choose what on-chain data they require and perform certain preprocessing, making it easier to take specific on-chain data to train AI.
• DefiLlama and RSS3 both have ChatGPT plugins so users can obtain on-chain data through conversation.

1.3.2 Use Cases Requiring Verifiable AI

This article argues that scenarios involving multiple parties' fairness and privacy require ZKPs for verification. We will discuss some of the applications mentioned by Modulus Labs:

• When a community distributes rewards based on AI-generated individual reputations, community members will certainly require auditing of the evaluation process, which in this case is the ML computation.
• In the scenario of AI optimizing AMM, which involves distribution of benefits between multiple parties, the AI computation process also needs to be periodically verified.
• When balancing privacy and regulation, ZK is one of the better solutions. If the application uses ML to process private data in the service, a ZKP of the ML computation is needed.
• Due to the wide reaching impact of oracle, if it is powered by AI, there is a need to generate ZKP periodically to check whether the AI is functioning properly.
• In competitions, the public and other participants need to check whether the ML algorithms comply with the competition specifications.
• In the potential use case of Worldcoin, there is a strong need to ensure that the ML model is used in a way that protects the privacy of individuals.

Overall, whether AI triggers on-chain state changes and whether it affects fairness/privacy are the two criteria for determining whether verifiable AI is needed.

When AI does not trigger on-chain state changes, AI service can act as an suggester, and people can judge the quality of AI service by the effect of the suggestion without the need to verify the computation process;

When AI does trigger on-chain state changes, and if the service is only for individuals and does not involve personal privacy, then users can still judge the quality of AI service without verifying the calculation process;

When the output of AI directly affects the fairness between different parities, and AI triggers on-chain state changes, then the community and the public should have the need to check the decision-making process of AI;

When the data processed by ML involves personal privacy, then there is a definite need for ZK to protect privacy and respond to regulatory requirements.

Source：Kernel Ventures

Part 2: Two Type of AI Application Architecture Based on Public Blockchains

In any case, the solution proposed by Modulus Labs is a great inspiration for how AI can be combined with blockchain and generate practical application value. However, the public blockchain not only enhances the ability of a single AI service, but also has the potential to build a new ecosystem of AI applications. This emerging ecosystem introduces a distinct paradigm for interactions among AI services, relationships between AI services and users, as well as fosters the collaborative dynamics between upstream and downstream entities. We can categorize this AI application ecosystem into two overarching types: vertical and horizontal architectures.

2.1 Vertical Architecture: Focusing on Composable AI

The "Leela vs the World" online chess game has an unique aspect where people can place bets on the human player or the AI, with tokens being automatically distributed after the game based on the outcomes. Here the purpose of ZKP is not just for users to verify AI's calculations, but also serves as a trust guarantee to trigger on-chain state changes. With this trust guarantee, composability between AI services, and between AI and native crypto dApps becomes possible at a dApp level.

Source：Kernel Ventures(base on the model from Modulus Labs)

The basic unit of composable AI is [off-chain ML model - ZKP generation - on-chain verification contract - main contract], gathering from the framework of "Leela vs the World", although the actual architecture of individual AI dApps may differ from the diagram.

First, chess games require a contract to track game state, but in reality AI may not need an on-chain contract. However, for the architecture of composable AI, if the main activity happens in a contract, it may be more convenient for other dApps to integrate with it.

Second, the main contract does not necessarily need to affect its ML model. The ML model of an AI dApp only need to trigger a contract related to its own action, and that contract is then called by other dApps.

Contract calls between dApps enable composability between different Web3 applications, including identity, asset management, financial services, and even social information. We can envision a specific combination of AI applications:

• Worldcoin uses ML to generate iris code for individual iris data and generate a ZKP.
• A reputation scoring AI app first verifies that the user is a real person (backed by the iris data), then assigns an NFT based on on-chain reputation
• A lending service adjusts loan amount based on the NFTs held by the user
• ...

While AI interactions on public blockchain is not something nouveau, Realms ecosystem contributor Loaf has proposed that AI NPCs could trade with players and each other, allowing the entire economic system to self-optimize and operate automatically. AI Arena developed a game where AIs automatically battle each other. Users first purchase an NFT representing a battle robot, backed by an AI model. Users play the game themselves, provide data for AI to learn from, and when ready, deploy it to battle other AIs. Modulus Labs mentioned AI Arena wants to make these AIs verifiable. In both cases, we see the potential for AIs to interact and directly change the on-chain state.

However, many details around implementing composable AI in practice remain to be fleshed out, such as how different dApps can leverage each other's ZKPs and verifier contracts. But with the amount of innovation happening in the zero knowledge space, for example RISC Zero's work on complex off-chain computations and generating ZKPs for on-chain verification, appropriate solutions may soon emerge.

2.2 Horizontal Architecture: Focusing on Decentralized AI Platforms

Here we introduce a decentralized AI platform called SAKSHI, proposed by researchers from Princeton, Tsinghua University, University of Illinois Urbana-Champaign, HKUST, Witness Chain and Eigen Layer. Its core objective is to enable users to obtain AI services in a more decentralized manner, making the entire process more trustless and automated.

Source：SAKSHI

SAKSHI consists of six layers: Service Layer, Control Layer, Transaction Layer, Proof Layer, Economic Layer and Marketplace.

The Marketplace is the layer closest to users. Users place orders through aggregators and sign agreement on service quality and pricing (SLA - service level agreement).

The Service Layer then provides an API to the client, which sends an ML inference request to the aggregator. This request is passed to a matching supplier server using a router deployed as a part of the control layer. So the Service and Control Layers resemble a Web2 service with multiple servers, but each server is operated by a different entity, associated with the aggregator through SLAs signed earlier.

SLAs are deployed on-chain as smart contracts, belonging to the Transaction Layer (In SAKSHI, it is referred to as the Witness Chain). The Transaction Layer also records the current state for each service order, and is used to coordinate users, aggregators and service providers, handling payment disputes.

To provide a basis for resolving disputes, the Proof Layer verifies if service providers adhere to the SLA by examining the models used. However, instead of generating ZKPs for ML computations, SAKSHI proposes an optimistic approach - establishing challenger nodes to audit services, incentivized by Witness Chain.

Although SLAs and the challenger network are on the Witness Chain, SAKSHI's proposal does not plan to use Witness Chain's native token for incentives to achieve independent security. Instead, it leverages Ethereum's security through Eigen Layer. So, the entire Economic Layer basically relies on Eigen Layer.

We can see SAKSHI acting as an intermediary between AI providers and users, bringing different AIs together in a decentralized manner to serve its users. This is more of a horizontal approach. SAKSHI's focus is on freeing AI providers to just manage their off-chain model computations, while matching user needs to model services, handling payments, and verifying service quality through on-chain protocols in a more automated way. Of course, as SAKSHI is still theoretical, numerous implementation details remain to be fleshed out.

Part 3: Future Outlook

Whether composable AI or decentralized AI platforms, blockchain-based AI ecosystem patterns seem to have commonalities - AI providers can interact directly with users and just supply ML models for off-chain computation. Payments, dispute resolution, matching user needs with services, can be handled by trustless protocols. As a trustless base layer, blockchains reduce friction between providers and users, giving users greater autonomy.

While the advantages of using blockchains as a base layer are well-understood, they are indeed suitable for AI services. However different to dApps, AI application computations cannot all be on-chain, so ZK or optimistic approach is needed to integrate AI services in a more trustless manner.

With improvements like account abstraction to allow better user experience, elements like private key management, chains and gas may not be noticed. With a smooth experience resembling Web2 UX, a much greater degree of freedom and composability, providing strong incentives for mass adoption, blockchain-based AI application ecosystems have an exciting future ahead.

REFERENCE

• Chapter 1: How to Put Your AI On-Chain：https://medium.com/coinmonks/chapter-1-how-to-put-your-ai-on-chain-8af2db013c6b
• Chapter 4: Blockchains that Self-Improve：https://medium.com/@ModulusLabs/chapter-4-blockchains-that-self-improve-e9716c041f36
• Chapter 6: The World’s 1st On-Chain AI Game：https://medium.com/@ModulusLabs/chapter-6-leela-vs-the-world-the-worlds-1st-on-chain-ai-game-17ea299a06b6
• AN INTRODUCTION TO ZERO-KNOWLEDGE MACHINE LEARNING (ZKML)：https://worldcoin.org/blog/engineering/intro-to-zkml#zkml-use-cases
• Zero-Knowledge Proof: Applications and Use Cases：https://blog.chain.link/zero-knowledge-proof-use-cases/
• SAKSHI: Decentralized AI Platforms：https://arxiv.org/pdf/2307.16562.pdf
• Honey, I Shrunk the Proof: Enabling on-chain verification for RISC Zero Bonsai：https://www.risczero.com/news/on-chain-verification
• 对话 Nil Foundation 创始人：ZK 技术或被误用，公开可追溯并非加密初衷：https://www.techflowpost.com/article/detail_12647.html
• IOSG Weekly Brief ｜点亮区块链的星火：LLM 开启区块链交互的新可能 #187https://mp.weixin.qq.com/s/sVIBF6iPXwhamlKEvjH19Q