Layer 2 scaling and Subdomains

đŸ§‘â€đŸ’» ENS Development Implementations
1

I thought I would just get a thread started for Layer 2 scaling and subdomains. I am working to better understand the various options and what might be the best layer 2 integrations for ENS. I started to look into zkSync. I will also start to look into Optimism. I know this is a quickly evolving area, but at the moment, does anyone know what are the most promising layer 2 scaling solutions for ENS integrations?

7 Likes
2

The Arbitrum community seem to be big, you may want to check that out.

1 Like
3

If you’re not already, it’s worth familiarising yourself with our plans for L2 scaling, too, which allows ENS names to use multiple different L2s: EIP-3668: Durin: Secure offchain data retrieval

7 Likes
4

I have been following it as best I can i.e https://youtu.be/9DdL7AQgXTM, https://youtu.be/L9N7U_bNmOU, but in the end I think a lot depends, in terms of the user experience on the particular layer 2 solutions, that are used. I know that Optimism and Arbitrum have come out early and got a lot of attention, but zkSync seems to be saying that their ZK technology is going to be ready very soon and is superior. I think in the end even if CCIP-Read allows for any Layer 2 scaling solutions, in most cases most people will just use whatever is easiest. Maybe we are still just too early, and that is why it’s hard to know where to put time into diving deeply into Layer 2s. For instance, Polygon just announced Polygon Miden, a STARK-based solution, so the landscape is changing rapidly. Anyone else looking into Layer 2s?

3 Likes
5

Yup, I didn’t mean to say that we shouldn’t do this! It’s important to evaluate the options to determine which ones are worth building infrastructure for. Just wanted to give some context on how they can be used.

1 Like
6

I personally think that having at least one (really any, I don’t think it’s important to pick the “right” one as long as later migration is feasible) Layer 2 option for ENS is probably the single most important thing for ENS right now. Fees are a huge threat to ENS usability and accessibility. It’s literally impossible to use ENS if you don’t have deep pockets right now.

5 Likes
7

For registering .eth names we’ve discussed only two options up until now.

  1. Pick an L2 to allow registration of .eth names and it becomes the new canonical chain/rollup where people can register their .eth names

  2. Allow multiple L2s to register .eth names, and sync them somehow so you couldn’t double register names

I don’t think we’ve thought of a solution for 2) yet, and 1) would mean we were picking a winner, and if that didn’t go well, we’d have to migrate to another L2.

For records/subdomains with CCIP-read, we wouldn’t have to pick a winner yet, which is why we’ve been developing that first. But I think if there were other viable options for splitting .eth we could look into this too

3 Likes
8

I think the security of ENS names on Layer 1 is more important than low fees at the moment for registrations. My question is more related to “we wouldn’t have to pick a winner yet.” I think we might want to start trying to pick at least a couple “winners” and focus on building the best user experience possible for records and subdomains. I am interested in trying to figure out who we think might be the possible Layer 2 winners. I will keep working on this. If anyone else is working on this, am interested in knowledge sharing.

1 Like
9

Hi there everybody. I’m highly interested in the layer two discussion and how to scale ENS in the safest way possible. I’ve decided to build oxo.eth as a subdomain name service provider so I’ve got some extra skin in the game here.

One idea might be to initially keep ENS level two names on mainnet, while migrating the subdomain registrations onto Layer Two zk or optimistic rollup. This would possibly accomplish a number of objectives:

  1. solve an immediate need for inexpensive name options on ENS
  2. grow out the name space by incentivizing a robust subdomain marketplace to explore dynamic use-cases
  3. use the experience of a layer two subdomain name-wrapper to test and fine-tune the viability of a long-term solution for ENS namewrapper on layer two.

I have a lot of questions about functionality of names across layer twos and how we can safely test to make sure we aren’t digging ourselves in too deeply. So maybe subdomains are a safe way to do this.

5 Likes
10

Would you like to combine our efforts in some way? I am working on the same thing for nib.eth. I plan to open source any code I create, so if you are of the same mind, working as a group might be a better way to go. I am also currently entered into the Chainlink hackathon, so we could submit for that as a way to focus the efforts.

11

Hey Premm, I appreciate the invite. I’m game to make things happen but also don’t want to step on anyone’s toes or make a huge effort only to see it obsoleted in the next week. I saw your workshop demo, really liked the direction you are going with it.

My subdomain idea for oxo.eth is really just about getting as many people to register a ultra-low-cost, ultra-resilient name with a one-time fee that lasts them for life. The tool might be just a simple script that every dapp, nft or wallet can add on their front ends.

I think we are aligned in the sense that we both want to expand the vision of ENS via subdomains, so I’m happy to help if I can.

Let’s chat about it on Discord. oxo#6288

1 Like
12

You should both probably evaluate the name wrapper, which we (True Names) plan to deploy soon and is specifically designed to address making it easier to issue subdomains trustlessly.

2 Likes
13

@oxo and @Premm.eth, I am also working on a project that involves subdomains. I’m probably focusing on L1 for now but this is a really cool EIP that I think would solve the L2 problem.

Happens to have been authored by nick.eth and 0age: EIP-2544: ENS Wildcard Resolution

2 Likes
14

Subdomains definitely seem like the easiest-to-implement route. Anyone can register foo.eth, move foo.eth to some rollup, and then once foo.eth is inside the rollup anyone can register bar.foo.eth inside that rollup; Durin would be used to let clients automatically discover those domains.

Advantages of the subdomain route:

  • Low total complexity; all that’s required in the subdomain solution is some kind of L1 getter and L2 getter, which can be achieved through a Durin integration. On the other hand, option (2) suggested by @jefflau.eth above (“allow multiple L2s to register .eth names, and sync them somehow”) would likely require significantly complex logic for the “sync them somehow” part, including reasoning about timing issues, waiting periods, etc.
  • Immediately supports all present and future L2s. On the other hand, option (1) suggested by @jefflau.eth above restricts to one L2, and Option (2) would also have to be restricted to a narrow whitelist of L2s that can be trusted to prevent attack by rogue L2s, whereas with the subdomain route it would be up to the user to choose subdomains that are in rollups that they trust.
  • Normalizes subdomains, allowing the ENS base layer to be more governance-minimized while opening the door for subdomains to have more activist governance (eg. different registration and fee schemes, built-in DAOs to delete registrations that are clearly impersonations
)

One disadvantage of course is that if people really want foo.eth, they would have to pay $50+ to register it. Additionally, the subdomain-focused route could lead to confusion between eg. vitalik.foo.eth and vitalik.bar.eth. That said, the x.eth root namespace is likely to get pretty congested anyway, and the fees are not that high compared to 10-year pre-renewal costs, and the traditional internet world already has a lot of experience dealing with TLD confusion so it’s hardly a new problem.

8 Likes
15

Hey Vitalik, I’m glad you share the vision, lol. I think normalizing subdomains will happen automatically because they are probably more akin to level one, while primary .eth names are more akin to level zero.

In any case, your point about congested namespace notwithstanding, they will be a critically important ingredient to the actual taxonomy of Ethereum as they make every organizational facet of the ecosystem distinguish itself and become more easily addressable.

For these reasons, we should incentivize adoption sooner rather than later. I’m considering giving a fair amount of names away for free to the first xyz,maybe registrants if I can raise the funds. I’m not sure how much it will cost on Optimism, lol, but I think we should incentivize people to get their names on layer two and grow the family.

Maybe ENS DAO can help out with this effort somehow, if it is appropriate.

16

I would agree that the subdomain route would be the easiest way. For an actionable plan to get there we need:

  1. Bridge for ERC721/ERC1155 (for NameWrapper) tokens
  2. Deploy a registry on each L2 that allows claiming that .eth name once you have bridged to the L2/sidechain
  3. Deploy a public resolver to each L2
  4. Deploy a generalised subdomain registrar to each L2 to allow committing your .eth to register subdomains. We could seed this with a few short 2LDs from the community.
  5. Deploy the NameWrapper to allow burnable permissions (to allow easy trustless subdomain registration)
  6. Deploy a UI to register subdomains
  7. Update ENS app to deal with multiple registries

I think in general the L2 subdomain route is the more practical and easily actionable. I don’t think getting .eth onto L2 is realistic unless we can fix the ‘sync them somehow’.

4 Likes
17

Glad to see this list of actionable items. I think it is also important to acknowledge that second-level domains (e.g. foo.eth) are all going to be owned by private parties who will want to offer their subdomains at the market price. The second-level domain owners themselves will be a large user base, and will want to have easy to use tools in order to control how their subdomains are marketed and sold. This would seem to be a significant project with ongoing dev involvement. Does it make sense for ENS to take on this project? If ENS does take on this project on at least a couple L2s, is there a way to make it sustainable? Maybe there should be revenue sharing put into the L2 contract? Maybe anywhere between 2-10%? Second-level domain holders could decided to create their own systems, to avoid paying the fee, if they wanted to. Also, imagine if L2s bring in more and more users, those users will end up flowing into the discord with all their problems, etc. I think the idea that subdomains don’t have a registration fee is nice in theory, but in the end even subdomain users will eventually end up interacting with ENS, and there will be real costs associated with those interactions.

3 Likes
18

Just to make sure I’m understanding the proposed subdomains strategy correctly, is this the approach?

  1. You transfer foo.eth to Arbitrum (ie. you use the deposit function in Arbitrum). At this point, from the point of view of L1 state, foo.eth belongs to the Arbitrum contract, and from the point of view of Arbitrum L2 state, foo.eth belongs to some specific account.
  2. At that point, anyone can send transactions inside Arbitrum to register bar.foo.eth
  3. If, after this point, you were to transfer foo.eth out of Arbitrum, all the subdomain.foo.eth domains registered inside Arbitrum would stop working. So if someone wants to actually use this scheme to create useful subdomains, they would have to transfer foo.eth to some domain where no one can take it out in step 1.

This requires deploying some standard contracts in Arbitrum (and on Optimism, and on any other L2) to make subdomain registration actually possible. It would also require someone to run nodes that provide Durin-compatible state proofs to make bar.foo.eth actually resolvable.

20

Rethinking
it’s a challenge to think many years into the future with only one cup of coffee.

21

Yes that is the basic idea. We would probably need to lock the resolver on layer1 for the foo.eth as well, otherwise they could change the resolver to point somewhere else and it would render subdomains unresolvable.

On L2 we could deploy a NameWrapper contract to burn permissions such as transferring back to L1, replacing subdomains etc.

We also have the problem of how to handle L2 updates, where the contract the resolver needs to verify against may change. Making it entirely trustless may be difficult

1 Like