1 00:00:00,040 --> 00:00:02,000 You need to actually store all that state somewhere. 2 00:00:02,400 --> 00:00:04,480 And for a billion users, it's actually going to be a lot of 3 00:00:04,480 --> 00:00:06,040 state. And this is usually everybody 4 00:00:06,040 --> 00:00:07,680 talks, you know, talks about GPS. 5 00:00:07,680 --> 00:00:11,320 But actually one of the bigger bottlenecks right now across the 6 00:00:11,320 --> 00:00:14,440 space is state. And so obviously no single 7 00:00:14,440 --> 00:00:19,120 computer, no single kind of node can process all that can 8 00:00:19,120 --> 00:00:22,160 validate the whole network. Now you can rotate this, 9 00:00:22,160 --> 00:00:26,320 validators validate what chart all the time, every block they 10 00:00:26,320 --> 00:00:27,840 can be. Actually, you know you can 11 00:00:27,840 --> 00:00:32,880 randomly select set of validators and they are able to 12 00:00:33,040 --> 00:00:35,680 validate this because they don't need to sink into the Shard. 13 00:00:35,680 --> 00:00:38,840 They don't need to process every single transaction that ever hit 14 00:00:38,840 --> 00:00:41,280 that Shard. They only need to look at this 15 00:00:41,280 --> 00:00:43,560 specific block. The data availability and 16 00:00:43,560 --> 00:00:47,960 consensus are merged together into a single single mechanic. 17 00:00:48,280 --> 00:00:52,320 The essence of it is you you want to have a design that is 18 00:00:52,320 --> 00:00:58,480 not dependent on the underlying hardware itself improving at a 19 00:00:58,480 --> 00:01:02,080 certain rate to be able to service user demands. 20 00:01:02,240 --> 00:01:06,280 You want to have mechanisms beyond that type of scaling. 21 00:01:20,440 --> 00:01:22,400 This episode is brought to you by Gnosis. 22 00:01:22,960 --> 00:01:26,120 Gnosis builds decentralized infrastructure for the Ethereum 23 00:01:26,120 --> 00:01:30,880 ecosystem with a rich history dating back to 2015 and products 24 00:01:30,880 --> 00:01:35,800 like Safe Cow Swap or Gnosis Chain, Gnosis combines Needs 25 00:01:35,800 --> 00:01:39,240 Driven Development with deep technical expertise. 26 00:01:40,000 --> 00:01:43,600 This year marks the launch of Gnosis Pay, the world's first 27 00:01:43,600 --> 00:01:48,040 decentralized payment network. With Agnosis Card you can spend 28 00:01:48,040 --> 00:01:51,880 self custody crypto at any Visa accepting merchant around the 29 00:01:51,880 --> 00:01:54,360 world. If you're an individual looking 30 00:01:54,360 --> 00:01:57,840 to live more on Chain or a business looking to white label 31 00:01:57,840 --> 00:02:02,640 the stack, visit gnosispay.com. There are lots of ways you can 32 00:02:02,640 --> 00:02:06,200 join the Gnosis journey. Drop in the Gnosis Dow 33 00:02:06,200 --> 00:02:10,120 Governance form, become a Gnosis validator with a single GNO 34 00:02:10,120 --> 00:02:14,560 token and low cost hardware, or deploy your product on the EVM 35 00:02:14,560 --> 00:02:17,400 compatible and highly decentralized Gnosis chain. 36 00:02:18,400 --> 00:02:21,280 Get started today at Gnosis dot IO. 37 00:02:22,840 --> 00:02:26,520 First One is one of the biggest node operators globally and help 38 00:02:26,520 --> 00:02:30,600 you stake your tokens on 45 plus networks like Ethereum, Cosmos, 39 00:02:31,040 --> 00:02:35,520 Celestia and Dydx. More than 100,000 delegators 40 00:02:35,520 --> 00:02:39,040 stake with Chorus One including institutions like Bit, Go and 41 00:02:39,040 --> 00:02:41,800 Ledger. Sticking with Chorus 1 not only 42 00:02:41,800 --> 00:02:46,520 gets you the highest years, but also the most robust security 43 00:02:46,520 --> 00:02:49,640 practices and infrastructure that are usually exclusive for 44 00:02:49,640 --> 00:02:53,000 institutions. You can stake directly to Chorus 45 00:02:53,000 --> 00:02:56,000 One's public note from your wallet, set up a white label 46 00:02:56,000 --> 00:03:00,000 note, or use the recently launched product Opus to stake 47 00:03:00,000 --> 00:03:02,800 up to 8000 ETH in a single transaction. 48 00:03:03,560 --> 00:03:07,240 You can even offer high yield staking to your own customers 49 00:03:07,520 --> 00:03:10,240 using their API. Your assets always remain in 50 00:03:10,240 --> 00:03:12,840 your custody so you can have complete Peace of Mind. 51 00:03:13,040 --> 00:03:16,000 Start staking today at Chorus .1. 52 00:03:17,440 --> 00:03:19,440 Hello everyone, welcome to Epicentre. 53 00:03:20,000 --> 00:03:22,680 Today I have an amazing episode lined up for you. 54 00:03:23,320 --> 00:03:28,320 We're talking to Alex and Ilya, the Co founders of Near, which 55 00:03:28,320 --> 00:03:32,440 is a in production sharded blockchain with a lot of value 56 00:03:32,480 --> 00:03:36,400 riding on it. Specifically, we will cover how 57 00:03:36,400 --> 00:03:40,240 near sharding actually works, try to build it concept by 58 00:03:40,240 --> 00:03:44,280 concept into an integrated hole, and then understand where they 59 00:03:44,280 --> 00:03:46,120 are in their journey to implement sharding. 60 00:03:46,920 --> 00:03:48,840 Alex and Ilya, welcome to Epicenter. 61 00:03:49,760 --> 00:03:54,000 So at this point, we've kind of done a few episodes with both of 62 00:03:54,000 --> 00:03:56,880 you. Maybe you could give you know a 63 00:03:56,880 --> 00:03:59,240 short introduction to your to your backgrounds. 64 00:04:00,800 --> 00:04:04,000 Hi, yeah I think at this point my background is all near. 65 00:04:04,720 --> 00:04:06,320 Everything that was before is irrelevant. 66 00:04:06,320 --> 00:04:10,240 But yeah, I I was working on the sharded database called Mem 67 00:04:10,240 --> 00:04:15,280 Sequel before near for five years which is right now it's an 68 00:04:15,640 --> 00:04:20,880 in production sharded database and and before that I was at 69 00:04:20,880 --> 00:04:24,120 Microsoft. Yeah, I mean my background is 70 00:04:24,120 --> 00:04:28,080 actually in machine learning. AII was at Google research prior 71 00:04:28,080 --> 00:04:34,360 to our startup adventures and I was one of the class. 72 00:04:34,360 --> 00:04:37,400 I was in a paper that introduced Transformers which is technology 73 00:04:37,400 --> 00:04:41,640 powering ChatGPT majority and other AI advancements. 74 00:04:42,320 --> 00:04:45,120 And then with Alex, we actually started originally near as AI 75 00:04:45,120 --> 00:04:52,640 company and realized we need SAS, cheap, easy to use, easy to 76 00:04:52,640 --> 00:04:58,360 build on blockchain because we wanted to use it ourselves for 77 00:04:58,880 --> 00:05:02,880 data crowdsourcing and some other data use cases for our AI 78 00:05:02,880 --> 00:05:09,800 company and adaptivity to that in 2018 and yeah, focusing on 79 00:05:09,800 --> 00:05:14,760 that ever since. Yeah, let's get into sharding, 80 00:05:15,920 --> 00:05:21,520 blockchain scalability. So what is sharding overall and 81 00:05:21,880 --> 00:05:26,080 why has it been a generally difficult target industry wide? 82 00:05:28,280 --> 00:05:33,360 I think I mean maybe broader question is if if you imagine 83 00:05:33,360 --> 00:05:38,320 having a billion users coming in and using blockchain as a means, 84 00:05:38,480 --> 00:05:42,280 payments as a mean of tracking ownership as a way to kind of 85 00:05:42,400 --> 00:05:45,160 coordinate resources and efforts. 86 00:05:47,040 --> 00:05:50,560 You imagine that you need to have kind of a few things 87 00:05:50,560 --> 00:05:53,160 happening, right? One is you need to actually 88 00:05:53,160 --> 00:05:56,280 store all that state somewhere and for a billion users it's 89 00:05:56,280 --> 00:05:57,360 actually going to be a lot of state. 90 00:05:57,360 --> 00:06:00,320 And this is usually everybody talks, you know talks about GPS. 91 00:06:00,320 --> 00:06:04,000 But actually one of the bigger bottlenecks right now across the 92 00:06:04,000 --> 00:06:08,920 space is state and kind of its growth and so. 93 00:06:08,920 --> 00:06:10,480 So that's probably problem number one. 94 00:06:10,480 --> 00:06:13,760 Problem #2 is, I mean you have billion users try, they 95 00:06:13,760 --> 00:06:15,760 transacting. There's a, you know, hundreds of 96 00:06:15,760 --> 00:06:18,920 thousands of applications. Obviously there's a lot of 97 00:06:19,400 --> 00:06:22,680 transactions flying around and and a lot of processing that 98 00:06:22,680 --> 00:06:25,200 needs to happen and kind of people want to put more and more 99 00:06:25,200 --> 00:06:28,360 complex smart contracts and complex logic indices. 100 00:06:28,720 --> 00:06:33,200 So you need to have throughput, bandwidth and processing power 101 00:06:33,200 --> 00:06:36,520 to do this. And so obviously no single 102 00:06:36,520 --> 00:06:41,200 computer, no single kind of node can process all that can 103 00:06:41,200 --> 00:06:46,400 validate the whole network. And so the way to support this 104 00:06:46,400 --> 00:06:49,120 is one way or the other, partition this computation, 105 00:06:49,120 --> 00:06:53,160 partition this storage and partition this kind of bad list 106 00:06:53,160 --> 00:06:59,160 to receive this. And so people have kind of 107 00:06:59,280 --> 00:07:02,640 historically been talking about sharding because that's how the 108 00:07:02,680 --> 00:07:05,760 two companies doing this, right. So Alex mentioned, you know, 109 00:07:05,760 --> 00:07:10,920 doing this kind of in web two world, then SQL single store now 110 00:07:11,080 --> 00:07:13,760 is used by Fortune 500 companies. 111 00:07:14,120 --> 00:07:19,720 You know Google and Facebook have their own solutions and it 112 00:07:19,760 --> 00:07:22,040 kind of seemed reasonable that this is an approach that you 113 00:07:22,040 --> 00:07:26,520 should take in blockchain. Now there are a lot of kind of 114 00:07:27,280 --> 00:07:30,600 problems that arise when you actually move into a 115 00:07:30,600 --> 00:07:34,880 permissionless setup, kind of compared to a permission setup 116 00:07:34,880 --> 00:07:36,800 that usually left two companies to deal with. 117 00:07:38,200 --> 00:07:42,000 I also want to add, Ilya said. It's obvious that you need to 118 00:07:42,000 --> 00:07:45,760 share processing. I don't think it was obvious to 119 00:07:45,760 --> 00:07:49,040 everybody until recently. So there were multiple block 120 00:07:49,040 --> 00:07:52,200 chains which were like the favorite thing they were, they 121 00:07:52,200 --> 00:07:55,280 like to say was like, look, look at Visa, look at how many 122 00:07:55,280 --> 00:07:57,920 transactions Visa processes. And that's a world scale. 123 00:07:58,240 --> 00:08:00,760 Obviously, we can do it on a single computer, right? 124 00:08:00,760 --> 00:08:02,960 But as a user, you don't use Visa frequently, right? 125 00:08:02,960 --> 00:08:06,080 You use it like 3 * a day on a good day, right? 126 00:08:06,080 --> 00:08:10,160 And so finally now generally when Neo launched we made 127 00:08:10,400 --> 00:08:13,400 multiple bets which were not obvious to everybody. 128 00:08:13,400 --> 00:08:16,160 You know like when near from day one we had that named accounts 129 00:08:16,520 --> 00:08:21,200 where you can rotate keys and and we had charding and it was 130 00:08:21,200 --> 00:08:23,760 an obvious to everybody that it's useful and now suddenly 131 00:08:24,240 --> 00:08:29,000 very scalable block chains which are not charted yet you know 132 00:08:29,560 --> 00:08:34,960 congested and they have no way of getting any more performant, 133 00:08:35,520 --> 00:08:37,520 right. And and similarly like you know 134 00:08:37,520 --> 00:08:40,720 when it comes to account abstraction like a theorem right 135 00:08:40,720 --> 00:08:44,800 now is switching to to that, so, so now finally it is becoming 136 00:08:44,840 --> 00:08:47,680 obvious to everybody that those were correct decisions. 137 00:08:49,320 --> 00:08:52,360 Yeah, I mean to give an example, right, like any, any kind of a 138 00:08:52,360 --> 00:08:55,800 single, I call it single node blockchain, right, which is 139 00:08:55,800 --> 00:08:59,840 something that every single node in the network needs to process 140 00:08:59,840 --> 00:09:02,720 every single transaction and store all the state, right. 141 00:09:03,120 --> 00:09:06,360 What it means is as soon as like let's say that that work has a 142 00:09:06,360 --> 00:09:09,600 high capacity, they also have a huge state growth. 143 00:09:09,600 --> 00:09:13,360 They have kind of limit on how many transactions they can 144 00:09:13,360 --> 00:09:16,160 process because of the bandwidth and execution. 145 00:09:16,720 --> 00:09:20,960 And so at some point there will be more demand like if if and it 146 00:09:20,960 --> 00:09:23,720 is very natural thing, right, the price for the transactions 147 00:09:23,720 --> 00:09:27,840 usually based on supply demand. And so while transactions are 148 00:09:27,840 --> 00:09:30,680 cheap, don't you know at some point there will be more demand 149 00:09:30,680 --> 00:09:35,760 because they're so cheap to even just spam spam it to try to get 150 00:09:35,880 --> 00:09:39,920 some financial benefit from because the transaction fees are 151 00:09:39,920 --> 00:09:42,640 so cheap. And so when that happens, right, 152 00:09:42,840 --> 00:09:46,640 you don't have a way to expand capacity, so your your prices 153 00:09:46,640 --> 00:09:48,640 start to grow for everyone, right. 154 00:09:49,240 --> 00:09:53,720 And so, so this leads to now you kind of pricing out people who 155 00:09:53,720 --> 00:09:57,240 are using this blockchain originally for normal use cases 156 00:09:57,240 --> 00:10:00,960 because of the spam and kind of people trying to run arbitrage 157 00:10:01,160 --> 00:10:04,760 for some other application. And so that's kind of just the 158 00:10:04,760 --> 00:10:09,880 principle where like any single like kind of state machine, 159 00:10:09,880 --> 00:10:12,360 right singular thing machine will get over on and start 160 00:10:12,360 --> 00:10:14,400 rising fees. Right. 161 00:10:14,400 --> 00:10:18,280 So kind of Solana is the, you know, contrasting example. 162 00:10:18,280 --> 00:10:21,720 Of course, even Ethereum and Bitcoin are based on the idea 163 00:10:21,720 --> 00:10:24,920 that the miners or the validators and even the full 164 00:10:24,920 --> 00:10:30,040 nodes of these system have to process every transaction that 165 00:10:30,040 --> 00:10:33,280 is happening in the system. Solana has taken that idea and 166 00:10:33,280 --> 00:10:38,000 said yes, we have a bunch of validators at the 1800 or 167 00:10:38,000 --> 00:10:42,720 something like that currently, and every transaction that goes 168 00:10:42,720 --> 00:10:46,280 to the Solana system has to be processed by every one of these 169 00:10:46,280 --> 00:10:49,200 validators. They are assuming that, OK, 170 00:10:49,200 --> 00:10:54,240 these validators can be placed in data centers where networking 171 00:10:54,240 --> 00:10:56,440 bandwidth is very high, which means a lot. 172 00:10:56,440 --> 00:11:00,440 They can ingest a lot of transactions from the network at 173 00:11:00,440 --> 00:11:03,480 a very high rate. They also assume that the 174 00:11:03,480 --> 00:11:08,960 machines are very performant, so the work of accounting can be. 175 00:11:09,840 --> 00:11:15,600 You can assume that each machine can handle lots of transactions 176 00:11:16,240 --> 00:11:21,640 do do their, do their accounting work and then Solana would also 177 00:11:21,640 --> 00:11:24,240 assume that. OK, maybe the history doesn't 178 00:11:24,240 --> 00:11:27,560 need to be stored by these machines, they only need to 179 00:11:27,560 --> 00:11:29,880 store the currently. What are the different accounts 180 00:11:29,880 --> 00:11:34,480 and what what balances they own and what they they kind of like 181 00:11:34,520 --> 00:11:40,360 a project like Solana assumes is the improvement in in compute in 182 00:11:40,360 --> 00:11:44,360 terms of like bandwidth, processing power, every 183 00:11:44,360 --> 00:11:48,840 resources it kind of double S on some time scale so some 184 00:11:48,840 --> 00:11:50,680 resources double on 12 month time scale. 185 00:11:50,680 --> 00:11:53,840 Another one doubt might download three-year time scale, but 186 00:11:53,840 --> 00:11:56,920 because of this, doubling the capacity of the blockchain would 187 00:11:56,920 --> 00:12:02,840 keep growing at a certain rate and the hope is that the user 188 00:12:02,840 --> 00:12:05,720 growth is actually slower than the doubling rate of the 189 00:12:05,760 --> 00:12:09,280 underlying hardware and therefore you continue to have 190 00:12:09,280 --> 00:12:13,800 like a cheap blockchain. Whereas in the near case like 191 00:12:13,800 --> 00:12:17,840 near the opposite approach where we where you say user growth can 192 00:12:17,840 --> 00:12:22,240 be way faster than the improvement in hardware. 193 00:12:23,160 --> 00:12:27,280 So fundamentally you need to move away from the paradigm of 194 00:12:28,160 --> 00:12:32,120 every validator or every node needing to store. 195 00:12:32,120 --> 00:12:35,520 First of all what are the balances of every account in the 196 00:12:35,520 --> 00:12:38,560 system are, and then you also need to. 197 00:12:39,240 --> 00:12:44,800 So basically no single machine may have a complete view on what 198 00:12:44,800 --> 00:12:48,640 the balances of every account on the near system is. 199 00:12:49,280 --> 00:12:55,200 And then it might also be the case that there's some machine 200 00:12:55,200 --> 00:12:58,720 and there's some transaction on the network and that transaction 201 00:12:58,720 --> 00:13:03,400 happened, but this machine is part of is is is part of part of 202 00:13:03,400 --> 00:13:06,120 processing that network, but it never actually executed the 203 00:13:06,120 --> 00:13:11,520 transaction itself. And so the essence of it is you 204 00:13:11,840 --> 00:13:16,800 you want to have a design that is not dependent on the 205 00:13:16,880 --> 00:13:20,960 underlying hardware itself improving at a certain rate to 206 00:13:20,960 --> 00:13:25,560 be able to service user demands. You want to have mechanisms 207 00:13:25,560 --> 00:13:31,080 beyond that type of scaling. Yeah, I would add that as I 208 00:13:31,080 --> 00:13:36,720 said, it's not even about users, it's it's actually in in in a 209 00:13:36,720 --> 00:13:42,280 way it's sadly the economics, the economics of this blockchain 210 00:13:42,320 --> 00:13:50,720 isn't such that you need to have kind of a way to expand capacity 211 00:13:50,760 --> 00:13:55,040 otherwise if you want to maintain low fees because that's 212 00:13:55,080 --> 00:13:59,000 that's at some like at some level there will be such like 213 00:13:59,240 --> 00:14:04,400 saturation where some subset of people are willing to pay higher 214 00:14:04,400 --> 00:14:07,760 fees because they need planning like they try to capture some 215 00:14:07,760 --> 00:14:11,960 economic value from an exchange token, launch whatever trading 216 00:14:12,600 --> 00:14:16,880 and that in turn increases price for everybody else, right. 217 00:14:16,880 --> 00:14:20,280 And so so Solana and and some other like kind of high capacity 218 00:14:20,280 --> 00:14:24,920 networks even though the idea that like hey we we have to have 219 00:14:24,920 --> 00:14:27,680 capacity and it will grow over time. 220 00:14:27,800 --> 00:14:30,840 The reality what happens is since that it gets slotted by 221 00:14:31,120 --> 00:14:35,520 transactions that are all trying to hit kind of the same economic 222 00:14:35,520 --> 00:14:39,400 opportunity and extracted value. And so that people are willing 223 00:14:39,400 --> 00:14:44,760 to pay way higher fees than folks that are potentially using 224 00:14:44,760 --> 00:14:48,880 it for you know other use cases right for payments for example 225 00:14:48,880 --> 00:14:51,200 and others. And so that's kind of the, the 226 00:14:51,200 --> 00:14:54,880 point is and this is to add to the side that like in the state 227 00:14:54,880 --> 00:14:57,640 grows and everything requires validators to continuously 228 00:14:57,640 --> 00:15:01,800 expand their hardware even it just to continue maintaining the 229 00:15:01,800 --> 00:15:04,880 network. So, so I think like to me 230 00:15:05,080 --> 00:15:09,680 actually like past like 3-4 months have been a really great 231 00:15:09,680 --> 00:15:12,320 validation and then this is not just about salon base and other 232 00:15:12,320 --> 00:15:17,240 like kind of even you know bases centralized sequencer, right. 233 00:15:17,240 --> 00:15:19,320 There's a single server effectively. 234 00:15:19,680 --> 00:15:21,880 But if the Nets cannot catch up with all the transactions that 235 00:15:21,880 --> 00:15:24,720 they need to process. And so that's kind of an example 236 00:15:24,720 --> 00:15:27,160 of just like as soon as you have enough economic activity, you 237 00:15:27,160 --> 00:15:30,760 starting to get kind of this slot of transactions trying to 238 00:15:30,760 --> 00:15:33,000 capture that. And you don't have any way to 239 00:15:33,360 --> 00:15:36,960 either isolate it and add that extra capacity for everybody 240 00:15:36,960 --> 00:15:40,560 else to to do this, right. And so example I like to use is 241 00:15:40,720 --> 00:15:43,720 imagine Netflix. You go to Netflix and first of 242 00:15:43,720 --> 00:15:48,400 all, like in the CDO ecosystem, it would ask you to choose which 243 00:15:48,400 --> 00:15:50,640 data center you want to watch from, right? 244 00:15:50,960 --> 00:15:53,640 Do you want their arbitrary data center or optimism data center, 245 00:15:54,600 --> 00:15:58,360 a base or you know, blast. And then when you go there, it 246 00:15:58,360 --> 00:16:00,440 says like actually, first of all, you need to bring your 247 00:16:00,440 --> 00:16:04,280 money from the other data center where you have your money if you 248 00:16:04,280 --> 00:16:07,440 want to pay for this movie, pay for watching the movie here. 249 00:16:07,640 --> 00:16:10,720 And then second one is actually you know because somebody else 250 00:16:10,720 --> 00:16:14,040 watches a very popular movie, you cannot watch this movie 251 00:16:14,280 --> 00:16:16,160 right now at the lower price, you need to pay more. 252 00:16:16,880 --> 00:16:20,240 So that's kind of the current stage right is and what we want 253 00:16:20,240 --> 00:16:23,680 to do is you know you go you can pick any movie and you watch it 254 00:16:23,680 --> 00:16:25,800 and you pay kind of fixed fee, right. 255 00:16:25,800 --> 00:16:27,320 That's like it's predictable for everyone. 256 00:16:28,520 --> 00:16:31,920 And so to do that right. Similarly how NASA need to use 257 00:16:31,920 --> 00:16:34,880 Amazon that kind of scales under the hood right and is able to 258 00:16:34,880 --> 00:16:39,880 build more data centers that had of the demand that cats lakes 259 00:16:39,880 --> 00:16:43,480 has kind of similarly you need a network that is able to scale 260 00:16:43,480 --> 00:16:47,720 with demand and kind of you know in a way you know you have the 261 00:16:47,720 --> 00:16:51,720 supply demand curves and so like you want to flatter the supply 262 00:16:51,720 --> 00:16:55,600 curve such that even as demand grows you kind of can maintain 263 00:16:55,600 --> 00:17:00,080 the their fixed. Fees, right. 264 00:17:00,080 --> 00:17:04,079 So this is the distinction between burst capacity and like. 265 00:17:04,079 --> 00:17:08,960 Average capacity in a sense where like a a system might only 266 00:17:08,960 --> 00:17:14,280 be using like X capacity is sometimes in a year, but then 267 00:17:14,400 --> 00:17:18,560 suddenly like one application or the old system might require 5X 268 00:17:18,560 --> 00:17:22,359 or 10X and that burst might happen very quickly. 269 00:17:23,359 --> 00:17:27,079 And what you're saying is essentially that if the if the 270 00:17:27,079 --> 00:17:31,040 scalability properties of a system are only dependent on the 271 00:17:32,040 --> 00:17:37,560 underlying machines that the validators use, then that cannot 272 00:17:37,560 --> 00:17:41,680 change very quickly to adjust to burst demand. 273 00:17:41,680 --> 00:17:44,640 Like certainly lots of demand comes in, machines can't be 274 00:17:44,640 --> 00:17:48,080 changed across the whole network that fast. 275 00:17:48,920 --> 00:17:53,240 So there needs to be like some other mechanism where a burst 276 00:17:53,240 --> 00:17:57,880 happens and the system is also able to somehow respond and 277 00:17:57,880 --> 00:18:03,520 being and be able to scale dynamically on a on a shorter, 278 00:18:03,600 --> 00:18:07,040 shorter time horizon. And this is this is a property 279 00:18:07,040 --> 00:18:09,960 nearly every blockchain kind of like lacks today, which is why 280 00:18:09,960 --> 00:18:13,720 you have gas congestion. Yeah. 281 00:18:13,720 --> 00:18:17,160 And so specifically in last months, we went from 4 shards to 282 00:18:17,160 --> 00:18:20,920 six shards, increasing our capacity by 50% because we had a 283 00:18:20,920 --> 00:18:23,400 couple of applications who had like massive growths. 284 00:18:23,400 --> 00:18:27,040 We have heart which grew from zero to 5 million users. 285 00:18:27,200 --> 00:18:31,880 It's like over a month, million daily actives within a month. 286 00:18:32,400 --> 00:18:35,880 And so we started to having this actually congestion to South of 287 00:18:35,880 --> 00:18:39,120 shards because of that. And so instead of just OK, 288 00:18:39,120 --> 00:18:42,440 everybody's now paying higher fees, your network added more 289 00:18:42,440 --> 00:18:47,840 capacity. So yeah, let's get into what you 290 00:18:47,840 --> 00:18:48,920 know what. What are the different 291 00:18:48,920 --> 00:18:52,360 challenges with with building building a sharded Shard 292 00:18:52,360 --> 00:18:56,360 blockchain? So there's a couple of them. 293 00:18:56,840 --> 00:19:02,440 First of all, there are certain changes to the user experience 294 00:19:02,560 --> 00:19:06,920 because since nobody maintains the state of all the accounts, 295 00:19:07,160 --> 00:19:10,880 if the transaction has to touch multiple accounts, something 296 00:19:10,880 --> 00:19:12,520 needs to be done about it, right? 297 00:19:12,520 --> 00:19:18,320 And it's a, it's a, it's a very large design space and generally 298 00:19:18,760 --> 00:19:21,640 we refer to those transactions across short transactions and 299 00:19:23,320 --> 00:19:29,120 that's that's one big challenge. The second challenge is in the 300 00:19:29,120 --> 00:19:31,960 network, in which every node processes every transaction. 301 00:19:32,440 --> 00:19:37,480 If you're if you have a node and you're at a particular state, 302 00:19:37,800 --> 00:19:41,560 you have very high certainty that every transaction was 303 00:19:41,560 --> 00:19:44,800 processed properly, because you literally processed each and 304 00:19:44,800 --> 00:19:47,560 every one of them, right? In the worst case, you can be in 305 00:19:47,560 --> 00:19:50,240 a situation where you're looking at a network which is not 306 00:19:50,240 --> 00:19:53,240 canonical, right? So maybe some other part of the 307 00:19:53,240 --> 00:19:56,560 network believes that another set of transactions happen on 308 00:19:56,560 --> 00:19:59,080 this one, right? But that's a very different 309 00:19:59,080 --> 00:20:02,720 problem from someone literally, you know, like making something 310 00:20:02,720 --> 00:20:04,640 that doesn't make any sense according to the rules of the 311 00:20:04,640 --> 00:20:07,520 chain. And so in the target chain, 312 00:20:07,880 --> 00:20:11,120 because every node only applies a subset of transactions, you 313 00:20:11,120 --> 00:20:16,680 need some checks and balances which ensure that that what you 314 00:20:16,680 --> 00:20:20,880 see is actually a correct state that results from the properly 315 00:20:20,880 --> 00:20:24,240 executed transactions. And when you start digging deep 316 00:20:24,240 --> 00:20:26,680 into that problem, into the problem of ensuring that 317 00:20:26,680 --> 00:20:30,480 everything is executed correctly, then you you start 318 00:20:30,480 --> 00:20:35,640 facing another problem where in order for like for almost any 319 00:20:35,800 --> 00:20:39,320 mechanic you can come up with that ensures that everything is 320 00:20:39,320 --> 00:20:41,800 executed correctly. Maybe with an exception of ZK 321 00:20:41,800 --> 00:20:44,760 proofs like. Once we start digging, today we. 322 00:20:44,760 --> 00:20:48,760 Will we will see it? You need to be able to access 323 00:20:48,960 --> 00:20:52,520 certain information in order to perform the validation, and that 324 00:20:52,520 --> 00:20:57,560 information could be made unavailable by malicious actors. 325 00:20:57,600 --> 00:21:02,760 And so you need to have a sort of native you need to have a 326 00:21:02,760 --> 00:21:05,720 native mechanic on the blockchain which ensures that 327 00:21:05,720 --> 00:21:08,800 certain pieces of data are available to certain 328 00:21:08,800 --> 00:21:11,840 participants and cannot be concealed right. 329 00:21:11,840 --> 00:21:14,840 And so those two challenges are like one of the biggest 330 00:21:14,840 --> 00:21:18,200 challenges that exist. There are there are some others. 331 00:21:18,200 --> 00:21:20,120 One interesting one would be that because the state is so 332 00:21:20,120 --> 00:21:23,840 big, you need to have a way for people to either synchronize 333 00:21:23,840 --> 00:21:27,720 state very quickly or work without synchronizing state. 334 00:21:28,640 --> 00:21:31,040 So I I think those four would be the most interesting ones. 335 00:21:32,840 --> 00:21:35,320 Right. So like, yeah, essentially, like 336 00:21:35,320 --> 00:21:38,360 imagine yourself like being an accountant of the near 337 00:21:38,360 --> 00:21:42,880 blockchain. It's it's a massive data 338 00:21:42,880 --> 00:21:45,720 structure. You only have a small part of 339 00:21:45,720 --> 00:21:51,640 it, the transaction comes. So the first problem is OK, you 340 00:21:51,640 --> 00:21:56,160 might not be able to process the transaction fully yourself 341 00:21:56,160 --> 00:22:00,320 because you only have a part of that entire data structure. 342 00:22:00,320 --> 00:22:03,520 So you can maybe make some changes to that part, but then 343 00:22:03,520 --> 00:22:07,480 the transaction might hit OK. Now it needs to do a change on 344 00:22:07,480 --> 00:22:11,960 some other part that you don't have and that's a completely 345 00:22:11,960 --> 00:22:15,800 different accountant. So you need to process you know 346 00:22:15,800 --> 00:22:19,560 some only a part of the transaction and then it needs to 347 00:22:19,560 --> 00:22:24,560 be like that that rename beta needs to be kind of handed over 348 00:22:24,560 --> 00:22:28,640 to some other party and then they do that and and so on. 349 00:22:28,640 --> 00:22:30,520 So like that's that's one, that's one issue. 350 00:22:31,560 --> 00:22:37,440 Second issue is if you're only handling a part of that data 351 00:22:37,440 --> 00:22:42,320 structure which has contains all the account balances, you 352 00:22:42,320 --> 00:22:48,040 receive that data from some place and then how do you even 353 00:22:48,040 --> 00:22:51,800 know that that data is genuine, right? 354 00:22:52,160 --> 00:22:57,440 So that's that's the problem of stateless validation or like how 355 00:22:57,440 --> 00:23:01,520 do I know that this data I'm receiving it's actually 356 00:23:01,520 --> 00:23:05,400 processed correctly in the past? Then? 357 00:23:05,400 --> 00:23:10,360 Kind of like, OK, if there's any mechanic to know that any kind 358 00:23:10,360 --> 00:23:14,840 of certificate that would tell me that this was processed 359 00:23:14,840 --> 00:23:19,000 correctly in the past, then the generators of that certificate 360 00:23:19,000 --> 00:23:24,280 kind of need to have had access to that data in the 1st place. 361 00:23:24,960 --> 00:23:30,080 But if that data wasn't there to the generators of like these 362 00:23:30,080 --> 00:23:35,200 certificates, then then they won't be able to generate 363 00:23:35,200 --> 00:23:37,640 certificates. A certain data needs to be kept 364 00:23:38,280 --> 00:23:43,800 in a state where you can reach it in order to do something with 365 00:23:43,800 --> 00:23:45,800 it. Yeah, so, so a couple of 366 00:23:45,800 --> 00:23:47,600 comments. So the first one would you, you 367 00:23:47,600 --> 00:23:50,080 mentioned that you need to process part of it and then send 368 00:23:50,080 --> 00:23:53,520 it to someone else. So it's also important that that 369 00:23:53,520 --> 00:23:58,040 message you're sending is not getting lost, right, but it has 370 00:23:58,040 --> 00:24:00,320 to be delivered with certificates. 371 00:24:00,320 --> 00:24:03,000 You mentioned that you need to be to have certain data to 372 00:24:03,000 --> 00:24:06,040 create certificate. It's also in many situations the 373 00:24:06,040 --> 00:24:08,480 case that you need certain data to be able to verify the 374 00:24:08,480 --> 00:24:12,640 certificate. Actually, like in Near in in one 375 00:24:12,640 --> 00:24:15,560 sense like there's a lot of complexity because fundamentally 376 00:24:15,560 --> 00:24:19,320 like kind of like the accountants in your system do 377 00:24:19,320 --> 00:24:24,200 not have, may not have access to the full data and so that leads 378 00:24:24,200 --> 00:24:28,880 to a lot of complexity. But in a different sense, Near 379 00:24:28,880 --> 00:24:34,680 is Near is similar to other block chains in IT that it's 380 00:24:34,680 --> 00:24:40,440 just one data structure containing accounts and like 381 00:24:40,440 --> 00:24:45,080 smart contracts and their data. And this is exactly the same as 382 00:24:45,080 --> 00:24:49,200 kind of like Bitcoin and Ethereum where it's you're 383 00:24:49,200 --> 00:24:51,680 dealing in the end with a single data structure. 384 00:24:51,880 --> 00:24:54,520 NIR is managing the data structure in a different way. 385 00:24:54,920 --> 00:24:57,600 But ultimately it's it's a single data structure like 386 00:24:57,600 --> 00:25:01,800 that's that's a unifying property across all of these 387 00:25:01,800 --> 00:25:03,320 systems. That's right. 388 00:25:03,800 --> 00:25:05,680 Yeah. So yeah, you can think of NIR as 389 00:25:05,680 --> 00:25:09,840 like a very large mapping from account IDs to state. 390 00:25:10,600 --> 00:25:13,040 A big difference from other block chains is that the account 391 00:25:13,040 --> 00:25:16,880 ID is not your key account ID. You think of it as like a domain 392 00:25:16,880 --> 00:25:18,280 name, right? So let you know. 393 00:25:18,760 --> 00:25:23,840 I would be Alex dot near. And it's not just a convenience, 394 00:25:23,840 --> 00:25:26,120 it's not just something that is easier to convey to other 395 00:25:26,120 --> 00:25:29,720 people. It's also like if you if you 396 00:25:29,720 --> 00:25:33,400 think about it, if if the key is what identifies your account, 397 00:25:33,800 --> 00:25:36,280 then if for any reason you have reason to believe that the key 398 00:25:36,280 --> 00:25:39,200 is compromised, your account is gone, right? 399 00:25:39,200 --> 00:25:41,000 You have to create a new one. You have to try to move the 400 00:25:41,000 --> 00:25:43,240 assets. Not all the assets are movable, 401 00:25:43,240 --> 00:25:45,040 right? Like you can imagine an NFT 402 00:25:45,360 --> 00:25:47,520 which is not movable by design, an NFT. 403 00:25:47,560 --> 00:25:51,720 You know like the first user of this feature, it's not a movable 404 00:25:51,720 --> 00:25:54,520 NFT. That NFT is gone forever, right? 405 00:25:54,520 --> 00:25:57,480 So near. If if I have a reason to believe 406 00:25:57,480 --> 00:26:01,120 that my key is compromised, I just change it, right? 407 00:26:01,120 --> 00:26:04,920 It also allows you to to do to like auction your account. 408 00:26:05,360 --> 00:26:07,520 Like like your account has a particular state that you think 409 00:26:07,520 --> 00:26:10,280 is of value, you can literally sell your account. 410 00:26:10,280 --> 00:26:13,240 There are services in there that allow you doing that right? 411 00:26:13,240 --> 00:26:16,040 And then this massive state of mapping. 412 00:26:16,400 --> 00:26:18,720 At the end of the day, it's still a mapping from an account 413 00:26:18,720 --> 00:26:22,840 to to state, similar to Bitcoin, Etherium, Stalana, any other 414 00:26:22,840 --> 00:26:25,280 blockchain, but that state is short. 415 00:26:25,280 --> 00:26:28,320 Just just to be clear, not Bitcoin because you J exos but 416 00:26:28,320 --> 00:26:31,640 yes Etherium so like that every account based blockchain. 417 00:26:32,640 --> 00:26:36,120 But yeah, you know, like you DXL, you can think of it is as 418 00:26:36,120 --> 00:26:39,960 even less persistent account than than just a key. 419 00:26:40,760 --> 00:26:44,520 And so this state of all the accounts, it's split into 420 00:26:44,520 --> 00:26:46,920 multiple subsets, right, into multiple sets. 421 00:26:46,920 --> 00:26:50,960 So today we split by by name, right. 422 00:26:50,960 --> 00:26:54,400 So there would be a contiguous set of accounts that lives on 423 00:26:54,400 --> 00:26:57,080 Shard one, and there is a contiguous set of accounts that 424 00:26:57,080 --> 00:26:59,480 lives on Shard 2. And. 425 00:27:00,000 --> 00:27:05,360 That those boundaries are not they not immutable through the 426 00:27:05,480 --> 00:27:06,800 through the life of the blockchain. 427 00:27:06,920 --> 00:27:08,840 And as a matter of fact they did change multiple times. 428 00:27:08,840 --> 00:27:10,560 When NEO launched, it was a single set. 429 00:27:11,120 --> 00:27:13,360 NEO launched with a single Shard, right? 430 00:27:13,360 --> 00:27:16,440 And then it was split into four and then in the recent months it 431 00:27:16,440 --> 00:27:20,080 was split two of them were split twice into two again. 432 00:27:20,640 --> 00:27:23,560 So it's and in the future that will be dynamic. 433 00:27:23,640 --> 00:27:27,360 In the future of the system will be changing the the boundaries 434 00:27:27,680 --> 00:27:32,200 as the you know like as the load changes automatically. 435 00:27:33,560 --> 00:27:38,760 So I mean, maybe one way to imagine it is like in your like 436 00:27:38,960 --> 00:27:43,840 in the postal system in your city most likely like your city 437 00:27:43,840 --> 00:27:47,640 is kind of like divided into these different regions, each 438 00:27:47,640 --> 00:27:49,840 with a different postal code, right? 439 00:27:50,480 --> 00:27:54,200 Where I live there called yeah PLZ or something like that. 440 00:27:54,200 --> 00:27:59,440 And so each kind of like region of the city will have will have 441 00:27:59,440 --> 00:28:02,280 a number and the city will be partitioned into various 442 00:28:02,280 --> 00:28:05,480 different postal codes and you'll have like a post office 443 00:28:05,480 --> 00:28:12,120 in every every code essentially. And Can you imagine like in near 444 00:28:12,120 --> 00:28:15,560 it's it's taking that data structure, you can think of that 445 00:28:15,560 --> 00:28:19,720 as the city and then breaking it down into like these these 446 00:28:19,720 --> 00:28:25,200 areas, these shards. And the dynamism is like if you 447 00:28:25,200 --> 00:28:28,520 have like a region in the city that has a postal code and 448 00:28:29,040 --> 00:28:31,560 suddenly lots of letters are being sent there and they're 449 00:28:31,560 --> 00:28:35,920 like, oh, now actually we need 2 post offices, then maybe they 450 00:28:35,920 --> 00:28:40,440 will divide the region in the city into into two different 451 00:28:40,440 --> 00:28:42,680 regions with two different post office with two different 452 00:28:42,680 --> 00:28:44,840 numbers. And in practice that does happen 453 00:28:44,840 --> 00:28:47,480 right? Like postal codes change over 454 00:28:47,600 --> 00:28:53,040 over long horizons and in near similarly like OK, the whole 455 00:28:53,040 --> 00:28:56,640 blockchain is broken down into like the shards. 456 00:28:56,960 --> 00:29:04,920 The definition of a Shard can also change in order to kind of 457 00:29:05,720 --> 00:29:09,680 route around the capacity demanding in in some way. 458 00:29:10,360 --> 00:29:13,560 If you think of near today, you can think of it as there is a 459 00:29:15,400 --> 00:29:19,640 you know, we all observe what happens in the city and how much 460 00:29:19,640 --> 00:29:21,880 mail goes to every post office, right? 461 00:29:21,880 --> 00:29:24,040 And at some point we realize that for a particular post 462 00:29:24,040 --> 00:29:27,320 office, there's a lot of mail coming in and it's, you know, 463 00:29:27,320 --> 00:29:29,560 it's getting harder for the employees there to handle it, 464 00:29:30,000 --> 00:29:31,240 right. And so there could be a proposal 465 00:29:31,240 --> 00:29:34,320 that says, hey guys, let's build another post office half a mile 466 00:29:34,320 --> 00:29:37,240 away and split it like this, right. 467 00:29:37,240 --> 00:29:39,040 And then there there's a separate entity which is 468 00:29:39,040 --> 00:29:43,400 validators of the network which which either choose to, you 469 00:29:43,400 --> 00:29:46,280 know, to go ahead with this change or not. 470 00:29:47,000 --> 00:29:49,200 And it's sufficient percentage of them, which I think is 80, 471 00:29:50,920 --> 00:29:54,280 you know, wants to go with this change, then it's then it 472 00:29:54,280 --> 00:29:57,000 happens, right. And you know, if you think of 473 00:29:57,000 --> 00:30:00,000 near of the future when the name of your sharding is there, it's 474 00:30:00,000 --> 00:30:02,200 slightly different. It's, you know, as mail starts 475 00:30:02,200 --> 00:30:04,120 coming into the building, another building just 476 00:30:04,240 --> 00:30:08,280 spontaneously pops in without without any human being 477 00:30:08,280 --> 00:30:09,800 involved, right. It's entirely. 478 00:30:09,800 --> 00:30:11,960 More like that building splits into two and. 479 00:30:11,960 --> 00:30:14,000 Moves away. Exactly, exactly OK And your 480 00:30:14,000 --> 00:30:16,960 wall appears, yes, to building separate or like on a on a set 481 00:30:16,960 --> 00:30:19,800 of rails. And that happens without any 482 00:30:19,800 --> 00:30:24,640 involvement from any natural intelligence, right. 483 00:30:25,040 --> 00:30:27,760 It just it it just occurs and then it's at some point, you 484 00:30:27,760 --> 00:30:30,560 know two post notices become, you know it's it's getting chill 485 00:30:30,560 --> 00:30:33,400 there. So they can, you know come 486 00:30:33,400 --> 00:30:35,160 together and it all disappears. Yes. 487 00:30:35,760 --> 00:30:39,120 Yes, exactly. But, but I think the important 488 00:30:39,120 --> 00:30:41,880 parts here right? As you said, zip codes changes, 489 00:30:41,880 --> 00:30:44,760 which means like when you're sending your mail, you need to 490 00:30:44,760 --> 00:30:47,360 like. Now whoever is in the new zone 491 00:30:47,360 --> 00:30:51,000 needs to update everyone. They're like in a new zip code, 492 00:30:51,680 --> 00:30:53,440 but. So on here, you never see the 493 00:30:53,440 --> 00:30:56,480 zip code on here you say I want a mail to be sent to Ilya, 494 00:30:56,960 --> 00:30:58,640 right? And Nir figures out the zip code 495 00:30:58,640 --> 00:30:59,840 itself. You don't need to know it. 496 00:31:00,800 --> 00:31:03,400 That's the beauty. Yeah. 497 00:31:03,400 --> 00:31:06,600 And and to compare with this with other approaches like 498 00:31:06,600 --> 00:31:09,880 subnets, roll ups, etcetera, I mean in a way they're trying to 499 00:31:09,880 --> 00:31:11,560 emulate the same behavior, right? 500 00:31:11,560 --> 00:31:16,320 It's like oh you know this this roll up is too busy. 501 00:31:16,600 --> 00:31:19,240 Instead of launching there, you know you can spin up a new roll 502 00:31:19,240 --> 00:31:23,000 up and now everybody can go there and you have more 503 00:31:23,040 --> 00:31:25,800 capacity. But it's a very, you know, not 504 00:31:25,800 --> 00:31:27,560 just manual and expensive process, right. 505 00:31:27,560 --> 00:31:31,600 I mean it's like each roll up you know cost is at least 506 00:31:31,600 --> 00:31:35,120 $1,000,000 a year just to run between sequencer explorers, 507 00:31:35,120 --> 00:31:36,920 RPCS etcetera, all the infrastructure. 508 00:31:37,280 --> 00:31:40,600 But it's also now every user, every developer, every sort of 509 00:31:40,600 --> 00:31:42,600 contract of us actually trying to use it. 510 00:31:43,000 --> 00:31:46,080 Now it is to figure out how to go there, how to bridge there, 511 00:31:46,080 --> 00:31:49,080 how what gas tokens is used there etcetera, right. 512 00:31:49,080 --> 00:31:53,120 So it's it's a huge load on the whole kind of understanding of 513 00:31:53,120 --> 00:31:57,240 the network process which we are actually addressing with kind of 514 00:31:57,240 --> 00:32:00,680 chain abstraction and chain signatures as well because we do 515 00:32:00,680 --> 00:32:04,000 believe this is kind of a unit like what we're trying to do 516 00:32:04,000 --> 00:32:06,680 with Near is a universal problem, right. 517 00:32:06,680 --> 00:32:09,480 It's like the capabilities of the network should be able to 518 00:32:09,480 --> 00:32:12,480 change dynamically and everybody should be able to route things 519 00:32:13,480 --> 00:32:16,520 without thinking about the underlying infrastructure. 520 00:32:16,920 --> 00:32:21,840 But on near we kind of solved it in a very like direct way by 521 00:32:21,840 --> 00:32:26,360 having this kind of namespace that is common for everyone and 522 00:32:26,520 --> 00:32:31,080 using that to route like our transactions and messages mail 523 00:32:31,840 --> 00:32:33,960 between between different participants. 524 00:32:35,560 --> 00:32:38,560 Yeah, that is so cool. I actually I actually own meher 525 00:32:38,560 --> 00:32:44,920 dot near and and yeah I've never needed to think about what chart 526 00:32:45,000 --> 00:32:49,480 it is on right? So to me I I only need meh dot 527 00:32:49,480 --> 00:32:56,160 near and it's journey through time maybe like it was processed 528 00:32:56,160 --> 00:33:03,480 in Shard #1 then Shard #3 and then it's changing and I never 529 00:33:03,480 --> 00:33:06,600 need to know about it right. Like that's that's that's like 530 00:33:06,600 --> 00:33:08,360 really. Yeah, I think it, it wasn't 531 00:33:08,360 --> 00:33:12,040 Shard. Yeah, Shard 0, then Shard 2 and 532 00:33:12,040 --> 00:33:16,360 then Shard 3. Now it's on probably short 3 533 00:33:16,360 --> 00:33:19,440 right now, but yeah, you don't, you definitely don't need to 534 00:33:19,440 --> 00:33:22,040 know about that. And like even I am like you 535 00:33:22,040 --> 00:33:23,800 know, there is a way to look it up. 536 00:33:23,800 --> 00:33:28,440 But we actually don't show it in Explorer usually because I mean 537 00:33:28,440 --> 00:33:31,560 some new explorers show sometimes, but because we don't 538 00:33:31,560 --> 00:33:34,240 actually want people to know because it's it's irrelevant 539 00:33:34,240 --> 00:33:36,480 information. It's like knowing which which 540 00:33:36,480 --> 00:33:41,760 exact computer in on which rack in AWS is, you know, providing 541 00:33:41,760 --> 00:33:43,560 us with this interface we're looking at right now. 542 00:33:44,920 --> 00:33:47,760 Yeah, yeah. So maybe like an interesting 543 00:33:47,760 --> 00:33:51,600 imagination for Near is because, like, ultimately it's like this 544 00:33:51,720 --> 00:33:54,920 human memorable names at the bottom. 545 00:33:56,000 --> 00:33:59,000 And maybe, you know, like each human memorable name actually 546 00:33:59,000 --> 00:34:02,720 corresponds to a person or a company because that's how the 547 00:34:02,720 --> 00:34:05,360 world is partitioned. And because like the Near system 548 00:34:05,360 --> 00:34:08,440 breaks into shards, you can almost imagine like a virtual 549 00:34:08,440 --> 00:34:12,880 connection of people that are transacting their business on a 550 00:34:12,880 --> 00:34:19,000 Shard at a certain point and these are the users of of the 551 00:34:19,000 --> 00:34:22,040 Shard itself. And of course like as the Shard 552 00:34:22,040 --> 00:34:25,280 boundaries change, the collection of people transacting 553 00:34:25,280 --> 00:34:29,120 on a Shard is also changing. But maybe if you imagine it as 554 00:34:29,120 --> 00:34:32,719 like being you know stationary or constant for a certain while 555 00:34:32,719 --> 00:34:35,639 which is true for near. We can we can think of this like 556 00:34:35,639 --> 00:34:39,520 virtual collection of people in the in the near suburb on a 557 00:34:39,520 --> 00:34:42,320 sense that's transacting on a Shard. 558 00:34:42,880 --> 00:34:46,159 And then the on the other side corresponding to a Shard you 559 00:34:46,159 --> 00:34:51,840 need kind of servers or validators or postman in our 560 00:34:51,840 --> 00:34:55,840 early analogy that are kind of processing the mail that's 561 00:34:55,840 --> 00:34:59,440 coming to that particular area or Shard. 562 00:35:00,120 --> 00:35:03,440 I guess like one of the question starts to become so in any 563 00:35:03,440 --> 00:35:08,040 blockchain network you have these validator machines or 564 00:35:08,840 --> 00:35:11,440 minor machines that are ultimately like kind of like 565 00:35:11,440 --> 00:35:14,720 this postman or accountants of the system that are doing the 566 00:35:14,720 --> 00:35:18,040 processing. And even in near I would imagine 567 00:35:18,040 --> 00:35:21,200 OK there's a set of validators that are that are found through 568 00:35:21,200 --> 00:35:23,880 proof of stake. Now these validators sort of 569 00:35:23,880 --> 00:35:28,360 like need to be assigned to shards that hey you go and 570 00:35:29,080 --> 00:35:34,280 process the transactions in in this in this Shard you other one 571 00:35:34,280 --> 00:35:36,920 you do it there and how does that process work? 572 00:35:38,200 --> 00:35:41,280 So I I first want to to correct slightly the first time I I 573 00:35:41,280 --> 00:35:43,600 think the 2nd analogy was good, but the first analogy was not 574 00:35:43,600 --> 00:35:49,400 quite correct because even though Shard boundaries do not 575 00:35:49,400 --> 00:35:54,680 change as frequently today as they will be at some point, it 576 00:35:54,680 --> 00:35:58,640 it it has been the case from day one or near that two accounts 577 00:35:58,640 --> 00:36:02,240 residing on the same chart has absolutely no significance for 578 00:36:02,240 --> 00:36:04,680 those two accounts. So I think a better analogy for 579 00:36:04,680 --> 00:36:07,520 that would be not the post office but like cell towers, 580 00:36:07,880 --> 00:36:09,240 right. We could be next to each other 581 00:36:09,240 --> 00:36:14,080 and I can call you and we will be you know, served by the same 582 00:36:14,080 --> 00:36:16,760 cell tower or we could be into in different parts of the world 583 00:36:16,760 --> 00:36:19,320 and I can call you and other different cell towers but we 584 00:36:19,320 --> 00:36:21,440 have no benefit. You know, like I, I will never 585 00:36:21,440 --> 00:36:24,160 know that you're on the same cell tower and I will never 586 00:36:24,160 --> 00:36:26,560 care. And it is the case of Mir that 587 00:36:27,080 --> 00:36:30,280 if you and I are on the same chart and they send you money or 588 00:36:30,400 --> 00:36:34,040 you know, like we transact on some smart contract or we'll if 589 00:36:34,040 --> 00:36:36,880 we are in different charts, from the user's perspective, there's 590 00:36:36,880 --> 00:36:39,360 no difference in, in experience, right. 591 00:36:39,360 --> 00:36:42,040 So you know, fees are not affected, the performance is not 592 00:36:42,040 --> 00:36:44,320 affected. You know like like you know, 593 00:36:44,320 --> 00:36:46,560 sharding is completely obstructed to it, right. 594 00:36:46,560 --> 00:36:49,840 And so there's no incentive, for example, to try to be on the 595 00:36:49,840 --> 00:36:51,480 same chart. There's no incentive to grant, 596 00:36:51,480 --> 00:36:54,120 for example, account IDs or the contention was at the same, you 597 00:36:54,120 --> 00:36:56,200 know, accounting in the same. Chart. 598 00:36:57,240 --> 00:37:00,680 When it comes to the second analogy, you can think about 599 00:37:00,680 --> 00:37:03,960 this way. You can think, I I like, I like 600 00:37:03,960 --> 00:37:07,480 going in multiple steps and effectively saying, you know, 601 00:37:07,480 --> 00:37:10,600 let's say we're designing a new blockchain and we want it to be 602 00:37:10,600 --> 00:37:14,600 sharded right on. How do we ensure security when 603 00:37:15,000 --> 00:37:17,040 not everybody processes every transaction? 604 00:37:17,040 --> 00:37:20,120 And the first idea would be, let's say we have a massive set 605 00:37:20,120 --> 00:37:23,520 of validators, right? So we set the, you know, the 606 00:37:23,520 --> 00:37:27,840 minimum key to be relatively low and we say we have hundreds of 607 00:37:27,840 --> 00:37:29,960 thousands of validators or even millions, I don't know. 608 00:37:30,800 --> 00:37:33,880 And then every Shard, even though it has only a subset of 609 00:37:33,880 --> 00:37:36,640 valid daters, it still has a massive set of validators, 610 00:37:37,080 --> 00:37:37,800 right? So it's. 611 00:37:38,720 --> 00:37:41,680 So we have a million total, 100 charts, and every chart has 612 00:37:41,680 --> 00:37:47,680 10,000 validators. Then you can say, well, if if 613 00:37:47,680 --> 00:37:51,640 you sample them randomly and we relatively certain that the 614 00:37:51,960 --> 00:37:55,160 total set of validators has up to a certain percentage of bad 615 00:37:55,160 --> 00:37:59,440 games, right, we say we believe that the total set has up to 25% 616 00:37:59,440 --> 00:38:02,800 bad games and not more, right? Then you can do the math and you 617 00:38:02,800 --> 00:38:07,000 say, well, if I sample 10,000 of them, then the percentage of the 618 00:38:07,000 --> 00:38:12,320 bad guys exceeding 33% is so unlikely that we can consider it 619 00:38:12,320 --> 00:38:16,040 to be impossible either to be like, you know, 1 / 10 to the 620 00:38:16,040 --> 00:38:19,120 power of some large number. And then you say, well, and 621 00:38:19,120 --> 00:38:22,760 because there's no more than 33% of bad guys in the chart, we can 622 00:38:22,760 --> 00:38:26,640 just assume that they adhere to the protocol that any state 623 00:38:26,640 --> 00:38:29,480 transition they approve of, Like if it has, you know, as a 624 00:38:29,480 --> 00:38:32,920 particular percentage of signatures of those people who 625 00:38:32,960 --> 00:38:35,840 are validating the chart, then we believe that that's the 626 00:38:35,840 --> 00:38:38,840 transition was valid because the number of bad guys is limited 627 00:38:38,840 --> 00:38:42,600 and the good guys signed off. So it's, you know, good to go. 628 00:38:43,200 --> 00:38:45,280 It has practical issues. We don't actually have a million 629 00:38:45,280 --> 00:38:49,760 of validators and we do want to have more than 100 charts in in 630 00:38:49,760 --> 00:38:52,120 the limit. But it has a bigger problem 631 00:38:52,120 --> 00:38:56,400 which is the contract of a big guy or a good guy is very 632 00:38:56,400 --> 00:38:59,280 abstract. At the end of the day, everybody 633 00:38:59,280 --> 00:39:02,400 who's on the blockchain, you know, they want to make money. 634 00:39:02,800 --> 00:39:04,360 That's the that's the ultimate goal. 635 00:39:04,360 --> 00:39:06,520 You know majority of validators, I'm sure there are some 636 00:39:06,520 --> 00:39:10,000 validators who are there to build the, you know the 637 00:39:10,040 --> 00:39:13,200 decentralized world of the future where everybody's a happy 638 00:39:13,200 --> 00:39:16,800 corgi owning their data but invalid. 639 00:39:16,800 --> 00:39:19,880 The majority of them are there because you stake money. 640 00:39:20,160 --> 00:39:23,040 So or rather like you have people delegate to you, you you 641 00:39:23,040 --> 00:39:25,120 keep the percentage, you make money, right? 642 00:39:25,120 --> 00:39:31,200 And so correspondingly we should think about the security in the 643 00:39:31,200 --> 00:39:33,480 presence of the bad guys who will try to corrupt other 644 00:39:33,480 --> 00:39:35,720 participants, right? And people talk. 645 00:39:35,720 --> 00:39:38,880 There are ways for people to talk, you know a lot of 646 00:39:39,040 --> 00:39:41,280 validators are just sitting on telegram, right? 647 00:39:41,280 --> 00:39:43,400 And it makes sense for them to be in the same telegram groups 648 00:39:43,400 --> 00:39:45,040 because they they run into issues. 649 00:39:45,400 --> 00:39:46,840 You know, like the network is too slow. 650 00:39:47,120 --> 00:39:49,560 The validator, they need to know that they need to operate the 651 00:39:49,560 --> 00:39:51,800 validator so they all in the same telegram channels. 652 00:39:51,800 --> 00:39:54,960 They all easily reachable if the bad guy wants to come and say, 653 00:39:55,360 --> 00:40:01,280 hey guys, I want to do this act of being a bad guy and I need 654 00:40:01,280 --> 00:40:03,440 that percentage of validators to cooperate, right? 655 00:40:03,440 --> 00:40:06,400 I can DM each of you and say this is how much money I'm 656 00:40:06,400 --> 00:40:08,880 willing to pay you because there's something for me to gain 657 00:40:09,200 --> 00:40:11,200 from the blockchain game going down. 658 00:40:11,480 --> 00:40:13,400 It could be some minor extractable value. 659 00:40:13,600 --> 00:40:19,360 It could be that I'm, you know I'm the Solana investor and I 660 00:40:19,360 --> 00:40:23,640 just want you to go down and Solana to go up etcetera right 661 00:40:23,640 --> 00:40:25,920 and so. The system needs to be designed 662 00:40:25,920 --> 00:40:28,920 in such a way that a very large percentage of the validators 663 00:40:28,920 --> 00:40:32,840 could be corrupted and, you know, incentivize to do 664 00:40:32,840 --> 00:40:36,320 something bad. And we need to correspondingly, 665 00:40:36,320 --> 00:40:40,600 let's say we have 100 or 1000 of validators and we have on the 666 00:40:40,600 --> 00:40:43,640 small sets subset of them in every Shard, We should expect 667 00:40:43,640 --> 00:40:45,600 that almost all of them will get corrupted, right? 668 00:40:45,600 --> 00:40:48,240 Or even all of them. And so the system needs to be 669 00:40:48,240 --> 00:40:50,120 designed in the way that, yeah, there are those, you know, 670 00:40:50,160 --> 00:40:54,040 postman in the post offices, but it could be that the bad guy 671 00:40:54,080 --> 00:40:56,320 enters the post post office, gives all of them, you know, 672 00:40:56,320 --> 00:40:59,600 $1000 and asks them to do something bad, you know, like a 673 00:40:59,600 --> 00:41:03,640 route and a mail which was not actually sent by the originator 674 00:41:03,640 --> 00:41:06,280 or something like this. And so we designed systems in a 675 00:41:06,280 --> 00:41:11,720 way that that is prevented or made very, very difficult to 676 00:41:11,720 --> 00:41:16,680 execute, if that makes sense. So not only mathematics of it. 677 00:41:16,680 --> 00:41:19,880 But if you if you take that that scenario that you sketched out, 678 00:41:19,880 --> 00:41:23,440 first there's a million validators and then I'm 679 00:41:23,440 --> 00:41:26,200 sampling. What I mean by sampling is, you 680 00:41:26,200 --> 00:41:29,240 know, it's a huge set and I'm taking 10,000 and I'm choosing 681 00:41:29,240 --> 00:41:31,760 randomly because the blockchain ultimately needs to choose 682 00:41:31,760 --> 00:41:35,320 randomly and. Then if I get the. 683 00:41:35,320 --> 00:41:41,640 Set of 10,000 my my mathematical intuition says that if it's like 684 00:41:41,640 --> 00:41:42,960 25. Percent of that. 685 00:41:42,960 --> 00:41:47,160 Set of million is 250,000. They are malicious in some way 686 00:41:47,160 --> 00:41:52,840 and 750,000 are kind of honest. If I'm choosing 10,000 randomly, 687 00:41:53,640 --> 00:41:55,000 my odds. Of. 688 00:41:55,720 --> 00:42:04,440 Kind of choosing a set where the majority, maybe 66% is 689 00:42:04,440 --> 00:42:09,760 malicious, means 6666 are kind of malicious and the rest are 690 00:42:09,760 --> 00:42:13,080 good guys. I would think like that would 691 00:42:13,080 --> 00:42:15,880 happen pretty frequently, right? Like if I'm if I'm if I'm 692 00:42:15,880 --> 00:42:19,320 creating these sets like once every second, I would think 693 00:42:19,320 --> 00:42:23,440 every six months or every year I'm going to get a set which is 694 00:42:24,400 --> 00:42:26,040 which is full. Of full of malicious. 695 00:42:26,360 --> 00:42:29,440 Now so if you have. If you have 250 out of a 696 00:42:29,440 --> 00:42:34,080 million, then even sampling 1/3 will never happen. 697 00:42:34,640 --> 00:42:37,840 If you sample 10,000 out of a million, then even then sampling 698 00:42:37,840 --> 00:42:40,640 1/3 would not happen. It's extremely unlikely. 699 00:42:41,800 --> 00:42:43,440 Oh, it's. Extremely unlikely. 700 00:42:43,480 --> 00:42:46,560 So the so the my my my physical intuition is wrong. 701 00:42:46,560 --> 00:42:51,360 And if I'm sampling 10,000 out of a set of million and I keep 702 00:42:51,360 --> 00:42:55,040 doing that, keep creating new samples once, you can do it like 703 00:42:55,040 --> 00:42:56,640 billions of. Billions of billions of times. 704 00:42:56,640 --> 00:43:00,720 Like you can do it every nanosecond for a billion years 705 00:43:01,800 --> 00:43:04,400 and it will not happen. We actually had the. 706 00:43:04,400 --> 00:43:06,840 Math in. One of our original papers, 707 00:43:06,960 --> 00:43:09,960 right. And it was I I don't remember 708 00:43:10,000 --> 00:43:16,200 like that exact constants, but yeah, it was like 8:50 or. 20 709 00:43:16,200 --> 00:43:18,200 minus. Studying something like that, 710 00:43:19,000 --> 00:43:23,440 Probability so like longer than universe exists kind of thing. 711 00:43:24,080 --> 00:43:28,600 But to an extent, it doesn't. Matter because we still like if 712 00:43:28,600 --> 00:43:29,320 your intuition. Was. 713 00:43:29,320 --> 00:43:30,880 Correct. Or if my math was wrong, which 714 00:43:30,880 --> 00:43:33,200 is possible, it would only make the. 715 00:43:33,200 --> 00:43:34,120 Situation worse. Right. 716 00:43:34,120 --> 00:43:36,880 But we're saying we we're saying, hey, let's say the math 717 00:43:36,880 --> 00:43:39,720 is such that and and and I think it is right, let's say the math 718 00:43:39,720 --> 00:43:43,080 is such that it's very unlikely to sample a large percentage of 719 00:43:43,080 --> 00:43:45,440 bad guys. It still doesn't matter because 720 00:43:45,600 --> 00:43:48,520 good guys can become bad guys when they sufficiently incentive 721 00:43:48,520 --> 00:43:52,120 us to be bad guys. And and then in the world of 722 00:43:52,120 --> 00:43:55,760 blockchains, incentives are often such that you can, you can 723 00:43:55,760 --> 00:44:01,400 benefit a lot by by corrupting, you know, a set of validators. 724 00:44:01,400 --> 00:44:03,800 And so you you would every now and then the validation will 725 00:44:03,800 --> 00:44:06,400 choose to do, will choose to do so, right? 726 00:44:06,480 --> 00:44:07,960 And. So correspondingly you. 727 00:44:07,960 --> 00:44:11,600 Want to design a system where even if the set of validators in 728 00:44:11,600 --> 00:44:15,960 the chart is corrupted, right? Either either due to sampling or 729 00:44:15,960 --> 00:44:18,440 because they were corrupted, what we call adaptively right? 730 00:44:18,440 --> 00:44:22,480 So after the fact, then the system still operates reliably, 731 00:44:23,560 --> 00:44:25,120 and so there are. Multiple you know there. 732 00:44:25,120 --> 00:44:29,600 Are many ways of ensuring that and it's it's the area of 733 00:44:29,600 --> 00:44:33,040 research that has been developing and this is where in 734 00:44:33,040 --> 00:44:35,880 sharding we we use. You know this is the the biggest 735 00:44:36,560 --> 00:44:38,280 user of Ziggy proves in sharding. 736 00:44:38,400 --> 00:44:40,560 Because you know, if I can just prove that my transition is 737 00:44:40,560 --> 00:44:43,000 correct, then the problem is. Solved. 738 00:44:43,600 --> 00:44:45,840 Right, instead of sending a bunch of validators, if you can 739 00:44:45,840 --> 00:44:49,280 just have a proof that says everything is correct, that it's 740 00:44:50,160 --> 00:44:52,760 and the problem is solved. But maybe building building 741 00:44:52,760 --> 00:44:54,960 this? Up from the from bottom up, 742 00:44:54,960 --> 00:44:58,720 right. I mean it it starts with so kind 743 00:44:58,720 --> 00:45:02,000 of we discussed right. There's there's account space, 744 00:45:02,000 --> 00:45:04,200 right. You know, think of it as a city 745 00:45:04,600 --> 00:45:08,880 with people and you know we have the cell tower. 746 00:45:08,880 --> 00:45:12,080 So when people, you know call each other like for, for, for 747 00:45:12,080 --> 00:45:16,000 use of the of the analogy when people call each other in the 748 00:45:16,000 --> 00:45:20,240 city, right, Kind of bounces to the cell tower and then goes to 749 00:45:20,240 --> 00:45:25,000 another cell tower to kind of connect them and so. 750 00:45:25,120 --> 00:45:29,320 So the first thing that we need to do right is to ensure that 751 00:45:29,440 --> 00:45:34,680 every second, every transaction is recorded, right, ordered and 752 00:45:35,600 --> 00:45:36,880 kind of across all. Charts. 753 00:45:37,880 --> 00:45:44,120 And that no, there's no way even for if everybody is corrupted in 754 00:45:44,120 --> 00:45:49,400 that chart to be able to kind of change that order and and for 755 00:45:49,560 --> 00:45:53,040 other use cases also, you know, potentially introduce something 756 00:45:53,040 --> 00:45:56,720 that's not valid, right. And so that's called data 757 00:45:56,720 --> 00:45:59,120 availability problem. The near had kind of data 758 00:45:59,120 --> 00:46:06,720 availability from from 2019 then the design Nightshade and then 759 00:46:06,840 --> 00:46:11,400 you know as other approaches like roll ups etcetera started 760 00:46:11,400 --> 00:46:15,360 becoming more popular, they also needed data availability and 761 00:46:15,360 --> 00:46:18,560 that's kind of where a lot of the current data availability 762 00:46:18,560 --> 00:46:25,120 offerings are coming to market like a very short. 763 00:46:25,640 --> 00:46:29,040 Primer would be, you know, like let's use roll ups as an 764 00:46:29,040 --> 00:46:30,680 example, right? So there's, let's say this 765 00:46:30,680 --> 00:46:34,880 hypothetical optimism and they they do transactions, but they 766 00:46:34,880 --> 00:46:37,040 do not use zero knowledge proofs, right? 767 00:46:37,040 --> 00:46:38,760 Actually don't know if optimism is planning to use zero 768 00:46:38,760 --> 00:46:41,920 knowledge proofs, right? And so corresponding we're using 769 00:46:41,920 --> 00:46:44,480 zero knowledge proofs for fraud. Proofs, I see. 770 00:46:44,480 --> 00:46:45,600 Interesting. Interesting. 771 00:46:46,160 --> 00:46:48,960 And so they check in the, you know, the the, the state route 772 00:46:49,120 --> 00:46:55,680 to Ethereum every now and then. And they say, you know I applied 773 00:46:55,680 --> 00:46:59,120 all the transactions correctly. And if you think you did not, I 774 00:46:59,120 --> 00:47:03,720 posted just enough of cryptographic information of 775 00:47:03,720 --> 00:47:07,200 like you know, a gestation that that if I did something wrong, 776 00:47:07,200 --> 00:47:09,960 you would be able to come and prove that it was wrong, right. 777 00:47:09,960 --> 00:47:12,200 And if you do that, I will, I will lose a lot of money. 778 00:47:12,280 --> 00:47:14,120 And so I have a strong incentive not to do so. 779 00:47:14,560 --> 00:47:16,200 Right. And so and so then you observe 780 00:47:16,200 --> 00:47:19,560 the the roll up and you see that some transaction was applied 781 00:47:19,560 --> 00:47:22,400 incorrectly. You can go to a theorem and say 782 00:47:22,600 --> 00:47:25,240 this is a transaction. It was applied wrong and this is 783 00:47:25,240 --> 00:47:27,600 the proof, right? But you can only do that if you 784 00:47:27,600 --> 00:47:29,440 actually see the transactions, right? 785 00:47:29,440 --> 00:47:32,040 So if the if the if the roll up was able to operate in such a 786 00:47:32,040 --> 00:47:35,240 way that the validators cannot see the transactions, then the 787 00:47:35,240 --> 00:47:36,760 roll up would be snapshotting something. 788 00:47:37,000 --> 00:47:39,400 But nobody can prove anything wrong because nobody sees what's 789 00:47:39,400 --> 00:47:41,480 happening. It's like you know it's a filled 790 00:47:41,480 --> 00:47:43,600 room. So data availability is 791 00:47:43,600 --> 00:47:47,800 effectively this concept of ensuring and proving that the 792 00:47:47,800 --> 00:47:51,960 transactions that you claim to apply and the state on on top of 793 00:47:51,960 --> 00:47:54,520 which you claim to apply those transactions are all visible to 794 00:47:54,520 --> 00:47:57,000 everybody, right. And and that's something that 795 00:47:57,000 --> 00:47:59,720 Near had from we were either first or. 796 00:47:59,720 --> 00:48:02,200 Second to. Have it like I I don't know when 797 00:48:02,200 --> 00:48:04,360 I don't remember when polka got launched and whether they had 798 00:48:04,360 --> 00:48:05,880 the data will be with you from day one. 799 00:48:07,000 --> 00:48:08,640 OK, so you. Have like a Shard. 800 00:48:08,640 --> 00:48:11,320 And then there's a. There's a set of validators that 801 00:48:11,320 --> 00:48:14,120 are processing transactions in the Shard. 802 00:48:15,240 --> 00:48:16,800 Let's first get an. Intuition of like. 803 00:48:18,280 --> 00:48:19,880 This. Set of like let's say imagine. 804 00:48:19,880 --> 00:48:24,160 Like Shard 2 or whatever the set of validators at a processing 805 00:48:24,160 --> 00:48:27,480 Shard too. Is it like a static set or does 806 00:48:27,480 --> 00:48:30,880 it keep changing, changing with time? 807 00:48:31,120 --> 00:48:34,840 Dynamically it's? Changing with time so. 808 00:48:34,840 --> 00:48:39,640 The idea is and and so there is like what's right now lives and 809 00:48:39,640 --> 00:48:43,200 what's been lives for for a few years and also what's we 810 00:48:43,200 --> 00:48:44,840 launching with status validation. 811 00:48:45,720 --> 00:48:47,200 I'll probably just. Start with about. 812 00:48:47,200 --> 00:48:51,160 Status validation just for for ease of explanation. 813 00:48:52,080 --> 00:48:57,880 So the status validation there is a two set kind of two roles 814 00:48:57,880 --> 00:49:02,160 that eval that it can play and and all of this is repeatable 815 00:49:03,080 --> 00:49:04,480 once. One role. 816 00:49:04,480 --> 00:49:07,640 Is so-called chunk producer. Which? 817 00:49:07,640 --> 00:49:10,920 Is somewhat similar to what you enroll up school sequencers 818 00:49:11,360 --> 00:49:14,320 right to this. The node that receives the 819 00:49:14,320 --> 00:49:18,480 transaction orders it in the block in the chunk, in your 820 00:49:18,480 --> 00:49:21,720 case. Responsible for their Shard. 821 00:49:23,200 --> 00:49:28,240 It sends out this chunk to others as well and then executes 822 00:49:28,240 --> 00:49:31,840 the transactions. And receives the kind. 823 00:49:31,840 --> 00:49:37,160 Of the result and so importantly, kind of where comes 824 00:49:37,160 --> 00:49:40,720 in the data availability when when the chunk producer. 825 00:49:40,720 --> 00:49:45,320 Sends. Out the the chunked information 826 00:49:45,480 --> 00:49:47,760 they include. They kind of so-called erasure 827 00:49:47,760 --> 00:49:51,920 coded, which means they replicate this information in 828 00:49:51,920 --> 00:49:55,040 such a way that, you know, they send it to other cell towers 829 00:49:55,840 --> 00:49:59,920 such that even if everybody who's in, you know, servicing 830 00:49:59,920 --> 00:50:04,320 this cell tower is offline, goes malicious, etcetera, other cell 831 00:50:04,320 --> 00:50:07,520 towers can completely replicate everything that happened in the 832 00:50:07,520 --> 00:50:09,800 cell tower. So that's kind of what data 833 00:50:09,800 --> 00:50:14,320 availability erasure coding is. So there's a chunk producer now. 834 00:50:14,600 --> 00:50:18,000 There's a small set of chunk producers, kind of similar how 835 00:50:18,440 --> 00:50:22,000 you know there's single sequence are usually on roll ups, but you 836 00:50:22,000 --> 00:50:26,720 don't want that because of censorship and reliability now. 837 00:50:26,720 --> 00:50:29,160 For validators. Actually have a different story, 838 00:50:29,160 --> 00:50:31,280 right? So what? 839 00:50:31,360 --> 00:50:33,880 Expansion you have this. Adaptive corruption problem, 840 00:50:33,960 --> 00:50:36,160 right? So if you have validators which 841 00:50:36,160 --> 00:50:40,240 is sitting there for a long term for a long time, it's it's 842 00:50:40,240 --> 00:50:42,600 possible that you go and say like hey, if you're in this 843 00:50:42,600 --> 00:50:46,800 Shard and I see you in this Shard for example, or I can 844 00:50:46,800 --> 00:50:51,080 bribe you to you know do something for the shark and so 845 00:50:51,560 --> 00:50:54,520 and then you need fraud proofs. And fraud proofs are complicated 846 00:50:54,520 --> 00:50:57,480 and kind of require additional timelines. 847 00:50:58,440 --> 00:50:59,920 And so with the. Status of additional. 848 00:50:59,920 --> 00:51:03,360 Say actually the chart producer not just produces kind of the 849 00:51:03,360 --> 00:51:08,320 transactions but also includes all of the state required to 850 00:51:08,320 --> 00:51:12,200 execute this transactions. And so that's so-called state 851 00:51:12,200 --> 00:51:14,040 witness. And so. 852 00:51:14,040 --> 00:51:16,280 Then any other. Node in this in the network 853 00:51:16,400 --> 00:51:20,280 right can receive this block and execute it without knowing 854 00:51:20,280 --> 00:51:24,920 anything else about the network except kind of like client of 855 00:51:24,920 --> 00:51:28,760 the of the network. So you receive everything, kind 856 00:51:28,760 --> 00:51:30,680 of you. Need to validate that if you 857 00:51:30,680 --> 00:51:33,760 apply this transaction and you have the state and the state was 858 00:51:33,760 --> 00:51:37,520 included in the previous block, then the result of this and you 859 00:51:37,520 --> 00:51:41,720 can confirm that and kind of send the confirmation and so 860 00:51:41,720 --> 00:51:47,080 that's kind of I mean in a way it's you know kind of stateless 861 00:51:47,080 --> 00:51:50,040 validation is ability for any node to come in and say like hey 862 00:51:50,040 --> 00:51:52,800 I'm ready to validate. I don't need to sync synchronize 863 00:51:52,800 --> 00:51:56,160 the network state, I don't need to maintain the state in on my 864 00:51:56,160 --> 00:51:59,080 desk right. Which again reduces the needs 865 00:51:59,080 --> 00:52:04,280 for the validator node requirements they can. 866 00:52:04,280 --> 00:52:05,960 Just like make sure that. Everything's OK. 867 00:52:06,560 --> 00:52:12,120 And so now you can rotate this validator's validate what chart 868 00:52:12,120 --> 00:52:14,880 all the time every block they can be actually. 869 00:52:15,040 --> 00:52:17,400 You know you can randomly select set of validators. 870 00:52:18,160 --> 00:52:21,160 They can be overlapping. You can select you know out of 871 00:52:21,160 --> 00:52:24,360 the million you can select you know 100,000 per Shard and 872 00:52:24,360 --> 00:52:27,080 they've evaluated 10 shards for example each if if there's 873 00:52:27,080 --> 00:52:34,440 enough capacity or or any kind of parameters and they are able 874 00:52:34,440 --> 00:52:37,480 to validate this because they don't need to sync into the 875 00:52:37,480 --> 00:52:39,000 Shard. They don't need to process every 876 00:52:39,000 --> 00:52:41,840 single transaction that ever hit that Shard. 877 00:52:41,840 --> 00:52:44,360 They only need to look at this specific block. 878 00:52:45,280 --> 00:52:48,680 So that kind of opens up a lot, you know, both kind of, you 879 00:52:48,680 --> 00:52:51,360 know, you can imagine I'm actually really excited that 880 00:52:51,440 --> 00:52:54,880 potentially, you know, not probably this year but soon 881 00:52:55,480 --> 00:52:59,840 enough somebody can open up a new tab, you know type in the 882 00:52:59,840 --> 00:53:05,920 URL which has kind of a validator node in in a browser 883 00:53:06,240 --> 00:53:08,440 and actually start receiving blocks and validating them 884 00:53:08,800 --> 00:53:12,160 because again like you don't actually need anything else and 885 00:53:12,200 --> 00:53:15,440 and browsers have web assembly to execute the the transactions 886 00:53:16,640 --> 00:53:18,840 embedded. So that's kind of. 887 00:53:18,840 --> 00:53:21,160 The like. Very very light, lightweight 888 00:53:21,360 --> 00:53:23,240 validation that you can rotate all the time. 889 00:53:24,600 --> 00:53:27,040 So. Like I'm imagining. 890 00:53:27,040 --> 00:53:29,400 This state. Witness is as more like. 891 00:53:29,880 --> 00:53:33,520 So let's say like there was block N and. 892 00:53:33,720 --> 00:53:36,880 Then the transaction. Came in and the chunk producer 893 00:53:36,880 --> 00:53:41,360 made n + 1. But is it the case that? 894 00:53:41,760 --> 00:53:46,560 For every transaction, almost like for every transaction that 895 00:53:46,560 --> 00:53:50,200 they processed in in that block, they are creating individual 896 00:53:51,040 --> 00:53:54,440 witnesses for each transaction. So if you take transaction one, 897 00:53:55,000 --> 00:53:59,280 they'll say, OK, transaction 1 modifies these two. 898 00:53:59,280 --> 00:54:02,360 Accounts these. Two accounts had this balance 899 00:54:02,360 --> 00:54:05,040 previously after the modification. 900 00:54:05,560 --> 00:54:08,840 The result is these two accounts have this balance now. 901 00:54:09,320 --> 00:54:14,560 So our state witnesses this was. What was before? 902 00:54:14,560 --> 00:54:18,040 This transaction was processed. This was after the transaction. 903 00:54:18,040 --> 00:54:20,160 Process. But the data that's being 904 00:54:20,160 --> 00:54:24,160 supplied is only those two accounts that are hit by the 905 00:54:24,160 --> 00:54:28,280 transaction. And so for every transaction you 906 00:54:28,280 --> 00:54:32,040 are just creating like these like these bread crumbs, these 907 00:54:32,040 --> 00:54:36,000 bare minimum amount of info that is needed to kind of validate 908 00:54:36,000 --> 00:54:38,480 that transaction and that's the state witness for that 909 00:54:38,480 --> 00:54:41,600 transaction. So every transaction that comes 910 00:54:41,600 --> 00:54:46,640 in the block of the Shard by these this chunk producer entity 911 00:54:47,640 --> 00:54:51,800 is kind of broken down into these individually verifiable 912 00:54:51,800 --> 00:54:53,760 pieces. And then those individually 913 00:54:53,760 --> 00:54:58,120 verifiable pieces are scattered across all of the validators of 914 00:54:58,120 --> 00:55:01,960 the Shard and they can kind of do the job of verifying these 915 00:55:01,960 --> 00:55:05,680 individual pieces one by one. And because each of these piece 916 00:55:05,680 --> 00:55:11,080 can be verified individually you that's why you are able to run 917 00:55:11,360 --> 00:55:13,640 the validator in your browser because. 918 00:55:14,680 --> 00:55:16,200 While your browser. May not be a powerful. 919 00:55:16,200 --> 00:55:18,920 Machine, It can still validate a few of them. 920 00:55:20,960 --> 00:55:22,480 Yeah, yeah. That's, that's right. 921 00:55:24,200 --> 00:55:26,280 So. Is it the case that? 922 00:55:26,280 --> 00:55:30,640 This chunk producer that's kind of like more a more long. 923 00:55:30,640 --> 00:55:33,080 Lived. Role and then the validators of 924 00:55:33,080 --> 00:55:35,320 a Shard is like a more short lived role. 925 00:55:35,320 --> 00:55:40,760 Meaning as a validator I'm doing some verification in this Shard, 926 00:55:40,760 --> 00:55:44,480 then few seconds later in a different Shard than a third few 927 00:55:44,480 --> 00:55:45,880 seconds later than a different Shard. 928 00:55:45,880 --> 00:55:49,080 Like that I'm constantly switching as a validator but as 929 00:55:49,080 --> 00:55:51,800 a chunk producer and few seconds later is a little bit. 930 00:55:51,920 --> 00:55:54,320 Is a little bit consulting. We produce a block every second 931 00:55:54,400 --> 00:55:57,520 but. Yeah, it's like every second, 932 00:55:57,560 --> 00:55:59,320 every. Block you can be valid in a 933 00:55:59,320 --> 00:56:01,560 different Shard because there is actually no difference. 934 00:56:01,880 --> 00:56:04,480 Like you, you don't actually care which Shard it's on because 935 00:56:04,480 --> 00:56:08,200 for you it's just a block result like a set of transaction to 936 00:56:08,200 --> 00:56:11,240 resolve the information you need and so that's why you can rotate 937 00:56:11,240 --> 00:56:15,560 validators now every second. I mean there's like networking 938 00:56:15,560 --> 00:56:19,840 requirements and you know data information propagation, but in 939 00:56:19,840 --> 00:56:22,800 principle, yes it can. It can rotate every second and 940 00:56:22,800 --> 00:56:27,320 then for chunk producers they rotate every epoch right now, 941 00:56:27,320 --> 00:56:32,600 which is 12 hours or 12 to 14 hours and there. 942 00:56:32,640 --> 00:56:34,280 Where? You because you need to actually 943 00:56:34,280 --> 00:56:36,360 sync the state. Like if you're moving to the 944 00:56:36,360 --> 00:56:39,360 next chart for the chunk producer, you actually need to 945 00:56:39,360 --> 00:56:41,360 know everybody's balances, right? 946 00:56:41,360 --> 00:56:43,520 And so you need to actually download all that, make sure 947 00:56:43,520 --> 00:56:47,880 it's correct, consistent. And then kind of while you're 948 00:56:47,880 --> 00:56:51,560 downloading, you actually need to now receive new blocks and 949 00:56:51,560 --> 00:56:54,760 apply them as well. And so you're kind of doing 2 950 00:56:54,760 --> 00:56:57,240 jobs in parallel. You validate it, you kind of 951 00:56:57,240 --> 00:57:00,680 chunk producing the Shard you're in and you're getting ready to 952 00:57:00,680 --> 00:57:05,040 produce Shard that you are the next time. 953 00:57:05,600 --> 00:57:08,560 And so that requires kind of more sophisticated setup. 954 00:57:10,520 --> 00:57:12,080 Right. So, OK, so then you have. 955 00:57:12,080 --> 00:57:15,280 These validators that are constantly jumping. 956 00:57:15,280 --> 00:57:17,240 From Shard to. Shard validating some small 957 00:57:17,240 --> 00:57:21,120 pieces and when is it the case? In like when I'm validating a 958 00:57:21,120 --> 00:57:25,000 certain piece, I'm also adding my signature saying yes I 959 00:57:25,000 --> 00:57:29,680 checked it and it's correct and every transaction and it's it's 960 00:57:29,680 --> 00:57:33,440 witness is kind of getting more and more signatures or 961 00:57:33,440 --> 00:57:36,040 attestations on the validators and that's how you're building 962 00:57:36,040 --> 00:57:39,560 up trust, but it's not. Accumulating over time. 963 00:57:39,600 --> 00:57:41,600 All the signatures happen on the same block, right? 964 00:57:41,600 --> 00:57:46,720 So, so every block you need to do a sign off and it's not, it's 965 00:57:46,720 --> 00:57:49,640 not the case that everybody signs of every block, right. 966 00:57:50,440 --> 00:57:52,320 We we just need a certain majority. 967 00:57:53,280 --> 00:57:55,480 And you know, like because blocks are created every every 968 00:57:55,480 --> 00:57:57,920 second and the validators are running on the relatively 969 00:57:57,920 --> 00:58:01,160 community hardware, sometimes you will miss a signature and 970 00:58:01,160 --> 00:58:05,320 like if you go to an explorer you will see that like nobody 971 00:58:05,360 --> 00:58:10,520 has 100% up time, people have like 99%, right. 972 00:58:10,520 --> 00:58:12,640 But yeah, but the idea is that, yeah. 973 00:58:12,640 --> 00:58:13,920 There's a. Set of validators. 974 00:58:14,160 --> 00:58:17,280 They validating a particular block, We know whom we expect to 975 00:58:17,280 --> 00:58:19,960 sign off on the block and then you know a majority, a 976 00:58:20,400 --> 00:58:23,120 percentage of them signs off and the block is created. 977 00:58:23,400 --> 00:58:25,840 You can look at it and say, well, that many validator signed 978 00:58:25,840 --> 00:58:28,520 off at this point. I know which charge they. 979 00:58:28,520 --> 00:58:31,280 Were supposed to validate. I know that unless someone 980 00:58:31,280 --> 00:58:34,960 corrupted them in .1 milliseconds, you know it's 981 00:58:35,760 --> 00:58:37,960 There's a relatively high certainty that the state 982 00:58:37,960 --> 00:58:41,800 transition is valid, right? Because on the. 983 00:58:41,800 --> 00:58:45,320 Other side, the mathematics says that when I'm sampling these 984 00:58:45,320 --> 00:58:51,480 validators randomly, my odds of getting a completely bad set of 985 00:58:51,480 --> 00:58:54,640 validators. If 25% of the set in the bigger 986 00:58:54,640 --> 00:58:58,080 network is corrupt, it's kind of low. 987 00:58:58,760 --> 00:59:03,320 So because of of that sampling, you're able to kind of trust 988 00:59:03,320 --> 00:59:06,080 that OK, while these validators are considered or you are 989 00:59:06,080 --> 00:59:09,080 sampling them constantly every second you are changing the 990 00:59:09,080 --> 00:59:13,000 samples, but because the prob. You. 991 00:59:13,000 --> 00:59:17,720 Calculate the. Probability of 1 sample being. 992 00:59:17,720 --> 00:59:21,880 Being malicious like. So 66% extent or something has 993 00:59:21,880 --> 00:59:25,080 been very low, you are able to trust kind of like the 994 00:59:25,080 --> 00:59:30,360 signatures on the witnesses of your transactions and be be sure 995 00:59:30,360 --> 00:59:35,360 of the state of of a particular Shard and. 996 00:59:35,360 --> 00:59:37,600 Meanwhile like these chunk. Producers, when they are 997 00:59:37,600 --> 00:59:41,600 producing these blocks, they are also forwarding the data 998 00:59:41,600 --> 00:59:46,360 corresponding to these blocks. To a set of validators. 999 00:59:46,360 --> 00:59:49,720 Now these this this other set of validators may be different from 1000 00:59:49,720 --> 00:59:52,560 the validators that are checking. 1001 00:59:52,560 --> 00:59:54,960 The witness the. Witnesses of the transactions 1002 00:59:54,960 --> 00:59:58,240 like they don't need to be the same set and. 1003 00:59:58,240 --> 00:59:59,920 So so. There's two things that 1004 00:59:59,920 --> 01:00:00,760 happened. One is. 1005 01:00:02,000 --> 01:00:03,320 You I. Mean the the. 1006 01:00:03,320 --> 01:00:05,560 Validators. That are receiving to check the 1007 01:00:05,560 --> 01:00:08,880 witnesses that actually received the data as well, right? 1008 01:00:09,040 --> 01:00:11,200 Because they actually can validate the transactions. 1009 01:00:11,880 --> 01:00:15,960 But also you want to send to other shards as well in case you 1010 01:00:15,960 --> 01:00:19,320 know this whole Shard of sale. But also like just you want to 1011 01:00:19,320 --> 01:00:24,000 route outgoing messages and so we're actually combine the 1012 01:00:24,000 --> 01:00:27,200 message routing data availability. 1013 01:00:27,200 --> 01:00:29,280 And. Consensus into kind of one 1014 01:00:29,480 --> 01:00:34,760 process where let's say you have you know let's say like you 1015 01:00:35,360 --> 01:00:40,120 withdrew money from my account on Shark One and then you're 1016 01:00:40,120 --> 01:00:42,720 sending money to Alex within Shark Two. 1017 01:00:42,720 --> 01:00:46,240 So now there's a message going to Shark Two saying you know you 1018 01:00:46,240 --> 01:00:49,560 should debit Alex you know 10 year. 1019 01:00:50,760 --> 01:00:55,120 And so now that message is not just a message, it also includes 1020 01:00:55,440 --> 01:01:02,320 a so-called eraser coded part of the transaction data that this 1021 01:01:02,320 --> 01:01:07,640 Shard was producing. And so kind of this process 1022 01:01:07,800 --> 01:01:12,360 ensures few things. One is everybody you know then 1023 01:01:12,360 --> 01:01:16,280 goes and when they actually signing and confirming their own 1024 01:01:16,280 --> 01:01:19,560 information and and sending the their approval, it also 1025 01:01:19,560 --> 01:01:23,800 confirmed they received the needed chunks, the needed kind 1026 01:01:23,800 --> 01:01:27,360 of parts from other shards. And so that's also provides us 1027 01:01:27,360 --> 01:01:31,160 guarantees to this this message delivery from from Shard to 1028 01:01:31,160 --> 01:01:34,600 Shard, it provides the data ability guarantees and it's all 1029 01:01:34,600 --> 01:01:38,440 kind of, you know integrated into the consensus messages that 1030 01:01:38,440 --> 01:01:42,960 are being sent by validators to each other to actually 1031 01:01:42,960 --> 01:01:46,560 accumulate the BST consensus let's say. 1032 01:01:46,560 --> 01:01:47,800 It's worth mentioning you there's an. 1033 01:01:47,800 --> 01:01:50,000 Extra role called block producers right. 1034 01:01:50,000 --> 01:01:53,880 So there's an actual is the blockchain, is the near 1035 01:01:53,880 --> 01:01:56,920 blockchain So it's not like because often when people think 1036 01:01:56,920 --> 01:02:00,080 of sharding and you know many sharding blockchains do work 1037 01:02:00,080 --> 01:02:01,960 this way. People think of multiple chains, 1038 01:02:02,240 --> 01:02:03,840 right? So every Shard is a chain. 1039 01:02:04,000 --> 01:02:06,840 It is not the case on near. On near there's only one block 1040 01:02:06,840 --> 01:02:10,960 chain and and there are block producers creating blocks on the 1041 01:02:10,960 --> 01:02:16,720 chain and when but but those blocks do not contain the actual 1042 01:02:16,720 --> 01:02:19,680 transactions, right? Or or like logically they do 1043 01:02:19,680 --> 01:02:21,160 right? Like you can think of a block 1044 01:02:21,760 --> 01:02:24,520 exactly the same way as you would think of a block on 1045 01:02:24,520 --> 01:02:27,480 Etherium, where it has like a header, consensus information 1046 01:02:28,320 --> 01:02:31,480 and a bunch of transactions with a difference that while 1047 01:02:31,480 --> 01:02:34,160 logically transactions are there, physically it only 1048 01:02:34,160 --> 01:02:37,600 contains information about what we call chunks, SO1 chunk per 1049 01:02:37,600 --> 01:02:39,960 Shard, or rather up to 1 chunk per Shard. 1050 01:02:40,360 --> 01:02:43,280 And physically, the block does not contain those transactions, 1051 01:02:43,280 --> 01:02:45,480 it just contains the information about the chunks that were 1052 01:02:45,480 --> 01:02:48,280 produced, right? And at every particular block, 1053 01:02:48,680 --> 01:02:51,760 some shards might might miss a chunk, right, because there's a 1054 01:02:51,760 --> 01:02:54,320 particular chunk producer responsible at every particular 1055 01:02:54,320 --> 01:02:56,760 moment. It could be a flying, it could 1056 01:02:56,760 --> 01:03:01,840 be, you know, busy, etcetera. And so a chunk could be could 1057 01:03:01,920 --> 01:03:04,960 could be missed, right? But if the chunk is produced, 1058 01:03:04,960 --> 01:03:07,200 what happens is that the chunk producer, when they produce a 1059 01:03:07,200 --> 01:03:11,200 chunk, as Ilya mentioned, they erasure coded and they send a 1060 01:03:11,200 --> 01:03:14,000 part of it to every block producer, right? 1061 01:03:14,560 --> 01:03:17,760 And the block producer would only sign off on the block if 1062 01:03:17,760 --> 01:03:22,720 they have a part of the chunk that that that is intended for 1063 01:03:22,720 --> 01:03:25,400 them. And so this is where consensus 1064 01:03:25,400 --> 01:03:31,080 and data availability are sort of mended together, is that, you 1065 01:03:31,080 --> 01:03:33,560 know, in order to reach a consensus on the block, 2/3 of 1066 01:03:33,640 --> 01:03:37,400 all the block producers waiting by stake have to sign off on it, 1067 01:03:37,480 --> 01:03:38,760 right? It's a BFT consensus. 1068 01:03:38,760 --> 01:03:41,600 If there's no 2/3 of signatures, the block, you know, we wait 1069 01:03:41,600 --> 01:03:44,600 until we have, right? We we favour safety over 1070 01:03:44,600 --> 01:03:46,800 liveness. And correspondingly, if we 1071 01:03:46,800 --> 01:03:49,680 cannot get 2/3 of signatures, we will stall, right? 1072 01:03:49,680 --> 01:03:54,360 But we and if you have 2/3 of signatures, because the block 1073 01:03:54,360 --> 01:03:57,040 producer would only sign off on the block if they have their 1074 01:03:57,360 --> 01:04:00,160 part of every chunk in the block, right? 1075 01:04:00,360 --> 01:04:03,680 Then you know that 2/3 of the block producers have, for every 1076 01:04:03,680 --> 01:04:05,400 chunk included have their little part. 1077 01:04:06,000 --> 01:04:10,920 And the eraser code is such that you need 1/3 to reconstruct any 1078 01:04:10,920 --> 01:04:13,240 chunk, right? So as long as you believe that 1079 01:04:13,240 --> 01:04:16,240 no more than 1/3 of the block producers is malicious, and if 1080 01:04:16,240 --> 01:04:19,920 you have 2/3 of signatures, in the worst case all the malicious 1081 01:04:19,920 --> 01:04:22,640 actors are included in those 2/3. 1082 01:04:22,640 --> 01:04:26,600 So you have 1/3 malicious, but you still have 1/3 honest and so 1083 01:04:26,600 --> 01:04:28,600 you can you can reconstruct any chunk, right? 1084 01:04:28,600 --> 01:04:31,960 So every chunk is available to everybody, guaranteed if you 1085 01:04:31,960 --> 01:04:33,600 have consensus reached on the block. 1086 01:04:33,760 --> 01:04:37,080 So data availability and consensus are merged together. 1087 01:04:37,080 --> 01:04:39,120 Into a single. Single mechanic. 1088 01:04:41,480 --> 01:04:43,360 Right, so like, this is wicked. Cool. 1089 01:04:43,800 --> 01:04:47,440 And it's also like hard to understand because this is 1090 01:04:47,440 --> 01:04:52,520 actually unlike any other system where data availability and 1091 01:04:52,520 --> 01:04:56,640 consensus are usually like like two very separate processes like 1092 01:04:56,800 --> 01:05:00,160 whether you go from the Ethereum to Celestia to all of the. 1093 01:05:00,400 --> 01:05:04,440 But in near it's almost essence right you you want. 1094 01:05:04,440 --> 01:05:10,400 To it, it sort of begins with with the your goals, right? 1095 01:05:10,400 --> 01:05:11,840 And then and then we were going back right. 1096 01:05:11,840 --> 01:05:15,480 So the goal was to have crossword transactions and 1097 01:05:15,480 --> 01:05:20,480 generally communication to be with a delay of one block, 1098 01:05:20,840 --> 01:05:22,800 right. So if I effectively, if in a 1099 01:05:22,800 --> 01:05:25,160 particular block a transaction initiated and it wants to do 1100 01:05:25,160 --> 01:05:28,880 something in another Shard, we want that to happen with a very 1101 01:05:28,880 --> 01:05:32,360 high probability in exactly the next block, right? 1102 01:05:32,960 --> 01:05:35,760 And so if the data availability was separate from consensus, 1103 01:05:35,760 --> 01:05:37,760 that would be extremely hard to ensure, right? 1104 01:05:37,760 --> 01:05:42,360 Because we need to be certain that data is available as of the 1105 01:05:42,360 --> 01:05:43,160 moment. When the block. 1106 01:05:43,160 --> 01:05:47,320 Is produced as opposed to that being a separate process, right? 1107 01:05:47,640 --> 01:05:50,000 And similarly Ilya mentioned there are three things which are 1108 01:05:50,000 --> 01:05:53,520 merged together, a data availability, consensus and the 1109 01:05:53,520 --> 01:05:58,000 message passing right. So together the chunk that is 1110 01:05:58,000 --> 01:06:01,760 now totally available and the moment of consensus being 1111 01:06:01,760 --> 01:06:04,600 reached also contains the messages that needs to be routed 1112 01:06:04,600 --> 01:06:07,560 to the to another chart. And it is designed in such a way 1113 01:06:07,560 --> 01:06:12,120 that it is ensured that by the time the chunk producer or that 1114 01:06:12,120 --> 01:06:15,360 other chart is producing the chunk, they not only know that 1115 01:06:15,360 --> 01:06:18,040 the messages exist, but they also have them right and so they 1116 01:06:18,040 --> 01:06:20,480 can immediately act upon it. And moreover they have to act 1117 01:06:20,480 --> 01:06:22,960 upon them, right? So a chunk producer, the chunk 1118 01:06:22,960 --> 01:06:26,160 would not be valid if the chunk producer did not act on the 1119 01:06:26,160 --> 01:06:28,520 messages that were sent from another sharp. 1120 01:06:28,840 --> 01:06:31,080 It could be that they don't act upon them immediately because 1121 01:06:31,080 --> 01:06:33,400 they because of congestion, like you mentioned, everybody sending 1122 01:06:33,400 --> 01:06:35,160 receipts to the same sharp right. 1123 01:06:35,160 --> 01:06:36,840 So that is automatically handled, right? 1124 01:06:36,840 --> 01:06:39,520 It could be that the receipt was not processed immediately, but 1125 01:06:39,520 --> 01:06:41,600 the receipt was acknowledged immediately and it's put on the 1126 01:06:41,600 --> 01:06:45,160 queue immediately. And most of the time it is also 1127 01:06:45,520 --> 01:06:47,680 acted upon immediately because congestion is there. 1128 01:06:48,120 --> 01:06:50,680 You know, most of the time there's no congestion, right? 1129 01:06:50,680 --> 01:06:52,040 But it is all. Part of the same. 1130 01:06:52,040 --> 01:06:56,320 Process where we ensure that if something happens in block M and 1131 01:06:57,920 --> 01:07:01,600 that something wants something else to happen in another shirt, 1132 01:07:01,600 --> 01:07:04,840 that something else will very likely happen in N + 1. 1133 01:07:07,000 --> 01:07:10,280 And maybe to to use like. ECDM and roll ups and allergy 1134 01:07:10,280 --> 01:07:14,360 here that you know you have optimism producing a block, 1135 01:07:15,320 --> 01:07:18,200 right? That block immediately sent to 1136 01:07:18,600 --> 01:07:27,920 ECDM validators who included and as well as they include every 1137 01:07:27,920 --> 01:07:30,280 other role. Let's say we have our optimism 1138 01:07:30,280 --> 01:07:35,000 arbitral trying to to send money directly between each other, 1139 01:07:35,200 --> 01:07:37,640 right? So like both of their blocks 1140 01:07:37,640 --> 01:07:42,360 need to be included at the same time immediately in the same 1141 01:07:42,360 --> 01:07:45,840 ECDM block, right? To guarantee data availability? 1142 01:07:46,880 --> 01:07:53,680 Because now the kind of our like let's say optimism sense 1143 01:07:53,680 --> 01:07:57,440 something to arbitrary connect. In it but. 1144 01:07:58,040 --> 01:08:02,520 If it's just that right, then arbitrary needs to read out the 1145 01:08:02,520 --> 01:08:06,760 state from from the CDM, right? Which adds extra latency. 1146 01:08:07,040 --> 01:08:11,200 And So what happens here is you assume that optimism and 1147 01:08:11,200 --> 01:08:14,960 Arbitrary are that those sequences are also validators in 1148 01:08:14,960 --> 01:08:19,000 the network. And so you send them, you kind 1149 01:08:19,000 --> 01:08:22,200 of optimism order and send their blocks to each other, right. 1150 01:08:22,200 --> 01:08:25,760 They confirm it and kind of those such stations are now 1151 01:08:25,800 --> 01:08:28,600 allowed to progress forward the blockchain. 1152 01:08:29,439 --> 01:08:32,920 And so like as if all the roll ups themselves formed a CEO 1153 01:08:32,920 --> 01:08:36,920 consensus, right and we're sending information to each 1154 01:08:36,920 --> 01:08:40,800 other directly and in turn that allows to optimize for latency 1155 01:08:40,800 --> 01:08:44,560 and for kind of this cross short communication because everybody 1156 01:08:44,560 --> 01:08:48,880 talking to each other directly and but rely but then you know 1157 01:08:49,040 --> 01:08:51,960 sending confirmation to the to the whole United system. 1158 01:08:53,479 --> 01:08:57,080 So I'll I'll try. To state this in kind of my own 1159 01:08:57,080 --> 01:09:02,319 understanding of how it works. So so it's like we need two 1160 01:09:02,319 --> 01:09:04,200 different views. One is kind of like the Shard 1161 01:09:04,200 --> 01:09:07,760 view and then when we need like the global view because there's 1162 01:09:07,760 --> 01:09:10,120 a global block. So you know, we we went to the 1163 01:09:10,120 --> 01:09:13,560 Shard view pretty well. It's like there's a huge set of 1164 01:09:13,560 --> 01:09:17,880 validators, Some of them are assigned to the Shard for. 1165 01:09:17,880 --> 01:09:20,319 For a block and then then we. Reassigned to other shards, and 1166 01:09:20,319 --> 01:09:23,760 they're kind of like validating the parts of the transactions. 1167 01:09:23,760 --> 01:09:27,080 In the Shard. Now these validators some 1168 01:09:27,279 --> 01:09:30,000 sometimes they also get the responsibility of being these 1169 01:09:30,000 --> 01:09:33,840 chunk producers which are more like long lasting entities for 1170 01:09:33,840 --> 01:09:36,600 12 hours for particular Shard they are. 1171 01:09:37,040 --> 01:09:39,920 They are producing like OK for this block. 1172 01:09:39,920 --> 01:09:43,160 This is the set of. Transactions. 1173 01:09:43,160 --> 01:09:46,560 And here are all of the witnesses, witnesses for it. 1174 01:09:46,560 --> 01:09:48,319 So these are like long lasting entities. 1175 01:09:48,760 --> 01:09:51,279 So you could have like a short lasting role and then you could 1176 01:09:51,319 --> 01:09:55,360 also get a long lasting role as a as as a validator, right. 1177 01:09:55,960 --> 01:09:58,120 So that's kind of like the local view of the Shard. 1178 01:09:58,120 --> 01:10:03,240 Now in the network there's like a global view where there's 1179 01:10:03,240 --> 01:10:06,520 actually a single blockchain with like block after block 1180 01:10:06,520 --> 01:10:11,800 after block like like Bitcoin or Ethereum, but what that block 1181 01:10:11,800 --> 01:10:17,920 contains is not the transactions themselves, but the chunks, 1182 01:10:18,560 --> 01:10:22,880 probably different shards that are sort of accepted. 1183 01:10:23,160 --> 01:10:25,280 Post. Consensus as being correct. 1184 01:10:25,320 --> 01:10:30,360 Like, OK, so here's block N it contains chunk chunk 1 from this 1185 01:10:30,360 --> 01:10:34,440 Shard, like chunk X from this Shard, chunk Y from that Shard, 1186 01:10:34,440 --> 01:10:37,160 chunk Z from that Shard and so on. 1187 01:10:37,440 --> 01:10:42,520 And it just contains what chunks the networks is is considering, 1188 01:10:42,520 --> 01:10:46,640 like finalized. And so all of the validators are 1189 01:10:46,640 --> 01:10:50,000 trying to build this blockchain that just contains contains 1190 01:10:50,000 --> 01:10:52,880 chunks and. The. 1191 01:10:52,880 --> 01:10:58,000 Validators are kind of like signing off on that on that 1192 01:10:58,000 --> 01:11:00,880 block containing chunks. They are trying to add their 1193 01:11:00,880 --> 01:11:05,440 signatures to it and their logic is something like what they are 1194 01:11:05,440 --> 01:11:09,120 checking is corresponding to each of the chunks that are part 1195 01:11:09,120 --> 01:11:15,520 of the block. Did I get the the slice of data 1196 01:11:16,760 --> 01:11:20,920 in order to ensure data availability for the whole 1197 01:11:20,920 --> 01:11:22,680 network? So as a validator, when I'm 1198 01:11:22,680 --> 01:11:26,240 signing off on a block, what I'm checking is OK, this block 1199 01:11:26,240 --> 01:11:29,520 contains these chunks. If it contains these chunks, I 1200 01:11:29,520 --> 01:11:33,440 should have received the data corresponding to these chunks. 1201 01:11:33,440 --> 01:11:35,800 Do I have it in my hard drive? Yes. 1202 01:11:36,200 --> 01:11:38,880 OK, so that's one sort of validation passed. 1203 01:11:39,480 --> 01:11:44,560 And then I sign and like all of the other validators are signing 1204 01:11:44,560 --> 01:11:47,360 that. So fundamentally the network is 1205 01:11:47,360 --> 01:11:54,240 coming to agreement that we have the data that we are going to 1206 01:11:54,240 --> 01:11:59,120 need to reconstruct any part of the actual transactions in the 1207 01:11:59,120 --> 01:12:01,280 block in the future. That's the thing people are 1208 01:12:01,280 --> 01:12:04,560 coming to consensus. So in a in a normal like Bitcoin 1209 01:12:04,560 --> 01:12:09,160 like the when a block gets finalized, the network comes to 1210 01:12:09,160 --> 01:12:13,240 consensus about these transactions that are processed 1211 01:12:13,320 --> 01:12:15,320 in near. When a block gets finalized, 1212 01:12:15,320 --> 01:12:19,320 network is coming to consensus about the validators 1213 01:12:19,680 --> 01:12:23,240 collectively agreeing that. They all have. 1214 01:12:23,240 --> 01:12:30,080 The data needed to reconstruct every part of the block should 1215 01:12:30,080 --> 01:12:32,200 the need ever arise. Is that right? 1216 01:12:32,920 --> 01:12:35,760 Is that intuition right? And they also. 1217 01:12:35,760 --> 01:12:37,400 Like in the world of. Stateless validation. 1218 01:12:37,400 --> 01:12:40,720 We also have the information that each of those parts were 1219 01:12:40,720 --> 01:12:46,000 reconstructed and validated by by a set of validators, right? 1220 01:12:46,000 --> 01:12:47,160 Right. Not only that, the. 1221 01:12:47,840 --> 01:12:52,640 The that the data is there that can reconstruct everything in 1222 01:12:52,720 --> 01:12:56,440 every transaction in the chunks, but also the data corresponding 1223 01:12:56,440 --> 01:12:59,240 to that every. Transaction. 1224 01:12:59,240 --> 01:13:03,760 With its state witnesses was. Validated by a. 1225 01:13:03,760 --> 01:13:07,200 Certain number of validators of the shards where the state 1226 01:13:07,200 --> 01:13:10,760 witnesses originated. So it's coming. 1227 01:13:10,760 --> 01:13:13,480 To consensus. About data that's yeah, that's 1228 01:13:13,480 --> 01:13:15,520 really interesting. It's really cool. 1229 01:13:17,040 --> 01:13:18,680 Yeah, I mean. The big the big benefit. 1230 01:13:18,680 --> 01:13:22,360 Was and I mean we do get this question which is like, you know 1231 01:13:22,360 --> 01:13:28,160 why ECDM kind of shifted from sharding to roll up architecture 1232 01:13:28,840 --> 01:13:30,400 and I mean. First of all, obviously not. 1233 01:13:30,400 --> 01:13:35,200 Talking for anybody individually, ECDM or ECDM is 1234 01:13:35,200 --> 01:13:39,920 not an agent themselves either. But practically speaking, to 1235 01:13:39,920 --> 01:13:42,280 design something like this right, you need to build 1236 01:13:42,280 --> 01:13:45,280 everything from ground up. You see how consensus, data 1237 01:13:45,280 --> 01:13:50,480 availability, message passing and kind of validation 1238 01:13:50,480 --> 01:13:56,000 correctness all layered in into one system and that requires 1239 01:13:56,000 --> 01:14:00,320 kind of this like approach and as well as the VM itself, right? 1240 01:14:00,320 --> 01:14:06,640 Because VM now needs to be aware that compared to you EDM where 1241 01:14:06,640 --> 01:14:09,440 everything is kind of available, right, you can always say like 1242 01:14:09,440 --> 01:14:13,680 hey, give me a state of that other account, like tell me how 1243 01:14:13,680 --> 01:14:18,520 much tokens does you know Alex have in, in the case of the 1244 01:14:18,560 --> 01:14:22,080 charted system like that requires a cross chart message, 1245 01:14:22,080 --> 01:14:23,760 right? That requires saying like, well 1246 01:14:23,840 --> 01:14:27,840 go find where Alex lives, right? And you know and ask him how 1247 01:14:27,840 --> 01:14:30,920 much tokens he has. And so you need to design kind 1248 01:14:30,920 --> 01:14:34,600 of everything from scratch, from bottom up with this 1249 01:14:34,600 --> 01:14:37,680 understanding given the goal we had, which is like you know, 1250 01:14:37,680 --> 01:14:42,760 ultimate horizontal scaling that is hidden from the users and 1251 01:14:42,760 --> 01:14:47,840 developers in many cases. And so for ECDM like they, they 1252 01:14:47,840 --> 01:14:50,440 can do not have such a luxury, right. 1253 01:14:50,440 --> 01:14:53,520 They have a working system, extremely valuable, extremely 1254 01:14:54,080 --> 01:14:56,760 kind of integrated everywhere. And so they needed something 1255 01:14:56,760 --> 01:15:01,440 that is kind of an evolution of their existing system versus a 1256 01:15:01,440 --> 01:15:03,440 complete rebuild right from scratch. 1257 01:15:04,080 --> 01:15:07,040 And I mean roll up architecture, you know, we use it as an 1258 01:15:07,040 --> 01:15:08,880 analogy because a lot of it is similar. 1259 01:15:09,040 --> 01:15:12,040 ECIDIUM provides the availability and consensus roll 1260 01:15:12,040 --> 01:15:14,760 ups are able to communicate with each other, but they need to go 1261 01:15:14,760 --> 01:15:18,840 through Etherium pretty much to kind of validate and and settle 1262 01:15:18,840 --> 01:15:22,320 before a message can be passed. And so a lot of it is kind of 1263 01:15:22,320 --> 01:15:25,520 spiritually the same and it's just because of the kind of 1264 01:15:25,760 --> 01:15:30,640 legacy of like well now each EVM is the whole separate universe 1265 01:15:30,640 --> 01:15:33,000 of accounts, right? And so now you I am as a user 1266 01:15:33,000 --> 01:15:35,120 have account that every chain right. 1267 01:15:35,120 --> 01:15:38,320 I don't have a singular balance now that I can use everywhere. 1268 01:15:38,600 --> 01:15:42,720 Like all of that is kind of a legacy, you know how do we kind 1269 01:15:42,720 --> 01:15:46,240 of upgrade the existing system into more scalable platform. 1270 01:15:46,560 --> 01:15:51,320 So that's kind of really the, the biggest obviously you know 1271 01:15:51,320 --> 01:15:54,120 in a way better that we had which was like starting from 1272 01:15:54,120 --> 01:15:55,520 scratch and kind of designing it. 1273 01:15:56,040 --> 01:15:58,400 Was this the luxury of the clean slate? 1274 01:15:58,640 --> 01:16:01,680 Yeah, luxury of the. Clean slate is. 1275 01:16:03,240 --> 01:16:05,760 Is what you had, right? Right. 1276 01:16:05,760 --> 01:16:07,840 So as a. Validator. 1277 01:16:09,320 --> 01:16:14,280 Sometimes I am. Taking on this role of being a 1278 01:16:14,280 --> 01:16:15,360 long. Lived Chunk. 1279 01:16:15,360 --> 01:16:18,040 Producer for 12 hours in a particular Shard. 1280 01:16:19,920 --> 01:16:23,960 I am constantly taking. The role of validating the state 1281 01:16:23,960 --> 01:16:27,200 witnesses of a Shard and I'm being assigned from Shard to 1282 01:16:27,200 --> 01:16:30,680 Shard to Shard and then. Every time a kind. 1283 01:16:30,680 --> 01:16:35,200 Of like a block is produced in the global main network what 1284 01:16:35,200 --> 01:16:36,520 I'm. Signing off on. 1285 01:16:36,520 --> 01:16:39,560 Is corresponding. To that block. 1286 01:16:40,360 --> 01:16:44,920 I should have received some data to backup the data of the state 1287 01:16:44,920 --> 01:16:46,920 of the entire network. The data of the entire network, 1288 01:16:46,920 --> 01:16:48,920 I should have received some small chunk of it. 1289 01:16:48,960 --> 01:16:51,960 I can identify it, have I received it. 1290 01:16:52,720 --> 01:16:56,360 And then I should not only should I have received data, but 1291 01:16:56,360 --> 01:17:00,960 I should have also validated some of the witnesses in the 1292 01:17:00,960 --> 01:17:03,280 global network or in the Shard. Have I done that? 1293 01:17:03,280 --> 01:17:05,000 And if I have done that, I sign off. 1294 01:17:05,800 --> 01:17:10,120 And if a majority signs off, that is when Near says OK, we 1295 01:17:10,120 --> 01:17:15,560 have consensus over all that the data is backed up properly and 1296 01:17:15,560 --> 01:17:20,040 all parts of the update had witnesses and they were 1297 01:17:20,040 --> 01:17:25,200 validated by enough, enough, enough validators and therefore 1298 01:17:25,200 --> 01:17:28,920 like this block is correct and like then that's done and then 1299 01:17:28,920 --> 01:17:30,680 the chain moves on. Yes. 1300 01:17:30,840 --> 01:17:31,760 Yeah, that's right. And. 1301 01:17:32,120 --> 01:17:35,080 At the end of the day, all of that complexity. 1302 01:17:35,080 --> 01:17:37,800 Boils. Down to you know, like there are 1303 01:17:37,800 --> 01:17:40,320 checks and balances that people do, but at the end of the day, 1304 01:17:40,440 --> 01:17:44,320 all you care about as the observer is do I have signatures 1305 01:17:44,800 --> 01:17:47,160 from the sufficient set to validate, and if I do, I know 1306 01:17:47,160 --> 01:17:50,880 that they have done all the work, or at least they claim to, 1307 01:17:50,880 --> 01:17:52,400 to have done so, right? But that's. 1308 01:17:52,520 --> 01:17:54,280 But that's a whole set of validators, right? 1309 01:17:54,280 --> 01:17:57,600 So for them to be corrupted, you need you. 1310 01:17:57,600 --> 01:18:01,760 Need to corrupt. Like a whole big proof of stake 1311 01:18:01,760 --> 01:18:07,400 system, which, you know, yeah, it has its own, you know, 1312 01:18:07,440 --> 01:18:09,680 design. There are certain design 1313 01:18:09,680 --> 01:18:11,800 principles that don't allow it to be corrupted without a 1314 01:18:11,800 --> 01:18:13,720 massive amount of money being lost. 1315 01:18:14,920 --> 01:18:18,440 And yeah, and so that allows also, you know, other chains to 1316 01:18:18,480 --> 01:18:20,240 easily create light clients, right, So. 1317 01:18:20,520 --> 01:18:22,760 So near itself. Encompasses a lot of processing 1318 01:18:22,760 --> 01:18:24,480 internally. It could also be a part of a 1319 01:18:24,520 --> 01:18:26,920 bigger ecosystem because building a lifetime for near is 1320 01:18:26,920 --> 01:18:28,560 a relatively straightforward process. 1321 01:18:29,000 --> 01:18:33,760 And near having you know general purpose WASM machine can can run 1322 01:18:33,760 --> 01:18:35,960 any light client for any blockchain that allows a light 1323 01:18:35,960 --> 01:18:40,680 client and that allows you to have two directional bridges 1324 01:18:41,000 --> 01:18:44,000 that effectively say as long as the light client of both chains 1325 01:18:44,000 --> 01:18:45,760 is not compromised. And light clients are very hard 1326 01:18:45,760 --> 01:18:48,760 to compromise despite the term light client like you know 1327 01:18:48,880 --> 01:18:49,840 compromising. In the theorem. 1328 01:18:49,840 --> 01:18:51,400 Light client or near light client is. 1329 01:18:52,160 --> 01:18:53,760 Extremely hard. Right. 1330 01:18:53,760 --> 01:18:56,040 And so then you say, well for as long as those are not corrupted, 1331 01:18:56,040 --> 01:18:59,760 Near is also part of the bigger ecosystem of of more. 1332 01:18:59,760 --> 01:19:04,120 Chains. So I guess. 1333 01:19:04,120 --> 01:19:08,440 Like every creator, when they make something, they end up 1334 01:19:08,440 --> 01:19:11,800 having like there's usually certain element of the system 1335 01:19:11,800 --> 01:19:16,520 that they wished was better. And then do you have those? 1336 01:19:16,520 --> 01:19:19,120 Like what? What for you individually? 1337 01:19:19,120 --> 01:19:23,520 What parts of Near are you kind of unsatisfied about in the 1338 01:19:23,520 --> 01:19:27,320 design? What I mean, there's few things 1339 01:19:27,320 --> 01:19:29,160 that we're still. Finishing up or like. 1340 01:19:29,320 --> 01:19:31,440 And and still on the road, I think. 1341 01:19:32,120 --> 01:19:34,000 So we mentioned dynamically sharding, right. 1342 01:19:34,000 --> 01:19:38,080 So right now as Alex mentioned, right, this is more of a kind of 1343 01:19:38,080 --> 01:19:40,440 a governance, technical governance process. 1344 01:19:41,080 --> 01:19:44,440 But the benefit with the stateless validation approach is 1345 01:19:44,440 --> 01:19:47,720 that because we rotate validators, you know, every 1346 01:19:47,720 --> 01:19:51,440 second, now you can actually change the number of shards for 1347 01:19:51,440 --> 01:19:54,960 validators very quickly, right? Because they they again, they 1348 01:19:54,960 --> 01:19:57,160 don't really care how many shards in the network, they 1349 01:19:57,160 --> 01:19:59,280 don't care which Shard, they just received the block. 1350 01:20:00,160 --> 01:20:01,640 And so the benefit? Here if. 1351 01:20:01,640 --> 01:20:05,400 We have sufficient kind of redundancy on chunk producers. 1352 01:20:06,120 --> 01:20:10,400 We can split the chunk producer group and say like you know as 1353 01:20:10,400 --> 01:20:15,080 of next block you don't care about half of the chart that you 1354 01:20:15,080 --> 01:20:18,840 were in, right. So comparative you know to to 1355 01:20:19,200 --> 01:20:22,560 where we are now, where we need to like everybody agrees you 1356 01:20:22,560 --> 01:20:25,280 know new client has been drawn, validators spit it up. 1357 01:20:25,640 --> 01:20:28,400 You know, this shortly happens, this can happen literally 1358 01:20:28,400 --> 01:20:31,800 instantly where everything like, OK, now we split into two 1359 01:20:31,800 --> 01:20:34,040 shards, you know, now I'm ignoring just half of the 1360 01:20:34,040 --> 01:20:36,560 transactions at that and they still receive because people are 1361 01:20:36,560 --> 01:20:40,160 still routing to me and I'm just processing this half And then on 1362 01:20:40,160 --> 01:20:43,160 the junk produce production side and then on the valid side, you 1363 01:20:43,160 --> 01:20:47,040 know, now you're just assigning. Yeah, sampling just from a 1364 01:20:47,040 --> 01:20:48,840 different for the listener, this is the. 1365 01:20:48,840 --> 01:20:52,240 Cell tower splitting into two dynamically, or the post office 1366 01:20:52,240 --> 01:20:55,040 splitting into two exactly and this can happen. 1367 01:20:55,040 --> 01:20:59,720 Like immediately, right, which is you know huge, huge benefit 1368 01:20:59,720 --> 01:21:03,400 for the spike in usage where you know sub applications just went 1369 01:21:03,680 --> 01:21:06,880 you know viral and esteem and or you know talking claim or 1370 01:21:06,880 --> 01:21:09,920 whatever and you can like hey let's just pull it out into a 1371 01:21:09,920 --> 01:21:13,720 separate Shard let it you know go nuts and then maybe merge it 1372 01:21:13,720 --> 01:21:18,760 back in like a day or so. So that that's that's you know 1373 01:21:19,000 --> 01:21:23,320 definitely huge kind of benefit of debt and and for context I 1374 01:21:23,320 --> 01:21:26,640 mean status validation is something we published in 1375 01:21:26,640 --> 01:21:31,120 February and I mean been building last year and should be 1376 01:21:31,120 --> 01:21:34,120 launching within the next few months and then we're going to 1377 01:21:34,120 --> 01:21:36,800 start working on dynamically sharded now. 1378 01:21:37,240 --> 01:21:38,440 From my. Perspective. 1379 01:21:39,080 --> 01:21:42,720 There is a few. Few things that. 1380 01:21:43,480 --> 01:21:47,520 Beyond that that would be that's what we should be working on. 1381 01:21:47,800 --> 01:21:51,320 One is and and now Alex actually worked on some designs for this 1382 01:21:51,360 --> 01:21:55,280 earlier is needless check production. 1383 01:21:55,720 --> 01:22:00,800 So right now there's one chunk producer at a time that is 1384 01:22:00,840 --> 01:22:02,920 responsible for producing chunk right. 1385 01:22:03,600 --> 01:22:06,480 And I mean they kind of rotate and they randomly assign, but 1386 01:22:06,480 --> 01:22:11,200 still you know if that chunk producer is offline now we have 1387 01:22:11,200 --> 01:22:14,680 a gap on that time slot. And you know when you drop in 1388 01:22:14,680 --> 01:22:17,600 GPS you have you know high latency with the users. 1389 01:22:18,400 --> 01:22:20,840 And so the idea definitely is they can also be. 1390 01:22:20,840 --> 01:22:24,560 They can also be deduced. Which is, yeah. 1391 01:22:24,720 --> 01:22:26,600 Something that happens on other networks right now? 1392 01:22:26,600 --> 01:22:29,520 Not not. Not because we sound. 1393 01:22:29,560 --> 01:22:32,920 Resilient to that in Just bad Guys shows another network to to 1394 01:22:32,920 --> 01:22:35,600 do those, not ours, but it can happen eventually, right? 1395 01:22:35,600 --> 01:22:37,560 So also leaderless chunk production consensus is 1396 01:22:37,560 --> 01:22:41,440 something we need to implement and then we have a a a pretty 1397 01:22:41,440 --> 01:22:46,760 clear way of achieving it. So leading by leading. 1398 01:22:46,760 --> 01:22:51,560 This chunk production SO when you say that I'm kind of like 1399 01:22:51,560 --> 01:22:57,920 reminded of algorand where where the the essential idea is like. 1400 01:22:58,080 --> 01:23:00,680 When you think of a network. Like like you when you think of 1401 01:23:00,680 --> 01:23:03,960 like a Cosmos network, the block chains rolling. 1402 01:23:03,960 --> 01:23:06,120 Along. And blocks have been produced. 1403 01:23:06,880 --> 01:23:11,760 Everybody knows who should be producing block n + 1, right? 1404 01:23:11,760 --> 01:23:16,840 It's publicly known. And if they fail to produce, the 1405 01:23:16,840 --> 01:23:21,160 network waits and then. Realizes fails to produce. 1406 01:23:21,160 --> 01:23:24,160 And then the network also knows if that guy fails to produce the 1407 01:23:24,160 --> 01:23:27,080 block, then this other guy should produce the block. 1408 01:23:27,800 --> 01:23:31,960 And there's kind of like a almost a line, a queue made of 1409 01:23:31,960 --> 01:23:36,240 like who has rights to produce. And so that's only what you mean 1410 01:23:36,240 --> 01:23:40,320 when you were saying leader. So if you have a Shard, you have 1411 01:23:40,320 --> 01:23:43,640 a multiple validate like multiple chunk producers, but 1412 01:23:43,640 --> 01:23:46,680 which one exactly produces the chunk for this block? 1413 01:23:47,600 --> 01:23:48,960 It's currently. Known. 1414 01:23:49,400 --> 01:23:53,480 In near just like Cosmos, but what you would like is a system 1415 01:23:53,480 --> 01:24:00,200 where there are N chunk producers and then when a. 1416 01:24:00,200 --> 01:24:03,240 Certain block rolls along. One of the chunk producer 1417 01:24:03,240 --> 01:24:06,640 realizes they have some. Kind of winning. 1418 01:24:06,640 --> 01:24:09,520 Lottery ticket and they can produce the chunks. 1419 01:24:09,520 --> 01:24:12,000 So this is no, this is not so you're explaining algorithm. 1420 01:24:12,400 --> 01:24:14,520 And it is not. I'm explaining algorithm, so is, 1421 01:24:14,520 --> 01:24:16,840 is. Is that division for lead now? 1422 01:24:16,840 --> 01:24:17,880 There's still a leader in what you? 1423 01:24:17,880 --> 01:24:19,960 Explain. So the only difference is that 1424 01:24:19,960 --> 01:24:22,200 the leader is not known in advance, right. 1425 01:24:22,200 --> 01:24:24,640 So partially solves the problem. It's much harder to give those. 1426 01:24:24,640 --> 01:24:26,840 For example, you cannot give those someone you don't know, 1427 01:24:27,080 --> 01:24:29,480 right. And so by the time you know that 1428 01:24:29,480 --> 01:24:33,800 they won the lottery ticket and we actually do the the way we 1429 01:24:33,800 --> 01:24:36,680 think of it is similar. So an algorithm, you actually 1430 01:24:36,680 --> 01:24:38,920 don't know in advance that you won a lottery ticket. 1431 01:24:39,160 --> 01:24:42,520 You, you know like like a fact. What happens is that everybody 1432 01:24:42,600 --> 01:24:45,320 looks at their lottery ticket and sees the number, and the 1433 01:24:45,320 --> 01:24:47,520 highest number wins. But you don't know if you have 1434 01:24:47,520 --> 01:24:49,760 the highest number because you don't know the numbers of 1435 01:24:49,760 --> 01:24:52,400 others. If you did and others did, then 1436 01:24:52,400 --> 01:24:53,640 it would be no different from Cosmos. 1437 01:24:53,640 --> 01:24:55,480 Then everybody would know, right? 1438 01:24:55,640 --> 01:24:59,040 So instead you say, well, I have a sufficiently high number for 1439 01:24:59,040 --> 01:25:00,560 me to believe that I might be the winner. 1440 01:25:00,560 --> 01:25:03,800 So I will produce the block. I will publish it, maybe someone 1441 01:25:03,800 --> 01:25:06,120 else will publish. And you know, given my number 1442 01:25:06,120 --> 01:25:10,320 was 97 out of 100, there's a good chance that I was the 1443 01:25:10,320 --> 01:25:12,480 highest, right? But maybe there was 98. 1444 01:25:12,960 --> 01:25:16,600 This approach has a has a minor problem that still multiple 1445 01:25:16,600 --> 01:25:18,640 blocks will have to be broadcast, right? 1446 01:25:18,640 --> 01:25:21,840 Because like effectively either the threshold is too high that 1447 01:25:21,840 --> 01:25:24,320 every now and then nobody will broadcast a block because nobody 1448 01:25:24,320 --> 01:25:25,920 want the ticket above a certain threshold. 1449 01:25:25,920 --> 01:25:29,120 Or it's like sufficiently low that multiple blocks will do the 1450 01:25:29,120 --> 01:25:32,360 broadcast but in our. But in our case, something 1451 01:25:32,360 --> 01:25:36,160 interesting to think about is that at the end of the day, the 1452 01:25:36,240 --> 01:25:40,160 chunk will be broadcast to everybody like a little part of 1453 01:25:40,160 --> 01:25:42,600 it, right? And so everybody will have to 1454 01:25:42,600 --> 01:25:44,360 receive. But within the network, within 1455 01:25:44,360 --> 01:25:48,000 the, within the set of the chunk producers, what they can do, 1456 01:25:48,400 --> 01:25:51,520 they will have to send the chunk in its entirety for validation 1457 01:25:51,520 --> 01:25:54,560 or like with with the validators of the of the chart, right. 1458 01:25:54,800 --> 01:25:58,680 So you can think of a system where on the high level what 1459 01:25:58,680 --> 01:26:01,840 happens is that every single chunk producer generates a 1460 01:26:01,840 --> 01:26:04,520 chunk, not just some people who who are beyond certain 1461 01:26:04,520 --> 01:26:06,960 threshold. Everybody produces A chunk and 1462 01:26:06,960 --> 01:26:10,000 then everybody stands to every person in the Shard. 1463 01:26:10,080 --> 01:26:14,200 So like every chunk producer every you know, like eraser 1464 01:26:14,200 --> 01:26:16,120 coded part. And so at the end of the day the 1465 01:26:16,120 --> 01:26:19,240 network overhead is not chunk size times number of 1466 01:26:19,240 --> 01:26:22,120 participants, It's still proportional to the chunk size, 1467 01:26:22,640 --> 01:26:25,720 right? But but now every but now you 1468 01:26:25,720 --> 01:26:28,760 have as many chances, you have chunk producers and then you 1469 01:26:28,760 --> 01:26:30,960 still do the lottery ticket. Then you review your lottery 1470 01:26:30,960 --> 01:26:34,080 ticket and if you want your chunk is is accepted right? 1471 01:26:34,080 --> 01:26:38,000 But there's no issue with the choosing the threshold and they 1472 01:26:38,000 --> 01:26:40,200 be spending the network with multiple chunks that have to be 1473 01:26:40,200 --> 01:26:42,880 exchanged in its entire team. So that's the high level idea, 1474 01:26:42,880 --> 01:26:44,280 right? But the high level idea is that 1475 01:26:44,280 --> 01:26:49,600 now you can literally never a chunk will be skipped, no matter 1476 01:26:49,720 --> 01:26:51,760 you know, like as long as there's one person you didn't 1477 01:26:51,760 --> 01:26:53,120 do, the chunk will not be skipped. 1478 01:26:53,120 --> 01:26:57,280 And it's, it's a slightly, slightly improvement. 1479 01:26:57,280 --> 01:26:59,840 Over. An AL grant idea where you, you 1480 01:26:59,840 --> 01:27:02,920 know, have a threshold and but still exchange the whole block. 1481 01:27:04,640 --> 01:27:06,800 Yeah, this is really. This is really. 1482 01:27:06,800 --> 01:27:09,400 Fascinating. So I think the essence of the 1483 01:27:09,400 --> 01:27:13,640 design being that. In Bitcoin or in? 1484 01:27:13,640 --> 01:27:16,960 Ethereum When When I? Have a block. 1485 01:27:17,960 --> 01:27:19,280 I have to forward. That. 1486 01:27:19,280 --> 01:27:25,200 Entire block to everybody, and there's a certain like diameter 1487 01:27:25,200 --> 01:27:27,360 of the network. So I'm a validator and there's 1488 01:27:27,360 --> 01:27:30,280 some validator to which I have the worst connection, like 1489 01:27:30,400 --> 01:27:35,440 there's multiple hops and that entire block must be now sent 1490 01:27:36,120 --> 01:27:38,920 across the diameter of the other side to that worst other 1491 01:27:38,920 --> 01:27:43,080 validator. But in near almost, it's like I 1492 01:27:43,080 --> 01:27:47,400 have a more efficient. Microphone or. 1493 01:27:47,400 --> 01:27:50,560 Megaphones I produce the block I. 1494 01:27:50,560 --> 01:27:53,600 Cut it into lots of pieces. And I only have need to send the 1495 01:27:53,600 --> 01:27:57,280 small pieces to all of the validator. 1496 01:27:57,280 --> 01:28:00,200 So there's some validator to which I have the worst 1497 01:28:00,200 --> 01:28:05,040 connection, but I only have to send a small piece to through 1498 01:28:05,040 --> 01:28:06,040 that. Worst. 1499 01:28:06,360 --> 01:28:10,200 Connection through that diameter of the network and because of. 1500 01:28:10,200 --> 01:28:12,400 That because. Because like this, this 1501 01:28:12,400 --> 01:28:16,200 broadcast of is only piece piece wise and this broadcast is kind 1502 01:28:16,200 --> 01:28:19,280 of like efficient. You can afford to have a design 1503 01:28:19,280 --> 01:28:24,400 where in a Shard, all of the chunk producers produce a block. 1504 01:28:24,680 --> 01:28:26,840 They broadcast their pieces and like. 1505 01:28:26,840 --> 01:28:31,000 Then they compare OK, which of these pieces has some highest 1506 01:28:31,000 --> 01:28:34,160 amount of randomness and that becomes like the canonical chunk 1507 01:28:34,680 --> 01:28:37,720 for for that block. Yes, yes, that be a. 1508 01:28:37,720 --> 01:28:40,040 Chunk of the block, Yeah. And it's like depending like 1509 01:28:40,080 --> 01:28:43,200 that person I have the worst connection to depending on why 1510 01:28:43,200 --> 01:28:46,080 they need my block, right? If they just the block producer 1511 01:28:46,200 --> 01:28:50,960 and they just need to to sign off, it's sufficient for them to 1512 01:28:50,960 --> 01:28:53,560 have just that little piece. We don't need to reconstruct the 1513 01:28:53,560 --> 01:28:57,040 block or a chunk. But if they do need the whole 1514 01:28:57,040 --> 01:28:59,920 chunk, it's still more performing than sending a whole 1515 01:28:59,920 --> 01:29:03,400 chunk to some, right? Like I sent little pieces and 1516 01:29:03,400 --> 01:29:05,880 then that person will collect little pieces from different 1517 01:29:06,320 --> 01:29:08,920 entities, right? So it's still a faster way to 1518 01:29:08,920 --> 01:29:13,200 propagate information and and I guess the advantage here for us 1519 01:29:13,200 --> 01:29:15,680 in building that leaderless consensus, sorry, leaderless 1520 01:29:15,680 --> 01:29:18,480 chunk production is that we already have a concept of this 1521 01:29:18,480 --> 01:29:21,200 erasure code, right? We already sent small pieces, we 1522 01:29:21,200 --> 01:29:24,600 already have the mechanic to gather them, right? 1523 01:29:24,600 --> 01:29:29,000 So that's it's much less invasive change. 1524 01:29:29,560 --> 01:29:33,360 Therefore, a network where today blocks are being sent fully 1525 01:29:33,640 --> 01:29:35,480 right, so for them to implement the same feature would be 1526 01:29:35,480 --> 01:29:38,240 implementing a lot of new mechanics. 1527 01:29:38,240 --> 01:29:40,000 Well, in our. Case it's just plugging into 1528 01:29:40,000 --> 01:29:45,000 existing machinery I I wanted. To touch, So you asked. 1529 01:29:45,000 --> 01:29:46,880 A question which I think is interesting and and nearly 1530 01:29:46,880 --> 01:29:51,360 covered it from a very different perspective of sort of, you 1531 01:29:51,360 --> 01:29:55,280 know, a. Something that. 1532 01:29:55,960 --> 01:29:59,640 Design wise is not great and we would like it to be different. 1533 01:29:59,840 --> 01:30:03,160 I I think something I thought a lot from the day we launched 1534 01:30:03,160 --> 01:30:05,400 near is that the accounting model for sharding is quite 1535 01:30:05,400 --> 01:30:09,040 different, right. Like you cannot have like flash 1536 01:30:09,040 --> 01:30:12,840 loans for example easily because accounts on. 1537 01:30:12,840 --> 01:30:14,560 Different. Shards and everything takes a 1538 01:30:14,560 --> 01:30:16,680 hope, right? And we've been trying to solve 1539 01:30:16,680 --> 01:30:19,080 this problem like we were trying to find a way to have atomic 1540 01:30:19,080 --> 01:30:23,560 transactions since day one with many different designs and it's 1541 01:30:23,560 --> 01:30:27,240 a drawback of sharding. But what's interesting is that I 1542 01:30:27,240 --> 01:30:31,560 think slowly we're coming to to realisation that long term not 1543 01:30:31,560 --> 01:30:33,760 having sharding is not an option, right. 1544 01:30:33,760 --> 01:30:36,920 So in essence the highest throughput block chains today 1545 01:30:36,920 --> 01:30:40,080 which are not sharded are getting congested and that it's 1546 01:30:40,080 --> 01:30:41,920 only that much they can squeeze more, right? 1547 01:30:41,920 --> 01:30:45,360 Like they they work day and night to remove all the sub 1548 01:30:45,360 --> 01:30:48,440 optimalities, but at best they will squeeze out another 20%, 1549 01:30:48,440 --> 01:30:50,520 right? Let's say 50% that will get 1550 01:30:50,520 --> 01:30:53,680 congested again like that optional blockchain today is a 1551 01:30:53,680 --> 01:30:57,280 fraction of what we want it to be to consider the whole 1552 01:30:57,280 --> 01:30:58,760 ecosystem to be successful, right? 1553 01:30:58,760 --> 01:31:00,440 And so sharding will have to happen. 1554 01:31:00,800 --> 01:31:04,360 And when sharding has to happen, people will have to deal with 1555 01:31:04,360 --> 01:31:07,920 this disadvantage of of this different account model. 1556 01:31:08,080 --> 01:31:11,320 And so Near in this case is positioned extremely well 1557 01:31:11,320 --> 01:31:14,680 because from day one every application near was built with 1558 01:31:14,680 --> 01:31:16,520 that account model in mind, right? 1559 01:31:16,520 --> 01:31:19,600 So we have tools, we have understanding developers in the 1560 01:31:19,600 --> 01:31:22,600 ecosystem are used to working in this set up, right? 1561 01:31:22,840 --> 01:31:25,200 While in the rest of the ecosystem people are still 1562 01:31:25,200 --> 01:31:28,720 operating in this atomic transactions mindset which they 1563 01:31:28,720 --> 01:31:32,760 will have to abandon eventually. Because at some point if their 1564 01:31:32,760 --> 01:31:37,080 application is to scale and applications they depend upon 1565 01:31:37,400 --> 01:31:40,600 are to scale, they will not be able to maintain this atomic 1566 01:31:41,160 --> 01:31:43,880 guarantees and scale to the user tried. 1567 01:31:43,880 --> 01:31:47,120 So they will have to abandon this mindset and we're 1568 01:31:47,120 --> 01:31:50,280 positioned uniquely in the sense that everything that is built on 1569 01:31:50,280 --> 01:31:53,680 Near this, you know, reach ecosystem applications is built 1570 01:31:54,400 --> 01:31:57,280 in the future proof way. You know, as we create more 1571 01:31:57,280 --> 01:32:00,360 charts, every application in Near gets to take advantage of 1572 01:32:00,360 --> 01:32:06,480 that, while for any application that is built on, you know what 1573 01:32:06,480 --> 01:32:09,560 we call synchronous. Runtime. 1574 01:32:09,720 --> 01:32:15,520 Then then they will have to to do right their applications I I. 1575 01:32:15,520 --> 01:32:16,640 Think that that actually the really. 1576 01:32:16,640 --> 01:32:20,560 Interesting part is because near is kind of a synchronous in in 1577 01:32:20,560 --> 01:32:23,920 the way every contract, every account and every contract is 1578 01:32:23,920 --> 01:32:28,480 designed to be independent. It actually doesn't. 1579 01:32:28,480 --> 01:32:31,520 Matter if that. Account is on near or not and so 1580 01:32:31,520 --> 01:32:35,880 that's why kind of a lot of the chain kind of abstraction ideas 1581 01:32:35,880 --> 01:32:39,760 becoming because well it. Actually doesn't matter for like 1582 01:32:39,760 --> 01:32:42,280 for. REST finance like an AML on near 1583 01:32:42,560 --> 01:32:46,360 doesn't matter, the token is a year on the stadium and based on 1584 01:32:46,360 --> 01:32:51,640 Salina like you can actually deposit any token and the rest 1585 01:32:51,640 --> 01:32:55,240 side answers will be able to handle it and so. 1586 01:32:56,120 --> 01:32:58,880 So like generally speaking nearest design with every like 1587 01:32:58,880 --> 01:33:03,680 every contract, every account is kind of handling assets that are 1588 01:33:03,680 --> 01:33:07,440 living on like in a synchronous way, right. 1589 01:33:07,440 --> 01:33:11,280 And obviously it's good to have them on near because you get 1590 01:33:11,280 --> 01:33:13,440 like one second communication time. 1591 01:33:13,440 --> 01:33:17,040 So like the latency is very low and you know that counts faces 1592 01:33:17,120 --> 01:33:21,720 is nice but it can be living somewhere else and it's like if 1593 01:33:21,720 --> 01:33:25,840 we have kind of a message passing way of sending this then 1594 01:33:25,840 --> 01:33:28,920 you know near smart contracts know how to deal with that And 1595 01:33:28,920 --> 01:33:32,520 all our standards like here C20 on analogous standard is 1596 01:33:32,520 --> 01:33:36,000 designed with school backs and kind of that's the passing mind. 1597 01:33:36,520 --> 01:33:40,440 And so again like compared to right now in the VMS they tried 1598 01:33:40,440 --> 01:33:43,320 to figure out how to do cross layer two communication. 1599 01:33:43,560 --> 01:33:46,280 The challenge is really lies and like all of the standards. 1600 01:33:46,280 --> 01:33:49,240 So I can imagine trying to say there's a 20 from 1 chain to 1601 01:33:49,240 --> 01:33:53,480 another like there's no standard address space or anything that 1602 01:33:53,480 --> 01:33:55,480 supports that. It's also synchronous like 1603 01:33:55,480 --> 01:33:58,160 expectation is that that transaction will execute same 1604 01:33:58,160 --> 01:34:01,560 block but actually it needs to you know be scheduled, message 1605 01:34:01,560 --> 01:34:05,680 passed settled, you know send somewhere else that revalidate 1606 01:34:05,680 --> 01:34:08,640 etcetera. So, so really that's kind of the 1607 01:34:09,360 --> 01:34:12,440 IT it, it was a very non trivial trade off, right. 1608 01:34:12,440 --> 01:34:16,840 And and we kind of I would say had a had a period of time where 1609 01:34:16,840 --> 01:34:23,200 we're like did we do a right trade off kind of but but right 1610 01:34:23,200 --> 01:34:26,520 now yeah we're seeing like we're literally seeing the validation 1611 01:34:26,520 --> 01:34:29,600 of our pieces kind of throughout, yeah. 1612 01:34:29,600 --> 01:34:30,920 So. The point being like something. 1613 01:34:30,920 --> 01:34:36,240 Like Flash loan where in the near design it's hard it's not 1614 01:34:36,240 --> 01:34:38,840 that flash yeah. It's not like Iron Man Low. 1615 01:34:39,000 --> 01:34:41,720 Yeah, yeah, it's. Not that flash. 1616 01:34:41,720 --> 01:34:45,440 So at some point in 2021 or something like that, it must 1617 01:34:45,440 --> 01:34:48,760 have seemed that, oh, Ethereum has flash nodes but near wooden 1618 01:34:49,160 --> 01:34:52,040 and that's a problem or is it perceived? 1619 01:34:52,040 --> 01:34:54,720 Problem. But when you look at like 1620 01:34:54,720 --> 01:34:59,000 Ethereum in 2028, which is Ethereum plus all of these L 1621 01:34:59,000 --> 01:35:02,600 twos and L threes, you can't have flashlights across their 1622 01:35:02,600 --> 01:35:05,880 entire ecosystem and you can't have flashlights across near. 1623 01:35:06,480 --> 01:35:13,760 So it's fine like like it's a. It's a downside, but not really 1624 01:35:14,320 --> 01:35:18,960 exactly like the modern. G 5/20/28 will be what what 1625 01:35:18,960 --> 01:35:24,120 people been building G5 near the past 2-3 years and as Ilya 1626 01:35:24,120 --> 01:35:27,040 mentioned, this entire. Ecosystem of L2's and L3's will 1627 01:35:27,040 --> 01:35:30,240 also be part of near ecosystem because because of chain 1628 01:35:30,240 --> 01:35:34,320 obstruction, right? Any account on any chain can be, 1629 01:35:34,720 --> 01:35:38,560 you know, with a very thin abstraction layer perceived as a 1630 01:35:38,560 --> 01:35:42,240 near account, just with a higher latency, right? 1631 01:35:42,880 --> 01:35:44,360 So so like a near account to near. 1632 01:35:44,360 --> 01:35:47,880 Account will be one second always but near account to 1633 01:35:47,880 --> 01:35:49,880 optimism account. It's going to be exactly the 1634 01:35:49,880 --> 01:35:52,760 same protocol on near site, but the latency will be higher 1635 01:35:52,760 --> 01:35:55,480 because there's communication between them. 1636 01:35:56,360 --> 01:35:58,360 Yeah, I'm not going to chain abstraction. 1637 01:35:58,360 --> 01:36:02,200 Because I feel like we've already covered so much, and I 1638 01:36:02,200 --> 01:36:05,400 did cover chain abstraction with in the previous episode with 1639 01:36:05,400 --> 01:36:09,720 Ilia. So I mean avoiding that because 1640 01:36:11,600 --> 01:36:13,840 things things start to become only too complex. 1641 01:36:14,640 --> 01:36:16,440 Curious listener? Can Google near chain? 1642 01:36:16,440 --> 01:36:19,040 Abstraction. Yeah, I I just. 1643 01:36:19,040 --> 01:36:21,880 Wanted to to to give an understanding why like like 1644 01:36:21,880 --> 01:36:23,800 chain obstruction didn't come from nowhere. 1645 01:36:23,920 --> 01:36:27,080 Chain obstruction was the mentality we took was near when 1646 01:36:27,120 --> 01:36:30,800 we designed near it's just like now we expanded that to kind of 1647 01:36:30,920 --> 01:36:35,600 all chains but it's still kind of you know the sinking we put 1648 01:36:35,600 --> 01:36:37,880 in into designing near is still there. 1649 01:36:38,840 --> 01:36:42,680 Now how do we apply it to the whole that three again assume 1650 01:36:42,680 --> 01:36:45,560 like you can think of the optimism just being another 1651 01:36:45,560 --> 01:36:49,000 Shard of near and this is where actually like you know for 1652 01:36:49,000 --> 01:36:54,320 example ZK proofs it and Aglayer what Aliga is working on is all 1653 01:36:54,320 --> 01:36:58,160 coming together because like if we can unify security if we can 1654 01:36:58,440 --> 01:37:03,920 kind of provide kind of common security layer then on top of 1655 01:37:03,920 --> 01:37:05,400 this you know and. Again, we have. 1656 01:37:05,400 --> 01:37:09,480 Near DA, we can actually settle DA of other layer twos. 1657 01:37:09,960 --> 01:37:14,080 Well, now they're actually not that different from other shards 1658 01:37:14,080 --> 01:37:16,280 of near. I mean there's differences in 1659 01:37:16,280 --> 01:37:19,800 sequencing and production. And so like there's things to 1660 01:37:19,800 --> 01:37:23,240 handle under the hood. But again we can kind of extend 1661 01:37:23,240 --> 01:37:26,440 our layer of abstraction that we provide to users and developers 1662 01:37:26,760 --> 01:37:30,080 to kind of cover up that and say like actually you know if 1663 01:37:30,080 --> 01:37:32,120 there's decay proofs and data availability, we can actually 1664 01:37:32,120 --> 01:37:35,520 like say security is the same and now we can message pass and 1665 01:37:35,520 --> 01:37:39,040 we can do gather species this way and so. 1666 01:37:39,360 --> 01:37:41,920 So that's kind of the idea is like you know how do we, how do 1667 01:37:41,920 --> 01:37:46,840 I apply the same methodology and and kind of user experience, 1668 01:37:46,840 --> 01:37:51,440 developer experience but but then expanded back more to the 1669 01:37:51,440 --> 01:37:55,840 rest of it 3. So like from. 1670 01:37:55,840 --> 01:38:00,840 My perspective, you know when I look at like Ethereum Ethereum's 1671 01:38:00,840 --> 01:38:04,400 road map and then like the near and near road map, one of the 1672 01:38:04,400 --> 01:38:09,320 things that stands out to me is in Ethereum the road map is 1673 01:38:09,320 --> 01:38:12,880 based on like scaling where these L twos and L threes. 1674 01:38:13,280 --> 01:38:19,360 But the relationship between ether, the asset and the core 1675 01:38:19,360 --> 01:38:25,480 asset of the L2 can be synergistic in at times but it 1676 01:38:25,960 --> 01:38:29,240 it can be non synergistic at other times right Like so. 1677 01:38:30,120 --> 01:38:34,520 So it's like the L2 pays the main Ethereum chain for certain 1678 01:38:34,520 --> 01:38:38,920 services and the service intended is usually data 1679 01:38:38,920 --> 01:38:43,680 availability. But it can be the case that the 1680 01:38:43,720 --> 01:38:48,640 L2 generates 100 million in fees, but it only pays 500,000 1681 01:38:48,800 --> 01:38:53,920 in fees to the main chain. It's this this relationship. 1682 01:38:53,920 --> 01:38:59,280 Is kind of like great if the L2 is kind of building a. 1683 01:38:59,280 --> 01:39:01,760 Completely new. Market that Ethereum never had 1684 01:39:01,760 --> 01:39:03,000 right? Like imagined? 1685 01:39:03,000 --> 01:39:07,280 I don't know, some some AI decentralized app comes and the 1686 01:39:07,280 --> 01:39:11,320 L to capitalize on it built it. They got 100 million in 1687 01:39:11,320 --> 01:39:14,120 transaction fees and paid 500,000 to Etherium main chain. 1688 01:39:14,120 --> 01:39:16,800 It's great for the Etherium main chain because there's a new 1689 01:39:16,800 --> 01:39:20,000 revenue stream coming. It went 500,000 but it's new. 1690 01:39:20,640 --> 01:39:25,840 The interesting case becomes when some app that was massive 1691 01:39:25,880 --> 01:39:28,400 like that's like massively popular on the Etherium main 1692 01:39:28,400 --> 01:39:34,240 chain generating millions in fees ends up thinking it's 1693 01:39:34,240 --> 01:39:38,960 better I migrate to that L2. And so they might be making like 1694 01:39:38,960 --> 01:39:41,720 10 million in fees on the main chain and then they migrate to 1695 01:39:41,720 --> 01:39:45,800 the L2 and then the fees get cut to a million and then Ethereum's 1696 01:39:45,800 --> 01:39:50,160 only making 100,000 on it. So, so it was making 10 million 1697 01:39:50,160 --> 01:39:54,840 in fees and now it's only making 100,000 in fees because the 1698 01:39:54,840 --> 01:39:56,400 L2's. Ecosystem exists. 1699 01:39:56,800 --> 01:40:00,760 And they're kind of like the relationship is well from the 1700 01:40:00,760 --> 01:40:03,560 Ethereum ether holders perspective. 1701 01:40:04,440 --> 01:40:08,080 That isn't so ideal, right? Because you're you're losing 1702 01:40:08,600 --> 01:40:12,000 adapt that might have been cultivated by these EM network 1703 01:40:12,000 --> 01:40:14,880 over years and then now it's kind of like migrated away. 1704 01:40:15,160 --> 01:40:17,480 And in practice this has happened with something like 1705 01:40:17,480 --> 01:40:20,520 DYDX. But what's really cool about 1706 01:40:20,520 --> 01:40:26,320 near is like this sort of system doesn't exist like the shards. 1707 01:40:26,520 --> 01:40:29,960 Like the relationship between like, near and the shards is 1708 01:40:29,960 --> 01:40:32,840 kind of the near token. Kind of like. 1709 01:40:33,480 --> 01:40:38,480 All the revenues made by all shards and kind of there is not 1710 01:40:39,560 --> 01:40:41,120 in order to. Scale it. 1711 01:40:41,120 --> 01:40:45,520 Doesn't need to have these complex economic James be 1712 01:40:45,520 --> 01:40:50,000 present between kind of. Like a main chain. 1713 01:40:50,000 --> 01:40:53,920 And an execution layer which is very much there in Ethereum, and 1714 01:40:53,920 --> 01:40:57,320 I believe that this will be, this will become a relevant 1715 01:40:57,320 --> 01:41:01,200 feature of Ethereum's ecosystem. Politics in the. 1716 01:41:01,200 --> 01:41:04,680 Future and NIA will just not have any of it. 1717 01:41:05,920 --> 01:41:07,560 Cool. So yeah. 1718 01:41:07,560 --> 01:41:11,960 I guess we can we can keep it at that and it was it was great to 1719 01:41:11,960 --> 01:41:17,360 have both of you on the podcast. Maybe we should have. 1720 01:41:17,360 --> 01:41:22,520 Another one to discuss on how Alex is planning to use recent 1721 01:41:22,520 --> 01:41:25,680 developments in the AI technology and what he's 1722 01:41:25,680 --> 01:41:29,160 building there. I was going to say that it's not 1723 01:41:29,160 --> 01:41:31,760 a coincidence. That AI stands for Alex Amelia. 1724 01:41:33,800 --> 01:41:34,480 Yeah. I mean, thanks. 1725 01:41:34,480 --> 01:41:36,600 Thanks for having us. Obviously this is a highly 1726 01:41:36,600 --> 01:41:41,040 technical topic that I think it's it's been really hard to 1727 01:41:41,040 --> 01:41:43,760 explain in general. I mean, we've been trying to do 1728 01:41:43,760 --> 01:41:47,680 this for years now, but. There kind of the. 1729 01:41:47,680 --> 01:41:51,920 Core idea is also like it was really hard to prove it out when 1730 01:41:51,920 --> 01:41:55,520 you just launched because when you just launched you don't have 1731 01:41:55,520 --> 01:41:58,440 anything so there's no users. So there's no need for sharding. 1732 01:41:59,000 --> 01:42:02,120 And I think like we was going to have that problem in Web 3 where 1733 01:42:02,560 --> 01:42:07,960 everybody was claiming scale, but until you actually have like 1734 01:42:07,960 --> 01:42:11,920 real world you know, massive user base to actually transact, 1735 01:42:12,400 --> 01:42:16,600 you know, just like a a general improvement was enough. 1736 01:42:17,120 --> 01:42:21,240 And I think only in last probably like 3-6 months we've 1737 01:42:21,240 --> 01:42:26,800 seen you know on near for example kind of multiple kind of 1738 01:42:27,080 --> 01:42:28,440 million user. Applications. 1739 01:42:28,440 --> 01:42:31,520 Launching right near right now somewhere between 1.5 to 2 1740 01:42:31,520 --> 01:42:37,360 million daily active right, which is more than any other 1741 01:42:37,360 --> 01:42:40,480 blockchain right now. We have more transactions 1742 01:42:41,160 --> 01:42:46,080 usually than all layer two combined at least on some days 1743 01:42:46,560 --> 01:42:50,360 and so like that that's kind of where this started to prove out, 1744 01:42:50,360 --> 01:42:54,520 right? And for context, we're still 1745 01:42:54,520 --> 01:42:58,440 under Solana transaction numbers, so Solana counts. 1746 01:42:58,440 --> 01:43:00,680 Solana counts. The consensus transactions. 1747 01:43:00,840 --> 01:43:03,200 So it's. I don't know how we compare. 1748 01:43:03,200 --> 01:43:08,200 To the to the actual member. Yeah, but. 1749 01:43:08,200 --> 01:43:11,160 But generally speaking, yeah. Like we have more data active 1750 01:43:11,160 --> 01:43:16,360 users than Solana and most of the days Tron because Tron is 1751 01:43:16,360 --> 01:43:19,200 kind of second the biggest right out. 1752 01:43:20,000 --> 01:43:23,120 But again like this, this is the point that you know as we 1753 01:43:23,120 --> 01:43:26,320 started to see kind of this growth like we started to see 1754 01:43:26,440 --> 01:43:28,400 you know congestion and sounds of shards. 1755 01:43:28,600 --> 01:43:31,840 And the idea was that, you know, we can just expand capacity 1756 01:43:31,840 --> 01:43:34,560 without increasing fees versus every other blockchain, 1757 01:43:34,560 --> 01:43:38,560 including Tronic chips. Really good example because the 1758 01:43:38,560 --> 01:43:43,400 transaction fees went from being very cheap to actually now being 1759 01:43:43,400 --> 01:43:48,280 like, you know, 30-50 cents for their users even though they are 1760 01:43:48,280 --> 01:43:52,240 running, you know, it was like a small subset of validators, you 1761 01:43:52,240 --> 01:43:54,600 know? A a kind. 1762 01:43:54,600 --> 01:43:58,560 Of modified Indian chain. So I think like that's kind of 1763 01:43:58,560 --> 01:44:00,840 where we're starting to see these things play out. 1764 01:44:00,840 --> 01:44:05,360 And obviously again it took a while right to ecosystem to 1765 01:44:05,360 --> 01:44:09,360 mature the applications to to you know build and launch as 1766 01:44:09,360 --> 01:44:13,200 well As for them to gain users. But now we're starting to see 1767 01:44:13,200 --> 01:44:16,920 this story really playing out and you know on real sweet. 1768 01:44:19,000 --> 01:44:24,680 It's it's exciting and it's also kind of tell now is really good 1769 01:44:24,680 --> 01:44:27,560 time to tell the story and kind of explain how it works. 1770 01:44:28,920 --> 01:44:31,760 Cool. Then I'll catch you again on. 1771 01:44:31,760 --> 01:44:34,120 Epicenter in the end, Alex, thank you. 1772 01:44:34,120 --> 01:44:36,040 Thank you for being there. Thank you. 1773 01:44:36,600 --> 01:44:40,400 Thank you. Thank you for joining us on this 1774 01:44:40,400 --> 01:44:42,800 week's episode. We release new episodes every 1775 01:44:42,800 --> 01:44:44,840 week. You can find and subscribe to 1776 01:44:44,840 --> 01:44:48,600 the show on iTunes, Spotify, YouTube, SoundCloud, or wherever 1777 01:44:48,600 --> 01:44:51,000 you listen to podcasts. And if you have a Google Home or 1778 01:44:51,000 --> 01:44:53,720 Alexa device, you can tell it. To listen to the latest episode 1779 01:44:53,720 --> 01:44:57,800 of the Epicenter podcast, go to epicenter.tv/subscribe for a 1780 01:44:57,800 --> 01:44:59,480 full list of places where you can watch and listen. 1781 01:44:59,480 --> 01:45:02,400 And while you're there, be sure to sign up for the newsletter so 1782 01:45:02,400 --> 01:45:05,680 you get new episodes in your inbox as they're released if you 1783 01:45:05,680 --> 01:45:07,320 want to interact. With us guest. 1784 01:45:07,320 --> 01:45:10,160 Or other podcast listeners, you can follow us on Twitter and 1785 01:45:10,160 --> 01:45:11,520 please leave us a review on iTunes. 1786 01:45:11,520 --> 01:45:14,000 It helps people find the show and we're always happy to read 1787 01:45:14,000 --> 01:45:16,320 them. Well, thanks so much and we look 1788 01:45:16,320 --> 01:45:17,480 forward to being back next week.