 How to do Magia Aggregatio, the magical aggregation. So how do you generate a graph 16 or a plonk proof right now? You perform setup ceremony and then you set up for a circuit and then you prove a specific input on the circuit and then you verify it or regenerators already call data. And what does auction verification look like? Basically you have a verifier contract that verifies the proofs. So on L1 the cost comprises of execution cost as well as call data cost. But on L2 the majority of the cost is the call data cost. So for a graph 16 proof the execution cost is 210,000 units. Call data cost is 120 bytes. For a plonk proof the execution cost is 300,000 units and the call data cost is around 400 bytes. But what if we want to verify 50 graph 60 proofs on chain? It will obviously take times 50 right? There will be around 10.6 million gas units and 6400 bytes. But what if I told you that you didn't have to live in that world anymore? What if we could prove 50 proofs at the cost of 1? And yes we can do that and we can do that using aggregation. What is proof aggregation now? Basically you can aggregate several proofs into a single proof and that is it and that is what proof aggregation allows you to do. And how do you do it? You can do that using Maze. It's a tool that helps you aggregate individual plonk proofs that you can generate using SnackJS into a single aggregated proof. And why should we use it? Basically you will get constant proof size. That means constant call data of 4,3,2,0 bytes. So it doesn't matter whether you're aggregating 20 proofs, 40 proofs, 50 proofs. The call data cost will always remain the same. And the same goes for the same goes for the execution cost. That would be approximately around 600,000 gas units. So let's try it out. To build an aggregation circuit, you need a bunch of plonk proofs for which you will build the aggregation circuit. So we generate the plonk proofs using SnackJS and then we build the aggregation circuit using Maze. So I've already done the necessary setup for generating plonk proofs using SnackJS. You can see the circuit is here and we have the proving key file over here. Now we'll use the circuit files, the proving key file to generate a bunch of proofs for which we will build the aggregation circuit. So for that first we need to install a fork of SnackJS that adds this new command called SnackJSplonkSetupMaze which helps you output necessary files for building the aggregation circuit. So it takes inputs.json which contains several inputs for which you need to generate the proof. So over here we have two inputs, this and this. And then it takes the circuit file and the circuit.zk file which is the proving key for a single plonk proof and will generate proofs.json, public signals and the verification key. So let's turn this command and it will generate the necessary files. So we've got two proofs, public signals and the verification key. So now we'll use the maze tool to build an aggregation circuit. So let's check it out. So maze tool has a bunch of commands. The first one is mock setup. Mock setup builds the aggregation circuit and runs a mock prover on it. And then we can also generate an evim verify for the aggregation circuit and we can create the proof, verify the proof and we can also simulate evim verification of the proof. So for the demo purposes, I'll stick to mock setup because the rest of the commands are pretty computationally expensive. So let's just run the command maze mock setup on the files over here. So we have the verification key, we've got the proofs which we need to aggregate and the public signals. And there you go. So we build the aggregation circuit for two proofs and now it is running the mock prover. So it will take a while. Until then, let's just try to understand how does it all work. So basically, in the verification of a plan proof, you have two parts. The first part is the cheap part that performs the computation required for pairing check. And the second part is the expensive part that is the pairing check. So the trick is that in the aggregation circuit, we verify the cheap part of each plan proof and within the aggregation circuit, we accumulate the expensive part of each plan proof into a single accumulator, single pairing check, and that is the final accumulator. And we expose the final accumulator as the public input of the proof. Now the verifier will first verify the proof of the aggregation circuit and then we'll perform a single pairing check on the final accumulator. And after this, the verifier would be satisfied of the proof of the aggregation aggregated proofs. And that is it. So now let's go back and check whether the aggregation circuit was successful or not. And you can see over here it was a success and it took 22 seconds. So that means our aggregation circuit of these two proofs is satisfied. So now you might be wondering, okay, fine, we're able to aggregate a lot of proofs into a single proof and we're able to save a lot of lot and call data and the execution. But what are we incurring in exchange? The thing that we incur in exchange is the proof of cost. It is very comparatively expensive to generate aggregated proofs. So for 25 proofs, it takes 27 minutes and for 50 proofs, it takes 28 minutes on a pretty beefy machine. So that is it. And that is it from my side. Thank you for listening.