We are excited to announce that smart contracts are in a near final state & we will be proceeding on to development of the UI.
Technical updates are presented below. If you're not interested in the technical details, scroll past to get a sneak peak at some initial UI designs.
If you missed last week's update, we covered the hashing mechanism, as well as the previous state of smart contracts.
The following updates assume general knowledge of Avvy's Core Architecture and Name Lifecycle.
After the initial auction is complete, users can register domains on-demand. The Leasing Agent handles these on-demand registrations as well as renewals. The Leasing Agent was completed this week.
To register a name, users are required to generate two zero-knowledge proofs. The first proof is related to the system constraints: do we allow this name to be registered? The second proof is related to the Pricing Oracle, described below.
The Leasing Agent supports bulk operations for registrations & renewals. This will allow users to perform multiple actions in a single transaction, which will be useful for those who wish to maintain registrations for more than one domain.
The pricing oracle is responsible for determining the price of a name. Our pricing curve is based on name length. The pricing curve itself is not finalized, though it is fairly certain that names of length 3, 4, and possibly 5 will have higher prices than other names.
Since names are presented as hashes, and not preimages, we cannot assess the features of the preimage. Users generate a proof asserting that the length of their name is at least n characters long. We use this proof to determine which pricing category the name fits into.
For example, a user registering dogs.avax is registering a name with 4-characters. They will be unable to generate a proof that shows their name as being at least 5-characters long, so it is impossible for them to be in that price class. They can generate a proof that says their name is at least 3-characters long if they want, but this would put them in a more expensive price class. The correct action is to generate a proof that asserts their name is at least 4-characters long (and this is what the webapp will do automatically).
Privacy Implications of Proofs
The proofs make statements about the length of the names being registered, which reduces the security of the hash. If we observe a proof that a name is at least 3-characters long, we can reasonably assume that the name is exactly 3-characters long (recall that it could be more, the user would just pay an unnecessary premium). Knowing the length of the space reduces the number of possible combinations of characters, making it easier for an attacker to brute-force the space & discover the preimage.
For this reason, names that fit into distinct pricing categories should be considered less secure by default. For many users, this privacy is not important (e.g. anyone who publicly shares their domain name will not be effected).
Users that desire privacy should register longer length names, which are:
We've updated the Auction contracts to support bulk operations, making it simpler and cheaper (gas fees) for users who wish to bid on multiple domains. The following operations will be able to be completed in a single transaction:
As mentioned in the December 3rd update, we will be excluding Internationalized Domain Names from the initial launch (to be released at a later date). This week we updated the constraints circuit to disable registration of any names with a dash in the third and fourth position of a name (e.g. the standard “xn--” prefix).
We've updated the Namespace Contract to use the hashing mechanism described in our December 10th update to generate unique* IDs for namespaces. This method of ID generation is preferable to storing incremental IDs in the contract itself.
* The chance of hash collisions using the hashing algorithm proposed should be extremely low. In the case of Namespaces, the finite number of namespaces that will not result in a collision. Our initial investigation implied that there will also be zero probability of collisions for Name IDs. We intend to continue investigating.
Next week we'll be proceeding with development of the user-interface for the application. Focus will be on creating a simple mobile-first UI that can easily support dark mode.
Join us on social media to keep up with news & development.
