1 00:00:00,200 --> 00:00:04,300 This is epicenter episode 397 with guests dank advised. 2 00:00:18,900 --> 00:00:21,500 Welcome to epicenter the podcast where we interview crypto, 3 00:00:21,500 --> 00:00:23,200 Founders, Builders and thought leaders. 4 00:00:23,400 --> 00:00:26,300 I'm Frederick a chance and I'm here with Brian Crane. 5 00:00:26,900 --> 00:00:29,800 And today, we're speaking with thank had faced, who is a 6 00:00:29,800 --> 00:00:33,400 researcher at the theorem foundation and heads the effort 7 00:00:33,400 --> 00:00:36,700 into sharding and statelessness updates for a theorem to. 8 00:00:37,300 --> 00:00:40,800 But before we talk about the theorem to with anchored, we'd 9 00:00:40,800 --> 00:00:44,800 like to tell you about our our sponsors for this week para, 10 00:00:44,800 --> 00:00:46,800 swap just came out with a huge update. 11 00:00:47,000 --> 00:00:48,700 That's even faster and more liquid. 12 00:00:48,700 --> 00:00:51,200 It's cheaper than Yuna Swap and comes with a new, gastric band 13 00:00:51,200 --> 00:00:53,800 that can cut your gas fees by up to 50%. 14 00:00:53,800 --> 00:00:56,700 Para swap is now multi chain and has expanded to polygons and 15 00:00:56,700 --> 00:00:59,000 violence. Marching start trading at Paris 16 00:00:59,000 --> 00:01:03,700 Opera dot IO / epicenter. And also, by Exodus Exodus is an 17 00:01:03,700 --> 00:01:07,000 easy-to-use wallet, which supports lots of assets and has 18 00:01:07,000 --> 00:01:09,500 native apps for all the platforms including IOS and 19 00:01:09,500 --> 00:01:11,700 Android, it's a pulley non-custodial. 20 00:01:11,800 --> 00:01:15,000 Your wallets, they believe in not your keys, not your coins. 21 00:01:15,500 --> 00:01:20,700 And so yeah go to Exodus.com and give it a try and with that. 22 00:01:20,800 --> 00:01:23,500 Yeah, let's let's head over to dunk rat. 23 00:01:23,900 --> 00:01:26,700 Thanks so much for coming on. Maybe you can start. 24 00:01:26,700 --> 00:01:31,200 Before we dive into all of the technical topics you might need 25 00:01:31,200 --> 00:01:34,500 to do things have a little bit and telling us sort of how your 26 00:01:34,900 --> 00:01:37,200 journey has come to working on the theorem. 27 00:01:38,500 --> 00:01:39,100 Yeah. Hello. 28 00:01:39,300 --> 00:01:43,700 Thanks for having me. Yeah, my My journey to etherium 29 00:01:44,300 --> 00:01:47,900 is, yeah. A bit different from probably 30 00:01:47,900 --> 00:01:51,000 most people because I came to it quite late. 31 00:01:51,000 --> 00:01:54,200 I'd say. So I only started fully working 32 00:01:54,400 --> 00:01:57,800 in Ethiopia, research around 2019. 33 00:01:58,300 --> 00:02:03,800 And before that I work for all different tech companies. 34 00:02:03,800 --> 00:02:09,900 I had a start-up and I was basically recruited into the ECM 35 00:02:09,900 --> 00:02:13,700 research team after I had saw after some research problems 36 00:02:13,700 --> 00:02:15,800 earlier for them and worked on them. 37 00:02:16,200 --> 00:02:20,300 And yeah. So basically, since early 2019, 38 00:02:20,300 --> 00:02:23,500 I'm working for the ATM research team, it has been like a very 39 00:02:23,800 --> 00:02:28,200 fun journey and I'm really enjoying doing research on the 40 00:02:28,200 --> 00:02:33,100 future of is here. So we had an episode on ethereum 41 00:02:33,100 --> 00:02:36,900 to recently with Danny Ryan and we actually ended up talking 42 00:02:37,400 --> 00:02:40,900 about the merge and the switch to proof of stake for the entire 43 00:02:40,900 --> 00:02:43,300 episode. But there's a couple of more 44 00:02:43,800 --> 00:02:46,200 more updates that are coming with a theorem to. 45 00:02:46,500 --> 00:02:50,700 So can you give us a very brief overview over the potential 46 00:02:50,700 --> 00:02:54,000 protocol updates and where they are at right now before we Deep 47 00:02:54,000 --> 00:02:56,900 dive into them. Right. 48 00:02:57,500 --> 00:03:01,300 So yeah, I mean there, there there will be several more 49 00:03:01,300 --> 00:03:03,700 updates. I think like the, the really, 50 00:03:04,000 --> 00:03:09,000 the biggest one that everyone is waiting for is the big promised 51 00:03:09,000 --> 00:03:15,100 upgrade of sharding and so probably like a while after the 52 00:03:15,100 --> 00:03:17,700 merge, I don't know, I would estimate between six and 12 53 00:03:17,700 --> 00:03:21,100 months. We will activate data shots 54 00:03:21,200 --> 00:03:25,900 which essentially means we are adding this very large. 55 00:03:26,000 --> 00:03:31,100 Age data, availability layer to a theorem, which means that you 56 00:03:31,100 --> 00:03:34,600 might have heard of Roll-Ups, which are basically a system 57 00:03:34,600 --> 00:03:38,000 where you only post transaction data to the train and you don't 58 00:03:38,000 --> 00:03:41,500 actually execute them. You either use fraud proofs or 59 00:03:41,500 --> 00:03:44,800 zero, knowledge proof in order to ensure that all this is 60 00:03:44,800 --> 00:03:49,300 actually valid and and the data shots actually allow us to 61 00:03:49,300 --> 00:03:54,000 instead of posting that data on the current very limited. 62 00:03:54,000 --> 00:03:57,700 He's one chain, that will be Merged into the beacon chain on 63 00:03:57,900 --> 00:04:00,500 with emerge. Instead of posting it on there, 64 00:04:00,500 --> 00:04:04,400 you can post it to to these data shots and ensure like it's 65 00:04:04,400 --> 00:04:06,600 available in every one can very easily verify that it's 66 00:04:06,600 --> 00:04:08,900 available. But it will be much, much 67 00:04:08,900 --> 00:04:11,500 cheaper because you have so much more space available there. 68 00:04:12,400 --> 00:04:17,200 This further to this, there will be a lot of work on, on the 69 00:04:17,200 --> 00:04:21,600 security of this. So, we will, we have kind of 70 00:04:21,800 --> 00:04:26,200 opted for this gradual rollout, where we don't like Do 71 00:04:26,200 --> 00:04:30,100 everything in one big bang, which kind of started with 72 00:04:30,100 --> 00:04:32,600 actually started. Last December with launching the 73 00:04:32,600 --> 00:04:36,900 beacon chain and we'll continue with the merge and then roll out 74 00:04:36,900 --> 00:04:40,100 of sharding. And they were basically after 75 00:04:40,100 --> 00:04:44,600 that, there will be many further upgrades, which are probably a 76 00:04:44,600 --> 00:04:47,900 bit less obviously visible to the user because they're more 77 00:04:47,900 --> 00:04:51,700 security upgrades. So, we cannot opt for this way 78 00:04:51,700 --> 00:04:54,700 of rolling out features. First, we start by like making 79 00:04:54,700 --> 00:04:58,500 the big rolling. The big features and then we add 80 00:04:58,900 --> 00:05:03,500 everything that is required to get them to towards the highest 81 00:05:03,500 --> 00:05:06,900 security. And so they will basically be 82 00:05:07,300 --> 00:05:13,000 all the work around ensuring data availability and that's the 83 00:05:13,000 --> 00:05:16,400 the proof of custody and data availability checks which are 84 00:05:16,400 --> 00:05:22,400 basically further upgrades that are required to make it to make 85 00:05:22,400 --> 00:05:25,800 data availability. Basically fully incentive comp. 86 00:05:26,000 --> 00:05:30,300 Compatible like to make sure that there are no incentive 87 00:05:30,300 --> 00:05:34,700 problems for validators before we go into, I think there's like 88 00:05:34,700 --> 00:05:37,500 so much already. I think that you should probably 89 00:05:37,900 --> 00:05:41,800 explore a bit more. So you mentioned that the first 90 00:05:41,800 --> 00:05:45,900 sort of charting is this data. So data really charts. 91 00:05:46,600 --> 00:05:49,100 Can you explain in? So, today, right, we have the 92 00:05:49,100 --> 00:05:51,900 existing assume that we know and, you know, it's very much a 93 00:05:51,900 --> 00:05:55,700 capacity and the transactions are too expensive and being too 94 00:05:55,700 --> 00:05:58,400 big. Pain for a lots of to the users. 95 00:05:58,800 --> 00:06:02,800 So, when you have these data visibility charts, like, how 96 00:06:02,800 --> 00:06:05,800 will they help scale if you're a man? 97 00:06:05,800 --> 00:06:09,200 You know what kind of parts that gets executed today or any 98 00:06:09,200 --> 00:06:15,800 theorem will be moved there? Yeah, so and that's basically 99 00:06:16,000 --> 00:06:19,600 going to be the Roll-Ups. So when you're here already we 100 00:06:19,600 --> 00:06:22,500 already have several Roll-Ups active on ECM now, so for 101 00:06:22,500 --> 00:06:27,400 example, zks think and others. And basically right now the way 102 00:06:27,400 --> 00:06:32,100 they work is they, they post. So for example, zika roll up 103 00:06:32,100 --> 00:06:35,900 works by posting this blob of data, on the chain that says 104 00:06:35,900 --> 00:06:37,800 like here, all the transactions he is. 105 00:06:38,000 --> 00:06:40,900 And then at the end there's a proof that says okay this is the 106 00:06:40,900 --> 00:06:42,700 new state route that comes out of it. 107 00:06:43,000 --> 00:06:46,900 So with data availability charts, you have only have to 108 00:06:46,900 --> 00:06:50,300 put this very last part on the execution chain. 109 00:06:50,300 --> 00:06:53,600 You only have to put the part that says, this is the proof and 110 00:06:53,600 --> 00:06:56,400 this is the new state route on the on the actual execution 111 00:06:56,400 --> 00:07:02,200 chain and everything else just can just go on on the data 112 00:07:02,200 --> 00:07:04,400 availability shots. So you basically save like a 113 00:07:04,407 --> 00:07:07,200 huge amount of guests that you don't need anymore to post this 114 00:07:07,200 --> 00:07:11,000 data. But actually today, I guess you 115 00:07:11,000 --> 00:07:15,000 don't have roll ups taking up a big part of the block space. 116 00:07:16,300 --> 00:07:20,300 I haven't looked at the stats in detail, but I would suspect that 117 00:07:20,700 --> 00:07:22,900 at least I mean, they're still, very, very new, right? 118 00:07:22,900 --> 00:07:27,600 Like we haven't had Roll-Ups for a very long time, but I, I would 119 00:07:27,600 --> 00:07:31,400 suspect that they would very quickly dominate. 120 00:07:31,400 --> 00:07:35,000 The Block space because essentially, they allow you to 121 00:07:35,000 --> 00:07:38,700 do things paying about 100 times less gas. 122 00:07:38,900 --> 00:07:43,100 So, why would you do transaction and pay a 100 times more. 123 00:07:43,100 --> 00:07:46,900 If you can do it for 100 times less, And and, of course, since 124 00:07:46,900 --> 00:07:49,300 it's much cheaper, there will be a lot more transaction, right? 125 00:07:49,300 --> 00:07:52,700 I mean, it's a kind of an obvious like consequence from 126 00:07:52,700 --> 00:07:55,400 having some sort of demand curve for transactions. 127 00:07:55,700 --> 00:07:59,400 So I would say, the natural economic equilibrium should be 128 00:07:59,400 --> 00:08:01,300 that almost everything happens inside. 129 00:08:01,300 --> 00:08:04,200 Roll-Ups. Okay, so let's talk about the 130 00:08:04,200 --> 00:08:08,800 concept of a shot, right? So is the shot kind of like a 131 00:08:08,800 --> 00:08:12,200 second Block Chain that runs in parallel with the first one, or 132 00:08:12,200 --> 00:08:16,500 how do I, how do I imagine this? So I will I will answer for this 133 00:08:16,500 --> 00:08:20,500 question from the perspective of data sharding, which is kind of 134 00:08:20,500 --> 00:08:25,000 this goal that we're currently working towards and there might 135 00:08:25,000 --> 00:08:28,700 be, or they will likely be in the further future execution 136 00:08:28,700 --> 00:08:32,799 charts, which will actually also be also an execute code. 137 00:08:33,100 --> 00:08:36,400 But that is currently like, that is several years in the future 138 00:08:36,400 --> 00:08:41,100 and and so, I, I will not take that many into account because 139 00:08:41,100 --> 00:08:43,799 data shots, already achieve a lot of what we want to do. 140 00:08:44,500 --> 00:08:47,500 So from the perspective, Effective of the data shots that 141 00:08:47,500 --> 00:08:50,600 were rolling out. Now, you shouldn't see the shots 142 00:08:50,600 --> 00:08:54,200 really as, as different blockchains because they will 143 00:08:54,200 --> 00:08:58,800 not come, they will not kind of come with their own Fork, Choice 144 00:08:58,800 --> 00:09:03,600 Rule and build on each other. And so on, it's basically just 145 00:09:04,000 --> 00:09:09,300 you could say it's just additional blocks of data that 146 00:09:09,300 --> 00:09:13,100 you put on the Chain but with a special property and that 147 00:09:13,100 --> 00:09:17,600 property is that full nodes. Do not need to download this 148 00:09:17,600 --> 00:09:21,000 flops in order to ensure that they are available. 149 00:09:21,300 --> 00:09:25,000 Like they it that we have a scalable solution that allows 150 00:09:25,000 --> 00:09:28,100 for nodes to know that they are available without downloading 151 00:09:28,100 --> 00:09:29,900 them. How does it work? 152 00:09:30,800 --> 00:09:35,800 So this is, this comes from a very interesting technique that 153 00:09:35,800 --> 00:09:37,900 is called Data availability sampling. 154 00:09:37,900 --> 00:09:43,100 And the essential idea, is that you can you can sample your 155 00:09:43,100 --> 00:09:48,600 sample, small amounts, Randomly selected from the data and thus 156 00:09:48,600 --> 00:09:52,400 you know, that very, very likely very large parts of the data 157 00:09:52,400 --> 00:09:55,000 available. So this is obviously not enough 158 00:09:55,000 --> 00:09:57,900 because when you, if you do that then you notice that. 159 00:09:57,900 --> 00:10:01,500 Oh like but 99.9% of the data being available is not enough 160 00:10:01,500 --> 00:10:05,700 because that 0.1% could be exactly where an attacker hides 161 00:10:05,700 --> 00:10:09,300 their malicious transaction. That prints one trillion ether, 162 00:10:09,300 --> 00:10:13,200 for example, we need 100% and the way you do that is by 163 00:10:13,200 --> 00:10:15,400 encoding the data in a special way. 164 00:10:15,600 --> 00:10:18,900 That makes sure that even if you only have fifty percent of it, 165 00:10:19,200 --> 00:10:23,100 you can always reconstruct 100%. And that is the key trick 166 00:10:23,100 --> 00:10:25,800 towards data available T that allows it to scale. 167 00:10:25,800 --> 00:10:29,800 And that means that basically with a very small constant 168 00:10:29,800 --> 00:10:31,800 amount. So it does not actually depend 169 00:10:31,800 --> 00:10:35,800 on the total amount of data that we ensure to be available of 170 00:10:35,900 --> 00:10:38,600 these samples. You can ensure that the full 171 00:10:38,600 --> 00:10:41,000 data is always available for download. 172 00:10:42,100 --> 00:10:45,300 If you look at the theorem one, you have - and you will have 173 00:10:45,300 --> 00:10:50,200 validators after after the mud. So, how are the shots maintained 174 00:10:50,300 --> 00:10:52,500 are there? Also validators who maintain the 175 00:10:52,500 --> 00:10:54,600 shots? Yes. 176 00:10:55,000 --> 00:10:59,500 So validators will be randomly selected essentially, so that 177 00:10:59,500 --> 00:11:04,000 they are, there are committees. A comedy is is a random 178 00:11:04,000 --> 00:11:06,300 selection from the full validator set. 179 00:11:06,800 --> 00:11:13,500 And these basically validate the shards, they They are kind of I 180 00:11:13,500 --> 00:11:15,900 guess the right thing to say with data shots, they are the 181 00:11:15,900 --> 00:11:18,100 first barrier. This is the first group of 182 00:11:18,100 --> 00:11:23,300 people who like are responsible for checking that the full data 183 00:11:23,300 --> 00:11:26,300 is available and they need to do nothing else because there is no 184 00:11:26,300 --> 00:11:30,600 execution so they do not need to do anything except for knowing 185 00:11:30,600 --> 00:11:32,900 that the data is available because that's all the data 186 00:11:32,900 --> 00:11:35,700 shots too. And the validators. 187 00:11:35,800 --> 00:11:38,900 They are, but they only validate on the Todd's. 188 00:11:38,900 --> 00:11:41,500 They don't validate on the main chain. 189 00:11:43,300 --> 00:11:45,500 They do know know that it's invalid data. 190 00:11:45,500 --> 00:11:48,300 So this is It's only one set of valid data sits all the stuff, 191 00:11:48,300 --> 00:11:50,800 okay? And they both they both 192 00:11:50,800 --> 00:11:54,000 validate, the beacon chain and they validate the shots. 193 00:11:54,100 --> 00:11:57,500 And and this is, this is essentially like I mean this is 194 00:11:57,500 --> 00:12:02,700 one of the I mean this is why why sharding is so important in 195 00:12:02,700 --> 00:12:06,500 our terms, like it's this notion that we call shared security. 196 00:12:06,500 --> 00:12:09,400 So like the essential part is we don't want. 197 00:12:09,400 --> 00:12:12,300 I mean, you could ask the question like well, Well, can't 198 00:12:12,300 --> 00:12:14,000 can't can't. You just have like many 199 00:12:14,000 --> 00:12:16,500 different blockchains communicating with each other 200 00:12:17,200 --> 00:12:21,000 and you get the same as child's problem is that you don't you 201 00:12:21,000 --> 00:12:23,900 don't get shared security. Like each of these blockchains 202 00:12:24,300 --> 00:12:29,100 only has its own smaller, valid data sets, and so has much less 203 00:12:29,100 --> 00:12:32,100 value securing it. Whereas like in and shouted 204 00:12:32,100 --> 00:12:36,000 system the essential thing is that it's always the full value 205 00:12:36,000 --> 00:12:38,100 that is securing the the whole system. 206 00:12:38,100 --> 00:12:41,400 There's no like subset that is responsible for one child. 207 00:12:42,700 --> 00:12:46,100 Okay, so basically say I'm a validator now, on on the main 208 00:12:46,100 --> 00:12:50,500 chain and I also then have to validate the shots. 209 00:12:50,500 --> 00:12:53,200 Do I have to validate all of them or do I get a subset? 210 00:12:54,400 --> 00:12:58,000 Basically, you get randomly assigned every Epoch to one of 211 00:12:58,000 --> 00:13:00,000 them. So, basically, it's, you have 212 00:13:00,000 --> 00:13:03,200 like, a completely, a completely random one that you have to 213 00:13:03,200 --> 00:13:04,600 validate. So you don't have to validate 214 00:13:04,600 --> 00:13:06,800 all of them. You will be on your bill. 215 00:13:06,800 --> 00:13:10,300 We will be validating all of them, but each Epoch, you only a 216 00:13:10,300 --> 00:13:13,600 Prague, you only validate one of them and That Is Random. 217 00:13:13,900 --> 00:13:16,500 So the you are, you're basically, you are you're only 218 00:13:16,500 --> 00:13:18,500 doing the work of validating. One of them. 219 00:13:20,100 --> 00:13:23,400 Okay, so does this also mean that proof of stake is a 220 00:13:23,408 --> 00:13:28,200 prerequisite for for sharding. So the answer was yes. 221 00:13:28,200 --> 00:13:32,200 And the reason is that - don't have any sort of identity. 222 00:13:32,200 --> 00:13:37,600 So you cannot the notion of assigning like a minor to a 223 00:13:37,608 --> 00:13:40,300 random committee and telling them like you need to validate 224 00:13:40,300 --> 00:13:42,100 this chart. Now doesn't make any sense 225 00:13:42,100 --> 00:13:45,200 because they don't have any. The only thing that identifies 226 00:13:45,200 --> 00:13:48,000 them as how many how much hash power they have whereas 227 00:13:48,200 --> 00:13:51,400 validators improves take the I have to pay this deposit and 228 00:13:51,400 --> 00:13:55,800 after that, they have a public key and we can say like this is 229 00:13:55,800 --> 00:13:58,200 the public key that is now in this committee. 230 00:13:58,600 --> 00:14:01,400 So in that way, it is essential to have proof of stake for 231 00:14:01,400 --> 00:14:03,500 shaving. Okay. 232 00:14:03,500 --> 00:14:08,000 And I am data shots created equal or are there different 233 00:14:08,000 --> 00:14:10,600 flavors and how many of them were there be? 234 00:14:11,500 --> 00:14:13,600 So they, they are, they are exactly equal. 235 00:14:13,600 --> 00:14:15,100 There's no difference between them. 236 00:14:16,000 --> 00:14:18,400 The only way is how applications use them. 237 00:14:18,400 --> 00:14:22,300 So, they could be Roll-Ups, which basically decide, I only 238 00:14:22,300 --> 00:14:26,800 accept blocks that are submitted on a certain shot number, which 239 00:14:27,000 --> 00:14:29,800 makes sense for them. Because then they need to check 240 00:14:29,800 --> 00:14:32,100 less data for whether it's relevant for them. 241 00:14:32,900 --> 00:14:37,200 But but from the from the consensus layer, they are 242 00:14:37,200 --> 00:14:41,800 exactly equal. And how can I make sure that my 243 00:14:41,800 --> 00:14:47,400 transaction gets send to the right chart so this would this 244 00:14:47,400 --> 00:14:53,800 would only be relevant. So I mean this is an application 245 00:14:53,900 --> 00:14:59,200 specific detail but like but the and the answer will depend on 246 00:14:59,400 --> 00:15:02,600 what kind of roll up your use. And it's I would say it's very 247 00:15:02,600 --> 00:15:07,900 likely that in most applications a user will not usually at least 248 00:15:07,900 --> 00:15:11,800 directly send their transaction to a heart or like to the 249 00:15:11,800 --> 00:15:16,800 validators even and they were rather send it to who Verb is 250 00:15:16,800 --> 00:15:20,800 responsible for creating blocks of the stroll up and they will 251 00:15:20,800 --> 00:15:26,300 then put it on on a chart. So if I understand correctly, 252 00:15:26,600 --> 00:15:31,300 the data shards, are mainly targeted at Roll-Ups, can I use 253 00:15:31,300 --> 00:15:32,800 this to store other kind of data? 254 00:15:32,800 --> 00:15:37,200 So kind of say, for instance, Oracle data, that kind of clogs 255 00:15:37,600 --> 00:15:42,700 the blockchain currently Yes. I mean I don't see why it 256 00:15:42,700 --> 00:15:49,100 couldn't be used for oracle's. Yeah, I mean you have to think 257 00:15:49,100 --> 00:15:53,000 about basically the only thing is it would still be a kind of 258 00:15:53,200 --> 00:15:57,400 roll up Oracle, I guess. Like, so in a way in a way, it's 259 00:15:57,400 --> 00:16:01,700 all Roll-Ups. Yeah, but but I mean, you can, 260 00:16:01,700 --> 00:16:03,300 you can have many different kinds of Roll-Ups. 261 00:16:03,300 --> 00:16:06,200 Like, you could have like, a contract specific roll up. 262 00:16:06,200 --> 00:16:08,700 Like, I mean, actually many Roll-Ups right now, are very 263 00:16:08,700 --> 00:16:10,100 application-specific. Right. 264 00:16:10,100 --> 00:16:14,000 For example, they only do transfers which is in essence 265 00:16:14,000 --> 00:16:17,700 one application. So, I think the roll-up notion 266 00:16:17,700 --> 00:16:21,800 is not is not restrictive. It can do everything. 267 00:16:21,800 --> 00:16:25,800 It's just, it's just an a way of implementing what you want to 268 00:16:25,800 --> 00:16:30,700 do, when you want to trade tokens on ethereum, make sure to 269 00:16:30,700 --> 00:16:33,500 consider para swap. First drop is a decentralized 270 00:16:33,500 --> 00:16:37,100 exchange aggregator so that you can get the best price across 271 00:16:37,100 --> 00:16:41,000 multiple ethereum Texas. And now Paris Rob has just been 272 00:16:41,000 --> 00:16:44,100 integrated in Ledger life. This means you can swap tokens 273 00:16:44,100 --> 00:16:46,900 using your lecture directly from The Ledger Lite app. 274 00:16:47,100 --> 00:16:50,600 No third parties involved. / strap is also multi chain and 275 00:16:50,600 --> 00:16:54,200 available on polygon and Vine and smart chain, give Paris 276 00:16:54,200 --> 00:16:57,100 Opera. Try at Paris, Rob dot IO, / 277 00:16:57,100 --> 00:17:00,800 epicenter, we'd like to thank Paris or up for their support of 278 00:17:00,800 --> 00:17:04,400 epicenter. Maybe we make sense to spend, 279 00:17:04,400 --> 00:17:07,200 like, a few minutes, if you could explain a little bit like, 280 00:17:07,200 --> 00:17:09,900 how you roll ups work, and what do you think the role of 281 00:17:09,900 --> 00:17:11,500 Roll-Ups is going to be in the future? 282 00:17:13,400 --> 00:17:15,200 Yeah. Roll-Ups are essentially this 283 00:17:15,200 --> 00:17:21,300 notion that you use the chain, only to ensure that data is 284 00:17:21,300 --> 00:17:25,599 available without itself, Computing. 285 00:17:25,599 --> 00:17:28,500 The correct execution of the of the data. 286 00:17:28,500 --> 00:17:32,400 So most obvious way this is when you when you use. 287 00:17:33,000 --> 00:17:35,200 So there are two flavors of Roll-Ups, right says, they're 288 00:17:35,200 --> 00:17:39,300 optimistic Roll-Ups and ZK. Roll-Ups also do not roll ups so 289 00:17:39,300 --> 00:17:43,100 the way ZK Roll-Ups to do this as maybe the more obvious ones. 290 00:17:43,500 --> 00:17:47,200 Like you put all the transaction data on the chain and then you 291 00:17:47,200 --> 00:17:49,800 have a zero. Knowledge proof that says, this 292 00:17:49,800 --> 00:17:52,200 is the result of the execution of that. 293 00:17:52,200 --> 00:17:55,800 And here is the new state route. Now you could ask the question 294 00:17:55,800 --> 00:17:58,400 why, why do I Neva need to put the data on the Chain? 295 00:17:58,400 --> 00:18:01,200 If I know that the computation was done correctly, right? 296 00:18:01,200 --> 00:18:04,600 What why does that matter? And the reason for that is that 297 00:18:04,800 --> 00:18:08,300 you need to be able to reconstruct the state as well as 298 00:18:08,300 --> 00:18:10,800 just the route. Like if you just have the root 299 00:18:10,800 --> 00:18:13,800 of the problem is that the root is not enough to Access your 300 00:18:13,800 --> 00:18:16,700 account. You always also need a proof 301 00:18:16,700 --> 00:18:20,900 that shows that your balance in that account is X, right? 302 00:18:20,900 --> 00:18:23,800 You need this as well and you can only generate that if you 303 00:18:23,800 --> 00:18:27,100 have the stage. So that's why it's essential for 304 00:18:27,100 --> 00:18:31,000 preserving this. Trust listeners that you that 305 00:18:31,000 --> 00:18:34,800 you also get all the data that's required to reconstruct the 306 00:18:34,800 --> 00:18:36,600 state. This can actually be less than 307 00:18:36,600 --> 00:18:40,000 all the transactions so you can also in a 0, ZK, Roll-Ups for 308 00:18:40,000 --> 00:18:43,000 example, it can also just be a diff of the state. 309 00:18:43,000 --> 00:18:45,900 It Just beat literally like the difference in the states that 310 00:18:45,900 --> 00:18:49,400 you need to put on chain. But that part is essentially an 311 00:18:49,400 --> 00:18:51,600 optimistic roll-up. Does it slightly differently? 312 00:18:51,700 --> 00:18:54,500 It's puts all a list of all the transactions. 313 00:18:54,500 --> 00:18:56,700 And in this case, it has to be all the transactions, even 314 00:18:56,700 --> 00:19:02,400 including signatures on the chain and also adds like the new 315 00:19:02,400 --> 00:19:05,200 statute says, like this is the result of executing this. 316 00:19:06,000 --> 00:19:10,000 And then anyone can, if there was an incorrect one, if there 317 00:19:10,000 --> 00:19:13,100 was some incorrect execution and this is not the correct outcome. 318 00:19:13,300 --> 00:19:17,000 And then anyone can post the fraud proof that regards this 319 00:19:17,000 --> 00:19:20,500 block and and resets the chain to the previous state. 320 00:19:20,900 --> 00:19:24,500 So that ensures that and a fraudulent transaction can never 321 00:19:24,500 --> 00:19:29,600 be included in that roll up. To get some more background on, 322 00:19:30,000 --> 00:19:33,800 ZK, sink, and ZK Roll-Ups. Last week's episode was with 323 00:19:33,800 --> 00:19:37,500 Alex Kowski of matted apps. So you can also go back one 324 00:19:37,500 --> 00:19:42,800 episode and check that out. So tancred can I ask about this 325 00:19:42,800 --> 00:19:46,800 switch from full charts or execution, charts. 326 00:19:46,800 --> 00:19:49,700 As you call it them earlier to date, availability charts 327 00:19:49,700 --> 00:19:52,500 because if I require it correctly, a while ago, with the 328 00:19:52,500 --> 00:19:56,800 idea was to actually have full execution charts, that would not 329 00:19:56,800 --> 00:20:01,800 just Data available but also be able to execute smart contracts 330 00:20:01,800 --> 00:20:04,700 and then loop back into the main chain. 331 00:20:05,000 --> 00:20:10,100 Why was this abandoned? Or at least, if not abandoned, 332 00:20:10,100 --> 00:20:14,100 then kind of split into two into a journey of two parts. 333 00:20:15,700 --> 00:20:22,200 Right, so to be actually clear here, I think doing this data 334 00:20:22,200 --> 00:20:24,700 shots. First has always been on the 335 00:20:24,700 --> 00:20:27,400 road map, but was probably less emphasized. 336 00:20:27,400 --> 00:20:31,100 I guess, several years ago, it was thought that this is like 337 00:20:31,100 --> 00:20:35,000 just a first step to kind of test the whole system out and 338 00:20:35,100 --> 00:20:40,400 test it under load and more and more it has become clear. 339 00:20:40,700 --> 00:20:44,800 I would say how awesome Roll-Ups are like how, what's because 340 00:20:44,800 --> 00:20:47,000 they own their own? Own already provide, provide 341 00:20:47,000 --> 00:20:51,200 this 100x geylang essentially if they do, if you do them well. 342 00:20:51,400 --> 00:20:54,200 So in the end, you could ask the question. 343 00:20:54,200 --> 00:20:57,300 Like, why would you do? Why would you even do and like 344 00:20:57,300 --> 00:21:00,000 even on the execution trials? Why would you do anything other 345 00:21:00,000 --> 00:21:03,000 than Roll-Ups? So this is I would say why it 346 00:21:03,000 --> 00:21:08,400 has more converge towards this notion of well actually like the 347 00:21:08,400 --> 00:21:13,600 main the main advantage like the the huge scaling comes when you 348 00:21:13,600 --> 00:21:18,800 have the roll-ups And, and maybe execution in the end, won't even 349 00:21:18,800 --> 00:21:22,600 be necessary. But the fact of 100, I mean 350 00:21:23,000 --> 00:21:26,100 that's still not enough, right? I mean, basically, if you look 351 00:21:26,100 --> 00:21:29,400 at the adoption of a theorem right now and the potential 352 00:21:29,400 --> 00:21:33,400 adoption of a theorem and if you if you then also look at what 353 00:21:33,400 --> 00:21:39,100 the, what the gas prices currently are, it seems to me 354 00:21:39,100 --> 00:21:42,100 that a factor of 100. Yeah, it's something but it's 355 00:21:42,100 --> 00:21:43,600 not a lot. All right. 356 00:21:43,600 --> 00:21:44,800 Absolutely. Oh no. 357 00:21:44,800 --> 00:21:49,300 But I mean the the Roll-Ups can scale the current system as it 358 00:21:49,300 --> 00:21:54,300 is pre sharding by I 100 x. Now once we add sharding data 359 00:21:54,300 --> 00:21:58,200 shots, just data shots. So that then you get another, 360 00:21:58,400 --> 00:22:02,400 like, 100x of the data availability roughly, like order 361 00:22:02,400 --> 00:22:06,400 of magnitude. So now, we had 10,000 x, so that 362 00:22:06,400 --> 00:22:09,100 is, that is a serious amount of scaling to start with. 363 00:22:09,100 --> 00:22:12,300 And that is not an absolute limit like we can add further 364 00:22:12,300 --> 00:22:16,200 shots. So the 64 shouts is, is 365 00:22:16,300 --> 00:22:19,700 according to that. Is that is just a constant and 366 00:22:19,700 --> 00:22:24,700 of course there are Trade-offs and like, it depends on how much 367 00:22:24,800 --> 00:22:28,100 value we have at stake and also importantly, how many users they 368 00:22:28,100 --> 00:22:29,900 are? How many shots we can support 369 00:22:30,000 --> 00:22:33,000 securely but it can be scaled further from that point. 370 00:22:33,000 --> 00:22:36,900 So there's no dead that that 100x is not the limit that we 371 00:22:36,900 --> 00:22:40,200 are at. Let's go back to the execution 372 00:22:40,200 --> 00:22:42,400 charts. So I Now understand that the 373 00:22:42,400 --> 00:22:45,700 data availability shots were always part of the plan, but 374 00:22:45,900 --> 00:22:49,600 what do you gain from execution? Charts that currently data 375 00:22:49,600 --> 00:22:52,900 availability charts. I cannot give to a theorem. 376 00:22:54,000 --> 00:22:59,500 So I guess this depends. So this basically, this depends 377 00:22:59,500 --> 00:23:04,000 on how far zero knowledge proof technology will develop in the 378 00:23:04,000 --> 00:23:07,600 future. So I think the main downside 379 00:23:07,800 --> 00:23:11,600 there are basically some downsides of optimistic Roll-Ups 380 00:23:11,600 --> 00:23:14,200 in terms of their finality interests while I mean. 381 00:23:14,700 --> 00:23:17,300 Yeah. So so basically, they need this 382 00:23:17,400 --> 00:23:21,900 very annoying to week withdrawal, delay that you can 383 00:23:21,900 --> 00:23:26,400 kind of work around. Small users like that. 384 00:23:26,400 --> 00:23:31,400 Don't have too much value but but it's always gonna be a 385 00:23:31,400 --> 00:23:34,200 problem. Like the solution is great for 386 00:23:34,200 --> 00:23:36,800 many things but it's not perfect. 387 00:23:37,200 --> 00:23:41,500 So now if you if you have very good if we can get a very good 388 00:23:41,900 --> 00:23:44,500 zero-knowledge virtual machine basically complete virtual 389 00:23:44,500 --> 00:23:50,700 machine that you can run inside a zero knowledge proof within 390 00:23:50,700 --> 00:23:54,400 the next few years. Then theoretically Akley, you 391 00:23:54,400 --> 00:23:59,700 can already with that, like build, essentially what I excuse 392 00:23:59,700 --> 00:24:04,400 and charts from from what we have now and then potentially at 393 00:24:04,400 --> 00:24:09,000 that point, getting execution charts might just mean nothing 394 00:24:09,000 --> 00:24:13,300 more than a training that that ZK roll up, that is doing that. 395 00:24:13,600 --> 00:24:16,600 So that might be like a very simple step, if we if we get 396 00:24:16,600 --> 00:24:18,800 there. Well, I mean, I'm very 397 00:24:18,800 --> 00:24:20,500 interested to see the progress on those. 398 00:24:20,500 --> 00:24:21,600 Like, there's your knowledge proof. 399 00:24:21,600 --> 00:24:25,900 Space has like made Really amazing progress and almost 400 00:24:25,900 --> 00:24:30,400 every year, like delivered more than I would have expected. 401 00:24:30,900 --> 00:24:36,600 So I would I would not say it's impossible, but it is still a 402 00:24:36,600 --> 00:24:41,400 very, very difficult thing to, to deliver the full. 403 00:24:41,900 --> 00:24:46,700 The full kind of everything that the ebm does now in a, in a 404 00:24:46,700 --> 00:24:49,400 Sleek a roll up. If we don't get that, then 405 00:24:49,400 --> 00:24:52,800 execution shots might basically special kinds of sharks, where 406 00:24:52,800 --> 00:24:56,600 you essentially get Much faster finality because the difference 407 00:24:56,600 --> 00:25:00,700 to like the problem with the with the optimistic Roll-Ups is 408 00:25:00,700 --> 00:25:08,000 that you have these kind of finality delays and and if we if 409 00:25:08,000 --> 00:25:10,800 we do make validators responsible again for taking 410 00:25:10,800 --> 00:25:13,700 execution which is essentially what an execution child would 411 00:25:13,700 --> 00:25:15,700 mean. Then then you would basically 412 00:25:15,700 --> 00:25:20,000 get get this another settlement layer on top. 413 00:25:20,000 --> 00:25:23,100 I would say. Well that's super interesting. 414 00:25:23,100 --> 00:25:26,500 I actually I would love it if you can speculate a little bit 415 00:25:26,500 --> 00:25:31,700 on how you think to sort of supply of if you block space and 416 00:25:31,700 --> 00:25:34,400 through produce going to develop, you know in the next 417 00:25:34,400 --> 00:25:37,800 year or so and how much and when you think those different 418 00:25:37,800 --> 00:25:40,400 technologies will start to have an impact. 419 00:25:41,700 --> 00:25:44,900 Right. I mean, I think my intuition, is 420 00:25:44,900 --> 00:25:48,500 that we can see the impact of Roll-Ups right now. 421 00:25:48,600 --> 00:25:52,800 Like we have seen this huge crash in gas prices, 422 00:25:52,800 --> 00:25:57,200 essentially, and I think that is probably partially because a lot 423 00:25:57,200 --> 00:26:00,300 of people have actually moved to roll ups. 424 00:26:00,300 --> 00:26:03,400 Now, for some simple applications, which is amazing, 425 00:26:03,700 --> 00:26:06,600 I don't think the gas reduction on the main chain is going to 426 00:26:06,600 --> 00:26:09,300 last, but the reduction on the roll-up is going to last. 427 00:26:09,600 --> 00:26:13,900 So, so That's pretty great. So there there's basically right 428 00:26:13,900 --> 00:26:16,300 now at least for simple things. There is already. 429 00:26:16,300 --> 00:26:22,700 This pretty much 100 X increase in Supply as Longwood as what 430 00:26:22,700 --> 00:26:28,000 you want to do, is transfer some of the theory, ether or ESC, 20. 431 00:26:28,700 --> 00:26:32,800 And then, the next the next, very big thing from that will 432 00:26:32,800 --> 00:26:35,200 essentially be shouting. So, when we activate the data 433 00:26:35,200 --> 00:26:39,100 charts, then for everyone who uses Roll-Ups, there will be 434 00:26:39,100 --> 00:26:42,500 another 100x. Increase in Supply and block 435 00:26:42,500 --> 00:26:46,000 space. Let's get to our sponsor. 436 00:26:46,000 --> 00:26:49,400 Exodus Exodus is a fantastic crypto currency wallet, that 437 00:26:49,400 --> 00:26:52,900 strikes the right balance between ease-of-use security and 438 00:26:52,900 --> 00:26:55,900 great features. You can get Exodus on the iPhone 439 00:26:56,100 --> 00:26:59,200 desktop app. Web app, Android whatever 440 00:26:59,200 --> 00:27:02,500 platform you use. It's a noncustodial wallet. 441 00:27:02,500 --> 00:27:04,800 That is so critical. Because what's the point of 442 00:27:04,800 --> 00:27:06,800 crypto? If you don't control your own 443 00:27:06,800 --> 00:27:11,500 assets with Exodus, you always do Old school and they've been 444 00:27:11,500 --> 00:27:16,700 around since 2015 over 1.2 million users rely on Exodus. 445 00:27:16,700 --> 00:27:20,200 So you know that they've stood the test of time, they have 446 00:27:20,200 --> 00:27:24,600 support for over 100 different crypto acids and remove in 447 00:27:24,600 --> 00:27:26,700 Exodus. You can easily change one 448 00:27:26,700 --> 00:27:30,200 different asset to the order. They also allow you to buy 449 00:27:30,200 --> 00:27:33,300 crypto with Fiat and they even have a great offer where you can 450 00:27:33,300 --> 00:27:37,800 buy up to $500 worth of crypto through the IOS app and pay just 451 00:27:37,800 --> 00:27:40,300 $1 in fee. So go to Exodus Dot. 452 00:27:40,500 --> 00:27:42,900 Cam epicenter and check out their wallet. 453 00:27:43,000 --> 00:27:46,400 We want to thank Exodus for their amazing support of 454 00:27:46,400 --> 00:27:50,600 epicenter. One of the problems that you 455 00:27:50,600 --> 00:27:53,500 also get with execution charts, but if you were to introduce 456 00:27:53,500 --> 00:27:56,300 them, right? Is cross shot. 457 00:27:56,500 --> 00:28:01,500 Communication and composability and the consequences of this on 458 00:28:01,500 --> 00:28:04,000 finality. Do you think this is, this is 459 00:28:04,000 --> 00:28:07,800 such a hard problem. That it's it won't be solved or 460 00:28:07,800 --> 00:28:14,600 do you think if we need to we can solve this It's not so much 461 00:28:14,600 --> 00:28:17,200 that cross shots like cross track. 462 00:28:17,200 --> 00:28:20,300 Communication is not an unsolvable problem. 463 00:28:20,300 --> 00:28:24,200 It is just a difficult engineering problem to get all 464 00:28:24,200 --> 00:28:27,500 the details, right? At least for a synchronous, 465 00:28:27,500 --> 00:28:30,700 communication for synchronous. Then then yes. 466 00:28:30,700 --> 00:28:34,600 The you have, you have a very difficult problem at hand. 467 00:28:34,600 --> 00:28:38,700 Not an unsolvable one again, but I think that that yes that is 468 00:28:38,700 --> 00:28:42,400 essentially my guess would be, that's not going to happen. 469 00:28:43,000 --> 00:28:46,300 That you will do synchronous Communications across shots or 470 00:28:46,300 --> 00:28:49,200 in data shots World used. You actually have the same 471 00:28:49,200 --> 00:28:51,000 problem. It's basically cross roll up 472 00:28:51,000 --> 00:28:54,800 core Communication in this case, Okay. 473 00:28:54,800 --> 00:28:58,500 Can you just explain synchronous and asynchronous communication 474 00:28:58,500 --> 00:29:01,200 in this context? Yes. 475 00:29:01,200 --> 00:29:07,700 So asynchronous is basically without like without a certain 476 00:29:07,700 --> 00:29:12,000 delivery guarantee like you can't you can't so so so far as 477 00:29:12,000 --> 00:29:17,500 communication would be what enables composability directly 478 00:29:17,500 --> 00:29:23,900 linking charts which I think is is not is not a very realistic 479 00:29:23,900 --> 00:29:30,500 thing to expect in that in this sense because Because it would 480 00:29:30,500 --> 00:29:36,400 mean that anyone can lock up resources on the blockchain. 481 00:29:36,400 --> 00:29:39,500 Like, I mean, essentially what compost ability means is that 482 00:29:39,800 --> 00:29:44,400 you have this lock on the on the whole chain in a way, right? 483 00:29:44,400 --> 00:29:49,500 Where only you get to determine what happens and I don't feel 484 00:29:49,500 --> 00:29:53,800 like this is likely to be a thing across Trout's although 485 00:29:53,800 --> 00:29:57,600 very theoretically possible. I mean, in Computing, we have 486 00:29:57,600 --> 00:30:01,100 all the models to do that. Doesn't make that much sense to 487 00:30:01,100 --> 00:30:03,400 me. They are all kinds of ideas to 488 00:30:03,400 --> 00:30:07,200 get around this, but I think the more realistic thing of how that 489 00:30:07,200 --> 00:30:14,400 will work out is that that you have certain ecosystems interest 490 00:30:14,400 --> 00:30:18,300 certain shots or certain Roll-Ups that care about 491 00:30:18,500 --> 00:30:23,100 composability internally. But not but are a little more 492 00:30:23,100 --> 00:30:27,000 Loosely coupled to the other systems around them. 493 00:30:27,000 --> 00:30:30,500 And our key was as synchronous communication, which is If you 494 00:30:30,500 --> 00:30:35,200 send a message and it will be delivered at some point, but you 495 00:30:35,400 --> 00:30:38,600 don't have any guarantee. When like any absolute guarantee 496 00:30:38,600 --> 00:30:41,800 and practice, it will always be very, very fast but you have to 497 00:30:42,100 --> 00:30:45,200 consider this very worst case that it could be delayed for a 498 00:30:45,200 --> 00:30:50,300 very long time. Okay, so let's talk about 499 00:30:50,400 --> 00:30:56,200 composability across data shot. So basically, if I have data 500 00:30:56,200 --> 00:31:00,200 within different, Roll-Ups are these still available after the 501 00:31:00,200 --> 00:31:02,000 fact? Was that a problem? 502 00:31:02,300 --> 00:31:05,500 Can these be accessed by other applications at a lot later 503 00:31:05,500 --> 00:31:10,000 point in time? Yes, so that is basically the 504 00:31:10,000 --> 00:31:13,800 way we've designed it. It's instantly available to 505 00:31:13,800 --> 00:31:16,400 everyone. So, there is no delay in 506 00:31:16,400 --> 00:31:22,400 communication between between the different data shots, there 507 00:31:22,400 --> 00:31:26,800 is a limit in. I don't think the, I think it's 508 00:31:26,800 --> 00:31:30,500 theoretically possible to have some notion of composability 509 00:31:30,700 --> 00:31:34,000 between ZK Roll-Ups. I don't know if that will be 510 00:31:34,000 --> 00:31:37,800 built. It's T much impossible for 511 00:31:37,800 --> 00:31:39,700 optimistic. Roll-Ups to do anything like 512 00:31:39,700 --> 00:31:42,400 that. However, I think maybe one 513 00:31:42,400 --> 00:31:46,100 notion we should we should correct you that many people 514 00:31:46,100 --> 00:31:48,000 have. So, one roll up, doesn't 515 00:31:48,000 --> 00:31:50,400 necessarily have to be only on one shot. 516 00:31:50,600 --> 00:31:54,600 So you could have a roll up that basically takes up 10 shot 517 00:31:54,600 --> 00:31:58,200 blocks like every in every cycle, right? 518 00:31:58,400 --> 00:32:02,500 And, and essentially, that roll up internally can provide full 519 00:32:02,500 --> 00:32:05,900 composability. So it is not like we are 520 00:32:05,900 --> 00:32:08,200 limiting. Any sort of composability 521 00:32:08,200 --> 00:32:11,500 between the data shots, as long as there's one roll up. 522 00:32:11,600 --> 00:32:15,400 And at least for ZK Roll-Ups, we, we can and see where you 523 00:32:15,400 --> 00:32:19,200 build these big Roll-Ups. It's a matter of optimizing, 524 00:32:19,200 --> 00:32:22,700 everything enough that proved us can handle this and are not too 525 00:32:22,700 --> 00:32:26,200 crazy expensive, but you could, you could have these huge 526 00:32:26,200 --> 00:32:29,000 Roll-Ups that provide internal composability at least. 527 00:32:30,700 --> 00:32:33,600 Aqua that's that's super interesting to hear. 528 00:32:33,600 --> 00:32:37,300 And I think this kind of clears up most of our questions around 529 00:32:37,300 --> 00:32:41,700 chatting so I'd kind of like to switch gears and move into the 530 00:32:41,700 --> 00:32:44,400 second topic for today which is statelessness. 531 00:32:44,400 --> 00:32:48,500 So say this is another big issue that the theorem Foundation 532 00:32:48,500 --> 00:32:53,300 research team is working on. So can you explain what the 533 00:32:53,300 --> 00:32:55,800 theorem state is? And how it's used? 534 00:32:57,700 --> 00:33:02,700 So the theorem State essentially, it consists on 535 00:33:02,700 --> 00:33:06,200 everything that is stored on the Athenian blockchain. 536 00:33:06,200 --> 00:33:10,100 So it would be for example, for you as a user, it would be your 537 00:33:10,100 --> 00:33:13,900 the balances of your accounts. It would be the balances in. 538 00:33:14,100 --> 00:33:16,700 Yes. The 20 tokens that you have but 539 00:33:16,700 --> 00:33:21,300 also any other kind of data that is necessary for, for example, a 540 00:33:21,308 --> 00:33:26,400 smart contract to know whether something is valid, it's the 541 00:33:26,400 --> 00:33:29,500 code of the smart. Contracts and add. 542 00:33:29,500 --> 00:33:32,400 All of these things. Those are all part of the 543 00:33:32,400 --> 00:33:37,600 etherium state. And, and at the moment, every 544 00:33:37,600 --> 00:33:40,400 every node in the theme network has to store this. 545 00:33:40,400 --> 00:33:45,700 Because the only way to know from whether one block is valid 546 00:33:45,700 --> 00:33:50,400 is to have the state and execute the the all the transactions in 547 00:33:50,400 --> 00:33:53,900 that block and update that state and and know that this was all 548 00:33:53,900 --> 00:33:57,600 done correctly. What's the current state of the 549 00:33:57,600 --> 00:33:59,500 theorem? As though the size of the state 550 00:33:59,500 --> 00:34:03,600 and is that in itself? The problem I don't have the 551 00:34:03,600 --> 00:34:07,200 very best idea of the numbers here, because they also depend 552 00:34:07,200 --> 00:34:10,900 on on implementation details. It's somewhere in the tens of 553 00:34:10,900 --> 00:34:14,400 gigabytes. As far as I'm aware, I've been 554 00:34:14,400 --> 00:34:17,900 quoted numbers between 10 and 100 here, but I believe it 555 00:34:17,900 --> 00:34:20,800 really depends on what exactly how exactly you store it. 556 00:34:20,800 --> 00:34:23,300 And you can do that more or less optimized. 557 00:34:23,300 --> 00:34:29,900 It is a l'm in the sense that already that makes it necessary 558 00:34:29,900 --> 00:34:34,699 because each block does a lot of State accesses right, like each 559 00:34:34,699 --> 00:34:39,199 block, each single transaction already access like at the very 560 00:34:39,199 --> 00:34:43,800 least two accounts like the sender and the receiver and and 561 00:34:44,000 --> 00:34:47,199 and so you have this hundreds of transactions and potentially 562 00:34:47,199 --> 00:34:51,900 like thousands of State accesses in them and if you if you know 563 00:34:51,900 --> 00:34:55,699 anything about this guy, oh then like you know that For example, 564 00:34:55,699 --> 00:34:58,500 in moment, hard disk, like can't really handle that. 565 00:34:58,500 --> 00:35:02,400 Like, each access costs already like on the order of 10 or more 566 00:35:02,400 --> 00:35:04,400 milliseconds. So, like that. 567 00:35:04,400 --> 00:35:06,200 That is a very long time to wait. 568 00:35:06,300 --> 00:35:10,100 And that is why right now. If them notes basically need 569 00:35:10,100 --> 00:35:12,200 ssds, there's no way around that. 570 00:35:12,500 --> 00:35:17,500 So it is a problem right now. It is also a much bigger problem 571 00:35:17,500 --> 00:35:22,100 is that you can do a Dos attack against this and blow the state 572 00:35:22,200 --> 00:35:26,300 up relatively cheaply to and even much larger size. 573 00:35:26,300 --> 00:35:30,000 And so like a lot of our gas costs, our have to be structured 574 00:35:30,000 --> 00:35:33,900 around this, making this so expensive that it won't happen. 575 00:35:35,100 --> 00:35:38,500 So, basically, the goal for statelessness is to kind of go 576 00:35:38,500 --> 00:35:42,300 to a version of etherium, that doesn't have this humongous 577 00:35:42,300 --> 00:35:45,700 state, right? So, how would that look like? 578 00:35:46,400 --> 00:35:49,600 Yes. So to be clear, the state will 579 00:35:49,600 --> 00:35:54,400 still be implicit and some people, and this is something to 580 00:35:54,400 --> 00:35:58,400 be discussed further. Some people will still store 581 00:35:58,400 --> 00:36:02,000 that full State and the question of statelessness around who 582 00:36:02,000 --> 00:36:08,400 needs to store that state and And so one thing that you can do 583 00:36:08,400 --> 00:36:12,800 basically with statelessness is to structure everything so that 584 00:36:12,800 --> 00:36:18,000 you can you can validate a block without needing the state like 585 00:36:18,000 --> 00:36:22,300 you can like just if I just send you that one block in isolation 586 00:36:22,300 --> 00:36:26,400 without anything else, you can just from that information 587 00:36:26,400 --> 00:36:29,600 decide whether it is a valid issue in block or not, you do 588 00:36:29,600 --> 00:36:33,300 not need any other context and that that is what statelessness 589 00:36:33,300 --> 00:36:35,400 does. So, how does this work? 590 00:36:35,400 --> 00:36:38,400 Technically wouldn't I have to have like some sort of 591 00:36:38,400 --> 00:36:41,300 representation of the entire state for that to actually work? 592 00:36:42,800 --> 00:36:47,600 So it works because we have cryptographic techniques that 593 00:36:47,600 --> 00:36:54,000 allow us to commit to two states and various extinct forms. 594 00:36:54,000 --> 00:36:56,500 And like basically everyone knows about these are called 595 00:36:56,800 --> 00:37:00,200 Merkle trees. As, for example, one of these 596 00:37:01,100 --> 00:37:03,500 that. So basically, it gives us this 597 00:37:03,600 --> 00:37:07,200 just 32 byte what we call state route. 598 00:37:07,400 --> 00:37:12,300 That, that is a commitment to the state in the sense that You 599 00:37:12,300 --> 00:37:16,700 cannot find any other state that would would allow you to compute 600 00:37:16,700 --> 00:37:21,200 this commitment. And and what statelessness does 601 00:37:21,300 --> 00:37:24,000 is that, it gives you all the data that has been read by the 602 00:37:24,000 --> 00:37:27,500 transaction, including so-called Witnesses. 603 00:37:27,500 --> 00:37:32,300 And the witness is a proof that this is the correct data given 604 00:37:32,300 --> 00:37:34,800 the state route and you have the state route, like, you know, 605 00:37:34,800 --> 00:37:37,400 that because it's only very short, so, you can just have 606 00:37:37,400 --> 00:37:39,100 that. So, that's the only thing you 607 00:37:39,100 --> 00:37:42,600 need to store as the current state and the witness Tells you 608 00:37:42,600 --> 00:37:45,400 yes, this this is the, this is the correct data given that 609 00:37:45,400 --> 00:37:49,200 state route. Okay, I see you said earlier 610 00:37:49,200 --> 00:37:53,400 that some people are some valid data, still have to have the 611 00:37:53,400 --> 00:37:55,100 entire State. Why is that? 612 00:37:56,400 --> 00:38:00,300 Well, I mean, this is a design choice and there are different 613 00:38:00,700 --> 00:38:04,200 potential designs here. But the design that we are 614 00:38:04,200 --> 00:38:09,800 aiming for now is, is what we call week statelessness and week 615 00:38:09,800 --> 00:38:13,700 statelessness means that you do need the state in order to 616 00:38:13,700 --> 00:38:17,200 produce blocks but you don't need it in order to validate 617 00:38:17,200 --> 00:38:22,100 blocks and that is a very good trade off in our opinion because 618 00:38:22,800 --> 00:38:27,600 it's okay to limit somewhat more The number of people who are 619 00:38:27,600 --> 00:38:32,400 able to produce blocks and that is in practice, unfortunately, 620 00:38:32,400 --> 00:38:35,500 in some ways going to happen anyway, because of the whole Mev 621 00:38:35,800 --> 00:38:38,400 thing. But as long as you have the 622 00:38:38,700 --> 00:38:42,400 ability to very easily, verify it by everyone, that is okay, 623 00:38:43,200 --> 00:38:47,700 that has that has some very nice implication in terms of the 624 00:38:47,700 --> 00:38:51,000 design space. Like, it means that as a user 625 00:38:51,000 --> 00:38:54,100 for example, you don't like, if you don't have this week's 626 00:38:54,100 --> 00:38:58,200 ageless if you want like Wrong statelessness, and in quotation 627 00:38:58,200 --> 00:39:02,200 marks, then then what you would need is that every user always 628 00:39:02,200 --> 00:39:05,900 keeps the witnesses for their accounts around and I don't 629 00:39:05,900 --> 00:39:07,700 think that is a very practical design. 630 00:39:07,700 --> 00:39:10,900 I think like from the ux point of view the the week list 631 00:39:10,900 --> 00:39:15,500 statelessness is really like a sweet spot that is a very like 632 00:39:15,500 --> 00:39:20,700 can I spot to live in? Okay, so this would then not 633 00:39:20,700 --> 00:39:24,700 reduce the size of the state. But basically, you reduce the 634 00:39:24,800 --> 00:39:28,200 number of people who require to actually keep that state. 635 00:39:28,300 --> 00:39:31,100 That's correct. Another idea that's been thrown 636 00:39:31,100 --> 00:39:33,700 around us statement, right? So basically, so you don't 637 00:39:33,700 --> 00:39:38,000 actually pay to store some sort of data on the blockchain. 638 00:39:38,000 --> 00:39:41,700 Once when you, when you send it in your transaction, but you 639 00:39:41,700 --> 00:39:46,800 actually pay continuously until until you need it. 640 00:39:46,800 --> 00:39:49,000 No longer store. All your money runs out and it 641 00:39:49,000 --> 00:39:51,900 gets deleted automatically. Where's that had? 642 00:39:51,900 --> 00:39:54,500 Do you think that's going to happen that do these ideas work 643 00:39:54,500 --> 00:39:56,900 together as to something else entirely? 644 00:39:58,500 --> 00:40:05,300 We have these discussions around State rent and in a way so 645 00:40:05,300 --> 00:40:10,900 statelessness alleviates this problem a lot because suddenly 646 00:40:10,900 --> 00:40:14,400 instead of like, I mean, we want a very large number of full 647 00:40:14,400 --> 00:40:21,500 nodes, right in the ideal World. Everyone who works in any way 648 00:40:21,500 --> 00:40:25,300 with the theme blockchain would run their own full note for 649 00:40:25,300 --> 00:40:28,100 several reasons, that's not really completely realistic. 650 00:40:28,200 --> 00:40:30,400 Ignou at. This is the future that we are 651 00:40:30,400 --> 00:40:33,200 working towards that in some notion that this is possible. 652 00:40:34,200 --> 00:40:38,300 And and therefore like statelessness really like 653 00:40:38,300 --> 00:40:41,700 reduces this problem of like having the state a lot because 654 00:40:41,700 --> 00:40:45,800 from like tens or hundreds of thousands of parties or Millions 655 00:40:45,800 --> 00:40:49,200 who need to have all the state around all the time on their own 656 00:40:49,200 --> 00:40:53,100 SSD. You suddenly reduce it to like 657 00:40:54,800 --> 00:40:58,500 Say, hundreds of parties who are actually producing blocks on 658 00:40:58,500 --> 00:41:01,000 easy? Are you who have very large 659 00:41:01,200 --> 00:41:04,000 incentives, any way to keep the state around? 660 00:41:04,400 --> 00:41:07,500 I mean, they, yes, they will needed to produce the block, so 661 00:41:08,000 --> 00:41:12,400 it alleviate this problem. A lot, it is a debate, I would 662 00:41:12,400 --> 00:41:16,400 say whether that whether with that state rent is still 663 00:41:16,400 --> 00:41:21,500 necessary, I would say if it comes it will come in a very in 664 00:41:21,500 --> 00:41:24,600 a slightly different form or from what People consider stage 665 00:41:24,600 --> 00:41:29,600 right now so it won't really be an ocean of you continuously pay 666 00:41:29,600 --> 00:41:31,100 in order to have your state alive. 667 00:41:31,700 --> 00:41:37,900 It's more that your state will be will be will after some 668 00:41:37,900 --> 00:41:42,200 period say one year if you didn't do anything with it it 669 00:41:42,200 --> 00:41:46,700 will become part of offer kind of Old State where it can be 670 00:41:46,700 --> 00:41:51,100 reactivated at any time for like maybe paying slightly more gas, 671 00:41:51,700 --> 00:41:54,400 it's not you you can't. Work with it anymore. 672 00:41:54,400 --> 00:41:56,900 So basically, there's, there's no continuous payment. 673 00:41:56,900 --> 00:42:01,200 There's just like, probably this at least the most likely where 674 00:42:01,200 --> 00:42:05,200 version of stay Trend that I see would be that if you don't use 675 00:42:05,200 --> 00:42:08,200 your state for a very long time, you will pay slightly more 676 00:42:08,200 --> 00:42:12,000 because you have to pay for a slightly larger Witness. 677 00:42:13,900 --> 00:42:18,600 Okay, so I see how the size of the theorem state is a problem 678 00:42:18,600 --> 00:42:22,300 for some users, and that it requires ssds and so on. 679 00:42:22,900 --> 00:42:27,300 But, in some sense, an even larger problem with aetherium is 680 00:42:27,300 --> 00:42:32,900 the fact that the evm doesn't allow for parallelization of 681 00:42:32,900 --> 00:42:35,000 computation, right? So, basically, you have to do 682 00:42:35,200 --> 00:42:39,600 everything in a certain order and always look at the entire 683 00:42:39,600 --> 00:42:45,900 state where some other Like chains have taken a more 684 00:42:45,900 --> 00:42:48,600 advanced approach and I mean, they were also later to the 685 00:42:48,600 --> 00:42:49,800 party. So, basically, for them, it was 686 00:42:49,800 --> 00:42:51,900 easy to see what the problems are. 687 00:42:51,900 --> 00:42:57,600 So I'm not taking sides here, but how do you feel about this 688 00:42:57,600 --> 00:43:03,200 inherent inability of the evm to allow for parallelization? 689 00:43:04,400 --> 00:43:08,700 Yeah, I mean, I think that's that's a good point and that, 690 00:43:08,700 --> 00:43:11,500 this, that that's why interesting. 691 00:43:12,000 --> 00:43:15,300 I honestly I'm not an evm engineer, so I cannot say in 692 00:43:15,300 --> 00:43:18,400 detail. If they, if it's impossible to 693 00:43:18,400 --> 00:43:23,600 change this, I can I I think like one large part of that is 694 00:43:23,600 --> 00:43:28,400 actually related in some way to statelessness in that one thing 695 00:43:28,400 --> 00:43:32,200 you would need in order to paralyze, things is to know what 696 00:43:32,200 --> 00:43:34,900 state each transaction axis. Right. 697 00:43:35,100 --> 00:43:38,000 And in a way we are starting to do that. 698 00:43:38,300 --> 00:43:42,000 Now I don't want to say we have a complete way to paralyze 699 00:43:42,000 --> 00:43:45,300 things, but yeah, I mean I can see that that is that is 700 00:43:45,300 --> 00:43:49,100 definitely like a very, very important part and that that 701 00:43:49,100 --> 00:43:53,400 would allow for a certain amount of scaling. 702 00:43:53,400 --> 00:43:58,600 If you, if you, if you paralyzed things and I would say like it's 703 00:43:58,600 --> 00:44:01,300 certainly a very good decision to that to design around that 704 00:44:02,300 --> 00:44:05,300 and I would encourage people who design work Claps to do exactly 705 00:44:05,300 --> 00:44:09,600 that to think about that as well and and maximize the 706 00:44:09,600 --> 00:44:12,500 parallelism, they can get out in order to be faster. 707 00:44:14,200 --> 00:44:18,500 Well let's zoom out a little bit and talk a bit about you know 708 00:44:18,500 --> 00:44:22,900 aetherium and where this project is going, I'd what makes you 709 00:44:22,908 --> 00:44:25,900 excited and what you think is the impact that it will have on 710 00:44:25,900 --> 00:44:31,800 the world. Wow, I think like that is it's 711 00:44:31,800 --> 00:44:36,400 still I mean, it's very, very hard in our time to make 712 00:44:36,600 --> 00:44:40,600 predictions about things further than five to ten years out. 713 00:44:40,600 --> 00:44:45,300 I would say because there's just too many things that are on on 714 00:44:45,300 --> 00:44:48,900 exponential trajectories, I'd settle for five to ten years out 715 00:44:48,900 --> 00:44:54,100 there. I think if they are young can 716 00:44:54,100 --> 00:44:57,400 provide many, many different things for different. 717 00:44:57,600 --> 00:45:02,200 This, it's essentially this coordination layer that allows 718 00:45:02,200 --> 00:45:05,700 you to make certain certain parts. 719 00:45:05,700 --> 00:45:08,400 Of course, it doesn't replace a community in any way, right? 720 00:45:08,400 --> 00:45:12,200 Like it's only a technical layer but allows you to solve some of 721 00:45:12,200 --> 00:45:16,700 the problems of getting communities aligned on certain 722 00:45:16,700 --> 00:45:20,800 goals and turning things into positive, some games. 723 00:45:20,800 --> 00:45:24,000 I think that is the amazing thing that this technology 724 00:45:24,000 --> 00:45:29,100 allows and we have seen that around This Resurgence. 725 00:45:29,100 --> 00:45:32,700 Now after I guess the initial shock of daoist like, where 726 00:45:32,700 --> 00:45:38,000 many, many people have started creating dowels and and they 727 00:45:38,000 --> 00:45:40,700 seem to work in some ways at least for now, which is great. 728 00:45:40,700 --> 00:45:43,000 Like this is amazing, communities are found together 729 00:45:43,100 --> 00:45:46,200 and have found a way to coordinate around certain goals 730 00:45:46,400 --> 00:45:50,900 without having to go through the traditional way of doing this by 731 00:45:51,000 --> 00:45:53,500 a corporation, for example, which would have been the old 732 00:45:53,500 --> 00:45:56,700 way which has like other costs associated with it is 733 00:45:56,707 --> 00:46:02,000 essentially You said that it turns things into positive, some 734 00:46:02,000 --> 00:46:04,100 games. So let me ask you for the 735 00:46:04,100 --> 00:46:05,900 metric. So basically, what's the metric 736 00:46:05,900 --> 00:46:09,200 that you think is going to improve for the average Joe 737 00:46:09,200 --> 00:46:13,500 using blockchain technology? I mean, the average Joe right 738 00:46:13,500 --> 00:46:16,000 now doesn't use blockchain technology, right? 739 00:46:17,000 --> 00:46:21,800 Basically, nobody does that and I think the question can be on 740 00:46:21,800 --> 00:46:24,500 many, many different levels and I think we are already seeing 741 00:46:24,500 --> 00:46:26,500 it. Surprisingly, like, it, it 742 00:46:26,500 --> 00:46:29,700 essentially, it changes the game of Finance at the moment. 743 00:46:29,700 --> 00:46:32,500 Mainly because Financial applications are what comes 744 00:46:32,500 --> 00:46:35,400 first just because they had just have the most money, the most 745 00:46:35,400 --> 00:46:39,300 willingness to pay. But but this permission is 746 00:46:39,300 --> 00:46:43,800 ecosystem that allows anyone to just go there and create like 747 00:46:43,800 --> 00:46:47,600 create something and deploy it without having to ask anyone for 748 00:46:47,600 --> 00:46:51,000 permission allows people to just play with it a lot. 749 00:46:51,300 --> 00:46:55,600 And I think we are right now we're already seeing the effect 750 00:46:55,600 --> 00:46:58,900 of that in terms of all the the fintechs. 751 00:46:58,900 --> 00:47:03,800 Like I mean my Barton my online banking apps have improved like 752 00:47:03,900 --> 00:47:07,500 tons over the last year's and I think this is obviously not 753 00:47:07,500 --> 00:47:10,800 based on blockchain technology but it's based on the pressure 754 00:47:10,800 --> 00:47:13,700 that these Companies now see where the compute competition 755 00:47:13,700 --> 00:47:16,900 will come from like you don't have to be a blockchain user in 756 00:47:16,900 --> 00:47:20,300 order to see the Improvement, it will come to you anyway because 757 00:47:20,300 --> 00:47:22,800 the others have to keep up. Otherwise we're coming for them. 758 00:47:24,900 --> 00:47:28,700 So you mentioned finances, this kind of first area that's 759 00:47:28,700 --> 00:47:32,100 getting a lot of traction. And then you also talked about 760 00:47:32,100 --> 00:47:36,900 how, you know, on a high level you see if there are more block 761 00:47:36,900 --> 00:47:40,500 changes this, like coordination layer that allows, you know, 762 00:47:40,500 --> 00:47:43,900 allows people to accomplish things more efficiently together 763 00:47:44,600 --> 00:47:48,000 to what extent do you also think that blockchains will kind of 764 00:47:48,000 --> 00:47:51,500 financial eyes? A lot of things around 765 00:47:51,500 --> 00:47:55,500 coordination that are today don't Rely on financial 766 00:47:55,500 --> 00:48:01,900 incentives, directly. Oh this is a difficult question. 767 00:48:01,900 --> 00:48:05,300 I'm not sure what you mean like do you mean your local sports 768 00:48:05,300 --> 00:48:09,600 club is going to become a dowel and suddenly everyone has a 769 00:48:09,607 --> 00:48:12,200 token or something. I'm not sure what that question 770 00:48:12,200 --> 00:48:14,100 refers to. Well I guess it sort of ties 771 00:48:14,100 --> 00:48:16,000 into like it. I think knows especially is 772 00:48:16,000 --> 00:48:18,100 done, like some work around ideas like this to right? 773 00:48:18,100 --> 00:48:22,200 Where you'd use that prediction markets to have make decisions 774 00:48:22,200 --> 00:48:27,600 as organizations. And I think I mean, I can see 775 00:48:27,600 --> 00:48:32,000 the sphere but I think Mainly it provides new options. 776 00:48:32,000 --> 00:48:36,300 I don't, I don't think nobody is going to force you to use 777 00:48:36,500 --> 00:48:38,400 Financial eyes. Prediction Market. 778 00:48:38,400 --> 00:48:41,000 It is still like, it is still your choice. 779 00:48:41,300 --> 00:48:46,000 So I don't see why it would would become like a forcing 780 00:48:46,000 --> 00:48:49,600 function for average people to just financialized everything. 781 00:48:49,800 --> 00:48:51,900 I'm you can, but this is your choice. 782 00:48:51,900 --> 00:48:56,700 And I think, like, many men, blockchains will provide things 783 00:48:56,700 --> 00:48:58,400 that are not Financial in nature. 784 00:48:58,500 --> 00:49:01,400 Like Systems can be built on top of them. 785 00:49:01,600 --> 00:49:07,200 Who says, we can't now already, for example, build a Twitter, a 786 00:49:07,200 --> 00:49:09,300 decentralized Twitter. For example, I think that would 787 00:49:09,300 --> 00:49:12,600 absolutely be possible. People are already beat building 788 00:49:12,600 --> 00:49:16,200 decentralized messaging apps, that doesn't have to be dfb 789 00:49:16,600 --> 00:49:20,400 financialized, so I don't see that automatically everything 790 00:49:20,400 --> 00:49:25,500 has to be financialized. So you think the fact that open 791 00:49:25,500 --> 00:49:31,600 finance has moved in fast is just because of ideological 792 00:49:31,600 --> 00:49:37,400 proximity or, you know, being Tech adjacent and the more 793 00:49:37,400 --> 00:49:41,700 social apps are going to come at a later point in time, but they 794 00:49:41,700 --> 00:49:46,400 are come. I think right now, I think it's 795 00:49:46,400 --> 00:49:51,200 just that the more social for example apps as you call them 796 00:49:51,800 --> 00:49:55,700 are just priced out of it and that is a natural consequence of 797 00:49:55,900 --> 00:49:59,400 Finance. Just always liked being there 798 00:49:59,400 --> 00:50:02,100 and and being just a very valuable application. 799 00:50:02,100 --> 00:50:04,900 Like let's be honest about it, Finance is a very valuable 800 00:50:04,900 --> 00:50:08,300 application, but it means that it prices a lot of things, which 801 00:50:08,300 --> 00:50:11,600 is kind of a shame from the development perspective. 802 00:50:11,600 --> 00:50:15,500 Because obviously, We are losing kind of important time where 803 00:50:15,500 --> 00:50:18,900 these other systems could bootstrap themselves and could 804 00:50:18,900 --> 00:50:23,800 start providing valuable things. But but I mean, we are now 805 00:50:23,800 --> 00:50:26,600 building the rails that will allow those in my opinion. 806 00:50:26,600 --> 00:50:29,600 I think like, when we have sharding, when we have those 807 00:50:30,700 --> 00:50:34,500 people will build all these other systems on them and they 808 00:50:34,500 --> 00:50:39,300 become I think and I think I'll end on a divisive question here. 809 00:50:40,000 --> 00:50:44,200 Do you think the applications that Eat less economic security 810 00:50:44,200 --> 00:50:47,300 because they will not be securing the values that 811 00:50:47,300 --> 00:50:50,900 Financial applications. Inherently do will actually 812 00:50:50,900 --> 00:50:54,700 needy theorem as a base layer, I mean quote, they quit, they run 813 00:50:54,700 --> 00:50:59,000 on any number of other particles that don't have the economic 814 00:50:59,000 --> 00:51:01,200 guarantees that a theorem currently has. 815 00:51:02,300 --> 00:51:04,500 I think we're there are different questions. 816 00:51:04,500 --> 00:51:09,100 The and I mean, I would say probably yes if you if you 817 00:51:09,100 --> 00:51:12,400 expect that the decentralized Twitter will just put its data. 818 00:51:12,500 --> 00:51:15,700 On the shards. I don't expect that that will be 819 00:51:15,700 --> 00:51:18,600 the case. I think what it will do, what 820 00:51:18,700 --> 00:51:26,200 many applications might do is use some blockchain and maybe if 821 00:51:26,200 --> 00:51:29,400 they're young because it is the settlement layer, but who knows? 822 00:51:29,400 --> 00:51:33,300 Whether that is nestled the case in the future will use this. 823 00:51:33,500 --> 00:51:37,900 For example, any of these applications they can right now 824 00:51:38,000 --> 00:51:40,400 let's talk about two or for example, which is concrete, 825 00:51:40,400 --> 00:51:42,400 decentralized applications, there's out there now. 826 00:51:42,600 --> 00:51:46,200 But it has huge problems. Getting people to actually run 827 00:51:46,200 --> 00:51:49,900 notes, right? We do need some sort of payment 828 00:51:49,900 --> 00:51:53,200 for this, like we knew do need some way of getting people to, 829 00:51:53,200 --> 00:51:55,400 like, run the infrastructure and so on. 830 00:51:55,600 --> 00:51:58,600 And I think that is more important like, that, that, that 831 00:51:58,600 --> 00:52:01,500 is where blockchains like etherium coming. 832 00:52:02,200 --> 00:52:04,300 Probably not for the data itself. 833 00:52:04,300 --> 00:52:07,500 You don't, you don't need to, but, but it could be for some 834 00:52:07,500 --> 00:52:10,900 sort of commitment to the data that makes a lot of sense, but 835 00:52:10,900 --> 00:52:14,500 not for the data itself, I would I would predict in the long run. 836 00:52:15,800 --> 00:52:19,100 But the economic incentive, they are surely, the, The Economic 837 00:52:19,100 --> 00:52:24,300 Securities that should require depend on how large the 838 00:52:24,300 --> 00:52:26,800 incentives are, right? So basically if the intent of 839 00:52:28,000 --> 00:52:32,000 miniscule compared to the security that if you affords, 840 00:52:32,000 --> 00:52:35,500 you then using a theorem as based am a be over care. 841 00:52:35,500 --> 00:52:40,100 Right. I expect that ethereum with 842 00:52:40,100 --> 00:52:43,800 Roll-Ups and charts will be will be quite cheap. 843 00:52:44,100 --> 00:52:52,800 So I Not think that you expect to pay wiii, I would say it's in 844 00:52:52,800 --> 00:52:55,600 the send or substandard range, what you would expect for normal 845 00:52:55,600 --> 00:53:00,300 transactions in in that future in Ethiopia - I think a lot of 846 00:53:00,300 --> 00:53:02,200 applications will be able to pay that. 847 00:53:03,000 --> 00:53:06,000 I think this is actually a super nice closing statement. 848 00:53:06,000 --> 00:53:09,300 So subsequent transaction fees. You heard it here first. 849 00:53:09,600 --> 00:53:11,400 Thank rat. Thank you so much for coming on. 850 00:53:12,100 --> 00:53:15,100 It was a pretty technical but I think there was a lot there. 851 00:53:15,100 --> 00:53:20,200 So If people want to dig into this somewhat, where should 852 00:53:20,200 --> 00:53:22,600 where can they go? And find more information on 853 00:53:22,600 --> 00:53:26,200 these topics. The, the depends, obviously, on 854 00:53:26,200 --> 00:53:29,500 the technical level that they want to get into. 855 00:53:29,800 --> 00:53:34,800 There are a lot of people trying to write blog posts about about 856 00:53:34,800 --> 00:53:37,400 these things. I can certainly collect some 857 00:53:37,400 --> 00:53:41,400 resources and we can add them to the description of the podcast. 858 00:53:42,200 --> 00:53:44,100 Honestly, we could do better in that respect. 859 00:53:44,100 --> 00:53:47,700 I don't think we're like, we're and I would encourage if 860 00:53:47,700 --> 00:53:50,600 anyone's to come forward and is good at it's digesting. 861 00:53:50,600 --> 00:53:53,000 The information writing it up. We need more of that. 862 00:53:53,000 --> 00:53:55,200 It's way too little and the whole space and I know many 863 00:53:55,200 --> 00:53:59,300 people have trouble catching up. If you really want to get into 864 00:53:59,300 --> 00:54:01,600 the tech, then I think III search. 865 00:54:01,600 --> 00:54:05,900 The Forum is an amazing like resource that has a lot of stuff 866 00:54:06,000 --> 00:54:09,500 and it's usually not super difficult to understand people 867 00:54:09,500 --> 00:54:11,800 try to make it somewhat understandable. 868 00:54:12,000 --> 00:54:15,700 The main problem is just a huge amount of information to digest, 869 00:54:15,700 --> 00:54:19,100 that most people probably can't completely catch up with. 870 00:54:20,300 --> 00:54:25,000 Okay, we're linked to these. Thank you for joining us on this 871 00:54:25,000 --> 00:54:27,400 week's episode. We release new episodes every 872 00:54:27,400 --> 00:54:29,400 week. You can find And subscribe to 873 00:54:29,400 --> 00:54:33,200 the show on iTunes Spotify, YouTube SoundCloud or wherever 874 00:54:33,200 --> 00:54:35,600 you listen to podcast. And if you have a Google home or 875 00:54:35,600 --> 00:54:38,400 Alexa device, you can tell it to listen to the latest episode of 876 00:54:38,400 --> 00:54:42,100 the epicenter podcast, go to epicenter dot TV /, subscribe 877 00:54:42,200 --> 00:54:44,900 for a full list of places where you can watch and listen, while 878 00:54:44,900 --> 00:54:47,300 you're there, be sure to sign up for the newsletter so you get 879 00:54:47,300 --> 00:54:49,500 new episodes in your inbox as they're released. 880 00:54:50,200 --> 00:54:52,600 If you want to interact with us guests or other podcast 881 00:54:52,600 --> 00:54:55,500 listeners, you can follow Oh us on Twitter and please leave us a 882 00:54:55,500 --> 00:54:58,200 review on iTunes helps people find the show and we're always 883 00:54:58,200 --> 00:55:01,100 happy to read them. Well thanks so much and we look 884 00:55:01,100 --> 00:54:55,100 forward to being back next week. Oh us on Twitter and please 885 00:54:55,100 --> 00:54:57,800 leave us a review on iTunes helps people find the show and 886 00:54:57,800 --> 00:55:01,100 we're always happy to read them. Well thanks so much and we look 887 00:55:01,100 --> 00:55:02,300 forward to being back next week.