V神最新技术探讨 以太坊如何解决隐私漏洞？

2019年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的来源，但可以看到哪个地址正在发送给谁。

（https://github.com/mimblewimble/grin/blob/master/doc/dandelion/dandelion.md 实现的danelion路由将有助于网络分析，但不是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，这使得隐私更具挑战性。

英文原始记录如下：

Vitalik：

Right now, Ethereum privacy is quite lacking. There are two reasons why. First, all of your activity is by default done through a single account, so it is all linkable on-chain. Second, and more insidiously, even if you have multiple accounts that you split your activity between (ideally, the default would be to use a different account for each application), the fact that you need to transfer ETH between accounts to pay for gas on all of them is itself a privacy leak.

This is a situation that could use improvement. Two areas come to mind.

Mixers

We can encourage the development of easy-to-use, and importantly decentralized (ie. not just “trustless”, completely serverless) mixers targeting privacy-preserving transfer of small amounts of ETH, so if you want to send gas payment to another account you can do so without linking the two.

Note that here, one major challenge with (eg. ringsig or zk snark based) smart contract mixers is that if you want to send funds from A to B, B still needs to have ETH to pay gas to submit the proof to receive their funds, and sending that gas would be a privacy leak; this can be solved with a layer-2 protocol where a user can broadcast their proof (including a commitment to what address they want to receive to and what fee they are willing to pay) over something like Whisper, and a specialized set of nodes could accept these proofs, include them into a transaction and pay for the gas, and collect the fee from the recipient. But this protocol needs to be specced out, standardized and implemented…

UX

If we make a default that for every dapp, a user uses a separate account, we have to overcome a few challenges:

Address generation: It would be nice to keep wallet software stateless, so users can easily export and import their keys between wallets; this implies using some deterministic scheme like privkey_for_dapp = hash(master_key + dapp_id). But then what is the dapp_id? How would that work for multi-contract dapps?

Dapp interaction: The most common category here is using ERC20 tokens inside another dapp. What is the workflow by which they would do that? To use KNC on Uniswap, would you first transfer KNC from their “Kyber account” to your “Uniswap account” and then do whatever you wanted to do with Uniswap? Something else? Ideally from a UX point of view, it would still feel like the user makes one operation; the UX of dapps that requires users to sign three transactions in a row to do something honestly really sucks.

Have people here thought about these issues more deeply?

Boris Mann：

“mixers targeting privacy-preserving transfer of small amounts of ETH, so if you want to send gas payment to another account you can do so without linking the two.”

This seems like a doable first task. The second part about Whisper etc. etc. seems like there are a lot of rabbit holes to go down. If we get these simple mixers, one can start by having users actually generate multiple accounts and not immediately link them. Still relies on OPSEC of the user, but a good start for simple dApp usage.

On the UX front, this is mainly a middleware and best practices issue. Can we help out wallets / web3 providers succeed at making this easier to set / generate accounts per dapp?

Do we use URL or IPFS hash as dapp identifiers? (think middleware) – or, of course, as you say, the contract address of the dapp.

I think starting with multiple accounts and multiple keys may not be ideal, but all of our single account solutions for securing / generating keys still work.

Vitalik：

Privacy by default for everything a la ZEXE would be really nice, but it’s still far away, and not something that could be easily done technologically. What I’m proposing here is some low hanging fruit that can reduce the extent to which users’ activities are all immediately linked to each other. It’s nowhere close to total privacy, but it’s a very significant improvement.

True, but making a mixer that doesn’t have the “deanonymize yourself by paying for gas” issue requires a layer 2 messaging protocol for things other than transactions (unless the way we want to solve this is by adding some limited form of base-layer abstraction…)

At Least Significant：

To be clear, the issue with using one account - or transacting between multiple accounts you own, effectively making it a single “profile” - makes it easier to identify people in meaningful ways.

For example, I can look at things like where addresses are getting their ETH/tokens from, which leads to eventually to an exchange. Exchanges help identify potential attack vectors for spear phishing, but it also reveals some geographic information. The times that these transactions occur also helps to narrow locale.

I can see what Dapps an entity is using, which helps point me towards where these users may be reachable on social media.

You can even profile what kind of wallet scheme their using. Whether they have a cold storage address, are just using MetaMask or some other hot wallet, etc. This helps to know how difficult it would be to attack the user.

There’s a ton of meta information on top of the obvious X sent Y to Z.

This problem becomes exponentially worse when you add it to things like airdrops or giveaways where many people are associating their social media identity with their address. Anything that can be used to tie an address down to any other identifiable information makes this blockchain meta-information very powerful to attackers.

There’s also the concern for big data mining operations / government conspiracies that may not be so far fetched that are applying deep learning algorithms to all of this to pain a bigger picture.

The problem with mixers/privacy layers/Dapp support is that they aren’t usually trustless and easy. If possible, I’d rather see privacy built into the base protocol and not be an option for users. They should have to explicitly prove a transaction, not explicitly hide them

Burrrata：

I agree that privacy by default is the only real solution. If it’s a choice, there’s always going to be incentives to trade information for access. Trading data for services is the default for major applications on the web today, and it’s what users are accustomed to, so they won’t even question it. Also, if it takes extra effort for developers or users to create privacy, and there are no economic incentives for doing so, then it’s an just an inconvenience at best and a sub optimal game theoretic business decision at worst. Better to have options for privacy than not, but like we see with 2FA and password managers today, they’re the exception and not the norm.

An idea that could help with geographic analysis via IPs and such might be dandelion routing. From what I understand it routes a tx between peers a certain number of times before having that tx broadcast to the network. This way you can’t tell where a tx originated from, but you would still be able to see which address is sending what to whom.

https://github.com/mimblewimble/grin/blob/master/doc/dandelion/dandelion.md

edit: realized danelion routing would help with network analysis, but not tx analysis.

Jochem Brouwer：

This is an idea for CREATE2 which can be applied in some situations. We use the fact that we can precalculate the CREATE2 address - which means we can transfer tokens here and we can even supply a salt! It is applied to ERC20 tokens where we try to semi-interact with contracts in a single TX.

The idea is that an user transfers tokens to the address which is precalculated by seeding the address of the user together with the calldata. Knowing these values proves that the user wants to “deposit” the value which is currently the balance of the precalculated address together with the calldata. Hence the seeded data in CREATE2 is the address of the user and the calldata.

Now let’s say we have an useless dummy contract to show the usage. An user A wants to transfer tokens to B but not directly. This useless SplitContract is deployed and we can now calculate the CREATE2 address where A should deposit: the salt is simply the address of A and B and the init_code simply transfers all tokens at the CREATE2 address to SplitContract. When we created the contract at the address where A deposited to in the SplitContract we hence knew the seed so at this point we also know address B. We can calculate how many tokens were transferred and now transfer all tokens to B. Note that the CREATE2 contract can be selfdestructed immediately after we transferred tokens (hence yielding extra used gas of about 11k (~32k contract deployment, 22k refund, ~1k execution cost).

This is of course rather stupid but it can be expanded. Think of a DDEX: here you can match someones trade by transferring tokens to a certain address. The only thing the user now needs to do is to broadcast that these tokens are deposited and either the maker of this order can now take them or the user includes a fee for someone else to ““mine”” this token on-chain which gives them incentive to pay for this gas. (This fee is hence in the calldata / salt). If the order is not matched the user can go on-chain to withdraw their tokens by simply providing the supplied calldata and showing that the user wants to cancel the order (to prevent the contract to try to match the order again). (Or the order is fulfilled already).

Notice that in the DDEX cases the contract is also only created and selfdestructed so no code is deposited, yielding a low amount of extra gas. The only downside in the implementation-side is that you can’t selfdestruct, create2 it again, and selfdestruct it again in the same tx which means you have to deposit code if you want to call back into this contract for some reason. When thinking about this I can also see why it would be really nice to have some kind of memory between call frames, something EIP 1283 tries to accomplish.

Jamie Pitts：

I’m interested also in how this applies to “account contracts”, which are essentially multisigs for a single person but with private keys on different devices + a recovery mechanism.

Account contracts make Ethereum more usable and help safeguard against loss of access to someone’s most important dapps, but they make privacy more challenging due to encouraging users to have a single point of entry to many dapps.