1 00:00:13,800 --> 00:00:15,720 Welcome to Epicenter, the show which talks about the 2 00:00:15,720 --> 00:00:18,480 technologies, projects and people driving decentralization 3 00:00:18,480 --> 00:00:21,400 and the blockchain revolution. I'm Sevaston Quichio and today 4 00:00:21,400 --> 00:00:25,640 my guest is Nick Johnson. He's the founder of ENSENS is 5 00:00:25,640 --> 00:00:28,960 the Theorem Name Service. It is the most used, most widely 6 00:00:28,960 --> 00:00:33,760 used decentralized naming service and the biggest Dow on 7 00:00:33,760 --> 00:00:37,840 Etherium. And we had Nick on a year ago. 8 00:00:37,840 --> 00:00:42,080 And so we're having him back on today to give us a bit of an 9 00:00:42,080 --> 00:00:45,920 update on ENS and talk about some of the interesting 10 00:00:45,920 --> 00:00:47,760 technical things that are happening with the protocol in 11 00:00:47,760 --> 00:00:50,520 terms of expanding to L twos. We'll also talk about 12 00:00:50,520 --> 00:00:53,200 governance. We'll talk about some of the 13 00:00:53,200 --> 00:00:56,640 growth that ENS has seen in the last little while and also 14 00:00:57,040 --> 00:01:00,160 looking to the future and where the project is going next. 15 00:01:00,360 --> 00:01:02,800 Thanks for coming on. They should be here again. 16 00:01:04,120 --> 00:01:07,560 So for those who missed the last episode, who maybe had never 17 00:01:07,560 --> 00:01:10,960 heard of you or never heard of VNS, which I'm sure is very few 18 00:01:10,960 --> 00:01:15,240 people, yeah, why don't we start with a bit of background and you 19 00:01:15,240 --> 00:01:19,160 know how you became interested in decentralized naming 20 00:01:19,160 --> 00:01:20,760 services? Sure. 21 00:01:20,760 --> 00:01:24,360 Yeah. So I've been a software engineer 22 00:01:24,720 --> 00:01:28,200 for About God about. 20 years now. 23 00:01:29,560 --> 00:01:33,040 And I've always had interest in sort of Internet infrastructure 24 00:01:33,040 --> 00:01:36,480 and so forth. And you know, when when I first 25 00:01:36,480 --> 00:01:39,080 heard about Bitcoin way back, I sort of looked into it and I was 26 00:01:39,080 --> 00:01:40,440 like, oh, that's kind of interesting. 27 00:01:40,440 --> 00:01:43,360 But that was just money. You know, like there's what I 28 00:01:43,360 --> 00:01:45,200 really want is a programmable platform. 29 00:01:45,520 --> 00:01:48,040 And so I sort of ignored it for a while. 30 00:01:48,040 --> 00:01:51,960 And then sometime later came across Ethereum and went 31 00:01:51,960 --> 00:01:54,440 suddenly, wow, this is exactly what I was thinking about. 32 00:01:54,440 --> 00:01:58,280 This is really very cool. Started playing around with it 33 00:01:58,280 --> 00:02:04,000 almost immediately and inside of you know three months was got a 34 00:02:04,000 --> 00:02:06,640 call from the Ethereum Foundation saying hey would you 35 00:02:06,640 --> 00:02:10,800 like to come work with us on on you know go Etherium or on Swarm 36 00:02:10,800 --> 00:02:14,760 or you know something something we're working on was a bit of a 37 00:02:14,760 --> 00:02:17,240 plunge for me because it was going from the comfort of like 38 00:02:17,240 --> 00:02:20,040 full employment to to a contractor position you know big 39 00:02:20,040 --> 00:02:24,080 pay cut you know unknown future etcetera, but. 40 00:02:24,600 --> 00:02:28,680 I was really quite hooked on you know Etherium and and what we 41 00:02:28,680 --> 00:02:32,560 could build with this. And so I I quit my job. 42 00:02:32,560 --> 00:02:36,320 I I joined the Etherium Foundation and pretty much one 43 00:02:36,320 --> 00:02:40,920 of my first jobs was to start working on well, I I started 44 00:02:40,920 --> 00:02:45,520 working on Swarm and my first sort of side project was you 45 00:02:45,520 --> 00:02:48,720 know what can I build in the way of a naming service? 46 00:02:48,720 --> 00:02:51,040 Because one of the very first things. 47 00:02:51,560 --> 00:02:55,680 That I noticed was how bad the user experiences with, you know, 48 00:02:55,720 --> 00:02:58,760 42 character long and hexadecimal addresses and so 49 00:02:58,760 --> 00:03:01,360 forth. And I was like, why is this not 50 00:03:01,360 --> 00:03:02,920 already here? You know, this seems like a 51 00:03:02,920 --> 00:03:05,480 really basic bit of infrastructure to allow people 52 00:03:05,480 --> 00:03:08,720 to, you know, not just transact with each other but interact 53 00:03:08,720 --> 00:03:12,200 with contracts and so forth without having to know, you 54 00:03:12,200 --> 00:03:15,040 know, the these identifiers. You know, We solved this on the 55 00:03:15,040 --> 00:03:19,880 Internet in like 1985. So I started working on what 56 00:03:19,880 --> 00:03:21,960 eventually became the Etherium Name Service. 57 00:03:22,920 --> 00:03:25,920 Started off as a sort of a side project from within the EF 58 00:03:26,760 --> 00:03:29,400 gradually grew to take more of my time until it was my full 59 00:03:29,400 --> 00:03:32,640 time job there. And then at some point the EF 60 00:03:32,640 --> 00:03:34,440 went well. You know, it's clear that this 61 00:03:34,440 --> 00:03:39,000 is more than one person's work, You know, what about we We spin 62 00:03:39,000 --> 00:03:40,640 you out into your own organization, give you a 63 00:03:40,640 --> 00:03:43,960 generous grant to get started, and you can build this as as a 64 00:03:43,960 --> 00:03:46,240 full time project with, you know, with funding. 65 00:03:46,760 --> 00:03:49,360 So it basically it went from there. 66 00:03:52,200 --> 00:03:52,720 Cool. Yeah. 67 00:03:52,760 --> 00:03:57,160 So I mean one of the things that I think is is interesting about 68 00:03:57,200 --> 00:04:01,680 the the decentralized namespace or the the, the use case of 69 00:04:01,680 --> 00:04:06,240 decentralized names in in crypto is that because it's so easy to 70 00:04:06,240 --> 00:04:11,200 build, it's so easy to build applications on on on 71 00:04:11,200 --> 00:04:14,600 blockchains whether that's Ethereum or Cosmos or Solana or 72 00:04:14,600 --> 00:04:20,560 whatever L1 right or L2. There's been a multitude of 73 00:04:21,320 --> 00:04:25,880 decentralized namespaces that have emerged that have popped up 74 00:04:25,880 --> 00:04:27,600 over the years. Of course like ENSI think was 75 00:04:27,600 --> 00:04:30,800 one of the first ones. We also have protocols like 76 00:04:31,280 --> 00:04:37,560 unstoppable domains we have a handshake also and and then you 77 00:04:37,560 --> 00:04:41,040 know Cosmos has their own and like each blockchain on Cosmos 78 00:04:41,040 --> 00:04:43,920 pretty much has their own. Solana has one I think and you 79 00:04:43,920 --> 00:04:48,400 know Polygon, it's very dear you mentioned this like early days 80 00:04:48,400 --> 00:04:50,080 of the Internet and how we solve this problem. 81 00:04:51,400 --> 00:04:54,840 But the the the thing about how the Internet solves this problem 82 00:04:54,840 --> 00:04:57,480 is because it's because all the infrastructure wasn't there. 83 00:04:57,760 --> 00:05:03,840 It was you know they I can and so the domain name Service was 84 00:05:03,840 --> 00:05:07,640 able to generate like tremendous network effect around like a 85 00:05:07,640 --> 00:05:12,320 single naming system and that's the Domain Name System and 86 00:05:12,320 --> 00:05:14,280 that's it's very different in crypto, right, because it's so 87 00:05:14,280 --> 00:05:16,400 easy to to to sort of like bring these up. 88 00:05:17,200 --> 00:05:20,400 How do you think about the future of name services and you 89 00:05:20,400 --> 00:05:24,160 know how we will reason about these different name spaces in 90 00:05:24,160 --> 00:05:25,800 the future? Will everything sort of coalesce 91 00:05:25,800 --> 00:05:30,560 to ENS or sort of resolve back to ENS and and and have this one 92 00:05:30,560 --> 00:05:33,200 main naming service or? Or do you think there can be, 93 00:05:33,960 --> 00:05:36,080 you know, many different name services that sort of compete 94 00:05:36,080 --> 00:05:38,800 with each other or that are complementary and how? 95 00:05:38,840 --> 00:05:42,280 How do you see that playing out? I mean, you know, naturally I'm 96 00:05:42,280 --> 00:05:46,880 biased here, but I would like to see ENSN and more generally the 97 00:05:46,880 --> 00:05:49,320 global namespace wins. So you know, when I say the 98 00:05:49,320 --> 00:05:51,800 global namespace ENS has dot EFF. 99 00:05:52,120 --> 00:05:56,200 But we also integrate with DNS transparently, so any DNS name 100 00:05:56,240 --> 00:05:59,560 is an ENS name as well. And I think that sort of 101 00:05:59,560 --> 00:06:03,360 approach is a better one than than 10,000 computing name 102 00:06:03,360 --> 00:06:05,440 services. There's, you know, there's a few 103 00:06:05,440 --> 00:06:08,080 problems with that, but the biggest of them is collisions 104 00:06:08,080 --> 00:06:11,080 and, you know, inevitably. More than one naming service 105 00:06:11,080 --> 00:06:14,160 springs up that that issues names that collide with each 106 00:06:14,160 --> 00:06:17,760 other, in which case you have situations where different 107 00:06:17,760 --> 00:06:20,280 people might get different resolutions for the same name. 108 00:06:21,200 --> 00:06:23,800 That's a recipe for disaster, both in terms of, you know, 109 00:06:23,800 --> 00:06:26,200 accidental losses of funds and so forth. 110 00:06:26,200 --> 00:06:29,960 And also it's just it's a dream for phishing and scamming and 111 00:06:29,960 --> 00:06:34,480 and so forth and so. What what I would love to see 112 00:06:34,480 --> 00:06:38,600 is, you know, it doesn't have to be ENS and DNS and that's it. 113 00:06:38,600 --> 00:06:42,440 But I would love to see more naming services and more chains 114 00:06:42,440 --> 00:06:46,160 integrate with ENS via the mechanisms we've exposed that 115 00:06:46,160 --> 00:06:48,880 make it possible to have a single unified namespace. 116 00:06:48,880 --> 00:06:52,280 Even if parts of it are administered differently or 117 00:06:52,280 --> 00:06:55,360 specifically to a given chain, they can all be in a single 118 00:06:55,360 --> 00:06:57,720 namespace and resolvable by a single client. 119 00:06:58,480 --> 00:07:00,600 I think it's also, you know, worth pointing out. 120 00:07:00,600 --> 00:07:04,680 Just the huge. Overhead this imposes on wallets 121 00:07:04,680 --> 00:07:08,040 and apps and so on to implement all of these and to 122 00:07:08,040 --> 00:07:11,200 independently decide how they're going to handle, you know, each 123 00:07:11,200 --> 00:07:13,520 of the services and their potential collisions and so 124 00:07:13,520 --> 00:07:16,120 forth that it can create a a mess. 125 00:07:17,320 --> 00:07:21,240 And so, yeah, what I'd love to see is, is ENS dominant 126 00:07:21,240 --> 00:07:23,520 naturally, but in a collaborative way. 127 00:07:26,200 --> 00:07:27,800 Yeah. I mean of course I think that 128 00:07:27,800 --> 00:07:31,960 makes sense it it makes sense for for everybody to be using 129 00:07:31,960 --> 00:07:34,960 the same namespace, right. I mean at least from a practical 130 00:07:34,960 --> 00:07:37,360 perspective and from the perspective of avoiding 131 00:07:37,360 --> 00:07:42,360 collisions. Yeah I I I see you're you're 132 00:07:42,360 --> 00:07:45,320 very hopeful but I I I don't I don't know how I like if we have 133 00:07:45,440 --> 00:07:49,840 you know if we continue to have like L ones with their own 134 00:07:49,840 --> 00:07:52,840 communities and sort of their own application space and I 135 00:07:52,840 --> 00:07:56,600 think it will be difficult to for everyone to align on on one 136 00:07:56,600 --> 00:07:58,840 namespace although we can we can arrange a hopeful I guess. 137 00:07:58,920 --> 00:08:02,960 I guess, yeah. What is some of the, what are 138 00:08:02,960 --> 00:08:06,800 some of the coolest use cases that you you've seen people 139 00:08:07,080 --> 00:08:10,960 implement using ENS? You know, beyond just having a a 140 00:08:11,080 --> 00:08:12,760 a name attached to the theorem address? 141 00:08:12,760 --> 00:08:14,920 Like, what are some unique things that people are doing 142 00:08:14,920 --> 00:08:19,120 with the ENS these days? I think some of the the sort of 143 00:08:19,120 --> 00:08:22,480 programmatic integrations like there are various if it's where 144 00:08:22,480 --> 00:08:25,480 you can. You know you send some ETH to, 145 00:08:26,080 --> 00:08:28,680 you know, die, dot, swap, dot, ETH or what not. 146 00:08:28,680 --> 00:08:29,720 Don't. Please don't use that. 147 00:08:29,720 --> 00:08:32,679 I don't know if it actually works, but you know, along those 148 00:08:32,679 --> 00:08:35,960 lines and it swaps it for die just transparently. 149 00:08:35,960 --> 00:08:40,799 So you can remove the need for AUI entirely and just automate 150 00:08:40,799 --> 00:08:42,960 this sort of thing. And that sort of thing's 151 00:08:42,960 --> 00:08:45,840 possible as well for, you know, automatically naming contract 152 00:08:45,840 --> 00:08:48,880 accounts, for automatically naming, you know, accounts on 153 00:08:48,880 --> 00:08:51,640 exchanges, deposit addresses, and so on so forth. 154 00:08:53,360 --> 00:08:55,800 I've, you know I've seen some cool efforts around 155 00:08:55,800 --> 00:08:59,120 automatically issuing people or sorry easily issuing people sub 156 00:08:59,120 --> 00:09:00,920 domains and so on for themselves. 157 00:09:01,240 --> 00:09:04,280 You know associated with some affiliation of the years, you 158 00:09:04,280 --> 00:09:05,760 know. So we've seen like the central 159 00:09:05,760 --> 00:09:10,440 and use it quite heavily and I guess you know some of the DNS 160 00:09:10,440 --> 00:09:13,600 integrations that we're seeing showing up now like dot art and 161 00:09:13,600 --> 00:09:18,600 dot box and so on, you know dot box through through their 162 00:09:18,600 --> 00:09:20,920 registrar. Are now making it possible to 163 00:09:20,920 --> 00:09:24,600 register dot box names natively on chain. 164 00:09:24,600 --> 00:09:29,120 So you can do it entirely through your Etherium client and 165 00:09:29,120 --> 00:09:31,640 then have the name owned as an NFT. 166 00:09:31,640 --> 00:09:34,160 So if you want to transfer the dot box to main, you transfer 167 00:09:34,160 --> 00:09:36,440 the NFT, and that's the authority of record of 168 00:09:36,440 --> 00:09:39,440 ownership. How does that work exactly? 169 00:09:41,040 --> 00:09:45,000 Effectively what happens is that dot box has like a holding 170 00:09:45,000 --> 00:09:47,920 company that holds all the rats names. 171 00:09:48,840 --> 00:09:52,680 And they have a contract that basically says, you know if you 172 00:09:52,680 --> 00:09:55,760 can prove you own the NFT then we'll follow your instructions 173 00:09:55,760 --> 00:10:00,320 on on what to do with it. And so you know that way it it's 174 00:10:00,320 --> 00:10:04,240 adherent to all the the Ican regulations around who is data 175 00:10:04,240 --> 00:10:06,920 and so on so forth. But you still have direct 176 00:10:06,920 --> 00:10:09,640 control over the name, and if you want to transfer it out, you 177 00:10:09,640 --> 00:10:13,080 can they simply transfer ownership to you at some other 178 00:10:13,080 --> 00:10:17,680 registrar, OK. And so then when you want to 179 00:10:17,680 --> 00:10:23,960 sort of manage your DNS, the DNS for the domain, you'll do that 180 00:10:23,960 --> 00:10:27,000 using sort of like a Web 3 authentication, is that? 181 00:10:27,960 --> 00:10:30,520 Yes. Where you sign in with Ethereum 182 00:10:30,520 --> 00:10:34,120 to sign into their interface and and manage it just like any M&A. 183 00:10:35,200 --> 00:10:36,960 Oh, that's super cool. I really like that. 184 00:10:36,960 --> 00:10:38,880 All right, I'm gonna get a box domain. 185 00:10:41,080 --> 00:10:42,960 Neat is this? Is this an integration that you 186 00:10:42,960 --> 00:10:45,720 guys helped put together? Because I mean I didn't even 187 00:10:45,720 --> 00:10:48,600 know about this doc box domain extension. 188 00:10:48,960 --> 00:10:52,160 Yeah, it's that. It's it was one of the 2012, you 189 00:10:52,160 --> 00:10:54,920 know, extensions that were there were the extensions that were 190 00:10:54,920 --> 00:10:58,000 optioned in 2012, but some of the needs have launched earlier 191 00:10:58,000 --> 00:11:00,080 than others and Doc Box is one of the later ones. 192 00:11:00,080 --> 00:11:03,160 But that's allowed them to take advantage of this when it might 193 00:11:03,160 --> 00:11:05,600 have been difficult to do so if they'd already launched and hit 194 00:11:05,600 --> 00:11:08,640 a lot of, you know, unwrapped registrations. 195 00:11:09,560 --> 00:11:11,440 Yeah. No, we we were quite closely 196 00:11:11,440 --> 00:11:14,040 with them on on setting this up and so forth and I've been 197 00:11:14,040 --> 00:11:16,560 really pleased to see them embracing E and ES for it. 198 00:11:17,280 --> 00:11:21,000 That's cool. And are you guys, you know, do 199 00:11:21,000 --> 00:11:24,960 you guys interact with or have you interacted with, you know, I 200 00:11:24,960 --> 00:11:30,000 can or any of the folks, you know, working in the in the more 201 00:11:30,000 --> 00:11:34,120 traditional domain name registration space and what's 202 00:11:34,120 --> 00:11:36,320 been your experience there and how like have them been 203 00:11:36,320 --> 00:11:38,600 receptive to to the idea of ENS? Yeah. 204 00:11:39,400 --> 00:11:44,120 Yep, so, so we've we've attended and presented at DNS O AC which 205 00:11:44,120 --> 00:11:47,920 is a an industry organization for DNS. 206 00:11:47,920 --> 00:11:51,800 We're active members of that. In addition, you know we've 207 00:11:51,840 --> 00:11:55,360 we've attended ICAN meetings and so forth we've found. 208 00:11:55,920 --> 00:11:59,440 A lot of people in the DNS world are quite receptive once you 209 00:11:59,440 --> 00:12:02,400 make it clear that this isn't a cash grab basically you know 210 00:12:02,400 --> 00:12:05,280 that we're actually seriously trying to build real useful 211 00:12:05,280 --> 00:12:08,920 infrastructure not just a platform for speculation which 212 00:12:09,160 --> 00:12:12,960 you know given crypto sometimes reputation in in the wider 213 00:12:12,960 --> 00:12:15,760 world, you know is is people's initial assumption. 214 00:12:16,960 --> 00:12:20,200 ICANN itself tends to be very conservative and you know 215 00:12:20,200 --> 00:12:23,120 understandably they're they're protecting a a core piece of 216 00:12:23,120 --> 00:12:27,360 them into these infrastructure. We're still working on 217 00:12:27,360 --> 00:12:31,040 convincing them that you know working with us is is better 218 00:12:31,040 --> 00:12:35,080 than trying to pretend we don't exist and I'm confident we'll 219 00:12:35,080 --> 00:12:36,760 we'll get there. But they're they're 220 00:12:36,760 --> 00:12:41,040 understandably cautious and the the competitors we've we've 221 00:12:41,040 --> 00:12:44,640 talked about previously, you know some of them issue hundreds 222 00:12:44,640 --> 00:12:49,240 or thousands of top level domains that inevitably collide 223 00:12:49,240 --> 00:12:51,600 with the DNS route and that causes a lot of. 224 00:12:52,080 --> 00:12:55,400 Of discord there. And so when we approach I can 225 00:12:55,400 --> 00:12:59,480 and other with two organizations where we're sort of careful to 226 00:12:59,480 --> 00:13:03,160 emphasize that our goal is to build with these pieces of 227 00:13:03,160 --> 00:13:06,520 infrastructure and not you know override them basically. 228 00:13:07,480 --> 00:13:10,960 Yeah I I remember speaking with the handshake folks like a 229 00:13:11,040 --> 00:13:16,400 couple years ago on the podcast and their their view was that 230 00:13:16,640 --> 00:13:21,560 you know they they did have overlapping extensions but that 231 00:13:21,560 --> 00:13:25,960 they wanted to they wanted them to be compatible with I can in a 232 00:13:25,960 --> 00:13:28,960 way that wouldn't create collisions. 233 00:13:29,600 --> 00:13:33,520 And you know from from the perspective of of of ENS, it's 234 00:13:33,680 --> 00:13:37,120 like ENS works nicely with I Can domains from the perspective 235 00:13:37,120 --> 00:13:41,880 that you can you can connect in a way your your your ENS name to 236 00:13:41,880 --> 00:13:46,400 an I can domain. Can you just like remind us how 237 00:13:46,400 --> 00:13:52,760 that works and what's the technical, sort of the the, the 238 00:13:52,760 --> 00:13:55,240 technical best that allowed this to to to be possible? 239 00:13:55,880 --> 00:13:59,240 Yeah so so all of that works through DNS SIC which is a 240 00:13:59,240 --> 00:14:02,000 security layer on top of the the base DNS layer. 241 00:14:02,560 --> 00:14:07,760 The way DNS SIC works is you sign your zone, so your your DNS 242 00:14:07,760 --> 00:14:11,360 records with a key you own and in the parent zone. 243 00:14:11,360 --> 00:14:14,320 So say you've got your ETH dot link, then the dot link zone 244 00:14:14,320 --> 00:14:18,960 signs your keys. And then the root zone signs the 245 00:14:18,960 --> 00:14:22,040 dot link keys, and then there's a root key that everybody knows. 246 00:14:22,040 --> 00:14:25,600 And so you have this chain of trust that establishes that you 247 00:14:25,600 --> 00:14:28,600 know this name was authorized by all the relevant authorities 248 00:14:28,600 --> 00:14:30,360 along the way down to your domain. 249 00:14:31,200 --> 00:14:35,480 And so the way we do DNS integration is you enable DNS 250 00:14:35,480 --> 00:14:39,880 set for your zone for your name. You sign it and then you set a 251 00:14:39,880 --> 00:14:43,680 text record saying, you know, I want the owner of this name on 252 00:14:43,680 --> 00:14:48,400 ENS to be 0X whatever address. And we're able to prove all of 253 00:14:48,400 --> 00:14:50,880 that on chain because it's all cryptographically signed. 254 00:14:50,880 --> 00:14:55,520 It uses, you know, either RSA or ECDSA, and we can verify the 255 00:14:55,520 --> 00:14:59,200 signatures on chain to then transfer ownership to you of the 256 00:14:59,600 --> 00:15:03,240 the record. The the one wrinkle here is an 257 00:15:03,240 --> 00:15:06,720 increasing number of DNS SEC implementations use ECDSA. 258 00:15:07,440 --> 00:15:11,120 And they use a curve that isn't the one Etherium uses, and so 259 00:15:11,120 --> 00:15:15,080 verifying it can be quite costly, you know, up to 260 00:15:15,080 --> 00:15:19,600 1,000,000 guests per per link. Basically there's a few 261 00:15:19,600 --> 00:15:21,960 approaches we're taking to to reduce that. 262 00:15:22,520 --> 00:15:26,520 One is there are now more efficient libraries that cost 263 00:15:26,520 --> 00:15:30,040 less gas. Another is there's an EIP out 264 00:15:30,040 --> 00:15:35,720 moment to add the SIP P256R1 curve to Etherium. 265 00:15:36,120 --> 00:15:38,920 Which was enabled not just efficient DNS SIC but a whole 266 00:15:38,920 --> 00:15:42,240 lot of other crypto primitives from sort of the real world 267 00:15:42,600 --> 00:15:44,360 because it's a very commonly used curve. 268 00:15:45,520 --> 00:15:48,520 And the final one is our effort on what we call guess list DNS 269 00:15:48,520 --> 00:15:51,120 SIC. Which is basically instead of 270 00:15:51,480 --> 00:15:54,160 verifying on chain and the transaction that you own the 271 00:15:54,160 --> 00:15:58,400 name at the time you update it, we move that to. 272 00:15:58,400 --> 00:16:02,400 When you try and resolve the name, you go and verify the DNS 273 00:16:02,440 --> 00:16:05,600 proofs at time. And we do that transparently to 274 00:16:05,600 --> 00:16:08,920 the client using our what's actually our L2 strategy equals 275 00:16:08,920 --> 00:16:13,120 CCIP read, which makes it possible for a client like 276 00:16:13,120 --> 00:16:17,200 Ethers to resolve the name and behind the scenes do the DNS 277 00:16:17,200 --> 00:16:19,520 verification without actually the client having to know 278 00:16:19,520 --> 00:16:22,920 anything about that. So yeah, that's a good 279 00:16:22,920 --> 00:16:25,720 transition I guess into the L2 strategy. 280 00:16:26,400 --> 00:16:30,400 So for now if I'm not mistaken I mean or or up until recently 281 00:16:30,400 --> 00:16:33,600 because I think ENS works now with with L twos but ENS was 282 00:16:33,600 --> 00:16:37,920 only compatible with layer one Etherium natively. 283 00:16:39,200 --> 00:16:42,680 Now there's there's a, there's a push to have ENS be compatible 284 00:16:42,680 --> 00:16:45,240 on Etherium L twos like optimism, arbitrary etcetera. 285 00:16:46,560 --> 00:16:49,200 Can you talk about what are the technical challenges there? 286 00:16:49,200 --> 00:16:53,000 Why has been, why has that been difficult and you know what's 287 00:16:53,000 --> 00:16:56,000 the technical implementation to to enable this? 288 00:16:56,920 --> 00:17:00,320 I think the the ultimate challenge is that E and ES is 289 00:17:00,320 --> 00:17:02,600 quite unlike a lot of other projects like if you have a 290 00:17:02,600 --> 00:17:06,319 token or you know you want to to bridge it to multiple networks, 291 00:17:06,319 --> 00:17:07,920 that's fine. You have a few here, a few 292 00:17:07,920 --> 00:17:10,160 there. If you have, you know, an 293 00:17:10,160 --> 00:17:13,880 exchange or some sort of D5 primitive, you can deploy it 294 00:17:13,880 --> 00:17:16,440 independently on each chain, and that's not a problem you you 295 00:17:16,440 --> 00:17:18,760 sort of have liquidity fragmentation, but you know 296 00:17:18,760 --> 00:17:22,000 that's tolerable. ENS is a little different 297 00:17:22,000 --> 00:17:25,680 because we have this global namespace, and so any deployment 298 00:17:25,680 --> 00:17:29,000 on other chains needs to have some sort of connection so that 299 00:17:29,000 --> 00:17:31,840 we know we won't issue the same name to different people in 300 00:17:31,840 --> 00:17:36,680 different places and so forth. And So what that ultimately 301 00:17:36,680 --> 00:17:41,360 means is that ENS will always be rooted on a theory ML one, but 302 00:17:41,600 --> 00:17:44,600 that doesn't preclude moving arbitrarily large parts of the 303 00:17:44,600 --> 00:17:48,560 tree off into. Different L twos and so forth. 304 00:17:48,640 --> 00:17:52,040 And that's the approach we've taken with our our solution 305 00:17:52,040 --> 00:17:56,120 which is called CCIP read and basically allows you to delegate 306 00:17:56,400 --> 00:18:00,200 entire parts of the ENS hierarchy to an L2 or even to a 307 00:18:00,200 --> 00:18:04,040 private database or you know anything you can verify on chain 308 00:18:04,040 --> 00:18:07,720 basically. And so if you for example own 309 00:18:07,720 --> 00:18:10,000 you know Wallet dot ETH and you want to issue sub domains to 310 00:18:10,000 --> 00:18:13,960 people, you can delegate Wallet dot ETH to the L2 of your 311 00:18:13,960 --> 00:18:18,080 choice, issue them on the L2. And people can resolve them 312 00:18:18,080 --> 00:18:21,160 transparently, without having to know which L2 it's on, and 313 00:18:21,160 --> 00:18:23,240 without any additional trust assumptions. 314 00:18:23,240 --> 00:18:26,440 Which seems outrageous, but it is possible. 315 00:18:27,400 --> 00:18:31,560 So could you describe this the CCIP read functionality? 316 00:18:31,560 --> 00:18:32,760 I've. I've heard about it, but I'm 317 00:18:32,760 --> 00:18:36,080 like not super in tune with how that works. 318 00:18:36,080 --> 00:18:39,360 And yeah. So the basic process of 319 00:18:39,360 --> 00:18:42,160 resolving an ENS name is that you call a smart contract. 320 00:18:42,160 --> 00:18:44,880 You know, grossly simplified, you call a smart contract you 321 00:18:44,880 --> 00:18:47,880 say what does NIT dot ETH resolve to and it returns 322 00:18:47,880 --> 00:18:52,920 resolve and that's all. 1L1 the extension with CCIP read is. 323 00:18:53,200 --> 00:18:56,200 You call the contract, you ask what it resolves to and it 324 00:18:56,200 --> 00:19:01,080 returns a revert error, basically saying I need more 325 00:19:01,080 --> 00:19:02,880 information to complete this request. 326 00:19:03,520 --> 00:19:06,520 And then more information is please go make an actually BE 327 00:19:06,520 --> 00:19:09,520 request to this endpoint with this data and then return it to 328 00:19:09,520 --> 00:19:11,920 me. And the client then goes off and 329 00:19:11,920 --> 00:19:15,720 transparently does that, you know as part of the contract 330 00:19:15,720 --> 00:19:19,600 call returns the data to the contract which then has an 331 00:19:19,600 --> 00:19:22,400 opportunity to verify that the data is actually correct. 332 00:19:22,800 --> 00:19:26,440 So how that works in practice is say your your data is stored on 333 00:19:26,440 --> 00:19:28,920 optimism. You try and resolve NEC dot ETH 334 00:19:28,920 --> 00:19:32,320 it goes, please consult the optimism gateway and give me 335 00:19:32,320 --> 00:19:36,000 back what it what it returns. The optimism gateway gives you 336 00:19:36,000 --> 00:19:39,240 then the resolution and NEC dot ETH along with all the Merkel 337 00:19:39,240 --> 00:19:42,120 proofs required to prove that that's part of the optimism 338 00:19:42,120 --> 00:19:44,880 state route. And then when you pass it back 339 00:19:44,880 --> 00:19:48,800 to the contract it verifies that the the proofs are correct and 340 00:19:48,800 --> 00:19:51,800 therefore that the the result is correct and returns it to you. 341 00:19:52,360 --> 00:19:55,200 And So what it looks like from a point of view of the clients, 342 00:19:55,200 --> 00:19:57,120 you know the the app using ethers. 343 00:19:57,440 --> 00:19:59,640 Is you just did a regular contract call and you got the 344 00:19:59,640 --> 00:20:03,680 data back and then we're building generic gateways and 345 00:20:03,680 --> 00:20:05,080 we're building libraries and so on. 346 00:20:05,080 --> 00:20:08,400 That mean when you're writing the L1 contract, it can be quite 347 00:20:08,400 --> 00:20:11,600 straightforward as well. It just says, you know, I depend 348 00:20:11,600 --> 00:20:15,560 on the storage slot from this chain and and then all the 349 00:20:15,560 --> 00:20:17,960 verification happens in libraries and so forth. 350 00:20:19,280 --> 00:20:23,120 So, so essentially the the contract is able to revert, say 351 00:20:23,120 --> 00:20:26,520 if it doesn't have the data it it tells the client I don't have 352 00:20:26,520 --> 00:20:30,360 the data. But here's an HTTP request that 353 00:20:30,360 --> 00:20:34,560 the client can independently make in order to to get the data 354 00:20:34,640 --> 00:20:39,240 essentially from a a centralized or like an an off chain source. 355 00:20:39,680 --> 00:20:42,880 That source returns the data with proofs that the data is in 356 00:20:42,880 --> 00:20:46,240 fact correct and then sends it back to the sends it back to the 357 00:20:46,240 --> 00:20:47,480 client. So. 358 00:20:47,480 --> 00:20:50,640 So there's a there's a liveness risk here, but there isn't 359 00:20:50,640 --> 00:20:54,000 necessarily like a there's no trust risk, right? 360 00:20:54,000 --> 00:20:55,240 OK. Yeah, exactly. 361 00:20:55,240 --> 00:20:59,400 And that's that's the thing because ultimately every roll up 362 00:20:59,400 --> 00:21:03,520 in order to be a roll up has to be able to prove things on L1. 363 00:21:04,400 --> 00:21:06,720 It means that the strategy works for any roll up. 364 00:21:06,720 --> 00:21:10,520 So you know, it's easiest for us with EVM based roll ups because 365 00:21:10,520 --> 00:21:13,840 we can just deploy the existing contracts we have. 366 00:21:13,840 --> 00:21:16,920 You know, with very few changes we need a bit of library code to 367 00:21:16,920 --> 00:21:20,720 deal with how that particular roll ups proves its state on the 368 00:21:20,720 --> 00:21:23,640 L1. But it could in principle. 369 00:21:23,640 --> 00:21:26,920 It can be used with any sort of L2, you know ZK proof ones as 370 00:21:26,920 --> 00:21:30,040 well as long as you just have some way to prove that a 371 00:21:30,040 --> 00:21:34,960 response from the roll up is is correct This particular like 372 00:21:36,040 --> 00:21:42,560 ENEIP, would it also allow reading from like IPFS or some 373 00:21:42,560 --> 00:21:46,880 decentralized storage source or would it only be off chain 374 00:21:46,880 --> 00:21:49,440 resources? It it absolutely does. 375 00:21:49,680 --> 00:21:52,640 And of course the trust model depends on the trust model of 376 00:21:52,640 --> 00:21:56,400 the thing you're reading from. So for instance, you could you 377 00:21:56,400 --> 00:21:59,760 could store a Merkel route in your, you know your contract on 378 00:21:59,760 --> 00:22:03,960 L1, and then your gateway could read data out of IPFS and return 379 00:22:04,000 --> 00:22:05,760 it. And the trust model there would 380 00:22:05,760 --> 00:22:08,520 be that you have to trust the route that was committed on L1. 381 00:22:09,560 --> 00:22:13,040 Equally it could return things from just a centralized database 382 00:22:13,040 --> 00:22:14,400 where all the records are signed. 383 00:22:14,840 --> 00:22:17,640 And the contract verifies the signature and then your trust 384 00:22:17,640 --> 00:22:22,360 model is of course the signer is is honest, OK, got it. 385 00:22:22,680 --> 00:22:26,680 And so with with regards to how L twos are using this, now 386 00:22:26,960 --> 00:22:32,040 practically speaking if you're if you've registered an ENS name 387 00:22:32,040 --> 00:22:38,000 on on Ethereum on on main net Ethereum, I mean typically with 388 00:22:38,720 --> 00:22:41,280 I mean I think there are some exceptions but the the, your, 389 00:22:41,280 --> 00:22:44,760 your address is the same on Ethereum as it is on L twos. 390 00:22:46,360 --> 00:22:48,720 Why, why does that correspondence simply not work? 391 00:22:48,720 --> 00:22:52,400 Why do you need like an extra layer in order to? 392 00:22:52,880 --> 00:22:55,040 I mean, couldn't you just like check with the theory and what 393 00:22:55,040 --> 00:22:58,800 the address is like with some kind of message passing rather 394 00:22:58,800 --> 00:23:05,120 than having the L2 needing to have its own namespace? 395 00:23:06,120 --> 00:23:08,880 So, yeah, so I guess there's a, there's a few issues here. 396 00:23:08,880 --> 00:23:12,160 One is of course that although EO as tend to share the same 397 00:23:12,160 --> 00:23:17,240 address across all chains, contract accounts don't and so 398 00:23:17,240 --> 00:23:19,640 we need to be able to handle that separately. 399 00:23:20,520 --> 00:23:24,200 But the the broader thing is that the the emphasis here is on 400 00:23:24,480 --> 00:23:27,520 providing the same level of security as L1 while reducing 401 00:23:27,520 --> 00:23:30,960 the transaction fees. So the reason the L TS are 402 00:23:30,960 --> 00:23:34,760 valuable here is it enables you to to not just update your own 403 00:23:34,760 --> 00:23:38,400 ENS name, but also potentially to issue sub domains and to do 404 00:23:38,400 --> 00:23:41,840 that trustlessly to third parties and so forth without 405 00:23:41,840 --> 00:23:44,320 having to engage in any transactions on our web. 406 00:23:44,560 --> 00:23:48,200 Which you know if your if your user is signing up to a wallet 407 00:23:48,200 --> 00:23:52,880 for the first time and it's it's 5 to $50 depending on guest fees 408 00:23:53,200 --> 00:23:55,680 to set up their name, they're going to be quite discouraged. 409 00:23:57,680 --> 00:23:58,920 Yeah, OK. Now that makes sense. 410 00:23:59,480 --> 00:24:02,640 And so then so then L twos, I mean practically speaking L twos 411 00:24:02,640 --> 00:24:09,800 have would have sort of a a like a an equivalent sub domain or 412 00:24:09,800 --> 00:24:12,760 are we talking about like a like if I'm if I'm set 3 point O dot 413 00:24:12,880 --> 00:24:15,800 ETH on Ethereum, would I also be set 3 point O dot ETH on 414 00:24:16,240 --> 00:24:19,480 optimism or whichever L2 I'm using? 415 00:24:19,880 --> 00:24:23,320 It's it's It's really up to you. We've got a sort of two 416 00:24:23,320 --> 00:24:25,080 orthogonal things here. One is. 417 00:24:25,520 --> 00:24:28,000 How your name resolves. And so you can have your name 418 00:24:28,000 --> 00:24:30,600 resolved to the same address for every chain ID, or it can 419 00:24:30,600 --> 00:24:32,760 resolve to a different address for each chain ID. 420 00:24:33,520 --> 00:24:35,760 And then there's where the records are actually stored. 421 00:24:36,080 --> 00:24:39,440 So you could store all your records on L1, but still in 422 00:24:39,440 --> 00:24:42,760 code, you know addresses for half a dozen different chains. 423 00:24:43,160 --> 00:24:48,160 Or you could store your records all on arbitrim, but you know 424 00:24:48,160 --> 00:24:50,560 all you ever return is an Ethereum L1 address. 425 00:24:50,560 --> 00:24:53,680 You know there's we've sort of separated the two so you can you 426 00:24:53,680 --> 00:24:55,120 can choose how that's divided up. 427 00:24:56,520 --> 00:24:57,640 OK. And what what are the 428 00:24:57,640 --> 00:25:02,040 complexities in terms of your wallets integrating this and 429 00:25:02,040 --> 00:25:08,400 having to resolve across like multiple L twos in order to 430 00:25:08,400 --> 00:25:11,120 avoid collisions? Yeah, this is one of the nice 431 00:25:11,120 --> 00:25:15,560 things about CCIP read approach is the wallets and the X and so 432 00:25:15,560 --> 00:25:17,760 forth. They don't have to be aware of 433 00:25:17,760 --> 00:25:19,720 all these different L twos. We don't have to update the 434 00:25:19,720 --> 00:25:22,640 resolution processes, you know, for each L2 we support. 435 00:25:23,160 --> 00:25:26,920 Because the CCIP read gateways as you observe, they they pose 436 00:25:26,920 --> 00:25:29,920 an availability risk, but there's no trust there and they 437 00:25:29,920 --> 00:25:34,080 take the job of translating the contracts requests into, you 438 00:25:34,080 --> 00:25:38,720 know, actual you know, if get proof calls or whatnot on the L2 439 00:25:38,720 --> 00:25:42,080 in question. And so clients and wallets 440 00:25:42,080 --> 00:25:45,120 simply need to implement a single unified DNS resolution 441 00:25:45,120 --> 00:25:49,520 process, and anyone can then permission lessly add new data 442 00:25:49,520 --> 00:25:54,840 storage mechanisms for ENS. OK, now I was reading about the 443 00:25:54,840 --> 00:26:00,880 ENS wrapper which is like a fairly new implementation that 444 00:26:00,920 --> 00:26:03,000 also is involved in the process of. 445 00:26:03,000 --> 00:26:05,720 Well from what I understand it that you know what the challenge 446 00:26:05,720 --> 00:26:08,920 was that ENS names were themselves NFTS but the 447 00:26:08,920 --> 00:26:12,920 subdomains were not right. The ENS wrapper now enables 448 00:26:13,680 --> 00:26:18,400 subdomains to also be NFTS and inherit properties from the, say 449 00:26:18,680 --> 00:26:21,840 not the top level but the the the main domain, right? 450 00:26:22,760 --> 00:26:25,440 How? How does that work and what is 451 00:26:25,440 --> 00:26:28,080 the role of the ENS wrapper with regards to L twos? 452 00:26:28,800 --> 00:26:34,480 Yeah, so so as you observed, like subdomains aren't ERC 741 453 00:26:34,480 --> 00:26:39,120 or 1155 NFTS because ENS actually launched before either 454 00:26:39,120 --> 00:26:43,640 of those standards existed. So while you can transfer around 455 00:26:43,640 --> 00:26:47,800 subdomains just like any other NFT, they they use their own 456 00:26:47,800 --> 00:26:51,320 interface for that. One of the things the name 457 00:26:51,320 --> 00:26:56,720 wrapper was was created to do was to, you know, improve that 458 00:26:56,720 --> 00:26:59,200 and and give a single unified interface to all names. 459 00:27:00,000 --> 00:27:05,160 But the essential thing that it's the F4 is that it makes it 460 00:27:05,160 --> 00:27:07,520 much easier to trustlessly issue subdomains. 461 00:27:07,960 --> 00:27:11,240 So it's always been possible to trustlessly issue subdomains, 462 00:27:11,240 --> 00:27:14,120 but it's required a bit of sort of smart contract engineering on 463 00:27:14,120 --> 00:27:16,880 the part of the owner of the name because. 464 00:27:17,600 --> 00:27:21,080 Ultimately, any any every name has control over all its 465 00:27:21,080 --> 00:27:24,160 subdomains. So if I own wallet dot ETH, I 466 00:27:24,160 --> 00:27:26,960 could I could issue you, you know, your name dot wallet dot 467 00:27:27,080 --> 00:27:29,920 ETH. But then I could take it back as 468 00:27:29,920 --> 00:27:32,280 any time. And if you want subdomains to 469 00:27:32,280 --> 00:27:34,960 actually be useful to people, then you need to have some way 470 00:27:34,960 --> 00:27:38,200 to credibly say I've revoked my permission to do that. 471 00:27:38,240 --> 00:27:40,920 And once I give you the name, you can feel assured that it 472 00:27:40,920 --> 00:27:44,000 will continue to be your name. And so that's what the wrapper 473 00:27:44,000 --> 00:27:45,720 provides. You can wrap a name. 474 00:27:46,320 --> 00:27:49,080 And then we have what we call fuses, which are a way of 475 00:27:49,440 --> 00:27:52,840 revoking your own permissions over a name so you can wrap it. 476 00:27:52,840 --> 00:27:56,760 And then you can burn the fuses to say you can't unwrap it. 477 00:27:57,080 --> 00:28:00,840 And to say that when you issue a sub domain you can't control it 478 00:28:00,840 --> 00:28:03,440 any further, only the sub domain or owner can. 479 00:28:04,360 --> 00:28:08,880 And so those permissions make it possible to to issue trustless 480 00:28:08,880 --> 00:28:12,440 sub domains and also to do that in a way that allows. 481 00:28:15,120 --> 00:28:19,040 That allows you to change how subdomains are issued and move 482 00:28:19,040 --> 00:28:21,760 to newer technology and so forth and upgrade your contracts 483 00:28:21,960 --> 00:28:24,640 without imposing any risk on the user that you'll use that 484 00:28:24,640 --> 00:28:27,120 opportunity to to reissue names and so forth. 485 00:28:28,120 --> 00:28:31,440 The way this combines with L2 is a bit further down the road map, 486 00:28:31,800 --> 00:28:35,640 but basically would would allow you to say well if you migrate a 487 00:28:35,640 --> 00:28:38,600 name to L1 then it gets all these same guarantees as a name 488 00:28:38,600 --> 00:28:42,400 wrapper. And while on L2 you can, there 489 00:28:42,400 --> 00:28:46,440 are other permissions you can burn to say you know I the the 490 00:28:46,440 --> 00:28:50,960 sub domains will always resolve using this CCIP read gateway or 491 00:28:50,960 --> 00:28:53,120 using this verifier for the gateway. 492 00:28:53,120 --> 00:28:57,200 So I can update the URL, but I can't change how it verifies and 493 00:28:57,200 --> 00:28:59,320 therefore it will always use optimism or whatnot. 494 00:29:01,080 --> 00:29:03,200 OK, what? What are some other applications 495 00:29:03,200 --> 00:29:07,400 of this CCIP read gateway other than the ENS? 496 00:29:08,400 --> 00:29:11,200 I mean you know there are broader implications in in E&E 497 00:29:11,200 --> 00:29:14,120 itself like the guest list DNS 6 stuff I implemented. 498 00:29:14,120 --> 00:29:16,800 You know we're effectively treating DNS like the L2. 499 00:29:17,720 --> 00:29:20,880 There are differently users outside that one of the the 500 00:29:20,920 --> 00:29:23,880 neater ones I've seen is around tokens. 501 00:29:23,880 --> 00:29:28,880 So for instance, your data Uri, could you know your data 502 00:29:28,880 --> 00:29:32,560 function to get metadata for a token could use CCIP read and 503 00:29:32,560 --> 00:29:36,080 therefore return sort of on chain data that's verified by 504 00:29:36,080 --> 00:29:38,960 the smart contract. But is actually hosted 505 00:29:38,960 --> 00:29:41,320 externally to save on guest fees for instance. 506 00:29:41,640 --> 00:29:44,960 Or in fact the very existence of the token could be sort of 507 00:29:44,960 --> 00:29:48,600 virtual and realized via these callbacks until such point as 508 00:29:48,600 --> 00:29:51,200 you claim it. So you could eardrop a bunch of 509 00:29:51,200 --> 00:29:54,800 entities to people with 0 on chain gas cost because they're 510 00:29:54,800 --> 00:29:57,600 only they only exist in the database until the person claims 511 00:29:57,600 --> 00:30:00,120 them right? Right. 512 00:30:00,120 --> 00:30:02,200 And then I guess the limitation is like, how long do you want to 513 00:30:02,200 --> 00:30:05,560 keep the database up for people to be able to claim them, right? 514 00:30:05,760 --> 00:30:09,760 I mean it just thinking about this, I mean are there could 515 00:30:09,760 --> 00:30:16,320 these off chain reads be used in lieu of of leveraging an on 516 00:30:16,320 --> 00:30:20,920 chain Oracle in some cases where the trust model allows it and 517 00:30:20,920 --> 00:30:25,800 are are some contracts using it? And and CCIP read calls can 518 00:30:25,800 --> 00:30:28,440 actually be used in transaction contexts as well. 519 00:30:28,440 --> 00:30:31,800 So you can use that data you get back from a call back to 520 00:30:31,800 --> 00:30:34,240 actually make a transaction, which effectively makes into a 521 00:30:34,240 --> 00:30:37,280 sort of a push Oracle rather than a a pull Oracle. 522 00:30:38,880 --> 00:30:41,760 Or perhaps I'm getting the two terms wrong way around. 523 00:30:41,760 --> 00:30:45,000 But in any case, you can fetch the data from the Oracle or from 524 00:30:45,000 --> 00:30:47,800 the external system and submit it at the time it's actually 525 00:30:47,800 --> 00:30:50,560 needed, rather than needing to, you know, have some system that 526 00:30:50,560 --> 00:30:54,600 regularly updates the theory in state, right? 527 00:30:54,600 --> 00:31:00,800 And would this also extend, I mean yeah, could you also use 528 00:31:00,800 --> 00:31:05,440 this with in complement with verifiable off chain 529 00:31:05,440 --> 00:31:11,040 computations where like a server is is performing a a computation 530 00:31:11,040 --> 00:31:16,960 right, maybe like with a AZKVM or like a wasm ZKVM or something 531 00:31:16,960 --> 00:31:19,000 like that right. And it's returning back. 532 00:31:20,360 --> 00:31:25,400 It's returning back of some some data with a proof. 533 00:31:27,360 --> 00:31:28,720 Is that? Is that also possible? 534 00:31:28,720 --> 00:31:30,840 Absolutely. As long as the proof can be 535 00:31:30,840 --> 00:31:33,680 verified inside the UVM, you can use it for it so. 536 00:31:34,120 --> 00:31:37,360 You know, we we talk about it as an L2 solution, but really it is 537 00:31:37,360 --> 00:31:41,040 a generic, you know, verifiable sort of potentially trustless 538 00:31:41,040 --> 00:31:45,440 off chain data fetching system. OK, well that's really 539 00:31:45,440 --> 00:31:47,520 interesting. This brings up like so many 540 00:31:47,520 --> 00:31:52,920 questions like what's the implication here, what's the 541 00:31:52,920 --> 00:32:02,440 broader implication of this of this, the CCIP read on just the 542 00:32:02,440 --> 00:32:09,760 necessity for yeah, on chain Oracle's off chain computation 543 00:32:09,760 --> 00:32:15,240 services And so this whole part of the stack that has built this 544 00:32:15,240 --> 00:32:18,560 business model on the ability to provide verifiable data to to 545 00:32:18,560 --> 00:32:22,520 chains. I think it's it's more a new 546 00:32:22,520 --> 00:32:25,720 technology and a new interface for doing that rather than it is 547 00:32:26,120 --> 00:32:28,680 removing the need for that. You know, we ultimately we still 548 00:32:28,680 --> 00:32:31,960 need that data from off chain. We still have the questions of 549 00:32:31,960 --> 00:32:34,280 like what degree of verifiability you can provide. 550 00:32:34,760 --> 00:32:37,760 And what this does is it provides an API where it's much 551 00:32:37,760 --> 00:32:39,960 more transparent and easier to integrate for apps. 552 00:32:40,880 --> 00:32:44,320 And it you know, it provides a situation where you can write 553 00:32:44,320 --> 00:32:47,840 apps that are actually using the soft chain data on demand 554 00:32:48,160 --> 00:32:51,120 without your app even having to know or care about that. 555 00:32:51,200 --> 00:32:55,040 So you know your, you know, claim of the AirDrop tokens 556 00:32:55,040 --> 00:32:58,520 could just look like a simple ERC 20 transfer function to the 557 00:32:58,520 --> 00:33:00,600 app. You know, you could claim your 558 00:33:00,600 --> 00:33:04,960 AirDrop just by transferring it, you know, into an account, but 559 00:33:04,960 --> 00:33:08,680 behind the scenes it's all using all of this, all of this 560 00:33:08,680 --> 00:33:10,880 infrastructure. So what it really does is just 561 00:33:11,360 --> 00:33:15,560 improve the developer experience and improve the ease of use of 562 00:33:15,560 --> 00:33:18,200 all of this. Very cool. 563 00:33:18,200 --> 00:33:20,160 Yeah. I'll have to spend a little bit 564 00:33:20,160 --> 00:33:23,320 more time researching this. Yeah, we're coming back to the L 565 00:33:23,320 --> 00:33:27,920 twos. You know of course I think you 566 00:33:27,920 --> 00:33:31,200 know when thinking about integrating ENS with Ethereum L 567 00:33:31,200 --> 00:33:35,520 twos, we're thinking about EVM L twos. 568 00:33:35,920 --> 00:33:42,040 But I think in the future we do expect to have non EVM L twos. 569 00:33:42,200 --> 00:33:48,160 I think with the growth of Eigen layer also we can expect a 570 00:33:48,160 --> 00:33:54,400 theorem security to be rented by non EVM platforms. 571 00:33:55,720 --> 00:33:59,520 What's the what are the implications here for ENS and 572 00:33:59,520 --> 00:34:02,520 making ENS compatible? And it sort of comes back to the 573 00:34:02,520 --> 00:34:04,680 first topic we were talking about earlier with you know this 574 00:34:04,680 --> 00:34:09,120 collision, so the multiple namespaces, what are some of the 575 00:34:09,120 --> 00:34:12,400 plans to make that possible? Let's say like someone wants to 576 00:34:12,400 --> 00:34:20,760 build a cosm wasm VM secured by a theory of security and bring 577 00:34:20,920 --> 00:34:24,360 ENS to to the to that to that, to that app. 578 00:34:25,800 --> 00:34:28,840 How would that be possible? You know, so in terms of the 579 00:34:28,840 --> 00:34:32,760 namespace, of course, all of this, you know, all of our 580 00:34:32,760 --> 00:34:36,440 efforts around CCIP Reader are pretty much they exist in order 581 00:34:36,440 --> 00:34:38,760 to ensure we have that one unified namespace. 582 00:34:39,199 --> 00:34:41,679 And so I've talked before about the importance of avoiding 583 00:34:41,679 --> 00:34:43,520 collisions or multiple registrations. 584 00:34:43,840 --> 00:34:47,560 But it's also equally about making sure that you can resolve 585 00:34:47,560 --> 00:34:50,360 names anywhere you know we shouldn't have a system where. 586 00:34:50,800 --> 00:34:54,480 You know an optimism where it can only resolve optimism based 587 00:34:54,480 --> 00:34:57,600 names and an Etherium or it can only resolve Etherium based 588 00:34:57,600 --> 00:35:01,480 names. And so you know with CCRP read 589 00:35:01,480 --> 00:35:05,080 we're able to provide that bridge and that bridge can be to 590 00:35:05,240 --> 00:35:08,320 to non EVML twos you know. Again, as long as you can verify 591 00:35:08,320 --> 00:35:11,960 the responses you can do it. What that looks like is a little 592 00:35:11,960 --> 00:35:15,680 more varied because of course non EVML twos have a much larger 593 00:35:15,680 --> 00:35:19,080 design space, so it's a matter of finding a way to. 594 00:35:19,640 --> 00:35:22,920 To build that out and and that will likely require you know L2 595 00:35:22,920 --> 00:35:26,520 specific engineering to build appropriate registries on the 596 00:35:26,520 --> 00:35:30,040 L2's and so forth. When it comes to resolution, 597 00:35:30,360 --> 00:35:33,680 ultimately it's still it starts at Etherium you know. 598 00:35:33,680 --> 00:35:40,840 So even if you're resolving a, you know ZK sync based name or a 599 00:35:40,840 --> 00:35:45,240 name that resolves to AZK sync identifier, you still start by 600 00:35:45,240 --> 00:35:47,880 the the look up process by by querying Etherium. 601 00:35:50,080 --> 00:35:51,520 OK. Yeah, it makes sense. 602 00:35:52,200 --> 00:35:57,000 And and are you know what's been the adoption of ENS, you know on 603 00:35:57,000 --> 00:36:01,120 on L twos, like which L twos are currently using it or do you 604 00:36:01,120 --> 00:36:04,200 expect we'll start start using ENS? 605 00:36:04,800 --> 00:36:08,080 So you know that because it's open and permission less, it's 606 00:36:08,080 --> 00:36:12,040 been a little bit, you know, we don't have a central database in 607 00:36:12,040 --> 00:36:14,320 that sense. So for instance, Coinbase 608 00:36:14,320 --> 00:36:18,560 started off on their own internal private database when 609 00:36:18,560 --> 00:36:23,840 they issued dot CB, dot ID names which all use CCIP read and they 610 00:36:23,840 --> 00:36:29,000 have since moved on to base. We've got a generic gateway that 611 00:36:29,000 --> 00:36:32,600 we've we've been building very recently which allows for very 612 00:36:32,600 --> 00:36:36,720 trivially building gateways to just about any L2 and we have 613 00:36:36,720 --> 00:36:40,840 stood up official gateways for optimism for that so far. 614 00:36:41,280 --> 00:36:43,760 But we're planning to expand that to Arbitron and to any 615 00:36:43,760 --> 00:36:49,040 other, you know, OP and R based L twos that pop up and you know 616 00:36:49,040 --> 00:36:51,560 from there to others because it's quite easy to add new 617 00:36:51,760 --> 00:36:53,400 verification mechanisms for them. 618 00:36:54,560 --> 00:36:59,320 Thus far, adoption outside like large integrations like Coinbase 619 00:36:59,640 --> 00:37:02,120 has been a little slow because most people don't have the 620 00:37:02,120 --> 00:37:06,320 resource to resources to build their own, you know, link. 621 00:37:06,640 --> 00:37:10,360 Your own gateway and so that's what our generic gateways are 622 00:37:10,360 --> 00:37:12,520 intended for this to make it much easier. 623 00:37:12,520 --> 00:37:16,360 So give us, you know, a quarter or so and you'll see people 624 00:37:16,600 --> 00:37:21,080 moving their names and their hosting to to L twos, you know 625 00:37:21,080 --> 00:37:25,080 easily through AUI 0 code, which is what we've been working on 626 00:37:25,080 --> 00:37:28,280 unlocking at the moment. Cool. 627 00:37:28,280 --> 00:37:29,880 Yeah. Well, let's, let's talk about 628 00:37:30,680 --> 00:37:34,920 about Coinbase a little bit. So I mean they recently 629 00:37:34,920 --> 00:37:41,320 announced the CB dot IDENS name that works across the Coinbase 630 00:37:41,320 --> 00:37:43,240 platform. Yeah. 631 00:37:43,280 --> 00:37:48,120 What what's the, how does that work and how how many new users 632 00:37:48,120 --> 00:37:51,480 have has ENS received from from that integration? 633 00:37:52,080 --> 00:37:55,480 It's it's hard to say because it's all off chain, but we know 634 00:37:55,480 --> 00:37:58,400 it's in the millions, you know, simply because they're 635 00:37:58,400 --> 00:38:00,000 onboarding their entire user base. 636 00:38:01,760 --> 00:38:06,320 CB dot ID is a great example of of both our DNS integration and 637 00:38:06,320 --> 00:38:08,680 our our off chain integration working together. 638 00:38:09,040 --> 00:38:12,720 You know CB dot ID is an ENS name even though it's also a DNS 639 00:38:12,720 --> 00:38:16,040 name and Coinbase simply imported at one time into ENS 640 00:38:16,080 --> 00:38:18,800 and then can treat it just the same as a dot ETH name. 641 00:38:19,200 --> 00:38:22,080 And the way they've they've used it then is to actually set it 642 00:38:22,080 --> 00:38:24,520 up. CCIP read initially. 643 00:38:24,520 --> 00:38:26,760 As I said, it sort of. You consulted their internal 644 00:38:26,760 --> 00:38:30,000 database for resolution. But they've they've since moved 645 00:38:30,000 --> 00:38:35,240 it to using data stored on base, understandably. 646 00:38:35,760 --> 00:38:38,720 Which means that they can provide. 647 00:38:39,040 --> 00:38:42,160 They can prove to you that you know you're the one in ultimate 648 00:38:42,160 --> 00:38:43,720 control of how your name results. 649 00:38:46,160 --> 00:38:50,440 Yeah, I haven't tried it yet, but I'll have to, I'll have to 650 00:38:50,440 --> 00:38:55,320 create my CB dot ID name. Yeah one of the one of the ways 651 00:38:55,320 --> 00:38:58,720 that I've been using ENS that I mean so you know I've got a 652 00:38:58,720 --> 00:39:02,000 couple of like ENS domains sort of for like my own my own 653 00:39:02,000 --> 00:39:03,720 personal use. But one of the ways that I've 654 00:39:03,720 --> 00:39:08,640 been using it that's been really really helpful and it's I mean 655 00:39:08,640 --> 00:39:13,680 it's very basic use case I guess but it's just naming all of all 656 00:39:13,680 --> 00:39:17,560 of the wallets that I use with like you know I've got this I've 657 00:39:17,560 --> 00:39:20,600 got this kind of like namespace like my own namespace that I've 658 00:39:20,600 --> 00:39:24,880 created and and you know the same way I guess that you would 659 00:39:24,880 --> 00:39:28,520 like name servers in your in your land or in you know your 660 00:39:28,520 --> 00:39:32,280 your your gateway. And so you know as a fund 661 00:39:32,280 --> 00:39:39,640 manager like we have several we have several noses safes and and 662 00:39:39,640 --> 00:39:41,760 and different addresses that we use and we've just like named 663 00:39:41,760 --> 00:39:44,440 every one of them and we know that like this is the address 664 00:39:44,440 --> 00:39:46,280 that we use for this and this is the address that we use for 665 00:39:46,280 --> 00:39:47,880 that. And that's made it very easy for 666 00:39:48,200 --> 00:39:51,520 for us to do capital calls with our LP's for example. 667 00:39:51,520 --> 00:39:54,000 We just like give them an ENS name and just verify that ENS 668 00:39:54,000 --> 00:39:57,760 name with them and stuff like in a an address and just you know 669 00:39:57,760 --> 00:39:59,760 when you're looking at your wallet, you just know, OK, like 670 00:39:59,760 --> 00:40:02,560 these are the names that I use and they're sort of like unique 671 00:40:02,560 --> 00:40:06,200 to me and I know what they are but but that's that's been a 672 00:40:06,200 --> 00:40:09,160 really cool use case. And you know couple that with 673 00:40:10,280 --> 00:40:15,680 the ability to like really easily buy ETH, ETH with a 674 00:40:15,680 --> 00:40:19,720 credit card on like any of these sort of like credit card, the 675 00:40:19,720 --> 00:40:22,600 service where you can buy ETH and you can basically like set 676 00:40:22,600 --> 00:40:25,840 up brand new addresses. That have never sort of touched 677 00:40:25,840 --> 00:40:28,480 the outside that have never been touched by your own personal 678 00:40:28,480 --> 00:40:32,800 addresses or sort of like quarantined right and and and to 679 00:40:32,800 --> 00:40:37,240 some extent shielded from your from your other identities 680 00:40:38,280 --> 00:40:40,000 because you can sort of put gas fees there. 681 00:40:40,280 --> 00:40:43,000 So we've we've been using that quite extensively to like set up 682 00:40:43,320 --> 00:40:46,080 you know an array of addresses that we that we use that we 683 00:40:46,080 --> 00:40:48,560 don't want to like be connected with our own personal identity. 684 00:40:48,560 --> 00:40:52,240 So I found that really like a great, great use case and 685 00:40:52,360 --> 00:40:55,200 something that we've been implementing at the fund. 686 00:40:56,960 --> 00:40:59,320 Yeah, I think that's that's absolutely the right way to 687 00:40:59,320 --> 00:41:01,920 handle it. And to treat on chain privacy 688 00:41:02,280 --> 00:41:06,920 like the connection between on chain privacy and naming comes 689 00:41:06,920 --> 00:41:09,640 up a lot. And the thing I always emphasize 690 00:41:09,640 --> 00:41:14,840 is that, you know, not naming your accounts is security sort 691 00:41:14,840 --> 00:41:18,560 of security. It seems harder to track, but in 692 00:41:18,560 --> 00:41:21,640 reality a determined person can certainly, you know, figure out 693 00:41:21,640 --> 00:41:23,320 which accounts are yours and so forth. 694 00:41:23,840 --> 00:41:26,600 The EE NES doesn't solve the problem that nor does it 'cause 695 00:41:26,600 --> 00:41:29,560 it, you know, the IT sort of makes it more obvious both to 696 00:41:29,560 --> 00:41:33,160 you and to others. You know what the account is 697 00:41:33,160 --> 00:41:35,960 for, and nine times out of 10 that's a benefit. 698 00:41:35,960 --> 00:41:38,440 And when it's not, you need to follow processes like you 699 00:41:38,440 --> 00:41:41,920 describe and make sure that the accounts you want to be separate 700 00:41:41,920 --> 00:41:44,440 are actually, you know, held separately and and set up 701 00:41:44,440 --> 00:41:47,000 separately. Yeah, yeah. 702 00:41:47,000 --> 00:41:49,240 It was a bit of a like we had to implement sort of a process to 703 00:41:49,240 --> 00:41:52,480 do it because like I messed up a few right, where it's like OK, 704 00:41:52,480 --> 00:41:53,720 I'm going to send some ETH over here. 705 00:41:54,160 --> 00:41:55,880 No, like I wasn't supposed to do that. 706 00:41:56,120 --> 00:41:59,640 So it is also about having like having good offset processes 707 00:41:59,640 --> 00:42:02,800 internally to make sure that like those things don't don't 708 00:42:02,800 --> 00:42:06,160 touch. But yeah, I was, I was chatting 709 00:42:06,160 --> 00:42:09,520 with a guy in in in Istanbul a couple of weeks ago. 710 00:42:09,520 --> 00:42:14,480 We were there for Cosmo virus and he was building this, this 711 00:42:15,560 --> 00:42:18,240 this site called 0X PPL, right, 0X people. 712 00:42:18,240 --> 00:42:21,480 I don't know if you've heard of it and it's sort of one of these 713 00:42:21,480 --> 00:42:28,440 like D bank type services but with really in depth sort of 714 00:42:28,440 --> 00:42:31,920 data on interactions between between addresses. 715 00:42:31,920 --> 00:42:34,840 So you you sort of like go to 1 address and then you you have 716 00:42:34,840 --> 00:42:38,600 this this hub and spoke thing that shows you all the other 717 00:42:38,600 --> 00:42:40,040 addresses that it's interacted with. 718 00:42:40,440 --> 00:42:45,120 And you know, I I think I'm fairly good with my security and 719 00:42:45,120 --> 00:42:47,320 my off SEC. But then you know in in in a 720 00:42:47,320 --> 00:42:50,600 couple of clicks he showed me that I had not, you know, 721 00:42:50,840 --> 00:42:53,360 properly implemented this process and like these two 722 00:42:53,360 --> 00:42:56,120 addresses that I thought were not linked together had been 723 00:42:56,120 --> 00:42:59,720 linked together somehow including like payments to to 724 00:42:59,720 --> 00:43:02,800 other folks. And so you know talking about 725 00:43:02,800 --> 00:43:06,120 privacy like you know one of the other things about this, this 726 00:43:06,120 --> 00:43:08,840 service is that now you know they're integrating and I'm sure 727 00:43:08,840 --> 00:43:11,680 all of the big sort of like chain analysis and sort of 728 00:43:11,720 --> 00:43:13,720 competitors to chain analysis are doing the same thing as 729 00:43:13,720 --> 00:43:17,320 implementing large language models to decipher connections 730 00:43:17,320 --> 00:43:19,600 between addresses. And and this is what they were 731 00:43:19,600 --> 00:43:22,520 doing right, where you can just say OK, what are the addresses 732 00:43:22,520 --> 00:43:26,680 that this particular address has been have been have interacted 733 00:43:26,680 --> 00:43:31,320 with or you know which address which Ethereum addresses were 734 00:43:31,320 --> 00:43:35,880 participate participated in the in the cosmos token sale for 735 00:43:35,880 --> 00:43:37,280 instance. You know, like you could sort of 736 00:43:37,280 --> 00:43:41,280 push it to that extent. Like have you thought about 737 00:43:41,280 --> 00:43:44,040 large language models and how they conflict with the idea for 738 00:43:44,040 --> 00:43:46,920 on chain privacy? And what are some of the best 739 00:43:46,920 --> 00:43:51,040 practices that we can employ now as users of Ethereum where 740 00:43:51,080 --> 00:43:54,280 Ethereum doesn't have effective privacy on chain and what what 741 00:43:54,280 --> 00:43:57,480 is your hope that will you know at some point get to full on 742 00:43:57,480 --> 00:44:00,800 chain privacy? Yeah, I think, you know large 743 00:44:00,800 --> 00:44:04,320 language models much like E&E sort of expose the assumptions 744 00:44:04,320 --> 00:44:06,000 that we make. You know, they're, they 745 00:44:06,360 --> 00:44:11,360 democratize access to the sort of functionality, but ultimately 746 00:44:11,360 --> 00:44:13,560 aren't providing you anything that wasn't already. 747 00:44:14,040 --> 00:44:18,280 You know they're on chain. The solution I think is better 748 00:44:18,280 --> 00:44:22,480 base layer privacy primitives. The unfortunate thing is that, 749 00:44:22,480 --> 00:44:24,960 you know, politically these things are contentious at the 750 00:44:24,960 --> 00:44:27,040 moment. I don't think it's an 751 00:44:27,040 --> 00:44:30,800 unreasonable ask that not everybody can read my entire 752 00:44:30,800 --> 00:44:34,280 transaction history and see, you know everything I do. 753 00:44:35,120 --> 00:44:37,760 And I think if you went to most people in the real world and 754 00:44:37,760 --> 00:44:40,920 said, hey, can I see your bank statement, they would react with 755 00:44:40,920 --> 00:44:43,640 alarm. But somehow when it happens on 756 00:44:43,640 --> 00:44:46,200 chain, that's seen as as illegitimate. 757 00:44:47,160 --> 00:44:49,840 And so I think a lot of it is we have to sort of fight that 758 00:44:49,840 --> 00:44:53,200 perception that a desire for financial privacy is somehow, 759 00:44:53,960 --> 00:44:58,600 you know, scurrilous before we can we can see widespread 760 00:44:58,600 --> 00:45:00,800 deployment of some of these these primitives. 761 00:45:02,120 --> 00:45:05,200 It's a. It's a good connection though to 762 00:45:05,200 --> 00:45:07,240 like a history of like using encryption. 763 00:45:07,640 --> 00:45:10,840 In that when it becomes the norm, it also becomes less of a 764 00:45:10,840 --> 00:45:13,960 target. So you know, nobody blinks that 765 00:45:13,960 --> 00:45:17,280 you use SSL for every single website now, but if you only use 766 00:45:17,280 --> 00:45:20,680 them to watch porn or or load the money then it would be a a 767 00:45:20,680 --> 00:45:24,960 sign of suspicion. Likewise, you know, chains like 768 00:45:25,880 --> 00:45:29,360 Z Cash, you know, seem to be treated with less intrinsic 769 00:45:29,360 --> 00:45:33,800 suspicion than mixes like Tornado cash, simply because 770 00:45:33,840 --> 00:45:37,040 privacy is the default. So I think we, we need better 771 00:45:37,040 --> 00:45:39,600 premises and we also need to sort of enshrine them and make 772 00:45:39,600 --> 00:45:42,800 them the thing that's used to it as much of the time as is 773 00:45:42,800 --> 00:45:45,760 practical rather than just an exceptional circumstances. 774 00:45:47,480 --> 00:45:50,920 Yeah, I mean I agree with you that like politically this this 775 00:45:50,920 --> 00:45:55,320 is very contentious. But I mean, ultimately my, my 776 00:45:55,360 --> 00:45:59,960 view on privacy is that it is an essential component of just the 777 00:45:59,960 --> 00:46:02,960 idea of, you know, just the idea of capitalism, right? 778 00:46:02,960 --> 00:46:06,440 Like capitalism is able to, I can't remember who said this, 779 00:46:06,440 --> 00:46:11,160 but like capitalism exists or is able to function because we had 780 00:46:11,160 --> 00:46:13,480 asymmetry of information, right? And so there's this like 781 00:46:13,480 --> 00:46:17,520 information arbitrage between between market players and 782 00:46:17,520 --> 00:46:21,640 having like full transparency over everyone's everyone's 783 00:46:21,640 --> 00:46:25,200 transaction history everyone's business dealings etcetera with 784 00:46:25,200 --> 00:46:27,240 with whom everybody interacts economically. 785 00:46:27,840 --> 00:46:31,640 If actually sort of like breaks down that a that information 786 00:46:31,640 --> 00:46:34,440 asymmetry and we end up in something closer to what I guess 787 00:46:34,440 --> 00:46:39,360 like communism right. What's the what's the hope do 788 00:46:39,360 --> 00:46:44,920 you think that that you know within the next 10 years we have 789 00:46:45,360 --> 00:46:49,640 you know better on chain privacy or like absolute on chain 790 00:46:49,640 --> 00:46:53,000 privacy would be I guess like the you know the the desirable 791 00:46:53,000 --> 00:46:59,760 outcome or or you you think that this is a pipe dream that will 792 00:46:59,760 --> 00:47:02,840 will never happen. I think it's it's difficult and 793 00:47:02,840 --> 00:47:06,680 it's particularly difficult inside like an EVM based L2 or 794 00:47:06,680 --> 00:47:10,840 an EVM based network because the system simply isn't built with 795 00:47:10,840 --> 00:47:13,400 it in mind. So I think if we see it, it will 796 00:47:13,400 --> 00:47:17,440 be through L twos that use you know, systems similar to ZK. 797 00:47:17,440 --> 00:47:21,280 Sure ZK sync you know, becoming widespread and becoming the 798 00:47:21,280 --> 00:47:24,280 default transaction thing. And I don't think that's 799 00:47:24,280 --> 00:47:27,320 necessarily a bad thing. You know, as Etherium becomes a 800 00:47:27,320 --> 00:47:30,120 sort of a clearing network and I don't think it's a problem that, 801 00:47:30,520 --> 00:47:32,760 you know, clearing network transactions are public. 802 00:47:33,760 --> 00:47:36,280 You know, in the same way that I would love to see more more 803 00:47:36,280 --> 00:47:39,200 transparency into the operation of like, you know, central banks 804 00:47:39,200 --> 00:47:41,640 and so forth, there's financial privacy. 805 00:47:41,640 --> 00:47:45,560 Most benefits individuals and companies not, you know, banks 806 00:47:45,560 --> 00:47:50,080 and and governments. I don't know how practical this 807 00:47:50,080 --> 00:47:50,920 is. It's. 808 00:47:51,320 --> 00:47:53,240 You know, aside from the political thing, it's a large 809 00:47:53,240 --> 00:47:57,800 technical challenge and having both financial privacy, you 810 00:47:57,800 --> 00:48:01,840 know, and and shielded transactions and also being able 811 00:48:01,840 --> 00:48:05,800 to engage in like arbitrary, you know, smart contracts is a 812 00:48:05,800 --> 00:48:10,240 really tough problem to solve. So I guess I would say I don't 813 00:48:10,240 --> 00:48:12,920 think we'll have it 10 years from now, but I think we might 814 00:48:12,920 --> 00:48:17,280 have moved the needle more of the direction of making privacy 815 00:48:17,280 --> 00:48:20,800 in the north and making it easier to to shield your. 816 00:48:21,480 --> 00:48:26,240 You know your assets and your transactions, Yeah, yeah. 817 00:48:26,240 --> 00:48:30,080 I mean, in the context of, you know, if we think about account 818 00:48:30,080 --> 00:48:33,560 abstraction and you're thinking more broadly about like 819 00:48:33,560 --> 00:48:39,880 decentralized identities and how identities are formed through 820 00:48:39,960 --> 00:48:43,320 these, you know, links to other forms of identity, right? 821 00:48:43,320 --> 00:48:49,800 So like you know currently if you want to add some weight to 822 00:48:49,800 --> 00:48:52,920 your ENS identity, you can you can attach your Twitter identity 823 00:48:52,920 --> 00:48:57,400 to to your ENS or you know key base has this model also where 824 00:48:58,080 --> 00:49:02,080 you'll attest to your ownership of other pieces of identity in 825 00:49:02,080 --> 00:49:05,280 order to bring more weight to you know your key base identity. 826 00:49:05,600 --> 00:49:09,720 It's a shame that key base is no longer really a viable product 827 00:49:09,720 --> 00:49:12,320 to use. But you know, how do you think 828 00:49:12,320 --> 00:49:17,960 about the role of account abstraction in in forming like a 829 00:49:17,960 --> 00:49:22,520 real decentralized identity in the form of ENS and perhaps also 830 00:49:22,520 --> 00:49:25,640 adding some layers of privacy there, since we can rotate keys 831 00:49:25,640 --> 00:49:33,040 and and and that can be used in the word in a way to to abstract 832 00:49:33,040 --> 00:49:35,920 away the ultimate beneficiary of an of an identity. 833 00:49:37,200 --> 00:49:41,080 I think account abstraction in some form is going to be fairly 834 00:49:41,080 --> 00:49:44,840 essential to to more widespread adoption as as a theory and end 835 00:49:44,840 --> 00:49:46,960 of. You know crypto in general 836 00:49:47,240 --> 00:49:51,080 because of the usability benefits it brings and and one 837 00:49:51,080 --> 00:49:54,320 of the pleasant side effects of that is that it's easier to then 838 00:49:54,320 --> 00:49:57,400 implement things like bit of financial privacy and so forth. 839 00:49:59,040 --> 00:50:04,400 Yeah, maybe maybe give an overview of you know what are 840 00:50:04,400 --> 00:50:09,520 the what are the advancements in account abstraction and and the 841 00:50:09,520 --> 00:50:12,320 use of account abstraction with DNS on Etherium. 842 00:50:14,160 --> 00:50:17,600 I think. I mean you know I I don't follow 843 00:50:17,640 --> 00:50:20,560 the area of research in as much detail as I I maybe should. 844 00:50:20,560 --> 00:50:23,680 But you know to my awareness there's sort of two general 845 00:50:23,680 --> 00:50:25,640 approaches. One is that we can enshrine and 846 00:50:25,720 --> 00:50:30,520 account abstraction in the the base layer in the EVM with 847 00:50:30,520 --> 00:50:33,480 things like off call and so on, which basically allow you to 848 00:50:33,480 --> 00:50:38,760 treat a a special contract account like an EOA and transact 849 00:50:38,760 --> 00:50:41,880 from it. And that provides, you know sort 850 00:50:41,880 --> 00:50:45,720 of a more direct way to do things and it also sidesteps, 851 00:50:45,720 --> 00:50:48,160 you know, a bunch of difficulties around, you know, 852 00:50:48,400 --> 00:50:50,360 gas and transaction fees and so forth. 853 00:50:52,480 --> 00:50:56,200 Things like that are promising, but large changes to the EVM 854 00:50:56,200 --> 00:50:59,840 tend to take a while and it's all too easy to have unintended 855 00:50:59,840 --> 00:51:01,800 side effects. You know and hence the the 856 00:51:01,800 --> 00:51:05,320 understandable caution and implementing them you know the 857 00:51:05,320 --> 00:51:09,120 2nd way is through. You know, authorizations 858 00:51:09,120 --> 00:51:12,240 through, you know, meta transactions and so forth, where 859 00:51:12,240 --> 00:51:16,080 all of this happens in the abstract, so you know in the in 860 00:51:16,080 --> 00:51:19,160 the user layer. That's much more practical and 861 00:51:19,160 --> 00:51:22,200 it's happening now. But also the user experience 862 00:51:22,200 --> 00:51:25,160 tends to be a bit worse. And it's a bit, there's a lot 863 00:51:25,160 --> 00:51:28,720 more infrastructure to set up, you know, So your user there has 864 00:51:28,720 --> 00:51:31,280 to sign a message and serve a transaction that then has to be 865 00:51:31,280 --> 00:51:34,600 sent to some sort of relayer. The relayer has to handle, you 866 00:51:34,600 --> 00:51:37,000 know, how to pay guest fees and how to be reimbursed. 867 00:51:37,320 --> 00:51:40,120 And then either the user or the platform has to somehow, you 868 00:51:40,120 --> 00:51:44,520 know, translate you know the right amount of funds into to 869 00:51:44,520 --> 00:51:46,360 pay the guest fees. And it all gets very 870 00:51:46,360 --> 00:51:50,560 complicated, but we can implement it, you know, as we 871 00:51:50,560 --> 00:51:52,840 wish without waiting for everyone to be in agreement. 872 00:51:53,800 --> 00:51:56,600 In either case, you know, E&E sort of continues to function 873 00:51:56,600 --> 00:51:58,400 the same way. You know, we we can name 874 00:51:58,400 --> 00:52:02,320 contract accounts just the same as naming externally owned 875 00:52:02,320 --> 00:52:05,320 accounts. You can transact from them just 876 00:52:05,320 --> 00:52:07,040 fine. You know, there's nothing sort 877 00:52:07,040 --> 00:52:10,200 of intrinsically linked to ENS, to to external accounts. 878 00:52:10,200 --> 00:52:13,320 So fortunately we we work with account abstraction really well. 879 00:52:13,760 --> 00:52:16,640 And, you know, being able to name those accounts can also 880 00:52:17,200 --> 00:52:19,880 improve the UX a lot, and you end up with more of them to keep 881 00:52:19,880 --> 00:52:22,120 track of than you might otherwise. 882 00:52:23,240 --> 00:52:26,800 Yeah I saw the the the comest team has a really nice 883 00:52:26,800 --> 00:52:29,840 implementation of of account abstraction in in their in their 884 00:52:29,840 --> 00:52:32,840 game. And yeah it's like it's it's 885 00:52:32,840 --> 00:52:34,400 great how just how well it works. 886 00:52:34,400 --> 00:52:39,400 You just do, you open the app, it creates, it creates a wallet. 887 00:52:39,400 --> 00:52:43,360 You connect that wallet to say like a passkey and and then you 888 00:52:43,360 --> 00:52:46,520 know further on as you sort of add assets to that wallet, it 889 00:52:46,520 --> 00:52:49,800 might ask you to like connected to different forms of identity 890 00:52:49,800 --> 00:52:52,840 or or different signing mechanisms. 891 00:52:53,200 --> 00:52:56,360 And yeah, the onboarding experiences is pretty incredible 892 00:52:56,600 --> 00:53:00,480 and in terms of enshrinement may be an interesting sort of 893 00:53:00,480 --> 00:53:06,120 examples to look towards this is osmosis on on from Cosmos. 894 00:53:06,480 --> 00:53:08,840 So they're they're building a counter abstraction into the 895 00:53:08,840 --> 00:53:10,880 protocol. Now of course for for us most 896 00:53:10,880 --> 00:53:12,520 it's different, right, because they're an app chain, they can 897 00:53:12,520 --> 00:53:14,240 sort of like control the entire stack. 898 00:53:14,960 --> 00:53:21,360 But like a month ago they demoed this this really sort of nice 899 00:53:21,360 --> 00:53:24,600 way to build a counter abstraction where existing 900 00:53:24,600 --> 00:53:28,400 addresses, existing EOA addresses could be turned into 901 00:53:30,840 --> 00:53:34,240 abstracted accounts. And then you can effectively 902 00:53:34,240 --> 00:53:36,520 like connect different pass keys, Twitter accounts or like 903 00:53:36,520 --> 00:53:39,760 any O off in in order to to sign. 904 00:53:39,760 --> 00:53:44,360 And then also have different signing mechanisms based on the 905 00:53:44,360 --> 00:53:47,080 types of transactions that you're participate that you're 906 00:53:47,080 --> 00:53:49,560 that you're issuing, right. So if it's like a a swap 907 00:53:49,560 --> 00:53:54,040 transaction or like a send token transaction, you may need like a 908 00:53:54,040 --> 00:53:55,560 certain amount of keys to do that. 909 00:53:56,040 --> 00:53:58,080 However, if you're just like voting on a government's 910 00:53:58,080 --> 00:54:01,120 proposal or performing some other action that doesn't 911 00:54:01,400 --> 00:54:04,440 involve transferring funds, you might be able to do that with 912 00:54:04,440 --> 00:54:07,440 like you know your your Twitter login or your Google login or 913 00:54:07,440 --> 00:54:09,280 something like that. So like having also permissions 914 00:54:09,440 --> 00:54:11,720 built in, the protocol is really nice and I mean that's one of 915 00:54:11,720 --> 00:54:13,680 the benefits of having an app chain I guess is that you can 916 00:54:13,680 --> 00:54:17,280 sort of you know you can, you can have total control over 917 00:54:17,280 --> 00:54:18,640 that. But I understand it like for 918 00:54:18,640 --> 00:54:20,600 something Ethereum, it's much, it's much more difficult to 919 00:54:20,600 --> 00:54:22,880 enshrine that into the protocol where you know there's so many 920 00:54:22,880 --> 00:54:25,760 applications and sort of L twos depending on that that base 921 00:54:25,760 --> 00:54:27,480 layer. So it's it's it's an interesting 922 00:54:27,480 --> 00:54:29,040 challenge to have to deal with, of course. 923 00:54:30,120 --> 00:54:32,600 It's interesting you bring that up because you just reminded me 924 00:54:32,600 --> 00:54:34,400 that. So a couple of years ago I 925 00:54:34,400 --> 00:54:37,640 proposed in the IP that would implement something very 926 00:54:37,640 --> 00:54:40,360 similar. Never got much traction 927 00:54:40,360 --> 00:54:42,680 unfortunately. But the basic insight is what if 928 00:54:42,680 --> 00:54:44,600 you could? What if an EOA could delegate 929 00:54:44,600 --> 00:54:47,200 call so? You would have a special 930 00:54:47,200 --> 00:54:51,000 transaction type that instead of just calling a train, a contract 931 00:54:51,240 --> 00:54:54,280 delegate calls it and therefore it executes as the EOA. 932 00:54:54,640 --> 00:54:57,640 And in principle, this would require a fairly minimal set of 933 00:54:57,640 --> 00:55:00,280 changes to the EVM because all of that infrastructure, all of 934 00:55:00,280 --> 00:55:02,320 that, that mechanism is already in place. 935 00:55:02,880 --> 00:55:04,760 Unfortunately, you didn't get a lot of traction. 936 00:55:04,760 --> 00:55:07,480 There are a couple of odd each cases around that but I think it 937 00:55:07,480 --> 00:55:11,280 would be tractable and you know potentially provide a much 938 00:55:11,280 --> 00:55:13,560 simpler mechanism than some of the other ones that have been 939 00:55:13,560 --> 00:55:18,040 proposed. Yeah yeah I'm I'm I'm really 940 00:55:18,040 --> 00:55:22,440 looking forward to seeing like a counter attraction come come to 941 00:55:22,440 --> 00:55:25,920 Ethereum in in more tangible ways and yeah I think we'll get 942 00:55:25,920 --> 00:55:29,680 there eventually right. There's already some some some 943 00:55:29,680 --> 00:55:35,160 implementations of it. So yeah maybe looking to looking 944 00:55:35,160 --> 00:55:38,360 to the future of ENS and reflecting in the last six 945 00:55:38,360 --> 00:55:41,800 years. So I think it's, I think it's 946 00:55:41,800 --> 00:55:47,440 safe to say that ENS is one of the like largest or if not the 947 00:55:47,440 --> 00:55:52,680 largest Dow in Etherium also generating revenue, right. 948 00:55:52,680 --> 00:55:57,080 There was this one day earlier this year where ENS generated 949 00:55:57,080 --> 00:56:03,720 like upwards of $235,000 in in domain fees in a day, you know 950 00:56:03,720 --> 00:56:06,240 millions. I think it's two 2.4 million 951 00:56:06,240 --> 00:56:09,640 addresses active ENS names. Yeah. 952 00:56:09,640 --> 00:56:11,680 What do you, what do you think of all this? 953 00:56:11,680 --> 00:56:14,120 And, you know, how do you reflect on like the last six 954 00:56:14,120 --> 00:56:18,120 years to today? It's certainly been a journey. 955 00:56:19,160 --> 00:56:22,880 We always intended to to decentralize ENS over time. 956 00:56:23,200 --> 00:56:28,880 When we launched was we launched not long after the the Dow And 957 00:56:28,880 --> 00:56:32,440 so we weren't exactly keen to be like, hey, let's launch and 958 00:56:32,440 --> 00:56:34,640 straight away launch a Dow and it'll be fine. 959 00:56:35,240 --> 00:56:37,680 You know, we wanted to actually see governance permissions 960 00:56:37,680 --> 00:56:40,160 mature and demonstrate their effectiveness first. 961 00:56:40,840 --> 00:56:43,240 But that absolutely happened and you know two years ago we 962 00:56:43,240 --> 00:56:48,000 launched the Dow and the E&S Dow and you're right, it's it's 963 00:56:48,000 --> 00:56:50,800 been, it's one of the largest you know by participation that's 964 00:56:50,800 --> 00:56:54,800 got ongoing revenue, it's you know ongoing participation as 965 00:56:54,800 --> 00:56:56,320 well. And I think it's been very 966 00:56:56,320 --> 00:56:58,280 effective as administering the protocol. 967 00:57:00,520 --> 00:57:04,280 I think the the revenue is an essential part of us the, you 968 00:57:04,280 --> 00:57:08,440 know the fees were for E&S names are set. 969 00:57:08,840 --> 00:57:11,160 To regulate the system rather than directly to bring in 970 00:57:11,160 --> 00:57:13,760 income. You know, the idea is if names 971 00:57:13,760 --> 00:57:16,280 are free to register, then they'd all be registered and the 972 00:57:16,280 --> 00:57:19,480 only way to get them would be to try and, you know, pay enough to 973 00:57:19,480 --> 00:57:21,240 the person who jumped on it first. 974 00:57:21,600 --> 00:57:25,040 And so we want to see that balance where it's possible to 975 00:57:25,040 --> 00:57:27,920 find a name that you know, represents what we want it to, 976 00:57:28,800 --> 00:57:32,120 you know, directly and easily and in a sort of a liquid 977 00:57:32,120 --> 00:57:34,960 fashion, rather than having the entire system squatted on 978 00:57:35,000 --> 00:57:36,400 immediately. You know, I've seen. 979 00:57:36,920 --> 00:57:40,360 That sort of behavior left uncontrolled has, you know, 980 00:57:40,360 --> 00:57:44,080 strangled ecosystems like main coin and other early attempts. 981 00:57:45,640 --> 00:57:48,400 But a very pleasant side effect of that is of course it 982 00:57:48,400 --> 00:57:51,560 generates funding which can help, you know, continue to pay 983 00:57:51,560 --> 00:57:53,240 for E&S development and so forth. 984 00:57:53,640 --> 00:57:58,040 And I think the fact that E&S has revenue that it can actually 985 00:57:58,040 --> 00:58:00,520 use to continue to pay for development. 986 00:58:01,040 --> 00:58:03,760 It's meant that we haven't had to you know look for venture 987 00:58:03,760 --> 00:58:06,960 capital funding which has now allowed us to stay truer to our 988 00:58:07,200 --> 00:58:09,440 our open source and public good roots. 989 00:58:10,440 --> 00:58:14,720 It's enabled us to help fund other projects in the ecosystem 990 00:58:14,720 --> 00:58:19,480 and you know and relating to EMS as well and it's it really 991 00:58:19,480 --> 00:58:21,440 provides us with like a stable future. 992 00:58:21,480 --> 00:58:24,520 So you know we've put a 50 million odd of the. 993 00:58:25,160 --> 00:58:28,000 The amount that's been raised into an endowment and its sole 994 00:58:28,000 --> 00:58:33,680 goal is to to grow stably and and safely over time so that E&S 995 00:58:33,680 --> 00:58:37,240 will remain a stable operating system for the next 100 years or 996 00:58:37,240 --> 00:58:40,480 more, You know, independent of what happens to revenue. 997 00:58:40,480 --> 00:58:43,600 Because we also don't want to have to make decisions of, well, 998 00:58:43,600 --> 00:58:47,280 it would be better for the ecosystem if this fee went away 999 00:58:47,280 --> 00:58:49,000 because it no longer serves its purpose. 1000 00:58:49,440 --> 00:58:51,600 But we need it in order to fund operations. 1001 00:58:51,600 --> 00:58:54,880 So it has to stay, you know. So our ultimate goal was to be 1002 00:58:54,880 --> 00:58:57,240 able to make those decisions independently of each other. 1003 00:58:57,480 --> 00:59:00,080 And things like the endowment, you know, work to make that 1004 00:59:00,080 --> 00:59:03,320 possible. So I guess the thing I I like 1005 00:59:03,320 --> 00:59:07,920 the most about it is, is it's enabled us to to maintain that 1006 00:59:07,920 --> 00:59:11,440 independence and that attitude that what we're building is 1007 00:59:11,440 --> 00:59:14,640 infrastructure, not, you know, a money spinner, not an investment 1008 00:59:14,640 --> 00:59:16,880 opportunity. Yeah. 1009 00:59:16,880 --> 00:59:20,840 How much is in the endowment? Well varies day-to-day. 1010 00:59:21,240 --> 00:59:23,560 It is a little under 50 million at the moment. 1011 00:59:23,560 --> 00:59:29,080 I think we it's divided up between ETH exposure and USDC 1012 00:59:29,080 --> 00:59:33,280 exposure. The basic in intuition is that 1013 00:59:33,600 --> 00:59:39,120 if somebody pays for 10 years of registration, we after a year 1014 00:59:39,440 --> 00:59:41,720 one team for that is effectively being used up. 1015 00:59:41,760 --> 00:59:43,920 You know, they've had their year of registration. 1016 00:59:44,280 --> 00:59:47,320 And so that's money that the Dow can spend or invest as it sees 1017 00:59:47,320 --> 00:59:50,200 fit and that's held as USDC for stability. 1018 00:59:50,600 --> 00:59:53,600 The remaining nine years are still money that was paid for a 1019 00:59:53,600 --> 00:59:55,360 service that hasn't been rendered yet. 1020 00:59:55,840 --> 00:59:58,160 And because it was paid in ETH, we keep his knee. 1021 00:59:58,160 --> 01:00:00,080 So we still have a large ETH exposure. 1022 01:00:01,080 --> 01:00:03,840 And the Dow therefore, sorry, the endowment therefore is 1023 01:00:03,840 --> 01:00:05,920 divided up into two those two sections. 1024 01:00:06,240 --> 01:00:09,200 And because of the ETH exposure, you know, I see some some very 1025 01:00:09,200 --> 01:00:13,200 large variation over time. Our endowment manager Carpet. 1026 01:00:13,200 --> 01:00:15,760 Key is is very good and publishes weekly reports and 1027 01:00:15,760 --> 01:00:19,160 monthly reports that you know provide a lot of detail into the 1028 01:00:19,160 --> 01:00:22,360 the goings on. Yeah, I mean. 1029 01:00:22,560 --> 01:00:26,680 The one of the interesting things about about ENS is I 1030 01:00:26,680 --> 01:00:29,800 think the the the the governance, how active it is. 1031 01:00:30,840 --> 01:00:32,840 You know the implementation of the delegate system. 1032 01:00:33,200 --> 01:00:36,880 You know, I was, I was sort of surprised, I mean pleasantly 1033 01:00:36,880 --> 01:00:39,640 surprised to see that Coinbase is a large delegate and. 1034 01:00:40,280 --> 01:00:45,520 Fairly active in in governance you know looking to the future 1035 01:00:45,520 --> 01:00:49,160 of of of ENS and particularly the governance you know how do 1036 01:00:49,160 --> 01:00:53,720 you think that will scale as ENS grows and you know will will 1037 01:00:53,720 --> 01:00:56,720 someone will we someday see like I can sitting on the governance 1038 01:00:56,720 --> 01:01:01,120 board of of of ENS you know and and and other large 1039 01:01:01,120 --> 01:01:03,600 organizations that that use the protocol. 1040 01:01:04,200 --> 01:01:08,480 I would yeah I would love to see participation from you know from 1041 01:01:08,480 --> 01:01:11,000 other large organizations and stakeholders. 1042 01:01:11,000 --> 01:01:14,400 You know I want and is to be built with those people in mind 1043 01:01:14,400 --> 01:01:16,040 and I want them to have a say in governance. 1044 01:01:16,600 --> 01:01:20,600 I think ultimately enabling that sort of thing means you know 1045 01:01:20,600 --> 01:01:24,040 doing what we can to make it as as easy as possible for people 1046 01:01:24,040 --> 01:01:27,680 to shift the delegated votes. You know we've we've done that 1047 01:01:27,680 --> 01:01:30,200 using things like free redelegation where we use meta 1048 01:01:30,200 --> 01:01:33,000 transactions and we pay the guest fees for re delegating 1049 01:01:33,000 --> 01:01:36,320 your tokens. But as with any project with a 1050 01:01:36,320 --> 01:01:42,440 token, the keeping people's attention and keeping them, you 1051 01:01:42,440 --> 01:01:45,520 know, focused on governance and and active in it can be a 1052 01:01:45,520 --> 01:01:48,040 problem. So we see this gradual decline 1053 01:01:48,040 --> 01:01:50,640 and delegated token counts over time. 1054 01:01:51,040 --> 01:01:54,800 And so combating that and and increasing governance 1055 01:01:54,800 --> 01:01:58,240 participation and also making it very easy for delegates to step 1056 01:01:58,240 --> 01:02:01,400 up and step down and not, you know, we want someone who comes 1057 01:02:01,400 --> 01:02:04,840 along late to have a good opportunity to, to encourage a 1058 01:02:04,840 --> 01:02:06,080 lot of people to delegate to them. 1059 01:02:06,640 --> 01:02:10,120 Equally, we want someone who is moving on to be able to make 1060 01:02:10,120 --> 01:02:13,680 sure that their votes delegated to them don't go to waste, you 1061 01:02:13,680 --> 01:02:15,000 know, because they're no longer active. 1062 01:02:16,120 --> 01:02:18,600 Solving challenges like that is going to be a big, a big thing 1063 01:02:18,600 --> 01:02:21,880 going forward for the UNICEAL to make sure it continues to be 1064 01:02:21,880 --> 01:02:27,400 representative in our talents. Yeah, I mean, I think like 1065 01:02:27,400 --> 01:02:31,000 governance. Delegation is, you know, it's 1066 01:02:31,000 --> 01:02:34,040 it's certainly like a an issue that we see in the Cosmos side 1067 01:02:34,040 --> 01:02:37,680 of things as well, right where? You know, I think Cosmos has a 1068 01:02:37,760 --> 01:02:41,000 Cosmos chains have a a different model where validators are sort 1069 01:02:41,000 --> 01:02:43,800 of the the de facto delegate, right. 1070 01:02:43,800 --> 01:02:49,120 If you don't vote, if you don't vote from your own sort of 1071 01:02:49,120 --> 01:02:53,160 token, your own tokens that your your validator votes for you. 1072 01:02:53,160 --> 01:02:59,400 But you know, that has created I think, a situation where I think 1073 01:02:59,400 --> 01:03:03,080 a lot of people are dissatisfied with the way governance is is 1074 01:03:03,080 --> 01:03:06,040 conducted, right where it would be better for. 1075 01:03:06,520 --> 01:03:10,440 In certain some cases maybe for things like like like spending 1076 01:03:10,440 --> 01:03:13,800 like community pool spending and things of that nature treasury 1077 01:03:13,800 --> 01:03:19,120 spending, treasury allocations to be governed by like a a group 1078 01:03:19,120 --> 01:03:22,200 of folks, right. So for that that responsibility 1079 01:03:22,200 --> 01:03:24,640 to be delegated to like a group of folks that are voted in by 1080 01:03:24,640 --> 01:03:26,360 governance that can be vetoed etcetera. 1081 01:03:26,360 --> 01:03:30,800 But we, you know, we found that. But I think the community is 1082 01:03:30,800 --> 01:03:33,040 moving more towards this model where governance 1083 01:03:33,040 --> 01:03:35,680 responsibilities are delegated to or should be delegated to 1084 01:03:35,720 --> 01:03:39,760 like sort of Sub Dow's, right? This is a sub Dow idea, so you 1085 01:03:39,760 --> 01:03:42,080 know it's a it's an interesting problem to solve. 1086 01:03:42,560 --> 01:03:44,560 Yeah. And and EMS approaches that a 1087 01:03:44,560 --> 01:03:46,440 little differently with our working groups. 1088 01:03:46,440 --> 01:03:50,480 You know that working the whole Dow relates working group 1089 01:03:50,480 --> 01:03:53,640 stewards on a regular basis and they have delegated authorities 1090 01:03:53,640 --> 01:03:55,280 to deal with day-to-day decisions. 1091 01:03:55,280 --> 01:04:00,080 I think there is a a common misconception in, you know, the 1092 01:04:00,080 --> 01:04:03,560 decentralized community that you know everything has to be 1093 01:04:03,560 --> 01:04:07,760 decided by everybody. But in reality, that's just not 1094 01:04:07,760 --> 01:04:10,160 how any large organization works. 1095 01:04:10,160 --> 01:04:13,360 There has to be some delegation of authority and what makes it 1096 01:04:13,360 --> 01:04:15,880 decentralized is whether there's transparency and checks and 1097 01:04:15,880 --> 01:04:18,560 balances over that. Whether you know somebody who 1098 01:04:18,560 --> 01:04:20,720 isn't representing their community can be removed and 1099 01:04:20,720 --> 01:04:23,600 replaced. Rather than that, every single 1100 01:04:23,600 --> 01:04:26,360 decision you know gets noted on by everybody, which is 1101 01:04:26,800 --> 01:04:29,720 exhausting and and requires everybody to be an expert on 1102 01:04:29,720 --> 01:04:31,840 everything. Great. 1103 01:04:31,840 --> 01:04:33,960 Well, next. Thanks so much for coming back 1104 01:04:33,960 --> 01:04:37,080 on and sharing an update on on ENS. 1105 01:04:37,960 --> 01:04:40,920 Yeah, really, really excited that we could have this 1106 01:04:40,920 --> 01:04:45,280 conversation again and also excited but to see ENS growing 1107 01:04:45,280 --> 01:04:50,800 and continue to grow and be a pillar for the way you know we 1108 01:04:50,800 --> 01:04:54,240 should conduct governance in the space and and and also an 1109 01:04:54,240 --> 01:04:58,880 important. An important component to 1110 01:05:00,280 --> 01:05:02,440 bringing in more adoption into Ethereum. 1111 01:05:02,440 --> 01:05:08,000 So yeah, number go up in terms of ENS names created, I think is 1112 01:05:08,000 --> 01:05:09,440 is a good metric to be looking at. 1113 01:05:09,880 --> 01:05:11,880 Absolutely. Thanks, Nick. 1114 01:05:12,320 --> 01:05:13,720 Yeah, thank you. It was a pleasure. 1115 01:05:16,000 --> 01:05:17,720 Thank you for joining us on this week's episode. 1116 01:05:18,120 --> 01:05:19,680 We release new episodes every week. 1117 01:05:20,400 --> 01:05:23,080 You can find and subscribe to the show on iTunes, Spotify, 1118 01:05:23,080 --> 01:05:26,120 YouTube, SoundCloud, or wherever you listen to podcasts. 1119 01:05:26,560 --> 01:05:29,360 And if you have a Google Home or Alexa device, you can tell it to 1120 01:05:29,360 --> 01:05:32,360 listen to the latest episode of the Epicenter podcast, go to 1121 01:05:32,360 --> 01:05:35,480 epicenter.tv/subscribe for a full list of places where you 1122 01:05:35,480 --> 01:05:37,720 can watch and listen. And while you're there, be sure 1123 01:05:37,720 --> 01:05:40,200 to sign up for the newsletter so you get new episodes in your 1124 01:05:40,200 --> 01:05:43,280 inbox as they're released. If you want to interact with us 1125 01:05:43,600 --> 01:05:46,000 guests or other podcast listeners, you can follow us on 1126 01:05:46,000 --> 01:05:48,160 Twitter and please leave us a review on iTunes. 1127 01:05:48,200 --> 01:05:50,280 It helps people find the show and we're always. 1128 01:05:50,400 --> 01:05:53,080 Happy to read them. So thanks so much and we look 1129 01:05:53,080 --> 01:05:54,240 forward to being back next week.