ENS Labs development proposal: ENSv2 and native L2 support

Why not just make ENSv2 as a separate product? What is the benefit to users of forcing ENSv1 users to be dragged along into the new system vs just letting people use either the new or the old system (voluntary migration)?

You would need to come up with another TLD, or you would need to put all of v2 under a subname like 2.eth. While I can appreciate the desire to have a single monolithic TLD, I don’t think that alone outweighs the credibility benefits provided by making ENSv1 immutable and building ENSv2 as a separate (new) product.

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.

The migration process will involve disabling all the ENSv1 registration and renewal controllers, and enabling new ones for ENSv2.

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

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.

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.

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

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.

You could auto migrate everyone to 2.eth (eg. give anyone free domain there), the implementers then could decide to just support 2.eth, if they no longer want to support .eth. Now you are breaking all the v1 applications that need to be updated to support the new version.

No; ENSv2 is designed such that resolution falls back to ENSv1 for unmigrated names. Clients will only need to support ENSv2, and all unmigrated ENSv1 names will continue to resolve indefinitely.

No; anyone who registered with ENSv1 will be able to use the name via ENSv2, even if they can’t migrate the name. That makes it far more useful than a name stuck on a legacy naming service that’s only in maintenance mode.

There’s absolutely no reason I can see that we’d embark on a path where we start a new naming service and don’t allow ENSv1 users to migrate to it. It’s a net negative in every way.

:dart: ENS should focus on making adoption easy and improving user experience, ensuring that managing a domain linked to a wallet is straightforward. If moving to Layer 2 doesn’t enhance this process, one has to wonder: are we prioritizing economics over utility?

1 Like