Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Nick Johnson: ENS - Multichain ENS Domains and Decentralised Identities

Episode Date: November 4, 2023

The very nature of Ethereum addresses, expressed as random hexadecimal character strings, represents a big hurdle for mass adoption, as they are not human-readable. ENS domains were envisioned to not only solve this and provide a seamless UX, but to also be the cornerstone of on-chain identities. However, in the current multichain landscape, a plethora of decentralised naming services arose, which led to a heterogeneous domain name pool. As a result, ENS aims to expand to L2s and non-EVM chains, attempting to provide consistency, in order to further reduce user friction and limit conflicting domain names.We were joined by Nick Johnson, founder of ENS, to discuss the current state of decentralised naming services from a multichain and L2 perspective, and how these ultimately tie into decentralised identities.Topics covered in this episode:Nick’s background and ENS historyThe plethora of decentralised naming servicesENS use casesInteracting with Web2 DNSL2 compatibility for ENS via CCIP ReadENS wrapper and subdomainsCCIP ReadBridging ENS to non-EVM L2sCoinbase’s cb.idENS and on-chain privacy OPSECAccount abstractionThe future of ENSGovernance Episode links:Nick Johnson on TwitterENS on TwitterThis episode is hosted by Sebastien Couture. Show notes and listening options: epicenter.tv/520

Welcome to Epicenter, the show which talks about the technologies, projects, and people driving decentralization and the blockchain revolution. I'm Sebastank with you. And today, my guest is Nick Johnson. He's the founder of ENS. EnS is the Ethereum name service. It is the most used, most widely used, decentralized naming service, and the biggest Dow on Ethereum. And we had Nick on a year ago. And so we're having him back on today to give us a brief. 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 L2s. We'll also talk about governance. We'll talk about some of the growth that ENS has seen in the last of the while and also looking to the future and where the project is going. Nix, thanks for coming on.

Pleasure to be here again. So for those who missed the last episode who maybe had never heard of you or never heard of you and asked which I'm sure as very few people, Yeah, why did we start with a bit of background and 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 I first heard about Bitcoin way back, I sort of looked into it and I was like, oh, that's kind of interesting. but oh it's 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 got a call from the Ethereum Foundation saying hey would you like to come work with us on on go Ethereum or on Swarm or, you know, something we're working on. It was a bit of a plunge for me because it was going from the comfort of like full employment to a contractor position, you know, big pay cut, you know, unknown future, etc. But I was really quite hooked on, you know, Ethereum and what we could build was it. And so I quit my job. I joined the Ethereum

Foundation and pretty much one of my first jobs was to start working on, well, 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 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, these identifiers. You know, we sold this on the internet in like 1985. So I started working on what eventually became the Ethereum 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, B.E.F. Well, you know, it's clear that this is more than one person's work. You know, what about we spin you out into your own organization, give you a generous grant to get started, and you can build this as a full-time project with, you know, with funding. So it basically went from that. Cool. Yeah. So, I mean, one of the things that I think is interesting about the decentralized namespace or the, you know, the use case of decentralized names in crypto is that because it's so easy to build, it's so easy to build applications on on on on on on on blockchains whether that's Ethereum or cosmos or solonar or whatever

L1 right or L2 there's been a multitude of decentralized name spaces that have emerged that have popped up over the years of course like ENS I think was one of the first ones. We also have protocols like unstoppable domains. We have handshake also. 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, you mentioned this like early days of the internet and how we solve this problem. But the thing about how the internet solved this problem is because all the infrastructure wasn't there, it was, you know, they, I can. 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. Now, it's very different in crypto, right, because it's so easy 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 have this one

main naming service 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 do you see that playing out? I mean, you know, naturally I'm biased here, but I would like to see EMS and more generally the global namespace wins. So, you know, when I say the global namespace, EnS has dot EF, but we also integrate with DNS transparently. So any DNS name is an EMS name as well. And I think that sort of approach is a better one than 10,000 competing name services. There's, you know, there's a few problems of that, but the biggest of them is collisions. And, you know, inevitably more than one naming service springs up 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, So it's just, it's a dream for fishing and scamming and so forth. So 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 the symposes 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. It can create a mess. And so, yeah, what I'd love to see is E&S dominant naturally, but in a collaborative way. Yeah, I mean, of course, I think that makes sense, it makes sense 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 see you're very hopeful, but I don't know how, like, if we have, you know, if we continue to have like L-1s with their own communities and sort of their own application space,

and I think it will be difficult to, for everyone to align on one namespace, although we we can we can we can rein hopeful i guess um 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 name attached to the earth theorem address like what are some unique things that people are doing with the ns these days uh i think some of the the sort of programmatic integrations like there are various efforts where you can uh you know you send some eath to uh you know die dot swap dot-eath or whatnot. Please don't use that or that note 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 a UI 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 and so forth. I've seen some cool efforts around automatically issuing people, or sorry, easily issuing people subdomains and so on for themselves, you know, associated with some affiliation of theirs, you know, so we've seen like Decentraland 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 their registrar are now making it possible to register.

box names natively on chain, so you can do it entirely through your Ethereum client, and then have the name owned as an NFT. So if you want to transfer the dot box domain, you transfer the NFT, and that's the authoritative record of ownership. How does that work exactly? Effectively what happens is that dot box has like a holding company that holds all the rap names, and they have a contract that basically says, you know, if you can prove you only NFT, then we'll follow your instructions on what to do with it. And so, you know, that way it's adherent to all the ICAN regulations around who is data and so on and 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. Okay. 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, exactly. Maybe you sign in with Ethereum to sign into their interface and manage it just like any MNA. Oh, that's super cool.

I really like that. All right, I'm going to get a box domain. Neat. Is this an integration that you guys help put together? because I mean, I didn't even know about this dot box domain extension. Yeah, it was one of the 2012, you know, extensions that were the extensions that were optioned in 2012, but some of these have launched earlier than others and dot 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 had a lot of, you know, unwrapped registrations. Yeah, no, we work quite closely with them on setting this up and so forth, and I've been really pleased to see them embracing YNES for it. That's cool. Are you guys, do you guys interact with or have you interacted with, you know, ICAN or any of the folks, you know, working in the more traditional domain name registration space and what's been your experience there and how, like, have them been receptive to the idea of YNS? Yep.

So, so we've attended and presented at DNSR. which is an industry organization for DNS. We're active members of that. In addition, 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, that we're actually seriously trying to build real useful infrastructure, not just a platform for speculation, which, you know, given crypto's sometimes reputation in the wider world, you know,

is people's initial assumption. ICANN itself tends to be very conservative. And understandably, they're protecting a core piece of internet infrastructure. We're still working on convincing them that, you know, working with us is better than trying to pretend we don't exist. And I'm confident we'll get there, but they're understandably cautious. And the competitors we've talked about previously, you know, some of them is sure. hundreds or thousands of top-level domains that inevitably collide with the DNS route,

and that causes a lot of discord there. And so when we approach ICANN and other Web2 organizations, we're sort of careful to emphasize that our goal is to build with these pieces of infrastructure, not override them, basically. Yeah, I remember speaking with the handshake folks, like a couple years ago on the podcast, and their view was that, you know, they did have overlapping extensions, but that they wanted to, they wanted them to be compatible with ICAN in a way that wouldn't create collisions.

And, you know, from the perspective of, of, of, of ENS, like, ENS works nicely with ICAN domains from the perspective that you can, you can connect in a way your, your, your, your, your, your name to an ICAN domain. Can you just like remind us how that works and what's the technical sort of the technical bits that allow this to be possible? Yeah, so all of that works through DNSSEC, which is a security layer on top of the base DNS layer. The way DNSSEC works is you sign your zone, so your DNS records with a key you own and then the parent zone. So say you've got your ETH.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 could verify the signatures on chain to then transfer ownership to you of the record. The one wrinkle here is an increasing number of DNSSEC implementations use ECDSA, and they use a curve that isn't the one Ethereum uses. and so verifying it can be quite costly,

you know, up to a million gas per link, basically. There's a few approaches we're taking to reduce that. One is there are now more efficient libraries that cost less gas. Another is there's an EIPR at the moment to add the SECP-26R1 curve to Ethereum, which would enable not just efficient DNSSEC, 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 gasless DNSSEC, which is basically instead of verifying on-chain in a 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. called CCIP read, which makes it possible for a client like ethers to resolve the name and behind the scenes do a 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 up until recently, because I think ENS works now with L2s, but ENS was only compatible with L3-1 Ethereum natively.

Now, there's a push to have ENS be compatible on EthereumL2s, like optimism, arbitram, etc. Can you talk about what are the technical challenges there? Why has that been difficult? And, you know, what's the technical implementation to enable this? I think the ultimate challenge is that ENES is quite unlike a lot of other projects. Like if you have a token or, you know, you want to bridge it to multiple networks, that's fine. you have a few here, a few there. If you have an exchange or some sort of defy primitive,

you can deploy it independently on each chain and that sort of problem. You sort of have liquidity fragmentation, but that's tolerable. ENS is a little different because we have this global name space. And so any deployment on other chains needs to have some sort of connections 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 Ethereum L1, but that doesn't preclude moving arbitrarily large parts of the tree off into different L2s and so forth. And that's the approach we've taken with 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 anything you can verify. on chain basically. And so if you, for example, own wallet.eath and you want to issue subdomains to people, you can delegate wallet.eath 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 CCIP read functionality? I've heard about it, but I'm like not super in tune with how that works.

So the basic process of resolving an ENS name is that you call a smart contract, grossly simplified, you call a smart contract, you say, what does Nick.Eath resolve to, and it returns a resolve. And that's a 1L1. The extension of CCIP read is you call the contract, you ask what it resolves to, and it returns a revert, an error, basically saying, I need more information to complete this request. And then more information is,

please go make an HTTP request to this end point with this data and then return it to me. And the client then goes off and transparently does that, 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 data stored on optimism, you try and resolve nip.eath echoes, please consult the optimism gateway and give me back what it returns. The Optimism Gateway gives you then the resolution in Nick.Eath, 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 proofs are correct and therefore that the result is correct and returns it to you. And so what it looks like from the point of view of the clients, you know, 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 then all the verification happens in libraries and so forth. So essentially the contract is able to reverse, say if it doesn't have the data, it tells the client, I don't have the data,

but here is an HTTP request that the client can independently make in order to get the data essentially from a centralized or like 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 client. So there's a liveliness risk here, but there isn't necessarily like a, there's no trust risk, right? Okay, interesting.

Yeah, exactly. And 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-up proves its state on the L-1. But it could, in principle, it can be used with any sort of L2, you know, ZK-proof ones as

as long as you just have some way to prove that a response from the roll-up is correct. This particular, like, EIP, would it also allow reading from, like, IPFS or some decentralized storage source, or would it only be off-chain resources? 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 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, that the signer is honest. Okay, got it. And so with regards to how L2s are using this now, practically speaking, if you're, if you've registered an ENS name on on Ethereum, on Mainnet Ethereum, I mean, typically with, I think there are some exceptions, but the, your address is the same on Ethereum as it is on L2s. 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 Ethereum 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 few issues here. One is, of course, that although EOAs 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 broader thing is that the emphasis here is on providing the same level of security as L1 while reducing the transaction fees. So the reason the L2 is it enables you to not just update your own ENS name, but also potentially to issue subdomains and to do that trustlessly to third parties and so forth without having to engage in any

transactions on L1, which, you know, if your user is signing up to a wallet for the first time and it's it's five to $50 depending on gas fees to set up their name, they're going to be quite discouraged. Yeah, okay, now that makes sense. And so then L2s, I mean, practically speaking, L2s have,

would have sort of a, like an equivalent subdomain or are we talking about like a, like if I'm, if I'm 7.0.org eth on Ethereum, would I also be set 3.0.8 on optimism or whichever L2, using. It's really up to you. We've got 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 our one but still encode addresses for half a dozen different chains or you could store your records all on Arbitram but you know all you ever return is an Ethereum L1 address. You know, we've sort of separated the two, so you can choose how that's divided up. Okay. And what are the complexities in terms of,

you know, wallets integrating this and having to resolve across, like, multiple L2s in order to avoid collisions? Yeah, this is one of the nice things about CCIP read approach is the wallets and the apps and so forth. They don't have to be aware of all these different L2s. 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 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, eith 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 permissionlessly add. new data storage mechanisms for ENEs. Okay. 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, you know, 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 main domain, right? How does that work?

And what is the role of the ENS wrapper with regards to L2s? Yeah, so as you observe, like sub-domains aren't ERC-721 or 1155 NFTs, because ENS actually launched before either of those standards existed. So while you can transfer around sub-domains just like any other NFT, they use their own interface for that. One of the things the name wrapper was created to do was to improve that and give a single unified interface to all names. But the essential thing that it's there for 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 smart contract engineering on the part of the owner of the name. because ultimately in ENS every name has control over all its subdomains. So if I own wallet.eath, I could issue you, you know, your name.wollet.eath, but then I could take a bagg 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. 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 that you can't unwrap it and to say that when you issue a subdomain, you can't control it any further, only the subdomain or odocab. And so those permissions make it possible to issue trustless subdomains and also to do that in a way that allows 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 reissue names and so forth. The way this combines with L2 is a bit further down the roadmap but basically would allow you to say well if you migrate a name to L1 then it gets all these same guarantees as the name wrapper and well on L2 you can, there are are other permissions you can burn to say, you know, I, the subdomains 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 what. Okay. What are some other applications of this CCIP read gateway other than the NS? I mean, you know, there are broader implications in ENS itself, like the guest. DNS sex stuff I implemented. You know, we're effectively treating DNS like the L-tube. There are definitely uses 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 that is actually hosted externally to save on gas 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 zero on-chain gas cost because they're only, they only exist in a 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, just thinking about this, I mean, are there, could these off-chain reads be,

used in lieu of leveraging an on-chain oracle in some cases where the trust model allows it and are some contracts using that? And CCIP read calls can actually be used in transaction contexts as well. So you can use that data you get back from a callback to actually make a transaction,

which effectively makes it into a sort of a push oracle rather than 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 Ethereum state. Right. And would this also extend, I mean, could you also use this with, in complement with verifiable lofting computations, where like a server is performing a computation?

right, maybe like with a ZKVM or like a Wasam ZKVM or something like that, right? And it's returning back, it's returning back of some data with a proof. Is that also possible? Absolutely. As long as the proof can be verified inside the EVM, you can use it for it. So, you know, 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. Okay, well, that's really interesting.

This brings up like so many questions. What's the implication here? What's the broader implication of this, of this CCIP read on just the necessity for, yeah, on-chain oracles, 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 chains? I think 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 eardrop tokens could just look like a simple ERC20 transfer function to the app. 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 infrastructure. So what it really does is just improve the developer experience and improve the ease of use of use of all this.

Very cool. Yeah, I'll have to spend a little bit more time researching this. Yeah, coming back to the L2s, you know, of course, I think, you know, when thinking, about integrating ENS with Ethereum L2s. We're thinking about EVML2s. But I think in the future, we do expect to have non-EVML2s. I think with the growth of eigenlayer also we can expect Ethereum 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 this collision.

And so the multiple namespaces. What are some of the plans to make that possible? Let's say, like someone wants to build a Cozumwasum VM secured by Ethereum Security and bring ENS to that app. How would that be possible? Yes. 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 name space. 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 law can only resolve optimism-based names and an Ethereum molecule can only resolve Ethereum-based names. And so, you know, with CTIP-Reed, we're able to provide that bridge.

And that bridge can be to non-EVML2s. 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-EVML2s have a much larger design space. So it's a matter of finding a way to build that out, and that will likely require, you know,

L2-specific engineering to build appropriate registries on the L2s and so forth. When it comes to resolution, ultimately it starts at Ethereum. So even if you're resolving a, you know, a ZK Sync-based name or a name that resolves to a ZKSync identifier, you still start by the lookup process by querying Ethereum. Okay, yeah, it makes sense.

And, yeah, what's been the adoption of ENS on L2s, like which L2s are currently using it, or do you expect we'll start using ENS? So, you know, because it's open and permissionless, 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 dotcb.ad names, which will use CCIP read. and they have since moved on to base. We've got a generic gateway that we've been building very recently,

which allows for very trivially building gateways to just about any L2, and we've stood up official gateways for optimism for that so far. But we're planning to expand that to Arbitrome into any other, you know, OPM-based L2s 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 large integrations like Coinbase has been a little slow because most people don't have the resources to build their own link, their own gateway. And so that's what our generic gateways are intended for, is to make it much easier. So give us,

you know, a quarter or so, and you'll see people moving their names and they're hosting to L2s, easily through a UI, zero code, which is what we've been working on unlocking at the moment. Cool, yeah. Well, let's talk about Coinbase a little bit. So, I mean, they recently announced the CB.ID, ENS name that works across the Coinbase platform. Yeah, what's the, how does that work?

And how many new users have, has ENS recently? see from that integration? 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.id is a great example of both our DNS integration and our off-chain integration working together. You know, CB.D.ID is an ENS name, even though it's also a DNS name, and Coinbase simply imported it one time into ENS and then can treat it just the same as a

dot-eath name. and the way 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 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 have to create my CB. ID ID name.

Yeah, 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 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, you know, the same way, I guess that you would like name servers in your, in your land or, you know, your gateway. And so, you know, as a fund manager, like, we have several,

we have several noses safes 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 we use for that. And that's made it very easy for for us to do capital calls with our LPs, for example. We just like give them an N.S name and just verify that ENS name with them instead of like an address. And just, you know, when you're looking at your wallet, you just know, okay, 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 been a really cool use case. And, you know, couple that with the ability to like really easily buy ETH with a credit card. on like any of these sort of like credit card, um, 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 are sort of like quarantined, right? And, um, and, um, and to some extent, uh, 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 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 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 or obscurity. 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 ENS doesn't solve the problem that not does it cause it? You know, 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 ten, 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 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, okay, I'm going to send some eth over here. Oh, no, like, I wasn't supposed to do that. So it is also about having like good offset processes internally to make sure that like those things don't, don't touch. But yeah, I was chatting with a guy in, in Istanbul a couple of weeks ago. We were there for Cosmoverse and he was building this, this, this, this, uh, he, he, uh, the site called zero X PPL, right? Zero X people. I don't know if you've heard of it.

And it's sort of one of these like debank type services, but with really in-depth sort of data on interactions between addresses. So you sort of like go to one address and then you have this hub and spoke thing that shows you all the other addresses that it's interacted with. And, you know, I think I'm fairly good with my security and my outside. sec, but then, you know, 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, uh, including like payments to, to other folks.

And so, you know, talking about privacy, like, you know, one of the other things about this, the services that now, you know, they're integrating and I'm sure all the big sort of like chain analysis and sort of competitors to chain analysis are doing the same thing is implementing large language models to decipher connections between addresses. And this is what they were doing, right, where you can just say, okay, what are the addresses that this particular address have been, have interacted with or, you know, which address, which Ethereum addresses were participated in the, in the cosmos token sale, for instance, you know, like, you could sort of push it to that extent. What, like, have you thought about large language models and how they conflict with the

idea of on-chain privacy and what are some of the best practices that we can implement now as users of Ethereum where Ethereum doesn't have effective privacy on-chain? And 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 any sort of expose the assumptions that we make, you know, they democratize access to this sort of functionality, but ultimately aren't providing you anything that wasn't already, you know, there 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, it's seen 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 see widespread deployment of some of these primitives. 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 launder money, then it would be a sign of suspicion. Likewise, you know, chains like Zcash, 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 need better primitives and we also need to sort of enshrine them and make them the thing that's, used as much of the time as is practical rather than just in exceptional circumstances. Yeah, I mean, I agree with you that, like, politically this, this is very contentious. But, I mean, ultimately, 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 a... asymmetry of information, right? And so there's this like information arbitrage between market players and having like full transparency over everyone's, everyone's transaction history, everyone's business dealings, etc. With with whom everyone interacts economically, effectively sort of like breaks down that asymmetry and we end up in something closer to what I guess like communism, right? What's the hope do you think that? that within the next 10 years we have, you know, better on-chain privacy or absolute on-chain privacy would be, I guess, like, the desirable outcome? Or do you think that this is a pipe dream

that will never happen? I think 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 L2s that use, you know, systems similar to ZKSha or 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, Ethereum 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 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 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 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. years from now, but I think we might have moved a needle more of the direction of making privacy than all and making it easier to shield your assets and your transactions. Yeah. Yeah, I mean, in the context of, you know, if we think about account abstraction

and, you know, 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 attach your Twitter identity to your ENS or, you know, Keybase 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 Keybase identity. It's a shame that Keybase. is no longer really a viable product to use.

But how do you think about the role of account abstraction in forming a real decentralized identity in the form of ENS and perhaps also adding some layers of privacy there since we can rotate keys and that can be used in a way to abstract away the ultimate beneficiary of an identity? I think account abstraction in some form is going to be fairly essential to more widespread adoption of Ethereum and of crypto in general because of the usability benefits it brings. And one of the pleasant side effects of that is that it's easier to then implement things

like better financial privacy and so forth. Yeah. Maybe give an overview of what are the advancements in account of and the use of account obstruction with the NS on Ethereum. I think, I mean, you know, I don't follow the area of research in as much detail as I may be should, but, you know, to my awareness, the sort of two general approaches. One is that we can enshrine account abstraction in the base layer and the EVM with things like Orthcall and so on, which basically allow you to treat 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 understandable caution in implementing them. you know the second way is through you know authorizations through you know metatransactions and so forth

where all of this happens in the abstract 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 in server transaction that then has to be sent to some sort of relayer the relayer has to handle how to pay gas 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 and to pay the gas 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&S sort of continues to function the same way. You know, 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 the NS to external accounts. So fortunately, 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 Cometh team has a really nice implementation of account abstraction in their game. and yeah, it's like it's great how just how well it works. You just, you open the app. It creates a wallet. You connect that wallet to say like a past key. And then further on, as you sort of add assets to that wallet, it might ask you if it like connected to different forms of identity

or different signing mechanisms. And yeah, the onboarding experience is pretty incredible. And in terms of enshrinement, maybe an interesting examples to look towards is osmosis on cosmos. So they're building a kind of abstraction into the protocol. Now, of course, for osmosis, 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 really sort of nice way to build account 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 Oath in order to sign. And then also have different signing mechanisms based on the types of transactions that you're participating, that you're issuing. So if it's like 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 just do that with like, you know, your Twitter login or your Google login or something like that. So like having also permissions built in the protocol is really nice. 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 have total controller with that, but I understand that like for something like Ethereum, it's much more difficult to enshrine that into the protocol where there's so many applications and sort of L2s depending on that base layer. So it's an interesting challenge to have to deal 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 contract, delegate calls it and therefore it executes as the EOA. And in principle, this would require a fairly minimal set of changes to be, because all of that infrastructure, all of that mechanism is already in place. Unfortunately, you didn't get a lot of traction. There are a couple of odd-age cases around it, but I think it would be tractable

and potentially provide a much simpler mechanism than some of the other ones that have been proposed. Yeah. Yeah, I'm really looking forward to seeing a countertraction come to Ethereum in more tangible ways. And, yeah, I think we'll get there eventually, right? there's already some some implementations of it. Yeah, maybe looking to looking to the future of ENS and reflecting in the last six years. So I think it's safe to say that ENS is one of the largest or if not the largest Dow in Ethereum. Also generating revenue, right?

There was this one day earlier this year where ENS generated like upwards of of $235,000 in domain fees in a day, you know, millions, I think it's 2.4 million addresses, active ENS names. Yeah, what do you think of all this? And, you know, how do you reflect on, like, the last six years and where ENS has gotten to today? It's certainly been a journey. We always intended to decentralize the ENS over time. When we launched was, we We launched not long after the DAO. And so we weren't exactly keen to be like, hey, let's launch and straightaway launch a Dow, and it'll be fine.

You know, we wanted to actually see governance, primitives, mature and demonstrate their effectiveness first. But that absolutely happened. And, you know, two years ago, we launched the Dow and the ENS Dow. And you're right. It's been, it's one of the largest, you know, by participation, it's got ongoing revenue. It's, you know, ongoing participation as well. And I think it's been very effective at administering the protocol.

I think the revenue is an essential part of it. The fees were, for ENS, 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 set that balance where it's possible to find a name. that, you know, represents what we wanted to, you know, directly and easily in a sort of a liquid fashion rather than having the entire system squatted on immediately. You know, I've seen that sort of behaviour left uncontrolled has, you know, strangled ecosystems like Nankoin 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 ENS development and so forth. And I think the fact that ENS has revenue that it can actually use to continue to pay for development. It's meant that we haven't had to look for venture capital funding, which has now allowed us to stay truer to our open source and public good routes. It enabled us to help fund other projects in the ecosystem and relating to EMS as well. And it really provides us with like a stable future. So, you know, we've put a 50 million odd of the amount that's been raised into an endowment, and its sole goal is to grow stably and safely over time, so that ENS will remain a stable operating system for the next hundred

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 don't longer serves its purpose, but we need it in order to fund operations so it has to stay. So our ultimate goal is 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 like the most about it is it's enabled us to maintain that independence and that attitude that what we are building is infrastructure, not a money spinner, not an investment opportunity.

Yeah. How much is in the endowment? Well, it varies day to day. It is a little under 50 million at the moment, I think. Okay. It's divided up between ETH exposure and USDAC exposure. The basic intuition is that if somebody pays for 10 years of registration, we, after a year, one-tenth of 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 an ETH, we keep it in ETH, so we still have a large ETH exposure. And the Dow, therefore, sorry, the endowment therefore is divided up into those two sections. And because of the ETH exposure, you know, see some fairly large variation over time. Our endowment manager, Karpak, is very good and publishes weekly reports and monthly reports,

but provide a lot of detail into the goings-on. Yeah. I mean, one of the interesting things about ENS is, I think the governance, how active it is, you know, the implementation of the delegate system. You know, I was sort of surprised, I mean, plus simply surprised to see that Coinbase is a large delegate and fairly active 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 we someday see like ICANN sitting on the governance board of ENS, you know, and other large organizations that use the protocol? Yeah, I would love to see participation from, you know, from other large organizations and stakeholders. You know, I want ENS 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 doing what we can to make it as

easy as possible for people to shift their delegated votes. We've done that using things like free re-delegation where we use metat transactions and we pay the gas fees for re-delegating your tokens. But as with any project with a token, keeping people's attention and keeping them focused on governance 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 increasing governance participation

and also making it very easy for delegates to step up and step down and we want someone who comes along late to have a good opportunity 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 the votes delegated to them don't go to waste. because they're no longer active. Solon challenges like that is going to be a big thing going forward for the NSDAO to make sure it continues to be representative in how it governs. Yeah, I mean, I think like governance delegation is, you know, it's certainly like 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 different model

where validators are sort of 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 validator votes for you. But that has created, I think, a situation where I think a lot of people are dissatisfied with the way governance is conducted, right, where it would be better for, in some cases, maybe for things like spending, like community pool spending and things of that nature, treasury spending, treasury allocations to be governed by like 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, etc. But we found that I think the community is moving more towards this model where governance responsibilities are delegated or should be delegated

to like sort of sub-dows, right? This is a sub-dow idea. So, you know, it's an interesting problem to solve. Yeah. And any of this project, that little differently with our working groups, you know, that working, the whole hour next working group stewards are a regular basis, and they have delegated authority to deal with day-to-day decisions. I think there is 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 voted on by everybody, which is exhausting and requires everybody to be an expert on everything. Great. Well, Nick, thanks so much for coming back on and sharing an update on ENS. Yeah, really, really excited that we could have this conversation again.

And I also excited to see ENS growing and continue to grow and be a pillar for the way we should conduct governance in the space and also an important component to bringing in more adoption into Ethereum. So, yeah, a number go up in terms of ENS names created, I think is a good metric to be looking at. Excellent. 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 slash 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.