ENS Labs development proposal: ENSv2 and native L2 support

[MicahZoltu]

@nick.eth

Perhaps using the term “permissionless” is confusing matters.

Anyone can renew any name, regardless of ownership on both ENSv1 and ENSv2.

The DAO controls which registration and renewal controllers are enabled at any time for .eth, on both ENSv1 and ENSv2. Only a controller that is enabled can be used to register or renew names, so if they disable all of them, it is no longer possible to register or renew names.

Ah, that was definitely the confusion. I wouldn’t call that a permissionless system because the DAO has permissions within the system that others do not have and cannot acquire. This aligns with my previous understanding that ENS registrations and renewals are permissioned, and only existing registrations are permissionless.

@nick.eth

• Naming systems are far less useful when there are many of them.
• We’d be imposing additional burden on client implementers to support both ENSv1 and ENSv2 separately.

There will still be many after deployment of ENSv2, since ENSv1 still must resolve properly for all of the names that don’t get migrated. Forcing people to migrate in order to renew their names doesn’t actually change that in any meaningful way. For example, I have immutable names registered for decades in advance where I threw away the keys (transferred ownership to an obviously constructed address) so I cannot migrate them. Because of this, ENSv1 must be supported by clients indefinitely, or at least until the last name expires which I suspect is far enough in the future that stopping renewals now won’t make any meaningful difference in terms of requirement to support ENSv1.

@nick.eth

We’d effectively be abandoning ENSv1, meaning anyone who registered a name for a long period under the expectation that it continues to be useful has been shortchanged.

IIUC, with the current plan you are effectively abandoning ENSv1. What I’m proposing is that ENSv1 continues to receive indefinite “maintenance”, which just consists of making sure the lights stay on (which should be pretty easy, especially if you build and release a simple IPFS hosted UI on the way out).

@nick.eth

It’s not possible to make ENSv1 (or any version) fully immutable so long as it pegs registration costs to the US Dollar, because there’s no immutable USD oracle.

Personally, I don’t care much about the cost of registrations/renewals being pegged to USD. I think it would be fine if they were switched to being priced in ETH as part of the wind-down process for ENSv1. This could lead to price explosion or collapse, but that may just end up being incentive for people to move to ENSv2 if cost becomes a problem in either direction.