Maze, CLI tool for building aggregation circuits for circom circuits | February 8, 2023 | 8:00 PM

single yeah so hi everyone so uh thank you for attending to this uh if KL online Workshop so today we are honored to have uh Jay to present to us about his project regarding uh aggregation and and aggregation circuits and Maze yeah so uh J1 known you just introduce yourself hello everyone uh I am John Jay you can call me Jeff short and yes if I work on United stuff I've been working with um previous students getting group now I've I'm searched to do working on Anonymous post box which uses which is a privacy sort of anonymous messaging app that enhances your privacy it does not tracks animated data so I'm working on that right now and that's it so my interests are xenologist proofs fully homomorphic encryption and homographic encryption yeah so let's get started uh oh yeah yeah yeah you can get started yeah okay great so uh the Meetup is about maze which is a CLI tool for building aggregation circuit for plant proofs so I'll quickly share my screen wait a minute share my screen is this visible yeah it's visible okay so um what is proof irrigation so as I understand that a lot of people are I think folks over here are familiar with circuits which is that you write a circuit for which you generate zero knowledge proofs using a specific scheme so the scheme could be got 16 or long and there varies are the schemes um so right now what you can do is that you can add a circuit have a single input and output that would be the proof now what if you want to aggregate of several inputs into a single proof and then use that single proof for verification of all the inputs and that is perfectly so what you can do is that you can take a bunch of proofs that you've generated on single inputs and build an aggregation circuit with which you can generate an aggregated proof and a verification of the executed proof would verify the rest of the groups which is what we use propagation now okay yeah so without proof aggregation if you use growth 16 that is a specific scheme for using which you can read 0 is synonymous proofs the execution cost on ethereum on L1 oh execution execution cost on ethereum is around 200 000 units uh 200 000 gas units and we called it a cost without any public inputs is around 128 bytes in case of plonk the execution cost is 300 000 units and the call data cost is not 400 bytes also uh just to be sure that I'm not speaking in blank uh how do you understand what what what do I mean by execution cost okay can you explain that I don't know yeah sure so basically on ethereum you have to run the instructions for the smart for the execution of the function in the smart contract and the execution costs something and that is the execution cost and the cost is charged in gas units which is what I mean by 200 000 gas units does that make sense yep okay uh and the call data cost is that you need to send the proof in the call data to the smart contract right so that the size of the call data is 128 bytes so the higher the call data is the hierarchy cost for the verification of the proof on on it on ethereum does it make sense so zklim has a question saying uh is it same like op code guess wait uh that's the question yeah so that's what that is what I mean by execution cost right because every instruction is awkward and every op code has a corresponding gas unit charged with it so that's what I mean by execution cost you're right so okay so yeah I'm not able to go back for some reason um yeah so in case of you should let's clear it as a new call data cost is 400 bytes and as I said before uh the hiring for you to generate uh to verify proofs on ethereum now in case of L2 l2s the execution cost is very cheap but the uh send the day let's so let's try out how does it work um to do that okay let me I'll stop sharing my screen and then share another screen to actually show you how it works does it works yeah yeah okay okay just give me two minutes um okay I think I should be able to do this let me do once and okay and my screen why am I not able to share this okay is advisable yes it's visible yeah okay so for the demo I will be using the readme that is there in giraffe me so I'll open the repository of maze uh wait a minute so this is the repository of Maize and then I'll be following this readme that you can follow anytime to actually um delegation circuit how Maize make constant responsible so um the property of constant gas isn't limited to Maize it's the property that you get with aggregated proofs so you can think of an aggregated proof as a single proof now what it has done is that it has verified a bunch of proofs and then created a proof of that verification into a single proof so verification of the single proof verifies the rest of the inputs so which is why and then you can just simply use the single proof uh on chain or the verification so which is why the gas cost does not scales with the number of inputs because everything is is present inside to single proof it doesn't make sense I'm asking uh lim if that makes sense if that answers the question cool okay so now uh let's get started with this so the way it works is is that you need to First install a specific Fork of star Js and then you need to install the May CLI tool to build aggregation circuit so to install the specific Focus managers you need to get clone this Repository and then install it what I've done is that I've actually downloaded it beforehand is my uh vs code visible uh yes it's visible okay so uh I've already cloned the repository of snog JS and then let's install this Repository um what I'm going to do is uh CD and started is uh so I I think my terminal is visible right uh yes okay so what you can do is uh first I'll run in trim installed and then I'll run npm run build and I think it's what's the command for this npm down build CLI so what it does is that it will build the CLI tool of non.js and then I can install it so sudo npm install global I need to put in sort of flag because I'm installing it globally and then install it right so the tool has been installed let's just verify it once start.js so how many how many of you are familiar with this uh CR2 so uh as I said before uh hi so I've been using that okay so to repeat the question is that can aggregated proof be reversed or deconstructed back to the initial proofs uh I don't think so because that would that would violate the properties in our knowledge right so in zero knowledge the verify cannot learn anything I don't think that's possible yeah so does that answer a question um okay I think it does okay so how many how many of you are familiar with this particular tool um structures I am not really familiar with this but yeah I'm going to carry on okay so what you can do with snog JS is that you can write a circuit in circum that is uh yeah so circum is a language in which you can write R1 CS circuits and what is a circuit you write circuit to prove a computation so but it's not JS you can set up the circuit for a specific proving scheme it could be growth 16 as you can see over here or it could be block in case of maze we only use block so we set up the circuit for Planck and then build the equation circuit using maze now in this specific focus on objs you would see that I've got an additional command called plancks and a maze so what is planck setup maze using this particular command you can generate necessary files for your circuit so that you can build aggregation circuit inside base so and any files that it generates are the verification key for the bronc um the proofs.json file that is a bunch of sample proofs and the corresponding bunch of public signals to public signals file and then you use these files to build the circuit inside maze so first I would create a circumcocket and then Carry On from there so let's just create a new file s the kit dot Circle and uh I will paste circuit so this is a multiplier circuit that I'll be using so just verifies that this particular constraint holds so this is this is the circuit I'll be using and then I'll also download a Tau file so do you guys know what is the top file no for me no for me as well um yeah so it's power supply so a top file consists of common reference string which is a CRS that is need for long scheme as well as got 16 scheme so it's just a bunch of secrets that you need to actually generate a circuit so yeah so I just downloaded a Tau file for 2 to the power 15. uh rows and basically what is water rows and what is this what is this 15 means what it means is that [Music] um you've got a big enough circuit which requires to the 15 rows to prove the competition now moving forward from here what I'm going to do is that I'm going to generate R1 CS file and as well as well as the possum file for the circuit for that is the multiplier circuit okay looks like there's something wrong ah sorry I should do it over here right so we just created a wasm file for the circuit and the r1cs file 50 socket and we can have a look of look over here now I will set up long for the circuit r1c is using the Tau file that I just downloaded and I think it already the wrong from folder just came towards right I'll just drag it outside and there you go and the setup runs successfully foreign [Music] create an input file which is input.

json this input file would contain bunch of inputs so it will contain different inputs for which I want to generate uh Z knowledge proofs using the circuit that I that I just created here foreign [Music] this and this and now I can generate proofs for these inputs using snog Js now what I'm going to do is that I'm going to take these inputs and generate proofs for them as well as publication files for them so that I can use those files inside maze so um and for that I would be using this command which is not just long setup maze inputs file which are the files over here and the wasm file now for some reason for the past few days because some incompatibility with wasm this command isn't working uh if you do this it will throw this at it but if you can actually trust me on this what it would do is that it will generate three files which are these three files the first file is the verification key for the prong circuit the second file contains two proofs for corresponding to two inputs that we had and the third file which is public Dot Public signals.json file um contains public inputs corresponding to the inputs uh inputs.json file now we can use these three files to generate uh to build an aggregation circuit for two proofs now let's head over to let's head now let's install maze tool so that we can use that tool to build a connection circuit and for that you will have to uh sorry get up any questions IJ uh I'm here again so if you don't mind if I ask a bit more fundamental questions so uh layer 2 solution has like under two umbrella that one is not one is stuck so under snap it has plong and a graph 16. and then maze is a type of tool that uses Plum that is easier for user to use is that correct did I frame it correctly Yeah you sort of framed it correctly up to the point so maze is a tool that builds an aggregation circuit for plant groups doesn't make sense or should I dig a d a big deeper uh maybe a bit people I think I'm slowly getting it okay okay so um okay let me let me think how to explain that um Okay so you know that you can generate proofs for a block circuit right um now if you want to generate 100 proofs you would like if you want to generate if you want to prove 100 inputs you would have 100 proofs right now what if we want to have a single proof for those hundred groups the way you do that is by building an aggregation circuit which Aggregates all those proofs into a single proof and that's it so make the tool for um aggregating those proofs into a single proof so it's I telling that this hundred proofs are proven correctly with just feeding one go through this aggregator which is Maze and then just shows that okay uh just one aggregate all the hundred proofs and then for the output will be a one proven proof right yeah so yeah so you have a single proof and once you verify that single proof all the proofs are verified okay okay so maze is the tool for doing that maze helps you to generate that single proof right okay all right and then it's using plong and then maybe just a bit deeper which is uh the song is a much new word compared to graph 16 is it uh yes Blanc is uh long skin was introduced and I'm not sure when when it was introduced but I think it was 2019 or 2018 I'm not sure but yeah much newer than God 16. but I mean they've got their own places their own trade-offs but yeah uh plonk opened up a new space about what could be done in terms of circuits like it it improvised a lot right right well thanks a lot thanks a lot so uh Vincent has a follow-up question so uh does this mean small things to prove increases security let's just be more things to prove increases security uh no um security it does not increase security because you're still using the same scheme so yeah no it does not increase security the security Remains the Same as of the framework that are using for building the ignition circuit okay anything else any more questions uh just another a bit more fundamental question just so I mentioned the execution cost yes I haven't written any smart contract to pushed to a blockchain so uh it's it the unit it's under gray is it oh it's or other units uh gray is the unit for pricing and execution cost s uh if you so gas units let's say my execution costs 10 gas units now gray would be that how much are you willing to pay for each of those gas units I see okay okay all right thanks thanks good uh yes so let's get back to the demo does it work okay I'll I'll get back the demo so to use maze you need to actually first uh clone this Repository and then install it so I've already cloned the repository here as you can see I mean I'm I'm right inside the directory what I'm going to do is I will first build it and then install it so cargo build um fillies so you would need rust to use maize or you can get a binary from somewhere else somewhere else so you just need a binary file that is the file for the CLI tool and you can just use that directly but right now I'm building it and then I'll install it so that I can use it um it is taking a while hmm any other questions meanwhile no yeah I think I have a question from my side so like that I don't think I'm uh explaining correctly about the security but basically what I'm trying to ask was that like since you have a lot of things to prove right then it means that it increases like there's a lot of like if you talk about a normal programming language it's like basically more proof it's like more if else statement is it like more if you're checking and checking because there's just a lot of proof is it uh so okay hmm this is the security of any single proof depends on the scheme since we're not changing the scheme neither is security nor the uh yeah the security neither increases or decreases okay and then like just wondering like why do we need a lot of proofs uh why do we need a lot of proofs yeah because like because like just now you said like only with one proof you can actually bypass all the proof right but why you do you why do we need so so many proofs like if it's like why not why not why not one for example and why does it need like a lot of proofs right uh so [Music] why do we need a lot of proofs it depends on the application to be honest so for example in case of scalability there are l2s like ZK avms they generate many proofs but when they have to submit the proofs on chain if they submit all the proofs then it'll be costly for them right so what they do is that they aggregate all those proofs into a single proof and then submit only that single proof on G does it make sense yeah it makes sense thank you so much yes which is why they're able to save a lot of cost okay uh yeah so it it finished what I'm going to do is that I'm going to install it in my path and this will install the mainclr tool in my PC so like one question so basically so that's why it's called like ZK Roll Up is it like you comp you're com compiling everything into one and you prove it at the same time uh ZK roll up you prove the batch at the same time I'm not sure if that is the only reason why it is called a CK roll up but yeah you sort of rolling up a bunch of proofs into a single proof okay thank you okay oh sorry sorry uh and and the the circuit it's the way that the proofs are being proven in it the scheme that you mentioned is how we arrive to prove that let's say a hundred things that requires to be proven so this the scheme is how we arrive to proof and consolidate aggregate into one with it uh the scheme is uh so this what you're talking about is the circuit aggregation circuit now the scheme is used for generating roofs sorry so the scheme is used for generic proofs for the circuit so you've got a circuit let's say uh you've written a circuit and it's an aggregation circuit now you will use a specific scheme like long agrot 16.

to prove that the competition that is done that is the the proof sorry the input that is used for a circuit is valid or satisfy the circuit right okay okay suicide to check the circuit weather is correct uh can you say again please uh so the scheme is like a way to check whether the circuit is has done its job properly yeah you collect on that okay okay thanks thanks because there's just too many jargon at every at the same time so yeah thanks thanks yeah if you if if uh if something that I say does not make sense please stop me right away and then ask me uh yeah so now this tool is installed and we can check that using the help command so you can see over here there are a bunch of commands the first one is mock setup mock setup would take the files that we have generated over here these are the three files and build an aggregation circuit for you and then run a mock proverb so mock prover is like approver but it runs a bit faster a lot faster than the actual proof because it not it does not generates an actual proof rather it just checks where the ignition circuit has been constructed correctly or not so you you use mock setup to check whether everything is working correctly or not um and the second command is generate evm verifier so it would build the addition circuit and output solidity byte code and then you can um the send this byte code on Eva on ethereum and create a new smart contract to verify your aggregated proofs on chain and then you've got create proof create proof is and you use create proof to create proofs for a aggregation circuit and then you can also verify the proof via and that you can also simulate verification of the proof inside the evm using this command using evm verify proof and that said you can create params as well which is not that useful but yeah you got this appear now for this demo I would stick to mock setup because running rest of the commands is much a bit expensive so I would check what are the things required for mock setup hmm so mock setup requires three arguments the first one is a verification key second is proofs which are the sample proofs the third is public signals which are the sample public singles and as you must have noticed we've got these three files over here so what I'm going to do is that I'll get into the directory of these three files uh wait uh okay art profiles and then yeah you've got these three files over here I'll use maze setup prove what was it set up setup oh sorry it was mock setup mock setup and the verification key proofs and public disease and then execute it so what this command does is that it will read in the files build the aggregation circuit for two proofs and right now it is running a mock program on the equation circuit to check whether this particular aggregation circuit is built correctly or not now you would notice that this addiction circuit only supports two proofs now what if you want to have 10 proofs or 20 proofs the trick in this case is that you actually generate the a green circuit for a higher maximum value so if you want to prove 5 or 10 or 20 proofs what you would do is that you would build an exhibition circuit for 50 proofs and then you can generate you can aggregate proofs up till 50 proofs so that's how you actually um use this in real life uh in in Practical scenario now uh you would notice that the ignition circuit was built successfully and it took 26 seconds now if I was creating a proof for the aviation circuit it might have taken around five minutes so you notice the difference between mock setup and create proof and that's it so that's the demo uh any questions foreign [Music] ER said we prove every time we need with the aggregator and then and then um to to send this one one proof to the on chain is uh is like a batch right uh we we aggregate all together and then send to the own chain in one batch and uh this is correct so my question is like there should be a buffer between the original source of independent um incomes and the aggregated one output sources for the aggregation so the I mean is on chain results and the uh sources can we have some difference so is there any like problem that because of this buffer can cause uh yeah you go ahead you were saying something else as well okay yeah sorry uh sorry to interrupt oh did I question properly that they didn't understand it I think what I um understand from the question is that uh you're saying that you've got inputs and then you've got a buffer uh I'm not sure what you mean by buffer uh so um for example there's this aggregator needs a multiple proof right we aggregate multiple proof so the proof itself can be uh Difference by the time right like we have to consider that and and this aggregator puts this multiple proof into one and then send this to the on chain right to use this I mean right yes you're right on that so it's like a batch so we we aggregate multiple proofs and then make this and as a one one uh one bet one proof yeah and then yeah and one one whole proof and then send this to the on chain but you're not doing this like every time the proof input was different like every time every single change can cause a badge to the on chain right okay not not because of you're not doing this right because of the guess or the computational power or so I mean yeah yeah if I can rephrase your question just just let me know whether I phrase it correctly or not I think you're referring to a specific context in which proof aggregation is used and that context yeah yeah yeah okay uh so okay uh the way it works on ZK roll ups in a very overview manner so sort of a very hand review manner is that uh you're gonna give your circuits that proved the execution Trace of the transaction yeah right so yeah that is one proof a single transaction resulted into a specific State change that is you can change it but but normally it works it works this way that oh like one transaction and one single change can cause a one proof right yeah now there are many ways to do it I might be wrong in cases where so the the different implementation but in a very simple manner you can think of it this way that one single transaction would cause a state change you generated proof for that state change yeah yeah now in a badge yeah you've got multiple people yeah so you prove each of them let's say you have 20 transactions yeah you have 20 proofs now yeah committing all these 20 proofs on chain will be expensive yes cost time 20. yeah using aggregation circuit we aggregate these screws into a single proof yeah so that the cost of proving a down chain is amortized among all these 20 proofs so rather than a single person paying let's say per proof the cost of proving a down chain is five dollars rather than everyone paying five dollars the five dollar is split among 20 people yeah and let's save the cost yeah so that's the point that I'm saying about the buffer so when you when you make a one transaction and send it to the Auntie directly then you can like reflect your current state to the on chain directly so there's no like buffer of the difference the state difference but if you're combine the 30 transaction 30 proof into one and wait until the 30 things 30 transactions can become one and then send this into one chain it it means uh the the there should be a gap between this one batch and the 30 transactions difference so I mean this this this this difference might change might cause a problem like um uh so you write on that there's a buffer but what happens usually is that if somebody can treat the transaction to the L2 yeah and in this case you're trusting the L2 to give you sort of light now you can wait for 30 minutes for L2 to submit the proof on chain for the state to be reflected right and it is possible that the proof might not verify and whatever information that you get you got right away is wrong so the difference in latency is sort of taken care by the L2 so you're interacting with the L2 it will tell you what the state is now until it is proven on chain you sort of trusting the L2 for whatever answer it gave you so like like there's a latency but we can like avoid the abusing case while checking the the timing timing when they when I send the the multiple batch to the proof to the on chain let's take an example just to make it easy um have you used uni sock oh yeah okay so unisop is a way to trade between tokens right if I want to exchange it for USD I can see it on Google now let's say there's a unisop on L2 zero knowledge yeah uh the way it would work is is that you would send the transaction to the roll up and the roll up would update its state right and you would see instantly that your ethereum has been converted to USD yeah right now the roll-up would take many transactions from many users and then aggregate into a single one to prove it on chain yeah right yeah in this case until it is not proven on chain you are essentially relying on the roll up sort of trusting the roll up that the state update that it gave you after exchanging ethereum to USD is correct but that doesn't mean that uh the roll-up can steal your money no because this state wouldn't be valid if it is not proven on change that you what would happen in the worst case is that you thought that your ethereum was converted to USD at some price but it did not simple as well it's filled with the ethereum okay so your like maze can be used in this aggregator like patch oh right in a more efficient way than previous one like that's that's the point of this demo right yeah uh it was a much more user-friendly way so building a market is expensive no not expensive it's hard okay got it yeah what we wanted was that the aim of building maze was that uh you you've already written circum circuits right now we don't want you to learn building execution circuit to build an engagement circuit for your circum circuits so mail is an easy way to do it it's a tool that Bridges the gap oh okay all right thank you sir sorry so zklim has a question it's like let's say there's uh aggregated proof consisting 100 proofs if I want to prove certain data between one single proof do I need to know what's the other 99 proofs too yeah is the question uh let's say there is an aggregated proof consisting 100 proofs if I want to prove certain data are within one single proof do I need to know what's the what are the other diagram proves well um you it depends on the circuit so it's very specific question so let's say you've got 99 proofs uh just just to uh be much more clear on this are you generating the rest of the 99 proofs are for the same circuit uh just a question back um just just so that I can get a bit more clear uh rest of the 99 proves to the same circuit uh Highland uh are you still there okay yeah so even if they are generated from different parties are they for the same circuit that means that are they generating proof for the same thing then yes you can sort of uh yeah so what you can do is that you can have a very uh okay so what you can simply do is that you can have a verification circuit for those 99 proofs and then a separate circuit for that one single proof in which you want to prove certain data I think that's possible yeah and then you can generate a proof for all of this at once but I don't think that would be that useful you can have a different circuit for that one single proof and have a irrigation circuit it will be it would be a lot more complex in that case but anyways yeah it is possible doesn't make sense what if it's a different from different circuits like would be yeah which you need to know like from each circuit like from each proof from each circuit uh well it depends so if you want to have an ignition circuit for two different proofs you can do that as well there's no issue on that so basically this two circuit you combine it and you prove once is it yeah you can do that okay okay thank you it's possible yes you you need to know the proofs of every proof to generate a valid proof for the ignition circuit yes that's true thanks no worries okay so uh yeah I was nearly done with my demo and now okay let's get back to the slides instruments Hey Hey sir can I can I question hey how do you aggregate this proofs are you making a marker tree or are you just using a linked list or like like how the structure is combined yes so um okay hmm so your question is that how do we build immigration circuit how do you like aggregate the multiple circuits how do you do yeah yeah using one okay so are you guys familiar with how does block work this is oh Paul long yeah oh no no not really but I've heard about it yeah okay so what I'm gonna do is that I'm just going to explain you how do you build a creation circuit for long proofs does that does it work okay okay okay so what is a plant proof a block proof consists of two steps so in order to verify a plong proof there's a cheaper part and there is an expensive part the cheaper part computes a bunch of data that's a prerequisite for the expensive part and the expensive part is called the pairing check which is quite expensive to do in the circuit does it make sense yes is it the difference between those the ceremony or like that there's a phase two for those Decay you're explaining different no no what I'm trying to explain is that a single verifier how do you win okay think of verification of long proof at two as a two-step process the first step is expensive it is it's cheap it's very cheap compared to the second step and the second step is the expensive part that is the pairing check okay okay okay so that that is how you verify a plant proof right a bunch of computation followed by a pairing check does it make sense so yeah yeah yeah yeah multiple multiple computation is a chip and then and then we do that then we do the expensive thing that really verifies things yeah so it uses the the the departs that you get from part one yeah to do the pairing check and if the pairing check is valid uh the proof is valid okay excellent so basically you're trying to say that when you aggregate the data is cheap but when you want to try to prove that those data is expensive no no uh I'm just talking about a single proof right now yeah yeah that's a single proof if you want to verify a single block proof that's what happens okay okay now in the aggregation circuit that Aggregates a bunch of long proofs what happens is that we verify the cheap part of each of the prompt groups we verified the part one that is a cheap part of each of the block groups so isn't it expensive it is it is not ex so the best part about a proof is that doesn't matter how expensive it is on the proverb side so I'm approver right if I want to prove something then it's expensive for me but the verify it is but for the verify it is not expensive because the proof is constant it does not scale with the amount of computation present there right doesn't make sense basically so like no matter how many how many prong circles there are like it was always like previously constants right it's constant in some way because the proof size is constant so the verification cost will be constant uh okay I understand the causes of verification it's awesome it's also constant okay okay with having more proofs you are making it expensive for the proverb like for example verifiers don't matter it doesn't matter for your favorite okay yeah because now for the verify it doesn't matter yep right okay what happens is that you verify within the circuit all the uh the part one of all the proofs that is the cheap part and then for the second part what it is that you accumulate the second part of each proof into a final accumulator and you prove that the accumulation is correct but you're still left with the final accumulator um this accumulator is making a such a Marco tree or oh it's a simple random linear combination okay okay okay thank you you've got a proof you've got a uh you've got to Define an accumulator now the verifier would verify the proof that means that it verifies that the accumulation into the final accumulator is correct and the cheap part of each proof is correct and then they verify separately outside the verification process verifies the final accumulator that is the single pairing check if C bearing check is valid rest of the position yes yeah yeah okay okay yeah that's okay thank you so much yeah so that was uh that is how an ignition circuit works now I just wanted to show you a few numbers um is this visible uh yes it's visible yeah so as I said before that it is good for the verifier because everything stays constant right the proof size is constant the call it is constantly on the verification part the cost remains constant but as the amount of proofs increase the approval cost increases so in order to generate an aggregation so aggregated proof for 25 proofs it takes 30 minutes using a 107 GB Ram like with a peak Ram of 107 GB on a pretty Buffy machine and for 58 proofs it takes around an hour so as you can see that as as the number of proofs increase the cost of generating an aggregation circuit increases as well yeah so that would be it from my side and then you can sort of scan this QR code for downloading maze or you can sort of contact me anytime on Twitter yeah so one question for me right uh so like when I'm thinking about maze so like this reminds me of a L1 chain called Mina so I think it's uh doing the same thing as well it's uh because it proving uh making all the proofs into one group and then uh submit it on chain right so like um so like like you said like the proofs like uh when the proofs are a lot it gets a lot of it gets more expensive so like uh that's the reason maybe one of the reason why uh the blockchain is quite slow so uh do you think that there's some similarities between uh mace and uh L1 Amina some sense um so in case of Mina as as far as I'm aware the way it works is that um you've got a single proof and then that's it that's the that's the blockchain and then every time when you do something there's a state change you prove that the state transition is correct from the last state to the current state conceptually yes they are aggregation aggregating straight transition proofs into a single proof so they're verifying that single proof would verify everything but in terms of uh technicality in terms of like the way they've implemented it is different but conceptually yes so any more questions uh from from anyone oh hi Jay hi uh repeats the last question for me uh so this a so I'm just wondering like for the layer 2 landscape right how you works it's uh like for example some of the uh zdk Roll-Ups like uh zika Singh stock net I'm sorry Start where those are the one that already did all these circuit aggregation for the user right so this maze in state is allow people to build their own circuit yes it's for Developers okay okay well just on the picture how where are all these uh technology is within that L2 landscape which is I think very fascinating thanks thanks nice hi I have one last question actually just wanted to know like what are what are Mrs May's uh future plans and goals like why are you trying to like achieve in the future with me yeah so uh the goal of me is is was to actually uh make it easy for developers to build aggregation circuits so that was the goal now the point is that there are better tools sorry and gradually their their better tools so so gradually we have better schemes for building aggregation circuit there's something called Nova because they're aware of it Nova is much better than I think in terms of complexity and competition then I'll share the link in just two minutes uh it's I be I think that it's much I've set the screen I've shared the link ah okay thank you uh hurry continue you can continue yeah so I think uh we've got better schemes coming up and it is getting much better as well other than that uh yeah so I think the gradual I think the future for Maze would be that it could be adopting these schemes ah okay I see thank you so any more questions from the from the rest okay so uh sorry you're muted shinkai oh okay so like thank you very much Jay for answering so many questions and I think all of us learned a lot regarding Maze and ZK as you know it's proofs in general as well so uh thank once again thank you very much so uh do you have any uh uh do you have anything to to say with us before we end this uh session okay um thanks a lot for having me it was fun too ah thanks Kim thanks for the comments yeah yeah okay thank you very much as well so uh right now I'm going to stop the recording