ENS: Identity in Your Apps

[Music] so hey everyone I am Greg sc. eth with ens labs and today we're going to be talking about ens identity in your apps so quick overview we're going to be talking about what is ens why is it important what are the different types of ens names how does it work and then lastly some resources for the hackathon this weekend so first of all what is ens in a single sentence it's a decentral permissionless naming protocol that lives on ethereum and scales to the entire internet the really high level overview is that we turn complex hex addresses into human readable names so you might be familiar with DNS which turns IP addresses into normal web domains like this number to google.com um the problem in crypto is even worse and so we're turning these long hex addresses into simple readable names like nick. eth the goal is that anywhere you read or write address you should be able to use an ens name and so this is in the context of reading on the left hand side you can see uh ether scan a live Ledger seeing that luke. eth sent something to me Greg sc.

eth which is clearly a lot more clear than me Greg scr sending something to o x554 f and so on um and then in the writing context this is metamask um me sending ether to Greg scr instead of having to copy and paste an address really just again human readable names and this works in two different ways so there is forward resolution which is going from a name to an address so for example what you saw in metamask of typing in nick. eth and getting this long address and then there's also reverse resolution which is I as the owner of say Ox B8 in this case um I claim that I want to be known across different apps as nick. and that means when I sign into different apps it can kind of recognize me as that and it becomes this portable web 3 identity and this is what really takes NS just from a simple web 3 username to really a web 3 profile and a again a portable identity so all of these are different daps not built by en but that recognize my name as part of my identity because again it is a portable web 3 identity um and just to really hone in on the idea of a profile versus a name most people think it's just name. eth and then some eth address for Main ethereum and call it a day but really it's important to highlight that there's a lot of other metadata attached to a name as well you know I have a description a location and an address for different types of chains as well so it's just important to realize that it's really an ens profile um even though we call it an ens name very often another representation of this is just when I sign into different apps across web 3 a lot of them will recognize me as my ens name again it is this portable web 3 identity so this is Snapshot and Macho again two apps not built by enss so we understand what it is at the high level and we're going to keep going a little bit deeper why is it important so I stole this slide from our uh designer the other day uh because I think it's important even for developers to understand what the goal of ens is you know at the surface it looks like we just sell these names but really it's a ux business um our role is to help make complex and scary interactions feel better across the internet this is ethereum right here you know the ethereum logo that we all know and love and the ens logo is literally meant to be a wrapper around ethereum it is to improve the ux of ethereum and the greater crypto ecosystem so now into some misconceptions um there are a lot of different types ofs names and most people think it's just do e but that is not true um there is one ens native TLD and that isth which has been most of what I've been saying so far but you can also use almost any DNS TLD and ens as well so a com domain XYZ domain and so on these all work as DS names but there are some differences so do e is really the the Top Dog in decentralization for onchain domains it lives on Main net ethereum it is fully decentralized controlled by ins Dow and there is an annual fee to make sure that the name space stays healthy whereas on the DNS side a lot of these things are not true it's not entirely decentralized it doesn't live on ethereum necessarily and there's no protocol fee so it's just a matter of tradeoffs but the point here is thats respects existing internet infrastructure and is not just limited Toth in this closed system we really try and bridge the gap between uh all of the internet and the flexible registration options I can I can dive into a little bit later but basically DNS names can be used for free uh in the enss ecosystem whereas do e names at least second level do eth names cannot so both of these type of names can be used in a number of different ways namely subdomains and issuing something like sub. name.

under just name. eth and these names can be offchain uh which includes on layer twos so this will'll get into more how it works but again uh in these offchain or layer 2 names it's just a flexible way of issuing names that again have no protocol fee gives developers infinite flexibility into how they want to issue these different names and again issue basically identity to their users across their apps and it is powered by ccip read or EIP 3668 which I have another slide on in a bit just to give you some context of really who uses this or where you may have seen it in the wild so far it's used by coinbase Unis swap poop and a lot more uh to a total of 5 million plus names and so it's getting well adopted and just increasing over time so now how does ens work this is the more dense part so the enss registry is just a smart contract on ethereum and at a very simplified level it stores names side by-side resolvers so you see here is my name and my resolver is Ox 4976 so on this is a smart contract that tells different applications how to resolve my name how to resolve different data associated with my en profile um CBD ID here this is the coinbase example and they use their own resolver and again team nick. eth um which has its own resolver as well multiple names can use the same resolver and most do use the same resolver but the resolver spec is an open standard that anybody can build their own and it's how you do a lot of this flexible interesting stuff with ens subnames so diving into each one of these and really what it looks like first we have the resolver that I use for greg. this is the public resolver which is just what we call the default resolver and basically in that you can store a object of addresses and an object of text records among other things and again I just want to highlight this is a simplification of it it's not actually storing like the string eth side by side in address but good enough for demonstration purposes and so this means I can store the address for any blockchain um in my ens name which a lot of people think is just for ethereum and so that's not true you can see here I store an eth address a base address and a Bitcoin address um and the base verse eth address is important to note because account abstraction doesn't guarantee that you have the same address on every chain and so ens is flexible enough to allow you to set a specific address per chain that you want to use when resolving your name and text records are a similar thinking of just an arbitrary data store for key value pairs so there's an avatar text record there's a description text record these are kind of standard and shown across many apps but also you can put ABC as a key and uh XYZ as a value and you can use that as a developer to do any sort of interesting thing that you'd like now getting into offchain resolvers so offchain resolvers are interesting because when you go to resolve something for a name so if I go to resolve an eth address for cb. ID or the Stars to indicate any subdomain under cb.

ID um from the smart contract perspective you actually get an error and this error is ccip read um and then the star is wild card resolution so I'll explain both of these steps basically Wild Card resolution is an ens spec that defines how to find the resolver for a subdomain that might not exist on chain so for example you can go into the coinbase wallet app today and register name. cb. ID and when I say register that's just like adding a record in coinbase's database but it becomes instantly accessible across all of web 3 so you can use this in metamask as soon as it's created in coinbase wallet even though it's not on chain and the way this works is uh metamask would look for the resolver of name. cb. that wouldn't exist and then it looks for the resolver of cb.

ID and that does exist on chain then it would resolve name. cb. idid through the resolver of cb. and this is wildcard resolution the ability to resolve subdomains under apparent name and then ccip read is the ability to fetch offchain data securely from a smart contract and so basically once it finds the resolver of CB to ID in that recursive process it will reach out to the Gateway URL that coinbase has specified which is basically just an API and it will return a response and then the client so metamask in this case will verify that response and return the answer which is an eth address or a Bitcoin address or anything like that so these two things in combination make it possible to issue free names to any user on and this is a lot of the Integrations we're seeing these days because it really allows developers the ultimate flexibility to issue names for free to all their users and then lastly let's take a look at the layer two example so there's a name team nick. and then there are subdomains under that the subdomains don't exist on Main ethereum and so when metamask goes to resolve something so let's use name.

team nick. as an example it won't exist and it will find the resolver of team nick. eth and end up at the same error because these layer 2 resolvers um are powered by something called the evbm gateway and that's a library that we used or that we built um that allows you to verify layer 2 state from a layer two from a layer one smart contract and so what's actually happening here is that they both use ccip read so they both revert with that offchain like lookup um and the difference between cb. and team nick. e is that cb.

ID reads from an offchain database or really any offchain data source and then it has a signature verification or really any arbitrary verification in the resolver smart contract whereas the evm Gateway allows you to minimize the trust required in this process so instead of reading from a database it reads from a layer 2 RPC and then the state of that layer 2 is verified on the layer one contract to make trustless Layer Two subdomains And so these are kind of two different approaches that teams are taking nowadays um an evm Gateway is a newer one that I think wouldd like to push so that is um two kind of like in-depth approaches to building in subnames and different types of names these are this is a link to o doc that has resources uh and links and contact info and code Snippets and all that stuff um if you're building this weekend on any of the things I've talked about or integrating any other sort of inss implementation to your app um should have info for you and we also have a booth to help I'll leave this up here for a second cool and then if you're using those resources we have 10K in prizes for the bests Integrations so this is for nothing specific there's not um any super specific track it's just generic best use cases of ens and this is because we think of ens as base layer infrastructure you know if you're building a really good application that has a need for usernames which most do um Implement enss in a really creative and a natural way and that is eligible for a prize or if you're really interested in building ens specific infrastructure like maybe certain Gateway tooling or certain smart contracts then that alone can qualify as well so we're keeping the gate open um any interesting Integrations or implementations of ens are eligible for prizes but that is what I have for you guys and I'm happy to take any questions this uh stat yeah so the state verification you you mentioned uh so I presume has to be L2 which is encored on ethereum Main net right yes so the evm Gateway is a few moving pieces there's a contract on layer one main net ethereum and there is a ccip read Gateway which is basically an API and then there's a contract on the layer two that the Gateway is reading from basically and uh the flow is that the layer one smart contract will revert with a ccip read lookup that that will hit the Gateway with certain uh data that you're requesting so a specific storage slot that you want to read from the layer 2 and then that will give it back to the client on layer one and there's a call back function as part of ccip read that can basically verify if the storage slot returned from the RPC has been uh kind of like committed to mainnet by the native layer 2 Bridge or the layer 2 like State Route um and if that checks out if it works then it will return the valid response otherwise it will fail and so in this case it's trust minimized because the Gateway cannot lie about the response from layer 2 it can't return in valid State otherwise the contract will not verify the data um and but it's still not fully trustless because the Gateway operator can just turn off the Gateway so it's a different tradeoff from coinbase and team Nick in the examples that I showed but uh further along the path of like a trustless layer two name so it's like all l2s do they use same Patricia trees as on L1 is this what made it possible the same what strategies sorry uh so the state Roo is it always a Patricia Tre like the same format of three that we have on L one yeah there are different implementations for different layer twos especially like ZK versus op stack versus arbitr and all these other things um we have the library called the evm gateway which currently supports op stack chains so uh base op main Zora so on and arbitrum as well and maybe one others and then some of the ZK stuff is a bit more complex and and still in works but generally they're not all identical uh but they have some overlapping like characteristics that'll make it possible nice very nice work thank you thanks um we have time for one more question I think if anybody has you gave an example of cb. and you mentioned that they have their own resolver uh the resolver address different so does cb. ID need to be renewed uh like pay make a payment and renew like we do for domains no so CB ID is kind of a combination of like using DNS and ens and using offchain names and so as long as they have the domain the DNS domain cb. ID they don't have to pay any fees to ens at all and they issued effectively 4 million names for free got it thanks yeah um cool I think we're out of time [Applause] [Music]