Docs Blog Contact
Avvy
The Avalanche Name Service

Dec. 10, 2021 Development Update

December 10th, 2021

This week was focused on smart contract development. We anticipate smart contracts being completed next week; afterwards we will be proceeding to development of the UI.

If you missed last week's update, we covered constraints enforced on name registrations via zero-knowledge proofs. This week, those constraints have been integrated into the existing smart contracts. An update on smart contract development is covered below.

 

Hashing Domain Names

We have a semi-final proposal for the name hashing algorithm. This algorithm is used to generate the unique ID for a given name. For more details on why we hash domain names, read about Privacy Mechanisms for Name Registrations.

Preparation for Poseidon

First, let's define the algorithm for converting an ASCII string into an input signals for the Poseidon hash algorithm. Split the string into chunks of 31 characters. Each 31 character chunk is prepared into a single integer for input into Poseidon. DNS labels have a maximum length of 63 bytes; we limit our label length to 62 bytes, or a maximum of two 31 character chunks.

For each 31-character ASCII chunk:

  1. Convert the chunk to its integer representation
  2. If the chunk is less than 31 characters in length, pad the end of the string with 0's until it has a length of 31 characters
  3. Convert each of the 31 integers into an 8-bit binary string
  4. Join all 8-bit binary string together into one 248-bit binary string
  5. Convert the joined binary string into an integer

The 31 character constraint is related to the circomlib implementation of Poseidon. For details on conversion between integers and binary strings, see the Num2Bits and Bits2Num functions in circomlib.

Generation of the unique ID

Drawing inspiration from the NameHash algorithm, we propose a recursive algorithm. For a given domain name consisting of n labels, we propose n rounds of the Poseidon hash. Each round accepts three input parameters: (1) the output from the previous round; (2) the first 31-character ASCII chunk of the label, prepared for Poseidon; (3) the second 31-character ASCII chunk of the label, prepared for Poseidon.

 

Smart Contract Development

Below we'll present an overview of the status of all smart contracts in the system. Read about the Core Architecture of the system for more details on the purposes of each contract.

Name Constraints & Blocklist

In the previous update we discussed compliance with ICANN's Spec 5 Schedule of Reserved Names, which requires blocking registration of some 9,000 names. We attempted to implement this blocklist in our circom circuits but the result was a poor user experience.

As an alternative solution, we have implemented a smart-contract blocklist. This will be used for blocking registration of names in a blocklist at the smart-contract level, on a per-namespace basis. 

We have completed the implementation of the Name Constraints contract for the .avax namespace, which does the following:

  1. Accepts a hashed name & a zero-knowledge proof.
  2. Checks the blocklist for a match on the hashed name - if the name is in the blocklist then it is not available for registration.
  3. Confirms that the proof was computed for the hashed name.
  4. Verifies the proof (see last week's updates for details on assertions made by the proof).

Domain & Namespace

The Domain & Namespace contracts are nearly final, however they may still undergo some changes. For more details on the purposes of these contracts, see the Core Architecture document.

Auction Agent

The contract to handle the Sunrise Auction has been prototyped and is nearly final. Again, this contract may still undergo some changes.

Leasing Agent

The contract to handle registrations after the Sunrise Auction has not yet been completed. We hope to complete this next week.

Pricing Oracle

The Pricing Oracle currently returns a fixed price for all domains based on Chainlink price feeds. We hope to augment this contract to support a pricing curve dependent on domain name length. The pricing curve will require an additional Circom circuit to make assertions on the length of a domain name.

Since the domain name length will be publicly known, it will weaken the privacy provided by the hashing algorithm. For instance, if an attacker knows that a name consists of 3 characters, they can brute-force all possibilities in a reasonable amount of time, discovering the preimage of the name. For this reason, the pricing curve will only be imposed on shorter names, while all other names will have a fixed price.

 

Blog RSS Feed

At the request of a reader, we've enabled an RSS for the development blog, available at https://avvy.domains/blog/feed/.