Onchain is the next online

Tanya Cushman Reviewer Reviewer's Name Good morning, everyone. How's everyone today? Good! My name is Jeff Lau, and I'm a co-founder of ENS. Traditionally, this talk is done by Nick Johnson, but sadly, he did not make it here today out to Thailand, so instead, I will be talking to you instead.

The last time I did the E&S, State of E&S talk was in 2018 at Prague. Who here was at DEF CON 4 Prague? Wow, wow. That's actually more than I thought. At that time, five years ago, we were exploring the permanent registrar and migrating from the Vickrey auction to the commit reveal registration of today.

Since last time, so much has changed, and I'll be talking about some of those things today. So who here has heard of ENS? Right, that's pretty much everyone. That's good. That's good.

Vitalik said this in 2024. ENS is our most successful non-financial application on Ethereum. And I'll go into a little bit of what ENS is for the very few people out there who don't know what it is. So ENS is for the very few people out there who don't know what it is. So ENS is a user experience protocol.

And that means we put users first. And that has multiple meanings. We endeavor to create the best user experience to make the blockchain easier to navigate. We want our users to be in control of their identity, creating true, trustless ownership. And the protocol is built to be incredibly control of their identity, creating true, trustless ownership.

And the protocol is built to be credibly neutral and permissionless, so anyone, anywhere can use ENS. ENS's humble beginning started with trying to solve one of the innate weaknesses of blockchain. Everything is a long number in hexadecimal, and it's completely unreadable. So really, how are we supposed to scale to billions of users if the first thing they do when they create a wallet is see this? ENS helps you turn that into something humans understand.

A name. The simplicity of a name is familiar to all of us. As soon as we are born, we are given a name, and it forms part of our identity. Whether that large number, sometimes called a hash, represents your identity on Ethereum, a decentralized website, or something else, a name is an order of magnitude more meaningful to people. And ENS serves humans, not machines.

ENS has several core principles that make our protocol user-centric. It's decentralized, meaning no single person or entity controls the levers and buttons that govern the protocol. It's permissionless, so anyone can register a name and create an identity without having to state who you are or where you're from. And lastly, the protocol itself is built to be credibly neutral. This means we're doing our best to not have codified, privileged actors in the system.

Okay, definitions out of the way. Let's talk about the years so far, and we've had a really great one. If you put all of the ENS registration durations end-to-end, you'd have to start 9 million years ago. In the late Miocene epoch, Earth was a wild realm of change. Sabertooth tigers stalk sprawling grasslands while early elephants thunder across open savannas.

And despite an abundance of large, sharp teeth, nobody was trying to sell Dentacoin to anyone. Some more seriously though, it illustrates we're brewing pretty damn well. Here's the basic stats. Nearly 2 million .eth names.

900,000 users, of which nearly 200,000 have set up decentralized profiles for themselves, which you can view in Ethereum follow protocol. But ENS was not only about .eth. A truer picture of ENS's popularity has to take into account the enormous number of names using one of our many, many partner integrations. And many of these are completely trustless and cost-free.

Linear, Base, and Uni all have released subdomain registrars this year. Linear has completely trustless on Linear L2 using state proofs on L1 for CCIP read verification. Base has them also stored in L2 but uses signature verification. And uni.eth has them completely off chain and verified using a signature.

This really shows the progressive decentralization of subdomains that can start simple and gradually be made trustless using L2s and a state proof with CCIP read. And lastly, the £1,000 Gorilla Coinbase. As of today, Coinbase reports they've issued over 12 million CB.ID names to their users. This marks the largest deployment of ENS names to end users since we launched and really demonstrating the value of rolling out ENS infrastructure to absolutely everyone.

And that has really been the theme of the past year or more, bringing ENS to more people, more affordably, and with less know-how required. CCIP read and off-chain names have been the foundation of that and have led to a number of hugely successful integrations. Almost 16 million active names, more than 14 million more than .eth names that exist, around 10 million users, and over 400,000 decentralized profiles. .

eth only paints a small picture of the success of ENS. But if you include all of our many partner integrations, you'll really see how wide-ranging ENS truly is. But ENS is not only about subdomains. Our success is how widely integrated we are, allowing names to be used out in the wild. Integrations are one of the most important success metrics for ENS.

Imagine owning a Visa credit card, but no one accepts Visa. This is the problem we need to tackle by bringing large integrations that allow the use of ENS within their existing users, allowing ENS name resolution to exist outside of our echo chamber. And this year has been a fantastic year for integrations. And I'd like to tell you about a few of them today. But first, while not an integration specifically, I'd like to quickly highlight Gasless DNS Sec, one of our biggest technological advances in ENS to date.

We've supported DNS top-level domains inside ENS almost since day one. But importing one came with a substantial fee. Gasless DNS set combines our trustless DNS import functionality with the gateway architecture of CCIP read and makes it possible to make nearly any DNS name function inside ENS without transactions or gas fees whatsoever. And one of the first to use the power of gas as DNSSEC was GoDaddy. GoDaddy added built-in support for every name registered through them, removing the usability barrier of understanding how to set up DNSSEC, and you can set up your DNS name to work in ENS using GoDaddy in just a few clicks.

GoDaddy has over 80 million names registered with them, 20 million customers, and just this one integration on its own vastly improves the network effect of ENS. In collaboration with 3DNS, Dotbox is the first truly blockchain-native, fully ENS-enabled DNS TLD. Dotbox registrations are all recorded on Ethereum, and every Dotbox name is automatically ENS-enabled. It's not just the main related companies that are integrating us, though. Bitwise, a traditional finance company who released their Ethereum ETF product this year, has created ENS subnames for each of the addresses that hold the ETH back in the ETF.

This is a great use case, and it hopefully makes tracking custody of unchanged assets more transparent and more auditable. Payment providers have started to adopt ENS too, most notably PayPal and Venmo. They rolled out their ENS support for their crypto wallets to all US users early this year. Venmo has 90 million US users and PayPal has over 400 million accounts globally. And this really shows how ENS is really super wide-ranging and going to millions and millions of users.

And lastly, can you really say you're a successful protocol until Google integrates you? Today you can search your .eth name on Google and it will automatically show you your balance and your resolved address. Google is the gateway to the internet, and ENS has become important enough to be integrated into the most used search engine. So what do these large integrations bring to ENS?

Well, subdomains means more users, more people using ENS for the first time, and broadening the social network ENS creates. Large integrations like PayPal, Venmo, and Google means there are more places for ENS to be used, making ENS fundamentally more useful. In the same thing, we've also been pushing forward L2 UX with some EIPs in the pipelines, the first of which is ERC-7785, that will enshrine ENS to be the namespace to allow discovery of new L2s. In the future, we hope to push further EIPs to help the fractionalization of L2 addresses and address this problem head-on. ENS works on these problems because, of course, selfishly it helps ENS proliferate.

But selfishly, it also helps the entire Ethereum ecosystem as well. Born out of Ethereum, we as ENS have never forgotten our roots, all the values that have come out of them. Ethereum is not just in our name, but in the DNA of E&S itself. For seven years, primary names have only existed on L1, which limits their use to people who are willing to pay Ethereum gas fees. Being able to set a primary name on any chain, effectively for free, will be a huge unlock for the Web3 UX.

And this is the first example of a more for free, will be a huge unlock for the Web3UX. And this is the first example of a more flexible contract that will be seen to be broadly in ENS v2, which was announced in May, and marks the first time that any ENS contract will be officially deployed to L2. And I'm proud to announce that primary names are coming to L2 and are available on testnets today. Reverse registrars, the smart contracts that power L2 primary names, are live today on a handful of testnets and should be coming to mainnet by the end of this year. And to be clear, there's nothing for developers, non-developers to do this time, but if you're a developer, you can go to testnets today and play around.

Now, things have really changed in the last seven years. I mean, look at our old 2017 logo. L2s are the norm now, and smart contract accounts are commonplace. Gas prices are fluctuating, and it's not sustainable to stay on L1 anymore. In May, we talked about moving to L2, driven by several key reasons.

The first is reducing the overall cost of interacting with ENS. The second is reducing the number of transactions in all possible situations. And the last is we want to let all users transact from the chain of their choice without the need for on and off ramps that can make L2 so painful. With these UX goals in mind, we are aiming to make a true improvement to ENS UX without the usual trade-offs. With that, on Monday at Friends Day, we announced our plans to build our own chain, which we're calling Namechain.

Namechain is built on a few core things that are really important to us ENS. Today, ZK EVMs are the only way to get transaction finality in a reasonable amount of time. And because ENS is one of the only applications that requires reading state from L1, we need the fastest finality we can to ensure that everything can be read from other L2s. ZK EVMs use ZK proofs to prove the correctness of a state transition on an L2 and commit this to L1. The ENS resolution process can then use CCIP read to verify the data from name chain.

Contrasting this to an optimistic rollup, the industry standard would require us to wait seven days before our name can be in use. The second is, of course, the stack must be complete open source, allowing it to be easily audited, edited, and forked if required. And lastly, we care about the credit neutrality and decentralization of ENS, and maintaining that is a priority. We're exploring whether shared sequencing or base sequencing makes sense for us at NameChain. As for decentralization, it is non-negotiable for us.

We're going to be building L2 to L2 bridging right into the protocol. So you can do things like commit whilst you bridge and pay from your preferred L2. This will allow you to start your ENS journey from any L2, lowering the barrier to entry when you buy your first name. And this is one of the primary reasons we want to launch our own chain versus deploying to another public chain. Being able to control the entire stack from protocol to governance means that this roll-up is here to serve ENS and naming.

This is super important to us as we at ENS are committed to being L2 agnostic. Name chain is the L2 we're building. But we're not just building an L2. ENS v2 is a complete ground-up redesign of ENS. And only one component of that is having a dedicated L2.

It's designed to be more flexible, more accessible, and more affordable. So we continue the momentum started with CCPI read and off-chain names and expand its utility to every user and application that needs it. So how are we going to do that? Well, first, we've redefined how names are registered and recorded with a completely redesigned registry. Second, .

eth names will be recorded and by default hosted on our dedicated L2 name chain. And finally, a user-driven migration with backwards compatibility. And let's explore these in a bit more detail. .eth on name chain means that all registration renewals will no longer live on Ethereum L1, but instead on name chain.

Storing it on name chain means that all registration renewals will no longer live on Ethereum L1, but instead on name chain. Storing it on name chain means that registration renewal gas will be significantly lower. Although Ethereum has its conveniences, it's not a long-term solution for gas prices on L1. Having registration on name chain means we can ensure registration gas costs are as close to zero as possible. However, even though .

ethnames will move to name chain, name resolution largely remains untouched and begins from Ethereum itself. Let me reiterate that. ENS resolution, reading from ENS names, remains anchored on L1. And that is a fundamental difference between ENS and other protocols moving to L2. We do not fractionalize our protocol.

We connect it together and remain as one. And this is how we remain L2 agnostic. L2 support was a consideration for the beginning of the design process of V2. And that means we can also deploy the V2 contracts to L2 networks. Combined with CCIP read, this makes it possible to seamlessly stitch together a coherent namespace from multiple distinct networks and L2s.

This architecture reinforces how we are staying L2 agnostic, beginning everything from L1, but only moving .eth to name chain while supporting ENS on other L2s. Okay, let's talk about the complete technical rewrite of supporting ENS on other L2s. OK, let's talk about the complete technical rewrite of the ENS registry. Registries are contracts that store data about that name.

The current registry stores the owner and resolver records, and currently all names are stored in a single flat registry. This design is straightforward, but also has a couple of significant drawbacks, one of which that it's difficult to find custom rules for name issuance and ownership. Another is that because each name exists independently in the registry, when a name is transferred or deleted, all subnames remain unchanged. We're solving both of these problems while adding more flexibility to the system as a whole by introducing a new registry design in ENS v2. In v2, each name optionally has its own registry which deals exclusively with its subdomains.

There's a root registry which contains all the top-level names. Each top-level name has a registry containing all the second-level names such as nick.eth and so forth. Using a hierarchy of registries has a number of advantages. Anyone who owns a name can now supply the registry implementation of their choice, giving full control on how subnames are issued and controlled.

This allows all the functionality of the name wrapper and more, whilst preserving the flexibility for name owners to set their own rules, ownership, and even resolution. When a name changes hands, or if an owner wants to start from scratch, they can easily replace the registry from the name entirely, erasing all existing subnames, allowing a very easy, fuss-free way of clearing up the hierarchy of your name. Likewise, because each registry exists independently, we can even insert registries at multiple places in the ENS hierarchy. When you're ready to move from a subname to an ethname of your own, you can bring everything with you while still ensuring your old name functions as it did before. In line with ENS's core principles, moving to v2 is an entirely user-driven and opt-in process.

All registrations will be transferred to the new L2 chain, because by its nature, a registry has to be stored all in one location. But the names themselves, their records, and subnames, however, can continue to exist on Ethereum or any other L2 or off-chain storage solution. After launch, users can migrate their names to v2 with a single transaction. This will move the name from the legacy flat ENS registry to the new hierarchical one. At the same time, they can choose to either leave the name on L1 or migrate it to name chain.

And names that aren't migrated will continue to function indefinitely. The new ENS contracts are programmed to automatically fall back to looking up names in the version 1 registry. This means that for names that are owned by immutable contracts or for users that can't or won't upgrade, functionality of their name is safeguarded forever. It's been seven years since the inception of ENS. Google, Venmo, PayPal, GoDaddy.

Wow, we couldn't have imagined seven years ago that we would get so far. And ENS is Ethereum-aligned and always will be. That's why we always enjoy coming and giving the state of ENS to DEF CON every single year since DEF CON 1 or 2. And L2 reverse registrars on testnet today, it's something we've been working on for a little while now, and we're really trying to bring the interop into Ethereum, and that's really been the theme for this DEF CON. And ENS is expanding to name chain.

But remaining on L1 whilst remaining L2 agnostic. And ENS v2 will improve the UX of ENS across the board for years to come. And lastly, this talk was too long to mention some of the amazing ENS DAO service providers this year. We're not the only ones building ENS. And it would be impossible to expand to a billion users without help.

To name a few, first, the Ethereum Follow protocol is bringing the social profiles of ENS to the masses. NameStone is powering many of the subdomain integrations and Unruggable for building the generalized gateways that are powering CCIP read. And of course, my ENS Labs team for building everything that we've seen today and supporting us today and for years to come. And finally, the adventure is not over. If you're looking for a position at ENS, we're always looking for good people.

So if you'd like to work for ENS Labs, please check enslabs.org for job postings. Thank you and enjoy your last day at DEF CON. Thank you so much, Jeff, for that. I think that was fantastic.

So as you can see here, if you've already asked your questions, that is great. What you can do is you can also upvote a question. So if you really, really want to have it answered, it can move up to the top of the question. So we're going to start off with the first one. What about privacy?

Using ENS is a major privacy leak and can dox a user. Sure. I mean, this is a question we get a lot for us at ENS is a usability protocol on top of Ethereum and L2s. And Ethereum and L2s have this issue regardless of ENS. So obviously you need to practice good OPSEC and make sure your address is not linked and do the things that you do to protect yourself with addresses.

Having a name on it doesn't additionally create less privacy. So you obviously need to create that good OPSEC no matter whether you're using ENS or not. All right. And then we've got Google integration supports .eth domains, but not the corresponding subdomains.

Why is that? I mean, if anyone from Google here can do this, it would be fantastic if they could. Obviously .eth is our flagship product. Google really respects that and wants to do some integrations and starting with .

eth. But hopefully in the future, we can really push them to do self-domains as well. And if anyone has connections at Google, please talk to us and we'll try and get that in. Okay, remember you can still add some more questions if you feel like none of the ones that you have are on here. We've got, can builders use name chain for other stuff?

Yeah, so as I said, name chain will be on a ZK EVM most likely and that means it's EVM compatible, so it's going to be a public chain that anyone can use. We're not going to be permissioning the chain so you can deploy your own resolvers. All right. Then at the top here we've got, what are some of the problems that stand in our way to increase mainstream adoption of ENS? I mean, I think this applies to all of Ethereum and all of blockchain itself.

It's really about getting... improving our wallet user experience, having names and all of these things to replace addresses. And once you do that, you can get more blockchain and Ethereum support across the board, in your cafes, in your paying for things day to day. And then it'll be very easy to kind of improve the mainstream adoption of ENS. I believe already ENS is quite widely supported across blockchain.

So it's really about expanding the entire ecosystem itself so ENS can serve a larger ecosystem. All right. Can Namechain be Keystore roll-up as well? It is something we talked about, and I don't think it's something we can rule out. I think a Keystore roll-up would be absolutely great.

But obviously there are technical difficulties to the Keystore roll rollup as well. So if we can solve them for other chains, I'm sure we can do it for Namechain as well. All right, we got one that just got upvoted quite hard. How will the ENS token be integrated with Namechain? That is something up for debate right now.

I believe the token is currently on L1, and for now it will stay on L1. Obviously, this is discussions about where we would put our DAO and governance contracts, but yeah, that's still up for discussion. And then a few more questions here. How does ENS compare with unstoppable domains? What do you guys think?

How does ENS compare with unstoppable domains? I think we're doing pretty well. I feel like that one was definitely a trap. The next question, when will the ENS manager app support EFP? Oh, we'll have to talk about that, Brantley.

All right. What has been the greatest challenge for ENS? The greatest challenge for ENS? Oh, there are many. I think it probably starts many, many years ago, and when people didn't really believe that we were a project worth supporting, but I think we've overcome that now, and it's really like a non-starter if your application doesn't support ENS names.

So I think just overcoming that just shows we're here to stay, and we're here to help all of you builders out here.