ZK Proof Aggregation with Garvit Goel of Electron Labs

Transcript

a ZK proof is really relating that this set of inputs is related to this set of outputs using this particular program I like to call ourselves as a ZK wrapper for ethereum Block space you will access the ethereum block space via this ZK layer and nothing else you have like ethereum block space here and then you kind of zoom out this aggregation layer which is offering you much more block space effectively and on top of that you have these rollups which then again offer you much more block space it's kind of multiplying As you move up the ledge [Music] I'm here with garage goel he's the

founder of electron labs they a universal proof aggregator that produces super proofs and the goal here is to significantly reduce the cost of proving on chain before we get started be sure to subscribe to get notified when new episodes drop every week and remember that none of what is discussed here on the interop should be considered investment or financial advice and also know that interop Ventures is an investor in electron labs and if you enjoy this content please consider sing with us we're validating on OS Quicksilver and osmosis just look for interop in active set hey Garett thanks for being on the show thank you for having me I'm excited to be here yeah absolutely so let's get right into it how did you get into ZK and what made you want to focus on solving the uh the

the problem which is that ZK proofs are so expensive to verify especially on ethereum yeah thanks so I think our journey started like almost two years back uh we were just trying to we had we were a bunch of people in New Delhi we were just trying to experiment with some ideas and build something on jail like we didn't really have any ideas but we wanted to do something on jail and as we started to work towards it we started to look deeper into the protocol side of things and how consensus works and all of that and ZK was this natural attraction to us it seemed to solve all the problems that actually plague the current blockchain designs and seem to solve all of them so we just kind of GRA towards that eventually and once you were into it we could see that's really

the right place to be and been been in that ever since over time we started to feel that as we were building things on ethereum and ZK we started to notice that most of the use cases that actually use ZK uh it's extremely expensive for them to verify these proofs on ethereum and no one really talks about them people are talking about Hardware acceleration gpus and all sorts of stuff but nobody's talking about the cost of verifying these trops on ethereum while that in my opinion happens to be the limiting factor right now you know when it comes to ZK based products so we thought okay we need to really address this and we need to figure out a way to reduce this cost significantly before anything else

becomes uh possible in ZK yeah what are some of the other attempts like made by say other teams or even on the of core ethereum uh client to reduce the cost of verifying ZK proofs yeah I think the very first one was actually the EIP process where uh a pre-compile was added in the evm to enable proof verification much more cheaply right so without that it would be even more expensive so that was one of the first things that uh that the ethereum community the code developers really made happen and that was really done to enable the ZK scaling Road map to happen right but over time even after that pre-compile it still is significantly expensive so we need to do

a little bit more work here I think we kind of maxed out the EIP process here so yeah we need to start looking elsewhere uh other approaches to really reduce the cost yeah yeah understood and what is it about ZK proofs that make them so expensive to verify on chain yeah I think uh I mean if you want to do any native computation you know let's say verify a proof on your lap top it wouldn't be really that expensive it's it's really it's it's fine all right I think doing anything on chain especially ethereum is generally very expensive compared to any other platform of computation so naturally ZK proofs have also turned out to be a little bit too expensive yeah okay well let's maybe take a little bit step a step back here

and maybe just you know give a little bit of a ZK crash course here I recognize like these topics are you know widely discussed but I think for some people getting a little bit of clarity on like what is a ZK proof and what's a ZK like client would be helpful and certainly also for me you know like always helpful to get a new perspective on you know how ZK proofs are used in crypto so yeah what is a ZK proof and um how are how are they verified on chain yeah I think so if you look at any ZK based product uh there are essentially two operations that are happening the first one is the proving side uh ZK proof generation as it's also called and the second part is ZK proof

verification right so ZK proof generation happens on offchain machines it could be your mobile phones browser typically it's some sort of large machine that somebody's running on AWS or a GPU running at somebody running at home that's that's where it usually happens proof generation proof verification happens on a smart contract typically ethereum uh right so that's kind of the two operations now the what a ZK proof really is is that it's really encapsulating a computation right so let's say certain inputs right or uh numbers let's say were used and some operations computational operations were performed and then to produce an

output right if we just kind of do that abstraction a ZK proof is really relating that this set of inputs is related to this set of outputs using this particular program it's really telling you that I mean in the in a general sense if you wanted to check that relationship between these three parameters you would ideally be required to run that computation yourself that's how that's how computation has been done before ZK but ZK really allows you to have a proof that these three entities are related to each other without actually you having to run that computation that program yourself right so it's really uh in a way you can say it's a computational compression so you don't have to perform that computation

anymore in order to check that relationship between that input output it's really not a very simplified explanation but it's really one of the it's it's really hard to go simpler than this uh yeah so no that's that's really helpful and the way the way I describe ZK proofs is the ability to prove that someone else did something that ends up that that you and you can verify the result I think that's also like a very simple way um to describe them now in crypto zekk proofs are used uh for a number of use cases like privacy is ALS is obviously one um use case but increasing over the years ZK proofs have been used to in the context of scaling

and rollups um can you briefly describe like the relationship between ZK proofs and rollups sure so so what what happened is that ZK proofs are originally designed for privacy but what people realize that they kind of ended up having this additional property where verification of the proof is is significantly cheaper than the computation itself right so you have this computational compression property again so you can perform some computation elsewhere and then verify it on your chain for a much lesser amount of resources so again you know with blockchains the challenge has always been how do we reduce the amount of computation we need to do on chain so

that's what rollups ended up being that you do perform computation elsewhere outside the chain on on onws on some other third party server and the proof of that is simply posted on ethereum so it really allows you to offload computation without increasing trust asumptions right and so here like the the issue again like coming back to the core problem the core problem is that blockchains are are inefficient when it comes to executing computations we have a limited amount of sort of computational bandwidth on a blockchain due to the fact that they're you know they have all these other properties they're decentralized they're censorship resist Etc that makes computation more expensive and so offloading the

computation to an offchain you know whether that's like a rollup or like an offchain uh computer you can just verify that computation on chain and then continue to run the blockchain as though that computation had been run there so in terms of the trust assumptions I mean are we operating in exactly the same trust assumptions or are there other trust assumptions that one has to take into account when verifying a ZK proof and integrating the you know the outputs of that of that computation into their application whether that's a dii application or whatever yeah I think if you talk about simply the ZK primitive the cryptographic Primitive right if you forget all the systems rollups around that the Primitive itself is completely

trustless I and I think uh people will not really debate that in my opinion that when you are offloading this computation you get full mathematical security there's no uh sort of dependent on any stake particularly for this security model to kind of hold but this is only true as far as the cryptographic Primitive goes the ZK proof itself when you build an entire sort of network around that which is the rollup itself then there are some uh sort of limited sort of uh I wouldn't say trust assumptions but uh nuances that kind of come into picture where there are sort of these edge cases where for example that mass exit problem and all of that where there's some dependency on who's generating the Pro so again like I would

uh it's really hard to quantify what those issues even are and this debate as you know is always ongoing on Twitter what are exactly the trust models for rollups and things get a bit subjective there but I would say that yeah like getting something done completely on chain is obviously slightly better in terms of trust resumptions but rollup model in my opinion at least is is quite good enough to really do that and again the Primitive itself is perfectly trustless in in my opinion yeah sure but like you know I think you made a good point like when you when you build uh A system that has multiple interdependencies you introduce some uh some other trust assumptions that don't exist in the Primitive you know what are some sort of key points or some key connections between those different U um

components of the system that introduce these you know Nuance trust assumptions as you put put it yeah right so let me let me try me it's really a very kind of hard to explain things so I think uh if you were to let's say go Case by case like for example one of the sort of trust assumptions is that let's say the underlying chain which is ethereum goes through a folking process right how does the rollup decide which folk is the one they want to be on right it really comes down to the governance of that rollup deciding which folk is the right one right so that's that's for example one example where you have some

dependen on the governance of the rollup itself now the how do you define the governance of a rollup that itself is a question because whether the rollup governance is happening on chain or is it happening on the rollup itself the governance contract particularly right if it's happening on chain then it could probably be two different governance decision happened on the two folks as well if it's happening on the rollup itself then then what are the liveliness properties around that because if the chain is going through a folking process is your rollup actually going through a liveliness issue as well while you figure out which rollup you're on so these kind of edge situations exist I think folking process is really one of those biggest issues where it becomes very clear uh that there is kind of a different trust assumption over here you

know we can quite starkly see the difference in the models here if you talk about a general ongoing process where the underlying chain is not really going through a uh through a folking process I think in my opinion you're broadly in the same category except the fact that you have some dependency on the people who are actually generating these proofs posting on ethereum so which is which is also also referred to as the sequencer and the single sequencer a multi sequencer debate is always happening on Twitter so if you have a single sequencer right which is basically just one person who has the absolute right to generate these troops on submit to ethereum the risk is that this sequencer can simply decide not to you know not to post proofs at all it could simply go offline yeah and

nobody's now able to generate these proofs anymore right so in this situation again what's the rooll up model in terms of being able to withdraw your funds uh kind of becomes a question usually rollups do have a mechanism you know where Mass exit problems are kind of uh avoided but again like if you have a single sequencer you can have sort of these you know these issues this becomes very starkly clear when you talk about the data availability side of things so for example let's say I have $100 you know in my account on a rollup the proof of that is definitely posted on ethereum but the fact that it's $100 like how like what if I lose that data what if everyone loses their data so generating that state back on ethereum for progressing the role of

forward becomes a little bit hard so that's why having that data available you know which what these dlas actually do becomes a bit of if you don't have that data available with you the role of sequencer can't really run away with your money but it can make sure that you are not able to access that money anymore right so these kind of uh sort of situations exist uh where uh where a rollup model is kind of not as secure as the underling chain right so with rollups you know of course we have this issue of of data availability that is basically like the core of how a rollup operates it needs to have access to the data and then there's also this sequencer problem uh where if you have a single sequencer there can be a a

censorship or liveness problem here where the sequencer can can censor transactions you know voluntarily or involuntarily yeah and that's also one of the risk okay and um one last thing here before we move on to electron and and the aggregation product um a ZK like client what's what's a ZK like client and how does it operate in this um in this scheme sure so before ZK light C let's understand what are like client is right so let's say you're sitting outside the chain and you want to understand you want to verify the transactions happening on the Chain you want to verify if their valid transactions or not so usually chains like uh or well-designed consens algorithms like tender and ethereum they supposed to have this light consensus where if

somebody wants to verify the validity of a transaction uh they can do so without running the full consensus from Genesis right so they should be able to run lighter form of computation to verify this computation that's what a light client or a light node or light consensus verification mechanism is Z Light client is the ZK proof that the light consensus were turned out to be valid so it's basically so ZK light C can also be looked at as an ultra light CLI it's an even lighter version of a light CLI where you get a ZK proof of vality of the light CL execution itself the the reason you need a z light CL is because Z Light CLS are so light that you can run them as smart contracts so you can verify the consensus of one chain inside the smart contract of

another like imagine trying to verify Solana consensus on an ethereum smart contract like you can't do that uh the computation requirement is massive but if you can if you could actually reduce Solana consensus to a z proof you can you know verify Solana consensus ethereum like for like $50 uh which is much more practical than otherwise yeah right so here the the application here would be to say like if you had an application on ethereum or on any chain that wanted to say verify that uh funds were transferred into um a contract or uh were locked uh on salana you could verify the state of salana and then have the confidence that those funds uh were locked over on salana and this we'll get

into later has implications for zqc which uh obviously relies on uh funds being kind of like segregated or locked uh before they can be minted on another chain very cool yeah thanks for that I think that going to be very helpful for a lot of people and sort of sets the the you know the context for the rest of the conversation here um so electron I think previously was focusing on building a ZK IBC implementation uh but you guys have since moved away from that to focus on this key problem which is the cost of ZK proofs and you've built a ZK proving aggregation mechanism that creates a super proof uh I love I love this term

super proof so what is electron doing here like when you're aggregating all these proofs and building this super proof uh what's actually happening in the background and how are applications interacting with the super proof yeah absolutely so let let me just give you Contex why proof aggregation was needed in the first place so as I said you have these ZK light cines which make it really cheap to verify consensus on ethereum but even after you know you have a ZK proof even ZK proof verification is it's much cheaper but it's still quite expensive at the end of the day like based on the current gas prices it has been fluctuating between $15 to $60 in the last couple of weeks and months for verifying one proof now if you want to verify ZK proofs on

ethereum very frequently let's say once every ethereum block this turns out to be like $200 million every year uh so I mean if you have a ZK based product it's going to be really damn expensive to operate that so we learned over the past one year while working with ZK IBC and ZK light clients that it was not just limited to these use cases all use cases using ZK be it privacy uh be it ZK micro rollups be it DK based da Bridges all of them have this problem of extremely expensive proof verification on ethereum so we have reduced the computation very significantly but it's still quite expensive so that is when we really

realize that we need to get this cost of proof verification down this is where proof agregation comes in and in my opinion it's really the only way to reduce the cost uh in the long run that that's kind of really only the fullprof way so proof aggregation works like this rather than every one submitting their own proof on ethereum WE collect these proofs from different protocols we aggregate them together into a super proof and this super proof is then submitted on ethereum what this allows you to do is that now the cost of the proof verification on ethereum is shared amongst all these different protocols and every single protocol has to pay like 1% of the fees that they were

paying originally so a drastic multiple orders of magnitude reduction in the proof verification costs on ethereum so that's that's where we really are so the super proof is simply the aggregate proof of all the other proofs that may be out there yeah that that's kind of what we're doing at this point okay and so when when you're constructing a super proof you're you're taking all these proofs and aggregating them together into one proof that anyone can verify and sort of check that their proof was included in in this super proof uh what's the process for doing that and what's the amount of computation that's required to to do this super proof yeah so good question actually so first of all uh I mean uh if you were

let's say talk about the process itself so what what's really happening is that uh you have let's say four different proofs coming from proof one proof two proof three proof four we basically have this uh so in ZK proofs there's this primitive called recursion so what recursion really does is that it's proof of proof so proof that is proving that a previous proof was actually valid right so what we do is that we create a recursive proof which is proving that the previous four proofs were actually valid right so let's say you have let's say n different proofs coming from various places rather than every single proof proving itself you have a single proof which is taking all these proofs as an input and then create a single proof which is again then validating all

of them so it's kind of again proof of proof but multiple proofs kind of being combined together so recursion as a primitive and once you combine recursion at a multiple level it kind of becomes aggregation and the good thing is that proofs continuously get smaller obviously there's a lower limit but the continuously gets smaller as you do more and more recursion so you you basically are able to come up with this really cheap way to verify proofs on ethereum okay and how many proofs can you aggregate um is it is it unlimited or do you have like an upper bound of how many proofs you can aggregate into the Super proof it it really depends on schemes but the one we use which is plony to in our opinion like you can like aggregate like infinite number of TRS

theoretically speaking so the limit of how many proofs you can aggregate is basically what are the number of machines you can access or what sort of computation you can access because as you're aggregating Moree proofs your computational requirements are going up so what is that limit of how many machines you can get uh before you sort of run out of machines and you run out of that so cryptographically speaking mathematically speaking there's really No Limit the limit really comes from how many machines you have okay and so once the super proof uh is created then it's posted on chain and anyone can verify that or so ethereum is verifying the super proof or like the destination chain is verifying the super proof good okay and then any application can look

at that proof and sort of like take some action based on that proof being um posted on chair and and and verified by ethereum precisely cool and so like what are the trust assumptions so as an application leveraging uh electron ZK proof aggregation um uh system uh I think yeah the universal proof aggregator what are the trust assumptions that the applications have to have in order to use uh electron yeah so I think there are sort of three areas you know three possible sort of areas right so for first one is obviously uh so the first question we get often is that are they settling on us now as opposed to ethereum so the answer is no you are

settling on ethereum so it's think of it like this it's more like proof R sharing rather than you sending you taking your own car to the destination just taking an Uber along with us right so that that's the only thing happening you still get to the end your destination you the whole of you gets in the end destination it's not like any piece of you is getting left behind in the car or anything like that so the fundamental rollup model or the settlement model kind of stays the same the second question that you often get is that what if somebody else's proof has a bug in it and gets hacked does that have a cascading effect on my proof if I'm using your so the answer is again no the way we construct our layer is that all the other proofs in the layer that are getting aggregated can

really fail could have bugs but your proof as long as it's correct really uh will be fine so your application's security is not affected at all okay the third one is that we do have our aggregation or recursion code that's really powering our infrastructure which is something that if there's a bug in that it will have an impact on your application right so you you can say that our additional code the recursion engine that we're adding is is sort of the additional trust assumption so any bug find found in our code can really have that impact so that that would that's kind of the trust model here okay and in terms of so we haven't really talked about the architecture of electron but like is this proof ha this proof uh aggregation happening on like a

central uh server somewhere or is there like a network of uh nodes that are constructing this proof so that we have you know sort of censorship resistance and and liveness failure res resistance what's the architecture so as of today it's a single machine that we are running so we are not sensor of resistance as of today but of course like uh our plan is to really have a Prova Network really doing this uh in fact gute is one company we're in touch with they're building this decentralized Prov Network where people just just come in really start running their own proving infrastructure the aggregation infrastructure and at that point uh electron team really disappearing will not have an impact on the uh you know infrastructure really staying up and contining to operate so

yeah shortterm it's centralized longterm we have a clear road map to really hand it over to the community basically okay so I'm actually curious about you know if you could go into detail here on the sort of longer term road map is the goal to build a like a dedicated electron uh layer one that would do this proving aggregation or to leverage some other infrastructure uh I I would say uh again so the reason uh anyone would be using a proof aggregation is because they're trying to get to the ultimate chain which is ethereum or some somebody else in the end right so for us to have an L1 which is really adding those trust assumptions wouldn't really make sense having said

that there is an opportunity here where when it comes to these two Network there's some sort of coordination required between all these people there's some sort of batching required for all the proofs that are coming in so we still still need to create batches or blocks as one can call them to really and and again have some sort of coordination among them so there's some sort of a you can say a s an L1 that doesn't really is not required for security purposes but for coordination and liveliness purposes right and eventually yeah I think in the long run our network will start to resemble something like that right uh you know yeah so I I think yeah that's kind of the long-term plan here yeah

yeah yeah okay so so I mean I think what I'm getting here is that the the utility of an eventual electron network is more a liveness and censorship resistance uh feature than a security feature because I mean we're talking about ZK proofs here so obviously like the proofs that are generated are verified by the ethereum blockchain or the destination chain and so that aspect kind of disappears um in in terms of you know coming back to the censorship resistance aspect uh what then becomes the um like how how would these different nodes sort of coordinate like would you have a I guess I guess what I'm trying to get to is is like how do you

incentivize uh nodes to stay online because like typically you know if you look at a proof of stake Network U we slash validators for producing bad blocks or um or sensoring blocks um although you know the censorship aspect like if you look at a cosmos chain like you can be offline for some time and like slashing is is fairly fairly limited but if you want to have like a really a really high liveness Network you'd have to have some sort of an incentive for those notes to stay online and to produce proofs very fast I presume so like what's the mechanism here for incentivizing that and potentially like slashing those those nodes if they were to go offline or censor uh proofs yeah I think at this point probably having a token would

really make sense I mean it's it's too early to kind of really you know at this point we really want to focus on the product and token can sometimes thought of a distraction but I I do think that again in the long run here that as as the as the community really starts uh that we sort of you know kind of disappear into the background and the network for for for their own sort of confidence in their product they would want that the network is really not dependent on us and the network can can kind of self sustain without us being the electron team really being kind of being the you know one tipping the balances tipping the scales in in kind of in the right way so I think at that point having some sort of a slashing mechanism or an incentivization

mechanism using a token becomes really important right and again like one thing I kind of forgot to mention here is that these people who are kind of using our Network they really need to uh they really need to pay a fees which is different than the fees that is being paid to verify these proofs on ethereum so these are two different things right they're paying a different fees they're not paying the ethereum gas fees anymore they're paying a different fees now so there's probably an opportunity again uh need here to really have some sort of a like a gas model on ethereum or some sort of a gas token maybe which balances the demand of proof uh aggregation versus what is available on the ethereum Block space and what's the cost of verifying these FS on ethereum so this

kind of this kind of mechanism I think the token is really well suited to have this kind of balance these two or three things out which is incentivization penalization and balancing demand and Supply so that's kind of again it's incredibly starting to look a lot closer to like being n L1 uh over a long enough period of time uh yeah okay so you mentioned that you guys are using planky as a as a proof scheme what are the other are there other compatible schemes like snark or Stark or other types of proofs that can aggregated or that are compatible with electron yeah so I mean uh so everyone out there is using a different scheme right uh some people are doing Halo to

Groth 16 uh blony to stars all you know all sorts of proof systems are there so I think for us it becomes really important that we support all proven systems we we really can't be limited to one proven system because uh you know everyone wants to access etherum block space everyone needs cheaper poops so the way we really envisioning this in the long run or even I I would rather short to medium term is that all proving systems or all proofs based on different proving systems should be aggregable so we should we should be a able to aggregate a plon proof with a stock proof with a halo2 proof with the gr 16 Pro so all of them should be agreable right so it's again uh not not been really done before there's not much the

kind of ideas of in the ZK space how to really do that but I in my opinion it's really an unsolved problem at this point the how do you reduce all proof systems into a single proof system so again that that's that's an experiment our our engineering team our ZK team is kind of doing internally we' made quite a bit of progress with Gro 16 uh and plony to uh and stocky interoperability with each other Halo 2 is again something that's really on our timelines how we want to do that uh yeah we just kind of it's It's question of road map and R&D how how we do that but you have to aggregate everything at the end of the day what's what's the biggest challenge like for like a total cryptography nimwit like myself like

what's the biggest challenge in aggregating these different proving schemes yeah I think the biggest challenge is we don't even know what will actually you know it'll take to actually aggregate them I think the that's kind of the biggest unknown here but I think uh so cry obviously there are cryptographic challenges that you know for example one proving System is using totally different kind of mats versus the other one and how do you get the maths of one proving system to work inside the mathematical structure the second one and vice versa so that's kind of the cryptographic description of the problem right but I think there are many practical challenges as well for example within our team for example we have great expertise on plony 2 and Gro 16 and these kind of proving systems but

let's say we wanted to do Halo 2 now we have no one in the team who does H and you will not find anyone out there I think I mean there are always exceptions that but you'll have have a hard time finding a cryptographer that understands all these proving systems with enough depth so it becomes a very big hiring and team building challenge as well but how do you actually get all this Talent together and again you know a lot of times these different proving systems and people from these different communities they also tend to be like politically disigned with each other they don't want to work together with each other those things kind of also exist so it's really this uh technical cryptographical practical political combination of all these challenges that

one really needs to go through to make this happen uh yep how many like top tier ZK Engineers or researchers uh are are out there like is it in the dozens in the hundreds um U yeah it's it's a difficult question to ask so I I I did this EX in India once like I was able to count a total of 14 Zeke engineers in India right okay so if there's 14 ZK engineers in India a country of like over a billion um what what does that say about the state of ZK yeah maybe there's just a low concentration in India definitely definitely very low

concentration here uh uh in terms of you know per capita Bas it will be higher in the US and Europe side but I think uh like I think the number is definitely less than 200 uh and I think 200 will really yeah yeah I think wow again like you know like if you start counting all the people in PHD programs across the world that number is obviously a lot bigger but uh like for example somebody doing cryptography in some college they might they might touch upon ZK so again how do you qualify whether they they part of the ZK Community or not but people who are actively working on the ZK space either in Academia or in the industry I think that number will be less than 200 in my opinion uh yeah so so basically like all the people that

have been on the ZK podcast uh that's the entire ZK Community for the most part all right well good job Anna um so yeah what's the like let's talk about the SDK a little bit the electron SDK what what is it and how can applications leverage it so uh we haven't really had a chance to release the SD itself so kind of early early days for for the SDK itself but so our philosophy for the SDK is that so we'll have this sort of uh infrastructure right again think drawing the Uber energy we already have a bunch like uber already has a bunch of cars running around and people sort of just come in and start using this people kind

of plug into the network and start using it then exit the network similar model here we have this aggregation Network which will be up and running and it will be aggregating proofs all the time and anyone who wants to submit a proof can just send the proof to the network and it will get aggregated and submitted to ethereum and our overall architecture will kind of make sure that you are able to extract your proofs specific information from our onchain submissions so you can kind of do that again drawing the Uber analogy the network does require a certain critical mass to exist in it for it to continue to make sense right so so let's say if there's no one using the aggregation layer then the cost of the aggregation layer really is the same as Pro submitting a single proof so it doesn't really make sense

again you know the Uber energy so again coming back to the to your question so the SDK will some sort of look like this that we will give you this RPC end point which will simply be accepting proofs from various people out there who want to submit proofs and once your proof comes in then we kind of handle everything else we generate your proof aggregate it together and submit an ethereum and then we give you certain pieces of uh onchain apis that you can call from and see that okay that your information is actually made to to the blockchain so again you so the SD kind of two parts checking uh sending the proof via the RPC endpoint and kind of pulling the relevant information from the onchain contracts yeah so the integration process is

really it's quite simple actually on on the high level it might seem complicated but it's really that simple it's just sending a proof rather than broadcasting it to ethereum or sending it to us it's it's really that simple okay so you know as an application you integrate the SDK that just allows you to you know send the proofs to to electrons such that they can then be aggregated and posted to the chain I read something about like I wanted to ask you about which is leveraging ZK uh proving in the browser and so this is something the SDK I think enables can you expand on that yeah no so we we we don't do proof generation in browser but yeah Happ to talk about browser based proofs in

general so so so again uh so that I think two kind of schools of thought about Bowser based proof generation some people are really trying to uh do distributed proof generation with some sort of in intended effect on scalability side of things personally I'm not I'm a bit skeptical of that I mean distributed computing based on leveraging people's individual machines that never really took off like ultimately people grav or the market R gravitated towards AWS and cloud-based systems you know these ideas never work and I think in ZK as well it will not really scale ZK proof generation in my opinion the real reason why browser based proof generation will take off in my opinion is for privacy right so if you're really trying to hide the data of

your transaction and you don't want to you don't want it to submit on on chain but you still want to leverage on chain uh you need to generate your proof in the browser because whoever generates the proof has access to all the data right so if you want to have a high level of privacy uh you want to generate your proof in the browser so I think one of the reasons browser proof generation hasn't really Advanced as much as we would want is because privacy hasn't really Advanced as privacy as a market and and kind of privacy products start to make sense people will start asking questions that why are you generating proofs on a server which can then now see all of my data so I want these proofs to be generated on my machine so

that I really have that kind of privacy I think that's how this this Market should should really play out uh in the long run yeah yeah one application I see here is you know I've talked to some teams that are doing um something in this in this area as ZK kyc so the ability to kind of do it do some kyc right locally on your machine so it could be I think here you'd have to have some kind of a like an application like either on a phone or maybe like a like a wasm application in your browser that checks the validity of some document uh could be like an ID or like your proof of residency document or something like that and then generates a

proof and then like submits that so you can basically do your own kyc without having to share all of this personal data with some random company or like some random person uh which you for which you don't know the sort of security practices or you know if they're going to leak their data I mean like that that happens that still happens a lot and then you could then I think that becomes really interesting in terms of having compliant blockchain applications where you can have proofs that a certain user has been verified so like in terms of Cil resistance that's like a huge application here but also in terms of making sure that you're like your users are in a compliant geography or jurisdiction or like something like

that I think that that's one interesting application um I've also heard um people talking about like having a validator in the browser and using zkm and proof verification in the browser to be able to kind of create a uh distributed network of of nodes and this would be particularly interesting for like small communi that are like kind of bootstrapping right where you have like an early number of users that aren't necessarily like professional validators but want to run these machines so it could be like for gaming or or like some us cases like this yeah I wonder if you have thought of other use cases that might be interesting for

like in browser um ZK proving so again the the the use case you're describing here I think is more of a z use case right so somebody was trying to verify let's say let's say trying to run the validator browser again too much computation too heavy for a browser or a machine so the idea is that you simply donate a ZK proof of the validator node and then verify it on your so again so you're not uh generating a proof in the browser you're verifying a proof in the browser so this is an application of proof verification in the browser yeah uh yeah again I I I I I have this kind of probably a bit too set of an opinion that browser based proof generation is really for privacy application like like the one you mentioned kyc is is a great

example right it's really a great example of this application u i I personally have thought about this a lot I I don't see why would somebody generate a proof in the browser if you're not trying to hide the data just just offload it to to to server man like it's just it's just quicker you know yeah yeah I mean there is the censorship and kind of liveness aspect so like perhaps you could have a like a fallback in the browser although this is kind of like an edge case right where like I mean most of these servers are online but like for an application to um have the a fallback mechanism such that like even if the servers go offline or they're taken offline you maybe by like a a government or nation state then one can still like do the proof

themselves as like a last ditch um kind of you could say that yeah yeah you could say that actually I mean it's like so you have single sequencer you have multi- sequencer and you have browser based proof generation so multiple levels of permission lessness or sensorship resistance basically and Bowser based being the ultimate one yeah yeah interesting cool um how are you working with like on your website says you're working with nosis and near and hyperland and router and a bunch of other uh teams how are you working with these teams yeah so uh most of these Integrations uh have been over the last one year they've been uh building ZK light clients or integrating existing ZK light clients with their infrastructure so for example with nosis

and near it has been building the Zite Cline for that chain itself and if you talk about router and hyperlane it has really been integrating existing ZK like lines with their Network so again hyperlane and router have this model where new security models can come in sort of plug into them and uh so the messaging layer kind of STS the same and our kind of uh ZK light security kind of integrates with that so that's that's what these Integrations are about again uh lately we've been moving everything towards proof aggregation so we we plan to aggregate the nosis light client the near light client into the aggregation layer fact that's that's something we've been discussing a lot with NOS team like one of the challenges that they have been facing with existing

implementations of Zite cines that they have they turned out to be extremely expensive uh again the gas cost verification so that's something that we are planning to work that we're working very closely with nosis on that we just get the cost down significantly lower same with near and again just kind of enable hyper Lane and rout to kind of Leverage that infrastructure to really add security to their customer base yeah so it's really kind of an adoption and business side of things really happening and playing out uh with this well that that brings me to the next thing I wanted to talk about which is inability and IBC I think this is one of the big applications for ZK and crypto and perhaps even sort of brings us to the end game which I want to talk about uh a little bit later but what are the

challenges in um bringing say a technology like IBC to ethereum and how does DK solve that so bringing IBC to ethereum has been I think discussed since Cosmos has been around it's you if you go back into those early days you you still see discussions around that and uh the challenge has always been that again IBC operates on this light clent model and as we discussed earlier that right CLS are again too still too expensive to verify on ethereum because of the block space limitations so it has always been a challenge how do you get the tendent and the cosmos light Trends verifying on ethereum so more than a year back electron came out with this paper where we showed that uh you can

generate ZK proofs of tender FL clients and verify them cheaply on ethereum so that has really kicked off a market in the last one year we've seen teams like Union polymer sync who really come up with these ZK tendent implementations to really make this happen right so this has been sort of ZK IBC 1.0 uh what people have been working with for quite a while and has been I think at this point is quite well understood in the cosmos community but if you actually zoom out you see that while these implementations exist none of them have gone to production none of them have gone to mainnet they're all ready for mainnet none of them have actually gone to mainnet and nobody really talks about that but the in my opinion the reason for that is that the moment you put

these things on midet the cost of proof verification will start to hit you and there's no one out there who can pay millions in fees every month to really do that so that is where uh our latest work with zki IC which we like to call zki IC 2.0 really comes in so zki IC 2.0 is zki IC plus proof agregation right so uh what we doing is again it's uh very straightforward rather than every single chain sending their own ZK tendent proofs on ethereum and paying the gas fees we can create an aggregate super proof for all of the cosmos chains so right now we have aggregated the top four chains uh in Cosmos which is Celestia osmosis injective and Dy DX so

if you have four chains being aggregated the cost that everyone is paying is 1x4 so this is live on testnet today we recently announced this couple of weeks days back but what we're doing now is really uh so there are 62 chains uh that are on Main net in Cosmos so we are uh as like we planning to expand our sort of chains that we supporting very soon and I think some something to the tune of 20 chains will get aggregated now again available via single proof uh so if you have 20 chains the cost that every chain is paying is 1 by 20 so you're paying 5% of the original cost so 95% reduction will be available right off the backat uh to these costos chains uh and again in my

opinion uh everything else can get solved you can always have a better proving system you can have better Hardware you can get the proving costs down quite significantly and some of the late implementations have done that recent implementations but proof verification cost is a limiting factor which is what IC 2.0 will really solve for the community yeah yeah yeah I I think this is also kind of the idea behind Atomic IBC right is to be able to aggregate all of the different uh IBC messages in in Cosmos onto a single chain and then that enables kind of asynchronous comp composability are you familiar with that uh yeah I I have some idea like uh you know people are trying

to kind of solve this problem in bridges in General uh so I think polygon AG is kind of also trying to attack that problem from from what I gather so the idea is that everything will kind of settle on ethereum Via this aggregation layer and the ethereum whatever settles on ethereum becomes a source of Truth so we can sort of pull this data from eum and you kind of know what has actually settled and what hasn't settled so you're really trying to define a source of Truth which could be to be honest any like it could be Cosmos Hub as well like you could settle on Cosmos hub uh again I haven't really looked too closely uh on how Atomic IBC is happening but been looking at what polygon is doing so I'm kind of guessing that that's that's what Atomic IC is about that we all try to

aggregate source of Truth in one place and kind of Leverage off of that uh yeah can you can you talk a little bit about like speak to the union approach and the polymer approach because I think those are the two teams at least like coming from the cosmos side that are most recognized as build this zki IC I think they now have a slightly um differentiated approach where you know polymer is focused more on the rollup space and and Union more on the broader app chain space how could ZK aggregation be leveraged by these teams to make the entire process more efficient yeah so uh yeah I think uh uh so if you let's talk about Union

particularly I think I was looking at Comet BLS which is which is the core product uh as far as I understand so I think that leveraging the agre so again they have used using some sort of aggregation already so I think the one of the reasons they did that if I'm not wrong is that they introduce BLS signatures for their chain and BLS signatures can be aggregated right so it's much easier to verify these BLS signatures on I think that's that's the reason I think they did it if I'm not wrong again so they're kind of already leveraging some sort of aggregation in my opinion but again uh in the long run even verifying a single PLS signature is a little bit expensive you want to get even that that cost lower and it's not just the signature like you still have to verify rest of the headers and as

more sort of chain data comes in this state this cost will probably go up so I think there's an opportunity for electron and unit to work here that their Comet BLS proofs can sort of be integrated with within the electron aggregation layer and then be submitted to theum so it will I think together this can really make Comet BLS and electron based cki IC cheaper than Axel itself so Axel itself is quite expensive if you want to go I hear this often from Cosmos folks that it's super expensive people were I think paying nor of $100 for going to ethereum I think together this combination of comet BLS and electronic I think will make uh ZK bridging ZK IBC cheaper than even centralized bridging uh you know so

yeah I think that's how polymer uh Union could probably use that polymer had been uh lately have been I think they focusing more on the as you said rollup side I think earlier they were trying to do something around uh uh they were trying to set up their own chain where they had changed some of the signature Primitives to ZK friendly ones which I think was an approach they aband later on uh so hard to really point out uh but again I think they could again they don't need to do that anymore they could just send the proof to the aggregation layer and not you know be leverage much cheaper cost right away yeah you you said something really interesting here

which is that you think that uh zki IBC could be even cheaper than centralized bridging yeah yeah so I mean so say right now if you talk about the cost of proof verification on ethereum so if I the last time I checked I think AXA was charging north of $100 for sending transactions to ethereum I paid $80 myself but if you talk about the proof aggregation layer the cost of verify transactions or proofs on ethereum will become cheaper than $5 right so $100 and $5 so it really becomes really really much cheaper than what a is offering right now uh and I think once you have higher level of

security the IBC level of security and a much cheaper pricing model as well I think it's really a very strong case for people using such a bridge as opposed to something like uh axler which is super expensive right now yeah yeah I think one of the other applications here for for zki IBC and ZK bridging generally is mesh security and reaking and like all of these applications that leverage the security of another chain and is able to verify the state of another chain um or at least verify that stake uh is is securing another chain like H how do you see that playing out uh long term and I

guess like taking a step back here what is is the ZK proof endgame like do we end up in a world where ethereum is just like this massive ZK proving ver ZK verification machine that is just verifying proofs from all these different layer twos and other chains that want to leverage its security like yeah take us take us like far into the future here yeah I think I 100% agree with that I think uh what's going to happen in the long run is that nobody access ethereum block space directly right everything will happen inside a ZK circuit and the only thing we'll do on ethereum is verify these proofs right so the only

function that the ethereum virtual machine or all of this infrastructure will have is just verifying these proofs consistently and we will be in a future where all ethereum block space so if you go to Ether scan if you look at a block and you look at all the transactions in the block all of them will be just ZK proof verification there will no longer be Unis swap swaps or simple trans they will just be proof verification and the reason for that is because the cost the demand for for uh the ethereum block space is so high and consistently increasing that it it's just not possible to access the etherum block space directly anymore it's it has become really hard for users right now I think in the long run it will become hard for even application specific

rollups or the larger rollups for that matter so I like to call ourselves as a ZK rapper for ethereum Block speed you will access the etherum block space via this ZK layer and nothing else and uh yeah so you have like ethereum block space here and then you kind of zoom out this aggregation layer which is offering you much more block space effectively and on top of that you have these rollups which then again offer you much more block space which kind of multiplying As you move up the layers uh yeah 100% agree with you on that just C proof verification nothing else is required on ethereum in my opinion and do you see uh do you see Bitcoin playing a role here I know this is also like currently like it's impossible to do ZK proof verification on bitcoin

but like Bitcoin is such a massive blockchain with like hundreds of billions of dollars of of market cap and a potential for it to also secure lots of other applications and we're seeing now like rollups on bitcoin do you think that at some point Bitcoin could also secure um you know other uh applications and basically sort of like do this proof verification on chain sorry I realized I said hundred hundreds of billions it's like you know over a trillion dollars of market cap yeah I first of all I mean I think everyone wants to see that happen I think there's no question of that uh we have also kind of experimented with Building trustless Bridges between

ethereum and Bitcoin in the past we could never really solve that problem I think I think Babylon chain is kind of really going places with respect to that I mean the protocol is definitely interesting but I was also check talk about some of the cryptographic Primitives they're kind of playing around with they have this thing called accountable assertions which really Leverage The Limited cryptography that you can do on bitcoin and leveraging that to really enable all these other sort of larger cryptographic pieces to happen I mean as you said right now it's impossible to verify gr 16 proofs ZK proofs on on bitcoin right now but I think over time better cryptography might unlock that again I think we are very far from that but there some sort

of if you go really deep into the woods on the Zeki side of things and we talk to people who are really touching on things like f and all of that there are some sort of early ideas as to how that might happen that stuff is kind of a little bit too hairy for me as well but again I think uh it will eventually happen over a long enough period of time I think where once you figure out one if you can verify one proof every 30 minutes on bitcoin that's all all you need one proof every 30 minutes on if you can do that then you can build everything else on bitcoin just just that that's all you need because then you can have aggregation layer to multiply that one proof every 30 minutes to large number of proofs and when you have large number of proofs you can have

a lot of computation in them so yeah I think it will eventually happen not sure how but yeah fingers crossed on that well the time horizons with Bitcoin are always a little bit longer than uh with every other chain but yeah I think there's also like a a huge potential here for for Bitcoin to really uh serve as like an underlying security layer for a lot of a lot of defi activity and sort of blockchain activity generally and I think we're starting to see that a little bit now and there's a lot more activity happening on bitcoin and as someone who's been in the space for a long time and like started with Bitcoin something I find really exciting yeah I love this idea of that everything else is an application layer

for Bitcoin basically I love that notion yeah great gab thanks so much for coming on today it's been a real pleasure and I think a very interesting conversation uh and looking forward to seeing electron grow and you know become a larger part of the ecosystem and providing proof aggregation for applications across ethereum and Cosmos and all other ecosystems um how can people learn more about electron I think the best way was follow us on Twitter V are at Labs electron on Twitter you can join our telegram Channel as well and which is ZK electron and we have a bunch of other de chats would love to have you join

them great thank you thank you thank you so much thank you for having me