ZKVM Determinism That Lasts: From Audits to Continuous Verification

Transcript

All right. Uh, thank you all for coming today. I'm Christopher Les. I'm the CTO of Veridise. Uh, we're a web3 security company and today I'm going to be talking about uh, ZKV ZKVM determinism that lasts and how we can go from just audits to continuous and probable uh, security. But before I do that, I want to tell you a story about the life of a Zgate developer up until now. Uh, and spoiler alert, uh, things were a bit chaotic. So, let's first meet the heroine of our story, which is a modern-day ZK developer. And during her quest, she has to write low-level uh, circuits in a very complex uh, system like a ZKVM. She

has to do that in a very low-level uh, language. uh she has to do a lot of optimizations. She has to ensure that everything is secure uh and often she has to do that with little to no uh dev tooling support. Uh I don't know about you, but like I wouldn't want to be in her shoes. And of course, there are no story without uh villains and she has like a lot of them. Uh starting with her uh product manager uh who wants everything uh delivered fast uh secure and let's be honest like you know um she doesn't have like many technical insights. Uh then there is this tool called an auditor. Uh full disclosure I'm uh one of these

creatures. Uh and our job is to find as many bugs as possible uh in a very um limited time manner. And when we are done, we just throw everything back to our heroine. She has to fix everything. Uh this slows down a lot. And because of like you know the complexity of the systems we review and the limited time frame uh we can have kind of like you know uh we can be a big budget line in the item of a of a project. Um but like you know as you already know we are kind of like a necessary component of the industry. Uh however we're not as bad as like you know the real level of our industry which are blackhat hackers which you know the only thing they need is like just a single

vulnerability uh and then like you know they can steal a bunch of funds a bunch of uh funds from the uh protocol and then they can have like very detrimental effects on the future of a uh of a project. Uh so how does the story end for our heroine here? Well, not that great. Um projects get delayed. Um maybe the project will go multiple rounds of auditing. Uh and even after that like you know there is a high probability that the critical uh bug will sneak in into production. Uh and to make matter worse, if like you know the uh team wants to introduce some upgrades into the protocol, the whole expensive cycle uh has to start all over again.

Um but regardless of of all of this, she managed to deliver. Uh so in an essence, he's a superhero. Uh, but I'm here uh to tell you today that life doesn't have to be that way and we want to make uh her life uh way better. Um, and how we're going to do that. So, we're going to introduce the best character in a superhero story uh the humble side geek. So for our heroine like the humble sidekick that we introduced is our tool called pyus which help her uh prove the derminism of her uh circuits. I'm going to go u into detail about like you know what's the

determinism and why that matters but let's see how the site gig helped our developer. So every time she writes a zikk circuit then pyus will check the terminism of the circuits. If everything is fine then okay she can continue on with her day. However, if uh things are not fine um pyus will report like this as a bug then she will fix it and then the same like loop uh will start all over again. Uh so this turns out to like lead to faster development cy uh cycles, reduces bug early on uh simplifies manual auditing later on down the line and generally um having pyos in the uh

project's pipeline gives guarantees that like outlive audits and you know they're continuously enforced through CI/CD. Um and this story doesn't leave only in our imagination. We have applied like this kind of like you know new way of developing ZK circuits and ZKVMs uh during and after our gatesman with risk zero when they came to us to uh audit the circuits of their ZKVM. I'm going to go to more uh details about this uh in a bit but uh first let's see why uh proving uh determinism uh matters.

So first of all let me give you a very quick definition of like what is a determinism in the context of uh zk circuits. So you can think of the ZK circuit as providing an interface to users uh that uh they can use to generate proofs about the execution of a uh of a program. So for example this uh let's take uh this very simple uh circuit API that let a user uh prove their balance. So on a high level you can think of uh this API as having a single input the uh user's address and a single out output uh the balance.

So generally speaking in most cases uh when developers develop uh a circuit their intention is to have a deterministic function from the inputs to the outputs. So for this specific case for every possible address we want at most one balance to be provable. Uh however the problem is that in today's ZK uh development world it's very easy for uh developers to uh essentially introduce relationships uh instead of functions. So here uh a a bug of that sort would allow somebody for the single address to prove uh that it has like you know two balances.

And so imagine an attacker that can prove uh that like you know it has two balances, two balances. Uh bet your money they will choose the bigger one. And usually in this context the bigger one is the the unintentional one because we work in these very large uh prime fields. um and why why this is kind of like you know an important problem to solve. So based on our experience as auditors and uh based on a very recent academic uh study uh these type of bugs are the number uh number one source of bugs uh in in ZK circuits.

They are very complex to find and even when you uh fix uh when you introduce a fix for this uh for these type of bugs, it's again hard to verify that like you know this um uh this kind of like fix actually uh patch the the bug. So we think uh we need something that is like you know automated. So let's go now and see how pyus automatically solves the pro this problem for us.

Um on a high level the API of pyus is as follows. So it uh tries to prove that for every input of your uh sorry for yeah for every input of your uh of your circuit uh you can only uh you know generate proofs that have like a single uh output value and um the result of pyus can be one of the following. Uh it can you know um verify that your circuit is is indeed deterministic in which case everything is fine. it can generate a counter example uh which is going to show you the actual bug. So it's going to show you two witnesses where like you know they have the same input and the outputs uh differ. So you can use that to um uh you can use that to debug your

circuits or it might get stuck and like you know run out of resources in which case it will report unknown. However, in this case, it will provide to the user the progress that it made thus far and then like you know users of Pyus can use that information to refine the input and then use Pyus again. Um this is a very uh high level. Let's go a little bit into more details. So internally Pyus use uses two um two techniques in a synergetic way. uh the first one being a static analysis which is uh cheap but can be a bit imprecise and the second one is SMT solvers which

are uh which provide deeper reasoning but they come with a bit of a premium in runtime execution. So the static analysis phase uh has predetermined uh patterns that can guarantee that an output is deterministic. uh this phase is very uh cheap and efficient uh to run but sometimes you might get stuck sometimes there might be some output that doesn't match uh the predetermined patterns so uh that phase might not be able to make more progress so this is when the SMT solvers uh will pick up uh and they essentially get uh encode the behavior of the circuit as a mathematical formula and then they

generate a they try to disprove it a proof that proves that you know the the output can have like only only one value. Um but like you know if you have ever used like an SMT solver this can be quite expensive and you know you have to uh bound their execution so you can you know you don't have to uh just wait for them indefinitely to to finish. And these two phases will run in a loop. And as they run, they're going to create a a common database a common database of outputs that are currently being proven to be uh deterministic.

So if one gets stuck then the other one which going to generate more outputs that are deterministic and that will lead to you know the other phase to get unstuck and this runs at the loop until you know we run out of outputs to to prove that they're deterministic. So this is a very high level overview of how like you know this the internals of pyus work and of course we have um we have employed like several optimizations on how we construct the SMT formulas to be more optimized uh to how we break out the proof of a large circuit to like you know subroofs uh but I'm not going to bother you with these details uh let's go and see uh how

pyus works in action And uh as I promised earlier uh I'm going to give you a bit more details about the engagement we had with risk zero to u verify determinism of their uh zkm circuits. So initially risk zero came to us to audit their uh circuits and the scope uh included around 120 uh subcircuits. Uh and of course part of the agreement was for us to verify that uh all of these uh subcircuits were uh deterministic and you know also apply all of our other you know um uh tools we have like you

know for for za circuits. So let's see how um how pyus performed. Um so if we counted pyus as a separate auditor in the in the whole process it would have been the top performing one as it found uh nine deter nine nondeterministic circuits and the majority of of these bugs were you know uh critical or high uh and he and Pyus managed to do that uh pretty fast like you know in most uh circuits like you know uh pico is terminated in few seconds and you know it wasn't able to handle like you know at the time only only one circuit.

Uh so let's go and see some of the bugs that Pyus managed to find. Uh the first of these bugs were in this component called expand uh U32 which take two uh inputs uh a 32bit integer and a sign bit and what it tries to do is like decompose this integer into four bytes. So the bug that uh Pyus managed to find is that when sign was zero uh it was possible to create two by decompositions of the of the same integer. So the lower one was like you know the intentional one the one on the top uh which is going to be like you

know a large like number was then intentional. So imagine if um a ZKVM application uh was using that to calculate like a balance of a user like I mentioned earlier. So the attacker would have the ability to kind of like you know create a very large number um given like you know uh the um the nondeterminism back here. Um so the second back sorry yeah okay this the animation was working. So the second bag was in the component called uh do div uh which as it name indicates takes two inputs nominator and denominator and

essentially what it does is finds quotient and remainder and expresses number as you know q times denominator plus the remainder uh and the bug here was that uh the this component internally wasn't constraining the remainder to be less than the denominator. ator and that way you could have two solutions to the equation. So for example you could say uh that like you know number you know two over one uh can be either you know Q2 remainder of zero or Q0 and reminder two. So imagine if like you know this one was calculating you know some rewards of a protocol uh some sorry some fees of a protocol and attacker could kind of like

essentially bypass paying the fees by selecting the solution that says Q to to zero. Um so uh these are the uh these are the bugs that I'm going to discuss today and these are the ones that actually fit in like you know a single slide. Uh but uh Pyus was also able to find like you know way deeper bugs that like you know had both the developers and our auditors kind of like scratching their heads for like hours before they understood what was the actual issue. So it's a very very helpful kind of like companion as people develop uh ZK circuits.

Um so after um the developers uh fixed the the bugs then K pyus came back in and uh gave the stamp of approval for every fix. So we knew that like you know the bugs were were actually fixed and you can find the final audit report uh in that QR code. And um fortunately for us we didn't end up here. So risk zero after the audit um added support into their zero gen Z gen compiler which is the language that they use to write their internal circuits. uh and uh later on when we audited their Ketak accelerator uh we again used Pygus and provide that

the KAC accelerator was uh deterministic and since then their uh their CI/CD uh runs uh Pyus every time they introduce and change uh into their uh into their circuits. Um and uh yeah um as we kept improving like you know picos uh it kept finding more bugs like remember the one circuit we couldn't verify initially we found like you know some uh some issues there and also it was able to find regressions as the as the risk zero developers were like you know um making like changes into their code.

Um so yeah before I leave you uh these are were all the details I had to say about like you know the engagement with zero and how like you know Pyus words uh works internally. Uh I want to uh plug for a few seconds another initiative we have uh to broaden the applicability of uh uh of Pyus and this is the introduction of a new uh intermediate representation language called LLCK and this has been recently funded by the Ethereum Foundation and the goal of this initiative is to kind of like you know unify ZK development because uh as you might already know it's kind of like a

bit fragmented because there are like you know so many uh different languages and embedded DSLs you can use to write circuits uh and this initiative tries to kind of like you know create a common IR where people can write their own analysis transformation passes write their own back ends and also uh that's where we come in and build like you know uh security tooling on top of this IR so if you lower to that IR uh you can run pyos you can run our static analyzers and you get all the uh benefits. So that's all I had for you today. Uh thank you so much for watching and also thanks to Risk Zero and Ethereum Foundation for all their support.

[Applause] Cool. Awesome. We have a couple minutes for questions if anybody. Hi. Um so you mentioned in the last slide that you're uh considering to add in support for PL3. How how ready is that? How are you how advanced are you on that path? Uh so yeah, we do have like a prototype um um like already working and we're like currently working uh with succinct to like you know do the same kind of like exercise and they're using plugin 3. So you know as as we speak we kind of like you know add more and more support. Okay.

So like yeah if anybody's interested we have a booth downstairs like you know come talk to us and like you know I'll give you even more details. Yeah. Hi thanks for the talk. Uh a more basic question. How did you guys ended up going for the verification of these like ZK circuits and ZKVMs? Was it like a company in this domain that approached you guys or did you guys see it coming and then went for it? Yeah. Uh so yeah we like I mean like you know we are an auditing firm so like you know we want to find like you know bugs or like you know verify their absence like you know as as fast as possible and uh like few years ago we entered the ZK space and

then we started like you know looking kind of like you know what are the most common bugs there and like you know these type of bugs were popping up like you know even even back then. Uh then you know we we did like some research we um published like you know the initial version of Pyus and afterwards like you know like as we get more clients we saw that like you know this this is kind of like a real issue. So we kept like you know working like you know kept improving like bikers. I'm sorry time is over. We can have more question. Thank you. Thank you.

[Applause]