Unveiling aggLayer: Smart contracts

Transcript

[Music] [Applause] [Music] Hello everybody. My name is Ignasio Ramos. I work at at Polygon at the protocol team and today we're going to talk about the the act layer. This track it's called built on Ethereum. So I will try to dive a bit in the smart contracts in the code and how does it work. But before this I need to give some context about the act layer so that everybody can understand better the the code. So let's go.

We only have like 12 minutes so I will go a bit fast. And this is I will first of all I will explain a bit how what is the a layer and why are we building it. Then the two types of actions that we support to be added to the a layer the PP and FP. And the points four and five we will dive in the code and we will see two functions. We will see a function that it's called to attach a chain to the act layer and also a function that it's called to verify the messimistic proof. We will check the inputs and a little bit in a very high level the code that's inside the function.

So first of all why we are building the a layer the problem that we are trying to solve is the fragmentation in the liquidity among all the chains that there are currently in the ecosystem. So what we want is to allow to bridge messages and assets between chains in a way that is cheap that is fast. We want this to make it feel like we are just using one chain. So for this we also need a very good UI and UX. But how can we achieve this in a technical way? What we do is that we deploy a bridge in L1.

This bridge is like the gateway to the a layer. This bridge holds all the value of the layer and we also deploy bridges in all the different chains. In a way, what we want is to allow it to do not allow a chain to transfer more assets than the ones that it has received in the past. I will go a bit deeper about this later as it's very related with a pessimistic proof. So once we have deployed all the bridges, what we need is like a ledger. We need a tracking of all the bridges that has been happening in the act layer and we need this information to be on L1. And how can we store all this information? There is a very famous structure that it's very used in

Ethereum which is the Merkel trees. This is the structure of the Merkel trees for the bridges that we use. I'm going to explain it a little bit. From one side we have the mainet exit tree. The leaves of the mainet exit tree um are the bridges that happens in L1. Here in this here is small we have another tree. It's the local exit tree. The local exit tree stores in its leaves the bridges that happen in each one of the chains there. So there is one tree in each one of the chains. When we join all these local exit trees, we have the rollup exit tree that gets all the trees of all the rollups. And when we join these two trees, we have the global exit tree. The global exit tree completely defines all the bridges that has

happened in the act layer in a moment of time and we need to move forward in time. That's why we use another one another tree. It's called the L1 info tree. The L1 info tree we use it to move around the global exit tree in time. So in each one of the leaves of the L1 info tree, we have a global exit route. For example, in the first leaf of the L1 info3, we will have a global exit route that contains some bridges and in the next leaf we will have another global exit route that contains those bridges and the new bridges that have happened in a slot of time. So now that I have explained how we do to store all the bridges, let's see which two types of

act chains we support in the um into a layer. So we have two types of act chains depending on let's say what we verify uh of these chains. The PB chain pessimistic proof chains they have the minimum requirement to be proven to be part of the a layer. What we prove is the pessimistic proof. The pessimistic proof assures that a chain cannot send more value than it has received. For example, imagine that POS wants to send 10 USDT to the GKBM. We have to check that indeed POS has received this 10 USDT in the past and it has not spent them. We call it

pessimistic proof because we um we know by default that one of these chains can be unsown but what we don't want is that if one of these chains gets in risk the fs of other chains can be um can be involved. So uh each one of these chains it's submitting a proof the pessimistic proof to L1. But to handle this we need more information. the trees uh that I've been explaining before are not enough. So if we are going to store more information on L1, we need more trees. Let's see how the pessimistic proof it's computed.

We have these three more trees. The first one is the local balance tree. The local balance tree is in each one of the chains and it stores in his leaves the amount of token of each one of the tokens that this chain has received. The local exit tree is the one that I've just explained before. It has the bridges that has happened in this chain. And the nullifier tree, it's used to avoid double spending. In each one of the every time we add a bridge to the pessimistic proof, a new leaf, it's added to the nullifier tree to avoid adding the same bridge more than once in the pessimistic proof.

So let's talk about the different step different constraints that the pessimistic proof has. First of all, you have to apply all the bridge exits to the old local exit tree. It's this one. And you get the new local exit tree. After that, you apply the bridge exits and the imported bridge exit. It's like say you apply the inbound bridges and the outbound bridges to the balance tree. After that, you check the nullifier. You check that all these bridges that you've been adding have not been added before. And finally you check that there is no negative balance in the local balance tree because that will mean that the chain is spending more balance than it has received. So when you are computing the proof when you are doing the proof in the circuit this will

be like the hard constraints that you need to have to generate a correct pessimistic proof that after that it will be verified on chain. Let's talk now about the second action type. It's called the if EP. This one we are not only verifying the pessimistic proof but also verifying the state transition. As you can see this system it's far more complex. It has a lot of flows. It has a lot of components. Actually katana it's using this kind of stack. I'm not going to go deep on this because I could be like one hour talking about but in a high level what I will say that we using the opsin stack. So we have a opth that's generating batches. These batches

are the the opposition proposer generates proof of these batches and with the akit and the layer we are generating the pacifistic proof from one side aggregating it to the proof generated by the opi ops improver and doing the settlement of this proof aggregated in L1. Okay. Now these two points um here you have a quer of the code but well it's open source. We are going to go to the agllayer contracts repository it's in the aglier team and it's called a layer contracts and we will see two functions how to attach a chain to the a layer and how to verify the pessimistic proof. I will try to to use the laptop with only

one hand. I'm not used to this. So this is the call to attach a chain to the act layer. The first input is the well one of the input is the chain ID. This is just identifier of the chain and it has to be unique and the initialize I'm going to do yes and the initialize by action it's some bytes that depending on the type of action are used to initialize the rollup in one way or in another. So the important one here I want to uh explain more it's the rollup type. The rollup type it's a stroke that we have created to share some feature among different relaps.

Let's check one moment the stroke of the rollup type. Yeah. Okay. Yes, we have a lot of patterns that are legacy that are used while the CKVM. But the most important here in the RO type is the consensus implementation and the RO verifier type. The consensus implementation has the logic of the um of the consensus and we have for example a consensus for the PP that I've explained before and also a consensus for the FP and we also have the verifier type the verifier type is a num with three options the state transition is for change for example like the ZKBM the pessimistic it's for the one I've

explained it and the alayer gateway there is the EVP that I explained it also before included in this a layer gateway verifier Coming back at the end to the to the function here we do some checks of the input but the important block here it's this one where we are deploying a proxy of the roll app that is pointing to that consensus implementation. Oops. And finally here we populate the rollup data with all the execution of this deployment and the rollup type information and we emit some events. And here we are initializing the roll app. In case of the FE we just initialize the action manager. In case of the PP we are

initializing more information like some roles, the G token address and some metadata. Let's go now to the function to verify the pessimistic proof. I will go fast because I don't have time. So it's just this input the rollup ID. It's which roll up it's submitting the pessimistic proof. After this we have the L1 info3 lift count. It's the L1 info3 that I explained you before. We're saying that that you have to verify the bridges that are included in the global exit exit tree at this moment of the time at this snapshot at this you have to prove the inclusion against that tree. We have the new local exit route and the new pessimistic route which is

the result of the state transition. We don't need the old ones because they are already stored in the smart contract. Here it's the proof and the acting data. It's just some data that it's used for after verifying depending on the action. So um I don't have more time. So that's everything from my site. I hope more or less you follow me and well if you have any questions maybe now or later I don't know. No question outside please. We don't have time. Okay we don't have time. I will be here.

[Music] Sorry, but you Yeah, I