00:05: Anna Rose: Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast, we will be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online. 00:27: This week, Tarun and I catch up with Uma from Succinct. We talk about the different products they have shipped in the last year, from the work they did on ZK bridge infrastructure, the Blobstream X product with Celestia, the Succinct platform, the prover networks, and their recent announcement about SP1. We discuss how all of these products fit together, what prompted their development, how the competitive landscape looks, the role of the provers, sequencers, aggregators of the future, and more. Now before we kick off, I wanted to highlight the ZK Jobs Board for you. There you can find jobs from top teams working in ZK. So if you're looking for your next opportunity in the space, be sure to check it out. And if you're a team looking to find great talent, be sure to add your job there as well. We also have our upcoming ZK Summit event to look out for. It's happening in Athens on April 10th. The event is shaping up. We've been adding speakers to the website and we'll share the schedule there soon. As always, this is invite only and space is limited. There is an application process and you need to apply to be eligible for a ticket. If you've already received an invite to buy your ticket, be sure to secure it. We expect the event to sell out. I've added the link in the show notes if you still want to get an application in. I hope to see you there. Now Tanya will share a little bit about this week's sponsor. 01:41: Tanya: Launching soon, Namada is a proof-of-stake L1 blockchain focused on multi-chain asset-agnostic privacy via a unified set. Namada is natively interoperable with fast finality chains via IBC and with Ethereum using a trust-minimized bridge. Any compatible assets from these ecosystems, whether fungible or non-fungible, can join Namada's unified shielded set, effectively erasing the fragmentation of privacy sets that has limited multi-chain privacy guarantees in the past. By remaining within the shielded set, users can utilize shielded actions to engage privately with applications on various chains, including Ethereum, Osmosis, and Celestia that are not natively private. Namada's unique incentivization is embodied in its shielded set rewards. These rewards function as a bootstrapping tool, rewarding multi-chain users who enhance the overall privacy of Namada participants. Follow Namada on Twitter, @namada, for more information, and join the community on Discord, discord.gg/namada. And now, here's our episode. 02:42: Anna Rose: So today, Tarun and I are here with Uma from Succinct. Welcome back to the show, Uma. 02:47: Uma Roy: Thanks for having me. 02:48: Anna Rose: Hey, Tarun. 02:50: Tarun Chitra: Aloha. Excited to talk about proving networks and more. 02:53: Anna Rose: Yeah. Uma, you've been on the show before. We did an interview about Succinct back in November 2022. So over a year ago, I'm going to link to that in the show notes. In that we do a bit of a background on you and the project, and I think John was on that one as well. We did a quick interview or sort of a casual catch-up interview in July 2023. So this is your third time on the show. For today's episode, what we want to do is a catch-up on Succinct because since you were on in November 2022, the project has released all these different products or initiatives. Back then we were talking all about bridges, but since then there's something called Blobstream X you worked on with Celestia, some sort of developer tooling for ZK, a prover network slash marketplace. And then, yeah, last week, and what kind of prompted this show, was the announcement of SP1. So yeah, I'm really excited to dig into all of this with you. 03:51: Uma Roy: Yeah, for sure. There's been a lot of updates. 03:52: Anna Rose: Quick disclosure, I am an investor in Succinct, as Tarun is as well. 03:58: Tarun Chitra: Yes. 03:58: Anna Rose: When we had you on in November, the main topic was kind of these ZK-like client bridging. And we were talking about Gnosis. I think maybe where we can start is what happened with the bridgework that you were doing, kind of what happened since. 04:18: Uma Roy: It's been really fun. I think, as you mentioned, we've built a lot of stuff and shipped a lot of stuff. So it's also been really busy, especially with our recent releases of the plans for the prover network and also SP1. It's been really exciting to see people finally using it. Especially with SP1, I think the open source community really, really loves it and has been really excited by it. And even internally, I think our team just using our own product has been really exciting because we've kind of left all the hellish circuit stuff behind. So that's also been awesome. 04:56: Anna Rose: Nice. Going back to that episode where you introduced Succinct, at the time you were working on the Gnosis bridge and generally, I mean, we categorize Succinct as a bridge company, a bridge-focused company. Can we talk a little bit about what came out of that time, working on bridges? Did you do other bridges? What stage are they at this point? 05:19: Uma Roy: Yeah, so when we started Succinct, I think John, my co-founder and I, were really interested in ZK broadly and how ZK can be useful to blockchain infrastructure applications, et cetera. And I think bridging at the time was really top of mind for a lot of people because I think the Nomad Hack had just happened that summer and ZK bridging was just becoming to be possible. So we were focused on that. We thought it was a really great application of ZK. So as you mentioned, we had built out this ZK Ethereum-like client for that right now is actually helping secure the Gnosis bridge from Ethereum to Gnosis. And then from that time also came work with Celestia on building a ZK bridge for Celestia to connect Celestia to Ethereum. So we did ZK Tendermint because Celestia is a Cosmos chain and so they have the Tendermint consensus algorithm. And then we've also been working with Avail, which is also a data availability layer and doing a ZK bridge for Avail. They're using Substrate, like the Polkadot SDK, I guess, that has a different consensus mechanism. It's called GRANDPA. And so we built this like ZK Substrate/GRANDPA thing for them. 06:39: I think from November, 2022, which was when I was on to like, I guess last summer, so summer of 2023, I would say we were really focused on building out all these bridges. We obviously didn't end up building a consumer-facing bridge because I think, at the time, doing the ZK stuff was just so difficult. Like we didn't have time to even think about building a consumer-facing bridge on top. We spent all of our head space writing these circuits and writing all this, the ZK stuff that ultimately we were like, ZK will end up in every bridge, but it'll be more like, oh, take all the existing bridges that are out there and then integrate ZK into them as a security mechanism rather than just like only being one ZK bridge. I think that doesn't make that much sense actually. So yeah, that was our big conclusion from that was like, yeah, ZK is awesome, really hard to use, but it'll end up getting adopted by everyone just using it, not us building like the only ZK bridge. 07:40: Anna Rose: Was that at the time an actual idea though? Like when you were doing this, you're building the infrastructure that could power these user-facing bridges, had it crossed your mind to try to launch a bridge project? 07:52: Uma Roy: Yeah, I think even when we started the company, I think John and I really loved ZK. Like that was the thing that was exciting to us. I know a lot of people, they viewed us as a ZK bridge, but I think that's not because we actually were one. I think that was more just like people saw ZK bridge and got excited and were like, oh, Succinct is a ZK bridge. But I think we were always just much more ZK, much more so than bridging. Like ZK is the thing we were really excited about, ZK is like why I got into this space, ZK is like what I wanted to work on. So I wouldn't even ever say that I was the ZK bridge project. 08:23: Anna Rose: Okay. I think I'm definitely guilty of categorizing you guys in the bridge category, apologies. What I am noticing that's interesting is last time, when you were on back in November, you were trying to tell us not to use ZK anymore. Do you remember? It was like, succinctness. 08:42: Uma Roy: Yeah, it's true. We still are not really using the ZK property as much. Yeah, I guess that is the inspiration for the name of the company. 08:49: Anna Rose: Fair. I mean, I know we're going to get into all of the new work coming up, and I totally appreciate that most of it is focused on the succinctness side of SNARKs. But do you think that privacy will be something that you are interested in? Or even in SP1, is privacy one of the things that you can kind of offer? 09:09: Uma Roy: I think privacy is actually still really interesting. So SP1, I think we can pretty trivially add privacy to it. And so I am excited about that. Actually, there was an open source contributor who was trying to generate SP1 proofs in Wasm. They have a PR in our repo so that you can do client-side proving with SP1. So that is definitely something we do want to support. And I think it's very interesting. 09:35: Anna Rose: Nice. All right, so we just talked about some of the kind of infrastructure work that bridges could use, the Ethereum light client and all of these other light clients. I have one question on this, which is more to do with just DA layers. Why does Celestia or Avail need a bridge to Ethereum? Is this work that ended up being put into the Blobstream work? Is it for the actual data availability? Basically, I'm trying to figure out, is this a bridge of a token bridge to Ethereum or is this the DA bridge? Is this bridging their actual offering to Ethereum? 10:09: Uma Roy: Yeah, that's a good question. So for Celestia right now, if you're a DA layer, so if you're a rollup using Celestia or Avail or whatever DA layer, as part of the fraud-proof mechanism or validity-proof mechanism, you need to be able to show this data was posted on Celestia. And so that's why there needs to be this bridge from Celestia to Ethereum so that as part of like, if you're rollup is settling on Ethereum, you have access to information that, oh, this stuff was posted on Celestia or Avail or whatever other DA layer you're using. So that's why they need a bridge, a unidirectional bridge from a DA layer to Ethereum. In Avail's case, they're also using it, I believe, to bridge their native token to Ethereum as well. So they're using our Ethereum light client on Avail and the Avail light client on Ethereum to do bidirectional token bridging as well. But for Celestia, it's just a unidirectional DA bridge. 11:07: Anna Rose: Then is ZK Tendermint, is that kind of the same thing as Blobstream, if it's only that one that you know? Is it the foundation of Blobstream X in some way? 11:19: Uma Roy: Yeah, ZK Tendermint is the core of Blobstream X. And then Blobstream also does some additional stuff on top by hashing all of Celestia's data routes to make it more easily available. So yeah, Blobstream is like a small thing just like on top of ZK Tenderment. 11:35: Anna Rose: Okay. 11:36: Tarun Chitra: So actually one thing I've been hearing about a lot in this whole aggregation layer type thing that people have been talking about is this idea that the DA layer would also store some type of execution proofs. Like you have your DA, the DA maybe goes via something like Blobstream, and then the execution side generates a ZKP that like, hey, this state was used in this function, and this is the output of this function. And then it tells the DA layer, okay, like it writes some proof of execution, like of usage. And I think that this is good because it lets you do this aggregation type thing at the DA side. Is this anything you've been thinking about? Because like a lot of what you're talking about seems almost relevant to doing something like that. So. 12:28: Uma Roy: Interesting. That is like new to me actually. So, I haven't heard of that. I think it would be like, build upon like some of the DA stuff. It sounds like a bit of a generalization of the bridging we're doing right now. But yeah, that is like a new concept to me. 12:44: Tarun Chitra: Okay, cool. I was just wondering, because I feel like we're talking about these one direction, unidirectional bridges, right? I feel like you're missing out on a lot of things you could maybe do if you had bi-directional in the sense of like the DA layers can respond. And so I've been thinking a little bit about applications like that, which would be a lot more efficient if you could have some proofs between the two systems about properties they can't validate about each other. 13:10: Uma Roy: Oh, interesting. Yeah, I see. Yeah, that's definitely possible. Probably would be pretty easy to build with SP1, honestly. 13:17: Tarun Chitra: Well, we need to get to talking about SP1 next. 13:19: Uma Roy: Not to show too hard. Yeah. 13:23: Anna Rose: All right. I don't know if this timing is completely correct, but I know that in my mind, there's Blobstream X, and then there's the SNARK toolkit or this developer tooling. Maybe, I don't know when each of those came out. Because I remember the announcement from Succinct basically being like, there is now this way to kind of easily use these tools. Tell us a little bit about what that is. 13:44: Uma Roy: Yeah, so we had been like working for a while on our original Ethereum light client and then also this light client for Celestia and for Aval. And yeah, the ZK developer experience, even on our own team, like obviously we have a pretty sophisticated team with a lot of expertise and it was just getting super complicated to manage all these circuit deployments. Like we realized, for example, that every time you build a circuit, we generally worked with pretty large circuits, we'd have to spin up a whole new machine, store the artifacts, manually upload them to S3 and do all this really manual stuff. And it was just a really horrible developer experience. And so also at the same time, a lot of random teams would come to us and say, hey, can you write me a circuit for XYZ? And we were just like, we don't have the bandwidth for that, we're a pretty small team, so maybe you can try doing it yourself. And they're like, okay, well, it's too hard to do it ourselves. 14:37: So that's kind of why we built the Succinct platform, which I think is what you're referencing, and we launched that around, I think, November. And it was really this ZK developer tool for people like ourselves or any ZK developer to make it really easy to develop and deploy any ZK application. So it just made it a lot easier where, okay, once I have the circuit, I can go to the platform, I can connect my GitHub repo, and then it takes care of building stuff, like circuits have artifacts, like the prover binary and things like that. So it takes care of all of that infrastructure around actually deploying a ZK app to production. And yeah, that was kind of the inspiration behind it, was born out of a lot of our work on building all these ZK bridges and realizing the ZK developer experience is really bad. And we were trying to fix that with alpha.succinct.xyz, which is our platform. 15:35: Tarun Chitra: One thing I think that is kind of interesting is this does remind me a little bit of to some extent, AI tooling, and I guess you had a tweet about this. So maybe I'm giving you kind of a layup for that. But this idea that like, hey, the people who are building applications or trying to use the systems end up going down the stack. So they start at the top trying to build the application, but then as they try to build multiple applications, they have to keep going down until they're doing sort of the full stack of infrastructure. In some sense, it seems like that was your journey here. You were kind of making different things, some of them you did via circuits, and then you kind of went downstream. So how do you think about the journey of going from building an application using ZK to trying to overall make, you end up building developer tooling and a VM effectively? 16:30: Uma Roy: Yeah, I think that's exactly right. I actually used to do a lot of AI stuff, so I totally agree with Tarun. There's this AI company, Hugging Face, that they were building their own AI chatbot, and then they ended up building a platform really similar to our alpha.succinct.xyz platform, because they realized building and deploying with AI was too hard. And we had a really similar journey, where we just kept on going down the stack to fix more and more problems with ZK. So for example, our platform made our lives a lot easier for building all these bridges. For example, there's a few developers on our team who are focused more on deploying these bridges to production, and they were using our platform and iterating with it. They were kind of the first customers of it, and it's helped them tremendously. Stuff that used to take them a month or something, now takes them an hour, because you can just click a few buttons, and then everything's saved for you. You can see where all your verifiers are deployed on-chain. It's really easy to monitor proofs. It's really easy to see what's going on. And so stuff that used to take them months is just really simple for them now through our platform. 17:43: And then the VM that we're building and the prover network is, I would say, maybe even another layer down the stack in solving the other biggest problem with ZK, which is writing all these circuits is really horrible. You know, just very difficult and requires a lot of specialized expertise. And then with the VM, you can just write Rust and normal code. And so after we built the platform, we were like, okay, this platform is really awesome, it makes it really easy to deploy stuff to production, monitor it, request proofs, really nice APIs, we have like a built-in proof explorer where you can see all the proofs and track everything, which is like really helpful for our customers because they can see like, oh, is there a problem? Like what's going on? But then we were like, okay, the biggest bottleneck to people using this offering is, no one wants to write circuits. Which is totally fair, because it's really difficult. And then we're like, okay, so the answer to that is a VM. And so that's why we were really inspired to build SP1. 18:43: Anna Rose: When you talk about the Succinct platform, alpha.succinct.xyz, I think you said, which systems are actually supported? Which circuits? Is it only limited to the ones that you're working on or is it more general? 18:58: Uma Roy: So it's built really modularly. So it actually supports a bunch of different proof systems right now. It supports Circom, gnark, and Plonky2. A lot of our current stuff's built in Plonky2. So it has really great support for that, but it actually supports a variety of options. And it's pretty easy to add new proof systems to it. And then it's not just our circuits, there's a bunch of teams using it, actually. Last week, I think we also announced Wormhole is using the platform. So they had written their own circuits for their Ethereum light client in Plonky2, and they are deploying it through the platform. I think there is a team from Near using it to build a ZK bridge for NEAR. And then there's some other random applications on it. So there's actually a few different external teams also using it for their own circuits that they've written. 19:43: Anna Rose: Does it have any sort of security analysis of these things, given that people are just going to use the tool to generate the code to do this, I guess? Is there any ever like a concern, like what if there is a problem in any of these? Did you get it audited? 19:58: Uma Roy: Our platform's just infrastructure, so it's not security critical. It's just a method of saving circuit binaries and APIs for requesting proofs and large-scale distributed proving and things like that. Your circuit is what ensures the integrity of what you're proving, if that makes sense, which is independent of our platform. 20:20: Anna Rose: I see, okay. 20:21: Tarun Chitra: So the circuit developer has to go get audited. 20:24: Uma Roy: Yeah, yeah, the circuit developer gets audited. Our platform just helps you deploy whatever. 20:28: Anna Rose: All right. That makes sense. I think I thought of it almost like an end to end, that you go on this and it sort of churns out the entire thing for you, but I guess it's more like it's tooling around a circuit. 20:40: Uma Roy: Yeah, yeah, yeah, exactly. 20:43: Anna Rose: Okay. So then we can move on to the next thing that you guys announced, which was the prover network. I saw that as like a prover marketplace, but yeah, what is the prover network? And you sort of painted a bit of a picture of going down the stack, but how does it actually come... From the succinct platform where you're built like the tooling around it?, why then a network? Actually, let's define it. I don't know if we've talked that much about it on the show. Uma, how would you define the prover network? 21:12: Uma Roy: Okay, maybe it's good to take a step back and think about like, okay, when a proof gets generated, there's actually a bunch of different actors and a bunch of different steps. And we kind of call that like the proof supply chain. I think actually Nick Matthew at Figment wrote an article about it. But basically, you have, of course, your application that's like requesting a proof. And then they're using some sort of proof system to express their logic, whether it's like a circuit or a VM, then they request a proof, then the proof gets generated. And then it gets potentially aggregated and then it lands on-chain in the application. So there's this proof supply chain with a bunch of different actors. And so our platform right now is a very simplified proof supply chain. Like you deploy your circuit on the platform and then when you send requests to the platform, we generate the proofs on our infrastructure, right? So it's kind of like, we are the entire proof supply chain. 22:16: Anna Rose: I see. 22:16: Uma Roy: Now, I think that's not super sustainable because, well, first of all, we could maybe price it, but then like today, I'm just like, oh, I decide some number that's like, hey, your proof is gonna cost this much. And it's not even super clear, especially as the proof supply chain gets a lot more complex. I think, hardware is going to be a really important part of that end game, there's probably even going to be a diversity of hardware providers, like are we going to be the best position to provide proofs at the cheapest prices? No, probably not. Also, for example, if you're an application, do you want to go talk to 20 different hardware providers and figure out who has the best prices or capacity or whatever? I don't think that makes that much sense. And so basically, I kind of view our prover marketplace/network as this protocol and set of standards for taking our platform and making it into a protocol. And it's also a decentralized protocol, which is nice, because a lot of... I think a lot of bigger projects that use us also want decentralization. But it is just like this protocol for having all the people in the proof supply chain kind of coordinate and talk to each other in one place. So that's kind of how I view it, if that makes sense. 23:28: Anna Rose: But you just mentioned that it's bringing, like taking the platform, turning it into a protocol, but do you mean that Succinct platform? Like the one that's building the tooling around circuits? Is that what you meant by platform? Or do you mean something else? 23:40: Uma Roy: Yeah, yeah. I know. Yes, I do mean that. I kind of view our current alpha.succinct.xyz as our prover network alpha actually. Like I think today, if you use alpha.succinct.xyz, you deploy your application there, and then we fulfill all the proofs for you. But over time, like once our prover network and marketplace goes live, you can imagine that there will be this competitive auction for a bunch of different people to provide proofs that are requested through that interface. And so in the fullness of time, I kind of view alpha.succinct.xyz as a deployment interface to our network, if that makes sense. 24:20: Anna Rose: I didn't think of it that way when you described it. Sort of it creates things around a circuit. I've definitely talked to a few different teams doing prover networks, but I don't actually know what the exact thing that is happening, like what part is being proved. I thought it was kind of the whole thing. Like I thought that it was like they sent you the thing that needs to be proved and then you generate the entire proof in the prover network. But if you're using this platform, which from what I understand, like it only generates something around the proof. It's not the full proof. 24:52: Uma Roy: No, no, no. Right now it does generate the proof. Maybe it's best to just start with like what is the prover network doing? The prover network is something where you deploy an application on the prover network. You say like, here is something that will generate a proof. Here is how you can generate a proof. So it's like some proving binary or some sort of circuit artifacts. And then you have this competitive marketplace, auction, whatever mechanism, and you have this set of people who are provers who actually generate the proof. And then it gets verified and then they get paid, right? So that's very simple to understand, right? It's like you're a marketplace where people are sending proof requests and you're matching them with provers who are generating proofs. Our platform makes it easy for people to send proof requests. It's just like a set of... It's like tooling to make it easy to deploy your circuit, send proof requests, whatever. I view our platform as something that makes it easy for anyone to want to prove. Because right now, if you want to send proof requests, there's no unified standards for all that stuff. 25:53: And then right now our platform, we run all this infrastructure and we are generating all the proofs. But that's not necessarily the most sustainable or desirable thing. And so in the fullness of time, when we have a prover network, anyone will be able to generate proofs. And so in that sense, alpha.succinct.xyz is kind of our prover network alpha. Like it's kind of what is live of the network today. And then over time, as we build out more of the protocol and build out the auction mechanism, hopefully with Tarun's great help, we will be able to turn that into a more full-fledged network where anyone can help provide proofs and it provides way better prices for users and things like that. 26:36: Anna Rose: I see. So it's sort of one piece along the chain. In those prover networks, the proof generation, I'm assuming if you are kind of creating a prover network, you're creating almost like the client software, the prover software that a prover would be running? 26:51: Uma Roy: Yeah. 26:51: Anna Rose: Would that be then like a next step for you guys? Like is that what, when you kind of announce a prover network, is that what you still would be building? 26:59: Uma Roy: Yeah, so I think the actual node software that provers in the network run can be pretty minimal. Like basically, if you're a prover, what do you have to do? You have to basically participate in this auction and say, hey, I'm willing to generate a proof for this price. And then you have to be able to download the circuit binaries and artifacts and then actually run them and generate the proof and things like that. And so we will have to build some node software, but I think that part can be fairly minimal. 27:30: Tarun Chitra: Do you think there'll be enough standardization such that the infrastructure costs to the actual provers is like relatively low, or do you think it will be, end up being this type of thing where like, okay, some particular proving systems are extremely bandwidth intensive or extremely compute intensive, but are not memory intensive, some are much more memory intensive. And like me as the prover, participating in the network, I might get a request from all these different particular systems, and then I effectively have to have multiple different types of infrastructure or hardware to generate them. How do you think about the homogeneity versus heterogeneity of the networks over time? Because I think that that's sort of obviously an important factor. 28:15: Uma Roy: Yeah, that's a really great question. So I think it might end up looking somewhat heterogeneous, actually. But I think the way we've been thinking about architecting it is very similar to how EigenLayer has architected their AVSs, where if you're a node operator participating in EigenLayer, you can opt into which AVSs you run. So you only choose like, hey, I'm going to run these X services because it makes sense for me. And I think nodes, like provers in our network will be really similar. You can say, hey, I'm cool generating Blobstream proofs, I'm cool generating the Avail proofs, I'm cool generating this other proof, and that's all I do, and I just participate only in those. You could also have really specialized provers that are like, hey, my hardware is best suited for VMs, like SP1, I'm just gonna participate in that. So I think it will... It might end up being pretty heterogeneous, but I think that's actually okay because it's opt-in, and it's just like a marketplace, right? So that's fine, right? As long as you induce competition amongst the people who are participating, it's fine if not everyone's participating in every single proof. 29:27: Anna Rose: Can we talk a little bit about those auctions? Kind of where are you at in your thinking around that? Is that something like the game of the marketplace, almost the incentives, making sure that the people who are doing these proofs can actually earn enough revenue to cover, at least cover their costs, hopefully make something? Yeah, how are you thinking about that? I mean, I'm guessing you have to sort of pre-define it, pre-think out a lot of the nuance of that. 29:52: Uma Roy: Yeah, so we've definitely put a little bit of thought into how to design a great auction. I've actually talked with Tarun a little bit about it and his other collaborator, Kay, as well. And also talked a little bit about it with all of Tarun's like mechanism design auction people, which has been a lot of fun. So we've started thinking about it. I think there's like... You have to be pretty careful with how you design the mechanism, obviously. So yeah, in short, we've started thinking about it, but I think we're hoping to collaborate with a lot of really great people who have a lot more expertise in auction design and stuff like that, to make it really robust for the long term. But we also might just start with something simple and then iterate. 30:36: Tarun Chitra: I think the interesting question is if you have something like what you talked about where people opt in and out of particular services, can you just have per service auctions or per type auctions, or almost like if I think about like nodes on AWS or Google Cloud, like there's like preemptible prices for each type or and sort of that's like the implicit auction for each type. Or do I need to actually do something across the different types because like, oh, I'm proving... I'm doing aggregation across multiple networks, right? This is also maybe slight tangent why I've been trying to understand all these people talking about these. I think Polygon in particular has been talking about these aggregation type of things. 31:23: Anna Rose: All of them have it, right? 31:24: Tarun Chitra: Yeah, yeah. And like aggregating over multiple rollups. And I do think you run into this issue, at least of what I'm talking about, where you actually make the economics a lot more complicated for that, versus the single node one. And I think that's... This heterogeneous versus homogeneous question is fundamental to that in a lot of ways. 31:43: Uma Roy: Yeah, that's really interesting. Yeah, I think it would be a lot easier if everything was homogeneous, for sure. But I just think, I mean, our opinion, and this also kind of informs like our SP1 design and stuff is like, in the fullness of time, it's just not necessarily super sustainable to be like, this is the only proof system you'll use, or like, this is the only VM you'll use. Like ZK is just so full of innovation and it goes so quickly that like, that's why on our platform and also our prover network, we're supporting everything. So we want to support all these different proof systems. We want to have a mechanism that's robust to this heterogeneity, I guess. Because I think that's like the most sustainable way to design it. I think the auction will probably in its simplest form just look like per type, kind of like what you said, like AWS has spot pricing just per CPU type. And I think that should actually work reasonably well. But yeah, I think it is an interesting question, whether there's something more optimal to do. 32:49: Anna Rose: One thought that I've been having around the prover network, prover marketplace kind of concept has been the role of the shared sequencer. The shared sequencer story says, and this sort of speaks to what you're saying, Tarun, like that's the... I think the, what do you call it, accumulator? Accumulation? 33:06: Tarun Chitra: Aggregation. 33:07: Anna Rose: The aggregation. So to me, that's sort of a shared sequencer's level, right? Is that kind of what you'd also call it? 33:15: Tarun Chitra: Yeah, I actually think this is going to be one of these very weird things where the terminology for what a sequencer is is going to get unbundled over time. Because like right now the sequencer is the single point and these aggregation things are like, hey, I have a sequencer sequencing rollup 569, but this sequencer is not a powerful enough sequencer, like it's not sequencing OP or ARB mainnet, and now it's getting aggregated with the OP and ARB mainnet sequencer. So like all these designs for either shared or decentralized sequencers are kind of implicit in all of them, like unbundling the roles, the tasks that a sequencer does into sub... It's kind of substituent jobs. And I think we're going to get words where like sequencer will equal the union of the set of tasks. 34:00: Anna Rose: All of them. 34:01: Tarun Chitra: And each thing will be some subset. 34:03: Anna Rose: So like a sequencer... This is why, because I was trying to think like who will be doing the proofs for the rollups. I'm assuming the sequencers are running the proving node software as well. And then you're talking about these nodes choosing which prover software, but then they're also in this sequencer hierarchy. But Tarun, do you think there will be a meta-sequencer eventually that emerges, some sort of Mecca, I don't know what you call this, but like the Power Ranger of all of these tools somehow. 34:40: Tarun Chitra: The Power Ranger. Wow. 34:44: Anna Rose: By the way, that's a weird reference. That's like after my time. I was too old for Power Rangers. 34:49: Tarun Chitra: I think I was exactly the time of Power Rangers when I was like four or five. If this aggregation type of thing is the final state of the best trade-off when you have heterogeneous demands, when I say heterogeneous demands, I mean, let's take Solana as one type of demand network, right? Of like people want low latency and sort of are willing to take more variance in their fees, versus say like Ethereum mainnet, which if it's mainly just settlement plus some very large trades, settling like Uniswap XL trades or something. And then Layer 2s, which have a lot of demand, they maybe have latency constraints, but they're gonna be very heterogeneous, right? Like Base is going to be a very different rollup than like Farcaster chain, which is going to be very different than that. Right? If you just look at their loads, they're going to look very different, right? So I think if you believe in the long run that everything will just be aggregated ZKPs, then I think the final boss is kind of what Uma was talking about, of like this network of people who are generating the proofs and then part of the network is assigned to do the aggregation, part of the network is assigned to do the individual things. And you stake and you get allocated to each of those, and the final boss is just like that network. And so, there's a world in which that could be the end state, if this kind of aggregation view of the world is true. It's definitely something that feels like the final boss, but I don't know how close we are. But Uma probably has a much better prediction about that. 36:23: Uma Roy: No, we're close. We're close Tarun. No, I so agree with you. I feel like in this modular thesis, like modular stack, there's going to be sequencing, which is just ordering. Even if you look at Espresso's docs, or other decentralized sequencers, they're just doing ordering. They're not doing any proving. Those nodes are optimized for super high throughput... Like let's just order stuff. Then, okay, now let's prove all the stuff that's been ordered, and that's going to be like, going through this proving network, right? And so then the proving network is going to coordinate like, okay, who are the hardware providers and who are these operators who are actually gonna be generating these proofs? As Tarun said exactly, aggregation is just another job type on the proving network. It's just like, hey, now we have a task that requires an aggregation proof. So that will get coordinated all on the proving network, and then it gets settled on Ethereum or whatever other chain is being used. Maybe the DA is posted on a separate layer. So yeah, I think it'll be sequencing, proving, settlement, DA is kind of the ultimate stack. 37:29: Anna Rose: But this is the thing is, going back to that concept of an agent, this is sort of the way we think about it, like a prover, a sequencer. I imagine that's still being one entity in a way. Or do you guys see that as truly you go through this marketplace, and then this marketplace, and then this marketplace is all different entities running these agents? Or I'm speaking a little bit because of the ZK validator. We're just thinking from the validator's perspective, as we explore this kind of stuff, we sort of imagine we could run a lot of these things at the same time. Maybe there's teams that build, or maybe the teams that are kind of developing this build, like a combo sequencer, prover, DA, check, I don't know, all of that. I guess I'm trying to figure out, is there a reason one would wanna separate them, or do you want to put them together? 38:18: Tarun Chitra: No, you can imagine a network where you're like... Imagine a proof-of-stake network where we stake some assets on the final settlement chain. Say we're restaking ETH or restaking ETH or locking ETH into a contract. And the staking network takes, let's say there's like 100 people participating with each different varying amounts, it samples them randomly based on the amount of stake they have and assigns them to a category. So it doesn't just randomly choose a leader for validating the whole block, it chooses a leader for the prover, a leader for the aggregation part, a leader for the DA, whatever. Getting that right is hard, right? Because you've turned this one-dimensional selection problem into a portfolio selection thing, right? Like I have to be fair to choose each of these tasks. But the idea is still, you could imagine this world of doing proof-of-stake where you're actually picking multiple classes of these agents assigning them for an epoch or... And the other thing that's important, I think, in the sequencer world, that people don't think about as much in the Layer 1 world is that in the sequencer world, you actually don't really need to be constrained to picking a new leader every block. You can play with the time element a lot more because you have the fraud and I mean, you should have the fraud and verifiability guarantees. So you could have a longer epoch. So someone gets picked for a week to be the sequencer, right? And I think the two dimensions you have to play with in these kind of what these sort of modular networks will look like is A, how do I... Can I convince people to stake a single asset? And then based on that single asset stake, you get assigned to each of these tasks that you have to be able to do. And maybe you indicate that like, maybe I don't have proving hardware, so when I stake, I opt out of being selected to be the leader for proving. I'm only the leader for DA and being a normal proposer. You could imagine a network allows you to express that preference. And then you get selected, like sortition style. But the thing is, I think there's going to be two dimensions. One is the set of tasks, like fail date block aggregate proof. 40:24: Anna Rose: Sequencer, prover. Yeah. 40:25: Tarun Chitra: And the other is time. Like how long... What's my lease? Like when I get selected, what's my lease on that? If you think about the normal cloud computing world, that is how you pay for services, right? Like I rent a GPU node and it's only hourly or I rent a FPGA node and it's like you have to commit to at least six hours, right? Like a lot of these microservices and miniservices, which are the sort of thing that inspired the modular world, they already do this type of stuff. It's just that they don't have to do this thing where they pick, they randomly assign people to the task to be fair, which is, that's where it's different in this world. 41:03: Anna Rose: Yeah. And that in their case, they're providing the service based on those kinds of dimensions. But in this case, you're picking the agent to provide the service, and they get compensated. 41:15: Tarun Chitra: Exactly, yeah. For each of the different subsets of services. 41:19: Anna Rose: That's interesting to think about. 41:21: Tarun Chitra: So I think that's the final boss. The question is, will there be a single network to rule them all in that world? And arguably, restaking is the closest thing to that, because you can reuse ETH for doing all the services. In some weird shape and form, it actually kind of is the closest to that final piece. 41:40: Anna Rose: Interesting. Okay, so I want us to also talk about sort of the announcement that prompted this interview, SP1. When I saw that, and I also had seen all of these other announcements, I was like, I think it's a really good moment to have Uma back on the show to go over it. Let's talk about what SP1 is and how that relates. And this is maybe where it's actually, I've had a bit of a hard time understanding how it relates to the other work that you've done. So yeah, what is SP1? 42:10: Uma Roy: Yeah, so SP1 is a 100% open source ZKVM that in short, if you want to use ZK, you can just write Rust and then you get a proof. More technically what SP1 is, is it is a RISC-V ZKVM. Yeah, it has really state of the art performance for a lot of technical reasons I can get into. And yeah, that's kind of like what it enables. And yeah, I think it's been very exciting for the open source community, for its performance benefits, for a lot of different things. And yeah, it's something that we're building at Succinct and it will plug into our prover network eventually. Like that will eventually be the best way to use SP1. So yeah, I was happy to talk about that connection because I think that has not been super obvious to people. 43:00: Anna Rose: Yeah, I thought, to me it was kind of like, the announcements came and they seemed... I actually had trouble linking them together. I think you've made a really good connection now for me from the Succinct platform to the prover network. And I mean, I guess I can imagine this connection, which is like with a really powerful, really like if a lot of proofs are being generated on a ZKVM using Rust, all of a sudden the volume is there to be able to have a prover network, which would be like, yeah, you wouldn't want to then be doing all those proofs yourself. But it's almost like you did it in a funny way. The prover network comes before the thing that would use it. The SP1 is using the prover network. Am I right? Is that the connection point? 43:44: Uma Roy: Yeah, yeah. I think the prover network is the base layer that powers everything. And then right now, the demand for the prover network, it's just too hard to write a circuit to want a proof. Right now, even for us, to get to the point where we are consistently wanting proofs, we had to do this horrible, terrible three-month, four-month circuit development. And now with SP1, we can just write Rust in an afternoon, and then now we just want proofs, like a stream of proofs for our application. So that's kind of how we view SP1. 44:16: Anna Rose: It creates demand. 44:17: Uma Roy: Yeah, it's creating demand for the network and making ZK developers' lives easier. And also, maybe 1000Xing like the total number of developers that can use ZK. 44:30: Anna Rose: Totally. 44:30: Uma Roy: Honestly, probably more than 1000Xing. Like anyone knows Rust that they can use... 44:34: Tarun Chitra: I mean, to be fair, let's just do some back of the envelope math. The number of people who've probably written a ZK circuit is probably under 200, would you say? 44:42: Anna Rose: More now. Maybe... 44:44: Tarun Chitra: Okay 500. 44:45: Uma Roy: I think it's more now, but you're definitely under a thousand. 44:47: Anna Rose: Yeah. 44:47: Tarun Chitra: Under a thousand. Okay. So 1000X means you want a million ZK developers. I just want to give you concrete numbers to these claims. All right? 44:56: Uma Roy: You're like, how many people do you think know Rust? 45:00: Tarun Chitra: That's got to be in the millions. So yeah, yeah, yeah, yeah, yeah. That'a gonna be probably a million, right? 45:02: Anna Rose: Yeah, yeah. No, I think a thousand's right. 45:04: Tarun Chitra: Yeah, so maybe a 1000X. Yeah, I think it's just worth sometimes sanity checking these numbers. Now I'm convinced. 45:12: Anna Rose: Crazy. All right. So SP1, ZKVM, RISC-V under the hood. I think we should mention that there is another project. I am an investor in that project. Tarun, I don't know if you are. 45:23: Tarun Chitra: Very tiny investor. 45:24: Anna Rose: Okay. So this is RISC Zero. So RISC Zero has been on the show a couple times. They have talked about the RISC-V concept. To me, they definitely pioneered that idea of you can use Rust as is. Would you say is SP1 very similar to RISC Zero? 45:40: Uma Roy: Yeah, I think it's interesting because we launched this, and I think a lot of people are like, oh, it's so competitive, whatever. I think for us, honestly, we really view SP1 as this open-source, public good that hopefully can be positive sum for ZK. Because I think we just need more than 1,000 people to be able to use ZK, if that makes sense. So I don't view it as extremely directly competitive. It is very similar. Now, the reason we built it is that RISC Zero, not all their stuff is open source. So in fact, the core logic of what are the constraints and blah, blah, blah is actually a closed source. They have this, I think it's called Zergen compiler that is closed source, where they write all the logic of the VM. And then what's open source is this auto-generated, the compiled version is all open source, but it's not modifiable by any external team. And so for us, we were really curious about ZKVMs. We really wanted to use one even internally, but for us, because we couldn't modify RISC Zero, it was just a non-starter to even think about using it because it was just not performant enough. 46:55: For a lot of the use cases we care about, like Tendermint or our bridging use cases, or even as zkEVM, because we couldn't modify RISC Zero, there was no path to getting better performance. And so that was why we were like, okay, well, we need to build a truly open source ZKVM where it's customizable, it's modifiable by the community. There's no vendor or platform or lock-in risk. It's just all out there. And we kind of looked around because we were like, okay, has anyone built this? And there just wasn't anything out there that was 100% open source and performant. And then we were like, okay, let's go build this. So yeah, I think the biggest difference is that it's 100% open source. And because of that, because it's customizable, it's also a lot more performant because you can really add these, we call them pre-compiles, to get the performance you want for use cases that are really important for us. So yeah, that was kind of the motivation. 47:51: Tarun Chitra: Could we talk about the relationship between SP1 and Plonky3 and which components you used and where the separation is? Just get a little architecture diagram because obviously you're using Plonky3 under the hood, but it would be great to kind of understand which components since there's a lot of stuff there. 48:08: Uma Roy: Yeah. So we are really big believers in open source, and I think we kind of think the terminal ZKVM will be like this truly 100% open source public good. Because the code has to be open source and be modifiable for it, I think honestly for anyone serious to really use it. And we looked around at the landscape. We had been previously really big users of Plonky2, which is this proof system developed by Daniel Lubarov and Brendan and other people at Polygon Zero. And we had been big fans of it. And Daniel had started working on Plonky3. Plonky 3 is like this library/toolkit of modular components that people can use to build new proof systems, new ZKVM, stuff like that. It's kind of like this library-toolkit type thing. And yeah, we looked at Plonky3, we'd already been, of course, familiar with the high level structure because it's similar to Plonky2, and it's like super high quality code. It has a good open source community around it. And so we built SP1 using Plonky3. So for example, a lot of our constraints and stuff like that are expressed with Plonky3's Air Builder and things like that. And we've also contributed back to Plonky3. I think there's a few PRs our team has merged into upstream into Plonky3 as we've like... Because it's not fully finished yet and they're always adding stuff. So we've also contributed upstream back to Plonky3. 49:36: Anna Rose: Are you one of the first to be using Plonky3 in production? Or is it already being used elsewhere? 49:43: Uma Roy: Yeah, it's a good question. Who else is using it? I think there's a few other teams that are using it or thinking about using it. Oh, there's this project called Volita that's also using it that Daniel and some other people are working on. Yeah. And then I think there's also a few other ones that maybe aren't public yet. 50:03: Anna Rose: I see, I see. Would you... I mean, kind of going back to the competitive landscape, are there any other products other than RISC Zero that are also in the same category? Because there are these other ZKVMs, there's other Rust-based VMs that we've also heard about. Yeah, is there anyone else that you kind of would have been looking at in that competitive space? 50:25: Uma Roy: Yeah, I actually think, for example, the Andreessen team has been working on Lasso and Jolt, like it's Justin Thaler, Sam Ragsdale and Michael, I think his last name is Michael Zhu. I don't know exactly what his last name is, but they've been working on Lasso and Jolt, which has a very similar vision. And I do think there are a few other projects with very similar visions, like some I think with folding based approaches, I've heard of any others with like the FRI STARK approach. So yeah, I do think there's other ones. I'm actually honestly pretty excited about all of them. Like I think there's a lot of techniques. For example, with Lasso and Jolt, there's certain techniques from that that could maybe be adapted back into SP1 that could help SP1 and vice versa. So I think it's really great that, and I think all these projects I mentioned are fully open source. So again, my view is the best VM that will really stand the test of time will be fully open source. And it's really great for the ZK community. And then I do think SP1 is the best option out there today because it just has really great performance and it's fully customizable and things like that. But in the fullness of time, for example, our prover network will support SP1, it'll support Lasso and Jolt, like when RISC Zero open source everything, it can also support RISC Zero. It can support any of these options. We wanna be fully modular and flexible, because we also know that's the most sustainable, given how fast ZK progresses. 51:52: Anna Rose: I know that when you released it, RISC Zero did have kind of a, they wrote kind of a welcome to the neighborhood tweet, but also mentioned something about performance. And I know the metrics that you had shared kind of compared performance on a certain level. But they were talking about GPU. I don't know, what were you benchmarking on? Does it matter, basically, what hardware you're using, how well these will perform? 52:16: Uma Roy: Yeah, I think one thing to say about benchmarking in general is it's very hard to do benchmarking, because it's such a multi-dimensional trade-off space. It matters what hardware you use, it matters, like are you benchmarking on a distributed cluster? Do you care about recursion? Like, there's so many different factors, like, do you have your own homegrown cluster using AWS? Are you using reserve pricing or spot pricing or on-demand pricing? Like, it's just very hard to do benchmarking. We really tried to do a very intellectually honest benchmark. So our benchmark was like on CPU, on the same machine, just run both VMs and then just look at the amount of time it takes on the same, exact same CPU just end to end run it through. I think that's the easiest way to benchmark because we just compare on the exact same hardware and you just look at the total time. I think they were saying basically that they have like a GPU implementation and on GPU it's like faster or whatever, it has better performance. That was just not really in the scope of our benchmark if that makes sense. 53:17: And there's like certain arguments for or against GPUs. For example, they're harder to get in the cloud because there's all these crazy AI companies that really like GPUs today. GPU is also something we're kind of thinking about potentially adding to Plonky3, like maybe it'd be awesome to have it. It is just really hard to benchmark. Totally apples to apples. And I think they were just saying, oh, we've spent a lot of time on GPU, so we just want to let people know that that's an option, for example. 53:45: Anna Rose: It's just going back to the prover marketplace thing because it's almost like, because the hardware and how, what you're running these proving nodes on seems to matter. So it's like there's the prover marketplace, there's the demand for the prover marketplace, and then there's the hardware powering the prover marketplace. Do you have any sort of hardware play or are you just sort of like, well there's CPUs, GPUs, and apparently there's an ASIC now, but are you just going to say like whatever hardware is there we're going to go with or do you want to influence that? Is that sort of outside the scope of the prover network? 54:22: Uma Roy: I think, yeah, the idea of the prover network is like any hardware provider can participate. So maybe, for example, the idea is like, we'll support a variety of different proof systems and a variety of different VMs, right? And then we'll also support any hardware provider and our marketplace/network will just be like this coordination layer where like the two parties can talk to each other and communicate and participate in this competitive auction or whatever. So I kind of view it similar to how like... You know how Ethereum provides this layer for the rollups to compete and like a bunch of different rollups have made really different choices in many different dimensions. And then Ethereum just sits in the middle and coordinates all the users and all the rollups and that activity. Like that's kind of how I view our network. It's like our network sits in the middle, there's like hardware providers on one side, there's like applications using a bunch of different proof systems and a bunch of different VMs on the other side. And we sit in the middle and just help coordinate that activity. So for us, for example, where we see a gap in the market, we'll step up to fill it in. So with the VM landscape, we saw that, okay, there was this lack of an open source performance VM. So that's why we made SP1 to just induce demand for this network. Because it's like, well, no one's going to ever use the network if there's no good options for VMs. And similarly, I think if one day we're like, oh, there's no good hardware providers. Maybe we have to try to jumpstart that, we will. But we have no current plans for that. And I actually do think there's a lot of really great hardware teams. So I'm really excited about potentially some of them even trying to accelerate SP1 or maybe even someone external doing the GPU thing for SP1. That'd be awesome. 56:05: Anna Rose: Yeah, I'm trying to imagine if you would... Would partner with hardware, or is that just like, provers can choose their hardware and you wouldn't have any say on that? 56:15: Tarun Chitra: I kind of think if you're going to go for the decentralized network, it's actually quite hard to pick one particular type of hardware. Like you really do need to actually have enough of a substrate that it's like anyone can plug in provided they meet some standards. I kind of think having to be one particular hardware platform makes it kind of hard to bootstrap in a lot of ways. Especially if the tasks have very different compute costs, right? Like the aggregation proofs might be cheap relative to the full block proof, right? 56:47: Uma Roy: No, a hundred percent. Yeah, I don't think we'd have to partner with a hardware provider. It's come hook in and play in the marketplace, like that's kind of the goal is it's like fully permissionless, fully open decentralized. I think that's the beauty of crypto is like, you don't have to ask anyone. 57:02: Tarun Chitra: You may have to issue some points. 57:05: Anna Rose: Proving points. 57:07: Uma Roy: Not yet. 57:07: Tarun Chitra: Proving points! 57:09: Anna Rose: Proving points, proof points! 57:11: Tarun Chitra: I actually think, by the way, a very tiny, tiny again aside, I actually think one of the best ideas that hasn't been done and actually is really good for using ZK is doing point systems that are like loot boxes where you don't know how many points you get and you get a ZKP that some particular calculation was done to generate how many points you should get for participating. But it's like a ZK loot box. It actually is ZK, not just sync. You really wanted to hide, because I actually think you turn the point systems into a lot more of a lottery game, and like... I don't know, people love that shit. 57:53: Anna Rose: Yeah, I think they weirdly find that more fair chance. 57:56: Tarun Chitra: I definitely think it's more fair in some ways, and it also would be public. The methodology is public because it's like this ZK, you can read the ZK circuit doing it, but it uses some provable randomness that can be. 58:08: Anna Rose: Pure casino, I love it. 58:10: Tarun Chitra: I mean, it is, but these point systems are like casinos where you don't know whether the casino's floors will like suddenly be pulled under you, right? Like it is a little bit... 58:18: Anna Rose: Rugged. 58:18: Tarun Chitra: There is some risk, right? I mean, look, I think there is a lot of pros of these point systems, because they actually help the teams design, QA tests their application, and they help the teams design which actions they wanna reward and not reward and figure that out iteratively instead of like okay, we're only going to reward liquidity and we can't change it ever. It's immutable forever. You know which in 2020 made sense, but I think now that the existence of industrial airdrop farming is there, you kind of have to now have more levers at hand. But anyway I think the ZK point systems actually has product market fit like tomorrow if someone built it. 58:59: Anna Rose: Yeah, someone should build that. 59:01: Uma Roy: Yes, someone should build it 59:03: Anna Rose: And then use the marketplace to generate the proofs. Although wait, okay, question about the marketplace. This has also come up. When you have these prover marketplaces, doesn't it also screw up privacy? Can you keep things private if other things, like you're sending data to the prover network to make proofs? I think it makes a lot of sense in the Succinct context, the succinctness, or the verifiable, making sure that it's correct. But it doesn't... 59:32: Tarun Chitra: ZKFHE. 59:34: Anna Rose: Yeah, so that's what I've heard. Like you have FHE eyes it and then you ZK it. 59:40: Uma Roy: Well, for privacy, I think basically the end game looks like this. You generate a really large proof client-side. So basically you do some client-side proving. So there's this like prover verifier trade-off where if your verification time is large, your proof time can be a lot shorter. And so, you basically generate this like really long verification, short prover time proof client-side, and then you go to the prover marketplace and you wrap that proof. And then you compress it and make it succinct and then you turn it into something you can use on-chain. So I actually do think the marketplace is still useful for privacy applications because of this wrapping stuff, wrapping and aggregation stuff. 1:00:20: Anna Rose: I kind of want to know what's next for Succinct, but I also sort of want to know what you think is just next in ZK. Because you're moving very quickly through these use cases. And I'm like, what is Uma thinking about now? 1:00:38: Uma Roy: Yeah, well, I think with SP1, I mean, I tweeted about this, but I really feel like it's this GPT-4 moment of ZK. Because I think the really cool thing about it is it finally has the correct shape. I really strongly believe, and this is probably non-consensus, that every single application will use ZK in some form in the future. Like every rollup will be a ZK rollup, like every bridge will be a ZK bridge, every oracle will be a ZK oracle, and I think all of them are going to use ZK by writing normal Rust or like normal code and then proving it on a ZKVM. Hopefully SP1, but whatever is the best open source VM, and then like coordinating on this prover network marketplace to get the cheapest possible proofs. I feel like that to me is the end game of ZK. And it's really exciting to see all the hype around SP1. Because even in our Telegram support group or just a number of things people can do is so great. Now, literally today, some guy was like, oh, I implemented some Black-Scholes stuff using SP1. And that was just like not something that would be possible with a circuit. Writing a circuit was horrible, and so I really hope SP1 catalyzes this wave of like any developer can now use ZK. It's really similar to GPT-4 because before GPT-4, to do AI, you had to do all this complicated stuff. You had to fine-tune these models. You had to have all these expertise. I was in that era, I was pre-GPT-4, I was doing all that stuff. And then now with GPT-4, it's like anyone who's a software engineer who can make an API call. I mean, you don't even have to be a software engineer, you can just make an API call and use AI. That's awesome. 1:02:20: Tarun Chitra: To be fair, though, the people building GPT-4 are still doing all the dark art... 1:02:27: Uma Roy: Oh, yeah, yeah, yeah. The people building GPT-4 are doing dark arts. Yeah, I agree. And similar to that, we built SP1, and we had to go through some pain, you know? It was very hard to build SP1. But now that we've built it, it's like, anyone can use it. Any developer can write Rust and get a proof. And that, to me, is really exciting, because, even I've just seen internally using it, is magical. Like, stuff that used to take us months now takes an afternoon. There's people in our support group, and finally, I can just be like, oh, you don't even have to ask me questions, you can just go write normal code. It's so awesome. And so I'm just really excited, because now I'm just like, okay, let's take SP1, let's get like ZK embedded in every single app, every single rollup, every single bridge, like whatever, it's now so easy. And then let's build this network to kind of be the hosting and infrastructure layer of it all. So yeah, I think we're just focused on that. Hopefully, this brings back the ZK bull market or whatever, because it's like now anyone can do anything with it. So it's awesome. 1:03:27: Tarun Chitra: I'm telling you the ZK bull market only comes back when you have ZK points. 1:03:33: Anna Rose: Hilarious. How big is the team? 1:03:35: Uma Roy: It's still pretty small. Yeah, it's like 10 people, but we are hiring. 1:03:39: Anna Rose: Okay. What's next for the company? It's like you released this, but what is your next steps? 1:03:45: Uma Roy: So we are hiring because I do think we do need more people to help build all this stuff. And yeah, I think for us, it's just like, let's take SP1 and let's make it production ready, get on-chain verification, get it audited, whatever, like make it faster, make it more performant. And then also start building this prover network where hopefully SP1 can be hosted. And when other open source VMs come out, and honestly, hopefully they're faster, because I think that will just induce demand for more proofs, like integrate those into our network and basically just start generating a lot of proofs. So yeah, I think that's just our plan is make SP1 faster and then build out the prover network and make sure that all the proofs are getting generated for the cheapest price possible. 1:04:39: Anna Rose: Is it all ZKVMs? Could any of those rollups use it? Could any of... I'm just trying to imagine who your customers could be for that prover network. 1:04:49: Uma Roy: Yeah, I mean, the way we're going to build a prover network is to support any proof system, any VM. So like... 1:04:56: Anna Rose: It could be EVMs. 1:04:57: Uma Roy: Existing rollups could use it. Yea, new ZK rollups can use it. Bridges could... Like anyone using ZK can use it because it'll be like this very general modular thing. Like it'll be like hardware providers can opt into who they want to provide proofs for, and then on the other side, if you're an application, you can just be like, hey, these are my binaries, these are the things I want to run, this is the proof I want generated. So it's very general like anyone can use it. 1:05:23: Anna Rose: Cool. Tarun, do you have any last thoughts? 1:05:25: Tarun Chitra: Nope, excited to see what people build, and like I said, if you're ever thinking about building ZK points with SP1, let me know because I have so many ideas for this. I have so many ideas. 1:05:38: Uma Roy: Whoa. That's so funny. I love it. 1:05:43: Anna Rose: It's good. 1:05:44: Tarun Chitra: I think the ZK market... 1:05:45: Anna Rose: Tarun, you gotta write a tweet about this. 1:05:47: Tarun Chitra: The ZK market just needs some degen energy. And I feel like SP1 makes it easier to have degen energy. So... 1:05:56: Uma Roy: No, I agree. Yeah, any degen can now do ZK. It's true. 1:06:00: Anna Rose: Wow. All right. Uma, thank you so much for coming back on the show and sharing with us all of these products, all of these projects and how they all relate. 1:06:10: Uma Roy: Yeah, thanks for having me. It's been fun. 1:06:12: Tarun Chitra: Thanks for coming on, and obviously super excited to see where this ends up. 1:06:14 Uma Roy Yeah, no. Good to chat with you guys. 1:06:17: Anna Rose: I also want to say thank you to the podcast team, Rachel, Henrik, and Tanya, and to our listeners. Thanks for listening.