以太坊 zkAPI 藏得住付錢的人，卻藏不住你問了什麼

以太坊基金會與開放匿名計畫於10月1日在以太坊主網上推出了zkAPI。使用者可以存入信用額度，並證明之後的AI API請求已付款，而無需向支付伺服器提供身分，也無需向模型供應商提供資金地址。供應商仍然會收到提示。這種分離很有用，但與匿名與模型對話相比，這是一種更狹隘的隱私主張。

以太坊基金會的技術公告對這一界限異常明確。該證明隱藏了哪張票據為使用付費，而供應商運行模型並看到請求。它還指出網路中介資料和提示內容是剩餘的關聯來源。這很重要，因為「私人AI支付」這個說法很容易被聽成「私人AI使用」。

根據基金會的說法，該專案已經上線，並有公開的GitHub儲存庫、一個持有USDC信用額度的主網金庫，以及一個從其公告連結的示範聊天介面。實際部署證明了有程式碼和合約可供檢查。它並未證明使用者採用、安全審計的範圍、每個客戶端配置中的匿名性，或對能夠辨識使用者寫作和文件的供應商的防護。

一筆存款取代一連串API發票

大多數商業AI API將金鑰連接到帳戶和支付方式。供應商可以將請求與帳單身分關聯起來，即使使用者從未在提示上簽名。zkAPI引入了已注資的金庫和私人票據。使用者將支援的資產（如USDC）存入合約；使用者機器上的軟體隨後產生零知識證明，證明一張有效的已注資票據可以支付有界使用量，而不揭露是哪張票據。

支付伺服器驗證證明並發行一個短期、有美元上限的API金鑰。在基金會描述的直接執行階段金鑰模式中，提示從使用者裝置帶著該金鑰傳送到AI供應商。工作階段結束後，一份簽署的收據記錄計量使用量，私人餘額會按使用量收費，而不僅僅是保留的上限。一個證明可以涵蓋包含多個請求的工作階段。

這避免了將每個模型請求都放到以太坊上。鏈上看到金庫存款、關閉和提款，而伺服器在鏈下驗證花費證明。模型供應商看到文字和API流量。支付伺服器看到工作階段已注資的證據和總費用，但在直接模式下不會收到提示。這些是關於所描述架構的主張，而非證明特定部署的日誌或網路配置永遠無法關聯使用者。

還有一種更簡單的代理模式。在該模式中，zkAPI伺服器將使用者的請求轉發給模型供應商。根據基金會的說法，該伺服器可以看到流量。在兩種模式之間做決定的人應該問，他們信任哪一方處理內容，而哪一方只需要驗證支付證明。一個看起來相同的本地介面，在底層可能會以不同方式路由請求。

該票據證明價值，但不揭露其存款人身分

該密碼學構造在默克爾樹中使用承諾。一項證明表示使用者的票據屬於有效的已注資票據之一，但不指出其是哪個葉節點。由票據秘密衍生的無效化器可防止同一筆餘額被花用兩次。該基金會指明使用 BN254 上的 Groth16 證明與 Poseidon 雜湊，並採用 32 層樹。這些細節對實作者很重要，但其財務原則是更簡單的：驗證成員資格與剩餘的支出權限，而不公開提供該筆信用的帳戶。

使用者不會因為隱藏身分而獲得免費使用。伺服器必須檢查支出證明並在發行臨時金鑰前保留一個上限。供應方計量使用量。收據在金鑰過期後結算實際金額。如果保留了 10 美元的上限，而消耗了 3 美元的服務，系統的用意是收取 3 美元，而非 10 美元。該範例說明的是保留邏輯，不是已公布的價格或保證的最低金額。剩餘餘額會留在私人票據中，並受該實作規則的約束。

無效化器處理的是一個特定失效情況：試圖將同一張票據花用兩次。它不能證明 AI 模型回答準確、不能保持提示的機密性，也不能阻止供應方記錄請求。零知識證明是關於一筆交易在既定電路下有效性的陳述。其保證不會自動擴展到隨交易一同流動的其他資料。

合約的退出路徑也很重要。該基金會表示，即使 zkAPI 伺服器消失，使用者仍可關閉金庫餘額並在鏈上提款。這避免了讓支付伺服器成為取回資金唯一途徑。它不會讓退出變得不可見：以太坊會記錄相關交易。使用者的退出能力取決於合約以及是否持有必要的秘密，而審慎的使用者在將大額價值託付給該機制前，應檢查部署地址、權限以及任何獨立審查。

供應方可以辨識出該證明無法揭露的內容

支付證明可以隱藏資金來源，但請求內容可能包含某人的姓名、雇主、病史或專有程式碼。讀取提示的模型供應方可以透過重複出現的詞語、上傳的檔案、對話歷史或高度獨特的事實，將其與先前的會話連結起來。不需要錢包連結。一個關於未發布產品、且在三段會話中使用相同內部專案名稱的提示，本身就是識別碼。

網路中介資料提供了另一條路徑。在執行時金鑰模式下，供應方可能看到裝置連線來源的 IP 位址。在代理模式下，中介者可以看到流量，並可能看到其來源網路資訊。該基金會明確表示，穩定的 IP 與相互關聯的時序可能削弱隱私，並建議尋求更強保護的使用者採用網路匿名工具。VPN 或 Tor 可以改變網路路徑，但兩者都無法移除輸入提示中的姓名。

有一個三層隱私測試。支付隱私詢問的是帳單能否被連結到某張資金票據或某個人。網路隱私詢問的是服務能否透過 IP、時序或裝置特徵辨識出某個連線。內容隱私詢問的是任何操作模型的人能否讀取提示。zkAPI 主要為第一層而設計。它可以減少模型供應方使用日誌與使用者支付來源之間的帳戶層級連結。它本身不會提供另外兩層。

這不是隱藏在細則中的缺陷。該專案自己的公告就說供應方會看到請求。誠實的描述比誇大的匿名口號更有力，因為它告訴使用者應把額外防範重點放在哪裡。使用該服務詢問一般性問題的人，可能獲得相當大的支付不可連結性。貼上一份已簽署合約與全名的人，無論支付途徑為何，都已在內容中揭露了身分。

即使證明完備，匿名集也可能很小

零知識可以隱藏數張票據中是哪一張付款，但實際的人群規模很重要。如果只有一名使用者在狹窄的時間窗口內以不尋常的存款金額為一個金庫注資，而隨後在一次會話後出現同樣獨特的提款，觀察者便可從公開的時序與金額形成一個看似合理的關聯。該證明在密碼學上可能仍然有效且未被破解。從外部資訊推斷是一種獨立的攻擊。

32 層樹是設計中的容量參數，不是數十億名不同使用者今天正在混合其信用的證據。一個剛上線的服務可能只有少量已注資票據。要在實務上評估匿名性，人們會希望取得有日期的存款數量、不同的活躍票據數與提款模式，並以注重隱私的方式進行彙總。一個程式碼儲存庫或理論上的樹大小並不能提供這些數字。

假設有十張票據符合某個會話的資格，而公開事實排除了其中九張。數學證明仍然可以完美地隱藏其見證，而周圍的資訊則指向第十張。這個簡單的例子說明了為何可信集合的大小與多樣性，比金庫中交易的原始數量更為重要。金額標準化、延遲活動與規律使用或許有幫助，但使用者行為與服務設計決定了哪些資訊可供關聯。

在 AI 供應商端還有第二種集合：共享一個短期金鑰的請求群組。該金鑰可以連結其上限會話內的請求，即使它無法識別存款。這是對會話進行計量的固有特性。如果客戶在之後的會話中反覆傳送相同的文件，供應商也可能跨金鑰將它們連結起來。隱藏帳單帳戶很有價值，但這並不會迫使供應商忘記它已讀取的內容。

在不假設任何人作弊的情況下，描繪單一會話的紀錄。以太坊記錄存款交易及其資金地址。使用者裝置保留票據秘密，並向支付伺服器傳送證明。伺服器記錄該證明的有效性、一個無效化標記，以及一個有上限金鑰的簽發事件。模型供應商記錄該金鑰、請求以及它計費的使用量。簽署收據將該金鑰與一個計量總額綁定。結束時，合約可以記錄一筆退出。每一方都擁有一份部分帳本。

預期的隱私屬性是：沒有任何單一誠實方的帳本會直接將資金地址與供應商的提示連結起來。一個聯盟、資料外洩，或擁有時間戳的外部觀察者，可能握有更多資訊。如果使用者存入一筆不尋常的金額，並立即傳送單一不尋常的請求，關聯事件可能變得更容易。如果供應商收到一份能識別使用者的文件，即使從未見過金庫地址，它也能知道是誰提出的請求。這是組合問題，而不是零知識證明失敗。

這項帳本練習也揭示了金鑰生命週期的重要性。會話憑證刻意將其授權的所有請求歸為一組，以便供應商對它們進行計量。50 美元的上限可能允許在單一金鑰下發出許多提示。較低的上限與較短的會話可以減少單一憑證內所連結的內容量，但它們需要更頻繁的證明，並可能增加延遲或費用。沒有普遍適用的隱私設定；使用者與供應商在便利性、成本與可連結性之間做出選擇。

公開的威脅模型應明確指出哪些紀錄會被保留，以及保留多久。它應說明伺服器在提交證明期間是否記錄來源 IP 位址、是否無限期儲存無效化標記，以及供應商在結算後是否能將收據識別碼與請求內容關聯起來。從資料庫中刪除帳單名稱是有幫助的。但如果一個持久性裝置識別碼悄悄重建了相同的輪廓，那就不夠了。

簽署的使用收據將信任轉移到計量上

供應商或伺服器需要一種方式，就實際執行的工作收費。該設計使用與短期金鑰及其使用量相關聯的簽署收據。這將一個核心商業問題轉移到計量的準確性上。如果供應商多計了代幣、請求或時間，有效的支付證明無法更正底層帳單。簽章使已宣稱的總額日後難以改寫；它並不確立所宣稱的使用量在供應商的價目表下是公平的。

客戶應該詢問計費單位是什麼、誰簽署收據、未使用的保留額如何釋放，以及當請求進行到一半失敗時會發生什麼。這些是披著不尋常密碼學外衣的普通帳單問題。上限限制了單一會話中意外費用的規模，但許多小會話仍可能累積出可觀的成本。速率限制與發票可能需要一個保護隱私的爭議處理流程。

這種取捨是營運層面的。傳統 API 帳戶簡化了客戶支援、退款與濫用調查，因為供應商可以識別買方。zkAPI 從預期的支付路徑中移除了持久性的帳單身分。供應商可能仍需要濫用控制、在適用情況下的制裁篩查，以及使用量執行。基金會表示定價與速率限制可以保留，但實際整合將顯示服務如何在其義務與詐欺控制之間，平衡無帳戶支付。

一個實際的測試是刻意中斷的會話。客戶取得一個有上限的金鑰，發出數個請求，失去網路連線，之後重新連線。收據是否只反映已交付的使用量？使用者能否在本機稽核計量金額，而不將提示傳送給支付伺服器？如果伺服器消失，使用者能否如宣傳般透過合約取回未使用的餘額？這些測試超越了證明是否驗證通過，進而探討產品在故障情況下是否維持所承諾的隔離。

鏈上合約是逃生出口，而非隱私護盾

根據基金會的說法，金庫合約可以驗證存款、關閉和逃生操作的證明。鏈上退出路徑之所以重要，是因為服務供應商關閉不應讓用戶資金滯留在營運商的資料庫中。該合約以智能合約風險取代了部分機構信任。即使隱私概念本身健全，證明驗證、會計或提款邏輯中的漏洞仍可能影響資金。一個活躍的地址是部署的證據，而非審計證書。

公開存款和提款也有隱私成本。知道用戶資金地址的人可以觀察到該地址與金庫進行了互動。他們可能看不到它支付了哪個 API 工作階段，但他們可以看到參與情況和金額。如果同一用戶迅速將一筆不尋常的金額提領到一個已與其關聯的地址，周圍的某些匿名性可能會縮小。私密票據打破了確定性的計費連結；它並未抹除公開的資金交易。

該項目源自以太坊研究上關於零知識 API 額度的設計，基金會認定這是 Davide Crapis 和 Vitalik Buterin 的作品。研究提案和生產系統回答的是不同的問題。前者提出了一種構造；後者必須處理金鑰儲存、前端行為、服務中斷、收據爭議、升級和真實對手。10 月 1 日的發布將這一想法推進到可測試的部署中，而這正是相關的新鮮切入點。

以太坊更廣泛的隱私努力並非同一產品。Crypto.news 對一項擬議原生隱私設計的報導涉及一項協議變更草案，而 zkAPI 是一個現在正在運行的應用程式。近期 zk.money 錢包的發布涉及另一環境中的私密轉帳。兩者都不應被引用為證據，證明透過 zkAPI 發送的 AI 提示對其模型供應商是隱藏的。

隱私主張應經得起可重現的測試

獨立審查者可以從不相關的地址創建兩個已注資的票據，與同一模型供應商發起短工作階段，並檢查客戶端、支付伺服器和供應商可見的每個封包和日誌。審查者應分別測試直接模式和代理模式。如果直接模式的支付伺服器收到提示，那就與所描述的分離相矛盾。如果供應商收到存款地址或持久的計費帳戶識別碼，那麼即使證明電路健全，預期的不可連結性也在整合層失敗了。

更困難的測試是統計性的。以不同的金額和時間運行許多工作階段，然後詢問僅擁有公開鏈上數據和伺服器日誌的一方，能否以優於隨機的機率將資金和使用關聯起來。基準取決於實際的匿名集以及對手擁有哪些輔助數據。一次成功的小型實驗室演示並不能確立在極小生產用戶群下的隱私，但它創造了一種衡量部署是否隨時間改善的方法。

內容測試直接且發人深省。在兩個全新的工作階段金鑰下提交同一份獨特的文件。如果供應商能在兩者中識別出它，那麼支付的不可連結性並未賦予用戶對話的不可連結性。關於支付的主張應由前兩項測試來評估；關於匿名 AI 使用的主張還必須經得起第三項測試。公布模式、威脅模型和結果將讓用戶能為其實際關切選擇正確的工具。

最強的理由是將計費與有用內容解除連結

有許多正當理由可以向 AI 供應商提出敏感問題，而不必建立與帳戶永久關聯的使用檔案。一名記者測試公開文件、一名研究人員探索有爭議的假設，或一名開發人員在代理中使用 API，可能希望供應商看到當前請求，同時切斷持久的計費關係。zkAPI 的設計解決了這一較狹窄的需求。它也讓機器能為計量服務付費，而無需為每個請求管理一個長期存在的個人帳戶。

反對過度主張的理由同樣強烈。供應商仍然看得到提示，而某些提示必然會洩露身分。有嚴格保密要求的企業可能需要合約控制、本地模型或機密運算，以及支付的不可連結性。有些用戶可能更偏好具有成熟支援和退款的普通帳戶，而非爭議機制仍不成熟的加密支付層。選擇取決於實際的威脅模型。

crypto.news 所討論的 以太坊隱私路線圖將隱私定位為一個更廣泛的目標。路線圖並不會將其未來的保護賦予今日的這個應用。AI 使用者必須判斷實際處理提示詞的即時客戶端與供應商路徑。

Crypto.news 在另一篇入門文章中解釋了零知識證明的較狹義機制。證明揭示了一個明確的事實，卻不揭示見證；它不是通用的隱形斗篷。其關於專注隱私的以太坊基礎設施的訪談強調了不同產品如何保護不同的資料。對 zkAPI 而言，有用的問題是在每個步驟中哪一方能看到哪一筆記錄，而不是該專案是否符合「隱私」這個寬泛詞彙的資格。

對懷疑性解讀最有力的反證，會是在沒有持久身分連結下的可衡量使用、清楚的模式標籤、獨立的安全審查，以及一份涵蓋 IP、瀏覽器遙測與收據的已發布威脅模型。對誇大行銷主張最有力的反證，已經在基金會的貼文中：供應商能看到提示詞。這兩項觀察可以同時成立。

基金會將機器對機器的 API 付款列為可能的應用。一個自主代理可能會使用一筆已注資的票據或許多短工作階段來發送數百次呼叫。如果其任務帶有客戶記錄，模型供應商即使代理的付款來源保持私密，仍能得知這些客戶的資訊。隱私利益屬於帳務連結；它不應被傳遞到請求中具名的每一個主體。

代理也需要預算控制。每個金鑰的上限限制了一個工作階段，但除非客戶端強制執行更廣泛的支出政策，否則一個迴圈可以取得重複的金鑰，直到票據被耗盡。營運者應定義每日或任務層級的限制、警示，以及獨立於密碼學證明的暫停控制。證明驗證的是已授權的額度，而不是代理的呼叫是否必要或經濟。

當多個代理共用一個額度池時，內部會計可能成為隱藏的帳務系統。營運者可能需要將費用分配給團隊或客戶，而不將其身分匯出給 API 供應商。這可以用本機帳本完成，但它會產生另一個需要保護的敏感資料集。從帳戶計費轉向票據計費並不會廢除對帳；它只是將其遷移。

最後，代理可以透過行為暴露自己。以相同排程、相同工具標頭和相同任務特定詞句進行的重複呼叫，可能使各自獨立的短命金鑰容易被聚類。隱藏鏈上注資票據對於付款監控很有用。它不是對代理隨每次請求發送的行為指紋的防禦。

部署仍需要威脅模型稽核

截至 10 月 2 日，基金會表示程式碼、伺服器、客戶端與金庫均已上線。該貼文連結了一個主網合約與儲存庫。它並未在公告中發布確定的使用者數量、經稽核的總價值、所有第三方整合，或保證每個客戶端配置都使用直接執行階段金鑰模式。此功能並未聲稱具名供應商有外洩或不當行為。它指出了每一方預期會收到的資訊，以及專案作者所承認的額外洩漏。

外部評估應檢查客戶端預設值與對外連線。瀏覽器示範是否將遙測傳送到不相關的網域？本機客戶端是否保留金鑰或提示詞日誌？付款伺服器能否將發行時間戳與網路位址結合？收據能否跨工作階段連結？電路與合約更新如何治理？一個證明可以在數學上嚴謹，而使用者介面卻意外洩漏了它原本要分離的身分。

同一項評估應測試 AI 供應商的視野。它會看到其所處理的內容以及一個工作階段憑證。它可能會依據請求路徑收集裝置或網路中介資料。供應商的資料保留政策與任何合約條款仍然至關重要。付款層可以減少一個可識別資訊的來源，卻無法約束所有其他來源。

如果 zkAPI 能可靠地防止模型供應商將有用的請求綁定到計費帳戶，同時保留用戶收回資金的能力，那它就是一項真正的進步。對於那些僅僅因為付款是以零知識證明的，就期望獲得私密對話的人來說，它會令人失望。這兩種主張應該分開評判。

值得關注的事項

• 模式標示：檢查每個客戶端是否在用戶發送提示之前，就可見地顯示直接執行時金鑰或代理路由。
• 主網活動：尋找有日期的已注資票據與使用量計數，並在不損害用戶匿名性的情況下報告。
• 安全審查：閱讀獨立評估的範圍，涵蓋合約退出、證明電路、客戶端儲存與收據結算。
• 元數據控制：在實際整合中測試 IP 處理、遙測、金鑰生命週期與供應商保留。
• 帳單爭議：檢查失敗請求、上限釋放與有爭議的收據如何處理，而不強迫揭露身分。

常見問題