DAPPCON 2024: PolygonAggregationLayer CrossChain Security Thru ChainLevel Accounting - Jordi Baylina

Transcript

well thank you I'm Jord valina I'm the technical lead at the polygon ckvm and and doing many other things in polygon and today I'm going to explain a little bit the work that we are doing in the in the for building the the agregation layer as many of you know uh polygon 2.0 is a kind of a constellation where it's not only the zbm it can be many rollups many layer TOS that can be somehow connected one each other the idea is that they share the same uh liquidity and that they this and then the idea this idea of composability between chains that the idea is that you can transfer value from one chain to the

other and then going back maybe in the same call with the synchronous calls so that the idea is that all the chains uh become very much like a single chain but by keeping the by by by keeping the autonomy of each individual of each individual chain and for that we need to build this system for connecting I mean for transferring value I mean for extending this bridge between uh this chains so um well uh benefits for that um cannot explain but you can I don't know but you can as an example you can have a uh

maybe one chain that's U selling hotels another that's selling plane tickets and maybe another that are doing insurance and you want to do a transaction that do the same things in a kind of monolitic things these things are are things that should be able to happen inside these inside these inside this chain okay so currently all all this is based in what we call the leel y bridge okay so let me explain a little bit of details how this bridge works okay so here the idea is that all the chains they have what we call it a local exit route I mean at this idea this local exit route is an Pen only tree that every time that some fonts exit from one chain uh they are

just added to this tree this Tre is in the panel you cannot remove things of the tree you are just adding things uh to the tree and all the rollups they have their own exit tree let me just see if the pointer works okay but the L1 is like another rollup I mean it's like another chain that also have their own exit tree and the idea so the idea is that of course when you deposit uh you deposit to that you are sending uh so um you are exiting so you are adding something to the local exit tree of the chain of the L1 because somehow you are exiting L1 to go to an L2 and then you recover in some of l2s and but when this chain wants to send something to another L2 they are just

writing this exit tree uh here okay so you you transfer to one to the other so the full idea of the rollups is that you just need to synchronize The Roots so here you have the global exit route which mainly contains is a tree that contains all the exit trees of all the chains and the idea is that you broadcast This Global exit route to all the chains and then once you have this you each chain can somehow uh use this part of the this part of the exit tree they mark it as use so that they cannot with rout rce and yeah that's very much how how this um uh this this uh Bridge uh works okay uh the leaves of this x3e of course can be nfts but uh can be r c20s

i mean can be any any sort of value or even some messages you can pass between the between the between the trees okay so well this is how actually works uh so of course course when uh this is a normal thing of a rollup a rollup uh uh when when a rollup sends fonts from A to B in general they are going to do it in the trusted state so sending the trees is just executing normal transaction in rollups these transactions used to be very few uh even can be about a second two seconds half a second depending on the rollup this is of course the TR State this is what very much what the centralized sequencer does then they exiting is very easy but when can you

use it in the other chain I mean if you are sending chains for you are sending funds from chain a to chain B when the other the other chain is safe uh to start using mean to withdraw this these these fonts and using well you need for this you need to this chain need to generate a proof this proof goes to L1 this when and this this proof this proof is included in the global xit Tre and once this Global X3 is broadcast is broadcast to the other chains then uh then the other chain can use it okay so you need for each chain you need to generate this proof and uh send it to to to to to L1 this is in the case of the Z W apps this proof time can

be well the generating the proof currently is about 2 minutes well actually with the with the last uh implementation is about 1 minute with the last generation of servers is uh less than 1 minute but it's still uh one minute and the idea is that the change they don't publish so we chain they they don't publish the this proof every every minute because it would be too expensive for this chain currently the Z GBM is I think it's about half an hour so one obvious uh solution to that and that's something that's well we are going to start very soon is the well instead of each chain having to publish each own proof on chain the idea is that

we can take all the all the proofs uh aggregate them together so generate a proof that proof all of them uh uh and then publish publish just one one single proof on chain this of course it saves a lot of cost from each uh from each chain because I mean this this cost is uh aggregated the fees of on L1 uh is just proving a single proof okay so and this is aggregated and this is much much cheaper but the interesting thing is because we are aggregating many proof of many chains that means that we can generate this proof much often so maybe it's we can uh generate a proof every I don't know every five minutes 2 minutes so and and this will accelerate a lot

this timing between one chain and the other okay and this is I mean this is version one version two this is very much what we have uh uh right now um uh uh on on on the polygon network but can we do it better I mean the idea is okay to many needs is probably too much if you want this to look as a as a as a single chain I mean the idea is okay we are many chains but users should see it like a single chain okay so well the first thing that we did in order to improve that but this is a little bit like a previous work and this is something that's really

important in the polygon in the polygon ecosystem at some point when we started the polygon EOS system we had like kind of a single proof that single proof that rules it all I mean it's and and a proof very much is a transition state so when if you have a zbm well you have very specific rules that are the zbm okay and then this is the specific State and if all the change they are following these rules then the system is safe because I mean you cannot I mean you cannot spend the funds of the other chain okay but here we are seeing and this is um one modification that we did uh time ago and that we are working really hard on that is that okay in the instead of having so one set of rules we we divide these

rules like in in two rules which are actually two proofs one is the rules that uh somehow um uh specify how the state transition function changes in inside your chain okay this would be the state transition function but then we have another set of rules is what are the rules that you need to follow in order to uh not affect so whatever you do in your chain does not affect to the other chains maybe you are screw in your chain but what cannot be possible is that you can in your chain you can withdraw the funds uh that you can withdraw the funds that are maybe stored in another chain this is something that this cannot happen and if you for

example you have like different state transition functions imagine you have a a z kbm but you can have maybe a zik wasam or you can have a maiden or maybe a a a U an application chain which a very specific State transition function define it than that and what happen if there is wrong I mean this can affect the full ecosystem so with this we separate this in two in these two proofs one is one proof is we call it the imaran proof or if you want the the cross chain accounting proof that actually guarantees that whatever you do in your chain uh will not affect the other chains and the other is the the proof of the chain I mean the proof that guarantees that your chain is is is is safe okay actually it could exist

perfectly in the system it could exist some chains that they don't even have a proof I mean they are on safe itself I mean I'm I have a chain that centralized that I'm deciding where the funds go well I could have that but this should not affect the other chains of course the people that want to use your chain it's your problem you're autonomous you do whatever you want in your chain but because you are in a community you are in another chains the is are what you waranty okay so this is an important concept that uh uh so this each chain needs to submit this this kind of two proofs okay so if we see the imaran proof mainly what does the imaran proof well the imaran proof well it mainly

what it do is it keeps a kind of an accounting of the full uh of the full system an accounting I mean here we have a different chains we have different assets and mainly what says is okay in chain this is the state I mean in the chain a there is that many assets of this kind for the people that's look thinking about nft you can think an nft like a normal token with a s with a total supply of just one okay but here is you need to keep a kind of an accountability where the assets are and oh W here there is some very light colors that difficult to see okay so uh so while let me just go uh let me just go to the next one so this the this

invariant proof so when when somebody when a chain submits a proof well here very much what you can you what you say is okay according according to this uh Global according to this uh Global accountability so all these uh so this state transition function and this is very much this local exit route I mean how many exits this differential exits this is what we call it exit route I mean this this this three of exits so how many EX so if you if you take all these exits all the fonts that are quitting this chain is do I have enough balance in This Global Accounting in order to send that if that's correct then if you know if you don't go

negative that means that this uh chain uh so that this state can this state can happen Okay me just go back um okay so we have this um well if you see this is in the the in the top we have a a single chain this chain is is is changing I mean it's having different local exit Roots I mean in root one 2 three in each one we are adding more exits and we have this exit a which is the differential of each chain and in the second is we have another chain of course it can be in different have different blocks so we have this this idea of the chains okay and uh well um so in order to coordinate here

the the full idea of the of this piece of the aggregation layer of this version three of the aggregation layer is to have this kind of coordination layer means having a would be a consensus layer uh should go relatively fast and here is where all the chains actually it's not not necessarily needs to be a blockchain but uh let's assume that's uh kind of a blockchain okay uh so the idea is that the different chains they can uh submit this uh this new state okay so they submit the state they submit uh uh what which chains they are the state route the local exit route which is State Route I mean from the aggregation layer is very much informative I mean

the important part is the local exit route because this is very much what I want to guarantee the Lo the the state route is very important for the for the for the for the for each state for each chain but not for the for for the gener for the for the full system okay and of course it it includes a proof okay a proof of this of this commitment okay um and then here in this chain the idea is that each each each uh each uh well each chain commits to this network and when when I'm saying this each chain I mean it can be anybody here of course there is some incentives that we will talk a little bit later okay but

somebody change and guarantee that this is belongs to change so they commit to this new state it's not on the commit they prove this new state okay and uh of course uh every time that uh every time that the chain commits uh to a new estate this x is history I mean all these um differentials on this local estate they are somehow stored in a in a in a in a in a tree that looks like very much like this I mean I'm just taking all the so for every time there is a comit I'm just keeping this accountability in chain a local exit the local exit Roots the state roots and the um uh the exit routs I mean this differential part this differential part of the local of the local exit route

okay so I'm keeping this and I'm Rec light this and I keeping this men the blockchain that's just keeping this uh this this this track okay so the proof so the proof what needs to do the proof well is this um crot chain accounting that internally I mean this is going to be a recursive accounting with this croch chain accounting also will uh will prove the state transition function but this again this state transition function can be anything even can be a do whatever you want I mean this proof this is going to be parameter for for for for each chain it's going to be kind of a parameter that will chain will be able to control uh auton autonomously okay so they are proving

that everything this is work and given a global exit route at a given point all this happen of course this Global exit route this this Global accounting route it can be relatively old so here I need to also include all the this ex history all these new events that happens that happens there in order to prove because maybe I don't at that point I didn't have enough funds to leave so I need to add other differentials in some other states in order to be able to in order to be able to to to to exit okay okay this is I mean the problem here the problem here is that the big problem that we have

here I have three minutes only okay the problem that we have here is that uh I mean uh maybe this proof becomes a little bit complex because if the uh last accounting I mean if the last um um snapshot of the global accounting is very old maybe I need to include I need to prove a lot of these exits that are in the future okay so here it can be uh one way to solve that is by having another proof that we call is a kind of a consolidation proof that's very much just taking all these exit route so all this history so I have a new snapshot of the history of this route of all the all the changes that happen and somehow it

updates the global accounting to this is appr proof okay and this gives a new snapshot of the global accounting rout this can happen maybe once per day okay so it does not needs to happen in each in each in in each uh place but this very much what it does it saves the it saves the the it saves the the the change I mean it change the the complexity of the proof they don't need to go very much uh uh backwards here is important to say that this model for example for Big Chain that they have a lot of TBL in general uh

they I mean they they can I mean they will not need they can use I mean they don't need to prove because they already have some phones maybe from other user so they this this this proof can be relatively cheap to generate okay okay another important topic and it's important this is uh different is because in this model okay we need to so in this model we need to to to White so for each chain so imagine a chain generates a new block but then the chain needs to generate the proof in order to be committed uh and and generates a proof for for the other

chain to happen okay so here we are a little bit in the same Paradigm uh on there of course it's a different chain they will not have to pay in L1 uh the same thing that in L1 but they have they still have this problem so in order to solve that here is U we have the option to uh that the chains that they so before sending the proof they commit to the state and this commitment of the state means that they cannot change this state okay so I can commit to one state and then another chain would be able to use that chain as far as they are following the other chain and they need to be to check they need to be sure that this state is valid and this is done

because they are running maybe a note from the other chain and checking that that this state is valid or setting in other words if a chain is able to build a proof for the other chain then I'm safe I'm safe uh to use that state because if the other chain doesn't submit the proof I will submit the proof because it's committed and it's committed here in the chain and this cannot change okay uh so this is the idea of the prec confirmations the problem I mean the problem of this model is that uh it it doesn't scale very well because if a chain wants to be connected to 1,000 chains then uh this chain will have to run uh uh 1,000 um nodes from the different chains which is doesn't

scale very well and that's why it's so important to uh have fast proofs and uh fighting for and this is the the huge improvements that are happening in ZK are not for optimizing the cost of the proof but but for for optimizing the the latency see how long it take the it take the proof and here is where Hardware acceleration will will pay a huge role in here and well this is where the things are are are are going for okay and the last uh and the last uh thing that I want to mention is of course this is a kind of a side chain and at some intervals maybe once per era in ethereum is going to be a kind of a consolidation with L1 consolidation of L1 is very much

you can understand these are like a normal like a rollup with a very specific State transition functions and this is very much what will be Consolidated in in L1 uh yeah with this uh with this is uh we can have would say here 15 seconds but this is probably pessimistic here we can have a fast with this system we can have really fast uh uh transfers of value which between chains this chain also will need to have all this incentiv layer here is where the pole token is very important because I mean how you pay um the provs and how you synchronize

the provs this also decentralizes the proving system okay so here we have a kind of this coordination layer that helps to to to um do these transfers between uh one chain and and and the other okay this is a little bit the road map I mean uh we already have the Al White Bridge available you can already use that we have this proof aggregation uh quite ready I mean this is a hope that in the next four we can enable that and we are working really hard in this a layer uh B3 let's see if by the end of the year we can we can have running I mean no commitments here but this is very much what we are working in polygon I have only like 20 seconds for a

question um but uh I mean maybe if it's a fast question like maybe I can take it but if not uh let's keep it here yeah I let's give it up for Jordie so we we actually have about uh four minutes for questions and this is the final Talk of the section so maybe we can get two possibly three if their quick so yeah any questions from the audience in maybe a little bit more of the details of how proving happens so imagine I've got chain a and chain B and we've got the global accounting route for chain a which tells me all the stuff that chain a has but now I mint a new token on chain a and I want to send that

over to chain B how how is the proof actually integrating the fact that this token just got created out of nothing on chain a how is the proof enforcing that I mean I understand if yeah this is very much this is very much in advance yeah yeah this is very much um this is like in general the tokens are like in layer one and in in layer one I mean you can generate a create a token in Layer Two okay but uh layer twos and layer ones for the bridge system there is no difference you can understand layer one like another layer two so the idea is that uh the chain the owner of the so the owner of the the chain of the owner of the token they can do whatever they

want they can mind so there is kind of an exception that the the I mean the exit tree of the chain that's owning the token they can do whatever they want in any case I mean if it's L2 that generating a token and of course if this if this chain is is is is bad you are going to be bad anyway uh the best example is layer one I mean layer one uh they can you can mine a token in L1 and you can transfer to other chains that means that in the in the loal loal exit root of the layer one you can add whatever you want and the uh the proving I mean the the proof allows you so in in in the I mean if we seen oh well it's

gone but if we seen the in the if you SE the leaf of the exit tree there is one of the fields that's the origin of the chain yeah okay and this is fun and this is important I mean this need this is important and this is much and this is included and take it in account in the in the logic of the pro okay all right thank you very much uh time for one one final question any other takers oh yeah up here in the front yeah I'm sorry if the question is uh redundant with what said because unfortunately I start the beginning of the I missed the beginning of the talk but is uh for for this system to work does that mean that every client running

the chain will have to add another client to run the aggregation chain if uh there is if you if you don't want to wait for the proof to happen yes if you have a proof uh then I mean you don't need to run because you already are proed here the problem is how long it takes to generate this proof and here is where it's really important to have proving systems that have very low lat latency and and this is what we're working on right now approve in the Z GBM takes 60 seconds in a CPU uh we hope that in the upcoming versions We can be few seconds and with the introduction of

Hardware in the ZK I think here we can go to really fast uh really fast proing systems and then we don't need we are trying to avoid that I mean that's the the full idea lovely okay uh join oh we do have one final but maybe you all can take that up after you want so let's let's give everyone else a Break um thank you for all of today's speakers and see you all back in here in about 25 minutes okay so we're going to resume at 4:35