Hello everyone. Thank you for coming to the last session of the day. I hope the session of the day. I hope the other sessions were good, and I hope this one will be good too. So, I'm Greg from ENS Labs, and today we're going to talk about ENS as a source of identity in your applications.
So, of course, first we have to answer the question, what is ENS? The Ethereum Name Service, or ENS, is a decentralized, permissionless naming protocol that runs on Ethereum but scales to the entire Internet. The simplest answer to the question of what ENS is is that it converts complex hexadecimal addresses into human-readable names. So my Ethereum address is So my Ethereum address is 0x19886, you know, and so on. I'm not going to say that.
Or the same data represented by my ENS name, Gregirl.eth, much simpler. And we think of ENS as a user experience protocol. So compare these two scenarios. On the one hand, I'm having coffee with a friend and I say, " friend and I say, " Send me another $5 to 0x17988627 and so on."
This will not happen. Um, or they have to copy and paste this to me and go into their wallet go into their wallet . This is a whole lot of flour. The alternative—I can say, "Hey, send $5 to gregirl.eth, easy to hear, understand, um, print, and make the payment."
This is make the payment." This is , um, and this is the simplest way to use ENS as a username. But over time, it became more like this profile. So, this is what my ENS profile looks like. You know, there's my address, the ox179 address, um, but there's also all these other things.
There is an avatar image, a banner image, and a description that says I like to build applications on web3 protocols. Um, and this is kind of one of the evolutions of ENS. Without this profile, I would connect the wallet and the apps would show something like this. Just a gray circle and a shortened version of my address, which doesn't really mean anything. It's kind of like getting a marketing email where the intern forgets to include your name and says, "Hey, this client says, "Hey, this client , who we definitely care about, clearly didn't have a very good experience."
And when you have an ENS profile and you log into an application that supports ENS, your profile will look like this, which is definitely which is definitely much better. It shows your avatar, your name, and possibly other data related to your profile. This is an example of what it might look like. You log in to the website and see your profile. This is very hospitable.
This is a better experience for you and for the app. Here are two examples of where ENS is used in reality. On the left reality. On the left is a transaction history view where first I sent something to a smart something to a smart contract that may also have the name ENS, and then someone with the name ENS sent me something. It's very easy to understand what's going on just by looking at this list.
But the two examples below are examples of what it would look like without ENS. Again , objectively worse than with names. Hmm, and on the right it's kind of the opposite. So, on the left, we read data from past transactions. On the right, we are performing a search on some real-time data.
So I send the assets to Gregscrolleth, which again is easier than copying and pasting into the app. So the first conclusion we can come to today is that users of cryptocurrency interfaces should never interact with a hexadecimal address because it is simply worse than ENS names. And likewise, wherever you read or write a hexadecimal address, you should be able to use the ENS name. So when you're building something this weekend, keep in mind how can I integrate ENS? Where should it be used?
Anywhere you see hexadecimal data in your application, this is one place where you can use it. So, now we know what it is, and why it is useful or important. But how does it work? So But how does it work? So , in general, there are two processes.
There is a direct read that goes from a name to specific data, i.e. an address or other types of data, which we will get to in a minute. And there is a reverse reading, which is the opposite. So, this is an address that goes to a name.
And this readback, in particular, supports addresses, not other data types. And this combination of forward and backward reading gives you the primary name, which is the source of identification that we saw earlier. This is what allows apps to verify that when you connect to their app, you are indeed represented by the ENS profile. So this replaces that gray box and the shortened address with your avatar and your name. Much better.
You would set up a primary name or reverse read through these reverse ledger smart contracts on six of these chains that you see here. And it's actually a simple mapping of address to name. So, there are functions where the owner, or someone who has the address, simply calls set name and enters their ENS name. And then, on the other hand , your name is read with the address in that chain. Um, and you can also set this on behalf of another user if you have their signature.
So you can sponsor someone who sets up a reverse entry or sets up their primary name. And there is a lot of documentation on everything I'm going to talk about. Um going to talk about. Um , some of these slides will have QR codes if you're interested in scanning them. Otherwise, you can find them yourself in the documentation later or visit the stand.
But, um, everything stand. But, um, everything I've talked about so far is pretty basic, right? It's just name to address, address to name, but really I want to position ENS as a universal pointer to pointer to anything on the Internet. So yes, you can call wallets and smart contracts, as I said. Um, but you can also create cool decentralized registries.
For example, at a recent hackathon, someone created a decentralized version of a package manager like npm, where each package was represented by its own ENS name, and it had text entries representing the package's metadata, and it pointed to decentralized content, which was the actual source files for the package. And this is something that, as you know this is something that, as you know , is a very good use of ENS that actually has nothing to do with addresses. Um, similarly, you can store credentials in a name, since ENS names can store any arbitrary data. You can use it as a source for a decentralized website. You can use it to store metadata about your AI agents.
Um, it's actually a pointer to anything on the Internet, not just addresses. And I want you to think about that as you create this weekend. So, um, I'll repeat some of these examples. ENS names allow text entries, as I showed earlier on this profile page. There are standard ones like avatar and banner etc.
, but also any arbitrary key-value pair works great. Um, an example of where you might use this, as I said, is storing agent metadata in the ENS name. And we have a specification for this called ENSIP 26. Well, it's not a name, it's a number. But number.
But anyway, um, if you go to our documentation and search for it, you'll find it. This is the newest option and a good candidate to good candidate to break something this weekend if you're researching agents. You can create decentralized decentralized websites, which means that the Cloudflare add-on doesn't disconnect your entire website from the network. The most common example of this is Vitalik. Vitalik's personal blog is hosted as a decentralized website on ENS.
It publishes content on a network like IPFS and then sets its ENS name to that content, turning it into a decentralized website, and that way people can access that content through such gateways to decentralized content or through their own gateways in the most decentralized version possible. I'm not going to talk about talk about not delving into decentralized decentralized websites right now, but if you're interested in learning more, here's another talk about exactly that. And again, we'll be at the booth after if you have any questions, but I see a few phones, so that's good. I'll wait a second. Cool.
Sorry, I'll see you later. And then, um, yeah, naming contracts. So most people again think of ENS as a name for EOA wallets or simply a wallet for an individual. But ENS names can name any addresses, including contracts. And that means that in block explorers like Ether Scan, or anywhere you see block history, er, historical transactions historical transactions , there's more context in what you're doing with your account.
This is more transparent for the user and, more importantly, more transparent for the person designing the contract. So if you're deploying contracts this weekend, consider how you can name them using ENS. And for that, there are some tools that we can share as well . Uh, and then the aliases. So, ENS names are second-level domains, as we call them.
This could be a name like gregscirl.eth-my name is ENS. And it can also be a DNS domain. So, for example, gregs.com can resolve to an address just like aethname.
Uh, both support subnames support subnames . So I can have sub.name.eth uh of any infinite level. This way you can have subnames 10 levels deep.
And that's cool because it allows for a really clean hierarchy. So to use the same decentralized npm registry example from earlier, it would be like version 1, say 1.2.3 packageame.registry provider.
And that's a little harder to say because the goal is not easy payments. It's easy, as you can see, presented as code, and then access decentralized content from there. So subdomains are really great for long-form, targeted content , as well as for engaging users at a lower cost. So buying a name costs a few dollars or buying a DNS name costs a few dollars outside of our system. But creating sub-names at any level is again completely free.
So you can buy projectname.eth and then give all your users sub.proname.eth or user ID.proname.
eth for free. And this becomes a really useful engagement tool. We have several tools for sub-names. One of them, which people really like at hackathons, is called Duran. Hmm, you can access it with this QR access it with this QR code or on the duran.
dev website. D U R I N. And I'll leave that for a second. This is essentially a step-by-step process of deploying smart deploying smart contracts on the EVM chain and connecting it to your ENS name at level 1 so that everything runs smoothly. Yes.
So, this is kind of a list of things you can do with ENS. And to highlight a few new things, ENSV2 is, um, a major protocol update that will be released very soon and is already available on Sapoleia. Um, the two main things I want to highlight are the new registry design, which, um, introduces a clearer hierarchy for subnames as you go down the tree. Um, and there's a new permissions framework that makes it easy to grant an address very granular permissions to perform certain actions with your name data with your name data . So both of these elements can be used for interesting things.
An example would be, um, org structures where you have org.eth, for example, company.eth, and then you have marketing.comp.eth.
And the marketing team is only allowed to update certain name records. Or you could have another contract that kind of takes into account the ENS hierarchy and says that if someone owns a subdomain in marketing.compe subdomain in marketing.compe , they have access to these things, whereas engineering.mmarketing.
eth , engineering.mmarketing.eth , anyone who owns a name in that collection name in that collection can do different types of things. Um, and these things just get simpler with ENSV2. Um, we also have a preview of the ENS CLI.
Um, which I position as the easiest way to train your agents to use ENS. So if you want to give, um, the ability to register names, resolve names, configure records configure records , do all the things that you would normally configure manually with ENS, then this should be an easy way to do it. Um, both of these things are in preview mode, but I think they could be useful at a hackathon like this. Okay, I hope you have a good idea of all the things you can create this weekend. And we have a number of prizes that we can award for this.
This week we have $20,000 in prizes, which is our largest prize pool ever . We have to show up when the market doesn't necessarily show itself, um, and support the developers. So, there are two broad categories for ETH global this weekend. There's creating from scratch, and then there's the prize for continuity. First, creating from scratch is the top layer.
Um, if you're building something with artificial intelligence, it's obviously a hot topic right now. We have three prizes. Um, first place, second place, third place. And you can see the amounts here. I'm not going to read everything out loud.
Um, it could be using the new ENSIPs that I mentioned earlier to store, you know, text data associated with agents associated with agents , or any metadata, or references to addresses that you can set up wallets for in your agents. The second is the creative use of ENS, which is a bit more vague. It's basically anything but AI agents, because there's its own category for that. Examples of this would be the decentralized npm registry or another project that I often share because the inspiration is this privacy solution that people have built on ENS, where every time you specify a name, it actually returns different data, and that's for privacy purposes. So if I send assets to a name, they are assigned to one address and, you know, go to one address on the chain.
But if someone else sends assets to the same name assets to the same name , they actually end up at a different address on the chain. And so the two parties can't see that we both sent assets to the same person, even though we sent them to the same name. Um, and that's, you know, a really cool level of privacy on top of ENS. So it's not a good idea to create these two same things because they were created in our examples, but hopefully this will start the process in terms of what might be possible. And then we have the overall prize.
So if you build almost anything on ENS that integrates properly, you know, without hard- coded data, it should work and make sense in your application sense in your application . This should not be added at the last second. Hmm, then you have the right to evenly distribute the $6,000 between all projects that apply. Hmm, this is the "from scratch" way. And then the path of continuity for everyone involved.
Hmm, we have another $4,000, essentially, for the best improvement of your application using ENS. It's hard to say exactly what that will be because different applications use ENS in very different ways, which I hope you've gathered, ahem, throughout this workshop. But yeah, first and second places for that. This is obviously something new, so it's a bit more experimental, but it's interesting to see how, um, people are also improving their existing projects with ENS. So, um, a couple of things to learn is that wherever your application shows a hexadecimal address, it should show ENS names instead.
Again, this is a simpler idea of it. Hmm, the broader view is that wherever you want decentralized data, it should be accessible through ENS names. It's the same, you know, line of thinking that ENS is a universal pointer to any data on the Internet. And that's what I have for you today. If you have any questions, we'll obviously be down all day today until at least midnight.
Um, actually all of tomorrow, and then we'll judge on Sunday morning. But if we're not there for some reason, or if you're hacking from a hotel, you can also ask questions in this development group and we'll get back to you quickly. And then also in Discord. But, um, I think we have a few minutes left for a little Q& A. So let's start at the beginning .
One question, for example, an organization you mentioned, like Alice, comes to market and it's like, "Can you make a difference?" Yes. So repeating the question for the camera, the question is whether you can reassign subdomains later, like in the organizational structure access example I gave earlier. Um, and I would say the answer is generally yes. ENS is highly customizable.
So, um, you'll have a registry contract that controls each level of subdomains. For example, a company will have a registry that will define how subdomains are created, and each level will have the same level will have the same . So the engineering company will have its own registry that will determine how subdomains are created. You can create a registry that, create a registry that, for example, won't allow you to change subdomains, in which case you won't be able to cancel them. In some cases, this is a good thing, like npm's decentralized registry.
In some cases, this is not what you need, which is probably due to the organizational structure. You want to be able to restrict someone's access. And so you'll be able to build in permissions that allow the parent company owner, that is, the company owner, or the operations team, for example, to revoke permissions at any level. So, in short, yes, it is configurable, but I would like to explain the different options. Hierarchical registers are possible in V1 and V2, ENSV1 and ENSV2, but in V2 it is simpler.
Which again works for Sapolia. So we can help you with that this weekend. Hmm, yes. Yes, the question was , is there a limit on the number of subdomain names? Hmm, no.
There can be an infinite number of subdomains under one name, and there are. Yes. No level, no limit. Hmm, and I'm glad you mentioned the gas commission. So, subnames can be on Ethereum L1, which have gas fees.
They can also be on L2, like in the Duran example I showed. Hmm, and they can also be completely off-chain. So completely off-chain. So , I could have the name ENS, hmm, like a name again, and configure it in a way that I could issue off-chain subdomains. And it could be in a database, and that's not the best use for a decentralized application.
But if you need a centralized application, which might be like a custodial wallet or an exchange that wants to make it easier for its users to accept payments or, for example, accept deposits on something, hmm, you can issue names in a database and it starts resolving immediately anywhere that supports ENS, and in that case there's not even a gas fee. So, again the long answer, short, uh, there's no limit to the number of names you can create, and sometimes they're free, sometimes they have a gas fee, depending on how you set them up. Yes. One more thing. Uh, yeah, this question is kind of the opposite, I guess, or the opposite of the previous question previous question .
The previous question was, or one of the previous questions was something like this, is it possible to make it so that the parent object can change someone else's permissions. And this question is, uh , like, sometimes it's bad, and how do you stop it? Uh, like I said, it's mostly customizable. You can configure this so that the parent object can change permissions or configure it so that they cannot. But ultimately, the parent object has to set this up.
So, yes, by default the parent object can control subdomains under it and must explicitly disable its ability to do so going forward. Yes, one more thing. Yes, the question is basically whether subdomains work the same way, or have the same functions, as two second-level domains (LDS), and the answer is no. They are exactly the same. An ENS name is an ENS name, and subnames are no less an ENS name than a second-level domain, for example, name.
eth. The only difference, or let's say the main difference, is that the second-level ethname is the most decentralized. This is a permissionless registry on the Ethereum network, controlled by the ENS DAO, while subdomains, as we have already learned from other questions, are controlled by whoever owns the parent ENS name. And there are probably different ownership permissions depending on how it's configured. But as far as solving the problem is concerned, all the features are available everywhere.
No, sorry. But you can come over after it looks like we'll have to finish recording. Thanks, guys.
Automatic transcript — names and jargon may be misspelled.