Welcome to Epicenter, the show which talks about the
technologies, projects and people driving decentralization
and the blockchain revolution. I'm Sevaston Quichio and today
my guest is Nick Johnson. He's the founder of ENSENS is
the Theorem Name Service. It is the most used, most widely
used decentralized naming service and the biggest Dow on
Etherium. And we had Nick on a year ago.
And so we're having him back on today to give us a bit of an
update on ENS and talk about some of the interesting
technical things that are happening with the protocol in
terms of expanding to L twos. We'll also talk about
governance. We'll talk about some of the
growth that ENS has seen in the last little while and also
looking to the future and where the project is going next.
Thanks for coming on. They should be here again.
So for those who missed the last episode, who maybe had never
heard of you or never heard of VNS, which I'm sure is very few
people, yeah, why don't we start with a bit of background and you
know how you became interested in decentralized naming
services? Sure.
Yeah. So I've been a software engineer
for About God about. 20 years now.
And I've always had interest in sort of Internet infrastructure
and so forth. And you know, when when I first
heard about Bitcoin way back, I sort of looked into it and I was
like, oh, that's kind of interesting.
But that was just money. You know, like there's what I
really want is a programmable platform.
And so I sort of ignored it for a while.
And then sometime later came across Ethereum and went
suddenly, wow, this is exactly what I was thinking about.
This is really very cool. Started playing around with it
almost immediately and inside of you know three months was got a
call from the Ethereum Foundation saying hey would you
like to come work with us on on you know go Etherium or on Swarm
or you know something something we're working on was a bit of a
plunge for me because it was going from the comfort of like
full employment to to a contractor position you know big
pay cut you know unknown future etcetera, but.
I was really quite hooked on you know Etherium and and what we
could build with this. And so I I quit my job.
I I joined the Etherium Foundation and pretty much one
of my first jobs was to start working on well, I I started
working on Swarm and my first sort of side project was you
know what can I build in the way of a naming service?
Because one of the very first things.
That I noticed was how bad the user experiences with, you know,
42 character long and hexadecimal addresses and so
forth. And I was like, why is this not
already here? You know, this seems like a
really basic bit of infrastructure to allow people
to, you know, not just transact with each other but interact
with contracts and so forth without having to know, you
know, the these identifiers. You know, We solved this on the
Internet in like 1985. So I started working on what
eventually became the Etherium Name Service.
Started off as a sort of a side project from within the EF
gradually grew to take more of my time until it was my full
time job there. And then at some point the EF
went well. You know, it's clear that this
is more than one person's work, You know, what about we We spin
you out into your own organization, give you a
generous grant to get started, and you can build this as as a
full time project with, you know, with funding.
So it basically it went from there.
Cool. Yeah.
So I mean one of the things that I think is is interesting about
the the decentralized namespace or the the, the use case of
decentralized names in in crypto is that because it's so easy to
build, it's so easy to build applications on on on
blockchains whether that's Ethereum or Cosmos or Solana or
whatever L1 right or L2. There's been a multitude of
decentralized namespaces that have emerged that have popped up
over the years. Of course like ENSI think was
one of the first ones. We also have protocols like
unstoppable domains we have a handshake also and and then you
know Cosmos has their own and like each blockchain on Cosmos
pretty much has their own. Solana has one I think and you
know Polygon, it's very dear you mentioned this like early days
of the Internet and how we solve this problem.
But the the the thing about how the Internet solves this problem
is because it's because all the infrastructure wasn't there.
It was you know they I can and so the domain name Service was
able to generate like tremendous network effect around like a
single naming system and that's the Domain Name System and
that's it's very different in crypto, right, because it's so
easy to to to sort of like bring these up.
How do you think about the future of name services and you
know how we will reason about these different name spaces in
the future? Will everything sort of coalesce
to ENS or sort of resolve back to ENS and and and have this one
main naming service or? Or do you think there can be,
you know, many different name services that sort of compete
with each other or that are complementary and how?
How do you see that playing out? I mean, you know, naturally I'm
biased here, but I would like to see ENSN and more generally the
global namespace wins. So you know, when I say the
global namespace ENS has dot EFF.
But we also integrate with DNS transparently, so any DNS name
is an ENS name as well. And I think that sort of
approach is a better one than than 10,000 computing name
services. There's, you know, there's a few
problems with that, but the biggest of them is collisions
and, you know, inevitably. More than one naming service
springs up that that issues names that collide with each
other, in which case you have situations where different
people might get different resolutions for the same name.
That's a recipe for disaster, both in terms of, you know,
accidental losses of funds and so forth.
And also it's just it's a dream for phishing and scamming and
and so forth and so. What what I would love to see
is, you know, it doesn't have to be ENS and DNS and that's it.
But I would love to see more naming services and more chains
integrate with ENS via the mechanisms we've exposed that
make it possible to have a single unified namespace.
Even if parts of it are administered differently or
specifically to a given chain, they can all be in a single
namespace and resolvable by a single client.
I think it's also, you know, worth pointing out.
Just the huge. Overhead this imposes on wallets
and apps and so on to implement all of these and to
independently decide how they're going to handle, you know, each
of the services and their potential collisions and so
forth that it can create a a mess.
And so, yeah, what I'd love to see is, is ENS dominant
naturally, but in a collaborative way.
Yeah. I mean of course I think that
makes sense it it makes sense for for everybody to be using
the same namespace, right. I mean at least from a practical
perspective and from the perspective of avoiding
collisions. Yeah I I I see you're you're
very hopeful but I I I don't I don't know how I like if we have
you know if we continue to have like L ones with their own
communities and sort of their own application space and I
think it will be difficult to for everyone to align on on one
namespace although we can we can arrange a hopeful I guess.
I guess, yeah. What is some of the, what are
some of the coolest use cases that you you've seen people
implement using ENS? You know, beyond just having a a
a name attached to the theorem address?
Like, what are some unique things that people are doing
with the ENS these days? I think some of the the sort of
programmatic integrations like there are various if it's where
you can. You know you send some ETH to,
you know, die, dot, swap, dot, ETH or what not.
Don't. Please don't use that.
I don't know if it actually works, but you know, along those
lines and it swaps it for die just transparently.
So you can remove the need for AUI entirely and just automate
this sort of thing. And that sort of thing's
possible as well for, you know, automatically naming contract
accounts, for automatically naming, you know, accounts on
exchanges, deposit addresses, and so on so forth.
I've, you know I've seen some cool efforts around
automatically issuing people or sorry easily issuing people sub
domains and so on for themselves.
You know associated with some affiliation of the years, you
know. So we've seen like the central
and use it quite heavily and I guess you know some of the DNS
integrations that we're seeing showing up now like dot art and
dot box and so on, you know dot box through through their
registrar. Are now making it possible to
register dot box names natively on chain.
So you can do it entirely through your Etherium client and
then have the name owned as an NFT.
So if you want to transfer the dot box to main, you transfer
the NFT, and that's the authority of record of
ownership. How does that work exactly?
Effectively what happens is that dot box has like a holding
company that holds all the rats names.
And they have a contract that basically says, you know if you
can prove you own the NFT then we'll follow your instructions
on on what to do with it. And so you know that way it it's
adherent to all the the Ican regulations around who is data
and so on so forth. But you still have direct
control over the name, and if you want to transfer it out, you
can they simply transfer ownership to you at some other
registrar, OK. And so then when you want to
sort of manage your DNS, the DNS for the domain, you'll do that
using sort of like a Web 3 authentication, is that?
Yes. Where you sign in with Ethereum
to sign into their interface and and manage it just like any M&A.
Oh, that's super cool. I really like that.
All right, I'm gonna get a box domain.
Neat is this? Is this an integration that you
guys helped put together? Because I mean I didn't even
know about this doc box domain extension.
Yeah, it's that. It's it was one of the 2012, you
know, extensions that were there were the extensions that were
optioned in 2012, but some of the needs have launched earlier
than others and Doc Box is one of the later ones.
But that's allowed them to take advantage of this when it might
have been difficult to do so if they'd already launched and hit
a lot of, you know, unwrapped registrations.
Yeah. No, we we were quite closely
with them on on setting this up and so forth and I've been
really pleased to see them embracing E and ES for it.
That's cool. And are you guys, you know, do
you guys interact with or have you interacted with, you know, I
can or any of the folks, you know, working in the in the more
traditional domain name registration space and what's
been your experience there and how like have them been
receptive to to the idea of ENS? Yeah.
Yep, so, so we've we've attended and presented at DNS O AC which
is a an industry organization for DNS.
We're active members of that. In addition, you know we've
we've attended ICAN meetings and so forth we've found.
A lot of people in the DNS world are quite receptive once you
make it clear that this isn't a cash grab basically you know
that we're actually seriously trying to build real useful
infrastructure not just a platform for speculation which
you know given crypto sometimes reputation in in the wider
world, you know is is people's initial assumption.
ICANN itself tends to be very conservative and you know
understandably they're they're protecting a a core piece of
them into these infrastructure. We're still working on
convincing them that you know working with us is is better
than trying to pretend we don't exist and I'm confident we'll
we'll get there. But they're they're
understandably cautious and the the competitors we've we've
talked about previously, you know some of them issue hundreds
or thousands of top level domains that inevitably collide
with the DNS route and that causes a lot of.
Of discord there. And so when we approach I can
and other with two organizations where we're sort of careful to
emphasize that our goal is to build with these pieces of
infrastructure and not you know override them basically.
Yeah I I remember speaking with the handshake folks like a
couple years ago on the podcast and their their view was that
you know they they did have overlapping extensions but that
they wanted to they wanted them to be compatible with I can in a
way that wouldn't create collisions.
And you know from from the perspective of of of ENS, it's
like ENS works nicely with I Can domains from the perspective
that you can you can connect in a way your your your ENS name to
an I can domain. Can you just like remind us how
that works and what's the technical, sort of the the, the
technical best that allowed this to to to be possible?
Yeah so so all of that works through DNS SIC which is a
security layer on top of the the base DNS layer.
The way DNS SIC works is you sign your zone, so your your DNS
records with a key you own and in the parent zone.
So say you've got your ETH dot link, then the dot link zone
signs your keys. And then the root zone signs the
dot link keys, and then there's a root key that everybody knows.
And so you have this chain of trust that establishes that you
know this name was authorized by all the relevant authorities
along the way down to your domain.
And so the way we do DNS integration is you enable DNS
set for your zone for your name. You sign it and then you set a
text record saying, you know, I want the owner of this name on
ENS to be 0X whatever address. And we're able to prove all of
that on chain because it's all cryptographically signed.
It uses, you know, either RSA or ECDSA, and we can verify the
signatures on chain to then transfer ownership to you of the
the record. The the one wrinkle here is an
increasing number of DNS SEC implementations use ECDSA.
And they use a curve that isn't the one Etherium uses, and so
verifying it can be quite costly, you know, up to
1,000,000 guests per per link. Basically there's a few
approaches we're taking to to reduce that.
One is there are now more efficient libraries that cost
less gas. Another is there's an EIP out
moment to add the SIP P256R1 curve to Etherium.
Which was enabled not just efficient DNS SIC but a whole
lot of other crypto primitives from sort of the real world
because it's a very commonly used curve.
And the final one is our effort on what we call guess list DNS
SIC. Which is basically instead of
verifying on chain and the transaction that you own the
name at the time you update it, we move that to.
When you try and resolve the name, you go and verify the DNS
proofs at time. And we do that transparently to
the client using our what's actually our L2 strategy equals
CCIP read, which makes it possible for a client like
Ethers to resolve the name and behind the scenes do the DNS
verification without actually the client having to know
anything about that. So yeah, that's a good
transition I guess into the L2 strategy.
So for now if I'm not mistaken I mean or or up until recently
because I think ENS works now with with L twos but ENS was
only compatible with layer one Etherium natively.
Now there's there's a, there's a push to have ENS be compatible
on Etherium L twos like optimism, arbitrary etcetera.
Can you talk about what are the technical challenges there?
Why has been, why has that been difficult and you know what's
the technical implementation to to enable this?
I think the the ultimate challenge is that E and ES is
quite unlike a lot of other projects like if you have a
token or you know you want to to bridge it to multiple networks,
that's fine. You have a few here, a few
there. If you have, you know, an
exchange or some sort of D5 primitive, you can deploy it
independently on each chain, and that's not a problem you you
sort of have liquidity fragmentation, but you know
that's tolerable. ENS is a little different
because we have this global namespace, and so any deployment
on other chains needs to have some sort of connection so that
we know we won't issue the same name to different people in
different places and so forth. And So what that ultimately
means is that ENS will always be rooted on a theory ML one, but
that doesn't preclude moving arbitrarily large parts of the
tree off into. Different L twos and so forth.
And that's the approach we've taken with our our solution
which is called CCIP read and basically allows you to delegate
entire parts of the ENS hierarchy to an L2 or even to a
private database or you know anything you can verify on chain
basically. And so if you for example own
you know Wallet dot ETH and you want to issue sub domains to
people, you can delegate Wallet dot ETH to the L2 of your
choice, issue them on the L2. And people can resolve them
transparently, without having to know which L2 it's on, and
without any additional trust assumptions.
Which seems outrageous, but it is possible.
So could you describe this the CCIP read functionality?
I've. I've heard about it, but I'm
like not super in tune with how that works.
And yeah. So the basic process of
resolving an ENS name is that you call a smart contract.
You know, grossly simplified, you call a smart contract you
say what does NIT dot ETH resolve to and it returns
resolve and that's all. 1L1 the extension with CCIP read is.
You call the contract, you ask what it resolves to and it
returns a revert error, basically saying I need more
information to complete this request.
And then more information is please go make an actually BE
request to this endpoint with this data and then return it to
me. And the client then goes off and
transparently does that, you know as part of the contract
call returns the data to the contract which then has an
opportunity to verify that the data is actually correct.
So how that works in practice is say your your data is stored on
optimism. You try and resolve NEC dot ETH
it goes, please consult the optimism gateway and give me
back what it what it returns. The optimism gateway gives you
then the resolution and NEC dot ETH along with all the Merkel
proofs required to prove that that's part of the optimism
state route. And then when you pass it back
to the contract it verifies that the the proofs are correct and
therefore that the the result is correct and returns it to you.
And So what it looks like from a point of view of the clients,
you know the the app using ethers.
Is you just did a regular contract call and you got the
data back and then we're building generic gateways and
we're building libraries and so on.
That mean when you're writing the L1 contract, it can be quite
straightforward as well. It just says, you know, I depend
on the storage slot from this chain and and then all the
verification happens in libraries and so forth.
So, so essentially the the contract is able to revert, say
if it doesn't have the data it it tells the client I don't have
the data. But here's an HTTP request that
the client can independently make in order to to get the data
essentially from a a centralized or like an an off chain source.
That source returns the data with proofs that the data is in
fact correct and then sends it back to the sends it back to the
client. So.
So there's a there's a liveness risk here, but there isn't
necessarily like a there's no trust risk, right?
OK. Yeah, exactly.
And that's that's the thing because ultimately every roll up
in order to be a roll up has to be able to prove things on L1.
It means that the strategy works for any roll up.
So you know, it's easiest for us with EVM based roll ups because
we can just deploy the existing contracts we have.
You know, with very few changes we need a bit of library code to
deal with how that particular roll ups proves its state on the
L1. But it could in principle.
It can be used with any sort of L2, you know ZK proof ones as
well as long as you just have some way to prove that a
response from the roll up is is correct This particular like
ENEIP, would it also allow reading from like IPFS or some
decentralized storage source or would it only be off chain
resources? It it absolutely does.
And of course the trust model depends on the trust model of
the thing you're reading from. So for instance, you could you
could store a Merkel route in your, you know your contract on
L1, and then your gateway could read data out of IPFS and return
it. And the trust model there would
be that you have to trust the route that was committed on L1.
Equally it could return things from just a centralized database
where all the records are signed.
And the contract verifies the signature and then your trust
model is of course the signer is is honest, OK, got it.
And so with with regards to how L twos are using this, now
practically speaking if you're if you've registered an ENS name
on on Ethereum on on main net Ethereum, I mean typically with
I mean I think there are some exceptions but the the, your,
your address is the same on Ethereum as it is on L twos.
Why, why does that correspondence simply not work?
Why do you need like an extra layer in order to?
I mean, couldn't you just like check with the theory and what
the address is like with some kind of message passing rather
than having the L2 needing to have its own namespace?
So, yeah, so I guess there's a, there's a few issues here.
One is of course that although EO as tend to share the same
address across all chains, contract accounts don't and so
we need to be able to handle that separately.
But the the broader thing is that the the emphasis here is on
providing the same level of security as L1 while reducing
the transaction fees. So the reason the L TS are
valuable here is it enables you to to not just update your own
ENS name, but also potentially to issue sub domains and to do
that trustlessly to third parties and so forth without
having to engage in any transactions on our web.
Which you know if your if your user is signing up to a wallet
for the first time and it's it's 5 to $50 depending on guest fees
to set up their name, they're going to be quite discouraged.
Yeah, OK. Now that makes sense.
And so then so then L twos, I mean practically speaking L twos
have would have sort of a a like a an equivalent sub domain or
are we talking about like a like if I'm if I'm set 3 point O dot
ETH on Ethereum, would I also be set 3 point O dot ETH on
optimism or whichever L2 I'm using?
It's it's It's really up to you. We've got a sort of two
orthogonal things here. One is.
How your name resolves. And so you can have your name
resolved to the same address for every chain ID, or it can
resolve to a different address for each chain ID.
And then there's where the records are actually stored.
So you could store all your records on L1, but still in
code, you know addresses for half a dozen different chains.
Or you could store your records all on arbitrim, but you know
all you ever return is an Ethereum L1 address.
You know there's we've sort of separated the two so you can you
can choose how that's divided up.
OK. And what what are the
complexities in terms of your wallets integrating this and
having to resolve across like multiple L twos in order to
avoid collisions? Yeah, this is one of the nice
things about CCIP read approach is the wallets and the X and so
forth. They don't have to be aware of
all these different L twos. We don't have to update the
resolution processes, you know, for each L2 we support.
Because the CCIP read gateways as you observe, they they pose
an availability risk, but there's no trust there and they
take the job of translating the contracts requests into, you
know, actual you know, if get proof calls or whatnot on the L2
in question. And so clients and wallets
simply need to implement a single unified DNS resolution
process, and anyone can then permission lessly add new data
storage mechanisms for ENS. OK, now I was reading about the
ENS wrapper which is like a fairly new implementation that
also is involved in the process of.
Well from what I understand it that you know what the challenge
was that ENS names were themselves NFTS but the
subdomains were not right. The ENS wrapper now enables
subdomains to also be NFTS and inherit properties from the, say
not the top level but the the the main domain, right?
How? How does that work and what is
the role of the ENS wrapper with regards to L twos?
Yeah, so so as you observed, like subdomains aren't ERC 741
or 1155 NFTS because ENS actually launched before either
of those standards existed. So while you can transfer around
subdomains just like any other NFT, they they use their own
interface for that. One of the things the name
wrapper was was created to do was to, you know, improve that
and and give a single unified interface to all names.
But the essential thing that it's the F4 is that it makes it
much easier to trustlessly issue subdomains.
So it's always been possible to trustlessly issue subdomains,
but it's required a bit of sort of smart contract engineering on
the part of the owner of the name because.
Ultimately, any any every name has control over all its
subdomains. So if I own wallet dot ETH, I
could I could issue you, you know, your name dot wallet dot
ETH. But then I could take it back as
any time. And if you want subdomains to
actually be useful to people, then you need to have some way
to credibly say I've revoked my permission to do that.
And once I give you the name, you can feel assured that it
will continue to be your name. And so that's what the wrapper
provides. You can wrap a name.
And then we have what we call fuses, which are a way of
revoking your own permissions over a name so you can wrap it.
And then you can burn the fuses to say you can't unwrap it.
And to say that when you issue a sub domain you can't control it
any further, only the sub domain or owner can.
And so those permissions make it possible to to issue trustless
sub domains and also to do that in a way that allows.
That allows you to change how subdomains are issued and move
to newer technology and so forth and upgrade your contracts
without imposing any risk on the user that you'll use that
opportunity to to reissue names and so forth.
The way this combines with L2 is a bit further down the road map,
but basically would would allow you to say well if you migrate a
name to L1 then it gets all these same guarantees as a name
wrapper. And while on L2 you can, there
are other permissions you can burn to say you know I the the
sub domains will always resolve using this CCIP read gateway or
using this verifier for the gateway.
So I can update the URL, but I can't change how it verifies and
therefore it will always use optimism or whatnot.
OK, what? What are some other applications
of this CCIP read gateway other than the ENS?
I mean you know there are broader implications in in E&E
itself like the guest list DNS 6 stuff I implemented.
You know we're effectively treating DNS like the L2.
There are differently users outside that one of the the
neater ones I've seen is around tokens.
So for instance, your data Uri, could you know your data
function to get metadata for a token could use CCIP read and
therefore return sort of on chain data that's verified by
the smart contract. But is actually hosted
externally to save on guest fees for instance.
Or in fact the very existence of the token could be sort of
virtual and realized via these callbacks until such point as
you claim it. So you could eardrop a bunch of
entities to people with 0 on chain gas cost because they're
only they only exist in the database until the person claims
them right? Right.
And then I guess the limitation is like, how long do you want to
keep the database up for people to be able to claim them, right?
I mean it just thinking about this, I mean are there could
these off chain reads be used in lieu of of leveraging an on
chain Oracle in some cases where the trust model allows it and
are are some contracts using it? And and CCIP read calls can
actually be used in transaction contexts as well.
So you can use that data you get back from a call back to
actually make a transaction, which effectively makes into a
sort of a push Oracle rather than a a pull Oracle.
Or perhaps I'm getting the two terms wrong way around.
But in any case, you can fetch the data from the Oracle or from
the external system and submit it at the time it's actually
needed, rather than needing to, you know, have some system that
regularly updates the theory in state, right?
And would this also extend, I mean yeah, could you also use
this with in complement with verifiable off chain
computations where like a server is is performing a a computation
right, maybe like with a AZKVM or like a wasm ZKVM or something
like that right. And it's returning back.
It's returning back of some some data with a proof.
Is that? Is that also possible?
Absolutely. As long as the proof can be
verified inside the UVM, you can use it for it so.
You know, we we talk about it as an L2 solution, but really it is
a generic, you know, verifiable sort of potentially trustless
off chain data fetching system. OK, well that's really
interesting. This brings up like so many
questions like what's the implication here, what's the
broader implication of this of this, the CCIP read on just the
necessity for yeah, on chain Oracle's off chain computation
services And so this whole part of the stack that has built this
business model on the ability to provide verifiable data to to
chains. I think it's it's more a new
technology and a new interface for doing that rather than it is
removing the need for that. You know, we ultimately we still
need that data from off chain. We still have the questions of
like what degree of verifiability you can provide.
And what this does is it provides an API where it's much
more transparent and easier to integrate for apps.
And it you know, it provides a situation where you can write
apps that are actually using the soft chain data on demand
without your app even having to know or care about that.
So you know your, you know, claim of the AirDrop tokens
could just look like a simple ERC 20 transfer function to the
app. You know, you could claim your
AirDrop just by transferring it, you know, into an account, but
behind the scenes it's all using all of this, all of this
infrastructure. So what it really does is just
improve the developer experience and improve the ease of use of
all of this. Very cool.
Yeah. I'll have to spend a little bit
more time researching this. Yeah, we're coming back to the L
twos. You know of course I think you
know when thinking about integrating ENS with Ethereum L
twos, we're thinking about EVM L twos.
But I think in the future we do expect to have non EVM L twos.
I think with the growth of Eigen layer also we can expect a
theorem security to be rented by non EVM platforms.
What's the what are the implications here for ENS and
making ENS compatible? And it sort of comes back to the
first topic we were talking about earlier with you know this
collision, so the multiple namespaces, what are some of the
plans to make that possible? Let's say like someone wants to
build a cosm wasm VM secured by a theory of security and bring
ENS to to the to that to that, to that app.
How would that be possible? You know, so in terms of the
namespace, of course, all of this, you know, all of our
efforts around CCIP Reader are pretty much they exist in order
to ensure we have that one unified namespace.
And so I've talked before about the importance of avoiding
collisions or multiple registrations.
But it's also equally about making sure that you can resolve
names anywhere you know we shouldn't have a system where.
You know an optimism where it can only resolve optimism based
names and an Etherium or it can only resolve Etherium based
names. And so you know with CCRP read
we're able to provide that bridge and that bridge can be to
to non EVML twos you know. Again, as long as you can verify
the responses you can do it. What that looks like is a little
more varied because of course non EVML twos have a much larger
design space, so it's a matter of finding a way to.
To build that out and and that will likely require you know L2
specific engineering to build appropriate registries on the
L2's and so forth. When it comes to resolution,
ultimately it's still it starts at Etherium you know.
So even if you're resolving a, you know ZK sync based name or a
name that resolves to AZK sync identifier, you still start by
the the look up process by by querying Etherium.
OK. Yeah, it makes sense.
And and are you know what's been the adoption of ENS, you know on
on L twos, like which L twos are currently using it or do you
expect we'll start start using ENS?
So you know that because it's open and permission less, it's
been a little bit, you know, we don't have a central database in
that sense. So for instance, Coinbase
started off on their own internal private database when
they issued dot CB, dot ID names which all use CCIP read and they
have since moved on to base. We've got a generic gateway that
we've we've been building very recently which allows for very
trivially building gateways to just about any L2 and we have
stood up official gateways for optimism for that so far.
But we're planning to expand that to Arbitron and to any
other, you know, OP and R based L twos that pop up and you know
from there to others because it's quite easy to add new
verification mechanisms for them.
Thus far, adoption outside like large integrations like Coinbase
has been a little slow because most people don't have the
resource to resources to build their own, you know, link.
Your own gateway and so that's what our generic gateways are
intended for this to make it much easier.
So give us, you know, a quarter or so and you'll see people
moving their names and their hosting to to L twos, you know
easily through AUI 0 code, which is what we've been working on
unlocking at the moment. Cool.
Yeah. Well, let's, let's talk about
about Coinbase a little bit. So I mean they recently
announced the CB dot IDENS name that works across the Coinbase
platform. Yeah.
What what's the, how does that work and how how many new users
have has ENS received from from that integration?
It's it's hard to say because it's all off chain, but we know
it's in the millions, you know, simply because they're
onboarding their entire user base.
CB dot ID is a great example of of both our DNS integration and
our our off chain integration working together.
You know CB dot ID is an ENS name even though it's also a DNS
name and Coinbase simply imported at one time into ENS
and then can treat it just the same as a dot ETH name.
And the way they've they've used it then is to actually set it
up. CCIP read initially.
As I said, it sort of. You consulted their internal
database for resolution. But they've they've since moved
it to using data stored on base, understandably.
Which means that they can provide.
They can prove to you that you know you're the one in ultimate
control of how your name results.
Yeah, I haven't tried it yet, but I'll have to, I'll have to
create my CB dot ID name. Yeah one of the one of the ways
that I've been using ENS that I mean so you know I've got a
couple of like ENS domains sort of for like my own my own
personal use. But one of the ways that I've
been using it that's been really really helpful and it's I mean
it's very basic use case I guess but it's just naming all of all
of the wallets that I use with like you know I've got this I've
got this kind of like namespace like my own namespace that I've
created and and you know the same way I guess that you would
like name servers in your in your land or in you know your
your your gateway. And so you know as a fund
manager like we have several we have several noses safes and and
and different addresses that we use and we've just like named
every one of them and we know that like this is the address
that we use for this and this is the address that we use for
that. And that's made it very easy for
for us to do capital calls with our LP's for example.
We just like give them an ENS name and just verify that ENS
name with them and stuff like in a an address and just you know
when you're looking at your wallet, you just know, OK, like
these are the names that I use and they're sort of like unique
to me and I know what they are but but that's that's been a
really cool use case. And you know couple that with
the ability to like really easily buy ETH, ETH with a
credit card on like any of these sort of like credit card, the
service where you can buy ETH and you can basically like set
up brand new addresses. That have never sort of touched
the outside that have never been touched by your own personal
addresses or sort of like quarantined right and and and to
some extent shielded from your from your other identities
because you can sort of put gas fees there.
So we've we've been using that quite extensively to like set up
you know an array of addresses that we that we use that we
don't want to like be connected with our own personal identity.
So I found that really like a great, great use case and
something that we've been implementing at the fund.
Yeah, I think that's that's absolutely the right way to
handle it. And to treat on chain privacy
like the connection between on chain privacy and naming comes
up a lot. And the thing I always emphasize
is that, you know, not naming your accounts is security sort
of security. It seems harder to track, but in
reality a determined person can certainly, you know, figure out
which accounts are yours and so forth.
The EE NES doesn't solve the problem that nor does it 'cause
it, you know, the IT sort of makes it more obvious both to
you and to others. You know what the account is
for, and nine times out of 10 that's a benefit.
And when it's not, you need to follow processes like you
describe and make sure that the accounts you want to be separate
are actually, you know, held separately and and set up
separately. Yeah, yeah.
It was a bit of a like we had to implement sort of a process to
do it because like I messed up a few right, where it's like OK,
I'm going to send some ETH over here.
No, like I wasn't supposed to do that.
So it is also about having like having good offset processes
internally to make sure that like those things don't don't
touch. But yeah, I was, I was chatting
with a guy in in in Istanbul a couple of weeks ago.
We were there for Cosmo virus and he was building this, this
this site called 0X PPL, right, 0X people.
I don't know if you've heard of it and it's sort of one of these
like D bank type services but with really in depth sort of
data on interactions between between addresses.
So you you sort of like go to 1 address and then you you have
this this hub and spoke thing that shows you all the other
addresses that it's interacted with.
And you know, I I think I'm fairly good with my security and
my off SEC. But then you know in in in a
couple of clicks he showed me that I had not, you know,
properly implemented this process and like these two
addresses that I thought were not linked together had been
linked together somehow including like payments to to
other folks. And so you know talking about
privacy like you know one of the other things about this, this
service is that now you know they're integrating and I'm sure
all of the big sort of like chain analysis and sort of
competitors to chain analysis are doing the same thing as
implementing large language models to decipher connections
between addresses. And and this is what they were
doing right, where you can just say OK, what are the addresses
that this particular address has been have been have interacted
with or you know which address which Ethereum addresses were
participate participated in the in the cosmos token sale for
instance. You know, like you could sort of
push it to that extent. Like have you thought about
large language models and how they conflict with the idea for
on chain privacy? And what are some of the best
practices that we can employ now as users of Ethereum where
Ethereum doesn't have effective privacy on chain and what what
is your hope that will you know at some point get to full on
chain privacy? Yeah, I think, you know large
language models much like E&E sort of expose the assumptions
that we make. You know, they're, they
democratize access to the sort of functionality, but ultimately
aren't providing you anything that wasn't already.
You know they're on chain. The solution I think is better
base layer privacy primitives. The unfortunate thing is that,
you know, politically these things are contentious at the
moment. I don't think it's an
unreasonable ask that not everybody can read my entire
transaction history and see, you know everything I do.
And I think if you went to most people in the real world and
said, hey, can I see your bank statement, they would react with
alarm. But somehow when it happens on
chain, that's seen as as illegitimate.
And so I think a lot of it is we have to sort of fight that
perception that a desire for financial privacy is somehow,
you know, scurrilous before we can we can see widespread
deployment of some of these these primitives.
It's a. It's a good connection though to
like a history of like using encryption.
In that when it becomes the norm, it also becomes less of a
target. So you know, nobody blinks that
you use SSL for every single website now, but if you only use
them to watch porn or or load the money then it would be a a
sign of suspicion. Likewise, you know, chains like
Z Cash, you know, seem to be treated with less intrinsic
suspicion than mixes like Tornado cash, simply because
privacy is the default. So I think we, we need better
premises and we also need to sort of enshrine them and make
them the thing that's used to it as much of the time as is
practical rather than just an exceptional circumstances.
Yeah, I mean I agree with you that like politically this this
is very contentious. But I mean, ultimately my, my
view on privacy is that it is an essential component of just the
idea of, you know, just the idea of capitalism, right?
Like capitalism is able to, I can't remember who said this,
but like capitalism exists or is able to function because we had
asymmetry of information, right? And so there's this like
information arbitrage between between market players and
having like full transparency over everyone's everyone's
transaction history everyone's business dealings etcetera with
with whom everybody interacts economically.
If actually sort of like breaks down that a that information
asymmetry and we end up in something closer to what I guess
like communism right. What's the what's the hope do
you think that that you know within the next 10 years we have
you know better on chain privacy or like absolute on chain
privacy would be I guess like the you know the the desirable
outcome or or you you think that this is a pipe dream that will
will never happen. I think it's it's difficult and
it's particularly difficult inside like an EVM based L2 or
an EVM based network because the system simply isn't built with
it in mind. So I think if we see it, it will
be through L twos that use you know, systems similar to ZK.
Sure ZK sync you know, becoming widespread and becoming the
default transaction thing. And I don't think that's
necessarily a bad thing. You know, as Etherium becomes a
sort of a clearing network and I don't think it's a problem that,
you know, clearing network transactions are public.
You know, in the same way that I would love to see more more
transparency into the operation of like, you know, central banks
and so forth, there's financial privacy.
Most benefits individuals and companies not, you know, banks
and and governments. I don't know how practical this
is. It's.
You know, aside from the political thing, it's a large
technical challenge and having both financial privacy, you
know, and and shielded transactions and also being able
to engage in like arbitrary, you know, smart contracts is a
really tough problem to solve. So I guess I would say I don't
think we'll have it 10 years from now, but I think we might
have moved the needle more of the direction of making privacy
in the north and making it easier to to shield your.
You know your assets and your transactions, Yeah, yeah.
I mean, in the context of, you know, if we think about account
abstraction and you're thinking more broadly about like
decentralized identities and how identities are formed through
these, you know, links to other forms of identity, right?
So like you know currently if you want to add some weight to
your ENS identity, you can you can attach your Twitter identity
to to your ENS or you know key base has this model also where
you'll attest to your ownership of other pieces of identity in
order to bring more weight to you know your key base identity.
It's a shame that key base is no longer really a viable product
to use. But you know, how do you think
about the role of account abstraction in in forming like a
real decentralized identity in the form of ENS and perhaps also
adding some layers of privacy there, since we can rotate keys
and and and that can be used in the word in a way to to abstract
away the ultimate beneficiary of an of an identity.
I think account abstraction in some form is going to be fairly
essential to to more widespread adoption as as a theory and end
of. You know crypto in general
because of the usability benefits it brings and and one
of the pleasant side effects of that is that it's easier to then
implement things like bit of financial privacy and so forth.
Yeah, maybe maybe give an overview of you know what are
the what are the advancements in account abstraction and and the
use of account abstraction with DNS on Etherium.
I think. I mean you know I I don't follow
the area of research in as much detail as I I maybe should.
But you know to my awareness there's sort of two general
approaches. One is that we can enshrine and
account abstraction in the the base layer in the EVM with
things like off call and so on, which basically allow you to
treat a a special contract account like an EOA and transact
from it. And that provides, you know sort
of a more direct way to do things and it also sidesteps,
you know, a bunch of difficulties around, you know,
gas and transaction fees and so forth.
Things like that are promising, but large changes to the EVM
tend to take a while and it's all too easy to have unintended
side effects. You know and hence the the
understandable caution and implementing them you know the
2nd way is through. You know, authorizations
through, you know, meta transactions and so forth, where
all of this happens in the abstract, so you know in the in
the user layer. That's much more practical and
it's happening now. But also the user experience
tends to be a bit worse. And it's a bit, there's a lot
more infrastructure to set up, you know, So your user there has
to sign a message and serve a transaction that then has to be
sent to some sort of relayer. The relayer has to handle, you
know, how to pay guest fees and how to be reimbursed.
And then either the user or the platform has to somehow, you
know, translate you know the right amount of funds into to
pay the guest fees. And it all gets very
complicated, but we can implement it, you know, as we
wish without waiting for everyone to be in agreement.
In either case, you know, E&E sort of continues to function
the same way. You know, we we can name
contract accounts just the same as naming externally owned
accounts. You can transact from them just
fine. You know, there's nothing sort
of intrinsically linked to ENS, to to external accounts.
So fortunately we we work with account abstraction really well.
And, you know, being able to name those accounts can also
improve the UX a lot, and you end up with more of them to keep
track of than you might otherwise.
Yeah I saw the the the comest team has a really nice
implementation of of account abstraction in in their in their
game. And yeah it's like it's it's
great how just how well it works.
You just do, you open the app, it creates, it creates a wallet.
You connect that wallet to say like a passkey and and then you
know further on as you sort of add assets to that wallet, it
might ask you to like connected to different forms of identity
or or different signing mechanisms.
And yeah, the onboarding experiences is pretty incredible
and in terms of enshrinement may be an interesting sort of
examples to look towards this is osmosis on on from Cosmos.
So they're they're building a counter abstraction into the
protocol. Now of course for for us most
it's different, right, because they're an app chain, they can
sort of like control the entire stack.
But like a month ago they demoed this this really sort of nice
way to build a counter abstraction where existing
addresses, existing EOA addresses could be turned into
abstracted accounts. And then you can effectively
like connect different pass keys, Twitter accounts or like
any O off in in order to to sign.
And then also have different signing mechanisms based on the
types of transactions that you're participate that you're
that you're issuing, right. So if it's like a a swap
transaction or like a send token transaction, you may need like a
certain amount of keys to do that.
However, if you're just like voting on a government's
proposal or performing some other action that doesn't
involve transferring funds, you might be able to do that with
like you know your your Twitter login or your Google login or
something like that. So like having also permissions
built in, the protocol is really nice and I mean that's one of
the benefits of having an app chain I guess is that you can
sort of you know you can, you can have total control over
that. But I understand it like for
something Ethereum, it's much, it's much more difficult to
enshrine that into the protocol where you know there's so many
applications and sort of L twos depending on that that base
layer. So it's it's it's an interesting
challenge to have to deal with, of course.
It's interesting you bring that up because you just reminded me
that. So a couple of years ago I
proposed in the IP that would implement something very
similar. Never got much traction
unfortunately. But the basic insight is what if
you could? What if an EOA could delegate
call so? You would have a special
transaction type that instead of just calling a train, a contract
delegate calls it and therefore it executes as the EOA.
And in principle, this would require a fairly minimal set of
changes to the EVM because all of that infrastructure, all of
that, that mechanism is already in place.
Unfortunately, you didn't get a lot of traction.
There are a couple of odd each cases around that but I think it
would be tractable and you know potentially provide a much
simpler mechanism than some of the other ones that have been
proposed. Yeah yeah I'm I'm I'm really
looking forward to seeing like a counter attraction come come to
Ethereum in in more tangible ways and yeah I think we'll get
there eventually right. There's already some some some
implementations of it. So yeah maybe looking to looking
to the future of ENS and reflecting in the last six
years. So I think it's, I think it's
safe to say that ENS is one of the like largest or if not the
largest Dow in Etherium also generating revenue, right.
There was this one day earlier this year where ENS generated
like upwards of $235,000 in in domain fees in a day, you know
millions. I think it's two 2.4 million
addresses active ENS names. Yeah.
What do you, what do you think of all this?
And, you know, how do you reflect on like the last six
years to today? It's certainly been a journey.
We always intended to to decentralize ENS over time.
When we launched was we launched not long after the the Dow And
so we weren't exactly keen to be like, hey, let's launch and
straight away launch a Dow and it'll be fine.
You know, we wanted to actually see governance permissions
mature and demonstrate their effectiveness first.
But that absolutely happened and you know two years ago we
launched the Dow and the E&S Dow and you're right, it's it's
been, it's one of the largest you know by participation that's
got ongoing revenue, it's you know ongoing participation as
well. And I think it's been very
effective as administering the protocol.
I think the the revenue is an essential part of us the, you
know the fees were for E&S names are set.
To regulate the system rather than directly to bring in
income. You know, the idea is if names
are free to register, then they'd all be registered and the
only way to get them would be to try and, you know, pay enough to
the person who jumped on it first.
And so we want to see that balance where it's possible to
find a name that you know, represents what we want it to,
you know, directly and easily and in a sort of a liquid
fashion, rather than having the entire system squatted on
immediately. You know, I've seen.
That sort of behavior left uncontrolled has, you know,
strangled ecosystems like main coin and other early attempts.
But a very pleasant side effect of that is of course it
generates funding which can help, you know, continue to pay
for E&S development and so forth.
And I think the fact that E&S has revenue that it can actually
use to continue to pay for development.
It's meant that we haven't had to you know look for venture
capital funding which has now allowed us to stay truer to our
our open source and public good roots.
It's enabled us to help fund other projects in the ecosystem
and you know and relating to EMS as well and it's it really
provides us with like a stable future.
So you know we've put a 50 million odd of the.
The amount that's been raised into an endowment and its sole
goal is to to grow stably and and safely over time so that E&S
will remain a stable operating system for the next 100 years or
more, You know, independent of what happens to revenue.
Because we also don't want to have to make decisions of, well,
it would be better for the ecosystem if this fee went away
because it no longer serves its purpose.
But we need it in order to fund operations.
So it has to stay, you know. So our ultimate goal was to be
able to make those decisions independently of each other.
And things like the endowment, you know, work to make that
possible. So I guess the thing I I like
the most about it is, is it's enabled us to to maintain that
independence and that attitude that what we're building is
infrastructure, not, you know, a money spinner, not an investment
opportunity. Yeah.
How much is in the endowment? Well varies day-to-day.
It is a little under 50 million at the moment.
I think we it's divided up between ETH exposure and USDC
exposure. The basic in intuition is that
if somebody pays for 10 years of registration, we after a year
one team for that is effectively being used up.
You know, they've had their year of registration.
And so that's money that the Dow can spend or invest as it sees
fit and that's held as USDC for stability.
The remaining nine years are still money that was paid for a
service that hasn't been rendered yet.
And because it was paid in ETH, we keep his knee.
So we still have a large ETH exposure.
And the Dow therefore, sorry, the endowment therefore is
divided up into two those two sections.
And because of the ETH exposure, you know, I see some some very
large variation over time. Our endowment manager Carpet.
Key is is very good and publishes weekly reports and
monthly reports that you know provide a lot of detail into the
the goings on. Yeah, I mean.
The one of the interesting things about about ENS is I
think the the the the governance, how active it is.
You know the implementation of the delegate system.
You know, I was, I was sort of surprised, I mean pleasantly
surprised to see that Coinbase is a large delegate and.
Fairly active in in governance you know looking to the future
of of of ENS and particularly the governance you know how do
you think that will scale as ENS grows and you know will will
someone will we someday see like I can sitting on the governance
board of of of ENS you know and and and other large
organizations that that use the protocol.
I would yeah I would love to see participation from you know from
other large organizations and stakeholders.
You know I want and is to be built with those people in mind
and I want them to have a say in governance.
I think ultimately enabling that sort of thing means you know
doing what we can to make it as as easy as possible for people
to shift the delegated votes. You know we've we've done that
using things like free redelegation where we use meta
transactions and we pay the guest fees for re delegating
your tokens. But as with any project with a
token, the keeping people's attention and keeping them, you
know, focused on governance and and active in it can be a
problem. So we see this gradual decline
and delegated token counts over time.
And so combating that and and increasing governance
participation and also making it very easy for delegates to step
up and step down and not, you know, we want someone who comes
along late to have a good opportunity to, to encourage a
lot of people to delegate to them.
Equally, we want someone who is moving on to be able to make
sure that their votes delegated to them don't go to waste, you
know, because they're no longer active.
Solving challenges like that is going to be a big, a big thing
going forward for the UNICEAL to make sure it continues to be
representative in our talents. Yeah, I mean, I think like
governance. Delegation is, you know, it's
it's certainly like a an issue that we see in the Cosmos side
of things as well, right where? You know, I think Cosmos has a
Cosmos chains have a a different model where validators are sort
of the the de facto delegate, right.
If you don't vote, if you don't vote from your own sort of
token, your own tokens that your your validator votes for you.
But you know, that has created I think, a situation where I think
a lot of people are dissatisfied with the way governance is is
conducted, right where it would be better for.
In certain some cases maybe for things like like like spending
like community pool spending and things of that nature treasury
spending, treasury allocations to be governed by like a a group
of folks, right. So for that that responsibility
to be delegated to like a group of folks that are voted in by
governance that can be vetoed etcetera.
But we, you know, we found that. But I think the community is
moving more towards this model where governance
responsibilities are delegated to or should be delegated to
like sort of Sub Dow's, right? This is a sub Dow idea, so you
know it's a it's an interesting problem to solve.
Yeah. And and EMS approaches that a
little differently with our working groups.
You know that working the whole Dow relates working group
stewards on a regular basis and they have delegated authorities
to deal with day-to-day decisions.
I think there is a a common misconception in, you know, the
decentralized community that you know everything has to be
decided by everybody. But in reality, that's just not
how any large organization works.
There has to be some delegation of authority and what makes it
decentralized is whether there's transparency and checks and
balances over that. Whether you know somebody who
isn't representing their community can be removed and
replaced. Rather than that, every single
decision you know gets noted on by everybody, which is
exhausting and and requires everybody to be an expert on
everything. Great.
Well, next. Thanks so much for coming back
on and sharing an update on on ENS.
Yeah, really, really excited that we could have this
conversation again and also excited but to see ENS growing
and continue to grow and be a pillar for the way you know we
should conduct governance in the space and and and also an
important. An important component to
bringing in more adoption into Ethereum.
So yeah, number go up in terms of ENS names created, I think is
is a good metric to be looking at.
Absolutely. Thanks, Nick.
Yeah, thank you. It was a pleasure.
Thank you for joining us on this week's episode.
We release new episodes every week.
You can find and subscribe to the show on iTunes, Spotify,
YouTube, SoundCloud, or wherever you listen to podcasts.
And if you have a Google Home or Alexa device, you can tell it to
listen to the latest episode of the Epicenter podcast, go to
epicenter.tv/subscribe for a full list of places where you
can watch and listen. And while you're there, be sure
to sign up for the newsletter so you get new episodes in your
inbox as they're released. If you want to interact with us
guests or other podcast listeners, you can follow us on
Twitter and please leave us a review on iTunes.
It helps people find the show and we're always.
Happy to read them. So thanks so much and we look
forward to being back next week.