Navigating Risks of Layer 2s: The L2BEAT Approach | Michał Sobieraj-Jakubiec - L2BEAT

[Music] what are the uh sorry but how do we withdraw yeah so uh what do I mean about the validating Bridge so let's look at the rollup and the a rollup may look look like uh just a blockchain right like like a side chain to ethereum but it has this one very important uh important uh think that it connects to ethereum In This Very Special way uh and it connects to the to ethereum Via this validating Bridge right so when we zoom in to the base layer to our ethereum blockchain uh we can see that there is this smart contract or rather a smart contract system that's called uh the validating bridge and uh yeah rollup has uh rollup is is working somehow with this validating Bridge uh so let's uh zoom in a little bit more we can you can see that our FS our money that we put on the rollup from ethereum are sitting here uh somewhere in this in this validating bridge in an escrow contract and uh if we enhance here we can see that there is also some connection between the what's happening on the rollup and uh what the bridge knows about so basically we want to uh roll up in is is this this validating Bridge uh just needs to be convinced about what is the current rollup state so how do we withdraw from the rollup basically what we what we need here is we need this this rollup data and uh the state commitment and if we have the rollup data uh then we can prove to to to the validating Bridge uh that for example via VIA Merle proof because the state commitment is just a milker root of the uh of the of the state Tre we can prove to the validating bridge that we own some fs and this bridge will uh will release our funds to us so why are are those funds even at risk right like it's uh this diagram looks quite quite good here and the answer is because of the centralized op rollup operators and um this is uh basically where most of the risk fups come from but those systems are built in a way that uh that should not allow The Operators to act maliciously so uh let's let's let's let's look at the first uh at the first part of our of our risk framework so this is State validation what does it mean uh so what we want to answer in this uh in this column of our risk framework is is it possible to find to find out if the state is valid so I told you before that there is this state commitment which is uh a root of the state tree and uh this guy here in the mustache and big hat he is proposing the state that's why we call him a proposer and uh let's and the thing is that most rollups actually don't allow you to uh I mean roll rollups itself that's that's the that's the idea behind a up it won't allow you to to post in valid State because there is this state there are different state validation techniques uh probably you heard about them one of them is optimistic one of them is uh zero knowledge I don't I don't want to go into too too many details about them uh because the the thing is that this is the the oldest column of our risk framework and uh we are actively uh we are actively trying to improve it because even though uh here we we we show for example that ZK proofs are not uh don't bring and risk behind them that's not really true because you have to trust the MAF you have to trust that the implementation of the MAF was done correctly there is no backs and uh so we are now actively working on changing this this column and to to make sure that we actually put the trust assumptions there and not the the technicala we obviously look at the technicala but we want to uh make sure that users don't have to care about that the users basically want to know uh what's what are the trust assumptions there okay so we have the state validation thanks to the zika thanks to the optimistic fraud proof game we know that the state commitments is valid right uh so can we withdraw now not so quickly uh let's look at the the second column this is data availability and uh what we want to answer here the question we want to answer is can we reconstruct the committed state so uh the thing is that the state commitment here uh it's just a root so it's it's very tiny uh amount of data that's representing ginormous State the state can be a couple of gigabytes or uh but and it doesn't need to be uh held on ethereum uh but the the question is if we can reconstruct the the state so we can know the pre preimage of the state commitment so we can put a miracle proof so we can withdraw right that's that's our question can we withdraw our FS our our FS uh still safe and the thing is that if the rollup data is posted on chain and uh and the validating Bridge has uh like you know few few lines of code that and ensure uh that the state commitment can only be posted if the rollup data was uh was committed before so we are good if this if the data is committed on chain is posted on chain we know it's available uh but there is a drw of that right because the data availability on ethereum layer one is quite expensive so uh yeah let's let's not maybe maybe let's not pose the data on chain but let's just pose it at some on some cheaper server right and uh so we so we just post blogs on some cheaper server and then tell our base layer that yeah we have this data and it is available right anyone can can look at it and anyone can uh can can basically uh it will be made available to anyone but there is a problem with this solution because the thing is that it's it's putting another point of failure and it's here with the with what the sequencer is telling to chain it's basically saying that yes I have this data it has been available but B the base layer doesn't have a way of confirming that and uh basically the moment that this data is not available to us we cannot reconstruct the state so we cannot withdraw because we cannot put the meracle miracle root uh the miracle proof of of the ownership everything's burn Everything Burns in a big fire and uh it's called the data withholding attack which can be catastrophic uh but so that's why it's very important that right now that the data is available and right now the best way uh of ensuring the data availability is posting the data on chain uh right now there is also uh we can also post into into Data availability committee with which is basically the same as here but uh it's not one person uh promising the data availability but a multi so more people than one and um so it it's still like you know yellowish gray area there are other data availability solution and there there they are actually on the rise right now uh you you probably know about Celestia aail is coming near da 4844 and all that cool stuff if anyone wants to talk about that I'm very happy to do that because we are currently working on evaluating those and uh that's my goal here on E Denver to to learn more about all those data availability Solutions so uh if you want to uh please hit me up and uh I'm happy to talk about those but the thing is that right now uh we don't have good data Avail availability Bridges to ethereum from for example Celesta uh that's why we consider it R and uh but yeah hopefully soon it's going to change oh not this way okay so what what else do we have uh okay have you seen that that was s that was subtle so I lied to you on the very beginning and uh the thing is that the validating Bridge it's often upgradable as I say this is not a single contract but there is many contract that hold some logic inside of the validating bridge that are actually upgradeable and um yeah who thinks it's actually wrong that those contracts are upgradeable and the thing is that I don't really think it's wrong because you know ethereum upgrades and if you want to have uh a rollup that is AVM uh that is evm equivalent you will have to upgrade it after some time right uh so we just want to make sure that those upgrades are done in some very specific way that doesn't hurt hurt users and specifically they don't put the bridged founds into uh into more risk okay so that's the third column not of our uh risk framework this is called exit window and I want you to think about exit window as basically upgradability with extra steps uh so the F we want to think about the exit window is just a number it's the upgrade delay uh so we don't want to have instantly upgradeable contracts uh but with some delay for example 7 days 30 days with some time log but we need to subtract the permissionless withdraw Delay from that because for example with the optimistic with the optimistic rollups uh it's it's always 7day withdrawal time right with the casing era there is always one day withdrawal time you you you cannot get it instantly so uh we need to make sure that uh if there is uh if there is a malicious upgrade coming you can front run this upgrade and withdraw uh your fs and uh so yeah we decided on those uh on those days we think that that for for for this for that this exit window should be at least 30 days for uh for a mature system and uh less than seven days is unacceptable it's a there is no time for people to realize that and actually try to do something about it uh and the thing is that backs happen right and uh those those validating Bridges those are some of the most complicated smart contracts that are on ethereum right now um so there is a solution for that and it's called Security Council which is uh basically a very fancy name for a multis but a very nice multis so we want to have a secur SEC Council which is a big multi with high threshold with uh publicly stated people who are um or or companies who are uh who are assuring that they will never use this uh this power to to accept the instant upgrade or or or or roll back for example or or pause withdrawal something like that that and they will only use it in case of of of possible backs that can lead to stealing fountains by by somebody okay so uh two last columns are quite uh are more about liveness but the first one is sequencer failure so sequencer is this guy on the top with a mustache and the thing is that normally when we interact with the rollup we we just we just interact with rollup itself and it is centralized right there is one sequencer that's running a note and he's basically accepting those uh those new those new state those every new transaction he's putting them in arbitrary order and he can for example censor you maybe he doesn't like you maybe I don't know you live in different country maybe it's even illegal for him to accept your transaction because uh because you are you are censored by some other entity the thing is that it it loses the censorship resistance uh and but there is a very elegant solution you can do it yourself you can inter interact with the base layer with ethereum which is sensorship resistance right that's that's one of the thing about ethereum that we love that it is sensorship resistant and uh you can basically send your own transaction to the ethereum layer one to force the sequencer in some way to include your transaction um so and and thanks to that he doesn't even have like there is no point for him to censor you but even if he does censor you then uh then you can force him to actually include your transactions so this is very elegant uh there are some technical differences between self sequencing and forcing via layer one uh but but basically most of the rollups this is surprising uh actually have this uh this implemented uh I mean most of the top 10 but I I will not go to into technicala but uh but that's the general idea you want to force the sequencer to to include your transaction through interacting via layer one okay and uh the last part of our risk framework is the proposal failure so uh the thing is that something can happen to a proposer I don't know he goes to jail he loses his keys whatever uh and this is a liveness incident so so even though the sequencer is posting more blocks to layer one uh the the sequencer is posting next blocks to layer one the proposer is is not being able to finalize them to to commit to them and uh basically we cannot move with the rollup any further and uh basically What's Happening Here with most of the rollups they are just uh creating they have this this mechanism that if a proposer is inactive for some time it's uh ranging from one day to seven days uh this proposal role so this uh you know permissioned guy in the mustache with a big hat uh it becomes uh it becomes an open role and anyone can do it uh so this is self- proposing and there is also a different uh a different idea for the starx system and and and loop ring which is uh which is actually quite smart because it's not uh it's not reasonable to assume that people will be able to create the ZK proof this is very very complicated math and uh so what they are using is that that yeah you need to basically reconstruct the state and prove to layer one that you own some fountains that you did on own some FS so basically if the proposer is inactive or is censoring somebody for too long time in starx uh you can just stop this system and uh it's being frozen and it's uh it's not reversible and the only way to escape and everyone will have to do it is to use the escape hatch oh not this way again okay so uh this is all of our risk framework and uh you can sleep peacefully now uh so if all of those things are green hopefully in the future obviously our R Frameworks also uh includes bus but you should be able to sleep peacefully your fountains should be should be safe uh so uh this is it in terms of uh this uh our RIS framework but a little bit of History this is a historically inaccurate uh ex picture of how this risk Frameworks were created as uh as um internal internal work for maker Dow of making sure that you know the that the chains that the layer twos that D is deployed are are safe and uh this is how it looks right now right we have over 40 Projects there is 28 billion value Lo total value locked uh so if you are interested in that uh we are hiring and we are looking for uh developers and yeah that's it from me I think we may have time for one question yeah you have to shout I don't I don't know if we can do it actually you too far yeah just hit me up afterwards okay that's it thank you