1 00:00:13,900 --> 00:00:16,300 Hi, welcome to epicenter of the show which talks about the 2 00:00:16,300 --> 00:00:19,100 Technologies projects and people driving decentralization. 3 00:00:19,100 --> 00:00:22,600 And the blockchain revolution. My name is CBS anchor Jo and I'm 4 00:00:22,600 --> 00:00:26,100 here today with a new co-host, just as fights are who. 5 00:00:26,300 --> 00:00:29,800 I'm sure. Lots of you will recognize as if 6 00:00:30,000 --> 00:00:32,600 I know your face and the in the theorem ecosystem. 7 00:00:33,200 --> 00:00:35,700 Joseph. Thanks for coming on and 8 00:00:36,000 --> 00:00:37,600 co-hosting. This one with me, it's actually 9 00:00:37,600 --> 00:00:40,900 quite fitting since we're talking with him beko who 10 00:00:40,900 --> 00:00:43,600 couldn't coordinates all the theorems core developer meetings 11 00:00:43,600 --> 00:00:45,900 and works at the, a theorem foundation on the protocol 12 00:00:45,900 --> 00:00:49,600 support team. And today, we're talking about, 13 00:00:50,300 --> 00:00:53,900 well, all things if you're re-emerge, which is quite timely 14 00:00:53,900 --> 00:00:59,100 because there was just a major test net, merge, right? 15 00:00:59,100 --> 00:01:03,000 Like a few minutes, Or we start at this, you know, this will go 16 00:01:03,000 --> 00:01:06,200 out fairly fairly soon after after that happens. 17 00:01:06,200 --> 00:01:07,300 So this is actually quite timely. 18 00:01:07,300 --> 00:01:11,500 But yeah, thanks for thanks for co-hosting this one Joseph and 19 00:01:11,500 --> 00:01:15,600 maybe tell us a little bit about yourself and what makes you a 20 00:01:15,600 --> 00:01:17,600 competent co-host on this particular topic? 21 00:01:18,800 --> 00:01:21,900 Well if I'm going to jump in on one, I feel like this is an 22 00:01:21,900 --> 00:01:24,800 appropriate subject. I've been around the ethereum 23 00:01:24,800 --> 00:01:27,300 space for a while. I do Communications and PR work 24 00:01:28,000 --> 00:01:31,900 with most of my time at 3 and Foundation as well, but I'm sort 25 00:01:31,900 --> 00:01:36,000 of a general tinkerer. So anything in the layer, one 26 00:01:36,700 --> 00:01:40,400 sort of Block Chain space, that passes the legitimacy. 27 00:01:40,400 --> 00:01:42,800 Sniff test is something that I've liked to play with for a 28 00:01:42,800 --> 00:01:48,600 while and Just happy to jump in. Cool. 29 00:01:48,600 --> 00:01:51,700 Well yeah happy to have you on. Hopefully you can come on for 30 00:01:51,900 --> 00:01:55,500 you know most of our you know, ethereum Focus episodes because 31 00:01:55,500 --> 00:01:58,800 I think you have a lot of Insider information and really 32 00:01:58,800 --> 00:02:01,700 good insights. So glad to have you here it and 33 00:02:01,700 --> 00:02:04,200 wonderfully about the public systems is that nobody has 34 00:02:04,200 --> 00:02:10,500 Insider information. If you're paying attention Yeah, 35 00:02:10,699 --> 00:02:13,000 and I, yeah, Tim. Thanks for thanks for joining us 36 00:02:13,000 --> 00:02:17,100 today, right? Right after the merge. 37 00:02:18,000 --> 00:02:21,100 I'm Cipollini. Oh, welcome Unser polio yes. 38 00:02:22,400 --> 00:02:23,600 Yeah. Thanks for having me. 39 00:02:25,900 --> 00:02:27,700 Cool. So before we talk to Tim just 40 00:02:27,700 --> 00:02:30,400 want to tell you about his sponsors this week, security 41 00:02:30,400 --> 00:02:32,800 block. Chains and earning rewards needs 42 00:02:32,800 --> 00:02:36,600 doesn't need to be energy, intensive or complicated and by 43 00:02:36,600 --> 00:02:38,000 staking your That's with Horace one. 44 00:02:38,000 --> 00:02:40,800 You contribute to network security and earn rewards to. 45 00:02:41,100 --> 00:02:43,800 Of course, one has been a Pioneer in this basement is 2018 46 00:02:43,800 --> 00:02:47,000 and they secure hundreds of millions of dollars in assets on 47 00:02:47,000 --> 00:02:50,400 over 30 decentralized, networks including Solana Cosmos etherium 48 00:02:50,700 --> 00:02:53,000 and many others. If you're an institution and you 49 00:02:53,000 --> 00:02:55,300 want to run your own node, you can use chorus one's white label 50 00:02:55,300 --> 00:02:58,600 service, and their battle-proven infrastructure to participate in 51 00:02:58,600 --> 00:03:00,500 proof of State networks in an easy way. 52 00:03:00,500 --> 00:03:02,900 So head over to course dot one and start your steak Journey 53 00:03:03,300 --> 00:03:06,700 were also supported by Paris. Swap are swap, is a multi-chain 54 00:03:06,700 --> 00:03:08,700 decks aggregator. This means that through Paris 55 00:03:08,700 --> 00:03:10,700 swap. You can easily access the 56 00:03:10,700 --> 00:03:13,800 liquidity of various different. Decentralized exchange has the 57 00:03:13,800 --> 00:03:16,600 protocol automatically finds the cheapest liquidity for you. 58 00:03:16,900 --> 00:03:19,500 So you can know that you are getting the best price for your 59 00:03:19,500 --> 00:03:22,800 trade Paris office. Also gasps friendly and helping 60 00:03:22,800 --> 00:03:25,900 you keep your transactions low. They recently added support for 61 00:03:25,900 --> 00:03:28,200 Avalanche polygon, B, SC and Phantom. 62 00:03:28,600 --> 00:03:32,300 And you can also use Periscope directly in your Ledger Live 63 00:03:32,300 --> 00:03:34,500 app. If you lose use a ledger in 64 00:03:34,500 --> 00:03:36,600 addition to that, they are also becoming a down. 65 00:03:36,600 --> 00:03:39,200 So if you have USB tokens that something you can participate 66 00:03:39,200 --> 00:03:40,800 in. As in participate in the 67 00:03:40,800 --> 00:03:43,400 governance of the protocol and the Paris walked out. 68 00:03:43,400 --> 00:03:46,600 Just voted the gas refund program which will allow pair 69 00:03:46,600 --> 00:03:51,200 swap stickers to get up to 100% of gas refunds on the trades on 70 00:03:51,200 --> 00:03:53,900 top of their Auto compounding yield so they're still learn 71 00:03:53,900 --> 00:03:56,100 more. Visit Paris, swap dot IO and 72 00:03:56,100 --> 00:04:00,500 since we're here I also want to mention something that I think a 73 00:04:00,508 --> 00:04:02,800 lot of people perhaps have already noticed some organizing 74 00:04:02,800 --> 00:04:05,600 a conference in Paris on July 22nd. 75 00:04:05,600 --> 00:04:08,100 It's called nebulae Summit. It's happening on the day after 76 00:04:08,100 --> 00:04:10,500 ECC. So during ECC week which is one 77 00:04:10,500 --> 00:04:14,000 of the largest aetherium developer conferences in Europe, 78 00:04:14,100 --> 00:04:16,800 actually one of the largest blockchain developer conferences 79 00:04:16,800 --> 00:04:19,300 in Europe as well. Nebula Simon is all about 80 00:04:19,300 --> 00:04:22,300 celebrating the cosmos and interesting ecosystem so I hope 81 00:04:22,300 --> 00:04:25,800 to bring a lot of you know Cosmos folks and etherium folks 82 00:04:25,800 --> 00:04:29,100 together for this conference will be joined by Cosmos 83 00:04:29,100 --> 00:04:31,200 developers researchers and entrepreneurs. 84 00:04:31,500 --> 00:04:34,200 As they discussed the challenges facing the interest chain and 85 00:04:34,200 --> 00:04:36,500 you're talking about the future of the internet of blockchains. 86 00:04:36,700 --> 00:04:40,700 So take Are almost sold out as we speak right now we're going 87 00:04:40,700 --> 00:04:42,900 to be pulling the plug on the ticket sale soon, but you might 88 00:04:42,900 --> 00:04:45,900 be able to squeeze in check out nebular dot Paris for more 89 00:04:45,900 --> 00:04:49,300 information and I do want to mention our sponsors who are 90 00:04:49,308 --> 00:04:56,300 making this possible F, most anoma Club Neutron a gorik, and 91 00:04:56,300 --> 00:05:00,400 Celestia. So with that, let's let's get 92 00:05:00,400 --> 00:05:03,600 into this Tim. Tell us a little bit about your 93 00:05:03,600 --> 00:05:07,000 background and how you got involved in this work. 94 00:05:07,100 --> 00:05:09,600 Work. Yeah well I guess your first 95 00:05:09,600 --> 00:05:14,500 thanks for having me on. Yeah my background so I I 96 00:05:14,900 --> 00:05:18,900 started like getting interested in Block, chains around 2013, 97 00:05:18,900 --> 00:05:21,900 2014. First year first heard about 98 00:05:22,200 --> 00:05:27,600 Bitcoin and got into that. Then a couple years later, I 99 00:05:27,608 --> 00:05:30,900 actually heard about a theorem through the doll but when the 100 00:05:30,900 --> 00:05:38,300 Dow was like a project and not a hack so I'd like Her dimensions 101 00:05:38,300 --> 00:05:40,500 of it before. But the the doll project is 102 00:05:40,500 --> 00:05:43,300 really what Scotty that like actually try out a theorem. 103 00:05:43,600 --> 00:05:46,900 So I literally bought ether and about thousand tokens like the 104 00:05:46,900 --> 00:05:50,600 week or even maybe day before it got hacked. 105 00:05:51,500 --> 00:05:55,800 And and then the next morning like remember reading on Reddit 106 00:05:55,800 --> 00:05:59,300 the post about some I think Lisa likes a saying, I think someone 107 00:05:59,300 --> 00:06:04,100 is draining the Dow and that was like a pretty eventful couple 108 00:06:04,100 --> 00:06:06,800 weeks after that because not only was so dis big hack but 109 00:06:06,800 --> 00:06:10,900 after it was The term classic split and you had to figure out 110 00:06:10,900 --> 00:06:14,800 like how to split your tokens in order to prevent replay attacks 111 00:06:15,100 --> 00:06:18,100 and and I knew like absolutely nothing about blockchain stands. 112 00:06:18,100 --> 00:06:22,200 I was just like copy-pasting random commands in my terminal 113 00:06:22,400 --> 00:06:25,200 hoping that I wouldn't just lose all my coins doing so. 114 00:06:25,700 --> 00:06:28,500 So it was like a really interesting, I guess what I 115 00:06:28,500 --> 00:06:32,200 think to get into this space but after the Dow there was like 116 00:06:32,200 --> 00:06:37,100 this this LOL or it felt like you know, maybe if they were was 117 00:06:37,100 --> 00:06:39,100 not. Going to be like a successful 118 00:06:39,100 --> 00:06:42,500 experiment because, well, if this is a smart contract 119 00:06:42,500 --> 00:06:45,200 platform and you can't write a smart contract on it without 120 00:06:45,200 --> 00:06:48,300 getting hacked. You know, is there, is there a 121 00:06:48,300 --> 00:06:50,600 ton of value there? So I guess I could following 122 00:06:50,600 --> 00:06:54,500 your bit, but I didn't like late, 2016, early 2017. 123 00:06:54,500 --> 00:06:56,100 You start to see a bunch of projects. 124 00:06:56,100 --> 00:06:59,500 I use the theorem again, and obviously in, like, by mid-late 125 00:06:59,500 --> 00:07:01,900 2017. There was this huge Ico, boom. 126 00:07:02,700 --> 00:07:07,400 And there I kind of realize like there would probably be a lot of 127 00:07:07,500 --> 00:07:10,900 Man for aetherium even if like all the applications in 2017 128 00:07:10,900 --> 00:07:14,800 turned out not to work clearly you know there's a lot of things 129 00:07:14,800 --> 00:07:18,300 you could do with blockchain like that and I decided I wanted 130 00:07:18,300 --> 00:07:21,900 to work like at the protocol layer because as a user like it 131 00:07:21,900 --> 00:07:24,300 was still pretty rough to use a theorem those days. 132 00:07:24,300 --> 00:07:28,600 And you know like when there were like ico's and the mempool 133 00:07:28,600 --> 00:07:31,800 would say congested for like hours to days it was just like a 134 00:07:31,808 --> 00:07:34,100 really bad experience in felt like there's a lot, you could 135 00:07:34,100 --> 00:07:37,300 improve their but I wasn't like an engineer research. 136 00:07:37,500 --> 00:07:38,800 Sure. I was like a product manager. 137 00:07:39,000 --> 00:07:41,900 So it took me a while to find like a product manager job 138 00:07:41,900 --> 00:07:45,400 working on the protocol and not on the product, built on top of 139 00:07:45,407 --> 00:07:48,900 the protocol so thick like about a year. 140 00:07:48,900 --> 00:07:53,100 But then consensus put together a protocol team and I joined 141 00:07:53,100 --> 00:07:56,100 that. And so I worked I worked as part 142 00:07:56,100 --> 00:07:59,800 of consensus for about two and a half years on their hybrid Edge 143 00:07:59,808 --> 00:08:04,300 or base you client. So got involved in basically 144 00:08:04,300 --> 00:08:06,200 main that protocol work through that. 145 00:08:07,500 --> 00:08:10,700 And as part of that, you know, I worked out with folks, like, 146 00:08:10,700 --> 00:08:14,800 Hudson who is chairing the awkward as calls of the time and 147 00:08:15,800 --> 00:08:19,300 and then around like 2020, he wanted to move on to other 148 00:08:19,300 --> 00:08:23,300 things. And yeah, I decided to step up 149 00:08:23,300 --> 00:08:26,300 and take the role there. And so since then I've been 150 00:08:26,300 --> 00:08:30,500 basically coordinating these developer calls that we have on 151 00:08:30,500 --> 00:08:34,100 the theorem where different protocol Implement 152 00:08:34,299 --> 00:08:37,299 implementation teams get together and chat about it. 153 00:08:37,400 --> 00:08:39,500 Changes to a theorem. Yes. 154 00:08:39,500 --> 00:08:44,400 That's how how I ended up here. Gotcha, and before we dig into 155 00:08:44,400 --> 00:08:49,000 core development and sort of how governance and a CD calls, all 156 00:08:49,000 --> 00:08:53,000 chord F calls work in general, what your role today, we 157 00:08:53,000 --> 00:08:57,500 mentioned earlier, you were with serum foundation on the protocol 158 00:08:57,500 --> 00:08:59,300 support side. What is protocol support? 159 00:08:59,300 --> 00:09:04,900 Can you just let the folks know? Yeah, so our team sucks pretty 160 00:09:04,900 --> 00:09:07,300 well though. That the T, my mind that the EF 161 00:09:07,300 --> 00:09:11,000 is called protocol support. And it's a bit of an odd team 162 00:09:11,000 --> 00:09:14,800 because, like, for me, it was no TV was just like Hudson, you 163 00:09:14,800 --> 00:09:17,900 know, like floating in the org chart and then like it since the 164 00:09:17,900 --> 00:09:21,900 theorem has like grown and gotten more complex in the past 165 00:09:21,900 --> 00:09:24,200 couple of years. Like the basically there was 166 00:09:24,200 --> 00:09:28,300 just like a team put together and you know there's folks like 167 00:09:28,600 --> 00:09:31,700 Danny and me where we obviously Charities calls. 168 00:09:31,900 --> 00:09:35,100 There's a bunch of folks. To help either, like get better 169 00:09:35,100 --> 00:09:38,400 inputs and share updates the community, like Trent, we just 170 00:09:38,400 --> 00:09:41,900 have folks who work on like, you know, specific stuff behind the 171 00:09:41,900 --> 00:09:43,900 scenes. Like there was the suppose we 172 00:09:43,900 --> 00:09:47,100 emerge today and someone on our team is just working on getting 173 00:09:47,100 --> 00:09:50,500 the hash rate on supposedly a so that we hit the merge at the 174 00:09:50,500 --> 00:09:54,100 right time. And, you know this, yeah. 175 00:09:54,100 --> 00:09:57,300 Stuff like client grants. Organizing like workshops. 176 00:09:57,700 --> 00:10:01,700 So, you know, anything that basically supports like the work 177 00:10:01,700 --> 00:10:04,500 of researchers and And core developers in the protocol is 178 00:10:04,500 --> 00:10:07,400 stuff. We try to help with yeah. 179 00:10:08,900 --> 00:10:11,400 I think we're getting toward the same point but may have a little 180 00:10:11,400 --> 00:10:14,600 bit of a delay just so folks kind of get it. 181 00:10:14,600 --> 00:10:17,600 What does governance look like on aetherium how is it? 182 00:10:17,600 --> 00:10:20,400 How does it relate to these all chord F calls and who decides 183 00:10:20,400 --> 00:10:22,400 anything? Okay. 184 00:10:22,400 --> 00:10:24,600 Yeah, this is. There's a lot to unpack here. 185 00:10:25,400 --> 00:10:29,300 So I guess like the very first bit that's important to know 186 00:10:29,300 --> 00:10:32,100 about like a theorem governance especially relative to like 187 00:10:32,100 --> 00:10:36,200 other blockchains, is we don't use like Queen voting or any 188 00:10:36,200 --> 00:10:40,700 sort of formal voting as part of the governance process and the 189 00:10:41,200 --> 00:10:45,200 roof reason there is that like we don't think that like coin 190 00:10:45,200 --> 00:10:50,600 holders are like the Only stakeholders that we should like 191 00:10:50,600 --> 00:10:56,200 disproportionately optimized for and and so if we don't have coin 192 00:10:56,200 --> 00:11:00,800 voting you know it becomes a much Messier process for 193 00:11:00,800 --> 00:11:03,800 governance to happen. There's definitely some pros and 194 00:11:03,800 --> 00:11:06,600 cons to that but I think overall it's it works quite well for 195 00:11:06,600 --> 00:11:11,400 theorem and generally the way the way I like changes to the 196 00:11:11,400 --> 00:11:14,900 protocol would happen you know this is the happy path and then 197 00:11:14,900 --> 00:11:18,900 we can talk about all the edge cases is You know, someone comes 198 00:11:18,900 --> 00:11:20,900 up with an idea. We have we have a pretty open 199 00:11:20,900 --> 00:11:23,700 process for like proposing changes to the protocol because 200 00:11:23,700 --> 00:11:26,900 all the specifications are public, you know, anyone can 201 00:11:26,900 --> 00:11:29,800 come and put together like a proposal to change something. 202 00:11:30,200 --> 00:11:34,400 We use VIPs for that. Mostly again, there's some 203 00:11:34,400 --> 00:11:38,800 exceptions here but like roughly we use the IPS and so if you 204 00:11:38,800 --> 00:11:40,700 want to change something on the protocol you come you put 205 00:11:40,700 --> 00:11:43,700 together the IP and then we usually ask that you get some 206 00:11:43,700 --> 00:11:47,700 feedback, you know, async from people who are like have 207 00:11:47,700 --> 00:11:50,300 relevant. Variants in the part of the 208 00:11:50,308 --> 00:11:52,800 theorem you changing. So imagine, you know, you're 209 00:11:52,800 --> 00:11:55,400 changing gas prices or something, then you probably 210 00:11:55,400 --> 00:11:57,400 reach out to some client teams. You probably want to do some 211 00:11:57,400 --> 00:12:01,200 benchmarking on likewise, the new gas price better if you're 212 00:12:01,200 --> 00:12:04,700 if you're adding something new, you know, like trying to get 213 00:12:04,700 --> 00:12:07,100 some feedback from like the people who will use this thing 214 00:12:07,100 --> 00:12:09,400 that you're adding and like why is it important to them and 215 00:12:09,400 --> 00:12:11,400 what's not? And once you have a proposal 216 00:12:11,400 --> 00:12:15,000 that's like in decent shape, we have these public calls that 217 00:12:15,000 --> 00:12:17,500 happen every two weeks called all core devs. 218 00:12:18,200 --> 00:12:21,000 And there's a, there's a mirror version of that for for changes 219 00:12:21,000 --> 00:12:24,200 to the beacon chain. But you know, for now we can 220 00:12:24,200 --> 00:12:26,100 assume they're like, roughly the same thing. 221 00:12:27,000 --> 00:12:29,100 So we have these public calls people come with a proposal and 222 00:12:29,100 --> 00:12:32,700 then discuss it and then, you know, kind teams basically 223 00:12:32,700 --> 00:12:36,400 decide whether or not that this is a change to should Implement. 224 00:12:37,100 --> 00:12:40,400 And in practice it's incredibly rare that like a change will be 225 00:12:40,400 --> 00:12:45,000 accepted like on the first. I'm the first time it's 226 00:12:45,000 --> 00:12:47,900 presented depending on the complexity of the change. 227 00:12:48,300 --> 00:12:51,800 It takes like a small number of months to like a small number of 228 00:12:51,800 --> 00:12:54,400 years to get that change included. 229 00:12:55,000 --> 00:12:58,900 And most of that time is spent just like in back and forth with 230 00:12:59,200 --> 00:13:03,200 protocol developers who try to understand like does this change 231 00:13:03,300 --> 00:13:07,300 actually benefits people and most importantly, like, is there 232 00:13:07,300 --> 00:13:10,700 a security risk to aetherium by introducing this change? 233 00:13:10,900 --> 00:13:13,000 So there's a long list of changes that like, would be 234 00:13:13,000 --> 00:13:16,300 beneficial to end users with like there are settings, 235 00:13:16,300 --> 00:13:19,800 security issues with them. And so, you know, we can't like 236 00:13:19,800 --> 00:13:24,400 have them in the theorem, then, you know, assume you go through 237 00:13:24,400 --> 00:13:26,800 this process. You convinced everybody on the 238 00:13:26,800 --> 00:13:30,400 client teams of like okay, this change should go in kind of 239 00:13:30,400 --> 00:13:33,900 teams will typically then write, like, write the code for your 240 00:13:33,900 --> 00:13:37,000 change, right? Testings and whatnot and then 241 00:13:37,100 --> 00:13:40,700 they just end up putting out the software there, still needs to 242 00:13:40,700 --> 00:13:43,700 be like, adoption of this software by the entire theorem 243 00:13:43,700 --> 00:13:46,000 community. And this is the part of ethereum 244 00:13:46,200 --> 00:13:50,100 governance, which is like, very From from a lot of projects or a 245 00:13:50,100 --> 00:13:53,800 lot of like uh Tyrell ones where when the client devs put out the 246 00:13:53,800 --> 00:13:57,000 software, you can think of it as like an opinionated suggestion, 247 00:13:57,100 --> 00:13:59,400 right? Like they think like okay these 248 00:13:59,400 --> 00:14:03,700 are the changes we should make to a theorem and and this is 249 00:14:03,708 --> 00:14:06,700 when we should make them. But if people like steak yours 250 00:14:06,700 --> 00:14:10,200 and not operators, don't upgrade their nodes, those changes just 251 00:14:10,200 --> 00:14:15,100 like don't happen and then practice, you know, usually by 252 00:14:15,100 --> 00:14:19,100 the time we've put out like a set of changes the community 253 00:14:19,100 --> 00:14:21,300 will adopt them. And the reason is like we try to 254 00:14:21,300 --> 00:14:26,200 prune changes that like we think would not be adopted earlier on 255 00:14:26,200 --> 00:14:29,400 the process just because it's quite messy to have an upgrade 256 00:14:29,400 --> 00:14:35,400 happen where where you know, it's highly contentious and and 257 00:14:35,600 --> 00:14:38,300 you know, to be carried, those have happened in the theorem in 258 00:14:38,300 --> 00:14:41,900 the past but generally, if something feels like, you know, 259 00:14:42,000 --> 00:14:46,000 there's not like broad community support and and there's not a 260 00:14:46,008 --> 00:14:50,200 strong enough rationale to like, Despite that then it's kind of 261 00:14:50,200 --> 00:14:52,500 inclined team's best interest to not include it because then 262 00:14:52,500 --> 00:14:54,800 they're the ones who have to deal with like the Fallout of a 263 00:14:55,200 --> 00:14:57,800 messy Network upgrade. So there is definitely like this 264 00:14:57,800 --> 00:15:02,700 check you know by like everyone involved in ethereum about the 265 00:15:02,700 --> 00:15:06,300 changes that go out. And then we, you know, there's 266 00:15:06,300 --> 00:15:10,100 often leads to like very intractable conversations about 267 00:15:10,100 --> 00:15:12,300 like what is the theory of community? 268 00:15:12,300 --> 00:15:14,400 And who should get a say in what not then. 269 00:15:14,600 --> 00:15:17,300 I don't think there's like a single answer there. 270 00:15:18,300 --> 00:15:21,100 You know, different change. Bring out different parts of the 271 00:15:21,108 --> 00:15:24,300 community with strong opinions, but yeah, it's really just 272 00:15:24,300 --> 00:15:28,200 process of just like trying to come up with a set of changes. 273 00:15:28,200 --> 00:15:32,000 That like-kind developers think will be adopted and and 274 00:15:32,000 --> 00:15:36,800 proposing them and and in the default case they usually end up 275 00:15:36,800 --> 00:15:40,000 being adopted but it's not something we can like, take for 276 00:15:40,000 --> 00:15:44,800 granted or forced upon people. That's interesting. 277 00:15:44,800 --> 00:15:48,600 I mean, I think that's the first time I heard someone really kind 278 00:15:48,600 --> 00:15:52,200 of explained the the governance process for for upgrades and 279 00:15:52,208 --> 00:15:54,600 etherium. I spend a lot more time on the 280 00:15:54,600 --> 00:15:57,200 cosmos side of thing and and and of course there are. 281 00:15:57,200 --> 00:16:00,700 You know, there's there's there's coin voting and your 282 00:16:00,700 --> 00:16:05,800 governance is is an issue. I think that, you know, affects 283 00:16:05,800 --> 00:16:09,000 all different blockchains. Whether it's, you know, 284 00:16:09,000 --> 00:16:12,000 something like Bitcoin or theorem would say it with its 285 00:16:12,000 --> 00:16:14,400 process. These or you know, blockchains 286 00:16:14,400 --> 00:16:17,000 with built-in coin voting governance. 287 00:16:17,600 --> 00:16:20,800 You think that coin voting governance, you know, could add 288 00:16:20,800 --> 00:16:25,500 some level of you useful signaling in etherium, 289 00:16:25,500 --> 00:16:27,700 governance. I mean, poor governance has its 290 00:16:27,700 --> 00:16:31,600 flaws and we certainly see that in the cosmos faced recently, 291 00:16:31,900 --> 00:16:35,600 but I think that as a signaling mechanism, it's highly effective 292 00:16:35,600 --> 00:16:40,400 and like we saw recently, you know, some proposals on on on 293 00:16:41,000 --> 00:16:43,300 some Cosmos chains, like get, you know, now, Two percent or 294 00:16:43,300 --> 00:16:47,300 above 90 percent by in. So, I'm curious what your 295 00:16:47,300 --> 00:16:49,200 thoughts are here. Yeah, that's that's a good 296 00:16:49,200 --> 00:16:52,100 question. So I don't think it adds much at 297 00:16:52,100 --> 00:16:55,800 the level of a theorem L1. And, and that's not to say it 298 00:16:55,800 --> 00:16:58,100 does, it's not useful in other contexts, but I think for us 299 00:16:59,300 --> 00:17:01,700 there's like two outcomes you can basically get with like your 300 00:17:01,700 --> 00:17:04,800 signal either. It's like you know mixed or it's 301 00:17:04,800 --> 00:17:08,800 like strongly in favor. I think for any case where it's 302 00:17:08,800 --> 00:17:12,000 strongly in favor we can get that signal you know quite 303 00:17:12,000 --> 00:17:15,599 easily. You know, and take, you know, 304 00:17:15,599 --> 00:17:18,000 let's take something like EIP 1559, right? 305 00:17:18,000 --> 00:17:20,000 Or like that. Even the merge, right? 306 00:17:20,700 --> 00:17:23,400 I think if you polled coin holders about the merged, it 307 00:17:23,400 --> 00:17:25,400 would tell you, they're all in favor because it reduces 308 00:17:25,400 --> 00:17:29,200 issuance. And I you know, maybe I don't 309 00:17:29,200 --> 00:17:31,400 know, maybe some of them have like a vested interest in proof 310 00:17:31,400 --> 00:17:32,900 of work. So they would pull against but 311 00:17:32,900 --> 00:17:36,200 like I my rough feeling is like, you know, it would probably be 312 00:17:37,200 --> 00:17:39,400 Large majority in favor and if you think something like yeah if 313 00:17:39,400 --> 00:17:42,400 you 1559 they would probably be even clearer because like okay 314 00:17:42,800 --> 00:17:46,300 coin you know, like coins are getting burnt that's like you 315 00:17:46,300 --> 00:17:51,900 know unnnnnnh undoubtedly good for quite holders but then it's 316 00:17:51,900 --> 00:17:56,300 like if we because we don't have like a formal process to gather 317 00:17:56,300 --> 00:17:59,300 other signals Beyond like these calls and whatnot. 318 00:17:59,700 --> 00:18:03,200 It would sort of elevate. I think like that signal above 319 00:18:03,300 --> 00:18:05,700 others. And it's not necessarily the 320 00:18:05,700 --> 00:18:09,300 thing you want to Optimized for, especially in the short term, 321 00:18:09,400 --> 00:18:12,100 right? Like, obviously, you know, like 322 00:18:13,000 --> 00:18:15,600 ether holders are like a stakeholder as part of the 323 00:18:15,600 --> 00:18:19,500 governance process, but they're not like the only one nor are 324 00:18:19,500 --> 00:18:22,600 they necessarily the most aligned, you know, you could 325 00:18:22,600 --> 00:18:25,900 argue like the client teams developing ethereum even though 326 00:18:25,900 --> 00:18:29,000 they're not like the biggest coin holders by several orders 327 00:18:29,000 --> 00:18:33,900 of magnitudes, like they have a desire to see like a theorems 328 00:18:34,100 --> 00:18:36,500 Thrive as like a long term, you know? 329 00:18:36,700 --> 00:18:40,100 Infrastructure that maybe like the coin holders today, don't 330 00:18:40,100 --> 00:18:42,300 have right. Like maybe again if you have 331 00:18:42,300 --> 00:18:46,200 like a very carrot troll view of this, maybe like most of the 332 00:18:46,208 --> 00:18:48,700 coin holders today are just holding for the merge because 333 00:18:48,700 --> 00:18:51,400 that's a trade for them and like, you know, they'll move on 334 00:18:51,400 --> 00:18:54,300 to the next stage and I'm not saying this is the case and I 335 00:18:54,308 --> 00:18:57,000 doubt it would be in practice but it's like it's not clear at 336 00:18:57,008 --> 00:19:00,800 the me, the signal from coin holders at a specific block 337 00:19:01,700 --> 00:19:04,400 being much more explicit than like all the other signals, we 338 00:19:04,400 --> 00:19:08,500 have actually adds value, And like the route reason there is 339 00:19:08,500 --> 00:19:11,500 like, yeah, you're like optimizing for many stakeholders 340 00:19:11,800 --> 00:19:15,100 and there's obviously some alignment between coin holders 341 00:19:15,100 --> 00:19:18,400 and the other ones, but it's not like complete and I think like, 342 00:19:18,500 --> 00:19:23,500 the more your project is like aligned with coin holders, the 343 00:19:23,500 --> 00:19:27,400 better like those governance votes are of a signal and if you 344 00:19:27,408 --> 00:19:30,500 think like imagine like a very simple hypothetical defy 345 00:19:30,500 --> 00:19:34,700 product, where like the coin basically gets part of like the 346 00:19:34,700 --> 00:19:37,700 profits from like the upper. Shouldn't have that defy 347 00:19:37,700 --> 00:19:39,800 product. I think in those cases, like, 348 00:19:39,800 --> 00:19:42,400 it's entirely reasonable to have the coin holders. 349 00:19:42,400 --> 00:19:45,900 Be like the main if not sole decider of governance there 350 00:19:45,900 --> 00:19:49,200 because it's like, well, they're like building this thing and 351 00:19:49,200 --> 00:19:53,200 this thing is like has clear like you know, business model or 352 00:19:53,208 --> 00:19:57,400 like flow structure funds flow of funds structure and they can 353 00:19:57,400 --> 00:20:02,100 optimize that and and there's not really like, you know, users 354 00:20:02,100 --> 00:20:05,200 are obviously maybe not quite holders but then the users are 355 00:20:05,200 --> 00:20:06,700 the ones who generate your Fateh. 356 00:20:06,700 --> 00:20:09,300 So, like you want to keep them happy, and this is like 357 00:20:09,400 --> 00:20:13,700 basically, you know, pretty simple alignment problem. 358 00:20:13,900 --> 00:20:17,300 And whereas Fourier theorem it's like, you know, like yes, 359 00:20:17,300 --> 00:20:20,800 there's obviously like that ether the asset but I think 360 00:20:20,800 --> 00:20:23,400 that's like a subset of what like, people are trying to build 361 00:20:23,400 --> 00:20:28,300 and and what users use it for. And that, you know, again the 362 00:20:28,300 --> 00:20:30,800 very simplest example there you could say like, well, you know 363 00:20:30,800 --> 00:20:33,300 it's good for coin holders when like, the fees are high and a 364 00:20:33,300 --> 00:20:35,600 lot of East gets burned, but that's obviously very bad for 365 00:20:35,600 --> 00:20:39,500 users. So you don't want the like yeah 366 00:20:39,700 --> 00:20:43,400 over optimize for them. So yeah and and you know that 367 00:20:43,400 --> 00:20:46,700 says it's also has had coin votes in the past and I'm not 368 00:20:46,700 --> 00:20:51,200 sure like we've gained much information from them and this 369 00:20:51,200 --> 00:20:53,700 is not even getting to like the technical parts of it were like 370 00:20:54,000 --> 00:20:57,700 a lot of the East is not in a position where like he could 371 00:20:57,700 --> 00:20:59,900 vote. So for example, you know some of 372 00:20:59,900 --> 00:21:02,400 it is like in a multisig, some of it, there's like wrapped in 373 00:21:02,400 --> 00:21:06,700 defy, some of it is like in Cold Storage so you're not even 374 00:21:06,700 --> 00:21:09,300 getting like a vote of like coin holders, you getting like a 375 00:21:09,300 --> 00:21:14,500 weird like vote of like the eith that's readily available and 376 00:21:14,500 --> 00:21:18,700 willing to like take some sort of like procedural risk to go 377 00:21:18,700 --> 00:21:22,800 and vote on that. So yeah, I'm pretty against it. 378 00:21:23,300 --> 00:21:25,600 But I think for some other projects like where do you 379 00:21:25,608 --> 00:21:29,300 incentive alignment is just much closer with just corn holders 380 00:21:29,300 --> 00:21:34,000 that it makes it thundersense. We will get to the merge in just 381 00:21:34,000 --> 00:21:37,900 a minute. I did want to just make a one 382 00:21:37,900 --> 00:21:40,300 sort of point of clarification. One further question when it 383 00:21:40,300 --> 00:21:44,100 comes to governance digging into the stakeholders that you were 384 00:21:44,100 --> 00:21:47,500 mentioning. So for a lot of folks listening 385 00:21:47,500 --> 00:21:52,000 in may have been a while and some of these terms consensus 386 00:21:52,000 --> 00:21:55,600 layer clients execution layer clients, you mentioned an entire 387 00:21:55,600 --> 00:21:58,400 secondary called. So, you know, in the old days 388 00:21:58,400 --> 00:22:01,500 all coordinates was all the Chordettes and now you kind of 389 00:22:01,500 --> 00:22:03,500 have these two layers happening in unison. 390 00:22:04,300 --> 00:22:08,000 Can you explain a little bit about what this client ecosystem 391 00:22:08,100 --> 00:22:12,500 looks like and you should have your thoughts on this sort of 392 00:22:13,300 --> 00:22:15,500 facet of a theory of evidence and where it's headed in the 393 00:22:15,500 --> 00:22:19,200 years to come. Yeah yeah that's a great point. 394 00:22:19,200 --> 00:22:21,800 So yeah, everything we kind of talked about. 395 00:22:21,800 --> 00:22:26,000 It's almost like the the pre Beacon chain etherium were like, 396 00:22:26,000 --> 00:22:30,200 yeah. We had even then unlike other 397 00:22:30,200 --> 00:22:33,700 like blockchains a, theorem has many implementation teams. 398 00:22:33,700 --> 00:22:37,500 So like the ethereum protocol is specified using like basically 399 00:22:37,500 --> 00:22:43,500 math and like some, some like readable but not optimized code 400 00:22:43,500 --> 00:22:45,800 and then there's different teams you like. 401 00:22:46,500 --> 00:22:49,400 It versions of this protocol and I think the best analogy is like 402 00:22:49,400 --> 00:22:53,600 web browsers in a way where like if you go to like the, theorem 403 00:22:53,600 --> 00:22:59,100 dot-org on Mozilla versus Chrome versus Firefox versus fari you, 404 00:22:59,100 --> 00:23:02,600 you get to the same web page but obviously like Chrome versus 405 00:23:02,600 --> 00:23:03,700 Safari. Have a bunch of different 406 00:23:03,700 --> 00:23:07,000 features that's like they optimized for and so can think 407 00:23:07,000 --> 00:23:09,700 of a theorem client implementations as that, right? 408 00:23:09,700 --> 00:23:12,000 Like, where does the single specification that they follow? 409 00:23:12,000 --> 00:23:16,200 Kind of like, you know, implementing HTTP and like DNS. 410 00:23:16,500 --> 00:23:19,700 Solving for a browser. But then there's like a bunch of 411 00:23:19,700 --> 00:23:22,400 degrees of freedom that they have to improve their 412 00:23:22,400 --> 00:23:26,000 optimization stuff around sync, speed, database storage, you 413 00:23:26,000 --> 00:23:29,700 know, the efficiency of API requests and whatnot. 414 00:23:30,200 --> 00:23:33,600 And so this means they all kind of get a say in the governance 415 00:23:33,600 --> 00:23:36,000 process, right? So it's not just like a single 416 00:23:36,000 --> 00:23:39,100 implementation team deciding this but it's basically a set of 417 00:23:39,100 --> 00:23:43,400 them and to make this even more complicated in practice. 418 00:23:43,400 --> 00:23:46,500 Now we have both like what we call the execution layer of A 419 00:23:46,500 --> 00:23:48,700 theorem, which is the current proof-of-work chain where like 420 00:23:48,700 --> 00:23:52,900 smart contracts and and and user balances live. 421 00:23:53,300 --> 00:23:55,600 But now we have this vegan chain, which is the proof of 422 00:23:55,600 --> 00:23:59,700 stake, implementation of aetherium, and this proof of 423 00:23:59,700 --> 00:24:04,200 stake, Beacon chain also has an independent specification and 424 00:24:04,200 --> 00:24:07,800 the set of independent implementations for it. 425 00:24:08,000 --> 00:24:10,400 And that means that like in practice for their governance, 426 00:24:10,400 --> 00:24:13,200 you know, they need to come to consensus across all these teams 427 00:24:13,200 --> 00:24:16,800 for changes and now we have the merge happening which is I like 428 00:24:16,800 --> 00:24:21,000 the combination of the current execution chain, where we remove 429 00:24:21,000 --> 00:24:23,700 proof of work. And instead rely on the existing 430 00:24:23,700 --> 00:24:27,200 Beacon chain that the bring consensus to the network. 431 00:24:27,400 --> 00:24:30,600 And so this means that both from like a technical but also 432 00:24:30,600 --> 00:24:34,000 governance group perspective like these two layers will merge 433 00:24:34,000 --> 00:24:37,200 together. Where, you know, now we have 434 00:24:37,300 --> 00:24:40,200 people from say that Beacon chain giving input into 435 00:24:40,200 --> 00:24:44,200 decisions that affect the execution chain because, you 436 00:24:44,200 --> 00:24:46,300 know, they're affected by it and vice versa. 437 00:24:46,400 --> 00:24:49,700 So and so this is probably like what the next couple years of 438 00:24:49,700 --> 00:24:54,400 governance for theorem are like is like finding like cleanly 439 00:24:54,400 --> 00:24:58,200 merging those two things and I think, you know, there's some 440 00:24:58,200 --> 00:25:01,600 like interesting aspects that both of them that I think we 441 00:25:01,600 --> 00:25:04,400 want to preserve. So I think that on the execution 442 00:25:04,400 --> 00:25:07,700 chain, you know, we have like this very open process. 443 00:25:07,700 --> 00:25:10,900 That's like fairly well-documented and people can 444 00:25:10,900 --> 00:25:14,200 come into for the beacon chain because this launch like 445 00:25:14,200 --> 00:25:17,200 separately from etherium, they wanted optimized for Need and 446 00:25:17,200 --> 00:25:20,900 so, they've been like, much better at executing efficiently 447 00:25:21,500 --> 00:25:25,800 and the cost there is like you. It's a bit harder to like, for 448 00:25:25,800 --> 00:25:29,400 Outsiders to follow the process in the specific changes. 449 00:25:30,000 --> 00:25:32,600 And I think, you know, as we as we Merchants to together, 450 00:25:33,000 --> 00:25:36,600 hopefully, we can preserve like the speeds that we've had from 451 00:25:36,600 --> 00:25:39,800 like developing these things independently and having it be a 452 00:25:39,800 --> 00:25:43,800 bit more modular but also make like the process for specifying 453 00:25:43,800 --> 00:25:46,300 changes across the entire theorem stack. 454 00:25:46,400 --> 00:25:49,900 Jack, you know, very clear and transparent. 455 00:25:51,200 --> 00:25:52,600 Yeah. So that's that's the big thing 456 00:25:52,600 --> 00:25:56,800 will be, will be working on next, but in short, you'd say 457 00:25:56,800 --> 00:25:59,800 it's much more of a peer review process than it is sort of a 458 00:25:59,800 --> 00:26:03,300 participatory sort of token holder kind of thing. 459 00:26:05,400 --> 00:26:11,000 It's definitely participatory. Peer reviews a bit. 460 00:26:12,100 --> 00:26:15,000 It feels a bit too distanced from like, what? 461 00:26:15,000 --> 00:26:16,900 Compared to what we have, right? Like peer reviews. 462 00:26:16,900 --> 00:26:20,000 Usually like Anonymous. And like it's also usually like 463 00:26:20,000 --> 00:26:24,000 one or a couple rounds, like very formal and discrete sets of 464 00:26:24,000 --> 00:26:25,800 reviews. I think what we have is like 465 00:26:25,800 --> 00:26:30,000 much more fluid where like, you get a bunch of reviews from your 466 00:26:30,000 --> 00:26:33,900 peers, but it's, you know, people are not Anonymous or, you 467 00:26:33,900 --> 00:26:36,500 know, they can be but like generally they're not or at 468 00:26:36,500 --> 00:26:39,600 least, not all of them. And and it's also it's not just 469 00:26:39,800 --> 00:26:41,700 Open to experts. This is probably the other thing 470 00:26:41,700 --> 00:26:43,900 as well. It's like you know for example 471 00:26:43,900 --> 00:26:47,900 take EIP 1559 which was like a popular one or you could think 472 00:26:47,900 --> 00:26:51,500 like EAP 30 74 which is like another popular change, it 473 00:26:51,500 --> 00:26:54,600 hasn't made it the theorem yet. It's not just kind as like 474 00:26:54,600 --> 00:26:57,500 reviewing and deciding about this like the community and 475 00:26:57,500 --> 00:26:58,900 different parts of it. Like, smart contract, 476 00:26:58,900 --> 00:27:01,500 developers, and whatnot will come and they'll have strong 477 00:27:01,500 --> 00:27:04,100 opinions. And those also need to get like 478 00:27:04,100 --> 00:27:07,500 Incorporated. So it's it's this weird mix 479 00:27:07,500 --> 00:27:09,600 where I guess there's a lot of public review but there's also 480 00:27:09,700 --> 00:27:13,700 So it's also open to like anyone to come in and, like, in 481 00:27:13,700 --> 00:27:17,300 practice, we get, it's like, we don't get every stakeholder that 482 00:27:17,300 --> 00:27:20,800 come in every time but what a change effects, like a set of 483 00:27:20,808 --> 00:27:23,600 stakeholders like you can, be sure that someone from that 484 00:27:23,600 --> 00:27:25,600 group will show up and have a strong opinion. 485 00:27:26,500 --> 00:27:28,000 And this is kind of what you want, right? 486 00:27:28,000 --> 00:27:30,900 Like you want, like the most qualified or like the person's 487 00:27:30,900 --> 00:27:35,000 like the strongest opinion to be heard and and to make a decision 488 00:27:35,000 --> 00:27:39,700 based on that. So can you talk a little bit 489 00:27:39,700 --> 00:27:44,100 about the like the test net landscape and what that looks 490 00:27:44,100 --> 00:27:46,000 like? And what are the current test 491 00:27:46,000 --> 00:27:52,600 Nets running? Yes, so that's changed a lot 492 00:27:52,600 --> 00:27:57,500 recently, but maybe I can like share where we were at and where 493 00:27:57,500 --> 00:28:01,100 we're hoping to go. But if there was like a lot of 494 00:28:01,100 --> 00:28:05,500 tests Nets and cousins, obviously useful for both 495 00:28:05,800 --> 00:28:08,400 application developers who can like deployed or contracts to 496 00:28:08,400 --> 00:28:11,100 them before going to Maine that. And for client developers, who 497 00:28:11,100 --> 00:28:14,300 can deploy, protocol changes them before going to maintenance 498 00:28:15,200 --> 00:28:17,500 the problem with pestilences, like, they end up being very 499 00:28:17,500 --> 00:28:21,400 unstable over time because One. Like if they run on 500 00:28:21,400 --> 00:28:23,900 proof-of-work, like proof of work is not meant to run with 501 00:28:23,900 --> 00:28:26,800 like little hash rate and you get a bunch of volatility in 502 00:28:26,800 --> 00:28:30,400 terms of block times and whatnot at to, if they run on proof of 503 00:28:30,400 --> 00:28:32,500 stake, again. It's like you're asking people 504 00:28:32,500 --> 00:28:37,300 to like, run these validators for no reward, so it's quite 505 00:28:37,300 --> 00:28:40,600 hard to keep them stable and then over time, you know, as 506 00:28:40,600 --> 00:28:43,800 just like a normal Block Chain their history and their state 507 00:28:43,800 --> 00:28:45,500 size grows. So it becomes harder to sink and 508 00:28:45,500 --> 00:28:48,900 node. So we've decided with the merge 509 00:28:48,900 --> 00:28:51,100 coming like this. Is like a good time to revisit 510 00:28:51,100 --> 00:28:54,700 like what are our tests and and what do we want them to be going 511 00:28:54,700 --> 00:28:58,700 forward. So basically we launched a new 512 00:28:58,700 --> 00:29:00,200 test that for the merge called Kiln. 513 00:29:00,300 --> 00:29:03,600 And this is like the first one will be shutting down right 514 00:29:03,600 --> 00:29:05,800 after the merge. And yeah, there is just, we 515 00:29:05,800 --> 00:29:09,500 wanted something earlier this year that anyone could use. 516 00:29:09,500 --> 00:29:13,300 That was like, show them what post-merge ethereum feels like. 517 00:29:13,700 --> 00:29:15,800 So, both infrastructure, providers, smart contract, 518 00:29:15,800 --> 00:29:18,000 developers and whatnot. I'm so it was like a new 519 00:29:18,000 --> 00:29:22,900 testament that we launched and It's only purpose is like you to 520 00:29:22,900 --> 00:29:25,800 be there as a Verge test nut before we merge the other ones. 521 00:29:26,000 --> 00:29:28,700 And so once we've merged my net, that one will go away. 522 00:29:29,500 --> 00:29:32,600 I'm and then if you look at like the other like longer live test 523 00:29:32,600 --> 00:29:36,900 that we basically have Gordy Rob Stinson and rinkeby, as well as 524 00:29:36,900 --> 00:29:41,600 kovin, kovin has been like half deprecated for like over a year 525 00:29:41,600 --> 00:29:44,500 and now is like fully deprecated, because open the, 526 00:29:44,500 --> 00:29:47,700 theorem is basically the only software that can run validators 527 00:29:47,700 --> 00:29:50,100 on it. And that client, Has been in 528 00:29:50,100 --> 00:29:54,300 like a semi deprecated state for a year and now it's fully been 529 00:29:54,300 --> 00:29:56,600 deprecated. So if you're using kovan 530 00:29:57,000 --> 00:30:01,600 basically this is not going to transition to the merge and so 531 00:30:01,600 --> 00:30:04,800 you should migrate to another test that because as soon as 532 00:30:04,800 --> 00:30:07,500 like the merchants the it means that the network you're using 533 00:30:07,500 --> 00:30:11,600 just does not does not reflect the state of ethereum network 534 00:30:12,100 --> 00:30:13,700 today. Rinkeby we can be is maintained 535 00:30:13,700 --> 00:30:17,300 by the get team and it's been around for a long time and now 536 00:30:17,300 --> 00:30:19,600 has like a large State and the history. 537 00:30:19,800 --> 00:30:21,600 Makes it harder to read notes on it. 538 00:30:22,300 --> 00:30:27,800 So we're also not transitioning this one through the merge but 539 00:30:27,800 --> 00:30:30,300 it has like a lot of applications depending on it 540 00:30:30,800 --> 00:30:32,700 already. So we have a bit of a longer 541 00:30:32,900 --> 00:30:36,200 shutdown period where we'll probably have it be live for 542 00:30:36,200 --> 00:30:41,100 like about a year from now. Although as soon as the merge 543 00:30:41,100 --> 00:30:43,800 happens again it won't be a good copy of the theorem my net. 544 00:30:43,800 --> 00:30:46,200 So it's most it'll mostly be there for like Legacy reasons 545 00:30:46,200 --> 00:30:48,300 but in about a year should be shut down. 546 00:30:49,400 --> 00:30:52,900 Then we had a rough skin, which was another really old test net. 547 00:30:53,500 --> 00:30:55,900 And this one was running on proof of work and it's always 548 00:30:55,900 --> 00:30:58,900 been really chaotic because getting proof of work hash rate 549 00:30:58,900 --> 00:31:03,500 on test, Nets is quite hard and and it's that means like the 550 00:31:03,500 --> 00:31:04,900 average amount to get is really low. 551 00:31:04,900 --> 00:31:08,000 But then if somebody just shows up when a minor, you know, they 552 00:31:08,000 --> 00:31:11,100 overwhelm the network and that causes like super quick blocks 553 00:31:11,100 --> 00:31:14,200 with a lot of uncles and then when they leave it causes super 554 00:31:14,200 --> 00:31:16,200 slow blocks. So it's just, it's just a bit 555 00:31:16,200 --> 00:31:18,900 annoying to maintain. It was always quite a bit in 556 00:31:18,900 --> 00:31:20,600 this. This chaotic State look like a 557 00:31:20,608 --> 00:31:23,600 lot of re orgs. And and so we actually we 558 00:31:23,600 --> 00:31:25,300 transitioned this one through the merge first. 559 00:31:25,300 --> 00:31:28,400 Because it felt like well, you know, it's already quite 560 00:31:28,400 --> 00:31:30,100 chaotic. If we break it, it's probably 561 00:31:30,100 --> 00:31:31,800 the least bad test that the brake. 562 00:31:32,200 --> 00:31:35,700 And now it's running under proof of steak, but after the merge on 563 00:31:35,700 --> 00:31:39,000 the theorem, a net will be shutting this one down as well. 564 00:31:39,000 --> 00:31:43,400 So sometime before the end of the year and this leads us to 565 00:31:43,500 --> 00:31:45,400 two tests Nets which were going to be maintaining. 566 00:31:45,700 --> 00:31:49,300 So, the first is Gordie, Gordie, is also like fairly old but I 567 00:31:49,300 --> 00:31:53,500 think of the like column Legacy test nuts, it's definitely the 568 00:31:53,500 --> 00:31:57,100 one which has, like the strongest Community around it. 569 00:31:57,300 --> 00:31:59,900 There's like a really diverse group of validators on it. 570 00:31:59,900 --> 00:32:03,400 There's like a lot of enthusiastic running on Gordy 571 00:32:03,600 --> 00:32:06,200 and there's also like the biggest Beacon chain, test Nets 572 00:32:06,200 --> 00:32:08,900 at the Prater Beacon. Shame, that's like anchored to 573 00:32:08,900 --> 00:32:11,600 it. So Gordy is a testament will be 574 00:32:11,600 --> 00:32:14,000 maintaining going forward. We're going to run it through 575 00:32:14,000 --> 00:32:15,700 the merge. It'll be the last test. 576 00:32:15,700 --> 00:32:19,000 Now if we actually run through the merge and so that validators 577 00:32:19,500 --> 00:32:21,700 Like dress rehearsal that they can. 578 00:32:21,700 --> 00:32:24,200 They can try before before going down, may not. 579 00:32:24,500 --> 00:32:27,800 But if you're using Gordy, you know, it's not, it's not going 580 00:32:27,800 --> 00:32:32,800 away anytime soon and then, lastly, because Roxton and 581 00:32:32,800 --> 00:32:38,500 rinkeby were like, so old. And like, large last fall, we 582 00:32:38,500 --> 00:32:42,500 launched a new test method called cipolla, and this 583 00:32:42,500 --> 00:32:44,900 actually just transition to proof of stake today, right? 584 00:32:44,900 --> 00:32:49,000 Before we recorded this and this is like a new test Network. 585 00:32:49,100 --> 00:32:52,500 We're the good thing about it is it's just like super light 586 00:32:52,500 --> 00:32:56,400 weights to sink if you want to run a node on it you can you can 587 00:32:56,400 --> 00:32:59,600 get up to speed in like less than an hour and it just makes 588 00:32:59,600 --> 00:33:02,400 like really easy to maintain the downside is there's obviously 589 00:33:02,400 --> 00:33:04,000 not as much stuff already deployed there. 590 00:33:04,000 --> 00:33:06,200 So there's not as much like interrupt between between 591 00:33:06,200 --> 00:33:10,000 contracts, but will be will be will be keeping this one as well 592 00:33:10,200 --> 00:33:13,100 and hopefully growing the amount of stuff on it over time and 593 00:33:13,100 --> 00:33:15,800 then the final difference between like guardianship olya 594 00:33:15,800 --> 00:33:20,200 is because Gordie already had a really like Large validator 595 00:33:20,200 --> 00:33:22,500 test, net. We're going to keep this as like 596 00:33:22,500 --> 00:33:25,200 an open validator set. So if you just want to try stuff 597 00:33:25,200 --> 00:33:28,500 on your validator on the test net, you could always use Gordy 598 00:33:28,500 --> 00:33:31,800 and even after the merge with Prater like you'll still be able 599 00:33:31,800 --> 00:33:35,700 to do that. But because again, like when 600 00:33:35,700 --> 00:33:38,600 people have these tests and validators, they end up like not 601 00:33:38,600 --> 00:33:41,600 really caring for them. It causes some amount of 602 00:33:41,700 --> 00:33:46,900 instability on sip olya instead we've had like just a 603 00:33:46,900 --> 00:33:51,900 whitelisted set of validators. R where, you know, these are all 604 00:33:51,900 --> 00:33:55,100 like infrastructure companies and whatnot that that commits 605 00:33:55,100 --> 00:33:56,500 the running them for multiple years. 606 00:33:56,500 --> 00:33:59,500 So there it's quite a stable experience for developers. 607 00:34:00,100 --> 00:34:04,100 So the recap all this Gordy and cipolla are the two tests that's 608 00:34:04,100 --> 00:34:05,400 that are like sticking around long term. 609 00:34:05,400 --> 00:34:07,900 This is what you should be using, you're moving to, and 610 00:34:07,900 --> 00:34:10,500 then the other tests were going to be shutting down, you should 611 00:34:10,500 --> 00:34:14,600 consider kovan basically already, you know, very far down 612 00:34:14,600 --> 00:34:19,199 gets deprecation window and the shutdown soon, kill the merge It 613 00:34:19,199 --> 00:34:21,199 will be shut down right after the main net. 614 00:34:21,199 --> 00:34:24,100 Merge Rutherfordton will be shut down before the end of this 615 00:34:24,100 --> 00:34:26,699 year. And then rinkeby will probably 616 00:34:26,699 --> 00:34:30,600 be shut down sometime next year, but it'll be lagging behind me 617 00:34:30,600 --> 00:34:32,199 method. So it won't be like a great 618 00:34:32,400 --> 00:34:37,900 stage environment anymore. Okay, and this leads us in a 619 00:34:37,900 --> 00:34:40,900 developer. It's good to know. 620 00:34:41,000 --> 00:34:45,600 If you're a user you've been probably waiting to hear what is 621 00:34:45,600 --> 00:34:50,900 the merge Where Do We Stand now? Because we're talking about test 622 00:34:50,900 --> 00:34:54,900 Nets and test that merges. What happened today but I will 623 00:34:54,900 --> 00:34:56,600 just hand you the mic for a while. 624 00:34:57,100 --> 00:35:01,400 What's coming up? Yeah, and I guess I think this 625 00:35:01,400 --> 00:35:05,000 is it's useful to give a better contact felt like, like how did 626 00:35:05,000 --> 00:35:06,800 we get to, like, where we are today and then like, what are 627 00:35:06,800 --> 00:35:10,100 the next couple steps? But basically we've been testing 628 00:35:10,100 --> 00:35:13,700 the merge for over a year now. And if you count the launch of 629 00:35:13,700 --> 00:35:17,200 the beacon chain, it's like more like two and a half or so years. 630 00:35:17,600 --> 00:35:19,200 And like I mentioned earlier, you know, we launched this 631 00:35:19,200 --> 00:35:23,000 Beacon chain separately from the ethereum like application, 632 00:35:23,000 --> 00:35:25,900 proof-of-work chain, because at the time, is already a ton of 633 00:35:25,900 --> 00:35:28,000 usage on a theorem. And we wanted to make sure that 634 00:35:28,000 --> 00:35:31,300 it's like the We can chain worked and was stable and that 635 00:35:31,300 --> 00:35:34,000 if it wasn't they wouldn't break everything else on the theorem. 636 00:35:34,300 --> 00:35:38,400 So we launched it, and after I'd been up and running for a while, 637 00:35:38,400 --> 00:35:42,000 you know, we started to the Prototype like, okay, how are we 638 00:35:42,000 --> 00:35:44,400 going to actually combine these two networks together? 639 00:35:44,700 --> 00:35:47,000 And like, really early designs for this? 640 00:35:47,100 --> 00:35:50,800 Had like a migration as part of them, or like, users would have 641 00:35:50,800 --> 00:35:54,800 to move from one to the other and I just felt like, really bad 642 00:35:54,800 --> 00:35:57,400 user experience. We're ideally you don't want 643 00:35:57,400 --> 00:36:01,900 them to Have to do that. And it was this Insight in. 644 00:36:03,100 --> 00:36:06,900 Yeah, a few years ago that well, the clients, that run a, 645 00:36:06,900 --> 00:36:09,600 theorem, the proof of work chain today. 646 00:36:10,000 --> 00:36:13,200 They're already used to this concept of like different 647 00:36:13,200 --> 00:36:16,200 consensus algorithms. So, like we mentioned, you know, 648 00:36:16,200 --> 00:36:20,700 main that mean that uses uses proof of work but a lot of the 649 00:36:20,700 --> 00:36:23,700 test that's don't write. They use what we call proof of 650 00:36:23,700 --> 00:36:26,400 authority, you're just different consensus engines and similarly 651 00:36:26,400 --> 00:36:28,200 like a lot of Enterprise private networks. 652 00:36:28,200 --> 00:36:30,200 Also, Use like different consensus engines. 653 00:36:30,400 --> 00:36:33,300 And so there is this idea of like, well what if instead of 654 00:36:33,300 --> 00:36:36,500 moving all the applications over from like the proof-of-work tank 655 00:36:36,500 --> 00:36:39,300 to the beacon chain? We simply had like the software 656 00:36:39,300 --> 00:36:43,300 that's running all the applications change, what 657 00:36:43,300 --> 00:36:46,900 consensus algorithm it listens to you to get, like to get the 658 00:36:46,900 --> 00:36:48,900 consensus on the state of the network. 659 00:36:49,400 --> 00:36:53,000 And this is like that, the very high level design of the merge 660 00:36:53,000 --> 00:36:56,800 is that once we hit a certain point, the clients on the 661 00:36:56,800 --> 00:37:00,000 network, stop listening to proof of Work as a way to get the 662 00:37:00,000 --> 00:37:03,300 latest valid head for the for the blockchain and it started 663 00:37:03,300 --> 00:37:07,000 listening to the proof of stake Beacon chain and this means that 664 00:37:07,100 --> 00:37:10,100 you don't need to move all the applications over from one to 665 00:37:10,100 --> 00:37:12,800 the other. You can simply kind of use a 666 00:37:12,808 --> 00:37:17,100 different rule to tell you what was the latest Allan Block and 667 00:37:17,100 --> 00:37:20,100 keep kind of building on the existing existing chain. 668 00:37:21,400 --> 00:37:25,500 So we first prototype that in May of last year, there was like 669 00:37:25,500 --> 00:37:28,500 a hackathon and we got some of the client team. 670 00:37:28,600 --> 00:37:31,800 To get her to prototype. Like, could the post-merge 671 00:37:32,000 --> 00:37:35,300 architecture work, where you have a beacon chain clients, 672 00:37:35,300 --> 00:37:38,400 that kind of keeps track of the head and then they receive 673 00:37:38,400 --> 00:37:42,400 blocks and they send them down to their execution client, which 674 00:37:42,500 --> 00:37:45,100 runs the evm transactions. Make sure that those 675 00:37:45,100 --> 00:37:49,300 transactions are valid and then like confirms that or orphans 676 00:37:49,300 --> 00:37:52,100 the block, if not. So we prototype that in this 677 00:37:52,100 --> 00:37:54,900 hackathon, we got it to work. So that was like, good 678 00:37:54,900 --> 00:37:58,100 confirmation that like, this design was sound, you know, like 679 00:37:58,100 --> 00:38:00,800 with the What would the two clients talking to each other? 680 00:38:01,100 --> 00:38:04,700 Obviously it was a hackathon for a ton of bugs as we spent like 681 00:38:04,700 --> 00:38:08,900 last summer, fixing all those bugs and ironing out a design 682 00:38:10,200 --> 00:38:15,900 for like it, final architecture. And then last fall we prototyped 683 00:38:15,900 --> 00:38:18,100 the actual transition from like proof of work that proof of 684 00:38:18,100 --> 00:38:20,800 stake. So could you like start a 685 00:38:20,800 --> 00:38:23,500 network up on proof-of-work, started Beacon, Shane 686 00:38:23,500 --> 00:38:27,200 separately, and have them transition and you do not fall 687 00:38:27,200 --> 00:38:30,600 apart throughout and safely like finalized on the other side. 688 00:38:30,800 --> 00:38:34,200 So we got everyone in person actually for this for a week and 689 00:38:34,300 --> 00:38:36,700 after like a week of work we managed to get like a first 690 00:38:36,700 --> 00:38:40,600 prototype of that working where we launched a definite and it 691 00:38:40,600 --> 00:38:43,300 started on proof-of-work moved over to proof of stake and it's 692 00:38:43,300 --> 00:38:48,000 finalized on the other side. And so again, this was just like 693 00:38:48,000 --> 00:38:50,300 a week-long hackathon. So there were tons of bugs and 694 00:38:50,300 --> 00:38:54,100 issues, and we spent like all of the Fall after that fixing 695 00:38:54,100 --> 00:38:57,200 those. And by they see the Christmas 696 00:38:57,200 --> 00:39:01,400 holidays. We How to spec for, like the 697 00:39:01,400 --> 00:39:04,500 entire merge and post-merger Theorem, which we felt was like, 698 00:39:05,000 --> 00:39:08,500 pretty stable, like not perfect but, you know, roughly, right? 699 00:39:08,500 --> 00:39:10,700 So we launched. Its first test, is called can 700 00:39:10,700 --> 00:39:14,100 Sugi, right? Like late, December. 701 00:39:14,700 --> 00:39:18,900 And this was just like, give people an idea of like what 702 00:39:18,900 --> 00:39:21,700 post-merge etherium would look like for us to reach out the 703 00:39:21,700 --> 00:39:24,100 infrastructure providers and application developers to make 704 00:39:24,100 --> 00:39:27,400 sure that like, you know, things didn't break when they were 705 00:39:27,400 --> 00:39:30,200 using it then, and And we got that confirmation. 706 00:39:30,600 --> 00:39:33,000 We also run a bunch of stress tests on the network like 707 00:39:33,000 --> 00:39:36,900 spammed it and put nodes and weird States and we found doing 708 00:39:36,900 --> 00:39:38,800 that. We found some, some edge cases 709 00:39:38,800 --> 00:39:41,800 in this spec. So we fixed all of those and in 710 00:39:41,800 --> 00:39:44,800 March, we launched this killed test net, which I mentioned 711 00:39:44,800 --> 00:39:50,000 earlier which which was basically like call it like 95% 712 00:39:50,000 --> 00:39:53,400 final spec for the merge. So we've done some small tweaks 713 00:39:53,400 --> 00:39:57,600 to this text since then, but no like big substantive changes. 714 00:39:58,700 --> 00:40:01,600 They've mostly been either like clarifications or just, you 715 00:40:01,600 --> 00:40:04,600 know, some edge cases that like a subset of clients were hitting 716 00:40:04,600 --> 00:40:08,000 and whatnot, but like, the overall like functionality has 717 00:40:08,000 --> 00:40:13,000 stayed the same since then. And after after launching Kiln, 718 00:40:13,700 --> 00:40:16,600 we still felt like it would be good to get like some more 719 00:40:16,600 --> 00:40:18,500 practice runs because you learn a lot. 720 00:40:18,500 --> 00:40:22,100 Like, when the network runs through the merge and it's a bit 721 00:40:22,100 --> 00:40:24,900 weird in a way because this is code that only has to run once 722 00:40:24,900 --> 00:40:27,400 on Main meth. And there's like a ton of 723 00:40:27,400 --> 00:40:29,900 complexity there. But in one summer just happened, 724 00:40:29,900 --> 00:40:32,000 you know, you never need to run through the transition again. 725 00:40:32,100 --> 00:40:36,400 So we wanted to make sure we got like as many kind of runs of 726 00:40:36,400 --> 00:40:38,500 that as possible. And we started doing these 727 00:40:38,500 --> 00:40:42,300 things called Shadow Forks, which are basically hard Forks 728 00:40:42,700 --> 00:40:47,000 where we only launched a small number of nodes, controlled by 729 00:40:47,000 --> 00:40:50,700 my client and testing teams which which have the hard fork 730 00:40:51,400 --> 00:40:53,100 and then we see how it goes for them. 731 00:40:53,300 --> 00:40:55,500 So you can think of this like, you know, there's like thousands 732 00:40:55,500 --> 00:40:57,400 of nodes on like the theorem Network. 733 00:40:57,500 --> 00:41:01,400 Well, we take like, 10 to 100, we spin them up and we tell 734 00:41:01,400 --> 00:41:04,700 those like small number of nodes, I hate emerges happening 735 00:41:04,700 --> 00:41:08,400 here and then we actually run through the merge on those nodes 736 00:41:08,700 --> 00:41:12,100 and see what happens. And, and for a couple days, 737 00:41:12,100 --> 00:41:14,700 also, we can replace transactions from Main methods. 738 00:41:14,700 --> 00:41:18,200 Well, so we get to see, not only like running through the merge 739 00:41:18,200 --> 00:41:21,400 on maintenance but also our denotes table afterwards, you 740 00:41:21,400 --> 00:41:23,200 know, can you still sink and whatnot. 741 00:41:23,800 --> 00:41:26,000 So we've been doing these shadow Forks over and over. 742 00:41:26,000 --> 00:41:28,200 I think we had like our 11th or 12th one. 743 00:41:28,700 --> 00:41:31,600 Earlier this week. So basically, like every week 744 00:41:31,600 --> 00:41:34,700 since since like late March, if not multiple times a week 745 00:41:34,700 --> 00:41:38,200 sometimes, and that's been really good that help us test 746 00:41:38,200 --> 00:41:42,900 like not only every client implementation but also every 747 00:41:43,100 --> 00:41:46,500 pair wise combination. So earlier we mentioned, you 748 00:41:46,500 --> 00:41:49,200 know, there's like these clients that work on the execution 749 00:41:49,200 --> 00:41:51,300 chain, these crimes. That work on the beacon chain, 750 00:41:52,000 --> 00:41:54,500 there's four on one side. Five on the other this means 751 00:41:54,500 --> 00:41:58,100 there's like, 20 pairwise combinations of like, one 752 00:41:58,100 --> 00:41:59,900 Beacon. Then what, execution time that 753 00:41:59,900 --> 00:42:01,900 you can get. And so the shadow Forks we 754 00:42:01,900 --> 00:42:05,900 basically passed every single possible permutation and we want 755 00:42:05,900 --> 00:42:08,800 to make sure that they all work and then we find, you know, when 756 00:42:08,800 --> 00:42:11,100 we find bugs we obviously fix them. 757 00:42:11,400 --> 00:42:14,700 And this is roughly like we're, we were like a month or two ago 758 00:42:15,600 --> 00:42:18,900 and now we've, you know, we feel like much more confident than 759 00:42:18,900 --> 00:42:23,200 liked it. The the Readiness of the code 760 00:42:23,200 --> 00:42:26,700 we're not like 100% there yet, but you know, we felt ready 761 00:42:26,700 --> 00:42:28,500 enough that it made sense to start. 762 00:42:28,700 --> 00:42:32,400 Working the like long-lived tests on a theorem and there 763 00:42:32,400 --> 00:42:33,500 were a couple of reasons for that. 764 00:42:33,600 --> 00:42:36,500 The first is like, which Rob's then we mentioned earlier. 765 00:42:36,500 --> 00:42:38,600 Like it's quite a chaotic test, it's already. 766 00:42:38,600 --> 00:42:42,000 So it was even if like something went wrong. 767 00:42:42,000 --> 00:42:45,000 It wasn't the end of the world, but we also wanted to give end 768 00:42:45,000 --> 00:42:48,200 users, like people running validators at home, the chance 769 00:42:48,200 --> 00:42:51,600 to run through like emerge. Basically because all these 770 00:42:51,600 --> 00:42:54,600 shadow Forks, the nodes are basically controlled by client 771 00:42:54,600 --> 00:42:57,600 teams and testing teams. But it's not open to anyone to 772 00:42:57,600 --> 00:42:59,800 run a node. So we have this first Roxton 773 00:42:59,800 --> 00:43:02,900 Fork where we had, we had like a new Pekin chain launch for 774 00:43:02,900 --> 00:43:06,100 Rustin and anyone could join that. 775 00:43:06,400 --> 00:43:10,000 And yeah, I'm on that. You know, we had people for this 776 00:43:10,000 --> 00:43:13,600 faith and the network moved over and generally the transition 777 00:43:13,600 --> 00:43:15,500 went well. So that was good. 778 00:43:15,500 --> 00:43:20,200 We found some couple bugs that's been fixed and then today we ran 779 00:43:20,200 --> 00:43:22,600 through the second test and that's that polio and the goal 780 00:43:22,600 --> 00:43:25,300 there was to make sure it was like the bugs, you know, the 781 00:43:25,308 --> 00:43:28,300 bugs on Robson wouldn't show up again and we're still worse. 782 00:43:28,700 --> 00:43:31,100 You generally looks like the fork went well but we're still 783 00:43:31,100 --> 00:43:34,300 digging into the details and coming through everything. 784 00:43:34,900 --> 00:43:37,800 Once we have that we basically have one more test net to do 785 00:43:37,800 --> 00:43:40,700 before May Nets and this is gorney with the printer Beacon 786 00:43:40,700 --> 00:43:42,600 chain and this is a test Network. 787 00:43:42,600 --> 00:43:46,500 You know, we really want things to be quite ready because this 788 00:43:46,500 --> 00:43:49,900 is where the majority of stagers are like expected to like run 789 00:43:49,900 --> 00:43:54,100 through the transition with their set up in anticipation of 790 00:43:54,100 --> 00:43:56,600 maenette and it has a ton of activity as well. 791 00:43:56,600 --> 00:43:58,400 So it's not a test that we wanted to. 792 00:43:58,600 --> 00:44:02,000 The break. So once, you know, we once we've 793 00:44:02,000 --> 00:44:05,100 like, debriefed on this supposedly a fork and and see 794 00:44:05,100 --> 00:44:07,500 whether there's any issues we need to fix or address. 795 00:44:08,100 --> 00:44:11,700 What we'll start scheduling and Gordy and then ones Gordy 796 00:44:11,700 --> 00:44:14,400 happens. Assuming it goes well then we 797 00:44:14,400 --> 00:44:18,500 would look at scheduling the fork for magnet and the goal is 798 00:44:18,500 --> 00:44:20,900 really just to get as many like dry runs. 799 00:44:20,900 --> 00:44:25,200 As we can in the increasingly complex scenarios where if you 800 00:44:25,200 --> 00:44:28,200 start super complex room to slide from the start, you're 801 00:44:28,200 --> 00:44:30,400 going to hit Bunch of issues. It could be really hard to find 802 00:44:30,400 --> 00:44:33,200 a root cause but if you start with like the small Dev Nets 803 00:44:33,200 --> 00:44:35,700 that you like increased complexity over and over, you 804 00:44:35,700 --> 00:44:39,300 always liked fixing bugs at like the edge of like the complexity 805 00:44:39,300 --> 00:44:43,300 and it just makes it much harder to much easier, sorry to fix 806 00:44:43,300 --> 00:44:45,200 those bugs. If you're, if you're increasing 807 00:44:45,200 --> 00:44:48,200 complexity as you go. Yeah, in short. 808 00:44:48,200 --> 00:44:51,200 It's like, yeah, we spent the past year testing, we've done 809 00:44:51,200 --> 00:44:54,200 one more test net. Today, there's one left and 810 00:44:54,300 --> 00:44:56,600 assuming things go, well, go. Well on that one. 811 00:44:56,600 --> 00:45:03,200 We'd move to my nut. So to recap, that merge 812 00:45:03,200 --> 00:45:06,400 specific, Dev Nets, long-standing merge specific 813 00:45:06,400 --> 00:45:10,800 Testaments in line with these shadow Forks, upgrade, the 814 00:45:10,800 --> 00:45:13,800 long-standing ethereum test Nets that we covered earlier. 815 00:45:14,100 --> 00:45:18,500 And then maenette, with one more long-standing test, net left to 816 00:45:18,500 --> 00:45:21,800 go, and that's girly. That's correct. 817 00:45:21,800 --> 00:45:23,900 Yep. And then Gordy with the Prater 818 00:45:23,900 --> 00:45:27,500 Beacon chain and we'll just call it all Gordy after it emerged. 819 00:45:29,000 --> 00:45:33,600 So what do you look for in a successful merge and when it's 820 00:45:33,600 --> 00:45:37,200 done what's next? So, I know that a lot of work 821 00:45:37,200 --> 00:45:40,800 has been done on Shanghai, and a lot of those listening would 822 00:45:40,800 --> 00:45:43,700 probably be curious about. So there's some misconceptions 823 00:45:43,700 --> 00:45:45,700 about the merge and I'm sure you're probably very familiar 824 00:45:45,700 --> 00:45:50,500 with and can speak to from token on blocks to scalability. 825 00:45:51,200 --> 00:45:57,100 And some of those things are covered in the next sort of set 826 00:45:57,100 --> 00:46:00,600 of upgrades that come after So what's left coming up until the 827 00:46:00,600 --> 00:46:02,600 merge? And what comes next? 828 00:46:04,100 --> 00:46:06,700 Coming up until the merge is basically we want to monitor 829 00:46:06,700 --> 00:46:09,800 these tests Nets like not only right after but also like you 830 00:46:09,800 --> 00:46:13,000 know call it a week after so that we can still sink notes to 831 00:46:13,000 --> 00:46:16,600 them and things work work well. And you know we have a whole 832 00:46:16,600 --> 00:46:19,300 slew of metrics that we look at like from some pretty basic 833 00:46:19,300 --> 00:46:23,900 stuff like our blocks being produced to like you know are 834 00:46:23,900 --> 00:46:27,300 like transaction fees for every transaction being routed to the 835 00:46:27,300 --> 00:46:29,400 right way. So it's you know now let's read 836 00:46:29,400 --> 00:46:31,500 just combing through all these metrics and making sure that 837 00:46:31,500 --> 00:46:33,800 like things are looking good and fixing anything. 838 00:46:33,900 --> 00:46:37,100 Or it isn't. And then when we fix things, you 839 00:46:37,100 --> 00:46:39,900 know, if we find a bug, well, typically, then write a test for 840 00:46:39,900 --> 00:46:44,100 it and then run all the clients through this test Suite, because 841 00:46:44,100 --> 00:46:46,500 it's possible that it's just like, you know, one client, it's 842 00:46:46,500 --> 00:46:50,300 something during during emerge, but then all the clients 843 00:46:50,300 --> 00:46:52,500 actually had the bug, it just happened, not to hit it. 844 00:46:52,600 --> 00:46:55,300 And so that it's like, it's really like fine calming through 845 00:46:55,300 --> 00:46:59,000 that and then if you know if you look out and you assume the 846 00:46:59,000 --> 00:47:00,700 virgin's happen and we're all good. 847 00:47:00,900 --> 00:47:03,100 Yeah. There's obviously more things on 848 00:47:03,100 --> 00:47:06,200 the etheric realm. But beyond that, and maybe the 849 00:47:06,200 --> 00:47:09,700 first that you hinted at, is this idea of like Beacon Cheng 850 00:47:09,700 --> 00:47:12,400 withdrawals. So because the merge is like the 851 00:47:12,400 --> 00:47:15,700 most complicated upgrade we've done to a theorem since probably 852 00:47:15,700 --> 00:47:19,400 launching a theorem. We tried to cut down anything 853 00:47:19,400 --> 00:47:22,800 that wasn't absolutely critical from it just so we can have like 854 00:47:22,800 --> 00:47:26,200 the smallest possible set of changes which is already a 855 00:47:26,600 --> 00:47:31,600 pretty big set of changes and and and the the the biggest like 856 00:47:31,600 --> 00:47:33,700 cut that is the ability for validators. 857 00:47:33,900 --> 00:47:37,700 Withdraw their Stakes back to to the execution layer. 858 00:47:37,700 --> 00:47:39,500 So the like Foley exit as a validator. 859 00:47:40,200 --> 00:47:41,700 So that's like the first big feature. 860 00:47:41,700 --> 00:47:45,300 We're planning for after the merge typically, when we have 861 00:47:45,300 --> 00:47:49,100 these hard forks with, with new features will introduce more 862 00:47:49,100 --> 00:47:50,400 than one. So there's a bunch of other 863 00:47:50,400 --> 00:47:52,900 proposals as well, but that's the stuff will be. 864 00:47:52,900 --> 00:47:55,200 It will be working on right after one thing. 865 00:47:55,200 --> 00:47:58,300 I'll note though with regards to validators and withdrawals is 866 00:47:58,300 --> 00:48:01,700 while validators, won't be able to withdraw like they're their 867 00:48:01,700 --> 00:48:03,700 Stakes after the merge like the 32. 868 00:48:03,800 --> 00:48:08,600 Heath + like the rewards they've accrued as soon as the merge 869 00:48:08,600 --> 00:48:10,900 happens. Validators will receive 870 00:48:10,900 --> 00:48:14,700 transaction fees that currently go to minors and they'll be 871 00:48:14,700 --> 00:48:19,300 receiving that on the execution layer itself. 872 00:48:19,300 --> 00:48:23,400 So they won't, they won't be locked. 873 00:48:23,400 --> 00:48:25,600 Like, validators are on the Deacon. 874 00:48:25,600 --> 00:48:27,200 Shame. So this is kind of neat. 875 00:48:27,200 --> 00:48:31,000 So if you are a sticker or even like using your stinking pool or 876 00:48:31,000 --> 00:48:33,100 something, you will start accruing. 877 00:48:34,500 --> 00:48:40,700 The non bird part of transaction fees, right after the merge. so 878 00:48:40,700 --> 00:48:43,800 let's talk about what happened, just just a couple of minutes 879 00:48:43,800 --> 00:48:49,000 ago, but an hour ago, the the cipolla emerge can you can you 880 00:48:49,000 --> 00:48:52,000 talk about that and in the context of like sort of a you 881 00:48:52,000 --> 00:48:57,000 know, this this broader roadmap and how significant it is to the 882 00:48:57,000 --> 00:49:03,200 broader merge efforts Yeah. So like we were saying, it's 883 00:49:03,200 --> 00:49:07,200 like the second out of three tests nuts and it is like this 884 00:49:07,200 --> 00:49:11,500 new one, which we hope to keep stable and the, the validators 885 00:49:11,500 --> 00:49:15,500 on this network are like a set of, you know, climb teams 886 00:49:15,500 --> 00:49:17,400 testing teams, infrastructure providers. 887 00:49:17,500 --> 00:49:22,900 So it's not, it's not like quite anyone like we because we want 888 00:49:23,300 --> 00:49:24,800 we want this network to be stable. 889 00:49:24,800 --> 00:49:29,200 We basically opened it the like any individual or entity that 890 00:49:29,200 --> 00:49:30,600 can come. It's the running state 891 00:49:30,800 --> 00:49:34,600 Validators over a long period of time but it is not just like a 892 00:49:34,600 --> 00:49:37,600 web page where you can sign up and launch a validator like 893 00:49:37,600 --> 00:49:40,300 there is for Prater. So this was like a good test 894 00:49:40,300 --> 00:49:41,500 because it's like it shows us. Okay. 895 00:49:41,500 --> 00:49:45,500 Like there is still like some group of like this think 896 00:49:45,500 --> 00:49:49,600 entities and individuals that need to coordinate and and debug 897 00:49:49,600 --> 00:49:54,800 things but it's still not as open as like the the Prater you 898 00:49:54,800 --> 00:49:57,300 can chain or maintenance. So yeah. 899 00:49:57,300 --> 00:50:00,000 It's like it increases like the complexity of things. 900 00:50:01,800 --> 00:50:03,900 You know, because we're on this, this this call. 901 00:50:03,900 --> 00:50:08,300 I haven't liked the digging through all the the specific 902 00:50:08,300 --> 00:50:12,400 things that happen but a lot of high-level right before I jumped 903 00:50:12,400 --> 00:50:16,000 on it seem like you know the network was relatively stable, 904 00:50:16,100 --> 00:50:19,500 there were some parts of validators that's hit like some 905 00:50:19,500 --> 00:50:22,300 some issues or were offline and it seems like folks are still 906 00:50:22,300 --> 00:50:25,200 looking into that but well, no better than like the next couple 907 00:50:25,200 --> 00:50:26,900 days. Like, you know what types of 908 00:50:26,900 --> 00:50:29,000 bugs that we hit, where they boarded bugs. 909 00:50:29,000 --> 00:50:31,500 Were they actually just like, And issues. 910 00:50:31,900 --> 00:50:34,300 So, if their configuration issues is actually quite good 911 00:50:34,300 --> 00:50:37,100 because it's like, you know, called is like operator error 912 00:50:37,200 --> 00:50:39,900 rather than the like protocol problems. 913 00:50:39,900 --> 00:50:43,500 So that seat, you can just restart the validators, the 914 00:50:43,500 --> 00:50:45,400 wrong with the right configs, and it works. 915 00:50:46,300 --> 00:50:48,600 So that's what we're looking at. I think once we have a clear 916 00:50:48,600 --> 00:50:50,800 picture, there will start thinking about. 917 00:50:50,800 --> 00:50:53,600 Okay, when do we want to Fork this last test net? 918 00:50:54,600 --> 00:50:56,900 I think our bar for the last test, net will be higher because 919 00:50:56,900 --> 00:51:00,000 we want to make sure that like, any Staker can run through it. 920 00:51:00,000 --> 00:51:04,000 And that it's Like as close to my net as as possible. 921 00:51:05,000 --> 00:51:07,200 And then yeah, assuming that goes well then we would we would 922 00:51:07,200 --> 00:51:13,100 then move to merge magnet. And so this next test net, 923 00:51:13,100 --> 00:51:18,300 anybody, anybody would be able to run a validator on this on 924 00:51:18,300 --> 00:51:22,100 this on the next Testament. Yeah. 925 00:51:22,100 --> 00:51:25,200 Yeah and you can already right like so you don't need to wait 926 00:51:25,200 --> 00:51:27,500 for the Verge. You can literally go and like 927 00:51:27,500 --> 00:51:32,000 register validator on Prater and and have it the up and ready for 928 00:51:32,000 --> 00:51:37,000 the merge. And if if you want to also run a 929 00:51:37,000 --> 00:51:40,600 post-merge validator right now, you can do so on rough stdin. 930 00:51:40,800 --> 00:51:44,400 So rough said has merged and so you won't run through the actual 931 00:51:44,400 --> 00:51:46,200 transition. But if you want to figure out, 932 00:51:46,200 --> 00:51:49,000 okay, how do I configure my validator so that like I 933 00:51:49,008 --> 00:51:52,500 actually get transaction fees and like, And some validators. 934 00:51:52,500 --> 00:51:54,600 For example. Today, it is possible to use a 935 00:51:54,600 --> 00:51:57,900 third-party provider. Instead of running an execution 936 00:51:57,900 --> 00:52:01,200 there node to track deposits. After the merge, it won't be 937 00:52:01,200 --> 00:52:03,700 possible to do so. So if you've been using, say in 938 00:52:03,700 --> 00:52:06,500 for our Alchemy, but your beacon chain, clients to track 939 00:52:06,500 --> 00:52:09,000 deposits. You can't do that after the 940 00:52:09,000 --> 00:52:10,500 merge. So you need to figure out, okay, 941 00:52:10,500 --> 00:52:13,000 how do I run? You know base, you never mind, 942 00:52:13,000 --> 00:52:18,200 get Aragon and you can do all that on Roxton today and 943 00:52:18,200 --> 00:52:20,600 register a validator and make sure that it's working. 944 00:52:21,200 --> 00:52:22,900 Yeah. Cool. 945 00:52:23,000 --> 00:52:27,700 So as we wrap up here, I think it would be interesting to maybe 946 00:52:27,700 --> 00:52:34,100 talk a little bit about about scaling and you know how like 947 00:52:34,100 --> 00:52:38,100 how post-merge, what's Caitlin we look like post-merge? 948 00:52:38,300 --> 00:52:42,300 And you know I think it's interesting that you know a 949 00:52:42,300 --> 00:52:46,700 theorem is taking this data, availability approach and 950 00:52:46,700 --> 00:52:51,600 allowing sort of like ecosystem change to build on top of this 951 00:52:51,600 --> 00:52:53,300 on. This on top of this base layer, 952 00:52:55,300 --> 00:52:59,400 what is what is your view about? Like what this ecosystem will 953 00:52:59,400 --> 00:53:03,900 look like post-merge you know, where will cover the majority of 954 00:53:03,900 --> 00:53:07,300 applications live. And, and I think one 955 00:53:07,300 --> 00:53:10,900 interesting, one interesting thing maybe also to consider is 956 00:53:12,200 --> 00:53:14,300 what are some of the interoperability. 957 00:53:16,500 --> 00:53:19,000 I mean beyond the, unlike bridging instance, things like 958 00:53:19,000 --> 00:53:20,700 that. Like are what is the word, the 959 00:53:20,700 --> 00:53:24,400 the work being done on a Need to ensure that all these different 960 00:53:24,800 --> 00:53:28,700 Roll-Ups and like chains built on top of the data. 961 00:53:28,700 --> 00:53:32,800 Availability layer will be able to talk to each other and like 962 00:53:33,100 --> 00:53:34,900 do cross chain calls and stuff like that. 963 00:53:36,500 --> 00:53:40,300 I think you know, over time in terms of just like designing if 964 00:53:40,300 --> 00:53:45,100 they them there's been this this like Evolution where it's like 965 00:53:45,100 --> 00:53:47,800 if you compare a theorem when it launched a Bitcoin, it was like 966 00:53:47,800 --> 00:53:51,800 this maximally complex blockchain relative to fit quite 967 00:53:51,800 --> 00:53:55,900 right where you know it concerns itself with like arbitrary 968 00:53:55,900 --> 00:53:58,200 computation and state and whatnot. 969 00:53:58,900 --> 00:54:01,400 I think obviously the blockchains landscape has 970 00:54:01,400 --> 00:54:06,600 evolved a ton since them and and like the kind of design See in a 971 00:54:06,600 --> 00:54:10,000 way for theorem has has kind of shifted the like okay what is 972 00:54:10,000 --> 00:54:12,000 the actual minimal set of things? 973 00:54:12,000 --> 00:54:17,000 We can provide with the highest level of security, which dead 974 00:54:17,000 --> 00:54:21,700 enable people to build, you know, applications scaling 975 00:54:21,700 --> 00:54:24,100 Solutions and whatnot that depend on them. 976 00:54:24,600 --> 00:54:27,600 And so, you know, like one very obvious shift is I decided that 977 00:54:27,600 --> 00:54:31,000 ethereum originally wanted to do something called execution 978 00:54:31,000 --> 00:54:35,400 charting where there's a bunch of like L1 shards which each 979 00:54:35,400 --> 00:54:38,100 process comp A patient and parallel that are like 980 00:54:38,600 --> 00:54:41,200 management protocol. And we've moved to this world 981 00:54:41,200 --> 00:54:45,900 where well instead, we'd rather allow like a free market of like 982 00:54:46,000 --> 00:54:50,400 solutions to emerge and use etherium as like more of a 983 00:54:50,400 --> 00:54:53,100 settlement layer in this would be seen with with l2's today. 984 00:54:53,800 --> 00:54:57,400 And this is how, you know, we think about like scaling is the 985 00:54:57,400 --> 00:54:59,900 l 1 chain. Like, I mean the capacity will 986 00:54:59,900 --> 00:55:03,600 keep improving and there's some stuff we can do but like it will 987 00:55:03,600 --> 00:55:07,600 not improve as quickly. As like the demand for Block 988 00:55:07,600 --> 00:55:11,600 space grows, you know, so if you imagine we improve the capacity 989 00:55:11,600 --> 00:55:15,800 like 10x or 100x over to next like five ten years, the men for 990 00:55:15,800 --> 00:55:17,900 blockchain might grow like 100,000 x, right? 991 00:55:17,900 --> 00:55:21,400 Like we need like several orders of magnitude more and this is 992 00:55:21,400 --> 00:55:22,800 where things like basically layer. 993 00:55:22,800 --> 00:55:28,500 Choose can't provide that. And so, and the way layer 2's 994 00:55:28,500 --> 00:55:32,500 work, like, at a very high level, is that they trade off 995 00:55:32,500 --> 00:55:35,700 this asymmetry, we're on etherium. 996 00:55:36,200 --> 00:55:40,600 It's like very expensive to run computation, but fairly cheap to 997 00:55:40,600 --> 00:55:45,700 store data, whereas on an L2 is actually quite cheap to run 998 00:55:45,700 --> 00:55:48,100 computations. So if you can run all your 999 00:55:48,100 --> 00:55:53,200 computations on L2 and post like some data about them back to L1 1000 00:55:53,600 --> 00:55:57,200 that allows you to, like, lower your fees a ton because you're 1001 00:55:57,200 --> 00:56:01,500 just running all these computations and not actually 1002 00:56:01,500 --> 00:56:04,500 running much on a theorem L1 +, ZK, Roll-Ups and optimistic, 1003 00:56:04,500 --> 00:56:07,400 Roll-Ups differ and how like, They approach this but a high 1004 00:56:07,400 --> 00:56:09,700 level it's like this is a symmetry between the cost of 1005 00:56:09,700 --> 00:56:12,400 like running operations versus posting data. 1006 00:56:13,100 --> 00:56:17,000 And so if we could get scaling solutions, that just run those, 1007 00:56:17,000 --> 00:56:20,700 computations off chain, either, like run like some proofs on 1008 00:56:20,700 --> 00:56:24,200 chain or some some disputes on chain but in mostly post data 1009 00:56:24,400 --> 00:56:27,600 that allows like for way cheaper transaction fees and for more 1010 00:56:27,600 --> 00:56:31,100 scale. And so today when these these 1011 00:56:31,100 --> 00:56:34,300 Roll-Ups and scaly institutions pose that about to aetherium, 1012 00:56:34,500 --> 00:56:37,400 the only mechanism they have to do so So is like storing data in 1013 00:56:37,400 --> 00:56:40,700 the blockchain forever. And this has like two to 1014 00:56:40,700 --> 00:56:43,100 consequences. One is like every single note on 1015 00:56:43,100 --> 00:56:47,100 the chain needs to process that data and to the, the hold on to 1016 00:56:47,100 --> 00:56:50,400 it basically forever. And so that means that like it's 1017 00:56:50,700 --> 00:56:55,600 it's still fairly expensive to store data on a theorem and so 1018 00:56:55,600 --> 00:56:59,200 when you pay for like a transaction on a layer to most 1019 00:56:59,200 --> 00:57:01,900 of the cost, you actually paying is to store this data back on 1020 00:57:01,900 --> 00:57:04,200 the theorem. The first thing we could do 1021 00:57:04,200 --> 00:57:06,000 there is like, okay, well how do we make it cheaper? 1022 00:57:06,200 --> 00:57:09,300 For data on other theory of because that doesn't mean it's 1023 00:57:09,300 --> 00:57:12,400 like cheaper for all these Roll-Ups that could be built and 1024 00:57:12,500 --> 00:57:16,300 or conversely that they can, like, accommodate more demand 1025 00:57:16,300 --> 00:57:18,300 for the same price and therefore scale. 1026 00:57:19,400 --> 00:57:21,700 And one thing about the Roll-Ups is, they don't actually need 1027 00:57:21,700 --> 00:57:24,600 this data to be stored Forever on the network. 1028 00:57:24,700 --> 00:57:28,300 They only needed to be posted on the network and available for 1029 00:57:28,300 --> 00:57:33,300 like some amount of time such that people can like, agree that 1030 00:57:33,300 --> 00:57:35,200 it was there and then it was correct. 1031 00:57:35,300 --> 00:57:38,900 And if If it is not correct have like a reasonable amount of time 1032 00:57:38,900 --> 00:57:43,900 to dispute it and typically this is on the order of like a week 1033 00:57:43,900 --> 00:57:46,300 more or less. So there's this like exception 1034 00:57:46,300 --> 00:57:48,900 within Roll-Ups that like, if the data has been made available 1035 00:57:48,900 --> 00:57:53,100 for roughly a week, it gives time for people to like, sanity 1036 00:57:53,100 --> 00:57:57,700 check it, make sure that there's no, like either malicious or 1037 00:57:57,700 --> 00:58:02,000 buggy transactions, or like mismatch between what the hell. 1038 00:58:02,000 --> 00:58:05,500 Two things is the state of the world and what L1 thinks the LT 1039 00:58:05,500 --> 00:58:08,700 state of the world? Is and if that happens that it's 1040 00:58:08,700 --> 00:58:10,800 fine. And so this is really the window 1041 00:58:10,800 --> 00:58:14,000 where like you want to provide like really strong security 1042 00:58:14,000 --> 00:58:17,900 guarantees around this data, this short period of time and 1043 00:58:17,900 --> 00:58:21,500 after that you almost like don't really need to provide much 1044 00:58:21,500 --> 00:58:25,400 because you can assume that all if there was a dispute it would 1045 00:58:25,400 --> 00:58:27,600 have been resolved. And and if somebody wanted to 1046 00:58:27,607 --> 00:58:29,900 make a copy of the data that they could have done so already. 1047 00:58:31,300 --> 00:58:33,400 And so this is where we get it to like this idea of data 1048 00:58:33,400 --> 00:58:36,200 availability. Which is say like, what if If 1049 00:58:36,200 --> 00:58:39,400 instead of just having these l2's store data on the 1050 00:58:39,400 --> 00:58:43,100 blockchain forever, they simply post it to another place where 1051 00:58:43,700 --> 00:58:47,000 still secured by etherium, but we don't guarantee this data is 1052 00:58:47,000 --> 00:58:49,400 available forever. We guarantee it's available 1053 00:58:49,400 --> 00:58:51,600 roughly like for how long roll ups. 1054 00:58:51,600 --> 00:58:54,800 Need it with some buffer, you know, on each side. 1055 00:58:55,000 --> 00:58:57,400 So like I was saying, you know, Roll-Ups usually need to stay 1056 00:58:57,400 --> 00:59:00,400 left for the order of like a week and like the proposals for 1057 00:59:00,400 --> 00:59:03,300 theorem right now is like what if we just provided a way to 1058 00:59:03,300 --> 00:59:06,000 make data available for like the order of like a month? 1059 00:59:06,200 --> 00:59:08,900 Or something. So it's like, you know, even if 1060 00:59:08,900 --> 00:59:11,900 it's even if you needed within a week, yeah, like maybe you need 1061 00:59:11,900 --> 00:59:13,900 to sink a node. Literally, you know, you need to 1062 00:59:13,900 --> 00:59:17,500 go buy a computer, get an internet connection setup, get 1063 00:59:17,500 --> 00:59:21,000 the guy come to your house, set it up, stick your node and and 1064 00:59:21,000 --> 00:59:23,700 you know this extra buffer would give you enough time that like 1065 00:59:23,800 --> 00:59:26,400 you could still recuperate student data that's way. 1066 00:59:26,800 --> 00:59:29,300 And so this is when we talk about like Proto, thanks Char. 1067 00:59:29,300 --> 00:59:30,200 Take. This is roughly. 1068 00:59:30,200 --> 00:59:34,100 The idea is what if we added like just a daily component on 1069 00:59:34,100 --> 00:59:36,000 the theorem, which is like affair? 1070 00:59:36,100 --> 00:59:39,800 Emeril but still highly secure but then you can charge less for 1071 00:59:39,800 --> 00:59:43,500 this data component because you're not, you're not basically 1072 00:59:43,500 --> 00:59:46,400 incurring a forever storage cause you incurring like a 1073 00:59:46,408 --> 00:59:49,800 short, duration, storage cost, and then the next level beyond 1074 00:59:49,800 --> 00:59:54,000 that is, what if instead of having all the nodes on the 1075 00:59:54,000 --> 00:59:58,000 network in cure this like short-term storage costs, you 1076 00:59:58,000 --> 01:00:02,800 could scale the amount of data that you're storing have nodes 1077 01:00:02,800 --> 01:00:06,600 Only Store subset of it but then get like a really Hi, 1078 01:00:06,600 --> 01:00:10,700 probabilistic guarantee that the rest of the data is available on 1079 01:00:10,700 --> 01:00:13,200 the network. And this is like, when we talk 1080 01:00:13,200 --> 01:00:16,100 about like full sharding, fourth area, more like, dang sharding, 1081 01:00:16,100 --> 01:00:18,700 which is like the latest spec for it, this is what it means. 1082 01:00:18,700 --> 01:00:21,500 Is we take this this infrastructure that we have the 1083 01:00:21,500 --> 01:00:24,800 store, like it ephemeral amount of data. 1084 01:00:25,500 --> 01:00:28,800 But instead of having every node store, a full copy of all the 1085 01:00:28,800 --> 01:00:34,500 data, you have every node Source a subset of it and do some like 1086 01:00:34,500 --> 01:00:39,000 cryptographic checks, Across the peer-to-peer Network to ensure 1087 01:00:39,000 --> 01:00:42,600 that other nodes are storing the rest of the day. 1088 01:00:42,600 --> 01:00:45,200 That would like a really, really high probabilities. 1089 01:00:45,200 --> 01:00:46,200 Right? Like thank you though. 1090 01:00:46,400 --> 01:00:49,300 There's like I don't know if it's like in the billions or 1091 01:00:49,300 --> 01:00:52,000 trillions but like there's an incredibly low chance of like 1092 01:00:52,000 --> 01:00:54,400 some amount of data would be would be unavailable on the 1093 01:00:54,400 --> 01:00:57,400 network and because basically, by doing that, you're able to 1094 01:00:57,400 --> 01:01:01,300 scale roughly by another order of magnitude, the amount of data 1095 01:01:01,300 --> 01:01:04,000 that you have. And then those, those cost 1096 01:01:04,000 --> 01:01:08,500 savings or like, basically, K-league bandwidth gets passed 1097 01:01:08,500 --> 01:01:12,100 on for layer choose and other solutions that help. 1098 01:01:12,900 --> 01:01:17,500 And so this is like roughly. The vision is just like, can we 1099 01:01:17,800 --> 01:01:21,700 hone in on the parts where security matter to most and like 1100 01:01:21,700 --> 01:01:25,200 put all of our efforts there and provide like these incredibly 1101 01:01:25,200 --> 01:01:29,100 high like security assurances that this data, you know, was 1102 01:01:29,100 --> 01:01:31,500 made available that this data was like correct and that the 1103 01:01:31,500 --> 01:01:35,600 network came to consensus on it. But then after that kind of 1104 01:01:36,100 --> 01:01:39,600 Outsource the, like, the community into the ecosystem, 1105 01:01:40,000 --> 01:01:42,900 like ways to store manage that data. 1106 01:01:42,900 --> 01:01:46,000 And you know, you're at a point was around like, like crossed, 1107 01:01:46,500 --> 01:01:49,800 you know, L to Communications and stuff like that. 1108 01:01:49,900 --> 01:01:53,900 I think, again, that's something where it feels like the L1 1109 01:01:53,900 --> 01:01:58,000 protocol itself is not the place for that to live, but where it's 1110 01:01:58,000 --> 01:02:01,100 probably much healthier. If you see just like Market, the 1111 01:02:01,100 --> 01:02:03,900 merge and the best Solutions, you know, gain traction there. 1112 01:02:06,200 --> 01:02:12,500 Okay, so, to recap slightly, the merge is happening. 1113 01:02:12,900 --> 01:02:16,600 And then, after the merge happens, we would dig into 1114 01:02:16,600 --> 01:02:19,600 things that look like optimizations that help with 1115 01:02:19,600 --> 01:02:24,100 scaling in L2 land. But I think, you know, as we 1116 01:02:24,100 --> 01:02:28,100 come close to closing, I could give you the mic back to talk a 1117 01:02:28,100 --> 01:02:31,700 little bit about why. I think some folks may be fell 1118 01:02:31,700 --> 01:02:35,600 off the wagon a little bit. Is that as a Research changes 1119 01:02:37,000 --> 01:02:41,800 titles, change, naming schemes change, and roadmaps change. 1120 01:02:41,800 --> 01:02:44,900 So, for those that have maybe been on the epicenter train for 1121 01:02:44,900 --> 01:02:48,700 closer to a decade, there are four stages to ethereum is 1122 01:02:48,700 --> 01:02:50,900 roadmap, right? There's Frontier Homestead, 1123 01:02:50,900 --> 01:02:53,200 metropolis and serenity and that's long gone. 1124 01:02:53,500 --> 01:02:57,600 And for those that sort of came around during the Ico era. 1125 01:02:57,800 --> 01:03:02,100 The question is when T2, which still kind of exists today in a 1126 01:03:02,107 --> 01:03:05,000 couple of different places and people that can Use one another 1127 01:03:05,000 --> 01:03:10,800 with supposed token. Name changes that don't exist, 1128 01:03:10,800 --> 01:03:12,500 but this revolves around some phases. 1129 01:03:12,500 --> 01:03:15,600 So, would you say this is kind of where the road map stands. 1130 01:03:15,600 --> 01:03:20,200 Now it's a merge be these kind of optimizations and whatever 1131 01:03:20,200 --> 01:03:24,400 else into the future. What is today's is this sort of 1132 01:03:24,400 --> 01:03:31,100 today's ethereum roadmap I guess I kind of met apart from your 1133 01:03:31,100 --> 01:03:34,600 question is like clearly the theorem roadmap has changed a 1134 01:03:34,600 --> 01:03:38,900 lot, so it's it's probably naive to expect, you know, today is 1135 01:03:38,900 --> 01:03:44,300 when it gets set in stone. I think maybe like the biggest 1136 01:03:44,300 --> 01:03:49,900 like conceptual changes were a bit less, like a linear now than 1137 01:03:49,900 --> 01:03:52,500 we were before. And because we've grown the 1138 01:03:52,500 --> 01:03:55,400 amount of people who contribute to the protocol, we're able to 1139 01:03:55,400 --> 01:04:00,100 do stuff in parallel to it agreed like We couldn't and so 1140 01:04:00,100 --> 01:04:03,100 there's things like when you know, like if you looked at like 1141 01:04:03,100 --> 01:04:05,800 you know, this like Frontier at the serenity roadmap or like 1142 01:04:05,800 --> 01:04:09,000 eats two phase zero phase one phase two, they all assume like, 1143 01:04:09,000 --> 01:04:11,100 you know, it's like we're going to work on 8 and we're going to 1144 01:04:11,100 --> 01:04:12,700 work on video. We're going to work on C. 1145 01:04:13,000 --> 01:04:16,600 Whereas today it, I think we're in a spot where like, obviously 1146 01:04:16,600 --> 01:04:18,700 we need to ship things. One after the other, we can't 1147 01:04:18,700 --> 01:04:21,400 ship every single thing at the same time, but there's 1148 01:04:21,400 --> 01:04:25,000 definitely different teams and different like, even within 1149 01:04:25,000 --> 01:04:27,600 teams like people that are working. 1150 01:04:27,700 --> 01:04:32,700 Going on, like the various, you know, big eater issues with 1151 01:04:32,700 --> 01:04:36,500 ethereum or like areas of improvements and the kind of 1152 01:04:36,500 --> 01:04:39,600 happening in parallel. So like we talked about like we 1153 01:04:39,600 --> 01:04:42,300 talked about Beacon, Cheng withdrawals, we talked about 1154 01:04:42,300 --> 01:04:44,200 sharding. We talked, you know, we didn't 1155 01:04:44,200 --> 01:04:46,800 talk about like, Mev and proposer Builder, separation 1156 01:04:46,800 --> 01:04:50,000 that we didn't talk about like statelessness and we didn't talk 1157 01:04:50,000 --> 01:04:53,300 about like DVM and genuine to improve that, but those are all 1158 01:04:53,300 --> 01:04:56,900 like threads that are happening in parallel today. 1159 01:04:57,900 --> 01:05:01,600 And I think you know a lot of high-level it's like there's 1160 01:05:01,600 --> 01:05:04,100 some protocol related things that we need to do to ensure 1161 01:05:04,100 --> 01:05:10,000 that a theorem like scales and is safe and like and that we we 1162 01:05:10,000 --> 01:05:14,100 don't end up in like a spot where there's like some 1163 01:05:14,100 --> 01:05:18,700 centralized actor within the system who can like exert a 1164 01:05:18,700 --> 01:05:22,500 really high level of control and of influence and there's a ton 1165 01:05:22,500 --> 01:05:24,600 of work that's being done on those fronts. 1166 01:05:25,400 --> 01:05:27,200 But then yeah, there's also a ton of work that's being done. 1167 01:05:27,200 --> 01:05:31,200 Like, Making sure the evm stays like relevant and keeps 1168 01:05:31,200 --> 01:05:35,100 improving and luckily, it's like, they're not blocked on 1169 01:05:35,100 --> 01:05:38,500 one, one on the other. And what what, I think like 1170 01:05:38,500 --> 01:05:41,700 happens is, then, you know, whenever something goes from the 1171 01:05:41,700 --> 01:05:45,500 spot where it's like ready to go from research to Productions, 1172 01:05:45,600 --> 01:05:50,600 then we typically will prioritize that and and gets 1173 01:05:50,600 --> 01:05:52,600 working on it at the client level. 1174 01:05:53,900 --> 01:05:57,600 And we've been lucky so far that like, it's just not happened as 1175 01:05:57,900 --> 01:06:02,100 To R&D efforts are like ready to shift at the same time and if 1176 01:06:02,100 --> 01:06:05,000 they are in the future which it probably will happen, then we'd 1177 01:06:05,000 --> 01:06:07,800 have to decide which one is higher priority or do we want to 1178 01:06:07,808 --> 01:06:11,800 bundle them together but yeah I think it's yeah there's not as 1179 01:06:11,800 --> 01:06:16,600 much like a single big roadmap and and that's one thing we've 1180 01:06:16,600 --> 01:06:17,800 tried to do like with the naming. 1181 01:06:17,800 --> 01:06:20,600 You know, you talked about like a 2 versus eat one and today we 1182 01:06:20,600 --> 01:06:23,100 call them like the consensus. They are versus like execution 1183 01:06:23,100 --> 01:06:26,400 layer and I think the best naming strategy like going 1184 01:06:26,400 --> 01:06:30,800 forward is just to try and Like describe things like very like 1185 01:06:31,200 --> 01:06:34,600 plainly like what they are like, you know, the consensus layer 1186 01:06:34,800 --> 01:06:38,800 like helps you, theorem Network. Come to consensus on the valid 1187 01:06:39,200 --> 01:06:42,500 tip of the chain, the execution layer, actually runs those 1188 01:06:42,500 --> 01:06:44,800 transactions. I think once we have like 1189 01:06:44,800 --> 01:06:47,200 sharding live, you know, it would be fair to called out like 1190 01:06:47,200 --> 01:06:49,600 a data layer or like a data availability layer. 1191 01:06:49,900 --> 01:06:52,600 And and similarly if you look, you know, the Mev land, when 1192 01:06:52,600 --> 01:06:55,300 they start to think about like proposer Builder, separation, 1193 01:06:55,500 --> 01:06:57,500 it's like they're taking this one step further. 1194 01:06:57,600 --> 01:07:00,100 They're looking at, like, okay, what's the role of a validator 1195 01:07:00,100 --> 01:07:03,000 where the different tasks that like a validator can do? 1196 01:07:03,000 --> 01:07:05,900 What are the degrees of freedom? And can we just like, you know, 1197 01:07:05,900 --> 01:07:09,700 segment that in an even more granular detail so that we can 1198 01:07:09,700 --> 01:07:11,900 we can analyze it better. So that's my hope. 1199 01:07:11,900 --> 01:07:15,000 Like I think if we if we can go for like having this like very 1200 01:07:15,000 --> 01:07:20,000 vague like yeah. Terms to just saying like Okay 1201 01:07:20,000 --> 01:07:23,900 these are like the five biggest problems and we need to address 1202 01:07:23,900 --> 01:07:27,800 them and this is like the solution bit that's Going to 1203 01:07:27,808 --> 01:07:29,900 address them, I'll be really happy. 1204 01:07:30,100 --> 01:07:34,400 Obviously, it's off its off my cultivate, but I've appreciated 1205 01:07:34,400 --> 01:07:36,400 that we're trending in that direction. 1206 01:07:38,200 --> 01:07:40,400 And I think we're going to have to save proposer Builder to 1207 01:07:40,408 --> 01:07:44,700 reparation for the second round. Yeah, you did someone else to 1208 01:07:44,700 --> 01:07:47,500 come and give it to our talk on that? 1209 01:07:47,500 --> 01:07:50,400 Yeah. Yeah, the next, the next time we 1210 01:07:50,400 --> 01:07:53,200 have someone from from EF on, it'll be the answer. 1211 01:07:53,200 --> 01:08:00,100 The question when III we should, you know, we need to start 1212 01:08:00,100 --> 01:08:03,100 getting some content out like early about about III again 1213 01:08:04,600 --> 01:08:08,200 since, you know, since it's our history with, you know, covering 1214 01:08:08,200 --> 01:08:11,200 this sort of topic on epicenter. But yeah, thanks, thanks for 1215 01:08:11,200 --> 01:08:14,000 coming on Tim. It's been great and you know 1216 01:08:14,200 --> 01:08:18,600 hopefully now our listeners, get a much better view of the 1217 01:08:18,600 --> 01:08:21,500 overall. All arch of the merge and 1218 01:08:21,500 --> 01:08:23,700 everything. That's, that's coming up. 1219 01:08:23,899 --> 01:08:27,100 Next, certainly I have a much better understanding NASA. 1220 01:08:27,600 --> 01:08:30,700 Hopefully, we can get you on again soon and in a couple of 1221 01:08:30,700 --> 01:08:35,399 months, when when things start to move into production. 1222 01:08:36,399 --> 01:08:38,100 Also, if you have, thank you so much for having me. 1223 01:08:38,899 --> 01:08:43,000 Great, thanks. Thank you for joining us on this 1224 01:08:43,000 --> 01:08:45,399 week's episode. We release new episodes every 1225 01:08:45,399 --> 01:08:47,399 week. You can find And subscribe to 1226 01:08:47,399 --> 01:08:51,100 the show on iTunes Spotify, YouTube SoundCloud or wherever 1227 01:08:51,100 --> 01:08:53,500 you listen to podcast. And if you have a Google home or 1228 01:08:53,508 --> 01:08:56,300 Alexa device, you can tell it to listen to the latest episode of 1229 01:08:56,308 --> 01:09:00,300 the epicenter podcast, go to epicenter, .t V /, subscribe for 1230 01:09:00,300 --> 01:09:02,899 a full list of places where you can watch and listen, while 1231 01:09:02,899 --> 01:09:05,200 you're there, be sure to sign up for the newsletter so you get 1232 01:09:05,200 --> 01:09:07,500 new episodes in your inbox as they're released. 1233 01:09:08,200 --> 01:09:10,600 If you want to interact with us guests or other podcast 1234 01:09:10,600 --> 01:09:13,399 listeners, you can follow Oh us on Twitter and please leave us a 1235 01:09:13,407 --> 01:09:15,800 review on iTunes. It helps me behind the show and 1236 01:09:15,800 --> 01:09:19,100 we're always happy to read them with thanks so much and we look 1237 01:09:19,100 --> 01:09:20,300 forward to being back next week.