Blog Contact
Avvy
The Avalanche Name Service

Privacy Mechanisms for Name Registrations

November 25th, 2021

Any information that gets sent into the Avalanche network should be considered public. Users who register a name don't necessarily want that name to be public. We aim to provide optional privacy for name registrations, though that privacy may be compromised to enable some features.

 

Hashing Functions

One-way hashing functions can provide the privacy we desire. We can use a one-way hash like keccak256 to hide the true name that a user wishes to register. Users compute the hash of the name they wish to register off-chain. Any interaction with the chain uses the hash to identify the name, rather than the true name. This prevents the true name from  ever reaching the Avalanche network.

This mechanism works well to provide privacy but we are left with another problem: how can we make assertions about the names that are stored on-chain? For example, what if we want to restrict the character set for the namespace to letters (A-Z), numbers (0-9) and dashes (-)? Without knowing the preimage in our smart contract, we cannot verify whether the name registered complies with our character set constraints.

 

Zero-knowledge Proofs

How can we make assertions about our preimage without knowing it? Zero-knowledge proofs have gained popularity in blockchain communities for solving this problem.

Zero-knowledge proofs can help us prove a fact about a private piece of information to a third party without revealing the private information. Thanks to tools like Circom, developers can implement zero-knowledge proofs in smart contracts with relative ease.

Our final process for preserving privacy without sacrificing name constraints looks like this:

 

The preimage & the hashed name are used to generate a proof on the registrant's device. 

The proof asserts the following:

  • The name is at least 3 characters long
  • The name uses only characters from the allowed character set: letters (A-Z), numbers (0-9) and dashes (-)
  • The full name, which must consist of 62 characters, is properly terminated (after the first NUL all remaining characters are NUL)
  • In order to respect RFC-3492 (Internationalized Domain Names), we'll ensure that any domains starting with xn-- are valid Punycode.

 

Poseidon Hash

Unfortunately, well-known hashing functions like sha256 do not work well with zero-knowledge proofs. The user creating the proof (i.e. in our case, the name registrant) would need to download a file larger than 10GB in order to make a proof for sha256. This is a terrible user experience.

The Poseidon Hash is optimized for zero-knowledge proofs. In comparison to sha256, a user creating a proof of the preimage of a Poseidon hash has to download a file that is only 8MB. This is a reasonable user experience.

 

Threat Modeling

We've managed to achieve our privacy goals while not sacrificing on system constraints nor user experience. That's great!

What have we sacrificed to achieve these goals?

Any cryptographic technique bears the risk of being broken. This is a reality that continues forever. An encryption scheme that has stayed strong for 200 years can be broken by new technology or by a mathematical breakthrough.

In our case, we've made two notable decisions:

  1. To rely on zero-knowledge proofs to enforce our system constraints
  2. To use a new hashing algorithm, which makes the user-experience more reasonable

Failure of zero-knowledge proofs

If the zero-knowledge proofs fail, the consequences are that our system will not enforce our naming constraints, leading to undesired names being registered on the system. In this scenario, we have two mitigation strategies. The first involves using a blocklist when reading data from the chain. The undesired names still exist on-chain, but they are not usable by standard tooling. This is the approach some other naming systems take.

The second mitigation strategy is to utilize revocation. This strategy maintains the desired constraints but requires exercising power over the system. Revocation is a sensitive concept that requires appropriate checks and balances.

Failure of Poseidon hash

If the Poseidon hash fails, the true names that have been registered by users will be revealed, eliminating all privacy benefit. This leaves us with a system that has no privacy, but respects system constraints. 

In this scenario, all previously registered names will be compromised. It may be possible to migrate to a new hashing function to preserve the privacy of future users.

We expect that many users will voluntarily compromise their name registration privacy to enable features such as reverse resolution. Those who have chosen not to enable reverse resolution will be the ones who lose if this event occurs. 

Users weighing the risk can consider that despite it's young age, the Poseidon hash is currently securing millions of dollars on various blockchains.