Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - ENS V2 Cross-Chain Domains & Namechain - Nick Johnson

Episode Date: April 9, 2025

Namechain is an L2 developed by ENS Labs, to enhance the scalability and efficiency of managing decentralized identities on Ethereum. It is designed to work in tandem with ENS V2, which introduced a hierarchical registry system for more efficient subdomain management and custom resolvers. A key vision for Namechain is to unify multi-chain user identities, creating a "digital identity chain" that simplifies how users interact with the broader blockchain ecosystem. This is achieved through features like L2-to-L2 bridging, which allows users to initiate ENS-related activities from various Ethereum Layer 2 networks, not just Namechain itself.Topics covered in this episode:High level overview of ENSCrosschain functionality through CCIP ReadDomain squattingOnboarding ENS users via Paypal and VenmoGoogle & GoDaddy integrationsENS V2 upgrade & NamechainTransferring tokens from Namechain to L1Sequencer security assumptionsScalabilityNew features & use casesENS roadmap & metricsEthereum ecosystem statusEpisode links:Nick Johnson on XENS on XSponsors:Gnosis: Gnosis builds decentralized infrastructure for the Ethereum ecosystem, since 2015. This year marks the launch of Gnosis Pay— the world's first Decentralized Payment Network. Get started today at - gnosis.ioChorus One: one of the largest node operators worldwide, trusted by 175,000+ accounts across more than 60 networks, Chorus One combines institutional-grade security with the highest yields at - chorus.oneThis episode is hosted by Friederike Ernst.

Nobody goes to Google by typing in their IP address into their web browser, and nobody should have to do the same to send crypto to their friends or anything like that. ENS's goal is to improve usability, and it does that by making it easier for people to name the resources they use all the time. But what we're doing effectively is migrating. Dot EVE, the sort of the main registry to its own chain. So ENS2 represents a complete rewrite of ENS, and at the same time we're moving it to be truly cross-chain natively. The registry, the sort of the core component of ENS, or the root, as it were, will always remain on Ethereum. But we're launching name chain, which is a ZK-based

L2, which will host all Dothethnames. Welcome to Epicenter, the show which talks about the technologies, projects and people driving decentralization and the blockchain revolution. I'm Frederica Ernst, and today I'm speaking with Nick Johnson, who is the founder of ENS, the Ethereum Name Service. And before I talk with Nick, let me tell you about our sponsors this week. If you're looking to stake your crypto with confidence, look no further than Corse 1. More than 150,000 delegators, including institutions like BitGo, Pintera Capital and Ledger trust Coros 1 with their acids. They support over 50 blockchains and are leaders in governance or networks like Cosmos, ensuring your stake, is responsibly managed. Thanks to their advanced MEV research, you can also enjoy the highest staking rewards.

You can stake directly from your preferred wallet, set up a white label note, restake your assets on eigenayer or symbiotic, or use the SDK for multi-chain staking in your app. Learn more at chorus.1 and start staking today. This episode is proudly brought to by NOSUS, a collective dedicated to advancing a decentralized future. NOSIS leads innovation with circles, NOSIS pay, and Metri, reshaping, open banking, and money, with Hashi and NOSIS VPN, they're building a more resilient privacy-focused internet. If you're looking for an L1 to launch your project,

Nosis chain offers the same development environment as Ethereum with lower transaction fees. It's supported by over 200,000 validators, making NOSIS chain a reliable and credibly neutral foundation for your applications. NOSISDAO drives NOSIS governance where every voice matters. Join the NOSIS community in the NOSISDAO forum today. deploy on the EVM-compatible NOSIS chain or secure the network with just one GNO and affordable hardware. Start your decentralization journey today at NOSIS. I.O. Nick, thank you so much for being here again.

It's my very great pleasure to be on again. So you have been with us on Epicenter several times, but for the people who missed it, so the last time was a year and a half ago, but for the people who missed it, Can you give us the TIDR on ENS for everyone who wasn't here for the last episodes? So ENS's key idea is that usability in Web3 ought to be every bit as straightforward as it is in Web 2. Nobody goes to Google by typing in their IP address into their web browser, and nobody should have to do the same to log into a website, you know, a Web3 app, or to send crypto to their friends or anything like that.

So E&S's goal is to improve usability, and it does that by making it easier for people to name the resources they use all the time. So the first one that comes to mind is people's crypto accounts, and so you can use your E&S name to name your Ethereum account, your Bitcoin account, any other chain you like. But it's also your Web3 profile, so it lets you consolidate all of your profile information,

have a portable profile that can be used across a variety of different, you know, platforms and apps. And it can also be used for naming decentralized content, such as decentralized websites through IPFES. Cool. I think there was a super comprehensive introduction to kind of like what the scope of ENS is. Last time we were on, we talked for a very long time about cross-chain functionality. So kind of like when ENS started, it was very much kind of like an Ethereum. main net project because kind of like at the time that was more or there was. And kind of then obviously kind of like L2s and other L1s and so came about.

And there was the question of kind of like how do you actually make this into operate, right? Kind of like do you have a domain name service for each individual L2, each L1? Or can you somehow marry these together? So you had super ambitious kind of cross-chain ideas back then. So tell us kind of like what your vision back then was and how this has evolved and what kind of has manifested itself. Yes. So you raise an important question, which is, you know, in a multi-chain world, do you have a different naming service for each chain or do you have a single one that attempts to encompass everything?

And we strongly believe the answer is the latter because, people don't exist in these silos on each chain. You know, they need a single unified identity. And although E&S is hosted on Ethereum, it's not just for Ethereum. And so our approach to solving this was, as you suggest, a multi-chain one. And then there's a lot of cross-chain communication and integrations. Effectively, what we were proposing and working on back then is a way for people to delegate their names or their entire parts of E&S to other chains.

And that has very much flourished since we last spoke. So right now you can get a base.eath e&S name, so Your Name.Base.combeau, or a uni.combeet or a uniswap or a variety of others. And in each case, they're hosted on the chain of the issuer's choice. And you can register the name and it resolves just the same as if it was hosted on Ethereum. And we're doing that primarily using a technology we developed called CCIP-Reed that enables smart contracts, not just DNS, but we're the primary user, to fetch data from outside the Ethereum blockchain in order to finish their sort of execution.

And that makes it possible to delegate all of this to do any arbitrary chain or even to things that aren't blockchains like DNS. So where's the data ultimately stored that kind of like I delegate to? So to use the example of base.eath and, you know, and subnames on base, the actual data is stored on base, the L2. When you attempt to enter that name into your Metamask or another wallet, it goes off and it consults Ethereum Mainnet and looks up, you know, the parent name and finds that that is, you know, then sending a referral to elsewhere, and it does a query which ultimately

results of looking up the data on base, returning the data to the client, which is able to verify trustlessly that it is actually accurate and represents what's really stored on base, and then returning it to the user. Okay, so can you maybe eluse a day? a little bit more kind of, if, kind of say, I register a name on base, so I'm earns. d base.eath. Do I automatically also have other earned names? So kind of like, could I also get earns.d.eath or earnst. Arbitrum.eath or earns.orgon.unee. Or kind of like, is it, is it kind of like a top level domain system? How do I think of this?

So ENS is hierarchical, much like the traditional DNS. So if you register your name. Base. Then that's the only name you have as a result of that registration. And where it is hosted depends on what the owner of base. DotEeth chose to do. If you register your name.eaf, then it's registered on L1 because that's where. DotEath itself is hosted.

But once you've done that, you could choose to then delegate that to any L1. two of your choosing. Right now, that's a reasonable technical operation to undertake, but we fully intend to make that easier for people to do on their own in future. Okay, so the idea is that kind of like, if I kind of like want all the my first name. Dot eith kind of derivatives, I registered once on mainnet and then kind of I own all the command thread addresses on the very subnet. So no one else can kind of register my my name on these, on on on on on two, so is it is it, is it not blocked? It's a little different. So if you register your name.eath, then somebody else could still

register your name.based.com, because those are considered to be totally distinct names. Okay. There is a single registry, a single sort of index of all names across all chains, though. So there's no, you know, your name.eith on mainnet distinct from your name.eith on base. distinct from, et cetera, et cetera. It's much like, if you imagine the old sort of phone exchange system where, you know, you call up an operator and then they direct you to the operator in New York, for instance, you know, and you sort of get routed through it.

It's similar to that where the system starts at the top level, which is on Ethereum, and then you sort of progressively look up hierarchically to find the, you know, where your name is actually hosted, which can only be in one place. Okay. Have you encountered a lot of kind of domain squatting problems? So kind of like say, I mean, I'm not that big a target, but say, for instance, Wittalick registers Vittalick.Eth and kind of like some other chain becomes available. I would assume kind of like his name would be one of the first registered regardless of whether he does it himself or whether he doesn't. Do you have any way of kind of adjusting for that? Yeah, it's an unfortunate reality of a permissionless system, really, and we definitely do see that sort of thing occurring. I think it's less pronounced in situations where people have less expectation of profit,

so people don't generally assign a high value to subnames, to subdomains. And we kind of, you know, that's to our advantage, because they're every bit as useful to an end user as a second-level name as, you know, your name.eath, but they are sort of less desirable to squat on and therefore more likely to be available, you know, and less likely to be sort of snapped up as soon as they're issued. But it is a definite issue. There's not really one good solution. You know, there's a number of approaches that different issuers and different name owners have taken. The obvious one is that you, allow them to be first and first served.

The, you know, a more sophisticated approach is that you can attempt to reserve and pre-issue high value or popular names to the people most readily identified by them. So, you know, some issuers have gone ahead and reserved, you know, several thousand of the most popular names and then they've either sort of left them there with some process to claim them. If you can prove your Vitalik, you get Vitalik. or they've proactively reached out to these people. The final option is to set up some sort of disputes and sort of arbitration system, which is historically being an unpopular option because it's much more prone to abuse

by the people maintaining the names. And we really like to emphasize the importance of trustless name ownership in ENS. But ultimately, if you own the parent-man, it's up to you to decide how trustless you want your subnames to be. Okay, okay, that's fair. Oftentimes kind of wallets resolve addresses even on networks that they're not registered, right? So, for instance, I own ferns.eath, because that's my name. And kind of like if I send funds to ferns.eath.

dot eth or noses, they still arrive in my, in my, in my, um, in my, um, in my, um, in my, um, in my, um, uh, in my wallet. So how's, how is that handled? It's just kind of like a resolution on, um, the wallet, um, on the wallet side. Yes, absolutely. So, you know, we have a main record type, uh, uh, you know, Ethereum address was the sort of the original type. But since then, you know, since L2s became more popular, that's been generalized to just crypto address in general. So when the wallet is attempting to resolve an address, it specifies which chain or coin type it wants to resolve. So that can be any L2 chain that has a chain ID, or it can even be any crypto chain in general using a coin type, so you can resolve a Bitcoin address on it as well.

and the type of record you're resolving is entirely independent of the network that it ends up resolving on. So you could have all your names delegated to linear, but you could then use it to resolve Bitcoin addresses. Cool. Thank you for shedding so much light on the cross-chain evolution. Let's talk about kind of like your users. So kind of I recently saw that you guys integrated with PayPal and Venmo, which kind of allowing people to kind of buy E&S domains with Fiat. Who are these users who are actually buying E&S domains with Fiat?

So kind of like, to me, kind of like if you're interested in an Ethereum name service address, I would have assumed you own some ether. So what goes? So we do have support for buying E&S names with Fiat through our act, but the integrations with PayPal and Venmo are primarily for their crypto wallet.

where it allows you to send crypto to E&S names from inside their apps. But I think both are important because, you know, I alluded earlier that really E&S's job is usability. And a big chunk of that is being an on-ramp and, you know, making it easy for people to have a really easy starting point in crypto. And so we want to make it very easy for people to get involved right from day one. and they shouldn't have to go through a series of, you know, steps and involving copying and pasting addresses

before they can get to the point where we're involved. So we are big fans of involving people from day one, and that ultimately means they need to have some way to solve that catch-22 of like need crypto to register a name and need a name to receive crypto. Yeah, that makes a lot of sense. I totally misunderstood those integrations, but that makes much more sense that someone can kind of van mo me money at my ethel.

address. How do you handle fees when that happens? So typically kind of on-rams are pretty expensive one way or another. And then they, they would also kind of have to cover the on-chain transaction fees. Yes. So I haven't used the PayPal integration myself because it's not available in my country. But my understanding is they, they don't charge any fees over and above network fees. at least from my reading the material available. And so it's quite affordable for their users. When it comes to name registration, which we've done through services such as Moon Pay,

there is a markup that that provider takes in order to do the crypto conversion and so on. And of course, they have to deal with things like credit card chargebacks and so on and so forth. You also had a number of other notable partnerships since we last had you on. What about Google and GoDaddy? Yeah, so GoDaddy integrated ENS name support for DNS resolution.

ENS is integrated with DNS almost since day one. And so now with GoDaddy, that's a great deal simpler for users to set up, because the steps to have your DNS name work inside ENS are basically that you have to set up DNS sec, which is the sort of security extensions for DNS. and then you have to set specific records on your name that say, when you resolve this name in E&S, it should resolve to this address and so forth. And our integration with GoDaddy makes that a great deal simpler for GoDaddy users

because now they can simply go into the interface and enter their Ethereum address or Alacupto chain addresses and it will just do all of the stuff behind the scenes to make that work. The integration with Google has primarily been around Google search, so now you can search any. dot-eath address inside Google search and right up the top of the search results is an info box telling you what it resolves to and a link to the Explorer page and so forth, which was a great stick forward.

Yeah, that's certainly very useful and I've used that in the past. You guys have been quacking on an upgrade to the general ENS protocol, ENSV2. Can you detail kind of what you'd like to, achieve with this upgrades or kind of like how will enS be better after than it is now? Absolutely. So, you know, I've already talked about our cross-chain efforts. And that was sort of step one in being more supportive of multiple chains and making it easier for people to delegate their names and host them elsewhere.

But ultimately that on its own is not enough because L1 is becoming more and more expensive of overtime. And if we want to attract new users who are new to crypto and who are, you know, just onboarding a system where you have to pay, you know, three times as much as the actual dot-eith registration cost and transaction fees and then pay similar fees when you want to update your name is simply not practical. And we can't even expect users to do that and then delegate it elsewhere. And that means that registering, renewing, updating.Eth has to be much cheaper by default. And ultimately, that means ENS needs its own L2.

So we intend to continue to support other L2s and other off-chain systems as first-class citizens. But what we're doing effectively is migrating.Eath, the sort of the main registry to its own chain. And while we were doing that, we sort of took a critical look at the core ENS infrastructure and said, well, it's been, I don't even know how many,

years is it seven now? And, you know, what have we learned in the last few years about ENS and what's changed in the ecosystem that means our needs are different? And so how can we improve the system? So ENS2 represents a complete rewrite of ENS. We've, you know, changed some of the core smart contracts and the way things are structured. And at the same time, we're moving it to be truly cross-chain natively. So the The registry, the sort of the core component of ENS, or the Rouge, as it were, will always remain on Ethereum. But we're launching name chain, which is a ZK-based L2, which will host all .Eath names and can also be used by anyone else who wants to host ENS records there. And we're, so we're moving all the dot-eith names there, and the resolution process will be basically the same as what I talked about earlier, where we can delegate things.

but in this case we've delegated every.eath named to this new chain. What's the stack you're using for this? We're working with consensus in the linear team, so we're building our own roll-up based on linear's stack, where we have a few somewhat odd requirements of our own that mean we don't want to just use the linear main net. Chief amongst those are we have very strong requirements on decentralization, so it's very important to us to build

a credibly decentralized roll-up, and that means ultimately becoming a based roll-up. And we have some interesting requirements because it's very important that when a user makes a change to their name, that's reflected when users resolve it as quickly as possible. And so that means that the latency, the time between making a change at showing up has to be low, and that's not a metric roll-ups tend to prioritize by default, because naively at least that means committing to mainnet more often and it means finalizing more often and that introduces additional costs because of the additional traffic on L1 and we have some novel improvements there that can improve that latency without additional costs

but that required us to work with linear to make a custom chain. Tell me about those improvements. So I think the one I'm sort of proudest of is one that, we came up with, together with the linear team at a recent workshop, and that's the insight that what we really care about is having, being able to prove on L1 what the L2 state is as quickly as possible. And by default, that means, well, we have to have finalized on L1, but the observation was made at this workshop that actually, there are other ways to do that. And so effectively, what we'll be doing is your typical L2, your ZK-based L2, the way it works is it grabs batches

of blocks and it creates a batch from that and it generates a single ZK proof that proves the entire batch is valid. And then it submits that ZK proof to L1 and the L1 code verifies the proof is valid and then updates the state for all of the blocks prior to that to be finalized. And so we still do that, but the observation was that, we can generate these proofs far more often than we need to for finalization, and we can use these intermediate proofs that get generated but not submitted to main net as proof that more recent states than the most recent finalized one are actually valid.

So what will happen when you resolve an EMS name that's stored on name chain is the service will return to you the result, along with a proof that that's part of the name chain state, and a proof, a ZK proof, that that state is valid and is, you know, a subsequent block to the one that was actually last finalized on MainNet. So by doing that, we get the latency way down, but we don't have the massive additional costs of finalizing every 10 or 15 minutes. Okay, that makes sense. So how often do you then finalize on Mainnet? So, you know, it will be a little flexible in terms of, you know, main net gas prices and load on name chain and so on. I think our target will be similar to linear where it's in the region of every hour to two hours.

But ultimately that will only affect things like, you know, the trustless bridge latency and so forth. It won't affect name resolution. So if you look at that in the limit, I mean, you could kind of, you could always think, almost think of this as, kind of like a sovereign chain, right? Kind of like even if you, even if you kind of never finalize to mainnet, and you can always, you can always prove that you could finalize to main net. So what's, what's, this is somewhat philosophical question, but what's the point in then kind of like finalizing to main net at all?

That's an interesting thought, yeah. And it's, you know, if you look at chains like optimism, they're perfectly happy with a seven-day latency. So, you know, optimistically, we don't need to do it so often. We do need to do it ultimately, though, because we want to be able to send tokens between chains, primarily for things like paying for the E&S name registrations and so forth, but also because a key component of V2 is we want users to be able to keep their existing guarantees over name ownership. And that means that users will be able to move their dot-eath names back to L1 if they need

the sort of absolute ironclad guarantees of security it can provide. And so that will also require using the canonical token bridge, and that will be somewhat slower, you know, bounded by the latency of finalization. How do you move a token that was originally minted on an L2 to mainnet? So what we do effectively is we have one token contract on name chain. and that is incorporated into the registry, which tracks all names, or all .eath names, regardless of their state. And then we have a second contract on Mainnet, which tracks only the names that have been moved to Mainnet. And so when you go to move the name, effectively, what happens is the token contract on L2 sends a message to the token contract on L1,

saying, you know, this contract is, this name is being ejected. and then it transfers ownership of the L2 token to sort of a holding contract so that it can't be moved around while it's effectively held on L1. And then on L1, the contract mints a new token that represents that same name and transfers it to the account the user nominated. Okay. So tell us about the security assumptions here behind the sequencer, right? because kind of like if I kind of, if I want to use my, if I want to move my F. earns.

D.E. domain from name Jane to domain net. Kind of I, I still rely on the sequencer to kind of not censor me, right? And kind of like if I don't, if there's no decentralized sequence, I kind of can't force an exit. Yes, absolutely right. And so there's two solutions to this. One is that we believe having a decentralized sequencer is very important. And so our goal is to launch with based sequencing, which means that ultimately any L1 sequencer can also be a name chain sequencer.

If that's impractical because of development status or costs, then we're going to launch with forced inclusion as a basic primitive and then migrate to based as soon as possible. and in either case it's possible to use consensus rules to force inclusion of a particular transaction. The second component is that once you have moved your name to L1, there's no action the L2 can take that affects the resolution of that, because when resolving, it first consult the L1 before checking the L2. So assuming you're able to eject the name once, no compromise or action on the L2 can affect

that going forward. And when it comes to migration day and people migrating over from E&SV1, it will be their choice whether they migrate the name to L1 or to name chain. Okay, so given I'm already a V1 user, do I need to do anything or what happens to my name during migration? Yeah, so effectively what you actually have is three choices. One choice is to do nothing. That's a good choice. And in that event, yes. And in that event, your name continue resolving indefinitely. You will continue to use the V1 contracts and so on for any updates. If you want to renew the name, you'll still have to do it through the V2 contracts, but that would have to be the only way you would interact with them. However, of course, it won't

show up in the same NFT collections as any other name. If you transfer it to someone, they would then be getting a V1 name, and you won't be able to take advantage of any of the new features or functionality. Your second choice is to migrate to name chain but on L1, in which case you can now use all the V2 contracts, but your name is still hosted on L1. And of course, your third choice is to migrate to name chain, in which case you get the best benefits of lower gas costs and so forth. Okay, tell me about the new features in a minute, but before we go into that, how do you think about the long-term scalability? Because kind of like with based roll-ups, kind of what you very much have is kind of this data availability paradigm where you kind of,

you post all transaction data to blobs on L1. And currently, that's not a bottleneck, but kind of like if you expect kind of like the world's main domain name system to kind of move on shape, you know, or kind of even a significant proportion of that, certainly that's going to become a factor. So I think yes and no, you know, definitely scalability is an ongoing effort. I think you'd be surprised by the volume of like all existing DNS registrations. You know, I have a friend whose hobby is downloading all the Root Zone files, and he does this regularly on a small group of Rainsbury pies he has.

And I haven't asked him, but I suspect the total size is actually smaller than an Ethereum Maynett today. Okay, I understand that, but kind of like also the DNS, kind of like the scope for that is way, way smaller than kind of like what ENS intends to become, right? So kind of like, if I were to kind of send you, I don't know, we went out for a drink and kind of like, I want to refund you five quid for my for my pint, then kind of I could probably send it to nick. Or kind of like on any other chain. And this is not something that I would typically do kind of in the DNS. So kind of I wouldn't expect kind of like just, you know, every Tom Dick and Harry to kind of have their own domain name registered. Yep, no, fair enough.

And consider me schooled on, on E&S scalability. You're absolutely right. I think, you know, there's two factors there. One is that I still do believe that the scalability is not, you know, we're no more than an order of magnitude off at worst from being able to handle that sort of volume, simply because although the volume we're talking about is high, it's a large volume of very small, simple transactions.

And I think the Ethereum roadmap contains enough improvements to that, that I'm not overly concerned about it. Ultimately, it may be more an issue of the cost effectiveness of this, because, of course, Ethereum block space and blob space is demand-driven, and we'd be competing not just with other E&S users, but with all roll-up users. Ultimately, we have the option to move data availability off-chain. It's something I'd prefer not to do, however,

because it has the absolute gold standard in terms of guaranteeing availability and of decentralization. Yeah, hear you there. Tell me about the new features I can access if I decide to not do nothing, but kind of like move my name over. Yep. So the primary thing I think is when we built ENSV-1, we built in upgradeability and sort of, you know, indirection in the resolution pathway, which means that when you set up a name, you can choose how it's resolved.

You can use our standard built-in stuff, or you can use your own custom resolver. It's up to you. And if you have a custom resolver, you can build in whatever functionality you like to change how names are resolved. but ultimately ownership was still controlled under the single central contract, the ENS registry, which decides who owns a name and what the rules are for changing ownership of names, what the rules are for creating subdomains and so on. And over time we've increased the flexibility of that, and the most recent effort around that was the name wrapper, which adds sort of additional programability to name ownership.

But it's ultimately still limited by the V1 architecture, rules around ownership. The big change in V2 is that name ownership is now hierarchical just like the names themselves are. So if you own your name.eath, you can use sort of any implementation you want to configure the ownership of that. We call them registries. And you can set rules for issuing subdomains, you can set rules for permissions on those and so on and so forth. and you can do that on mainnet or on name chain. And so that makes it much more flexible for applications like issuing subdomains and so forth. And this is not something with a lot of end users may take advantage of directly,

but they will benefit from it by making it much easier for people to set up subdomain issuance and so forth so that they can then get the names that represent them and the applications they're using very easily. That makes a lot of sense. Are there already applications that you have in mind that kind of like will make use of this? I think, you know, subdomain issuance is the really obvious one. And, you know, previously this has been a bit more difficult because it's relied on things like the name rap. It's had to be a lot more sort of bespoke for people to set up. The whole thing really revolves around what we think is a very flexible permissions model.

and so ultimately it also means that you can do things like if you're a developer, you can set up a name for your app that when entered into a browser resolves to your app, but you can then also set up rules that ensure that that name is stable. So you could set up version 1.0.0.0.0.0.0.0. Or something or safe.Eth or something like that. And you can provide an ironclad smart contract enforced guarantee that that version is immutable. and as we've seen with the recent by-bit hack, that can be a really valuable resource to have. And all of these things are like technically possible today with EnS.

They're just a lot more cumbersome to set up than they will be. Yeah, that makes a lot of sense. Is governance going to change in any way with B2? Not in a meaningful sense, like in the technical aspects, yes, because governance will now have to manage resources that are held across multiple chains. but ultimately we will handle it the same way, you know, token bridging and other things work. You know, governance initially will continue to be, and the ENS token will initially continue to be on main net.

When a contract that's owned by governance on name chain needs to be updated, it'll work by sending a message using the trustless bridge to that chain to affect the update. In the long term, but not at launch day, I would like to see us, you know, migrate Ns token to name chain and therefore most of the Dow's responsibilities there and sort of reverse that set up where main net changes are made via messages instead of the other way around. I hear that. So if you if you zoom way out kind of I mean obviously there was kind of this societal mission for ENS, namely kind of bringing this capability kind of like to the every man. If you look at tangible metham.

of kind of how people live their lives and kind of like what makes them better. What's the metric kind of you would point to to kind of reflect whether ENS works as intended? I think, you know, I've always had a sort of a three-part roadmap in mind for E&S in the very long term. the first is that people should generally be able to assume that the app they're using supports E&S and be surprised when it doesn't rather than surprised when it does. And I think we're 90% of the way there to that. ENS adoption in apps is pretty good with the notable exception of many centralized exchanges. And people now have this expectation that they can use their ENS names wherever they need to.

The second stage is that users should not have to deal with addresses at all, really. You know, this should be just as obscure a developer thing as IP addresses. And we're still a long way from that. And, you know, so that is the thing that I would like to focus on the most next. And in the final, you know, and much more pie in the sky one is that, like, everyone is using E&S-based naming for, you know, all technical resources. You know, we'll take over the world. speak, you know, only less megalomaniacly.

And, you know, so I think that that second goal is much more the practical one to be focusing on now. And I don't think it's an unreasonable one. It's just we need others to prioritize usability as much, you know, we need them to see it as important as we think it is. Yeah. I hear you there. When you think about time scales for these developments, Is this something kind of like you think of in a matter of months, years, decades? So, you know, one of my favorite saying is that people overestimate what they can do in a year and underestimate what they can do in 10. For the next year, we're very much focused on launching name chain and getting it, you know,

in production and fully functional. And, of course, our outreach efforts go on in parallel with that and are essential part of that, especially since we're going to need existing acts and wallets and so forth to upgrade to support name chain. I don't think it's unreasonable that a decade from now we would be, you know, in a situation where crypto is much more usable than today, primarily as a result of E&S names being ubiquitous. I think either we succeed in making crypto more usable, like, and by we owning the entire ecosystem, or we watch crypto sort of continue to be a hobby and a side project and, you know, not reach the mass market adoption we'd all like to see it achieve.

Yeah. What are your thoughts on kind of the current vibe in the ecosystem? So kind of having things like I don't really want to call the mass market kind of applications, kind of like selling meme coins probably. to me this is kind of like it's a very regrettable development but kind of like it is something that kind of like appears to a lot of people

and kind of like having that kind of happen on non-etherium chains as kind of like an ethereum of the first hour what does that do to your mind space what are your thoughts on kind of whether when, I mean, in the classest way of framing this question is, kind of like, when is it time to kind of move to Solana? I think that we've now, Ethereum has been around long enough to be able to extrapolate a trajectory here, which is that Ethereum researchers and community build interesting new ideas and then other projects borrow them.

And sometimes they do them to more commercial or widespread success than the people who originated them. And that's kind of a fact of life in a way. I think that Ethereum still has the most, you know, vibrant and productive developer ecosystem and core developers and sort of evolution. I personally believe that that makes it the best place to stick around with and where you're going to see the most interesting things.

and it has the best chance of succeeding. But, you know, the unfortunate long-term truth is that that's not always true in the real world. You know, Edison got a lot of publicity, and Tesla didn't. And, you know, regardless of their individual merits and personalities. So I don't have a guarantee that that's the case. It's just where I'm, you know, making my bets, I guess, figuratively speaking. What do you think kind of like we as the Ethereum community kind of need to do in in order to kind of remain competitive and relevant?

I think, you know, the risk of sounding like a broken record focusing more usability certainly helps. And, you know, most of us are here because we care about building decentralized systems. But there's also a need to sort of take a bit of a reality check and recognize that for a lot of users, their first steps into the ecosystem will be through centralized clearinghouses. and that rather than taking a peerist's approach of, you know, you have to join by doing this, that and the other thing and, you know, going to like a peer-to-peer exchange to buy your first ether and so on, we should recognize that these are crucial parts of onboarding people and making that path from, you know, initial steps to fully participating in a decentralized fashion is the really truly important thing. So I think kind of like in the ecosystem there's often kind of been this fallacy that people believe decentralization itself is a value to people, right? Kind of like if you speak with regular people, kind of like decentralization absolutely is not a value. It's kind of like what it can afford, right?

So how do we kind of take this super robust resilient infrastructure and kind of like build user experience? that are genuinely better than what people already have. Because not only do you have to have something that kind of like is usable. In my eyes, it's not enough to kind of not be worse than what they already have, right? And you have to be kind of like better in some very tangible way. Yes, absolutely. And I think perversely things like the SEC's hostility towards crypto did a lot of efforts on Ethereum, a great favour by demonstrating the value of all of this because it's much like, you know,

locks on your front door. 99% of the time they're an inconvenience. And the trick is convincing people that they're an inconvenience worth having because the 1% of the time that they matter, they save your bacon, so to speak. So I think part of it is that. But I, that, you know, that's still not necessarily a compelling, a compelling place to come from. We don't really want to be selling people seatbelts and convincing them that this is a great and sexy seatbelt. It's still a seatbelt. We do need to make the effort to make these

decentralized offerings every bit as compelling and as easy to use as centralized ones, and that is necessarily more difficult to do. I don't have a silver bullet except, you know, my earlier observation that often the important thing is here is having pathways that mean that you can engage to the degree it's important to you. So things like eth.link and east dot limo provide very easy but somewhat centralized ways for people to access IPFS. Knowing that that content is there, they can access it in the easy way. And if they're using it and their ISP or their government suddenly decides, you know, that's no longer acceptable to them, that content is there and they're one small step away from accessing it in a manner that's much more decentralized and

compatible with being sustainable in an hostile environment, so to speak. Other things you think we need to be cautious to not do or to not engage in, anything kind of like where you think kind of like as an ecosystem, it's inadvisable to kind of engage in that sort of behavior? Yeah. I think it matters a lot how you approach things. And so, you know, reacting with outward hostility towards legacy systems is never productive. And it also ignores the facts that very few productive things proceed by revolutions.

You know, much more succeeds through evolution. So, you know, partly for that reason, ENS integrates directly with DNS, because DNS is how most people on the internet live their lives. and use their systems. And it would be unrealistic to say, oh, we're just going to wholesale replace it from nothing. You know, it's much more productive to say ENS is a system that builds on and enhances DNS and adds these additional guarantees around sovereignty and uncensurability than it is to say, you know, we're just going to supplant it wholesale.

And so, you know, I'm sort of cautious of that same approach when taken for other things in the Ethereum and the wider crypto. ecosystem. And likewise, you know, thinking seriously about why these principles are important to us, you know, and it's not to defend the worst bad actors in our ecosystem who decide to use these platforms we build for ill. It's to defend the people who are, you know, are in regimes where they're being, you know, their ability to express themselves or to engage in, you know, legitimate political discourse are being suppressed, for instance, you know. And it's, you know, So it's important to say, you know, these are the things we're building for,

not just, you know, these are the institutions we're building against. I think these are super nice closing remarks. Nick, where can people come to kind of find out more about ENS, how to integrate, how to kind of partake in government, where can they hear your thoughts? So the main resource they should go to is E&S dot demand. domains. If you want to participate in the ENS Dow and governance of ENS, it's discussed.enS.combs. If you want to learn about building on top of VNS, then dox.ns.ns.comans.

And if for some reason you want to listen to me more, then I'm Nick S.D. Johnson on Twitter, although I don't post there as often as I used to. Super nice. Thank you so much for being here. It was my pleasure.