ZK11: Insights from and on Taxonomy of ZKP Vulnerabilities - Gyumin Roh

Transcript

[Music] I I think this is the strongest audience I've given a talk to so it's pretty nervous but anyways thank you so much for coming to my talk uh my talk is about skap security but uh to be more detailed we're going to try to gather some insights from it and we're also going to try to get some insights on the tax give abilities so we're going to discuss about like why of certain bugs happen and we will um it will turn out that the main reason for why all these books happen is that the circuit Pur we're thinking about the circuit side uh

the reason for a lot of these bgs are that uh when you're implementing the circuit the the language you're you're interacting with uh exposes a lots of lot of cryptography to the surface level and because that cryptography is quotequote new to the uh people who are just used to in usual quotequote usual applications so this new uh cryptography the addition of this new cryptography leads to uh certain classes of bugs and we'll like discuss how uh each uh part of this new cryptography leads to a certain p and so on so so before we like get into like the major points uh I want to like go through the brief history of how we we we became to

understand the B classes so as for me like this is more of a personal story rather bit of history but anyways uh my understanding of like this entire SK B Class stack is back at back when uh September back at September 2022 this was when uh zerx Park very cool people by the way uh Zer Park's uh ZK Security Group kind of kicked off and they tried to do a lot of different things and one of the things they tried to do was Kyle uh at PSC I believe uh wrote the like first draft of the now very popular zkb tracker repos story on Zer Parts gith repo uh and as you can see here I helped them review the thing was which was

pretty cool like it was the very early days like 2 years ago uh so the results from that uh initial draft of the CK bu tracker was looking something like this so you have some like so here like you have some like good initial like bug classes so you have some you know classic stuff like under conin circuits like overflows and underflows B lengths uh and also some more cryptography bugs like uh in BR 16 uh if you like just forget to add a dumy constraint it can get optimized out and you have malleability issues so those bugs are there and also some more cryp cryptographic bugs like frozen heart and

like some Weir we things happening trust the setup so overall like this is very still raw but the like the basic ideas of like what types of books there are are um already developed so that's pretty nice and later uh and later when I studied um a video in ZK Study Club by JP uh there was like this very nice slide from The Talk this is back in April 2022 uh so what this uh what this slide does is that it breaks down the entire zkp like de development stack into layers so you have a computation you want to like in zp you want to like prove that you've done you've done a computation correctly right so you have a computation then you

turn that computation into a circuit and you to you know to turn that computation into a circuit you fit it into a specific Ortiz that could be like cross like or CS or blish or whatever and then you do some magic to make into an non proof and then you use that you know prover verifier system and you shove it into a you know into your application so that it inter it integrates everything so like so because like we can like uh take layers like make make the entire Z development St into layers what you can also do is that you can apply this kind of idea into vulnerability finding so each of these uh each of these layers

have their own possible ways or you know how can happen so so some initial like layering ideas emerge and later uh June of last year I gave a talk on etherum Soul uh basically the idea was that this is this is this idea is also prominent in my talk right now but the main idea is that the reason for why the circuit bugs happen is so like the reason why circuit bugs happen is because let's say you working on Halo 2 uh the reason why Halo 2 when you're writing a h circuit the reason why these bugs happen usually is either that you made a mistake that that you would made uh even if it was not ZK so like if it's application like

like specification bug you would made you would have made the same mistake whatever or not you like developing an AC circuit or or your like smart contract inity or whatever uh but more more does it keep you like specialized bugs happen because like you have to fit everything in a like targeted aromatization so let's say plish so because you have to like encode everything encode every every part of your into pish uh there are specific uh like what's the word like uh intricacies of plish that make it difficult to like encode your computation into plish correctly and so what so my idea at the time was that you

could take some properties of plish for example any any like friendly automatization you can take funish and expect what what properties this plish oration have and from that you can actually just recover a potential vulnerability class so for example like very easy one is that clish works over a prime field FP and because we were working in FP uh well obviously like everything wraps up mod mod P so like all over fs and wonderfoods happen because of it and uh and and so on so that was my like main idea ofing Soul uh talk and then uh some big work has been come up recently on March uh this year's

March and there was like this big paper by like six great people uh on their our overall you know understanding of zkp vulnerabilities so they did a lot of things they surveyed like current toolings and such they surveyed lots of AUD reports that are public they went through all the bugs and they like classified like which BG you know this BG you know corresponds to this class and so on and also another big thing that they did is uh this this figure is taken from the paper another big thing that they did is similar to the this slide what they did was they like they broke down the stack into four layers so

there is the circuit layer where you encode your computation to Circuit there's the front enday layer which uh handles the witness generation and like the whole compilation into like the constraints and there's the backend layer which does the trusted setup if you need if you need one there's the whole proving there's the whole verifying that's all done in the backend layer and finally there's the integration layer where you take this uh system and you know put it into the application to make everything work out so a very good layering done here uh and while while the work uh done by you know the the paper I I'll call it the paper

the G paper is pretty great I think there are some challenges that we still need to resolve uh one is that we still need some better classification for the circuit layer issues uh because circuit layer uh audits are pretty dominant pretty dominant in the auditing scene right now and we also need like more data set and work on the front end and back end but this isn't really like uh like the paper author SP like this the reason why there's like not a lot of data set in these two layers is that there hasn't been that many audits in these two lers they are pretty rare if you like go around and search for a like cqp audit report it's most likely going to be about circuits in the circuit later so like it is what it is so but

it's it's unfortunate but it still is a challenge but I think the main uh challenge that we still have to like solve is that we really need more insights from these surveys and by insights I I mean like so you collect all these like you know vulnerabilities and vulnerability types and you kind of want want to like get a conclusion from conclusion from them that that can like directly uh help the zkp like over overall security of the zkp landscape and I think like there has not been that much work to like extract some good insights from these like uh surveys so that's the goal today uh so like the ultimate goal on like why we work on this taxonomy or bug

class or like you know reading all the all the reports is that we we do this to improve the Z security and I think the biggest uh challenge right now in Z security is that we need more Auditors uh obviously in more M mature places like smart contract security we we still uh need more more senior Auditors we we everyone complains that we need more senior Auditors and that's very true uh but I think in in zik security uh even for junior level Auditors there's a shortage of it uh and I think that's a problem like you need J you need Junior Auditors and then those Junior Auditors become senior Auditors by you know more experience than more studying so I think we just

need more people in general and uh so to all more more people I think that these surveys all about like bu classes should provide insights to like lower the barrer for zkp security entry uh zkp already is a pretty uh you know has a high entry barrier uh regarding you know math and such so I think uh Z security also has you know these barriers and I think I believe that these surveys should aim to lower this barrier so the game plan is that as mentioned before the big difference between the usual let's just say that um our Target is smart contract security people who are very strong in their their field and we want to convince them to join Z

security uh because there there is some still like very similar context um so let's say that uh in that case the new like factors that you know these people these like strong aers in in the blockchain scene need to like get get get accustomed to is the quotequote cryptography exposed to the surface layer of what you're auditing and uh you can just focus on this set and you you can focus on how to like explain this like cleanly and like without having such a big hurdle uh uh you know you don't want to like make it sound too hard uh harder than it it already is so so what we can do is that we can just focus on this set and how to

explain it to onward strong web series security researchers top uh so like unfocusing on this set leads to following questions when we're all only like talking about circuit layer and the integration layer because front end and back end obviously requires very heavy math it's it is like defined to be heavy math so it's obviously like doing security work on those layers will need math but when we all uh when we're just talking about the circuit layer and the aritic uh circuit layer and the uh integration layer uh these two questions are sufficient to onward uh new security researchers so point one for the circuit layer is that in circuit layer you are you're given an

a computation you you want to encode it into a circuit right so the main question is that so if you are uh developer uh if and and you have a good uh sense of what kind of comp you want to like encode into a circuit then the mistakes you make will be derived from the factors of pish or whatever or or whatever that makes like encoding the encoding the compostition of circuit hard right so you can ask this question uh extract different kinds of factors of the aration and then recover uh some points that you uh you may make a mistake and like and then these

ideas will be like directly connected to the the vulner that can find as uh and for the integration layer the main question would be like how one should like view these dkp systems as like boxes because integration layer is mostly about purely integration you you assume that the zkp system itself is fine but you integrate it wrong and uh and a happens so for integration layer uh the the second question below would be sufficient to uh you know get a hand of it and of course like since we have like as mentioned before layering has been uh pretty important in our understanding of uh SKF security and the main the main

reason why like this is very important is that it allows to like separate separate it and then like attack it one at a time so we should definitely utilize it um so like because later is possible we don't have to like worry about like the witnesses being interpolated into polinomial and committed into like a polinomial commitment uh we don't have to worry about it because those are in a separate layer so we do need to like uh utilize this as hard as we can to like uh to separate uh different kinds of audits that are out there and allocate each audits to uh people you know Auditors that are

most so main computer vision here is that a uh this line of thinking will give a very natural way to understand the bug classes that are out there so you don't need to like read all the othero reports to like recover this line of all classes that's that's the one one thing and the second thing second major thing is that um I'll will be try to I'll try to discuss about the additional mathematical prerequisites for Auditors that are already strong on the the smart contracts or other blockchain related uh environment uh and and finally and this this line of this line of you know thinking will also give a relationship between the zkp

development metag game and what what prerequisites the Auditors mov so basically the reason why the third third entry here the fourth entry here is possible is that uh for example if you have it's a it's a spoiler but anyways uh if you have a very strong general purpose of the km then you will be writing code instead of circuits and because you you're allowed to just write code and then you'll be just able to compile into a circuit uh now that developers are writing code the code on code cryptography exposed to the surface later becomes zero so the auditor who's also like reviewing the code itself doesn't really have to care because the cryptography exposed service is also zero so that makes GTP security work a

little bit differently than what it is right now so that's the main point of the for line here so so let's like talk about like what properties are are there for like the plish that leads to like these kinds of bugs so anyways so of course like the circuit layer's point is to like turn a confutation to circuit and the system should be SEC friendly uh okay so like this is pretty much taken from the itum soul talk so I'll be very brief so basically uh there is a line of bug class that's called assign not constraint so what this bug what this bug is about is that you like compute some witness off circuit and then you just assign it to the witness board uh

but you forget you forgot to constrain it afterwards by some some like implicit way so for example like if you are trying to do a division uh like Division and get a quotient and remainder uh doing it directly in a circuit is very hard because you know the Plage doesn't support it so what you really what you usually do is you just compute the qu and the remainder of circuit and then just constrain that a is BQ plus r and r the remainder R is you know less than the B uh and you just do it that way so the reason why you have to do you have to go around like this is that you can't just straight up divide in the plish so this is the reason why a limited set of constraints in

plish kind of kind of leads to this bu class called assign constraint so Sim so similarly uh in a lot of circuits and a lot of chips what what happens is that they assume that a certain constraint has been already placed beforehand even though that that constraint is not very expensive when we're just talking in native land uh because the constraints are expensive in zkp land so for example like if I have a input that's like constrained to be between like 0 and 2 the^ of n those checks are very easy in Native you native our you know machine but it's very hard to do it in zp because we have to bid you have to decompose it into bits and do all that so this is why like many

circuits assume that these kind of checks has been done but sometimes people forget that these like these assumptions exist and uh use the library in a very wrong way and that leads to a very prominent bug class if you like really look at the circuits and audit them uh called assumptions handling this is also in the S paper uh so in a way you can you can say that the reason uh you can say that that constraints being very expensive like even the most simple simplest constraints and most common constraints being very expensive Le to this kind of this kind of issue and and so on for others like I already mentioned about like the usage of FP leading to overflows and underflows and so on so you can actually like do like this you know PL plish SL

you know aration is like some kind of some property to a b class kind of like pipeline uh as shown in this this slide right here uh and some more additional book class these these book classes are in the paper but I do believe that as as I mentioned before I do believe that some additional like uh work on all classes can be done uh like in on top of the S so paper and it's these three uh I'll be listing here uh one class that they didn't mention they don't mention is that there are uh cryptography tricks used inside uh circuits to in order to optimize it and

those tricks can be used incorrectly because obviously those are very non-al so I I can I can call this like set of bugs as incorrect incorrect tricks and there's uh also like this one is in the uh zelic zelix blog regarding zipy security uh because the pish aromatization has like a fix with this board like it has a fixed it has a fixed number of rows and columns and like the the constraints being applied on them are fixed because you have to like you know compile them and you do what do what Clan does for example uh plish does in for example uh it makes it this makes it very difficult for one to handle like variable length object the usual usually

what one has to do is that you have to like assign a fixed maximum number of length of you know variables and have a separate variable for its actual length and handle it that way uh and it becomes very like weird uh weird to handle like easy to make mistakes so there's that and also like the wholey for plish uh kind of makes it like the main idea of pish kind of makes our constraints to be of of a like of two forms one is for boundaries and one is for transitions like for example in many like Hal to or punkish constraint systems we either have have a constraint that deals with a

single row or two cons rows two consecutive rows and uh and programming in this way does lead to uh several types of mistakes one most prominent that I'll be discussing later so there's like more pipelines in this fashion can be done if you just try to connect the usual programming patterns inside uh blanish and the B classes that are apparent uh and So speaking of like protography tricks there's a lot lot different kinds of them uh one is lookups there's Dynamic lookups there's Vector lookups uh you know used with r RLC and there's also F Shamir F shammer can be used f shammer is also used in the back end when you're like doing the

whole entire proving and verifying but it's it can be also used within the circuit by for example if you're on Halo 2 there is this thing called phases so you have like first phase things and then after you write all the witnesses for the first phas you can do a f are there and then that Randomness can be used to uh generate Witnesses for the second phase things and so on uh in order to like optimize your circuits and there's also this relatively new technique called not really not really new but relatively new technique called offline memory checking which can be used to simulate like Memories in circuits that's pretty cool and also in general in a lot of different uh a lot of different circuits some mathy tricks are used for example if you're if you're trying to implement an emulate field or

multiplexors or whatever some mathematical tricks will be used and uh and for variable length objects as I mentioned before they us usually fixed maximum length array and a separate variable for its length and uh there's like two ways this could wrong this could go wrong one is if you have if you check like equivalence of two different things by using a random linear combination uh one could pad the this string with prefix or like depending on like where how you you know accumulate stuff uh you could use prefix or suffix zeros so that two different things uh uh two different things accumulate to the

same RLC so like they're considered the same even though they're different uh and another very uh dangerous thing that that could happen is that sometimes you will like allocate a fixed column uh but it it it's not going to be fixed in practice because like the the indexes of the you know the entries of the fixed column is dependent on the like the variable length object so sometimes handling variable length objects incorrect could lead to like fixed column not being fixed like not being equal for like different instances and this is and this is one of the bugs we have found in like actual audits this this type of bug yeah so there's that and uh another very common type of bug is I this slide is reused

that's how common this is but uh in a lot of uh constraints you kind of accumulate something over multiple rows and in many times uh uh they forget to handle either the first or the last row maybe sometimes they forget to like handle the final rows next row and something like that they like a lot of weird stuff can happen for example you can uh take the very first row and consider the previous uh previous offset of it and things go very weird uh so in general like handling the first and last rules are very important and this is something that's easy to miss because you know the way you write

constraints uh you have to like make two different kinds of constraints and it's all very easy to forget about one so in in in usual uh cases uh people forget to like handle the boundary constraints so right now in this example the constraint that's missing is that on the first row the value and the accumulator has to be the same uh with only like the constraint in in the in the bottom uh you could have accumulator being six 68 and 687 and that's obviously not we want not not what we want so there is that uh and for the integration layer uh as I mentioned before for for the integration layer we could just uh handle everything by wondering about how

we can uh view the CP system as a blackbox so what we can do is that we can just blackbox it as like a user have a public input and a secret and they and approve a computer winess and approve and then the verifier checks uh the proof with the public input and this will because we're now in the integration layer we can we can just assume that the the circuit encodes the function you want to do correctly so you can just you can just say that uh the verifier check will uh verify this computation F instead of the circuit C so here we see that the main characters is the function f the computation F the public input X Puff the private value wpr and the proof is p so by viewing

each one of them because these four are the main characters that are like exposed to at the surface level uh you can go go through these thing go through this these objects one by one and try to like extract uh what kinds of books that that could happen so for example uh say that you are wondering about like the function f here uh because we are in the we are in the integration layer F and the circuit are the same thing now uh the the main reason for vulnerabilties in this slide is that the verifier will probably do the verification of f the the the correct competition of F and it the verifier will do some some stuff some additional stuff right but these two combine might

not be sufficient to constrain whatever you know application Behavior you wanted to you know constrain so this is more of a specification issue than anything else and this is what you know this is what smart contract security people will be very good at uh like even without you know additional training so that's good for them so it's it's good that you know uh these people can just join in and help out in these kinds of vulnerabilities uh for xov uh this is the usual like constrainted to be less than P type of bug here uh the reason why the reason why the bugs happen here is that the public inputs are supposed to connect the zkp world and the verifier world like let's say it's on elong or something uh then it's

going to connect the zkp world and the L1 world but the native type for zkp uh is the prime ffp uh so unless you're on B it's not going to be 2 256 uh but on the L one it's probably going to be un 256 especially when you're just considering p is to 56 bits but the problem is that of course XX plus p is different in unit to 56 but they are equal in FP so there's like different types happening and this type mismatch is what H what causes these these Puffs so a solution as we all know is we we force x on the L1 to be between zero and P so that we force the two types to be FP like instead of FP you to 56 we force it to be FP

FP so this kind of deals so if if you handle the this type mismatch correctly then the xub in the zkp world and the xub in the verifier world is exactly the same so unless you're doing something weird that's probably in something weird that's probably going to be in this F land uh everything is going to be fine so we can just Abra abstract everything away and just consider it safe and for uh and for w PR uh the main main task for w PR is it's secrecy that's question I'm actually not sure like but I do believe that this

especially for this uh this is an area that like uh tooling can definitely help because it's so clear what you need to do um yeah so I think tooling can be definitely made I'm not sure if it exists right now but it it can definitely be made I I hope somebody can I I aces are very but have to the Des are yeah yeah yeah if there's if there's a tooling that'll be great yeah I do agree to be honest I'm not very

knowledgeable on Tooling in general in regarding Z security so I I hope there is one yeah uh and for w priv the leakage of this secret value is the most important part but this is usually stemed from a design issue which is something that you know uh blockchain security people infra security people are already already cre that so there's that and for finally the proof itself uh the main idea regarding the proof uh main attack idea regarding the proof is usually malleability sl/ front running so the main idea here is that let's just say that in in layer one there is this function uh that takes some some I don't know Behavior t uh probably input X Po and approve pi and what it does is that

it verifies pi and then performs the action t uh so what what could happen is that if an honest person like sub misss FTX power Pi the uh front runner can read the pro PI from a mol and then just copy it and then just send ft Prime so different Behavior but with the same public input and uh Pro PI right so this causes the layer one thingy to do T Prime instead of T which is very bad and our usual defenses include just adding t to the public input to stop M issues so uh so this is the most classical ideas of uh using proof using proofs to attack the system and these conclude like the four

main characters of the integration later and these are pretty much all the B I think that all like the main ideas of all B so found so far regarding like uh zp security so so now that we're done with like extracting all the like uh B classes we can like now talk about the prerequisites the mathematical ones for uh C security Auditors so we're we'll we'll continue to focus on the circular layer and the integration layer so what you'll need is that obviously you'll need a very high high level understanding of like like a high level understanding of Z kpn's properties you will have to understand the arithmetization you working on very deeply you'll have to understand the

field obviously because that tied to the arithmetization uh very deeply um well but you will you won't have to understand understand how the piop and the PCP works so you will have to deal with the like interpolation Computing the proofs po the commitment all that you you won't really need to like deal with them when you're just working on a circuit layer and because as I mentioned there are some cryptographic tricks being used uh and those are exposed to surface level like for example like phases and such uh you would need to have a good command of them and if your uh if your constraint system uh makes use of the mathematical tricks you would have definitely have to have a good

understanding of it and also as as mentioned there are some malleability attacks that are possible so you would have to like know this as well but the problem is that of course like these four things uh practically represent the set I mentioned before these four the auditor needs to know these things because these four things are the cryptography that's exposed to you at the surface level right so of course since everything is exposed to the surface you have the auditor has to like understand everything right but the problem uh but the interesting thing is that while these like cryptography that are at the surface level are hard and difficult to grasp like completely they have relatively simple conclusions and

quote unquote apis that one can just just uh just take it for granted and it will also like it will make the auditing experience more or less the same so I'll I'll be explaining that later so so these conclusions can be like just T taken for granted and be used as a black boox and we can actually like do some additional layering inside the circuit developing experience to like uh make more blackboxes available for for the Auditors or developers so uh using this using these correctly uh yeah using these like techniques and blackboxes correctly will be will help in reducing the workload regarding like

mathematical protocol for the Auditors so by this I'll like explain the like the main ideas so for example let's just talk about the meability stuff right obviously like the the idea uh and like the cryptographic idea behind the meability of text are like very non-trivial but but the interesting thing interesting thing is that the most of the work is done already by cryptographers and we can just use their results for example uh for example if you're working on Kg based stuff like plk uh they are proven to be simulation extractable Al they are proven to be noral uh this is done in the print paper here and this was also talked in ZK Summit 99 I believe so if

you're working on PL you don't need to really worry about like M ability attacks in general so like of course like the attacks in this is still possible because like the public inputs don't have the intention t uh but figuring out figuring out that this is a vulnerability is doesn't really require that much math to be honest it's like a design issue more than anything so so for plk you don't really have to have you know additional like cryptographic understanding and for Gro 16 of course it's known that this is malleable like uh in some some you know public is not being used it can be malleable but also the interesting thing is that usually these are handled by the backend backend layer by just adding Dy

constraints there so the usual circuit auditor don't don't really have to worry about these things too much and of course as mentioned before the remaining of tech ideas on proof p is pretty pretty like straightforward and doesn't require that much mathematical background so there's that and similarly uh this is like the big idea of of like what how I view like circuits in general so like on the bottom layer we have like the proof system the like the basic artiz and all that and on the top we have some uh cryptograph cryptographic trickery like look up speci miror and memory like offline memory checking and so on and sometimes and often times there are an additional layer called

libraries like we use liaries all the time in smart contracts and it's similar for zkp as well for example these liaries can handle uint ECC hash emulated Fields multiplexers solare arrays data structures bite operations bit operations all that and the circuits can uh of course use the proof systems you know like the API for you know like handling variables and assigning constants and those stuff directly they can also utilize lookups vmir memory to you know make the circuits go faster and they can also use these chips and libraries to make the developing easier right so in a way if if you're if you have like in usual smart contract

security like if you use open zeppel in you know if if if a project uses open Zepplin Library uh of course we do take a look at the open Zepp library is like basic assumptions and how it works and and such you know stuff like that but nobody like really takes a deep dive into opening library and like audits it completely we usually assume that the basic fundamentals of open Zepp code is safe uh so similar to that like for example if if there's like a fixed library that a lot of people have looked at it and a circuit utilizes these circuits that reduces so for example like in usual case implementing u56 in Halo 2 or Cluny 2X or whatever is not

non-trivial but if there's a no Library beforehand that implements you into 56 then a circuit writer can just use that library and now the now a layer of like cryptographic madness has been like lifted off from our shoulders and it makes everything much more easier so it it reduces the number of like exposed cryptog cryptographic tricks so it makes uh both developing and auditing require less math in general and also uh let's talk about the like cryptographic tricks we mentioned the the F shamir's lookups and memory checking uh for example like in in fasir like fasir and how it works is pretty cryptographic like random Oracle

model and is related proofs are pretty hard to understand in cryptography I still don't recall the like the Shor Shor signatures you know safety proof in my head like it's too hard uh but uh their core ideas and core intuitions regarding security is like very intuitive the main idea of vamir and their security is that transcripts must have everything that's computable so far uh and in that case the hash is just considered as uniform random and this is like exactly how random Oracle model Works anyway so it's not like that it like this kind of intuition based I intuition based thinking loses any information like this is how cryptographers thinks anyway like Crypt cryptographers do like more ungodly

stuff with romor model uh so it's fine uh a lot of text here but basically like the idea is that like for example a very common RLC application is to prove that the C the string C is a concatenation of A and B and you use that and to prove that you compute the RLC of the these things a b and c and one checks like this RLC based equation uh but this RLC requires a random gamma and the most important part regarding you know F bugs is that how how one should select gamma and the the intuition here is that if a and b are known then the correct value of C is known in advance because C is the concatenation of A and B right so so

since a since a BC are all computable what we do is that we just take the hash of these three things and shove it into gamma and everything will be fine and of course if one forgets to include C for example and take gamma is a hash of A and B the intuition is that one fixed one fixes the value of a and b and that will fix the value of gamma because gamma is the H of A and B and then you just you fuzz you fuzz with C uh to get a value that matches the RLC value but C is not the concatenation of A and B and you hope that it works and and intuitively like it it feels like it will work and it actually does uh even though it doesn't really work uh that well it's clear that it's a bug so

everybody will fix it uh so of course like launching a full attack regarding these like RLC related things might be more involved might maybe like require more mathematics so there's like the last challenge attack from W zeppin has been uh discussed in this in this ZK Summit uh there's also a very the OG guys from tropus uh discussing the frozen heart liability lots of bugs there and also back in uh PR crypto uh at death death connect uh I think s pretty uh discussed an attack uh on incorrect RLC by using some lattice techniques uh so so this does like require some level of cryptography but I do believe that the most important part in auditing is finding the vulnerability

rather than like making a full chain exploit so finding the bug uh can be done with most of the intuition so for example for last Str attack like it's clear that the entire like transcript has not been shoved into the you know the entire entirety of the things that can be shoved into the transcript has not been shoved into the transcript and that's why you know what happened so at that point it's already like known to be a bug and the the rest is like some exercise so finding that bug uh just just sping the bug itself can be done purely by by intuition which is a good news for like Auditors who don't really have want to go into this like deep stuff and also for like memory checking models uh if you're doing a uh logarithmic derivative

logarithmic uh derivative based single array memory checking you would probably like do something like this equation like above but which looks difficult but all it does is that over a over a fixed tole of uh avt which is ADV value and time stamp you are checking that the sum of uh input multiplic cities are equal to the sum of output multipli cities uh over all those Tes so so of course like here the the reason why like the the equation above leads to the conclusion on on the below uh is very non-trivial and it's of course not not very easy but but uh once you accept that once you accept this fact uh the core idea is that like uh the core idea is that these

like black boxes the so the line below here is the Black Box uh these black boxes can help you reduce circuit auditing into less of a like paper reading session like Peach level Peach level paper reading session but it's more of a like mathematical puzzle it's a puzzle it does require some math in a sense but it's uh it's more of a puzzle than like like hard math S I think the puzzling aspect is more like puzzle aspect is uh bigger in Z be secur and people realize so I wanted to get that out of the way uh and uh and while I do I did discuss some like good news for the people who didn't want to like go

through the the heavier ends of skipy cryptography but still want to audit stuff uh here are some like news on the opposite side of it so first of all there is the hidden prerequisite that can be stand from the computation F so like we just we kind of assume that uh indirectly assume that the computation F itself is pretty familiar to the you know Auditors from the blockchain space but in a lot of cases uh this F itself can be quite mathematical and obviously to in order to audit a a zkp implementation of f you have to understand F very concretely so there's like there's like a hidden perquisite there so for example if f is about elliptic Cur curves if f is about EDSA verification which is very complex

uh f is of about cache functions and in the extreme case f is of about snark verifier so you're doing a recursive snarks or maybe you're doing folding so there's the recursive part of the folding uh in in in these cases because your your computation that you want to verify itself is already quite mathematical you would have to know these things uh deeply uh to audit it of course so in general having much much better fundamentals uh regarding you know the stuff you want to audit uh will lead to more functions more computations that you can actually audit so you can actually uh you can actually audit more applications so obviously having better fundamentals will be good for you

because you can AIT more stuff uh and of course there is the fact that prerequisites don't really equal to difficulty uh our discussion is is really mostly about prerequisits but difficulties a very different thing uh even even though like circuit auditing might not require that much math it's still a very difficult uh task to audit implementations of very complex data structures uh and also like of course you need to understand plish aromatization for example to audit because most uh circuits these days are these days are based in punkish so you need to understand this aromatization but it's pretty hard already already and also in general I do believe that the

nurse s people are the most competent at such um you know tasks and like audits so I think if you're a good if one is a you know good auditor even though I like tell you that oh like this heavier cryptography side is might not be actually needed so you might uh need to focus more on the you know puzzle side of things uh they would they would still like try to learn this deeper cryptographic things because that's what that's usually what good Auditors do they try to go into the deep ends like that's that's like all the qualities of good auditor uh so like this talk is mostly about like not being scared of zp secur too much rather than like telling you that like I I really don't want to be that person who's like oh you don't actually need this you don't actually

need that I really don't want to be that person uh obviously like knowing more uh is is good for your skill but this is more about uh not being scared of this this space too much so yeah there's that and also like uh so so the talk I did so far it kind of leads to like this picture right here so it's the same picture from uh before but uh below to the two arrows below are colored in red and two arrows on top is colored blue so basically the blue arrows are like blue arrows require less mathematics less less heavier mathematics uh and the Red Arrows require some heavy math some some quote unquote heavy math uh so for example like if you're uh just working

over the chips and liers that are already audited then you can since you can use them directly as if you you were just working on you know regular un 256 and so on uh working over those would require oh okay would require less math but more of a puzzle stuff while while building a u implementation or ECC implementation from scratch would require more mathematical tricks and therefore more mathematics uh to be able to competently audit it so but if you look at if you stare if you stare at this uh long enough what you will get is like this which is very like which is very uh scary for some people like for me this

this scares me a little bit so like so if you stare at this long enough like the idea is that if if one has good chips and good libraries and good you know front ends um in general that will make circuit auditing SL circuit development very much like regular code writing right that's why these are colored in blue so if this uh Trend continues what we will get is that we will just get a zkm which or like zds C that doesn't really like expose uh lots of topography to the surface and for example like let's just say that there's a like anyways um so the main idea of this picture that I like Drew on iPad anyways uh is that you one will write

just code and shove it into a general propery KVM and that will like immedately lead immediately like turn everything into a you know uh good CP you know system uh and if this happens uh basically the the set I was talking about before the cryptography exposed to the surface will be zero and The Meta will be something like write programs or code not circuits and this this uh meta for developers would lead to audit code circuits meta for Auditors so it's like uh like not requiring not like saying that oh you don't actually need this or this or this uh for zkb zkp auditing turns into something like oh zkp

auditing and regular code auditing is now exactly the same because we we're now like writing code instead of circuits so this is also a very good time to think about the strength of zbm uh if you are like trying to learn uh you know zkb security from the bottom up and you want to like make a bet on make a bet on whether or not just studying the like the the up the frontmost layer is sufficient you would you would have to like make a bet on on whether or not like a zkm might you know make your work completely like irrelevant because now you are just reduced to just working on code that just show into zkm but also at the same time specialized circuits are important for optimization uh but maybe

but maybe like zkm are strong enough to like make those specialized circuits irrelevant who knows uh but at the same time if there are uh if there are specialized circuits so for example if I'm a person who who knows like only the like the the Earth matiz and it's uh and stuff like that and I I claim that oh um ZK Willams might exist but that does that does not make you know my knowledge irrelevant because uh irrelevant because specialized circuits will exist and I'll be able to do circuit level circuit level front you know layer uh audits on those specialized circuits uh that might not be true because specialized circuits

usually will be like heavily optimized and those heavily optimized circuits will not just simply use libraries and you know it will be it will try to like optimize more uh so like it will use all tricks that are like on your hands so so auditing those specialized circuits would require lots of like deep fundamentals so basically you can't expect that uh this kind of like structure would exist in those in those specialized circuits uh specialized circuits would probably like would use everything at once so that like all colors are pretty much red uh in this uh picture so so it's kind of hard to like bed on it uh so the after the zkm starts

to build up the the the picture looks something like this so here the blue color the blue arrows are representing the the stuff that doesn't require that much math the red uh arrows uh represent something that uh requires a good understanding of tricks and math so you need some mathematical stas to handle those stuff and the green green stuff is added uh here and those uh represent a complete understanding of the entire Z stack so something like this uh so the bottommost layer is probably like the like the actual like Stark verifier or something like that so those require you know very good understanding like full paper level understanding of the Stark

uh and so on so you can like divide the ckp auditing into three layers and each of these three layers will require different levels of mathematics so you can like pick and choose uh and if you and overall if you're considering about like if if you think about the zbm meta uh there will be less circuits to audit because everything will be written in like lots lot of things will be written in code so circuit layer audits won't be like as dominant as it is right now like right now circuit layer AIT consists of like 90% of AIT right now but if there's a zqm many many of those circuits will be just code so less of that will exist less of them will exist and that would

lead to front and back end layers uh becoming a big Target while right now those won't those didn't receive as much attention because there are less less audits available uh as time passes these uh these layer audits will receive more attention as their portion will will increase and also if you're building a VM computation we we discussed the computation F we discussed is about building a VM so obviously to audit a ZK VM you need to know how VMS work so there's also that so overall if you if you combine these together it it kind of like leads to the conclusion that it the meta rewards heavy covery fans heavy math fans and heavy compiler fans heavy

VM fans so the most nurse night people on the planet so so so like it's very like The Duality of that yes the duality of this talk is like a oh you might not you might not need to be nerds night and B but the meta will reward nerds KN people so so take it away as you as you like uh so which is kind of bullish for me because I recently uh this is a self show but uh I recently found like a weird like cryptographic mistake oh hey a weird mistake in like cryptography paper so I can I can actually like do the heavy cryptography stuff so it's just kind of good I don't know uh so anyways uh

yeah so anyways uh the conclusion here is that by plugin plugin playing uh this so plugin playing this zkp development meta game so like whether or not you use like lots of libraries or you use like uh heavy like Specialized optimizations or you use ZK VMS uh uh depending on this like zkp development meta game uh You can conclude that currently I do believe that there are plenty of that uh one without a super heavy knowledge of math and craphy can definitely help regarding security and definitely some blackbox reductions and layers operations can build help build intuition and help onboard people very quickly and yeah and so on but in the

zik meta I do believe that strong knowledge on the entire zik stack will be very much appreciated and also knowledge on more more like uh more complex structures such as VMS and compilers will be also very very important and a very good uh skill to have for to be a good auditor uh so conclusions again so we gave an insights on the taxonomy by we by like thinking about uh the St cryptography exposed the surface the mistakes come from this set so starting from the cryptography itself we you can kind of think about like how this this property can like mess up with the you know developers minds and make

them cause mistakes and they can all like they can be like mapped into uh a bug class and also we by like thinking about this set forus surface we can derive the auditor mathematical prerequisites and by using black boxes and additional layers and so on we can like we can separate this this mathematical stack into parts and this can like help you know Auditors get a good sense of what they need to study in order to like audit what so it uh it makes everything more transparent in in a way and also finally we we showed how to like use the big picture like the the one with arrows and stuff to view the zip security landscape based on how people will develop zip circuits and and

uh and we focused on KVM as a big so I hope like this kind of like makes you helps you understand like how zkp Security will change based on how zkp technology advances uh I think it's a very good thing to think about if you're like interested in Security in general so yeah hope uh you guys learn something from it I guess thank you [Applause] and any questions um so right now would you st before you we got like five minutes

more question okay uh so looking at the situation right now would you say that there is a profile of a circuit auditor mostly dominated by the skills you need to audit a circuit or is that rather a uh circum auditor like language specific like a Noir auditor a Kyra auditor how how would you think about it is concept the dominant thing or the language expertise that's a very good question but um I think uh my answer might not be directly related to your question so I'm sorry about that but I do believe that one of the things that is also like bullish on people who are nurse KN is that there like right now even for the circuits I think every zkp team is still

developing their own thing like there's no Universal like B uh like fundamental layer so that uh you kind of have to have a mathematical fundamental to like get get you know accustomed to like other languages very quick because there so many languages out there so yeah I think that's another reason why like mathematical fundamentals are very like appreciated in general unless you're like a very fast learner in general but yeah but yeah thank you everyone

[Applause]