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 E, the sort of the main registry, to its own chain. So ENS 2 represents a complete rewrite of ENS, and at the same time we're moving it to be.
Truly cross chain in natively the registry, the sort of the core component of ENS or or the Rouge as it were will always remain on Etherium. But we're launching name chain which is a AZK based L2 which will host all dot ETH names. Welcome to Epicenter, the show which talks about the technologies, projects and people driving decentralization and the blockchain revolution. I'm Federica Ants 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 course one. More than 150,000 delegators, including institutions like Bit Gold, Pantera Capital and Ledger Trust. Course one with the assets they support over 50 block chains and their leaders in governance on networks like Cosmos, ensuring your stake is responsibly
managed. Thanks to the advanced MEB 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 Eigenia 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 you by Nosis, A collective dedicated to advancing a decentralized future.
Nosys leads innovation with Circles, Nosys Pay and Metri, reshaping open banking and money. With Hashi and Nosys VPN, they're building a more resilient, privacy focused Internet. If you're looking for an L1 to launch your project, Nosys Chain offers the same development environment as Aetherium with lower transaction fees. It's supported by over 200,000 Ballot Aires, making Nosys Chain a reliable and credibly neutral foundation for your applications.
Gnosis Dow drives Gnosis governance, where every voice matters. Join the Gnosis community in the Gnosis Dow forum today. Deploy on the EVM compatible Gnosis Chain or secure the network with just one GNO and affordable hardware. Start your decentralization journey today at gnosis dot 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 on epicentres 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 TLDR on ENS for everyone who wasn't here for the last episodes? So so E&SS key idea is that 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 app or to send crypto to their friends or anything like that. So E and 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 ENS name to name your Ethereum account, your Bitcoin account, any other chain you like. But. We it's also your Web 3 profile, so it lets you consolidate all of your profile information, have a portable profile that can be used to cross a variety of different, you know, platforms and apps. And it can also be used to for naming decentralized contents such as decentralized websites
through IPFS. Cool. I think there was a super comprehensive introduction to kind of like what what 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 main net project because kind of like at the at the time that was more or less all there was and kind of then obviously kind of like L
twos and other L ones. And so came about and there was the question of kind of like, how do you actually make those interoperate, 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 what kind of has manifested
itself? Yes. So you, you raise an important 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 although ENS is hosted on Ethereum, it's not just for Ethereum.
And so our approach to solving this was as you, as you suggest, a multi chain one. And that involves 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, you know, entire parts of ENS to other chains and that has very much flourished since we last spoke. So right now you can get a base dot ETH ENS name, so your name dot base dot ETH or a uni dot ETH ENS name from Uniswap.
Or a variety of others. And in each case, they're hosted on the chain of the the issuer's choice and you can register the name and it resolves just the same as if it was hosted on Etherium. And we're doing that primarily using a technology we developed called CCIP Read that enables smart contracts, not just DNS, but we're the primary user to fetch data from outside the Etherium 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. So where's the data ultimately stored? They're kind of like I delegate to. So to use the example of base dot ETH and you know and. Sub names on base. The the actual data is stored on base.
The 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 in 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. OK, 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 Ernst dot base dot ETH, do I automatically also have other names?
So kind of like could I also get Ernst dot ETH or Ernst dot arbitram dot ETH or Ernst dot uni dot ETH? Or kind of like, is it, is it kind of like a top level domain system or how, how do I think of this? So. So ENS is hierarchical, much like the traditional DNS. So if you register you know your name dot base dot ETH, 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 dot ETH chose to do.
If you register your name dot ETH, then it's registered on L1 because that's where dot ETH itself is hosted. But once you've done that, you could choose to then delegate that to to any L2 of your choosing. Right now that's a reasonable technical operation to undertake, but you know, we fully intend to make that easier for people to do on their own in future.
OK. So the idea is that kind of like if I kind of like want all the my first name dot ETH kind of derivatives, I registered once on mainnet and then kind of I own all the commensurate addresses on the various Sup net. So no one else can kind of register my my name on these on, on, on L2. So is it? Is it? Is it not? Blocked.
It's it's a little different. So if you register your name dot ETH then somebody else could still register your name dot based dot ETH because those are considered to be totally distinct names. OK. There is a single. Registry a single sort of indexable names across all chains, though, So there's no, you know, your name dot ETH on mainnet, distinct from your name dot ETH on base, distinct from, etcetera, etcetera.
It's much like if you imagine a. 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.
OK. 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, Vitalik registers Vitalik dot ETH 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 do do do you have any way of kind of
adjusting for that? Yeah, it's a, 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 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 dot ETH. 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 1 is that you simply, you know, 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 you're Vitalic, you get vitalic dot base dot ETH or they've, you know, proactively reached out to these people. The, you know, the, the final option is to set up some sort of disputes and, and sort of arbitration system, which has historically been an unpopular option because it's 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 sub names to be. OK, OK. That's fair. Often times kind of wallets resolve addresses even on networks that they're not registered, right. So for instance, I I own F Ernst dot ETH because that's my name. And kind of like if I send funds to F Ernst dot ETH on noses it, they still arrive in, in my in my in my wallet.
So how's, how's that handed? Is that just kind of like a resolution on the wallet on the wallet side? Yes, absolutely. So, you know, we have a main record type, you know, Ethereum address was the sort of the original type. But since then, you know, since L2's 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 you know. 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 to linear but. You could then use it to resolve
Bitcoin addresses. Well, 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 ENS domains with Fiat. 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?
So, so we do have support for buying 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 send crypto to to ENS names. From inside their apps, but I think both are important because, you know, I I alluded earlier that really EN s s job is usability and a big chunk of that is being an on rampant 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 from day one. And they shouldn't have to go through a series of, you know, steps into involving 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. 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. How how do you handle fees when that happens? So kind of typically kind of on Rams are pretty expensive one way or another. And then they they would also kind of have to cover the, the on chain, 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 the material available and so it's 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, so GoDaddy integrated ENS name support for for DNS resolution. ENS has 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 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 see it specific records on your name that say when you resolve this name and ENES, 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 into their Etherium address. Or other crypto. Chain addresses and it will just do all of the stuff behind the scenes to make that work.
The integration of Google has primarily been around Google search, so now you can search any dot ETH address inside Google search and right up the top of the search results is a nympho 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 ENS V2. Can you detail kind of what you'd like to achieve with this upgrade? So kind of like how how will ENS be better after than it is now? Absolutely. So you know I've already talked about our cross chain efforts and and that was sort of step one in being more. Supportive of 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 over time 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 dot E registration cost and transaction fees. 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 registering, renewing, updating dot ETH names has to be much cheaper by default. And ultimately that means ENS needs its own L2. So we continue. To, you know, intend to continue to support other L twos and other off chain systems as first class citizens. But what we're doing effectively is migrating dot ETH the the sort of the main registry to its
own chain. And you know, while we were doing that, we sort of look, took a critical look at the, the Corey and S infrastructure and said, well, it's been. I don't even know how many years is it 7 now? 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 ENS 2 represents a complete
rewrite of ENS. We've, you know, changed some of the core smart contracts and, and the way things are structured. And at the same time we're moving it to be truly cross chain in natively. So the the registry, the sort of the core component of ENS or or the rouges that were will always remain on Etherium. But we're launching name chain which is a AZK based L2 which will host all dot ETH names and can also be used by anyone else who wants to to host ENS records there.
And we're, so we're moving all the dot ETH 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 dot ETH name to this new chain. And what? What's the stack you're using for this? We're working with consensus and 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, 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, 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 main it more often and it means finalizing more often.
And that and introduces additional costs because of the additional traffic on L1. And we have some some novel improvements there that can can improve that latency without additional costs. But that required us to work with linear to to make a custom chain. Tell me about those improvements. So though I think the one I'm I'm sort of proudest of is one that we came out 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 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 then 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 as 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 finalisation. And we can use these intermediate proofs that get generated but not submitted to mainnet as proofs that more recent states than the most recent finalised one are actually valid. So what happened? What will happen when you resolve an ES name that's stored
on main chain is the. The service will return to you the result along with a proof that that's part of the the name change state and a proof ZK proof. That that state is valid and is, you know, 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 of finalizing every 10 or 15 minutes. OK, 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, mainnet 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, if you look at that in the limit, I mean, you could kind of you could, 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 finalized to mainnet and you can always, you can always prove that you could finalize to mainnet. So what's, what's this is somewhat philosophical question, but what's the point? And then kind of like finalizing
to mainnet at all? It's an interesting thought, yeah. And it's, you know, if you look at chains like optimism, they're perfectly happy with the 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, you know, primarily for things like 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 dot E 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 the canonical token bridge and that will be, you know, somewhat slower, you know, in the bounded by the latency of
finalisation. How do How do you move a token that was originally minted on an A to to 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 dot ETH names regardless of their state. And then we have a second contract on mainnet which tracks only the names that have been moved to 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, this name is being ejected. And then it transfers ownership of the L2 contract token to sort of a holding contract so that it can't be moved around while it's, you know, 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 if the user nominated. OK, 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, if I want to move my FN dot ETH domain from name Jane to to mainnet, 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 sequencer, I kind of can't force an exit. Yes, absolutely right. And so there's 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
change sequencer. If that's impractical because of, you know, development status or 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 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 the resolution of that, because when we're 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 ENESB 1. It will be their choice whether they migrate the name to L1 or
to name chain. OK, so given I'm already AV1 user, do I need to do anything or what happens to my name during migration? Yeah. So, so effectively what you actually have is 3 choices. One choice is to do nothing. That's a good choice. And in that. Event Yes, and in that event your name will 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 have. They would then be getting AV. One 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. OK, tell me about the new features in a minute, but be kind of before we 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, you post all transaction data to blobs on L1. And currently that's, that's not a bottleneck. But kind of like if if you expect kind of like the words main domain, Domain Name System to kind of move on share, you know, 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 scalabilities in ongoing effort. I think you'd be surprised by the the volume of like all existing DNS registrations. You know, I have 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, and I. I haven't asked him, but I suspect the total size is actually. Smaller than than Ethereum. May need today.
OK, 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, we went out for a drink and kind of like I want to refund you £5 for my for, for my pint. Then kind of, I kind of I could probably send it to Nick dot ETH 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 just, you know, every Tom, Dick and Harry to kind of have their own domain name registered. Yep, No, fair enough. And, and considerably schooled on, on, on it is scalability. You're absolutely right.
I, I think, you know, there's two factors there. 1 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 and I, I think the, the Etherium. Road map 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, 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 roll up users. Ultimately, we we have the option to move data availability off chain. It's something I'd prefer not to do, however, because it has the, you know, 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. Yeah. So the, the primary thing I think is when we built ENSV one, we built in upgrade ability 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. Her name's resolved, but ultimately ownership was still controlled under the single central contract, the ENS registry, which decides, you know, who owns a name and what the rules are for changing ownership names, what the rules are for creating subdomains and so on. And you know, over time we've increased the flexibility of that.
And they 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 architecture's 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, you know your name dot ETH, you can use sort of any implementation you want to to configure the ownership of
that. We call them registries, and you can set rules for assuring subdomains. You can set rules for. You know, for. Permissions on those and so on and so forth. And you can do that on main net or on main chain. 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 sub domain 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 will make use of this? I think, you know, sub domain issuance is the the really obvious one. 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. 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, but you know, we need to do into a browser results to your app. But you can then also set up rules that ensure that that name is stable. So you could set up, you know, version version 1 dot, you know, Gnosis. Dot ETH or something or safe dot 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 Buybit 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. 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 to that chain to to affect the update in the long term. But not at launch. Day I would like to see us, you know, migrate ENS token to to name chain and therefore most. Of the Dow's. Responsibilities there and sort of reverse that set up where 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 Everyman. If you look at tangible metrics of kind of how people live their lives and kind of like what, what, 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 road map in mind for ENS in the very long term. The 1st is that people should generally be able to assume that the app they're using supports ENS 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. You know, ENS adoption in in apps is pretty good with the notable exchange exception of
many centralized exchanges. And people now have this expectation that they can use their 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 as 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 to focus on the most
next. And in the final, you know, and, and much more pie in the sky 1 is that like everyone is using E&E space naming for, for, you know, all technical resources, you know, it will take over the world, so to speak, you know. And the list megalomaniacally. 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 usability as much, you know, we need them to see it as important as as we think it. Is. Yeah, I, I hear you there. When you think about time scales for these developments, is this, is this something kind of like you you think of in the matter of months, years, decades? So, you know, one of my favorite saying is, 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 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 where crypto is is much more usable than today, primarily as a result of ENS 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 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 it's a very regrettable development, but kind of like it is something that kind of like appears to to a lot of people and kind of like having that kind of happen on non Ethereum chains as as kind of like a an
Ethereum of the first hour. What does that do to you kind of your mindspace? What what are your thoughts on kind of whether when I mean in the classes way of framing this question is kind of like when is the time to kind of move to Solana? I. I think that 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 the people who originated them. And that's, you know, kind of a fact of life. In a way. I, I think that Ethereum still has the most, you know, vibrant and, and productive developer ecosystem and core developers and sort of, you know, 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, 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 you know the risk of sounding like a broken record. Focusing more usability 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 and that.
Rather than taking a purists 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. We should recognize that these are. Crucial parts of onboarding people and making that path from, you know, initial steps to to fully participating in a decentralized fashion as is the really truly important. Thing.
So I, I think kind of like in the ecosystem, there's, 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 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 SC CS hostility towards crypto did a lot of efforts on Ethereum, a great favour by demonstrating the value of all of this, because it's, 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, the 1% of the time that they matter, they, they save you bacon, so to speak.
So I think part of it is, is that, but I that, you know, that's still not necessarily a compelling, a compelling place to come from. You know, we, we don't really want to be selling people seatbelts and, and convincing them that this is a great and sexy seat belt. It's still a seat belt, you know. We, we, we do need. To to make the effort to make these decentralized offerings every bit as 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 my earlier observation that often 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 dot link and ETH 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, 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 inadvisable to kind of engage in that sort of. 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 and. It also ignores the facts 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 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 and uncensorability than it is to say, you know, we're just going to supplant at wholesale. 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.
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 I'll, it's to defend the people who are, you know, are, 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 of 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 these these are super nice closing remarks, Nick, where can 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 you your. Thoughts. So the the main resource they should go to is ENES dot
domains. If you want to participate in the ENS Dow and governments of ENS, it's discussed dot ENS dot domains. If you want to learn about building on top of ENS, then docs dot ENS dot domains and if for some reason you want. To listen to me more than I'm Nicky Steve 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.