ZK10: zkApp Road to Production - Alex Soong & Sachin Kumar

Transcript

foreign [Music] from GK P2P for this first talk of the of the afternoon so yeah please enjoy thank you so much all right let's go ahead and get started um we actually wanted to start off the talk by updating the title of our talk so over the weekend we were discussing how the development of our application shaped our perspective on the overall ZK app space and found that to be a little bit more of an interesting talk than just digging much more deeply into the application that we built so we updated the talk uh the title of our talk and um why give a talk if you aren't going to share some bold takes and so we're

presenting credibility proofs our Z case Transformer this is an advocacy for developing more apps with credibility proofs and sharing the takeaways from developing our own not sure how many of you guys out there are just starting out in ZK since this is the summit but we did want to span multiple scale levels in case there were others who were starting out just like we were at the last Summit hopefully this artifact can bootstrap the first few months of app development for you so a little bit about us we work together on set protocol which was an evm-based D5 protocol focused on on-chain asset management and we were among the first teams to explore Smart contract-based Financial Services and this is talking you know before uscc was even launched by Circle this means that we've spent the last six years exploring

D5 and crypto economic incentives and our observations on the current value of smart contracts can be summarized into three things you get near instant settlement of complex transactions you get Global price discovery which is true when you have markets on chain open to anyone with an internet connection and lastly you have payments which are now enabled by liquid staple coins in multiple currencies or is that to do with ZK we'll come back to this in a second but um as a brief Assad I wanted to comment on AI which is having its moment as a technology Trend and deservedly so but I would pause it that in 2010 it was somewhat challenging to follow along as an application developer when someone said that their application was powered

by AI it often ended up being some sort of rule-based execution so in other words when someone said that they used AI you knew that it doesn't work because when it works you give it a name right it becomes deep learning it becomes Predictive Analytics more recently in generative AI it's Transformers diffusion and now with the branch for each modality pair and I think it's a good time to bring this up because ZK is going through where I posit AI was for much of the last decade It suffers from a lot of obscurity while boasting a deep set of value propositions that expands you know almost every week so I think it's safe to say that many people on the outside looking in don't really know what the takeaways are but like any technology Trend there are going to be

Diamonds in the Rough at any stage depending on how one looks at it um so what's the first thing that people see today um I'm not going to get into it if you're at a conference named ZK Summit I'm sure you've seen this before but in short it's unclear it's unhelpful and the papers keep piling on confusing nomenclature which I understand is exciting for research but not framed for adoption so how can we clarify this so through discussing this talk with Sachin we settled on the classification of Applied zero knowledge proofs that made sense to us that we wanted to share this is extended from Ian Myers who some of you may know worked on zcash and Elio um so what is that same graph in AI look like for its own knowledge proofs I

would begin first with confidentiality applications so this is a fancy way of saying private payments it's done with a zero knowledge proof and an accumulator in practice this is a snark and a Merkle tree this is deployed today and it takes the form of zcash Monero and tornado cash it's largely explored but hasn't gained a lot of transaction or is being censored outright altogether as we're finding out next you have scalability applications these are your Roll-Ups and zkevms you know how this works you have a server that compresses transactions into a proof and submits that to the blockchain so if your blockchain is slow and can only do 10 transactions each of those transactions is now a proof of 10 000

transactions that were signed into executed correctly thinking here being that some of the most popular blockchains are slow and that faster blockchains are going to unlock a new wave of applications this makes some sense but mostly it's Tailwinds from D5 and nft usage in previous cycles and there's a ton of venture funding behind this which is actually great because they're ultimately improving performance for anyone else that's usually that's utilizing general purpose snarks improving systems but to me this leaves out the most interesting parts of zero knowledge proofs which are found in the third and last section which I'm the most excited about which is credibility apps you know the proofs used here involve leveraging sign data return from existing systems and using it to construct verifiable statements about

off chain or real world interactions these data sources can be API calls they can be emails electronic documents and you can even construct complex statements recursively from multiple of these but the tie off app classifications I wanted to share another angle of them as overlapping because as we know applications are often leveraging more than one of the features of their own knowledge proofs in practice so the boundaries are not strict in terms of limiting values that are utilized in fact a lot of the applications live at the intersections of you know two or more of these value props and of course in somewhat of like a cheeky sense you can always say something like a scalability focused application is always making a credibility statement about the underlying batch transactions and likewise when you make a credibility proof that data can optionally be masked

by the circuit providing confidentiality but in the end it's helpful and important to really simply classify your application and use that to decide how much of each of the value propositions to capture without feeling the need to maximize all of them so back to credibility uh the proofs are interesting because you're suddenly able to rely on statements on chain harnessing consensus and then using that to execute additional logic but when used in a well-designed application they have the potential to be something bigger altogether and disrupt an existing inefficient workflow so going back to defy and smart contracts you can essentially insert these credible statements into a smart contract that settles a complex transaction that may include reconciling payments the most

easily understood of these is an escrow transaction in which case you have a signed document that can represent a proof of a closing statement and then the smart contract May settle the transaction instantly sending Goods to users and then forwarding any money to any of the other counterparties this is a really really powerful combination and a reality today depending on how complex of a statement you want to make and of course if you're willing to live with the trust assumptions that you'd have to take on uh so with this perspective in mind I wanted to reiterate the title of the talk and make the claim that credibility proofs are zk's equivalent of the Transformer which we all know was um the pivotal Innovation that led to chat GPT and that disrupting the right workflow and uh with the right ux will probably be zk's own chat GPT and we

think that this is closer than the community probably thinks and I want to encourage more devs to think about proving complex statements and building great applications around them and of course this would be no fun if I was just saying this without doing it myself and so the rest of the talk will be laying out some design questions and how we answer them with our own application so a little bit about dkp to P in a nutshell it is a peer-to-peer fiata crypto on-ramp we utilize a smart contract to Escrow a digital currency like usdc then sometime later a user who wants to on-ramp can on-ramp without collaborating with a depositor by first sending them Fiat through a payment Channel such as venmo then they generate a proof which represents a receipt of the payment and finally they submit that

proof on chain to claim that original deposit of usdc so this is going to be a very light introduction I don't want to spend too much time talking about the different mechanisms that we built into the protocol but for the purposes of this talk you can treat this as an altruistic service maintained by someone who simply wants to see more people utilize usdc it was actually born in at ZK hack in Lisbon and we thought it would be awesome to close the loop with an update on an app so the key workflow here of course is onboarding and the solution seeks to improve on existing Pathways that are either associated with extremely high fees or incurring high latency before ranting access to your funds on chain so under the hood we piggyback off of a protocol called dkim which is short for

domain Keys identified mail all the data in the email including included in the header parameters like the from the two the subject and the hash of the body are all signed by the sender domain and can be verified using a public publicly available domain key it allows anyone to verify that the email message was not faked or altered and then using regex the contents can be used to make statements about the actions of the recipients so for us when a venmo transaction is executed emails are sent to both the sender and the receiver and either of these can be used to generate a proof of the statement that the sender actually sent the money all right so with the app's basics in mind I wanted to share some questions we encounter when building our own apps and then dig into you know our design

decisions and hopefully this gives you a window into what's possible today and where there's going to still be some room for flexibility when building credibility apps so the first is going to be asking you know what proving system you should use that's a natural question to ask it sounds obvious to say that you should prove one that allow you should pick one that allows you to optimize your ux but today there are you know a plethora of proving systems to choose from that all Tout you know proving performance trusted setup mitigation and Quantum resistance which can be overwhelming for application developers to consume um it's going to be tempting to optimize for performance as a proxy for ux however when we thought about it we decided that performance wasn't actually

going to be a bottleneck and this makes some sense when we think about the slow proving times relative to how the workflow is actually performed in real life today for example on ramping so putting my Divi hat back on the likes of compound and uniswap found so much usage because they replaced traditionally complex tasks like taking loans and creating new markets and so even paying a thousand dollars in network fees and waiting for a few blocks is actually a drop in the bucket and so therefore it's somewhat of a safe bet that users will tolerate latency if their workflow is materially improved that said you still want performance where you can but not at the cost of other side effects that can degrade the experience and for on-ramping we decided that the best

experience would be be to allow on-rampers to complete the flow without introducing asynchronicity which we discovered as a byproduct of exploring Halo 2. more on this later as we explore the stack the second is whether privacy is actually necessary and what to do about it if not so in privacy is obviously a pillar when discussing ZK applications or the current solution for preserving privacy is a proof generation in the client but not all applications require privacy to be first class citizens and we came to the conclusion for that on that for on-ramping it probably wasn't this is somewhat drawn from the observation that zcash and Monero haven't really taken off while usdc

which is pseudo-anonymous and has built in actually even has built-in censorship sees increasing volumes and so if you're not sure or don't have a strong inclination about this you can actually think about making this a choice to users to trade off privacy preserving client-side proofs which are slow with fast server-side proof generation and you'll see how you know what we chose what technologies we chose to achieve this in our stack and the last question was around identifying dependencies that we would encounter and how we would handle them so applications in this class will by definition be dealing with external dependencies since you're trying to prove a statement from data from a part of some other system and so in our case we have critical dependencies on the The

Domain Keys used to sign the emails which can change and of course the email templates themselves since we rely on regex of the emails this affects your applications because you have to handle routing proofs appropriately to ensure Service delivery between key and template updates and this also affects your deployment process because the proving system that you ultimately choose may require trusted setups which would potentially have to be done frequently and are Opera operationally intensive luckily a lot of these are somewhat solved problems whereby managing domain keys and email template updates can be solved with proper versioning as well as on-chain Registries when deployed and in the case of trusted setups there are emerging projects like potion that seek to make

this simple as possible and are actually come complete with the UI cool so with that I want to hand things over to Sachin who's going to share some takeaways exploring the circuit development side of things and what factors were considered in making the design choices that we did cool yeah so the learnings that I'm going to share are largely applicable to all credibility proof based apps uh we will share concrete zkp to be examples as required so when building ckp to be ckp apps there are multitude of gkp languages dsls libraries proving systems that are available at your disposal but for production Z caps we think these six parameters are the most important ones that affect your decision uh on deciding

the tooling for a CCAP those include dependencies so if you include any libraries that you are using like RSA eddc signature verification extractor uh development experience primarily on how easy is the language to pick up and trusted setup these parameters affect your development and go to market speed next we have the parameters that affect the user experience the most which includes Uber performance proving key size if is important if you are doing in browse approving and on-sun verification costs let's go over some of the options that we have I'm assuming some initial knowledge and experience with these languages here um okay so option one is come using the cross 16 proving system development parameters first it has mature

implementations our main dependencies EK email had a mature and stable circum implementation it is easy to pick up and experiment with it has JavaScript like syntax and a Descent of X and it does require trusted setup next ux parameters um it has super fast server side performance using rapid snark slow in browser performing proving for large circuits keys are in gigabytes for large circuits and it has the cheapest on-chair verification cost because it uses the growth 16 proving system the second option that we have is Halo 2 which is based on the proving system uh dependencies like RSA and zkml are largely a work in progress and unoptimized it is hard to pick up well

easy if you know rust beforehand but the vanilla Halo 2 API is still a bit overwhelming so I would suggest to use the hello to live by Axiom instead they have some they have done some great work in simplifying the API does not require any trusted setup because it is based on the Planck proving system ux parameters well Halo 2 has fast client side proving although in browser proving for circuits with degree K greater than 10 isn't really feasible due to the wasn't binder limit keys are very large and might exceed tens of gigabytes on-site verification gas cost is high for circuits that are large verifier exceeds the bytecode size limit so to bypass that you would have to do per

server side aggregation which introduces a lot of latency in the app so when should you you choose com over Halo 2 the first obvious is if your dependencies are in circum then you you're forced to do that and otherwise if your circuits are small um I think it's the Hands-On the best option because it offers you fast browser proving time DT optimized was improver and you get privacy for free but when you're building with real world apps as Alex alluded to earlier everything is in sunshine and rainbows and more often than not when you're building credibility proof based apps your circuits would be big and that's when you have to review your choices

and the decision mainly to whether or not choose one proving system over the other boils down to whether privacy is critical for your application if privacy is not critical for application in that case we suggest you should use com and you get fast server set proving using rapid snack but if privacy is critical to application then you need to perform client-side in browse approving for which you could use Halo 2. but then you run into the two problems that I described before namely the wasm memory limit and the large verifiers uh in order to bypass the wasn't memory limit you you would have to break down the circuit into chunks for example RSS signature verification could be broken down into two components uh the first

one is hashing the input using the star circuit and then performing exponentiation using the RSS circuit and then combining the results of both of those on chain um to bypass large verifiers uh you would need to do server side aggregation which obviously introduces latency note that these are tough engineering problems uh you don't you can also you could also use Halo 2 if you are going to continuously update your circuits uh not having to do trusted setup every time does help or if you need to leverage recursion which is a rather complex topic and you wouldn't need it in most cases at the beginning so which language did we choose for zkp2p well first of all our circuits are quite big because venmo emails are quite

lengthy and you need to Hash all the data in the email and as Alex mentioned earlier privacy is not critical for on-ramping hence we went with circum which offers us fast server set proving um it also gives you low latency synchronous on-ramping flow for a better ux it does also give you optional slow in browser proving and the cherry on the cake is our the zkml circum implementation was quite mature and stable but circum has its cons it requires trusted setup well that is not an issue because we could automate we can automate that using portion from PSE it has slow in browse approving for

large circuits uh fine I guess it's more more of a feature rather than a bug because it allows users who choose privacy over latency to still use ekp to be key sizes are large again that is not an issue for Server set proving but for in browser proving we have an engineering solution to just chunk and compress the keys it does it is not great but it works a quick look at the zkp2p metrics our latest circuits have 5.9 million constraints it takes around 40 seconds for server side proving using rapid snark 400k for gas for on-chill verification but if you want to do in-browser proving you would have to download 1.7 gigabits of compressed proving key and it would take around 9 minutes for

proving on the client side that's just the cost that you have to pay for privacy now if privacy isn't absolutely critical to your application then instead of making decisions for your user you should give your users a choice or where they get to choose between privacy and speed for maintaining privacy you can use in-brow in browse approving using Halo 2. and for Speed and low latency stick to server side proving in circum we are envisioning this flow where we offer both these options to be the state of zkp2p proving yeah let's talk about how to build secure credibility proof-based Recaps next

know that these learnings are specific to circum and may not or may may not always apply to Halo 2. the first concept to understand here is that unlike completely on chain protocols all the computation in Z caps isn't happening on chain instead part of the computation is done off chain in the circuits and the rest is done in smart contracts hence there's a shared responsibility between the circuit and the smart contracts to keep the system secure uh the general framework to think about it is that if if f is a costly function to compute then you would compute F in the circuit and produce a snack which provides computational integrity enough for security you need to do two checks the first and the obvious one is two you need to verify the snack which basically gives you the guarantee that F

was completed correctly but that alone is not sufficient uh because it could have been completed on any input so you would also need to check that the inputs and the outputs uh to the F were correct inside the smart contract let's understand that with an example um so in zkp2b as Alex mentioned earlier we verify the dkm RSS signature among other things signature verification is costly hence we do it inside the circuit the circuit makes the RSA modulus public and inside the contract we check that the RSA model is uh matches the stored venmo modulus on chain this basically authenticates that this blob of data was signed by venmo next nullifiers

nullifiers are used to prevent double spending for example in zkp2p it prevents users from using the same payment email more than once to prove an option transaction generally nullifier is constructed using hash of unique identifiers sourced from the data it is specific to every application and you you need to put some thought into it but for credibility credibility proof based apps where you are proving an option statement coming from a web to service it becomes tricky because if if the nullifier is sourced from the web to data this basically allows the web to service that produce the data to de-anonymize you for example in zico P2P we use the hash of the DCM signature as nullifiers but that means when Mock and dno de-anonymize online users but that

is a trade-off that we're willing to make because we need nullifiers to prevent double spending in Z caps proofs are generally meant for some specific online State again exam example in GK P2P an option payment proof is generated to unlock a specific on-chain escrow now in order to prevent front running and MAV attacks we need to tie the proof to that specific on-chain state we can do so using this neat little trick of accepting the piece of data as an input to the circuit and then adding a fixed Square constraint on top of it for example in the code snippet here taken from the zkp2 circuit we're trying to we're tying the proof to the specific order ID that we want to collect the escrow funds from finally a quick slide on how to think of

upgrading your Z caps a year from now so given the high paced research around around proving systems which is evident by the need of need of two ZK Summits every year you should expect to redirect your circuits in the newest fastest proving system to offer the best ux possible to your users both us and the zkml team are expecting to do the same a year from now and rewriting all the circuits is one of the risks of developing Z caps right now but we are optimistic and we are willing to take the bet with that I'll hand over the stage back to Alex all right so uh just a bit of a quick recap um we discussed how ZK applications can

be bucketed into confidentiality scalability and credibility apps to better understand the ecosystem of which we as a team believe that there's huge potential around applications focused on credibility as we show with zkp2p the ecosystem is probably more capable than what most people are expecting right now and is equipped with a pretty rich design space that's waiting to be explored and so expect you know you'll see that you'll you guys will all see a lot more interesting apps that will emerge shortly and so with that go out and build we want to give a special shout out to ayushin Sora from the ZK email team for building zika email and sharing all of their insights with us and also a big thanks to Andy from The PSE for supporting our development

uh and with that I want to thank you for choosing our talk and open things up to questions [Applause] great thanks Alex thanks Sachin so yeah I mean you you've done my job we do have time for a few questions so yeah please raise your hand I will pass by the mic for any questions come on be creative yes you put a lot of you put a lot of emphasis on the trade-off space between speed and privacy where do you think like that distributed witness proving and kind of um threshold based Things fall on that trade-off space and do you think that

like in your experience looking at this for for Consumer apps uh it'll it represents an interesting middle middle building ground so like your question is about distributed proving okay could you repeat the question like uh secret shared proving between yeah different provers yeah um I mean you could do that but uh you would need a network for that I believe for you need a network of validators to perform that I guess multi-party computation uh our focus is more on like the ux whether the user is

whether the user is ready to reveal parts of the data to be able to send the proof fast on chain or maybe use it on a mobile device because in browser proving is possible on even though slow it is possible on uh your laptops but it is not possible in on your phones so you you would choose the option for Speed there rather than privacy otherwise if you want to be you want to preserve your privacy then you'd go for the other option which is client-side proofing thanks make sense just a second question how are you thinking about surfacing privacy like what privacy trade-offs a user is making when they decide to when they're picking yeah so if if you take the specific

example of zkp2p um the user is willing to share their venmo ID with the server who's producing the proof and so that's the trade like they are willing to share all the contents of their email including the from the two maybe the name the bank account they use and uh the venmoid with only with the not not with everyone on chain but only with the server which is producing their proofs cool thanks um in a in a prior iteration we actually first had the on-ramper specify a specific order of how much usdc they wanted on chain and they were able to

pass along encrypting keys that were then you know pushed on chain and then the off-ramp would be able to use that to encrypt like venmo handles but then we decided in this iteration we wanted to experiment with a much more synchronous flow for the on-ramper to not have to go through that process so they're just tapping into available liquidity that's on chain this one yeah you had on a slide that one of the risk is to just having to like keep on rewriting your circuits and whatever the newest proving uh languages are you guys investigating looking at something like Noir for

instance where you can kind of swap out proving back ends have you guys looked into um we haven't looked into noise specifically but our team member did develop like right like the the dependencies that we need for writing zkml or zkp to be are missing right now and one of our team members did write RSA Neuer so that is one of the dependencies that we need um also about rewriting circuits so here from now uh some of the languages are moving towards swapping out backends very similar to noise so in that case we might not need to rewrite everything from scratch and we could just uh we could stick to the same front end but

use a different backend yeah okay guys thank you very much thanks for the talk