Using Aztec(zkMoney) for ENS privacy

Hey everyone!

We, at ChainSafe’s Solutions, integrated Aztec/zkMoney to experiment with providing more privacy for ENS users.

Problem Statement

With an ENS name, it is easy for anyone to see the complete financial history of any associated address. For example, here we can check how Vitalik has spent his assets. And for the ENS names tied to social media profiles, the address is certain to be of the person.

We still want people to be able to publish and use an easily memorable name for their address and at the same time have their spending pattern private. What we essentially want is a de-linking of receiving and spending addresses for a given ENS name.

This should be achievable with no changes to the core Ethereum protocol and minimal changes to the ENS protocol for the solution to be easily adopted.

Our Solution

A cool thing about how ENS is currently implemented is that every user can set their own custom Resolver contract. By default, PublicResolver is used. This can be changed by using Registry contract’s setResolver() method in the ENS app.

While trying to look for best the possible solution to bring privacy to ENS, we stumbled upon Aztec’s contracts. Aztec is a privacy focused zk-rollup. In the main contract, RollupProcessor, there is a publicly accessible method called depositPendingFunds(). Using this method, anyone can deposit ETH/DAI on behalf of anyone else. The other person can, at any time, submit a proof that they own that address and claim those funds. These funds can then be used as private transfers within L2 or can be withdrawn to a fresh account on L1, with no linking to the previous address.

What we did was to implement a custom resolver contract that will redirect the funds sent to an ENS name directly to the Aztec’s RollupProcessor’s depositPendingFunds() method. Users can set their resolver to the custom resolver and claim all the funds in zkMoney’s UI.

No additional UI needs to be developed to start using our resolver. Current versions of ENS and Aztec UI supports this out-of-the-box.

Links & Resources

For more detailed information of the solution, please find all the links below:

We appreciate any feedback and if this is useful for the end users!

We will continue to explore building a polished version of this to make privacy for ENS users even more seamless.

We have already submitted a proposal for this here.

9 Likes

This is really interesting! I love to see work being done to enhance privacy.

Is this method (Aztec) susceptible to possible censorship/sanctioning similar to how OFAC sanctioned Tornado?

3 Likes

I think, technically, any contract interaction is susceptible to censorship, including Aztec.

2 Likes

Interesting work!

My main reservation is around the need for all clients to change how they resolve names in order to support ‘private send’. Can I suggest an alternative approach?

  1. Create a proxy factory that can instantiate a unique proxy contract for each user.
  2. When ETH is sent to the proxy contract, call the deposit function on the Aztec bridge and forward the Ether.
  3. Users can simply use the standard resolver and set their proxy contract as the address the name resolves to.

As long as the wallet does gas estimation for ether sends to contracts (we will need to survey how widespread this is), the send will be able to invoke the smart contract functionality and work seamlessly.

Since ERC20 tokens don’t have fallbacks, it won’t work seamlessly for them - instead, it might require a ‘sweeper’ that identifies proxies with ERC20 balances and calls a function on them to forward them to the bridge.

5 Likes

Great suggestion! It’s totally doable, the gas cost of the deployment can be a discouraging factor when the fees are high. It’s still a better approach than to ask all clients to resolve addresses differently. :raised_hands:

2 Likes

Hey @nick.eth !

Thanks for the feedback, we would love to integrate this feedback into a revised solution. As per my discussions with slobo.eth, I would like to politely propose that ChainSafe be incentivised for this work. We have dedicated valuable engineering resources to building this solution and would really appreciate some recognition. If the community feels this to be necessary, could we please have a discussion about this, Nick? We’d be happy to update the proposal and re-upload it on the form, if you prefer? Let me know :slight_smile:

cc @jagrooot @slobo.eth

1 Like

What does this sentence mean?

Hey @daylon.eth :slight_smile:
What I mean is that we are proposing to be compensated for our efforts relating to this solution and/or the implementation of the proposed changes made by Nick.eth

Bare in mind that whilst ChainSafe values contributing to important communities such as this one, we are also a for-profit company with 120 employees and bills to pay :slight_smile:

We were instructed to release a solution, and should the community feel it is worthy of recognition, then compensation could be considered. I hope that answers your question and clears up any confusion! I’m always available for a call if you like. Have a great day!!

1 Like

@bryant.chainsafe

We are grateful for you building in public like this. That being said, after given this some thought, the Ecosystem Working Group does not believe this warrants a retroactive grant for work performed.

This appears to be quite a ways away from being able to be used by the general community. As important as privacy tech is we generally hold off funding projects this early in their development.

Thanks for letting me know, @slobo.eth. I appreciate you being direct.

Hopefully we can find alternative ways to collaborate in the future.

Cheers,
Bryant.