Skip to content

Latest commit

 

History

History
39 lines (31 loc) · 2.83 KB

File metadata and controls

39 lines (31 loc) · 2.83 KB

Research: Verifiable Inference & Helicone AI Gateway

Executive Summary

Verifiable inference creates a cryptographic "proof of thought," ensuring that an AI model's output was generated by a specific model state without tampering. While Helicone provides robust observability (logging, caching, rate-limiting) for LLMs, it does not currently natively support TLSN (Transport Layer Security Notarization) or similar verifiable inference protocols in its public offering.

Note: The user indicates an existing integration of TLSN into Helicone's AI Gateway. This implies a custom implementation or a private fork. This document outlines the standard architecture for such an integration.

1. Helicone AI Gateway Overview

  • Core Function: Unified API proxy for LLM providers (OpenAI, Anthropic, etc.).
  • Key Features:
    • Intelligent Routing: Load balancing across models.
    • Caching: Reduces costs and latency.
    • Security: Prompt injection protection (via Llama Guard).
  • Current Limitation: Acts as a "trusted middleman." Standard logs are not cryptographically verifiable by a third party.

2. Verifiable Inference Architectures

A. TLSN (Notarized Sessions)

  • Concept: Proves that a specific HTTP response (the AI inference) actually came from a specific server (e.g., api.openai.com) without revealing the private API key.
  • Workflow:
    1. Agent sends prompt to Gateway.
    2. Gateway (or Client sidecar) initiates a centralized interaction with the AI Provider.
    3. The Prover (Gateway) creates a TLSN proof of the session.
    4. The Verifier (Smart Contract or specialized node) verifies the proof.
  • MultiversX Implementation:
    • The proof can be posted to a MultiversX Data Availability layer or verified by an off-chain Oracle (due to computation costs), with the result (hash) stored on-chain.

B. opML / zkML (Cryptographic Proofs)

  • Concept: Generating a Zero-Knowledge proof of the actual matrix multiplications (inference).
  • Status: Extremely computationally expensive. Practical mainly for small models, not yet for GPT-4 scale.

3. Standardization Opportunities

To standardize "Verifiable Inference" for MultiversX agents:

  1. The "Proof Header": Define a standard field in the agent's response payload (MCP protocol extension) containing the TLSN proof or hash.
  2. Verification Registry: A MultiversX Smart Contract where trusted verifiers attest to the validity of these proofs (similar to ERC-8004's Validation Registry).

Recommendations

  • Leverage the User's Integration: Since the user has a TLSN implementation, this should be codified as the "Reference Implementation" for the standard.
  • Hybrid Approach: Use Helicone for logging and routing, but wrap the specific high-value inference calls in a TLSN wrapper to generate the on-chain proof.