# What don't we know? Understanding Security Vulnerabilities in SNARKs | Devcon SEA

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-07
- Duration: 25:41
- Watch: https://streameth.org/watch/yt-njXVouCOBQY
- YouTube: https://www.youtube.com/watch?v=njXVouCOBQY

## Description

Zero-knowledge proofs (ZKPs) have evolved from being a theoretical concept providing privacy and verifiability to having practical, real-world implementations, with SNARKs (Succinct Non-Interactive Argument of Knowledge) emerging as one of the most significant innovations. Prior work has mainly focused on designing more efficient SNARK systems and providing security proofs for them. Many think of SNARKs as "just math," implying that what is proven to be correct and secure is correct in practice.

Speaker(s): Stefanos Chaliasos
Skill level: Intermediate
Track: Security
Keywords: Security

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum, https://warpcast.com/devcon
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon SEA was held in Bangkok, Thailand on Nov 12 - Nov 15, 2024.
Devcon is organized and presented by the Ethereum Foundation. To find out more, please visit https://ethereum.foundation/

## Transcript

[Music] hello thanks for the introduction so today I'm going to talk about uh vulnerabilities mainly in the implementation of uh uh snarks or ZK snarks and also on what can go wrong when we deploy snarks in production uh this is a joint work with collaborators from TM the theum Foundation ZK security the scroll foundation and also Imperial College London okay so let's start um okay what is the state of uh zkp applications uh today we have ZK rollups that have become uh very popular in the last two years they have more than 5 billion USD in uh tvl in them uh we have Zas which is a payment system system it was deployed I think the ver version around 2015 2016 we have many ZK applications both for infrastructure such as ZK Bridges but also for private payments for um using wallets without having to use S phrases like ZK login we have private programmable l1s and l2s like Mina Alo azdc and also we have some of chain applications and although all of those systems have been deployed we haven't seen any major exploits like uh the Dow exploit we had in smart contracts and although we haven't seen any exploit there have been bugs in systems deployed uh in production so zikas had a vulnerability sorry for the pictures might be a bit small but I will go through through them so zikas had the vulnerability for I think more than a year in it um people from within the zikas found it and ped it uh then one of the most popular mixers had a vulnerability that if someone exploited uh it could have basically drained the smart contracts of that protocol one of the most popular zik rollups had the major vulnerability that someone could again potentially could have exploited and get everything out of that rollup and also I would say that uh in audits in z protocols even in topnotch protocols if you compare it with top notot uh smart contract protocols the ratio of critical vulnerabilities it's even higher so there are many vulnerabilities and people for many years suggested that zps are very difficult and very hard and not many people uh actually understand them and also they have suggested that to exploit a ZK protocol it's much more difficult to exploit for example is smk contract uh vulnerability I would say the first one is not true anymore right because if you see the number of presentations in ZK in Devcon this year and compared with three years ago we have an exponential increase and also although it might be true that some ZK vulnerabilities is difficult to exploit I would say that some of them are pretty simple and for example here we have a circum circuit it's uh a very old circuit but this anyone who has written a circum circuit could probably understand what's going on here and still there are such vulnerabilities in Z protocols that I think are pretty easy to exploit so there is a huge risk uh if there are still vulnerabilities in deployed protocols to be able to exploit them at some point okay so uh let's start with uh explaining what are the properties of a ZK protocol right we have knowledge sness which M basically means that a dishonest Trover cannot convince a verifier of an invalid statement except with a negligible probability we have perfect completeness which means that if you have a valid statement an approver will always be able to convince H an honest verifier of the correctness of that statement and also we have zero knowledge which means that the proof pass that we produce with a zero knowledge proof does not reveal anything about the weakness we are uh proving so what is our thread model in uh uh ZK uh word right we have three adversaries we have the network adversary who observe the system and its public values but cannot interact with the system we have the adversarial user which basically is able to submit some inputs for proof generation in a nonest and non malicious prover and finally we have the adversary approver which is the most common uh thread model and it's our thread model when we actually need the ZK property right but I would argue that even if we don't need it if we want to have a fully permissionless system then that's the addresser we have and has the ability to produce proofs and has the ability basically to do everything to try to trick the verifier uh to give you an example of what I mean with the second category because it might be a bit confusing consider ZK rollups at the moment right where we have a single centralized trusted um L2 node that is both the sequencer and the prover so users can only submit the transactions there and then that centralized node will produce a proof so in that case we have an adversarial user basically and and what can be the impact of a vulnerabilities so we might be able to try to break soundness which means that aover can convince a verifier of a false statement and that could result in basically for example in Zig rollup to get all the funds out of it we can break completeness which means that a verifier cannot verify proofs or basically that reprover might generate invalid proofs right and for example such a vulnerability uh could basically have a high impact in the liveness of Zur olabs and we might also break zero knowledge which means we have some information leakage um okay so what we did is we analyzed 141 uh bugs and vulnerabilities from audit reports for from vulnerability disclosures and from backt trackers and our goal was to split those vulnerabilities in layers and understand what can go wrong in each layer and also create a taxonomy of vulnerabilities so let's start with that figure so in the real work non snar work we'll have a relation a specification some idea that we want to actually create a zkp about it and we might have some public and private inputs so the first uh step is to manually encode that specification that idea in a circuit and get the circuit implementation so we figure out that in that level it's where most of the level vulnerabilities happen and the main reason in our understanding is because it's confusing for most developers to write circuits because they have to be to think both about computation and also about constraints and they might do a very aggressive optimizations there and they might try to apply some trigs and that typically leads to vulnerabilities so we identified three main vulnerabilities under constraint vulnerabilities which means that uh you forgot some constrains or some of your variables are partially constrained we might have and that typically leads to soundness vulnerabilities which is the worst vulnerability can happen in Z in the Z system then we have over constraint vulnerabilities which is the exact opposite that most typically will lead to completeness issues and we also have comput or hint errors which is on just on the computation part and accordingly you might have messed up constraints but the root cause was in the computation part um so we did a complete root cause analysis and I will share with you uh a QR code for our paper to look into examples and to look on how you can fix some of those vulnerabilities Etc but very briefly here we have categorized them in three main root cause classes first is that in When developing circuits we have a different programming model and that could lead to many vulnerabilities secondly we observed that the root cause of vulnerabilities were optimizations and also having cryptography at the outer layer and in very uh lowlevel dsls that could introduce many vulnerabilities and also common errors like in any software uh like uh specification issues or API misuses Etc so the next layer is uh the front end uh which is basically composed from uh two components a compiler and a witness generator the compiler will take the circuit and will try to produce an intermediate representation that it's on what our proof system works on top for example R1 Cs and then witness gener generator will take the circuit will take the public and the private variables we have and it will produce a witness and the next one is a backend the backend is composed of three main functions setup proving and uh verification and things can go wrong in all those functions so the vulnerabilities we identified here in the front end is incorrect constraint compilation and errors in witness generation and in the previous presentation we saw how things can go bad uh there and it's very critical to actually trust and be able to H have um correct implementations of front ends and in the back end the situation is quite similar um we from our data we found out that UNS safe verifier it's a very common issue and can lead to Major vulnerabilities um and let's go to the next one the next one and the last one is the integration layer which is basically you can think of it in the blockchain space as the JavaScript that is responsible to run your prover client side and create a proof and also the smart contract that um consumes that uh proof and calls the verifier you have implemented or it was produced automatically and try to do some things and we have some very interesting vulnerabilities in uh that layer I want to focus in the first one which is passing unchecked data uh and what does that mean sometimes as already H said we might try to do some optimizations in the circuits and for example one thing that it's pretty common is for people to say okay uh in that circuit let's have some implicit assumptions that our inputs are in a specific range and then the delegate that check to the actual code that will call the verifier so in that example we forgot we forgot to do H such a check and that could lead to Major vulnerabilities then in our infrastructure and uh in the last uh year or so there has been a major change in some architectures where instead of circuits we have zvm circuits right so the developers now only care about writing some program typical in a high level language like rust and then compile that program and uh giving it as an input to zvm still circuit bugs can happen in the zvm itself and I would say a suppled uh new thread here is traditional compilation errors that might happen to the rust compiler for example that that could lead to have invalid proofs so that's something that people should take into consideration when using uh zvm Souls so another way to see what we currently uh described is in a hierarchal uh way and here I have an example of all the stack uh when we use uh the programming languages and snack J with growth 16 Azure proof system I have two new layers here one is fil arithmetic elliptic ear which have nothing nothing to do with ZK but when we construct and Implement um a proof system we have to have such a very efficient library and things can go wrong there and also things can go wrong in the hardware in the operating system in the blockchain we are using right so you should always um be very uh basically think about what you're are going to use and apply all traditional best security practices we know from other fields and one last thing is that in the proof system there could be errors there that could be errors in the initial description in the papers of proof systems so if something goes wrong there it doesn't matter if you have formally verified uh circum circuits if you have the best back end or front end it could be exploitable and that basically it's true for any layer so if your front end or the back end it's uh vulnerable then even if you have formally verify uh your circuits they could be exploitable okay uh so we did that analysis and now I want to present some of the results uh so we categorize the bugs in uh all those layers and also based on their impacts and we can see that circuits was uh the number one uh threat in the whole infrastructure of using uh zkps and also most of the vulnerabilities are res can result in soundness issues so what can we do uh fortunately there has been like a lot of development and a lot of research of uh creating uh security tools for ZK circuits for specifically for ZK VMS or ZK EVMS and also in the last month two new papers were published and tools circus which was presented in the previous um talk and also MTZ K which is great because such novel tools can detect infrastructure bugs uh in circuits in uh zkps but I would say there are still still a lot of work that needs to be done uh for example most of the circuit tools they target a specific DSL and also they typically Target a specific uh vulnerability class and then we have uh some tools like static analys tools like circum spect which might have tons of U false positives and then we have some really nice tools and very novel tools like pus that try to formally verify and find any under constraint issues in the circuits but unfort fortunately uh th those tools do not scale that well uh so there's a lot of uh space to do to have Innovation uh and try to build better tools and uh here I have a list of um security tools you can scar that QR code and it's basically GitHub repository if I don't have any of the tools that you are know of please add them and yeah we need to do a better job here and one also major issue I see in the space is that we don't have good uh tools for writing tests and most of the code base that us your knowledge proes are unfortunately not that uh good in having like a complete test Suites and try to to understand in the testing uh part both uh soundness and completeness issues okay so in conclusion why do we have bugs well one of the reasons is that because zkps are not just mods there are implementations and many things can go wrong in those implementations uh why else H this is a quote from Ron rivest in a completely uh different context but I really like it and I would say that in the ZK space unfortunately we have give to the poor developer uh enough rope with which to hun himself circuit languages are are typically very low level so they don't have good abstractions for developers to write U uh safe code uh we expose a lot of cryptography to the outo layers and also there is a lot of complexity and a different uh threat model than what uh developers are used to and there is a lack of specification throughout um the whole uh uh infrastructure and the whole stack for using zkps so we need to write more specifications so what can we do basically we have to negate everything from the previous slide we need more learning resources which I think we are doing a great job in that as a community uh we need to write specifications and get used to write specifications because uh if we have complete specification then we know exactly what checks we should put uh in each uh layer and what vulnerabilities can happen in each layer and that's how we can help developers but also Auditors into doing a better uh job in trying to find vulnerabilities uh in those systems we need easier and more secure programming languages which I think it's kind of where we are heading to uh for example Noir is a is a great language that it's much more safer than writing uh circuits in ccom or hello2 but in some cases people will still need to write circuits in hello2 or ccom because they need to do some specific optimizations or they need to deploy to specific uh uh blockchains for example and then we need the better testing and security tooling from simple Frameworks to write unit test to do property based testing to formal verification and not just formal verification uh so that's it I have there a link with our paper where you can find many examples and how to try to avoid some of those pitfalls and we also have a blog post that uh uh we uh publish many blogs about uh ZK Security in general so thanks a lot thank you Stefanos this was enlightening um all right people as usual you can ask your questions here we're going to go through them in order and let's take the first one several times in your slides you refer to Witnesses what are witnesses are those private inputs uh so a witness I would say it's composed from both the private inputs the public inputs and all the intermediate steps and the outputs for our circuit so I will say it's a a trace that then we create a proof about that Trace thank you all right all right next next question I've put a bunch of those so do ask serious questions please we have a bit of time what is your favorite bug ever what is the most interesting bug you've ever found H that's a very good question I think I can't pick one uh but I would say typically the simple bugs right uh for example the bug I have in one of the first lights that could have lead to basically draining uh one of the major mixers we have in the space um but also bugs that have to do with using cryptography in the circuits and typically due to some optimizations or some logic errors in those circuits there could be like pretty interesting exploits that someone can do pretty cool thank you all right the next one you're doing research looking for bugs you're paying your bills and buying your Foods by finding bugs can we consider you have a bug based diet we can consider that yeah definitely I hope that in some future world there won't be that many bugs and maybe I will have a better diet but unfortunately at the moment we have tons of bugs fantastic thank you what are your thoughts on T okay that's the question of Dev conal everyone asking that question uh I would say it's a different you have different security assumptions when you use tees right it's I think it can work a along with the GPS but they can't replace GPS H you have a much weaker uh thread model when you are working with tees so yeah people should use them when they have to use them but also don't trust them like a black box that will do everything for you and you are secure if you use a te wonderful thank you um what can we do to make more secure languages like Noir faster compared to circum particularly with respect to gas cost how do we make more how do we make it more efficient SO gas cost I have I will say that it's uh independent kind of of uh what programming language you you're using it's more about like what proof system you are using right and if that proof system is has very efficient verification that's the main factor but also more General in the circuit uh layer um I would say that indeed someone if you don't like really use unsafe inir which then breaks the whole purpose of using Noir um you can write more optimized ciruits at that point in circum but I would hope that we will have uh uh major advances in compilers for zkps and then we can have like compiler optimizations that very strong like in any other field and uh rely on those optimizations to get like pretty optimized uh circuits but if we do that then we need very very solid uh testing for our compilers to detect any issues in those optimizations thank you you mentioned in your slide that you know sometimes we give too much rope to the users to angang themselves with I think the design in ZK circuits is difficult but also using them is not very common place right a lot of users are not used to using this kind of systems and what goes in what goes out what you can do with them what can be what is safe Behavior to do that you mentioned learning resources do you think there's something to do with users also to explain to them what are the benefits and what should be done or is it entirely on the app developer yeah yeah that's a great question I think as researchers it's our responsibility uh to create uh learning resources that are easy to follow by almost everyone uh so I think we are doing kind of a good job there uh for example at ziki security we published a book on hello 2 and basically many teams in that space develop a pretty nice learning resources and what I really like is that they also have a section about security vulnerabilities and what you should look at when you use a specific DSL so yeah I think we are doing a great job on that and in the few years it will be even better fantastic stanos thank you we're over time uh so thank you for your talk thank you thanks a lot