ENS Privacy - Research Document

--- tags: ens --- # ENS Privacy - Research Document ENS privacy dilemma is an interesting one. On one hand we want to have a public resolver, which can be used by other services like wallet providers to be able to resolve a name to an address seamlessly and have the user transfer a token to the receiver without any intervention. But on the other hand we want to keep the actual spending of the receiver private to not allow an on chain analysis of financial transactions of a user. (Either private or have a de-linking between receiving and spending address). ## Ideas ### 1. Using on-chain Mixer When a user registers an ENS name, all mappings points to a single contract address. This contract essentially will transfer the received tokens to a mixer contract. For e.g. Tornado Cash. For keeping a track of which token belongs to whom, during the registration of ENS, a mapping will be stored for the name and the receiving address. This mapping will then be used to generate a note stating that the given token belongs to whoever owns this note. For withdrawal, anyone possessing the note can withdraw to an address of their given choice from the mixer. What we are essentially proposing in this idea is a bridge from the tokens received on ENS and a direct deposit of that in the mixer. **Issues**: - How will the note be stored and transferred? When Alice transfers some X token to Bob, how is Bob supposed to get the note in case of this async deposit? In the current version of Tornado Cash, when a user deposits ETH, they receive a note which they can redeem to withdraw from other account. - Because the withdrawals will be on-chain, EACH receive transaction will cost significant gas because a proof verification will have to be done on-chain. A user would rather have a public address associated with ENS and receive all their tokens there and when they want to de-link, use the mixer proactively to save up on the gas cost. ### 2. Changing the ENS mappings We cannot have a private mapping of ENS names to an address as this basically destroys the purpose of ENS. We DO want to have a visible public address associated with a name. Even if we frequently update the address, for example, after every time a user receives a token, they can update it to some other address. But this does not solve anything. Any decent on-chain analysis can easily figure out and create a map of addresses associated with an name. ### 3. Using stealth addresses (Umbra) For the purpose of having a de-linked receiving and spending address on chain, [Umbra Protocol](https://github.com/ScopeLift/umbra-protocol) does a great job. Read docs on how the Umbra Protocol works. Few caveats: - Both the sender and the receiver needs to use the protocol to be able to send and receive the funds. - The scaling issue of requiring to scan all *Announcement* events can be detrimental to the UX. This also means the work needs to be delegated to a third-party provider willing to scan all the events and return relevant ones. This could mean that the 3rd party would now be able to know which addresses correspond to a given user. This can be mitigated if the protocol implements "view tags". More [info](https://github.com/ScopeLift/umbra-protocol/issues/377). - Sender and receiver will always know the new stealth address associated with the transfer. - Integrating this into a wallet can be performance heavy. A wallet would constantly need to monitor all the *Announcement* events to know the stealth addresses associated with the current private key. I think in general the issue with stealth address is: - Keep a large list of addresses that the senders have created to send it to you and corresponding private keys. If wallets decide to integrate this, they would have to constantly monitor "some sort of" activities on chain. In case of Umbra, that is the emitted events. - Spending that by combining might already reduce the privacy set. This part would be pretty tricky for the users especially for ERC20 tokens. Might work for ERC721. ### 4. Using Aztec Connect as L2 for ENS Primary idea: Directly deposit the ETH from L1 into the Aztec connect's bridge. From there the receiver can then claim them and use it either internally within Aztec network or withdraw to another account from the bridge to a fresh address. Funds can be directly sent to the resolver address and the resolver forwards it to the bridge contract invoking correct Aztec address set during the registration. The Ethereum address used for ENS and Aztec should be the same. We chose this approach, specification for which can be found [here](https://hackmd.io/@cilOhZOYSdepMrS71Goxqg/BkedGj7Cq). ## Papers [1] Analysis of privacy preserving techniques for DNS: https://www.jstage.jst.go.jp/article/transinf/E93.D/5/E93.D_5_1031/_pdf/-char/en -> discusses about transport layer privacy, not relevant to us. Add noise in query fetching i.e. submit queries for n domains with n-1 to be just noise.