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.