ZK API Usage Credits: LLMs and Beyond

來自:https://ethresear.ch/t/zk-api-usage-credits-llms-and-beyond/24104
日期:2026-02-12

Davide Crapis 與 Vitalik Buterin

API 計量的一個核心挑戰在於同時實現隱私性安全性效率。這對於涉及大型語言模型的 AI 推理尤其關鍵,因為用戶會提交高度敏感的個人資料,但此問題也普遍存在於任何高頻率的數位服務中。目前,API 提供者被迫在兩個次優方案中做出選擇:

  1. Web2 身份驗證:要求身份驗證(電子郵件/信用卡),這會將每個請求連結到真實世界的身份,造成大規模的隱私外洩與側寫風險。
  2. 鏈上支付:要求每筆請求都進行一次交易,這種方式速度極慢、成本高昂,且難以混淆用戶完整的交易圖譜。

我們需要的是一個系統,讓用戶能夠一次性存入資金,並以匿名、安全且高效的方式進行數千次 API 呼叫。提供者必須獲得付款保證並受到防範垃圾請求的保護,而用戶則必須確保其請求無法被連結到其身份或彼此之間。我們以 LLM 推理作為主要用例,但該方法具有通用性,同樣適用於 RPC 呼叫或任何其他固定成本的 API、圖像生成、雲端計算服務、VPN、資料 API 等。

範例

  1. LLM 推理:用戶將 100 USDC 存入智能合約,並向託管的 LLM 發出 500 次查詢。提供者收到 500 筆有效且已付費的請求,但無法將它們連結到同一存款人(或彼此之間),同時用戶的提示詞也無法與其身份連結。
  2. 以太坊 RPC:用戶存入 10 USDC,並向以太坊 RPC 節點(例如 eth_call / eth_getLogs)發出 10,000 次請求,以驅動錢包、索引器或機器人。RPC 提供者受到防範垃圾請求的保護並獲得付款保證,但無法將這些請求關聯成一個持久的用戶側寫。

提案概述

我們利用速率限制零知識證明將匿名性與財務權益綁定:遵守協議限制的誠實用戶保持不可連結性,而雙重支付(或以其他方式超出其允許容量)的用戶會密碼學地揭露其密鑰,從而啟用罰沒機制。我們設計的協議能夠處理可變成本的 API 使用情況,同時也直接支援更簡單的每次呼叫固定成本作為特例。

我們使用一個靈活的記帳協議,其中每個請求預先設定每次呼叫的最高成本,並在呼叫結束時確定實際成本後,由伺服器發放退款。用戶私下累積已簽署的退款憑證,以便在每次呼叫的實際成本僅在執行後才知曉的情況下,取回未使用的額度並解鎖未來的容量。雙重質押機制讓伺服器能夠執行合規政策,同時保持公開的問責性。

ZK API 使用額度協議

該協議利用伺服器退款,並與客戶端的退款累積及償付能力證明配對。該模型透過要求用戶證明其累積支出——以其當前的憑證索引表示——嚴格保持在其初始存款與其驗證過的退款歷史記錄範圍之內,來強制執行償付能力。

防範垃圾請求的保護是透過經濟手段執行的:用戶的吞吐量自然受到其可用存款緩衝區的限制,而任何重複使用特定憑證索引(雙重支付)的企圖都會被速率限制零知識證明所阻止。

基本元件

協議流程

註冊
用戶生成私密金鑰 k,推導出身份承諾 ID = Hash(k),並將 D 存入智能合約。合約將 ID 插入鏈上的默克爾樹。

退款收集(非同步)
請求處理完成後,伺服器提供一個已簽署的退款憑證 r = {v, sig},其中 v 是退款金額,sig 是伺服器對 v(可能還包括唯一的請求 ID)的簽名。用戶將這些憑證本地儲存。

請求生成(可平行化)
用戶選取下一個可用的憑證索引 i。他們可以同時生成多個請求(例如,憑證 i, i+1, i+2)。

用戶生成一個 ZK-STARK 證明 π_req,證明:

  1. 成員資格:ID ∈ 默克爾樹根。
  2. 退款總和計算:
    電路將退款憑證列表 {r_1, ..., r_n} 作為私密輸入。
    • 對於每個憑證,電路:
      • 驗證伺服器的簽名。
      • 提取金額 v_j
    • 電路計算總和:R = ∑_{j=1}^{n} v_j
  3. 償付能力(信用檢查):在索引 i 處的總潛在支出,由存款加上所有已驗證退款的總和所涵蓋:
    (i + 1) * C_max ≤ D + R


← 返回列表