ERC-8227：具備全同態加密餘額與零知識驗證的加密代幣標準

摘要

我正提議一項新的 ERC，旨在定義一個具備 全同態加密（FHE）餘額 與 零知識傳輸驗證 功能的 同質化代幣 標準接口。

簡而言之：這是一個 ERC-20 代幣，沒有人能看到你的餘額或轉帳金額，但任何人都可以驗證每筆轉帳的有效性。

PR: Add ERC: Encrypted Token Interface by Valisthea · Pull Request #1680 · ethereum/ERCs · GitHub

儲存庫: GitHub - Valisthea/styx-erc-encrypted-token: ERC-XXXX: Encrypted Token Standard — FHE-encrypted balances with ZK transfer verification. By Kairos Lab. · GitHub

作者： Valisthea

問題所在

ERC-20 暴露了一切。餘額、轉帳金額、授權數值——全部都是公開的。這產生了五個具體問題：

投資組合曝光 —— 任何人都可以查詢你的持有量，從而實現有針對性的社交工程攻擊和搶先交易（front-running）。

轉帳監控 —— 鏈上圖譜分析甚至能讓使用者在經過混幣器後仍被去匿名化。

MEV 榨取 —— 可見的待處理金額使得夾心攻擊（sandwich attacks）成為可能。隱私是代幣層面上唯一能結構性修復 MEV 的方案。

治理脅迫 —— 餘額可見的代幣加權 DAO 投票，會導致賄選和政治報復。

監管緊張 —— GDPR 第 17 條（刪除權）、MiCA 和 HIPAA 與永久性的公開餘額儲存存在衝突。

為什麼現有解決方案無效

混幣器 / 隱私層（Tornado Cash, Aztec Connect）是外部包裝器。隱私代幣在未解除隱私（unshielding）前無法在 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 接口、證明格式、斷言編碼和安全分析，均在儲存庫中。

社群提問

方案註冊表 —— 標準應該定義一個 bytes4 註冊表來識別 FHE 方案，還是使用自由格式的字串就足夠了？

證明大小 —— 證明大小合理的「應該（SHOULD）」限制是多少？1KB？4KB？

總供應量可見性 —— totalSupply 應該強制公開，還是機密供應量應該作為核心接口的一部分（而非擴展）？

費用接口 —— 標準是否應該包含一個針對 FHE 計算成本的選用費用擴展（pGas 模型），還是完全交由實作決定？

密鑰輪換 —— 草案包含了用於密鑰生命週期管理的 keyVersion() 和 isKeyActive()。這在標準層面上是否過度設計，還是必不可少的？

期待社群的反饋。這是第一個提議原生 FHE 加密代幣餘額的 ERC —— 如果之前討論過類似內容，我很想了解先前的相關研究。

— Valisthea

        5 則貼文 - 2 位參與者

        [閱讀完整主題](https://ethereum-magicians.org/t/erc-8227-encrypted-token/28214)