ENS V2 Cross-Chain Domains & Namechain - Nick Johnson. Ep. 593

Transcript

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 the 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 crosschain natively. The registry the sort of the core component of ENS uh or or the route as it were will always remain on Ethereum but we're launching namechain which is a a zk based L2 which

will host all nameains. Welcome to epicenter the show which talks about the technologies projects and people driving decentralization and the blockchain revolution. I am Frederick Ants and today I'm speaking with Nick Johnson who is the founder of ENS, the Ethereum name service. Um, and before I talk with Nick, um, let me tell you about our sponsors this week. If you're looking to stake your crypto with confidence, look no further than Chorus 1. More than 150,000 delegators, including institutions like BitGo, Panta Capital, and Ledger, trust Chorus One with their assets. They support over 50 blockchains and are leaders in governance on networks like Cosmos, ensuring your stake is responsibly managed thanks to their advanced me research. You can also

enjoy the highest staking rewards. You can stake directly from your preferred wallet. Set up a white label node, restake your assets on layer or symbiotic or use their SDK for multi-chain staking in your app. Learn more at chorus.1 and start staking today. This episode is proudly brought to you by Nosis, 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. Nosis DAO drives Nosis governance where every voice matters. Join the Nosis community in the Nosis DAO 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.io. IO 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 um on Epicenter several times, but for the people who missed it,

so the last time was a year and a half ago. Um but for the people who missed it, can you give us the TR on ENS for everyone who wasn't here for the last episodes? So, so ENS's uh key idea is that uh usability in web 3 ought to be every bit as 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 to log into a website, you know, a web 3 uh app or to send crypto to their friends or anything like that. So ENS's goal is to improve usability and it does that by uh 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. Uh and so you can use your ENS name to name your Ethereum account, your Bitcoin account, any other chain you like. Uh but we it's also your web3 profile. So it let you consolidate all of your profile information, have a portable profile that can be used across a variety of different uh you know platforms and apps. Uh and it can also be used for uh naming decentralized content such as decentralized websites through IPFS. Cool. Um I think that was a super comprehensive introduction to kind of like what what what the scope of ENS is.

Last time you were on we talked for a very long time about crosschain functionality. So kind of like when ENS started it was very much kind of like an Ethereum um main mainet project because kind of like at the at the time that was more or less all there was um 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 interoperate right kind of like do you have um a domain name service for each individual L2 each L1 or can you somehow marry these together. So you had super ambitious kind of um crosschain ideas back then. So te tell us kind of like

what your vision back then was and how this has evolved and what what kind of has manifested itself. Yes. So you you raised an important uh question which is you know in a 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 they need a single unified identity. And uh although ENS is hosted on Ethereum, it's not just for Ethereum.

And so our approach to solving this uh was as you as you suggest a multi-chain one uh and that involves a lot of crosschain communication and integrations. Um, effectively what we were proposing and working on back then is uh a way for people to delegate their names or their you know entire parts of ENS to other chains. Uh, and that has very much flourished since uh we last spoke. So right now you can get a uh base uh ENS name. So your name.baseeth or a uni uh ENS name from unis swap uh or a variety of others. And in each case, they're hosted on the chain of the

the issuers's choice. Uh, and you can register the name and it resolves uh just the same as if it was hosted on Ethereum. Uh, and we're doing that primarily using a a technology we developed called CCIP read that enables uh smart contracts, not just DNS, but we're the primary user uh to fetch data from outside the Ethereum blockchain in order to to finish their sort of execution. And that makes it possible to delegate all of this to to any arbitrary chain or even to things that aren't blockchains like DNS. So So where is the data ultimately stored that kind of like I delegate um to? So to use the example of uh base um uh and you know and

subnames on base the the actual data is stored on base uh the the L2 when you uh attempt to enter that name into your uh MetaMask or another um wallet uh it goes off and it consults uh Ethereum mainet and looks up uh you know the parent name uh and finds that that is uh you know then sending a referral to elsewhere and it does a query which ultimately results in looking up the data on base uh 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 elucidate a little bit more kind of if

kind of say I I register a name on base so I'm ess.e e or ns uh uni or kind of like do is it is it kind of like a top level domain system or how how do I think of this? Uh so so ENS is hierarchical much like the traditional DNS. So if you register um you know your name.baseeth 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.eth

chose to do. If you register your name, then it's registered on L1 because that's where itself is hosted. But once you've done that, you could choose to then delegate that to to any uh L2 of your choosing. Uh right now, that's a reasonable technical operation to undertake. Uh but you know, we fully intend to make that easier for people to do uh 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 um kind of derivatives I registered once on mainet and then kind of I own all the command thread addresses on the various subnet. So no one else can kind of register my um my name on these on on on

L2s or is it is it is it not blocked? Uh it's it's a little different. So if you register your nameeth then somebody else could still register your name.base.eth because those are considered to be totally distinct names. Okay. Uh there is a single registry a single sort of index of all names across all chains though. So there's no you know your nameeth on mainet distinct from your name.eth on base distinct from etc etc. It's much like uh uh if you imagine a uh the old sort of phone exchange system where you know you you call up an operator and then they direct you to the operator in 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 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 I mean I'm not that big a target but say for instance um vitilik registers vitilik and kind of like some other chain becomes available. I would assume kind of like his name would be the one of the first registered regardless of whether he does it himself or whether he doesn't. um do do you have any way of kind of um

adjusting for that? Yeah, it's a it's an unfortunate reality of a a permissionless system really and we definitely do see that sort of thing occurring. Um 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 to subnames to subdomains. Uh, and we kind of, you know, that's to our advantage because they're every bit as useful to a an end user as uh, a second level name as, you know, your name. But they are sort of less desirable to squat on and therefore more likely to be available uh, you know, and less likely to be sort of uh, snapped up as soon as they're issued. Um, but it is a definite

issue. Um, there's not really one good solution. You know, there's a number of approaches that different uh issuers and different name owners have taken. Uh the obvious one is that you simply, you know, allow them to be first in first served. Um 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 uh 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 Vitalic, you get Vitalic.base.eth um or they've, you know, proactively

reached out to these people. Um the you know the the final option is to set up some sort of disputes and and sort of arbitration system uh which has historically been an unpopular option because it's uh much more prone to abuse by the the people maintaining the names and we really like to emphasize the importance of of trustless name ownership in ENS. But ultimately if you own the parent name it's up to you to decide how trustless you want your subnames to be. Okay. Okay, that's fair.

Often times kind of wallets resolve addresses even on networks that they're not registered, right? So for instance, I um I own Ferns.eth because that's my name and kind of like if I send um funds to Ferns on Nosis, it they still arrive in in my in my um in my wallet. So how's how is that handled? Is that 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 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 it wants to resolve. So that can be you know any L2 chain that has a chain ID or it can even be any uh you know crypto chain uh in general using a coin type. So you can resolve a bitcoin address on it as well. Um 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 uh to linear but you could then use it to resolve bitcoin addresses.

Cool. Thank you for sh sh sh sh sh sh sh sh sh sh sh sh sh sh sh sh sh sh sh sh shedding so much light on the crosschain um evolution. Um 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 um ENS domains with fiat. Um who are these users who are actually buying ENS 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 uh so so we do have support for buying uh ENS names with fiat through our app, but the integrations with PayPal and

Venmo are primarily for their crypto wallets where it allows you to uh send crypto to to ENS names from inside their apps. Um but I think both are important because you know I I alluded earlier that really ENS's job is usability and a big chunk of that is being an on-ramp and and you know making it easy for people to have a really easy starting point in crypto and uh so we want to make it very easy for people to get involved right from from day one and they shouldn't have to go through a series of you know steps into evolving copying and pasting addresses before they can get to the point where we're involved. So we are big fans of 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 that makes a lot of sense. Uh I I totally misunderstood those integrations, but that makes much more sense that someone can kind of Venmo me money at at my ETH address. Um how how do you handle fees um when that happens? So kind of typically kind of on-ramps are pretty expensive one way or another and then they they would also kind of have to cover um the the onchain uh the onchain uh transaction fees. Yes. Uh so I haven't used the PayPal integration myself because it's not available in my country. Um but uh my understanding is

they uh they don't charge any fees over and above network fees. um at least from my reading the the material available um and so it's it's quite affordable for their users. Uh when it comes to name registration which we've done through services such as Moon Pay uh 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, so GoDaddy uh integrated ENS name support for uh for um DNS resolution. ENS is integrated with DNS almost since day one. Uh and so now with GoDaddy, uh that's a great deal simpler for users to set up because the the steps to 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 ENS, 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 other crypto uh chain addresses and it will just do all of the the stuff behind the scenes to make that work. Uh the integration with Google has primarily been around Google search. So now you can search any 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 step forward. Yeah, that that's that's certainly very useful and I've used that in the past. You guys have been working on an upgrade to the general ENS protocol um ENS v2. um can you detail um kind of what you'd like to

um achieve with this upgrade? So kind of like h how how will ENS be better after than it is now? Absolutely. So, you know, I've already talked about our crosschain efforts uh and and that was sort of step one in being more um supportive of of multiple chains uh 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 over time. Uh and if we want to attract new users who are new to crypto and who are you know just on boarding a system where you have to pay you know three times as much as the

actual ETH registration cost and transaction fees uh and then pay similar fees when you want to update your name is is simply not practical and we can't even expect users to to do that and then delegate it elsewhere and that means that uh registering renewing updating ethnames has to be much cheaper by default and ultimately that means ENS needs its own L2. Um so we continue to you know we intend to continue to support other L2s and other offchain systems as first class citizens but what we're doing effectively is migrating the the sort of the main registry to its own chain. Um and you know while we were doing that we sort of

look took a a critical look at the the core ENS infrastructure and said well it's been I don't even know how many years is it seven now um and you know what have we learned in the last few years about ENS and what have what's changed in the the ecosystem that means our needs are different and so how can we improve the system so ENS2 represents a complete rewrite of ENS um we've you know changed some of core smart contracts and and the way things are structured uh and at the same time we're moving it to be truly crosschain natively. So the uh c the registry the sort of the core component of ENS uh or or the route as it were will always remain on Ethereum but we're launching

namechain which is a a zk based L2 which will host all names uh and can also be used by anyone else who wants to to host ENS records there. Um, and we're so we're moving all the EET 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 name to this new chain. Um, what what's the stack um you're using for this? We're working with uh consensus and the linear team. Uh so we're building our own rollup based on linear uh stack where we have a few uh somewhat odd requirements of our own that mean we don't want to just use

the linear mainet. Uh chief amongst those are we have very strong requirements on decentralization. So it's very important to us to build a credibly decentralized rollup. Uh and that means ultimately becoming a base rollup. Um, and we have some interesting requirements because um, 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 and showing up has to be low. And that's not a a metric rollups tend to prioritize by default because naively at least that means committing to mainet more often. means finalizing more often and that in

introduces additional uh costs because of the additional traffic on L1 and we have some some novel uh improvements there that can can improve that latency without additional costs. Uh but that required us to work with Linear to to make a custom chain. Tell me about those improvements. Uh so I think the one I'm 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 uh being able to prove on L1 what the L2 state is uh as quickly as possible and 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 uh your typical L2 your ZKbased L2 the way it works is it grabs batches of blocks and 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. uh 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 mainet as proof that more recent states than the most recent finalized one are actually valid. So what happen what will happen when you resolve an ENS name that's stored on namechain is the uh the service will return to you the result along with a proof that that's part of the the namechain state and a proof a zk proof that that state is valid and is uh you know subsequent block to the one that was actually last finalized on mainet. So by doing that we get the latency way down but we don't have the massive additional costs of of finalizing every 10 or 15 minutes.

Okay that makes sense. So how often do you then finalize on mainet? Uh so you know it will be a little flexible in terms of uh you know mainet gas prices and load on namechain and so on. I think our target will be similar to linear where it's in the region of every hour to 2 hours. Um but ultimately that will only affect things like uh you know the trustless bridge latency and so forth. It won't affect uh name resolution. So if you if you look at that in the limit I mean you could kind of you could you could always think uh 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 mainet and you can always you can always prove that

you could finalize to mainet. So what's what's this is somewhat philosophical question but what's the point in then kind of like um finalizing to mainet at all. It's it's an interesting thought. Yeah. And it's uh you know if you look at chains like optimism they're perfectly happy with a 7-day latency. So you know optimistically we don't need to do it so often. We do need to do it ultimately though because uh we want to be able to uh send tokens between chains, you know, primarily for things like uh paying for the ENS 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 ethnames back to L1 if they need the sort of absolute ironclad guarantees of of security. it can provide and so that will also require using the the canonical token bridge and that will be you know somewhat slower uh you know in the bounded by the latency of finalization. H how do how do you move a token that was originally minted on an L2 to to mainet? So what we do effectively is we have one token contract on uh namechain uh and that is incorporated into the registry which tracks all names uh or or all names regardless of their state. Um and

then we have a second contract on mainnet which tracks only the names that have been moved to to mainet. And so when you go to move the name effectively what happens is uh the token contract on L2 uh sends a message to the token contract on L1 saying uh you know this contract is this this name is being ejected um and then it transfers ownership of the L2 contra uh token to a sort of a holding contract so that it can't be moved around while it's you know effectively held on L1. Uh and then on L1 the contract mints uh a new token that represents that same name and transfers it to the account the user uh the user nominated.

Okay. So, so tell us about the security assumptions here behind the sequencer, right? Because kind of like if if I kind of if I want to use my uh if I want to move my ferns um domain from um namechain to to mainet um 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. Uh absolutely right. And so there's there's two solutions to this. One is uh that we uh believe having a decentralized

sequencer is very important. And so our goal is to launch with based sequencing, which means that ultimately any L1 uh sequencer can also be a namechain sequencer. Um if that's impractical because of uh you know development status or or costs uh then we're going to launch with forced inclusion as a a basic primitive and then migrate to based as as soon as possible. Um and in either case it's possible to to use consensus rules to force inclusion of a particular transaction. Uh the second component is that once you have moved your name to L1, there's no action the L2 can take that affects the the resolution of that because when when resolving it first consults the L1

before checking the L2. So assuming you're able to eject the name once, no compromise or or you know action on the L2 can can affect that going forward. And when it comes to migration day and people migrating over from ENS v1, it will be their choice whether they migrate the name to L1 or to namechain. Okay. So given I'm already um a V1 user, um do I need to do anything or what happens to my name during migration? Uh yeah. So so effectively what you actually have is three choices. One choice is to do nothing. Mhm. And in that event, yes. Uh and in that event, your name will continue resolving indefinitely. Um you will continue to

use the V1 contracts and so on for any updates. Um if you want to renew the name, you'll still have to do it through the V2 contracts, but that would have be the only way you would interact with them. Um however, of course, it won't show up in the same NFT collections as as any other name. If you transfer it to someone, they would have they would then be getting a V1 name. uh and you won't be able to take advantage of any of the new features or functionality. Um your second choice is to to migrate to to namechain 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 namechain in which case you get the best benefits of of lower gas costs and

so forth. Okay. Tell me about the new features in a minute, but kind of before we before we go into that, um, how do you think about the long-term scalability? Because kind of like with based rollups, um, kind of what you very much have is, um, kind of this data availability paradigm where you kind of you you post all transaction data to blobs on L1. And currently um that's that's not a bottleneck but kind of like if if you expect kind of like the world's main domain uh domain name system to kind of move on chain you know or kind of even a significant proportion of that certainly that's going to become a factor.

Uh so I think yes and no. You know definitely scalability is an ongoing effort. Um, I think you'd be surprised by the the volume of like all existing DNS registrations. You know, I have a a a friend whose hobby is downloading all the root zone files, and he does this regularly on a small group of Raspberry Pies he has. Um, and I I haven't asked him, but I suspect the total size is actually smaller than the Ethereum mainet today. Um, okay. So I understand that, but kind of like also the DNS kind of like the the scope for that is way way smaller than kind of like what ENS intends to become, right? So kind of like if if if I were to kind of send you I don't know we we went out for a drink

and kind of like I want to refund you five quid for my for for for my pint then kind of I um kind of I could probably send it to Nick or kind of like on any on any other chain. And this is not something that I would typically do kind of in in the DNS. So kind of I wouldn't I wouldn't expect kind of like ju just you know every Tom, Dick, and Harry to kind of have their own domain name registered. Yep. No, fair enough. And and consider me schooled on on uh on ENS scalability. You're absolutely right. Um I I think you know that there's two factors there. one is that I I still do believe that the scalability is is not, you know, we're no more than an order of magnitude off at worst from 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. Um, and I I think the the Ethereum road map contains enough improvements to that that uh I'm not overly concerned about it. Um ultimately it may be more an issue of uh the cost effectiveness of this because of course you know Ethereum block space and blob space is demand driven and we'd be competing not just with other ENS users but with all rollup users. Um ultimately we we have the option to move uh data availability offchain. Um, it's something I'd prefer not to do, however,

because it has the, you know, the absolute gold standard in terms of, uh, guaranteeing availability and of decentralization. Mhm. Yeah. Um, hear you there. Tell me about the new features I can access um, if I decide to not do nothing but kind of like move my name over. Yep. Um so the the primary thing I think is when we built ENSV1 uh we built in upgradability and sort of uh 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. Uh it's up to you. And if you have a custom resolver, you can

build in whatever functionality you like to change how names resolved. But ultimately ownership was still controlled under the single central contract, the ENS registry, which decides uh you know 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 you know over time we've increased the flexibility of that. And the the most recent effort around that was the name wrapper which adds sort of additional programmability to to name ownership. But it's ultimately still limited by the v1 architectures rules around ownership.

The big change in v2 is that uh name ownership is now hierarchical just like uh the names themselves are. So if you own uh you know your name.eth ETH you can uh use sort of any implementation you want to to configure the ownership of that. We call them registries. Um and you can set rules for issuing subdomains. You can set rules for uh you know for permissions on those and so on and so forth. Um and you can do that on mainet or on namechain. And so that makes it much more flexible for for applications like issuing subdomains and so forth. And this is not something that 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 are there already applications that you have in mind that kind of like will will um will make use of this? Uh I think you know subdomain issuance is the the really obvious one. Yeah. Um and you know previously this has been a bit more difficult because it's it's relied on things like the name wrapper and it's had to be a lot more sort of bespoke for people to set up. Um 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 you know when entered into a browser resolves to your app but you can then also set up rules that ensure uh that that name is stable. So you could set up you know version version one you know Nosis or something or safe or something like that and you can provide an ironclad smart contract enforced guarantee that that version is immutable. Um, and as we've seen with the recent uh bybit hack, that 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 that that makes a lot of sense. Um, is governance going to change in any way with B2? uh not in a a meaningful sense like in the technical aspects yes because governance will now have to manage resources that are held across multiple chains um but ultimately we will handle that 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 mainet uh when uh a contract that's owned by governance on namechain needs to be updated it'll work by sending a message using the trustless

bridge to to that chain to to affect the update. Uh in the long term, uh but not at launch day, I would like to see us, you know, migrate name uh ENS token to to namechain and therefore most of the DAO's responsibilities there and sort of reverse that setup where where mainnet changes are made via messages instead of the other way around. I hear that. So if you if you zoom way out um 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 um tangible metrics of kind of how people live their lives

and kind of like what what uh uh like what um makes them better. what's the metric kind of you would point to to kind of reflect whether ENS works as intended? Um, I think, you know, I've always had a sort of a a three-part road map in mind for ENS in the very long term. Uh, the first is that uh people should generally be able to assume that the app they're using supports ENS uh and be surprised when it doesn't rather than surprised when it does. Um, and I think we're 90% of the way there to that. You know, ENS adoption in in apps is pretty good with

the notable exch of of many centralized exchanges. Um, and people now have this expectation that they can use their their ENS names uh wherever they need to. Um, the second stage is that users should not have to deal with uh addresses at all really. You know, this should be as just as obscure a developer thing as IP addresses. and we're still a long way from that. Um, and you know, so that is the thing that I would like to to focus on the most next. And then the final, you know, and and much more pie in the sky one is that like everyone is using ENS based naming for for, you know, all technical resources, you know, we'll take over the world, so to speak,

you know, only less megal megalomaniacally. Um, and you know, so so I think that that second goal is 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 uh usability as much, you know, we need them to see it as important as as we think it is. Yeah. Um I I hear you there. When you think about time scales for these developments, um is this is this something kind of like you you think of in a matter of months, years, decades?

Uh so you know one of my favorite sayings is that people overestimate what they can do in a year and underestimate what they can do in 10. Um for the next year we're very much focused on launching namechain and getting it you know in production and fully functional. Um and of course our our outreach efforts go on in parallel with that and are essential part of that especially since we're going to need existing apps and wallets and so forth to upgrade to support namechain. I don't think it's unreasonable that a decade from now we would be you know in a situation where where crypto is is much more usable than today. Uh primarily as a result of of ENS names you being ubiquitous.

I think either we succeed in making crypto more usable like and by we I mean the entire ecosystem or we watch crypto sort of continue to be a a hobby and a side project and uh you know not reach the 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 them mass market kind of applications kind of like selling selling meme coins probably to me this is kind of like it this is um it's a very regrettable development but kind of like it is something that kind of like appeals to

to a lot of people and kind of like having that um kind of um happen on um non-ethereum chains um as as kind of like a an Ethereum of the first hour, what does that do to kind of your mind space? What what are your thoughts on kind of whether when I mean in the crassest way you're framing this question is kind of like when is it time to kind of move to Solana? I I think that uh we we've now Ethereum has been around long enough to be able to 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 or or widespread success than than the people who originated them and that's you know kind of a fact of life in a way. Um I I think that Ethereum still has the most uh you know vibrant and and productive developer ecosystem and core developers and sort of you know evolution. Um 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. Um but you know the unfortunate long-term truth is that that's not always true in the real

world. you know, um, Edison got a lot of publicity and Tesla didn't. Um, and, you know, regardless of their individual merits and personalities. Um, 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 What do you think kind of like we as the Ethereum community kind of need to do in order in order to kind of remain competitive and relevant? I think uh you know the risk of sounding like a broken record uh focusing more on usability uh certainly helps and you know we 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 and recognize that for a lot of users their first steps into the ecosystem will be through centralized clearing houses. Um and that rather than taking a purist'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 your first ether and so on. Um we should recognize that these are crucial parts of of onboarding people and that making that path from you know initial steps to to fully participating in a decentralized fashion is is the really truly important thing.

So I I think kind of like in the ecosystem there's always there's 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 what it can afford, right? So, how how do we how do we kind of take um this super robust resilient infrastructure and kind of like build user experiences that are genuinely better than what people already have because kind of like not not only do you have to have something that kind of like is usable, it's in my eyes, it's not it's not enough to kind of not be worse

than what they already have, right? Kind of 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 favor by demonstrating the value of all of this because it's it's much like, you know, locks on your front door. Uh 99% of the time they're an inconvenience. Um and the trick is convincing people that they're an inconvenience worth having because the the 1% of the time that they matter, they they save your bacon, so to speak. Um, so I think part of it is is that um, but I that, you know, that's still not necessarily a compelling uh a

compelling place to come from. You know, we we don't really want to be selling people seat belts and and convincing them that this is a great and sexy seat belt. It's still a seat belt, you know. Um we we we do need to to make the effort to make these decentralized uh offerings every bit as as compelling and as easy to use as centralized ones. And that is necessarily more difficult to do. Um I don't have a silver bullet except you know my my earlier observation that often uh the important thing is here here is having pathways that mean that you can engage to the degree it's important to you. So things like eth.link and eth.l limo provide very easy but somewhat centralized ways for people to access IPFS

um knowing that that content is there they can access it in the easy way and if they're using it and their their ISP or their government suddenly decides you know that's no longer acceptable to them that content is there and they they're one small step away from accessing it in a manner that's much more decentralized and and compatible with being you know sustainable in a 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 where you think kind of like as an ecosystem it's inadvisable to kind of engage in that sort of behavior. Yeah. I I think it's it it matters a lot how you

approach things and so you know reacting with outward hostility towards legacy systems is is never productive. Um and it also ignores the fact that that very few productive things proceed by revolutions. You know much 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 and use their systems. Um, and it would be unrealistic to say, "Oh, we're just going to the 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 and

uncensorability than it is to say, you know, we're just going to supplant it wholesale. Um, and so, you know, I'm sort of cautious of that same approach when taken to taken for for other things in the Ethereum and the wider the wider crypto ecosystem. Um, and and likewise, you know, thinking seriously about why these 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 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 their ability to express themselves or to to engage in, you know, legitimate political discourse

are being suppressed, for instance, you know, and it's so it's important to to say, you know, these are the things we're building for, not just, you know, these are the the institutions we're building against. I think the these are super nice closing remarks, Nick. where can where can people um come to kind of find out more about ENS um how to integrate how to kind of partake in government um where can they hear you your thoughts uh so the the main resource they should go to is ensomains uh if you want to participate in the ENS DAO and and governance of ENS it's discuss doommains uh if you want to learn about building on top of ENS then

docs.NS PNS.domains. Uh, and if for some reason you want to to listen to me uh more, then I'm Nick SD Johnson on 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.