ENS Labs development proposal: ENSv2 and native L2 support

šŸ§‘ā€šŸ’» ENS Development
1

Introduction

ENS Labs is excited to present our vision for the next iterations of the ENS protocol, which weā€™re calling ENSv2. The Ethereum Name Service (ENS) has been a crucial component of the Ethereum ecosystem, providing a decentralized, secure, and user-friendly naming system. However, as Ethereum continues to grow and evolve, the current ENS architecture faces limitations in terms of scalability and user costs. To address these challenges, enhance functionality, and align more closely with the Ethereum ecosystem, weā€™re proposing the extension of the ENS protocol to a Layer 2 network: either a public network or our own custom Layer 2. This proposal details that process and includes a formal request for additional funding from the ENS DAO to support the development of the new architecture and the migration process.

This proposal follows several months of research, internal deliberation, and external conversations with L2s, members of the ENS community, and many members of the Ethereum ecosystem. You can review the proposalā€™s technical design document here for a deeper look into what weā€™re proposing for the protocol at the architecture level.

Background & Problem

Since its launch in 2017, ENS has evolved from solely naming onchain addresses into a multi-faceted (DNS, NFTs, Email, RWA) naming protocol. With millions of .eth names registered across numerous dapps, wallets, and browsers - it has seamlessly connected users as a vital bridge to web3. ENS currently operates on the Ethereum mainnet, and while Ethereum and our current architecture has served ENS well, it has limitations in terms of scalability and cost-efficiency. As demand for Ethereumā€™s blockspace increases, so have the costs associated with registering and updating an ENS name. These issues arenā€™t local to ENS, with Vitalik sharing his ā€œrollup centricā€ (read: L2-centric) roadmap as part of Ethereumā€™s plan to mitigate these issues. The emergence of L2 solutions presents an opportunity for ENS to overcome these limitations by offering improved scalability, reduced gas costs, and the potential for enhanced functionality while maintaining backward-compatibility and continuing to derive security from Ethereum. Itā€™s of the utmost importance that the ENS protocol remains decentralized as we continue to serve our users.

Proposed Solution

Weā€™re formally proposing the extension of the ENS protocol to an L2, and a new hierarchical registry design for ENS, where each name has its own personal registry responsible for managing subdomains and resolvers. This design will be coupled with the introduction of an updated Universal Resolver, which will help streamline the resolution process and provide a better experience for users and developers.

The authoritative registry for .eth names will be deployed on a selected L2 network. Users will have the flexibility to move their names between the L2 and Ethereum mainnet (L1), allowing them to choose the optimal balance between cost, security, and functionality. Itā€™s important to note that users DO NOT need to move their names from Ethereum to the L2: it is 100% optional.

L2 Selection Framework

To ensure a thorough and objective evaluation process in choosing between a public L2 and building a custom L2 for the ENS migration, we have developed a comprehensive Selection Framework. This framework will guide our decision-making process and help us identify the most suitable option that aligns with ENSā€™s requirements and goals. The Selection Framework consists of 3 requirements and 9 ranking criteria.

The requirements are:

  1. EVM Compatibility: The L2 network must be at least Type-4 EVM-compatible by Vitalikā€™s Taxonomy.
  2. Censorship Resistance & Decentralization: The L2 must have a credible path to censorship resistance and decentralization of the sequencer.
  3. Open-Source: All critical L2 infrastructure must be available under an OSS license.

The ranking criteria are:

  1. Finality and State Updates: We will consider the time required for transactions to be committed to L1, and to be finalized. Fast time to first L1 commitment, and fast time to finality, are essential for decreasing latency between user updates to ENS names and those changes being observable by clients.
  2. Security and Resilience: The availability of fraud proofs and the frequency and thoroughness of security audits will be assessed to ensure the security and integrity of ENS on the L2 network.
  3. Performance and Scalability: We will evaluate the L2 networkā€™s transaction throughput, confirmation times, gas costs, and scalability roadmap.
  4. Decentralization and Governance: The governance model and the ability for ENS to maintain governance independence will be evaluated to ensure alignment with ENSā€™s values and objectives.
  5. Interoperability and Composability: We will assess the L2 networkā€™s cross-chain compatibility and adoption of standardized interfaces to facilitate interoperability with the broader Ethereum ecosystem.
  6. Developer Experience and Tooling: The availability and maturity of developer tools, documentation, support resources, and the strength of the developer community.
  7. Adoption and Network Effects: We will evaluate the L2 networkā€™s existing projects, partnerships and the potential benefits of joining a specific tech stack to gauge its impact on ENS adoption and usability.
  8. Customization and ENS-Specific Features: The L2 networkā€™s ability to accommodate ENS-specific requirements will be assessed.
  9. Operational and Economic Considerations: We will consider the quality of technical support, operational overhead, fees, and conduct a comprehensive cost-benefit analysis to ensure the long-term sustainability and viability of running ENS on the L2 network.

Migration Plan

The migration to L2 will proceed in phases, designed to minimize disruption for DApps, wallets, and users. Initial phases include changes to the resolution process, which will facilitate a smooth rollout of more fundamental changes later in the process. For more details see the migration section of the design doc.

Crucially, existing names will continue to function indefinitely, allowing existing applications that rely on the immutability of ENS names to continue to operate without changes - though these names will not be able to take advantage of some of the new functionality enabled by ENSv2.

Anticipated Impact

We anticipate the deployment of ENSv2 will represent a step change in functionality and usability for both developers and end-users. Developers will benefit from the increased flexibility provided by the new registry design, as well as being able to benefit from other infrastructure deployed as part of the migration. Users will benefit from the reduced transaction fees and increased throughput that comes from hosting their names on an L2, while still being able to choose to retain the security and availability guarantees of hosting their name on L1 if desired.

Funding Request

To execute the proposed migration to Layer 2, ENS Labs will need additional funding from the ENS DAO. In the coming weeks we will put forward an executable proposal to request an annual budget increase of 4 million USDC, which will be primarily allocated to hiring additional developers and covering infrastructure costs related to L2 development and deployment.

This funding is crucial for ENS Labs to successfully develop and deploy ENSv2, and to extend .eth to a Layer 2 network, enabling us to carry out the necessary development work to build and implement the chosen L2 solution. We kindly request the ENS DAO consider this funding proposal as an integral part of the overall ENSv2 plan.

Next Steps

The ENS Labs team is already evaluating L2 networks for suitability. A detailed migration plan and timeline will be established, taking into account the technical requirements and community feedback. Weā€™re also making good process on a first iteration of proof-of-concept contracts that implement the new architecture.

In the coming weeks, weā€™ll be putting forward an executable proposal for additional funding for ENS labs to allow us to take on this major evolution in the life of ENS. This will allow us to hire more engineering, operations, and go-to-market talent to build and deploy ENSv2 in a timely manner, as well as covering infrastructure costs relating to the deployment and operation of L2 infrastructure.

We encourage active participation and input from the ENS community throughout this process. Your insights and support are crucial in ensuring a successful migration that benefits all stakeholders. There will be several opportunities to provide feedback, starting with the following:

31 Likes
2

Yes!

2 Likes
3

Hey Nick thanks for posting this.

Part of the requested funding will also be for the research to decide which L2 would match the criteria you set out and not only to implement it?

3 Likes
4

Are external development teams an option for hiring more engineering, operations, and go-to-market talent?

Many recipients of ENS and OP grants likely have significantly more experience with ENS than other smart contract developers.

5

We can research and select an L2 in Labs with our current resources, but thereā€™s little point in doing so if we donā€™t have the funding to execute on it.

I think weā€™ll be looking both at hiring and outsourcing as appropriate.

2 Likes
6

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.

Wouldnā€™t it be better to keep them as they are, and instead make L2.eth subdomain and allow the L2 control stuff underneath? This would keep the old system functional and not get censored by the new system.

7

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

8

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
9

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?

10

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.

11

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.

12

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
13

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
14

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.

15

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?

16

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

17

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
18

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:

19

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.

20

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