In the zkPrompt protocol, system interactions involve four participants: User, Prover, Proxy, and LLM service provider.
Protocol Background and Comparison
The core concept of zkPrompt is similar to zkTLS [1], which integrates zero-knowledge proof 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 through the Proxy to the Prover, who then passes it back to the user. The entire TLS communication only occurs between the Prover, Proxy, and LLM service provider. Since the user does not directly participate in this communication, they may be concerned about the Prover tampering with the response. To address this trust issue, zkPrompt requires the Prover to generate a zero-knowledge proof, proving that the returned response was indeed generated by the LLM and has not been tampered with, thereby achieving high tamper-resistance security.
The implementation of this protocol can significantly enhance the credibility and security of AI Agents, releasing high-value application scenarios such as on-chain asset management, hedging strategies, financial AI assistants, payment systems, etc., all of which rely on extremely high-credibility 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 might take hours in Ezkl, which is almost impossible to deploy practically when facing large model services like OpenAI or DeepSeek.
We propose a more practical trust model: the system does not require users to verify the internal execution process of the LLM, but instead assumes that large LLM service providers are trustworthy and focuses on ensuring that the Prover cannot tamper with the output. This design reflects real-world needs—mainstream LLM service providers have natural credibility due to their reputation and broad user base, while Prover nodes are typically invisible to users and more likely to be attack points, thus must be strictly constrained.
Trust and Security Model
We assume that there is no collusion between the Proxy and Prover. To further strengthen this assumption, we recommend decentralizing the Proxy in real-world deployments to avoid single-point trust or failure.
To simplify initial implementation, we temporarily assume that the user's Prompt and final response are uploaded 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 through a TLS session from the LLM or simply locally forged and encrypted by the Prover.
To solve this problem, we introduce a Proxy signature mechanism: when the Proxy receives an encrypted response from the LLM, it will sign the ciphertext and upload both the ciphertext and signature on-chain. Subsequently, the Prover provides a zero-knowledge proof, proving the following statement:
The plaintext obtained by decrypting this ciphertext is exactly the response returned by the LLM.
The core of this proof is to verify the correctness of the symmetric decryption process, which can be efficiently implemented using existing achievements like Dubhe [3].
Verification Process
Since LLM responses typically include the user's Prompt, the verifier (such as a miner) only needs to complete the following checks:
- Verify the validity of the Proxy's signature on the ciphertext;
- Check if the decrypted plaintext contains the user's original Prompt;
- Verify the zero-knowledge proof provided by the Prover.
After completing these steps, the miner can confirm that the Prover has honestly returned the true response from the LLM.
Privacy Protection Design
If the user wishes to hide the Prompt and response content, the following solution can be adopted:
After sending the Prompt and receiving the response, the user uploads its hash value on-chain, rather than the plaintext. Set:
- H1 = Hash(Prompt)
- H2 = Hash(Response)
Assume that the substring [I:J] in the response exactly corresponds to the Prompt.
At this point, the Proxy uploads the response's ciphertext on-chain, and the Prover generates a Zk proof using the response plaintext Www as a Witness:
- 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 confident that the response indeed comes from the LLM and has not been tampered with—without revealing any plaintext content.
Author Introduction:
Felix
Chief Research Scientist at Zypher Network
Felix is a researcher in the AI core team at Zypher Network, focusing on next-generation multimodal large models and trustworthy AI systems. He is currently dedicated to model compression methods based on zero-knowledge proofs (ZK) to enhance the generalization capabilities and security of AI Agents in decentralized environments.
Before joining Zypher, Felix participated in multiple cutting-edge AI projects at Microsoft Research Asia and the University of California, Berkeley, accumulating rich research experience. His research results have been published in top AI and network security conferences such as NeurIPS, S&P, CCS, Usenix Security, and NDSS.
Felix is currently a PhD candidate at the National University of Singapore, with research directions 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 promoting innovative integration of AI and ZK technologies at Zypher, helping to build a trustworthy, integrated, 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: Succinct Zero-Knowledge Proof for Standard AES and Its Related Applications:
Https://Homes.Luddy.Indiana.Edu/yh33/Mypub/Dubhe.Pdf
