Mopro: Client-side proving on mobile made easy | oskarth, Independent Researcher | ETHTaipei 2024

hello everyone my name is Oscar I'm going to talk to you today about the mpro so the tldr is kind of takea away from this talk there three things I wanted to take away so first is that we want to make proofs on mobile second is that mop is a toolkit for seek application development on mobile and finally let's make CK proofs on mobile grade together so we want to make proofs on mobile why do we want clients side proving so let's put CK Ser knowledge back into CK I think over the last few years in the c space we have seen a lot of focus on sort of the succinctness properties you get uh from CK and that's great and definitely needed but if you want to get sort of privacy Properties or inability and so on you basically need client side proving so I'll give you some examples of this so first find is supas uh Susu uh so susal is this kind of Proto Network State uh that happened the first event was Montenegro uh last year and basically you have this kind of seek identity system called supas that allowed you to get entry into various events or or do kind of voting and these types of things um and then later on uh late last year at Dev connect they also sort of uh they they improved on this concept or like made kind of added like games to it so they did this thing where you have to catch cryptographic frogs it's like ecdsa signatures and if you caught like 50 you got like a like a green hat or whatever and this is kind of maybe a silly example but it's like people doing experiments in kind of a crypto fashion in terms of seek identity and private voting and these types of things for more real world example so there's a system called adhar uh which is basically a digital ident system in India uh and it's it's huge it's basically a necessity if you live in India like I think they have more than 800 million users and whenever you sort of apply for a bank account or a job or getting an apartment or a loan or whatever you basically have to give over your digit identity uh to to to the provider uh and it's basically in form of a PDF and then is this sort of r signature signed by the government in it and it's great and very useful and so on but obviously as you do that uh there's some problems because you give up your information and all these types of things so there's a product called anadar a PC sponsored product which basically add CQ to this so you get things like selective disclosure so you can imagine that you can prove that you have valid Identity or prove that you live in a certain Province or what have you uh without raling for example your address or other personal information that's that's pretty useful and there's also other similar uh products like this like proof of passport H which is kind of the similar thing uh in uh Europe uh for passports and Mina in Japan and so on so there's a lot of these type of products and I guess the general theme that we seen the last year and a bit before is that you have this um kind of web two D identity system where you have cryptographic material like if it's RSA signatures in a PDF signed by government or maybe GitHub public keys or etherum keys or what have you and then basically taking that and permission adding CK and Building Systems on top of it so that's a very promising direction that we're starting to see uh and obviously this is a lot more complex than a super example in terms of the the constraints uh that you have to prove and so on uh with RCA signatures um other examples out of seek identity so going back to the origin of this space with Bitcoin and so on like transactions and and to make fungible money so kind of private transactions kind of like cash like if you don't want to have a record that of ties your salary to if you buy a coffee then you that's basically a necessity and we still don't have hav't seen of widespread option of that yet even though there are prodcts like cach and so on that are pushing for this uh so to do that basically you need clients proving right because it's sort of how you would get those privacy properties that sort of regain those privacy properties that that naturally you get with something like cash and I guess more generally s of private finances is if you get a mortgage or whatever uh you also need some kind of clients are approving for that there's also more novel examples social uh social networks uh where you might want to hide the social graph see is very useful for that inms of clent improving and then there's also other things like ckl so um recently there was a project u e Oxford I think that use mpro for this uh where they basically take your your private photos and they able to prove something and do something cool about that and that's not example of where you want to use of client side proving think us more generally like what kind of properties do we want from client proving so obviously it has to be uh secure and S of trust minimized so the use journe journe is the proof and the key material is safe and so on uh it should be fast so you want to have good performance when it comes to Big circuits in order for it to be sort of a comparable a comparable use experience to kind of similar systems and this is becomes a problem when it comes to things like anadar because it's a lot more complex than just uh sup pass or semaphor or something like that uh another thing is if that you have these bigger circuits if it's RC signatures in case of anadar or some ecdsa keys or get up whatever public keys or D like eil signatures or whatever uh you get like a much larger anity set because there only millions or sometimes even billions of these Keys around so if you can hook into that it's much better for privacy propery as well and finally it should be sort of friendly so both to the use and developers it should be very easy to use and robust and just kind of work and I guess with something like supas it basically has to work on a phone right because if you had conference like this you might not carry your laptop around so it has to work fine good on a phone and it also has to work for like 95% of people which mean which means 95% devices because otherwise you can't really use it for gatekeeping events or voting and stuff like that so and when I say uh kind of client side proving I don't just mean browsers I also mean sort of native proving and it might sort of ask like why bother and I think there are few reasons for this so first thing is in terms of security so if you do things natively you get operating system level security with secure enclave and biometric authentication and so on uh and that's important for example if you're talking about real world identities if you have your passport you might not what want to upload that to a random web view what good reasons uh also performance is very important as I mentioned before um so with Native you get native performance so that's things like uh multi threading and GPU Hardware acceleration and and these type of things and while you can get that to some extent in a browser it's always going to be not as good as as native and it's also going to be sort of less consistent across different devices and the browsers and so on finally you get sort of better affordances so integration with the phone so whether it's camera or sensors NFC push notifications secure Enclave uh persistence and all these types of things so you're just going to get a much smoother experience if it's native obviously some trade-offs right so if you don't need an app it's easier not to have an app um and there might be certain censorship Avenues as well depending on the platform but finally I think the biggest reason is just that it's very complex uh to develop and distribute and so on and this is where mpro comes in so m is a toolkit for seek application development for mobile uh it's basically a set of libraries and utilities with a bunch of design goals in mind uh so one is modularity uh so it's very easy to of add additional proof systems and and Target different platforms and so on and our is very developer friendly so it will be very easy to get started and of hide a lot of the complexity of mobile app development for you uh and performance as mentioned before that that's a very important goal especially for these kind of more complex uh circuits that you want to prove from a phone to get a good use experience and then finally multiplatform so that it works of on Android and iOS and R native and so on and you can f a bit bit like a Foundry for cka app development if you're familiar with that this is basically how the main interface Point as a command line interface been working on bit recently and you basically choose the platforms that you want and then you initialize your product uh and then you prepare sort of the Circ the circuits for example circum circuits and create artifacts around that and then you can build on iOS and other platforms and you can also do things like testing and exporting findings and so on so the idea is that you can get started as developer in just five minutes and a few months and this Str is this this sort of product structure so you have sort the core uh rust scaffolding and so on and your circuit and then you have IOS product and Android as well as a config the config file just gives you a little bit more control in terms of the specific devices you're talking to IOS and Android um if you want to have debug information as well as sort of what Circ you want to use and where it is uh but basically would just bring your circuit and then just plug it into this config and then after that you get like an example application that allows you to prove and verify uh straight from mobile and this is xcode uh so it just generates this product for you so resolution is not great here but uh how does this work like I think you can think of it a bit like as these different layers so you start off with the user and then they're using some application and then it's a bunch of tooling and then it goes to like proof system and and computer science at some point uh and the general goal here is sort of separation of concerns and modularity as I mentioned before so user I don't know if you can see but it has they have like no brain they don't want to think about things they don't want things to work you have the app developer has a swift brain and just focuses sort of on making an application and making a great use experience and the CK brain as of just wants to focus on circuits and then s of rust the brain wants to care about tooling and so on and there's lots of things going on here and you don't have to understand it in detail uh but what I'll do is I'll basically take one thing at each layer to give you an idea of roughly how this works and what it looks like so we start off so with the circuit uh and to start off we're using circom which is basically the most used DSL for client side proving it's been around for a long time and just empirically it's what a lot of products that are using client side proving are still using uh and you basically take your circuit as you have it and then you can run more proper pair and it will sort of generate the artifacts that are needed for it this is then plugged into mopro core which is kind of the rust core Library uh with these multiple adapters which being one of them uh it's straightforward to add more and doing a hackathon a few months ago we add a sort of PC for Kimi which is a plish proof system so it's very straightforward to add new proof systems uh and with this you get sort of an API for initializing uh Library improving and verifying and so on and dealing with calization uh and for circum we're using circum compat um to load the circuit and then the witness generation is either native it's kind of a work in progress or via wasmer and the proving itself is done natively with ar graph 16 which is part of the arcworks family of libraries after that we have sort of the Moy so that's kind of the how you deal with talking across language barriers so uh function forign interface uh and it's basically like a bridge between rust and other languages if it's Swift and cin and so on and it's wrapping this rust core API and sort of dealing with what's called lowering and lifting so basically when you're talking across language barriers a big number in Rust is not the same as in Swift so you need to deal with that conversion and it's using unify to generate binding for these different languages and supports IOS and Android and Rec native although that's a bit separate right now but all of those platforms are supported so unify that's basically uh Firefox answer to the question how do you build complex multiplatform applications uh because at some point uh you want to Target different platforms and you have a complex of business logic or whatever then it's nice to have that in one codebase for example so in Rust uh and then you so have these fin layers for language binding to these different platforms where it's Desktop Android areas and so on and I think we're starting to see that slowly in the in the secp as well where SEC space as well where if you want your application to work and sort of reach Mass adoption you want to be able to use it from different platforms and rust is a great great sort of choice for having the business loic somewhere and then just having this fin H bind this to other environments once you have that you sort of have these this native uh bindings in Swift and cotland and so on and you can use it in application so this is anadar version one sort of a showcase app that's going to come up soon hopefully um and it's using moo underhood and then wi rack native so and then finally obviously have the user and they just want things to work right like if you if you're using something you're trying to achieve some kind of goal you don't really want to think about details or what CK stuff you just want things to work right and I think it's really exciting and cool if we as a space and ecosystem can of create this these use experiences that kind of hide this C voodo stuff under the hood and just create amazing use experiences so zooming out a bit again so the general goal here without thinking about understanding all the details is that we want to make life for you as an application developer easy right because there's a lot of concerns here like there there ux and there's application development and like Swift libraries and tooling and proving systems and circuits and whatnot and like it's hard for one person or like you need a lot of people for this or at least many hats and with mopro basically we're trying to split this up so you only have to focus on your area of expertise so if you are an application developer you only have to focus on making a great application you and use experience for your users and basically the main interface is just this m Pro command line interface few commands and that's sort of basically what you need um and and you can start with that in like a few minutes and and from application developers point of view basically you're hiding all of the rust and CK stuff under the hood you don't have to think about that which is how it should be designed uh so I mentioned modularity as a as important design goal so that applies in a lot of uh ways so one thing is in terms of uh platforms so it's very it's trivial to S of add support for for new platforms like if you want to make some kind of app in python or what have you uh adding proof systems is also very easy so we've done a PC for Kimi uh there's also some people that are working on other types of proof as well and I guess generally with this type of tooling you sort of get a lot for free because the concerns you have when you use a new platform or a new proof system are basically the same it's like ffi and station and linking and pack in and so on so once you have that tooling it's not that hard to add like another platform or another proof system and this rust core is also used as kind of shelling point and in the CK space in general because it's sort of fast and secure and flexible and has lots of developers and finally it's also a public good uh this Library so it's not tied to some specific product or business basically whatever is useful to developers and people is what we want so we're not sort of shoe into a specific ecosystem of way of solving things and thanks PC and ser park for the grant so where are we now uh so I showed ear the anadar version one showcase app so we've been working with that and also with the proof of passport uh product and supporting them uh what happened with anadar is basically we did a PC earlier well last year late last year and at that time the number of conerns were around 160,000 60,000 uh and now it's up to 1.6 million maybe a little bit less but it's still like 1 million a bit above uh and as you're increasing number of constraints you're obviously going to R into new problems so big Focus for the last few months has been in terms of understanding the limits of client side uh performance like what happens when you have these many constraints and can we actually do it and so on as well as other types of uh performance things that we working on like native wi generation and loading of various artifacts and just making it better to support a good use experience and then also improving developer experience I showed the command line interface just making it very easy for people to get started uh as an example we had this hacker font project we didn't know about that just used moo because it was useful to them and they didn't even ask any question stuff so that's good so hoping to see more of that kind of thing as well as API and rack native support and stuff like that so just briefly show you sort of uh when we looked into of the limits around client side proving basically the biggest ball neck by far is memory usage and that's kind of something we would have guessed but it's nice to have empirical sort of proof of that and and basically oh it doesn't show the whole graph here but uh um this is number of constraints so it goes this is 1.6 million constraints basically so what that means is that if you have a phone with 4 gigabytes of memory because you need a little bit of buffer for system and other applications and so on you can definitely do like 1.6 million constraints and probably a bit above like two million constraints something like that um and this is like a showstopper in terms of uh hard bck there are also other performance concerns that I'm not going to go into detail about in this talk but that's cool that basically means that a lot of these seek identity systems like anad proof of passport and so on they are on order of the magnitude of like 1 million constraints and as long as you have a pretty modern phone from the last few years like four gigabytes or so memory it might take a while but you should be able to sort of uh create a proof from there so that's pretty nice so that's basically mpro and uh so call to actions let's make cko mobile great together uh so in Taiwan uh some people might know this is organization called ging V go zero and they have this model which is us not by no is doing this you are to nobody uh and there's lots of ways you can contribute to this um so obviously first of all if you are want to make a c application you can use it and write c apps in it and it's very easy now with moreok interface and you can provide feedback uh but it's also like a community product there's lots of things that we would like to see and have added so we want to have support for of uh more platforms and more proof systems and various performance improvements and docs and API and stuff so lots of things to work on and there's also lots of grants in the space so if you in this you can definitely get funding for it uh so in teral platforms we have uh experimental re na support that can be a bit better integrated to make it easier for people to get started uh web would also be interesting it's a bit of a Sidetrack but it would be nice to have sort of one codebase that allows you to Target all of these platforms one go proof systems we have heard interest from both people to work on Halo 2 uh as well as Noir uh in terms of clients proving but there are also other more exotic kind of pro systems you can imagine uh seeing so like Nova and falling schemes Vol in the head there another one binus and there all kind of things that are new proven systems that make a lot of sense for clients are proving especially in sort of a limited resource environment like a mobile phone uh performance also a lot of things to work on uh making the native witness generation work better and sort of more smooth uh GPU so we have some people working on a grant right now actually to sort of take advantage of the GPU powerful GPU that we have in our phone moven is over there he's working on that as well as other things in terms of the documentation applic and API and so on that you can work on so contributors there's a bunch of contributors uh both sort of in terms of Upstream products and Main contributions and downstream uh C Park PC for the grant of support uh Vivian has been helping a lot building out Moos she's back in the back there uh jannis and uh Florent who've been working on anadar and proof of passport respectively who also been helpful in terms of creating like a feedback loop uh for this uh M and and food that are working on GPU proving uh F Remco from worldcoin whove been doing a lot of similar things with rust and com SE proving for mobile phones as well as Iran and back and hopefully you if this is something that you do so recap we want to make proofs on mobile m a tool kit for CK app development application development on mobile and let's make C proofs on mobile great together fut CK the fut mobile the Futures now thank you uh here's some links to Moo M any questions [Applause] and now we have five minutes for the QA does anybody have questions for Oscar can you go back to the the memory graph do you know why this relationship is linear I mean it looks too yeah um so it's basically because of the number of constraints and then when you load it in uh in aworks you basically have to keep all of that in in mind in memory um there might be ways around that but I'm pretty sure that's fundamental especially when it come to graph 16 and Halo 2 and stuff like that because of Perpetual powers of tow and how it works there are other kind of proof systems that don't necessarily have this limitation uh but yeah so I think it's just fundamental because of the constraints and you need that in improving but it might be better ways around it but yeah thank you do we have more questions for Oscar actually just one add to that so this is It's linear but you can probably reduce the constant a bit so I believe if you do this with with the draw script it's like the memory is twice as much and you can probably pull this down a bit uh if you sort of use better techniques and so on optimization thanks for the talk Oscar uh my my question is around the proven Keys which is the first bit right I think that can be over a gigabit gigabyte in some cases right so how do you think about solving that is that a way like making that stuff faster maybe caching or yeah yeah so the proving key size is definitely an interesting uh problem and it's not a ball neck but it's it's important to think about terms of app distributions on so one thing we' have done is that because we're using arworks uh we actually took the set key and we turn it into what's we call like an arc set key uh and it's using Point compression and stuff like that so now it's half the size uh in aworks but it's still pretty big so like for anad is like on order of hundreds of megabytes uh one thing that you can do is you can sort of download after effect uh and then sort of load it into memory and stuff like that so that's one approach and we have experimental support for that uh so yeah that's that's one we're dealing with it but at the same time it's kind of fundamental to grow 16 so at some point it's going to be too much and that's when you might want to look at the alternative techniques uh but for now it seems okayish yeah do we have more questions thank you so much Oscar thank you