AggLayer Technical Overview: Present State and Future Roadmap

Transcript

Oh, can I start? So, hi everyone. I'm Jesus. I work on polygon on the protocol team and today I will explain an a technical an overview of the a layer what we have currently on mainet and when what we want to aim to do in the future and it works but so first a quick introduction in case that you don't know h what's a layer uh a layer we can say that it's a interoperability protocol uh to coordinate in settlement so basic using zero knowledge proofs so basically uh what we are doing is like try to coord coordinate the settlement of a lot of chains. And how we do that is like uh we try to uh to we let the chain

operators to define the chain security level that they want. But we always require a minimum which we call it pessimistic proof that I will go uh afterwards and basically uh what it does the pessimistic proof is basically try to h keep the assets from one chain like don't let other chains pull yours right. So I will go there afterwards but uh more or less is a settlement layer they all and all the chains share the same bridge interface and this makes very easy to prove h if to prove this bridge interactions and for instance to to to make this pessimistic proof. So how we do it? We have all the same bridge as I said all the all the same bridge

interface. H we do this zero knowledge proof that it's the minimum uh minimum thing that we need to prove in order to to protect all the chains and the clear note which basically it's um uh it's a server it's a it's a it's a service that coordinates all these settlement uh and send proofs to layer one. So I will explain a little bit more of the pessimistic proof. As I say the pessimistic proof is the common proof for all the a layer chains. So basically it's the minimum security warranty. So all chains in order to be in the a layer needs to verify this and basically this is a chain accounting. So what is the pessimisticity proof is basically checks the current balance of the chain checks

what's what are the new assets that the user sends to this chain and what's assets this chain sends to other chains and basically computes the balance and the balance should be always positive or zero right and if the balance is negative then the proof fails and basically this chain cannot cannot uh settle in that layer and this is like the minimum right with with this you know for sure that all the chains cannot drop pull other chains So you have you know that if you are on a chain on inside of the act layer as a user and you trust this chain because it has I will explain but it has some security properties. If there are other chains in the act in the act layer that are less secure it does not affect you

as a user which is one important property that we want to keep. And also inside of the pessimistic proof we verify an arbitrary proof that we call it action proof which uh it's defined by the chain operator can be anything and we are we are verifying it doing a ZKBM proof and how it works basically is like the chain operator can define whatever state transition function that they want to put maybe can be an ACDCA or can be um a full execution proof. to just a proof of all exce for example whatever and uh of course the depending on what what whatever the operator chooses it will have the chain

will have more or less security warranties but as I said as a user you want you will choose right if you go to a chain which has full execution proof you know that you will be secure because you trust GU or ref if you go to a chain that it's just an ACDCA then or a proof of stake or a proof of multiple or signatures then you know that your security will be less. H and but all the chains can can can benefit from being inside of the layer having this same bridge interface and having quick interactions but uh of course any chains will have different properties. Maybe the less secure ones will be cheaper and the more secure ones usually will be expensive or or slower.

Okay, so this is how is like our last schema and this is how katana works. I don't know if you heard about katana but we deploy a new chain like some weeks ago and I think today or yesterday they announcement that it's publicly launched and this is how it works uh as you see uh we have what we have a to the left thing to to the left side is the action proof which basically is divided into two proofs. Uh you will be used to that but uh we verify a lot of proofs inside of proof because the we are on the recursion era and and everything is verifiable. So uh you you basically split the whatever the logic you want improves and you verify all of them and it works. So inside of the XM proof of

the system that we have now we have the ops improve which basically we we run our op nodes we verify them using a library that sukin did using sukin technology sp1 and and with this we have a proof of op then we took this proof of op and we get the state roots of this proof of this of this um chain and we take the layer 2 storage of the bridge and basically match all the layer 2. Basically, we check everything that happens in the bridge in the storage and say okay the users send this trans these assets to this chain and claim these assets from this chain. So basically we

check what assets h this chain receive it and what assets the chain send it and we match this with the pessimistic proof. So basically what we are seeing here is like we have the minimum security guarantee which is the pessimistic proof that is the chain level accounting and the action proof is like adding security both having a full execution proof and then matching this full execution proof estate with the pessimistic state and finally after this this this exchange proof is generated it's verified inside the pessimistic proof alongside the the the other logic that I set and finally on the layer Okay.

Okay. Now this is a flow on what's actually how how the information flows from the layer one perspective. So uh how it works on layer one is like we have a layer 1 contract that is called rollup manager and basically it manages all the chains on layer one. So anytime you want to be added inside of the act layer uh you you you create a new contract which is called I call it actually smart contract a consensus orchain contract and there you put all the logic that you would that you want that it's extra right all these act proof parameters that I say that are alongside the the minimum logic and how it works is like okay you create a network you create your your own act smart contract and you are and you and

and you attach it to to the act layer and and when when when a layer tries to settle a proof, it will get the information from your smart contract and it will get your aggregation B key and the actain parameters. Uh the aggregation B key I don't know if you're used to to the ZKBMS but basically defines the program that you want to verify. So defines all the logic that your chain has uh alongside the the minimum which is the chain level accounting which in the case that we just see it was an opinion proof and the action parameters will be the parameters that you want to check and from your proof to the layer one. So for example if you are verifying an opin probably you will want to check the previous

state route or the previous block number. So you get some information from layer one which is there in the same parameters you choose whatever logic you want in this case uh we full execution proof and then this is retrieve it on layer one so as a user you are sure that once a layer is attached to the to the layer you know which security guarantees has you know if it's a full execution proof you know if it's a CDCI or you know if doesn't have more security guarantees and they just are pessimistic proof time. So I will do a quick flow now. Uh this here we have the user that sends a transaction to the sequencer and basically this updates this updates the op node state right. Then uh we have a

module that is called a kit which basically is the module that is in the middle of the basically the rollup stack and the act layer. This is a kit for example in this case it will have a somehow a module that it will be a roll approver which basically will will generate the proofs of this opin with this library and also with sync synchronize the bridge of this of this chain and with to these informations I can generate the proof that I show you before that it was the opinion plus the bridge proof and we'll send what we call a certificate in the act layer h any chain that wants to do a state transition. So it wants to update the state, it has to send a certificate.

It's like the transactions or or the way to say the layer that you want to update your state transition and basically the kit what we will do is like fetch information of the rollup stack generate the proofs if have to generate some proofs of the act in this case opin and send all of these to the layer all with all the proofs computated then the layer will check the proofs check that everything is okay and we'll accept the certificate and then basically the the state will be settled on the layer and afterwards the layer can send this certificate or uh a lot of certificates to layer one depending if you aggregate the proofs or not.

And this is the same data flow but a little bit more like expanded. I just did like a minimal one and this is on our docs and if you want you can check it like it's the it's the same thing but it's bigger and it's just a a quick reminder that you can check it on the docs and okay now that I explained like a little bit of introduction of everything now I I want to share what actually it's on mainet so what I explain is like our new system but uh not all chains use that because basically we are operating with a lot of chains and a lot of legacy chains and it's very difficult to update them all at once. So this is the current status of this morning of of the act layer. As you see this is Cardona and mainet and basically we have a lot of

baliums or ZKVMs that uses the Hermes prover in case that you don't know before having that layer we we we make an EVM Hermes prover uh which basically was an Azkm and uh and and most of the chains are these legacy ones that they don't use PP and all these systems but there are just plain EVMs and anytime more and the plan is to break all the chains to this system. We we want to create the change to the PP which is the next generation which is the pessimisticity proof that I just talked about. And the last thing that we did is the aglayer gateway change which basically is a PP but also has this

action proof that I I talk about and as you see we have tune right now which is Bokuto and Katana and Buto is the test net of Katana which is the new chain that has uh this full execution proof with opin and and everything and as you see this is the current state. So we have a lot of legacy things that we want to migrate. Uh we have this new system that seems to work. Uh the act layer basically coordinates all the certificates of all the networks and submit the transactions to the chain settlement and currently we are using only SP1 to verify all the proofs and this is related to the future state which the point will be to have more than more than one ZKBM uh to verify the proofs. So uh to both act improves and

to and the pessimistic the idea will be to have multiple GKBMS and in this way you can have more security for example following the approach of the beam chain where you can you can like you can be protected about soundness issues if you have more than one brewer that can prove the same thing for so you can have redundancy here or you can make a cost efficiency games because these provers are are advancing very fast and each day one is more efficient than another. So the best way will be like to to be able to verify everything with everything and and choose in the last moment which one is the the most optimal one. Right? So this is one of the points. Other thing is the proof aggregation even if something super easy we didn't focus on

aggregate pessimistic proofs and this is like something that we want to do uh now as you see before we don't have much pessimistic chains yet. So it was not a a priority but uh now it will be because now we are starting to have more chains. So uh it's something that it's very doable and very and we have shortly and finally we want to focus on preconfirmations which this will allow this fast bridging fast secure bridge in between chains like you reusing this logic where you have the same bridge interface and you have all these settlement layer you can you can use that to have fast preconfirmations between chains and and to have fast bridging that probably you heard about it and that's it uh I have if you I can I can show you a a dashboard. Well, what

what I show you before, which is this, which is the the current I know it's not so it's not working. Just if I don't put whole screen, it works. But if I click here, the link will be leaked. Let's do it quickly. Uh so the the URL cannot be filtered yet I guess because they told me to not do it.

forget about the link and uh this is the current dashboard which is fetching just information from the from the from the layer one basically and and sepia and it's fetching like all the rollup information as I show you before and this for example is katana and here's how it was deployed and it was updated to a layer gateway to support opin and this is the certificates that I'll talk about which which basically this is a proof from the some block to some block and and finally you Finally, we we see that we have some activity today because I guess it's the launch. So, the people they they are working with I guess that they are playing with it. And now, yes, I finish. Uh thank you so much for the assisting the presentation.

[Applause] You have any question? No question. Okay. Thank you very much. Oh, my question is quite generic. If you're kind of creating transaction across different uh chains uh and it's need to happen like in in sequence what happens if transactions finished on one network but didn't finish on another one so that kind of the full transaction is not so finalized.

So you're talking about super transactions maybe. Yes. And as as unto like it's about like because you're doing with the ZK proof obviously there is no transaction here. It's only the proof of transaction itself. But my question is that if the transaction is quite complex and goes across different networks like coordinate that our current approach is it will be multiple transactions. So each time this transactions go to a different network it will be a different transaction. So it can revert in any time of the place. So imagine I I am on katana. I'm on one chain. I want to do a swap on another chain. Probably what I will do is like first interaction to to this this katana this other chain this unis swap. Then another transaction will

happen on the other chain and depending on the results the funds might return in one way or another. Right? So my transaction will always go through but then I will handle the logic in the next transaction of the of the next chain. Does this answer your question? Yeah. So we don't have this where you we block the state and we make a transaction which so I just was curious how you're addressing that particular situation. So you're kind of dealing with the state already like after right. So exactly and and if there was for some reason transaction didn't finish so it means previous steps already finished. I mean so you cannot return them. Yeah. So you can return it in application level not in GK level. I so your transaction will

revert but maybe you can have a smart contact say okay if this reverts just return the phones to the user and and that's it okay and if it's fast enough it it should not have much uh collision if you do it on application level I think okay clear thank you thank you any any question thank you very much thank