Ethereum Magicians
This proposal introduces a system contract for shielded ETH and ERC-20 transfers integrated directly into the Ethereum protocol to resolve governance risks and fragmentation. It leverages ZK proofs and standard transaction formats to enable private transactions that are compatible with existing wallets.
AI 生成摘要
本提案建議在以太坊協議中內置一個用於 ETH 與 ERC-20 代幣隱私轉帳與提款的系統合約，以解決治理風險與碎片化問題。它利用零知識證明與標準交易格式，在確保與現有錢包兼容的同時，實現原生級別的隱私交易功能。
提案內容： 一個用於 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 版本中是否可接受，或者是否應將基於累加器的作廢標誌方案作為先決條件？
運作中的實現： 伺服器端證明演示請見 —— 這是通往完整錢包集成的一個橋樑，同時等待錢包原生採用意圖標準。源碼：。
完整規格： [PR 連結 — 提交時添加]。進一步描述動機的文章。
1 則貼文 - 1 位參與者 [閱讀完整主題](https://ethereum-magicians.org/t/eip-xxxx-protocol-enshrined-privacy-pool/27889)