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.
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.
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:
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.
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.
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.
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:
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.
The contract to handle the Sunrise Auction has been prototyped and is nearly final. Again, this contract may still undergo some changes.
The contract to handle registrations after the Sunrise Auction has not yet been completed. We hope to complete this next week.
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.
At the request of a reader, we've enabled an RSS for the development blog, available at https://avvy.domains/blog/feed/.
