Building ZK App Chains with Mina - ETHGlobal Singapore 2024

[Music] uh welcome to the workshop um about Mina and prod kit and yeah in this Workshop we're going to show you how to build zal knowledge application chains on top of mina using produ kit and so yeah so basically the approach that we're going to take is we're going to talk a bit about like what are the properties and the characteristics the features of mina itself then going we're going to see okay like how can we leverage that to build nice applications on top of that and yeah what we can leverage to do that all right awesome let's start with what is min a protocol itself and we're going to talk about the steps uh from a trusted blockchain networks towards kind of the internet of verifiable applications and the technique we're going to use for that is Zer knowledge proofs I'm sure everyone has heard of that already um we're going to talk about that in more detail later on as well so basically kind of the big iteration that we're going to do here is we're going from trustless to actually verifiable and not only verifiable Al succinctly verifiable um yeah the first kind of big block that we're going to look at is is how like what our executions environment in this case and how we can use it for trustless code execution so so far every all the all of the blockchains they offered some execution environment um that uses this decentral decentralized property and the way they did that is by using consensus and blockchains to offer that replicated environment and what that means is that every Active network participant they have to execute the same code again and again to actually verify that it has been done correctly so and as part of that they have to store a copy of the whole chain state in order to be able to do that verification so um example of that our smart contract Serv for example and now what Minar is doing is actually offers a distributed environment where every participant can verify all of all of everything that's ever happened on that blockchain to just by verifying one consigned proof and kind of the step that you can we can think of here is kind of going from having like a monolithic layer one blockchain to doing Roll-Ups where only interested uh participants um can verify only stuff that they're interested in and still be um sure that everything is valid so as an example for replicated execution of environments for example ethereum is Solana is also Bitcoin or any other blockchain that we know that is out there um one of the most fundamental building blocks of doing that is kimchi which is a proof system that's native to mina that was developed by Mina and we can use that to actually create that execution environment that we talked about and as part of kimchi we also offer pickles which is kind of this technique for recursing over um kimchi proofs which allows us to actually and kind of have like it's basically infinitely recurs over a a large set of proof to that compress that into one single proof that everyone can verify in a Conant time and so we have three properties of Kimi here and the first is that is distributable so as soon as you create the kimchi proof you can give that any party and they can verify it independently and trustly it's also privacy enabled that means that everything that you execute using kimg um is private by default so that means that I run the code I create the proof of the code and all of the data that I have inside of that will never be leaked to any third party so it means that I don't know I can do my on my machine and I can only leak the stuff that I want to the third party and the third party can still verify that I did that using my um unleaked data without actually knowing the data and the third property is that ex synct six synct means that it doesn't matter how much computation I want to prove in the end I will always get a constant size proof that will never change its size and also that it's going to be verify in a constant amount of time it's going to take a constant amount of effort to actually do the verification this means that I can put infinitely many execution steps into one proof and only verify that which obviously has super nice scalability effects awesome so if we now have this nice proof system where where we can execute anything um we can also verify trusty why do we need consensus still because it gives us these three properties and I'm actually going to start in right here which is State synchronization we want to execute our code on a shared Global state where every everyone kind of can agree on on some source of Truth and some amount of data that is accepted to be true um amongst all participants um a second property that we get is censorship resistance so that we can through the consensus be sure that that basically everyone who wants to participate can also participate without kind of relying on a single party that can censor or allow or allow anyone in or allow someone not in um yeah also nice property and then then also finality which is coming hand in hand with that state synchronization property which means um after some time after some Network conditions um have been met basically we can sure that some computation some shared Global state is irreversible and will never be rolled back so now we can take these consensus properties that are true for every blockchain out there by the way and we can say okay like what additional um properties do we get when we um take that to the our verification based CK world right um so the first is execution verification and the big change here is that it's actually succinctly verifiable so we can say okay like we have this property uh we have this blockchain um it has the shared Global State and all this execution that has happened on there and in order for me to verify that that is actually happened and that is final um we don't have to verify everything that's ever happened we can only verify that single Conant proof in a constant time and then we have to proof Singularity which means that um everything that's ever happened isn't only verifiable um cly but it's also kind of compressed into this one proof that I can give anyone without them having knowledge of the current Network State and they can verify that um by themselves and also trust this Ste and all of that um leads into this model being able to do decentralization at scale um because we can fit as much computation as we want while still having this nice distalization properties of being able to run full nodes uh with minimal Hardware requirements at the end which is which enables a much bigger audience to actually run full nodes and participate actively awesome so basically just is that as a summary Mina protocols it has verifiable execution environment and has and it has a verifiable consensus that is because Mina not only um compresses all of the execution that happens on it into that consent proof it also um proves the consensus itself that means that we don't have to run the verification on the consensus we can also use the same proof and verify the same thing awesome so that was kind of a tldr of Mina and now we're going to look at our kind of model for building applications and we separate it into application and in base layers and kind of the separation of the responsibilities of those two layers on top of mina um so um the first is application layer and that is kind of the layer where our applications live where there will execute their code where there will store their state and everything of that execution state will be proven and then on the other side we have the base layer which actually verifies that execution and does some other duties of um accumulating those proofs and letting them interop interop with each other basically that that we can have application layers that communic communicate with each other and yeah are super interactive so the application layer and what properties do we have on on those um basically the way we build application layers are something that we call ofin compute which means that the code doesn't actually run on the blockchain itself but we run it outside of that we run it for like some time frame and after that we we create a proof of all of those execution and we take the proof we go to the base layer and you say hey we did all that um can you verify that that we actually did it correctly and so one one of the nice things about having this offchain execution model is it we not Bound By Any like G limits or block sizes or anything like that we can super freely and flexibly um design our applications layer to our needs as long as it's provable obviously and using that um we can then still doesn't matter what we actually did we can go to the uh base layer and say okay please verify this for me um our application layer obviously is also privacy enabled um since everything in kimchi is privacy enabled we also took that um and put it or kind of get the property for the application layer as well and as a additional property we also get that we can be optionally private we can have some public stuff some public execution and we can have private execution we can kind of freely choose um what we want to do in which part of our execution which parts we want to keep private and which part we want to um leave public and then as I already T touched upon uh it's customiz ible we can freely decide how we want to design that uh what we want to actually do and yeah then coming to the base layer um which is um kind of the the place where all of the applications layer come together where say like where verification happens and where a few of other things happen and coming to the um yeah the first one verifi scaling um that basically means that um scaling becomes an issue of the past because we took that model of decoupling the application layer and saying okay like do all of your stuff off chain and then only do the verification onchain and this means that obviously the scalability properties of that Bas layer become so much better because we don't have to actually run any any code on that we only have to verify it which makes it which makes it so much cheaper to do and therefore gives us Better scalability Properties the other thing that we do in a Bas layer is proof accumulation since we already touched upon Mina is a constant size proof um that means that all of the proofs that we actually give Mina to verify they also get merged and recursed into that conze proof so everything that is in the Mina proof is every application layer that ever was executed on that and then also we can use the base layer for programmable interoperability which means that multiple application layer can talk to each other through that base layer um yeah as and The Primitives we're going to use for that are sh sequencing we have a feature called actions on Mina which allow us to do something like sh sequencing where you have kind of this permissionless framework where sequencing happens on on the base layer and then only the execution happens on the application layer which gives us super nice sensorship resistance qualities the base layer will also surface the shared liquidity um for all this application layer where all the tokens live all the value is basically stored then only if you use an application you can go to the application layer and Bridge tokens in use them there but still have the security of the layer one and then verify element applications basically run off chain and then they need to have some point in time where they say okay like all my execution that I did of chain please verify that that's called settlement and where all that transfers happen and stuff like that it's called settlement and we use the base layer for that and therefore kind of inher inherit the security properties of the base layer awesome uh here we have some um basically um infographic where we show how that kind of can look and on the bottom we have the application layer and on the top we have the Bas layer and we can see that the base layer offers us some things for example sequencing settlement bridging tokens and then with the application layer that can have a variety of of impl a that could be CK roll apps normal circuits NPC computation peer-to-peer CK circuits whatever you can imagine and they can use settlement sequencing interoperability and liquidity sharing to interoperate with the Bas and have this kind of common subset um of Truth while still being having their own identity and their own um implementations awesome um that was kind of just a primer on what Mina actually kind of offers and on what the Val proposition is and now we're going to look at how to actually build using that model and we're going to touch Now quickly on OJs itself which is kind of the low Lang language that is used to build kimch circuits then we're going to go into produ kit and see how we can build application chains on top of meina um all right just kind of the uh a summary of of of yeah what are the things that we we need to actually build verif verifiable code and the first primitive that we have are circuits and circuits is kind kind of the description of the program that is then later proven you can kind of imagine this as kind of being a function um that outputs proof so you have a function you put a code in there and it outputs a proof of that execution and then we have o and which is our as as I already touched upon um lowlevel language to actually build those circuits and it's actually something that prot kit also uses under the hood and it's kind of this typescript SDK that you can use to really like super nicely and and and low has a really cool API that you can use to actually build those circuits and then as part of the the outputed proofs um that those proofs contain public private public inputs and outputs and these are kind of the parts of data that are leaked to the outside and then they have private inputs that stay private on the party that that proves them all right so let's look at a uh this code basically this code is kind of a low-level um or it's basically kind of what describes a circus in our case we want to prove a program that increments a count up by only one at a time um so what we Define here uh at the beginning is the counter state which is basically the state of our program and what we describe in the secret program is kind of a state transition from a input state to Output State it's part of the state we have a counter and as you can see here in like at the method what we going to do is we consume that input State we're going to say okay um we access the counter we add one and and we output that again and all of that kind of describes the entire circuit that is how it's done nothing else um yeah it has a method called increment data when we say for example we get the secet program which is kind of the the wrapper around those circuits we a count. increment and it's going to execute that it will output a proof and anyone else can verify the proof U yeah exactly that's how how we're going to use it first we we need to do a compile step which kind of comp files this program into that the more lowlevel language or yeah does everything that needs to be prepared to actually create proofs um then we're going to define the state we going to create the proof by calling the increment function and then we're yeah we we we get the proof and what we can do then in the next step is we can actually take the proof verify it using that program again and we get an output is it valid or is it not valid part of the proof by the way is public inputs and outputs as well awesome so how do we now actually take those that that programming model and how do we interact with the base layer in a in a way that's kind of has a Common Language and the way we do that is using smart contracts and that's a primitive that is also offered by orangs and it's used to interact with the Mina layer one part of the protocol are account updates and account updates are kind of these right instructions towards accounts so we're going to say okay like update the balance by subtracting 1,000 or whatever and yeah let's skip that for now um so that's an example of a of a smart contract um it has a slightly different API um as you can see we can Define State here for example counter and then when we we we have a method that's kind of that method creates a proof of account updates and what we're going to do here is we give it the counter proof and said okay um we started at a certain counter we called that function that's defined in that counter proof and we got that output and what we're going to do here is we first we verify the proof and then we take that onchain value We compare it with the input of the proof and then we're going to apply that output value to the unch state again same same thing here how we're going to use it and we first have to compile it we then going to instantiate it with some onchain address because the obviously that um smart contract has been deployed somewhere or in that case actually we're going to deploy it afterwards so we're creating Min transaction we're going to fund that account and we going to deploy a contract that's basically it um then after we've deployed it we can now actually call that smart contract function going to call count increment um we're going to make a get a pro out of that and we're going to create a new transaction that actually calls it the this contract gives it the proof that we've generated and we get a transaction from that we prove it we send it and yeah gets included awesome so that has been kind of a a small introduction to how we rewrite layer one programs but for this haathon actually we're going to focus on C application chains and these are going to be written with a framework called prot kit and that's what what I'm going to introduce now um so prot nutshell it's a it's built on top of O so it's powered by o it has the same Primitives it has the same structures um pretty much the same API as well um but what it now kind of offers is kind of this iteration top of the verifi verifiable protocol and execution and so everything in prod K is as well proven but we're going to use a more onchain based uh uh protocol and and framework for that and we have a lot of buil-in Primitives so that we can now kind of go to that application layer without having to build everything ourselves so we give you a lot of those toolkits um out of the box you could just reuse them um yeah how exactly we're going to see now awesome so now kind of the question arises um basically if we have the verif viable compute and if the base layer offers shell sequencing why do you need another sequencer reason for that is execution orchestration um these proofs in in and of itself are very power powerful to um basically prove State transition but as soon as multiple users want to access the same state get a lot of problems like race conditions data race and stuff like that so what we need to do is we need to build something that orchestrates these executions and that's what we do what we did with proit so that you don't actually have to do it yourself so how does it work in practice so everything in prod kit is again proven and provable that means that everything that happens in produ kit has validity proofs attached to them so you can kind of think of them as a secet rollup yeah um we take those proofs later and we give it to the Bas layer to them be settled there um everything in prodate is built in a way that the sequencer operator cannot actually do something bad they cannot be fraudulent because all of the circuitry all of the code is provable therefore they don't have any possibility to do something bad um we also separate that prodate into fre distinct components which are the sequencer the protocol and the runtime and so the way that works is that the runtime contains all of the application code that you guys might build um um the protocol then kind of has all the underlying circuits that orchestrate all of like the state rights the tree that's under the hood everything that's kind of not not leaked to the to the user side and then the sequencer does all of the proving the work orchestration um all of the kind of the devops that has to has to happen around that so like yeah most most most of the application will only touch on the runtime side um yeah awesome so how kind of that can a workf work or look like um if an application is actually written using prot kit um so everything kind of starts normal a user creates a transaction they only sign them they don't do anything proven there um they send the transaction to a men poool that's operated by the sequencer and yeah that resides in the men pool then what happens when a block gets created a bunch of transaction get collected they get executed and as part of that execution they emit State transitions which basically in our model means you have some State and that updates from a from value to a two value and all of those State transition also get collected and get proven based on a global shared State obviously as part of that block production that transaction are also sequence so they have an order which is very important because that way we don't have RIS conditions or anything else that we would have otherwise um exactly and then when the blog is proven everything gets put together um we get one single proof that we can then use to sell on the lay one so let's let's look at at at some more graphically um built um workflow for example we have Ellis here she submits a transaction to the application chains mol so then when a block has created the sequencer picks up those transactions and executes them and this is the part where we kind of split it the first is it executes the runtime so runtime basically means your applications code everything will be executed and it produces St transitions additionally to that the protocol get executed that's attached to a kind of transaction and it also emits some State Transitions and yeah those stats will will be proven and will be then um if you go to the right here um collected into the block proof and that St transition proof along with that transaction proof um yeah become the block proof and that then gets committed to the base layer to be verified what else can proit do um we can do token bridging we can Bridge everything from the layer one to the layer two um obviously as I've already touch upon sement um we have a buil-in AR node um that collects all the data that's has been here historically emitted um we can also process that data using our processor um we do everything regarding proof paration for you so you don't have to do that um we also offer kind of a suit of devops Integrations so you can host your application really easily on some server and run it in a production like environment aome let's look at how we can actually build application with that how does that look it starts with the the star kit that's s kit is a git repo you can clone it or you can use dgit here um clone it to your local um machine you install all the dependencies and you're good to go um what you get from the Star kit um basically what we wanted to do we want wanted to make the entry to protate or end to mina as easy as possible so we build everything that's used in 99% of the use cases just out of the box and we give you kind of a toolkit of things that you can you can work with rather way and so as an example in that is kind of the file structure that you get when you clone the the star kit and a big part of that is like the in apps SL web you get kind of a pre-built UI there will be a screenshot of that later and how that looks so we build kind of a really basic UI where we can kind of see the pattern how like the client and the server connect stuff like that we already built it here and then in package packages SL chain um we buil kind of the rough structure of an application chain already for you so as part of that we um we ready serve this balances module um where we kind of just just have a super easy example of like how balances work so here you can add balances to an account with a certain token ID um as part of that a think also as foret is also included so that's going to be important for UI as well so we have like some some basic configur ation basically that you can just get started right away you can just um start that actually running is as easy as that you call pnpm install install all dependencies and then call PNP pnpm Def and that's going to run the sequencer in the back end and the UI in the front end and that UI looks like that um we have some really basic functionality some block counter in the in the left hand side in the top and a connect wallet so you can connect your wallet in this case Oro wallet which is kind of the Mina um default a wallet Chrome extension and then we have a faet here you can connect your wallet and then get some some sample tokens and that's like kind of shows the workflow of of how you get from a A to Z and then you can basically iterate on top of that build your own application obviously delete all of that if you want um just basically to Showcase um how easy it is um let's look at how runtime modules basically your application code will be structured and and written um we have like basically three important Concepts here um runtime modes are class based so you can create your own typescript classes that extend the runtime module and you can orchestrate them based on that um we offer state for properties so you can define a state super easily on that and then run them methods which actually um run your code um we look at a really quick example here um um voting so here we Define some structs and doesn't really matter kind of running out of time so I have to speedrun this right now um so this is this is what a r model looks like we have an annotation here r model which defines it as one um we Define some State here which are proposals some proposal idea and then the proposal itself and treasury where we um kind of keep track on how much tokens we still have in there um then we created a function called vote and where a user can votee in a proposal so two arguments here proposal ID and the vote which is a Boolean um the first thing we're going to do is we're going to retrieve the proposal itself from the state we do this via this proposal get this is an Asing method so we have to wait that and then we do some assertions here um here in this case we we assert that it's kind of still in the valid voting period and after that uh we're going to apply that vote either if it's a yes or no vote to the votes that are are here we do that using approvable if that's kind of the O um pondor to to IFS themselves and yeah we're going to apply that and then at at the last step we're going to set that updated proposal to the state using the proposal ID again calling this proposals. set um yeah this is another one um I think I'm going to skip that for now um feel free to hit me up later to to get the whole example um yeah we can test them really easily um by using this test testing app chain thing that we provide um yeah pretty much the same as we saw before we call app chain. transaction we call a the the function and then from there we can do some assertions like did the state get update that what's the execution result was actually valid or not stuff like that um yeah if you want to learn more come to a booth or go to prod k.f all of the documentation will be there um yeah we will be here the whole weekend so we free to headit us up anytime you see us around um yeah all links are there Discord um docs website everything there awesome thanks for listening and see you around [Music]