Nick Johnson: ENS - Multichain ENS Domains and Decentralised Identities. Ep. 520

Transcript

welcome to epicenter the show which talks about the Technologies projects and people driving decentralization and the blockchain revolution I'm SEO 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 um 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 enf and talk about some of the um interesting technical things that are happening with the protocol in terms of expanding to l2s we'll also talk about governance uh we'll talk about some of the growth that ens has seen in last a little while and also looking to the Future and uh where

the project is going Nick 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 s which I'm sure as very few people um yeah what why do we start with a bit of background and uh you how you became interested in uh decentralized naming Services CH yeah uh so I've been a software engineer uh for about God about 20 years now um and I've always had interest in sort of Internet infrastructure and so forth um 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 oh it's just money you know like is 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 uh started playing around with it almost immediately uh and um 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 uh you know go ethereum or on Swarm or you know something something we're working on on um 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 uh you know unknown future Etc but I was really

quite hooked on you know ethereum and and what we could build with it uh and so I I quit my job I I joined the ethereum foundation and pretty much one of my first jobs was to start working on um well I I started working on Swarm uh 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 experience is with you know 42 character long heximal 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 uh you know the these identifiers you know we solved this on the internet in like 1985 um so I started working on what eventually became the ethereum name service um started off as a sort of a side project from within the EF um gradually grew to take more of my time until it was my full-time job there uh and then at some point thef went well you know it's clear that this is more than one person's work um you know what about we we splend 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 um the decentralized name space or you the use case of decentralized names in in crypto is that because it's so easy to build uh it's so easy to build applications on on on blockchains whether that's ethereum or Cosmos or Sal or whatever L1 right or L2 there's been a multitude of uh decentralized name spaces that have emerged have popped up over the years of course like ens I think was one of the first ones uh we also have protocols like uh Unstoppable domains we have uh handshake also um and and then you know

Cosmos has their own and like each blockchain on Cosmos pretty much has their own salana as one I think and you know polygon um it's very you you mentioned this like early days of the internet how we solved this problem um but but the the the thing about how the internet solved this problem is because this because all the infrastructure wasn't there it was you know they um I can and sort of the domain name Service uh was able to generate like tremendous Network effect around like a single naming system and that's the domain name system now 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 Dame

services and you know how we will reason about these different name spaces in the future will everything sort of coales to ens or sort of resolve back to ens and uh 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 complimentary how do you see that playing out I mean uh you know naturally I'm here but I would like to see emn and more generally the global Nam space win so you know when I say the global Nam space ens has e but we also integrate with DNS transparently so any DNS name is an ens name as well um and I think that sort of approach is a better one

than than 10,000 competing 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 uh issues names that collide with each other uh in which case you have situations where different people might get different resolutions for the same name um 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 fishing and scamming and and so forth um so what what I would love to see is you know it doesn't have to be enss and and DNS and that's it but I would love to see more naming services and more change

integrate with the NS via the mechanisms we've exposed uh that make it possible to have a single unified name space even if parts of it are administered differently uh or specifically to a given chain they can all be in a single name space and resolvable by a single client um I think it's also you know worth pointing out just the huge overhead the imposers on um 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 um and so yeah what I'd love to see is is in is dominant naturally but in a a collaborative

way yeah I mean of course I think that that makes sense uh it makes sense for for everybody to be using the same name space right I mean at least from a practical perspective and from the perspective of avoiding collisions yeah um I I see your you're very hopeful but I I I don't I don't know how like if we have you know if we continue to have like l1s um with their own communities and sort of their own application space and I think it will be difficult to uh for everyone to align on on one name space although we can we can AR hopeful I guess I guess um yeah what are some of the um 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 their imag ask 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 eth to uh you know die. swap. eth or whatnot don't please don't use that I don't know if it actually works um but you know along those lines uh 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 um and that sort of thing is possible as well for you know automatically naming contract accounts for automatically naming um you know accounts on exchanges deposit addresses and so on and so forth um I've you know

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 the central land use it quite heavily um and I guess you know some of the DNS Integrations that we're seeing showing up now like art andbox and so on you know dobox through um uh through their regist are now making it possible to register dotbox names uh natively on chain so you can do it entirely through your ethereum client um and then have the name owned as an nft so if you want to transfer the dotbox domain you transfer the nft and that's the authoritative record of

ownership how does that work exactly uh effectively what happens is that dotbox has like a holding company that holds all the ratch names um 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 uh and so you know that way it's adherent to all the the I can 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 with some other registra okay and so then when you want to sort of manage your DNS uh the DNS for the domain you'll do

that using sort of like a web 3 auth authentification is that yes ex you use sign in with ethereum to sign into their interface and and manage it just like any L A oh that's super cool I really like that all right I'm going to get a box domain neat uh is this is this an integration that you guys help um put together because I me I I didn't even know about this dotbox uh domain extension yeah it's that it's it was one of the 2012 you know extensions that were the the extensions that were option in 2012 but some of the have launched earlier than others and dotbox 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 um yeah no we we work quite closely with them on on setting this up and so forth and I've been really pleased to see them embracing for it that's cool and are you guys um 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 uh in the more traditional domain name uh registration space and what's been your experience there and how like have been been receptive to to the idea of enss Y so so we've uh we have ATT teamed presented at DNS o which is uh a an industry Organization for DNS we're

active members of that um in addition you know we've we've attended Ian meetings and so forth we've found uh 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 uh which you know given crypto sometimes reputation in in The Wider world you know is is people's initial assumption um I can itself tends to be very conservative uh and you know understandably they're they're protecting a core piece of Internet Internet infrastructure um we're still working on convincing them that you know working with us is is better than uh trying to

pretend we don't exist uh and I'm confident we'll we'll get there but they're they're understandably cautious um and the the competitors we we talked about previous viously you know some of them issue hundreds or thousands of top level domains um that inevitably collide with the DNS route and that causes a lot of of Discord there and so when we approach Ian and other web 2 uh organizations we we're sort of careful to emphasize that our goal is to build with these pieces of infrastructure 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 um extensions but that they wanted to they wanted them to be compatible with Ian uh in a way that wouldn't uh create collisions and you know from from the perspective of of um of ens like ens Works nicely with Ian domains from the perspective that you can you can connect uh in a way your your your ens name to an I can domain um can you just like remind us how that works and what's the technical sort of um uh the the technical B that allow this to to to be possible yeah so so all of that works through DNS SEC which is a security

layer on top of the the base DNS layer uh the way DNS SEC works is uh you sign your zone so your your DNS records uh with a key you own and then the parent zone so say you've got you know eth link then the link zone signs your keys and then the root zone signs the link keys and then there's a root key that everybody knows and so you have this chain of trust that establishes that uh you know this name was authorized by all the relevant authorities along the way down to your domain um and so the way we do DNS integration is you enable DNS set for your Zone uh for your name you sign it and then you set a text record uh saying you know I want the owner of this

name on ens to be ZX whatever address uh 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 uh uh 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 ethereum uses uh and so verify Ying it can be quite costly um you know up to a million gas per per link basically um there's a few approaches we're taking to to reduce that uh one is there are now more efficient uh libraries that cost

less gas uh another is there's an EIP out at the moment to add the uh sb26 R1 curve to ethereum which would enable not just efficient DNS set but a whole lot of other uh crypto Primitives from sort of the real world because it's a very commonly used curve um and the final one is our effort on what we call gasless DNS SEC which is basically instead of verifying onchain in a transaction that you own the name at the time you update it uh 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 equal

ccip read uh which makes it possible possible for a client like ether 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 with l2s but ens was only compatible uh with L one ethereum natively uh now there's there's a there's a push to have NS be compatible on ethereum l2s like optimism arbitrum Etc um 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 ens is quite unlike a lot of other projects like if you have a token uh 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 defi primitive you can deploy it independently on each chain and that sort of a problem you you sort of have liquidity fragmentation but you know that's tolerable enus is a little different because we have this Global name space 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 ethereum L1 but that doesn't preclude moving arbitrarily large parts of the tree off into uh different l2s and so forth and that's the approach we've taken with our um our solution which is called ccip read and basically allows you to delegate entire parts of the NS hierarchy to an L2 or even to a private database or you know anything you can verify on chain basically um and so if you for example own you know wallet. e and you want to issue subdomains to people you can can delegate wallet. eth to the L2 of your choice issue them on the L2 uh 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 um functionality i' I've heard about it but I'm like not super uh in tune with how that works and yeah so the basic process of resolving an ens name is that you call smart contract you know grossly simplified you call a smart contract you say what does nick. eth resolve to and it Returns the result and that's all one L1 the extension with ccip read is you call the contract you ask what it resolves to and it returns uh a revert an error basically saying I need more information to complete this request and

the more information is please go make an HGB request to this endpoint with this data and then return it to me and the client then goes off and transparently does that um you know as part of the contract call um 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 stored on optimism you try and resolve neck. e it goes please consult the optimism Gateway and give me back what it what it Returns the optimism Gateway gives you then the resolution in nick. E along with all the Merkel proofs required to prove that that's part of the optimism State Route um 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 the point of view of the client you know the the app using EAS is you just did a regular contract call and you got the data back um 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 this storage slot from this chain um and then all the verification happens in libraries and so forth so so essentially the the contract is able to rever say if it doesn't have the data it it tells the client I don't have the data um but here is 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 offchain 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 um there's a liveness risk here but there isn't necessarily like a there's no trust risk right okay interesting yeah exactly and that's that's the thing because ultimately every rollup in order to be a rollup has to be able to prove things on L1 um it means that the strategy works for any rollup so you know it's easiest for us with evm based Roll-Ups because we can just 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 rollup uh proves it State on the L1 um 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 rollup is is correct this particular like um uh EIP uh would would it also allow reading from um like ipfs or some decentralized storage Source or it would it only be uh offchain resources uh it absolutely does uh and of course the trust model depends on the trust model of the thing you're reading from so for instance you could

uh you could store a Merkel route in your uh 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 root that was committed on L1 um 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 is honest okay got it and so with with regards to how l2s are using this now practically speaking uh if you're um if you've registered an ens name on on ethereum on on Main etherium uh I mean typically with I think there are some exceptions but the

the your your address is the same on ethereum as it is on l2s uh why why does that correspondence simply not work why do you need like an extra layer in order to uh I mean couldn't you just like check with ethereum what the address is like with some kind of message passing um rather than having the L2 needing to have its own um Nam space So yeah so I guess there's a there's a few issues here one is of course that although EOS ways tend to share the same address across all chains uh contract accounts don't um and so we need to be able to handle that separately um 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 L2 is available here is it enables you to to not just update your own ens name but also potentially to issue subdomains uh and to do that trustless LE 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 gas fees to set up their name they're going to be quite discouraged yeah okay now that makes sense and so then so then l2s I mean practically speaking l2s have would have sort of a a um like a an equivalent

subdomain or are we talking about like a like if I'm if I'm SE 3.0. eth on ethereum would I also be SE 3.0. eth on optimism or whichever else you 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 uh and then there's where the records are actually stored so you could store all your records on L1 but still encode you know addresses for half a dozen different chains or you could store your records all on arrum but uh you know all you ever return as 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 okay and what what are the complexities in terms of your wallets integrating this and having to resolve uh across like multiple l2s in order to avoid collisions yeah this is what 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 El who we support because these 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 eth get proof calls or whatnot on the L2 in question um and so clients and wallets simply need to implement a single unified DS resolution process and anyone can then permissionless add new data storage mechanisms for en okay now um I was reading about the ens wrapper uh which um is like a fairly new implementation that also is involved in the process of well from what I understand it that you know the challenge was that ens names were themselves nfts but the subdomains were not right uh the NS wrapper now enables uh subdomains to also be FTS and inherit properties from the say not the top

level but the the the main domain right um how does that work and what is the role of the ens wrapper with regards to l2s yeah so so as You observe like uh subdomains aren't erc721 or 1155 nfts because ens actually launched before either of those standards existed um so while you can transfer around subdomains just like any other nft uh they they use the interface for that one of the things the name rer was was created to do was to uh you know improve that and give a single unified interface to all names uh but the essential thing that therefore is that

um it makes it much easier to trustless issue subdomains so it's always been possible to trustless issue is 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 NS every name has control over all its subdomains so if I own wallet. eth I could I could issue you you know your name. wallet. e but uh then I could take it bag at 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 you know once I give you the name you can feel ured that it will continue to be your name uh and so that's what the wrapper provides you can wrap a name uh and then we have what

we call fusers which are a way of revoking your own permissions over a name so you can wrap it and then you can uh burn the fuses to say you can't unwrap it and to say that when you issue a subdomain uh you can't control it any further only the subdomain Odo can um and so those permissions make it possible to to issue trustless subdomains and also to do that in a way that allows um uh allows you to change how subdomains are issued uh 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 uh the way this combines with L2 is a bit further down the road mapap

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 uh and Well on to you can uh there are other permissions you can burn to say you know I the 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 whatnot okay what what are some other applications of this ccip read Gateway other than ens um I mean you know there are broader implication in ens itself like the gasless DNS 6 stuff I implemented you know we're

effectively treating DNS like the L2 um there are definitely uses outside that uh one of the the neater ones I've seen is around uh tokens so for instance your data Ur uh could uh your you know your data function to get metadata for a token could use ccip read and therefore return s of onchain data that's verified by the smart contract um but is actually noed 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 air drop a bunch ofs to people with zero onchain 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 uh for people to be able to claim them right I mean it just thinking about this I mean are there could these op chain reads be used in lie of uh of leveraging uh an onchain Oracle in some cases where the trust model allows it and are some contracts using that and and ccip read uh calls can actually be used in transaction contexts as well so you can use that data you get back from the Callback to actually make a transaction which effectively makes it into sort of a push Oracle rather than a a pull Oracle um or perhaps I'm getting the two terms wrong way around but in

any case you can fit 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 it's like yeah could you also use this with ex um in complement with verifiable offchain computations where like a server is U is performing a computation right maybe like with a um a ZK VM or like a wasm zkm or something like that right and it's returning back um it's returning back of uh some some data uh with a

proof is that 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 we talk about it as an L2 solution but really it is a generic you know verifiable sort of potentially trustless soft chain data fetching system okay W that's really interesting this brings up like so many questions like um what's the implication here what's the broader implication of this uh of this um the ccip read on just the necessity for yeah onchain oracles offchain uh computation service

and so this whole um part of the stack that has built its business model on the ability to provide verifiable data to chains I think it it's more a a new technology and in new interface for doing that rather than it is removing the need for that you know we ultimately we still need that data from offchain we still have the questions of like what degree of verifiability you can provide um what this does is it provides an API where it's much more transparent and easier to integrate for apps um and it you know 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

um you know claim of the airdrop tokens could just look like a simple erc20 transfer function to the app uh you know you could claim your airdrop just by transferring it you know into an account um but behind the scenes it's all using all of this uh all this infrastructure so what it really does is just improve the developer experience and uh 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 coming back to the l2s uh you know of course I think you know when when when thinking about integrating ens with ethereum l2s we we're thinking about um evm l2s but I think in in the future we

we do expect to have non-ml 2s I think with u with the growth of a lay also we we can expect uh ethereum security to um to be rented by non-m uh platforms um what's the what what are the implications here for ens and making ens compatible and this sort of comes back to the first topic we were talking about earlier with you know this collision and so the multiple name spaces um what are some of the plans to make that possible let's say like someone want to build a km wasm VM uh secured by ethere of security and bring ens to to to that to that uh

to that app um how would that be possible yeah so in terms of the name space of course all of this um you know all of area surround ccip read are pretty much they exist in order to ensure we have that one unified name space and so 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 work can only resolve optimism based names and a theum can only resolve theorum based names um and so you know with ccip read we're able to provide that bridge uh and that bridge can be to to non evml 2os you know again

as long as you can verify the responses you can do it but what that looks like is a little more varied because of course non evml 2s have a much larger design space so it's a matter of finding a way to uh to build that out and and that will likely require you know L2 specific engineering um to build appropriate Registries on the l2s and so forth um when it comes to resolution ultimately it's still it starts at ethereum you know so even if you're resolving a um you know a um ZK sync based name um or a name that resolves to a ZK sync identifier you still start by the pro the lookup process by by quering ethereum okay yeah makes sense and and

are yeah what's been the adoption of Ys you know on on l2s like which l2s are currently using it or do you expect will um start start usings so you know the because it's open and permissionless it's been a little bit uh you know we don't have a central database in that sense so for instance coinbase started off on their own internal private uh database when they issued cb. a names which will use ccip read uh and they have since moved on to base uh we've got uh a generic Gateway that we've we've been building very recently which allows for very trivially building gateways to just about any L2

uh and we have stood up official gateways for uh optimiz for that so far but we're planning to expand that to arbitrum and to any other you know op andr based l2s that pop up um and you know from there to others because it's quite easy to add new verification mechanisms for them um 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 uh you know link their own Gateway and so that's what our generic gate ways 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

hosting to to l2s uh you know easily through a UI zero code uh which is what we've been working on unlocking at the moment cool yeah well let's let's talk about um about coinbase a little bit so I mean they recently announced the cb. um ens name that uh Works across the coinbase platform yeah what what's the how does that work and uh how many new users have has ens received from from that integration it's uh it's hard to say because it's all offchain but we know it's in the millions uh you know simply because they're onboarding their entire

user base um cb. ad is a great example of of both our DNS integration and our our offchain integration working together you know see cb. as 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 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 uh data stored on uh base uh understandably uh which means that they can uh provide they can prove to you that you know

you're the one in Ultimate control of how your name resolves yeah I haven't tried it yet but um I'll have to have to create my cb. ID uh name yeah one of the one of the ways that I've been using ens the I mean so you know I got a couple of like ens domains for for like my own my own personal use but one of the ways that I've been using it that's been um really really helpful and it's I mean it's very B basic use case I guess but uh 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 Nam space like my own namespace that I've created and um and you know the same way I guess that you would like name servers

in your in your landan or you know your your your gateway and um so you know as a fund manager like we have several uh um we have several uh nois safe 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 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 ens name and just verify that enss name with them instead of likeing um 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 um but that's

that's been a really cool use case and you know couple that with um the ability to like really easily um buy eth eth with a credit card on like any of these sort of like credit card um servic where you can buy eth and you can basically like set up brand new addresses that have never sort of touch the outside that have never been touched by your own personal addresses are sort of like quarantined right and and um and to some extent uh uh shielded from your from your other identities because you can sort of put gas fees there so we 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 uh like a great great use case and something that we've been implementing um at the fund yeah I think that's that's absolutely the right way to handle it and to treat onchain privacy like a the connection between onchain privacy and naming comes up a lot and the thing I always emphasiz is that um you know not naming your accounts is security through obscurity you 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 but not ases it cause it you know the it sort of

makes it more obvious both to you and to others uh 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 I 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 um but um yeah I was I was chatting with a guy in in uh in istano a couple weeks

ago we were there for cosmoverse and um he was building this um this uh this site called ZX PPL right zerox people I don't know if you've heard of it um and it's sort of one of these like debank type Services um but with really indepth um sort of data on interactions between uh between addresses so you sort of like go to one address and then you you have this uh 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 in my absc 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 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 this service is 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 and this is what they were doing right where you can just say okay what are the addresses that this particular address has been um have been have interacted with or you know which address which ethereum addresses uh were participate participated in the in the cosmos um token sale for instance you

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 onchain privacy and what are some of the best practices that we can Implement now as users of ethereum where ethereum doesn't have effect of privacy on chain and what what is your hope that will you know at some point get to full onchain privacy yeah I think uh you know large language models much like I sort of expose the assumptions that we make you know they they democratize access to the sort of functionality um but ultimately aren't providing you anything that wasn't already uh you know there on chain um the solution I think is better Bas layer privacy Primitives

um the unfortunate thing is that you know politically these things are contentious at the moment uh 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 um and I think if you went to most people in the real world and said hey can I or bank statement they would react with alarm um but somehow when it happens on chain it's seen as as illegitimate um 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 uh you know scarless uh before we can we can see widespread deployment of some of these these Primitives um 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 laund the money then it would be a sign of Suspicion um likewise you know chains like um zcash you know seem to be treated with less intrinsic suspicion than mixers like tornado cache um simply because privacy is the default so I think we we need bit of Primitives and we also need to sort of try them and make them the thing that's used 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 um 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 um between Market players and having like full transparency over everyone's um everyone's transaction history everyone's business dealings Etc uh with with whom everybody interacts economically uh effectively sort of like

breaks down that as that information asymmetry and we end up in something closer to what I guess like communism right um what's the uh what's The Hope do you think that that you know within the next 10 years we have you know better onchain privacy or like absolute unchain privacy would be I guess like the you know the the desirable outcome uh or or you you think that this is uh a pipe stream 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 l2s that use uh you know systems similar to ZK sure ZK sync uh 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 um you know in the same way that I would love to see more more transparency into the operation of like you know Banks and so forth there Financial privacy most benefits individuals and companies not you know Banks and and governments um 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 in the direction of making privacy the nor and making it easier to to Shield your um you know your assets and your transactions yeah yeah I mean in the context of um uh you if we think about a account abstraction and you thinking more broadly about like decentralized

identities and how identities uh are form through these you know links to other forms of identity right so like um you know currently if you want to um add some weight to your ens identity you can you can attach your Twitter identity to uh to your enss or you know keybase has this model also where um you'll uh attest to your ownership of other pieces of identity in order to uh bring more weight to you know your keybase identity it's a shame that keybase uh is no longer really a viable product to use but um 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 um and and that can be used in in a way to um to abstract away the ultimate beneficiary of an of an identity I think uh account abstraction in some form is going to be fairly essential to to more widespread adoption of of ethereum and of you know crypto and general because of the usability benefits it brings uh and 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 um maybe maybe give an overview of

um you know what are the what are the advancements in coun struction and um and the use of account of structure with the NS on ethereum 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 sort of two general approaches one is that we can enshrine and account abstraction in the the base layer in the evm um with things like or call and so on which basically allow you to treat a a special contract account like an EA uh and act from it um and that provides you know sort of a a more direct way to do things and it also

sidesteps you know a bunch of difficulties around uh you know gas and transaction fees and so forth um 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 uh you know the second way is through uh you know authorizations through uh you know meta transactions and so forth where all of this happens in the abstract you know in the in the user layer um 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 then has to sign a message in serve a transaction that then has to be sent to some sort of relayer the relayer has to handle you know how to pay gas fees and how to be reimbursed and then either the user or the platform has to somehow you know translate uh you know the right amount of funds into 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 um in either case you know ens sort of continues to function the same way you know we we can name contract accounts just the same as naming uh externally owned accounts um you can transact from them just fine you know there's nothing sort of intrinsically linked TOS to to external

accounts fortunately we we work with account abstraction really well and you know being able to name those accounts can also improves the ux a lot and you end up with more of them to keep track of than you might otherwise yeah I saw the um the comth team has a really nice implementation of of account abstraction in in their in their game and um yeah it's like it's it's great how just how well it works you you just you uh you open the app uh it creates uh it creates a wallet you connect that wallet to say like a pass key and and then you know further on as you sort of add asset to that wallet it might ask you to like connect it to different uh forms of identity or or different um signing mechanisms and yeah

the UN boarding experiences is pretty incredible you in terms of enshrinement uh maybe an interesting uh sort of example to look toward it's is um is osmosis on on um on Cosmos so they're they're building a kind of exraction 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 um but um uh like a month ago they demoed this uh um this really sort of nice way to build a coun abstraction where existing addresses existing EA addresses uh could be turned into um abstracted accounts and then you can effectively like connect different pass Keys Twitter

accounts or like any ooff uh in order to to sign and then also have um 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 uh however if you're just like voting on a government's proposal or performing some other action that doesn't involves transing funds you might be able to just 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 I mean that's one of the benefits of having an app chain I guess is that you can sort of um you know you can you can have total control over that but I understand

that like for something like ethereum it's much it's much more difficult to enshrine that into the protocol where you there's so many applications and sort of l2s depending on that that bass 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 a couple of years ago I proposed thep that would Implement something very similar uh never got much TR traction unfortunately but the basic Insight is what if you could what if an EA could delegate call so you would have a special transaction type that instead of just calling a TR a contract delegate calls it and therefore it executes as the EA and in principle this would require a fairly minimal set of changes to the evm because all that

infrastructure all of that that mechanism is already in place um unfortunately it didn't get a lot of traction there are a couple of odd AG cases around it but I think it would be tractable um and you know potentially provide a much simpler mechanism than some of the other ones that are being proposed yeah yeah I'm I'm I'm really looking forward to seeing like more counter attraction come come to ethereum in in more tangible ways and um yeah I think we'll get there uh eventually right there's already some some some imple implementations of it so yeah maybe looking to um looking to the future of ens and reflecting on the last six years um so I think it's I think it's safe to say that ens is one

of the um like largest or if not the largest Dow in ethereum um also generating Revenue right there was this one day uh earlier this year where ens generated like upwards of $235,000 in in domain fees in a day um you know Millions I think it's two 2.4 million addresses uh active ens names yeah what what do you think of all this and you know how do you reflect on like the last six years and where uh ens has gotten to today uh it's certainly been a journey um we always intended to to decentralize the NS over time when we launched was we

launched not long after the the Dow uh 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 uh you know wanted to actually see governance Primitives mature and and demonstrate their effectiveness first um but that absolutely happened and you know two years ago we launched the Dow and the ens Dow uh 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 um you know ongoing participation as well and I think it's been very effective at administering the protocol um I think the the revenue is an essential part of it the you know the fees were uh 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 that' 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 want it to um 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 uh has you know strangled ecosystems like NCoin and other early attempts um but a a very pleasant side effect of that is of course it generates funding which can help uh 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 develop pay for development it's meant that we haven't had to you know look for Venture Capital funding which is now allowed us to stay trer to our our open source and public good roots um it enabled us to help fund other projects in the ecosystem and you know and relating to ens as well um and it's it really provides us with like a stable future so you know we've put 50 million odd of the the amount that's being raised into an endowment and that sole goal is to to grow stably and and safely over time so that ens will remain a stable oper system for the next 100

years or more uh 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 is to be able to make those decisions independently of each other and things like the endowment you know work to make that possible um 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 it varies dayto day uh it

is a little under 50 million at the moment I think we okay it's divided up between eth exposure and usdc exposure um the basic in intuition is that if somebody pays for 10 years of reg ation um we after a year one/ tenen of that has effectively been 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 rented yet and because it was paid anath we keep it e so we still have a large eth exposure um and the Dow therefore sorry the endowment therefore

is divided up into two those two inter sections and because of the eth exposure you know seees some some fairly large variation over time our endowment manager carpat is is very good and publishes weekly reports and monthly reports that you know provide a lot of detail into the the going on yeah I mean the one of the interesting things about uh uh about ens is I think the the the the governance how active it is um 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 uh fairly active in in governance uh you know looking to the future of of uh of

ens and particularly the governance you know how do you think that will scale as ens grows and you know will some will we someday see like I can sitting on the governance Board of of uh of enss you know and and and other large organizations that that use the protocol I would yeah I would would love to see participation from uh 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 uh 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 their delegated votes um you know we've we've done that using things like free redelegation where we

use Mr transactions and we pay the guest fees for redating your tokens but as was any project with a token the uh keeping people's attention uh and keeping them you know focused on governance and and active in it can be a problem so we see this gradual decline in delegated token counts over time and so uh 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 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 the votes delegated to them don't go to waste you

know because they're no longer active um soling challenges like that is going to be a big a big thing going forward for the NSD to make sure it continues to be representative in our governs yeah I mean I think like governance delegation is uh you know it's certainly like a an issue that we see on the cosmo side of things as well right where you know I think cos Cosmos has a cosmos chains have a a different model where validators are sort of the the deao delegate right if you don't uh vote um if you don't vote from your own sort of token uh your own tokens that your your validator votes for you but you know that has created I think a a

situation where I think a lot of people are dissatisfied with the way governance is uh is conducted right where it would be be better for you in C some cases maybe for things like like U like spending like community pool spending and things of that nature uh treasury spending uh treasury allocations uh to be governed by like a a group of folks right so for that that U responsibility to be delegated to like a group of folks that are voted in by governance that can be vetoed Etc but um we you know 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 subd dows right this subow idea so um you know it's a it's an

interesting problem to solve yeah and and ens approaches that a little differently with our working groups you know that working uh the whole Dow El working group stewards on a regular basis and they have delegated authority 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 um 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 and requires everybody to be an expert on everything great well uh Nick thanks so much for coming back on and uh sharing an update on on ens um yeah really really excited that we could uh have this conversation again and also excited see um ens growing and continue to grow and be uh a pillar for the way you know we should conduct governance in the space and and and also an important um an important component to um bringing in more adoption into ethereum so yeah ex number go up in terms of uh ens uh names created I think

is is a good metric to be looking at absolutely thanks Nick yeah thank you it was a pleasure