dYdX Layer 2 Architecture

Transcript

hey guys i'm brendan from dydx um and my talk is just going over our architecture for building a layer two decks on ethereum and hopefully just give people a little better idea of um i guess what it means to build a layer two um and sort of the technical challenges that we've uh thought about while doing so um so first of all just going over the basics it's kind of like what do you what do we want to achieve when running in exchange in our case we're running a perpetual exchange where you basically deposit collateral um i have this point number two stuff happens so that's like

trading um funding payments which is sort of like the equivalent of like either paying or receiving interest depending on what your position is liquidations um basically everything that causes p l um and then sort of eventually you want to withdraw your collateral um after you've uh made or lost money on the exchange um so those are kind of like the basic steps or basically what we want to achieve is deposits stuff happens and withdraw so what does that mean so basically we are batching different transactions so these trades these funding payments et cetera into what we call blocks or layer two blocks um and

these blocks are sent to the layer one every so often um so we try to keep most things happening off chain and then basically putting as many things as we can into a single layer two block and then publishing that proof on chain um in our case we have on chain data availability so that means sort of uh before the state transition happens we post to the contract um all of the all of the changes to balances that are happening on chain and then also in a separate transaction uh a zero knowledge proof or i guess there's some knowledge because you have the entry data availability but basically a proof um that the balance changes happen according to some predefined rules so there's basically like

uh a sort of like smart contract enforcing this um this state transition please excuse my my dog sparking um so just going over sort of the transaction types that we support um the first is a deposit where you need to move your funds somehow from layer one to layer two so a user has to send a layer one transaction and this moves your collateral your funds into the layer 2 contract then as part of the block if this deposit transaction is included then it's basically moving the funds that are held in the layer 1 to the layer 2. so um in this first point the user is moving funds on the layer one and they

kind of get held in this escrow contract if you will um and it waits for the uh the pods that actually get included in the layer two to move the funds from layer one to layer two and sort of marks them as used on layer one um it's sort of kind of like a trussless guarantee if the deposit is not processed into layer two then after a while the user can just cancel the deposit and be like hey i want my funds back the other main thing that happens is trading users sign each of their orders so let's say i want to buy uh the btc perpetual um at a certain price um for a certain fee um and i want the order to expire after you know this many hours so a user cryptographically signs each

order with their their private key um and each trade will happen between two order between two parties who have placed their orders um and then we guarantee at the end according to the smart contract that each party is well collateralized so that just means they've basically posted enough margin you know you can't post ten dollars worth of margin and be trading millions of dollars for example there are price updates because uh we're trading perpetuals so everything is basically um uh you know trading on leverage using collateral um so you can update any number of different asset prices um this is just you know if you want to update the bitcoin price and ethereum price for example all of these prices are signed by

some predefined quorum of signers in this case we've partnered with chain link to provide that data and these are used for as i mentioned before checking the collateralization during trades to make sure all accounts are well collateralized also a thing for determining liquidations like can we liquidate this account and we can if the account doesn't have enough collateral for example and then lastly for funding payments which is sort of a perpetual specific thing and i mentioned that's sort of uh sort of like an interest rate thing which i'll talk a little bit more about later or i guess right now so the funding payments are basically specific to trading perpetuals and basically um in a peer-to-peer way all the people who hold long positions

pay short positions or maybe vice versa depending on uh basically uh how that how that uh how the synthetic asset is trading against the real asset so basically if a lot of people want to go long bitcoin for example then um then the uh the asset may be trading at a premium to the actual price of bitcoin and in that case people who hold long positions will pay short positions and that sort of provides incentive for uh the btc perp to stay in line price-wise with the ac with actual price of btc so there are certain rules enforced around this for example the the smart contract enforces the limit on the maximum funding rate that

can be paid so that you're not just uh uh that the layer two can't just charge an arbitrary uh funding rate on on people's positions um and as mentioned before this uses the oracle price uh the other thing that people want to do is uh withdrawing from the exchange of course so this moves the collateral from the layer two to the layer one um in this transaction um that gets included in the layer two after that block is mined the user must then send a separate layer one transaction basically to uh move the funds from the contract um back to their wallet or to another address that they want um so i guess the good thing about um kind of doing these uh zero knowledge proofs is that this happened instantly

when the block is mined so um this is as opposed to uh doing like an optimistic roll-up l2 um since there is a a proof that gets mined um and that says okay the state transition is definitely valid then the user can withdraw as soon as the the layer two block gets mined into the layer one but this still requires a non-optimal waiting period i think right now we're mining blocks at least every three hours but basically if you want to withdraw then you kind of you might have to wait up to three hours basically to send this layer one transaction after the layer two block is lined so there's something that we can do called instant withdrawals or fast withdrawals um and basically

uh these first two points are outlining um the mechanics of that all all it's doing is a liquidity provider an lp is will send the funds instantly to the user on layer one and the user will send funds to uh the lp on layer two so basically like for example p sends these are a thousand dollars on layer one and then the user transfers the lp a thousand dollars on layer two so the i guess so that's pretty simple but the kind of trickiness about that is just how do you do it trustlessly um or with in a trust minimized way um so the user basically off chain sends the lp a signed message that they will transfer the funds to them on l2 contingent on

this l1 this l1 transaction having gone through so what the lp can do is they send the tokens to the user on layer one um and through a specialized smart contract that basically records that this does happen um and then the lp basically forwards the signed message to the exchange and relies on the exchange including this uh transfer into the next uh layer two block to be mined and in that block it will transfer the funds from the user to the lp if and only if um this certain fact is registered on the smart contract that had transferred the tokens on layer one so basically to go back to these first two points the lp sends the funds to the user and then

the user sends funds on l2 if and only if the first point holds another action that can be taken is liquidations so it requires an account to be below a certain margin according to the oracle prices and the positions that that account has open and it basically decreases the size of a user's position by by decreasing by trading that position um against an open order so it basically if you have a long and you're liquidated then it sells off a piece of your position to another account that has an open order for that account so if someone else has a limit order for buying bitcoin um then i'll just take the best order on the book basically and then

sell off the position okay so i want to talk a little about forced actions which are basically how do you make sure that things are done in a trustless or trust minimized way so basically what you want is you want to impose actions on the layer two by taking action on the layer one and that basically means that for the purposes of self-custody and stuff like this you want to be able to make sure that you can withdraw your funds because you um you might not always trust the operator of the l2 to you know perform the withdrawal the withdrawal transaction on your behalf so there are two kinds of actions a forced withdrawal

and a forced trade and basically these are signed by the user these are layer one transactions that they send to the contract and the layer 2 must process these within a timeout period otherwise the exchange will shut down and everyone will receive their funds back so the l2 either has to process them like say that the user does a withdrawal then they have to give the user their money back or they can also prove that the withdrawal is invalid for example if the user says i want to withdraw a million dollars but the user only has 10 dollars then the l2 still has to include this transaction in the l2 but it can prove basically that's invalid like oh this user doesn't have a

million dollars i guess there are other considerations i want to touch on stuff like minor extractable value since there's no competition for blocks um each block is currently signed by uh multiple parties so us at dydx and also starkware who we work with for example um so there might be exist there exists some level of mev which means basically like some benefit in doing stuff like reordering transactions and stuff like that um and uh that's uh currently somewhat unavoidable but basically you can optimize some of the proofs or some of the rules around the exchange by creating optimizations that don't

actually make the exchange more trustless so for example one optimization that we did was rather than prove every single price transition um you really only have to prove the highest and lowest uh prices for each asset within the l2 block um since you since theoretically you can basically just reorder all of the price updates um it doesn't make the exchange any less trustless to just prove the highest and lowest values um and some stuff coming up in the near future would just be right now the all the contract upgrades and parameters are controlled by dydx token governance um and we continue to

work on new features and making things more gas efficient so proofs continue to get more uh both gas efficient and cpu efficient um and i guess right now you need to sort of like when you sign orders the layer 2 can't use the typical ethereum crypto parameters um so there's basically like a you kind of like need to link a new um start key and something that's coming up is you won't need to send basically this additional transaction um to onboard onto the exchange and that's all i had for today so um thank you and hopefully that helped kind of people understand what a layer two is and the different

considerations that go on in in running one