Modularity Maximalism w/ Uma Roy (Succinct Labs)

**Speaker A:** Hello, welcome and thank you for tuning in for another episode of the Strange Water podcast. We've got a great one for you today. At some point in every builder's career, they have a very specific moment in the process of trying to solve some big hairy problem. They find themselves so bogged down in implementation details that they end up spending more time creating custom tooling and frameworks than actually solving the problem. Or maybe they skipped over thinking through the framework and the tools that they might need and they just charged ahead, only to realize halfway through that they don't have any tools and are irrevocably tied to the thoughtless architecture that they had just hacked into place. Again, this is a very common experience. What is not common is the realization that if you're experiencing all of these problems, every other developer is probably going through the exact same growing pains. These special people realize that if they spend enough time and care making their own lives easier and their own development faster, they can also offer these tools to other developers and transform incredibly advanced and nuanced computer science into plug and play APIs. If all the stars align just perfectly, these people are able to bring together all the ingredients needed to transform practical developer tools into a venture backed company. A company capable of that one one three magic and one desperately needed to make advanced mathematics and technology easily accessible to application developers. Well, as you're all aware, zero knowledge cryptography is one of those fields incredibly ripe for these kinds of builders. While capable of what seems like actual magic, ZK cryptography is incredibly hard to understand and it's even harder to actually get working. And so I'm sure you can see where this is going. It was inevitable that a builder like today's guest would seize this opportunity. Uma Roy is the co founder of Succinct Labs, a company that aims to make ZK development as simple as possible. I've heard some very prominent members of the crypto ZK community describe Succinct as foundry for zk, but I like to point at how Twilio abstracts away all the challenges and complications of telephone companies and provides web API access to text messages and phone calls, and use that to describe what Succinct is trying to do for zk. Either way, the point is that Succinct aims to abstract away all the advanced cryptography of ZK so that developers can focus on building applications and not postdoc level math. In today's conversation you'll hear everything from the story of sysync to what kind of applications and use cases the Platform is beginning to open up. In particular, I want to underscore the theme of today's episode and maybe of SySync's ethos, modularity. And I guess I want to leave you with this idea that there's only one way to build at the bleeding edge. Modularity, maximalism. One more thing before we begin. Please do not take financial advice from this or any podcast. Ethereum will change the world one day, but you can easily, easily lose all of your money between now and then. Okay, let's get to the show. Uma, thank you so much for joining us on the Strange Water podcast. **Speaker B:** Thanks for having me. **Speaker A:** Of course. So I'm super excited. I like, I think that what succinct is, is like both the. The right business to build right now, but the perfect story of like builders finding problems and realizing that you can build a company around the problems you just solved. But before we get to any of that, I'm a huge believer that like the most important thing in any conversation are the people in it. So with that as a starter, can you tell us a little bit about yourself and how you found crypto and zk? **Speaker B:** Yeah, for sure. So throughout kind of my life, I've always been really into math. I did a lot of math and research in high school, and then also I was a double major in math and CS in college. So I've always really liked math. And then I also realized, you know, I really like building things. And so coming out of school, you know, I was working at a few different places doing machine learning stuff. But when I found crypto, I thought it was very interesting ideologically and also kind of like the space I think is very interesting and it's always very exciting and it's very different from everything else. And when I found about found out about ZK in particular, I thought it was kind of this like perfect fit of my math and computer science interests. Like, there's so much interesting math going on, which really was what drew me in. But then also it felt like it was this really exciting new primitive that could be used to build a lot of really exciting stuff in crypto. And that's why I became just like really enamored with ZK and went fully. **Speaker A:** Down the rabbit hole for sure. So when you say it really resonated with you ideologically, like, what does that mean? **Speaker B:** Yeah, I think like a lot of crypto's principles around like self sovereignty and those ideals resonate with me. And then I find like a lot of the mechanics like composability Also very interesting. And you know, the world computer vision I think is very interesting. And also like the deeply open source ethos of the space also resonates with me. **Speaker A:** I guess you don't hear many machine learning people that make the jump the same way you don't hear a lot of ZK people that make the jump because there's so much to like learn and fall down the rabbit hole. Like, I guess I wonder what, what was not that interesting or not interesting enough about machine learning for you that you did get attracted over here? **Speaker B:** I mean, I, I think machine learning is very interesting and I still really like it. I think at the time I just thought ZK was like so new and so under explored that that's what like made me extra interested in it, if that makes sense. **Speaker A:** For sure. I mean I've had I. The a repeating theme with. A lot of the conversations that I've had on this podcast are like, what's special about ZK is it's like almost like this soldering point between research and entrepreneurship. And I, I said to you before the podcast, I was at Stanford SBC and I saw John from Succinct present and like that that's a conference where it's literally every other presenter is either a professor or a grad student reading out their research. And then there's a bunch of kids in the audience like figuring out in real time how to turn that research into a real product. And that happens everywhere. But there's like clearly something special and fast happening here. **Speaker B:** Yeah, for sure. The space moves really fast. **Speaker A:** So can you talk to us a little bit about your journey from I guess like finding ZK and falling in love with it to founding Succinct? Like yeah, just how did you get to the point where you realized like, oh, we need to start a company. **Speaker B:** Yeah. So I, and my, my co founder and I, we met at the Xerox park co working space they had last year. Xerox park is this organization that's kind of like a sister org to the Ethereum foundation in some ways. And they were hosting this like ZK oriented co working space and kind of summer program I guess. And I met my co founder there and we started working together on a ZK bridge project. It was technically really interesting and novel at the time and I also really enjoyed working with my co founder and yeah, from there it kind of felt like, oh, ZK bridging really resonated with a lot of people and made a lot of sense in terms of solving a really important problem. In the industry. And we realized a lot of that work could be like more generalizable and important to like beyond just what have we done that summer? So that was when we decided to. **Speaker A:** Start Succinct and so I guess to like open up that moment a little more. I was watching one of your presentations earlier this morning about how the bridge you're talking about is the Gnosis Omni bridge, I think they called it, something like that. Right. So first, like from a kind of like entrepreneurship journey, can you talk a little bit about like how you found the opportunity to be working on, at least for Ethereum, such an important part of the infrastructure. And then can you talk a little bit through the journey of actually building the ZK bridge and then realizing, oh my God, these primitives are so difficult, but once they're done they're super usable. And I don't want to put words in your mouth, but I believe that's probably the start of your company. **Speaker B:** Yeah, for sure. So yeah, when we started the company, I think the Gnosis people had been in touch with some of our friends and some of the Xerox park people and they kind of had this idea for a ZK bridge to secure the Ethereum Toosis bridge. And basically that involved instead of having a multi sig, which you know is like kind of problematic and they can get hacked and they have these bad security assumptions, generating a ZK proof of consensus and then kind of having this trust minimized cryptographic proof of the state of two chains and using that to secure the bridge instead of like kind of what at the time was the industry standard of the multisig. So the idea actually I believe originated from one of the Gnosis co founders, I think it's Martin and maybe I think some of the people also working on Gnosis chain, like some of the original team of Gnosis Chain, like perhaps Igor as well. And yeah, I think at the time we were just working on ZK stuff and kind of looking for something to do and then they had this idea and it was, you know, that was like kind of the match there. So that's how we started on working on this bridge. At the time I think it wasn't super clear if it was even technically possible. Like verifying the consensus of a chain in a ZK proof involves a lot of like non native arithmetic and like a lot of kind of slow primitives traditionally in a circuit. And so I think a lot of people didn't think the proof time would be performant or it'd really be Possible. But yeah, we just kind of went for it and did it and then it ended up being performant. Like the proof generation was like, you know, two minutes. So like totally reasonable. And yeah, then we got it working kind of end to end. And today it helps secure the Ethereum to Gnosis bridge. Yeah, along the way, as you kind of mentioned, we are building this bridge. And I remember for John and I, we'd worked on it over the summer. I think we'd gotten the circuits working maybe sometime in September or October. And then from that point to take it to production was like a really long journey. And it finally launched on mainnet in March. And there was a lot of things about like ZK development and deployment and production that we realized throughout our journey were really terrible developer experiences. Like, you know, we, we are developers, so we've developed like front end and back end and we have all these nice tooling like Vercel for like automatic deployment or like GitHub for collaboration. And ZK development in contrast, feels so primitive and that's like at every part of the ZK development stack. So like, building with circuits. Originally when we were using circom and like, for listeners of this who view circom, we were using an old version of Circum that didn't have like print. So when you were debugging your circuit, you couldn't even print what was going on. So it's basically impossible to debug. **Speaker A:** Like does it work or does it not? **Speaker B:** Yeah, exactly, it's. They have like no insight into what's going on. And since then they've added logging. But yeah, we were on like an earlier version where they didn't have that. So, you know, developing the circuits is really hard and kind of nightmarish. And then, you know, keeping track of like all the kind of build artifacts associated with the circuit process is also really difficult. We had to. We were working with some of the biggest circuits I think, that have been used in production even now. So we'd always have to SSH onto remote machines and like to do our builds and to generate proofs. And so it was just a really horrible process. And then deploying it in production had like a lot of other hurdles too. Like we had to write our own relay infrastructure, we had to write our own scalable proof generation infrastructure and stuff like that. So yeah, and end to end, it probably took like more than six months to go from start to finish. And along the way we kind of realized like a lot of this tooling is kind of a general problem. For any ZK developer out there. So after we worked on that, we started working on, like, other ZK Lite clients because, you know, it was a very natural evolution. We'd done an Ethereum ZK Lite client, and then we thought, okay, let's do a ZK Tenderman like client, which is used by the Cosmos ecosystem, and help connect it to Ethereum. And we also are working on like a ZK Grandpa like client, which is used by a lot of substrate chains. And so those things are actually like, we've spent the past months since March building those out and developing them as well. They're not in Certcom anymore. They're in a different proving stack called Plunky 2. But along the way, we realized a lot of the same problems were still there. And so when we'd been building these ZK bridges, we'd built a lot of infrastructure in house to kind of make it easier for us internally to build with zk. So we kind of came up with this system of really easy remote builds and version circuit artifacts and better SDKs and better frameworks and things like that. And at some point we realized like, okay, it's not sustainable for us to always be building all these circuits. And this infrastructure is going to be useful for a lot of other ZK developers too. What if we can turn this into a platform where it's not just us building these ZK like clients, but we can let any developer build with ZK in the way they want to build. So, yeah, that was kind of the evolution from like, our start and focus on ZK bridging to kind of building this like, broader ZK platform. **Speaker A:** And so just to, I don't know, like, help, like, put context into this. So when you say six months to get like this bridge up and running, like, what percentage of that would you say is like, solely about zk and what percentage of it would be about, like, you know, just the, the things needed to make a bridge work that are just application and level. **Speaker B:** Yeah, it's a good question. They're pretty intertwined. I think we probably spent like, I would say maybe two to three of the months on the ZK stuff. So like getting the circuits, building them, redoing the builds when we change stuff, copy pasting the, the verifiers into our projects and things like that. And then maybe two to three months are spent on like, more generic infrastructure around like, scalable proof generation, relaying and stuff like that. And then of course, some of that infrastructure is like, more specific to our app. But yeah, that was, I would say it's like pretty even split. **Speaker A:** Yeah. So I apologize for jumping to like the hard portion of this episode this quickly, but because my question for you is when you're building, you know, a framework based around ZK based like primitives that are, you know, kind of like modularly plugged into apps, I I wonder in a. In systems that are so complex and nuanced, like how reusable and how like plug and play are these systems. And I think that has implications for like using third parties like Succinct or like more importantly for as systems upgrade, like how tied to like specific implementations or versions or whatever are applications going to be when they make the decision to like develop with any specific ZK system? Do you have any sense of that yet? **Speaker B:** Yeah, that's a good question. So I think to describe what Succinct is at like a high level, the Succinct platform is basically kind of this set of developer tooling that modular and proof system agnostic. And it helps any ZK developer build with zk. So by proof system agnostic I mean you can choose like any framework like Circom or Ponky2 or Gnarc or anything else to build your ZK circuit with. And then we have this kind of modular set of components that'll help you. So as an example, we have circuit builds which help you manage your circuit artifacts and things like that. We have one click verifier deploys, we have a proof explorer that shows you proofs from any proof system. The reason we built it this way is internally even we've been using a bunch of different proof systems for our different clients. And so we kind of realized also in the long term ZK proof systems might end up being very fragmented because different proof systems are good for different use cases. And so that's why we kind of built this platform to enable developers with like kind of best in class tooling, no matter which proof system or app or use case they're doing. And we call like, our mindset is kind of summarized by like we're minimally opinionated. So basically if you have like this succinct JSON which is kind of like a package JSON, if you've worked with like front end or like JavaScript before, which is kind of like tells us, okay, here's like the commands that we want to run and like they have to have like a certain format and maybe sometimes some of your files have to have like be named a certain thing. And then if you like follow this set of like, minimally opinionated conventions, then you kind of get all this nice tooling for free. So to answer your question around like, yeah, these, these ZK applications are like, pretty complex. Like they can, there's often a lot of nuance and like, how ZK is being used or where it's being used. But I think because we're ZK developers ourselves and we, we have used like a bunch of different proof systems in a bunch of different contexts for a bunch of different use cases, we've tried to make it as general and flexible as possible while still like, retaining a lot of the benefits. And I think from our own internal usage of our platform, it's like, been pretty successful at striking like the right balance. **Speaker A:** And that makes so much sense from the standpoint of like, the company you're building and like the services that you want to provide to developers. I guess I'm wondering, as a application developer yourself, who has developed with like these ZK primitives, do you have a sense of like, let's take for example, the Gnosis chain bridge that you've made. Once you've deployed something with a specific, let's say, proof system in it, like, are you committing that entire application kind of irrevocably to that proof system? Or are we able to develop these like, primitives and I guess, like frameworks in a way that like, allow maybe some like, modularity and upgradeability? **Speaker B:** I think for us we have this as part of succinct. We kind of have this proof standard where a lot of the use cases we're targeting kind of follow this new term. I don't know if you've heard it of like a ZK CO processor where basically you're taking a lot of compute that's too expensive to be done on chain, and we move it off chain and then verify a proof instead. And so we have this proof standard where like for any off chain compute, there's this simple API where you pass in input bytes, it generates a proof, and then you verify a proof and you get like verified output bytes corresponding to your input bytes. So you can think of it as you're making a function call with some inputs, and then you get verified outputs, but instead of the function being computed on chain, it's computed off chain. I think given this kind of proof standard abstraction, it's actually now much easier to switch out your proof system because basically you, you can have the same function and same logic and you just implement it in the new proof system. And as long as it conforms to that same like spec, then it's really easy to swap out, which is awesome. So I think before the way we developed our. So when we originally developed our system, for example, like the Ethereum to Gnosis Bridge, a lot of our infrastructure was built in this really monolithic way where, you know, the proof system we'd chosen and then all of our infrastructure was like really tightly coupled and really tightly integrated. So actually it would have been really hard to switch out the proof system. But I think with our new product and kind of like our new standards and our new mindset, it's actually a lot more modular, so it's a lot easier to switch. **Speaker A:** So I guess like that is the story of Succinct realizing that. I mean, I guess to take off like lessons from our ancestors that like standards allow us to really like multiply or have outsized force on innovation because once things are standardized, the next layer of people have a lot more flexibility to worry about what they're building and not worry about, in our case, complex math and essentially wizardry. Right. So I guess, yeah, that is what you're building with Succinct, whether it's the actual compute that you're offering or just the standards themselves, which I'm sure you're hoping are adopted by people outside of you. That makes a lot of sense. And now it makes sense why people are investing in you. **Speaker B:** Yeah, we definitely hope that. We've been using like our own platform for a lot of our internal development of ZK Lite clients. And with our new light clients, like we've been able to get them to production, I would say like easily 10 to 20x faster than our original Ethereum like client. Like our, their client, like I mentioned, took like six months to get to production fully. And then our Tendermint Light client, I would say, you know, end to end. Just thinking about like getting it to production took like maybe around a couple weeks to a month using the platform. And that was just something that was really enabled by our developer tooling buyer standards, like buy all that stuff. So I think hopefully we can offer like the same sort of leverage to like all other ZK developers. **Speaker A:** Yeah, very cool. So let's like move this conversation a little bit to the applications, the almost application layer, because first I'd like you to just like kind of expand. We've been using light clients and bridges kind of synonymously. So can you just like real briefly for people that don't really understand that, explain what you mean. But then why I really want to talk about is like, now that you've figured out these light clients to reach across chains, like, what are some other interesting applications outside of bridging that you guys are, if not saying actively developed yet, at least thinking about that now that you have this ZK package. **Speaker B:** Yeah. To talk about bridges and light clients. Basically bridging is just the problem of like, I have one chain A and I have another chain B. And I want chain A to be able to talk to chain B and I want to kind of do it in the most secure trust minimized way possible. The best way to do that is on chain B you should verify the consensus of chain A because like that kind of is the ground truth of what's going on on chain A. Historically, verifying consensus has been really difficult on a chain because it's like a very heavy computation. Like you have to verify signatures, you have to verify a lot of hash functions. And so that's like a perfect use of ZK where you can take that really expensive computation, you can generate a cryptographic proof for it and then you can just verify that proof. And it's, you know, verifying that proof is a lot less expensive than redoing the original computation. And that's kind of where you get this ZK bridging A like client. So yeah, that's verifying consensus is useful for understanding the state of another chain. And then that is useful for running a light client which is just a client of a blockchain that just keeps track of like the block headers or like some sort of minimal state about another chain. And you want to run like a light client of chain A in a smart contract on chain B so that you can understand like what's going on in chain A. And then you can do stuff like, oh, there were tokens burned on chain A. Let me mint tokens on chain B. So like an on chain, gas efficient like client powered by ZK is kind of like the holy grail of bridging. And that when we originally started, that was like the main focus was replacing, you know, these centralized multisigs that are kind of this like shortcut and like not very secure with these on chain ZK like clients. **Speaker A:** Got it. That is why we're using light clients and bridging in the same way. Because essentially the hard part about bridging is the light client. With that as background, what are the other types of uses for light clients that are really starting to get you excited? I know the most basic things are things like your browser wallet doesn't need to use Infura, it can directly verify the chain. But is there anything else that now that it's trivial to deploy light client, you are hearing or thinking about what applications can be built with it? **Speaker B:** Yeah, I think for a gas efficient on chain light client, I think the main use case is bridging and I think bridging can be pretty broad. It can be used for just moving money and tokens. It can also be used for sending messages which can be useful for things like cross chain governance or cross chain lending or more complex cross chain interactions. We've been recently working with some DA layers like Celestia and Avail that where they use the bridge to like verify that data was posted to their chain. So it's not like a money movement use case, it's more of like a verify that the data is available on another chain use case. So yeah, I think those are kind of like the use cases of like clients. But yeah, there's also a lot of other applications of ZK other than just like light clients that were pretty extensive. **Speaker A:** Yeah, for sure. So like I'd love to get to that. I wonder if it's worth talking about the work you're doing with Celestia while we're still in kind of this realm. So I'll leave this to you. **Speaker B:** Yeah, so we've been working with two DA teams, Celestia and Avail. They're both basically providing a L1 blockchain that's only focused on data availability. So it has a very minimal execution layer and it has data availability sampling to provide more very high throughput DA because that's a bottleneck for a lot of rollups on Ethereum in general. In order for Ethereum rollups to be able to use these DA layers, they need to be able to verify that the data is actually in the other chain. And so for that we've been working with both Celestia and Availe to make like a ZK enabled like client for their chains so that we can have like an Ethereum like client of Celestia or an Ethereum like kind of Avail that can basically attest and say like hey, this data is available on Celestia or hey, this data is available on Avail and then Ethereum roll ups that are using those chains for DA can use that like Client in the case of like a fraud proof or something to say like oh yeah, this was like the da the data that was posted on those chains or in a ZK roll up as like a part of verifying their validity proof. Yeah, that's like the work we've been doing with them, it's been really interesting because to do that work we've had to develop like a lot of really optimized primitives or like signature verification and hashing. And the work has been exciting because it's like a lot of the state of the art primitives that we've been able to put together and we've gotten it to the point where they're the light clients are pretty like the ZK proof generation is like really performance. And then yeah, we've been building these light clients and developing them internally with our platform. So kind of our, the first customer of the platform is really ourselves and you know, the platform's really sped up a lot of our work. Like clients, like I would say 10 to 20x. So that's also been really exciting to have like a real world use case for a platform too. **Speaker A:** And then, sorry, last thing on light clients, but have you guys started like thinking about tackling the like super high throughput chains like, like Avalanche or Solana that you know, like, regardless of how complicated it is to do like ZK proving on those chains, the reality is, is that they move at like orders of magnitude speed faster than Ethereum. That. I don't know, I just imagine that like whether you're talking about like latency issues or just like size issues, I don't know. But there's, there must be some sort of complication there. **Speaker B:** Yeah, I think for Solana, I think they're actually still working on their like client protocol. I think it's maybe called Tiny Dancer or something like that. Or maybe diet client. Yeah, diet clients I think is their, what they're working on. So I think they're still working on kind of like their like client protocol. Although I think it would be quite possible like Solana uses ED25519, which we have like really optimized circuits for. I think they use SHAW hashing, which we have really optimized circuits for. So I think it's like a matter of someone who understands the Solana consensus and understands their like client protocol putting the pieces together, whether that's like our team or like someone else. **Speaker A:** Yeah, yeah, makes sense. Cool. All right, so let's continue this conversation forward and talk about like now that you have some of these general purpose tools and are in this space of zk, I guess application, innovation, what are some of the other things that, that you're starting to get really excited about for zk? **Speaker B:** Yeah, so I think just this general class of Zk co processor applications with augmenting smart contracts with off chain compute is exciting. I think the light clients are specific use case of that, but I think some other specific ones include oracles. So for example, we recently have been working with LIDO to make a validator statistics oracle to replace their current trusted oracle. So for some context, like right now in Lido, it's really important to their protocol to understand how much eth is staked by their validators on the beacon chain. And right now they have like a trusted oracle for that where it's like I think 5 out of 9 multi sig of people who compute that quantity and then they post it on chain. But as part of like making their protocol more decentralized and resilient, they want like a ZK proof of that and you can't do like if you tried to do the computation on chain, it's like way, way, way too expensive. Like yeah, it'd be way too difficult. **Speaker A:** And sorry, can you just like unpack that a little bit? Is that because it would be about identifying all the individual validator keys that are corresponding to each entity and then bundling up the aggregate signature for just. So like why, why would that be too difficult without zk? **Speaker B:** Yeah, basically you'd have to iterate through, I guess at this point the million validator public keys on the beacon chain. Then you'd have to like sum them up if they're in like the Lido validator set and then you'd have to like add up all their balances. So yawn Jane, like doing a million of those like local proof verifications and additions is just going to be way way too expensive. Yeah, but with ZK it becomes like a lot more feasible. You just move that compute off chain and then you verify that proof. And so we posted this proof of concept we did for them where we generated a proof of a ZK proof of their validator balances across the whole beacon chain and then yeah, that could hopefully one day augment their current oracle and then in the future like totally replace it with like a fully trustless cryptographic. I think this class of like validator statistics applications is really interesting for like all the liquid staking protocols or like anyone that's doing like validator related stuff like including eigenlayer. So yeah, that's like one broad use case of Oracle I'm excited about. Another use case is like I think teams like Axiom are focusing on this where you have like historical state queries. So basically you can have this really large scale, big Data computation of a twop or like some historical information in the chain. And normally to do that on chain is way too expensive because you have to verify kind of previous block headers and Merkle proofs of the state. So you move that competition off chain, you can use it, you can do something complex like a twap or some average or a sum, and then you can use that statistic on chain. So that's another interesting use case. Other interesting use cases are similar to that. Or for example, instead of doing for an airdrop, instead of doing a Merkle route, like a trusted Merkle route, where someone just posts like, hey, here's all the addresses by some criterion, now you can have like ZK proof that like those addresses were computed with respect to like some cryptographically provable criterion. And so you can have like autonomous airdrops and maybe you can start having like continuously rewarding autonomous airdrops. So yeah, like, I think a lot of these Oracle use cases are really interesting. I think ZK machine learning is also like pretty interesting. I think that's like a little newer, but yeah, there's been like some exciting use cases around like having like NFT valuation protocol for lending or something with kml. I'm not like super familiar, but yeah, I think ZKML is exciting. And then of course I think a huge category is also like privacy. Like there's a lot of new interesting privacy primitives and applications like Nocturne and some other ones out there for KYC and things like that. And so I think that's also an exciting application of ZK as well. **Speaker A:** Yeah, no, for sure there's a lot of interesting stuff and I think so much once you understand the primitive or I guess the concept that what ZK is particularly useful for is taking something that's complex and then projecting the results of that into Ethereum or a blockchain. But who cares if it's not Ethereum, right? And then, and then like just understand that like when you find these like huge differentials in like computation needs, that's like. And I guess like, I'm just really struck by the LIDO example because it seems like you're kind of dancing between the consensus layer and the execution layer in that one in this like interesting way that just for one, kudos to you for figuring it out. But two just shows we have a long way to go in terms of core Ethereum protocol development. So last question before you move on from just what's exciting in the application area for zk. Have you gotten any Cool visions of how ZK is going to transform things that aren't necessarily directly related to blockchain. I know the famous one that we like he batting around in our circles is like the cameras that can like prove that this, this image was taken with this sensor at this date and time and like that kind of stuff. And so I might have taken away like the one good answer, but is there anything else that is on your mind where like ZK is really going to change the way that like the world actually works? **Speaker B:** Yeah, I think some, like one interesting one I've heard of recently is basically there's a team in Xerox park and then I think a few other teams working on this idea of like at like attestations with ZK for selective revealing. So I think at a high level the idea is like something like you have all these like attestations of like, you know, someone, you know, was at this event or maybe someone has this GitHub repo or something. And the attestations could be like kind of like provided by decentralized authorities or like some cryptographic proof. Like an altercation could be like, oh, I have this balance on Ethereum, which is obviously like secured by Ethereum, but they could also be like provided by a centralized authority like the government, for example. Oh, you have this driver's license with this birth date and then, you know, this expiry date and things like that. And then with those credentials you can start with zk, you can start revealing like complex subsets of information. So you could say something like, oh, I have this driver's license credential with a birthday that's greater than 21, but I'm not going to tell you like exactly when I was born or anything else. And so you, with zk you can kind of have these like very general statements across like many different attestations or subsets of attestations and combine that into kind of like a rich identity layer or platform or protocol. And I think, you know, that could be, you know, I think probably that will end up being like on or involved with blockchain in some form, but it doesn't have to be at all. And I think, yeah, that's like quite an interesting use case. **Speaker A:** Yeah, I mean like the obvious, like way to sell that to every American is like, imagine not having to give your Social Security number out, but still like complying with KYC so that when you get, you know, just like you're. I get my renters insurance from Lemonade, like a company that sounds like a Joke, you know, but I still have to give them my Social Security number. Like, Zeke, this kind of system or this kind of world would, like, solve that. **Speaker B:** Yeah, for sure. Like, another common example is, you know, often when you're doing a rental application, they'll want to see like, your bank account or like a W2 or something, which obviously I think a lot of people view that as kind of like a gross violation of privacy. And so with zk, you know, you could have like an attestation from your bank, attesting to like, your previous, you know, bank account information and history. And then you could selectively reveal, like, oh, my income is above this amount, but I'm not going to tell you exactly what it is. And like, that's all the rental people need to know. **Speaker A:** Yeah. And then the other. So I. We've talked to a lot of people on this podcast about zkml. I still don't really understand that. I think it's like, to me so obvious that cryptography and machine learning come together because, like, machine learning is about, like, abundance and like, just craziness and like chaos. And cryptography is about, like just scarcity and control and, and slow, you know, so those will come together at some point. I don't really understand it yet, but the other application, which I actually feel like no one's really talking about yet. But the deeper I get into technology, the more I'm convinced that the Jetsons is an accurate representation of what the future is going to be like, just everything, like robots, like Chrome, crazy shiny. And I think that whether we're talking about driverless cars or Amazon sending drones to do deliveries or all this stuff, part of the true implementation of the Internet of Things is going to have to be machines with some sort of autonomy that have some sort of identity. And like, I don't understand how that happens without zk. And so that's like the other, like, the intersection of Internet of Things and ZK is like, really where I've got my chips on. If I could put chips on it. **Speaker B:** Interesting. Yeah. I haven't thought too much about that, but it is an interesting idea. **Speaker A:** Cool. Well, so let's kind of move back to the succinct level and like, something I'm very curious about, when you're like, building a company that is predicated on implementing cutting edge research that is like, so cutting edge that they're still like, printing out the paper for the first time, like, how do you as a business leader think about, like, when it's the right time to dedicate resources to something that's brand new. Like, when does something become proven out enough that you feel like, comfortable allocating company resources? Like, can you just talk to me what it's like being a company at the bleeding edge of research? **Speaker B:** Yeah, that's actually a great question and something we've had to kind of like, grapple with a lot. I think my answer might be like, a little maybe different than what you'd expect, which is we had kind of seen this landscape of like, cutting edge research and algorithms and even engineering improvements, like, constantly, like every month. It's like, hard to keep up. And I think another thing we observed with a lot of companies in this space is like, a lot of them had kind of like made a bet on like a particular research direction or like stack, and then, you know, if it had gone well, well, okay, that's great. But if they kind of made the wrong bet, then they were maybe kind of like stuck with those choices, even if, like, it's suboptimal. And so I think one thing we realized is we'd been struggling with this for a long time, which was like, okay, there are new, there is new stuff coming out, like folding. You know, there's all this stuff with Starks. You know, there's like a lot of different directions, like, which one should we choose? And we'd struggled with that question for a long time. You know, of course we, we had made some concrete decisions for our, like, clients, but you know, for further, for future efforts. We, we were always still like, grappling with that question. And then I think one day it kind of came to us that like, in our struggle was the answer which was not to like, come up with some galaxy brain, like, we know better than, you know, Dan Bonet and like all these other people of like, what the future is. But kind of like the answer we arrived to was like, given that it's so uncertain, given that there's so much movement, let's build something that's like actually modular, that no matter what direction the research goes, we can still like, help take it. Like, we can take advantage of that research and provide value to that research and more easily use that research research so that, that like, perspective around like, not wanting to commit to any one direction and, and not wanting to build monolithically kind of led us to that answer. And our vision of like, building this more modular toolkit and more modular stack. So yeah, my answer to your question is kind of like this no answer, which is we, we decided to invest in a modular approach that would let us be like evenly kind of hedged no matter what direction works. And so you can see that in our platform and then in our standards and like a lot of the other pieces of what we've been building, it's really built in this proof system agnostic way so that like when the latest proof system comes out and like it finally gets to production, it can just like plug into our system really easily and we can take advantage of the new stuff as it comes out. **Speaker A:** Yeah, so I guess like what you're really saying is that first and foremost you separate as much as possible and in a modular way the like literal actual math and like the things that are related to cryptography and like the harnesses in which the cryptography needs in order to run. And you try to make that interface as seamless and as replaceable as possible. And so that gives you the flexibility to like continue like making the harness better and better over time while like swapping out and implementing more and more of the math engines. Correct? **Speaker B:** Yeah, yeah, no, I think that's like a great summary. **Speaker A:** Yeah. And so are you guys the kind of people that are at these conferences when a new paper comes out and are like that day, like, let's try to get this into production or are you more taking a step back, looking at like, okay, what are the like, types of applications that this could be useful for? Who are the types of people that are using this? Like, is there developer enthusiasm for this and then waiting to like start to put that into production? Just how do you think of new proof systems in that dimension? **Speaker B:** Yeah, I think for like we have, we are still very aware of the latest research because I think even as like application developers it's, we still have to be responsible for like if for example, this new lookup argument came out and we implemented it in our proofs, in our proof system we were using for our light clients and then it sped up things by a lot. So we do have to be aware of the research, I would say like on the engineering to research spectrum, we are like aware of the research and we like keep up to date with the state of the art papers. But like we're not writing papers so we're not like that far along that the research spectrum. But we're still very aware of what's going on and I think that's important for a company like us to always keep on innovating and be at the bleeding edge. I do think compared to a lot of other ZK teams, we are a lot closer to the app layer. And actually getting, we're really focused on oh, what's the use case, what does this enable? How is this going to be important for us, our applications or other developers building applications. So I think in that sense we try to be close to the app layer and the user layer because also we care a lot about that and we think that's what's important. So yeah, that's kind of how I'd say we fall on that spectrum of engineering. **Speaker A:** And maybe who knows, you'll get to a point where you open up that backend like the engine portion so that anyone can plug in their Pro system and somebody else might do the work for you of implementing the paper that came out five minutes ago or, or the researchers themselves can put it in your system and see if it works before they even release the paper. Like that's the cool part about building a modular company. **Speaker B:** Yeah, for sure. I mean that is definitely the goal. Like we think the platform is really useful for like app devs because you know, it just helps them with their development and deployment workflow. But then we also think that like if you're a new proof system and you want people to use you, like you can plug into our standards and then it becomes you just gain a lot of distribution because now it becomes easy for any application developer to try out your stuff. So we kind of view it as this two sided, almost marketplace thing where there's benefits to both sides and then they can come on our platform and coordinate and then it's a really positive sum game to be playing. So that's definitely our intention is we want new proof systems that are like five minutes old to be integrated into the platform and available for everyone to use. **Speaker A:** For sure. For sure. So while we're still in like the, I don't know this part of the conversation, how do you guys think about the role of ZK hardware and like where there's just so many interesting companies right now from like Sisig to Inguayama to like a lot of the like research is coming straight out of the EF for the verified, sorry the verified delay function stuff like clearly whatever the role is going to be, however important it's going to be, there are going to be ZK based like Asics and hardware. How much are you guys thinking about that whole field as important to what you're building both in the immediate term and in the long term? **Speaker B:** Yeah, I think ZK hardware is really interesting and hopefully is what, you know, takes proof generation time to like the next order or orders of magnitude of Being you know, performant and fast for us, I think again like we have this more modular approach where like hopefully one day also as the hardware gets like more mature and like more production ready, it can also be another actor that like ends up coordinating on our platform. So like it's kind of this like three sided coordination game of like application developers, proof systems and then hardware and like hopefully the standards of the platform, the components and like, you know that that platform becomes like this coordination layer for all these actors and like the ZK supply chain of the future. I my impression of hardware now is that the hardware teams are still like working a lot to get their stuff actually usable and production ready. I think some challenges they face is kind of around like they also kind of have to bet on like what proof system or approach is going to. **Speaker A:** Work more than most. **Speaker B:** Yeah. And so they're like really exposed to that kind of risk, I guess. And so I think that's like a challenge for, for their teams to kind of like deal with and figure out. I think one interesting thing we've seen with teams like Ulvitana is like they are designing next generation proof systems in I think coordination with their hardware. So I think that's like a really interesting approach where like they have expertise on both and then they can really tailor the two well together with their like more recent work on Phineas, I think it's called. So yeah, I think that's like really interesting. And yeah, I think for us like the hardware companies, I think most are still like fairly on the earlier side of things. I, some, some are actually like working. But yeah, I think as they become like a bigger and bigger actor in the ZK supply chain, like hopefully we can also start involving them more in like the conversation between app developers, systems and like that hardware piece. **Speaker A:** Yeah, I mean, I think, I think what we're learning as computer scientists, like we learned on day one and just it's gone in the background and now it's coming back and like making sure we know enforce is just the power and the importance of modularity and like whether that's the modular blockchain thesis and how we're like all designing our life's work to like look or it's how you as an entity are deciding to build a company. And I think that this is just what it means to be developing responsibly, I guess in such a high innovation environment is like you build out what you can today and you just prepare for everything to get better and maybe not at the same rate, but you Just got to know that everything will get better, like probably faster than you individually can do yourself. **Speaker B:** Yeah, I'm like a big believer that you know, we'll have thousand x the ZK compute in like a year or two. And so like we should all be building and thinking of applications with that frame, like that kind of frame of reference in mind. **Speaker A:** And man, I can't believe this now but I think it's been two years. I think it was 2021 and it was Thanksgiving. The Starkware guys came on a bankless podcast and I remember somebody said something to the effect of yeah, already today we're doing protein folding calculations on Stark. Net or whatever on starkware. And you know, it's like why would you do that? Like there's no reason to do that. But the point is it's just like really hard computational stuff that I don't, now that I know more, I don't even really know what it means to say they were doing it on starknet. But just I'm a huge believer that order of magnitude improvements just open up entire new applications and entire new visions. And like that's how we got from like the text based ARPANET to GeoCities to having like live conversations amongst thousands of people at once. And so what that means for zk, I don't know. But maybe that's the pathway to my robot based ZK future. **Speaker B:** Yeah, that's, that is like a. I had not heard of that use case of zk. And yeah, it is. I don't know, I also don't really know what it means. But yeah, it is interesting to think about like oh yeah, in one to two years or like even 10 years, like what stuff will be in ZK? Like maybe one day the entire NYSE will be ZK iFied. Right? Or like you know, let's like, let's think really big. Like maybe all of these like finance venues will have to generate a ZK proof that you know, the orders were executed in this particular way or whatever. So yeah, it is kind of like nice to let your mind go crazy. **Speaker A:** Yeah, no, and I just think it's especially important in this field to take a step back and be like wait, why are we creating these moon math primitives? And I hope some people are thinking past the blockchain layer. But anyway, with the last 10 minutes that we have here, I would love to talk about your guys latest announcement which is the succinct developer port platform. So can you talk a little bit about like what, what you guys announced and like what people can come do and I guess like some of the things that people are doing. **Speaker B:** Yeah, so yeah, I mean I've already been like kind of mentioning it throughout this podcast, but the succinct developer platform is kind of this place where we want to bring kind of state of the art, like best in class tooling for any ZK developer in this modular, proof system, agnostic way. And today we've already been using it internally for a while to develop our ZK Lite clients. And that was kind of the original inspiration for building this tooling. So all of our ZK Lite clients, whether that's our Ethereum one or the Celestial Light client or the Avail like client, are all projects that are hosted on the platform today. Another important piece of the platform is it has this like discovery layer. So if you're not a ZK developer, you're just like an application developer. Maybe you don't even know that much about zk. One really nice thing about the platform is you can go to alpha sysing, dot, xyz, slash, discover and you can just see like what projects are out there, like what proof systems are people using. What is possible with zk? Like what can you do today? Like you know, what interesting class of applications even exist? And I think like that discovery layers really important for ZK to even just like educate people on what's possible if that makes sense. And that's like something we thought was like really underemphasized in the space. So yeah, the platform is like general ZK developer tooling helps you manage like circuit build circuit artifacts like remote building, one click verifier deploys scalable APIs for proof generation, hosted relayers like manage production grade infrastructure on chain requests, off chain API calls for proofs, like all that stuff that if you're a ZK developer today is a huge pain point. And I think a platform involves a lot of that. And yeah, in general it tries to make ZK applications just more legible to the public. Yeah, so that's kind of like the goal of the platform and we've been using it internally to build these clients. We've also been building like for example the Lido Oracle that I mentioned earlier with the platform. Like a lot of our ZK projects are built with our platform and it's really helped us go faster. And now we're opening it up to the world and we announced it publicly because now we want other people to start building with it because it's finally in a spot where it's I Think good enough for external use. **Speaker A:** And this is, I don't know, a little bit of a soft question, but let's say you had this developer platform as it stands today, back when you guys were developing the Gnosis chain. You said before that took you six months. Like, what would you roughly say, like, having these ZK tools but not having any of the bridging infrastructure and like just coming to the table knowing you want to build a bridge. Like, how long do you, how quickly do you think that you could get the job done? **Speaker B:** Yeah, I think with the platform it would honestly have taken us maybe one to two months to get it done. Yeah, like, I think a lot of the stuff we had struggled with or is like directly solved by the platform because like we created the platform so we were solving our own problems. But yeah, like, even with our new like clients, they took one to two months to like develop. I mean developing the circuit primitives are, you know, took longer, but now that's kind of done and like reusable by anyone. But then the actual process of productionization was like, like one to two months and that just like, would have not been possible before. So, yeah, I think it's like a 10x over like our previous experience. And it's also a lot more fun because I think the platform takes care of all the boring stuff that no developer likes to do. Like all the infrastructure, like, you know, like setting up an EC2 and like, you know, pushing your artifacts to S3 and like setting up managed build pipelines and stuff. Like that all sucks. Like, that's not, that's not the fun part about building a zk and like, we take care of that. So you get like. I think it's also a lot more fun because like you can focus on like the interesting math parts, the interesting circuit parts, like the stuff that's actually specific to your application and then all the like glue and like behind the scenes stuff is like taken care of. **Speaker A:** For you, you know. So I'll tell you a quick story. This summer I had the opportunity to have a few minutes with Professor Dan Bone and he. I mentioned to you before, and I've mentioned on this podcast many times, I went to Stanford. And so he was like, oh, do you know the story of alchemy? Like where they came from? And I was like, no, I mean, I guess I don't really. And he's like, it's a pretty cool story essentially. And I forget especially like exactly what it was, but they were either developing a game or a Dex or something and it didn't really go that well. But what they realized is they spent so much time dealing with RPC stuff that they realized like, oh, everything that we did in order to solve our own problems is a product and we should just like double down on this thing. That's actually pretty great. And so, you know, I, I, back in the day in like 2013, I was messing around with stuff. Not blockchain stuff, but I was messing around with building apps that could send text messages. And like, Twilio was just perfect. You know, you didn't have to worry about like networks or how to communicate across like any of this stuff. You just, it was literally an API and like, maybe you had to fund your account, but it was just taken care of for you. And so I think like, there's so much opportunity in what you're doing and there's so many like, clear examples like alchemy or a billion things outside of our industry that this is a path to a unicorn. That I'm just like so excited for you and so impressed and yeah, just excited. So congratulations. **Speaker B:** Oh, thank you. No, that, that means a lot and yeah, no, it's like great to hear. I mean, I think it's just like the start of like a lot more work to come. But yeah, no, I think like the early support is like always very meaningful and yeah, it's like, great to hear that. Like, I think people like you who are like, really familiar with the ZK space are like excited about the ideas because we've been like, hard at work, you know, building this stuff for a while. **Speaker A:** Well, what I just like, really, really believe that. Like, I love all you guys, but like, we're really big nerds and I think that everyone wants to be as like, nerdy as us and like, let's let the application developers focus on building applications and like the game right now, whether it's what you're doing or what a lot of the hardware companies are doing or a lot of people are doing in their own way is like, let's create, let's turn this from Moon Mat gibberish into things that developers are familiar with, like APIs and just modern, like computer science paradigms. **Speaker B:** Yeah. **Speaker A:** Cool. So last few minutes, like, can you tell us, like, what are like, how is the developer platform going to evolve? Like, what are the things that you're excited to, to, to add on? Is it more about like performance? Is it more about new features around the harnessing? Is it more about new proof systems? Like, what are you excited about as now that the Developer platform is externally facing things. **Speaker B:** Yeah, I think the thing I'm most excited about is like the applications, like what are people going to build that's new with kind of like the tooling. So that's really exciting. I think integration of new proof systems is also really exciting. So today we support like a lot of the popular ones like circom, gnar and ponky2. But I'm also really excited to integrate things like Noir or even like I think ZK VMs and ZKE VMs are becoming like really accessible. And so I think for some use cases like that may not need as much performance. I think they're also a great fit. And so for example, we can imagine like integrating for example an existing zkeVM or a ZK VM into the platform and making that accessible for people. Or things like ZK WASM or like what Rezero is doing or scroll zkvm I think are really exciting to integrate into the platform. So yeah, I think basically applications and then also integrations to make it easier for those application developers to use that tooling. Very exciting. I think those are the things that we're looking forward to doing and always improving the developer experience with the customer feedback that we get. **Speaker A:** Well, if I can make one request is can you start doing the Stark stuff? Because I, I am so impressed by them, but I don't understand why. It's like such a kind of segregated community and I understand it's like such a different amount of math but like I want, I don't understand how there's so much TV on starkware and somehow I don't know any of the starkware people. **Speaker B:** Yeah, yeah. Like we could integrate Cairo onto the platform too. Like you write Cairo and then it's deployed. That's actually pretty interesting and I had not thought of that. Yeah, no, Cairo could be a supporter proof system for sure. **Speaker A:** Cool. Well, we could talk afterwards about my like really just off the cuff bad business ideas. But Uma, thank you so much for joining us on the podcast. Before I let you go, can you just tell everyone where they can find you, where they can find Succinct and if they just like want to learn how to get involved in ZK or like learn the things that they need to learn in order to build on Succinct, like what is your recommendation? **Speaker B:** Yeah, so you can follow our Twitter account @SUCYNC LABS. On Twitter, we generally post all of what's going on there and then you can go to our website Succinct XYZ and, like, kind of describes, like, our platform and, like, what it does and kind of, like our philosophy, too. I think our blog is also a good resource for, like, a lot of our announcements and kind of, like, the vision of what's going on. And then, yeah, the platform's available @alpha succinct XYZ, so you go check it out. Like, anyone can, like, deploy our demo application there. It's still in alpha, so if you want to deploy your own ZK thing, you just have to, like, reach out to us, but. And then we can whitelist you and then you can, like, go deploy your own repo. Yeah, those are kind of, like, all the resources. We'll probably have, like, some docs coming soon. I think right now the best way is just to, like, reach out to us on Twitter or dm and then, yeah, we can, like, help you, guide you through that process. We're always, like, super happy to help. Yeah, I think those are kind of, like, the main ways of interacting with. With us and the platform, I guess. **Speaker A:** Cool. Awesome. Well, thank you so much, Uma. Again, I. I hope I just, like, made clear how, like, awesome I think what you're doing is and how excited I am for you and just wish you the best. So thank you again for the time and I don't know, have a good rest of your day. **Speaker B:** Yeah, thanks so much for having me.