Vitalik Buterin 的偏執模式測試 Ethereum 對 AI 私隱的承諾

Vitalik Buterin 為其 AI 代理加上四層私隱防護，儘管他承認這套實驗性配置仍較慢，亦容易受到流量分析影響。Vitalik Buterin 的偏執模式結合 Tor 路由、掩護流量、匿名付款及本地提示詞改寫，目標是防止 AI 供應商輕易將對話與發起對話的人連繫起來。

這個原型於 Ethereum Foundation 與 Open Anonymity Project 在 Ethereum 主網推出 zkAPI 兩周後面世。該系統透過零知識證明，將按用量計費的 API 付款與用戶的付款身分分離。Buterin 的封裝方案則嘗試處理單靠付款私隱無法隱藏的資訊，包括網絡地址、時間模式及可辨識的寫作習慣。

這項分別對正考慮把自主代理用於金融、研究或內部營運的機構尤其重要。Ethereum 可提供私密付款機制，但無法令外部模型忘記其必須處理的提示詞。因此，這項實驗測試一個更棘手的命題：多項並不完整的防護措施，能否組成一個對實用 AI 代理而言足夠私密的運作環境。

Vitalik Buterin 的偏執模式加入四層私隱防護

Buterin 的實驗將 AI 私隱視為一連串彼此獨立的洩漏問題，而非單一加密問題。

2026 年 10 月 16 日，Buterin 介紹一個圍繞其個人 AI 代理框架建立、與 OpenAI 相容的 daemon。daemon 是一種背景程式，負責管理代理與外部模型供應商之間的請求。

這套配置會為每段對話分配獨立的 Tor 線路。Tor 會經由多個中繼節點傳送流量，避免目的地直接看見用戶原本的互聯網地址。

只要工作階段仍在進行，每段對話便會保留其獲分配的線路。新工作階段會獲得另一條線路及新的付款授權。這項設計可限制不同對話之間直接建立關連，同時避免每則訊息都承受效能代價。

Buterin 亦會把真實請求與隨機掩護流量混合。掩護流量是為了讓觀察者更難辨認真實活動而發出的誘餌通訊。這種方法可隱藏被動監控下明顯的請求突增，但無法擊敗所有形式的時間分析。

本地語言模型會在提示詞離開用戶電腦前進行改寫。這個步驟嘗試移除風格指紋、慣用表述及其他可能識別作者身分的語言模式。

本地模型不會令提示詞內容變得不可見。它會改變表達方式，同時保留足夠含義讓遠端模型作答。姓名、文件、交易細節或罕見事實仍可能揭示用戶身分。

其後，Buterin 在 bubblewrap 沙盒內執行代理。沙盒會限制程式可存取的檔案、裝置及網絡資源。網絡呼叫會經過 torsocks，將受支援的連線導入 Tor 網絡。

付款層來自 zkAPI。軟件不會出示連接帳戶的傳統 API 金鑰，而是透過加密付款證明取得短暫有效的憑證。

Buterin 以查詢 Tallinn 的純素餐廳測試整套系統。這項任務刻意保持平常，但測試了由本地改寫至遠端推論的整個流程。

他形容這套架構「已變得頗為可用」，但指出啟動新對話時仍有明顯延遲。這個承認比名稱更準確地界定了實驗。偏執模式是具備明確取捨、可運作的原型，而非完成品私隱產品。

公開程式碼亦附有重要警告。zkAPI repository 將其啟用私隱功能的分支描述為非生產環境版本。部分網絡 manifests 尚未部署，而生產用證明材料亦尚未完整。

這些限制令事件不止是一項功能公布。Buterin 建立了具體的威脅模型，並揭示各組件的失效之處。結果促使需要保證、審核及營運問責的機構作出仔細檢視。

為何 Ethereum 的 AI 安全推動現時重要

AI 代理會將一般私隱弱點轉化為營運風險，因為它們結合敏感背景資料、外部工具及採取行動的權限。

標準聊天機械人接收文字並回傳文字。代理則可維持記憶、檢視文件、呼叫 API、執行程式碼及與金融帳戶互動。這些額外能力令系統更有用，但亦擴大身分洩漏的後果。

投資代理可能接收投資組合資料、計劃中的交易、錢包地址、稅務問題及私人研究。企業代理則可處理客戶記錄、原始碼、產品計劃或法律文件。

即使供應商不要求真實姓名，多項訊號仍可重建身分。互聯網地址可揭示網絡來源；付款方式可將使用情況連繫至帳戶；寫作風格及反覆出現的事實亦可將不同工作階段關聯起來。

Ethereum Foundation 的 zkAPI launch 處理了問題中的付款部分。用戶將信用額存入 Ethereum 金庫，並獲得代表其結餘的私密票據。

當軟件需要 API 存取權時，便會生成零知識證明。該證明確認存在足夠信用額，卻不識別原始存款或其擁有人。

服務隨後會發出具有限制消費額度的短暫有效金鑰。提示詞會傳送至模型供應商，付款授權則經由另一條路徑傳送。供應商可看見內容及使用情況，但理應不會取得付款人的帳單身分。

現行設計使用 BN254 曲線上的 Groth16 證明。承諾值及 nullifier 可防止觀察者直接將每項請求連繫至同一筆存入的結餘。nullifier 是一種單向識別碼，可在不揭示底層秘密的情況下阻止重複使用。

這種方式有別於透過可見區塊鏈交易逐次付款。直接鏈上付款可能暴露時間、錢包歷史及服務之間的關係，亦可能為互動式代理帶來不可接受的延遲。

zkAPI 改為授權一個工作階段。這可減少重複的證明及結算工作，同時保留資金來源與個別請求之間的分隔。

該系統不僅適用於 AI 推論。其架構可支援其他按用量計費服務，包括區塊鏈資料呼叫、媒體生成、頻寬或機器對機器任務。AI 仍是最清晰的測試案例，因為提示詞往往包含私密或商業敏感資訊。

機構對系統的評價將有別於個人開發者。原型可容忍手動設定及不斷變動的介面；銀行、研究實驗室或企業安全團隊則需要穩定控制、記錄完善的失效模式及獨立審查。

這些買家亦需要知道哪一方可觀察每個階段。付款伺服器可看見有效授權及總用量；模型供應商可看見提示詞及回應；Ethereum 會記錄存款及提款，但不會記錄對話本身。

這種分隔可減少集中式資料收集，但不會消除資料暴露。對機構用戶而言，這項差異決定系統能否支援受監管工作負載，還是只能用於較低風險的實驗。

這個時機亦反映 AI 安全的更大轉變。各機構正由一般私隱承諾，轉向把信任分散於裝置、付款系統、網絡及推論供應商之間的技術控制措施。

Buterin 的原型透過提出一個問題，推動這個趨勢：私隱是否應圍繞代理本身建立？若代理控制路由、改寫、付款及權限，用戶便較少依賴供應商的帳戶政策。

匿名付款不等於匿名 AI

核心取捨很直接：Ethereum 可以隱藏付款者身分，但模型仍需要足夠資訊來完成所要求的工作。

private usage design 直接說明這項限制。zkAPI 不提供網絡匿名性，亦不會防止提示詞內容造成的私隱洩漏。

這條界線至關重要。零知識證明可在不揭示資金關係下確認付款，但無法阻止推論供應商讀取提交作處理的文字。

本地提示詞改寫嘗試減少這種暴露。小型模型可移除慣用措辭、替換可識別的短語，或在傳送前概括某些細節。

然而，當代理接收更具體的工作時，改寫的效用便會下降。要求概述公開文件很容易清理；涉及私人合約、醫療記錄或專有程式庫的請求則困難得多。

移除過多背景資料會降低答案質素；保留必要背景則可能披露用戶原本想保護的資訊。沒有任何路由技術可解決內容與效用之間的衝突。

對話歷史會造成另一個弱點。單一提示詞可能幾乎不會揭示資訊，但一連串對話可形成獨特的個人檔案。重複出現的地點、項目、偏好及詞彙，會為不同工作階段提供關聯點。

獨立 Tor 線路無法阻止以內容為本的關聯分析，獨立付款憑證亦不能。它們限制特定識別碼，卻仍讓模型供應商可取得語義識別碼。

代理的工具同樣會產生資訊。搜尋查詢、擷取的文件、交易呼叫及錯誤訊息均可能暴露意圖。若工具其後傳送未經修改的檔案，改寫後的用戶提示詞便幾乎沒有保護作用。

沙盒處理的是另一種威脅。它限制遭入侵或被誤導的代理在本機上可接觸的範圍。這項保護很重要，因為代理可能遵從嵌入網站或文件內的惡意指令。

不過，沙盒只能執行其獲授予的權限。若代理確實需要存取敏感資料夾，該資料夾的內容仍可進入其工作背景。

因此，機構部署需要明確的資料邊界。安全團隊必須界定代理可檢視哪些檔案、可呼叫哪些工具，以及哪些目的地可接收輸出。

它們亦需要供事故調查使用的日誌。這項要求可能與不可連結性衝突。除非在本地處理審計，否則一個旨在抹除身分與使用情況之間連結的系統，可能會令內部問責變得更困難。

這項承諾並非完整匿名性，而是分區隔離：不同參與方只會得知交易的不同部分。

這仍可能很有價值。模型供應商可處理提示詞，卻不會收到持續存在的帳單檔案；付款系統可結算用量，卻不會看見對話；網絡中繼節點可轉送流量，卻不知道兩個端點。

機構已在金融託管及存取管理中採用相似的分隔原則。任何單一營運者都不應持有濫用系統所需的全部憑證、批准及記錄。

但 AI 推論加入了一個無可避免的接收方。除非運算在本機或保密硬件內進行，否則遠端模型必須接收有用內容。Paranoid mode 可減少周邊中繼資料，但無法消除這項基本依賴。

Tor 與掩護流量仍留有時間差缺口

Paranoid mode 提高監控成本，但 Buterin 自己的威脅模型說明，隨機誘餌流量無法保證不可連結性。

Tor 能有效應對許多被動觀察者。它透過多個節點轉送流量，隱藏用戶與目的地之間的直接連線。

不過，AI 流量呈現可辨識的模式。用戶發出提示詞，服務供應商接收請求，再傳回回應。即使內容仍經過加密，封包的時間與流量大小仍可形成相配的特徵。

隨機掩護流量令這種配對更困難。偽造請求包圍真實活動，令觀察者需要比對的可能事件增加。

主動攻擊者有更多選項。模型供應商可故意延遲或改變回應流量。如該供應商與入口中繼節點合作，雙方可搜尋同一個經操控的模式。

Buterin 在討論其實作時指出了這種可能性。他偏好的長期方案，是採用具備恆定掩護流量的專用 mixnet。

mixnet 會透過多個中介節點傳送訊息，並延遲、重新排序及混合流量。即使用戶沒有真實請求，恆定掩護流量仍會維持規律的傳輸。

真實訊息其後會取代誘餌封包，而不改變可見的傳輸速率。觀察者在 agent 活動前、期間及之後看到的模式都一樣。

這種更強的設計帶來直接成本。用戶閒置時，恆定流量仍會佔用頻寬。混合機制會增加延遲，而全球分散的中繼節點則增加營運複雜度。

系統亦需要足夠多獨立的中繼營運者。如某個組織控制所選路徑上的每個中繼節點，便可重建更多路由資訊。

經濟誘因不會自動解決這個問題。質押可懲罰可量度的失誤，卻無法證明名義上分開的營運者並無共同擁有人。

一個最近推出、使用 Paranoid Mode 名稱的項目，提出三跳路由及已質押中繼節點。其網站表示，該項目獨立於 Buterin 及 Ethereum Foundation。這個區分十分重要，因為某個實作存在，並不代表獲得背書。

這個獨立網絡亦說明另一項挑戰：代幣激勵可能分散對安全評估的注意力。中繼獎勵、治理規則及懲罰參數，不能取代密碼學審查。

Tor 限制分析亦指出，供應商仍會收到經改寫的提示詞。因此，流量保護與內容保護必須分開評估。

延遲仍是用戶最明顯的成本。Buterin 表示，新對話的啟動較慢，因為每個工作階段均需建立全新的網絡及付款狀態。

機構或會為敏感研究或高價值交易接受這種延遲。但對於需要快速工具呼叫的日常互動工作，它們較不可能接受。

掩護流量亦帶來額外的財務問題。若作為誘餌的模型呼叫到達收費供應商，成本將會很高。網絡層封包較便宜，但需要可識別並安全丟棄掩護訊息的專用基礎設施。

可行的設計必須決定誘餌在哪裏終止，以及由誰支付其傳輸費用。它亦必須防止中繼節點為節省頻寬而假裝發送所需流量。

這些問題並不會否定該原型。它們釐清了減少明顯中繼資料與提供可辯護匿名保障之間的差距。

這個區分將決定 paranoid mode 是維持為個人設定，還是成為機構 AI 的參考架構。

機構採用需要審計、控制與清晰責任

機構會將這個技術堆疊視為一系列安全依賴，而非單一冠上 Ethereum 名稱的私隱功能。

第一項依賴是 zkAPI 本身。其公開儲存庫將協議標示為實驗性，並警告介面可能在穩定版本發布前變更。

密碼學系統需要的不只是可運作的程式碼。機構會尋求獨立審計、可重現建置、安全參數生成，以及對已發現漏洞的清晰應對措施。

智能合約風險亦仍然存在。存入 vault 的資金取決於合約邏輯、證明驗證及提款機制。私隱好處無法抵銷會鎖定或錯誤轉移資產的漏洞。

第二項依賴是本機客戶端。它處理錢包資料、工作階段憑證、提示詞改寫及路由決策。該環節一旦遭入侵，便可繞過下游的每一層私隱防護。

因此，軟件發行亦成為威脅模型的一部分。用戶需要驗證二進制檔、更新、依賴項及設定檔。企業團隊亦會要求受管理部署及政策執行。

第三項依賴是用於改寫的本機模型。其輸出必須在移除識別資料的同時保留任務含義。沒有簡單的評分可證明它同時達成這兩個目標。

改寫可能改變關鍵的合約措辭或技術限制。它亦可能保留一項獨特細節，因為刪除該細節會令提示詞無法使用。

組織需要涵蓋私隱及語義準確性的測試。這些評估應採用具代表性的工作負載，而非一般聊天範例。

第四項依賴是模型供應商。Paranoid mode 減少供應商取得身分及付款中繼資料的機會，但供應商仍控制推論。

它可按其技術設定及合約義務保留內容。它亦可更改模型、記錄系統或濫用控制方式，而本機客戶端無法驗證。

保密運算提供其中一條可能的支援路徑。可信執行環境會在受保護硬件內隔離程式碼及資料，同時提供有關運行中軟件的證據。

不過，由硬件支援的推論亦會引入自身的供應商、認證系統及漏洞歷史。它轉移信任，而非消除信任。

機構亦必須決定如何處理法律要求及內部調查。旨在防止關聯的私隱系統，可能令合規、欺詐審查及員工問責變得複雜。

實際可行的企業版本，可能需要由組織在供應商以外控制身分。僱主可知道哪名員工啟動工作階段，而模型供應商只會收到不可連結的授權。

這項安排可保留內部管治，而不會讓推論公司取得完整用戶檔案。它亦需要在審計日誌與提示詞內容之間作出審慎分隔。

原本 AMBCrypto 的論述將這項實驗與機構對 Ethereum 的興趣連結起來。這個結論仍屬推測。Buterin 並未宣布機構產品、客戶部署或正式的 Ethereum 協議變更。

mainnet 付款報告確認 zkAPI 已投入運作，但部署並不等於採用。使用數據、供應商整合及獨立安全審查，將提供更有力的證據。

機構亦重視持續性。它們需要可信的營運者、支援流程、服務水平預期及遷移計劃。開源原型可提供元件，卻未必提供這些保障。

最有力的短期案例，可能涉及已營運 Ethereum 基礎設施並理解其風險的開發者。他們可測試私密 API 付款，而不將整個技術堆疊視為可投入生產的方案。

較大型組織可將這個架構作為模式研究。分離付款身分、網絡來源、提示詞準備及本機權限，然後根據組織實際的威脅模型評估每項控制措施。

Ethereum AI 私隱的下一步

三項訊號將顯示 Vitalik Buterin paranoid mode 正在成為基礎設施，還是維持為具影響力的實驗。

第一項訊號，是經獨立審查、具備穩定生產工件的 zkAPI 發布版本。審計應檢視 vault 合約、證明系統、客戶端錢包及提款路徑。

穩定版本將強化匿名 API 付款可支援實際應用的論點。若持續警告仍有未部署元件，系統便會維持在實驗用途範圍內。

第二項訊號，是模型供應商或 API gateway 採用。當開發者可在毋須為每項服務重建整合的情況下，存取多項推論服務，付款層便會更有用。

供應商支援亦會測試匿名付款能否與防止濫用並存。即使服務無法識別每名付款者，仍需要速率限制、欺詐控制及法律合規。

若能取得可行平衡，便可支持 Buterin 更廣泛的說法：API 不需要永久連結身分的帳戶。若主要供應商拒絕，則會削弱該架構的實際覆蓋範圍。

第三項訊號，是專為 agent 流量設計、可信的網絡私隱層。它必須提供恆定掩護流量，同時不令延遲及頻寬成本變得難以接受。

該層亦需要獨立的中繼多樣性及可量度的安全模型。僅有代幣化中繼清單，無法回答營運者集中度或主動攻擊的問題。

成功開發將彌補 Buterin 指出的最重要網絡弱點。若失敗，Tor 與隨機掩護流量仍會是有用但不完整的防禦措施。

讀者不應將 ETH 市場走勢視為驗證指標。該原型與網絡收入、機構需求或資產價格之間，並無已證實的關係。

有意義的指標屬於技術及營運層面。應留意審計結果、穩定版本、真實供應商整合，以及處理敏感工作的開發者持續使用的情況。

對 AI 開發者而言，眼前的教訓在於架構設計。身分會透過多個渠道外洩，因此單一私隱功能無法獨自保護 agent。

團隊應繪製付款系統、網絡、供應商、本機客戶端及 agent 工具各自可觀察到的內容。他們亦應在其技術知識庫中保存可搜尋的威脅模型及決策紀錄。

Vitalik Buterin paranoid mode 令這種分散的風險變得可見。它並未確立機構級私密 AI，但為安全團隊提供了一個可具體質疑的技術堆疊。

下一個問題是，獨立審查者與服務供應商能否將其分層保護轉化為可靠基礎設施。在此之前，paranoid mode 應被視為一項具備異常坦誠限制的嚴肅實驗。