Updates to ENS Controller. Should we do Bulk Commits/reveals?

[AvsA]

On the latest ENS Small Grants round, one of the winner was Alexnetto.eth work building a referral feature for the RegistrarController. The basic referral is implemented and during the process he even found some errors on the tests in the current ENS contracts GitHub. The goal is to enable third party wallet integrations or name registry apps that have a business model built in, thanks to the referral fees (a percent which is reduced from the fee and controlled by the DAO).

You can read more about that progress here.

I’d like to talk about the next steps in the improvements we are building.

You can read a more detailed specification of the next features here, but the main two goals are to make commits with payments and bulk commits. The latter is the one that might be more controversial.

Commits With Payments would mean that you would send the ether for paying your domain on the first transaction (commit) and not the second (reveal). This small change, together with referral fees and an optional tip, could mean that the registration app could execute the second transaction.

Meaning the process would change from make one transaction, wait for confirmation, wait another minute, make reveal transaction, wait again into Make one transaction and wait. If you come back in a few minutes and the process hasn’t been finished you could do the reveal yourself and save the tip. This adds the danger that your registry app might frontrun you, but (1) that can happen anyway with the current model as they can simply log your searches and (2) the old process will still be available if you don’t trust your frontend.

Bulk Commits are the more controversial feature that I think would be nice sharing here. This is mostly a gas saving feature: a lot of the cost of transactions is storing data, so this would enable a registry app to make multiple commits into one (magic of merkle trees).

This feature should also allow the bulk registration of lots of new names at once, which can have more controversial effects.

• More efficient registrars: the change of the commit+payment already allows the registration flow to become “user does one transaction then waits”. In this case, the user might not even need to do the first commit transaction, as a registrar app might be built in a way that they await for N names to be requested before doing them all at once in bulk. This could lead to cheaper still registrations (althought it concentrates powers on registrars)
• Club impact: New clubs (10k club, 24h club, Flags clubs) would be easier to register all at once, which might be both good as it allows the quick creation of a club, but it can remove the social and competitive aspect of it.
• Domain squatting: A squatter can bulk commit to thousands or tens of thousands of domains names at once. They are limited by the cost of the reveal, and because we expect that a lot of potentially squattable names have already been done so.
• Frontrun danger: a potential frontrunner bot could register all possible 10 letter combinations in a single merkle tree and then use that to frontrun any reveal transaction they see on the network. This would in practice negate the advantadge of a common commit.

I believe these dangers could be alleviated by limiting the size of the merkle tree and the duration of a commitment to 24h max. This would also make the reveal cheaper as the merkle proof needs less roots to prove.

So what the general community thinks? Are merkle tree based commits a good idea? They could enable massive gas savings and more quick registration of names in bulk, but is that something we want?

[nick.eth]

I’m generally in favour; we didn’t design the gas costs of registration as a deliberate barrier, and we shouldn’t retroactively try to make them one. If the end result is too much squatting, the price of name registration can always be increased.

Do you need a merkle tree here? If you require all the names from a single commitment to be registered at once, you can avoid the need for one, simplify the code, and effectively enforce a limit on the size of a batch commitment based on gas used.

[AvsA]

This is a really good point. I’m trying to come up with scenarios in which it’s useful to commit a batch but only reveal a few and most of them are more vector attacks than actually beyter experience.

[lcfr.eth]

Quick Q. What is the process here for modifying the ENS contracts based on small grant votes?

It seems like small grants can be used to bypass an overall DAO vote on core contract changes based on the discussion. (dev has already started implementing contract changes on his end).

While maybe I missed the DAO vote on adding referral fees?

I was under the impression to do any core contract changes the ENS DAO should be voting on these or will that take place after …?

I think small grants should probably put aside protocol changing grants possibly without those being voted on by the DAO as a whole first to see if funding it makes sense for the builders and the DAO at all?

[wolfram]

A small grants vote is not a vote on core DAO operations.

[AvsA]

@lcfr.eth

What is the process here for modifying the ENS contracts based on small grant votes?

Small grants paid for a developer to make GitHub pull request with a feature. For that to be accepted it would still go through a formal governance process (and testing, audits, etc)

Even if a rogue developer skips the formal process, for this to work it needs to be added as a controller and that can only happen through a wide DAO vote.

[lcfr.eth]

That sounds as its like I hoped Just didn’t see it discussed somewhere about the “pipeline” from small grants → protocol changes. Thanks for clearing that up AvsA!

[5pence.eth]

Thanks @AvsA. Awesome write up.
I see your question about using merkle trees, but is this also a temp check for a potential executable proposal? If so, should we recategorize it to the “DAO Wide → Temp Check” category? @Meta-Gov_Stewards

@AvsA

On the latest ENS Small Grants round, one of the winner was Alexnetto.eth work building a referral feature for the RegistrarController. The basic referral is implemented and during the process he even found some errors on the tests in the current ENS contracts GitHub

It’s slightly confusing with the inclusion of this small grants Referral Feature reference. The Referral Feature won a small grant round, but the changed ETHRegisterControllerv2 that alexnetto.eth has designed isn’t implemented in the existing ENS workflow today, and it would require a DAO vote on an executable proposal before it is included. I know you clarified this above, but should that have its own separate temp/check or draft proposal for discussion?

@AvsA

Commits With Payments would mean that you would send the ether for paying your domain on the first transaction (commit) and not the second (reveal).

I was always under the impression that the two payment commit/reveal registration process was designed to protect the registrant from front-running. Would this change mean that we’d be removing that protection from users that register through a 3rd party registrant? I understand they could still use the official ENS site if they don’t trust the other frontend, but new ENS users likely wouldn’t know this.

@AvsA

Bulk Commits are the more controversial feature that I think would be nice sharing here. This is mostly a gas saving feature

The downsides to Bulk Commits that you mentioned make me wonder about the pros/cons of that one as well. We don’t have many ENS end users needing to do Bulk Commits. It seems that would mostly be a way for 3rd party registry apps to save on gas. I’d worry that the 3rd party registrar wouldn’t pass that gas savings on to the registrant. Are there any other benefits to the end users from the Bulk Commits feature that would outweigh the downsides you mentioned (domain squatting, club impact, frontrun, etc.)?

[AvsA]

@5pence.eth

Would this change mean that we’d be removing that protection from users that register through a 3rd party registrant?

There would still be a two step process, what changes is that anyone can execute the reveal transaction. Since there would also be a referral payment (and maybe an optional tip), the registry app has an incentive to make that happen. This isn’t a cost saving, just a UX improvement.

Your correct maybe I should’ve posted this as temp check. I didn’t because there has been a few referral temp checks/discussions.

[5pence.eth]

Thanks AvsA.

I only mention the temp check categorization as a way to get more eyes on it. It’d be awesome to hear thoughts from the other delegates and maybe even our incredible support team.

(I personally have tons of questions, but they’re mainly just protective and probably predictable. )

Again, awesome write up.

[clowes.eth]

Commits with Payments.
Great idea. Nothing to add. It does beg the question as to what the process is/would be for this change/the general upgrades improvements that have been made in the ENS contracts Github repo. Is it simply a case of getting DAO approval to change the ETH registrar controller?

Referral fees.
Is this needed? The product my team have been working on have implemented their own smart contracts that interface with the various ENS core contracts. We could easily add our own ‘referral fee’ mechanism. We havn’t, because we don’t want to take a cut… but any third party dev team could, and then it is left to free market economics. I see no need to overcomplicate the core contracts.

Bulk commits
Again gas saving bulk commits can be implemented by third party devs (although not as efficiently). Based on the downsides you’ve mentioned I don’t think core contract functionality is a priority at this point. Especially with bulk renewal. Commit gas fees are a one time cost, and further thought would need to be given to how it would be implemented to minimize the mentioned downsides.

Support
As a more general point, I think supporting third party devs needs to be prioritised. The small grants offering sounds interesting (I’ve only just heard of it), but IMO there are more fundamental dev support issues. The most prominent being that the ens contracts repo (seemingly) does not have branches for the ‘currently deployed’ contracts, and lacks documentation on what the master branch actually contains.

It was unnecessarily complex in my opinion to discern what contracts are deployed on mainnet such that I could deploy personal copies onto a testnet and develop against them. Things like the Price oracle add additional complexity - I had to create my own PriceOracle stub etc. I think this is a huge barrier to entry/innovation for third party developers.