1 00:00:00,240 --> 00:00:05,320 My hot take is that all ZK roll up teams are actually just roll 2 00:00:05,320 --> 00:00:08,160 up teams and they should think of themselves as roll up teams, 3 00:00:08,600 --> 00:00:11,680 not ZK team. With the technology we put out 4 00:00:11,680 --> 00:00:14,240 there in SP1, ZK has become a commodity. 5 00:00:14,240 --> 00:00:17,200 It is accessible to every single roll up team out there. 6 00:00:17,560 --> 00:00:20,600 And actually recently we did an integration with OP stack, which 7 00:00:20,600 --> 00:00:24,160 is traditionally an optimistic roll up stack and we made OP 8 00:00:24,200 --> 00:00:26,760 stack into a ZK roll up. The integration is called OP 9 00:00:26,800 --> 00:00:29,880 Succinct and it's like live and running and people can use it. 10 00:00:30,040 --> 00:00:32,840 So if you want to prove some computation, you just write it 11 00:00:32,840 --> 00:00:36,600 in Rust and then you can generate proofs with US P1. 12 00:00:36,880 --> 00:00:39,360 Welcome to Epicenter, the show which talks about the 13 00:00:39,360 --> 00:00:42,120 technologies, projects and people driving decentralization 14 00:00:42,120 --> 00:00:45,040 and the blockchain revolution. I'm Federica Ants and today I'm 15 00:00:45,040 --> 00:00:48,240 speaking with Umar Roy, the Co founder and CEO of Succinct. 16 00:00:48,640 --> 00:00:52,560 Succinct are building a decentralized CKVM and Prover 17 00:00:52,560 --> 00:00:55,840 network. And before we talk with Umar, 18 00:00:55,880 --> 00:00:58,120 let me tell you about our sponsors this week. 19 00:00:58,880 --> 00:01:02,080 This episode is proudly brought to you by Gnosis, a collective 20 00:01:02,080 --> 00:01:04,560 dedicated to advancing a decentralized future. 21 00:01:05,080 --> 00:01:09,280 Gnosis leads innovation with Circles, Gnosis Pay and Metri, 22 00:01:09,360 --> 00:01:11,560 reshaping open banking and money. 23 00:01:11,880 --> 00:01:15,000 With Hashi and Gnosis VPN, they're building a more 24 00:01:15,000 --> 00:01:17,480 resilient, privacy focused Internet. 25 00:01:17,920 --> 00:01:21,320 If you're looking for an L1 to launch your project, Gnosis 26 00:01:21,320 --> 00:01:23,960 Chain offers the same development environment as 27 00:01:23,960 --> 00:01:26,480 Ethereum with lower transaction fees. 28 00:01:26,760 --> 00:01:30,760 It's supported by over 200,000 ballot errors, making Gnosis 29 00:01:30,760 --> 00:01:33,680 Chain a reliable and credibly neutral foundation for your 30 00:01:33,680 --> 00:01:36,960 applications. Gnosis Dow drives Gnosis 31 00:01:36,960 --> 00:01:39,360 governance, where every voice matters. 32 00:01:39,720 --> 00:01:43,000 Join the Gnosis community in the Gnosis Dow forum today. 33 00:01:43,680 --> 00:01:47,680 Deploy on the EVM compatible Gnosis Chain or secure the 34 00:01:47,680 --> 00:01:52,000 network with just one GNO and affordable hardware. 35 00:01:52,400 --> 00:01:56,120 Start your decentralization journey today at gnosis dot IO. 36 00:01:56,520 --> 00:01:59,640 If you're looking to stake your crypto with confidence, look no 37 00:01:59,640 --> 00:02:03,480 further than course one. More than 150,000 delegators, 38 00:02:03,480 --> 00:02:06,600 including institutions like Bit Go, Pantera Capital, and Ledger 39 00:02:06,600 --> 00:02:08,120 Trust Course One with the assets. 40 00:02:08,520 --> 00:02:10,919 They support over 50 block chains and are leaders in 41 00:02:10,919 --> 00:02:14,120 governance on networks like Cosmos, ensuring your stake is 42 00:02:14,120 --> 00:02:17,080 responsibly managed. Thanks to the advanced MEV 43 00:02:17,120 --> 00:02:20,680 research, you can also enjoy the highest staking rewards you can 44 00:02:20,680 --> 00:02:23,400 stake directly from your preferred wallet, set up a white 45 00:02:23,400 --> 00:02:27,160 label note, restake your assets on Eigenia or Symbiotic, or use 46 00:02:27,160 --> 00:02:29,440 the SDK for multi chain staking in your app. 47 00:02:29,920 --> 00:02:33,040 Learn more at Chorus .1 and start staking today. 48 00:02:33,720 --> 00:02:35,600 Uma, thank you so much for coming on. 49 00:02:36,440 --> 00:02:38,960 Thanks for having me. Cool. 50 00:02:39,000 --> 00:02:43,040 Uma, can you tell us a bit about your professional and 51 00:02:43,040 --> 00:02:46,760 educational background before starting succinct? 52 00:02:48,080 --> 00:02:50,720 So I've always done a lot of math. 53 00:02:51,800 --> 00:02:57,160 In high school and college I did a lot of math research and after 54 00:02:57,160 --> 00:03:01,840 school, well, during school I, I studied math and computer 55 00:03:01,840 --> 00:03:07,040 science at MIT and I also got my master's there actually in 56 00:03:07,040 --> 00:03:09,360 machine learning. And after school I was working 57 00:03:09,360 --> 00:03:13,760 in machine learning research at Google Brain, and then after was 58 00:03:13,800 --> 00:03:15,760 at a small start up doing machine learning stuff. 59 00:03:16,720 --> 00:03:20,720 But my interest in math is what originally hooked me into ZK 60 00:03:21,920 --> 00:03:24,560 because obviously it has a lot of math and it's a very math 61 00:03:24,560 --> 00:03:29,000 heavy field. And I found ZK through a friend 62 00:03:29,520 --> 00:03:32,800 who I met at MIT. And yeah, that's kind of like 63 00:03:33,000 --> 00:03:37,600 how my background ties into ZK. Your foray into kind of like 64 00:03:38,680 --> 00:03:43,720 blockchain was mostly prompted by your interest in zero 65 00:03:43,720 --> 00:03:47,920 knowledge stuff. Yeah, that's, that's roughly 66 00:03:47,920 --> 00:03:50,760 correct. I, I'd always been interested in 67 00:03:50,760 --> 00:03:53,880 kind of like the ideas and concepts of blockchain broadly, 68 00:03:53,880 --> 00:03:57,560 not just ZK. But when I finally like learned 69 00:03:57,560 --> 00:04:02,040 about ZK, I kind of that got my interest enough that I realized 70 00:04:02,040 --> 00:04:03,600 I wanted to like build in the space. 71 00:04:05,040 --> 00:04:09,480 What was it about zero knowledge technology that kind of grew in 72 00:04:09,480 --> 00:04:14,200 specifically? Probably like a lot of other 73 00:04:14,200 --> 00:04:17,640 people, I was just really fascinated by the actual 74 00:04:17,640 --> 00:04:20,880 technology. I think ZK is a very magical 75 00:04:20,880 --> 00:04:22,840 concept. Like you can prove to someone 76 00:04:22,840 --> 00:04:26,440 else that a certain computation is true without revealing what 77 00:04:26,440 --> 00:04:29,440 the inputs are. That seems almost like it should 78 00:04:29,440 --> 00:04:33,720 be impossible. And so it was just a puzzle to 79 00:04:33,720 --> 00:04:37,200 me of like how to figuring out, like how that's possible, 80 00:04:37,200 --> 00:04:39,760 understanding the map, understand the cryptography. 81 00:04:40,680 --> 00:04:42,200 And yeah, that's like what really drew me in. 82 00:04:43,280 --> 00:04:45,320 Cool. So you came for you came for the 83 00:04:45,320 --> 00:04:48,720 tech. Tell us about how that kind of 84 00:04:48,720 --> 00:04:51,120 transformed into a vision for Succinct? 85 00:04:53,080 --> 00:04:55,480 Yeah. So we were building in the ZK 86 00:04:55,480 --> 00:05:00,320 space for a while. So I met my Co founder at this 87 00:05:00,320 --> 00:05:04,520 summer residency hosted by Xerox Park, which is this I guess 88 00:05:04,520 --> 00:05:07,960 sister organization to the EF, the Etherium Foundation. 89 00:05:08,840 --> 00:05:11,480 And they were hosting this like kind of Co working over the 90 00:05:11,480 --> 00:05:13,400 summer together. So I met my Co founder there. 91 00:05:13,400 --> 00:05:18,080 We were working on AZK project. Actually it was related to Nosys 92 00:05:18,840 --> 00:05:21,400 and I think maybe that's one of the first times we interacted 93 00:05:21,400 --> 00:05:25,520 was through that. But we are building AZK bridge 94 00:05:25,520 --> 00:05:29,480 from Ethereum to Nosys chain and in particular building a 95 00:05:29,760 --> 00:05:32,320 Ethereum ZK like client. So that was like our first 96 00:05:32,320 --> 00:05:34,640 Orient to the ZK world was building this project. 97 00:05:35,400 --> 00:05:38,240 How did the product offering evolve over time? 98 00:05:39,200 --> 00:05:41,640 So Succinct was started out of that project. 99 00:05:42,960 --> 00:05:45,760 So originally when we started Succinct, we were building AZK 100 00:05:45,760 --> 00:05:50,120 bridge kind of with this end game thesis that the future of 101 00:05:50,120 --> 00:05:52,720 bridging was all going to be ZK like clients. 102 00:05:52,760 --> 00:05:54,760 And I still think that's actually true. 103 00:05:56,520 --> 00:06:00,160 So we were really focused on building this bridge and making 104 00:06:00,160 --> 00:06:03,760 all bridges ZK. We worked on that for maybe like 105 00:06:03,760 --> 00:06:07,160 six months and actually shipped an Ethereum ZK like client and 106 00:06:07,160 --> 00:06:11,040 it got integrated into the Nosus validator set as a ZK validator. 107 00:06:11,560 --> 00:06:14,800 We shipped a few other ZK like clients, but then after some 108 00:06:14,800 --> 00:06:19,560 point we realized that, you know, ZK was too hard. 109 00:06:19,680 --> 00:06:22,560 Like building each of those like clients took, you know, several 110 00:06:22,560 --> 00:06:25,280 months and many engineers and it's very, very complicated. 111 00:06:25,800 --> 00:06:29,520 And we realized that, you know, ZK has a lot of potential, but 112 00:06:29,520 --> 00:06:33,320 if it was always going to be so hard to use, it wasn't, it 113 00:06:33,320 --> 00:06:36,400 wasn't going to go anywhere. And that's what inspired us to 114 00:06:36,400 --> 00:06:39,840 build our ZKVM FP1, which makes ZK really easy. 115 00:06:39,840 --> 00:06:43,680 So instead of spending months, you know, making a like client 116 00:06:43,680 --> 00:06:46,520 and writing these like things called circuits, you just write 117 00:06:47,000 --> 00:06:49,960 normal code and Rust and you still can use ZK. 118 00:06:50,360 --> 00:06:52,680 And yeah, that was evolution from our early days in ZK as 119 00:06:52,680 --> 00:06:55,320 like ZK builders to like building underlying ZK infra 120 00:06:55,320 --> 00:06:57,040 that makes ZK accessible to everyone. 121 00:06:58,120 --> 00:07:02,080 Quick, before we kind of dive into the ZKVM because I have so 122 00:07:02,080 --> 00:07:08,400 many questions as let's kind of briefly clarify kind of what a 123 00:07:08,760 --> 00:07:12,600 ZK like client does. So kind of like it's basically 124 00:07:12,600 --> 00:07:19,720 it's, it's a client that can kind of verify the state of 125 00:07:20,160 --> 00:07:23,680 another blockchain on chain, right. 126 00:07:23,680 --> 00:07:26,800 So kind of can you talk about this a little bit and why, why 127 00:07:26,800 --> 00:07:30,520 you think ZK like client bridges are kind of the end game of 128 00:07:30,520 --> 00:07:32,680 bridges? Yeah. 129 00:07:32,680 --> 00:07:38,720 So a like client is just a protocol to verify the consensus 130 00:07:38,720 --> 00:07:43,080 of a particular chain. And so when you verify the 131 00:07:43,080 --> 00:07:46,400 consensus of a particular chain, you can then you know, 132 00:07:46,400 --> 00:07:49,720 understand if someone has like burned a token on that chain and 133 00:07:49,720 --> 00:07:51,440 then you can mint them a token on the other side. 134 00:07:51,440 --> 00:07:53,000 So kind of like classical bridging. 135 00:07:55,120 --> 00:07:59,880 So AZK like client is just implementing that like client in 136 00:07:59,880 --> 00:08:04,080 a zero knowledge proof and then verifying that proof on chain 137 00:08:04,080 --> 00:08:06,800 instead of verifying like the whole like client functionality. 138 00:08:07,400 --> 00:08:10,000 And the reason you'd want to do this is if you want to run a 139 00:08:10,000 --> 00:08:12,840 like client on Ethereum, it'll be really, really expensive 140 00:08:13,800 --> 00:08:16,400 because you'll have to verify a bunch of signatures, you'll have 141 00:08:16,400 --> 00:08:19,040 to do a bunch of computation. Whereas if you have a ZK like 142 00:08:19,040 --> 00:08:24,400 client, you just verify a proof of that computation and that is 143 00:08:24,400 --> 00:08:28,000 just a lot more gas sufficient. So basically TLDR is a ZK like 144 00:08:28,000 --> 00:08:31,000 client is a way to generate a zero knowledge proof of a like 145 00:08:31,000 --> 00:08:33,960 client that makes it really gas sufficient to use in on chain 146 00:08:33,960 --> 00:08:38,720 contexts for bridging. I think that's, that's, that's a 147 00:08:38,720 --> 00:08:41,480 fantastic summary. So kind of let's move on to the 148 00:08:41,480 --> 00:08:45,800 kind of ZKVM part. So you said that I'm kind of 149 00:08:45,800 --> 00:08:49,560 like building the circuits was really hard. 150 00:08:50,080 --> 00:08:54,160 How, how can we kind of like as someone who's never actually 151 00:08:54,160 --> 00:08:58,160 written a circuit before, how do I go about it? 152 00:08:58,160 --> 00:09:01,960 So kind of, I know what kind of the logic is I kind of want in 153 00:09:01,960 --> 00:09:05,040 that circuit. What do I do? 154 00:09:07,200 --> 00:09:11,240 Yeah. So to take a computation that 155 00:09:11,240 --> 00:09:15,440 you want to generate AZK proof form, you have to write it in a 156 00:09:15,440 --> 00:09:18,760 form that like you can actually do a ZK proof in. 157 00:09:19,200 --> 00:09:22,800 And historically that meant taking your computation and 158 00:09:22,800 --> 00:09:25,800 breaking it down until additions and multiplication. 159 00:09:25,960 --> 00:09:29,080 So it's very primitive. You'd basically use a 160 00:09:29,080 --> 00:09:32,120 specialized language or DSL. There's a bunch of other of 161 00:09:32,120 --> 00:09:35,680 options out there including tools like cercom, which maybe 162 00:09:35,680 --> 00:09:40,120 people have heard of, where you would make a computational graph 163 00:09:40,120 --> 00:09:43,440 out of adds and multiplies that express your computation. 164 00:09:44,920 --> 00:09:48,960 Obviously that's, you know, very, it's not very fun because 165 00:09:48,960 --> 00:09:51,720 you're working with these very basic primitives and very basic 166 00:09:51,720 --> 00:09:54,040 building blocks. And it's similar to like writing 167 00:09:54,040 --> 00:09:57,160 assembly or writing a very very low level language instead of 168 00:09:57,160 --> 00:10:04,480 writing something like Python. Why is it that in order for it 169 00:10:04,480 --> 00:10:07,880 to kind of be incorporated into a into a ZK? 170 00:10:07,880 --> 00:10:11,880 Second, why can you only use additions and multiplications? 171 00:10:13,720 --> 00:10:18,200 Yeah, that's a good question. So the way ZK protocols 172 00:10:18,200 --> 00:10:22,800 generally work is you take your computation and then you encode 173 00:10:22,800 --> 00:10:27,000 it into polynomials and then you prove relationships between the 174 00:10:27,000 --> 00:10:30,480 polynomials. And that's kind of where the 175 00:10:30,480 --> 00:10:32,360 additions and multiplications come from. 176 00:10:32,360 --> 00:10:35,040 Like in polynomial world, you can do additions and 177 00:10:35,040 --> 00:10:38,000 multiplications and you can prove that polynomials are 178 00:10:38,000 --> 00:10:40,840 related to each other by like those operations, I guess. 179 00:10:41,440 --> 00:10:46,240 And so it has to do with like all the underlying math and 180 00:10:46,240 --> 00:10:50,160 cryptography of how ZK actually works and kind of turning your 181 00:10:50,160 --> 00:10:53,400 computation into something as polynomial friendly is the 182 00:10:53,400 --> 00:10:56,760 reason you have to break it down into these very like primitive 183 00:10:58,320 --> 00:11:00,400 relationships, if that makes sense. 184 00:11:01,760 --> 00:11:03,840 I mean, you know, obviously there's a lot more math there 185 00:11:03,840 --> 00:11:06,000 than I could dive into, but maybe that's like a simplified 186 00:11:06,000 --> 00:11:08,840 explanation. I I think that's, that's fair. 187 00:11:08,840 --> 00:11:11,480 Maybe we'll link to some resources in the show notes. 188 00:11:12,720 --> 00:11:20,840 So the ZKVM is my understanding correct that kind of I can put 189 00:11:21,960 --> 00:11:25,960 whatever rust code or piping code or whatever into it and it 190 00:11:25,960 --> 00:11:30,920 did kind of automatically turn it into a ZK second? 191 00:11:32,800 --> 00:11:36,400 So it is correct that you can put any Rust code into it. 192 00:11:36,400 --> 00:11:39,960 So now if you want to prove some computation, you just write it 193 00:11:39,960 --> 00:11:43,720 in Rust and then you can generate proofs with SP1. 194 00:11:44,760 --> 00:11:48,560 You can't do Python because like we, you know, Python's like 195 00:11:48,720 --> 00:11:52,040 interpretive language. But yeah, you can do Ross, which 196 00:11:52,040 --> 00:11:55,280 is like, I guess the most, one of the most common languages 197 00:11:55,280 --> 00:11:59,960 used in blockchain. It doesn't quite turn the code 198 00:11:59,960 --> 00:12:03,520 into a circuit. What it does is it compiles the 199 00:12:03,520 --> 00:12:06,320 code to an instruction set called RISC 5. 200 00:12:06,320 --> 00:12:09,040 So that's like somewhere to EVM, you know, you have a bunch of OP 201 00:12:09,040 --> 00:12:14,360 codes and then we prove the execution of that RISC five of 202 00:12:14,360 --> 00:12:17,280 all those RISC 5 instructions. So we basically prove that like 203 00:12:17,560 --> 00:12:19,920 when you execute the program and all the instructions in the 204 00:12:19,920 --> 00:12:23,880 program correctly that it gives like a certain output and a 205 00:12:23,880 --> 00:12:27,800 certain result. So we have a RISC five circuit 206 00:12:27,920 --> 00:12:30,880 that is responsible for proving the execution of this RISC 5 207 00:12:30,880 --> 00:12:34,800 bytecode and then your program gets run through that circuit, 208 00:12:36,200 --> 00:12:38,200 if that makes sense. So that's we're not turning your 209 00:12:38,200 --> 00:12:40,680 computation into a circuit, we're instead going through this 210 00:12:40,680 --> 00:12:44,360 RISC 5 layer. What's a RISC 5 layer? 211 00:12:46,560 --> 00:12:48,440 RISC 5 is like an instruction set. 212 00:12:48,760 --> 00:12:51,840 So your program gets compiled to a bunch of instructions in a 213 00:12:51,840 --> 00:12:53,840 row. So it might be like do an add, 214 00:12:53,840 --> 00:12:58,280 do a multiply, do a subtract, you know, then do a jump or do a 215 00:12:58,280 --> 00:13:03,400 branch or whatever. So that's like the underlying 216 00:13:03,400 --> 00:13:08,160 instructions of your program. And then we prove that like the 217 00:13:08,160 --> 00:13:11,400 instructions of your program are executed correctly, like in the 218 00:13:11,440 --> 00:13:16,720 correct order and you know, end up touching memory correctly and 219 00:13:16,720 --> 00:13:19,520 stuff like that and having this final output. 220 00:13:20,760 --> 00:13:23,520 For those that are that are familiar with the EVM, it's very 221 00:13:23,520 --> 00:13:26,240 similar. Like you take Solidity, it gets 222 00:13:26,240 --> 00:13:30,080 compiled to EVM by code, which is a bunch of like EVM OP codes. 223 00:13:30,520 --> 00:13:33,160 And then when you run a smart contract, you're just executing 224 00:13:33,160 --> 00:13:35,080 a bunch of EVM op codes in a row. 225 00:13:35,920 --> 00:13:38,240 So it's it's pretty similar mental model. 226 00:13:39,480 --> 00:13:45,600 When you say we prove who was we in this, in this situation? 227 00:13:47,920 --> 00:13:51,720 Yeah, like our Z KB M SP1 is proving the execution of the 228 00:13:51,720 --> 00:13:54,560 RISC 5 code. OK, cool. 229 00:13:54,560 --> 00:13:58,840 So it's it's it's a fully trustless set up, right? 230 00:13:58,840 --> 00:14:01,360 Kind of like it's not you guys proving that. 231 00:14:01,600 --> 00:14:04,400 OK, why hasn't this been done before? 232 00:14:04,400 --> 00:14:10,720 So kind of like it seems like kind of turning it seems like 233 00:14:10,720 --> 00:14:14,880 it's pretty well understood what kind of operations you can kind 234 00:14:14,880 --> 00:14:26,320 of feed into a into a ZK proof. So why, and I assume there's 235 00:14:27,040 --> 00:14:29,960 pretty good cookbooks how to kind of turn whatever you have 236 00:14:29,960 --> 00:14:34,360 into that, why didn't what kind of you build exist before? 237 00:14:36,080 --> 00:14:41,080 Yeah, it's a good question. So I think for a long time 238 00:14:41,080 --> 00:14:44,200 people were really fixated on proving the EVM. 239 00:14:44,200 --> 00:14:47,360 So there was a lot of ZKEVM teams. 240 00:14:47,760 --> 00:14:52,360 And I mean, that makes sense because validity and all the 241 00:14:52,360 --> 00:14:55,880 Ethereum stuff runs in EVM, so people are really fixated on 242 00:14:55,880 --> 00:14:59,440 that particular objective. And then I think also it wasn't 243 00:14:59,440 --> 00:15:05,720 super clear that proving risk 5 would be performance or doable. 244 00:15:05,720 --> 00:15:08,000 Like people thought it would be really slow. 245 00:15:08,720 --> 00:15:11,720 It's not an instruction set that's really designed for ZK. 246 00:15:12,840 --> 00:15:15,360 It's actually a very common instruction set that's used by, 247 00:15:15,680 --> 00:15:18,320 you know, in many other contexts. 248 00:15:18,320 --> 00:15:20,440 So people just didn't think it'd be performant. 249 00:15:20,440 --> 00:15:22,720 They'd be like, sure, you could do this, but it would just be 250 00:15:22,720 --> 00:15:26,560 really slow. And I think 1 of SP1's major 251 00:15:26,560 --> 00:15:31,880 innovations was that we actually showed that it could be fast for 252 00:15:32,080 --> 00:15:35,600 workloads like like clients or roll ups that people care about. 253 00:15:36,880 --> 00:15:39,840 And now there's, I mean, there's a lot of people trying to prove 254 00:15:39,840 --> 00:15:43,000 this risk 5 instruction site these days. 255 00:15:43,000 --> 00:15:48,720 And yeah, so these days there are more people trying to do 256 00:15:48,720 --> 00:15:51,200 that. I think it's worth mentioning 2 257 00:15:51,200 --> 00:15:53,640 teams. One is the Stark War team. 258 00:15:54,720 --> 00:16:00,080 They didn't try to prove risk 5, but they wrote a ZKVM for Cairo, 259 00:16:00,200 --> 00:16:06,680 which is like their instruction thought and it's like a, yeah, 260 00:16:06,680 --> 00:16:09,680 it says instructions said that's optimized for ZK or like 261 00:16:09,680 --> 00:16:12,560 designed for ZK. So they kind of like pioneered 262 00:16:12,560 --> 00:16:16,880 in many ways ZKVMS way back, you know, 5-5 years ago. 263 00:16:17,560 --> 00:16:24,080 And then the Risk Zero team was working on proving risk 5 264 00:16:25,400 --> 00:16:29,600 execution. And then I think our major 265 00:16:29,600 --> 00:16:35,200 contribution was kind of taking RISC 5Z KVMS and making them 266 00:16:35,200 --> 00:16:38,520 really, really performant for Bola and showing that it's 267 00:16:38,520 --> 00:16:42,600 actually like practical to use for a lot of workloads people 268 00:16:42,600 --> 00:16:45,560 care about. Cool. 269 00:16:45,560 --> 00:16:50,280 So I think kind of we've covered the basics of SP1. 270 00:16:50,800 --> 00:16:54,920 The other key part of your offering is the Prover network, 271 00:16:55,200 --> 00:16:57,400 right. So tell us about that and kind 272 00:16:57,400 --> 00:17:00,920 of like how these two intact? Yeah. 273 00:17:00,920 --> 00:17:04,000 So SP one is, you know, an open source project. 274 00:17:04,000 --> 00:17:07,240 You can run SP1 and generate proofs on your laptop. 275 00:17:07,680 --> 00:17:11,160 But I like to tell people that's not really a fun time because 276 00:17:11,160 --> 00:17:12,960 proof generation is very intensive. 277 00:17:13,560 --> 00:17:17,599 And so to actually make it very performant and really cheap, we 278 00:17:17,599 --> 00:17:22,119 have a GPU implementation of SP1 where if you generate proofs on 279 00:17:22,119 --> 00:17:24,200 a GPU, it's much faster and much cheaper. 280 00:17:25,359 --> 00:17:27,720 But obviously I think most people don't want to like set up 281 00:17:27,720 --> 00:17:31,400 that infrastructure themselves. And so our Prover network is a 282 00:17:31,400 --> 00:17:36,360 way for, you know, anyone to outsource proof generation to 283 00:17:36,360 --> 00:17:38,640 the Prover network. So instead of generating proofs 284 00:17:38,640 --> 00:17:42,080 on your laptop, you generate them through the Prover network. 285 00:17:42,240 --> 00:17:45,880 So you send it like, hey, I have a program, here's my inputs. 286 00:17:46,160 --> 00:17:49,440 I want you to generate a proof. And then the Prover network 287 00:17:49,440 --> 00:17:52,600 provides a protocol for anyone in the world to plug in their 288 00:17:52,600 --> 00:17:57,400 GPU and contribute capacity. So it's kind of similar to 289 00:17:57,400 --> 00:18:02,120 mining where like in the past anyone in the world could, you 290 00:18:02,120 --> 00:18:04,960 know, mine Bitcoin blocks through the proof of work 291 00:18:04,960 --> 00:18:08,360 mechanism. We have a similar kind of 292 00:18:09,200 --> 00:18:12,640 concept or architecture where anyone in the world can generate 293 00:18:12,640 --> 00:18:17,200 proofs and like earn transaction fees from the Prover network. 294 00:18:18,800 --> 00:18:21,840 How does the consensus mechanism for the Prover network work? 295 00:18:24,080 --> 00:18:26,440 Yeah, that's like work that's coming out soon. 296 00:18:26,440 --> 00:18:30,120 So we're right now the Prover network doesn't exist. 297 00:18:30,120 --> 00:18:35,840 It's just like a concept we've put out there, but it it it's 298 00:18:35,840 --> 00:18:37,880 not actually like live or running yet. 299 00:18:38,680 --> 00:18:42,600 There's no consensus mechanism for the Prover Network. 300 00:18:42,600 --> 00:18:46,600 There's more like an allocation mechanism for like if there's a 301 00:18:46,600 --> 00:18:49,960 bunch of proofs coming in, who gets the right to generate the 302 00:18:49,960 --> 00:18:51,920 proof and earn the fees from that proof. 303 00:18:52,600 --> 00:18:56,000 So the allocation mechanism that we have is this like auction 304 00:18:56,000 --> 00:19:00,320 style mechanism that we're going to publish some more material on 305 00:19:00,320 --> 00:19:04,720 thin and that's responsible for deciding like you know who gets 306 00:19:04,720 --> 00:19:09,080 to generate the proof and at what clearing price the fees get 307 00:19:09,080 --> 00:19:12,520 paid. What do you envisage as the use 308 00:19:12,520 --> 00:19:18,080 cases for SP1 and kind of the proofs generated by the proof of 309 00:19:18,080 --> 00:19:22,960 net quack? I think I'm really excited about 310 00:19:23,000 --> 00:19:26,560 ZK roll ups in general. I think right now there's a lot 311 00:19:26,560 --> 00:19:31,400 of talk about the Etherium fragmentation and all these 312 00:19:31,400 --> 00:19:34,120 problems that the roll ups can't interoperate and talk to each 313 00:19:34,120 --> 00:19:38,440 other. And I think the biggest flaw of 314 00:19:38,440 --> 00:19:42,240 the optimistic roll up design is that withdrawals and bridging 315 00:19:42,240 --> 00:19:44,760 takes 7 days. And fundamentally, I think that 316 00:19:44,760 --> 00:19:46,840 leads to a lot of this fragmentation and 317 00:19:46,840 --> 00:19:50,680 interoperability issues. So I think ZK is the best way 318 00:19:50,680 --> 00:19:53,640 we're actually going to solve that in the Etherium ecosystem. 319 00:19:54,320 --> 00:19:58,160 Every roll up, I think will be a ZK roll up and they will all be 320 00:19:58,160 --> 00:20:02,040 able to talk to each other via, you know, verifying ZK proofs of 321 00:20:02,040 --> 00:20:05,400 each other's state. And then there will be like 322 00:20:05,400 --> 00:20:08,520 seamless purging at interop. So in the near term I'm most 323 00:20:08,520 --> 00:20:13,360 excited about ZK roll ups using SP1 and turning every roll up 324 00:20:13,360 --> 00:20:16,360 into a ZK roll up. In the longer term, I think 325 00:20:16,360 --> 00:20:19,480 there's a lot of other really exciting applications even 326 00:20:19,520 --> 00:20:22,560 outside of block chains. So for example, there's teams 327 00:20:22,560 --> 00:20:25,800 that are doing ZK e-mail or ZK passport where they basically 328 00:20:25,800 --> 00:20:30,480 prove, you know, passport attestation information or 329 00:20:30,480 --> 00:20:33,000 e-mail information in a zero knowledge proof. 330 00:20:33,280 --> 00:20:35,760 And then you can use that to bridge off changing the on 331 00:20:35,760 --> 00:20:38,840 chain. Or you can kind of even use it 332 00:20:38,840 --> 00:20:41,320 in non block chain context to prove that like you have certain 333 00:20:41,320 --> 00:20:43,400 credentials or your certain nationality. 334 00:20:44,680 --> 00:20:46,280 And I think that's really interesting. 335 00:20:46,280 --> 00:20:51,200 Like basically ZK attestation, ZK identity is pretty exciting. 336 00:20:52,560 --> 00:20:56,200 And then there's a bunch of other types of software broadly 337 00:20:56,200 --> 00:21:00,960 that can be proven ZK that could benefit from verifiability that 338 00:21:00,960 --> 00:21:07,040 I'm also excited about. South, I'm talking about ZK roll 339 00:21:07,040 --> 00:21:11,720 ups. I mean, one of the core tenets 340 00:21:11,720 --> 00:21:16,560 of kind of their existence is that they kind of produce these 341 00:21:16,920 --> 00:21:19,680 ZK proofs. Kind of I earlier kind of got 342 00:21:19,680 --> 00:21:24,200 the impression a little bit that this is infrastructure for 343 00:21:24,640 --> 00:21:29,480 customers of what whatever feather that kind of are not 344 00:21:29,480 --> 00:21:33,520 specialized in ZK or kind of don't want to kind of put in the 345 00:21:33,520 --> 00:21:36,080 effort to kind of build their own ZK infrastructure. 346 00:21:36,280 --> 00:21:38,640 This can't be set for ZK roll ups, right? 347 00:21:38,880 --> 00:21:41,280 So kind of like if you look at the ZK roll ups that are 348 00:21:41,280 --> 00:21:46,680 currently out there, are they interested in kind of using a 349 00:21:46,760 --> 00:21:53,000 commoditized version of of AZK proof generator? 350 00:21:54,760 --> 00:22:00,600 Surprisingly, yes. I think my hot take is that all 351 00:22:00,600 --> 00:22:04,400 ZK roll up teams are actually just roll up teams and they 352 00:22:04,400 --> 00:22:07,960 should think of themselves as roll up teams, not ZK teams. 353 00:22:09,000 --> 00:22:13,280 I think with the technology we put out there in SP1, ZK has 354 00:22:13,280 --> 00:22:16,160 become a commodity. It is accessible to every single 355 00:22:16,160 --> 00:22:19,000 roll up team out there. And actually recently we did an 356 00:22:19,000 --> 00:22:22,040 integration with OP stack, which is traditionally an optimistic 357 00:22:22,040 --> 00:22:26,200 roll up stack and we integrated, we took their state transition 358 00:22:26,200 --> 00:22:29,280 function. We stuck it in SP1 and we made 359 00:22:29,520 --> 00:22:32,960 OP stack into a ZK roll up. It's called the integration is 360 00:22:32,960 --> 00:22:36,120 called OP succinct and it's like live and running and people can 361 00:22:36,120 --> 00:22:40,480 use it. So already we've kind of taken 362 00:22:40,480 --> 00:22:44,120 existing stocks that are non ZK and innovative ZK into them. 363 00:22:44,640 --> 00:22:49,720 And so it's just inevitable that every single roll up will be ZK. 364 00:22:49,720 --> 00:22:53,440 So if you're a ZK roll up team, I think there's a lot to 365 00:22:53,440 --> 00:22:56,640 building a robot that is very, very difficult and very 366 00:22:56,640 --> 00:22:58,320 important. That's not on the technology 367 00:22:58,320 --> 00:23:01,240 side. You know, it's like BD, you 368 00:23:01,240 --> 00:23:04,560 know, exchange integrations, making your ecosystem great, 369 00:23:04,560 --> 00:23:09,320 making your app developers lives great, you know, attracting 370 00:23:09,320 --> 00:23:12,040 liquidity and stuff like that, attracting users. 371 00:23:13,640 --> 00:23:17,360 And I think now that all the roll ups have ZKI, think all the 372 00:23:17,360 --> 00:23:20,360 roll ups should like focus on basically like that more user 373 00:23:20,360 --> 00:23:23,840 facing layer of the stock and just use whatever the easiest 374 00:23:23,880 --> 00:23:27,680 best tool is for ZK, which in this case like sticking you know 375 00:23:27,680 --> 00:23:30,480 your roll up state transition function and SP1 seems like a 376 00:23:30,480 --> 00:23:35,280 pretty good option. If you look at the proofs that 377 00:23:36,960 --> 00:23:42,760 ZK roll ups use, are they in any way geared towards the use case? 378 00:23:42,760 --> 00:23:45,640 Because kind of SP1 is very general purpose, right? 379 00:23:45,640 --> 00:23:48,760 So kind of I would have assumed that kind of like if I were to 380 00:23:48,760 --> 00:23:52,160 build the ZK roll up, I would actually build it in such a way 381 00:23:52,160 --> 00:23:56,360 that it's geared exactly towards my purpose and that would make 382 00:23:56,360 --> 00:24:00,200 it more performing than kind of a general purpose machine. 383 00:24:01,480 --> 00:24:04,680 That's also, yeah, really great question and observation. 384 00:24:04,680 --> 00:24:07,760 So I think historically that is what ZK roll up teams have done. 385 00:24:07,800 --> 00:24:12,520 They like hand coded this specialized custom circuit for 386 00:24:12,520 --> 00:24:16,880 the EVM and for their roll up. There's two interesting things 387 00:24:16,880 --> 00:24:20,440 though. One is actually SP 1 is very, 388 00:24:20,440 --> 00:24:24,560 very performant. So we've actually seen it be 389 00:24:25,120 --> 00:24:28,880 sometimes even more performant than custom solutions that teams 390 00:24:28,880 --> 00:24:31,040 have created. And that's because a lot of 391 00:24:31,040 --> 00:24:34,960 these ZK roll up teams started a few years ago and the the ZK 392 00:24:34,960 --> 00:24:37,200 tech has improved a lot in the meantime. 393 00:24:37,520 --> 00:24:41,880 And also SP 1 is really fast and we have a GPO implementation and 394 00:24:41,880 --> 00:24:45,560 we have this system of like pre compiles that make it very, very 395 00:24:45,560 --> 00:24:49,080 efficient. SO1 surprising fact is that 396 00:24:49,080 --> 00:24:51,680 actually sometimes SP 1 can be more performant than a custom 397 00:24:51,680 --> 00:24:54,960 stack for the EVM. And I think this was even 398 00:24:54,960 --> 00:24:57,640 surprising to us and surprising to other people. 399 00:24:57,640 --> 00:25:00,160 So that's like 1 interesting thing. 400 00:25:00,960 --> 00:25:06,320 The other thing is even if SP 1 is a bit slower, say it's even 401 00:25:06,320 --> 00:25:12,920 like you know, 50% or 25%, you know, more expensive or slower 402 00:25:13,440 --> 00:25:16,680 because you can just take normal code and run it in SP1. 403 00:25:17,560 --> 00:25:20,160 Life in all other dimensions gets a lot better. 404 00:25:20,160 --> 00:25:26,040 So your because you can just reuse existing Rus tooling like 405 00:25:26,040 --> 00:25:30,280 RAF and Rev M and Ethereum notes software because your developers 406 00:25:30,280 --> 00:25:33,040 can update their state transition function whenever 407 00:25:33,040 --> 00:25:36,720 Ethereum upgrades because you kind of have like all this 408 00:25:36,720 --> 00:25:39,880 flexibility and you have really great tooling and it's so easy 409 00:25:39,880 --> 00:25:43,960 to build. I think the cost basically or 410 00:25:43,960 --> 00:25:48,840 sorry, the benefits basically vastly outweigh the costs and so 411 00:25:48,840 --> 00:25:52,800 I think all teams are basically moving towards the ZKVM based 412 00:25:52,800 --> 00:25:55,680 model. OK. 413 00:25:56,360 --> 00:26:00,320 Let's talk about the Prover network in a little bit more 414 00:26:00,320 --> 00:26:02,120 detail. So kind of like in order to kind 415 00:26:02,120 --> 00:26:05,320 of become a Prover, I kind of need specialized hardware. 416 00:26:05,320 --> 00:26:08,240 I get that because kind of like you, you're carrying this 417 00:26:08,240 --> 00:26:13,440 towards GPU's and what else do I need to fulfill to kind of 418 00:26:13,440 --> 00:26:16,800 become part of the Prover network and how do you make sure 419 00:26:17,120 --> 00:26:22,240 that the proven network remains decentralized and incentivized 420 00:26:22,240 --> 00:26:25,840 effectively? Yeah, it's. 421 00:26:26,840 --> 00:26:31,120 So for the Prover network, as you mentioned today, people need 422 00:26:31,120 --> 00:26:33,600 like GPU's to join and run proofs. 423 00:26:33,960 --> 00:26:37,520 And again this our Prover network, like we've written up a 424 00:26:37,520 --> 00:26:39,920 design for it and we're going to be publishing that's it. 425 00:26:39,920 --> 00:26:42,520 And we'll probably have like a test net in the upcoming months 426 00:26:42,520 --> 00:26:45,080 for it. And so we'll be able to like 427 00:26:45,080 --> 00:26:47,480 test out a lot of these ideas and make sure that they actually 428 00:26:47,480 --> 00:26:50,400 work. The mechanism we designed for 429 00:26:50,400 --> 00:26:53,560 the Prover network in terms of allocating who gets what proof 430 00:26:53,560 --> 00:26:56,720 and stuff like that was specially designed to keep 431 00:26:56,720 --> 00:27:00,880 decentralization in mind. So normally you could just to 432 00:27:00,880 --> 00:27:03,560 decide who gets approved, you could allocate it to, you know, 433 00:27:03,680 --> 00:27:06,480 the person who offers to prove it the cheapest or you could 434 00:27:06,480 --> 00:27:08,960 have some mechanism like this that's kind of a straw man. 435 00:27:09,680 --> 00:27:13,560 Our mechanism is specially designed so that it still 436 00:27:13,920 --> 00:27:16,400 maintains decentralization and prevents like prover 437 00:27:16,400 --> 00:27:19,960 concentration. So more concretely, there's kind 438 00:27:19,960 --> 00:27:23,560 of this parameter that you can tune up or down and depending on 439 00:27:23,560 --> 00:27:27,760 what the value of that parameter is, prover, sometimes with some 440 00:27:27,760 --> 00:27:31,240 probability, people who are a little more expensive than the 441 00:27:31,240 --> 00:27:34,000 cheapest prover will still get selected to generate a proof. 442 00:27:34,800 --> 00:27:37,680 And that's like important for making sure that a lot of people 443 00:27:37,680 --> 00:27:40,600 can participate and it just doesn't concentrate towards like 444 00:27:40,680 --> 00:27:42,920 one really big, large, dominant prover. 445 00:27:44,040 --> 00:27:46,280 So yeah, we kept that pretty explicitly in mind when 446 00:27:46,280 --> 00:27:48,720 designing the mechanism for the prover network. 447 00:27:51,840 --> 00:27:57,000 Yeah, that's probably the biggest important thing for it. 448 00:27:58,920 --> 00:28:07,120 This is a very new question, but is the output of the CKVM 449 00:28:07,400 --> 00:28:09,800 deterministic? So kind of like if I put in some 450 00:28:09,800 --> 00:28:12,560 sort of Rus code, will I always get the same output? 451 00:28:14,360 --> 00:28:20,320 Yes, or people should only prove programs that are deterministic. 452 00:28:20,320 --> 00:28:25,920 So yes, that's true. OK, so I can easily verify that 453 00:28:25,920 --> 00:28:31,120 kind of the the quote that I'm getting back from the prover 454 00:28:31,120 --> 00:28:35,240 network is sufficient and correct, right? 455 00:28:36,640 --> 00:28:42,400 Yeah, the whole kind of point of ZK is that you can verify that 456 00:28:42,400 --> 00:28:46,400 the proof and the computation was done correctly in much less 457 00:28:46,400 --> 00:28:49,800 time to redo the computation. So I think that uniquely enables 458 00:28:49,800 --> 00:28:52,480 the Prooper network. There's like no additional trust 459 00:28:52,480 --> 00:28:55,400 assumptions. There's no yeah, there. 460 00:28:55,440 --> 00:28:57,760 There's no additional like trust vectors. 461 00:28:58,320 --> 00:29:02,160 You send it your request for proof, someone generates a proof 462 00:29:02,440 --> 00:29:06,480 and then you can verify that the proof is valid and then the 463 00:29:06,480 --> 00:29:10,200 money gets like sent out to them after the proof gets verified. 464 00:29:11,040 --> 00:29:15,320 So I assume succinct business model is also somewhere in this 465 00:29:15,320 --> 00:29:20,760 incentive layer, right? Yeah, Yeah, that's exactly 466 00:29:20,760 --> 00:29:23,720 right. I think our thesis is that 467 00:29:24,120 --> 00:29:26,720 people will want to use the Prover network because it'll be 468 00:29:26,720 --> 00:29:29,280 much more cheap and much more efficient and much more easy 469 00:29:29,280 --> 00:29:31,600 than, you know, them setting up their own infrastructure. 470 00:29:32,600 --> 00:29:36,560 I think in practice, people that use SP1 today use our cloud 471 00:29:36,560 --> 00:29:38,600 proving service instead of running it themselves. 472 00:29:38,720 --> 00:29:43,280 We basically offer like a, we'd like to call it our Prover 473 00:29:43,280 --> 00:29:45,760 network beta, but really it's just us generating proofs and 474 00:29:45,760 --> 00:29:48,120 sending them back to people. And most people use SP1 through 475 00:29:48,120 --> 00:29:51,080 that because setting up your own infrastructure really sucks. 476 00:29:51,840 --> 00:29:54,120 So we imagine that, you know, people want to generate proofs 477 00:29:54,120 --> 00:29:58,000 and pay for that. And yeah, that, you know, that 478 00:29:58,120 --> 00:30:00,600 those fees will be directed to the Prooper network. 479 00:30:02,280 --> 00:30:06,200 I kind of imagine it actually similar to DA where today, like 480 00:30:06,200 --> 00:30:09,600 if you're a roll up, you pay Ethereum for settlements, you 481 00:30:09,600 --> 00:30:12,120 pay Ethereum for DA 'cause you're posting your transactions 482 00:30:12,120 --> 00:30:14,560 there. And I imagine in the future that 483 00:30:14,560 --> 00:30:20,480 you'll part of each transaction will pay for proving and that 484 00:30:20,480 --> 00:30:22,000 will like go towards our approval network. 485 00:30:24,080 --> 00:30:27,440 When, when you say that that goes towards the prover network, 486 00:30:27,680 --> 00:30:33,280 you, you yourselves, are you a privileged party in that 487 00:30:33,520 --> 00:30:39,360 approver network kind of do you get kind of some basis points of 488 00:30:39,880 --> 00:30:44,120 all transactions that are kind of settled on that prover 489 00:30:44,120 --> 00:30:47,600 network or are you just one of the provers yourselves? 490 00:30:48,520 --> 00:30:53,720 Oh, like our our company, yeah, No, no, I don't think we'll be a 491 00:30:53,720 --> 00:30:57,080 privileged party like it's going to be a decentralized neutral 492 00:30:57,080 --> 00:31:01,720 protocol and we will just participate in it probably is 493 00:31:01,720 --> 00:31:04,040 like approver of last resort basically. 494 00:31:05,720 --> 00:31:08,440 How does it work for you in business times though? 495 00:31:08,480 --> 00:31:13,400 So kind of like if if you're only a proving participant in 496 00:31:13,400 --> 00:31:16,920 your network and you kind of you get the fees that everyone else 497 00:31:17,120 --> 00:31:24,200 who hasn't developed either SP1 or the Prover network also gets. 498 00:31:24,840 --> 00:31:28,480 How is that? How's that work right for you 499 00:31:28,480 --> 00:31:30,960 guys? Yeah. 500 00:31:30,960 --> 00:31:33,760 Well, I think the network will also have some like marketplace 501 00:31:33,760 --> 00:31:37,240 fee for, you know, facilitating kind of this interaction. 502 00:31:37,360 --> 00:31:37,840 Yeah. OK. 503 00:31:38,040 --> 00:31:41,240 So, so that way kind of you, you are kind of your company somehow 504 00:31:41,240 --> 00:31:44,320 is a privileged party and that kind of like you're offering the 505 00:31:44,320 --> 00:31:47,120 marketplace. And kind of like I, I kind of, 506 00:31:47,120 --> 00:31:49,760 if you, if you're working under the assumption that kind of like 507 00:31:49,760 --> 00:31:58,320 these, these CK proofs will be commoditized completely, then 508 00:31:58,320 --> 00:32:00,880 obviously kind of the fees will be kind of like a race to the 509 00:32:00,880 --> 00:32:02,560 bottom. So you kind of you need to be 510 00:32:02,680 --> 00:32:05,600 able to kind of participate and kind of like the entire volume 511 00:32:06,040 --> 00:32:09,800 and kind of make it worth your while, right? 512 00:32:10,920 --> 00:32:13,800 Yeah, I think, yeah, exactly. Like, I think it's like any 513 00:32:13,800 --> 00:32:15,680 other protocol. For example, Lido kind of 514 00:32:15,680 --> 00:32:19,720 facilitates this interaction between people who want to stake 515 00:32:19,720 --> 00:32:22,240 and then also like the professional note operators and 516 00:32:22,240 --> 00:32:26,760 they have a 5% fee to the node operators, 5% fee to their 517 00:32:26,760 --> 00:32:28,520 protocol. I imagine it being pretty 518 00:32:28,520 --> 00:32:29,760 similar. OK. 519 00:32:30,280 --> 00:32:33,360 And So what what blockchain applications are currently 520 00:32:33,360 --> 00:32:37,520 supported by offering you? So you just talked about the OP 521 00:32:37,520 --> 00:32:41,760 succinct offering. Is there is there anything else 522 00:32:41,760 --> 00:32:45,920 or anything you're particularly excited that that that's 523 00:32:45,920 --> 00:32:48,840 launching soon? Yeah. 524 00:32:49,680 --> 00:32:56,400 So two bridges actually run on SP1, the Celestia bridge and the 525 00:32:56,440 --> 00:33:01,880 Avail bridge are like SP1 programs and you know run 526 00:33:01,880 --> 00:33:06,520 through SP1 and you know, our ZK by clients actually on Ethereum 527 00:33:06,520 --> 00:33:08,680 that you know secure pretty big ecosystem. 528 00:33:09,320 --> 00:33:13,240 Our original dream of every bridge being a ZK bridge came 529 00:33:13,240 --> 00:33:17,400 true, but it is through SP1 instead of, you know, our 530 00:33:17,400 --> 00:33:21,280 original approach of handwriting every single program. 531 00:33:21,800 --> 00:33:24,920 So that's pretty cool to see. I'm very excited about the ZK 532 00:33:24,920 --> 00:33:29,400 roll ups and OP succinct. They're a very popular roll up 533 00:33:29,400 --> 00:33:31,120 stock. A lot of people use them like 534 00:33:31,120 --> 00:33:35,800 base Unichain world, world chain as well. 535 00:33:36,080 --> 00:33:41,480 So it's kind of exciting to one day have a path towards all 536 00:33:41,480 --> 00:33:44,440 those ecosystems becoming ZK roll up. 537 00:33:46,080 --> 00:33:48,960 There's also a lot of other people building very cool stuff. 538 00:33:49,360 --> 00:33:53,080 Some in the Bitcoin ecosystem they're building like Bitcoin 539 00:33:53,560 --> 00:33:56,760 roll ups or Bitcoin L twos, some Bitcoin bridging. 540 00:33:58,040 --> 00:34:00,600 There's even some people in Solana that are building with ZK 541 00:34:00,600 --> 00:34:02,680 with their new network extensions. 542 00:34:03,960 --> 00:34:07,920 That's also quite interesting. There's all these application 543 00:34:07,920 --> 00:34:11,760 specific block chains also for like trading that I think are 544 00:34:11,760 --> 00:34:15,679 quite interesting. Basically, I, I have this thesis 545 00:34:15,679 --> 00:34:20,320 that in the long term for very, very popular apps like trading, 546 00:34:20,320 --> 00:34:23,840 it doesn't make sense to have the overhead of a general 547 00:34:23,840 --> 00:34:27,239 purpose execution layer. You're going to have these like 548 00:34:27,239 --> 00:34:30,480 specialized roll ups that are only built for one application 549 00:34:30,480 --> 00:34:32,280 and are hyper, hyper optimized for it. 550 00:34:32,639 --> 00:34:35,000 And some people are building basically these like 551 00:34:35,000 --> 00:34:38,320 decentralized exchanges that are hyper optimized for trading with 552 00:34:38,320 --> 00:34:41,560 us P1. So that's also another cool kind 553 00:34:41,560 --> 00:34:46,239 of category. And then there's stuff outside 554 00:34:46,239 --> 00:34:51,239 of blockchain, like ZK e-mail. Someone made this proof of 555 00:34:51,679 --> 00:34:53,960 driver's license application with SP1. 556 00:34:53,960 --> 00:34:55,639 That was cool. Like you verify your driver's 557 00:34:55,639 --> 00:34:57,880 license and you can reveal information about that with the 558 00:34:57,880 --> 00:35:01,320 ZK proof. So the ZK identity stuff is also 559 00:35:01,320 --> 00:35:05,120 really interesting to me. Yeah, super interesting. 560 00:35:05,680 --> 00:35:11,000 What do you see as kind of the the main bottlenecks in ZK 561 00:35:11,360 --> 00:35:18,680 adoption? I think right now with SP1, ZK 562 00:35:18,680 --> 00:35:22,760 is actually finally really easy. Like in a lot of the protocols 563 00:35:22,760 --> 00:35:27,760 we talked to and work with for them using SP1 is often the 564 00:35:27,760 --> 00:35:30,520 simplest part. It's really building up the rest 565 00:35:30,520 --> 00:35:33,480 of their protocol that's hard. You know, building the on chain 566 00:35:33,480 --> 00:35:37,160 smart contracts, even designing your protocol logic, building 567 00:35:37,160 --> 00:35:38,680 out the front end, stuff like that. 568 00:35:39,280 --> 00:35:44,240 So I think there's this new generation of like ZK native 569 00:35:44,240 --> 00:35:46,800 protocols that are building with ZK from day one. 570 00:35:47,440 --> 00:35:51,440 And actually ZK is the easiest part and getting their entire 571 00:35:51,440 --> 00:35:55,280 protocol to mainnet is kind of like the biggest blocker to them 572 00:35:55,280 --> 00:35:58,720 wanting a lot of proofs. I also think there's some like 573 00:35:59,080 --> 00:36:04,600 kind of technical debt and emotional attachment to the old 574 00:36:04,600 --> 00:36:07,760 way of doing things in the ecosystems as well. 575 00:36:07,960 --> 00:36:11,880 So for example, you know, I think tomorrow every roll up 576 00:36:11,880 --> 00:36:15,120 should be a ZK roll up and all the OP stock chains should 577 00:36:15,200 --> 00:36:19,640 immediately use ZK because it's cheap, it's really fast, it 578 00:36:19,640 --> 00:36:23,120 works. But you know, I think for a lot 579 00:36:23,120 --> 00:36:27,320 of people, like they're used to the optimistic technology or in 580 00:36:27,320 --> 00:36:29,160 many cases they don't even run fall proofs at all. 581 00:36:29,160 --> 00:36:32,000 So they they're just using a multi sig and you know, that's 582 00:36:32,560 --> 00:36:35,440 kind of easy enough. You know, while things are good, 583 00:36:35,480 --> 00:36:38,040 obviously it's really bad when something breaks, but that 584 00:36:38,040 --> 00:36:40,960 happens rarely. So I think ZK is kind of like 585 00:36:41,360 --> 00:36:43,560 it's kind of similar to decentralization in a way. 586 00:36:43,560 --> 00:36:46,040 It's like eating your vegetables like you kind of have to 587 00:36:46,800 --> 00:36:49,720 decentralization is really important when something goes 588 00:36:49,720 --> 00:36:54,520 wrong or there's, you know, some like breakdown in trust of the 589 00:36:54,520 --> 00:36:57,520 centralized actors and that's when you're people are happy 590 00:36:57,520 --> 00:36:59,400 they built a decentralized system, right. 591 00:37:01,440 --> 00:37:04,480 So I think ZK is similar where it's like, so maybe using the 592 00:37:04,480 --> 00:37:07,320 multi CIG is fine 99% of the time, but then there's this 593 00:37:07,400 --> 00:37:10,200 catastrophic tail risk and you really wish you actually did 594 00:37:10,200 --> 00:37:13,840 have full validity proof in those situations. 595 00:37:15,120 --> 00:37:17,440 And so I think as an ecosystem, one of the biggest things today 596 00:37:17,440 --> 00:37:21,160 is like, we're all just, you know, kind of living in the 597 00:37:21,160 --> 00:37:23,520 happy path and living in this world where we don't worry about 598 00:37:23,520 --> 00:37:26,880 those scenarios. And I think in general, there 599 00:37:26,880 --> 00:37:30,440 needs to be like more of a push to like actually having 600 00:37:31,120 --> 00:37:36,480 decentralized verifiable systems that operate that actually kind 601 00:37:36,480 --> 00:37:39,920 of fulfill like the promise of all the stuff that we're doing. 602 00:37:42,080 --> 00:37:46,760 Yeah, no, I I agree. I think people don't like 603 00:37:46,880 --> 00:37:52,440 thinking about the failure modes kind of as long as things are 604 00:37:52,440 --> 00:37:54,840 good, right? Yeah, they don't think about the 605 00:37:54,840 --> 00:37:57,080 failure modes until it's like too late. 606 00:37:58,280 --> 00:38:02,960 Yeah, absolutely. What kind of metrics do do you 607 00:38:02,960 --> 00:38:06,040 look at for succinct to gauge your success? 608 00:38:06,040 --> 00:38:09,120 So kind of like what? What are you optimizing towards? 609 00:38:10,520 --> 00:38:14,280 I think one really concrete metric is just number of proofs 610 00:38:14,680 --> 00:38:18,120 and also like you know, amount of computation. 611 00:38:18,680 --> 00:38:22,360 So we call it like cycles, like how many risk 5 instructions are 612 00:38:22,360 --> 00:38:25,880 we proving? So that's a really fun metric to 613 00:38:25,880 --> 00:38:29,040 look at. I think recently, like in the 614 00:38:29,040 --> 00:38:32,800 past month, we proved like trillions of cycles and that's 615 00:38:32,800 --> 00:38:36,760 been going up into the right very quickly, especially as we 616 00:38:36,760 --> 00:38:38,880 get more and more roll ups using it because they use a lot of 617 00:38:38,880 --> 00:38:41,920 cycles. The other metric I think I 618 00:38:41,920 --> 00:38:46,520 personally care a lot about is like kind of like the quality of 619 00:38:46,520 --> 00:38:48,640 the usage. So it's like, are we 620 00:38:48,800 --> 00:38:51,760 meaningfully moving the ecosystem towards more 621 00:38:51,760 --> 00:38:57,800 verifiable systems and like, you know, more verifiable 622 00:38:57,800 --> 00:39:01,560 applications in general? So for me, Obesisys Sync was 623 00:39:01,560 --> 00:39:05,400 really exciting because it was like an opportunity where you 624 00:39:05,400 --> 00:39:08,960 can now finally see a path for every roll up on Ethereum to be 625 00:39:08,960 --> 00:39:12,560 a ZK roll up. And even though that doesn't 626 00:39:12,560 --> 00:39:16,520 happen like today, it's kind of like the first step and then you 627 00:39:16,520 --> 00:39:19,520 can fill in the dots. So yeah, that's like another 628 00:39:19,520 --> 00:39:22,720 metric. It's like, oh like can this 629 00:39:22,720 --> 00:39:26,640 thing be generalized to like and more instances? 630 00:39:28,400 --> 00:39:31,960 So FP one's open source, right? Yeah. 631 00:39:32,560 --> 00:39:36,280 So as a prover network, what's your Moat kind of like what 632 00:39:36,280 --> 00:39:44,120 stops me from kind of just setting up a second prover 633 00:39:44,120 --> 00:39:50,200 network that kind of just make sure there's a kind of fee raise 634 00:39:50,200 --> 00:39:54,240 to the bottom? Yeah, that's a good question. 635 00:39:54,680 --> 00:39:58,960 I think integrating with a Prover network, there's like a 636 00:39:58,960 --> 00:40:02,800 developer integration cost and developer switching cost. 637 00:40:03,680 --> 00:40:06,520 And then also like all the provers will be connected to our 638 00:40:06,520 --> 00:40:09,120 network and generating proofs with our network. 639 00:40:10,040 --> 00:40:13,600 And so if you want to access kind of all the provers in our 640 00:40:13,600 --> 00:40:18,760 network then and you there, there becomes another competing 641 00:40:18,760 --> 00:40:23,600 network, then you're not going to like want to switch over so. 642 00:40:23,960 --> 00:40:28,800 I think the network itself kind of aggregates both the supply 643 00:40:28,800 --> 00:40:31,520 side, so like all the provers and then also all the demand 644 00:40:31,520 --> 00:40:33,120 side, which is like all the proof for costs. 645 00:40:33,800 --> 00:40:36,880 And then with that there becomes this like flywheel that's like, 646 00:40:37,600 --> 00:40:40,600 you know, the more demand there is and the more supply gets 647 00:40:40,600 --> 00:40:45,320 built out, you know, and then the more supply that gets built 648 00:40:45,320 --> 00:40:47,040 out, proofs get cheaper. So hopefully there's more 649 00:40:47,040 --> 00:40:50,560 demand. And so I think it would, it 650 00:40:50,560 --> 00:40:55,160 would be really difficult for another prover network I think 651 00:40:55,160 --> 00:40:59,480 to come in and compete and like make sure all the provers are 652 00:40:59,480 --> 00:41:02,400 integrated and make sure all the demand also gets routed there 653 00:41:02,400 --> 00:41:06,360 and stuff like that. Which way do you see succinct 654 00:41:06,400 --> 00:41:08,360 developing? So kind of like if you, if you 655 00:41:08,360 --> 00:41:12,680 think about kind of succinct in the next say three to five years 656 00:41:12,680 --> 00:41:16,120 or so, so something inordinately long, kind of like in blockchain 657 00:41:16,120 --> 00:41:22,040 times, where are you going? I think for us, like we just 658 00:41:22,040 --> 00:41:28,320 want ZK to be as widely adopted as possible and making, you 659 00:41:28,320 --> 00:41:30,680 know, as many things verifiable as possible. 660 00:41:31,760 --> 00:41:36,280 I think verifiability is this like very fundamental, new 661 00:41:36,280 --> 00:41:39,960 primitive, and obviously in the context of block chains, it's 662 00:41:40,000 --> 00:41:45,000 very powerful and needed because that's like one of the 663 00:41:45,000 --> 00:41:47,280 fundamental premises is that you're building these like 664 00:41:47,280 --> 00:41:51,240 verifiable, trustless systems. And so for systems to be 665 00:41:51,240 --> 00:41:52,640 trustless, they have to be verifiable. 666 00:41:52,640 --> 00:41:55,440 So I think it's very fundamental to blockchains. 667 00:41:56,040 --> 00:41:59,960 So I really hope it gets adopted in all the blockchain contexts 668 00:42:00,240 --> 00:42:02,080 that it should be. So that's like roll ups, 669 00:42:02,080 --> 00:42:06,360 bridges, stuff like that. But then yeah, beyond that, I 670 00:42:06,360 --> 00:42:10,640 think I'm also really excited about seeing these verifiable 671 00:42:10,640 --> 00:42:15,400 systems more in the real world as well, beyond blockchains. 672 00:42:16,800 --> 00:42:19,760 And I think that will be very, very interesting. 673 00:42:20,680 --> 00:42:24,000 And I think that's uniquely kind of enabled by being able to 674 00:42:24,000 --> 00:42:25,920 write normal code. Like I think it's hard to 675 00:42:25,920 --> 00:42:29,440 imagine that normal people adopting this Decay stuff if 676 00:42:29,440 --> 00:42:32,640 they had to go through all the pain of writing custom circuits 677 00:42:32,640 --> 00:42:35,400 and doing all this cryptography and stuff like that. 678 00:42:35,720 --> 00:42:39,680 But now that you can just take normal Rust code and generate 679 00:42:39,680 --> 00:42:43,720 proofs of it, hopefully that enables a much larger class of 680 00:42:43,720 --> 00:42:45,240 applications to become verifiable. 681 00:42:46,880 --> 00:42:51,480 What new features or improvements can we expect or is 682 00:42:51,480 --> 00:42:54,440 it, I mean, I, I assume kind of the stacks not ossified, right? 683 00:42:54,440 --> 00:42:55,840 Kind of like it'll keep developing. 684 00:42:57,200 --> 00:43:00,040 Yeah. We're, we're always trying to 685 00:43:00,040 --> 00:43:04,720 make it faster and cheaper. So that's like our main series 686 00:43:04,720 --> 00:43:10,400 of improvements is on the proof system side, kind of innovating 687 00:43:10,400 --> 00:43:13,680 and figuring out how to make the underlying cryptography better. 688 00:43:14,680 --> 00:43:17,880 Also in the engineering side, there's a lot more optimizations 689 00:43:17,880 --> 00:43:21,360 that we're always working on to make it faster and cheaper. 690 00:43:22,280 --> 00:43:25,360 So yeah, on SB1 side, that's like our North stars to make it 691 00:43:25,360 --> 00:43:27,040 as fast and as cheap as possible. 692 00:43:28,280 --> 00:43:34,280 And then I think a really big upgrade will be finally having 693 00:43:34,280 --> 00:43:37,040 an actual prover network where anyone in the world can 694 00:43:37,040 --> 00:43:39,880 participate in generating proofs. 695 00:43:41,280 --> 00:43:45,160 And hopefully that also enables SP1 to get better and better as 696 00:43:45,160 --> 00:43:47,480 well, because now it's not just us generating proofs. 697 00:43:47,480 --> 00:43:51,160 It's like harnessing humanities collective intelligence and 698 00:43:51,160 --> 00:43:56,080 optimizing the system. So I kind of view it somewhere 699 00:43:56,080 --> 00:43:59,800 to like mining, where in Bitcoin mining you had this proof of 700 00:43:59,800 --> 00:44:03,520 work game or proof of work puzzle and there became this 701 00:44:03,520 --> 00:44:07,040 global scale hardware build out centre around it, right? 702 00:44:07,280 --> 00:44:11,160 You had so many mining companies that were developing, you know, 703 00:44:11,160 --> 00:44:14,080 their custom ASICS and then also deploying it in data centers 704 00:44:14,080 --> 00:44:16,480 across the world. And it began this like global 705 00:44:16,480 --> 00:44:19,640 movement to optimize computing a Shaw hash function. 706 00:44:20,160 --> 00:44:23,120 And our hope is kind of like by having this prover network and 707 00:44:23,120 --> 00:44:27,200 also setting up this very similar game and objective that, 708 00:44:27,800 --> 00:44:31,840 you know, it'll be like this collective global race to also 709 00:44:31,840 --> 00:44:40,040 improve SP1. If kind of SP1 and ZK tech kind 710 00:44:40,040 --> 00:44:45,320 of gets integrated into other tech that kind of like you're 711 00:44:45,320 --> 00:44:48,320 hoping it will, it will get integrated too. 712 00:44:49,920 --> 00:44:57,000 How will the Internet be different in 5 or 10 years from 713 00:44:57,000 --> 00:45:05,440 now to how it is today? Yeah, I think today, like if you 714 00:45:05,440 --> 00:45:10,440 want verifiability on the Internet, there's two options. 715 00:45:10,600 --> 00:45:13,760 One is you transact with like a decentralized system like 716 00:45:13,800 --> 00:45:15,280 Ethereum or something like this, right? 717 00:45:15,480 --> 00:45:18,160 You have this very expensive, like decentralized consensus 718 00:45:18,480 --> 00:45:22,360 consensus or you have regulation. 719 00:45:22,360 --> 00:45:27,760 So for example, like if I want to get a credit score, there's a 720 00:45:27,760 --> 00:45:31,120 credit scoring agency that is responsible for, you know, 721 00:45:31,120 --> 00:45:34,400 computing my credit score based on a bunch of statistics. 722 00:45:34,840 --> 00:45:38,280 And then they're regulated by the government to make sure that 723 00:45:38,280 --> 00:45:41,200 they're like, not doing anything racist or bad. 724 00:45:42,520 --> 00:45:45,600 And then, yeah, we just have trust and verifiability through 725 00:45:45,600 --> 00:45:50,240 basically regulation or trusting centralized intermediaries. 726 00:45:51,440 --> 00:45:54,280 So I think in a world where verifiability is like very easy 727 00:45:54,280 --> 00:45:57,560 and very ubiquitous, you can imagine instead that the same 728 00:45:57,560 --> 00:46:03,040 credit scoring company instead has to posted DK proof that they 729 00:46:03,040 --> 00:46:06,440 updated everyone's scores in a correct way according to a fair 730 00:46:06,440 --> 00:46:10,440 model that we all agree on is like the correct model. 731 00:46:11,080 --> 00:46:14,160 And instead of having regulation, you basically verify 732 00:46:14,320 --> 00:46:20,120 a cryptographic computation and you can make sure that people 733 00:46:20,120 --> 00:46:25,160 are doing the correct things and like, you know, respecting the 734 00:46:25,160 --> 00:46:26,920 properties you might want of their systems. 735 00:46:27,720 --> 00:46:29,400 So I think that's pretty exciting. 736 00:46:29,400 --> 00:46:33,600 You can just have verifiability in a lot more places and you can 737 00:46:33,600 --> 00:46:37,200 have it enforced with code instead of with like 738 00:46:37,880 --> 00:46:42,040 regulations. So kind of like if you look at 739 00:46:43,000 --> 00:46:48,040 metrics that pertain to the average user, how would they 740 00:46:48,040 --> 00:46:52,520 notice that? Yeah, it's a, that's a good 741 00:46:52,520 --> 00:46:58,360 question. I guess in this credit scoring 742 00:46:58,360 --> 00:47:01,680 example, I think they would probably notice systems becoming 743 00:47:01,720 --> 00:47:07,800 like more transparent. So you have just like more 744 00:47:07,800 --> 00:47:11,720 transparency on like what's actually going on in like all 745 00:47:11,720 --> 00:47:14,320 these currently regulated entities. 746 00:47:14,320 --> 00:47:16,200 And right now you're like trusting that the government is 747 00:47:16,200 --> 00:47:18,840 a reasonable job regulating, but in the future you can check 748 00:47:18,920 --> 00:47:21,720 yourself. So I think you just get a lot 749 00:47:21,720 --> 00:47:24,560 more transparency. And then I think if you have 750 00:47:24,560 --> 00:47:28,600 more verifiability, then you know, it should also be a lot 751 00:47:28,600 --> 00:47:31,480 more efficient, right? Because. 752 00:47:32,840 --> 00:47:35,920 And I think that's also like one of the thesises of like crypto 753 00:47:35,920 --> 00:47:38,160 broadly, right? Is like, OK, now we can have 754 00:47:38,160 --> 00:47:43,600 this like trustless exchange and now we can have like trustless 755 00:47:43,600 --> 00:47:46,800 exchange of like any asset. And that's kind of what lets us 756 00:47:46,800 --> 00:47:50,080 have like all the millions of assets we trade today on chain, 757 00:47:50,080 --> 00:47:52,640 like all the meme coins and like NFTS and stuff like that. 758 00:47:53,440 --> 00:47:55,680 And so you can imagine that like, oh, now that verifiability 759 00:47:55,680 --> 00:48:02,480 is really easy, maybe we have more expressive conditions that 760 00:48:02,480 --> 00:48:05,560 we can use in our day-to-day lives, if that makes sense. 761 00:48:05,560 --> 00:48:08,520 I mean, I guess this is a bit abstract, but I think you just 762 00:48:08,520 --> 00:48:11,080 have more expressivity and then that leads to more efficiency 763 00:48:11,080 --> 00:48:12,960 because you can just like do more complex stuff. 764 00:48:14,640 --> 00:48:17,800 So and tell us about the timeline for the proven network 765 00:48:17,800 --> 00:48:22,680 when, when is the test net going to come live and how can people 766 00:48:22,680 --> 00:48:25,160 find out more about it? How can they be prepared to kind 767 00:48:25,160 --> 00:48:30,920 of take part as the proof us? I think the kind of architecture 768 00:48:30,920 --> 00:48:33,680 and design will be out in like the next few weeks. 769 00:48:35,000 --> 00:48:39,440 And then after that, the test set will probably be out in like 770 00:48:39,480 --> 00:48:43,760 the next few months. We already have like an internal 771 00:48:43,760 --> 00:48:46,360 version working that we're testing out. 772 00:48:46,360 --> 00:48:50,240 So maybe we have like a dev net internally that we use. 773 00:48:50,240 --> 00:48:54,200 But yeah, the test net, that's like people can participate in 774 00:48:54,680 --> 00:48:57,080 in in a full form. I'd be out in like the next few 775 00:48:57,080 --> 00:49:00,240 months. And how do people stay abreast 776 00:49:00,240 --> 00:49:03,360 of developments kind of where, where should they follow you on, 777 00:49:03,360 --> 00:49:05,680 on Twitter or where do we send them? 778 00:49:07,240 --> 00:49:10,880 Yeah, Twitter's great. Just as the same to Labs account 779 00:49:10,880 --> 00:49:14,000 or my personal account is also a good resource. 780 00:49:14,800 --> 00:49:16,040 Cool. Fantastic. 781 00:49:16,040 --> 00:49:20,160 Uma, thank you so much for coming on today and telling us 782 00:49:20,160 --> 00:49:23,560 about the Prover Network and SP1. 783 00:49:23,720 --> 00:49:26,960 It's been a pleasure. Yeah, thanks for having me.