Episode 255: Verifying Consensus On-Chain with Succinct

Transcript

[Music] 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 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 Xerox Park 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 discussed the challenge of building this kind of like 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 want to invite you to join the upcoming ZK hack 3. a virtual multi-week event starting on November 22nd it's all online so you can join from wherever you are it's the third time we 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 risk zero alio and Noma 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 want to challenge themselves so every week we release one of our ZK puzzles that is a broken ZK system or 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 cred within the community so even if you aren't an expert you still might want to 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 today's episode is sponsored by Aztec Aztec network is building the first privacy enabled ZK roll-up 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 forward slash careers that's aztec.network forward slash careers so thanks again Aztec and now here's our episode [Music] today tarun and I are here with the folks from succinct welcome Uma and John to the show hello it's good to be here yeah thank you so much for having us it would be great to hear a little bit about the two of you and obviously we're going to be getting into succinct I want to hear like at what point did you get excited about CK because I feel like

this your Journey's pretty fresh right like you got in this year I started working on ZK related stuff actually around this time last year cool I'm really good friends with uh the person who runs the Rex Park gub sheep 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

um 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 cool and John what pulled you in yeah on my end I was like um 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 um Yi you should definitely interview him and Jonathan sometimes wait wasn't he wasn't he on at some point oh no no we had his collaborator yeah he came up during that episode also

hi I'm on this episode 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 but from like the system side and theoretically and then he actually suggested I looked really into ZK I hadn't really looked at into it at this point and he referred me to like the Xerox Park folks and I actually ended up spending a summer there and that's like where I met Uma in my whole zika Adventure began when was that that was around may I think yeah I'd actually quit my like original plans for the summer to do ZK with zerks park cool what is what's 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 on board is it complicated is it easy air quotes industry space um but yeah 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 the space but you know there's a lot of really good Learning Materials you know actually like Xerox park has this website called learn.xrxpark.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 the 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 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 the space yeah I think similar to John I also had the perfect background for it uh 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 uh with the stuff I'm doing full time with you know 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 uh 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 uh 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 do you feel like are you in ZK or are you in blockchain like do 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 are you you're really asking them are they degens or not where are you djans were you or have you ever been a Degen I think personally I have I like the Degen Spirit um I don't know if I'm personally a d-gen but I 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 oh just the ZK Mathis school or something like that I think for me like I also really

align with the values of the space uh more broadly and ZK is such a perfect or ZK snarks are such a perfect fit for blockchain right uh 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 yeah I think on my end I feel like um I definitely got originally nerd snack by crypto um by itself like separate from ZK and I think like what really got me into crypto was like the concept of defy um like how cool amms work actually like one point I like emailed guermo to do like cffm research with him and but I think and then rug pulled him yeah

don't worry he told me he was like like there's an undergrad I remember he's like there's this undergrad who emailed me and then he disappeared 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 izk like outside crypto and I think like the folks that like Risk zero are definitely like candidates for this I think there's this whole field of like zkml that's Brewing uh right now and I think for the short term probably applications DK 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 so so actually uh one one you know instead of the uh blockchain versus CK question I think a more pertinent question is both of you came from ml which is like the most centralizing anti-privacy uh technology and movement that exists on this planet um so like what made you make the pivot that's like uh that's a big jump from the uh from that world to hit this world wow that's uh strong opinions on ML I still because I like ml so I can't sorry those were those were those were my opinions for me honestly

crypto and it's an 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 a 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 what the 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 XYZ 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 um and I think that to me that was very inspiring it felt like you don't know what's going to happen here and it's very exciting it sounds a bit like to work in ml you're probably going to 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 yeah probably I mean there's a lot of ml s right now so yeah I think that that's also very exciting

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 I I think the bar is also a lot higher to like go from zero to Something in ml in 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 bind worked at Fair like did X or Y like like whereas in

crypto it's like literally you could just be an Anon anime character and like you know yeah I think the Vibes are better in crypto yeah like another thing crypto is like I think people have like something they want to prove to the rest of the world and like they want to 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 Twitter often it does just way more interesting on that front I mean all the drama and AI is just like who raised more money for GPU yeah or AI ethics uh sites yeah whereas like crypto somehow seems to have avoided that part of this the sphere for them which is like a funny trade-off

you both went through the Xerox Park 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 yeah I think Xerox Park is basically this r d org for Applied cryptography so also they have some people are 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 you know not have anything that's super grifty or things like that so um 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 being 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 um it's really good energy and yeah obviously I met John there which was amazing yeah totally great I think gub sheep I don't know why we're not actually saying his name no no he's got cheap he's been on the show okay I'm sure it's a different name but now he's got cheated

on the show okay he's done a really great job like cultivating the community and like like a sense of like culture of like strong collaboration and like making it really easy like for example for me for example to like onboard into the whole CK space and get to talk to like and learn from like the smartest people so I think for me it was like a really instrument part of my CK journey and I'm super thankful I do actually want to 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 yeah I think some of the tooling is a little bit buggy I think okay a lot of weird bugs okay what's your 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 oh John I feel like we're thinking of the same thing yeah oh wow wait I think we can't name the library though okay okay the library is overall amazing the library is overall 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 no I think it was like a week and a half I mean we were like actively doing it but like every night I would spend a few hours looking at the seg fault not understanding what's 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 4am and I realized you know we had we had initialized an array of size 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 100 to 99 and then it worked did you tell somebody yes we did we did they I

think they fixed it okay or did they at least add an error message like a helpful error message actually I think they fixed it because I haven't run into that again but you really can't blame them though because like they're doing it all open source since like I don't I don't know like what if they're even getting paid to do it so yeah yeah it's it's a heroic effort from them so someone needs to make coin sessions like the thing where people confess their uh their sins uh before bugs for bugs and features yeah actually you guys worked on coin fashions oh yeah one of our in a previous life we were working on

message board oh with decades with DK at Xerox park right yeah yeah cool I actually wanted to ask you Uma about like the iterations like the problems you started on ID like other problems um I know we 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 yeah so the original stuff I was working on was you know building one of the early experiments was DK 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 um but I think for me I really like solving really hard 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 uh it's already been kind of built it's not anything complicated it's more about building this like product experience that's going to 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 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 want to hear from you what is succinct doing and actually what kind of what category do you put yourselves in 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 assisting to non-interactive proofs and then I think ZK has become this like catch-all term on Twitter to refer to these existing proofs so people will refer to them as EK proofs or ZK snarks when they're sometimes just snarks and not exactly yeah yeah so I think you know with the ZK snark you can kind of 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 succinctives part gives you scalability so the succinctness lets you have this like succinct proof that you

know some computation is has resulted in a certain answer uh and you know we're using the succinus 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 and once you've accessed 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 is called succinct you know I was looking at all the ZK companies uh today like and all of them have like the letter z k yeah like like everything I do Fair yeah I mean I mean I mean crypto crypto you know while I uh admire the ability to Fork everything and copy your thing there is this like tendency to have no originality in naming like every L1 has Hoka X Soul X Cosmo X and there's like a million of the same like name things and

I feel like ZK is just like it's a very happy like that it's starting to be like yeah although I okay I'm gonna just give myself a little credit that when I started with the ZK naming there weren't that many just FYI but yeah I totally agree I totally agree that like it sort of has there's projects now that are called ZK that aren't CK but I the success for the concept yeah like a concept has reached success when it gets copied you know imitation is a form of flattering totally yeah 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 like clients though like are you talking about two like clients on two different networks talking to

each other yeah that's exactly the idea it's very similar to ibc's concept which is like like clients for interoperability and then we're making like clients gas efficient enough for expensive block space chains like ethereum for example 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 Roll-Ups do the same thing as what you're doing yeah so ZK Roll-Ups are using the succinctness property to scale execution so in a ZK roll up 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 uh so we're kind of using the similar properties for a different computation um 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 the ability for any network to do it like I'm kind of curious like how customized these like clients actually have to be yeah so right now what we have is we spent all our time getting this sort of proof of consensus um idea working for ethereum and in particular right now what we have is this custom-made circuit that proves

that a random subset of 512 ethereum validators have signed off on a block header and 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 when you say it's unidirectional like where does a like client live in that

case so it's from ethereum out are you saying it's a like client that people deploy outside of it that can talk to ethereum yeah so essentially we have like a smart contract that we can deploy on any chain that we want to run the like line on and you basically want to run the like client on the Chain that's receiving the messages because the like client essentially keeps track of a ledger of block headers and the the blockhead essentially allow you to access State at any point in time do those networks all have to be or other chains have to be evm 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 okay but what what like prevented people from doing this before

is this a very hard problem has something changed that allows for this I think a lot of people were actually thinking about this like I think Kobe and atcelo and Georgios were working on trying to like basically create some sort of like client uh bridge I think the cosmos people figure this I think yeah yeah it's called plumo yeah and I think another thing is you know I'll clear the cosmos folks uh thought this this like client Bridges were a really great idea but I think another thing that people generally haven't realized is 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 like 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 Vines from 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 a 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 was basically assisting you you have hard to do and I think Payne 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 want to 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 multi-stick bridge it's easier because you can well you trust that the participants did the consensus 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 zkevm teams and people like zcash or you know

whoever else has been working in that space and developing these libraries it's still their libraries are still really hard to use to actually accomplish these goals I mean I think there's actually this Twitter thread that Miya numo were like discussing in with like George's and Kobe but I think when we first start talking about our like 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 use is 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 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 is just getting like more efficient like how did you do that 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 won Sports cello and like it 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 in 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 Kobe and Georgia's hadn't worked on that since 2020 right two years is kind of a long time especially when you're having like these like more like exponential increases in performance due to just like hey we like optimized caching or and stuff like that yeah totally I think there was a couple of things so uh 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 going to 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-to-end working demo of a bridge today from ethereum and we're using a test net so go early to knows this 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 um that was actually my question about like using cryptography for a bridge using like 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 yeah so compared to an optimistic solution it's actually much faster because then 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

a 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 is even to my opinions of Roll-Ups but I think if a ZK roll-up is technically feasible which I think now it seems like they totally are then it's actually a better solution than an optimistic role because you don't have to wait for this seven day challenge period so I also think the same thing of you know ZK or a proof based I like to call it proof-based interoper 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 is it more expensive somehow so you have to verify the proof so that's potentially more expensive but the whole point of assisting proof is is that it is cheap to verify so it is like a little more expensive but it's not that much more offensive cool um you talked about like what you've built so far is the girly test net tenosis 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 them connection first yeah so actually when we were First beginning um this like research project on like

potassium 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 yeah so if we could accomplish this ZK like 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 um we got some funding from gnosis Dao 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.sync.xyz the progress of sending a token from Gorly to gnosis chain why it 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 so as John mentioned the the nice thing about gnosis chain is that they also use ethereum proof of stake consensus okay uh for their chain and so if we can have an ethereum proof of stake like client then we can have a like client running in ethereum for

gnosis chain and then we can have a like client running a gnosis chain for ethereum and so then we can have like the bi-directional message passing we can deploy our ethereum blight client today to any evm chain so like Avalanche polygon you know whatever else uh gnosis Etc um and also all the Roll-Ups and like what that gets you is you need directional 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 uh daps have their governance living on ethereum because their governance token lives on ethereum that it's never going to move off of

ethereum so 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 um 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 uh 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 and ethereum or some other token on ethereum I can lock my token on polygon in a smart contract uh and then I can say hey

world like if you give me you know one ethon ethereum you can unlock this locks 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 so actually you need directional 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 like 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 tender men then we can

start bridging back messages from Cosmos to ethereum or the cosmos ecosystem to ethereum uh Etc in terms of like the circuit complexity for each consensus like what sort of 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 tenderman is just to like get some relative scale of like how complex these look 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 latency you get on top of each finality for any message to pass across I think for ethereum they were 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 and signatures and instead of doing n checks you reduce it down to a single check 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 tenderman circuit

is actually very likely to be much bigger I think we estimate that's going to be around 100 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 I think in terms of complexity like from implementation perspective tenement 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 BL 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 scalar multiplication and addition of elliptic curve points so you don't have to implement this complicated pairing thing and so I think conceptually EDSA is much more simple to implement but because it's not aggregatable the circuit size is larger BLS conceptually harder to implement but then our circuit is 20 million constraints 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 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 you for two different chains for do two different Cosmos chains yeah like if you were trying to do bi-directional you would you could do it I guess with two very disjoint valuator sets but you probably need some amount of overlap between them right there's a role called the relayer which is 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're having validators on either side talking to each other to themselves rather right but the relayers are unincentivized true and there's that's a problem some sort of weird problem there yeah yeah I think when we say we do like a like 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 like 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 like client for a single Cosmos chain at a time if that makes sense yeah yeah yeah it almost sounds then like are are you like IBC like would yeah each one of those like it would Implement a different module that is 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 like clients that live on your chain yeah exactly yeah it'd basically we re-implement IBC instead 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 ethereal and if you integrate that with our current existing technology which is the eat fly client you can actually have a two-way Bridge from ethereum to any Cosmos app train and it can sort of be like basically as a very trust minimized bridging solution that every Cosmos app could use 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 this new thing to connect to

ethereum if I'm understanding correctly I also like I haven't spoken to the team that's do 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 oh one thing we actually didn't mention um since you brought up three layers is that succinct has relayers as well so maybe do do you guys want to talk through kind of like the role of relayers in your system yeah we spent a lot of time talking about the snarks but I actually think play putting together the whole system working end to 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 like 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 uh 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 gnosis that's like running this ethereum white client and it'll say hey here's this new block header and here's a proof that the header is valid and so then the notice a smart contract will process that transaction and keep that header in its memory

um or in the smart contract storage so there's an operator and anyone can run this operator like it's totally permissionless uh 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 like client on gnosis there's another level of this which is like actually passing the messages so just because you have a like 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 uh 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 and 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 so what the receiving noses contract will do is it'll talk to the like client and it'll get like the state route from the like 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 uh and again with the relayer it's also permissionless like anyone can send these messages and anyone can relay these messages uh so yeah that's like how the whole system works end to end and how the light clients actually use to pass messages

and then you can imagine the other directions like also the exact same 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 Merkel proof and then validate the Merkle proof against the state route stored into the like client and then there's also some gas cost Associated to that but end to end it's actually very cheap for users I sort of want to just check so like you you talk a lot about like the message passing can people pass tokens I get I mean I guess so if they can lock things but like and I know you know you're not using the term Bridge here but I like a lot of

this sounds like layers of bridges that I've spoken to before like axeler has sort of the message part of it so like I'm just curious like yeah or like could one build on top of what you've built tokens and I don't know what else you can build on Bridges and so what we have is we have this bridge contract where you deposit your tokens you want to pass into they get locked then the bridge contract will pass a message through the arbitrary message Bridge saying Uma locks these tokens on ethereum give her the corresponding tokens on gnosis and then the execute message will call the withdrawal contract I will meet you the

tokens so you can with arbitrary message passing you can like build anything you want mm-hmm 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'm just curious if 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 a different because I've always gotten the impression like IBC and maybe I'm deluded here but I've always thought like IBC seems safer than some of the bridge kind of proposals that we've seen and yeah it hasn't been hacked so far 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 sign off on a header and that you're like doing exactly what an honest balloter 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 yeah how do you think about so like when you think about IBC right it took forever because like it was formally verified like client was fully verified

under like a bunch of different sort of conditions how do you think about dealing with uh verification and testing when you have to think about both the surface area of the snark verification like bugs in the the snark as well as bugs and sort of like the networking layer the 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 they're 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 it's like Wormhole stuff like that they all had these like rehypothecation issues because a message

was like deserializing correctly effectively and it didn't like cause like create balance so I guess like how do you 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 like the thing we talked about earlier with 99 versus 100 right that that's like that could be a buffer overflow in like a normal piece of code so 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 um growth 16 which is one of the most battle tested proving systems and we wanted to also use one of the most battle tested uh tool Stacks that exist for circuits because pragmatically these

are the only systems that have a 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 uh computation graphs so actually we've been formal verification in CK is also something that's very much being developed right now and that could be really interesting as basically the core prone is 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 merkel-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 yeah actually one question uh maybe slight tangent but like have there been any sort of like overflow underflow type of bugs in 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 bugging 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 uh maybe you like didn't didn't like initialize or register correctly somewhere and you like the compiler you know made a mistake in in like

registration like have you guys heard of any any cool bugs because like I I actually don't know I've never heard of any but like obviously there have to be stuff like yeah I know tornado cash a while ago had a bug but that was the missing constraint like instead of a sign doing an equality constraint assignment they just did like an equals assignment and I think Kobe was actually involved in finding that bug um but that was a while ago and that wasn't it wasn't some complicated like buffer over the floor 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 one thing is like it could be a case that even though circuit is under constrained 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 like 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 like client and we can like change some flag from like so you don't support forking then like what what if there is actually sort of like a long Fork uh 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 so what actually happens under the hood with even the eat 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 like 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 validators already do from my understanding 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 not even actually worried as much about the circuit writers personally as much as I'm worried about the compiler yeah and like they're being like state that is shared outside of like snark evaluation and and state that is like

commingled somehow now and you can like read and write to the same spot and like that's very hard to find then the compiler you know could have to 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 just it I'm not trying to scare people I'm I'm just trying to say that like it does feel like this huge surface area 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 roll up 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 compile version of a gap like any complex system has a lot of surface area for 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 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 even even though like there are a lot of really new exciting improving 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 um 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 it is true that unfortunately bridges

are the greatest bug Bounty that's ever existed yeah 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 DK 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 because you have one you host it with one of the three people in the world who's ever found one Kobe Kobe gherkin who's who's on his

co-host of the show too but um 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 I just actually think there probably needs to be like a a ZK and snarks and probably Stark although you know that's a little bit out like before visceros live and stuff like really thoroughly I think like there sort of needs to be a uh a separate version of like code Arena um or like immunify specialize for this not not like the normal smart contract

like I 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 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 as a smart contract on ethereum and like give out some award Johnny 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 what groups are are trying to do that there's this auditing firm called veridice 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 you

know elliptic curve arithmetic and these circuits that we're using so that's great um 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 maybe it's not the only check but it's a good check to have as well I mean that sounds like a fun episode yeah like what's the difference between non-zk and CK formula verification how do you handle the state isolation between the like non -circuit version on the circuit because like I feel like the state isolation to me is like the hard part like 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 has a ton of these bugs where so these are the my favorite types I mean okay when I say favorite I mean they're the most intellectually interesting they're also probably the most 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 read the and write to the validators machine locally and so like the smart contract bug like flows all the way through to like the validator running it or like whoever's those those bugs are crazy and I I like I kind of feel like a lot of the newer chains have had those eth kind of got very lucky

that like this window where no one bothered like with it for a while I mean people did with it in Shanghai in 2016 but like I feel like at the compiler well it avoided the supply chain attacks not again I'm not trying to scare the out of 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 I want to go back to the company succinct how big is your team how long have you been around and where where are you headed like at what stage exactly are you said it sort of said you've deployed on Gurley and on gnosis chain but yeah like yeah how big are you how far along are you what can we expect yeah so over the summer uh when we

started working on it like late May uh 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 up the snarks for each 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 uh yeah hit us up on we're on Twitter at the stage Labs or you can email us but yeah we're trying to grow the team and looking for people like all across the stock and I think

we're working on basically taking our existing thing that we belt out over the past few months and really productionizing it so we're in the middle of an audit we're in the middle of like gas optimizing 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 uh bi-directional trust minimized bridge between ethereum and gnosis which which is great for their chain and then we have like a few other adapts 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 want to 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 and consensus for the other chains so I think the cosmos ecosystem and tenements really interesting to us um 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 we we recently raised some money and are hiring people to work on all this stuff 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 want to maybe build something don't do it

inspirational talk from these two actually like me and UMO were actually trying really hard to think about like cool ideas in Zeke 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 zika identity space is like really really cool but as you must 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'd highly encourage like anyone in the space who's interested to start yeah I think just like diving in trying out

some code not being a 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 my advice 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 I think there are some other Bridges out there that like the face approach is very pure and I 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 Z game responsible 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 definitely okay that was the most hedged yes thing you could have said that was like like if this is neutral you were like just barrels in in a world where you have ZK uh portholes like bridge-like constructs that don't want to be called Bridges

what does that mean for Roll-Ups is the world going to have fewer Roll-Ups when you actually trust the bridges or you know they're supposed to be sort of complementary but like they could actually be substitutes in some sense yeah I think it offers like a very interesting alternative to like if you're a Dap and you want like high scalability like maybe instead of building a roll-up now you can just build like a Cosmos app train or your own app train that just directly connects hooks into eth um 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 SRI Ram from eigenlayer Recently wrote this like paper about like running like clients on like different L ones on each other to also gain the advantages of like mesh

security so somehow it feels like these like proof-based like clients can sort of enable both the roll-up future for ethereum but also a world where maybe mesh security becomes the future I'm not sure yeah and for I guess for listeners mesh Securities 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 some Cosmos people always sort of have the right idea a bad wrong formalism and they didn't formalize it they just were like oh yeah whatever we'll like somehow

do this weird staking derivative and like share security without explaining how or why it worked uh but like yeah sriram has this new paper that's really good at trying to formalize the the correct intuition but wrong sort of description that I think in the cosmos ecosystem people have had but also Roll-Ups are moving in that direction too like all the evm Roll-Ups seem to be like hey we're gonna have app chains for so it's like I think I think it's sort of inevitable yeah especially if you don't want a centralized sequencer I could go on a huge rant about Central sequencers like people are going to have to figure out this problem um and not just make another layer one yeah in the process in the process yeah yeah all right on that note I want to

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 yeah this is fun good to see you guys yeah thank you so much thanks tarun for being on again always happy to be here all right I want to say thank you to the podcast team Rachel Tanya and Henrik and tour listeners thanks for listening