.eth 2.0: Dissecting the Design of ENS v2 and Migration Steps

Transcript

Hey, hey guys. Um, so I'm going to talk about ENSV2 today and talk about how ENSV2 is designed and u been somehow implemented and how does the migration step work from ENSV1 to ENSV2. So here's a um brief introduction about myself. Um I'm just an extraordinary dev and somehow do open source software contribution in Ethereum ecosystem and now I'm focusing on ZK privacy and protocol design kind of stuff and I used to do core smart contract at harvest finance and I co-host E Taipei ZK Taipei and I love to do privacy related residency and um since I'm doing the

talk in English today um I have written a article about ENSV2 a couple months months ago in Mandarin. So if you guys are interested, feel free to look into that article as well. And I also created a group chat so that if any of you have um other questions after this talk, feel free to ask in it and and I I will share as much information I have um to every one of you. Um, a disclosure is that I'm only doing this as a um as my interest and hobby in ENS and I'm not affiliate affiliated with ENS. So, this is purely my study and my understanding of ENSV2.

So, today I'm going to Oh, so before we start, I want to ask um how many of you have heard of ENS before? Can you raise a hand? Okay, like a third. Um, and how many of you own an ENS? Okay. Yeah, roughly. So um I'm going to slightly talk about what is ENS and how does ENSV1 work and what are the ENSV1 limitations that bring into um the change of ENSV2 and what are the challenges of migration and name resolution um during the implementation of the ENSV2 and kind of dive in dive deep dive

into the uh some of the implementation of the ENS SV2 and also bring out some tips um if you're new to ENS and what can you do um within within the ENS ecosystem. Okay, so let's talk about um what is ENS actually. So ENS is the domain name system for Ethereum. So if we're going to access a website um in a traditional internet world, we have to look up a specific domain name um into a DNS server and to get the IP address of the website so that we know we can know where do we ask where do we have the IP

address to access the website. So this is kind of the idea of a domain name system to abstract things and make things easier into human readable um text that will be easier for the user to access. And so in a ethereum kind of blockchain world um what can it brings to the user? So I'll use a money transfer example. So if we want to transfer money to our friends, we'll often have to ask what is your bank account and where can I send the money to you. So it often bring out um sending a long text about which bank it is, what is the bank account number sort of

things. Um and that's also the case in Ethereum ecosystem. But with ENS things changed when you're sending money to your friends. Your friends can simply said that oh what is my username? Like I'm vitalic. And the only thing that you'll need to do is to look up this u username into the ENS protocol and the ENS protocol will do name resolution back to you saying that what address tied to this ENS name and so you'll know or your application or your wallet will know where do they send the money to. So that kind of abstract all the user experience

and make everything easier for the user. So the reason why ENS matters in Ethereum ecosystem is it brings a human readable um text to all kinds of application or protocols um to replace addresses with memorable names and also extensible. I'll bring out this um in the following pages. But it not only can store uh what this username represent as an address, it can also represent other things like content hash and text. And also because of this extensible feature, it can also be a new web3 identity for user in the blockchain world that um you can store

all sort of things or all sort of records that you want to u bring with you into different applications and it also aligns with the blockchain core value which is decentralization per permissionless and credit neutral. So here's the common use case and it's also why it not only represent addresses, it also represent content hash and also represent um text. So uh you can see the red boxes that I highlighted. So it can simply represent wallet address. So you'll know that what this username tied to which address on the blockchain and also it do

multi-chain support. Um if you're not familiar um I'll talk more about what multi-chain and what layer 2 layer 1 represent in this ecosystem. Um but it do support modi chain which is uh you can use this username across all the chain in the ethereum ecosystem and also it represent IPFS content which is a decentralized web content storage service. So you can simply store a IPFS hash to your ENS username and that can be resolved into a decentralized web service like using e limo or something.

Um and also it can tie to traditional service like uh GitHub or like Twitter account. So you can so store all sort of things to this decentralized identity representation. So which brings it to so much potential beyond just resolving a username to a address. Okay. So that's kind of what ENS uh can do and what it represent. And I'm now going to slightly talk about how ENSV1 actually work. So there are two comp core component in inside ENSV1. The first one is the registry. The registry is you can simply understand it as a table that store oh this name uh who's the owner of this

name and what is the resolver of this name and the resolver I'll talk about in the next slide but the resolver um is will be stored also inside the registry. So um if you were trying to resolve a username, you first interact with registry to get the resolver tied to that uh ENS username. So if I'm trying to figure out what vitalic eeth linked to which address, I'll first get the resolver which is 0x123A in this case. And once I have the resolver address, I'll then interact with the resolver. So the resolver is a independent contract that store all the record that we just mentioned like

addresses content hash and text um that tie to a user. So once we have the resolver we'll interact with the resolver to get all the records that tie to that user. So here are the complete flow of how user interact with registry and resolver. So first you get the resolver that tied to that username and once you have that address you interact with the resolver itself to get the specific uh specific record that you want to access like address text and content hash and so that's how the resolution work and I'm going to slightly talk about registration flow um because this is a core limitations that NSV2 is trying to

solve. So in a blockchain world there is a case that transaction will get frontr run which is mean that um you're sending a transaction but if someone u managed to find a way to send transaction faster than you um your transaction will not be executed and you'll be um your your transaction will fail and the transaction happened be before you um will successfully executed and that will be the success case. So uh in order to protect the user we want the people that trying to registrate the username uh can successfully registrate the username. So we have to design a mechanism to uh

overcome this limitation. So this is a commit and reveal kind of scheme that is commonly used inside the blockchain world. Do you have a question? Oh no nothing. Um and so this is commit and reveal. So commit and reveal require two transaction for a user to registrate a username. So first you commit a a a list of um information that you want to register your username in the later transaction. So in this case you'll register um the duration of the username and the owner of the username and the label which is actually uh take vital.

For example, it will be vital itself and the duration will be how long do you want to own this username. So first you commit this hash into the contract and then um after a minute you will send another transaction to co-register in which you reveal um all the information that you committed hashed in a previous transaction and if those uh information matched uh we can identify that a minute ago you were the one that you were the one that sent the commitment and we'll know that oh yeah you have commit before and we'll give this username to you and then in the last step we'll transfer or

meant the ENS name um which is implemented in ERC721 but you can just think it as a name card to the user itself so we'll need this kind of mechanism to prevent um front run in ENSV1 um so that just got give everyone a brief idea about how um ENSV1 overcome come this. So here's the a couple feature that enosv1 has it's mainet center like everything is on mainet and one singleton registry which is mean that um every username all the record you can access through a single registry contract like the lookup table that um

we we mentioned in a couple slides before. So take ETH for example ETH have a registry contract where we can get all our information that we need and also it's ERC721 um based so all ENS name is a ERC721 token so that's um some of the feature that ENSV1 has but also these springs to the limitation of ENSV1 so since it's mainet center it requires There's high gas fee in a compact uh condensed network uh situation that user have to pay a high gas fee to register their ENS name to set record to do all

kinds of transaction and all kinds of action for the user and also because um it's one singleton registry um so it'll be a bit hard for what what we call subname management I'll talk about subname in the next slide but you can imagine um subname as a name that's underneath your ENS name. Like if you're vitalic, you can imagine it like different path under a domain name. So take vitalic.eth for example, you can be app.vallic.eth or doc.vallic.eth.

So each different subname belongs to vitalic.eth is also being stored inside the same registry contract. So what we can imagine is that if vitalic this username is expired and this name is been transferred to other user all the previous store record like docu.vitaliketh app.vitalic will still remain in the same state onchain. So everything everything record every every sort of things that we store before will remain unchange. So the new user will have to um replace all the previous record himself. So it'll be a bit complicated and also it's all

implemented in ERC 721. So it's um if you know ERC 11155 it's also a um a bit not that extensible comparing to ERC 1155. Yeah. So um in a previous slide we talked about sub name. So this is kind of how subname is work. So in a most simple use case subname is also a record just like text content hash and address that tie to a ENS name. So like sub 2, sub 1, sub3 uh nameeth. Um it's just a record that tied to the nameeth. So no token or

no feature no um utilities uh tied to that subname. So in order to give utility or to give the ownership of that subname we uh ins created something we call name wrapper. So name wrapper is a wrapper around the original ens. So the idea is to transfer the original um ENS name into a ERC155 contract and that contract will be the new owner of the original ENS name and all the subname will be issued as a

ERC155 token. Um after that and they created something called fuses which is um a permission system one-way permission system is why it called fuses. So once you burn it or once you initiate it there's no way going back. Um so they created this oneway permission system for the name wrapper in order to give more utilities to the subnameo holders. So um it can gives them permission to transfer the token to set their own resolver and to um do their own subnames like um like the fourth layer of the

subnames tied to that ERC 1155 token. So it's a bit complicated to do subnames in the ENSV1. So adding up with all these difficulties that they encounter in ENSV v1 they proposed the ENSV2. So the main issue that they want to solve the first one is the subname limitation that we just talked about and also the high gas fee that um that's been caused by staying on layer 1 and their solution will be this the ENSV2 which is a whole system architecture that reimplemented a lot of the core ENS contract and also they do

their own layer 2 their rollup called namechain to resolve the high gas fee. So this is how ENSV1 work. It's a flat registry one registry and store all the different ETH name to it. And in ENFV ENSV2 they turn this flat registry into a hierarchical registry which makes it customizable. Um each owner of their ENS name they have their own registry so they can decide their own issuance roles. So their ownership roles and once the name has been transferred they can just placed it with another new um empty registry. So all

the previous record will be washed away. [snorts] So it's a lot a lot easier for a new owner to manage the name. And then we talk about the name chain. So a couple question I have um about they once they announced namechain is why do they want their own rollup and what kind of rollup do they want and how do they build their own rollup. So why do they need their own rollup is because um back in the day uh when ENSV1 is implemented there's no such thing as as rollup or it it's not been well explored yet so no one is know what is really the scalable uh solution in the

future so L2 centric isn't a thing during that time so but now with L2 is entering a L2 centric era they want to be L2 agnostic which means that they don't want to uh stand with a specific layer two. They want their own layer two so that they can work with everyone. They don't want to be friendly with a specific there to like they are only um supporting them and also with their own name chain their own rule up they can reduce the gas fee and they can also provide gas subsidies to the user to um to to compensate them with registering name and also in V1 they use ETH as the name pricing and now with their own

namechain they can do USD pricing and also they can do instant registration. Unlike in ENSV1 you have to do commit and reveal. Now with their own chain they can do instant registration because um in their own chain they can decide what the block time and with uh then the new tech that block time can be reduced significantly and about what kind of rollup they have been discussing for a while about whe whether to use the op rollup or to use the zk rollup and at the end they decide to go with zk because of the faster layer one finality and this is super important I'll talk about in the later implementation. Why uh instant or or fast finality is important in a name

resolution case and then how do they build their own rollup as we know building rollup is a super complex thing. So they choose they are deciding amount which rollup as a service they want to go to. So they have discussed about optack or using arbitrum nitro and all kinds of zkms that are popular today and at the end they go with the linear using the zkm um as they have a close relationship of working together on the subname and also uh in the linear zkm it's a type 2 zk um roll up and it takes only two epoch time to reach the L1

finality. And so once they decide all the things they want to do the next step will be what are the biggest challenges they encounter. So the first thing is how does the migration work? How do they migrate the user from ENSV1 and how does the backward compatibility work? How do they also support um the previous user even the previous user don't migrate to V2 they can also support and resolve their um V1 name so this is kind of the core important part about how ENSV2 is using and um I talk about two action today the first one is migrate how

migrate work how do they move their chain between uh move their name between layer 1 and layer two and how does the name resolution work and for first part I'm going to talk about how migration work. So this is the migration flow. So the key point is that it's a layer 1 plus layer 2 solution. So no one is being left behind. You can keep your name in either chain and you can decide by the user itself. So first of all the user sent their uh username their ERC 721 or 1155 to the migration controller contract and as we talk about the name wrapper if it's a ERC1 1155 which is

mean it's a subname it will unwrap the subname first if it's a top level domain name then it won't go through the unwrap and the user can then have two step to decide whether they want to migrate their name to stay on layer 1 or they want to migrate their name to layer two. So if the user decide to stay on layer 1, it will just call the ejection controller and the ejection controller will just call the registry v2 to register the name. So it's pretty simple. And um if you want to migrate to layer 2, it will send a message to their namechain bridge. And the name bridge will send a message to the bridge

controller on layer 2 and mint a not not mint transfer the ERC 1155 new ENSV2 name to the user. And uh why we say it's transfer is because before the name chain is been deployed all the record in ENSV1 will be snapshot and sync to ENSV2. So all the name will be minted to the bridge controller uh while on namechain. So it will just um been minted already and so it'll just be purely transferred to the user in this case. So this is why ZK is important. Um this is why instant finality is important because the name will either behold on ejection controller uh be

behold on migration controller because the user uh transport the name to here or it'll be hold on bridge controller. So there will be a time where the owner is not actually the owner of the ENS token because the token will be hold inside either the bridge controller or the migration controller. So ENS will want to have faster finality so that their resolution can work successfully to know whether the name is on layer 2 or whether the name is on layer one. So once we um finish the tackle the first difficulty which is the migration then we focus on the backward compatibility.

So this is how um with the ENS v2 and v1 the backward compatibility resolver actually work. So the user calls a contract called universal resolver v2. You can just understand it as a single entry to resolve all the name and it will call the root registry to get the um for take for example the ETH name belongs to which registry and it will returns it to the the address of ETH registry and once we figure out which registry this name belongs the user can interact with it with the specific registry and to get the resolver like in the ENSV1 resolving

um process to get um where do I actually interact with the resolver to get the exact um record that I want. So in this case uh in layer 1 there will be a ETH fallback resolver. So in my understanding in the ENSV2 registry all name unlike um in v1 has their specific resolver they will all point to ETH fallback resolver and so no matter what name you own um once ENSV2 has been deployed your name will be linked to ENS ETH fallback resolver so all uh resol resolution go through ETH

fallback back resolver and in the ethobback resolver there's two paths to decide how to resolve the name. If you haven't migrated it'll just point you to the original universal resolver v1 um which resolve the v1 name and if your name has been migrated to v2 it will call the name chain to do ccip what we call wildcard resolution and it's a bit complex but you can just imagine it as um there's two way one v1 and one v2 and it can work either way. So no matter you migrate your name or not, whether you migrate your name to layer 1 or layer 2, all three option can be successfully resolved with the ETH fallback resolver.

So does this impact their partners? um it it will be pretty simple for the partners to upgrade to ENSV2 because um for their partner they either interact with ENSJS package to get the name resolve or they interact with the universal resolver um to resolve the name. So in either case, ENS labs uh can simply just upgrade um the address that pointed to for resolving to universal resolver v2. And if you're a protocol that you resolve directly with a contract, you can just upgrade the contract address to universal resolver v2 as well. And if you're an app

developer, you can just upgrade to the latest ENSJS package so that um you know where um resolver the the address of the universal resolver v2s. So it'll be pretty simple to upgrade to NSV2 for all kinds of partners. So with um solving the ENSV2 and the name chain um the the whole protocol can have zero down zero downtime for name resolution and for the user they can have opt-in control decide how they want to migrate their names and with the name chain uh user can have guest subsidies and also have backward compatible name

resolution. So the the with the whole system architecture like this um we're going to slightly talk about how um the the core contract actually work. So this is the migration and ejection controller. So um to simply understand it you can just understand it as there's two step. Um in this part you can decide uh the user can decide they want to keep their name on layer one. So it just interact with the layer 1 ejection controller to migrate their name to layer 1. And if you want to move your name to layer two, it will just send a

uh message to the bridge to move your name to layer 2. And if we want to use the eback resolver um first it just um verify your name and suffix. It's a uh I I I can just simply talk a bit about this. Um this might be too complex for most of the user but first it just verify the name and suffix to see that the name is actually the one that you're trying to resolve. And um if your name is just purely ETH um it'll just call the ETH resolver. And if your name is still on v1 it'll just call the universal resolver v1.

And if your name is on v2, it will form a complex request called from CCIP and interact with the name. Um CCIP is a big topic. So if anyone is interested in this um I can provide more links in the future but um you can imagine it as a off-chain name resolution but being able to verify onchain. Okay. So lastly, I'm going to talk a bit about some ideas that if you're a newcomers to the ENS ecosystem, what it can do. So first, you can register your own ENS name. And here's the NS app and you can just reg register your ETH name here. And if you want to get your

subname, you can use Coinbase and UNISOP. They provide free subnames to their user. And um they also work with GoDaddy. So it doesn't work only one way for ETH2 address. You can use also use um traditional DNS name to link to your onchain address. And you can also bring your DNS into ENS, bring your traditional website onchain into an ENS name um with a complex tag um which is for another day.

But if you have a DNS name like coscop.org, or you can also bring this as a ENS onchain and to bring subnames to your user. Okay, that'll be all for today and here are some resource and reference um for anyone is interested to dive in more and these are the links that I shared in the previous slide. So if anyone has any questions or things want to talk about more I can share more detail in there. Um but yeah, that'll be pretty much for today. Um to see if anyone has any questions.

>> Okay, >> thanks to Ryan and Oh, so nice talk. And um uh maybe we have one question for um does anyone have questions? No. Okay. I might be do some research about how to migrate my um ENS handle to the V2 tonight. Okay. So, thanks to Ryan and