1 00:00:00,360 --> 00:00:04,400 This is Epicenter episode 507 with guest Alex Glucovsky. 2 00:00:18,440 --> 00:00:20,360 Welcome to Epicenter, the show which talks about the 3 00:00:20,360 --> 00:00:23,400 technologies, projects, and people driving decentralization 4 00:00:23,400 --> 00:00:26,920 and the blockchain revolution. I'm Brian Crane and I'm here 5 00:00:26,920 --> 00:00:30,460 with Federica Ernst and today we're gonna speak of Alex 6 00:00:30,460 --> 00:00:33,940 Lukrovsky. He is the Co founder and CEO of 7 00:00:33,940 --> 00:00:36,780 Matter Labs. And Matter Labs is the company 8 00:00:36,780 --> 00:00:42,860 that's building ZK Sync, which is one of the most exciting and 9 00:00:43,060 --> 00:00:48,580 sort of largest ZK roll up technologies that's looking to 10 00:00:48,580 --> 00:00:52,070 scale Ethereum by kind of maintaining all the theorems, 11 00:00:52,070 --> 00:00:56,470 trust, assumptions and bring freedom to people all over the 12 00:00:56,470 --> 00:00:57,910 world. So thanks so much for joining 13 00:00:57,910 --> 00:01:00,510 us, Alex. It's my pleasure. 14 00:01:00,710 --> 00:01:05,030 Thank you for having me. So we had your own like three 15 00:01:05,030 --> 00:01:10,590 years ago and a lot has happened since then, including the ZK 16 00:01:10,590 --> 00:01:13,950 space having gotten lots of traction, lots of interest. 17 00:01:13,950 --> 00:01:17,830 It's still an area that's, you know, hard for a lot of people 18 00:01:17,830 --> 00:01:20,590 to sort of understand and wrap their head around, even people 19 00:01:20,590 --> 00:01:23,310 working crypto. So I thought maybe we can start 20 00:01:23,310 --> 00:01:29,030 with just a very brief recap of what are ZK rollups and why is 21 00:01:29,030 --> 00:01:33,550 ZK such a great technology to scale blockchains? 22 00:01:35,390 --> 00:01:37,030 Absolutely. Let me try it so with 23 00:01:37,190 --> 00:01:41,670 blockchains. You know, like the we really 24 00:01:41,670 --> 00:01:43,910 observe the revolution the the cost. 25 00:01:43,910 --> 00:01:46,790 Starting with Bitcoin and the theory I'm taking it to the next 26 00:01:46,790 --> 00:01:50,110 level smart contacts and all the programmability of money, 27 00:01:50,790 --> 00:01:55,630 interactions value. Like really this is to me, it's 28 00:01:55,630 --> 00:01:58,550 the continuation of the Internet revolution but it's a quantum 29 00:01:58,550 --> 00:02:01,270 lip. It's a jump from Web 2.0 to web 30 00:02:01,270 --> 00:02:05,790 3.0, like adding value to the Internet on transaction level. 31 00:02:06,970 --> 00:02:12,610 The problem is that the very same properties that make things 32 00:02:12,610 --> 00:02:15,250 like the coordinate theory and decentralized blockchains 33 00:02:15,250 --> 00:02:20,290 valuable, they also lead to the difficulties in making it 34 00:02:20,290 --> 00:02:25,690 available to all of people. There are some key things, in my 35 00:02:25,690 --> 00:02:29,170 opinion, that we can distill this value to. 36 00:02:29,290 --> 00:02:33,610 Among them are trustlessness, permissionlessness, openness and 37 00:02:33,890 --> 00:02:36,170 full absolute inclusivity of this networks. 38 00:02:36,840 --> 00:02:40,880 And to achieve that in the blockchain world from the early 39 00:02:40,880 --> 00:02:44,240 days, we embraced the maxima of don't trust, verify. 40 00:02:44,800 --> 00:02:48,840 So essentially everyone has to verify all the transactions, all 41 00:02:48,840 --> 00:02:50,480 of the activity that's happening on chain. 42 00:02:51,120 --> 00:02:55,480 And you can think of blockchains as the social economic systems, 43 00:02:55,920 --> 00:02:58,760 but in the essence, what's happening under the hood, those 44 00:02:58,760 --> 00:03:01,920 are just computing systems. So Ethereum is really Ethereum 45 00:03:01,920 --> 00:03:04,560 started with the narrative of being the world computer. 46 00:03:05,210 --> 00:03:08,530 And it's what the theory really is, if you look at it from the 47 00:03:08,530 --> 00:03:13,730 computer science. So that means everyone has to 48 00:03:13,730 --> 00:03:17,370 redo all of the computations for everyone else, which leads to 49 00:03:17,370 --> 00:03:21,050 quadratic complexity of communication, storage, 50 00:03:21,370 --> 00:03:25,490 computational requirements, and it's just infeasible to bring it 51 00:03:25,490 --> 00:03:31,690 to the work when you are scaling the Internet and adding a value 52 00:03:31,690 --> 00:03:37,600 layer onto the Internet. You can't rerun the computation 53 00:03:37,600 --> 00:03:42,560 of all the other servers of all the other, like redo everything 54 00:03:42,560 --> 00:03:47,080 that everyone else is doing. So like this is a fundamental 55 00:03:47,080 --> 00:03:51,120 limitation which people have tried to solve with different 56 00:03:51,120 --> 00:03:56,800 tradeoffs, always leaving some parts of this value proposition 57 00:03:57,400 --> 00:04:00,320 severely damaged. Like either you give up 58 00:04:00,400 --> 00:04:03,560 decentralization, or you give up security, or you give up some 59 00:04:03,560 --> 00:04:07,280 other important properties. And it was not until zero 60 00:04:07,280 --> 00:04:12,000 knowledge proves fear that we found a fundamental solution to 61 00:04:12,040 --> 00:04:14,600 this. So we came up earlier. 62 00:04:14,600 --> 00:04:19,240 The community came up with some really ingenious ways to make 63 00:04:19,240 --> 00:04:23,360 these trade-offs in a limited way. 64 00:04:24,040 --> 00:04:27,040 We we experimented with things like state channels, payment 65 00:04:27,040 --> 00:04:30,720 channels, plasma which then transitioned into like 66 00:04:30,720 --> 00:04:34,600 optimistic roll ups. All those things were important 67 00:04:34,600 --> 00:04:38,240 steps on this journey. But the ultimate destination is 68 00:04:38,240 --> 00:04:43,120 0 Knowledge Proofs to explain why Zero knowledge Proofs are 69 00:04:43,120 --> 00:04:47,200 specifically like more more precisely succinct 0 knowledge 70 00:04:47,200 --> 00:04:53,520 proofs or Snarks are in fact. They would be better called 71 00:04:53,840 --> 00:04:55,680 proofs of computational integrity. 72 00:04:56,200 --> 00:05:00,920 They allow you to verify arbitrary amount of computation 73 00:05:01,560 --> 00:05:04,320 very cheaply. It doesn't matter how much 74 00:05:04,320 --> 00:05:07,080 original computation you do, how much it would take you to 75 00:05:07,080 --> 00:05:11,360 naively recompute. You can let someone do the hard 76 00:05:11,360 --> 00:05:14,360 work for you and then only present you with a final proof. 77 00:05:14,560 --> 00:05:17,880 Just going to be a short file, like one KB or maybe a few 78 00:05:17,880 --> 00:05:21,450 kilobytes of data. That you can process using very 79 00:05:21,450 --> 00:05:25,690 simple arithmetic operations and come to back to result whether 80 00:05:25,690 --> 00:05:30,210 it's true or false. And the beauty of it, you can 81 00:05:30,250 --> 00:05:34,290 combine various 0 knowledge proofs recursively. 82 00:05:34,290 --> 00:05:38,010 So you can do a lot of computation in parallel and then 83 00:05:39,570 --> 00:05:44,250 verify them, produce a proof that you verified some proofs 84 00:05:44,410 --> 00:05:46,730 and verify these proofs of proofs, and so on. 85 00:05:47,130 --> 00:05:50,290 Until we get to this one single proof, which attests to the 86 00:05:50,290 --> 00:05:54,850 integrity of all the computation that you manage to back in 87 00:05:54,850 --> 00:05:56,930 there. And then you settle this on 88 00:05:56,930 --> 00:05:59,850 something like a theorem, as in global settlement layer, global 89 00:05:59,850 --> 00:06:02,490 layer of consensus, where we all agree, okay, this is the last 90 00:06:02,490 --> 00:06:06,170 state. And this enables us to scale 91 00:06:06,210 --> 00:06:08,530 blockchains basically indefinitely. 92 00:06:09,490 --> 00:06:16,230 And just let's say if I'm to verify all of these proofs, then 93 00:06:16,230 --> 00:06:18,590 I need to know what is being proved though. 94 00:06:18,590 --> 00:06:21,630 So if there's like a huge chain of all kinds of computation, I 95 00:06:21,630 --> 00:06:24,430 still need to know, like you know, all of the things you are 96 00:06:25,470 --> 00:06:28,150 computing, even if I don't have to do the computations. 97 00:06:28,630 --> 00:06:31,870 You don't have to know all of these things. 98 00:06:31,910 --> 00:06:38,390 You only need to commitment like in cryptography. 99 00:06:38,390 --> 00:06:41,590 In the work of blockchains we have a really nice primitive 100 00:06:41,590 --> 00:06:44,040 called commitment. Where you can have a single hash 101 00:06:44,800 --> 00:06:50,120 that is a fingerprint of multiple things, like usually 102 00:06:50,120 --> 00:06:54,680 with packets in a Merkle tree, and you have a lot of the leaves 103 00:06:54,720 --> 00:06:55,880 at the bottom of the Merkle tree. 104 00:06:55,880 --> 00:06:58,400 And then you have 1 hash, the root hash of the sparkle tree, 105 00:06:58,760 --> 00:07:03,080 which will change like which is an unambiguous representation of 106 00:07:03,160 --> 00:07:05,440 all of the data that is committed in this tree. 107 00:07:05,880 --> 00:07:08,520 If you have to change one of the leaves, this hash will 108 00:07:08,520 --> 00:07:10,720 necessarily change, and it's really, really hard. 109 00:07:11,320 --> 00:07:14,750 Computationally infeasible. To find like to fake it, to find 110 00:07:14,750 --> 00:07:17,630 some hash that will correspond to the set that you want. 111 00:07:18,470 --> 00:07:24,670 So in in this regard, you don't have to know all of the things 112 00:07:24,670 --> 00:07:28,350 that's happening computationally there, you only have to know 113 00:07:28,350 --> 00:07:32,950 that whatever you're very fine has a subset which is of 114 00:07:32,990 --> 00:07:36,990 interest to you. So like I I was recently 115 00:07:36,990 --> 00:07:39,550 thinking that the best way to describe zero knowledge proofs 116 00:07:39,550 --> 00:07:42,750 in the blockchain context. Would be to call them not zero 117 00:07:42,750 --> 00:07:45,870 knowledge proofs, but like partial knowledge proofs where 118 00:07:45,870 --> 00:07:49,630 you can only look at things that are important to you but you 119 00:07:49,630 --> 00:07:52,470 still have the full picture and you know that everything else 120 00:07:52,710 --> 00:07:55,790 that you currently don't care about is also still correctly 121 00:07:55,790 --> 00:07:58,150 verified. So a good example of this to 122 00:07:58,150 --> 00:08:02,350 intuitively understand this and you can calibrate me to let me 123 00:08:02,470 --> 00:08:06,950 go deeper into tech or more high level in this interior, but the 124 00:08:07,030 --> 00:08:10,190 intuitive understanding for people out there would be. 125 00:08:11,060 --> 00:08:14,380 Imagine you're getting you're receiving a payment on PayPal or 126 00:08:14,380 --> 00:08:19,300 Venmore or your bank account. You will see that your account 127 00:08:19,300 --> 00:08:22,940 balance has increased. You might want to see who is 128 00:08:22,940 --> 00:08:27,540 this payment coming from and you don't care about all the other 129 00:08:27,540 --> 00:08:30,860 accounts in the world. You still want to be sure that 130 00:08:30,900 --> 00:08:34,179 all the other accounts in your in at least in your bank are 131 00:08:34,179 --> 00:08:38,059 correctly managed, that all the other payments are done with 132 00:08:38,059 --> 00:08:40,740 high integrity. Because if that's not the case. 133 00:08:41,100 --> 00:08:43,659 Maybe your account is increased, but like all the other accounts 134 00:08:43,659 --> 00:08:46,700 are increased by $1 million and so the bank is really insolvent 135 00:08:47,140 --> 00:08:49,380 and it will be will be able to to pay you this money. 136 00:08:49,380 --> 00:08:51,580 When you go to the shop with your credit card you won't be 137 00:08:51,580 --> 00:08:54,780 able to make the payment, so you don't care about those 138 00:08:54,780 --> 00:08:59,020 competitions, but you still want them to be to be to be correct. 139 00:08:59,740 --> 00:09:02,940 So like 0 knowledge proofs would allow you to verify the 140 00:09:02,940 --> 00:09:05,700 integrity of all the other payments without having to care 141 00:09:05,700 --> 00:09:08,870 about them. And the way we implement 0 142 00:09:08,870 --> 00:09:11,470 knowledge proofs in the world of blockchains, the way we apply 143 00:09:11,470 --> 00:09:14,750 them to blockchains today on Ethereum is by building ZK 144 00:09:14,750 --> 00:09:17,910 rollups. And so we can talk about what ZK 145 00:09:17,910 --> 00:09:20,350 ROLLUP actually is. Yes, let's do that. 146 00:09:20,350 --> 00:09:28,750 So in a ZK rollup, who produces the ZK proofs and kind of what's 147 00:09:28,750 --> 00:09:30,830 the mechanism meant to end? Sure. 148 00:09:30,830 --> 00:09:34,710 So ZK Rollup is a layer to scaling solution. 149 00:09:35,240 --> 00:09:38,080 So instead of transacting directly on layer one on the 150 00:09:38,080 --> 00:09:42,880 theorem on the main net itself, we say, let's create a parallel 151 00:09:42,880 --> 00:09:47,960 blockchain that is going to process transactions completely 152 00:09:47,960 --> 00:09:51,720 separately. So we will have someone, some 153 00:09:51,720 --> 00:09:55,520 entity or maybe decentralized by of entities that will accept 154 00:09:55,520 --> 00:09:58,040 transactions and will sequence them in blocks. 155 00:09:58,320 --> 00:10:01,280 We'll call this by. The sequencer can be centralized 156 00:10:01,280 --> 00:10:04,010 run by 1 server. Can be decentralized, run by 157 00:10:04,010 --> 00:10:05,570 consensus of multiple validators. 158 00:10:06,090 --> 00:10:08,010 Doesn't matter. Let's just assume we have this 159 00:10:08,010 --> 00:10:10,650 one blockchain. So the sequencer collects 160 00:10:10,650 --> 00:10:13,930 transactions, back them into blocks, verifies that they're 161 00:10:13,930 --> 00:10:17,210 valid like tries to. If the blocks are invalid, they 162 00:10:17,210 --> 00:10:18,370 won't be able to produce the proofs. 163 00:10:18,930 --> 00:10:22,090 And after the blocks are complete, they do two things. 164 00:10:22,330 --> 00:10:26,610 One is they compute the zero knowledge proofs for all the 165 00:10:26,610 --> 00:10:30,690 transactions in the block, and they produce a final proof that 166 00:10:30,690 --> 00:10:33,710 this block is complete. To make it practical, it 167 00:10:33,710 --> 00:10:36,590 probably requires still recursive proof generation. 168 00:10:36,590 --> 00:10:39,750 So we will split this block into small, many small multiple 169 00:10:39,750 --> 00:10:42,230 chunks. We will produce the proof for 170 00:10:42,230 --> 00:10:45,190 each of the chunk. Maybe we will move heavy 171 00:10:45,190 --> 00:10:48,150 operations into specialized 0 knowledge proofs that are more 172 00:10:48,150 --> 00:10:51,230 efficiently verifiable than generic purpose transactions. 173 00:10:51,230 --> 00:10:53,030 We will produce the proof of that. 174 00:10:53,110 --> 00:10:56,030 Then we will aggregate all these proofs together in one single 175 00:10:56,030 --> 00:10:59,710 proof of the block which contains like all the all the 176 00:10:59,710 --> 00:11:01,710 logic that verifies all the logic that we need. 177 00:11:02,300 --> 00:11:04,580 The transactions were done correctly, that the users 178 00:11:04,580 --> 00:11:08,020 authorized and with signatures, that smart codec logic executed 179 00:11:08,020 --> 00:11:11,660 correctly, and then all the hashes, like, we can basically 180 00:11:11,660 --> 00:11:14,980 all the computation, right? We have this one proof, and then 181 00:11:14,980 --> 00:11:20,980 this proof is submitted on layer one along with the new root hash 182 00:11:20,980 --> 00:11:23,420 for this block. So we don't publish the entire 183 00:11:23,420 --> 00:11:25,260 state, We don't publish all the transactions. 184 00:11:25,260 --> 00:11:28,340 We just say, here's the new state, here's the new commitment 185 00:11:28,340 --> 00:11:32,630 to the state, the new root hash. And here's a proof that this 186 00:11:32,630 --> 00:11:36,390 newer root hash is indeed a valid transition from the 187 00:11:36,390 --> 00:11:39,310 previous root hash, the previous commitment to the state which is 188 00:11:39,310 --> 00:11:44,430 recorded from layer 1, to this new root hash and layer ones. 189 00:11:44,430 --> 00:11:47,350 The smart contract only theorem can actually verify this proof. 190 00:11:48,270 --> 00:11:52,710 Come to conclusion objectively, by nature of pure math 191 00:11:52,710 --> 00:11:55,550 verification that the proof is correct and make the state 192 00:11:55,550 --> 00:11:57,550 transition. And then we need the second 193 00:11:57,550 --> 00:11:58,990 thing. We need to make sure. 194 00:11:59,400 --> 00:12:01,840 That even though the state transition is now valid, 195 00:12:01,960 --> 00:12:06,200 verified on on on layer one, and the transition is made and we 196 00:12:06,200 --> 00:12:11,920 have the new root hash of this state, everyone else knows what 197 00:12:11,920 --> 00:12:15,680 actually happened in this block. It was specifically with regard 198 00:12:15,680 --> 00:12:18,680 to it what what is the new state of all the accounts in the 199 00:12:18,680 --> 00:12:21,480 block. Because if people don't know it, 200 00:12:21,480 --> 00:12:26,200 if external observers, the users or the the other violators don't 201 00:12:26,200 --> 00:12:28,240 know what what what changed in the state. 202 00:12:29,100 --> 00:12:31,420 They will not be able to do anything with it. 203 00:12:32,340 --> 00:12:37,460 Like we will enter a state which is committed on the theory that 204 00:12:37,460 --> 00:12:41,300 no one except for the for whoever made this transition can 205 00:12:41,300 --> 00:12:43,460 actually process. I cannot prove to you that I 206 00:12:43,460 --> 00:12:46,780 have money, I cannot access this money, cannot withdraw, I cannot 207 00:12:46,780 --> 00:12:49,660 transact on this chain. So it would be like a frozen 208 00:12:49,660 --> 00:12:54,180 state. So in order to solve this, we 209 00:12:54,180 --> 00:12:57,500 have to publish something to the users to everyone. 210 00:12:58,120 --> 00:13:00,640 Who wants to observe need to publish some piece of 211 00:13:00,640 --> 00:13:05,320 information that will allow them to reconstruct the state or to 212 00:13:05,320 --> 00:13:07,800 reconstruct the changes that happen from the state from the 213 00:13:07,800 --> 00:13:10,840 previous known state. So there are two ways to do it, 214 00:13:10,840 --> 00:13:14,040 like one is you publish all the transaction inputs and you just 215 00:13:14,040 --> 00:13:16,400 like make it available to everyone and then people can 216 00:13:16,400 --> 00:13:20,200 recompute these transactions and reconstruct the state, which is 217 00:13:20,200 --> 00:13:21,920 something the optimistic roll ups do. 218 00:13:23,440 --> 00:13:26,360 And the second approach is that you publish the actual 219 00:13:26,360 --> 00:13:29,160 differences. For each storage slot that has 220 00:13:29,320 --> 00:13:33,720 been changed in this roll up block, you publish the new state 221 00:13:33,720 --> 00:13:37,400 of the storage slot. Either way, the observer now can 222 00:13:37,400 --> 00:13:42,160 reconstruct the state and they can work with the new block. 223 00:13:42,480 --> 00:13:45,760 But the trick is we have to publish it on some really strong 224 00:13:45,760 --> 00:13:49,560 censorship resistant system. And the most censorship 225 00:13:49,560 --> 00:13:52,520 resistant we have is Ethereum itself. 226 00:13:53,000 --> 00:13:55,240 So we kind of abuse the theory of network to. 227 00:13:55,870 --> 00:13:59,390 Make this data available. We call it the data availability 228 00:13:59,390 --> 00:14:02,870 and the ultimate vision for Ethereum to be the settlement 229 00:14:02,910 --> 00:14:05,350 and the data availability layer for rollups. 230 00:14:05,790 --> 00:14:09,710 Making rollups the center of Ethereum roadmap and really the 231 00:14:09,750 --> 00:14:12,950 place where all or most of the activity on Ethereum will 232 00:14:12,950 --> 00:14:14,630 happen. Cool. 233 00:14:15,150 --> 00:14:17,670 There's a lot to unpack here. Let me maybe recap this. 234 00:14:17,670 --> 00:14:23,350 So basically from a technical point of view, what a ZK rollup 235 00:14:23,990 --> 00:14:27,950 requires is fall forward. So you need regular checkpoints 236 00:14:28,070 --> 00:14:31,950 on L1 that can't revert. You need a proof of correctness 237 00:14:31,950 --> 00:14:36,910 from checkpoint to checkpoint. You need data availability on 238 00:14:36,910 --> 00:14:41,870 L1, either directly by call data or kind of in the dank sharding 239 00:14:41,870 --> 00:14:45,430 world in the site car blobs. The first thing is you need 240 00:14:45,430 --> 00:14:49,190 forced inclusion, and basically that the next checkpoint is only 241 00:14:49,190 --> 00:14:52,310 valid if forced inclusions are provably. 242 00:14:52,660 --> 00:14:54,620 Part of the next checkpoint, right. 243 00:14:54,780 --> 00:14:59,060 So we were kind of we will go into this in just a little bit 244 00:14:59,380 --> 00:15:03,980 and to kind of discuss kind of the recent developments in kind 245 00:15:03,980 --> 00:15:08,100 of the Villadium world and so on to kind of look at the entire 246 00:15:08,100 --> 00:15:11,500 spectrum of kind of shades of L2. 247 00:15:12,620 --> 00:15:17,020 But maybe before that kind of let's quickly talk about the 248 00:15:17,020 --> 00:15:21,380 newly launched CK SYNC 2.0, because that kind of that came 249 00:15:21,380 --> 00:15:22,830 out. Recently. 250 00:15:22,990 --> 00:15:28,470 So now that we kind of know how ZK rollups function 251 00:15:29,510 --> 00:15:32,830 theoretically, let's get down to the meaty part. 252 00:15:32,830 --> 00:15:39,470 So what's new with ZK Sync 2.0? Well, ZK SYNC 2.0, which we call 253 00:15:39,510 --> 00:15:42,230 ZK Sync ERA, is not such a recent development. 254 00:15:42,230 --> 00:15:46,230 We watched it half a year ago, Life in a Minute, and it was the 255 00:15:46,230 --> 00:15:50,070 very first ZK ABM, the very first ZK Rollup. 256 00:15:50,830 --> 00:15:55,110 With generic programmability that could execute contracts 257 00:15:55,110 --> 00:15:58,150 written for solidity insolidity for AVM. 258 00:15:58,590 --> 00:16:02,150 So you could take a contract that works on Ethereum and you 259 00:16:02,150 --> 00:16:06,430 just deploy it and it works out-of-the-box in most cases and 260 00:16:06,430 --> 00:16:09,390 all the tooling works or like not all the tooling works but 261 00:16:09,390 --> 00:16:15,190 like the critical pieces work like the web free API, the 262 00:16:16,510 --> 00:16:19,390 testing, the deploying the access to it like logs. 263 00:16:20,030 --> 00:16:23,710 And everything follows the EVM programming model. 264 00:16:24,190 --> 00:16:28,590 And yes since then we we experienced a lot of growth on 265 00:16:28,590 --> 00:16:33,950 the platform and it's in fact now the the most popular L2 on 266 00:16:33,950 --> 00:16:36,990 Ethereum, we had more transactions in the last 30 days 267 00:16:36,990 --> 00:16:40,950 than any other. L2 was I think 25,000,000 268 00:16:40,950 --> 00:16:45,070 transactions with arbitrary following with 24 and optimism 269 00:16:45,070 --> 00:16:47,630 is 16,000,000 and everyone else way below. 270 00:16:48,660 --> 00:16:55,060 And it's currently the 3rd L2 by TVL and it's also growing, 271 00:16:56,180 --> 00:16:59,580 fluctuating but the D Phi component is growing very 272 00:16:59,580 --> 00:17:02,900 strongly and we have more and more projects launching on ERA. 273 00:17:02,900 --> 00:17:08,980 So era, yeah it's it's a big step for a theory. 274 00:17:09,020 --> 00:17:13,540 It's you know, it's what people were waiting for many years and 275 00:17:13,540 --> 00:17:17,339 and thought it will take many more years to arrive in in the 276 00:17:17,339 --> 00:17:21,310 full form. Let's kind of look at the 277 00:17:21,310 --> 00:17:24,390 taxonomy of different CK roll ups, right? 278 00:17:24,390 --> 00:17:27,710 So basically it's a space that has grown, you know, leaps and 279 00:17:27,710 --> 00:17:32,270 bounds in recent years. And even on this podcast we we 280 00:17:32,310 --> 00:17:37,070 recently interviewed Jody and David from ZKEVM at Polygon. 281 00:17:37,310 --> 00:17:43,430 We spoke with Ellie from Stark with Zack and Joe from Adstech. 282 00:17:44,030 --> 00:17:46,870 But there's also other people we haven't had on the podcast yet, 283 00:17:46,870 --> 00:17:49,790 like the scroll team, the linear team, and so on. 284 00:17:50,230 --> 00:17:53,310 Do you have a taxonomy in your head for these different ZK 285 00:17:53,310 --> 00:17:54,790 rollups? So basically, what kind of 286 00:17:54,790 --> 00:17:58,870 buckets do they fall into? Vitaly came up with this post 287 00:17:59,390 --> 00:18:02,630 introducing different types of ZK Avms. 288 00:18:03,110 --> 00:18:08,870 I'm not sure it will be irrelevant in the midterm, like 289 00:18:08,870 --> 00:18:11,350 it's probably irrelevant. Still relevant now, but we're in 290 00:18:11,350 --> 00:18:12,990 a very early experimentational phase. 291 00:18:13,770 --> 00:18:19,210 In that post he broke it down into essentially degrees of 292 00:18:19,210 --> 00:18:22,170 closeness to the original theorem specification. 293 00:18:22,170 --> 00:18:29,850 Like how how, how far do we deviate from pure native layer 294 00:18:29,850 --> 00:18:33,330 one in the M? Different ZK Avms have like some 295 00:18:33,330 --> 00:18:36,090 of them embrace the byte code native approach, some of them 296 00:18:36,090 --> 00:18:40,410 embrace compiling some, some are somewhere in between. 297 00:18:41,370 --> 00:18:44,970 Some of them are trying to be as close to where one is to 298 00:18:44,970 --> 00:18:50,690 replicate the full blocks of layer one and let storage be 299 00:18:50,690 --> 00:18:56,090 kept in the exactly same format. So look at this. 300 00:18:56,250 --> 00:19:02,730 I think this classification is going to disappear in the short 301 00:19:02,730 --> 00:19:07,090 future because the productivity of 0 knowledge proves is 302 00:19:07,090 --> 00:19:10,330 accelerating, still at the really high pace. 303 00:19:11,180 --> 00:19:15,500 And so the performance characteristics will allow us to 304 00:19:15,500 --> 00:19:20,580 basically verify arbitrary computations we will be able in 305 00:19:20,580 --> 00:19:25,060 the very short term, we will be able to run like Ziki ABM, like 306 00:19:25,620 --> 00:19:31,460 specialized programs compiled from Solidity to a Ziki VM which 307 00:19:31,460 --> 00:19:36,900 is optimal for proving or proof the bytecode native EVM, and 308 00:19:36,900 --> 00:19:39,460 like maybe even have storage proofs for. 309 00:19:40,490 --> 00:19:44,890 For the exact same format as Ethereum or we will be able to 310 00:19:44,890 --> 00:19:52,690 run like native code written in raster C all of that on the same 311 00:19:52,690 --> 00:19:55,090 platform. So you as a builder will have a 312 00:19:55,090 --> 00:19:59,690 choice of what type of computational environment you 313 00:19:59,690 --> 00:20:02,250 want. For some applications you might 314 00:20:02,250 --> 00:20:07,410 want to run bytecode compatible EVM, just there are use cases 315 00:20:07,410 --> 00:20:09,570 like you want to deploy the address. 316 00:20:10,010 --> 00:20:13,810 The contract which has exactly the same addresses as on all the 317 00:20:13,810 --> 00:20:16,850 other AVM chains. So you have no choice but to 318 00:20:16,850 --> 00:20:21,730 deploy native native code there. But for some other cases you 319 00:20:21,730 --> 00:20:29,770 want 100,000 TPS decks optimized for very specific operation. 320 00:20:30,530 --> 00:20:34,130 You can't really do it in. In India you can't do it because 321 00:20:34,130 --> 00:20:36,250 your your sequencer is going to be the bottleneck. 322 00:20:36,730 --> 00:20:40,850 So you will probably write a specialized app specific 323 00:20:41,090 --> 00:20:44,690 application in Rust that just does that. 324 00:20:45,250 --> 00:20:49,010 And you might want to deploy it as a Ziki Roller because you 325 00:20:49,010 --> 00:20:52,370 still want all the benefits of interoperability and security 326 00:20:52,370 --> 00:20:53,730 that you derive from Ziki Roller. 327 00:20:54,210 --> 00:20:57,250 But you will probably not do it in India and you still want a 328 00:20:57,290 --> 00:21:00,530 platform that can that enables you to incorporate all of these 329 00:21:00,530 --> 00:21:03,930 designs. And so I think the real taxonomy 330 00:21:03,930 --> 00:21:07,730 is going to be the like this architecture of interoperability 331 00:21:08,010 --> 00:21:11,830 in the chains. So it's something we recently 332 00:21:11,830 --> 00:21:18,550 came up with the publication of the ZK stack that allows you to 333 00:21:18,550 --> 00:21:22,710 deploy your own chain and the architecture of hyper chains and 334 00:21:22,710 --> 00:21:26,470 hyper bridges that connect them will allow you to have this like 335 00:21:26,470 --> 00:21:28,910 different types of infrastructures deployed in the 336 00:21:28,910 --> 00:21:32,110 interconnected way. So I think that's going to be 337 00:21:32,110 --> 00:21:35,830 like one major classificator, like how different role 338 00:21:35,870 --> 00:21:39,610 ecosystems approach this application specific design and 339 00:21:39,610 --> 00:21:42,050 interpretability between them, like whether or not they can 340 00:21:42,050 --> 00:21:45,530 make it seamless and native. And the second big 341 00:21:46,210 --> 00:21:51,490 classification parameter that I would pick is the treating of 342 00:21:51,490 --> 00:21:54,650 data availability. Do you publish the transaction 343 00:21:54,650 --> 00:21:56,690 inputs or do you publish the state divs? 344 00:21:56,770 --> 00:21:59,170 In what way do we enable volition? 345 00:21:59,170 --> 00:22:01,330 Or is it the single data availability model? 346 00:22:01,570 --> 00:22:04,330 You can only be a ZK rollup or only be a validity. 347 00:22:04,890 --> 00:22:07,130 This is going to be a big important difference. 348 00:22:07,710 --> 00:22:11,510 So those two things I think are much more than the degree of 349 00:22:11,510 --> 00:22:14,550 compatibility, because the compatibility is going to be 350 00:22:14,550 --> 00:22:18,750 solved and. Let's talk about the first 351 00:22:18,790 --> 00:22:23,990 complex of questions 1st and then kind of the validium kind 352 00:22:23,990 --> 00:22:28,070 of spectrum later. So we had LE on recently and he 353 00:22:28,070 --> 00:22:32,990 was very adamant that Zkevms are not performant enough. 354 00:22:33,350 --> 00:22:36,270 And basically, they don't offer basically in terms of kind of 355 00:22:36,270 --> 00:22:41,950 how much computation you can do. He says that Cairo is doing 356 00:22:41,950 --> 00:22:44,630 much, much better. But it sounds like you're saying 357 00:22:44,630 --> 00:22:47,870 that in principle you can kind of mesh these two approaches. 358 00:22:47,870 --> 00:22:50,590 Did I get that right or did I misunderstand? 359 00:22:51,150 --> 00:22:54,830 This is absolutely correct, yes. So I agree with earlier that EVM 360 00:22:55,350 --> 00:22:57,870 is not the most performant platform, especially for 361 00:22:57,870 --> 00:23:01,520 sequential operations. So you can you could construct 362 00:23:01,520 --> 00:23:05,600 an EVM that verifies transactions in parallel, and 363 00:23:05,600 --> 00:23:11,560 then even though the performance of these transactions is not at 364 00:23:11,560 --> 00:23:15,800 the limit of what the current compute is enabling, you kind of 365 00:23:15,800 --> 00:23:18,360 don't care. Because what you care about is 366 00:23:18,360 --> 00:23:22,560 the cost per transaction. And if the cost is much, much 367 00:23:22,560 --> 00:23:27,400 less than the what the user is willing to pay. 368 00:23:27,810 --> 00:23:29,730 And think of like payment applications. 369 00:23:29,770 --> 00:23:32,450 Like if you're or you know like some some important some trading 370 00:23:33,210 --> 00:23:37,050 where your margin is like some a few dollars per transaction but 371 00:23:37,050 --> 00:23:41,290 you're only paying 0.0001 cent, you probably don't care. 372 00:23:41,290 --> 00:23:45,090 Like what you care about is security, you care about 373 00:23:45,090 --> 00:23:47,610 interpretability and you care about time to market. 374 00:23:48,250 --> 00:23:51,650 And if time to market is important, you probably and 375 00:23:51,650 --> 00:23:54,890 you're building smart contracts. You want to tap into a reach 376 00:23:54,890 --> 00:23:57,940 existing ecosystem. You want to be building on 377 00:23:57,940 --> 00:24:01,100 Something like Solidity that has a lot of libraries, a lot of 378 00:24:01,100 --> 00:24:04,100 frameworks, a lot of tooling, a lot of people who know how to 379 00:24:04,100 --> 00:24:05,700 build it. Because it's already hard to 380 00:24:05,740 --> 00:24:09,140 hire Solidity developers. How hard would it be to hire 381 00:24:09,660 --> 00:24:12,100 people who have to learn some specialized language? 382 00:24:12,940 --> 00:24:18,860 So you want to reach broad ecosystem to be building your 383 00:24:18,860 --> 00:24:22,100 stuff on. However, for other applications 384 00:24:22,100 --> 00:24:29,150 for like something that like this 100 KTPS exchange, you 385 00:24:29,150 --> 00:24:32,110 absolutely need the ultimate compute. 386 00:24:32,790 --> 00:24:35,070 You want to like bring it down to you. 387 00:24:35,070 --> 00:24:39,310 Probably maybe you don't even want to run it inside a virtual 388 00:24:39,310 --> 00:24:44,110 machine like no matter if it's Cairo or VM or EVM or whatever. 389 00:24:44,350 --> 00:24:47,590 Maybe you want like really like a bare metal implementation of 390 00:24:47,590 --> 00:24:51,350 your specific roll up that can sell transactions really, really 391 00:24:51,350 --> 00:24:54,660 fast running because all of them are sequential because they are 392 00:24:54,660 --> 00:24:56,060 trading on the same trading pair. 393 00:24:56,500 --> 00:24:59,900 You want to run them as fast as possible what the processor 394 00:24:59,900 --> 00:25:02,620 enables you. So you get to this ultra high 395 00:25:02,620 --> 00:25:06,740 frequency trading with 10s or hundreds of thousands of TPS. 396 00:25:07,460 --> 00:25:11,620 So yes, I believe the future is with this differentiated 397 00:25:11,620 --> 00:25:13,660 spectrum of approach. Cool. 398 00:25:13,660 --> 00:25:17,300 That's very helpful. I want to understand this a 399 00:25:17,300 --> 00:25:21,100 little bit more. So let's say you have to EVM. 400 00:25:21,620 --> 00:25:26,940 Today on Ethereum, right with the EVM, basically there are 401 00:25:26,940 --> 00:25:33,100 some performance limitations. For example, one is because of 402 00:25:33,100 --> 00:25:36,340 the consensus, you have to like propagate the blocks like it 403 00:25:36,380 --> 00:25:39,020 requires certain amount of block time, you can't make them too 404 00:25:39,020 --> 00:25:42,660 massive. Another thing is maybe the kind 405 00:25:42,660 --> 00:25:45,220 of computation of the state and the EVM. 406 00:25:45,620 --> 00:25:50,520 Now we have the ZKV EVM here. What becomes a bottleneck here, 407 00:25:50,520 --> 00:25:53,400 right, because you have a single sequencer that you sent a 408 00:25:53,400 --> 00:25:56,520 transaction to. It's basically the bottleneck, 409 00:25:56,960 --> 00:26:03,640 the speed at which you're able to create the proofs for for all 410 00:26:03,640 --> 00:26:07,960 the transactions. Or I mean first of all how does 411 00:26:07,960 --> 00:26:12,400 the the throughput and scalability of, you know one 412 00:26:12,400 --> 00:26:16,880 single CKVM compared to ether main net and what what are the 413 00:26:16,880 --> 00:26:20,720 bottlenecks there? That's really great question. 414 00:26:20,720 --> 00:26:22,920 So we will have a couple of bottlenecks. 415 00:26:23,320 --> 00:26:25,360 The first intermediate bottleneck is going to be the 416 00:26:25,360 --> 00:26:29,680 speed of your sequencer, the base at which you can accept and 417 00:26:29,680 --> 00:26:33,640 execute transactions and compute the block intermediate, block 418 00:26:33,640 --> 00:26:39,000 results and block hashes. This does not depend on the like 419 00:26:39,000 --> 00:26:41,280 whatever what's your knowledge proofs or fraud proofs you're 420 00:26:41,280 --> 00:26:43,880 using does not depend on data availability. 421 00:26:44,120 --> 00:26:48,370 It's just basic computation and networking and it depends on the 422 00:26:48,370 --> 00:26:52,770 architecture of your chain. Some chains will be 423 00:26:52,770 --> 00:26:55,930 decentralized and so you will have to tap into consensus and 424 00:26:55,930 --> 00:27:00,210 you have to also make sure that your sequencing layer is fast 425 00:27:00,210 --> 00:27:02,850 enough and like your latency is good enough for your 426 00:27:02,850 --> 00:27:06,610 application. And some other chains might even 427 00:27:06,610 --> 00:27:10,610 be completely centralized with a single server that can respond 428 00:27:10,610 --> 00:27:14,910 in like 20 milliseconds time. And for some use cases this like 429 00:27:14,910 --> 00:27:18,670 for this super high frequency trading this would be the case. 430 00:27:18,670 --> 00:27:22,070 They will likely prefer this, but they might still want the 431 00:27:22,070 --> 00:27:25,470 full validity and security derived from Ethereum and open 432 00:27:26,390 --> 00:27:29,630 being not an isolated chain but the part of the bigger ecosystem 433 00:27:29,630 --> 00:27:34,990 with all this rich liquidity. So that's your first bottleneck 434 00:27:35,070 --> 00:27:37,630 and as you can see like the various trade-offs lead to 435 00:27:37,630 --> 00:27:41,390 various different solutions. Your second trade off or 436 00:27:41,390 --> 00:27:45,470 bottleneck is going to be your the data availability, how you 437 00:27:45,470 --> 00:27:47,630 store data availability, how you manage data availability. 438 00:27:48,190 --> 00:27:53,430 If you are a Ziki roll up then you are competing with all the 439 00:27:53,430 --> 00:27:57,310 other roll ups on ethereal ziki and optimistic for the block 440 00:27:57,310 --> 00:27:59,630 space because the block space of Ethereum is limited. 441 00:28:00,230 --> 00:28:03,390 It's kind of a 0 sum game. If some blockchain if some roll 442 00:28:03,390 --> 00:28:08,500 ups will get more data, there will be less data data 443 00:28:08,500 --> 00:28:13,300 availability bandwidth available to other roll ups so which will 444 00:28:13,300 --> 00:28:16,140 lead them just to higher prices for this data bandwidth. 445 00:28:17,060 --> 00:28:21,420 So this is a big problem and the only way to solve it in the 446 00:28:21,420 --> 00:28:27,660 short term to make the throughput really unlimited is 447 00:28:27,660 --> 00:28:30,660 to use external data availability like off chain data 448 00:28:30,660 --> 00:28:34,180 availability. So you will still have Z key 449 00:28:34,180 --> 00:28:38,250 roll ups and maybe every chain should have a part of its 450 00:28:38,250 --> 00:28:41,690 account in on the ZK roll up where all the data is published 451 00:28:41,690 --> 00:28:43,650 on Ethereum and they enjoy high security. 452 00:28:44,370 --> 00:28:48,050 But for the accounts that do not need high security or are 453 00:28:48,050 --> 00:28:53,010 willing to take some risks into account you want to publish data 454 00:28:53,010 --> 00:28:55,770 availability externally with zero knowledge proofs. 455 00:28:55,770 --> 00:28:58,730 It makes a lot of sense. Makes a lot less sense with 456 00:28:58,850 --> 00:29:01,570 optimistic approaches which we can discuss why. 457 00:29:02,570 --> 00:29:09,700 But for for ZKS it works. So if you can go and you have 458 00:29:09,700 --> 00:29:12,700 this kind of elastic extension of data availability bandwidth, 459 00:29:13,420 --> 00:29:15,220 then this bottleneck is going to be solved for you. 460 00:29:15,980 --> 00:29:19,860 And the third bottleneck we have is the actual ability to 461 00:29:19,860 --> 00:29:23,420 generate 0 knowledge proofs. And this is the least of our 462 00:29:23,420 --> 00:29:26,660 problems because the proof generation is they're relatively 463 00:29:26,660 --> 00:29:32,420 cheap and we can do it on very broadly available hardware. 464 00:29:32,880 --> 00:29:37,400 So the we last week we announced an upgrade called Bujum, a new 465 00:29:37,400 --> 00:29:40,720 proof system that is being that's going to be embraced by 466 00:29:41,560 --> 00:29:45,720 Ziggy Singh era. This is a proof system we've 467 00:29:46,160 --> 00:29:49,240 been working on and off for a couple of years is based on the 468 00:29:50,200 --> 00:29:52,880 construction called Redshift which is just a combination of 469 00:29:52,920 --> 00:29:56,480 Plonk and Plonkish arithmetization and Fry 470 00:29:56,480 --> 00:30:00,920 polynomial commitment. And the implementation we have 471 00:30:00,920 --> 00:30:05,290 today only requires 6 to 16 gigabytes of RAM. 472 00:30:05,290 --> 00:30:08,090 Depending on your configuration, you can choose parameters like 473 00:30:08,090 --> 00:30:11,530 let's say 1616 gigabytes of RAM only. 474 00:30:11,530 --> 00:30:14,290 GPU is basically consumer grade hardware. 475 00:30:14,610 --> 00:30:17,290 You can do it on gaming machines, you can do it like on 476 00:30:17,330 --> 00:30:20,810 any cloud provider. They have plenty of GPUs 477 00:30:20,810 --> 00:30:23,810 available for machine learning for other purposes that you can 478 00:30:23,810 --> 00:30:26,130 utilize. So we will be able to prove all 479 00:30:26,130 --> 00:30:30,840 of the world's value transactions with ZK using 480 00:30:31,160 --> 00:30:33,960 something like this. So that is not really a 481 00:30:33,960 --> 00:30:38,600 bottleneck. So data availability and the 482 00:30:38,600 --> 00:30:42,400 sequential throughput or the sequencer throughput are really 483 00:30:42,400 --> 00:30:44,960 two bottlenecks and we can talk about the solutions. 484 00:30:45,480 --> 00:30:48,800 The solution to the sequencer throughput is to have many 485 00:30:48,800 --> 00:30:51,520 chains. There is no alternative to this. 486 00:30:52,120 --> 00:30:55,600 Like we will not be able to handle all of the world's value 487 00:30:55,600 --> 00:30:59,870 transactions on a single monolithic chain because it's 488 00:30:59,870 --> 00:31:02,710 just physically invisible. Like you cannot imagine all of 489 00:31:02,710 --> 00:31:06,630 the world's Internet servers running on a single server or 490 00:31:06,670 --> 00:31:10,830 even on a single data center. Like that doesn't scale. 491 00:31:10,830 --> 00:31:12,830 You need to be able to add more and more on demand. 492 00:31:13,630 --> 00:31:18,910 It also won't work because different no matter what 493 00:31:18,910 --> 00:31:23,030 configuration you take, you're making some trade-offs, latency 494 00:31:23,030 --> 00:31:26,030 versus decentralization. Like if you're decentralized 495 00:31:27,110 --> 00:31:30,650 consensus then you will nature to be able to handle less 496 00:31:31,090 --> 00:31:36,450 throughput and less like. When you say decentralization in 497 00:31:36,450 --> 00:31:40,170 this context, like what are you talking about decentration of 498 00:31:40,170 --> 00:31:41,770 the sequencer? OK. 499 00:31:41,770 --> 00:31:45,330 If you want to decentralize the sequencer as opposed to one, OK, 500 00:31:45,330 --> 00:31:49,450 that makes sense, yeah, yeah. So one validator will be able to 501 00:31:49,450 --> 00:31:53,170 handle like really high load with very low latency. 502 00:31:53,810 --> 00:31:57,860 If you want to have hundreds of validators, then you naturally 503 00:31:57,860 --> 00:32:00,140 have to make the data available to all of them. 504 00:32:00,140 --> 00:32:02,580 You have to reach consensus, which requires at least two 505 00:32:02,580 --> 00:32:04,940 rounds of communication between all of them. 506 00:32:04,940 --> 00:32:07,500 You probably want them to be like broadly geographically 507 00:32:07,500 --> 00:32:11,460 spread, not in the same country, not on the same continent. 508 00:32:11,460 --> 00:32:15,780 So like the communication loop becomes larger, like you're not 509 00:32:15,780 --> 00:32:19,530 getting anywhere, like you will be in the region of like one 510 00:32:19,530 --> 00:32:21,770 second, order of magnitude of one second, maybe half. 511 00:32:21,850 --> 00:32:24,450 Then basically you run something like tenement or something like 512 00:32:24,450 --> 00:32:28,050 that, or correct tenement of hot stuff like you need. 513 00:32:28,050 --> 00:32:30,730 Like even with the newest modification of hot stuff, you 514 00:32:30,730 --> 00:32:35,130 need 2 rounds of consensus, 2 rounds of messaging for the 515 00:32:35,130 --> 00:32:37,130 consensus. Which means you have to like 516 00:32:37,130 --> 00:32:40,810 just send a message twice between different continents. 517 00:32:41,370 --> 00:32:43,930 And you just limited by the speed of light and the speed of 518 00:32:43,930 --> 00:32:48,200 communication and those networks which will determine the latency 519 00:32:48,200 --> 00:32:51,480 of your consensus which you can eliminate if you're using like a 520 00:32:51,520 --> 00:32:56,080 localized data server for centralized sequence. 521 00:32:56,680 --> 00:33:00,280 So those trade-offs are impossible to make like once and 522 00:33:00,280 --> 00:33:04,640 for all one-size-fits-all. So you will need multiple chains 523 00:33:05,080 --> 00:33:08,760 and so the question is how do we incorporate multiple chains in 524 00:33:08,760 --> 00:33:14,170 an architecture where they can still seamlessly, trustlessly 525 00:33:14,170 --> 00:33:16,370 and capital efficiently communicate with each other. 526 00:33:17,090 --> 00:33:20,010 And this is where the hyper chain architecture comes into 527 00:33:20,010 --> 00:33:22,010 play. This is why we've been working 528 00:33:22,010 --> 00:33:27,010 so hard on making this architecture available in the ZK 529 00:33:27,010 --> 00:33:31,690 sync network and we would love to make it available to other 530 00:33:31,690 --> 00:33:34,050 roll ups as well. But unfortunately the way 531 00:33:34,050 --> 00:33:38,250 Ethereum is architected, it's not going to be as seamless 532 00:33:38,570 --> 00:33:40,290 between different roll up ecosystems. 533 00:33:41,650 --> 00:33:45,850 You will be able to pass messages between say Ziki Sync 534 00:33:46,210 --> 00:33:50,330 like one of the Ziki Sync hyper chains and like one of the stock 535 00:33:50,330 --> 00:33:53,970 where Starknet itself or one of the old trees. 536 00:33:54,570 --> 00:33:58,410 So there will be some degree of trustlessness, but it's not 537 00:33:58,410 --> 00:34:01,610 going to be as seamless in terms of assets movement. 538 00:34:02,330 --> 00:34:06,050 To move an asset from one roll up to another you will either 539 00:34:06,050 --> 00:34:09,650 need to use external liquidity or you will have to go through 540 00:34:09,650 --> 00:34:14,610 layer one and actually pass the this asset from one. 541 00:34:15,090 --> 00:34:19,010 Like bridge contract on Ethereum which belongs to Zicky Sing, to 542 00:34:19,010 --> 00:34:21,730 the bridge contract on Ethereum which belongs to some other roll 543 00:34:21,730 --> 00:34:25,570 up which will make a theory layer one itself. 544 00:34:25,570 --> 00:34:29,850 The bottleneck of this bridge which will not really scale for 545 00:34:29,850 --> 00:34:32,090 like we're talking about millions or billions of users. 546 00:34:32,810 --> 00:34:37,650 But within the ecosystem will inside the Zicky Sing hyper 547 00:34:37,650 --> 00:34:41,710 chain network, it will be possible in to arbitrary degree. 548 00:34:41,750 --> 00:34:46,510 So like the way you can imagine, Hyperchange is just like like 549 00:34:46,510 --> 00:34:51,909 you have like domains for e-mail you have Brian at Epicenter or 550 00:34:51,909 --> 00:34:56,230 Gmail or whatever I have like alex@matterla-bs.com you can 551 00:34:56,230 --> 00:35:01,390 send an e-mail from any address on any domain to any other 552 00:35:01,390 --> 00:35:04,630 address on any other domain and you don't have to care about it. 553 00:35:04,630 --> 00:35:08,030 You don't like the communication is the same, you just do one 554 00:35:08,030 --> 00:35:12,570 click and in a few seconds or minutes the message arrives on 555 00:35:12,570 --> 00:35:16,450 the other side and it's end to end encrypted, like you know 556 00:35:16,450 --> 00:35:19,770 it's trustless. How does this work technically? 557 00:35:19,770 --> 00:35:26,650 Because basically one ZK sync chain would have to know the 558 00:35:26,650 --> 00:35:30,090 state of the other chain to actually make this happen, 559 00:35:30,090 --> 00:35:31,210 right? So basically it's kind of like 560 00:35:31,210 --> 00:35:33,770 the old problem of kind of having smartshots and how they 561 00:35:33,770 --> 00:35:36,150 communicate, right? But yes. 562 00:35:36,150 --> 00:35:40,910 So if you want to learn like real technical detail, like deep 563 00:35:40,910 --> 00:35:43,510 technical details on how it works, I highly recommend this 564 00:35:43,510 --> 00:35:48,910 Slosh paper where the Slosh team has done an extensive research 565 00:35:48,910 --> 00:35:51,230 and documented really well how this will work. 566 00:35:51,230 --> 00:35:56,550 But like the high level, yes, the two chains that transact 567 00:35:57,510 --> 00:36:00,590 between each other and need to share need to have access to 568 00:36:00,590 --> 00:36:03,790 each other's state. So this is already possible with 569 00:36:03,910 --> 00:36:06,870 all roll ups on Ethereum. The moment you finalize the 570 00:36:06,870 --> 00:36:12,150 state on one rollup, you can use storage proofs to access the 571 00:36:12,150 --> 00:36:14,310 state of any other rollup. Because you can go, you can 572 00:36:14,310 --> 00:36:18,350 pass. You can imagine that Ethereum 573 00:36:18,350 --> 00:36:21,830 kind of unites all of the states of all the rollups in one huge 574 00:36:21,830 --> 00:36:29,070 merkle tree, where Ethereum state tree is like the top of 575 00:36:29,070 --> 00:36:33,590 this huge merkle tree. So what you do is only one 576 00:36:33,590 --> 00:36:37,340 chain. You commit a message with a 577 00:36:37,340 --> 00:36:42,500 destination of some other chain. And in this message you say here 578 00:36:42,500 --> 00:36:48,780 I like, I am burning let's say 100 ETH on this chain here like 579 00:36:49,220 --> 00:36:50,780 the smart contact takes care of this. 580 00:36:51,380 --> 00:36:56,420 And so like I promise I like, I burn it in favor of this 581 00:36:56,420 --> 00:37:00,700 destination on some other hyper chain within some period of 582 00:37:00,700 --> 00:37:02,860 time. And you make this commitment, 583 00:37:02,860 --> 00:37:06,490 you store it in storage. The other chain can then read 584 00:37:06,490 --> 00:37:09,850 the storage and say, oh, I see that this amount was burn. 585 00:37:10,810 --> 00:37:12,610 And here's a very, very important part. 586 00:37:13,570 --> 00:37:18,610 Because both chains run the exactly same subset of circuits, 587 00:37:18,970 --> 00:37:23,690 the exactly same subset of like cryptographic enforcement of the 588 00:37:23,690 --> 00:37:29,670 rules, I can trust this other chain with a message that for 589 00:37:29,670 --> 00:37:32,670 this commitment that the the this action has actually been 590 00:37:32,670 --> 00:37:34,910 performed, that they actually burned this 108th. 591 00:37:35,550 --> 00:37:40,390 I can trust it blindly because that chain is is like it's 592 00:37:40,430 --> 00:37:45,950 validity is enforced by exactly same circuits as my own chain as 593 00:37:45,950 --> 00:37:49,270 as I as myself, as as I myself as a chain, right. 594 00:37:49,270 --> 00:37:53,510 So like for me, I can trust that chain as much as I can trust 595 00:37:53,510 --> 00:37:57,070 myself. So I can easily min this 108th 596 00:37:57,380 --> 00:38:01,100 on this chain like through some system counter that has access 597 00:38:01,100 --> 00:38:04,300 to like minting. And it's probably going to be 598 00:38:04,300 --> 00:38:06,900 like a part of the of your bridging. 599 00:38:07,140 --> 00:38:10,260 Like your tokens will have to be aware if you either use system 600 00:38:10,260 --> 00:38:13,220 conference for tokens or you use specialized tokens that know 601 00:38:13,380 --> 00:38:17,540 about this functionality can mint this assets and then you 602 00:38:17,540 --> 00:38:21,460 can use this assets natively. So you need to be part of the 603 00:38:21,460 --> 00:38:23,980 same state, you need to have the same circuit so they can trust 604 00:38:23,980 --> 00:38:26,730 each other. And then the third key component 605 00:38:26,730 --> 00:38:31,930 of this architecture is that all of these chains have to share a 606 00:38:32,490 --> 00:38:36,050 single bridge on Ethereum that holds assets for them. 607 00:38:36,730 --> 00:38:40,050 Because if you don't share the same bridge that holds the 608 00:38:40,050 --> 00:38:45,250 assets, then you can kind of like trust the other chain. 609 00:38:45,370 --> 00:38:50,170 You can be sure that they burn some like 100 E and you can mint 610 00:38:50,170 --> 00:38:54,390 it yourself inside your chain. You will never be able to 611 00:38:54,390 --> 00:38:56,670 withdraw this hundred you because they don't belong to you 612 00:38:56,990 --> 00:38:59,270 then. No blocked in your near bridge 613 00:38:59,270 --> 00:39:02,910 on this area. Is is that last one the main 614 00:39:02,910 --> 00:39:06,830 reason why you wouldn't be able to get the same kind of 615 00:39:06,830 --> 00:39:09,950 convenience when it comes to like vision to start net or some 616 00:39:09,950 --> 00:39:11,550 other thing? Precisely, yes. 617 00:39:11,550 --> 00:39:14,710 Like you, you like in order. So like there would be a 618 00:39:14,710 --> 00:39:18,110 question if you can trust Stark NET contracts because it's a 619 00:39:18,110 --> 00:39:21,710 separate system that is managed by entirely different governance 620 00:39:22,150 --> 00:39:24,200 You might like, you know you will have to write your 621 00:39:24,200 --> 00:39:28,840 specialized contract, the custom user contract that says I trust 622 00:39:28,840 --> 00:39:32,200 Starknet maybe other contracts don't but I do trust them. 623 00:39:32,200 --> 00:39:36,440 So like I can believe that this message is real, but then like, 624 00:39:36,800 --> 00:39:40,280 so that's actually the first problem like even if we if we 625 00:39:40,280 --> 00:39:46,280 could manage the the ownership of this contract if this 626 00:39:46,280 --> 00:39:49,760 contract would not be able to persuade the system contract 627 00:39:50,640 --> 00:39:54,090 that we should mint if because the system contract does not 628 00:39:54,090 --> 00:39:57,490 know if Starknet is not compromised by their government. 629 00:39:57,490 --> 00:40:02,130 The system contract basically is able to verify the computation 630 00:40:02,450 --> 00:40:06,170 that's done using specific circuits and starkness as 631 00:40:06,170 --> 00:40:09,610 different circuits, so it like cannot directly verify. 632 00:40:09,610 --> 00:40:12,530 That it's just a different system, not not governed by the 633 00:40:12,530 --> 00:40:15,290 same like upgradeability pattern by the same code. 634 00:40:15,730 --> 00:40:19,530 So like the system the system contract can only trust other 635 00:40:19,530 --> 00:40:22,360 system contracts of trusted origin. 636 00:40:22,360 --> 00:40:26,040 It cannot trust users code because if I can deploy 637 00:40:26,040 --> 00:40:30,000 arbitrary smart contract which says meant me $1 million trust 638 00:40:30,000 --> 00:40:32,960 me bro it's like it's it's honest because it's kind of from 639 00:40:32,960 --> 00:40:34,920 the other chain. The system contract will say you 640 00:40:34,920 --> 00:40:39,600 know like maybe maybe not so it has to be a message that comes 641 00:40:39,600 --> 00:40:43,720 from the other system contract that actually burned this this 642 00:40:43,720 --> 00:40:46,840 100 feet. But yes, but then the second 643 00:40:46,840 --> 00:40:50,520 part is is is you're right. Like even if we if we solve that 644 00:40:50,520 --> 00:40:53,090 we like on the system level we make an agreement. 645 00:40:53,090 --> 00:40:56,170 We say like the kissing trusts darkness. 646 00:40:56,170 --> 00:41:00,210 Darkness trusts the kissing. We still cannot pass the assets 647 00:41:00,210 --> 00:41:02,970 because they are locked in different underlying bridge 648 00:41:02,970 --> 00:41:06,210 conference. How does the hyper chain know 649 00:41:06,210 --> 00:41:10,450 which other chains are in the hyper chain architecture and to 650 00:41:10,450 --> 00:41:12,610 trust them right? I mean they kind of need a Hyper 651 00:41:12,610 --> 00:41:16,450 chain ID that kind of says I am Hyper chain 72. 652 00:41:17,040 --> 00:41:20,360 You can trust me, but is there any way of kind of faking that 653 00:41:20,360 --> 00:41:21,800 or do you need a centralized register? 654 00:41:21,800 --> 00:41:25,960 How do you go about that? You will have a smart contact on 655 00:41:25,960 --> 00:41:34,200 Ethereum that will hold the Merkle tree of the hyperchange. 656 00:41:34,200 --> 00:41:39,560 Let's call it the shared prover or the shared verifier in this 657 00:41:39,560 --> 00:41:43,830 Merkle tree. All the state changes will only 658 00:41:43,830 --> 00:41:47,550 be authorized if they are coming from a trusted hyper chain. 659 00:41:47,550 --> 00:41:52,430 And by trusted I mean like from a hyper chain with the circuits 660 00:41:52,510 --> 00:41:56,270 that the prover contract knows. Because the prover contracts are 661 00:41:56,270 --> 00:41:59,990 always verifies the proofs against some verification keys. 662 00:42:01,950 --> 00:42:05,990 Like when you verify a proof you need to know what you verify you 663 00:42:05,990 --> 00:42:09,070 don't like. You need to have this commitment 664 00:42:09,150 --> 00:42:11,350 to the circuits which we call the verification key. 665 00:42:11,770 --> 00:42:18,290 It's a small key, but it unambiguously identifies certain 666 00:42:18,290 --> 00:42:21,850 cryptographic program. One circuit always produces one 667 00:42:21,850 --> 00:42:26,970 specific verification. So this breach contract will 668 00:42:26,970 --> 00:42:30,170 have like one single verification key for all the 669 00:42:30,170 --> 00:42:33,370 hyper chains. Any hyper chain that wants to 670 00:42:33,370 --> 00:42:36,870 make a state position must support this verification, which 671 00:42:36,870 --> 00:42:40,350 means that they are enforcing all the rules the way we all 672 00:42:40,350 --> 00:42:43,430 agree that we all enforce. And this is also how you make 673 00:42:43,430 --> 00:42:48,070 sure that the the tokens on each hyper chain actually 674 00:42:48,070 --> 00:42:50,030 commensurate, right? Because basically I could be 675 00:42:50,830 --> 00:42:54,350 evil hyper chain and could say, look I have 100 ETH, I will burn 676 00:42:54,350 --> 00:42:58,550 it, I will reissue it on hyper chain 19 and then basically I 677 00:42:58,670 --> 00:43:02,830 burn some sort of fake ether and kind of get really ether on 678 00:43:02,830 --> 00:43:05,300 hyper chain 19. Absolutely correct. 679 00:43:05,300 --> 00:43:08,620 So they have to share the circuits, maybe not all the 680 00:43:08,620 --> 00:43:12,260 circuits, the hyper chains are actually highly customizable, 681 00:43:12,740 --> 00:43:14,700 they are, they are fully sovereign, you can choose your 682 00:43:14,700 --> 00:43:17,820 sequence, you can choose your data availability model, you can 683 00:43:17,820 --> 00:43:19,460 choose your extensions whatever you want. 684 00:43:19,820 --> 00:43:23,620 But there must be a some really small subset of circuits that 685 00:43:23,700 --> 00:43:28,660 enforce this integrity, that enforce this the the asset 686 00:43:28,660 --> 00:43:32,700 treasury that like really everyone cannot mess with anyone 687 00:43:33,140 --> 00:43:36,570 else's assets. So this part must be common and 688 00:43:36,570 --> 00:43:40,850 this is going to be the critical part to verify in the state 689 00:43:40,850 --> 00:43:44,210 transitions. I think I think I get get that 690 00:43:44,210 --> 00:43:46,490 part. Now let's maybe back up a little 691 00:43:46,570 --> 00:43:49,530 kind of to the four requirements of AZK rollup. 692 00:43:49,730 --> 00:43:54,010 So as we as we talked about you kind of you need you need 693 00:43:54,370 --> 00:43:57,090 regular checkpoints that kind of rebut you need a proof between 694 00:43:57,090 --> 00:43:59,730 checkpoint to checkpoint then you need data availability and 695 00:43:59,730 --> 00:44:03,050 the reason why you need data availability is so that. 696 00:44:03,540 --> 00:44:06,540 If there is no data availability, there's like some 697 00:44:06,540 --> 00:44:10,300 sort of secret transaction that I can kind of include in the 698 00:44:10,300 --> 00:44:13,260 block. Other people can no longer 699 00:44:13,620 --> 00:44:16,780 calculate the current state of the block and can no longer 700 00:44:16,780 --> 00:44:20,660 build on it, and thereby I can effectively break it, right? 701 00:44:20,660 --> 00:44:21,260 I can. Kind of. 702 00:44:21,260 --> 00:44:24,220 I can't steal ones, yeah, but I can. 703 00:44:24,220 --> 00:44:26,940 I can make sure that no one else can do anything because I have 704 00:44:26,940 --> 00:44:29,140 the secret transaction. This is why you need the data 705 00:44:29,140 --> 00:44:32,620 availability. There are villadiums. 706 00:44:33,030 --> 00:44:37,230 Which are basically ZK rollups without data availability and 707 00:44:37,230 --> 00:44:42,630 this is kind of the direction that cello is going as well as 708 00:44:42,630 --> 00:44:47,070 Polygon and so on. How do you think about this 709 00:44:47,350 --> 00:44:51,350 spectrum of L tuners? And do you think maybe there's 710 00:44:51,350 --> 00:44:57,510 even a way of kind of doing data availability optimistically so 711 00:44:57,510 --> 00:45:00,230 that basically don't actually because basically if you look at 712 00:45:00,390 --> 00:45:03,630 how much you spend? On the checkpoints versus on the 713 00:45:03,630 --> 00:45:07,390 data availability, maybe you can give us the exact numbers for ZK 714 00:45:07,390 --> 00:45:10,790 sync, but almost everything actually is is for data 715 00:45:10,790 --> 00:45:13,510 availability rather than the checkpoints, right? 716 00:45:15,030 --> 00:45:16,830 Absolutely correct. So I'll start with this last 717 00:45:16,830 --> 00:45:20,830 question. Indeed the absolute majority of 718 00:45:21,030 --> 00:45:24,350 the costs is going towards data availability from like we 719 00:45:24,430 --> 00:45:27,990 currently have 3050 sales per transaction depending on 720 00:45:27,990 --> 00:45:31,310 fluctuating gas prices Ethereum across all the roll ups. 721 00:45:32,040 --> 00:45:35,600 The bulk of this cost is going to the table ability and it's 722 00:45:35,600 --> 00:45:41,000 not going to change even after AP4844 which will hopefully 723 00:45:41,000 --> 00:45:44,760 bring the costs down by a factor of 10 X make 20X. 724 00:45:45,360 --> 00:45:48,200 But like the even the remaining one cent is going to be the 725 00:45:48,200 --> 00:45:50,440 majority of the cost because the zero knowledge proofs 726 00:45:51,240 --> 00:45:55,400 computation part is tiny. It's like 0.0 something like 727 00:45:55,400 --> 00:45:58,490 it's hard to calculate exactly because there are many 728 00:45:58,490 --> 00:46:01,010 components in the system like it's really like you can 729 00:46:01,010 --> 00:46:06,410 benchmark something in vacuum but it's in detachment from the 730 00:46:06,410 --> 00:46:08,370 real system. It's not going to be indicative, 731 00:46:08,370 --> 00:46:12,330 but like we know for sure it's like a so correct. 732 00:46:12,330 --> 00:46:14,530 The data availability is important, so if you want to 733 00:46:14,530 --> 00:46:18,250 lower the cost you have to seek this external data availability 734 00:46:18,250 --> 00:46:21,970 solutions like the building something like volidiums or 735 00:46:21,970 --> 00:46:24,050 volitions talk about that in a second. 736 00:46:25,490 --> 00:46:30,090 The the like let's reason about their L Two's Ness. 737 00:46:30,650 --> 00:46:33,170 I think we need a good definition of what an L2 738 00:46:33,170 --> 00:46:37,850 actually is and I've not seen a strict definition adopted by the 739 00:46:37,850 --> 00:46:41,570 community like we kind of like know it intuitively but but not 740 00:46:41,570 --> 00:46:43,970 precisely. I think a good definition would 741 00:46:43,970 --> 00:46:51,090 be an L2 is a chain that derives its security from underlying 742 00:46:51,090 --> 00:46:53,670 layer. One like security in various 743 00:46:53,790 --> 00:46:56,270 senses, like it would be liveness, could be security of 744 00:46:56,270 --> 00:46:59,510 fonts, retrievability of the fonts eventually and so on. 745 00:46:59,510 --> 00:47:03,670 But you need to derive some security from L1 if you don't 746 00:47:03,670 --> 00:47:08,310 derive security like for some significant security from L1. 747 00:47:08,790 --> 00:47:14,550 So a side chain for example is not an L2 because your security 748 00:47:14,550 --> 00:47:17,350 entirely depends on your set of validators. 749 00:47:18,360 --> 00:47:20,080 They can do whatever they want with your money. 750 00:47:20,080 --> 00:47:23,680 If they collude, they can still, they can freeze whatever. 751 00:47:24,360 --> 00:47:28,400 With ZQ roll up the security is 100% direct from layer one. 752 00:47:29,080 --> 00:47:33,120 You can always guarantee that the users will eventually be 753 00:47:33,120 --> 00:47:35,880 able to withdraw all the funds, no matter what the validators, 754 00:47:36,240 --> 00:47:39,600 if the contracts are immutable, if they don't have the right to 755 00:47:39,600 --> 00:47:42,760 arbitrary change contracts, and of course if there are no box in 756 00:47:42,760 --> 00:47:46,240 the implementation, which is a significant risk, which is not 757 00:47:46,240 --> 00:47:49,490 negligible, like let's assume those two factors for now. 758 00:47:50,170 --> 00:47:53,850 But in this case ZQ Rollup is like ironclad. 759 00:47:53,970 --> 00:47:57,130 Security is exactly the same as the theorem in terms of its 760 00:47:57,130 --> 00:47:59,810 properties. The validium is in between. 761 00:48:01,130 --> 00:48:07,370 All the transactions in validium are enforced by zero knowledge, 762 00:48:07,370 --> 00:48:10,330 proofs and theorem. So it's not possible to make 763 00:48:10,370 --> 00:48:13,930 anything invalid. It's not possible to execute 764 00:48:13,930 --> 00:48:15,610 something not on behalf of the user. 765 00:48:16,350 --> 00:48:20,310 In this sense, it derives a very significant part of its security 766 00:48:20,310 --> 00:48:24,430 from Ethereum. And for some use cases you 767 00:48:24,430 --> 00:48:27,590 really you don't care that much about data availability, you 768 00:48:27,590 --> 00:48:32,550 only care about the correctness of the code. 769 00:48:33,070 --> 00:48:37,470 Like an example of this would be, let's say, online voting. 770 00:48:38,510 --> 00:48:41,900 Let's say that you you're voting like, let's ignore salsish 771 00:48:41,900 --> 00:48:43,940 resistance for now. Let's let's imagine that we have 772 00:48:43,940 --> 00:48:47,140 some like perfect Salish resistance input because maybe 773 00:48:47,140 --> 00:48:50,580 like, you know, like what? Like each party collects their 774 00:48:50,580 --> 00:48:54,900 own votes and then each party submits their like, you know, 775 00:48:54,900 --> 00:48:57,860 like we we have like, you know, blue party and the red party. 776 00:48:58,340 --> 00:49:01,300 Both of them get as many votes as they can from their 777 00:49:01,300 --> 00:49:05,580 respective proponents, and then each of them submits a 778 00:49:05,580 --> 00:49:08,870 transaction on this chain and all you care about is to 779 00:49:08,870 --> 00:49:12,470 calculate the votes correctly. And then you want to publish the 780 00:49:12,470 --> 00:49:15,310 result on chain, but you want to make sure that it's actually 781 00:49:15,310 --> 00:49:20,430 like correctly available on chain to other contacts, not 782 00:49:20,830 --> 00:49:22,950 just to humans. To demonstrate which you could 783 00:49:22,950 --> 00:49:25,830 do off changes generating 0 knowledge proofs, you want to 784 00:49:25,830 --> 00:49:29,270 make it available to contacts. So for this, data availability 785 00:49:29,270 --> 00:49:32,270 is really not important. All you care about in the end is 786 00:49:32,270 --> 00:49:34,350 that the result is correct, right? 787 00:49:35,250 --> 00:49:39,610 The same applies to oracles, like when you do Oracle updates, 788 00:49:40,210 --> 00:49:44,090 you don't care about the state of the Oracle update because you 789 00:49:44,090 --> 00:49:48,370 can discard that. Like if the chain is frozen, who 790 00:49:48,370 --> 00:49:49,690 cares? Like you will be able to make 791 00:49:49,690 --> 00:49:53,890 new Oracle ticks on the new chain when users migrate, right? 792 00:49:54,330 --> 00:49:56,810 But what you care about is that the Oracle updates have been 793 00:49:56,810 --> 00:49:59,410 correctly verified that they're coming from trusted sources, 794 00:49:59,890 --> 00:50:02,570 that the way that averages are computed correctly and so on and 795 00:50:02,570 --> 00:50:06,480 so on, right? So for those use cases, Validium 796 00:50:06,480 --> 00:50:10,360 does not constitute any reduction in security because 797 00:50:10,680 --> 00:50:13,320 you only use security for computation, which it's 798 00:50:13,320 --> 00:50:16,200 perfectly secure. So from this perspective, I 799 00:50:16,200 --> 00:50:19,040 think that Validium is actually like it should deserve to be 800 00:50:19,040 --> 00:50:25,000 called ML2 to some degree. When we talk about the actual, 801 00:50:25,000 --> 00:50:28,320 like real life security, like real world security for the user 802 00:50:28,360 --> 00:50:31,080 assets, it becomes a lot trickier. 803 00:50:32,140 --> 00:50:35,780 It's really hard to reason like we Now we are back to this game, 804 00:50:35,780 --> 00:50:41,580 theoretical a plane where we can imagine that the operator, the 805 00:50:41,580 --> 00:50:46,020 validators of this Villadium chain that locks a lot of like 806 00:50:46,260 --> 00:50:48,260 some billions of dollars of your assets. 807 00:50:48,740 --> 00:50:52,020 They could say, oh you know what, like let's try to 808 00:50:52,020 --> 00:50:55,380 blackmail our users, let's freeze the state and then like 809 00:50:55,380 --> 00:50:58,340 demand ransom. Or maybe they don't freeze the 810 00:50:58,340 --> 00:51:00,450 state. Maybe they are hacked because 811 00:51:00,450 --> 00:51:04,570 the servers that operate the validium have to be online, the 812 00:51:04,850 --> 00:51:06,250 keys have to be on the whole machines. 813 00:51:06,770 --> 00:51:09,530 So maybe there is some like ingenious way to hack the 814 00:51:09,530 --> 00:51:12,970 systems and they compromise the majority of the of the 815 00:51:12,970 --> 00:51:16,970 validators and then the hackers can demand some like it could 816 00:51:17,010 --> 00:51:21,050 potentially become tricky. So I would of course treat 817 00:51:21,170 --> 00:51:25,130 validium accounts always as like significantly less secure than 818 00:51:25,130 --> 00:51:29,000 Ethereum accounts. But then you know, like you 819 00:51:29,000 --> 00:51:32,720 could like the. I think the ideal solution is 820 00:51:32,720 --> 00:51:35,680 the combination of both. When you have something like a 821 00:51:35,680 --> 00:51:40,200 volition system where you as a user can decide for each of your 822 00:51:40,200 --> 00:51:43,320 accounts, do you want it to be stored on Ethereum? 823 00:51:43,600 --> 00:51:48,280 Like on a ZQ roll up with full Ethereum security guarantees but 824 00:51:48,280 --> 00:51:52,040 maybe higher cost of transactions on this account and 825 00:51:52,080 --> 00:51:56,480 for some other account you decide that it should be a valid 826 00:51:56,480 --> 00:51:58,800 unit. Or is the key partner account 827 00:51:58,800 --> 00:52:01,720 where the data availability is secured off chain by some 828 00:52:02,280 --> 00:52:04,360 committee with some economic security. 829 00:52:05,360 --> 00:52:09,520 But you use it as you would use your savings and your current 830 00:52:09,520 --> 00:52:11,800 account. You would keep most of your 831 00:52:11,800 --> 00:52:14,600 assets, most of your savings on the savings account. 832 00:52:15,280 --> 00:52:18,560 Maybe you put them in some default protocols from your roll 833 00:52:18,560 --> 00:52:21,320 up account and you don't touch it every day, the only 834 00:52:21,320 --> 00:52:24,120 transactor rarely on it. So like most of your value is 835 00:52:24,120 --> 00:52:28,290 there and then you move some of this value to your current 836 00:52:28,290 --> 00:52:31,890 account on the on the validium side of of the volition. 837 00:52:32,330 --> 00:52:34,810 Let's say on like you you on Zicky sink it would be called 838 00:52:34,810 --> 00:52:37,290 Zicky Porter. So you put it in Zicky Porter, 839 00:52:37,290 --> 00:52:40,810 maybe you have like your millions of dollars and on that 840 00:52:40,810 --> 00:52:45,010 side and just a few thousand per month to pay for for your daily 841 00:52:45,010 --> 00:52:48,490 needs on the volition side. And so you kind of like you you 842 00:52:48,530 --> 00:52:52,970 you explicitly manage the risks of this exposure and if everyone 843 00:52:53,050 --> 00:52:57,780 else is doing the same, then you have a lot less value locked on 844 00:52:57,780 --> 00:53:02,420 the Validium side of the evolution, but you will have a 845 00:53:02,420 --> 00:53:05,820 lot more transactions, which actually makes a perfect sense 846 00:53:05,820 --> 00:53:08,300 from the from this balanced perspective, right? 847 00:53:08,300 --> 00:53:11,100 Like you will have a lot of cheap transactions, a lot of 848 00:53:11,100 --> 00:53:14,820 trading going on there, a lot of like computational activity like 849 00:53:15,300 --> 00:53:19,660 Oracle updates and arbitrage transactions and so on and so on 850 00:53:19,660 --> 00:53:23,420 happening on the evolution side. Sorry, on the Validium side. 851 00:53:23,820 --> 00:53:24,900 Can I quickly? Kind of. 852 00:53:25,580 --> 00:53:27,180 Question this to a certain extent. 853 00:53:27,340 --> 00:53:31,340 Basically, if you kind of look how say Cello is transitioning 854 00:53:31,340 --> 00:53:35,700 to being an L2, they're not forgoing their validator set, 855 00:53:35,700 --> 00:53:39,420 right? So why a kind of CK sync? 856 00:53:39,420 --> 00:53:42,300 And to be fair, all other L2S have like a centralized 857 00:53:42,300 --> 00:53:45,940 sequencer, which is definitely also an attack vector, right? 858 00:53:46,740 --> 00:53:51,180 The Validiums that kind of we see emerging, they already have 859 00:53:51,180 --> 00:53:55,710 a decentralized validator set. And so basically, there's many 860 00:53:55,710 --> 00:53:58,590 entities that in principle are allowed to kind of build the 861 00:53:58,590 --> 00:54:00,830 blocks. Where do we see the trade off 862 00:54:00,830 --> 00:54:02,990 here? So I mean, obviously if you had 863 00:54:03,270 --> 00:54:07,790 a decentralized sequencer on ZK Sync, this point would kind of 864 00:54:07,790 --> 00:54:10,310 fall, but currently you don't, right? 865 00:54:11,110 --> 00:54:12,350 You can't really compare the two. 866 00:54:12,350 --> 00:54:15,630 So first of all, we are committed to decentralizing the 867 00:54:15,630 --> 00:54:17,550 sequencer. We actively work on this. 868 00:54:17,550 --> 00:54:20,910 We have a prototype which will unveil very soon. 869 00:54:20,910 --> 00:54:24,230 It's running on the hot stuff consensus. 870 00:54:24,230 --> 00:54:26,550 It's going to be fully decentralized as a sequencer. 871 00:54:27,310 --> 00:54:30,030 And what you want to get from the sequence of decentralization 872 00:54:30,030 --> 00:54:34,790 primarily is the resilience and the liveness of your network. 873 00:54:35,110 --> 00:54:37,550 You want to be sure that the network will remain operational, 874 00:54:37,550 --> 00:54:41,430 like for everyday transactions, even if one or multiple parties 875 00:54:41,430 --> 00:54:43,710 are compromised or going down or unavailable. 876 00:54:45,070 --> 00:54:47,750 But the sequencer does not affect the security of your 877 00:54:47,750 --> 00:54:50,430 funds. So you could argue that liveness 878 00:54:50,430 --> 00:54:52,190 is part of security. I will admit that. 879 00:54:52,710 --> 00:54:57,460 But if you put a lot of value in some default applications, yes, 880 00:54:57,460 --> 00:55:00,260 you will be annoyed if it's not available, and you might have 881 00:55:00,260 --> 00:55:04,220 some like opportunity costs for not being able to use it for a 882 00:55:04,220 --> 00:55:08,020 couple of days. But it's nothing compared to the 883 00:55:08,020 --> 00:55:11,140 ability to lose all of your fonts locked in, like in Unis 884 00:55:11,140 --> 00:55:13,140 Lock for example. Right, but the validators can't 885 00:55:13,140 --> 00:55:15,500 steer from you, right? I mean so basically if you have 886 00:55:15,500 --> 00:55:18,700 the ability to kind of run your own full node, you can't be 887 00:55:18,700 --> 00:55:20,980 duped about the state of the chain. 888 00:55:21,810 --> 00:55:24,970 You can never steal funds, you can never steal funds. 889 00:55:24,970 --> 00:55:28,490 Like all you could try to do is like the validators could try to 890 00:55:28,490 --> 00:55:30,890 double, like they can't even do a double span. 891 00:55:30,890 --> 00:55:35,970 Like they can only do some short term faking on chain that will 892 00:55:35,970 --> 00:55:41,250 never finalize on the theory. And if you're if you're making 893 00:55:41,250 --> 00:55:45,610 high value transactions, you always want to wait for the 894 00:55:45,610 --> 00:55:48,410 final find, like for the finality on the theory and for 895 00:55:48,410 --> 00:55:51,440 the checkpoint, but it actually guarantees that this transaction 896 00:55:51,440 --> 00:55:54,560 is final before accepting it. If you're expecting someone for 897 00:55:54,560 --> 00:55:57,760 some of the payment of $1 million, you have to wait for a 898 00:55:58,200 --> 00:56:01,760 You cannot trust the sequencer, they just I have a confirmation. 899 00:56:02,280 --> 00:56:03,760 Absolutely. But that's the same on 900 00:56:03,760 --> 00:56:07,480 Villadium, right? So on Villadium, the validators 901 00:56:07,480 --> 00:56:11,800 or like your guidance of data, the data availability providers 902 00:56:12,320 --> 00:56:15,820 can actually freeze. Your state can freeze the entire 903 00:56:15,820 --> 00:56:19,020 chain, and so your value will become unavailable to you. 904 00:56:19,060 --> 00:56:21,700 You need only a single honest validator, right? 905 00:56:21,700 --> 00:56:24,380 Because you're only one person who kind of makes the data 906 00:56:24,380 --> 00:56:26,700 available. Great question. 907 00:56:26,860 --> 00:56:29,460 This is a big misconception about the data availability 908 00:56:29,460 --> 00:56:34,780 systems. If you have a state transition 909 00:56:34,780 --> 00:56:38,460 which has been authorized by a decentralized set of validators, 910 00:56:39,860 --> 00:56:44,140 and at least one of them is honest, that will apply. 911 00:56:44,570 --> 00:56:47,210 This one honest validator will share the data with you. 912 00:56:47,930 --> 00:56:52,530 However, if the majority of your validator set is compromised, 913 00:56:53,090 --> 00:56:57,330 let's say like 2/3 of the validator set is malicious, then 914 00:56:57,330 --> 00:57:01,530 they will do a state transition without sharing it with any of 915 00:57:01,530 --> 00:57:06,090 the honest validators. So even though you have 1/3 of 916 00:57:06,090 --> 00:57:09,010 the honest validators on the chain, they will never get a 917 00:57:09,010 --> 00:57:11,450 single bit of this data from the malicious parties. 918 00:57:12,970 --> 00:57:16,370 So it's like what matters is like who controls the state 919 00:57:16,370 --> 00:57:22,330 transition, not who controls the data for the honest blocks. 920 00:57:23,050 --> 00:57:25,490 Because if you control the state transition ability, then you can 921 00:57:25,490 --> 00:57:28,490 always make this state transition into this unavailable 922 00:57:28,490 --> 00:57:31,090 state and it doesn't matter that you have like a lot of honest 923 00:57:31,090 --> 00:57:33,490 people on the chain. Okay. 924 00:57:33,490 --> 00:57:37,970 So you need more than 1/3 honest majorities. 925 00:57:38,670 --> 00:57:42,230 The other quorum like the chain can decide is it like one like 926 00:57:42,310 --> 00:57:48,030 50%, two thirds, whatever. But like some quorum this quorum 927 00:57:48,030 --> 00:57:51,830 that decides that yes we can accept the state transition 928 00:57:51,830 --> 00:57:57,230 because we like the the the smart contract on Ethereum has 929 00:57:57,230 --> 00:58:01,230 to make a decision whether this block has data available or not. 930 00:58:02,350 --> 00:58:06,630 And it's it's impossible to look for for this block to for this 931 00:58:06,630 --> 00:58:10,080 contract to tell it. Subjectively, it cannot talk to 932 00:58:10,080 --> 00:58:13,320 all the validators. It cannot make data availability 933 00:58:13,320 --> 00:58:15,040 sampling. Because it's a smart contract, 934 00:58:15,040 --> 00:58:18,080 it can only work with limited amount of data that's been 935 00:58:18,080 --> 00:58:22,120 passed. So the what the contract can 936 00:58:22,120 --> 00:58:24,800 verify is like okay. Do I have enough signatures? 937 00:58:24,800 --> 00:58:27,800 Do I have a quorum of signatures, Let's say 2/3? 938 00:58:28,520 --> 00:58:30,520 It's a limitation of this verification code. 939 00:58:31,560 --> 00:58:33,480 Okay. Yeah, that totally that clears 940 00:58:33,480 --> 00:58:37,400 up my question. So if you look at kind of how. 941 00:58:38,010 --> 00:58:41,890 DK sync and all other L2S are implemented at the moment. 942 00:58:42,250 --> 00:58:45,930 They're all upgradable, usually from a single multi sync, right? 943 00:58:45,930 --> 00:58:47,970 So I totally understand why this is done. 944 00:58:48,210 --> 00:58:51,090 So you need to be able to mitigate potential 945 00:58:51,090 --> 00:58:54,930 vulnerabilities and and on top of that L1 hasn't really 946 00:58:54,930 --> 00:58:58,450 ossified enough, so there might be upgrades on L1 that kind of 947 00:58:58,810 --> 00:59:00,810 might actively break things on L2. 948 00:59:01,650 --> 00:59:05,250 So how, how do you then mitigate kind of? 949 00:59:05,700 --> 00:59:07,780 The risk of compromise key attacks, right? 950 00:59:07,780 --> 00:59:10,940 Because say there's like 20% twenty people on your on your 951 00:59:10,940 --> 00:59:15,300 committee and you need like you know 10 signatures for upgrading 952 00:59:15,300 --> 00:59:19,620 the contract any allowing you to steal funds and so on like 953 00:59:19,900 --> 00:59:22,540 actually ceiling funds not just freezing them. 954 00:59:22,820 --> 00:59:28,060 How do you mitigate that risk? This is a great question and 955 00:59:28,060 --> 00:59:31,380 this is something like if you if you would ask me like how I feel 956 00:59:31,380 --> 00:59:36,590 about this credibility, I would say I feel terrible like we it's 957 00:59:36,590 --> 00:59:39,070 a key sync. The very first version of the 958 00:59:39,070 --> 00:59:41,830 protocol we deployed is of Zicky Sync version one, which is now 959 00:59:41,830 --> 00:59:44,230 called Zicky Sync right? It was completely immutable. 960 00:59:44,990 --> 00:59:47,950 It was immutable with some upgrade period because we could 961 00:59:47,950 --> 00:59:51,110 not tolerate that. Like the idea that some multi 962 00:59:51,110 --> 00:59:54,030 sync control of credibility or the team can control of 963 00:59:54,030 --> 00:59:57,150 credibility and just propose arbitrary changes completely 964 00:59:57,150 --> 01:00:00,990 defeats the idea of this trustless scaling, right? 965 01:00:00,990 --> 01:00:05,080 So like the? That was something we were we 966 01:00:05,080 --> 01:00:09,520 were finding disgusting and then we had to learn the hard way 967 01:00:09,520 --> 01:00:13,520 that, like we are way too early. We have to make the we have to 968 01:00:13,520 --> 01:00:16,320 react to all our abilities because the bugs will be found 969 01:00:16,320 --> 01:00:19,680 in the short term while the system is in developments. 970 01:00:19,680 --> 01:00:23,120 You have to think you have to take a very paranoid defensive 971 01:00:23,360 --> 01:00:27,920 mindset with mechanisms of defense in depth where you have 972 01:00:27,920 --> 01:00:30,480 multiple layers of protection and you should be able to react 973 01:00:30,960 --> 01:00:33,170 react in a timely manner to threats. 974 01:00:33,770 --> 01:00:38,810 So we came up with the idea of the Security Council and since 975 01:00:38,810 --> 01:00:41,810 then it like the the second chain that embraced the Security 976 01:00:41,810 --> 01:00:46,170 Council was Arbitron earlier this year and now it's it's a 977 01:00:46,410 --> 01:00:50,290 it's a broadly popular idea that like most other chains are 978 01:00:50,290 --> 01:00:53,970 embracing and italic and L to be they are making great effort to 979 01:00:54,130 --> 01:00:58,970 to push for it to to a set sign high bar of standards of what 980 01:00:58,970 --> 01:01:01,010 constitutes a true Security Council. 981 01:01:01,430 --> 01:01:04,950 So let's look at how Security Council works. 982 01:01:04,990 --> 01:01:08,510 A-Team should only be able like the core team of any protocol 983 01:01:08,510 --> 01:01:13,990 should only be able to propose a change for the upgrade which 984 01:01:13,990 --> 01:01:17,550 will execute with some time lock so that the users have time to 985 01:01:17,550 --> 01:01:20,190 withdraw from the protocol if they don't like the change or if 986 01:01:20,630 --> 01:01:22,550 I'll try the protocol looks malicious. 987 01:01:23,470 --> 01:01:28,230 Now if you deal with emergency, if there is a open box on your 988 01:01:28,230 --> 01:01:31,190 system and live smart contracts, you want to be able to 989 01:01:31,190 --> 01:01:32,950 accelerate this. And this is where Security 990 01:01:32,950 --> 01:01:38,310 Council would kick in and you would get some external people 991 01:01:38,470 --> 01:01:41,230 may be appointed by the governance of your protocol like 992 01:01:41,230 --> 01:01:46,390 hopefully or ideally a broad set of participants of highly 993 01:01:46,390 --> 01:01:49,750 reputable people from the community from a lot of 994 01:01:49,750 --> 01:01:54,950 different jurisdictions who use off chain cold wallets to 995 01:01:54,950 --> 01:01:57,910 control these keys. So what it gives you is the 996 01:01:57,910 --> 01:02:01,590 protection from a regulatory capture. 997 01:02:01,670 --> 01:02:04,590 Like it's a lot harder to compromise people in different 998 01:02:04,590 --> 01:02:06,710 jurisdictions because like now it has to be something 999 01:02:06,710 --> 01:02:09,470 universal. If if one government goes wrong 1000 01:02:09,550 --> 01:02:13,350 and and tries to like hijack the protocol, they will not be able 1001 01:02:13,350 --> 01:02:15,910 to do it. Like if if if if a single 1002 01:02:15,910 --> 01:02:19,270 company controls the protocol then the government of the 1003 01:02:19,270 --> 01:02:21,510 company where the company is incorporated would come to them 1004 01:02:21,510 --> 01:02:24,750 and say like make this upgrade or or you go to jail or 1005 01:02:24,750 --> 01:02:27,750 something like this right. But if if if we have a like a 1006 01:02:27,750 --> 01:02:32,820 broad set of participants, then it's much less likely because 1007 01:02:32,820 --> 01:02:35,980 it's harder. The second protection it gives 1008 01:02:35,980 --> 01:02:42,220 you is that compromising a lot of cold wallets in hardware 1009 01:02:42,220 --> 01:02:46,420 wallets or air gap machines or something like highly secured is 1010 01:02:46,500 --> 01:02:53,060 a lot harder than compromising the online servers with hot keys 1011 01:02:53,180 --> 01:02:56,910 in memory that are probably running in some cloud providers 1012 01:02:56,910 --> 01:02:59,950 that have access to the Internet that are vulnerable to 0 days. 1013 01:03:00,350 --> 01:03:05,310 To compromise the cold wallets that are not connected to the 1014 01:03:05,310 --> 01:03:09,110 Internet someone would have to go and break into like all of 1015 01:03:09,110 --> 01:03:12,070 the multi participants, which is a little bit harder. 1016 01:03:12,790 --> 01:03:14,790 But it's still not a perfect solution. 1017 01:03:15,470 --> 01:03:21,870 And the perfect solution would be to bypass the need to like to 1018 01:03:22,270 --> 01:03:26,250 withdraw the rights of upgrades from both the team and the 1019 01:03:26,250 --> 01:03:31,570 Security Council altogether. So the I can imagine the world 1020 01:03:31,570 --> 01:03:37,050 where the Security Council appointed by the governance, 1021 01:03:37,330 --> 01:03:41,970 proudly decentralized, highly secured with gold keys, can only 1022 01:03:41,970 --> 01:03:45,130 freeze the protocol for a short period of time if they see an 1023 01:03:45,130 --> 01:03:49,970 emergency, if there is a bug that needs the treatment, they 1024 01:03:49,970 --> 01:03:52,460 should go and do this. And then they should bring this 1025 01:03:52,460 --> 01:03:55,660 question to the protocol governance and the protocol 1026 01:03:55,660 --> 01:03:58,420 governance should decide and then make appropriate changes 1027 01:03:58,420 --> 01:04:00,980 and make the emergency upgrades on the product. 1028 01:04:01,820 --> 01:04:05,700 And then even in this case the question is like what is 1029 01:04:05,700 --> 01:04:07,740 governance? Is it just the majority of the 1030 01:04:07,740 --> 01:04:10,860 top and holders? Is it some broader set of 1031 01:04:10,860 --> 01:04:13,180 participants like I really admire? 1032 01:04:13,220 --> 01:04:16,610 I want to make a shout out to the Optimism team for for doing 1033 01:04:16,650 --> 01:04:19,610 a lot of work on on the on the process of governance like 1034 01:04:19,890 --> 01:04:22,730 elaborating different schemes like they have the idea of the 1035 01:04:22,850 --> 01:04:25,650 House of Citizens, the House House of Token Holders. 1036 01:04:26,050 --> 01:04:31,410 You offer a consensus between both of them, and even then we 1037 01:04:31,410 --> 01:04:33,610 might have some better mechanisms such as like 1038 01:04:34,010 --> 01:04:36,650 eventually bringing up this question to the consensus of 1039 01:04:36,650 --> 01:04:43,380 where one, you know maybe initiating a an upgrade in a way 1040 01:04:43,380 --> 01:04:46,380 that can only be accomplished with the soft fork of layer one 1041 01:04:46,380 --> 01:04:49,780 itself if there is a disagreement between different 1042 01:04:49,780 --> 01:04:53,100 parties of these governing entities. 1043 01:04:53,580 --> 01:04:56,700 So this is a big question which requires a lot more research, 1044 01:04:56,700 --> 01:04:58,220 but I hope I could get something. 1045 01:04:59,900 --> 01:05:01,300 Cool. That was very helpful. 1046 01:05:01,580 --> 01:05:04,780 So one question I think is kind of like very connected to this. 1047 01:05:05,690 --> 01:05:09,690 You mentioned the risk of bugs. I mean, I've also heard of other 1048 01:05:09,690 --> 01:05:12,930 people being quite concerned about this with regards to ZK 1049 01:05:12,930 --> 01:05:16,410 rollups. Can you talk a little bit about 1050 01:05:17,170 --> 01:05:25,090 where are the risks of bugs and what kind of consequences could 1051 01:05:25,090 --> 01:05:27,890 we have if there are maybe bugs in different places? 1052 01:05:28,250 --> 01:05:32,620 Well, all of the rollups are relatively new systems that need 1053 01:05:32,740 --> 01:05:35,460 to be bottle tested for a long period of time with a lot of 1054 01:05:35,460 --> 01:05:38,860 money until we kind of have enough confidence that they are 1055 01:05:38,860 --> 01:05:41,500 secure. The box can happen in various 1056 01:05:41,500 --> 01:05:45,740 places. For ZQ rollups, they're really 1057 01:05:46,060 --> 01:05:49,980 like if you look at the complexity of the systems, the 1058 01:05:49,980 --> 01:05:56,100 complexities is bounded to different isolated components. 1059 01:05:56,660 --> 01:06:02,000 So you could have a back in cryptography potentially. 1060 01:06:02,000 --> 01:06:05,720 Theoretically that could allow you to fake proofs or you could 1061 01:06:05,720 --> 01:06:09,600 have a back in circuits that would allow you to if you have 1062 01:06:09,920 --> 01:06:13,840 like if you are the validator, you can submit any proposal for 1063 01:06:13,840 --> 01:06:16,680 the new block. You could submit a malicious 1064 01:06:16,680 --> 01:06:20,160 block and then fake the proof that this block is actually 1065 01:06:20,160 --> 01:06:22,360 valid, right? If there are box, if you forgot 1066 01:06:22,360 --> 01:06:25,360 some constraints, if some things are missing in the circuit. 1067 01:06:26,200 --> 01:06:30,270 So to mitigate these things it's it's actually a lot easier to do 1068 01:06:30,270 --> 01:06:34,150 insecure labs and let's say an optimistic collapse, because you 1069 01:06:34,310 --> 01:06:38,670 can create redundant systems like the way it works in in all 1070 01:06:38,750 --> 01:06:42,750 mission critical systems today with like live emergencies, 1071 01:06:43,230 --> 01:06:45,390 aviation, nuclear energy and so on. 1072 01:06:45,870 --> 01:06:49,430 You never rely on a single component for security or for 1073 01:06:49,430 --> 01:06:52,550 safety for that matter, like in the aviation you always have 1074 01:06:52,550 --> 01:06:54,710 like multiple engines and multiple sensors. 1075 01:06:55,470 --> 01:06:58,910 The same thing can apply here. You don't want to rely just on 1076 01:06:58,910 --> 01:07:03,910 the validity proofs, you want to do things like 2 FA where you 1077 01:07:03,910 --> 01:07:08,430 need two separate mechanisms. In the case of ZQ roll up for 1078 01:07:08,430 --> 01:07:12,510 example, it would be. First a consensus of the 1079 01:07:12,510 --> 01:07:18,430 validators has to agree on that the block is valid and only then 1080 01:07:18,430 --> 01:07:21,190 they produce the zero Knowledge proofs and Ethereum Contact 1081 01:07:21,190 --> 01:07:24,830 verifies both the signatures of the majority of the validators 1082 01:07:25,470 --> 01:07:28,900 and the easier knowledge proof and only both match. 1083 01:07:28,900 --> 01:07:30,140 Then you make a state transition. 1084 01:07:30,740 --> 01:07:33,500 So now if there is a buck in cryptography it's you. 1085 01:07:33,620 --> 01:07:36,180 In addition to to breaking cryptography, you have to 1086 01:07:36,180 --> 01:07:39,980 compromise the majority of the violators, which is hard because 1087 01:07:39,980 --> 01:07:44,700 most likely they they were honest to begin with and then it 1088 01:07:44,700 --> 01:07:46,140 will be hard. You would you would have to buy 1089 01:07:46,140 --> 01:07:49,260 a lot of stake to be able to get to this critical quorum. 1090 01:07:49,780 --> 01:07:52,900 But then in addition to that, if you introduce some things like 1091 01:07:53,020 --> 01:07:56,480 withdrawal delays as we have in the case sync error for example, 1092 01:07:56,960 --> 01:08:01,320 the delays are withdrawed. The withdrawals are delayed by a 1093 01:08:01,320 --> 01:08:04,480 few hours. In addition to just verifying 1094 01:08:04,480 --> 01:08:09,560 the proof, you could say that you would also need to 1095 01:08:09,560 --> 01:08:12,920 compromise the Security Council who would be able to support the 1096 01:08:12,920 --> 01:08:16,000 problem and freeze the contract before the new malicious state 1097 01:08:16,000 --> 01:08:20,529 transition is compromised, which will bring you to three FA and 1098 01:08:20,529 --> 01:08:22,490 then like you can add one more layer of protection. 1099 01:08:22,490 --> 01:08:24,930 You can say that in addition to the validators and zero 1100 01:08:24,930 --> 01:08:27,970 knowledge proofs and this kind of fraud proof monitoring by the 1101 01:08:27,970 --> 01:08:31,930 Security Council, we would require a trusted execution 1102 01:08:31,930 --> 01:08:35,850 environment like SJX for example, proof that the state 1103 01:08:35,850 --> 01:08:38,770 transition is valid. It would give you like 4 layers 1104 01:08:38,770 --> 01:08:41,770 of protection that you have to bypass and you don't have to 1105 01:08:41,770 --> 01:08:47,370 rely on Intel or or NVIDIA or NVIDIA or other providers for 1106 01:08:47,370 --> 01:08:52,569 this. Like if the SGX proofs become 1107 01:08:52,569 --> 01:08:55,490 unavailable then the governance can always intervene and just 1108 01:08:55,490 --> 01:08:58,210 switch them off. This would be something so you 1109 01:08:58,609 --> 01:09:02,689 would always have kind of a multi stick of several different 1110 01:09:03,130 --> 01:09:07,609 components with growing degree of complexity of breaking that 1111 01:09:08,810 --> 01:09:11,330 for security. Okay, cool. 1112 01:09:11,569 --> 01:09:16,490 Thanks for explaining that. So maybe a final topic we wanted 1113 01:09:16,490 --> 01:09:19,970 to touch on, which is that. One thing that's being discussed 1114 01:09:19,970 --> 01:09:23,370 a lot, which is the sequencer and the decentralization of 1115 01:09:23,370 --> 01:09:28,569 sequencers, I mean it sounds like if I get sort of the ZK 1116 01:09:28,569 --> 01:09:33,290 sync path correctly, right, is that you basically want to have 1117 01:09:33,290 --> 01:09:37,970 the technologies to allow you know, like lots of different 1118 01:09:37,970 --> 01:09:44,250 people to do lots of CK roll ups and to choose to choose sort of. 1119 01:09:45,189 --> 01:09:47,910 Whether they want centralized sequencer or decentralized 1120 01:09:47,910 --> 01:09:50,750 sequencer and maybe different types of parameters. 1121 01:09:51,149 --> 01:09:56,550 So as a result, is that correct? And then for the path of, OK, I 1122 01:09:56,550 --> 01:09:59,590 want to decentralize sequencing solution. 1123 01:10:00,510 --> 01:10:03,550 Are you guys building decentralized sequencer and you 1124 01:10:03,550 --> 01:10:05,430 know how, what does that look like? 1125 01:10:05,870 --> 01:10:10,310 This is a correct statement. We are focused now on the ZK 1126 01:10:10,310 --> 01:10:15,040 stack, so we are which is based on the source code of the key 1127 01:10:15,040 --> 01:10:18,720 sync error. This is a modular framework. 1128 01:10:19,400 --> 01:10:22,080 This is a framework where you can replace different components 1129 01:10:22,560 --> 01:10:27,640 from the sequencer to the data availability layer to the way 1130 01:10:27,640 --> 01:10:29,920 you handle MVV. Like all of this, things are 1131 01:10:29,920 --> 01:10:32,800 going to be customizable for you and you have the full freedom to 1132 01:10:32,800 --> 01:10:35,560 choose what components you use in what way. 1133 01:10:35,560 --> 01:10:40,870 But we have to provide the basic components which some of them we 1134 01:10:40,870 --> 01:10:45,270 are working on at Matter labs, some will be provided by the 1135 01:10:45,270 --> 01:10:49,030 community, some will be provided by the grants program that that 1136 01:10:49,030 --> 01:10:53,070 we we want to initiate. But sequencer is really 1137 01:10:53,070 --> 01:10:57,390 fundamental it's it's one of the most important parts of the of 1138 01:10:57,390 --> 01:11:01,350 the stat and this is something we definitely want for the for 1139 01:11:01,350 --> 01:11:04,110 for error. We don't want error to remain a 1140 01:11:04,110 --> 01:11:05,590 chain with centralized sequencer. 1141 01:11:05,870 --> 01:11:09,510 We want to go to to to decentralize it in all aspects 1142 01:11:10,030 --> 01:11:13,710 as soon as we possibly can. So we are actively working on a 1143 01:11:13,710 --> 01:11:17,830 decentralized consensus. As I said before, we're using 1144 01:11:17,830 --> 01:11:22,710 hot stuff or modification of hot stuff called hotshot for it, 1145 01:11:23,950 --> 01:11:32,950 which gives you a very decent throughput at a very decent 1146 01:11:32,950 --> 01:11:38,430 latency. So for ZK Sync, we always take 1147 01:11:38,430 --> 01:11:48,220 the user needs as the like the north star of where we want the 1148 01:11:48,220 --> 01:11:51,460 Arctic architecture to go like we always architect back from 1149 01:11:51,460 --> 01:11:54,580 the ideal user experience we envision and the ideal user 1150 01:11:54,580 --> 01:11:58,780 experience is that every transaction confirms almost 1151 01:11:58,780 --> 01:12:03,380 instantly like within under one second and it costs like under 1152 01:12:03,380 --> 01:12:07,800 one cent. So that's kind of the the 1153 01:12:07,800 --> 01:12:10,040 utopia, the crypto utopia that we want to build. 1154 01:12:10,520 --> 01:12:13,680 And from this perspective the the consensus has to be fast 1155 01:12:14,160 --> 01:12:16,600 decentralized, but fast enough and low latency enough. 1156 01:12:16,600 --> 01:12:22,120 And HOTSHOT was was meeting this criteria criteria so it became 1157 01:12:22,120 --> 01:12:26,320 our choose. So, so just to clarify this 1158 01:12:26,320 --> 01:12:32,080 here, the consensus here, so it's basically. 1159 01:12:33,310 --> 01:12:36,950 Like, how does that work? Does it basically mean you have 1160 01:12:37,230 --> 01:12:41,910 a kind of like improve mistake that let's say there is someone 1161 01:12:41,910 --> 01:12:45,150 that's kind of like the leader at this point who does the 1162 01:12:45,150 --> 01:12:51,510 sequencing and then a bunch of data together gets passed around 1163 01:12:51,510 --> 01:12:54,350 and others kind of using hot stuff. 1164 01:12:54,550 --> 01:12:59,470 They test the validity or like the correctness of it and and 1165 01:12:59,470 --> 01:13:02,830 then that's confirmed and then you go to the next leader. 1166 01:13:03,450 --> 01:13:07,610 Or is hot stuff just used to basically choose the sequencer 1167 01:13:07,610 --> 01:13:10,930 and then for some point you just have this one party that's a 1168 01:13:10,930 --> 01:13:12,730 sequencer? Or like, how does that work? 1169 01:13:13,650 --> 01:13:18,930 So the blocks are being produced roughly every second and every 1170 01:13:18,930 --> 01:13:25,610 second the leaders decide that and all of the validators reach 1171 01:13:25,610 --> 01:13:30,050 consensus on what's the next block and it's in fault 1172 01:13:30,050 --> 01:13:33,090 tolerance. So like if the leader, if some 1173 01:13:33,090 --> 01:13:38,010 of the participants go down or become unresponsive it will self 1174 01:13:38,010 --> 01:13:41,090 repair quickly. But every second we have a 1175 01:13:41,090 --> 01:13:43,290 decision. Yeah, yeah, Okay. 1176 01:13:43,650 --> 01:13:47,490 And then do you feel like all of these things that are like huge 1177 01:13:47,490 --> 01:13:51,010 topics at the moment on the theory like around the Mev 1178 01:13:51,010 --> 01:13:55,770 pipeline and the proposed builder separation and those 1179 01:13:55,770 --> 01:13:57,950 kind of things? Will Will. 1180 01:13:57,950 --> 01:14:04,230 To what extent will this carry over to like this and the kind 1181 01:14:04,230 --> 01:14:07,030 of decentralized sequencing seeker sync roll ups? 1182 01:14:07,790 --> 01:14:10,030 This is a really, really good question. 1183 01:14:10,270 --> 01:14:12,550 I don't have a definitive answer to it. 1184 01:14:12,550 --> 01:14:15,150 We are in the research phase. We're looking at all the 1185 01:14:15,270 --> 01:14:18,710 different developments there. We're in touch with the Ethereum 1186 01:14:18,710 --> 01:14:21,070 Foundation with with guys building. 1187 01:14:21,590 --> 01:14:23,670 There are really amazing teams out there being shared 1188 01:14:23,670 --> 01:14:27,300 sequencers who think that shared sequencing is is the paradigm. 1189 01:14:27,300 --> 01:14:32,100 Sorry theorem, I don't have a firm conclusion yet like how it 1190 01:14:32,100 --> 01:14:34,740 will work. I have some concerns which which 1191 01:14:34,740 --> 01:14:38,460 I shared with all of them about the centralization of power. 1192 01:14:38,900 --> 01:14:44,500 If we come to to a world where proposal builder separation 1193 01:14:44,500 --> 01:14:48,780 leads to just a few entities essentially building all of the 1194 01:14:48,780 --> 01:14:52,460 blocks and all the chains, I think that's a bit dystopian 1195 01:14:52,460 --> 01:14:55,620 because it will give them a lot of soft power. 1196 01:14:56,180 --> 01:14:59,260 And like you don't want to eventually like to like like 1197 01:14:59,460 --> 01:15:04,860 some Google or Facebook or something like big corporation 1198 01:15:04,860 --> 01:15:09,420 like this to be powering all of the blockchains with nominal 1199 01:15:09,420 --> 01:15:12,660 decentralization through solid-state. 1200 01:15:13,140 --> 01:15:16,700 So we want to design systems that actually encourage 1201 01:15:16,740 --> 01:15:19,380 decentralization in various regards. 1202 01:15:19,380 --> 01:15:24,900 But there is a popular opinion that that might not be possible 1203 01:15:24,900 --> 01:15:29,660 and eventually, because of the complexity of entity extraction 1204 01:15:29,660 --> 01:15:35,740 and the value that you can produce from there, that this 1205 01:15:35,780 --> 01:15:42,100 inherent specialization in for builders will inevitably lead to 1206 01:15:42,100 --> 01:15:45,140 this outcome. I don't want to believe this. 1207 01:15:45,660 --> 01:15:48,300 I want to believe that we will be able to come up with designs 1208 01:15:48,300 --> 01:15:52,620 that actually broadly decentralized the system with a 1209 01:15:52,620 --> 01:15:59,940 lot of individual participants with ways to actually mitigate 1210 01:15:59,940 --> 01:16:05,220 MV and like it to prevent at least toxic MV from happening, 1211 01:16:05,260 --> 01:16:09,380 like targeted MV attacks. I think there are designs out 1212 01:16:09,380 --> 01:16:13,660 there that largely can accomplish this but I've also 1213 01:16:13,660 --> 01:16:19,580 heard concerns of schemes like encrypted mantles that they they 1214 01:16:19,580 --> 01:16:23,660 could lead to other problems leading to like less efficient 1215 01:16:24,740 --> 01:16:27,300 arbitrage on on on such systems and so on. 1216 01:16:27,780 --> 01:16:30,260 I don't have a definitive answer but we have a research team 1217 01:16:30,260 --> 01:16:32,740 focused on this and we will be just trying things out. 1218 01:16:33,180 --> 01:16:36,980 I can promise you that ZK Singh that you know to our core 1219 01:16:36,980 --> 01:16:40,460 various and we we we have not discussed the ZK credo yet but 1220 01:16:40,500 --> 01:16:42,820 this is like I encourage everyone to read and contribute 1221 01:16:42,820 --> 01:16:46,260 to the ZK CREDO which is our mission and philosophy and 1222 01:16:46,260 --> 01:16:49,800 various statement. We will do everything we can and 1223 01:16:49,800 --> 01:16:53,920 and we want our community to enforce it to go in the 1224 01:16:53,920 --> 01:16:56,200 direction of the maximum decentralization and 1225 01:16:56,200 --> 01:17:00,920 trustlessness. And so we will just pick the 1226 01:17:00,920 --> 01:17:05,280 designs for era and I think the community will support it that 1227 01:17:05,280 --> 01:17:08,400 maximize the decentralization and trustlessness and minimize 1228 01:17:08,400 --> 01:17:12,000 Med. But for hyper chains, I'm sure 1229 01:17:12,000 --> 01:17:14,480 that we will see a lot of experimentations and people will 1230 01:17:14,480 --> 01:17:17,900 be trying all the different models with like from going 1231 01:17:18,260 --> 01:17:22,820 maximum MV and then distributing it to the community to trying to 1232 01:17:22,820 --> 01:17:25,740 minimize MV and work with like first conference serve 1233 01:17:25,740 --> 01:17:29,340 principles or encrypted mantles or some other novel approaches 1234 01:17:29,340 --> 01:17:32,060 which I'm not aware of and eventually the market will 1235 01:17:32,060 --> 01:17:36,180 decide what works best. I wish we could go on because 1236 01:17:36,500 --> 01:17:39,860 lots of these actually sound super interesting, but we are 1237 01:17:39,860 --> 01:17:43,020 already way overtime. So we'll just have to have you 1238 01:17:43,020 --> 01:17:45,820 back at some point. Thank you so much for joining 1239 01:17:45,820 --> 01:17:48,380 us, Alex. It was super insightful. 1240 01:17:49,140 --> 01:17:50,260 Thank you. It was my pleasure. 1241 01:17:50,260 --> 01:17:51,540 It was a very interesting conversation. 1242 01:17:51,540 --> 01:17:53,940 Thank you for great question. Thank you so much. 1243 01:17:56,220 --> 01:17:57,940 Thank you for joining us on this week's episode. 1244 01:17:58,340 --> 01:17:59,900 We release new episodes every week. 1245 01:18:00,500 --> 01:18:03,300 You can find and subscribe to the show on iTunes, Spotify, 1246 01:18:03,340 --> 01:18:06,340 YouTube, SoundCloud, or wherever you listen to podcasts. 1247 01:18:06,870 --> 01:18:09,590 And if you have a Google Home or Alexa device, you can tell it To 1248 01:18:09,590 --> 01:18:12,550 listen to the latest episode of the Epicenter podcast, go to 1249 01:18:12,550 --> 01:18:15,710 epicenter.tv, subscribe for a full list of places where you 1250 01:18:15,710 --> 01:18:17,950 can watch and listen. And while you're there, be sure 1251 01:18:17,950 --> 01:18:20,390 to sign up for the newsletter so you get new episodes in your 1252 01:18:20,390 --> 01:18:23,510 inbox as they're released. If you want to interact with us 1253 01:18:23,830 --> 01:18:26,230 guest or other podcast listeners, you can follow us on 1254 01:18:26,230 --> 01:18:28,110 Twitter. And please leave us a review on 1255 01:18:28,110 --> 01:18:29,670 iTunes. It helps people find the show 1256 01:18:29,670 --> 01:18:31,030 and we're always happy to read them. 1257 01:18:31,910 --> 01:18:34,430 So thanks so much and we look forward to being back next week.