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.
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?
The reason to not shutdown ENSv1 is because people already have built stuff for it and they want to keep running that stuff without being forced to build all new tools.
Iâm quite happy with ENSv1 and I see no advantages for me to move to ENSv2. However, you will be turning the lights of ENSv1 off and there is nothing I can do to keep using ENSv1 like I have been. This is problematic and will cause me to keep my eyes out for an alternative naming system because I donât want a system that can be turned off or bricked after I have built integrations, tools, setup autonomous workflows, etc.
Even if I liked some ENSv2 feature and wanted to move, I would still hesitate because the forced upgrade shows a willingness and capacity to shutdown the system and I may not agree with changes in ENSv3 (e.g., perhaps it isnât censorship resistant which is a hard requirement for me).
Iâm specifically looking for an autonomous naming system, not one that continues to operate only because some DAO decides that they want to allow it to continue to operate as designed. The registry being DAO controlled was always something I grumbled at but I hoped that the DAO would never actually utilize its power to brick it, and one day the DAO would make it immutable. Instead, it seems that the DAO is eager to brick the ENSv1 registry which is the exact opposite behavior I expected when I got into ENS.
I feel like we are talking at cross-purposes here.
ENSv1 will continue to function for unmigrated names. Individual users can choose whether they migrate their names to v2; there is no âforced upgradeâ. If you want to, you can continue to renew your v1 name (though, using the v2 contracts to do so) and not migrate any records to v2, indefinitely.
If you want to write a future-proof, general purpose ENS resolver, you will need to update your resolution process to use v2, because otherwise you will only be able to resolve the subset of names that have not migrated from v1 to v2.
The only DAO power being used here is to control registry controllers - eg, to disable registration of new names on v1. Everything else is voluntary on the part of users; migration consists of transferring your v1 name to a contract that then issues you a matching v2 name and is, again, totally voluntary.
Importantly, this also means disabling renewals of existing names using existing tooling. If one has an autonomous system running that depends on autonomous renewals, the system will fail when the name runs out and if the keys have been thrown away (truly autonomous) it canât recover.
An example of such a system is an immutable name (perhaps a subname registry) where anyone can pay to renew the system, or perhaps the system collects fees from interactions and automatically pays the renewal fees. The system may have no way to transfer to ENSv2, it can only call the ENSv1 registry renewal function(s) and make payments.
To be clear, Iâm not saying that such systems necessarily exist today, but these are the types of systems I have considered building in the past and may build in the future. This forced move to ENSv2 tells me that even if I target ENSv2, the DAO has shown a will and capacity to make backward incompatible changes that could cause an immutable/autonomous system to cease functioning when ENSv3 comes around.
Tangentially related question: will ENSv1 subname registries still function as normal? I havenât looked deeply into the contract structure, but Iâm assuming that subnames can be registered/extended as normal without any changes? If the SLN moves to ENSv2, would the subname registry (on ETH mainnet) still be able to function without any changes?
Registration of new .eth names and renewal of ENS .eth names on L1 were never an immutable guarantee. Therefore, anyone who created an immutable system did so at their own risk. The most future-proof way of owning an ENS name is to simply register the name for a very long time, such as 50-100 years.
Also even if the original owner of the name no longer has the keys it will still be possible to renew the name on L2 by anyone.
I understanding that the registry was never guaranteed to be immutable, but until this point the power to halt the registry or use it to censor people hasnât been exercised and some of us were hoping that eventually the DAO would âthrow away the keysâ once it found a billing strategy that could work indefinitely.
This proposal makes it clear to everyone that the registry isnât just ânot censorship resistant yetâ, but rather it is something the DAO intends to utilize at least for forcing users to migrate to whatever new thing the DAO considers an improvement (regardless of whether users agree).
This gets into the philosophy of censorship resistance and immutability. Most systems, companies, governments, organizations, etc. throughout history always start out operated by people with good intentions, but eventually every single one gets captured in one way or another (due to its incentives) by people whose goals/values donât align with the systemâs users/citizens/customers. By building systems that are immutable, we ensure that no one has the power to capture/corrupt the system, because in the end it is end-users making a decision on what to use and they can continue using the old system indefinitely even if the people who built it would prefer users move to something new.
It is this power to force users onto a new platform, and a willingness to utilize that power, that concerns me. While I am a bit worried about moving ENS to an L2 because currently there are no censorship resistant L2s, the real issue here is that I donât think anyone should have the ability to force users of ENSv1 to move to ENSv2 if they donât want. If ENSv2 is great, everyone will move to it in time voluntarily.
The counterexample (on the surface) to immutability is the IPv4 vs IPv6 situation. Network effects are strong and many, Iâm sure, wish they could unilaterally force everyone to move to IPv6 by somehow shutting down or degrading IPv4 service quality. However, as frustrating as it is that the upgrade to IPv6 is opt-in, I think it is the right choice for humanity/society as a whole because it means that the power to shut off the internet doesnât really exist (I know this analogy is a bit of a stretch due to the way IP assignments work, but I think it works if you squint).
I am only talking about ânewâ .eth names and renewing .eth names, which are both controlled by the ENS DAO. The existing ENS names in the L1 registry are not controlled by the ENS DAO.
As Iâve mentioned previously, anyone can renew any name - so if the system fails to autonomously renew itself, anyone else can renew it on the systemâs behalf.
Further, thereâs a history of upgrading and replacing renewal controllers, so there was never any expectation that the address to which you could send renewal transactions would remain consistent.
Since migration is entirely optional, you can keep operating a v1 subname registry indefinitely; such names simply wonât be able to be migrated to v2 until the parent name is.
Again, everything about this migration is opt-in. Nobody is being forced to do anything.
An autonomous system would cease being autonomous if it starts relying on independent third parties to altruistically do what was previously done autonomously by the contract(s). This scenario is what Iâm frustrated with, where one cannot build an autonomous system on ENS. At best it would be autonomous for a while and then the registry would be disabled (replaced by v3) and it would become non-autonomous.
To approach this from another angle: Lets say you release v2, and then ENS DAO is captured by special interest groups and they propose a v3 upgrade. You dislike the changes in v3, but ENS DAO has the ability to disable the v2 registry. You do not want to move to ENS v3, but you also cannot continue to fully utilize ENS v2 because no new names can be registered and existing names cannot be renewed, they can only be migrated. The only option for you at this point is to go build your own new not-ENS naming system.
The only defense against this (aside from solving the problem of avoiding capture and ethos drift that humans have been trying to solve since the dawn of civilization) is to make it so ENS DAO does not have the power to disable the registry. I was generally fine with ENS DAO taking their time on figuring out how to best do this (which is why I havenât complained in the past), but this change signals that there are not plans to disable the registry, and instead the registry is used to retain the power to change ENS functionality broadly over time (e.g., v1 â v2 â v3).
I suppose this means someone could create a subname like og-ens.eth and then deploy an immutable registry at that location, which would essentially ossify ENSv1 forever, but just as a subname. Has any thought been given to the ENS team doing this in an âofficialâ capacity and perhaps using a single character subname like 1.eth? This would give those people who have a strong desire for immutability a place to go that opts out of the ENSv2 migration.
Would it be reasonable for the ENS DAO to allow for free name extensions (not new registrations) prior to the ENSv1 registry being disabled? This would allow anyone who wants to stay on ENSv1 the ability to do so without encountering high costs. Perhaps this could be accompanied with a condition that any âfree extensionâ doesnât get migrated to ENSv2 (only paid extensions do). To protect against squatters leveraging this, you could also make it so only non-transferrable/immutable namese can leverage this free extension.
The registrar controller has always been an upgradeable/replaceable component, because we rely on oracles for pricing. Itâs been upgraded several times over the life of ENS both for oracle changes and feature improvements, and because of our reliance on oracles itâs not plausible that we can lock it in permanently any time in the future.
All of which is to say that nobody has historically been able to rely on using a single contract and method indefinitely to renew a domain. This migration is no different to any other and doesnât break any expectations in this manner.
As Iâve said several times now, the upgrade is opt-in. The DAO cannot disable the registry - v1 or v2.
Existing names will be able to be renewed without migration. Renewal will require calling a method on the v2 deployment, but will extend the life of the unmigrated name.
The ENS DAO does not have the power to disable the registry.
I donât really understand what youâre proposing here.
No. That would effectively mean giving away registrations for free, and as noted above, unmigrated names can still be renewed under v2, without migrating the name.
That would entail some kind of split, whereby a name could have expired and been reregistered on v2, while still remaining valid on v1. The upshot of this would be that the same name would resolve to different addresses depending on which version of ENS you are resolving against. Avoiding this is a non-negotiable goal of ENS, because it leads directly to loss of user funds.
For a bit of context, this ENSv2 upgrade/migration is being weighed in my head against the counterfactual world where ENSv2 is just a new naming system with a new TLD like .eth2 or .ens2 or something. To me, that is the ideal solution as it truly is 100% opt-in, where people can use ENSv1 or ENSv2 in their full capacity forever. In such a world, ENSv1 would eventually make the registry immutable (and get rid of the off-chain oracle) and it would go into maintenance mode with an immutable UI, immutable contracts, and all future work would occur on ENSv2.
This is not as bad as I originally understood, so that is good. I thought the name had to migrate to v2 in order to be renewed. I didnât realize you could renew in ENSv2 but leave the name in ENSv1 forever. (still not a fan for other reasons, but I concede that the situation is slightly less bad than I thought)
I think our disagreement may be around what the definition of âopt-inâ is. To me, âopt-inâ means one can continue using all of the functionality of v1 without having to move to v2 ever. IIUC, your definition of opt-in means that people who previously registered on v1 can continue using their v1 names as-is until they expire (at which point they can use v2 to extend their v1 name). If my representation of your usage of the term correct, then I think it gets to the heart of our disagreement.
This is news to me. Perhaps I misunderstood or was given bad information long ago, but I thought the registry being mutable was meant to be a temporary solution while the ENS team experimented with a number of different pricing strategies (e.g., harberger tax, auctions, etc.). I thought the long term goal was to make the registry for .eth immutable eventually, but you all didnât want to delay launch until all the problems were solved.
Canât ENS DAO disable renewals and registrations entirely? If they can, that is functionally the power to disable the registry. (note: Iâm using the term registry here as a separate thing from the resolver, but maybe Iâm using the wrong terms)
ENS DAO registers v1.eth name with uint_max expiry.
Setup v1.eth as a subname registry.
Enable subname auctions and fix the renewal price in ETH or as a function of gas price or something else that doesnât require an off-chain oracle.
Burn fuses necessary to make v1.eth an immutable subname registry.
Continue to support registration of *.v1.eth names in the UI indefinitely (or at least build an immutable UI and libraries for it).
At launch of ENSv2, create the same for *.v2.eth on ENSv2.
While anyone could do these steps except for the uint_max expiry and a 1-2 letter SLN, having ENS DAO do it and promise UI support for it is a strong show of good faith/credible neutrality that ENS DAO will continue to support ENSv1 indefinitely. It also shows a willingness to work towards true protocol immutability, even if it isnât perfect. Importantly, this would set a precedent for future ENS upgrades so people donât have to worry about ens v5 adding censorship and leaving them out in the cold with their names, tooling, integrations, etc. A user particularly concerned about this could register a subname of v2.eth rather than .eth as they have a credible commitment from the ENS team that theyâll be able to continue using v2.eth indefinitely as they are today.
What is the problem with giving something away for free here? ENS is not a profit seeking entity, and I feel like the constraints I listed would make it so the only people who actually took you up on the offer are people building immutable names for things (not squatters). I havenât put a huge amount of thought into this, but it seems like at least on the surface it could be a tractable solution that has limited gamability.
Sorry, I think I was being a bit too terse here. Iâm not proposing that ENSv2 would be âblindâ to the free extension and see a different expiry date than v1 saw. What I meant was that if a user took the free extension option, they would be unable to migrate to v2 until the extension ran out (essentially the name is stuck on ENSv1 until free expiry ends).
I would love for that to be the case - but so far nobody has come up with a solution that eliminates external, mutable dependencies, and is reliable and resistant to attack. There may still be such a system, but at this point itâs safer to plan as if there is not.
Yes, the DAO can do that. Thatâs very different to disabling the registry entirely, because all existing names continue to function and can be transferred, updated, and resolved. Thereâs also a timelock period during which anyone could register or renew any name for an unlimited period before any changes took effect.
This isnât really supporting ENS v1 though, is it? Itâs creating a new, immutable naming system on a subdomain. That sounds like a good idea, but itâs orthogonal to the ENS migration to L2.
Registration fees exist to prevent the entire namespace being speculatively registered indefinitely and thereafter sold off exclusively via the secondary market. If there was a period when you could register or renew a name for free, the entire namespace would be bought up pretty much instantaneously.
I donât think thereâs really anything to gain here. Users can extend on v1 pre-migration for as long as they like if theyâre concerned, and post-migration they can extend even unmigrated names via L2. Meanwhile, to have a coherent view of the namespace, all clients (eg, software resolving names) will have to upgrade to resolving via v2 regardless of this.
I think perhaps this is the part that is actually bugging me, but my brain was previously struggling to recognize it coherently until you expressed it succinctly here.
Imagine ENSv2 was not benevolent, and part of the ENSv2 protocol or officially supported libraries censored existing registrations. Perhaps an OFAC style blacklist embedded into the official libraries or as part of the ENSv2 protocol. People who donât like it cannot stay on old ENSv1 clients without essentially forking away from the rest of the network, but if they want to move to ENSv2 they cannot use official ENS software without participating in censorship. If the censorship is baked deeply into the protocol, this censorship may be difficult or impossible (depending on the mechanism of censorship) to bypass even with substantial engineering effort.
By normalizing the idea that ENS version upgrades require all clients to update in order to not fork away from the ENS network, it introduces an opportunity for a malevolent (misguided/captured) ENS DAO to introduce changes that the userbase may not appreciate. This is similar to my position on the normalization of L1 upgrades, and how slow ethos shift over time can result in a âboiling frogâ scenario where people keep moving to ENSvNext because each step is only slightly less ethos aligned than the previous, and there is no clear opportunity for the broader community to fork away from the network.
It is particularly problematic with ENS because name resolution is rarely handled by end-users, it is handled by browsers, operating systems, applications, etc. This means that end-users arenât the ones that are ultimately making a decision on whether to upgrade to ENSv2 or not, it is a small number of people who may have more financial interest in âfollowing the leaderâ than âfollowing the ethosâ.
I would much rather see ENS DAO normalize/ossify the meme that they will never use their position of authority to force a client upgrade onto the userbase, even if this upgrade is not violating the original ENS ethos.
I understand your concerns here. Ossification isnât a non-goal - but I believe this particular upgrade is crucial to securing ENSâs long-term relevance by moving more functionality off L1 and the transaction fees it imposes.
I think the main question is not whether the ENS protocol will be upgradedâupgrades are necessary to stay up to date with the tech landscape and continue to meet users where they are. Instead, I think the main question is who decides what to upgrade to.
Upgrades require clients to change their code, which is essentially asking clients to vote on the upgrade. If clients donât want to make changes, then the protocol wonât be changed. Ossification of the ENS protocol will take place when a diverse set of ecosystem participants, including on-chain apps, clients such as wallets, offchain software, indexers, and eventually decentralized validators and sequencers for a âstage 2â rollup, arrive at the conclusion that the protocol has become sufficiently stable and major upgrades are no longer necessary.
There are a number of ways that the ENS DAO can become less relied upon in the ENS protocol. Currently, with the design of ENS V2, it relies upon connecting ENS L2 with L1 Ethereum using CCIP-Read, using the resolver of .eth. This is a standard way to resolve ENS names offchain and from L2s; however, the offchain resolver canât be âburnedâ because there is an offchain URL dependencyâthe list of gateways that resolve the name from L2 to L1 with proofs. In terms of reducing ENS DAO control, it would be better if clients simply resolved L2 ENS names directly themselves using the chain ID and smart contract address of the V2 registry. This would require the clients to âspecial caseâ the .eth TLD, which is entirely possible, and is actually something that could be proposed by anyone in the ENS community. Clients are the ones who will decide in the end, and all it would require is proposing an ENSIP and getting enough support for it.
Overall, the goal should be to keep the root L1 and L2 registries simple, basically managing the ownership and records of a name. Other functionality should be pushed as much as possible into the hands of a diverse community of ENS ecosystem participants, who all get a vote in how ENS will be upgraded over time.
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?