This post is part of a larger effort to discuss potential features to be included in an upgraded version of BNS. Please see the megathread for more information.
Proposal: implement a change to the two-step registration process to reduce the potential for front-running expirations
The current BNS contract uses a “commit-reveal” scheme, where a user preorders and then registers their name in two steps. The desired outcome of this is to reduce the potential for front-running a registration. The current implementation does not prevent front-running, and it only adds additional complexity and cost to registrations.
To understand how front-running can occur, it’s important to understand that anyone can register a name in just one transaction by using a custom contract that calls name-preorder and name-register in a single transaction. Various apps take advantage of this to make registration more easy for users.
To illustrate the potential for front-running in the current implementation, imagine this example:
- Alice wants to register
alice.btc - Alice makes a first transaction, calling
name-preorder. Alice’s desired name is not known to the public yet - Next, Alice broadcasts a contract call to
name-register, which includes the “plain text” name they wish to register - An attacker sees this
name-registertransaction in the mempool, and broadcasts a custom “preorder and register” transaction with a higher fee - The attacker’s single transaction is confirmed first, resulting in the attacker owning
alice.btc
Proposed solution: required time delay between preoder and registration
To prevent this scenario, a new version of BNS can require a minimum period of time (such as 1 block) between a pre-order and registration transaction. By implementing a required time delay, the previously described attack cannot be executed.
Determining the “best” time delay must balance the need for a good user experience, while still making it difficult to front-run. A delay that is too small (such as 10 seconds) is not sufficient, because the user’s transaction cannot be confidently confirmed that quickly. An attacker can spend a higher fee to easily confirm two transactions before the user’s final transaction is confirmed.
The ENS protocol uses a similar scheme, and their required delay is 1 minute. This value, which is roughly 4 blocks on Ethereum, is sufficient that a user at risk of being front-run can spend enough on fees to have their transaction confirmed within that amount of time.
This scheme doesn’t completely prevent front-running, because there is no guarantee that a user’s transaction can be confirmed in a specific amount of time. The goal is to create a design that balances both usability and safety.
Allowing single-transaction registrations
As described earlier, many apps have begun providing registration experiences that can be completed in a single transaction. For most users, this is a desirable result, and they are likely not at risk of being front-run.
To maintain this capability while still providing safety, a new BNS contract can implement a single-transaction registration flow that prevents transfers of the name for a minimum amount of time. This transfer restriction would prevent attackers from using this method to front-run registrations.
As an example, assume a “preorder delay” of 1 minute, and a “transfer delay” for single-transaction registrations of 20 minutes:
- Alice preorders
alice.btcand their transaction confirms - Alice broadcasts their
name-registertransaction - An attacker sees this transaction in the mempool, and front-runs the registration by broadcasting a “single transaction”
- The attacker’s transaction is confirmed first, but they cannot transfer the name yet
- Soon after, Alice’s transaction is confirmed
- The BNS contract sees that Alice’s preorder transaction came before the attacker’s registration, and transfers the ownership of the name to Alice
Downsides of this approach
This proposal should reduce the potential for front-running, but it cannot completely prevent it. In addition, it adds complexity and the potential for confusion of users.
If this proposal were to be rejected, it may be the right approach to remove the name-preorder step entirely. Such a change would reduce in easier and cheaper registration fees, while still having the same potential for attacks as the current implementation.