Anna Rose (00:00:05):
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:00:27):
This week, Tarun and I chat with Succinct Labs. Guests, Uma and John explain how they got interested in Zero Knowledge Tech. We talk about their work at 0xPARC as well as the goals of Succinct Labs. That is to provide proof of consensus through SNARK based like clients. Their offering acts a little bit like IBC, but in the Ethereum context. And we discuss the challenge of building this kind of light client on Ethereum, their first implementation linking Gnosis Chain to Ethereum and how they imagine interacting in other cross chain environments. Both Tarun and I are investors in the project, Tarun via Robot Ventures, myself through ZKV. And this is something that wasn't confirmed at the time of recording, so I thought I'd mention it here in the intro. Now before we start in, I wanna invite you to join the upcoming ZK HACK III, a virtual multi-week event starting on November 22nd.

(00:01:16):
It's all online so you can join from wherever you are. It's the third time we've run this event. And I can tell you ZK HACK is a very special event. It's a combination of a multi-week series of long form workshops from the best teams working in ZK teams like Aztec, Risc0, Aleo, Anoma, Scroll, Mina, Sismo and EF's Privacy and Scaling Exploration Group. These workshops are designed to onboard and show developers how they can start working with zkDSLs platforms, tools, and tech. Each workshop is different, so have a look at our schedule and sign up for the events that you are most interested in. Now, the workshops are designed for all levels, but we at the same time have something for the experts or the folks who really wanna challenge themselves. So every week we release one of our ZK puzzles that is a broken ZK system of protocol. Find the bug, submit an answer as quickly as you can, and you can rank on our leaderboard. We'll have three puzzles in total and as mentioned, we release one each week. The winners of these will get prizes, spotlights, and a lot of credit within the community. So even if you aren't an expert, you still might wanna give it a shot. Keep an eye out on our Twitter and in our Discord, links are in the show notes. And yeah, I hope to see you there. Now Tanya will share a little bit about this week's sponsor.

Tanya (00:02:34):
Today's episode is sponsored by Aztec. Aztec Network is building the first privacy enabled zkRollup on Ethereum. The team is proud to announce Noir the world's first universal ZK language Noir makes it safe and intuitive to write privacy preserving ZK circuits. Aztec is now hiring engineers and cryptographers to build the execution layer supporting Noir's private smart contracts. Join the team making private Ethereum a reality. You can learn more by visiting aztec.network/careers. That's aztec.network/careers. So thanks again, Aztec. And now here's our episode

Anna Rose (00:03:14):
Today Tarun and I are here with the folks from Succinct. Welcome Uma and John to the show.

Uma Roy (00:03:20):
Hello. It's good to be here.

John Guibas (00:03:21):
Yeah, thank you so much for having us.

Anna Rose (00:03:24):
It would be great to hear a little bit about the two of you and obviously we're gonna be getting into Succinct. I wanna hear like at what point did you get excited about ZK? Because I feel like this, your journey's pretty fresh, right? Like you got in this year.

Uma Roy (00:03:40):
I started working on ZK related stuff actually around this time last year.

Anna Rose (00:03:45):
Cool.

Uma Roy (00:03:46):
I'm really good friends with the person who runs 0xPARC @gubsheep I think is his handle and yeah, we knew each other for, for a very long time. And so he was the one who originally pulled me in, told me about ZK and that's how I started. And when I started I was actually working on stuff related to ZK identity. So I was working on an anonymous message board and other fun kind of anonymous social experiments and then decided to do something more in infrastructure and that was like more technically meaty. But I've been working on ZK stuff since I guess like for a year now, I'd say.

Anna Rose (00:04:25):
Cool. And John, what pulled you in?

John Guibas (00:04:28):
Yeah, on my end I was like really interested in like machine learning and database systems and yeah, throughout while I was doing this, I was actually working with this math professor at UChicago called Yi you should definitely interview him and Jonathan sometime.

Tarun (00:04:43):
Wait, wasn't he, wasn't he on at some point? Oh no, no, no. We had his collaborator.

Anna Rose (00:04:49):
I don't know. Wait, Yi?

Tarun (00:04:51):
What's his last, what's the guy who's at San Jose?

John Guibas (00:04:53):
Yi Sun

Anna Rose (00:04:53):
Yeah, yeah

Tarun (00:04:54):
No, no, no. What's Yi friend? The guy who

John Guibas (00:04:56):
Oh, the consensus guy. The consensus guy

Anna Rose (00:04:58):
Gasper.

John Guibas (00:04:59):
I heard his name too.

Tarun (00:05:00):
Yeah, Yi came up during that episode. Oh, also, hi, I'm on this episode.

John Guibas (00:05:06):
Yeah. So I was like doing machine learning research with Yi and then separately I had gone down this like huge rabbit hole in crypto because I thought it was just like super cool both on like the system side and theoretically. And then Yi actually suggested I looked really into ZK. I hadn't really looked on into it at this point. And he referred me to like the 0xPARC folks and I actually ended up spending a summer there and that's like where I met Uma and my whole ZK adventure began.

Anna Rose (00:05:31):
When was that?

John Guibas (00:05:32):
That was around May I think. Yeah, I actually quit my like, original plans for the summer to do ZK with 0xPARC.

Anna Rose (00:05:40):
Cool. What is it like to join the ZK space right now? You joined this summer, John, like what does it feel like joining this industry? What does it look like as you, as you get onboarded? Is it complicated? Is it easy

Tarun (00:05:52):
Industry, air quotes,

Anna Rose (00:05:53):
Industry space? Um, but yeah

John Guibas (00:05:59):
Yeah, I think it's a really exciting time right now. I mean I think I was, I had like basically the perfect background to get started in ZK. Like I had a strong math and CS background and I think those are like strong prerequisites for getting to this space. But you know, there's a lot of really good learning materials. You know, actually, like 0xPARC has this website called learn.0xPARC.org that I'd recommend for anyone like getting started with ZK. He posted all like the lectures he did for his ZK learning group. But at the same time it's really exciting because there's all these new frameworks, all these new proving systems and the design space for how you could even build the same ZK system is so large that I think actually this space like really reminds me of when I used to do like research in academia in the sense that, you know, you really have to like go deep. You have to read the code itself and the papers itself to like figure out what's really going on.

Anna Rose (00:06:43):
And Uma you've been in it for a year when you joined, like yeah, how did you take it? What did you think about the space?

Uma Roy (00:06:49):
Yeah, I think similar to John, I also had the perfect background for it. In high school I was super into math. I was actually reading about elliptic curves and you know, I was very into number theory in high school and then, you know, continued some of that in college. And so it's kind of funny that it's now coming back with the stuff I'm doing full time with ZK. I think, like John said, the space is super exciting. It feels very new, it feels very underexplored. There's new proving systems that are coming out and getting published, you know, every month. There's just so much activity on, you know, people discovering what the possibilities are and it feels like a big community that where everyone knows each other since it's still or not a big community. It's a small community where everyone knows each other. So that I think is also pretty fun because you see the same people over and over again and you can kind of get to know them over time.

Anna Rose (00:07:39):
Do you feel like, are you in ZK or are you in blockchain? Like did you just enter the blockchain space or the ZK space? I know this is a bit of a weird question, but I do feel like there's this slight shift, there's a lot of people now that are coming just through ZK. They're not necessarily coming, you know, from other projects that have been around for a while.

Tarun (00:07:58):
Are you're, you're really asking them are they Degens or not

(00:08:03):
Were or are you Degens?

Anna Rose (00:08:05):
Where you, or have you ever been?

Uma Roy (00:08:08):
A Degen? I think personally I have, I like the Degen spirit. I don't know if I'm personally a Degen, but I think I like crypto's values and ideology. I think I wouldn't be in this space, you know, I don't think it's sufficient to just think just the ZK math is cool or something like that. I think for me, like I also really align with the values of the space more broadly. And ZK is such a perfect, or zk-SNARKs are such a perfect fit for blockchain, right? Like you can get privacy on this public ledger and then you can get scalability on this decentralized ledger. And so because it's such a perfect fit, I think it's hard to have one without the other.

John Guibas (00:08:50):
Yeah, I think on my end I feel likeI definitely got originally nerd psyched by crypto by itself. Like separate from ZK and I think like what really got me into crypto was like the concept of DeFi, like how cool AMMs work. Actually, like one point I like emailed Guillermo to do like CFFM research with him and, but I think

Tarun (00:09:11):
And then rug pulled him

John Guibas (00:09:13):
Yeah

Tarun (00:09:14):
Don't worry. He told me, he was like, there's this undergrad, I remember he was like, there's this undergrad who emailed me and then he disappeared

John Guibas (00:09:24):
Oh no. But I think ZK has largely advanced because there's been so much interest in the ZK VM. Like I think the ZK VM teams, like single handedly moved all this like research like five years forward in terms of like productionizing it and I think now we're starting to see applications of like ZK, like outside crypto and I think like the folks that like RISC Zero are definitely like candidates for this. I think there's this whole field of like ZK ML that's brewing, right now. And I think for the short term probably applications of ZK will be largely blockchain because blockchains are one of the few systems that really care about accountability and it's like a really obvious use case. But I think we're just getting to the tip of the iceberg for what's possible.

Anna Rose (00:10:02):
Mm.

Tarun (00:10:03):
So so actually, one, you know, instead of the blockchain versus ZK question, I think a more pertinent question is both of you came from ML, which is like the most centralizing anti privacy technology movement that exists on this planet. So like what made you make the pivot? That's like a, that's a big jump from that world to this world.

Uma Roy (00:10:29):
Wow. That's strong opinions on ML. I still personally like ML, a lot of my friends do it, so I can't

Tarun (00:10:35):
Sorry. Those were my opinions not

Uma Roy (00:10:40):
Yeah, I think for me honestly crypto and its ideology and kind of crypto feels very underexplored with ML. I think as you said, it is very centralizing, especially with large language models. Having a billion dollars to throw at GPUs to train your huge model is a huge advantage. And crypto feels more of this renegade movement where it's not super clear what's gonna happen. You know, there's still so much undiscovered stuff, people trying new things with ML it feels more clear like what you can do with it. Like now people can see, oh now I can train this language model to mimic, you know, X, Y, Z or whether that's like a book or emails or whatever else. And especially with the image stuff like Dolly, I also think it's really cool, but I think with crypto there's a lot more emergent behavior that is a lot more interesting and unique in some ways and I think that to me that was very inspiring. It felt like you don't know what's gonna happen here and it's very exciting.

Anna Rose (00:11:42):
It sounds a bit like to work in ML, you're probably gonna be working on a project whereas because there's so much space in our space, you can actually do your own project. Like you have founded a company. Would you be able to do something like that in ML do you think? Like right now?

Uma Roy (00:11:57):
Yeah, probably. I mean, there's a lot of ML people founding companies right now with especially all the generative AI stuff. So yeah, I think that that's also very exciting.

John Guibas (00:12:08):
Yeah, I think the difference is like in crypto it's much easier as an individual to have a much higher leveraged impact into the space just because it's still so small still so early. I think in AI like you just need a lot of money, you need a lot of engineers unless you have like some super great idea. But even then I think there's a lot more low hanging fruit in this space.

Tarun (00:12:27):
I think the bar is also a lot higher to like go from zero to something in ML in the sense that like there's a little, like even though it's like, you know realistically like not that old of a field, there's still some feeling that you need to have some like apprenticeship logos on your resume. Like worked at Deep Mind worked at Faro, like did X or Y like whereas in crypto it's like literally you could just be an anon anime character and like, you know, start the project

Uma Roy (00:12:56):
Yeah, I think the vibes are better in crypto.

John Guibas (00:12:59):
Yeah, like another thing in crypto is like, I think people have like something they want to prove to the rest of the world and like they wanna say, oh you're wrong and I'm right. I think in machine learning like that doesn't exist. Like no one's trying to like there's no like interesting drama going on on Twitter often. Like crypto's way more interesting on that front.

Tarun (00:13:14):
I mean all the drama and AI is just like who raised more money for GP

Uma Roy (00:13:20):
Yeah.

Tarun (00:13:22):
Or AI ethics fights where it's like crypto somehow seems to have avoided that part of this, the sphere for the most, which is like a funny trade off.

Anna Rose (00:13:31):
You both went through the 0xPARC program, kind of community. Tell me a little bit about like what it is to work in there, how does it work? This might actually be cool for our listeners who might be interested to get involved. Like how does one join that community?

Uma Roy (00:13:46):
Yeah, I think 0xPARC is basically this R and D org for Applied Cryptography. So also they have some people working on autonomous worlds and I think they're really modeled after the Ethereum Foundation from my understanding. Like the whole idea is to empower other teams and other people in the ecosystem to go explore and like build and have a really nice community environment that's very collaborative for everyone to explore ideas together and figure out like what's interesting and cool and you know, I think also a very strong core value of theirs is to not have anything that's super grifty or things like that. So you know, I'm actually like quite good friends with the founder and like other people in the community. So for me over the summer working with other people in the community, it was just really fun because it was basically like we're working on really cool stuff with all our friends and we get to hang out and it was really good energy and yeah, obviously I met John there, which was amazing.

John Guibas (00:14:44):
Yeah, totally great. I think @gubsheep, I don't know why we're not actually saying his name.

Anna Rose (00:14:49):
No, no, no. He's @gubsheep. He's been on the show.

John Guibas (00:14:50):
He's @gubsheep.

Anna Rose (00:14:51):
@gubsheep. It used to be on the show as a different name, but now he is @gubsheep on the show. Okay.

John Guibas (00:14:56):
Okay. Yeah, he's done a really great job like cultivating the community and like, a sense of culture of strong collaboration and making it really easy for example for me to like onboard into the whole ZK space and get to talk to like and learn from like the smartest people. So I think for me it was like a really instrumental part of my ZK journey and I'm super thankful.

Anna Rose (00:15:17):
I do actually wanna ask though, what's the hardest part you found as you joined like starting fresh in ZK today with the documentation that exists, the resources that exist, what's hard?

John Guibas (00:15:27):
Yeah, I think some of the tooling is a little bit buggy I think.

Anna Rose (00:15:30):
Okay.

John Guibas (00:15:31):
I mean how to deal with a

Uma Roy (00:15:32):
to say the least

John Guibas (00:15:33):
lot of weird bugs

Tarun (00:15:34):
Okay. What's your all time favorite bug that you've run into? And my favorite, you can interpret it as you thought it was enlightening at the end or it was infuriating and you wasted a week and it turned out you missed a quotation mark somewhere.

Uma Roy (00:15:48):
Oh John, I feel like we're thinking of the same thing.

John Guibas (00:15:51):
Yeah.

Anna Rose (00:15:52):
Oh wow. There is a best one. Let's hear it.

John Guibas (00:15:56):
Wait, wait. I think we can't name the library though.

Uma Roy (00:15:59):
Okay. Okay.

John Guibas (00:15:59):
The library is overall amazing,

Uma Roy (00:16:01):
The libraries are all amazing, but there's a certain library we were using and it has this property where if you initialize a variable and you don't use a certain part of the variable, it won't throw an error. Like at compile time it will just throw a runtime error. But the runtime error does not really tell you anything about the error. It just says seg fault. And so we spent a week, you know,

John Guibas (00:16:26):
No I think it was like a week and a half. I mean we weren't like actively doing it but

Uma Roy (00:16:30):
Like every night I would spend a few hours looking at the seg fault, not understanding what was going on. John was deep in like GDB, I was just looking at the code and one night I was like, okay, I'm going to stay awake until I figured this out. So I stayed awake until 4:00 AM and I realized, you know, we had initialized an array of size a 100, but we were only using 99 of the variables and that was causing this error. And so I changed, it was one character I just initialized, I changed a 100 to 99 and then it worked.

Anna Rose (00:17:00):
Did you tell somebody?

Uma Roy (00:17:01):
Yes, we did. We did they, I think they fixed it.

Anna Rose (00:17:04):
Okay.

Tarun (00:17:04):
Or did they at least add an error message? Like a helpful error message?

Uma Roy (00:17:09):
I think they fixed it because I haven't run into that again. Yeah, but

John Guibas (00:17:15):
You really can't blame them though because like they're doing it all open source since like I don't know like what if they're even getting paid to do it, so

Uma Roy (00:17:22):
Yeah. Yeah. It's, it's a heroic effort from them. So

Tarun (00:17:26):
Someone needs to make Coinfessions like the thing where people confess their sins <inaudible> for bugs and features. Yeah, actually you guys worked on Coinfessions

Uma Roy (00:17:40):
Oh yeah, whatever. In a previous life we were working on an anonymous message board.

Anna Rose (00:17:47):
Oh

Tarun (00:17:47):
With ZK

Uma Roy (00:17:48):
With ZK

Tarun (00:17:49):
At 0xPARC right?

Uma Roy (00:17:50):
Yeah. Yeah.

Anna Rose (00:17:52):
Cool. I actually wanted to ask you Uma about like the iterations, like the problems you started on ID like other problems. know we met about like a different project too like some time ago. Yeah. Tell me a little bit about how you got to the problem you're working on. What was your pathway there?

Uma Roy (00:18:09):
Yeah, so the original stuff I was working on was, you know, building one of the early experiments was ZK message. So it was this anonymous message board where you could kind of post as one of n members in a group. So you'd have like a ZK proof that you belong in this group without revealing who you are and then you can post messages tied to that identity without revealing your exact person. I still think it's a really, really cool concept and there's been several evolutions and iterations of the idea that, you know, some of them I was working on, some of them are with different people that used to be collaborators. I thought that stuff was very fun and very interesting but I think for me, I really like solving really hard, challenging technical and engineering problems. And I think there with ZK identity or ZK social kind of in air quotes as like a category I guess, I think it's a really fun category, but I think the ZK part is actually very simple. Like it's already been kind of built. It's not anything complicated. It's more about building this like product experience. It's gonna go viral or you know, whatever other goal you might have around it. And for me I wanted to do something just like much more technical engineering heavy. And so ZK for infrastructure I think was just something I wanted to explore and, you know, and ended up working on and found very, very interesting and very, very compelling.

Anna Rose (00:19:27):
Nice. Well I think this is a really good moment for us to define what Succinct is. Before we started, I tried to call it a ZK bridge and you quickly corrected me. So I wanna hear from you what is Succinct doing and actually what kind of, what category do you put yourselves in?

Uma Roy (00:19:45):
Yeah, so what we're building is a trust minimized interoperability layer for blockchains, you know, including Ethereum and other blockchains to be able to communicate with each other in a native way. So the tool we use to accomplish this is, you know, Succinct to non-interactive proofs. And then I think ZK has become this like catch all term on Twitter to refer to these Succinct proofs. So people will refer to them as ZK proofs or zk-SNARKs

Anna Rose (00:20:14):
When there's sometimes just SNARKs and not ZK

Uma Roy (00:20:17):
Exactly, yeah. So I think, you know, with the zk-SNARK you can kinda get two things. The ZK part, the zero knowledge part lets you kind of hide the inputs into the function you're proving and the succinctness part gives you scalability. So the succinctness lets you have this like succinct proof that some computation has resulted in a certain answer and you know, we're using the succinctness properties to basically scale verification of consensus. So what we're doing right at the highest level is, you know, if we have a source chain and a target chain that are trying to communicate, we'll verify the consensus of the source chain in the execution layer of the target chain. And then once you can verify the consensus of a source chain in the execution layer, then you have access to the block header.

(00:21:00):
And once you have access to the block header, you can prove anything about what happened on the source chain in the context of the target chain and take actions accordingly and vice versa and you can pass arbitrary messages and you know, you can build a token bridge, you can just do whatever you want with this communication. There's no ZK in it. Like we are using succinctness to scale this expensive computation of verifying consensus. and that's why the company's called Succinct. You know, I was looking at all the ZK companies today like, and all of them have like ZK in their name

Anna Rose (00:21:30):
Start with the letter ZK. Yeah, yeah. Like, like everything I do.

Uma Roy (00:21:35):
Yeah.

Tarun (00:21:35):
And I mean crypto you know, while I admire the ability to fork everything and copy your thing, there is this like tendency to have no originality in naming. Like every L 1 has Hoka X, Sole X, Cosmo X and there's like a million of the same like name things. And I feel like ZK is just like bear market

Anna Rose (00:22:01):
It's starting to feel like that

Tarun (00:22:02):
It's starting to be like that

Anna Rose (00:22:03):
Yeah. Although I, okay, I'm gonna just give myself a little credit that it, when I started with the ZK naming, there weren't that many, just fyi.

Tarun (00:22:10):
Sure

Uma Roy (00:22:10):
You were the OG

Anna Rose (00:22:13):
I totally agree that like, it sort of has, there's projects now that are called ZK that aren't ZK

Tarun (00:22:19):
But that's success for the concept. Like a concept has reached success when it gets copied. You know, imitation is the form of flattery.

Anna Rose (00:22:25):
Totally.

Uma Roy (00:22:25):
Yeah, that's true.

Anna Rose (00:22:27):
But Uma, I wanna, I wanna go back to what you were saying because like you just described, like when you talk about that proving and so it being succinct, are you talking about light clients though? Like are you talking about two light clients on two different networks talking to each other?

Uma Roy (00:22:42):
Yeah, that's exactly the idea. It's very similar to IBC's concept, which is like, light clients for interoperability and then we're making light clients gas efficient enough for expensive block space chains like Ethereum for example.

Anna Rose (00:22:56):
Cool and here you're not using any of like the economic games. You're not, so it's not optimistic, it's pure cryptography, but like why is it different from, I mean I kind of know the answer, but like do ZK-rollups do the same thing as what you're doing?

Uma Roy (00:23:10):
Yeah, so ZK-rollups are using the succinctness property to scale execution. So in a ZK-rollup, right, you're proving that I have some state of the world and then I applied a bunch of transactions and now this is the new state of the world and the proof is just proving I process the transactions correctly. I'm not sending random people, random coins, things like that. So we're kind of using the similar properties for a different computation.

Anna Rose (00:23:35):
Hmm. Where do you start with that though? Like do you already have two chains that you're working with? Are you thinking of this as like chain agnostic and you're creating just the ability for any network to do it? Like I'm kind of curious like how customized these like clients actually have to be.

John Guibas (00:23:51):
Yeah, so right now what we have is we spent all our time getting this sort of proof of consensus idea working for Ethereum. And in particular right now what we have is a custom made circuit that proves that a random subset of 512 Ethereum validators have signed off on a block header qnd basically what this allows you to do is you can verify these proofs on any other execution environment. So that could be Solana, it could be Avalanche, it could be even your laptop. And this allows us to have basically trust minimized access to Ethereum State because what we do is essentially run a light client. So right now what we have is a unidirectional bridge essentially from Ethereum to any other chain. But in the limit what we can do is we could for example, do it for other ecosystems or other consensus protocols like Tendermint. And combining these two things would give you a two-way bridge.

Anna Rose (00:24:45):
When you say it's unidirectional, like where does a light client live in that case? So it's from Ethereum out, are you saying it's a light client that people deploy outside of it that can talk to Ethereum?

John Guibas (00:24:55):
Yeah, so essentially we have like a smart contract that we can deploy on any chain that we want to run the light client on. And you basically want to run the light client on the chain that's receiving the messages because the light client essentially keeps track of a ledger of block headers and the block headers essentially allow you to access state at any point in time.

Anna Rose (00:25:15):
Do those networks all have to be, or other chains have to be EVM?

John Guibas (00:25:18):
So the contract we have right now is EVM, but theoretically we could code it in any other language including Move or whatever Solana and Cosmos use.

Anna Rose (00:25:27):
Okay. But what like prevented people from doing this before? Is this a very hard problem? Has something changed that allows for this?

John Guibas (00:25:35):
I think a lot of people were actually thinking about this like I think Kobi and at Celo and and Georges were working on trying to like basically create some sort of light client bridge. I think the Cosmos people figure this

Anna Rose (00:25:46):
Is it Plumo?

John Guibas (00:25:46):
I think so.

Uma Roy (00:25:48):
Yeah, yeah. It's called Plumo.

John Guibas (00:25:49):
Yep and I think another thing is, you know, clearly the Cosmos folks thought this light client bridges were a really great idea. But I think another thing that people generally haven't realized right is like these blockchains as the nature of being these like distributed state machines already have an algorithm to agree on the state of the chain. So actually if you really want to build like the maximally secure bridge, I would argue that some sort of like light client based approach or some sort of approach where you verify the consensus algorithm itself in another blockchain really is like as far as you can get in terms of security. And I think this idea combined with the fact that, you know, the ZK VM teams have done a great job at demonstrating that these SNARKs are extremely scalable and you can do amazing things as much as running like entire execution by some of them. And if you combine these two things together, it comes clear that maybe something you can do is you can just verify the consensus algorithm of any consensus algorithm inside of SNARK and just verify that on chain. And I think me and Uma were kind of at the perfect, arrived at the perfect time where SNARKs were becoming more usable. This idea had been floating around and we were basically able to put these two things together to create, I think what was basically Succinct.

Uma Roy (00:26:58):
You asked if it was hard to do and I think yeah, the pain John and I experienced this summer to make the whole system work is an affirmative. Yeah, it's definitely hard. It's painful and yeah, like you mentioned, right, it's not as easily scalable per chain, like per chain you wanna add that has a different consensus mechanism. You have to implement a SNARK for its consensus. So it's not this, if you set up like a multisig bridge, it's easier because you can

Tarun (00:27:24):
Well you trust that the participants did the consensus.

Uma Roy (00:27:27):
Yeah, exactly. So it's a hard problem to do in writing these circuits. While it has become easier over the past few years, thanks to the great work of the ZK VM teams and people like Zcash or you know, whoever else has been working in that space in developing these libraries, it's still, their libraries are still really hard to use to actually accomplish these goals.

John Guibas (00:27:45):
I mean I think there's actually this Twitter thread that me and Uma were like discussing it with like Georges and Kobi, but I think when we first started talking about our light client for Ethereum, some people on Twitter just couldn't believe it because they couldn't believe that the proving time for verifying these like BLS signatures, which is this elliptic curve that Ethereum uses could be verified in a SNARK in like a reasonable amount of time. So I think even like six months ago a lot of people didn't think that this idea was actually possible.

Anna Rose (00:28:11):
Is there some work that's been happening like libraries or innovations or something that allowed for that? Is it because enough people are going over this territory, the engineering's just getting like more efficient? Like how did you do that?

Tarun (00:28:23):
Well I, I would also maybe ask, add one thing which is like I think in the Plumo case they were going for a very different like end use case, right? They wanted to support a mobile wallet, they wanted to support Celo and like had slightly different consensus properties. There were sort of like a lot of things that went into that that like maybe like made it not obvious to see or like easy to see how to separate those from like the ZK or succinctness pieces because you're trying to like package everything as one thing for a mobile wallet which like adds in a lot of other concerns. I think stripping it down to the bare minimum and then also like yeah, being able to take advantage of a lot of the work done over time compounds much faster. And also I think like Kobi and Georges hadn't worked on that since 2020. Right.

Anna Rose (00:29:12):
Yeah.

Tarun (00:29:12):
Two years is a long is kind of a long time.

Uma Roy (00:29:14):
Yeah, totally.

Tarun (00:29:15):
Especially when you're having like these like more like exponential increases in performance due to just like, hey we like optimized caching or in stuff like that.

Uma Roy (00:29:25):
Yeah, totally. I think there was a couple things. So as part of proving this, like these BLS signatures you need to do non-native field arithmetic, like the elliptic curve that the SNARK uses is different than the elliptic curve the signatures are being proven in and doing non-native field arithmetic is just, it's honestly pretty ugly inside a SNARK and I think a lot of people were just averse to you know, doing something like that. And I think it turns out when you actually do it and you implement a bunch of optimizations, it actually does become like pretty possible to get a proving time that is realistic. Like it's not gonna be a proving time, that's you know, one second, but it actually is you know, still quite feasible and we actually have like an end-end working demo of a bridge today from Ethereum and we're using a testnet, so Goerli to Gnosis Chain but really it could be from Ethereum to any other chain and that's you know fairly performant like you know, you don't have to wait two hours or three hours for your assets to transfer. You know, it could be like it's a couple minutes on top of the Ethereum finality delay.

Anna Rose (00:30:28):
Hmm, that was actually my question about like using cryptography for bridge using light clients, like there's reasons that there are like optimistic bridges and these things, like there's this sense that it's supposed to be faster or somehow cheaper. Like are there trade offs that come along with what you've built or do you feel like because you've been able to get that size down or speed, like since you've been able to optimize it so much, is it actually like on par with those other solutions at this point?

Uma Roy (00:30:54):
Yeah, so compared to an optimistic solution it's actually much faster because in an optimistic solution you have to wait for this challenge period where anyone can like issue a fraud proof and for us, like we're just issuing the zk-SNARK that is of validity proof. So we just have to wait for the time it takes to generate a proof, which we're very confident we can get down to be relatively negligible and then we just post the proof on chain, it gets verified and it's quite fast. So I think compared to an optimistic approach, I'm a bit of a SNARK maxi and I think this applies even to my opinions of roll ups, but I think if a zkRollup is technically feasible, which I think now it seems like they totally are, then it's actually a better solution than an optimistic roll up because you don't have to wait for the seven day challenge period. So I also think the same thing of you know ZK or proof based, I like to call it proof based interop or a proof based roll up. But in a, I think proof-based interop is also similar, like if it's technically possible it's just strictly better because you don't have to wait for this challenge period.

Anna Rose (00:31:57):
Is it more expensive somehow?

Uma Roy (00:31:59):
So you have to verify the proof. So that's potentially more expensive, but the whole point of assisting proof is that it is cheap to verify. So it is like a little more expensive but it's not that much more expensive.

Anna Rose (00:32:12):
Cool. You talked about like what you've built so far is the Goerli testnet to Gnosis, tell me a little bit about that project, that deal, like how did that happen and what are you maybe being used for? Are you testing a use case for this or is it just like make the connection first?

John Guibas (00:32:29):
Yeah, so actually when we were first beginning this like research project on like potentially building like a zk-SNARK enabled like client, we actually collaborated really closely with the folks at Gnosis to basically build this technology because in their case, Gnosis chain actually implements exactly the same algorithm as Ethereum consensus.

Anna Rose (00:32:50):
Yeah.

John Guibas (00:32:50):
So if we could accomplish this ZK light client for Ethereum, actually this would enable a trust minimized two-way arbitrary message passing bridge between Ethereum and Gnosis chain and I think maybe Martin actually talked about this on your podcast. We got some funding from Gnosis Dow and that was actually what funded our research. But basically we first started off with the circuits, , we got it working, we coded the contracts and basically for the past like five months or so we've been working on the system and actually just like a few days ago we deployed the demo publicly and anyone can actually go ahead and try it like demo Gnosis to Succinct XYZ the progress of sending a token from Goerli to Gnosis chain.

Anna Rose (00:33:30):
Why Gnosis? Could you have done something else? Could you have done like Polygon as well? Like any equivalent EVM chain or was there like when you say sort of it was the same like yeah what was it specifically about that, that made it kind of a good starting point?

Uma Roy (00:33:44):
So as John mentioned, the nice thing about Gnosis chain is that they also use Ethereum proof of stake consensus.

Anna Rose (00:33:51):
Okay.

(00:33:52):
For their chain. And so if we can have an Ethereum proof of stake light client, then we can have a light client running an Ethereum for Gnosis chain and then we can have a light client running in Gnosis chain for Ethereum and so then we can have like the bidirectional message passing. We can deploy our Ethereum light client today to any VBM chain so like Avalanche, Polygon, you know, whatever else, Gnosis, et cetera and also all the rollups and like what that gets you is unidirectional message passing from Ethereum to the other chain and actually I think that's also quite interesting to do. Like there's actually a lot you can do with only passing messages one way from Ethereum and as an example for, you know, a lot of dapps have their governance living on Ethereum because their governance token lives on Ethereum and it's never gonna move off of Ethereum.

(00:34:41):
You know, you conduct a governance on Ethereum and then you use that to pass the message to control your deployment on another chain and so that's like a really perfect use case of unidirectional messaging. You can also imagine like other kind of use cases there's something called BTC Relay from a long time ago that actually uses this unidirectional messaging concept in a way to do trust minimized swaps between Ethereum and Bitcoin but at a high level, like the idea there is like say I have some, you know, token on Polygon and I want Ethereum on Ethereum or some other token on Ethereum, I can lock my token on Polygon in a smart contract and then I can say, hey world, like if you give me, you know, one Eth on Ethereum, you can unlock this locked token and so then someone can fill me on Ethereum and send a message of the fill to polygon and the token will be unlocked on the other side.

(00:35:34):
So actually unidirectional messaging I think is actually quite powerful already. Like for governance use cases there's, I'm sure there's also use cases like we haven't even thought of that would be really cool. And so I think with our Ethereum light clients since in my opinion I love Ethereum and I think most of the interesting state in the blockchain world lives on Ethereum and most of the interesting activities on Ethereum. I think unidirectional messaging from Ethereum outwards is like already so powerful and then of course once we start doing like proof of consensus for Tendermint, then we can start bridging back messages from Cosmos to Ethereum or the Cosmos ecosystem to Ethereum et cetera.

Tarun (00:36:09):
In terms of like the circuit complexity for Eth's consensus, like what's sort of the final circuit size you have? Like how many gates or roughly like how big is it and then like how big do you think say Tendermint is just to like get some relative scale of like how complex these look?

John Guibas (00:36:26):
I think for our Ethereum circuit it has around 20 million constraints and like for people who that means nothing to that roughly accounts to around like potentially like 30 seconds approving time and like a beefy machine if you use a GPU that could even go down even more. So in terms of proving time, that's actually a really good, it's like really fast and that's like essentially the latest you get on top of Eth finality for any message to pass across. I think for Ethereum they're actually quite smart because you know they have so many validators they need an efficient way to check signatures because it's completely impractical to actually check like 400,000 signatures. So they use the signature scheme called BLS, which has this property that's very easy to aggregate signatures. So you could take N signatures and instead of doing N checks you reduce it down to a single check.

(00:37:12):
But in Tendermint unfortunately they use this signature scheme called EdDSA and in this case it doesn't have this nice aggregation property. So even though Tendermint tends to have much less validators securing the network, the circuit size for the Tendermint circuit is actually very likely to be much bigger. I think we estimate that's gonna be around a hundred million constraints if we do it in the same proving system that we're using right now. And that would also be like a proving type of maybe like 50 seconds on CPU, much less if it were on GPU.

Uma Roy (00:37:41):
I think in terms of complexity, like from implementation perspective, Tendermint is actually much easier than what we did for Ethereum. And this goes into like more technical detail, but in the BLS signature scheme to verify BLS signature, you need to implement this operation known as pairing, which is a function of like two elliptic curve points that results in a number and you know, that's just involved in the verification of a BLS signature. Pairing is very complicated to implement. It's like a complicated function and involves like having to deal with elliptic curves over different fields and all this stuff for EdDSA when you verify an EdDSA signature, it's much more simple. You're just doing some like scaler multiplication in addition of elliptic curve points so you don't have to implement this complicated pairing thing and so I think conceptually EdDSA is much more simple to implement but because it's not aggregatable, this circuit size is larger, BLS conceptually harder to implement, but then our circuit is 20 million constraints.

Tarun (00:38:40):
Yeah. You know, I guess one question regarding that is, so you have this sort of like validator sampling method. In the case of Cosmos though you're not guaranteed that the validator overlap between two IBC chains is particularly high. Like potentially, I'm just trying to think in terms of like the worst case outcomes. Like how do you know how much of a validator overlap or like sort of that is needed in IBC versus because I'm imagining that's sort of important unless you can sample both separately and like get two-thirds on both sides. Does that make sense?

Uma Roy (00:39:16):
You're saying for two different chains?

Tarun (00:39:19):
For two different Cosmos chains? Yeah, like if you were trying to do bidirectional you would, you could do it I guess with two very disjoint validator sets, but you probably need some amount of overlap between them, right?

Anna Rose (00:39:31):
There's a role called the relayer, which like can or it doesn't always have to be done by the validators that's usually passing that. I don't know if that helps answer your question, but it's not always that you are having validators on either side talking to each other to themselves rather.

Tarun (00:39:46):
Right but the relayers are unincentivized also so like there's some sort of

Anna Rose (00:39:49):
True and that's a problem

Tarun (00:39:51):
Sort of weird problem there. Yeah.

Uma Roy (00:39:54):
Yeah, I think when we say we do like a light client for Cosmos, I think we're actually being pretty imprecise. I think what we mean is we would do a like client for a specific Cosmos chain. So the way our light client works, it's very simple, like we keep a commitment to the validator set and then we just process updates and we verify like two-thirds of the validators have signed off on this block, so we'll like keep track of this, we'll keep this block header around and then every so often the validator set rotates and so then we'll if there's a validator set rotation, we'll just like update the commitment and so we only would make like a light client for a single Cosmos chain at a time, if that makes sense.

Tarun (00:40:35):
Yeah, yeah, yeah.

Anna Rose (00:40:36):
It almost sounds then like are, are you like IBC

Uma Roy (00:40:41):
Yeah

Anna Rose (00:40:41):
Like would each one of those, like it would implement a different module that in like maybe they have IBC running but they also have Succinct running which will link them to something else, but with a similar concept of like these light clients that live on your chain?

John Guibas (00:40:56):
Yeah, exactly. Yeah, it'd basically be we reimplement IBC inside of SNARK and this would essentially allow for every Cosmos chain to have the same security as an IBC bridge to another Cosmos chain, but this time actually to Ethereum.

Anna Rose (00:41:08):
Yeah.

John Guibas (00:41:09):
And if you integrate that with our current existing technology, which is the Eth light client, you can actually have a two-way bridge from Ethereum to any Cosmos app chain and it can sort of be like basically a very trust minimized bridging solution that every Cosmos app could use.

Anna Rose (00:41:22):
I mean there's another model here, right? Like there's isn't there people doing just like they're doing IBC on Ethereum sort of saying like, well if we have IBC on Ethereum then we can link directly to everything on Cosmos. Do you know what I mean? Like trying to bring that over. But in your case you would have each Cosmos chain implement this new thing to connect to Ethereum. If I'm understanding correctly. I also, like I haven't spoken to the team that's, I know that there is a ZK-IBC that's doing this. I haven't spoke to them so I don't know like what the challenge with that is. But yeah, it helps me actually paint a picture of what you're working on

Tarun (00:41:59):
Oh, one thing we actually didn't mention since you brought up relayers is that Succinct has relayers as well. So maybe do you guys wanna talk through kind of like the role of relayers in your system?

Uma Roy (00:42:10):
Yeah, we spent a lot of time talking about the SNARKs, but I actually think putting together the whole system working end-end is the SNARKs are only like a small part of that. So the way our system works right is if I have like an Ethereum light client running on Gnosis, then let's just take the unidirectional case at first is I'll have an operator who like reads Ethereum's block headers and reads like the validator attestations and then, you know, every epoch it'll generate a proof that the validators have come to consensus on the, you know, a particular header in the block and so in this case you're verifying like two-thirds of these validators have like signed off on this header and then it'll send an update to the smart contract running on that's like running this Ethereum light client and it'll say hey, here's this new block header and here's a proof that the header is valid.

(00:43:00):
And so then the Gnosis smart contract will process that transaction and keep that header in its memory or in the smart contract storage. So there's an operator and anyone can run this operator like it's totally permissionless because you know, any, all this data is public and like the circuits are public so anyone can run this operator and generate these proofs and update the light client on Gnosis. There's another level of this which is like actually passing the messages. So just because you have a light client doesn't mean you can like pass messages. We have another layer to do that which we're calling like the arbitrary message bridge. So we have a smart contract on Ethereum that's like the sending contract where you can send messages to from any other Ethereum contract and then we have a receiving or executing contract on Gnosis that will basically, you have a relayer who watches for messages on Ethereum and then we'll send an execute transaction on Gnosis for example, and it'll say, okay, for a message on Ethereum, I'm going to send an execute transaction on Gnosis with proof that the message is included in this Ethereum smart contract.

(00:44:05):
So what the receiving Gnosis contract will do is it'll talk to the light client and it'll get like the state route from the light client and then it'll say it'll verify like an account proof and a storage proof like that verifies this message was actually sent on Ethereum and again with the relayer it's also permissionless, like anyone can send these messages and anyone can relay these messages. So yeah, that's like how the whole system works end to end and how the like clients actually use to pass messages and then you can imagine the other directions like also the exact same.

John Guibas (00:44:34):
Yeah, so the cost would be to send a message, you have to pay the cost of like storing the message in like Ethereum State. So that could either be storing it into a storage slot or emitting an event and then on the receiving end you have to pass in the Merkle proof and then validate the Merkle proof against the state route stored into the light client and then there's also some gas costs associated to that, but end to end it's actually very cheap for users.

Anna Rose (00:44:58):
I sort of wanna just check. So like you, you talk a lot about like the message passing. Can people pass tokens? I guess so if they can lock things but like, and I know you know you're not using the term bridge here, but like a lot of this sounds like layers of bridges that I've spoken to before, like Axler has sort of the message part of it. So like I'm just curious like yeah could one build on top of what you've built tokens and I don't know what else you can build on bridges?

Uma Roy (00:45:27):
Yeah. When you pass messages you can pass any state. So we have, our demo is actually like a token bridge between between Ethereum and Gnosis.

Anna Rose (00:45:36):
Okay.

Uma Roy (00:45:36):
And so what we have is we have this bridge contract where you deposit your tokens, you wanna pass into, they get locked, then the bridge contract will pass a message through the arbitrary message bridge saying Uma locked these tokens on Ethereum give her the corresponding tokens Gnosis and then the execute message will call the withdrawal contract that will get you the tokens. So you can, with arbitrary message passing, you can like build anything you want.

Anna Rose (00:46:00):
Do you feel like in building it this way though, is it safer in a way because you have this like, light client and you don't have, I don't know, custody or you're not like I I'm just curious if you feel like these solutions are more immune to the sort of bridge hacks that we've seen more recently. Like is there, is it different? Because I've always gotten the impression like IBC and maybe I'm diluted here, but I've always thought like IBC seems safer than some of the, the bridge kind of proposals that we've seen and yeah, it hasn't been hacked so far.

John Guibas (00:46:32):
I think up to implementation details, which there could be bugs, I think this is pretty much like very close to the end game design for bridging. I think just you can't do better than verifying that all the validators have like signed off on some consent or signed off on a header and that you're like doing exactly what an honest validator does to check the state of a chain. So I think in that front it's probably like theoretically the most secure. I think potentially things that people could be worried about is, you know, like smart contract bugs or ZK circuit bugs. But actually I think I would argue that like these are implementation risks that exist in any cryptographic system and that's just something we have to manage and we can work on over time.

Tarun (00:47:12):
Yeah. How do you think about, so like when you think about IBC, right? It took forever because like it was formally verified, the light client was formally verified under like a bunch of different sort of conditions. How do you think about dealing with verification and testing when you have to think about both the surface area of the SNARK verification like bugs in the SNARK as well as bugs and sort of like the networking layer, the like, you know, serialization layer, stuff like that. And in fact, you know, like arguably a lot of the bridge hacks or at least a lot of the ones that were not just, hey, there are only, there was really only one key were sort of due to kind of like these like lower layer things messing up like the optimism bug that wasn't attacked in the wild, but really like wormhole stuff like that. They all had these like re-hypothecation issues because the message was like de-serializing incorrectly effectively and it t didn't like because create balance. So I guess like how do you think about that whole space and you know, and like actually verifying and testing a circuit because like obviously it's like extremely nascent, look like the thing we talked about earlier with 99 versus a 100, right? That that's like, that could be a buffer overflow in like a normal piece of code so

John Guibas (00:48:24):
Yeah, I think as a team we really care about this and actually like even I think for like, there's obviously really much more advanced proving systems that we could use today, but actually as a team we decided to use Groth16, which is one of the most battle tested proving systems and we wanted to also use one of the most battle tested tool stacks that exist for circuits because pragmatically these are the only systems that have really stood the battle of like production. I think also on the formal verification front actually with circuits, it's really interesting because a lot of these circuits are inherently just arithmetic computation graphs. So actually we've been, formal verification in ZK is also something that's very much being developed right now and that could be really interesting as basically the core pros we're using are just like big integer add big integer multiply and stuff like that. And that stuff can all be formally verified hopefully very soon. But I totally agree with you that like there's a lot of risks here and I think, you know, one thing that I think we plan to do for example, is basically just be very pragmatic about this. Like, for example, any Merkle proof library, like hopefully we can just use like the optimism one, which has also been in production for a really long time and I think these are just choices that we can make as a team to reduce these risks.

Tarun (00:49:31):
Yeah. Actually one question maybe slight tangent, but like, have there been any sort of like overflow, underflow type of bugs and circuits like in production ever? Like, maybe not like production, production like Zcash, but I mean because like obviously I guess they have the inflation bug in a couple other things, but more like bugs you've heard of because like I feel like that to me is the ultimate wild west in cryptocurrency is actually like circuit level bugs that like may maybe you like didn't like initialize or register correctly somewhere and you, or like the compiler, you know, made a mistake in like registration. Like have you guys heard of any cool bugs? Because like I actually don't know. I've never heard of any, but like obviously there have to be some like

Uma Roy (00:50:16):
Yeah, I know Tornado Cash a while ago had a bug, but that was a missing constraint. Like instead of a site doing an equality constraint assignment, they just did like an equals assignment and I think Kobe was actually involved in finding that bug but that was a while ago and that wasn't, it wasn't some complicated like buffer overflow thing. It was just like a simple thing that was missing. I haven't personally heard of anything, although, yeah, I'm sure it exists

John Guibas (00:50:40):
One thing is like, it could be a case that even though a circuit is under constraint, it could be like exponentially difficult to actually be able to use that constraint to do some really bad nefarious damage because just because you have one degree of freedom doesn't necessarily mean that it gives you controllable freedom on the output you care about in the circuit. I think another interesting thing that me and Uma have been exploring is like we can actually add a lot of safeguards inside our light client itself. So one thing we've actually been discussing is, you know, let's say that there is a bug in our circuit. What does a bug mean? A bug means that even though the validators didn't sign off on some header, we say that we approve an inner circuit, but what you can do in your light client is if for the same block number there are two block headers that both passed all these checks, then we clearly have some situation where like something went wrong in our system. Right? Clearly for some reason there's two equally valid block headers from the same block number and that should never happen and that's like a sort of assertion we can add inside our light client and we can like change some flag from like oh

Tarun (00:51:42):
So you don't support forking then? Like what, what if there is actually sort of like a long fork that then reconciles itself in the six block finality period? Like there is some sort of like you are making some choice there that might be slightly different than the Eth stock fork choice rule.

John Guibas (00:52:00):
So what actually happens under the hood with even the Eth validators is like at some point in time they decide to change the fork ID of the chain and that's like something we just can't get around. Like basically we either have to schedule these fork upgrades or we have to redeploy the light client. So that's just something we can't get around due to the nature that how Ethereum works and that's actually something that all these Eth validators already do from my understanding.

Tarun (00:52:24):
Okay, cool. Yeah, the only reason I ask is like, you know, I think obviously there's an amazing set of things you can do with SNARKs, but I feel like, you know, if Kobe and like three people are the only people in the world who've ever like really found a ZK, a bug in a circuit, there must be like a ton because like in a lot of ways I actually am not even actually worried as much about the circuit writers personally as much as I'm worried about the compiler.

Uma Roy (00:52:51):
Yeah.

Tarun (00:52:52):
And like there being like state that is shared outside of like SNARK evaluation and state that is like commingled somehow and you can like read and write to the same spot and like that's very hard to find and the compiler, you know, could hide that from you because it's like, it's sort of generating all that code. Like how do you guys view the state of security for SNARKs and like over time how that evolves? Because like yeah, it just, it, I'm not trying to scare people. I'm not. I'm just trying to say that like it is, it does feel like this huge surface area.

Uma Roy (00:53:24):
Yeah, I think there is a huge surface area, but one thing I will say is like any system has like a big surface area. Like for example, if you look at an optimistic rollup, like they also have a lot of smart contracts on chain that are like coordinating all these games and you know, they have to worry about like a particular compiled version of a gap. Like any complex system has a lot of surface area for risk. Like actually our smart contracts are pretty small because a lot of the complexities in the SNARK, which is nice now of course, okay auditing a SNARK is also hard. I think that's like one of the reasons we decided to, you know, make our proofs in a proving system that has been around for the longest time and it's actually been used in production and like Tornado Cash and things like that is then you can be more confident that there isn't, you know, some random surprise in the compiler or whatever.

(00:54:14):
Even though like there are a lot of really new exciting proving systems coming out that could potentially make our performance a lot better. I think from a security perspective it seems simpler to do something that's like older that, you know, maybe isn't the most efficient or the most performant, but, you know, people can feel better about the security properties of so I think that's how we like kind of think about it. How does anything really gain trust and security? It's like, it's been used for a long time. It hasn't been, you know, hacked or exploited. Like that's how they figure out, you know, whether hash functions are safe. And so I kind of view it in a similar way. I think there are efforts to do like formal verification, you know, I think they're making progress on it, but I think probably the tried and true way of like, you know, figuring out whether something's secure, which is like, let's just wait and see if it gets hacked is like, also applies here.

Tarun (00:55:01):
It's true that unfortunately bridges are the greatest bug bounty that's ever existed.

Anna Rose (00:55:05):
Oh

Uma Roy (00:55:06):
Yeah.

Anna Rose (00:55:07):
When you're talking about this like vulnerabilities in SNARKs, like, I'm gonna do a little side plug here, but like ZK HACK, what we do with that event is basically to like do these ZK puzzle competitions or you're supposed to basically hack a ZK circuit or something, something around it and we try to, it's always modeled after like historic hacks and I'll put the link in in the show notes to that because it's kind of a resource, it's like a history of things that have happened so far might give people bit of

Tarun (00:55:39):
That's because you have one, you host it with one of the three people in the world who's ever found one these

Anna Rose (00:55:45):
Kobi, Kobi Gurkan who's who sometimes cohosted the show too. But yeah, but I think like there is an effort. I mean at least that is an effort to like allow people to be aware of it because I think you do need more eyes on this. Like you do need people to also like know techniques to hack these things so that they can be hacked so that we hopefully hack them before they're in production or, you know,

Tarun (00:56:06):
I just actually think there probably needs to be like a ZK and SNARKs and probably STARK, although, you know, that's a little bit out like before RISC Zero is live and stuff, like really thoroughly, I think like there sort of needs to be a separate version of like Code Arena or like Immunify specialized for this not like the normal smart contract. Like I feel like somehow like that has to get off the ground and I it probably will once people start using things like Succinct a lot.

John Guibas (00:56:37):
Yeah. The cool thing is like you can make like on chain bounties. So like if someone could hack a circuit, you can actually do that. You can encode that as a smart contract on Ethereum and like give out some award

Anna Rose (00:56:46):
John, you and Uma you both mentioned formal verification efforts. Can you share a little bit about like what is going on there? This is the first I heard about it and it's like, yeah, like who's doing that and maybe what groups are are trying to do that?

Uma Roy (00:57:00):
There's this auditing firm called Paradise that I think is trying to do formal verification for circuits and they've managed to formally verify some BigInt libraries that are used for elliptic curve arithmetic in these circuits that we're using. So that's great.

Anna Rose (00:57:18):
Cool.

Uma Roy (00:57:19):
I think formal verification, yeah. That different people have different thoughts on formal verification. I honestly don't have very strong opinions on it, but I know other people do.

Anna Rose (00:57:28):
Maybe it's not the only check, but it's a good check to have as well.

Tarun (00:57:32):
I mean, that sounds like a fun episode to do of like, what's the difference between non ZK and ZK formal verification? How do you handle the state isolation between the like non circuit version and the circuit? Because like I feel like the state isolation to me is like the hard part. I feel like somehow that, that part in my head that's like, I don't know how, I don't know how well anyone knows the entire pipeline of these compilers and it took Solidity a while I feel like, to find some of these like very nuanced bugs and like Solana's had a ton of these bugs where, so these are the my favorite types of, I mean okay, when I say favorite, I mean they're the most intellectually interesting. They're also probably the one that should be like keeping you up at night. But it's these bugs where you can actually send malicious code that's run in the VM and then jailbreak the VM and write to the validator machine locally.

(00:58:26):
And so like the smart contract bug like flows all the way through to like the validator running it or like whoever's, those bugs are crazy. And I like, I kind of feel like a lot of the newer chains have had those Eth kind of got very lucky that had like this window where no-one unbothered like fucking with it for a while. I mean they, people did fuck with it in Shanghai in 2016, but like, I feel like at the compiler level it avoided these supply chain attacks. Not, again, I'm not trying to scare the shit outta people. I'm really just trying to point out that like, there's a whole new world of this stuff that will be super cool.

Anna Rose (00:59:01):
I wanna go back to the company Succinct. How big is your team? How long have you been around and where are you headed? Like at what stage exactly are you, you said sort of said you've deployed on Goerli and on Gnosis chain, but yeah, like yeah, how big are you? How far along are you? What can we expect?

Uma Roy (00:59:21):
Yeah, so over the summer when we started working on it like late May, it was just me and John and we kind of built out the whole thing over the summer together, the two of us. And honestly like the circuits are just one part of it. Like we built out the SNARKs for Eth consensus, but we had to build out the operator, the relayer, the smart contracts, the front end, John's like somehow also like good at design. So, you know, we had to do all this stuff and then right now we, you know, we're trying to grow the team so if anyone's listening and I'm very interested in ZK or anything else, like yeah, hit us up we're on Twitter @succinctlabs or you can email us. But yeah, we're trying to grow the team and looking for people like all across the stack and I think we're working on basically taking our existing thing that we built out over the past few months and really productionizing it.

(01:00:09):
So we're in the middle of an audit. We're in the middle of like gas, optimising our smart contracts and we're going to productionize this and you know, we're working closely with the people at Gnosis to build a bridge, a bidirectional trust minimized bridge between Ethereum and Gnosis, which is great for their chain and then we have like a few other dapps that we're working with closely, you know, to explore some of these other unidirectional use cases from Ethereum outwards, like the governance use case and some other use cases. So that's like, you can expect to see all that stuff coming out. And we really wanna go into production like probably on the order of like a few months, like after the audit and after everything feels really good. And then, yeah, the other people on our team are working on doing proofs of consensus for the other chains. So I think the Cosmos ecosystem entitlement's really interesting to us. Especially with like IBC they're like super aligned on, you know, their vision of interop and so yeah, we're also like working on getting that working and yeah, that's like the stage of the company and we recently raised some money and are hiring people to work on all this stuff.

Anna Rose (01:01:11):
Cool. Going back a little bit to the beginning of this episode and sort of like joining the ZK space, do you have any advice to people who are just arriving who wanna maybe build something? Don't do it?

Tarun (01:01:30):
Well, I, okay. Maybe, maybe let's

Anna Rose (01:01:33):
No inspirational talk from these two

John Guibas (01:01:37):
Actually like me and Uma, were actually trying really hard to think about like, cool ideas in ZK to work on. I think there's a lot of cool ideas, but a lot of them are a bit like further out. Like I think this whole like ZK identity space is like really, really cool but as Uma said, like it feels a lot more like a product question and I think that needs to be figured out but yeah, I think if people are like interested in getting ZK, it's actually a really great time. I think, you know, it's a really great time. It's still early, it's still small and I think there's probably a lot of interesting applications that people haven't even thought of that's possible. So I would highly encourage like anyone in the space who's interested to start.

Uma Roy (01:02:09):
Yeah, I think just like diving in, trying out some code, not being afraid, like even though things don't have great documentation, to be honest, I think even with Googling around and like asking the right questions, like people are generally pretty friendly and like willing to help out. So I think just diving in and not being scared of diving in would be like my advice.

Tarun (01:02:27):
Cool. If you had to say a nice thing about a non ZK bridge, pick any bridge, what nice thing would you say about them?

Uma Roy (01:02:40):
I think there are some other bridges out there that, like the proof-based approach is very pure and I think the optimistic solutions are actually quite interesting. I just think like, you know, I'm a SNARK maxi, so I think like if the ZK bridge is possible is better, but they're also like, I would say pretty pure as well but you know, with an impure solution you can sometimes have like faster bridging or things like that. So it's like there's always trade offs to all these things.

Anna Rose (01:03:10):
Definitely.

Tarun (01:03:12):
Okay. That was the most hedged nice thing you could have said, That was like if this is neutral, you were like just barely. In a world where you have ZK portholes like bridge like constructs that don't wanna be called bridges, what does that mean for rollups? Is the world gonna have fewer rollups when you actually trust the bridges or, you know, they're supposed to be sort of complimentary, but like they could actually be substitutes in some sense?

John Guibas (01:03:47):
Yeah, I think it offers like a very interesting alternative to like, if you're a dapp and you want like high scalability, like maybe instead of building a rollup now you can just build like a Cosmos app chain or your own app chain that just directly connects hooks into Eth, with like a proof-based bridge. And I think one interesting thing here is like, I know, you know, the Cosmos people have been thinking about this for a while and I think also Sreeram from Eigen Layer recent wrote this like paper about like running light clients on like different L1s on each other to also gain the advantages of like mesh security. So somehow it feels like these like proof-based light clients can sort of enable both the rollup future for Ethereum, but also a world where maybe mesh security becomes the future. I'm not sure.

Tarun (01:04:28):
Yeah. And for, I guess for listeners, mesh security is where when you have many chains, they actually are able to pull together security. You know, right now when you cross a bridge, your net security is the security of the minimum, the weakest link, it's the minimum overall chains you traverse, whereas you could make it the sum or like somewhere in between minimum and sum. Cosmos people always sort of have the right idea of bad wrong formalism and they didn't formalize it. They just were like, oh yeah, whatever. Well like somehow do this weird staking derivative and like share security without explaining how or why it worked. But like yeah, Sreeram has this new paper that's really good at trying to formalize the correct intuition, but wrong sort of description that I think in the Cosmos ecosystem people have had, but also rollups are moving in that direction too. Like all the Eth EVM rollups seem to be like, hey, we're gonna have app chains for, so it's like I think it's sort of inevitable.

Uma Roy (01:05:24):
Yeah, especially if you don't want a centralized sequencer. I could go on a huge rant about centralized sequencers. Like people are gonna have to figure out this problem.

Tarun (01:05:33):
And not just make another L1

Uma Roy (01:05:36):
Yeah. Yeah.

Tarun (01:05:36):
In the process. In the process.

Uma Roy (01:05:38):
Yeah.

Anna Rose (01:05:38):
Yeah. All right. On that note, I wanna say thank you Uma and John for coming on the show and sharing with us Succinct and also kind of your journeys into ZK. Thanks a lot.

Uma Roy (01:05:47):
Yeah, this was fun. Good to see you guys.

John Guibas (01:05:49):
Yeah. Thank you so much.

Anna Rose (01:05:50):
Thanks Tarun, for being on again.

Tarun (01:05:53):
Always happy to be here.

Anna Rose (01:05:54):
All right. I wanna say thank you to the podcast team, Rachel, Tanya, and Henrik, and to our listeners, thanks for listening.