zkSessions: Pratyush Mishra on Arkworks

Transcript

so hi everyone uh yeah again apologies for the various technical difficulties on my end but yeah i'm proud huge and i'll be talking about awkward which is our rust ecosystem for snarks this is the collaborative effort of a lot of people at berkeley as well as a number of external contributors so you can go to the artworks address to sort of look at our github people so okay so this uh i guess event has been more about sort of the uh you know a showcase of the different languages but artworks it has a framework to write constraints for snacks but also has sort of um apis and libraries for basically every level of the sort of snark stack so including um algebraic stuff implementations of snacks themselves and then gadgets and

constrained writing frameworks and then applications built on top of those all of these things such as implementation of sexy and proofreading data and more it's a little bit more detail so the bottom level of the stack you have the very core algebraic objects such as fields and elliptic curves and polynomials and efficient algorithms or all of these uh we abstract all of these away behind the generic uh behind generic api so that at the next level of the stack which is describing or implementing actual snarks you don't have to worry about the details of your underlying curve implementation or field implementation you can just be generic over the corresponding trade and then we sort of have a corresponding

uh gain system api that you can use to program uh circuits for these snarks and using this generic api we implement a number of uh cool gadgets for everyday programming as well as for useful cryptographic primitives and then we use these inside uh arc works to implement um some cool applications and external uh folks have also used it so for example cellular users are constrained i think framework too for their circuit of like batch verification of bls signatures yeah but in this talk we're focused we'll focus primarily on how you would actually do application development with artworks and uh mainly focused on the constrained writing portion so if you want to if you want to

write your own cool snark application right there's two components there's a you have to decide what kind of stock you want to use as well as uh you have to write you know express your application logic uh in some form that is understandable by the snark right so for the first uh choice you have to decide what snack you want to use and you have to decide what curve you want to use with that snug for the second thing you have to use these existing gadgets or maybe write your own gadgets to express your logic so let's delve into each of these steps in a little bit more detail so for choosing a smart kind of curve as you saw earlier we have these very generic apis that you can use to maybe have a generic snart crate and a generic curve trade and you can sort of

plug and play uh all the different various compilations as long as they're compatible so in a little bit more detail so let's say you have drop 16 right and you want to switch between bls 12377 to pw6 or any other you know pairing friendly curve uh to do that all you need to do is just change one type parameter you don't really have to do a re-implement plot 16 at all similarly if you want to switch between proof systems you can be generic over the kind of group system and all you have to do is switch out um the type parameter so let's say you know you for some reason think that kraut 16 doesn't provide uh enough um simulation extractability or you know non-malleability they can switch to cross smaller or now let's say you're tired of the burst circuit

uh trusted setup you can switch to marlin or in the future plonk just by changing one and then let's say you want to switch from [Music] polymer commitments within malinor within planck or any of these recent um polynomial commitment-based snarks again all you have to do is just switch out the type parameter um from for example cases you tend to uh proof space polynomial like in halo right so we make it easy to switch between stocks but like i guess this is like sort of the easy part the tough part is actually you know expressing your constraints um for your application in a way that's understandable by the snark and we've already been over

uh our ones yes they won't go into too much data but like the rough takeaway for rncs is that it's a sort of mathematical way of expressing computation which is understandable by snacks but the problem is that you know humans are not very good at writing math directly so you ideally want some sort of abstraction that allows you to write high-level stuff and that is human understandable and compile down to r1cs and to do that we provide a very high level and efficient constraint writing framework that uh it looks essentially like you're writing native code uh in rust uh but compiles down in the back end to something which looks like uh r1 which is r1cs let's uh delve a little bit more deeper into this uh backend on into this framework so we provide

within this framework a number of useful gadgets so if you want to do standard programming such as you want to you know have conditional selection or booleans or add unsight integers and so on we have tools for that we also have gadgets for algebraic objects such as elliptic curves and finite fields and then you can use both of these components together to reuse it to implement useful cryptographic primitives such as hash functions of various kinds signature verifiers local tree verifiers recursive slack verifiers and all these are implemented right now in our libraries and yeah you can use these apis to implement your own higher level primitives or to implement your

application logic so let's take a look at you know how you would actually use these objects right um and we'll do this via this example of current server multiplication so um at the top you have uh this cursor multiplication algorithm is some algorithm that is used within um uh i guess snap developments it's not really you know you don't really have to worry about too much what it does but basically at the top you have the native rust code which is what you would execute on your you know computer normally and at the bottom you would you have something which is like from the previous version of uh awkward which is very similar to bellman um but this is how you sort of express that logic in um uh yeah the sort of this older style of writing constraints

as you can see it sort of completely obscures the logic uh uh like the logic flow and which is happening in in the top uh code sample right it's very difficult to match the two and see which part corresponds to what so to resolve that in sort of our latest version of artworks we changed our apis and introduced new abstractions which allows us to use things like traits and overloading of operators to make the sort of native code almost match entirely with the constraint code right so there's uh only some russ technicalities which make the two different but otherwise it's very easy to sort of follow or to compare the constraint code to the native code and make sure that the logic is implemented correctly right and sort of the same applies for

we have very high level apis which match uh the rust code for something like a hash function to uh sort of this equivalent constraint code um yeah and sort of that's that's a takeaway that with our library you can you know write these constraints in a manner that's very similar to how we just write them for normal execution in rust uh so in comparison with like vs cells um there's some advantages and some disadvantages so the pros are you can because you're just writing rust you can just leverage properties of rust which include you know the very strong type system and memory safety and the great speed and uh the great tooling such as cargo and the sort of surrounding ecosystem of trades right you can also leverage non-determined you can just compute the

witness via normal rust and this leads to more efficient circuits some gear cells i think most essence that we've seen today they don't directly allow the end user to leverage non-determinism and support for debugging and profiling circuits um which we have to actually you know improve a little bit but it's it exists um and i'm not sure for existing dsls it's quite there yet the cons are that you have to well learn rust which is probably much more complex than learning um some very like a simple z uh dsl that's optimized for programming structs and on top of that you have to learn how to use our framework and the sort of surrounding apis but hopefully that's not you know too much of overhead um and we're still sort of working

out how to um uh be compatible with other ecosystems so you write your constraints and artworks and they plug them into uh you know some of the other proving backends that we saw today like aztec are halo 2 or so on right via zq interface but that might you might sacrifice some efficiency by doing that um i i want to sort of note that you can use the rest of the of artworks not you know everything below the constraint writing stack as a back end for for a dsl and as you saw earlier already socrates is uh has only integrated this uh noah i think there are plans or in progress plans to implement this um and leo as well i think there is a sort of

in-progress plan to do that so yeah your dslr could easily support uh artworks as a the proof systems in artworks as a back end okay yeah so that's it um there's the number of contributors worth it quickly as well as um externally with all kinds of experience levels uh we have a number of stars on all of our repos if you want to get started with artworks these are sort of the relevant links um you have to get github and twitter there's also telegram and recently at the zika proof workshop i uh i gave a tutorial um on actually using our framework to do a simple roll-up style application uh yeah you can take a look at that to become familiar with the ecosystem thank you