Zypher Research: zkPrompt - Trustless AI's Secure Interaction Protocol

In the zkPrompt protocol, system interaction involves four participants: User, Prover, Proxy, and LLM service provider.

Protocol Background and Comparison

The core idea of zkPrompt is similar to zkTLS [1], which integrates zero-knowledge proofs into the TLS communication process to ensure data integrity and authenticity. In the zkPrompt system, the user initiates a request to the LLM through the Prover, which then forwards the request to the LLM service provider via a third-party Proxy.

The LLM processes the request and returns the response to the Prover through the Proxy, which then relays it back to the user. The entire TLS communication occurs only between the Prover, Proxy, and LLM service provider. Since the user does not directly participate in this communication, there may be concerns about the Prover tampering with the response content. To address this trust issue, zkPrompt requires the Prover to generate a zero-knowledge proof, demonstrating that the response returned was indeed generated by the LLM and has not been tampered with, thereby achieving a high level of tamper-resistance security.

The implementation of this protocol can significantly enhance the credibility and security of AI Agents, unlocking high-value application scenarios such as on-chain asset management, hedging strategies, financial AI assistants, and payment systems, all of which rely on highly trustworthy AI systems.

Design Advantages

Compared to existing ZKML frameworks like Ezkl [2], zkPrompt significantly reduces system overhead. For example, generating a ZK proof for a simple GPT-2 model in Ezkl may take several hours, making it nearly impractical for deployment with large model services like OpenAI or DeepSeek.

We propose a more pragmatic trust model: the system does not require users to verify the internal execution process of the LLM but assumes that large LLM service providers are trustworthy, focusing instead on ensuring that the Prover does not tamper with the output. This design reflects real-world needs—mainstream LLM service providers have inherent trustworthiness due to their reputation and broad user base, while Prover nodes are typically invisible to users and more likely to become attack points, thus requiring stringent constraints.

Trust and Security Model

We assume that there is no collusion between the Proxy and the Prover. To further strengthen this assumption, it is recommended to decentralize the Proxy in real deployments to avoid single points of trust or failure.

To simplify the initial implementation, we temporarily assume that the user's Prompt and final response are recorded on-chain in plaintext (privacy protection methods will be explained in subsequent sections).

Technical Challenges and Core Solutions

The main technical challenge is that the Prover can forge ciphertext. Even if the user sees a certain ciphertext, they cannot determine whether it was actually obtained from the LLM through a TLS session or simply forged and encrypted locally by the Prover.

To address this issue, we introduce the Proxy Signature Mechanism: when the Proxy receives the encrypted response from the LLM, it will sign the ciphertext and upload both the ciphertext and the signature on-chain. Subsequently, the Prover provides a zero-knowledge proof to demonstrate the following statement:

The plaintext obtained by decrypting the ciphertext is indeed the response returned by the LLM.

The core of this proof lies in verifying the correctness of the symmetric decryption process, which can be efficiently implemented using existing results such as Dubhe [3].

Verification Process

Since the LLM's response typically includes the user's Prompt, the verifier (such as a miner) only needs to complete the following checks:

1. Verify that the Proxy's signature on the ciphertext is valid;
2. Check that the decrypted plaintext contains the user's original Prompt;
3. Verify the zero-knowledge proof provided by the Prover.

After completing these steps, the miner can confirm that the Prover honestly returned the true response from the LLM.

Privacy Protection Design

If the user wishes to hide the Prompt and response content, the following scheme can be adopted:

After sending the Prompt and receiving the response, the user uploads its hash value on-chain instead of the plaintext. Let:

• H1 = Hash(Prompt)
• H2 = Hash(Response)

Assuming that the substring [I:J] in the response corresponds exactly to the Prompt.

At this point, the Proxy uploads the ciphertext of the response on-chain, and the Prover uses the plaintext response W as a Witness to generate the following ZK proof:

• Hash(W) = H2
• Hash(W[I:J]) = H1
• Decrypt(Ciphertext) = W

The verifier only needs to confirm the validity of the Proxy's signed ciphertext and verify the ZK proof provided by the Prover to be assured that the response indeed originated from the LLM and has not been tampered with—without revealing any plaintext content.

Author Bio:

Felix Chief Research Scientist at Zypher Network

Felix is a researcher in the core AI team at Zypher Network, focusing on next-generation multimodal large models and trustworthy AI systems. He is currently dedicated to developing zero-knowledge proof (ZK)-based model compression methods to enhance the generalization ability and security of AI Agents in decentralized environments.

Before joining Zypher, Felix participated in various cutting-edge AI projects at Microsoft Research Asia and the University of California, Berkeley, accumulating rich research experience. His research findings have been published in top conferences on artificial intelligence and cybersecurity, including NeurIPS, S&P, CCS, Usenix Security, and NDSS.

Felix is currently a PhD candidate at the National University of Singapore, with research interests covering efficient model inference optimization, decentralized AI architecture, model robustness, and cryptography. With a solid background in the intersection of AI and blockchain, he is committed to driving the innovative integration of AI and ZK technology at Zypher, contributing to the development of a trustworthy, unified, and secure decentralized AI ecosystem.

References:

[1] Detailed introduction to zkTLS:
++Https://Www.Blocmates.Com/Articles/What-Is-Zktls-A-Complete-Guide++

[2] Ezkl project homepage:
++Https://Github.Com/Zkonduit/Ezkl++

[3] Dubhe: A concise zero-knowledge proof for standard AES and its applications:
++Https://Homes.Luddy.Indiana.Edu/yh33/Mypub/Dubhe.Pdf++