ZK API Usage Credits: LLMs and Beyond

ethresear.ch

Davide Crapis and Vitalik Buterin A core challenge in API metering is achieving privacy , security , and efficiency simultaneously. This is particularly critical for AI inference with LLMs, where users submit highly sensitive personal data, but applies generally to any high-frequency digital service. Currently, API providers are forced to choose between two suboptimal paths: Web2 Identity: Require authentication (email/credit card), which links every request to a real-world identity, creating massive privacy leaks and profiling risks. On-Chain Payments: Require a transaction per request, which is prohibitively slow, expensive, and makes it difficult to obfuscate the full user’s transaction graph. We need a system where a user can deposit funds once and make thousands of API calls anonymously, securely, and efficiently . The provider must be guaranteed payment and protection against spam, while the user must be guaranteed that their requests cannot be linked to their identity or to each other. We focus on LLM inference as the motivating use case, but the approach is general and also applies to RPC calls or any other fixed-cost API, image generation, cloud computing services, VPNs, data APIs, etc. Examples: LLM inference: A user deposits 100 USDC into a smart contract and makes 500 queries to a hosted LLM. The provider receives 500 valid, paid requests but cannot link them to the same depositor (or to each other), while the user’s prompts remain unlinkable to the user identity. Ethereum RPC: A user deposits 10 USDC and makes 10,000 requests to an Ethereum RPC node (e.g., eth_call / eth_getLogs ) to power a wallet, indexer, or a bot. The RPC provider is protected against spam and guaranteed payment, but cannot correlate the requests into a persistent user profile. Proposal Overview: We leverage Rate-Limit Nullifiers (RLN) to bind anonymity to a financial stake: honest users who stay within protocol limits remain unlinkable, while users who double-spend (or otherwise exceed their allowed capacity) cryptographically reveal their secret key, enabling slashing. We design the protocol to work when API usage incurs variable costs, but it also directly supports the simpler fixed-cost-per-call as a special case. We use a flexible accounting protocol in which each request sets a maximum cost per call up front and once the actual cost is determined at the end of the call the server issues a refund. Users privately accumulate signed refund tickets to reclaim unused credits and unlock future capacity even when the actual per-call cost is only known after execution. A Dual Staking mechanism lets the server enforce compliance policies while remaining publicly accountable. ZK API Usage Credit Protocol The protocol utilizes server refunds paired with refund accumulation and a proof-of-solvency on the client side. The model enforces solvency by requiring the user to prove that their cumulative spending—represented by their current ticket index —remains strictly within the bounds of their initial deposit and their verified refund history. Anti-spam protection is enforced economically: a user’s throughput is naturally capped by their available deposit buffer, while any attempt to reuse a specific ticket index (double-spending) is prevented by the Rate-Limit Nullifier. Primitives k : User’s Secret Key. D : Initial Deposit. C_{max} : The maximum cost per request (deducted upfront). i : The Ticket Index (A strictly increasing counter: 0, 1, 2, \dots ). \{r_1, r_2, \dots, r_n\} : A private collection of signed Refund Tickets received from the server. Protocol Flow Registration The user generates secret k , derives an identity commitment ID = Hash(k) , and deposits D into the smart contract. The contract inserts ID into the on-chain Merkle Tree. Refund Collection (Asynchronous) After a request is processed, the Server provides a signed Refund Ticket r = \{v, \text{sig}\} , where v is the refund value and \text{sig} is the Server’s signature over v (and potentially a unique request ID). The user stores these locally. Request Generation (Parallelizable) The user picks the next available Ticket Index i . They can generate multiple requests (e.g., tickets i, i+1, i+2 ) simultaneously. The user generates a ZK-STARK \pi_{req} proving: Membership: ID \in MerkleRoot. Refund Summation: The circuit takes the list of refund tickets \{r_1, \dots, r_n\} as private inputs. For each ticket, the circuit: Verifies the Server’s signature. Extracts the value v_j . The circuit calculates the sum: R = \sum_{j=1}^{n} v_j . Solvency (The Credit Check): The total potential spend at index i is covered by the deposit plus the sum of all verified refunds: (i + 1) \cdot C_{max} \le D + R . RLN Share & Nullifier: Slope: a = Hash(k, i) . Signal: x= Hash(M) , y = k + a \cdot x . Nullifier: Nullifier = Hash(a) . Submission User sends: Payload (M) + Nullifier + Signal (x, y) + Proof. Verification & Slashing The Server checks the Nullifier in its “Spent Tickets” database: Fork/Double-Spend Check: If the Nullifier exists with a different x (Message), the user tried to spend the same ticket on two different requests. Solve for k and SLASH. Solvency Check: Verify \pi_{req} to ensure the ticket index i is authorized by the user’s current funding level. Settlement Server executes request. Refund: Server issues a signed Refund Ticket r = (C_{max} - C_{actual}) . User adds r to their accumulator to “unlock” higher ticket indices for future use. Server-Side Accountability (Dual Staking) To deter API abuse beyond simple rate-limiting (e.g., violating Terms of Service, generating illegal content, or jailbreaking attempts), we introduce a secondary staking layer. For example, a user might submit a prompt asking the model to generate instructions for building a weapon or to help them bypass security controls – requests that would violate many providers’ usage policies. We would like a way to enforce such policies without giving the provider a straightforward way to profit from false positives. Concretely: The user deposits a total sum Total = D + S . D (RLN Stake): Governed by the math of the protocol. Can be claimed by anyone (including the Server) who provides mathematical proof of double-signaling (revealed secret k ). S (Policy Stake): Governed by Server Policy. Can be slashed (burned), but not claimed , by the Server if the user violates usage policies. The purpose of doing this, instead of simply setting D higher, is to remove the server’s incentive to fraudulently take away users’ deposits, which could be high depending on how high the deposit is. Slashing Mechanism for S If a user submits a valid RLN request that violates policy (but does not trigger the mathematical double-spend trap): Violation: Server detects policy violation in the request payload (e.g., prohibited content). Burn Transaction: The Server calls a slashPolicyStake() function on the smart contract. Input: The Nullifier of the offending request and the ViolationEvidence (optional hash/reason). Action: The contract burns amount S from the user’s deposit. Constraint: The Server cannot claim S for itself, it is sent to a burn address. This prevents the server from being incentivized to falsely ban users for profit. Public Accountability: The slashing event is recorded on-chain with the associated Nullifier . While the user’s identity remains hidden, the community can audit the rate at which the Server burns stakes and the posted evidence for these burns. 1 post - 1 participant Read full topic