Identity in Your Apps with ENS - ETHGlobal Bangkok 2024

[Music] hello I am Greg devil at ens labs and today we're going to be talking about ens as a source of identity in your apps so first of all let's answer the question what is ens uh the ethereum name service is a decentralized permissionless naming protocol that lives on ethereum and scales to the entire internet basically we turn complex hex addresses into human readable names and so up top you see my address is ox 179a and so on obviously nobody is going to remember this it's hard to understand it's confusing and so on but instead of that using Greg scroll. eth is a human readable name that people can understand and it's easy to send assets to or represent me kind of on chain and online so a common way to understand ens is similar to DNS you know DNS is everywhere it's in the browsers that we use every day uh it maps IP addresses to human readable names so instead of typing in an IP address in a browser you type in google.com and similarly for ens instead of typing in an address basically anywhere I use this address Greg scroll. eth represents me instead and so if you can think about anywhere browsers show IP addresses you should use names similarly anywhere you read or write an sorry you write an address you should be able to use an ens name so on the left you can see ether scan an example of where you would see a list of people sending transactions and it shows luke. eth sending something in to Greg grr.

eth that is so much easier to understand than something like what's right below it of me interacting with a smart contract that just has an address Ox 554 F and so on that means nothing to me but a transfer of luke. eth into Greg sc. eth very easy to understand just at first glance and on the right hand side you can see the kind of opposite right so not looking at something that happened in the past but me sending assets to Greg scroll. I just type in the name easy to remember easy to type and it just works in metamask wallet and in many other apps across the ecosystem so these two kind of features are different processes right we have forward resolution where typing in a name resolves to an address and it's actually a specific address on a different chain so I can store a different address for base than I can for op mainnet and so on and same for reverse resolution so I go from an address to a name and this is used in the example of ether skan that we saw earlier we call this primary names and as of basically last week you can also have a primary name for each L2 whereas previously it was just a primary name on mainnet and so I will talk a little bit more about that later um but that's just on test Nets now so some exciting new stuff to play around with anyways in started as this idea of a username you know just a name to address mapping but really over time it's moved into more of a profile so this is a view of Luke's profile right here in the back you can see he has a bunch of text records we call it basically accounts and general meta metadata he has a list of addresses across chains this is both evm and nonm so he has a Bitcoin address right there and all of this is kind of stored attached to his ens name because it's really a portable onchain profile more than it is just a web through username and so you should be thinking about from that perspective similarly this is again the primary name part when I sign into Apps across the ecosystem it will show me my name not only my address because again ens is my portable onchain identity and so why is this important the kind of goal here is that users of crypto powered experiences should never interact with hex addresses because they're confusing and long and just annoying right and then we take that a step further and say users of any experiences should never interact with hex address so it's 's goal to solve this you know this is the ethereum logo as we all know and love and the enss logo is actually designed to be a wrapper around ethereum because ens makes ethereum and crypto at large easier to use yeah it's a nice little detail that I think some people Miss um cool and so moving on what are the different types ofs names you know a lot of people just think eth is ens but that's actually not totally true so ens is the protocol but it supports a number of names e is the one and only native TLD so that's the one basically that we created and it is onchain and it is maximally decentralized and all that stuff but eness also supports DNS tlds so google.com Greg scroll.

XYZ I think I have that and and so on um these can all be used as an enss name and so anywhere you type a name yeah question Tom H how does that get involved with the yep so the question just to repeat for the recording is how does a DNS name work in DNS compared to a e name and the answer is exactly the same um anywhere you can use a e name you can also use a DNS name like a um assuming it's like enabled to do so you know so it doesn't work out of the box but there are very easy ways to configure an existing DNS domain to work within enss and I'll show you a little bit of a like live example of that in a second but so just to kind of like compare those two things D eth lives on Main ethereum it is maximally decentralized kind of our our gold uh our gold tier let's say and it's controlled by en Dow and there is a fee to register those names DNS on the other hand there is actually no protocol fee um so that's one way it differs the only reason there is a fee for doth is to keep a healthy namespace and avoid people just holding a DOI name forever that's not a healthy Nam space whereas DNS names they already have that and so because it's considered a safe namespace you can use it in ens the same way you can. eth ultimately one big difference though is that ownership is controlled by the DNS domain registar so name cheap god daddy and so on it is not as decentralized and onchain Native asth if you want to put it that way and then both of these names support offchain and L2 subnames or really they both support the same stock of like flexible data that you can do with the NS um and I'll explain more about this in a second but of subnames are the idea of having like sub. name. eth similar to how you can in the DNS world and if you do this again with eth or DNS there's no protocol fee developers have ultimate flexibility to kind of build what they want and this is made possible by a spec called ccip read or ERC 3668 which I'll show you a fun diagram for in a second but this is used by coinbase Unis swap Linea and more out in production you can see here the biggest one is actually cb. ID you know that's notth that is a DNS name that they imported into enss for free and gave out 12 million subnames of also for free so coinbase actually gave 12 million users a human readable blockchain name without paying ens a single dollar and that's pretty impactful when you think about it and the others are similar but they use a eth name so I'll do a quick overview of how ins works from the tech perspective the inss kind of core registry exists on Main ethereum and it stores a name side by side with a resolver and again you'll notice this registry stores both eth names and DNS names a resolver is what's responsible for kind of returning the data that is associated with a name and so here you see luke.

eth has a list of addresses text records and so on these are just stored internal contract storage which means it is again the most decentralized but also the most expensive because of main net gas I'll give a little shout out to the content hash record over here who is basically a way which is basically a way to turn a do e name into a decentralized website um I'm going to kind of skip over that for now but happy to take a question at the end for more an offchain resolver which is how you do the subnames like I mentioned previously is basically starts with the same data structure but you just return different results so instead of using internal contract storage you actually revert with a soft chain lookup and this is ccip read this standard for reverting with an offchain lookup and what that means is it tells the client to basically get data from elsewhere so if we look at this diagram the client let's say is metamask wallet the resolver is a smart contract contract on Main ethereum and the Gateway is an API that you have somewhere in your back end right I went to look up example. eth I ask the resolver what is the eth address of example. eth and it reverts with a soft chain lookup that basically tells metamask again in this example to basically ask the same question to this Gateway and then the Gateway will return some data that it gets from an offchain data source that offchain data source can really do anything it can fetch from a database it can fetch from a layer 2 Network and it is really implementation specific so whatever you want to do is possible with this architecture and then the cool part is that in this callback function so where you see the verify decode data it will actually verify the data that the Gateway returns and so this is how we have trustless L2 subnames in this callback function for example you can check that the state that was returned by the Gateway in on the right hand side actually exists on layer one just depending on the way layer two rollups work so Layer Two rollups occasionally post their state to Main ethereum and in this little verify call back function we can check that it's telling the truth the reasoning for this is that the Gateway can never lie and this is a trustless L2 setup so an L2 resolver looks like this which you'll notice is exactly the same as an offchain resolver because they both just adhere to ccip read and it is really up to implementation specific Logic for how you're doing where where you're reading from and so again the difference between offchain resolver and L2 resolver is really not too much from the surface they both use ccip read they both read from some offchain Gateway and it's just the Gateway in one scenario on the left reads from offchain data like a database whereas the right hand side reads data and returns storage proofs from a smart contract on layer two and then that verification logic that last step is really the difference the left has arbitrary verification so you're just trusting the operator of the Gateway where in the right hand side you're actually verifying the state root of the layer to itself again to have trustless L2 subnames on an enss name because it is significantly cheaper than onchain than like L1 records okay so I know that was a lot and I will have time for questions in just a few minutes but first I want to run you through a couple new resources so I'm going to have QR codes both on this slide and the next slide and then the following slide as well will be kind of like one QR code that includes that goes to a doc that has all these other ones so if you miss these first two it's okay but I want to take a second to highlight uh this new tool to issue L2 subnames and we're calling it Duren can you see that yes you can okay so Duran is basically an an opinionated approach to building L2 subnames with enns um this is what makes the cb. ID and the linear. eth and the b.

stuff Poss possible this has been possible for a while um but just a lot of moving pieces and honestly quite difficult so exactly for this audience for hackathon developers that want to quickly build something really like interesting on ens uh we came up with this and the idea I'll pull up the GitHub read me to kind of go through a quick overview but um this is basically yeah an opinioned way to do L2 subnames it makes it super easy it gives you one contract that you can customize and deploy to a number of layer tws and then all of a sudden you have a layer 2 smart contract where you can register names like sub. name. eth and that will work anywhere your ens names work normally uh and so again you'll have another opportunity to copy this QR code or the domain during. is just a really easy approach and so this is a brand new thing it literally launched a few hours ago so if you have any issues with it or if you have any questions this is what we want to see people building with the most and we will be by the booth in the back obviously helping people with it so that's the latest tooling for L2 subnames and then we have L2 primary names as I mentioned at the beginning primary names is kind of the second process in ens and what really turns it from an address or sorry from a web 3 username into a web 3 profile primary name is like anywhere you see an address online on ether scan on a dashboard anything like that you should be able to basically turn it into a name and that process of an address kind of declaring that they want to be known as a certain name currently on Main net is only possible on layer one and so again high gas fees but as of this week uh the contracts to do that on Layer Two are now live and so if I go back to this page uh it has information oops on how you can do exactly that and so docs. un.

domains we'll have information on a whole bunch of stuff including this but basically the idea is with Duren you can create L2 subnames for super cheap and then you can set the primary name for that account on whichever given chain that you're using via the L2 primary name kind of new feature and this provides an L2 native experience for your users and also easier for app developers because you don't have to handle every step of the process thanks to Duren like you would have had to so the combination of these two tools is kind of what we're looking for this weekend and the main prize which I will talk about in a second um but I'm just going to leave this screen up here for a second because this has a link to a notion page that includes basically quick start guides Snippets contact info Etc on all the stuff that I just discussed um and it looks like a couple people are still scanning so I'll keep this up here for another second cool and then these are our prizes So based on the everything that I just explained the three things that we're looking for the most or really the two things are best L2 subname experience that is built with Duran and uses L2 primary names this could be naming smart contracts this could be onboarding a new user through some consumer application excuse me uh and setting their primary name right away and kind of anything else that you might come up with we think this will be the most popular uh way to implement ens going forward and so this hackathon is really the first place that we're going to see people use it so very excited about that the second that I forgot to update the emoji for is about most creative use case of so obviously a lot of people are into Ai and agents right now if you're building AI agents maybe you can think about naming that with an enss with an ens name and so for example if you're using xmt or some messaging protocol you can go to message agent. eth effectively and get certain functionality whereas a different agent would have a different name this can also use Duran if you wanted to so it's just like creative use case um plus L2 primary name or just a creative use case on your own that could be unrelated another example here is something privacy related um that will kind of leave up to you but have some ideas if you want to come by the booth and ask questions and then lastly is best use of ens this is likely to be uh in L2 experience so there will probably be two winners of the first prize and the last prize both being L2 but generally any ens implementation is eligible to win best use of enss excuse me and these prizes will total $10,000 so again that is what I have for you we have uh three or four minutes for questions I think but this is the same QR code that was on the previous page so I'll just leave it up here for a minute as I take some questions um but yeah thank you thank you for coming yeah uh can you say that again um for for example we have a domain DNS name TLD um do something does it does it play nice with the durine or um the primary names do we change the resolver in yep so um basically L2 primary names work with any type of VNS name that can be eth on mainnet that can be e on layer 2 that can be um really anything yeah any to make not only is there any plan to make any uh name that is not a subname also configurable through a N2 yes uh we actually just announced anoun this week that ens will be launching a chain called name chain that is not really ready to be hacked on quite yet so in the future yes but for the sake of the hackathon no thank you yep uh I have a question about uh during Dev I I used the ccip tools with off change S Bar before what is the difference between oange s this yep so the question is what's the difference between ccip do tools which is another tool that we have and Duran basically ccip tools is built for totally offchain uh kind of setups which means reading data from a database or something like that and it has like signature verification so it's just trusting that the operator of the Gateway is returning the results that it wants to whereas durren takes a different approach and instead of reading from an offchain database it reads from a smart contract on Layer Two and so if I go over here you'll see in the Duran repo which is linked from dur dodev uh there are a few smart contracts and the one that you're actually going to be reading from and customizing is this and so you basically see a register function it stores that register function in this registry and when I go to resolve a name like let's say name. Duran dodev because you can have L2 subnames under a DNS name then you would end up basically reading from this layer to Smart contract so T tldr the difference is ccip ccip do tools is built for offchain data sources like a database whereas D.D is built for L2 stuff um but cool I hope that answered your questions I think we are out of time if you have anything else we are at the booth by the state um in the back corner so hope to see you there [Music]