coSNARKs in Practice: coNoir

Transcript

hi everyone my name is Lucas I'm a founder and CEO of T and before we start I just want to make sure we're all on the same page so I think you would all agree with us that even if we make blockchains scalable and if we solve inter probability they are not commercially viable so there's still a crucial piece missing it's infrastructure and we call it like private compute and at that we believe that coar will play a very crucial role uh into delivering private computation on blockchains so I just want to make a

quick temperature check who have you heard of the term collaborative snarks or short Co snarks yeah I guess there's like 10 people that's like nine more than at if then were last year so slowly we go now before we're talking what are coars I want to make sure why do we need them and for this uh let's look back at the web free state models that we have today everybody is familiar even outside of this room with the public State model so we got this from ethereum basically programmable blockchain so we have this now for 10 years and the great thing about it was that we did get composability of this state for free so

you couldn't even construct really a public State without being composable and with composable I mean like what you see in defi these Lego building blocks that you can stack together you can call other smart contracts without worrying uh that you do not have access to the state but of course it came with this huge downside of having everything public and thanks to very talented and gifted teams that were brave enough to build in the Privacy space we have now uh what we call Private State unfortunately it's not the case like with public state that it comes with a default composability so the private State we see today that is

mostly CK based lacks some of the composability features we are so used to from public blockchains and which make them so interesting now to make private State composable what do we need we of course need verifiability and what we have to solve here is we have to compute on multiple private states without leaking them to anybody and the first one pretty much looks like CK verifiability we know this uh for a few years already uh it's great uh to do this with CK and the second problem statement is a textbook example of the definition of secure multiparty

computation or short MPC which we already heard from uh the talk world today so the easy solution to create composable private state which is also known as private shared state is just to combine them both and that's essentially what collaborative snarks are combining these two subfields of cryptography CK and MPC now thankfully there was a paper in 2021 from Dan Bonet and Alex that showed us how to collaboratively compute the proof and what this means is that no Prov gains knowledge about the witness data so about the private State and their approach was just to run a CK

Rover in an NPC environment so really straightforward combining these Technologies this wouldn't be a paper in its own like this would be too easy what they really showed in this paper was that unintuitively the overhead that you create by combining these two complex technology is not a multiplication of the overheads that we have from CK and NPC so let's take for example CK uh what's the overhead today probably in the range between 100x and 10,000x depending on uh the use case and the hardware and etc etc and similar for NPC maybe a bit lower you would think that if you

combine those two technologies you end up with a multiplication of the overhead so like really order of magnitude five six and then you're getting slowly screwed but what they could show in this paper is that you can add MPC to CK with essentially no overhead so a statement of the paper was whatever you can prove with a single Pro in your knowledge you can also do in a collaborative fashion with little overhead of course like in every paper there are some detail left for the re to figure out and this is getting nesty at some point but we'll see how we solve that now before we dive into uh a bit

more of the practice of collaborative snarks and what we have built uh why do we need them like with real world applications for example we heard this today already in some talks they're very good for private proof delegation so think about very complex your knowledge proof client s side that you might want to Outsource or like in the world case you have very limited resources because you're running on very old phones you can now have another option between like doing client side proving or doing this transparent delegation where you have no uh security and privacy for your data you can use collaborative snarks to privately Outsource your proof

generation with the same speed that any uh hard uh server side uh CK has and the ne this is not really a net new application it's just uh an improvement of existing Z knowledge Pro uh uh proof generation but the other three are like really private shared State application that you cannot build with CK alone so this is for example private dark pools like think of a private decentralized exchange where you have to combine for example two orders uh in a secret sh secret shared fashion or you want to build onine games that have some asymmetric information think of fog of war or from the talk

earlier private uh ckl now enough from like Theory and examples what have you built so why are we here at noron and not any other talk any other event because we have built uh what we call kir which is an MPC VM plus an NPC proving backend for Noir like why we need both we will see in a minute but basically like the NPC proving backend for Noir is wrapping the ultrah honk proofer in this case into an NPC environment so we reimplemented the

whole Ultra honk uh every step and every component um maybe some learnings here was like uh the linear um operations in the Pro like the multiscalar multiplications for example exle are very easy to do in NPC you can just use basically the native CK version and you are as fast what gets a bit tricky is the Su check part of the ultra hon proofer because here there are nonlinear uh computations and so this is the most complex part if you rebuild it an NPC and a very nice feature again for collaborative snarks is you can use the same verifier as traditional snarks so

you don't have to build any new verif fires they're all compatible so in this case for example with barenberg which is a Tex proving backend now we also had to build a full MPC virtual machine and this the reason is because we have to do the witness extension also in NPC witness extension is a part of the your knowledge proof generation that is usually doesn't get a lot of attention because what it does is basically doing a Plaine computation uh of the program so just a regular program execution and if you're doing this like uh in public or client side this is the part that consumes less resources so you

don't worry too much about it but like if you want to have truly private shared State also this witness extension because here we also using the private data has to be performed in an confidential environment and that's why you have to do the whole part in MPC and as Noah allows arbitary programs we also have to allow arbitary programs and that's why you need general purpose capabilities for confidential compute and this lead us down to the rabbit hole of building a whole mcbm just a side note why also in the paper they omitted this part of bit because if you're just using collaborative snarks for private proof delegation you kind of can uh you don't

have to do this you just do the witness extension locally because it's less uh resource constrainted and do just the heavy part the heavy lifting than in MPC but it's essential if you want to have private Shar State now a bit into the details how is Conor deployed so how does this really look like from a developer perspective you just write regular nor program so you don't have to learn any new language uh there's no NPC language you have to learn you just have to know no so on the left we see for example a program where we have an inclusion proof uh done with a posidon uh 2 hash function and the

nor uh the Norte then compiles the program and we just have to interpret it differently first with our mpcm uh just interpret the different variables that are secret shared uh in a different format and then execute the whole uh program in our MP CVM and then in the end produce a colle collaborative snarks or proof about the computation and what you see here with Alis and Bob is they are the users in this system and they do the secret sharing it's a technique from MPC so that you split up your witness data into secret share and at Randomness client s side this is important like that you do this client s side otherwise you would leak all your information and

then you directly send the secret shares to the MPC Network which take this as an input for the program the quote no program and what you get out is like you're getting free secret shares as a result out and you combine them for example here it's called Charlie but this is very abstract you could for example think this is a smart contract and the smart contract then gets the output of the computation and approv so this is here depicted with uh coars and this is then verified in the very traditional way with a verifier that already exists in that ecosystem so where are we in the

practice how much of this is implemented how fast is it so since last week we have the first benchmarks out uh so this is the first time we show them here this is for uh the first row is for a posidon 2 hash function so a CK friendly hash function that is used a lot in the nor and atte uh stack and you see like the MPC VM this is basically what I told you about witness extension and the MPC proof generation is the actual collaborative snarks generation on the right hand we have the nor program so if you do it uh just with CK and from the absolute times this is quite okay already like if you look at a posidon call this takes roughly 100

milliseconds and if you have like Merkle Cree inclusion proofs of death uh size 16 you have one second and like for 32 it's 2 seconds but we're kind of still a bit off from the CK uh only times and this is mainly due to because we just uh worked on feature richness for Conor so far and not on performance so we have implemented also what we call co- circum which is the same as Kar but for which is of course not that feature Rich and there we could show that you can quite uh you can approximately match the

CK proving times so we would expect that these times on the left come very close to the times on the right over time and to get there uh or to get there we focus in the next uh couple of months on performance and this means we will implement the remaining blackbox function which are basically pre-compiled in nor uh we have already three implemented 17 left to go and do more general purpose improvements thank you here is a link to the GitHub Rao it's all open source so if you want to

try it out uh just uh give it a shot and yeah just hit me up after the talk and we can help you set up everything thank you Lucas for excellent talk uh Lucas besides being a founder and CEO was also former craphy researcher and also former pro cyclist which I found very interesting um but yeah if you guys have any questions uh for Lucas I'm happy to hand you the mic if not I can start off with one uh maybe you could talk high level about uh the trade-offs between privacy scalability and performance uh with T so would say with T it's all about

privacy where you have probably some tradeoffs with scalability is you can choose your underlying MPC protocols so there are NPC protocols for different trust assumptions and you can of course go uh way more decentralized or you can go less parties you have uh honest majority dishonest majority so you have some levers here that you can pull and maybe a followup um how do you see this playing out um with like consumer applications using T and maybe Aztec and other networks um to try to solve different scalability problems performance problems I would assume that first

people look very heavily at the performance so they want to have privacy but it doesn't have like it's not allowed to cost too much so they would be probably be fine with a setup that is like not decentralized with 100 or 200 notes there may be good with like a few notes that run in tees for example and how do you see maybe these types of solutions evolving over time especially on the consumer side on the consumer side uh could you double click what what do you mean uh maybe uh at the institutional level let's say um how people may interact with uh Taco with with Aztec with these types of

networks I think they will like fade away a bit in to the infrastructure perspective and people don't really know what they're working on or whatever they just know the properties they get from the system like they know that they get privacy did they know they get some sort of uh some kind of decentralization and probably have a feeling how strong they are but not more not anymore what do you see as some of the blockers for for that reality I think the concept that we propose are extremely difficult to craft once from a technical side like defx can be much better but also like being building business models where data is

not the center I think nobody's trained for that and so having like creative people Builders to think outside a box that they don't have to use the data to make money is will take some time what other ways could people Center the business on outside of data do you guys have any ideas that Taco that you feel like people building on taso would be excited by yeah for example like take world uh they don't use your data they don't store anything of your iris code and soever they cannot ever monetize this so they have to find different ways to monetize their tax stack and I think

we'll see some creativity there in the coming months awesome thank you cool have some more questions uh you had mentioned that with circom you guys hit kind of parody with the just the ZK and then the MPC proof but with you mentioned how some check is where like the great cost is you don't see you we probably won't hit like equal for the NPC proof with ultr honk though right I imagine there will be some overhead with the MPC proof like do you uh I guess kind of how how do you you see the overhead there with the actual

NPC Network in ultrah hunk yeah so if we can like rely on a very good Network I would see that the overhead is very minimal why we have such a huge overhead for example in the Su check for now is like people build differently in CK Be not with the constraint of MPC in mind so you have a lot of multiplicative dep in the Su Che which is not needed you can rebuild it and that's what we are currently doing uh so making more uh multiplications in the same round so you don't have too many Communications rounds uh in the NPC protocol because this often gets them the bottleneck okay yeah makes sense hi the um in general MPC systems

still suffer from Byzantine generals problems as well too so do you see a future where you would collaborate with other cryptoeconomic systems and integrate this as a providing service where you'll have other you know um slashes other other things to prevent civil attacks in the future definitely like as blockchains we all uh have the collusion problem and I think one way is like putting the uh node operators of the kards in tees gives quite a good Assurance already but again of course you can stack them uh and for example use IG layer for the liess property and I think then you can build a really

robust system if you stack those Technologies together cool any other final questions all right thank you Lucas and T [Applause]