Improving gas-efficiency of DNS domain claims with optimistic verification

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.

1 Like

How much deposit size do you have in mind?

That’s a bit of an open question; I think it would have to be at least 5 figures.

I really like the idea of fraud proofs for RSA.

github.com/thehubbleproject/RedditHubble may be overkill for htis project. But its a way to make programable rollups. Very early days at the moment. But sharing in case its interesting.

I think it would also be valuable to explore a fully stateless system for this which will reduce the cost alot more. You already have the fraud proof. Adding the stateless ness and rollbacks would allow you to remove

Perhaps https://ethresear.ch/t/lazy-launch-deploy-early-with-scaleability-then-add-smart-contract-interoperability-later/7805/2 is also interesting ?

  • 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).

You could pause the system for a time to allow fraud proofs before allowing change resolver actions to be processed.

We’d like to explore more level 2 possibilities in future, but anything like this will require substantial changes to clients - so it would be a much larger project.

That’s an option - and it means the deposits can be much smaller - but it also slows everything down, and requires a second transaction for each update.

We can have the claimer apply the second transaction for a batch of claims so users don’t need second tx. Would this cost alot of gas as they need to interact wtih storage during this second tx ?

Lets do this for a subdomain that has alot of users that way we don’t need to change the core :slight_smile:

Nick, have we started implement this as a temp solution? With the high gas, it makes renew the existing name almost impossible. Hope we can have a solution in near future. There are a lot of short names expire very soon. Thanks!

His proposal is specific to DNS integration (eg: .xyz) which does not have the notion of renewal. This solution is to mostly decrease computing intensive aspect of proving the ownership of DNS record, so less likely to be effective for normal name renewal which will cost the same storage cost as Nick stated.