ZK10: ZKP Privacy Chains & iOS Client Side Proving in practice - Darvish Kamalia

Transcript

[Music] cool so we're going to go through a small workshop and we're going to demonstrate proving on iOS devices sort of a proof of concept for approving on mobile devices um a little bit of introduction I'm Darvish I'm an iOS engineer at puzzle uh we build all kinds of tooling on top of um CK privacy chains and yeah we're very excited to be here so before we start uh make sure you've downloaded xcode um and you've cloned our repo and you've also downloaded the puzzle wallet extension

um you'll need all those three things there's links down there for all three of those um in case you need to follow along so before we get into the workshop just a quick overview of why you would want to build on mobile in the first place the biggest reason that's where the users are if you look at Global trends for internet access we see that 60% of web access around the world happens on mobile phones and if you look at Emerging Markets like Africa and Asia you'll see that number even higher 69% in Asia 75% in Africa so increasingly users are not using their desktop devices to access the internet and so if we want to on board the next billion

users will have to meet them where they are which is on mobile additionally mobile gives you some amazing Hardware features that you don't get with a desktop or in a web environment for example you get secure Enclave uh on Apple devices which is a hardware separated secure execution environment similar to sgx um and that allows for just an additional layer of security security which is really important when you're you're dealing with sensitive data like financial information Healthcare information you also get access to a GPU and a multi-threaded uh and a CPU that's

architecture that supports multi-threading multi-core CPUs um multi-threading on iOS and on Android is a very mature ecosystem and there's a lot of very sophisticated tooling available so you can get the most performance for your uh apps and you get off systems that people are already used to so face ID Touch ID uh these are authentication mechanisms that users are already familiar with and they trust them and we can leverage those to build apps that they also trust and the biggest one is just engagement um people will always have their phones on them and that can be

leveraged to drive usage to drive adoption uh to get people into your apps and help them enjoy the apps so one of the biggest ones that we've seen personally is uh because people always have their phones on them you can you can bring people into your app as you meet them where they are uh we saw that with we work with Empire da to build a fundraising platform for them and we saw that when they were at events they were handing a QR codes to people to go to their website and check it out and so they wanted people to be able to donate from their phones but because we didn't support mobile at the time uh

they couldn't use the platform and so it was it led to less engagement than ideal another Advantage is you get to use uh push notifications which users are increasingly becoming very familiar with and both apple and the Android ecosystem are pushing um for wider adult option of push notifications uh you can do smart pushes now they can be interactive they can be rich notifications with pictures and video and you can use all of those things to drive people um to use your app and also just notify them of important events uh something that we've run into is while building multi we realize that if your multisig is proposing a transaction and you need n number of people to approve it if they

have to all wait till they get back home to their desktop or laptop to do that then you're going to wait a long time approve transactions if they can just approve transactions on their phone then you end up increasing the speed by an order of magnitude and lastly you have native payments integration so Apple pay and Google pay again are payment systems that users are already very familiar with they trust them they're familiar with like how they use they've got bank accounts and all the off ramps on Rams set up so you're able to integrate with those directly before we get into the actual Workshop we just wanted to touch on some of the problems that need to be

solved before mobile proving can become a thing and one of the or sorry the two main reason uh the two main reasion of uh problem solving that we need to do U are around State Management and proof generation so for privacy based change most of them follow the utxo model of notes spent unspent nullified trees and we need somewhere to manage that state um if any of you have used a privacy chain before or interacted with it you're probably familiar with this initial giant timec consuming step where your device has to sync the entire wall State find all the utxos that you own figure out if they're spent or not spent

so um that is a problem that you also have to solve on mobile except you're very constrained because you cannot just download a whole blockchain onto a mobile device you don't have that much room so uh that is um that is something something that you have to figure out before you can make your chain uh usable on mobile devices uh that is not what we'll be focusing on today we think that is a problem area that needs to be addressed but um and there's some very promising work in that in that re um area but we're going to focus on the second uh pro set of problems which is around proof Generation Um execution traces so this involves generally building a circuit uh which is you know translating your code into constraints

and then into um actual bik code and generating proving generally also verifying keys for your um program and then creating the actual proof data and depending on the Chain this can be anywhere from few kilobytes to a few megabytes and that's kind of the problem area that we'll be focusing on today and demonstrating today uh but we just wanted to highlight that the other area is also important and needs to be solved oh sorry cool so where do we stand right now right now mobile is mobile interaction with blockchains is in a very early stage mostly like the rest of this space um the ecosystem around

non-privacy Focus chains like ethereum is pretty is is getting to a pretty mature place now uh you can use any number of ethereum Wallets on mobile and they leverage some of the hardware features we talked about a lot of them store keys in the keychain um some even uh try to support secure Enclave for doing things like signing messages and uh approving transactions and that kind of thing the issue is because these are non privacy fers or actually non ZK uh wallets there is no proof generation that needs to be done and so the actual computation involved to sign a message is relatively small compared to

generating zero knowledge proof and and that we are able to do today so what we're not able to do is more complex computations like generating a zero knowledge proof one potential solution is offloading this computation to a to another device it could be uh something like uh like what mobile coin does or with using sgx um in a server somewhere and but that involves sending your circuit inputs private inputs off somewhere else and you can use you know private information retrieval create a TR trusted execution environment and demonstrate that the computer that's executing your transaction cannot actually compute or cannot actually see

any of that data but it still involves sending private input somewhere um and this only exists because of the limitations of a mobile device um we think that in an Ideal World mobile devices are actually able to do all proof generation on device and so we don't have to send private inputs anywhere and that would create a lot of peace of mind and just be more secure than uh sending private uh inputs off somewhere else so with that in mind that's the ideal State we're getting there we're not there yet and uh yeah we're going to try and demonstrate what this looks like today and hopefully in some ideas about where how we can improve it in the

future cool so we're going to get to the workshop now if anyone's trying to follow along this will be the URL it is puzzle ISU slz Summit iOS Workshop that's the repo and it's also down there um if you want to take a look so and this has instructions for the whole Workshop already so um in case you fall behind or need a second this these instructions are um pretty much what we're going to do here today and I will also be demonstrating these on here in case you can't follow along uh if you're curious or if you're

on a Windows laptop which is fine um cool so the first thing we're going to do is we're going to navigate to this website we've build a little believe it's CK Summit 10 do bell. app yeah and and that is also on that little page over there so this is just a little demo website we built that will help you see

um the executions that you're running and the goal of the workshop is you will run against an Al IO program and you'll you'll do execution against an AO program will broadcast a transaction to the chain so that we can see that it was like a valid transaction that we executed and then you'll be able to see the results um in this tab so to get started we're going to connect our wallet and this is going to prompt you to download puzzle wallet which is something uh we developed at puzzle it's a wallet that currently supports Alo in the future any number of other privacy chains and um uses infrastructure that we've developed at puzzle to make the

experience of using privacy chains as simple and intuitive as possible so we're going to go here and we get a little model that this stap wants to connect and yeah now we're connected to this St so if you're connecting for the first time you'll see that your uh balance here will be zero and the we can just ignore the second line for now so our goal here is to allow you or anyone using this to Mint some of these tokens that we've come up with the ZK sub 10 token and mint some and also be able to transfer some so if

you're not familiar with interacting with uh onchain program essentially you have a piece of code deployed on chain somewhere and we will just be calling specific functions on that deployed program with some specific inputs um very familiar to like sort of any anyone who stands uh interacted with a smart smart contract before so I'm going to go back to the sorry go back to my workshop here so we're at step two um connecting your wallet and step three to grab some Alo credits so if you don't have Alo credits um you can text their faucet or you can

let one of us know and we will be happy to provide you with some if you're trying to do some development cool so the next step is going to be uh cloning the repo which might take a second so give people a chance to do that for uh the repo link is also on this um

paper down here by the way um but if not you can also just look for puzzle hgz Summit iOS Workshop cool and now we can get to an actual demo so sorry this is the demo app it's fairly simple doesn't do much essentially it's just a way to execute against an arbitrary smart contract uh that's deployed on Alo the main file that you would need to interact with is content v. Swift which

is where we have all the code that shows this page right here so I'm going to get rid of all of this and we can fill all that in together so as you can see right now I have a 100 ziki Summit tokens and we're going to try and run an execution that allows us to uh get some more and so just so uh people have an idea of what we're

actually running here um I'm going to first pull up the code for for the smart contracts just so we can see um what functions we'll be executing again so the and you don't need to do this this is just for demonstration um but this is what the contract is named oh one second I use a different one

sorry awesome you should there you go so if you're curious this is the the code for the smart contract looks like and it's pretty standard token stuff very basic uh essentially the function that we'll be using today is uh mint private and as you can see this function takes in two inputs one is the address that is that will get the newly minted uh coins and then the the second input is a unsigned 64-bit integer that is

just the amount that amount of tokens that the address will be getting um obviously again it's a super simplified thing General you wouldn't just be able to Min as many tokens as you want for yourself but for the purposes of demonstration this this should be sufficient so our demo is going to execute against this mint private function so if I go back to our Workshop let's see here you go we are at step oh actually yeah we are at step eight these are a little out of order

but um yeah actually sorry we need to do step six first I skipped the step there but before we can execute we need to provide our execution with a private key to generate the proofs and a fee record to pay the fee for uh the execution so to get those I'm going to go back to Chrome I'm going to pull up my puzzle wallet I'm going to go here I'm copy my private key and I put this key right at the top cont vi. Swift um the private key

variable and then I need a record to pay my fees so um if you're familiar with other bxo type Chains It's called U the these if records can be called notes um but essentially this is just a piece of data that um shows that you have a certain number of credits and you can pay the fee to execute this transaction so to do that I'm going to go into my records Tab and go go to the unspent records and you can use any of the records that uh are associated with the credits. Alia program so I'm going to use this one that's

unspent I'm going to click on it to copy it and I'm going to put that into this Fe record variable so that's the only two inputs I need and now I'm going to go back in and run this demo app it's going to take a second to compile awesome so now we are almost ready to execute so again um to run the execution these are the these are the parameters um and

yeah if you're curious about the actual source code um we just saw that here so um this is the program name ZK Summit token B10 Alo the function name you saw earlier it's called mint private so I'm going to put that in here and our inputs so our first input is the address that will'll be getting the new tokens so to get that me go back into my oh sorry go back into my wallet I am going to copy this time my address and put that into the first field the second

field the second input here is uh onsign 64-bit integer which is the amount of tokens that you want to Min so I'm going to say we're going to get 50 tokens and because we don't do type conversions yet you have to just put in the type of this number which which is an unsigned 64 bless you uh 64-bit uh integer and yeah we can do a couple runs um for the first one we're just going to run as is and then we can cach actually we'll we'll have it cach the keys just so we can see what this looks like and yeah now we

can just run this program and go back to xcode and we're going to see this execution Trace here so I will also switch to a memory view so we can just see utilization and we can see why we are kind of a bit of ways away from being able to do executions very efficiently on mobile devices um this is a multi-threaded implementation which is why you see usage over 100% but yeah if you look at the execution trace it computed the trace um the constraints it generated a proof then it did approve for the fee transaction obviously and then it broadcast this transaction so uh that's

a transaction ID after a successful execution and so if I were to go back to build a token and refresh this probably give it a second to sync let's see if we can see this transaction in our activity there you go so it's been private here okay might have to disconnect let's see think I have to disconnect the that before oh there you go yeah just needed a second uh but yeah we see the that we

now have 50 more 50 more tokens um and yeah that's that's the workshop um the demo app again will be available for everyone to use so um if you guys are curious you can execute against pretty much any arbitrary Alia program and generate proofs uh the only thing to watch out for is now that I have broadcast this transaction this fee record that I used for this transaction has been spent so if I wanted to do another trans uh another transaction I would have to go back to my go back to my my wallet and get a new unspent record

so give this a moment to think uh yeah these are all unspent so I should hopefully have one that's been returned to me but yeah either of these would work because they're unspent um so yeah every time you run an execution just make sure you're getting a new fee record but yeah I think that's that's the workshop thank you [Applause] what about the caching approving oh yeah we can demonstrate caching oopsies good question yeah that's a good question

um I don't know if we noticed this on the first run but um actually I can go back and hopefully maybe show you guys this was our run we just did uh I don't think we can see it but memory usage for that first run was pretty high because we were generating the proving and verifying Keys um hopefully on this second run because we've already done it before we should be we should be we should do a little bit better than that so while that compiles I'm going to go grab my new unspent records some oh that's the

wrong that's the wrong window this is the right window okay that's a new record I'm going to run that on here okay there we go cool so we have a new record in there now um we're going to see if this does better and I have to run it a couple times uh Z Summit input is our address so they go

back and copy that and we're going to make us ourselves another 50 tokens cool let's run this so hopefully this should be a oh sorry um hopefully we should see less memory usage this time if it's able to reuse the same there you go that was it so with the cache Keys it runs significantly faster um no network usage

because to generate the keys you have to download parts of the SRS string which we saw in the previous transaction I think if I go back uh through the bill logs and we look at this one is that the one oh okay it looks like I already had um the SRS strings um cached but if I let me see if I can find a different one that didn't have them I don't think I have a save transaction but um if you were to run

this with without cach keys or if you were to clear the cache and run it again you would see it that it would have to redownload the SRS string which is about a 300 megabyte download up to like a few gigabytes depending on the size of your program and then it would have to compute the proving Keys which would take a while so actually let's see if I can um demonstrate that so if I just delete this from from here um and we delete all the cache data and then we run it again

aloor private like this is already copied yeah that's good to use 64 um and I'm not going to update the key record because we don't need to broadcast this transaction but just so we can see it running and see the keys being generated so first you'll see in the logs that it's downloading the parts of the SRS file which this one's 0 megabytes but yeah this can get pretty big um and then you can also see the memory usage here which is going to spike to probably around a gigabyte depending on how big the string needs to get cool yeah so this this is a part of the

string 300 megabytes um and it's going to take a second so so yeah these metrics up here um can have demonstrated pretty well um if you were using this kind of um if you were using this much data on someone's mobile device and they were not on an limited plan you would use of all their data for the month to sign one transaction so that is something to keep in mind when you're thinking about optimizations about around do you ship parts of your SRS data with the app do you download it on the Fly uh there's

trade-offs there if you're downloading on the fly like we're doing right now um you're going to be using a lot of network uh bandwidth but your app install size will stay small versus shipping it with the app you could run into a potentially have a multi multiple gigabyte app where most of it is just a SRS data so yeah cool yeah and it's not going to be able to broadcast a transaction which is fine but um it that that's how long it took to do that transaction without the keys cashed already um which was significantly slower than when we did it before with the cash Keys yeah uh I just curious have you ever blown up your phone like blood simulator

like generation yeah we were doing some experimentation with um an older version of Aztec prover and um with that that was their ASC connect um code so it's it's not in use anymore and this was before they had uh come up with their optimized provs you know turbo plon and honk and all that stuff and so um yeah that that refused to run on my phone because the size of the proving key was uh more than the available RAM on my phone and so it would just crash my app um which this is already you know uh if you look at the most recent at least Apple devices uh the most recent ones have 6 GB of RAM

and then uh I think the 13 had like four gigb of ram so um I think we've actually went in our testing run into a program that generates like a proving key that's a little over 4 gigb in size so that would not run on a 13 on an iPhone 13 which is not even like that old of a phone that's two two years ago so yeah definitely very early definitely a lot of optimization to be done but it's promising cool yeah on that just how long take to actually do that's a great question so if you look at the CPU timeline

basically this is the this was the time that the proof was generated at so you'd say I can't seem to like pull up actual um seconds here but if you look at the memory usage trying to see this chart yeah I don't think any of these charts are going to give you a good enough estimation but essentially um it was way longer to actually download the keys than uh do the proof um if you wanted to compare um you can just compare the time that it

took to run the cach we're run with the cash Keys versus without um I think it took us like a few seconds to run it with cash keys and then without took us I think close to a minute so yeah that's that's the difference cool any other questions oh sweet thank [Applause] yoube one question just in terms of like going on from here is mostly that the size of the that you think B just um I

mean that's one of yeah um uh yeah we we mentioned like a few uh like we mentioned this briefly like earlier but U there's broadly two categories of problems that need to be solved um for privacy chains on mobile and the first category of problems is around State Management so managing your utxos um which is right now involves for most like Aztec Alo most chains like downloading the whole world State and all that so that's also not feasible on mobile um so for that category of problems there's like all you know downloading World State managing state in general that's U that needs to be solved but then for proof execution yeah sizes of proven keys are

definitely one um that's probably the one we've run into the most um but outside of that there is also actual computation intensity um what we did here was like a fairly simple program but um as you're trying to execute more complicated prog programs um you start using up a lot of resources and it starts taking longer and longer to generate a proof which from a ux perspective isn't great because um on mobile devices most at least Apple and Android I know that like if you're trying to do very intense computation in the background it will just kill your process so basically to run the proof you have to have your app open in front

of you which is fine if it's a few seconds but as you start getting into minutes it starts becoming unfeasible um yeah some something we didn't demonstrate here but we did run into was uh when we had this running on just a single-threaded implementation instead of using multi-threading it would take about three or four minutes to generate a proof so um that's not feasible so yeah and for intuition there is just Bas on the complexity of the generally the complexity yeah yeah generally yeah generally the complexity of the contract how many constraints it's generating um and then depending on the trade-off that were made designing the protocol itself um you know um like I

think if you're looking at astec for example like between plon and honk they've focused on um reducing the complexity of the prover um but like what Zach was talking about earlier this morning about uh with honk they're trying to um make it so that provs have to do like an order of magnitud less computation um for example so um yeah that's that's generally the biggest factor it's just a complexity of the smart contract and then the actual protocol itself yeah sweet yeah yeah how did you do multithreading there like uh so the multi-threading

implementation for this one is just inside um snark BM which is ao's uh VM implementation that executes their transaction and so we just um leverage that um just essentially got it to link against multi-threading libraries that are already available on iOS um because snar wasn't originally built for iOS and then so yeah that we just leverage whatever was inside that but um as far as I understand there is other optimizations you can still do with like gpus and that kind of thing so it's definitely room for improvement was it was it a is theirs like significantly different I think I remember Aztec connect was just like pretty multithreading um yeah I believe Aztec

connect's um multi-threading implementation was um I forget the specifics but it it wasn't um it wasn't really optimized um for their code I think they just kind of uh took the biggest four Loops that were iterating over large sets and just like broke those out into individual threads but um I think this implementation is a little more tailor to their actual code so it's a little smarter that aous like how been developing with alus in general um I mean I think with Aztec we were

using Aztec connect which is an older version of their codebase so um I I think it was a little bit easier to work with Alo um but also there's considerations around the fact that astec is written in C++ which is significantly easier to use um in an iOS Target because it's supported natively um on Apple platforms and there's a whole tool chain a whole tool chain that uh is provided for C++ code on iOS devices with uh whereas it's Alo is built on Rust and so there's no native tool chain you kind of have to do a lot of work to get that code to run on a iOS device so yeah what are you deal um just a lot of

improvisation I'd say that yeah awesome cool thanks guys