'Fast Withdrawal Schemes for the Optimism Rollup' - Bartek Kiepuszewski

a i think you've already made the intro but uh we have martech coming on to talk about withdrawal schemes from optimistic roll-ups so uh bartek you are already here and i'll i'll ask you to turn on your video and uh kick us off with the talk all right uh thank you very much and uh welcome uh everybody let me just share the screen um so good uh okay so uh let's just talk uh for uh the next 20 minutes um about how we can actually uh enable fast withdrawals for the optimistic roll-ups as you probably uh know for the optimistic roll-ups there's this big concern regarding the uh the time that it actually takes the withdrawal of funds and this is uh one of the main concerns or critics of this kind of a technique and i'd like to actually dive a little bit deeper so that you have all really good understanding like uh what exactly is preventing users from withdrawing in a short time frame and how can we actually alleviate this problem and what are the proposed techniques and solutions to this so a little disclaimer whenever i talk about the layer 2 i actually mean a rollup which is like a thing that you build on top of l1 and not the side chain um a little bit confused why some people including ethereum foundation they kind of call all the scalability techniques later too but just to simplify for me uh l2 is something that you build on top of l1 and it actually uses the security of l1 so a very quick summary i mean you probably must have heard already about the optimism and we've had some great talks and yesterday there was a fantastic workshop from ben and calvin from optimism team i have to admit that they got the picture wrong because the l1 is should be at the bottom and you build above l1 you build l2 so l2 should be on the top and they got it backwards but other than that let's have a look uh quickly what happens when the end user submits a transaction to l2 so there's the sequencer which is like a mining node on l2 and the end user uh when they submit the transactional to it gets bundled uh with a lot of other transactions and uh the whole bundle is actually included in l1 uh it's sent simply to to a smart contract on the one which is called ovm uh for optimistic virtual machine canonical transaction chain and you can see here in yellow that this is actually stored on l2 this transaction information now after a while uh the sequencer also appends uh what's that was called the state batch uh which is literally a new state route for the whole bundle so it says to us that if you were to execute all these transactions in a bundle you'll end up with a state tree with that root and anybody can check if this is indeed correct right so uh so when the sequencer sends the state to l1 it doesn't send the full state because there will be like a massive amount of data it only sends the other state route and as you can see this is very cryptic and we can kind of um trust the sequence said the state root is indeed correct and this is by the way no different from from l1 if you look at the ether scan of any block you'll see that there's also a state route of all the transactions like here 271 transactions included in this block and uh and we have to kind of assume that this is correct um there's uh this uh cool uh crypto economic game played between ethereum nodes it just does not make sense for the nodes to publish not the correct state route however there is no proof right there is no like a zero knowledge proof or anything like that you know if you're in l1 chain so this state route uh this is r1 and this is a very similar technique that's used by the optimistic roll-ups they just publish a state route of the l2 um so what happens after one week after one week actually the state uh this state updates it's just assumed to be correct uh that means that uh since nobody was challenging the state route uh the whole chain and the whole construction is assumed to work uh normally and we kind of trust that this may never be changed however if during this week uh somebody made a valid claim that this state is actually was actually wrong then we delete it right so this there's kind of a reorg happening here on l1 and of course on l2 as well but it's important to know that the reorg only is happening at the state level here but the original transaction is still here and this is why we call it a canonical right once this transaction is submitted uh to a chain to l1 that cannot be deleted by anybody because it's just baked into l1 and there is no way and this is guaranteed by a smart contract only one that this can never get deleted so the key side from all this really uh to to enable fast controls and also further uh cool features that you can build on top of optimism is that once the transaction is submitted it can never be deleted from the canonical chain and whenever we see this transaction here we can actually compute the state ourselves right we don't have to wait for the sequencer i mean anybody running a full node over l2 can look up at this transaction can actually read the canonical transaction chain straight from l1 and they can compute the correct state for themselves very much like you would be doing running the the full node on l1 so if you look up this transaction you can check yourself whether this transaction will actually succeed and if this is actually initiating a withdrawal transaction you can actually see whether that will succeed or not and whether the die should be sent to the user or you may get a revert right like an insufficient balance or whatever i mean there can be a lot of reasons why this transaction can revert uh but again uh you can check it yourself you don't have to wait for the sequence this is the yeah uh the clue for how you would like to approach the fast withdrawal scheme so uh to go into a little bit more details um there is this mechanism um in optimist optimism roll up that allows you to send messages from l1 to l2 and vice versa they do it by having two different contracts so one on l1 one on the two and this guy on l1 that allows you to send a message to this contract and this message will get uh relayed to l2 uh and vice versa if you send the uh the message to l2 it will get relayed all the way back to l1 and let's see exactly how it happens uh using the uh the actual bridge um a erc20 bridge as an example so we deployed two additional smart contracts so these are ours not from optimism right on l1 we've got the other l1 uh part of the bridge on l2 we've got the uh l2 part of the bridge and the user on the one would initiate the positive they would simply send a die to this uh this smart contract to this part of the bridge this will actually lock this die inside the smart contract it will invoke a method called send message and this takes two arguments uh like the destination and and the payload so in this case we want to send the message to the other side of the bridge right and the way it works it actually inserts this transaction directly into the canonical transaction chain it's kind of like almost like a backdoor if you like and you can use this vector for your transactions as well if you feel that the sequence is like censoring you or whatever but this vector is extremely uh important in the whole construction so the so this vector is actually used by the across the main messenger and once it's included now this uh this is canonical right this is as good as any transaction that was inserted by the sequencer inside the batch because of that now sequencer has no choice it has to execute this transaction because if it skipped the state would be challenged right uh so now this is very uh canonical so the sequencer has to execute it and execution is very simple it's just uh passing the the um the data payload to whatever destination so in our case uh it was uh to the dive bridge and the method was complete deposit the payload was 100. this actually informs the diode bridge to mint uh the equivalent of die the equivalent token for die on l2 and of course this token will be sent to the user right on the l2 account and i think it's important to know that this construction is 100 permissions like you know this bridge does not introduce any additional trust assumption there is no operator there is no multisig there is like nothing right i mean this just works and it will always work um so let's have a look uh how it works the other way uh it's a little bit more complicated we initiate withdrawal on the l2 bridge it actually burns uh the tokens on the two and uh sends the message the other way right sending the message the other way this guy the l2 cross domain messenger they have to simply uh put this information into its state tree that's the state on l2 and that's it they don't need to even issue any event or nothing like that it's enough to to simply update the state because this initiate withdrawal that will be eventually put into this update uh initiate withdrawal this um update transaction batch right so this initiate withdrawal will end up in the canonical transaction chain um then the state including this little message here will be appended uh to uh to l1 and now uh because we are not sure if this is correct now we have to wait right we have to wait through the the fraud proof window and um and once that passes anybody can actually pick it up and can relay this message to the across the main messenger right there's this little check inside this smart contract it actually checks whether the default proof window elapsed and if this is so it actually assumes that the state is correct uh the actual initiate withdrawal can be passed and uh and it's easy to imagine what happens next the uh this method is invoked on the die bridge and eventually the die is sent to the user right so so how do we actually deal with this one week delay and by the way um the frequently asked question is what if the state hash submitter one is actually incorrect and nobody submits the fraud proof right uh what happens then and the answer is that the uh the security assumption of the whole construction is broken right so if that happens we would need to basically shut the whole roll up and start all over and to make this construction fully secure we have to make sure that this section never happens so if the state is wrong uh somebody has to be incentivized to actually submit the correct state right to submit the frog proof all right so let's have a look at how we can approach the fast withdrawals from the very simple schemes to to schemes that are somewhat more complicated well like i said before anybody can look up this transaction as soon as this is actually put into the economic transaction chain and they can uh validate this transaction by simply executing it and uh looking up the the actual state so because anyone can check if this will succeed and or fail um we can introduce uh this little guy here um that we will call a liquidity provider and they can assist uh the end user uh how would they do that so imagine that the end user does not want to wait for one week right uh they have initiative withdrawal they can see this transaction on chain and now uh they have to wait right so the liquidity provider can come um to the game they can validate this transaction themselves without the waiting for the sequencer and they can offer this user the die or the token that will be withdrawn eventually after one week and um and if they have this die right now they can actually give this user that die and claim the original users die uh in a week right and note that because this can never get deleted it doesn't really matter whether this new state uh update from the sequence is actually correct or not it's it's completely irrelevant uh if i can validate myself the initiate withdrawal and if i don't make a mistake doing so i can be 100 certain that after a week the die will be actually released right so if we can find a way uh to make sure that this diary released to me i can make this swap and this is uh called the liquidity provider uh enabled fast withdrawal it's very simple uh to actually implement however it's got a couple of drawbacks well first of all it can be quite expensive for low liquidity tokens also the big withdrawals may lead to liquidity crunch because i mean maybe there's actually more tokens on l2 than l1 and if that's the case and if somebody wanted to suddenly uh remove all that liquidity that may be simply not enough liquidity on that one to assist such a huge withdrawal and also that probably uh wouldn't work at all for uh for nfts uh because these are unique right uh so unless user is with trying connect nft to sell it immediately uh this scheme wouldn't actually work uh however for a lot of use cases that uh could be actually quite good how can we do better well um now we're going to the the maker protocol make a protocol actually can provide a virtually unlimited liquidity a maker protocol can mint die using whatever is available as a collateral it's up to the governance of the maker protocol but it can actually serve as a cheap uh liquidity provider and the intuition would be to to simply mint die for one week and give that diet to the end user and after one week since we can validate this initiate withdrawal transaction uh ourselves this is almost like a risk-free loan right uh so it would be very similar to the flushment but for the duration of the fraud proof window not of one transaction like a normal flash loans or flash men's but the uh for the duration of the whole week will the mint die and after one week the dye will be returned and it will be burned um and we can go one a step further we can actually remove the liquidity provider and we can do everything in a smart contract by using oracles and it just happens that the maker protocol has oracle network and that oracle network can be quite naturally extended to do the validation of this canonical transaction chain and if that's done like this we can imagine that perhaps the bridge itself can simply ask the oracle uh whether the withdrawal will succeed and if the oracle says yes then it will simply release the die right so that looks very simple um it does not introduce any additional trust assumptions except for the oracles themselves but but this is actually important that this scheme is actually dangerous because if the oracle fails then this architecture can actually lead to a double spend and i don't have much time to explain why this is the case but i leave it to all interested viewers to sort of think a little bit about it but let's try to improve on this so now instead of just releasing the die we actually print or mint die in a microvolt right so the way now it would potentially work is that the user who would be trying to mint die now they would actually ask the bridge to to do the fast food troll and that bridge would ask the makerbot to die and again the maker vault will ask the oracle whether the withdrawal will succeed if the oracle confirms that this die is actually minted right so there will be some debt here recorded the original die still stays at the vault but the dye the freshly minted die can be released all the way to the user right and after a week uh the the die will be released now of course not to the user but the vault and it will uh erase the debt right so so that would work and the interesting uh feature of the design is that now if the oracle fails then the maker will have to cover the loss right and interestingly enough this is not any extra additional security assumption because the way the makeup protocol works today is that it actually relies on the oracle networks and the oracle failure the potential oracle failure is covered by the various mechanisms inside the maker protocol right so we're actually piggybacking on the whole micro infrastructure to do that and the good thing is that uh such potential failure of the oracle network that does not affect uh dye uses it will affect mkr holders and this is literally what the mkr token is for the only downside of this particular design is that it's not particularly flexible because the user to make a fast withdrawal they have to go to the maker vault uh every single time that's actually guys consuming so let's improve on that uh how about we actually tokenize the withdrawal claim right so instead of sort of going to the bridge and going to the vault the user may go to additional component which we'll call fdiminter f stands for a forward die and this represents a tokenized withdrawal claim think nft which says i have initiated withdrawal and i will get this amount of die uh in a week from from the deposit contract right so we will use this uh as a collateral potentially but we don't have to we can actually swap it uh with somebody else right and here the liquidity provider may be back in business we can create a sophisticated swap market we can create some additional secondary liquidity solutions around it and the users can maybe perhaps even bundle uh these tokenized withdrawal claims and use them as a quattro to to to mint um like a like a mint die in bulk if you like right and hence the gas fees will not be such a big problem here so this is probably the most sophisticated type of uh structure and construction uh but as you've seen i mean we can iterate we can build different type of bridges and and the last point that i wanted to make is that given the fact that of different type of bridges now you have to sort of realize that users will be able to actually use many of them with different mechanisms so for example they can use the dye bridge with our first withdrawal scheme but they can perhaps use some other type of bridge like a multi-token bridge and this uh will also create die on l2 right however these are not the same die they won't be fungible directly i mean you can easily swap them one to one however they can't be like mixed and matched because uh you cannot go through one bridge and exit through another bridge right so i think it's important for the community to realize that they there must be some sort of a social consensus on what is the actual diet token on on each of the layered tools and we i guess from the user perspective you wouldn't want to wait uh to end up in a situation where uh there are a lot of different competing die implementations right um so main takeaways um message passing from l2 to one is an oracle problem and maker already has an oracle network uh and die security actually relies on them so we can easily leverage uh this construction maker also has no liquidity constraints at all for die so there will be no problem of liquidity crunch and also this scheme can be used to provide dye liquidity to support fast withdrawals for other tokens as well it's a little bit different but it definitely can be used and we we were really happy to talk with other projects on uh how we can achieve that and also the last note uh we need social consensus around the issue of what constitutes the uh the real token on l2 so thank you very much and i hope i uh made everything quite clear and if you've got any questions i don't know if you've got time for them or not but that's the end of my presentation awesome thank you so much bartek and i guess as a bear market story i can share i don't know how many viewers realize but maker dao you know basically started defy uh when dai launched about three years ago that was the first you know decentralized uh product uh cdp vaults um and what's really exciting now about maker you know building this bridge and working on roll-ups is the original vision of maker and dye you know being accessible to lower income communities uh or you know just anyone who may have not had access to the banking system so really excited to hear maker focusing on that and making it affordable basically to do transactions with maker awesome so