ZK API 使用鳴謝：LLM 及其他

本文為機器翻譯

展示原文

戴維德·克拉皮斯和維塔利克·布特林

API計量的核心挑戰在於如何同時實現隱私、安全和效率。這對於使用LLM的AI推理尤為關鍵，因為用戶會提交高度敏感的個人數據，但這一挑戰也普遍適用於任何高頻數字服務。目前，API提供商被迫在兩種次優方案中做出選擇：

Web2 身份：需要身份驗證（電子郵件/信用卡），這會將每個請求與現實世界的身份關聯起來，從而造成大規模的隱私洩露和用戶畫像風險。
鏈上支付：每次請求都需要進行交易，速度非常慢，成本很高，而且難以混淆用戶的完整交易圖。

我們需要一個系統，用戶只需一次性充值，即可匿名、安全、高效地發起數千次 API 調用。服務提供商必須獲得支付保障和反垃圾郵件保護，而用戶則必須確保其請求不會與其身份或其他用戶關聯。我們以 LLM 推理為例進行演示，但該方法具有通用性，也適用於 RPC 調用或任何其他固定成本 API、圖像生成、雲計算服務、VPN、數據 APIETC。

例如：

LLM 推斷：用戶向智能合約存入 100 USDC ，並向託管的 LLM 發出 500 次查詢。提供商收到 500 個有效的已支付請求，但無法將這些請求與同一存款人（或彼此）關聯起來，同時用戶的請求也無法與用戶身份關聯。
以太坊 RPC：用戶存入 10 USDC ，並向以太坊 RPC 節點（例如eth_call / eth_getLogs ）發出 10,000 個請求，以支持錢包、索引器或機器人。RPC 提供商受到反垃圾郵件保護並保證支付，但無法將這些請求關聯到持久的用戶配置文件中。

提案概述：我們利用速率限制無效器(RLN) 將匿名性與經濟利益掛鉤：遵守協議限制的誠實用戶保持匿名，而雙重支付（或超出其允許的容量）的用戶則會以加密方式洩露其私鑰，從而觸發懲罰。我們設計的協議適用於 API 使用成本可變的情況，但同時也直接支持更簡單的固定每次調用成本模式。

我們採用靈活的計費協議，其中每個請求都會預先設定每次調用的最高費用，並在調用結束後確定實際費用後，服務器會進行退款。用戶可以私下累積已簽名的退款憑證，以便在實際每次調用費用僅在執行後才可知曉的情況下，回收未使用的額度並解鎖未來的容量。雙重質押機制使服務器能夠在執行合規策略的同時，保持公開透明。

ZK API 使用信用協議

該協議採用服務器端退款機制，結合退款累積和客戶端償付能力證明。該模型通過要求用戶證明其累計支出（以其當前票券指數表示）嚴格控制在其初始存款和已驗證的退款記錄範圍內來強制執行償付能力。

反垃圾郵件保護措施以經濟的方式實施：用戶的吞吐量自然受到其可用存款緩衝區的限制，而任何試圖重複使用特定票據索引（雙重支付）的行為都會被速率限制無效器阻止。

基本元素

k k ：用戶的私鑰。
D D ：初始存款。
C_{max} C m a x : 每次請求的最大成本（預先扣除）。
i i : 票號索引（嚴格遞增的計數器： 0, 1, 2, \dots 0 , 1 , 2 , … ）。
\{r_1, r_2, \dots, r_n\} { r 1 , r 2 , … , r n } : 從服務器收到的已簽名退款憑證的私有集合。

協議流程

登記
用戶生成秘密值k ，導出身份承諾ID = Hash(k) ，並將ID存入智能合約。合約將ID插入鏈上默克爾樹。

退款收取（異步）
請求處理完畢後，服務器會提供一個已簽名的退款單r = \{v, \text{sig}\} r = { v , sig } ，其中v是退款金額， sig是服務器對v的簽名（可能還包含一個唯一的請求 ID）。用戶將這些退款單存儲在本地。

請求生成（可並行化）
用戶選擇下一個可用的票證索引i 。他們可以同時生成多個請求（例如，票證i、i+1、i+2 、 i + 1 、 i + 2 ）。

用戶生成一個 ZK-STARK 證明\pi_{REQ} π r e q ：

成員資格： ID \in I D ∈ MerkleRoot。
退款總額：
該電路將退款單列表\{r_1, \dots, r_n\} { r 1 , … , r n }作為私有輸入。
- 每張門票對應的賽道：
  - 驗證服務器簽名。
  - 提取值v_j v j 。
- 該電路計算總和： R = \sum_{j=1}^{n} v_j R = ∑ n j = 1 v j 。
償付能力（信用檢查）：索引i處的潛在總支出由存款加上所有已核實退款的總和來覆蓋：
(i + 1) \cdot C_{max} \le D + R ( i + 1 ) ⋅ C max ≤ D + R 。
RLN 份額和無效化器：
- 斜率： a = Hash(k, i) a = H a s h ( k , i ) 。
- 信號：
  - x= Hash(M) x = H a s h ( M ) ,
  - y = k + a \cdot x y = k + a ⋅ x 。
- 空值：空值= Hash ( a ) Nullifier = Hash ( a ) 。

提交

用戶發送：有效載荷（M）+ 無效器 + 信號（x，y）+ 證明。

驗證與懲罰
服務器會檢查其“已用票據”數據庫中的無效化器：

分叉/雙花檢查：如果無效符存在且x x （消息）不同，則表示用戶試圖在兩個不同的請求中使用同一張票。求解k k和 SLASH。
償付能力檢查：驗證\pi_{REQ} π r e q以確保票號i i已獲得用戶當前資金水平的授權。

沉降

服務器執行請求。
退款：服務器簽發已簽名的退款票r = (C_{max} - C_{ actual } ) r = ( C max − C act u a l ) 。
用戶將r r添加到其累加器中，以“解鎖”更高的票券指數以供將來使用。

服務器端問責制（雙重質押）

為了防止除簡單限速之外的 API 濫用（例如，違反服務條款、生成非法內容或嘗試越獄），我們引入了二級質押層。例如，用戶可能會提交請求，要求模型生成製造武器的指令或幫助他們繞過安全控制——這些請求會違反許多服務提供商的使用政策。我們希望找到一種方法來強制執行這些政策，同時避免讓服務提供商輕易地從誤報中獲利。

具體而言：

用戶存入的總金額Total = D + S To t a l = D + S 。

D D （RLN 權益）：由協議的數學原理決定。任何提供雙重信號（已揭示的秘密k k ）數學證明的人（包括服務器）都可以申領。
S S （策略權益）：受服務器策略約束。如果用戶違反使用策略，服務器可以扣除（銷燬）該權益，但不能收回。

這樣做的目的，而不是簡單地提高D D值，是為了消除服務器以欺詐手段奪走用戶存款的動機，而這種動機可能很高，具體取決於存款金額的大小。

S型切割機制

如果用戶提交了一個有效的 RLN 請求，該請求違反了策略（但並未觸發數學上的雙花陷阱）：

違規：服務器檢測到請求負載中存在策略違規（例如，違禁內容）。
銷燬交易：服務器在智能合約上調用slashPolicyStake()函數。
- 輸入：違規請求的Nullifier和ViolationEvidence （可選哈希值/原因）。
- 操作：合約從用戶的存款中銷燬金額S S。
- 限制：服務器不能將S S歸自己所有，它會被髮送到銷燬地址。這可以防止服務器為了牟利而惡意封禁用戶。
公開問責：罰沒事件會記錄在鏈上，並附帶相應的Nullifier 。雖然用戶身份仍然隱藏，但社區可以審核服務器銷燬權益的頻率以及這些銷燬事件的公開證據。