New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

Identity in Your Apps - ETHGlobal Singapore 2024

ETHGlobalWed, Oct 9, 2024, 12:00 AM

Join us for a workshop with Greg Skril titled, "Identity in Your Apps." Learn all about ENS (Ethereum Name Service), the decentralized naming protocol used by Coinbase, Uniswap, Venmo, and thousands more. We'll cover: - What is ENS - How does ENS work under the hood - Some ideas for what you can build on ENS - Latest resources to help you during the hackathon This workshop took place at ETHGlobal Singapore 2024, a 3-day hackathon held from September 20 to 22, 2024, that brought together the most skilled web3 developers, designers and product builders from all around the globe for a weekend-long adventure to advance the Ethereum ecosystem! ________ Follow us: x.com/ethglobal Website: https://ethglobal.com Email us at: hello@ethglobal.com

Transcript

Okay, then we'll just use the extra 30 seconds. So extra 30 seconds. So , hello everyone. I'm Greg from ENS Labs and today we're talking about ENS and how to integrate identity into apps . We will talk about what ENS is, why it is important, what types of ENS names there are, and what misunderstandings are associated with it.

We will also take a look at how ENS works in the background and provide you with some resources. First of all: What is ENS? The Ethereum Name Service is a decentralized and permissionless naming protocol based on Ethereum and scaling to the entire internet . ENS converts complex hex addresses into human-readable names. That's actually the most important thing to remember.

Nobody wants to deal with cryptic addresses like 0xc. People simply want an understandable name like "Nick". This can be compared to the world of DNA. Before DNS domains existed, there were only IP addresses, and that is now a thing of the past. Similarly, ENS wants to make hex addresses a thing of the past and establish these readable names in the crypto sector and on the internet .

Wherever an address is read or written, an ENS name should be available instead . This is an example of what it looks like when reading as well as writing. It is very easy to understand why Luke is sending a transaction to "Greg.eth" . You can see exactly what's happening on a block explorer .

However, if I send something to this random contract address , there's no way of knowing what will happen. There is no context to this transaction. It is not readable for humans and does not provide a user-friendly experience. ENS solves this problem. On the right side you can also see the sending of values ​​to an ENS name.

This is the correct context. Nobody wants to copy and paste an address or, even worse, painstakingly type it from the screen. You make a typo and lose your money. ENS makes both experiences significantly better. At ENS, we have two concepts for resolution.

There is forward and backward resolution. Forward resolution means: I enter a name and it is resolved into the address, as I just showed in the MetaMask example on the previous slide. But there is also reverse resolution. If a name is associated with multiple addresses, or if you are loading a dashboard, you can improve the page's context by loading the name from the address. We call this reverse resolution or a primary name.

And this idea, which actually started just as a username, you know, ENS, most people know it as a portable username. It's actually a profile. And that means this is my ENS profile, you know, Gregscirl.eth, but I've linked a lot of metadata to it. I have a number of addresses on different social media chains, an avatar, and also these social media accounts.

ENS names can store any type of metadata . I've already spoken to a few hackers today who had some interesting ideas about what it could be . And I will go into more detail about that later . This is just one example of my portable profile that accompanies me through Web3. For example, I'm on Snapshot, I'm on Matcha.

These are websites that were not built by ENS . But they are implementing ENS as a form of identity, and it simply makes my experience on Web3 and the internet as a whole better. Now that internet as a whole better. Now that you understand what it is, why is it important? I think it's important to clarify the guiding star for users of crypto-based experiences crypto-based experiences .

Whether it's something crypto-native like Matcha on the previous slide or something consumer-oriented like Blackbird, if you're familiar with the rewards app . Users of these apps should not have to interact with hex addresses at all . Everything should be done via names. Everything should be readable and understandable for humans and provide a good context for the Web3 and provide a good context for the Web3 experience. Here is a recent example from one of my side projects that I found funny and wanted to tell you about.

I had this small on-chain bakery side project called Good Bread by Greg. And this is a fun little NFT of it. A friend of my mother wanted to have an NFT . Which, I know, is kind of strange, but she wanted it. So I asked my mother to send me Caroline's address.

And she actually sent Caroline 1.cbid back to me . I changed Caroline's name . It wasn't really Caroline 1, but it was good enough. The cool thing was that I hadn't even asked her for a name.

I had actually asked her for an address. But people simply understand names better than addresses. I saw that and thought it was really cool how ENS improves experiences in practice and makes crypto accessible to people. And that's exactly what we want ENS to be. I was a little surprised, but it was very cool and it worked out that way.

This is Ethereum and ENS; the logo is meant to represent a shell around Ethereum meant to represent a shell around Ethereum because it encases Ethereum and improves the experience. Okay, now we know what ENS is and why it 's important. So let's move on to the different types of ENS names . Most people think ENS is just ETH, but it's actually much more than that. Any existing DNS TLD like .

com, .xyz, and so on can be used as an ENS name, and you'll see examples of that shortly . And there are some differences. ETH therefore exists on the Ethereum mainnet. It is the most decentralized on-chain domain controlled by the ENS DAO.

And there is an annual fee for name registration as well as gas fees on Ethereum. In contrast, DNS is much more flexible. You know, the goal of ENS is not just to collect registration fees. The goal is to have a healthy namespace. And since DNS names already have a registration fee with Namecheap, GoDaddy or similar providers, there is actually no fee for using them in ENS .

We simply want people to have a human-readable name that they can use across the internet. The disadvantages are that it may not be as decentralized or as strongly on-chain, but it basically works in the same places as an ETH name. And I think it's important ETH name. And I think it's important to understand that. In addition to these two options, ETH and DNS, off-chain subnames are also possible.

These have become increasingly popular lately. If you've heard of Base or Linea, or anything else that's been released in the last month or two , the cool thing is that there's no ENS protocol fee . Developers have the greatest possible flexibility to do more or less what they want. And this is made possible by this cool EIP called CCIP-Read or EIP-3668, which I will explain shortly . There are now millions of these names created by all these projects without them paying anything to ENS.

Ultimately, we want users to have names that are readable by humans. These projects have many users and can essentially provide them with human-readable names for free. So it's really great to see how these are catching on . So before I go into the exact reason or the precise explanation of how this works, let's take a step back. The ENS Registry is a smart contract on the Ethereum mainnet that stores all ENS names along with a resolver.

This resolver is what contains all the magic of storing data associated with an ENS name. The registry is therefore basically just a mapping of names to resolvers. So these are some of the examples I mentioned earlier examples I mentioned earlier . CBid and Lineia. All three are interesting for different reasons, and I will explain why.

Also, Gregscroll.eth is my ENS name. I'm using the public resolver, which is a smart contract—0x49 or whatever in this case, or resolver.eth, because we like to name our smart contracts. Resolvers store data associated with ENS names .

So I can store a separate address for each blockchain . This could be a Layer 2 network or another type of network. This is another common misconception. People think it's just a single address, but in fact there are wallets that implement Bitcoin for an ENS name. So if you are with PayPal or Venmo and own Bitcoin and have linked a Bitcoin address to your ENS name, you can send Bitcoin to Gregscroll in Venmo.

Which is pretty cool. And the same applies to text data records. Text records are simply any key-value pairs that can be appended to a name. Think of it like metadata for each type of user profile. There are a lot of interesting use cases to explore here.

The next case has a similar structure next case has a similar structure . You have name, address and text – the same . You have name, address and text – the same interface for a resolver. But now we have this revert with off-chain lookup. A revert usually indicates an error .

But here, CCIP-Read is implemented, the EIP I explained earlier, along with an ENS-IP called Wildcard-Resolution. This combination allows you to have off-chain subnames or subnames on a Layer 2, like the CBid thing or Lineia that I showed earlier. Wildcard resolution is basically a specification that states: If a name does not exist in the registry—let's take greg.cbid, which is off-chain and therefore does not exist in the Ethereum mainnet—then it will be rejected. If it doesn't exist there, we look for the CBID resolver that actually has data on-chain .

This data, or this smart contract, essentially delegates the resolution process to an off-chain server such as Coinbase's API , which can read from a database, an L2, an IPFS gateway, or anything else. And that allows you to use off-chain subnames. Basically, you just configure your off-chain data source at the higher level, and then everything else below it happens transparently. And yes, that's another way to explain CCIP-Read . So, um, the client or your website—it all runs through libraries, but it's good to understand the principle—the client contacts a smart contract.

This smart contract then says: “I do n’t have the data you’re looking for, but you can contact this other API service to get it. API service to get it. ” The client then contacts the gateway server with the requested data, and the gateway server verifies this in the backend via this callback function. This callback function can do really useful things. She can basically do anything you want.

Linear is another example of an off-chain name, but it actually reads data from a Layer 2 layer. You might be wondering what the difference is between these two off-chain systems, CBID and Linea off-chain systems, CBID and Linea . The point is: Linea names verify the state proof of the NFT, which exists on a Layer 2 , while CBID simply resides in a database on the Coinbase servers. So what really happens is this: In this callback function, the smart contract verifies the state root that Linea transmits to the Ethereum mainnet, and thus one can use trustworthy L2 thus one can use trustworthy L2 subnames that are resolved by the Ethereum mainnet. That 's a pretty cool feature.

It may be difficult to grasp at first, but I think understanding CCIP-Read is a good step towards truly understanding how ENS works. Both systems therefore use CCIP-Read. One reads data from outside the chain, the other from a Layer-2 RPC. One offers an arbitrary verification logic. There may not be any, or it may only check whether a signature or message from a server confirms that everything is correct – that everything is correct – if it is only reading from a database.

In the other case, however, verification is based on a state root in the Ethereum mainnet, which was transmitted by a Layer 2 . This goes into a lot of detail, but perhaps you now understand how these two approaches differ. If you would like to learn more about it or build with it yourself : We will of course have a stand and are happy to help. We also have a channel on the ETH Global Discord server, where we are happy to offer support. This is a good place to start to find all these links.

I'll show this again briefly: If anyone is interested, we have $9,000 in prize money for the best ENS integrations. That's quite general. The idea is that any app you have, if it could use names quite naturally, you know, if addresses are part of your experience, implementing ENS makes that better . And that makes you eligible for this price. It does not have to be a specific ENS application.

It's simply a very good natural implementation of ENS into an existing app or another app you're building this weekend. And then this is a new thing. We take our documentation very seriously. And if you have feedback on our documentation, we basically offer $1,000, um, or $500 to two different teams. They simply give good feedback on our documentation.

So you don't even need to integrate ENS. You can do that and apply for both, but if you read our documentation and want to understand a topic and are having difficulty understanding it, that is valuable to us. And so you could potentially win $500 just for providing feedback on our documentation . It's something new we're trying, but it should be interesting. And yes, thank you for your time.

I don't know how much time I have for questions. Okay, cool. So, yes, any questions? I'll gladly answer them. And here is the same QR code again, in case it's helpful.

What's wrong, Cartik? Tell them about the free stuff. Yes . OK. All right then.

Yes. Good. Good. Quick note. After you submit your projects this weekend , everyone who has the Hacker Package, which I think is all of you, will be able to claim a free name via the ETH Global website and enjoy all the benefits of ENS, a portable Web3 identity that accompanies you across the internet.

And that was an enjoyable partnership. Thanks. Thanks. They had a technical question Thanks. They had a technical question .

Yes . I would like to ask, since we are talking about subdomain names. Does that mean, if I use an off-chain resolver, yes? that it's free. Yes .

So, let's continue from here. Oh yes. The question was, if you use an off-chain resolver, is it free? The answer is yes. There are a few steps to set up the process.

Basically, you need to set the resolver for the top-level domain, in this case line.eth, on Ethereum , which will incur gas fees, quite minimal, you know, a few dollars, and for the purpose of the hackathon, we are happy to sponsor that. Um hackathon, we are happy to sponsor that. Um , but every subname you create, whether it's one or 11 million like on Coinbase, is completely free, provided you do it offchain. And if you do it on a Layer 2 And if you do it on a Layer 2 , then those are, um, Layer 2 costs for the user, or if you cover the fees, that depends on the scenario.

Yes. But generally, the setup costs a few dollars and you never have to pay anything again. There is no actual fee. It's just gas. But does this also apply to these domains or to DNS?

Yes . The question was therefore whether this applies only to ETH names or also to DNS names ETH names or also to DNS names . And that's the difference. OK. It is therefore possible to use a DNS name in ENS without paying any fees and to set it up so that subnames work the same way.

Technically, we still recommend setting it up onchain because the name resolution process is simply a bit faster, as there is one less CCIP read call in the process. But for a hackathon and simply to set something up, there is absolutely nothing wrong with using an offchain DNS name and keeping everything completely free. It's possible, of course. Are there any further questions course. Are there any further questions ?

Yes. Yes . You just mentioned that resolvers also exist with DNS names, right? So I'm wondering if it's also possible to use a wildcard for DNS ? Yes .

The question was: Is wildcard resolution possible for DNS names ? And the answer is yes. That's exactly what you see here on the screen. Um, cbid is a DNS name. You know, .

id is the same as .com, .xyz and so on. And they have a wildcard resolver, so any name... wildcard resolver, so any name...

So I have ensl.cb.id. That's the name I chose for my demo . And if you search for ensc.

cb.id in MetaMask, the Chrome extension, for example, it actually shows my address, and that's a wildcard resolution under a DNS name. And the reason this is so cool is actually because it can function as both a DNS domain and an ENS domain . For example, um, let me see if I can find a good example . There's this company called Fluid Key that does really cool things with ENS names.

I think I've got, let's say , Gregill. fluidkey.id and I don't know what this noise is. Um, oh, they're having problems with their domain. Okay, it looks like their domain might have expired, which isn't good, but I 'll let them know.

Be that as it may 'll let them know. Be that as it may , normally that would work as an ENS name. So I can enter Gregscril.fluidkey into MetaMask enter Gregscril.fluidkey into MetaMask .

ID. Did I spell it wrong? No I haven't. Um, ah, okay. Well saved.

Thanks. Um, yes . This is a website; you can enter it into your browser and also into MetaMask to send assets there. Fluid Key essentially generates a new stealth address every time you resolve the name. So it's a really cool use case for privacy in conjunction with ENS names.

You can currently see that this address begins with oxa. When I reload the page, I expect to see a new address here. But ultimately, as the owner of Greg's grill.fid, I could withdraw the funds from all these generated accounts. It 's a really cool product, both because of the product itself and because of the name, which is compatible with both DNS and ENS.

Yes . Just a quick question. Secure. Yes How would you proceed? So the question is, how do you set up something like Linea, i.

e., subnames on a Layer 2? We basically have demo endpoints for gateways that you can use, so you don't have to provide all the parts yourself. One would need to write a smart contract on Layer 2, in this case Linea, that registers the names, and there are a few ways to do that. Depending on how trustworthy or untrustworthy it should be , there are different options.

One can write a gateway that simply calls a Linea-RPC , retrieves and returns the results without performing state-root verification performing state-root verification – in this case, one would have to provide a custom gateway, as this is not a standard. However, if you use the EVM gateway – which I haven't mentioned, but which is in the resources at the end of the QR code resources at the end of the QR code – it's basically a framework that takes care of most of this state-root verification for you . There are gateway servers that you don't have to operate yourself because it's a standard implementation, but you have to write a smart contract on both Layer 1 and the Layer 2 used to connect the parts, since the Layer 2 connect the parts, since the Layer 2 implementation is not necessarily standardized. It could be an NFT or any other on-chain object, so there is a lot of flexibility. Absolutely.

Yes. Last question. Resolve the domains to access an app. Yes . Also, ENS names can also function as websites, and that's the example I mentioned: Vitalic example I mentioned: Vitalic .

Vitalic.eth attached this dataset . As you know, I said that you can attach a lot of metadata to an ENS name. One of them is this content hash dataset. Um is this content hash dataset.

Um , and that's basically an IPFS content identifier, for which there are various gateways that allow easier access. For example: vitalic.eth.link Um, .link is a gateway that effectively looks at what's in front of it.

In this case, vitalic, and it puts vitalic together and searches for the content hash . It resolves this content from an IPFS node, which is a decentralized storage network, and basically returns the result as an HTML page, like a web page. This allows you to host decentralized websites via an ENS name, which are easily accessible through these gateways. One is ETH.link, the other is ETH.

O. Um, another one that popped up last week is ETH.sucks, which is kind of funny. Um, I thought to myself: "Someone, anyone at the hackathon should make ETH.Oros or something similarly cool."

Um, but this one was only added last week, and it's funny to see that a number of different providers are offering the same thing. You know, it's a distributed, decentralized system, and that's why all these different gateways deliver the same content different gateways deliver the same content , provided by ENS. And yes, ETH.X is kind of funny. So, um, cool.

Thanks, guys. If you have any questions , we're at the booth.

Automatic transcript — names and jargon may be misspelled.