EIP-XXXX：協議內置隱私池

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

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

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

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

基於標籤的無罪證明（Label-based proof of innocence）： 票據帶有一個可追溯至原始存款的譜系標籤。交易對手可以要求提供祖先證明；基礎合約不強制執行合規性。是否存在我們未考慮到的情況，即交易對手層級的自願性 PoI 是不足夠的？

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

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

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

運作中的實現： 伺服器端證明演示請見 private.facet.org —— 這是通往完整錢包集成的一個橋樑，同時等待錢包原生採用意圖標準。源碼：github.com/0xFacet/facet-private-demo。

完整規格： [PR 連結 — 提交時添加]。進一步描述動機的文章可在此查閱。

        1 則貼文 - 1 位參與者

        [閱讀完整主題](https://ethereum-magicians.org/t/eip-xxxx-protocol-enshrined-privacy-pool/27889)