Building ZK App Chains with Mina - ETHGlobal Bangkok 2024

e okay uh hello everyone for the internet of verifiable applications and yeah let's get right into it um so what is Mino protocol how do you think about that the internet of verifiable applications um so what is exactly this step from trustless to verifier basically kind of you could execute code uh in like a Global Network without trusting anyone to actually execute the code correctly so when we now make the SE to verifiable we actually want to do exactly that but in a very succinct and efficient manner will execute our code in a trustless manner and anyone actually can verify that in a super nice way um all right so what concrete step did Mina now take to actually facilitate that um so until now kind of blockchain had their native execution environments replicated what does replicated mean in order for anyone to verify um what download all the data all the transaction that went in and execute them themselves to make sure the result is the same and therefore it can be trusted and verified so every Active network participant had to do that that obviously scales very badly so what Mina did is we took that that model that instead of everyone having to execute the same thing only the ones that are interested in actually knowing what that particular computation was um have to execute it and all the other one can verify a succinct proof of all the work that's ever been happened and make sure that basically every that allows them to basically accept the state of the network um so uh examples for replicated execution environments are like etherum Solana allows us to do that and in short that Z knowledge proofs um in our case that's kimchi kimchi is our proof system and we can use that to actually build the executed and proofed um and combine them together in one single proof so we can kind of fold everything together in one extinct um kind of package that doesn't depend on the size of execution that went into it and it has three basic properties um the first is distributable so that um to a lot of like participants and all of them can verify that statement in a very quick and cheap manner it's also privacy enabled so since mean we're talking about zero knowledge proofs and and one of the side effects that that technology gave us uh was that we can actually do private computation and make it verifiable afterwards which allows us to like not leak any data to to like a blockchain environment to a public network in case we wanted to stay private and the third property as I've already touched upon uh previously it's very succinct so basically means that no matter how much code execution you try to prove the proof of that and the verification it or the cost of verification it takes to actually verify that is constant size so it doesn't change um as that and what we took what we made with kimchi is we basically said okay that execution can be a blockchain and so we basically made the whole blockchain one single size proof and that means that basically the longer the chain Gets In traditional blockchain the state grows and the amount it takes to verify that blockchain also grow that blockchain and all the data this current state is valid without actually having to rerun all of that aesome um so if we have this trustless operation um that allows us to actually prove and then verify any computation on any machine in a trustless manner so why do we need consensus um consensus we need for basically three things one is finality that property basically says okay any computation that you made if you operate on like a global state that you guys or that anyone kind of wants to agree to um then finality says at some point I can make sure that that computation is actually something we call canonical basically meaning it cannot be roll like a shared database or like a blockchain um we want to make sure that anyone can actually participate so what censorship resistance give us gives us is that no single party or no bigger group of parties can actually um control what goes into the blockchain and what doesn't go into the blockchain um as I mentioned we are operating like a shared database on a global State and what consensus gives it it actually coordinates and synchronizes those operation in like a concise manner um yes all right so that consensus stuff that's not new um that has been around for 10 years or more um with all the blockchains that are out there so what makes our consensus which is verification based special um so uh the first thing is we Save A Lot on EX ution verification um previously I already said it two times I think we don't have to verify all the stuff that went into the blockchain um we can actually verify single proof of that if and kind of one sixing proof everything that goes into that will also become part of that sixing proof it means that having that I can actually verify any um and that in the end enables decentralization at scale um we can scale that system because our Hardware requirements and other things don't depend on the amount of computation that happens it stays the same and therefore like anyone can participate and it's super easy to join the network awesome just to summarize um Mina protocol kind of enables a verifiable execution environment and about building on Mina is by separating that architecture models into the application layer and the base layer so we already talked about like decentralization properties and we can build on top of that and the application layer is exactly that what gets built on top of dat and yeah do stuff like that that happens on the application layer um okay um all right let's look at how the application layer Works in this case um so what we want to achieve is verifiable and distributed computation that scales and there are three components to that um the application layer in our case we do something offchain and we then commit a proof of that that computation has been run honestly to the blockchain back and therefore can verify that everything we did was actually valid this enables us to like not be dependent on any gas costs or any like block size limit or anything like that because we can put as much computation as we want into that single proof and then let the blockchain verified um also all our as well so you can kind of think of this model of like public and private computation they kind of marry into each other on the application layer so you can have stuff private on your client side uh phone or whatever you can prove it you can execute it and then combine it with some public execution that kind of coordinates execution um you can build anything you want it can have any like it can have any logic it can have any architecture it's not like um con I don't know restricted by like any smart contract model or um bite code or whatever the um in a in a great manner um it also does proof accumulations since I've mentioned basically all applications become part of that six proof it also does it accumulates it basically verifies proof with proof and therefore kind of comes to that like prove Singularity and also the Bas layer gives us interoperability between those provable applications that we build on application layer we need some way to kind of for them to interact with each other and that is what the base layer gives us um so The Primitives that we have available at the base layout for actually achieving that are three um we have shared sequencing so the Mina protocol is kind of the this action reducer pattern we call it embedded which basically gives a Shar sequencing so basically users can use that as like the central liquidity layer so that we don't have liquidity fragmentation over like many layer twos we can have them in one place and then actually interact with them that way and the last part uh part is verifiable element so application this is kind of just the way we kind of think of kind of drawing that up on at the top we have the base layer that verifies our proofs we have things like yeah Salon we can build our application in and and those as I've already said can have like a kind of multiple faces right they can be like rollups they can be NPC stuff they can be like peer-to-peer multi Party U protocols um yeah stuff like that and the way those kind of interact with each other is by settlement um and basically kind of the from um all right um let's look at how we can actually build those those verifiable verifications uh verifiable applications um so how do we build on me protocol um just to kind of give you like a um circuits basically means your application your uh business logic everything that you write will get compiled to a circuit and that circuit is the thing that we can actually prove um they have some restriction they have like some uh some properties that we have to think about when when building L that we use to um build kimchi proofs and it's built by overlaps and it's typescript SDK that uh people can use to actually write circuits and we use it under the hood as well so that's something we have to um think about um and then we have this concept of public and private inputs also outputs um and what that means that basically basically if I have a program I have inputs to the program and I have some output from the program and we can kind of decide as a developer if we want a certain part of those uh inputs to be public and another part to be private and what that enables us ex exactly that um privacy enabling client side proofing all right um let's look at some simple example of how we can actually write a circuit so here um is one to that and creates a proof that it correctly added one um and as an output it outputs the new counter and the syntax we use for that is called Seer program is kind of the construct that we use to build circuits within OJs and so the first thing we do as the counter State that's the state we Define we say it has one value it's a u in 64 that means it's 6 we Define the inputs and the outputs then we Define uh one method in our case it's called increment and it does a very simple thing it receives the in like that's the thing in the in the method function it receives the state it computes over that state in our case basically two steps and the first thing is we need to actually take that secret program and compile it that means under the hood it basically translates that into that Circ take the secret program that we created call our function which is called increment with the input State and that's an asynchronous operations takes a few seconds and after that we receive the proof out of that which can then under there used to verify that proof um and see like if it's valid or not and that verified um return value that we get from there is in Boolean saying true if it's circuit that's a circuit that like does something it's kind of in on its own it doesn't really interact so how can we now kind of go from this simple circuit to building actual seek application chains where multiple users can inter interact with each other where we can build our applications um that users can use m user applications that then run on the blockchain and yeah under the hood it's powered by ons so all the base building blocks that we use and also how like the business logic is written is using ons and The Primitives that ons gives us um BR is and to end so like there's no no one that can actually or maliciously influence the result of any computation everything is kind of proven in Primitives so we try to kind of make the the framework as powerful and versatile as possible so you have a lot of tools that you can work with that actually help you um with building those applications and Abstract over a few things that are more complicated and and tedious to why do we need an R sequencer and the reason why why why the question is here is that produ kit has to be run by someone someone has to prove that code execution someone actually has to run the application to generate the proofs therefore that's some party right why do we need that the reason is execution orchestration proving is a tedious task um and also executing everyone's uh transaction in like a a I don't know sequenced manner is also something that's not very easy especially when you only have like circuit writing tools and like some protocol ad me offers so that's why we why we bu proit we want to make that as easy as possible um all right so how does the uh CK application chain work in practice um so it's based on validity proofs um that means that again everything end to end is proven um but compared to like other that again leads to that that there's no sequencer operator malleability so if if you are the party that actually executes your application um you have no way of kind of influencing the result and then we separated the and those kind of give us different tools which we can work with most applications will be built in the runtime so that basically says okay what does your application do and in the protocol you can customize how the chain behaves under the hood so like are the Annis how are Fields handled stuff like that goes into the protocol and then the sequences everything that goes on like API level interacting with database and stuff like that awesome so how does this C application chain work under the hood so we have a pretty simple workflow I would say um so just kind of the int tend to do something I want to swap this token for this token on a deex and users authoriz those authorize those signatures at those transactions by a signature so they sign the stuff they want to do therefore we can make sure it actually came from them and all right next thing the transaction lands in a me pool so the sequencer the one that operates the app chain um keep transitions are emitted what are St transitions basically they mean since we all basically the the the application operates in a global State transaction that come in and get executed can um change that state they can write to it they can read from it and every 10 seconds or whatever you configure it um they will collect it into a block so the block is kind of the Primitive that gives us those those containers of multiple transactions and therefore kind of allowing us to um yeah iteratively basically continue run just to again go quickly through it Alis here on the top left um it she submits transaction to the application chain manool the sequencer picks up the transactions executes them as part of executing it will emit array of State transitions those are executed by the protocol and then appli to like the global State all of that is proven and to end therefore like we receive a transaction proof we bundle multiple of those transaction proofs together in a block proof and that block proof G to the base goes to the base layer in our case uh Mina and gets verified there then the whole cycle starts again AL what I can prodate do apart from just writing super simple stateful applications it can do token bridging it goes out of the base uh out of the box with element and we have a archive node and a sequencer or ar arive node implementation that basically allows you to index all of the the stuff that goes on on your chain we also have a framework for processing that data basically giving like historical I don't know infogressive Graphics or have like a framework for for doing that we do proof paralyzation out of the box so that stuff actually gets executed very fast um yeah we also have devops and Integrations awesome so let's build it let's see how the code looks um for us it all starts with starter kit so that's a repo on GitHub you can get cloned that or useit um and clone it on your machine what do you get from the SAR kit basically a few things um the big chunk of your work will probably be in the runtime and that is part of an app chain so basically that that is what lives under packages chain source and there you can build your applications um configure your your sequencer do stuff like that um so all the logic goes into the app chain what also comes out of the box is a pre-built UI so it gives you kind of a a rough SC skeleton of the UI how you can like connect your wallet connect to the sequencer basically have all those those front and backend inter interaction we kind of build a template for that um all right so that's basically what comes with the star kit um how can we run it after we we uh buil the application uh we can obviously the first thing is we we have to do we need to install our dependencies after that we can can call pnpm Dev and it will spin up the U it will spin up the sequencer um hot reload stuff like that um how say you look that's how it looks um it basically gives you that skeleton that I talked about with a foret uh you can the first step thing you have to do is you connect your wallet in our case or wallet which is like the predominant wallet for mina um you connect it after you did that on the right top um St update there okay how can we build a runtime model so basically run modules are the way we build applications and how we structure them you can think of them like classes or like smart contracts and solidity stuff like that um basically it's built out of three things it has a class based definition it has stateful properties so state that you can write different things you have to you can choose to execute or not execute um we'll see how that works later let's build kind of a minimal example of the structures so we have a proposal ID um and and we have a struct to actually collect all the votes that we did so kind of a number that says how much voted yes how much voted no and then a proposal uh consists of a recipient an amount and the votes that have already been casted um all right so the runtime module um let's quickly go over that we Define the first thing we do is we have defined State on the r module so as you can see um just okay coming back to like the the cloud frame picks it up and then you can Define State like we see here so in our case we create a state map basically means kind of a mapping from like a number in our case to that actual proposal um we can call Stat map. from we assign it to like our instance variable um basically in our case says okay what is the address of the treasury where does that money live um all right also important uh we have to in Che the dependency in our case which is the balances module um it basically keeps tracks of all the balances that all accounts have on the app then we can create a runtime method um basically in our case what we do is we want the user to be able to vote and they vote for a specific propos yeah we can we can go into the code basically it's on code um you should see all the or or find all the examples in our repositories it's a very intuitive way to actually write um staple applications the state kind of gives us get and set methods so we can actually get and set State our documentation as well um another method execute executing proposal in case it passed all right we can also write tests um we use chest for that um it's like a native typescript uh framework we have like some utilities for that to actually test your code um create like unit tests for your methods see if they behave right all right um um you'll also find a lot of mina team members around the conference if you have any questions um also the slide should be available in that any questions if you want to try to build on Mina um we talk about the prices later on stage so yeah thanks for listening