提案內容： 一個用於 ETH 和 ERC-20 代幣隱私轉帳與提款的系統合約 —— 採用單一規範票據樹（canonical note tree）、僅限硬分叉升級、無管理員金鑰。存款是公開的；轉帳和提款則透過在預留的鏈 ID 上簽署標準 EIP-1559 type-2 交易來授權，這些交易會被轉換為零知識證明（ZK proofs）並提交至鏈上（本地提交或透過隱私 RPC）。隱私 RPC 將意圖鏈（intent chain）呈現為標準 EVM 網路，因此錢包會看到正常的發送流程 —— 無需自定義簽署介面。配套的證明驗證預編譯（precompile）具有分叉定義的電路 ID，允許在每次硬分叉時添加新的授權方法和證明系統。

為何要納入協議（Enshrine）： 應用層的資金池面臨兩難：可升級 → 治理風險；不可變 → 僵化風險。系統合約解決了這兩個問題 —— 代碼透過與任何協議更改相同的社會共識過程進行升級，因此當密碼學假設減弱時，資金池可以隨之遷移。匿名集從第一天起就是規範的，而不是在競爭部署中從零開始引導。以太坊定義了有效的公開交易；對有效私密交易的規範定義是一個自然的補充。失敗影響範圍是有限的：系統合約中的 ZK 正確性漏洞會暴露資金池持有的資金，但不會影響共識層。

我們希望獲得回饋的關鍵設計選擇：

意圖格式（Intent format）： 用戶在根據執行鏈 ID 確定性生成的預留鏈 ID 上簽署標準 type-2 交易。這適用於所有現有錢包且無需修改，但在電路內部處理 RLP + keccak 的成本很高。這值得電路成本嗎？或者是否有更簡潔且不需要錢包更改的授權原語？

基於標籤的清白證明（Label-based proof of innocence）： 票據帶有可追溯至原始存款的血統標籤。交易對手可以要求提供祖先證明；基礎合約不強制執行合規性。是否存在我們未考慮到的情況，即交易對手層級的選擇性加入（opt-in）PoI 是不足夠的？

發行者查看密鑰（Issuer viewing keys）： 許可資產發行者註冊一個與其代幣地址綁定的查看密鑰；電路會自動為其代幣加密額外的密文。這種範圍受限的可視性 —— 發行者可以看到自己代幣的轉帳，而看不到其他任何內容 —— 是否足以滿足人們實際擁有的發行者使用場景？

系統合約 vs. 僅預編譯： 僅靠 ZK 驗證預編譯雖能使鏈上操作的 Gas 成本可行，但無法解決資金池合約本身的治理、僵化或匿名集碎片化問題。資金池狀態必須存在於某個具有升級模型的地方。人們是否看到了僅靠預編譯就能實際解決這些問題的路徑？

狀態增長： 每筆資金池交易會寫入約 4 個永久存儲插槽（作廢符 nullifiers 不可修剪）。這對於隱私池來說是標準做法，但納入協議使其成為協議層級的狀態。這在 v0 版本中是否可以接受，或者是否應將基於累加器的作廢符方案作為先決條件？

開發中實作： 伺服器端證明演示位於 private.facet.org —— 這是錢包原生採用意圖標準之前的過渡方案。源代碼：github.com/0xFacet/facet-private-demo。進一步描述動機的文章可在此查閱。

完整規範：

• Pull Request

• EIP 直接連結