ERC-721 隱私泄露問題凸顯，三種方案或能緩解

當前，NFT 市場主要使用了三種 token 標準，它們分別是 ERC-721、ERC-1155 以及 ERC-998，而佔據整個市場主導地位的依舊是 ERC-721 token 標準，例如無聊猿（BAYC）、加密朋克（CryptoPunks）、ENS 等眾多第一梯隊的 NFT 項目均採用了該 token 標準。

然而，隨着鏈上分析工具的發展，採用 ERC-721 標準的 NFT 面臨的隱私泄露問題變得越來越嚴峻。

為了說明問題的嚴重性，本文先通過一個例子來進行說明。

ERC-721 NFT 如何泄露隱私

使用 ERC-721 代幣標準發行的資產都具有獨一無二的特點，這無疑是推動 NFT 資產炒作的一個重要屬性，然而當前以太坊等公鏈還具有了賬本公開透明的特點，意味着用戶可使用區塊鏈瀏覽器等工具，通過 ERC-721 代幣查詢自己或他人的錢包信息。

最容易暴露隱私的 ERC-721 token，自然就是 ENS，其在為用戶提供便利的同時，造成了非常嚴重的隱私泄露，例如近期的“知名 ENS 地址遭投毒”事件，僅僅是 ENS 隱私泄露問題的冰山一角。

除了 ENS ，頭像類的 ERC-721 token 也會帶來嚴重的隱私泄露問題。

舉例來說，近日，用戶名為 KinkyBedBugs 的 Twitter 用戶花費了 400 ETH 購買了一隻胖企鵝（Pudgy Penguins）NFT，並將其用作自己的 Twitter 頭像。

通過查詢 opensea 的數據記錄（或特徵），我們可得知購買該 NFT 的錢包地址就是 saudietheran.eth（0 x304A97c9A85C92C93Ca24e0A85B69f892B67355E），在該網站上，我們可以看到該錢包地址持有的所有 NFT。

而通過鏈上數據查詢工具，我們甚至可以追蹤到該錢包的關聯地址及持倉情況。

（註：圖片來自 watchers）

在這個例子當中，由於 KinkyBedBugs 是一個匿名賬戶，並且其顯然做好了 NFT 錢包與主錢包地址的分離，因此，以上的信息泄露可能都是 KinkyBedBugs 故意而為之的（主動將信息透露給公眾，以實現某種目的）。

但如果通過 NFT 關聯到了持有者的真實身份，並且其沒有做好錢包聯繫分離，一旦被懷有惡意的對手方（例如黑客、投毒者、敲詐者等）利用，NFT 持有者就可能面臨非常危險的攻擊。

在了解了 ERC-721 NFT 帶來的隱私泄露問題的嚴重性后，我們需要了解一些緩解措施。

緩解措施 1：做好錢包隔離和身份隔離工作

正如在本文當中提到的例子，我們在使用 ENS token 時，應盡量避免將自己的真實身份與錢包地址聯繫在一起，例如真實姓名拼音或常用英文名可能都是糟糕的選擇，而採用一些較通用的詞，例如 DeFi、NFT、DAO、DEX 等，可以增加一些隱私性。

接下來，錢包隔離工作將是至關重要的，一般來說，我們都會有多個以太坊錢包地址，其中會有 1-2 個存放資金的主地址，而其餘存放小額資金的錢包地址會用於日常的交易或協議交互。

而我們要做的，就是切斷主錢包地址和日常交易地址之間的任何聯繫，這意味着這些錢包之間不能有任何相互轉賬的操作。（註：如果實在有轉賬的需求，可以通過中心化交易所作為中間的橋樑）

做好錢包隔離工作之後，我們將主錢包用於存錢用途，而將日常用的錢包用於存放價值較低的 ENS 或 NFT 小圖片。

緩解措施 2：隱身地址（stealth address)

近期，以太坊研究人員 Anton Wahrstätter（@Nerolation）在 ethresear.ch 發表了一項 ERC721 擴展提案‌，其提議將 zk-SNARK 技術應用到 ERC-721，以保護相關 NFT 持有者的隱私。

對此，以太坊聯合創始人 Vitalik 評論稱，使用常規隱身地址‌（stealth address) 技術可以更簡單地實現，不需要 Merkle 樹或 ZK-SNARK 級別隱私的原因在於，每個 ERC721 都是獨一無二的，因此不可能為 ERC721 創建“匿名集”。相反，用戶只是想隱藏指向發送者和接受者的高度可見的公共身份鏈接（因此，你可以將一個 ERC721 token 發送給 vitalik.eth，此時 Vitalik 本人可以看到這一點，但其他人都不能看到 vitalik.eth 這個地址收到了一個 ERC721 token，他們只能看到某人收到了一個 ERC721 token）。

那這種技術方案的原理是怎樣的呢？Vitalik 解釋稱：

“1、每一個用戶都有一個私有 p（以及對應的公鑰 P = G * p）；
2、要發送給某人，首先生成一個新的一次性密鑰 s（以及對應的公鑰 S = G * s），然後發布 公鑰 S
3、發送方和接收方都可以計算一個共享密鑰 Q = P * s = p * S。他們可以使用這個共享密鑰生成一個新地址 A = pubtoaddr (P+G * hash (Q)), 並且接收者可以計算相應的私鑰 p+hash (Q)。發送方可以將他們的 ERC20 發送到該地址；
4、發送方將掃描所有提交的 S 值，為每個 S 值生成對應的地址，如果他們找到包含 ERC721 token 的地址，他們將記錄地址和密鑰，以便他們可以跟蹤他們的 ERC721 token，並在未來快速發送；
通過在智能合約錢包內納入此方法，你可以將該方案推廣到智能合約錢包：
generateStealthAddress (bytes32 key) returns (bytes publishableData, address newAddress)
這樣發送方將在本地調用，發送方將發布 publishableData 並使用 newAddress 作為 ERC721 目標地址。假設接收者將以這樣的方式對 generateStealthAddress 進行編碼，以便他們可以使用 publishableData 以及他們個人擁有的一些秘密來計算可在 newAddress 訪問 ERC721 的私鑰（newAddress 本身可能是基於 CREATE2 的智能合約錢包）。
而剩下的一個挑戰就是弄清楚如何支付費用。"

這一想法也獲得了 Anton Wahrstätter 的認可，其目前正在根據 vitalik 的建議撰寫一份 EIP‌，計劃將提議的 generateStealthAddress (bytes32 key)應用到智能合約錢包當中。

緩解措施 3：零知識證明方案

然而，正如 Bain Capital Crypto 研究合伙人 Wei Dai 指出的那樣‌，隱身地址（stealth address）方案的缺點在於，如果它應用於 ERC-721 以外的任何 token（例如 ERC-20 或 ERC-1155 )，由於可以追蹤傳輸鏈，其可添加的隱私性是非常有限的。相比之下，基於 zk-SNARK 零知識證明的方法可以完全保持機密性或匿名性。

在他看來，理想情況下，L1 應支持可由智能合約應用使用的隱私保護 token，這可以通過已知技術實現，實際上，用戶可以充分利用 Aztec 等以隱私為中心的 L2，並在 L1 上默認設置隱私保護 token 記賬，他進一步解釋稱：

" 以太坊內置隱私的主要問題是，我們有一個和 EOA 相關的固定 gas 費用支付機制，除非我們有保護隱私的 gas 支付方式，否則所有隱私保護 token 標準都沒有實際意義。這就是為什麼目前最好在以太坊的單獨層中完成隱私，除非可以進行保護隱私的 gas 支付。”

而擺在用戶面前的另一個問題是，採用零知識證明隱私解決方案，可能會遇到監管上的一些麻煩，例如 FTX 交易所就屏蔽了一些 Aztec 用戶地址，併發出了相關警告。

可見，更好的隱私性，也不一定是一件好事。

一點淺見

作為一名普通的以太坊用戶，就目前來說，我們首先應做好身份隔離和錢包隔離工作，以避免嚴重的隱私泄露問題，而在不久的將來，內置隱身地址（stealth address）方案的智能合約錢包，可能會得到更多的採用。

而隱私性更好的零知識證明方案，由於監管方面的擔憂，或許會遇到一些阻力，這還需要我們更多的觀察。