With the current high gas prices, we’ve been thinking about ways to reduce the gas costs of common operations in ENS. Most ENS gas costs come down to the cost of writing data to storage, but there is one area where computation dominates: claiming DNS names. Currently this is only rolled out for .xyz, but deployment to more TLDs is a short-term goal, and we’d like to make it as efficient as possible.
Currently our plan is to roll out the current system, with a few tweaks and improvements, then work on an improved system that will be much more gas efficient, later. I’d like to outline the proposed improvement here, for community input.
The gas costs of claiming a DNS name on ENS (eg, claiming foo.xyz so you can use it as an ENS name) are dominated by the cost of signature verification. Currently, each RSA signature costs in the region of 100k gas to verify, while if we roll out our P256 support, it will cost over 1 million gas per signature, due to the fact that there’s no precompile - we have to do it all in userspace. With a typical claim requiring one or two signature verifications, the cost of claiming your DNS domain can be in the region of 100k to 2M gas (~$4 to $40 at current prices) on top of any non-signature-verification overhead.
What I’m proposing to do is to introduce an optimistic-rollup type system, which functions as follows:
- A DNS registrar contract allows anyone to register as a validator by providing a (large) deposit.
- Anyone can call a registered validator, asking it to sign a set of DNS records for the registrar. The validator checks the signatures on the record set, and if they are valid, produces a signature.
- The user can then call a method that updates the ENS registry using data from DNS. This would function similarly to the current DNSSEC integration, with the crucial difference that the signatures on the submitted records are not validated, only logged to the chain. Instead, the method checks that the provided validator signature is valid and corresponds to a bonded validator; this signature verification is significantly cheaper than the DNSSEC signature validation, and only one is required per record set.
- Anyone can call a method on the registrar, providing the data for a previously asserted signature, making the claim that it’s invalid. When that happens, the contract does verify the signature, and if it is invalid, slashes the validator’s deposit - sending some to the caller, and burning the remainder. It would also reset the record that was set back to its previous value.
The ENS team would naturally host a bonded validator of our own, as well as a process to check signatures in logs from the registrar and automatically submit disputes if invalid signatures are found.
This system has a number of benefits:
- Claiming a DNS name becomes substantially cheaper, by as much as 2 orders of magnitude in some cases.
- Updates are still instantaneous - there’s no waiting/dispute period.
- Only a single transaction is required, which can be submitted by the user - no need to have the validator be capable of submitting transactions on the user’s behalf.
- The “attack cost” can be easily characterised based on the size of the validators’ deposit.
But also some drawbacks:
- A bonded validator can, at the cost of their deposit, submit false records to the ENS registry. These would be restricted to DNSSEC-enabled suffixes (Eg, they couldn’t mess with .eth).
- Although the dispute process reverts the change made by the malicious validator, it can’t revert any changes that were made as a result of that (for example, a malicious validator could claim a name, and then create subdomains or change resolvers before the dispute transaction is processed).
- The penalty for one invalid signature is the same as the penalty for many, so a malicious validator is incentivised to submit many invalid transactions at once.
- There’s little incentive for others to operator validators, as doing so locks up a large amount of capital. Validators could be paid a fee for the service they offer, but that fee would offset the gas savings from using this system in the first place.
I’d be interested to hear what the community thinks of the idea, and the tradeoffs it embodies, as well as any refinements anyone has to offer.
