ENS Labs development proposal: ENSv2 and native L2 support

This sounds like an attack against ENS. This will disable the original contracts. You can no longer register and renew ENS names to the original contracts. Nobody should have this kind of power.

Where did you get that conclusion from?

Quoting nick below

I’m glad to see this as a requirement, but I’m concerned about how ill defined it is. For example, I haven’t seen any L2s that have what I would consider a “credible” path to censorship resistance, but many people believe almost all of them do. Most things that call themselves L2s claim to have plans on how they will provide censorship resistance in the future, and some even have concrete ideas. Claiming to have a plan isn’t sufficient IMO and concrete ideas aren’t meaningful IMO if they don’t end with an immutable and permissionless autonomous system.

Any L2 whose plan for censorship resistance is a multisig or DAO governance contract for upgrading isn’t actually censorship resistant IMO. The .eth registry did the right thing by making sure even the DAO can’t retract already registered names, and I think any L2 ENS should have the same property, that no one (including a DAO or multisig) cannot trigger an upgrade that would allow altering the registry.

It is possible that those pushing this idea forward share my thoughts, or maybe they don’t, but at the least this proposal should make it far more clear what exactly is meant by “a credible path to censorship resistance”.


My personal recommendation, build your own L2 (ZK Rollup). I think ENS is useful enough that it would benefit from own-L2, and the benefit of sharing a rollup with other applications isn’t worth it, and just increases the risk of costs growing faster than if ENS is an own-L2.

2 Likes

From the Design Doc:

  1. Disable new registrations and renewals on ENSv1.

While I am not opposed to disabling new registrations. I think disabling renewals has potential to break existing contracts. Imagine an ENS name whose ownership is transferred to an autonomous and immutable contract where anyone can pay to extend the registration, or the system uses funds it accumulates through operation to extend the registration. Disabling registrations will break such a system and the name will expire at some point with no ability to extend it.

I think ENS should strive to not break any application/contract that has chosen immutability, as doing so discourages future developers from choosing immutability when we should be encouraging developers to choose immutability.

The canonical case for this is people who setup autonomous unruggable third level names where anyone can extend the second level name and it is unowned (so cannot voluntarily migrate to v2). Users who have a third level name and thought it would last as long as anyone cared will now have a third level name that will expire at some point, with no way to extend it.

Instead of disabling renewals, can we instead just make the .eth registrar immutable and throw away the keys so it will continue to operate indefinitely as it is? This would go a long way to reassuring people that they can depend on ENS not rugging them if they decide to build censorship resistant software.

Switch over clients to using the new universal resolver for ENSv2, possibly
using a one-time-upgradeable proxy to allow this to be done
instantaneously.

What does “clients” refer to here? Is this referring to app.ens.domains? What do one-time-upgradable proxies have to do with off-chain clients like that?

I understood that nick talks about new contracts on L1, not about the original contracts? The design doc states:

**1. Disable new registrations and renewals on ENSv1.**
2. Perform a new sync, updating the state of ENSv2 on L2 to match the set of
registrations and expiries existing on L1.
3. Switch over clients to using the new universal resolver for ENSv2, possibly
using a one-time-upgradeable proxy to allow this to be done
instantaneously.
**4. Enable registrations and renewals on ENSv2.**

The registrations and renewals are NEVER enabled on ENSv1 again.

Disabling this is a required step of the migration - otherwise it’s impossible to synchronize data to the new instance.

Fortunately, renewals are permissionless - anyone can renew any name - so the scenario you describe will not prevent the name from being renewed.

Agreed, and this is one of our guiding principles in the upgrade - hence why existing names will continue to function indefinitely without migration.

We have a plan for this, described in the design doc - 3LD owners can migrate their name even if the 2LD is not yet migrated. This creates a ‘shadow’ node in the new registry representing the unmigrated parent name.

No, because it would result in duplicate registrations with the same name.

A client is any software that resolves ENS names. The idea with the one-time upgradeable proxy would be that it allows clients to all be switched over at once on execution of a DAO proposal.

My perception (and personal opinion) is that as with many things in the crypto arena there are tradeoffs. The crux one here being duplication of effort. There are incredibly competent, well funded teams who are focussing their efforts on building out L2 solutions using various technologies. The time and cost associated with doing it ourselves (from scratch) would be vast. Especially given:

From the tech doc:

“A new deployment on an L2 - either a public one or a dedicated chain”

There are of course complex considerations in relation to censorship resistance if the decision was a public L2 but the L2s that I imagine are being considered have vast economic incentives to be good actors more generally.

If a dedicated chain is the chosen direction (see ENS Chain) theres arguably even more flexibility wherein on initial release the DAO (or any other trusted parties) could operate the sequencing for the chain and it could be decentralised over time as the technology and surrounding ecosystem develops (based sequencing etc).

The OSS nature of any chosen tech stack means that it could be forked and customised as appropriate and many of the potential solutions e.g Arbitrum Orbit and the OP Superchain proactively market the flexibility and customisability offered in the architecture of their design.

The ZK stacks are generally less mature but there is obviously significant promise in ZK tech. I suspect that the reason this proposal isn’t explicit in which chain/stack might be used is because there is still significant research/discussions to be had in this regard to ensure the decision is the best one possible.

1 Like

I’m confused by this because these two statements seem to contradict each other. What I’m hearing (which must be wrong) is that migration requires disabling renewals, but renewals cannot be disabled because they are permissionless. What am I misunderstanding here?

I fully agree that it is very hard, and if you can use an existing open source codebase that would be ideal rather than inventing everything yourself. However, I think for the long-term health of ENS it would be better to be on its own chain rather than a shared chain, as that minimizes the risk of usage costs spiking for reasons unrelated to ENS usage. I would rather see this come to fruition in 2-5 years on its own chain than land in 9 months on a shared chain.

The problem is that economic incentives change with time, which is why we should be very careful to pick a chain that cannot be captured or have its incentives change in the future. It is critical that ENS survive the test of time, and no L2 has survived the test of time. In fact, every L2 (except Fuel v1) has failed to achieve their stated goals of becoming a true L2 (same security guarantees as L1, achievable via immutability and permissionlessness).

I would fight very hard against this. Everyone has big plans for “we’ll decentralize later” and the track record across the board is extremely poor. No L2 that has stated this has actually achieved the goal, and almost no applications have. The ones that actually do become permissionless almost always do so within months of their launch, where they launch with a backdoor “just in case something goes wrong initially” and they very rapidly remove the backdoor.

If you have an actual design for immutable/permissionless sequencing, you should implement that up front. If you do not have a design, you should assume that you never will until you discover it. We should not be building ENSv2 on the hopes that someone solves a hard problem at some point in the future. We should devote resources to solving that hard problem first, and then go build ENSv2.

2 Likes

Migration requires disabling renewals on the old contracts, so that we can take a snapshot of all registrations and transfer them over to the new contracts cleanly.

When renewals are enabled, anyone can renew any name.

There are definitely tradeoffs in choosing a shared chain vs a dedicated one. Even if we choose a dedicated one, though, it will be based on standing up an instance of an existing L2 design, not creating our own from scratch.

With respect, ENS itself is a clear counterexample.

IIRC, ENS threw away the keys to the .eth registry relatively soon after launch, and the system launched fully designed and engineered to be operated permissionlessly. What I’m arguing against here is doing either of:

  1. Launching without first coming up with a complete solution to making the system permissionless.
  2. Launching without a very clear plan/roadmap that ends in permissionless.

I believe ENS did both of those in its original launch, and I am optimistic that ENS will do both again (unlike nearly everyone else building in this space). However, what was suggested above is that the launch of ENSv2 would occur without solving the design problem or having an explicit roadmap, which is what I would fight hard against.

So renewals aren’t permissionless (ENS DAO can disable them), and the plan is to re-enable them for ENSv1 after the migration is complete, and only leave new ENSv1 registrations disabled permanently?

ENS is not a counterexample as it never went full permissionless. The renewals and account creation has always been under control of ENS governance.

While registrations and renewals have always been governed by a smart contract, it took about 3 years from launch before the ability to replace or upgrade that contract was revoked. I think the parallel here is similar: we need a credible path to decentralized sequencing from an L2, not necessarily to have it already in place.

Agreed!

Definitely not.

No, ENSv1 renewals will need to remain disabled, because both renewals and registrations are governed by the same contract. While we could deploy a new one that only allows renewals but not new registrations, this would needlessly complicate matters when the same renewals can be done via the v2 infrastructure.

1 Like

I’m back to confused by this statement then:

I’m probably missing something simple, but the two bolded statements seem contradictory to each other. Unless anyone can disable renewals, but I’m pretty sure that isn’t the case. :sweat_smile:

Renewals will be disabled on L1.

Renewals will be permisionless on L2 and then you will be able to provide a proof on L1 to renew, but normal renewals will be disabled on L1, so it will be more like a ‘sync’ renewal via a proof.

So ENSv1 renewals are permissioned, and the plan is to make ENSv2 renewals permissionless (unlike their historic ENSv1 counterparts)?

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