ERC-721隐私泄露问题凸显，三种方案或能缓解

转载

823 天前

10106

隔夜的粥

文章转载来源：隔夜的粥

当前，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 记账，他进一步解释称：