ERC：加密代幣標準 — 結合全同態加密餘額與零知識傳輸驗證
我正在提議一項新的 ERC 標準，該標準定義了一個同質化代幣接口，利用全同態加密技術保護餘額隱私，並透過零知識證明進行轉帳驗證，在確保隱私的同時讓任何人都能驗證交易的有效性。
摘要
我正提議一項新的 ERC，旨在為具備全同態加密（FHE）餘額與 零知識（ZK）轉帳驗證的同質化代幣定義標準介面。
簡而言之：這是一個無人能看到你的餘額或轉帳金額，但任何人都能驗證每筆轉帳皆為有效的 ERC-20 代幣。
PR: Add ERC: Encrypted Token Interface by Valisthea · Pull Request #1680 · ethereum/ERCs · GitHub
作者： Valisthea
問題所在
ERC-20 暴露了一切。餘額、轉帳金額、授權（approval）數值——全部都是公開的。這產生了五個具體問題：
投資組合曝光 —— 任何人都可以查詢你的持有量，從而實現有針對性的社交工程攻擊和搶先交易（front-running）。
轉帳監控 —— 鏈上圖譜分析甚至能讓使用者在經過混幣器後仍被去匿名化。
MEV 榨取 —— 可見的待處理金額使得夾心攻擊（sandwich attacks）成為可能。隱私是代幣層面上唯一能結構性修復 MEV 的方案。
治理脅迫 —— 餘額可見的代幣加權 DAO 投票，使得賄選和政治報復成為可能。
監管衝突 —— GDPR 第 17 條（刪除權）、MiCA 和 HIPAA 與永久公開的餘額存儲存在衝突。
為什麼現有解決方案無效
混幣器 / 隱私層（Tornado Cash, Aztec Connect）是外部包裝器。隱私代幣在取消隱私保護之前，無法在 Uniswap、Aave 或 Compound 中使用——這破壞了隱私保證，也損害了 DeFi 的可組合性。
基於承諾（Commitment）的方法（Pedersen, Poseidon 哈希）隱藏了數值，但不支持計算。如果沒有發送者的配合，你無法將兩個承諾相加。借貸協議無法在承諾的抵押品上計算清算門檻。
FHE 原生鏈（Fhenix, Zama 的 fhEVM）雖然存在，但尚未提出標準介面。每個實現都自創 API，導致錢包和協議無法進行通用整合。
目前沒有任何 ERC 對加密代幣餘額進行標準化。本提案填補了這一空白。
本標準定義的內容
一個擴展了 ERC-20 元數據（名稱、符號、小數位、總供應量）的介面，並為所有隱私敏感操作提供加密對應項：
加密查詢
encryptedBalanceOf(address) → 返回 FHE 密文（僅所有者可解密）
encryptionScheme() → 識別使用的 FHE 方案（TFHE, OpenFHE 等）
publicKey() → 合約的 FHE 公鑰（使用者以此加密輸入數據）
盲轉帳（Blind Transfers）
blindTransfer(to, encryptedAmount, proof) → 經過 ZK 驗證有效性的轉帳
blindTransferFrom(from, to, encryptedAmount, proof) → 委託盲轉帳
事件：BlindTransfer(from, to, proofHash) — 不洩漏金額
加密授權
blindApprove(spender, encryptedAmount, proof) → 加密授權額度
encryptedAllowance(owner, spender) → 剩餘授權額度的密文
選擇性披露（選用）
- verifyBalancePredicate(account, predicate, proof) → 在不洩漏餘額的情況下證明「餘額 ≥ X」
屏蔽 / 取消屏蔽 橋接（Shield / Unshield Bridge）（選用擴展）
shield(amount) → 從公開 ERC-20 池移動到加密池
unshield(amount, proof) → 從加密池移動到公開池
本標準與 FHE 方案無關，也與 ZK 證明系統無關。實現可以使用 TFHE、BFV、Groth16、Halo2 或任何符合指定要求的系統。
關鍵設計決策
FHE 優於承諾 —— FHE 密文原生支持同態加法/比較。合約無需解密即可更新餘額。借貸協議可以同態地驗證「餘額 ≥ 抵押門檻」。
謂詞證明（Predicate proofs）優於餘額查詢 —— DeFi 很少需要精確餘額。它需要的是「這是否足夠？」——一個布林值。verifyBalancePredicate 為協議提供了它們所需的信息，且僅此而已。
不含金額的事件 —— BlindTransfer(from, to, proofHash) 保留了可索引性（誰發送給誰），同時不洩漏金額。proofHash 允許獲得授權的離線審計員進行驗證。
向後兼容 ERC-20 —— 公開元數據函數是相同的。代幣可以同時實現這兩種標準，並以 shield/unshield 作為兩池之間的橋樑。
安全考量
草案包括對以下內容的詳細分析：密文可延展性（通過證明綁定緩解）、證明重放（在公開輸入中使用 nonce + chainId + contractAddress）、側信道洩漏（時間、Gas——通過恆定大小電路緩解）、量子威脅（基於格的 FHE 被認為具有抗量子性）以及密鑰管理（具有 ≥ 5 個保管人的門檻 Shamir SSS）。
完整的規範，包括 Solidity 介面、證明格式、謂詞編碼和安全分析，均在儲存庫中。
社群提問
方案註冊表 —— 標準是否應該為 FHE 方案標識符定義一個 bytes4 註冊表，還是使用自由格式的字串就足夠了？
證明大小 —— 證明大小合理的「應該（SHOULD）」限制是多少？1KB？4KB？
總供應量（totalSupply）可見性 —— totalSupply 應該強制公開，還是機密供應量應該作為核心介面的一部分（而非擴展）？
費用介面 —— 標準是否應該為 FHE 計算成本包含一個選用的費用擴展（pGas 模型），還是完全交由實現決定？
密鑰輪換 —— 草案包含了用於密鑰生命週期管理的 keyVersion() 和 isKeyActive()。這在標準層面上是否過度設計，還是必不可少的？
期待社群的反饋。這是第一個提議原生 FHE 加密代幣餘額的 ERC——如果之前討論過類似內容，我很想了解先前的研究。
— Valisthea
1 則貼文 - 1 位參與者
[閱讀完整主題](https://ethereum-magicians.org/t/erc-encrypted-token-standard-fhe-encrypted-balances-with-zk-transfer-verification/28214)