1月19日，Vitalik在以太坊官方技术论坛Magicians发起了关于账户隐私方面的讨论。讨论中Vitalik提出通过开发工具和layer2验证的方式可以完善隐私漏洞。

vbuterin：

目前，以太坊的隐私环境存在漏洞。有两个原因。首先，默认情况下，用户所有活动都是通过一个帐户完成的，因此账户可以链接链上内容。其次，即使用户有多个帐户，将用户的活动分开（默认情况下每个活动使用不同App，即使用不同的帐户），用户需要在帐户之间转移ETH支付Gas费，这样的设计本身隐藏了隐私泄露。

这种情况我想到了两个方面去改进。

1.Mixers

我们可以鼓励开发易使用且完全去中心化（完全无服务器）的Mixers，以保护持有少量ETH的账户隐私，如果用户想将Gas费付款发送到另一个帐户，不需要两个账户链上的关联验证（例如基于ringig或zk-snark的）。智能合约Mixers面临的一个挑战是，如果将资金从A发送到B，B仍然需要支付Gas费才能提交证明以接收资金，这个过程会隐藏隐私泄漏。这可以通过layer2协议来解决，用户可以通过layer2协议来广播证明（包括他们想要接收的地址、承诺以及愿意支付的费用），而不是像Whisper这样的，并且一组专门的节点可以验证这些证明，包括交易、支付的Gas，并从收件人处收取费用。但是这个协议需要进行规范，标准化和实施......

2.UX（用户体验）

如果我们为每个dapp设置默认值，用户使用单独的帐户，我们必须克服一些挑战：

（1）地址生成：保持钱包无状态，用户可以轻松地在钱包之间导出和导入密钥;这意味着使用一些确定性方案privkey_for_dapp=hash(master_key+dapp_id)。但问题是dapp_id？对于多合同dapps该怎么用？

（2）Dapp交互：最常见的办法是在另一个dapp中使用ERC20令牌。但这样做的工作流程是什么？例如在Uniswap上使用KNC，首先将KNC从用户的“Kyber帐户”转移到“Uniswap帐户”，然后在Uniswap执行操作。从用户体验的角度来看，用户会认为这是执行一步操作，在dapps的用户体验中需要用户连续进行三次操作才能做到目标操作真的很糟糕。

Boris Mann：

“我们可以鼓励开发易使用且完全去中心化（完全无服务器）的Mixers，以保护持有少量ETH的账户隐私，如果用户想将Gas费付款发送到另一个帐户，不需要两个账户链上的关联验证（例如基于ringig或zk-snark的）。”

这似乎是可行的首要任务。关于Whisper等的第二部分似乎有很多不足。如果我们得到这样的Mixers，可以先让用户实际生成多个帐户而不是立即关联，仍然依赖于用户的OPSEC，简单的dApp使用是一个好开始。

在用户体验方面，主要是一个中间件和最佳实践问题。我们可以帮助钱包/web3开发者成功地使每个dapp更容易设置/生成帐户吗？

我们可以使用URL或IPFS哈希作为dapp标识符吗？（可以考虑中间件）-或者正如你所说的dapp合同地址。

我认为从多个帐户和多个密钥开始可能并不理想，但我们用于保护/生成密钥的所有单一帐户解决方案仍然有效。

vbuterin：

默认情况下，对于ZXZE的所有内容都非常好，但它仍然很遥远，而不是技术上容易做到的事情。我在这里提出的是一些还未解决的建议，它可以减少用户活动直接相互关联的程度。虽然无法完全解决隐私问题，但是一个非常显着的改进。

“这似乎是一项可行的首要任务。关于Whisper等的第二部分似乎有很多漏洞。”

没错，但是开发“通过支付Gas达到去中心化匿名”的Mixers需要layer2协议用于交易以外的事情（除非我们想要解决这个问题的方式是基于添加一些有限形式的例如图层抽象...）

AtLeastSignificant：

要明确的是，使用一个帐户的问题，或者在拥有的多个帐户之间进行交易，有效地使其成为单个“个人资料”，可以更轻松地以有意义的方式识别人员。

例如，我可以查看获取ETH/令牌的地址，最终完成信息交换。交换有助于识别分叉式网络的钓鱼潜在攻击媒介，也揭示了一些地理信息。这些事务发生的时间也有助于缩小区域设置。

我可以看到正在使用的Dapps，这有助于指出这些用户可以在社交媒体上访问的位置。甚至可以分析他们使用的钱包方案，他们是否有冷钱包地址或使用MetaMask或其他热钱包等，这有助于了解攻击用户的难度。

在明显的X发送Y到Z之上有大量的元信息。当你将它添加到空投或赠品等许多人将他们的社交媒体身份与他们的地址相关联的事情时，这个问题会变得更加严重。任何可用于将地址与任何其他可识别信息联系起来，都可以使得这种区块链元信息对攻击者来说非常强大。还有人担心大数据挖掘操作可能不是那么遥远，将深度学习算法应用于所有环节，也会让问题变得更加严重。

混合器/隐私层/Dapp支持的问题在于便于开发和足够信任。如果可能的话，我宁愿看到基础协议中内置的隐私，也不是用户的选择。

burrrata：

我同意隐私是唯一真正的解决方案。如果这是一个选择，那么总是会有激励来交换信息以进行访问。服务交易数据是当今网络上主要应用程序的默认数据，这是用户习以为常的，因此他们不会质疑它。

此外，如果开发人员或用户需要额外的努力来创建隐私，没有这样经济激励，它最多只是一个开发不方便的游戏理论业务决策。最好是选择隐私而不是就像我们今天看到的2FA和密码管理器一样，它们是例外，而不是常态。

可以通过IP等帮助进行地理分析的想法可能是蒲公英路由。根据我的理解，在将tx广播到网络之前，它会在对等体之间传播一定数量的tx。通过这种方式，无法分辨tx的来源，但可以看到哪个地址正在发送给谁。

Jochem Brouwer：

这是一个可以在某些情况下应用CREATE2的想法。我们使用的事实是我们可以预先计算CREATE2地址，这意味着我们可以在这里转移令牌，它适用于ERC20令牌，可以尝试在单个TX中与合约进行半互动。

该想法是用户将令牌转移到通过将用户的地址与calldata预先计算的地址。知道这些值证明用户想要“存储”的是预先计算的地址的余额以及密码数据。因此，种子数据CREATE2是用户和calldata的地址。

现在让我们说我们有一个无用的虚拟合同来显示用法。用户A想要将令牌转移到B但不是直接转移到B.这是不用SplitContract的，我们现在可以计算CREATE2A应该存放的地址：salt只是A和B的地址，init_code只是将CREATE2地址上的所有令牌传送给SplitContract。当我们在A地址创建合同时，SplitContract因此知道了种子，所以此时也知道地址B。我们可以计算转移了多少令牌，现在将所有令牌转移到B。

例如一个DDEX：在这里你可以通过将令牌转移到某个地址来匹配某些人的交易。用户现在需要做的唯一事情是广播这些令牌已存入，并且该订单的制造商现在可以接受它们，或者用户包括其他人的费用“挖掘”这个令牌链上给出他们鼓励支付的gas。（此费用因此在calldata/salt中）。如果订单不匹配，则用户可以通过简单地提供所提供的calldata并显示用户想要取消订单（以防止合同再次尝试匹配订单）来链接以撤回其令牌。（或者订单已经完成）。

请注意，在DDEX案例中，合约也只是创建和自我结束，因此不会存放任何代码，从而产生少量的额外gas。实现方面唯一的缺点是无法自我修改，再次创建它，并在同一个tx中再次修改它，这意味着如果你因为某些原因想要回调这个合同，你必须存入代码。在考虑这个时，我也可以看到为什么在调用帧之间有某种内存会很好，这是EIP 1283讨论中想要完成的。

Jamie Pitts：

我也对这种适用于“帐户合同”的方式感兴趣，“帐户合同”本质上是针对单个人的多重行为，但在不同设备上使用私钥+恢复机制。帐户合同使以太坊更有用，并有助于防止失去对某人最重要的dapps的访问权限，但是由于鼓励用户只有一个单点进入许多dapps，这使得隐私更具挑战性。