全文
付款紀錄與服務內容為何會被連在一起
以太坊基金會在 2026 年 10 月 1 日介紹 zkAPI，目標是降低 API 使用與付款身分之間的連結。一般服務常把多次請求放在同一帳戶下，方便計費，也形成長期使用紀錄。這裡要解決的是資料如何被串連，而不只是付款時是否填入姓名。假設兩個工作階段使用同一個可識別帳戶，即使每次付款金額不同，服務仍可能把它們理解成同一人的活動。
證明有額度，不必交代哪筆存款
來源描述的設計讓使用者先存入額度，再以零知識證明取得消費授權。可以把它理解成回答一個範圍受限的問題：是否具備足夠且未重複使用的付款能力，而不交出所有相關資料。這與單純把姓名欄位刪掉不同，因為刪除欄位後，固定帳號仍可能充當身分標記。設計的價值在於減少完成驗證所需暴露的關係，但證明的涵蓋範圍也限定了它能保護什麼。
消費上限是預留，不必等於最後帳單
zkAPI 的短效金鑰帶有消費上限，工作階段結束後依實際用量結算。假設使用者授權最多十單位預算，服務最後只用了三單位，上限與實際收費就應分別記錄。十單位表示可以接受的最大暴露，三單位才是這個例子的用量。若介面把兩者都叫餘額，容易讓人誤會預留已被永久扣除。這個假設也說明，限制支出與核對計量是不同問題，設定上限不能替代對帳。
付款保密不會讓請求內容自動保密
即使付款與存款之間的關係被隱藏，服務仍可能讀到請求內容。假設使用者在輸入中直接寫入公司名稱與完整專案資料，付款層的隱私不會把這些字抹掉。時間、網路來源與重複輸入也可能提供額外線索。來源另區分直接使用短效金鑰與代理轉送模式，後者讓轉送方接觸流量。因此，判斷誰看得到什麼，必須沿實際資料路徑逐一追蹤，不能把單一隱私功能擴大成全面匿名。
可驗證付款仍需要可理解的服務邊界
本站認為，這類設計最有價值的地方是將權限壓縮到一次工作所需的範圍：有限預算、有限期間與有限資料揭露。對使用者而言，仍需分辨授權是否過期、用量如何記錄，以及中斷後哪部分額度可再使用。這些是產品與結算語意問題，不能只靠證明有效就自動解決。本文依十月的設計介紹說明機制，不把所有 API、供應商或後續版本都描述成已具備相同能力。