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.