like google.com. So ENS solves the same problem for crypto. The idea is anywhere you can put an IP address, browsers use DNS. Similar to how that is true, anywhere you read or write an Ethereum address or any crypto address, you should be able to use an ENS name.
Um, and these are just two examples of where you might see ENS being used in the wild. You know, the left is an example of Etherscan viewing past transactions. You know, Luke sending something to Gregsil.eth is much easier to understand than Gregirl.eth sending a transaction out to ox554F3B.
You know, that doesn't mean anything. The first one has so much more context and meaning to it. On the right side, you see the different example. Instead of reading from past transactions, you're writing a transaction. So instead of sending ETH to a random address that I just copy and paste, I could be sending ETH to a name, Greg.
So much easier, so much more clear, um, and just a better experience overall. So these two things are examples of the two processes that we have in ENS. There's forward resolution and there is reverse resolution. Forward resolution is the idea of going from a name to an address and any number of names can point to the same address. So for example, I can have Greg.
eth and Greg 2. And Greg 3 and they all point to the same address. But reverse resolution is the opposite. So an address that then resolves into a single name. And an address can only have one name per chain.
Today this is only supported on mainet Ethereum but very soon in a matter of weeks you'll be able to set a different reverse record. Um so that's the second process on different chains. So for example on base I can kind of identify my address as gregirleth and on optimism I can identify that same address as a different name. And this could be useful for smart contracts or really anything like that. And the end goal of this is when you sign into different websites, you know, this is Snapshot and Matcha, two things that have nothing to do with ENS, but they are crypto applications that I sign into with my wallet and they identify me as my ENS profile because ENS is really this global web 3 profile that travels with you between applications.
It's the idea that not only ENS is a username, you know, it points from a name to an address, but it's this profile. Uh the name comes with me across web 3 and it comes with me alongside all of these kind of records that I have set alongside an ENS name. I can set an address for different chains. I can set text records which is an arbitrary key value pair. Um and this just looks like a profile.
You know, there's a lot more data to it than just an address. And I'll explain how that's actually stored in a little bit. But to recap, why is this important? Um the goal is users of crypto-powered experiences should never have to interact with a hex address. And a way to visualize that is like this is the Ethereum logo and the ENS logo is actually a wrapper around the Ethereum logo.
That's how it was designed. Um we want to make Ethereum easier to use and more friendly and that kind of came from the very beginning of the logo. So from the technical side, how does ENS work? Um there is a core registry on mainet Ethereum today that stores a name alongside a resolver. This resolver is a smart contract that stores all the data associated with a name.
Multiple names can use the same resolver or you can build your own resolver for a very specific use case. So here are just two examples. Greg, that's my name. I use the resolver ox4976. And base uses their own custom resolver.
We're going to take a look at both of these because they do some interesting things. So, Greg, I use what is called the public resolver. It's just the default resolver whenever you register a name. Um, and this stores records onchain. So, each of these items, my ETH address, my base address, my Bitcoin address are all stored on mainet Ethereum in smart contract storage.
So, that comes with gas fees and all the like. In addition to addresses, I can store text records. These are the arbitrary key value stores that I described earlier. Um the kind of common ones are avatar, description and so on. But you can imagine throwing really anything in here.
So if you have a proof that proves something about an identity, uh you can set that in a text record and then anybody that knows your ENS name because you've connected to their application can kind of access that proof and do whatever they might want to do with it depending on what the proof includes. So text records are where you can get kind of fancy and just throw arbitrary data in your ENS profile. And then the last part is a content hash. And this is a pointer to decentralized storage on IPFS or similar networks. And I'm going to share a cool idea on what you can build with that a bit later.
Um so this is the public resolver, right? Everything is onchain on mainet. Very simple. There's also this idea of an off-chain resolver. And an off-chain resolver is something that looks a little weird like this.
You'll see that it reverts with this off-chain lookup. If you don't know what that is, that off-chain lookup is CCIP read. Has anybody heard of CCIP read? I'm curious. Okay, so very few.
Cool. CCIP read is an EIP number 3668 or an ERC that basically defines how to fetch off-chain data from a smart contract. And it looks something like this. There's a client which is like a website, you know, you can imagine it being a wallet. There's a resolver which is the ENS resolver smart contract that I described earlier.
And there's a new party of this gateway. A gateway is like an HTTP API. It's not a crypto service. And so what happens in a resolver that implements CCIP read is a wallet will go ask a resolver, hey, what's the address or text record or any specific data stored for gregirl in this resolver? Or I'll I'll be more explicit.
You know, bass uses this. So I'll say greg.bass.eth. Um a client goes to look up greg.
base.eth. the resolver actually reverts with an off-chain lookup saying, "Hey, I don't have that data." But you can go find the data you're looking for at this gateway. Um, once you hit the gateway, you can do anything you want.
So, you can fetch data from a layer 2. You can fetch data from an off-chain database. And this is what makes off-chain ENS subnames possible. It makes it possible to have names that are completely free, but still work the same way onchain names work. It's a very flexible system that's quite cool.
Um, and once the gateway returns the data to the client, then the client will verify that data according to what the resolver defined. And here is another opportunity to basically verify that the gateway is not lying about a certain piece of data. So, let me walk through an example. If base stores their data on a layer 2, this gateway could return the storage proof from the layer 2 of what you're looking for. And then in the L1 resolver over here, you can verify that that's valid data.
So this whole system becomes trustless and really flexible. So you can basically trustlessly access L2 data from a layer 1 smart contract. And this is just this is not specific to ENS. We just happen to implement it in resolvers so that you could do cool things like offchain and L2 subnames. And I'm happy to answer questions about that after.
But before I do, I'm going to walk you through a couple things. First, uh how am I doing on time? Because I can see. Okay, great. Um so we have three prizes.
The first is L2 subnames using the CCIP read stuff that I just described. Then we have ENS infrastructure and general best use of ENS. Since we have some time, I'm going to go through a demo that heavily utilizes CCIP read. So um I will bring this QR code back in a minute. So no need to rush into it.
But we have this new tool. Does it show? Yeah. Called Duran. I'll make it a little bit bigger.
Duran is a framework for creating L2 subnames on ENS. and it works using CCIP read. The idea here is say I have example on mainet Ethereum and I want to create subnames of it. So like Greg.example.
eth in an application to onboard my users with a more friendly username. When you're onboarding users to your app, they would never have to see an address. They just get a name from the first point that they touch the Ethereum ecosystem. And so let's go through an example of what this works. Say I have my test name is often Greg scroll just with three L's.
This is my ENS name on layer one, right? And I can choose any chain that I want my subnames to be on. For simplicity, I will choose Bipolia. And what I'm going to do now is deploy this registry smart contract. This smart contract is what will store all of the subnames that I'm about to create.
So if you used my app and got username.gregscirleth then that would be as minted as an NFT on baseoleia to this contract and it's just a factory. You don't have to change anything about it. It kind of comes out of the box as an opinionated starting point. So we make it very easy for you.
The next step is going to be basically linking this new L2 contract with the L1 contract for the name because you have L1, you have L2. You need to tie them together. And the way you do that is by using an off-chain resolver. So I have already done that before when I was preparing for this demo, but it's just a single button that does the transaction. And now I'm going to basically set the target of the name on L1 to be my newly deployed L2 contract.
And this is the last step of connecting the L1 name to the L2 smart contract. The L2 smart contract being this one that we just deployed from the factory a couple seconds ago. This just complete. Great. So now is where the kind of fun creative part comes in.
We have this example smart contract that the link doesn't work to. Um, it's over here. I will fix that. Um, and what this does is gives you a really easy starting point of how to let your users register a name on L2. But this can be customized.
So, at this point, it's kind of the business logic of how you want users to use your app. You can require that they have a uh proof of personhood proof on world chain in order to register name and you can enforce that in the smart contract or you could make sure you can enforce that the user owns a certain NFT or has a certain ETH balance or really anything because this is your own smart contract that will basically gate access to minting new subnames on the L2. Uh but based on the way we've built it, you don't have to change anything. it will work out of the box. And so I'm going to deploy the very basic example that we give you.
Um this is the same contract that I just showed you and I'm missing something. So this is the contract that I showed you on GitHub and we have a script to deploy it and the script is yelling at me because I haven't set the L2 registry. So what's happening here is this L2 registry is a smart contract that is generic and then you deploy a custom controller. Basically the controller is what allows you to write names into the registry. And so you have to connect the two like that.
And now I can deploy the controller and that should verify itself as well. Cool. So this is my new L2 registar it's called. This is the smart contract that your users will actually call register on to create a name in the smart contract. But before you do that the last step and I know there's a little bit of jumping around here.
I'll leave time for questions at the end. You have to approve the registry smart contract to accept calls from the new registar that you just deployed because it has to know that it's permissioned basically. And so I'm going to copy this new L2 registar that I just deployed the example version of. And on the L2 registry, I'm going to connect my wallet and called add registar. Okay.
And now this is the last step of Duran. What we've done is deployed an L2 registry. We've connected that L2 registry to the L1 resolver of the ENS name which connects those two. We've deployed a registar controller contract which is what your users actually interact with. And then we've connected the L2 registar controller contract to the L2 registry so that it has permissions to actually create new NFTs.
And the end result of all of that is in this L2 registar, you know, this very basic example that we provide that is meant to be customized by you, the developer, I can call register test and set myself as the owner right here. And now the end result of that is I go to Sapoleia ENS and type in test the Greg scroll with three. And it should be showing an ETH address in a second. Did I forget to do something? Oh, I forget to do this up above.
This is what connects the L1 name to the L2 registry contract. Okay. And now if I go to this ENS page and search for test.gracirl.eth something is still wrong.
Oh, demos never work as smooth as you want them to. Um, if I can't figure this out in a second, then we can skip it. But this should have an internal [Music] transaction. That's really okay. Okay, it will work like that in reality.
I probably skipped some step at the end, so apologies. Um, but yeah, that's the process of creating L2 subnames on ENS. And if you run into any issues like I just did, you can come by the booth and I'll I'll help you out. Now is the time to scan the QR code if you want to save that page and visit it later. Um, it's not the easiest thing in the world, but it is significantly easier than it was before this tool existed.
And so we are excited to have people use that. Um, it supports base, [Music] arbitrum, cello, world chain, linear scroll, and I might be missing one, but lots of chains. And so you can kind of get as flexible as you'd like. Um that is a deep dive into L2 subnames. And now just to revisit the prizes, we have best ENS infrastructure and then best use of ENS.
The two infrastructure ideas are brand new and don't exist yet. So I kind of just brain dumped everything onto the screen so you can take a picture of this and read it back later, but I will walk through it in my own way. ENS has this idea of attaching an IPFS content hash to the name to make a decentralized website. This is how something like vitalic.eth.
limmo works. His data is the data for this website is stored on IPFS, but it's accessed through the ENS name vital.eth. The idea here is to build open-source software that makes it easy for any individual person that runs a VPS or a home server to basically contribute to the health of ENS by pinning decentralized websites on a local IPFS node. It's a little abstract.
It definitely requires some knowledge of IPFS in addition to ENS, but it's just a really cool idea for a back-end engineer that might be looking for um yeah, a more back-end task to work on this weekend. And I think it's really cool. something that I haven't seen working in production in ENS and something that I would run on my server personally. So I think that's a really neat idea. And then infrastructure idea number two is ENS has primary names like I explained before the idea of an address mapping to a name.
Right now this is only on L1 Ethereum but is coming to L2s in just a matter of weeks. And the way this works is those smart contracts will accept a signature from users that can be sent to many chains at the same time. And so a piece of infrastructure that's going to be required is basically a relay or service that accepts a signature and sends that transactions to different chains. Um, this doesn't exist. It needs to.
If you build it this weekend, you could be the first one to build it. And that's really cool and it's something that ENS will need uh very soon. So, another back-end focused task if you're looking to do something kind of new and potentially very useful this weekend. Uh, and the best use of ENS prize is fairly generic. It could be one of the things I previously discussed, or it could be something about text records, storing proofs for different cool aspects of an identity in an ENS text record, or really any type of ENS integration.
If you're building a wallet, then you accept ENS names in the input field. Um, and stuff like that. So, this one's more broad and kind of get creative. But that is most of what I have to share with you. This is a QR code that goes directly to my Telegram.
So, if you have any questions, obviously I'm going to be here all weekend at the booth, but you can send me a message anytime. And I think we have two minutes or so, well, 50 seconds for questions. So, if anybody has a question, happy to take it. [Music]
Automatic transcript — names and jargon may be misspelled.