Securing Cross-Chain Interactions with ZK Coprocessor: From Design to On-Chain Verification

Transcript

[Music] uh hi uh my name is Bartk and uh I work for Herodotus and we are going to cover today basically uh the topic of uh crosschain interactions in general how to make them zika provable and uh and also like the design of the co-processor. Um and uh and in general yeah so we can start we can start with the problem we've got uh in general in the space like we've got couple of

blockchains there is like data distributed all around them couple of like interesting facts we can have like for example somebody like has some has some like high balance somebody can can have like some interesting history and all of those kind of like are separated among blockchains and uh what we want to do is be able to uh make some statements about those um about this data uh in general and kind of later maybe like convince somebody that uh that that that kind of we logic or like the the the thinking we've got uh is is like like convince somebody with the with the zero knowledge proof about this about this data essentially distributed all around the all around the blockchains.

So, so far it actually like requires uh generally like there's some trust assumptions to do such a things uh because like for example you want to do simple bridge uh that is going to like uh check if the one one one on one side the the funds were deposited on the second side is going to like mean the funds. So it requires some oracle some some uh some sequencer and stuff. So, so the like currently uh more or less most of the time the the the the solutions kind of require the uh the trust assumptions uh some centralized centralized back end to to to like manage these things. Uh and also like smart contracts really struggle to um to

like access the data crosschain. For example, you want to have some uh some some some smart contract to like uh like give give you access to something based on the like history you've got. for example on Bitcoin or for example on Ethereum and it's like a little bit problematic and slow to do this now. Uh so in general um like the the the uh data on the blockchains is really structured. So that's really the thing we can leverage. Uh the data on the blockchain is kind of like built in the in the treel like tree like way. So to just really quickly show you the good diagram I found online. Uh for example this is Ethereum. uh there's like couple of couple of sections what we are like

mostly interested in our use cases in with our clients and stuff is like like the state roots thing. So essentially like the the states of for example smart contracts what the values they kind of have in the maps and stuff. So uh the the the data in the blockchain is really nicely structured. Uh so like when we have this MPT this is like Merkel particry uh essentially like we've got couple of like this is this is essentially like the data on the in the smart contract itself. So there is like a algorithm to like have the proof of this specific element really exists in the tree itself and we have like uh really like pretty simple logic to to see if if this data with like the only

the necessary things from from the from the like other parts of the tree. we can make the statement if this is really comp like like essentially like calculates the same route that was actually in the in the in the state root of the block. So there is like a way uh like algorithmic way to verify that data really exists on the blockchain and it really comes up to the final block. So we can recalculate the block hash and later check if the block hash is really in the in the blockchain. And this way we actually can prove like one simple small thing about some for example account balance like check it like if it really exists check the leaf exist check if this root note exists and recalculate the block. So in general there is like a logical way to uh to to make it to make

it work. What we did essentially is like bringing this this logic is like really really easily accessible in Rust. uh there's like many libraries to do so and what we did essentially is like making this logic but available right now in the Zik cell uh and uh and and we implemented the whole logic to to to verify this sort of uh statements in in Cairo in Kairo zero. Uh so right now it's like really nice and really uh let's say easy and and pretty fast. I'm going to show you the capabilities uh to make the zero knowledge sort of statements about this about this data that exists on the blockchains. And this is like Ethereum example. You can do the same like the the the same adapters for like the other other other blockchains.

Uh not not necessarily like EVM EVM based. Uh so so so yeah. So so so it's pretty powerful. Um so this is the general how the how the storage proof works. Uh and the and the Herodotus uh like Herodotus we've built the Z co processor for that. So this is essentially like bringing this logic of verification into the into the Kairo zero DSL. Uh and uh this allows when we have like couple of adapters for different blockchains like uh like like for example a chain or for example Ethereum for example couple of those we can like verify the data from from couple of those bring them into the into the like common ground into the into the Kairo zero into the trace of Kyro zero and create one single proof of for example some statement. So we're going

to get into the more specific examples in a second. uh but in general uh what we did is like to also bring to the user the the the flexibility of this solution. What you do is like you define your your your kind of like module of logic uh in in Kairo one in Kairo one like program later you just you just compile it into the into the bite code and uh you put it into the framework of of of of the zk processor. Uh I'm going to show you in a second how it works because I I have like a nice nice video. So essentially like you define your logic your your logic for example accesses couple of storage slots couple of um couple of like maybe account balances and stuff what you bring it

into the co-processor processor like figures out what I have to download for the from the RPCs uh what what what like storage proofs I have to kind of also bring from the nodes and later when the when the sound run is is is actually like executed it verifies all of those data on based on the like logic I explained like a second for and runs the custom logic of the of the of the of the user. Later the uh later the like the whole thing is kind of like um like the trace is generated and later can be proven can be proven with the uh with the with the with the proof with the uh with the provers essentially. Uh so uh when when we've got the proof of this sum statement essentially from the of the user users logic and the and the

onchain data what we can do is like the verify this on chain uh we can verify this on L1 verify this on L2. Uh this specific like slide example is verifying the stuff on the on the L2 with the integrity verifier. Uh this is like the the ZK stack verifier uh that is right now working and deployed on the stark net. So so like you can have this kind of like finality options. there's like of course finality option for the for the one and stuff. So so onchain data custom logic and uh making the statement on chain to like maybe convince some smart contract that you are for example eligible for for like voting power and stuff like this. Um yeah the the recent capabilities um for example uh I can show you like this I want to show you

like this starkgate bridge solveny this is really nice example I developed some time ago. Uh so essentially when we have two sides of of like Stargate Stargate Bish uh it's like one of the on the L1 the second one is on the on the starknet the the first one is on the on the Ethereum you can check if like for example the token balances on the both sides uh really like kind of are close to each other. Uh so uh so and after that like when you have the data from the chain one from the chain two you do develop this custom logic to verify this you later can u can like develop the like prove the zero knowledge in the zero knowledge way that you actually checked it and for example you've got like a nice I don't know like like green marks okay this that this this this

bridge is still working and it's solvent and stuff. So uh how this module works, how this module looks like. Uh I hope it's like somewhat visible. One second. Um okay. So the stuff this is like the the module for the ZK processor in general. This is this module is going to like access couple of data like it's going to say it wants to like get some data from the from the blockchain. It gets from the blockchain one from the blockchain two and later this is like presented to the to the Z processor like back end. This is all like client side run and you can run this on on the client side fully like you can do the trace generation on the client side and you can also do the proving on the client side. So in general this is the whole thing is is running on on your on

your laptop. All of the benchmarks by the way I did is on this consumer laptop. So so we we're going to go back to it. But in general the main function is like okay I want to access data on the start gate. I want to access data on the startet. I want to access data on the on the L1. And um so this is like L2 access and uh and in uh um one second and um yeah and in general uh I want to like get the from the from the both sides I want to have like a token balances later. Uh so I have like Stargate balance on on Ethereum. I have like a starket balance on on on starket and this is like you see this is like getting a storage slots like from the from the from the uh from

the starknet smart contract and it's like get getting a balance from the from the on the Ethereum side and they can check if this balances kind of like are close to each other. This is like logic I defined. Maybe it's right, maybe it's wrong. But essentially like uh uh this this logic what I want to see is is like this module want to check if this is up to some certain percent. But the data from the chain I I got is is verified uh like with the with the like MPT MP3 trees like on the on the Kyro zero backend side. So so so this later this whole module can be proven one single ZK star proved to somebody okay the bridge is for example still working. uh the second nice example. So so this target is for example zero 0.6.6

seconds to to to run 9 seconds to proof uh on with with the stew on this laptop. Uh and for example like maybe maybe some other example um the uh like address non-interaction. So you can say for example like this is like a compliance compliance module compliance kind of uh compliance kind of flavor. So what you see is like okay I have some address but I want to check it's every transaction if it's never interacted for for example with tornado cache so it's never sent any stuff to the tornado cashache uh yeah this is this is the example you you can think of so it's like going through the like checking getting the nons of the account going through all the nonsis checking the transactions that are corresponding

to this nonsis and checking if the if it never interacted with the with some like uh like forbidden address essentially so yeah this is like the also pretty cool. Uh 3 seconds to to trace gen, 70 seconds to prove. Uh yeah, this is like the the current capabilities. Uh so in general also like maybe blacklist example is like this a little bit more uh sophisticated example. So in general it's similar flavor but a little bit different approach. It's like I'm checking the blocks like for example span of 100 blocks if uh if there is like a no event of uh of withdrawn from the tornado cache to me essentially so like tornado cash never sent or like

there was no transaction that actually gave me some stuff uh from from like the forbidden address essentially tornado cache is just example here it's some some forbidden address for example so I define the withdrawal event signature and I check with the bloom filters inside the zco processor based on the data that was that was on chain and verify it. I check uh if if nobody like if there's no such event for for withdrawal to my to to to some certain account essentially. Yeah. So so it goes through the through the indexes of blocks and checks in the bloom uh essentially if it contains and stuff like this and if it's true I'm just blacklisting some some address. So it can be used for example like using the like this like having a nice big trees of like blacklisted example blacklisted

accounts that are kind of like spoiled and this is like some area of of blacklisted accounts and stuff. Yeah. So uh yeah in in general that's the that's some that's some that's some examples. Yeah. And uh one second. Uh and um yeah I have some videos I can show about like how to run this thing. So so in general this is like the like the like the rust run uh of this like ziko processor. First thing what we do is have to do the dry run. This is like uh like figuring out what essentially is necessary to get from the from the module like like what necess what data is necessary to to actually run the module. So this is like

figuring out okay what was the accesses maybe what balances I have to kind of break from the from the RPC. uh later like we we do the fetching. So actually the the the proof fetching uh so we are also connecting to the RPCs to the to like GIF and okay give me the account proofs of of this account and this account and uh and the final when all all the all the data is ready and kind of like ready to do the actual uh the sound run. So the run with all the checks of MPT checks and stuff. Uh it's like the the the final um the final round. Uh one second. Uh it's like the it's like the final round and this is like essentially like the trace generation is of course pretty fast. So so yeah so it's pretty so it's pretty basic. So essentially that's how we use

the the the the dry run the first stage later the proof fetching and later the actual sand run and and this is like in this in the in the in the in the kairo zero. So in the in the provable DSL checking every every data like you see also there's like a uh there is like a um because when you recalculate the block the block from the from the state roots you have the you have still the problem okay what actually I how can I prove that this block really existed in the in the blockchain itself. Uh let me stop it. So uh you have to also like prepare some infrastructure to actually okay I want to check if the block really exist in the blockchain itself. I could do this. Okay, I just jump to a block and go back to the to the genesis. But

it's too slow. It's like if you have to do this every time, it's it's it's pretty bad. So what we do is like we grow some infrastructure also in the in the zero knowledge provable way that we we grow essentially like like a tree that okay there there exists a contract that holds the um that holds the like state root the of the of the like of the tree that was grown uh with all the block hashes essentially. So every block that exists in this tree uh was really checked for this up to the genesis essentially like was was checked if it really fits fits the chain also in the in the in the provable way in the zik circuit that travels back uh to the genesis and it was done like for you and

this is like the infra maintenance that it actually speeds up the the process for the users. So uh so so yeah it's also like one single smart contract that just holds one value in 256 of the latest state route and this uh contract accepts this state change only if it sees the proof of actually checking checking to the genesis and this is also done in the in the kairo zero and and zero knowledge way. So it's like offloading the the stuff uh to the to the to the like some other back end essentially.

Um yeah so the uh 5 minutes okay so in general like between stages uh maybe if I have maybe let's not go to the technical details maybe let's go to the interesting stuff because like when we do this sort of things we see that essentially we have pretty high demand for the um like we generate a lot of traces essentially so we have a demand essentially because like when you when you have like a big big trace you have to prove it. So when you have big trace the resources consumption for the proving stage is is is quite significant. It grows uh it goes pretty rapidly. So in general what we what essentially like I I did a lot recently is like the research for the

continuation stuff like so minimal change we have to do for the existing ste prover to to support the the continuation stuff. So continuations is like okay I have a bleak trace I want to split it into chunks prove it separately and later when I have couple of proofs I can I have to aggregate them and check if they really like did the stuff they supposed to do and after the aggregation stage like this circuit this aggregation shut aggregation aggregator is still like the developed in the in the in the DSL so it can be also proven but right now I I have this like much smaller proof because this is just a couple of verifiers So I can like prove it again and give the give the final give the give the final like statement

essentially. So this this trace is pretty big like it's huge to to put it into the single single strip prover. So what I do is just split it later aggregate it verify it in the also in the in the in the zk circuit and prove it again. So I have like uh like I have I have like this leverage of not not having to prove the super large trace all at one time. So, so this is what we what I what I did pretty much uh like um this is currently working uh like we are using this internally and this is like essentially generating that's what you expect. So essentially big trace couple of proofs later aggregate them. Uh so so yeah all all pretty pretty basic. Uh so

uh yeah and actually this is like like super nice that we actually were managed to like achieve this with super small um modifications to the current stew. It's like um yeah it's like a pretty pretty nice to see that this is like not a not a big change. uh and uh and what it's important also to remember on this side of the aggregator like when you have the aggregator it also has to be because here when you when you split the traces into couple of couple of charts it's like okay I have like I I present to the ST proofs okay uh like prove me this couple of of of kasm transitions this is like the memory for you and okay this is like doing the doing the job but later

on the aggregator side you also have to kind of see if the if the if the shards are like proving the the the the the like part of the original stuff you actually intended to because maybe somebody actually flipped some you know some some trace that this shot is not proving anymore the the stuff you are interested in. So you have to like check the commitments for the memory. You have to check the commitments for what was actually proven. And this is like the the aggregator stage uh aggregator stage logic. But uh yeah uh right now it's it's it's implemented and it's working internally. So so so it's pretty cool uh in general uh yeah so so it really helps and it's u but like having a more specific um benchmarks and stuff. Yeah.

We I'm going to have this next time so not yet. But in general, yeah, that's that's I guess pretty much. Any any questions for this? Any questions? Okay. So so when you use the setup for verifying the states across chain like for Stargate or something like this how do you like it needs to be that the proof generation is fast enough so that there's no state transition in either chain right can you can you say again like I have chain A and chain B and I have the state

root of each chain and I prove I generate a proof for solveny or something across both chains and I need to make sure that the proof is generated fast enough so the state transition doesn't occur in any chain right yeah yeah so yeah yeah yeah sure sure so what we do is like okay okay that's good thank you thank you continue thank you [Music]