This week has been mainly dedicated to development of Circom circuits for enforcing system constraints. The development is more-or-less complete and we'll now shift to integrating these circuits into the main contracts. Constraints that are enforced include:
The final compiled circuits require users to download around 25MB of files to generate a proof asserting the name they wish to register complies with the system constraints. This is a one-time download which can be used for multiple proofs. We consider this to be a reasonable user experience.
For more information, read about Privacy Mechanisms for Name Registrations.
Notably, we will be excluding Internationalized Domain Names (IDN) from the initial launch process. To comply with ICANN policies, names prefixed with xn-- (indicating an IDN) must contain valid Punycode. Implementation of constraints enforcing valid Punycode could push back the launch date. Instead, we've created constraints to match strings beginning with xn-- and will block those registrations initially. IDNs will be launched at a later date.
To comply with ICANN's Spec 5 Schedule of Reserved Names, we're required to block registrations for a provided list of more than 9,000 names. We attempted to enforce this within our constraints circuit by hashing the blocked names & storing only their integer representation. Our best implementation to check set membership still bloated the circuit - the end user would be required to download a 100MB file just to assert the name they desire to register does not belong to the given blocklist. We consider this to be an unreasonable user experience and will instead seek to implement the blocklist at the smart-contract level.
There has been lots of buzz on Twitter recently about arbitrage bots on Avalanche. After discussion in the #research channel of the Avalanche Discord, we've decided it is important to build in protections against frontrunning. Our proposed mitigations rely on the following assumption: if a user issues two transactions t1 and t2, separated by enough time that they are included in separate blocks b1 and b2 respectively, then it is improbable that the same validator would be chosen as the block proposer for both b1 and b2. We are further investigating the probability of such a scenario occurring.
During the Sunrise Auction, users place sealed bids on domains. These bids are hashed with a salt, making it infeasible for an attacker to determine which domain is being bid on. In the event that two bids of identical amounts are received for a given domain, the earlier bid will be declared the winner. In theory, it is possible for the block proposer to (1) witness a bid transaction which should be in the next proposed block; (2) submit a duplicate bid transaction, but with an earlier timestamp; (3) have a winning bid if there are no other bidders. This would result in the block proposer winning the auction for that domain if they are able to determine the preimage of the bid & reveal it.
Fortunately, because of the salt, it's unlikely that the frontrunner would be able to determine the preimage. They would need to be selected as the block proposer for both the sealed bid & for the bid reveal. Without the preimage, the frontrunner cannot reveal the bid, which disqualifies it from the auction.
The Domain Name Lifecycle, which covers the lifecycle after the Sunrise Auction, has multiple scenarios where users can register domains. The risk scenario occurs when a user attempts to register a domain that is currently not registered. Of course, the block proposer can observe the transaction, submit a duplicate transaction with an earlier timestamp, and “register” the domain that the user was attempting to register. In this case, the user's registration attempt would be a failed transaction, because the block-proposer had already registered the domain.
The mitigation is similar to the one previously proposed. Registrations occur in two steps: (1) the user hashes their registration request with a salt and submits the hashed request; (2) the user waits for the transaction to be accepted; (3) the user reveals their registration request (matching it to their sealed bid). In order to successfully front-run these transactions, the frontrunner would need to be the block proposer in both the initial block and the reveal block.
Other phases during the Domain Name Lifecycle are already covered: Grace-period registrations & lease extensions require authentication of the registrant, and a frontrunner cannot sign on behalf of the registrant. Expired Domain Auctions can be handled similarly to the Sunrise Auction.
