I’m not sure this is a good idea. An L2 may change or may go away at some point in the future. Being able to move a .eth domain back to L1 should always be an option, even if this means that any other information that was stored in the L2 resolver will be gone.
1 Like
I see a new problem here similar to the problem of ENS not knowing which L2 to pick. Second-level domain holders (e.g. foo.eth) would need to choose which L2 is the best, and then they would be stuck on that L2. This could be a real problem in the case of valuable second-level domains. I think this will be a deal breaker for many. Using this system simply pushes off ENS’s problem of which L2 to choose on to second-level domain holders.
I see three options:
-
Second-level domain holders (e.g. foo.eth) choose a L2 and issue subdomains, but those subdomains are not trustless.
-
ENS picks an L2 and moves everything over to that L2, without burning the permission to move to another L2 in the future.
-
Second-level domain holders form DAO’s that govern the second-level domains. Anyone who holds a subdomain is a member of the DAO, wherein they have a say in which L2 will be used for the second-level domain.
Each of these options have pros and cons. For instance, let’s imagine that a wallet wants to give out subdomains to their users, which option will they choose. I would assume that they will choose option 1. They will issue subdomains to their users and keep control over the second-level domain. If they want to switch to a new L2 later on they can do it, and they can simply migrate all of the subdomains over when they move. Most users will most likely not care or not know that there is anything wrong with this approach. It is however a con that the system is not trustless.
In another example, a group of second-level domain holders with high value domains (e.g. wallet.eth , address.eth, etc. ) might choose option 3., wherein they will give control over to a DAO to make decisions over which L2 will be used. The main con to this system is that it creates a DAO of DAOs structure to ENS, which adds complexity and is essentially fracturing the community.
I do not see “burn[ing] permissions such as transferring back to L1” as a workable solution. There is a fundamental problem with the idea of creating trustless assets on an L2 which is not trusted.
In the case of NFTs more broadly on L2s, they don’t have the same challenge of having to occupy the same name space as all other chains and L2s (e.g. CryptoPunks and PolyPunks).
1 Like
Seems to me ENS needs to run it’s own layer two. It’ s too important.
What if ENS allows that? Let second-level domain owners decide what they want to do with subdomains: if they want to move them to an L2 network, let them. If they want to migrate to a different L2 network later on, let them. If they want to break things and make subdomains unresolvable, let them do that. ENS’ attempt to fully control how subdomains are manged seems to make things too complicated and requires complex solutions that might cause new complications. Making the whole structure modular will allow more flexibility in the future, when people want to implement something that wasn’t considered by ENS but is still possible thanks to the modular structure.
Also, locking second-level domains on L1 might be seemed as an excessive measure. What if someone wants to keep some subdomains on L1 (e.g. subdomains assigned to some critical infrastructure contracts) while having user subdomains on L2? Or maybe there are cases when identical subdomains on different layers is a solution.
To me, bridging and deploying a registry with a public resolver looks like a 20% solution that covers 80% of cases. Bridging would allow to claim second-level domains on L2 and the registry would only allow to register subdomains to not allow second-level domain duplicates between L1 and L2.
5 Likes
So as I understand it, the solution should not be whether we move resolver to L2 or not, but more so how ENS is moved such that the majority of data is moved to L2. Finalization should happen on mainnet…forever. However, it should become ever more efficient.
The way I look at it is by pretending its real estate. Lets pretend ENS is a top floor high rise in San Francisco. Every character of every record need not be stored in said high rise. Nay. We can store the vast majority of data for each record in storage units in Nebraska. All we need is a reference point for the San Francisco office to point to.
In other words, the majority of the data resides on L2 chains. Multiple chains, redundantly. L1 mainnet simply has a reference to the data stored across the multiple chains in a verifiable manner. Efficiency of L2, with consensus of mainnet.
Thats simply the generalization of the idea, execution will require much more thought and work.
1 Like
I’m not sure this is a good idea. An L2 may change or may go away at some point in the future. Being able to move a .eth domain back to L1 should always be an option, even if this means that any other information that was stored in the L2 resolver will be gone.
The challenge with this is: if we want to deal with the possibility that some L2 will go away, then who decides whether or not a migration happens? I guess one option would be to allow individual names in the L2 to withdraw to L1? Ideally we could even package many names from the same L2 up into some kind of NFT with a Merkle root, withdraw and move that token to a different L2, and then unpack them in the destination L2.
Would either of those paths be possible within the context of the existing ENS standard?
I think the beauty of ENS has always been its simplicity and composability. When I look at the various options for utilizing one or more L2 scaling solutions, there is only one solution that will not expand the complexity of ENS, and that is if ENS as a whole chooses an L2 and migrates. In this case, the complexity that necessarily comes with an L2 will be abstracted away from ENS. In the event that the chosen L2 needs to be changed at some point in the future, there is already a system in place to make that change, which doesn’t add any complexity to ENS, which is the DAO.
I currently believe that any other solution adds complexity to ENS and doesn’t solve any problems, but instead, moves those problems around.
Also if one L2 is chosen, it is very easy to create a system where the legacy L1 resolver and the new L2 resolver coexist. All that would need to be done is for the L2 resolver to take precedence over the L1 resolver. If there are a bunch of L2s then this becomes much more difficult.
3 Likes
Would it make sense to keep all foo.eth on L1 but let the owner define that all subdomains bar.foo.eth will be hosted in an L2 supported by ENS? Can I set the resolver of foo.eth on L1 to a one deployed on an L2? (Forgive me if I’m missing technical aspects of this.)
This would allow users that are OK with a third level domain to use the cost efficiency and speed of an L2. But the second level domains will always be on L1.
Right. The broader issue is: we can use the name wrapper, and equivalents on L2, to ‘lock’ things such as the resolver contract, the ability to replace subdomains, etc. But this is difficult with an L2, because the protocol used to prove L2 contents on L1 will change over time as the L2 undergoes its own hard forks and improvements. Introducing the ability to change how the resolver for a name verifies L2 proofs also introduces the vulnerability that a malicious 2LD owner could use that facility to revoke owned subdomains.
One workaround for this is that an L2 gateway can allow the owner of a subdomain to ‘push’ that domain to L1; at that point it gains the same security as any other L1 domain. However, this brings us back to the thing we’re trying to avoid - high gas fees.
It would certainly be possible to make a CCIP-read (formerly Durin) gateway that relies on Merkle proofs of inclusion in a list of subdomains, which themselves are stored on L2. This would have some big advantages: it’d be L2 independent, and easily migrated to any other storage system. But a big disadvantage: the merkle root has to be updated regularly onchain, and if we also want the L1 infrastructure to be able to verify that domains are not being deleted from the tree, all updates would have to be propagated in a way that allows an L1 contract to verify that, rather than just sending a new root. We’d effectively be building our own (admittedly simple) rollup.
Perhaps there’s a solution available here with ZK proofs rather than plain merkle proofs, to permit multiple updates with constant cost? I’m not familiar enough with them to say.
This is how the current CCIP-read system will work.
1 Like
From my, non-technical, point of view this is fine, and sounds like a simple, clean implementation approach.
2LDs will be on L1, and 3LDs will be on either L1 or L2.
Yes, anyone that wants to use a 3LD should choose their 2LD “provider” wisely. I would be hesitant to accept this if we didn’t have DAOs. But DAOs give people a way to organise and get a cool 2LD, manage it is a way that they trust, and have their 3LD on top of it.
(Getting a 3LD from a DAO will probably open up new opportunities for both DAOs and their members. Setting your avatar to the DAO NFT, maybe support and resolution of issues, human intermediated governance, airdrops, etc.)
That would mean that the decision is centralized but it might be wise to let subdomain holders choose whatever L2 network they want (considering an ENS registry/bridge/gateway is deployed on it). Some L2 networks might be more preferable in specific cases.
Multi-layer resolution system seems like a good upgrade to subdomains scaling but not as a solution that enables it. It’s something that would be nice to have to make subdomains management complete, but that’s definitely an advanced feature.
I wonder what would the structure of the ENS infrastructure be if it tries to follow the modularity of Ethereum? If L1 is the consensus and finalization layer and L2s are the data/apps layers, then where ENS domains belong to? Trying to move subdomains to L2 makes it look like second-level domains belong to the consensus level and this pushes them away from the data/apps levels. But it’s still expected that second-level domains are as available to users as subdomains, and if they’re left on L1 then it separates them from subdomains because they’re more expensive to buy/renew. Is this separation viable? Can it be that, at some point in the future, second-level domains are mostly owned by dapps/services that provide subdomains to their users as a subdomain-as-as-service solution (maybe like email names)?
Let’s see it from a user’s perspective.
We are discussing here about scenarios where a user must make a decision between L1, and various L2s. They also have to be aware of the technicalities of features like moving a domain from L1 to an L2 and what this means, moving (or not being able to move it) back to L1, moving between L2s. Decisions that require understanding of what L1/L2s are, the differences I between L2s and also technical aspects like pointing to the right resolver, etc.
I wouldn’t expect that most user can or are even willing to deal with these things. As the user base grows, it seems natural to me that most users will delegate the complexity and responsibility to organisations (hopefully DAOs).
This is not relevant to this discussion, but on this topic it would be interesting to see what kind of tools ENS can make and provide that will help DAOs provide this service to users. For example a turn-key solution that will give voting power to subdomains in order to update the resolvers, or migrate between L2s, or batch updating subdomains.
3 Likes
After reading some of the comments, it seems the technical challenges mostly have to do with issues beyond ENS’ control. So whatever is decided, I would hope that it is in favor of maximizing ENS’ sovereignty.
For me, there is no point to making ENS subdomains available on only one layer two. For ENS to achieve maximum potential, I think it needs to be available universally. If it is only available on one chain you risk one of the layer two’s forking ENS which I don’t think would be desirable.
I like the idea of 100% ENS sovereignty and self-reliance, so if that means we need our own rollup, let’s make it happen.
1 Like
Letting people choose also means letting DAOs and dapp developers choose what L2 solution better fits their use-case and the needs of their users. If ENS chooses an L2, that’s a higher risk for ENS because, if the L2 they’ve chosen gets shut down or loses the race (or gets hacked, or pivots, etc.), ENS will be obliged to provide a solution to migrate user domains to another L2. Also, communities of L2 solutions that were not chosen by L2, won’t be happy and someone will submit a proposal to add support for other L2 solutions and ENS will eventually have to support multiple L2s.
At first I also believed that ENS supporting any L2 was the best option. As a solution it builds upon a stable secure foundation, which is the L1 ENS system, but when looking further into it, I came to the conclusion that supporting multiple L2s will not solve any problems, instead will only move problems to second-level domain holders, who in many cases will not be in a position to solve those problems effectively.
Second level domain holders will not be willing to migrate a domain to an L2 and burn their permission to move it back to L1. That means that second level domain holders will have a problem. If they want to issue subdomains they will either have to let their buyers know that the domains can be revoked at any time, or else they will need to establish a DAO and include all their subdomain holders, so as to determine what happens if the L2 fails.
For many applications, forming a DAO will be unrealistic. The uses of the subdomains can be so prosaic as to not inspire any community involvement, e.g. link shortening, naming a single NFT, naming a single smart contract, GPS location data, etc. If a user bought a subdomain for naming a single piece of data for example a GPS location, it doesn’t make sense to be in a DAO for that. That would mean that the second-level domain holder would most likely issue domains without it being trustless in almost all cases.
The benefits of ENS picking an L2 and moving are clear – immediately the gas fee problem is basically solved, second-level and third-level domains can be registered within a single interface. Buyers of second-level and third-level (subdomains) are treated equally, and everyone who owns a domain has the same risk.
While L2s add complexity, they should still provide the same level of security for on chain assets. That is the point of L2s, vs side chains. ENS is positioned better than anyone else in order to face the issues of migrating to an L2 and successfully onboarding millions of domain holders. Web3 is going to be a multichain world, where any particular side chain or L2 will need to be able to interact with other chains and L2s. If ENS stays on L1 it won’t make it any easier to interact with, because most users will be on L2s anyway, so they will be accessing ENS cross chain.
2 Likes
This is true if there’s an optional L1->L2 migration solution for all domains, not only subdomains. If there’s such solution, then: it shouldn’t be optional, but rather mandatory. If L1 gets very expensive to use and L2s get mature, reliable, and robust, ENS will simply migrate to L2 and there will be no need to use L1 for anything but finalization.
If we ever get to this situation (and I believe we will), we won’t need to worry about multi-layer resolution and inter-layer migration plans. L2 will be simply cheaper and all applications (including ENS) will move to it–this is the picture of the future that rollups are painting for us. At some point in the future, we’ll, hopefully, have rollup networks interconnected in a bigger network so L2<->L2 data migration won’t, hopefully, be a big problem.
Again, this looks like an attempt to decide for second-level holders. This is similarly to DNS creators deciding for web application developers. Let them do whatever they want. Let them revoke subdomains if they want. Let them choose who can or cannot buy a subdomain. Let them establish a DAO if they think it would be right thing to do. It doesn’t really feel correct if ENS imposes any rules or requirements here.
If they chose an L2 that has failed, they would need to migrate to a different one. The same is true for any application that runs on this or that L2–that’s a risk that has to be taken at this moment. Should ENS mitigate this risk? Probably, yes, for second-level domains, but not for subdomains. ENS might build a tool to simplify data migration, but ENS won’t pay for gas anyway, so second-level domain owner would still have to take the risk.
I agree. But at this moment, when there are multiple rollup chains competing and it still not clear which of them is better and if or which of them ever wins the race, choosing one of them would be unfair. ENS is a common good. Every rollup chain has a community and users around it. Choosing one of them and leaving others behind a fence would be unfair.
There’s another aspect that just popped up in my head: if multiple rollup networks will eventually coexist, how would ENS resolve domains from different rollup networks? If bridging allows to bridge second-level domain to only one network then that looks like a solution. ENS would still have to have a central registry deployed to one network so other networks could get domain ownership info from it.
1 Like
Has this been frozen?
I’ve been thinking about L2 integrations… How about we just add a property to .eth domains, where it specifies the L2 where the resolver is hosted. So, the .eth token is always on L1, but the resolver can be in L1 or any (EVM compatible) L2. Same contract, no changes (I guess?), default is L1. ENS can deploy resolvers to L2s, but anyone else can do it too if they want.
Would this be a simple and elegant solution?
I think you can express a similar logic using EIP-3668( aka CCIP-read, Durin) just let the gateway server to return data without any verification logic.
@nick.eth, what do you think?
1 Like
Sometime ago I wrote this about L2 subdomains offloading:
- you register foo.eth on L1
- on L1 there is a record
subdomain-registar that points to a L2-chain_id:owner_address (for validation, see below) - there is a L2 ENS contract, where you can register any amount of subdomains X.foo.eth
- this subdomains are not operational until sync with L1
- the owner choose when to sync with L1 in batch mode
- L1 accept to sync *.foo.eth iff (if only if):
L1/foo.eth/subdomain-registar/L2-chain_id:owner_address = L2:address
advantages:
- L1 is always the authoritative chain.
- if L2 is gone, no problem.
- if the user want to move to another L2, no problem.
- simple
cons:
- only for subdomains
- if subdomains are few, the cost is about the same (or more).
2 Likes