This thread is intended for technical feedback on the ENSv2 design doc.
7 Likes
One thing that I really like from the current registry / .eth registrar is the idea of a separate Owner and Manager. It allows the user to put their name in cold storage, while still being able to safely create subnames, edit records, and so on, without risk of losing the name/NFT itself. That is one thing that, in retrospect, was missing from the Name Wrapper: Wrapped names could no longer have a separate manager. You could approve an operator on the Public Resolver, but that would only be for editing records. If you wanted to do anything else (e.g. involving subnames), then you still had to make transactions from the Owner account.
With the new hierarchical system, that functionality will be up to each individual node, and what registry they choose to use. I would advocate for this “separate owner and manager” functionality to remain present in the v2 .eth registry, and in the default user registry. I think it really helps from a security perspective to be able to send the NFT into a separate wallet and never have to touch it!
4 Likes
I’m quite conflicted on this. It has definite advantages, as you outline, but it adds a lot of complexity and confusion to the system. On balance, I think it’s more trouble than it’s worth, given we can replicate similar functionality with things such as approved operators on resolver contracts.
3 Likes
The current Public Resolver does support approved operators and that’s awesome (thanks @Premm.eth!). However, that only applies to editing records for a name.
If you need to manage subnames, or update the resolver itself, then you’d still need to break out your cold storage Owner wallet and connect it (for a wrapped name). For an unwrapped .eth 2LD, you can do all of that from the Manager account. Is there some way you’re thinking we could still replicate that in the new model? It couldn’t be at the resolver level though, right?
The wrapper also supports approved operators, and we could implement that for standard registries as well.
1 Like
Yes, but an approved operator also has the ability to transfer ownership of the name, which defeats the point here.
Perhaps there could be a separate set of operators that could do everything except for transferring ownership. That way you could keep the NFT in cold storage, and approve a hot wallet as a “suboperator” or “manager”, and rest assured that even if your hot wallet is compromised, your name/NFT cannot be taken.
9 Likes
A more programmatic and standard approach would be to have a rolls based system. There could be a set of role types, with different permissions and approved addresses can be added to a particular role.
This would also unify all the renewal controllers and other functions into a single roll based system.
3 Likes
Does this only apply to .eth 2LD?
The parent is the one who controls subname registry implementation through getSubregistry. For example, in a domain renting case, a parent can restrict the rentee from maliciously updating their registry.
It applies to all names, though of course it won’t be effective if the parent names aren’t also locked.
Curious how you are initially thinking about interoperability and composability. There are a couple opportunities for real innovation: the initial migration is a great opportunity to establish some cross-chain standards for non ERC-20s. Presumably we will also want asset support on the L2, what does liquidity look like and how do users get their assets on the chain?
This is a deep rabbit hole but want to begin the conversation around
- What is the entire set of items to be migrated
- How do the new items (that live on the L2) interact with the rest of the ethereum ecosystem
Also forgive any ignorance of information outlined in the design doc as I cant open the link (seems to be a local issue)
I like the new design of ENS v2. I think it will move ENS forward by a lot! Great job. Are you thinking about implementing features related to account abstraction in ENS v2? That could be cool because it opens ENS to more user-friendly use cases.
For example:
- minting and transferring subdomains for users on-chain
- gas-free reverse registration (that would be awesome)
- gas-free record-setting
Ideally, a dApp can be developed where every interaction with ENS only requires a signature. The dApp developer could set up something like a paymaster to take care of the actual transaction execution.
1 Like
Generally being AA and SCW friendly will be a goal for ENSv2.
1 Like