Designing for Irreversibility: Lessons from Shipping ENSv2

Transcript

[music] [music] Okay. Hello guys. Can you hear me? Yeah. Good. So, thank you for coming for our talk and my name is Makoto aka Matken and this is Kevin uh aka Walkman. and I'm protocol lead and yeah Kevin is a technical writer and today I want to talk about yeah how we ship basically in SV2 and hopefully people who are interested enough to come to this talk knows that we finally released uh V2 y thank you

[applause] thank you uh if you haven't tried our new and also not just protocol I think our front end got like brand new and we even got a two of them. And if you you have a ENS name already, uh if you migrate to V2, you get this cool uh NFT which kind of represents unique to you, you are kind of on chain activity. And this is uh the one from Nick Guest who is a founder of the ENS. Uh and today we going to focus on four topics. I'm covering first two topics of why did we create V2 to begin with and what's been changed throughout the journey to get to the release. It's almost like two years it happened and especially when we first

announced we said we'll go layer two but we ended up staying on layer one and we I going to touch upon why and Kevin going to talk about the challenges get got get to the point and also how we actually made it possible. So we we are here uh talking about V2 right now. Okay. And so yeah why we view V2? So I don't know how many of you guys kind of OG enough to experience like like D5 summer JPEG summer all the things like yeah okay here you go. Oh lots of ogs.

Interesting. So you might remember the days that like you know everything was going crazy and gas was super expensive. uh no exception to ENS. That's I I remember that I think at the height of it registering a name which usually cost like $5. Yeah, it cost 150. I just look into the deal and I just realized actually the high was $400 and people were still registering for it which is crazy but not I think when it gets to you know costing $450 to register $5 doesn't make sense. So that was a kind of critical moment when we have to start looking into the V2 uh sorry layer 2 and but then if we say we going to

transition our whole system to a different chain maybe we shouldn't rather just copy and paste what we already have but we should just step back and think through how we going to rebuild from scratch if we have opportunity to do so. So, and one of the stuff we wanted to tackle is this kind of subname issue that we had. Yeah. Yeah. 35 nearly 35 million names, but what's on chain on the layer one is actually the 972K under the ETH and the rest is mostly by so-called subname system mostly powered by using that technology called CCIP read which we kind of came up almost like five six years ago. Oh, by the way, the history

of EN actually who's OG enough that you in the space since 2017 okay still like maybe 20% impressive uh yeah and uh so the at the most of the high expensive gas is storage cost on the uh layer one so we came up with architecture called CCIP read which allows you to store name data on layer two yet we have this interperable way to be able to verify It's storage proof uh so that you can see and verify on uh layer one so that you don't have to make like a 100 chain connection to to read the data and uh then also that was a part of integrant.

Another ingredient is so if we wants to make the subname truly the your name one of the uh interesting thing is the ownership and you have to make sure no one can take the name away from you. Then the problem of the our initial design was that basically the parent name so like a issuer of subname was all always be able to claim subname's ownership which wasn't really great. So uh we came up with a so-called name wrapper in back in 2023 but as the name suggests it was to wrap what we already have rather than just rearchitecting from scratch. So because we had a given opportunity let's rearchitectate from scratch that's how we kind of started

and then yeah question two why L1 not the chain and I don't know if how many of you guys like following sorry for the journey we went through but we announced I think we had a workshop uh I think our rangaboo team did the initial research and in April we said yeah we do need a layer two and we did I think six about six months of research to come up with the initial partnership. But then we spend another uh year just thinking about actually the final configuration set and the on way we actually transition to partner with Nethermind but then three months later we actually said okay let's step back

actually we go to layer one. So we went to series of transitions and uh so one of the reason again it's not necessary to criticize any of the layer 2 but most of the layer 2 is mostly used for kind of defy usage but like naming system has its own kind of and especially how we architected for the interparability had a series of requirement there's two of them one is a kind of fast finality for the CCIP read to work but most of the layout to especially like optimistic rollups [clears throat] they usually take seven days to finalize and using our CCIP system that means even though you update the name you can't resolve on

L1 using storage proof for seven days which isn't really acceptable and you could you have a various ways to configure to make it quick but there's always tradeoff of like faster finality that it costs more to uh on the L1 Yes. And also this is if post I think it was the end of the 2025 that like they he kind of got frustrated of the progress of the kind of stage two of the you know interoperability and the censorship resistance stuff that basically the uh yeah like we still have there's I think during that time there's serious case that like a sequencer could kind of

sense L2's activity all the stuff uh that's a bit problematic for us because we are name service which uh deals with intellectual property and in the V1 we could say even if there's a lots of like take down notice and stuff we arake the system that no one can take ownership but if you own on L2 by its nature there's always for the central kind of hotspot people can kind of seize and stop so we want and then while we are thinking how do we mitigate or even if we can't start with the ideal setting how long it takes to get to ideal. Well, we weren't quite sure how long actually gets to the safe stage. Then why it's debating actually

L1's gas are getting cheaper the again the same chart I showed earlier uh gas for the registration start going down from the to 2025 and and by the time we we kind of made the decision the transaction for the I think this is trans for the registration is like 20 cents or something like that. So it and I think final kind of decider is again going to the June dashboard to figuring out the economic tradeoff that this is a chart of the all the transaction happened in the V1 system on layer one and I think when we started it was costing like on its high it was costing I think L1 all the transaction was about

50 million and there's always I think economic trade-off that for L2 to exist you have to have enough transaction to justify for the finalization cost. Uh but in again defi's case you need a high throughput and lots of transactions but in case of naming system it's not something you encourage to to interact all the time. It's more likely you know you register the name for like five or sometimes 10 years. So you only you could only transact with uh the chain like once every decade then it doesn't uh economically make sense was the decision we we reconlay at that time and now yeah I'm I'm pass to Kevin

>> thank you Makato um yeah now we have heard from Makoto like a little bit about the historical part of like why it was necessary to develop 2 and I want to talk a little bit about also like why was it hard and why did it take a long time to actually make it work? Um yeah, maybe like to go through a few reasons. Uh your name is yours. So this is like one of the kind of guarantees that came with ENS from the very beginning. Um and so migration is like voluntary opt-in user initiated process and V1 names keep resolving and you can also still renew your V1 name

indefinitely. the price for kind of to achieve this we had the price that we had to pay is kind of like a pre-migration process where we took all of the like the subset of onchain v1 names which was around like 900k um we had to reserve these names in ENSV2 and also sync it to make sure that every person that has an active v1 registration can claim the exact same name also in v2 and so that they not get for run by somebody right I will go a little bit more into detail about this process a little bit later. Um, another guarant gu guarantee like nobody can take the name away from you. So the smart contracts don't have like any

backd doorors and also they reference each other in an immutable fashion and uh the consequence of this um guarantee is that during the development of the NSV2 we had to be like very very sure that the core of the protocol is very sound [clears throat] and consistent and doesn't contain any like uh like dangerous flaws or bugs because after the deployment. Um, these might be essentially unreoverable or at least like you would need to pay like a huge huge price to fix this uh afterwards, right? Um, then buying a name is safe. People trade names similar to like NFTs in general.

And so, of course, from the users perspective, it should be safe and essentially like a no-brainer to buy and sell ENS names, right? And in V2, we shipped a new permission system. uh which is kind of like a follow-up to the name wrapper that Makoto mentioned earlier. Namewepper was kind of built to enable people to issue subnames right to their uh to the community essentially but also in a way so that these subnames can be emancipated which means essentially they are standing on their own and the parent cannot really interfere in uh yeah cannot interfere with this name and in v2 this was streamlined with a new permission system it's called enhanced access control and

uh because it's like a little bit like it's Well, like it's it's stronger like more u there are more options as compared to nameweber. And um this kind of required us to come up with a way to ensure that when you sell a name or or when you buy a name, you're not getting wacked because the previous owner might retain some permissions on that name. And one of the um ways this is achieved in ENSB2 is with mutable token IDs. So ENFV1 essentially had like 721 NFTs, 1155 NFTs, and these had fixed um token ids. But in V2 there's a process that's called uh it's called d regeneration

where actually if a permission is granted on the name or revoked. So the permission set changes the token is burned and minted again to the same owner with a different token ID. So if it was like listed on an uh on some sort of like exchange or marketplace um and the roads are changed afterwards while the offer is kind of standing the offer will goes there because the token ID changed right and there's also uh two transfer paths essentially like the safe default path which um kind of uh is based on this design and there's unsafe way to opt out if you like want to do this for some reason.

Um, so yeah, what made it possible to uh launch ENSV2? This is a chart showing the past year and the different phases we were going through um to launch NSV2. So we have multiple audit rounds and um also a public audit competition. You can see like the upper left corner is from March to September. And then the kind of second row shows the final Soria deployment after all of the audits were finished. We deployed to Sapoleia and also already deployed some contracts to mainet for some testing purposes.

And uh you can see if you uh like read a little bit more then root registry for example was redeployed because the wall was missing. This is like one of the things I was mentioning earlier like at this point it was fine but that's something that you really don't want to have when you actually go live on mainet and um one of the processes uh that is listed here the pre-migration is something that I want to talk about a little bit more now um essentially the main problem is like from a users user perspective there should be essentially like no downtime or no like real change like uh something that you can feel when we go from V1 to V2 and one of the biggest problems would

have been you have a V1 name and somebody comes and takes the exact same name on V2 and then we switch to V2 and then there's like [snorts] either a name collision or like somebody just took your name away right so we had to take all of the live V1 names and reserve them for the correct owners in V2 and this process called premigration and Um there is also like a a secondary problem which is there is there was some expected downtime in in uh ENS because we had at some point we had to switch the controllers from V1 to V2 and we wanted to minimize this downtime obviously and so what we were doing is

we uh enamorated all of the onchain names in V1 and then reserved them in the V2 registry on mainet contracts already, right? So this diagram shows like a simplified flow of this process. First there are 900k live names about like webbed and unwpped and the pre-migration script essentially check the status of all of these names on v1 and also on v2 to check if there's already like some uh reservation um in place and then kind of like batch register these names on v2 like batch reserve them and essentially what this would look like is you can see

here in this example the owner is just address no uh zero for some time and there's an ENS v1 resolver placed on this node in the ENSV2 hierarchy which essentially is just like a redirect right so if you resolve this name and it has not migrated to V2 then it will just kind of look in the V1 hierarchy and it will resolve as as normal um and when you decide to migrate you're essentially like kind of claiming the reserv the reserv the reserved slot in V2 right um The problem is with this uh with this process when we started the pre- migration um ENSB2 was not live and ENSB1 was still kind of live was live on

uh on on mainet. So registrations were open, renewals were open like the the set of names can change every day, right? So what we did is we went like um kind of like a bulk face in the in the first seven days and also kind of keeping in mind the gas price like stopping if it it hits some threshold and then starting again. And so like in the first seven days we reserved all of these names in V2 and then we had daily reruns where we would kind of sync new like names that have been renewed uh since the day before or new registration. We also sync these to V2, right? And then at the end on October 27th, we kind of the proposal was

already passed to activate the NSV2 and we kind of switched the controller from V1 to V2. And this is when uh the registrations on v1 were frozen and renewals were not possible for some time. And this was kind of like the last sync that we did for the premigration. Um yeah. So essentially like this is a process that is really uh um where it's really important to get it right because it incurred like around 8 or something in in gas costs, right? and the data is already in the V2 infrastructure and if we had discovered a bug later on in the E registry on V2 we had to go uh like redo the whole process and pay the price

again. So and actually on the day of the launch we figured out that around 250 names were missing from the pre-migration and that's because uh one RPC was under reportporting the events that that we were looking at. So it was just cut off. So like a lesson I think is that you should never only have one source of truth. You should have at least two I guess and make sure that they agree and they're internally consistent. And then uh other things we did to make sure that um the launch will be successful is of course like um besides the audits and the contest like do mainet fork tests where we actually take the DAO proposal which has the call data

to activate V2. So you kind of like do a time skip your fast forward time to see what will happen once this is live with some frame break. We did resolution tests like backward like backwards compatible resolution seeing how everything behaves are the subname safe and so on and so forth. All of these things um were very important of course and also there was like after the proposal passed there was also like a time lock and um yeah so these were the precautions we took and also like over the whole year there team at labs made sure that libraries are upgraded to ENSV2. Um the most important thing at least for like the resolution of ENS

names is using the universal resolver contract which um is kind of like the now like the standard way to resolve ENS names and get like text records and so on so forth from the uh ENS hierarchy and you can see like on the right hand side there's a graph um showing that we went from like 21% to 53% uh based on like mpm downloads of v2 two ready libraries. So, it's like a nice bump. Um, but I think it's a good time if you wanted some protocol or app to make sure that you bump up your libraries also.

Um, yeah. So, another thing like as part of the launch, we also released two apps, the ENS app and the ENS explorer. And on the beta launch on supporter, we also kind of um made sure that the community can use them so that we have like a little bit of time until the mainet launch to fix the most critical bugs or UI problems. And we launched a very nice uh NFT that Makoto showed earlier. Um yeah, that's that's all talk. Thank you very much.

Oh, >> thank you gentlemen. So, we have some questions from the audience already. >> So, let's jump straight into it. The first one is uh what was the hardest irreversible decision in shipping ENSV2 and why? >> Oh, that's also hard. I know. >> Okay. I didn't know that this live. [laughter] I was coming like someone who's questioning then. Yeah. What was the hardest irreversible decision? What was the hardest?

>> Uh, >> one hard decision. Probably many. >> That's really good question. Uh, let me think through what we are. [laughter] >> Okay, that's fine. Um, there's uh one question about um about Ethereum gas that's now supposed to be much better. Okay. Um and >> and like the question is like isn't isn't it like now problem kind of solved >> or or why moving to uh L2?

>> I can take those if you want. I mean is it this question? >> Well, I think he misunderstood because we ended up not going to layer two. >> Sorry. >> We didn't we ended up not going to layer two, right? So we did if we went to the layer two. Yeah. like why did we move but it's more about like a low lower gas allowed us to stay on L1 >> so >> okay >> I mean that I think when we deciding uh whether we go to L1 or L2 and we also had came across like why do we even upgrade but then we do have a lots of benefits of rearchitecting it and which thanks to this current gas price we

actually this new architecture It wasn't really possible when we we first came up to have it on L1 but now we can actually do it. Hence we stayed is a kind of answer. >> Yeah. >> Got it. Okay. Also >> um >> one of my own um probably from the techn um you probably tried it's not it's not over there. Um you probably had some issues uh by having both versions coexistence right >> and you test on test net probably. What was like first what people should be uh uh um concerned about or what should they watch for having those two uh uh coexist and were there any finding

testing those uh two coexistence? uh when we are testing the biggest worry is that the pre-migration is a rights to be able to migrate right but because we allow people to we don't force people to move so we we keep it but the biggest one of the biggest uh point is if we didn't m do premigration properly we could have missed some names to to reserve so people could just like kind of front without the existing owner migrating. So that was uh one of the uh scary point and that's not

something you can detect with the security audit because security audit is more mostly about smart contract itself but this is more about the operational thing. So that one again I think we we actually missed 250 on the initial one then but by having multiple source of truth we could detect it. So that was one of the yeah uh concern >> um and we have probably [snorts] time for one more um with ENSV2 if a user migrates their name to the new registry will indexer still need to relay on rainbow table uh tables to uh to resolve name hashes back to

human uh readable names or is it addressed already? Uh we did change we no longer use the uh label hash and name hash uh for the v2. So I think it was a that was a I think a coded version of the yeah so it has a full text so you don't need to resort to rainbow. However, I think some of the all the east names when you migrate uh we were able I think the second level east name we were able to detect all the names but some of the sub names we

couldn't actually uh to m to be able to migrate we need to know the name and for the do east name we knew everything because even though the registry itself didn't have the decod all the information controller had it uh so by using that we got everything but for the sub name I think we could one able to pre-register so in that case but because owner is the same person so they could just do it yeah uh but to answer quickly I think for the v2 yeah you don't have to use rainbow table is a short answer yeah >> okay so uh yes we're out of time although

like we still haven't answered all questions. Um so thank you thank you and uh for your insightful [music]