ZK Hack Kraków: Hacking with Aleph Zero (Damian Straszak)

Transcript

[Music] hi everyone and first of all welcome in kco uh this is a very special place to us to ALF zero because most of our team is based here so in particular we have lots of people on site uh and yeah we would love to talk to you uh you can ask questions you can ask questions about alzer about ZK in general and you would really love to chat so yeah I think that that's that's the most important thing here to just uh learn new things learn new

people and uh build something cool so we are here for you and this Workshop is devoted to um giving you some background uh on Alf zero on uh what are our bounties so that uh it's easier for you to start hacking essentially so we have um two categories of bounties basically it's um very similar to what was shown in the v diagram um and it's essentially a hacker path where

you will be using a very specific like library for snarks in Rust uh to do something um and there's a product path where you are free to build whatever you want uh and obviously we will give give you some pointers some ideas um in the last slide I will I will link you actually to a larger document where we have um some documentation some ideas some tips and so on uh that will maybe give you some ideas um right so let's uh start with the hacker puff and to explain the

Bounty I first need to maybe recall you how privacy is achieved using ZK using ZK snarks in general so if you know zash or you know one of the other privacy protocols like tornado and so on they all very very similar and the central object in each of these protocols is the so-called shielded pool or the anonymity pool this is technically a Merkel tree where the leaves are some kind of nodes you can think of noes you can think of nodes as some hidden accounts okay so

there is there is uh a particular uh account State um that is hashed together with some uh Magic crypto stuff and it leaves in one of the leaves of the of the merro tree so this is this is technically how the how the shielded works and when someone is making a transaction then basically they are updating the state of this account and this is very similar to you know blockchains in general blockchains um that are that are public where everything is public uh except

that um when you make a transaction you don't show the state um you normally don't even show what the state transition is you only show a proof that the state update you made is correct right and for that you need to generate a Z Cas and the proof or the relation actually that uh uh that you prove consists of pretty much two things one thing is that the previous note the previous state that you had is one of the leaves in the tree and you prove that the state transition from your old state to a new

state is correct and then then your new state is essentially added to the tree and there is also this nullifier business where you need to kind of revoke the old uh state right so this is this is the familiar flow if you don't know that uh basically yeah I think I think the starting point is is uh the classical design of zos I think this is where everything started uh they came up with it very early on and it's used in all this uh uh privacy protocols great so this is how it all works and then um what's the challenge here uh so the main challenge is

that you need to generate this proofs on a user device which is typically either a browser or a mobile phone so normally uh you don't have desktop clients for uh crypto applications for blockchains so so this is this is for convenience of the users that you normally use browser extension like metamask or you use just like a mobile app to interact with blockchain and well this is this is some kind of a limitation because these devices are not super powerful and Computing proofs Computing snarks is a little bit heavy

so we need good methods we need good uh uh ideas to make this uh fast enough so that the user is not affected right because if the proving time is like 30 seconds well that's uh a little bit uh too slow for the user to be happy with uh with how the app works great so well how do we make it fast uh so we first need to figure out what is slow uh in this uh whole proof and the slow part is typically proving that your previous state is in the tree so this is essentially a miracle PA proof

um uh basically showing a miracle PA in a tree uh and proving that you know this this this branch is correct right uh so this is essentially our goal make proving these kind of statements there is a particular leaf that uh uh has a Merle Branch to a particular rout fast um and what we have prepared for the sacaton is uh repository with some kind of benchmarks and these benchmarks are targeted for the web browser environment so basically I would say um

this is the more popular um the more popular way of I guess interacting with the blockchain currently uh for a browser and what we are benchmarking is um essentially a meracle proof with on a tree which has roughly two two to the 36 leaves okay so 36 levels if this tree is binary of course you can play with different ARs and so on and um this this this might Al also change things um what we haven't done and what we would actually love to see is this kind of benchmarks also run on mobile and well this is this is also like

included in the Bounty if you can do that if you can like um set it up uh get it running on a mobile either Android or iOS that is that's that is a great result um yeah here in the slide are also some detail details um on the curve that you that we use on the has function um so the curve um is something that we would rather not change other than yeah that there is some small maybe uh decision to be made whether we use this BN 256 curve which is kind of outdated um and has some lower security than uh it was in initially um

understood and there is this I would say more modern curve that uh you can also use but it largely doesn't matter uh running times will scale a little bit with the with the Curve but this this doesn't matter to us uh what we are kind of committed to is Halo 2 so Halo 2 is a great Library um zikar is uh using it it was first uh uh developed by by the Zer te and then many many Forks of the original repository has been made including Forks that changed the polinomial commitment to kcg um where the original one was the IPA one uh so yeah these are all

technical details if you're interested in that just go to the uh to the reple uh the link is here but also the link is in the last slide where I have everything together um and yeah there are also details on what do we really want here what are the criteria of uh judging the solutions and so on so on uh but yeah I would say yeah we just want to make it fast there are a couple of ways you can do that you can play with the WM uh compilation you can play with uh uh with the circuit we you can play with um yeah many different parameters of the circuit that can maybe uh change the running

time um all tricks allowed in general great and also included in the hacker path is yeah I would say a technical challenge to implement uh snark friendly encryption in uh Halo 2 so first of all why do we need it uh why do we need encryption in uh um in snarks so here's the story um there is this um there is this issue with all the Privacy

protocols that um if you make privacy completely permissionless if you don't put any limitations on who can join and who can leave and when then there is this issue that certain Bad actors will use your protocol as some of you might heard about tornado cash and this is obviously bad so people have been thinking about all kinds of ideas how can you prevent this kind of Bad actors to use the system or how can you dis disincentivize them uh to not join the Privacy pool to not laundry money essentially um so one of the ideas is to have a party in the system uh

called an anonymity revoker um this is meant to be uh probably a decentralized committee who under certain conditions could decrypt or reveal a trace of a particular party in the Privacy pool okay so what this party what this part what the particular user did in the pool and in particular how did they leave the pool and the idea here is that well if you have funds that were deposited to the pool which obviously came from a bridge hack or whatever so the intention

of the hacker was essentially to uh launder the money in the Privacy pool then it's kind of sensible uh to Just DE anonymize this particular user okay obviously this is not so easy and um the decision process of what needs to be uh revealed and what doesn't is kind of complex but yeah the technical part here is that we need to add um some mechanism to the system that will allow to um de anonymize some users and the way to do that is

essentially for the user to include in every transaction not only the proof that the state transition is correct but also some details of this state transition uh so some details of the call data and the way the user does that is by encrypting this uh data using a specific key the key of the anonymity revoker okay so um in order for this to be efficient uh it's always good to instead of encrypting everything with uh one asymmetric uh encryption key just do it in two steps first generate a

symmetric key uh then encrypt the key and then use the symmetric key uh to encrypt the data this might sound a little bit confusing if it does I'm sorry but this is actually what happens uh in you know every cryptography application that you use so if you talk to your bank youve use DLS or you do essentially everything then you don't use asymmetric crypto all the time you just uh agree on a key using Dy Helman or something and then you use symmetric encryption right this is to make it efficient so it's the same here um so the challenge is um there are a couple

of ideas on how to uh do symmetric encryption um efficiently uh in a snark friendly way just uh we want you to implement one of these ideas um and that's that's that's essentially the challenge there are some resources on um what you can do um you can uh that there are some articles that we link and uh yeah the challenge is to implement it in Halo 2 great so are there any questions to for this particular part because yeah I I imagine this might be a little bit

confusing um so what you cannot do here uh what would not work is use a AES right AES is the standard symmetric crypto encryption that is used everywhere because this is a standard but obviously it is not good for uh snarks because it's it's not snark friendly you cannot easily write this particular function as an arithmetic circuit in a particular finite field so this is why uh it's maybe not so great but there are maybe other ideas maybe other encryption

algorithms that can be used um right yeah and by yeah I don't follow this only um sorry can you can you say it again yeah so the protoc Des yeah obviously I mean we are open to everything essentially as part of uh actually both our bounties it's just good to talk to us before you start

hacking and yeah we can we can uh find a good path uh for what you can build and yeah uh there are literally eight of us here today so yeah there there will be enough of us to basically take any question and answer whatever your doubt is so yeah obviously yes great um so let me now move to the product path and here it's also very flexible and you would like you just build something that is using crypto for

privacy so you have seen the ZK landscape in a previous talk it was very nice and in particular there was this uh uh this blob of privacy protocols um and I think it's pretty similar to uh to a blob saying clients say proving uh because for privacy uh you build snarks that normally hold some secret data and to do that you want the the the particular user to create the proof because if the proof would be generated by a server then the user would need to trust the server right so this is uh what we do we

do privacy and we would like you to build uh projects that involve some Secrets some clients sign prove it and yeah there are lots of different ideas uh there are some ideas mentioned in the materials that I will link in the last slide um mostly related to ZK games I would say but uh yeah we have lots of other ideas just talk to us if you have some idea and would like to refine it also talk to us uh this is probably the greatest way to uh to come up with something cool and when it comes to the Tex stack we

are kind of flexible um Alf zero is currently using Inc as the smart contract language but we are building an evm uh compatible layer um so we've thought that it's probably best if we allow hackers to use um any evm stock because it's just simplest and this is uh where the tooling is mature and where you can uh take a particular puth that is um well understood and and has been followed by many already so you will be able to find answers to your questions

and ask us uh ask other hackers about um some issues that you can uh encounter so the stock that we recommend is um the most popular one is writing um contracts in solidity um writing uh circuits so defining your uh relations in circom and using snjs to generate proofs essentially and if you like some other Tex stack but it also compares to evm then that's great um you can use it and it will be eligible for the

Bounty um we recommend people to uh deploy their projects to sapoia on ethereum or you can deploy somewhere else some other test net this is fine with us um yeah just use whatever you are comfortable with um so what we have prepared for the hackaton is a very simple repository with an example of an app using this particular stack so this is actually the link the QR code um to the repository and the repository essentially shows you uh the simple Le possible example of a

of an app which has this DK component this client s side proving component and yeah it's uh the simplest thing that you can imagine namely that you as a user um can prove that you know a factorization of a particular number that is posted on chain so there is a challenge posted um a number and you must must uh show its factorization factoring number is hard so this change makes sense kind of because the numbers that uh we allow in the challenge are still quite small so maybe not so challenging

at all but uh well this is just an example anyway um what's the project structure we have three things uh one thing is the circuit another thing is the cont contract and yet another thing is the front end and we'll talk about each of them separately uh for a little bit so the circuit this is the simplest circuit that you can imagine written in the ccum language so well what do we have here um we have um three variables a b and c and some of them are marked um input signal and some of them are marked

as output signal so think of the input signals are secret variables okay so we would like the user to submit the proof that they know A and B but we don't know we don't want the user to reveal this uh these two numbers right because yeah that's that's that's what uh want to do um um the user just wants to prove that they know the factorization without revealing the factorization that's what makes it fun at that that what makes the ZK technology actually useful here

so how can we do that um this is this is essentially the definition of the circuit um it's very simple one and um I can already um mention that this circuit is not entirely correct um that there's there's some things missing as we will discuss in a moment um because this circuit is just checking one constraint that the two private inputs A and B um multiply together give the public um input C okay but essentially all the circuits

that you will bu will follow the same shape it will be just more complex in what kind of constraints you have um and we have linked some tutorials some learning materials on circom that will show you essentially how we can build more complex ciruits great um then how is this ciruit used one place where this ciruit is used is is to generate one particular verifier contract so if you open the contract directory in the repository you have two contracts

there uh one is actually written by a human by us um and one is written uh by a program it's automatically generated from the circuit uh and this is called graph 16 verifier do soul and essentially the the main method in this contract uh is called verify proof and it essentially takes the proof um for a particular output and it verifies the the proof uh whether it is correct or not so inside if you if you go into this contract which I'm not sure I recommend there are just uh some calls to evm

precompilers that deal with uh elliptic curve operations um so the more interest interesting contract is the one that you write um it's where this verifier is actually used so here it's very simple um I just show you one particular method in this contract it's called solve Challenge and well you just point to a challenge that you want to solve and you provide a proof that this CH that that shows that you are able to solve the challenge proof shows that you know these two numbers A and B that multiplied together give

C and yeah there is some particular way how you need to uh break the proof into parts and how you need to plug it in into the verifier but this is standard and this will be the same for anything you build so you don't need to like learn why this and yeah yeah how it works you can just use the same code essentially um so gr gra 16 is uh has proves of constant size so no matter how the circuit looks like uh except for the number of uh outputs the proof will be the um the proof will be of the same

size so yeah it's uh yeah also this code will be the same great great um so uh then there is a front end and I would say the most interesting line the front end is um how you generate the proof okay because this is normally the um the most um challenging part um but if you use tjs it's quite simple I would say so what you need to generate the proof are first first of all the two private inputs in this case A and B you need something called The Proving

key which is generated uh in a phase called the setup um the setup for you know a developer deployment of contract is not a big deal you just yeah you just run some mocked setup um and it's fine for a real deployment in production the setup is act actually a big deal uh if you use grow 16 because you need uh so-called ceremony for that so there is a um particular secret generated in the setup that nobody should know unless they will be able to generate incorrect

proofs so we need a specific way of generating the setup to make it work but yeah we don't care about that here there are wellknown ways do that if you use grow 16 yeah you need to use a ceremony if you use plon uh then you need a ceremony but it's Universal so you can probably reuse some other ceremony and if you use Starks uh or harsh based uh snarks then essentially you don't need any setup so this is probably something you know just just a reminder and what this essentially does is runs this uh wor uh binary that is generated by um from

from the circuit okay again uh when you follow the shape of the project you will just need to edit the interesting Parts you will not need to like make it all work um yeah all these details because it's already there and yeah uh I guess for the front end there is uh there is is react used uh I'm probably the least uh um the least competent person to talk about react uh but I guess there are many experts here so yeah I I I don't feel um comfortable talking about react um so I

will not um and regarding this circuit and this example so um some two there are two exercises I would like to um you to think about uh one exercise is quite obvious because uh some constraints missing in the circuit and the constraint is basic the constraints are that both A and B should be larger than one otherwise you can just factorize as 1 time n right where N is a challenge so it's not very interesting if you add this constraints then you cannot use trivial factors anymore

and unfortunately there is another issue and this issue you will be able to understand only if you know the details the that the variables the signal variables are not like U one 28 or U 526 256 sorry uh they are finite field elements and this changes a little bit things and you need to be careful because overflow work uh very differently than than overflows on on variables you would normally use um so yeah you can think about it you can ask us if you don't know the

answer but um even if we add these constraints a larger than one B larger one it will be still wrong uh meaning that there will be still a way to cheat the contract to treat the verifier great so m um this is the um summary of our bounties uh so there is this hacker puth there's this product puth um hacker puth is more about working with Halo tool working with optimizing the browser prover time product path is building your own things uh you're are very flexible if you have your own idea uh

just come to us we can discuss or just start building because yeah there are no hard constraints here in the path um just build something interesting that t client proving um and yeah this is the QR code which has a document which has all the details uh mentioned about the bounties some more um information some materials for the hackers some documentation and so on so feel free to uh just CER and and see for yourself we will also post it on Discord and yeah this is the prime

source of information for our bounties and you should talk to us uh because we're here we are uh glad to talk to you and thank you that's all