New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

'MEV Minimization on L2: Solution Space and Design Constraints' - Eli Ben-Sasson

ETHGlobalSat, Oct 9, 2021, 12:00 AM

Speaker

Eli Ben-Sasson

Eli Ben-Sasson from StarkWare speaks about the forefront of problems and potential solutions in MEV minimization research on Layer 2. ---------------------------------------------------- Follow us: https://twitter.com/ETHGlobal​ Check us out: https://ethglobal.co​ Email us at: hello@ethglobal.co

Transcript

uh do are you able to share your presentation from from your phone would you like someone i prefer that if someone else can can do it for me that would be easier because i'm joining from uh from actually just you know from some family event from a car you don't want to hear the full story anyway so if someone can share my uh my my screen you know uh yeah let me just do like this and then i can uh um okay can you see me well okay uh and can you hear me well yeah terrific and i'm supposed to go for like uh 15 minutes or so or 10 minutes and then leave time for questions let's aim for 10 minutes uh and leave for questions okay so 10 minutes okay so i'll start so hi i'm ellie ben sasson i am a co-founder and president at starkware and i want to tell you a little bit about a few of the methods for doing med protection on layer two and of course i'll be speaking from the angle of star queers technology so i'll be focusing mostly on vidu which is a start based vdf in time lock so can we move to the next slide please okay so what is the problem the problem is that the l2 operators right now we're discussing uh mev protection on layer two so any operator that is operating on l2 receives uh transactions and just like on l1 just like with the miners this operator may extract value unfairly and in the same kind of from uh censoring transactions from inserting um the operator's own transactions and from modifying the true sequence of events um so those are the three problems right deletion insertion and uh reordering um can we move to the next slide please now how how can we solve this on layer two and i want to say at the very first at the very beginning that that actually conventional uh methods in in certain cases may work very well okay but i'm not gonna devote a lot of talk to that so what do i mean i mean in the conventional world like if you go to you know standard regulated exchanges uh they will have similar problems and the way they are uh their integrity is asserted and checked is by a combination of auditing uh reputation and legal incentives so if you assume that there is an ability to hold the operator accountable either by inclusive accountability meaning that the mempool is visible to everyone or by some delegated accountability where there's some you know legislator or regulator that can look at things um then you can apply the conventional mechanisms right it's a repeated game people will leave if the reputation is damaged and of course there's the fear of legal actions and this applies to single operator uh in particular the the the systems sorry the the customers that we are right now serving you know diversified ui dx immutable x uh these are all single operators that they and starkware if we were to uh do shenanigans uh all of these things would apply to us so i know we're not and i trusted our counterparties or not um and it may apply to decentralized operators especially if the operator identity is public okay so if you have a small network of uh public entities you know reputable financial institutions or something then this may apply but let's talk so let's move to the next slide so let's talk about the more interesting case what kind of cryptographic primitives can we put to bear on this so we have uh commit reveal schemes uh that's the first kind um you have vdfs and time locks that's going to be my focus you have trusted execution environments like uh in those sgx and you have uh secure multi-party computation these are four different methods that i'm aware of that can be applied to solve the problem and especially in the case of decentralized operators so let's move to the next slide here's a brief comparison of how they you know a few parameters so um the first column you know is this a non-interactive setting because non-interactive is a little bit better it's more complicated when you have interactive protocols you know parties can leave off and it makes things much more complicated and less secure so vdfs and trusted execution environments are non-interactive whereas commit reveal schemes and secure npcs they are interactive and hence you know not as good you can ask which of these technologies is available you know today for use uh so all but secure npc um i would say are available securing pc you know theoretically we know how to do it there are some um things out there that are like this but uh you don't have elements of this form in production today so if you're asking about vdfs and timelocks so starkware has a video service running right now everyone can use it and you know there are other such vdfs chia has a vdf there's a whole bunch of other things transparency you know is there a trusted setup you need to trust anything so all of these uh protocols but for the trusting execution environment uh they are transparent or can be made transparent depending on what is the technology you're using for uh the secure npc or commit revealed uh timelock um and uh yeah i think the lack of transparency for the trusted execution environment makes it very uh problematic because uh uh you know i don't find it reasonable to assume that a lot of value will reside on trusted execution environments without keys being compromised um and finally what kind of protection do you expect to get from these schemes so i think that the bottom to give you much better protection because you can have inputs fully encrypted and the operator will sort of operate on them without even knowing exactly what's going on whereas with the first two it's a bit uh you know the information is revealed at some point or can be revealed and and they are you know they give you some of the protection but not as good now if you look at these uh um so so i would argue that vdf time locks are kind of uh in the sweet spot as far as we know today because they are have all the v's and they're you know they don't have the three pluses they're not fully green but i think they're pretty good so they may be used let's go on to the next slide now when it comes to a cryptographic time locks or vdfs there are two basic mechanisms that you can use them uh two modes you can use them in you can use the time lock where transactions are so you can ask users to submit their transactions uh using a cryptographic time lock plus some uh um you know expiration time to prevent uh opening of this so that's one op one mechanism right so now when the transactions are put in the mempool and are being sequenced um the operator doesn't really know what's going on and only after they've been sequenced are they opened the second option is to apply a vdf which means that the transactions are submitted in the open so the operator actually sees them the operator will sort them arbitrarily but now we'll fix the sequence in a block right we're talking about l2 so you can rely on l1 for your security so you basically commit to this order you apply a vdf to the block header and then you use the vdf randomness to resort and shuffle the transactions according to the permutation that was selected and then you process them okay so those are two basic options you can use with uh time locks and let's just do a brief comparison of them so let's move to the next slide so if you look at the time lock based uh approach it's slightly better in that it actually shields the information while it is being sequenced from the operator which means that the operator it precludes the operator from inserting or deleting certain things right because the operator doesn't know what's going on whereas in the vdf approach the operator can extract some value by deleting transactions inserting her own transactions and things like that so there's an advantage to the time lock based approach in this shielding but on the downside it requires k computations of delay functions because each one of these uh delay things needs to be opened and and uh i know that there are some really really cool um vdfs which can be uh or time locks that can be opened with just one opening um but uh you know at least the ones that i'm aware of that are out there right now in production don't have this property um and then the challenge is that uh but the challenge with the timelock based approach is that miners may demand to see the unlocked transactions by given to them by side channels and thereby sort of compromise the whole scheme so miner could say look if you want me to sequence your transaction even though it's time lock please show me the opening of it and usually it's it's going to be very easy to prove that a certain thing was opened in a certain way in all of these schemes okay the second approach is the vdf one oops uh sorry let's go one slide back the second approach is the vdf one and uh you need to compute only one delay per block but the operator can do some stuff and extract some value okay so let's move on to the very last slide of this presentation so i want to say that you know vidu is going to appear on starknet so cairo will have support for vdfs and um by a dedicated built-in that will do this and then it means that you can have you know when you're you know programmers of uh starknet smart contracts will be able to write all kinds of things like time lock based uh mev protections you could have vdf based mvp protection so you could implement both of these two modalities that i spoke about previously um using uh vidu as a built-in as part of your basically code base uh for cairo and of course there's gonna be a lot more that you can do with it that is outside of uh mev um you can do second price auctions which again can be some solution for uh um or all kinds of sealed bid auctions you can have lotteries leader election you know proof of stake protocols and more and more all of these things will be uh programmable very efficiently on l2 um and and i hope that people will you know build applications um with this and i just want to say that as we're prioritizing the set of built-ins and things that will go into the cairo programming language would be really really cool to collaborate with teams that actually want to use this in production as soon as possible we have already deployed uh vidu as a service you know in production on on mainnet ethereum uh sadly no one's using it right now uh we'd love for people to come up and say they want to use the uh you know the version of it that will be part of cairo so please talk to us happy to answer any questions and thanks thank you ellie um any questions please post them in the chat okay no questions um okay we have a comment from alex i am worried about the impact on markets like price lag between um centralized exchanges and video enabled liquidity pools yeah so so i mean there's a there's one variant that i really like that could give you sort of the the best of both worlds it would look something like this so um you process in real time the orders um based on the current market conditions and you understand that um that that actually the sequencing may be such that some people win more or lose more based on the sequencing and maybe even the miners have been uh you know playing games here but the protocol then has a reconciliation period which means that you will take so after all these orders have been done the smart contract will take the sequence of orders randomly permute them according to a vdf and let's say two minutes or five minutes later we'll run this reconciliation protocol that will either transfer funds or leave some of the funds outside and you know renumerate randomly according to your order so what this would mean you know as a user i think you would get this would be like the sweet spot unless you're in the business of extracting value right because you could get immediately uh you know you wanna let's say access unit swap and get something you'll get pretty much uh the final price but there'll be there's there'll be this random delta that you will you know learn of like five minutes later so if you bought a thousand dollars uh you know you got a thousand dollars worth of whatever token it is but maybe after five minutes it's gonna be you know either a thousand and ten dollars or it's going to be 990 dollars based on the random uh you know the randomness that comes out of video so i think this would be this would give you the immediacy of a centralized exchange and the uh fairness of uh of as if you applied to that's my preferred uh but it's more elaborate logic oh i see interesting it's kind of reminiscent of probabilistic payments where kind of yeah an expectation you have the behavior that you want and it's fair but um in in real time on a discrete basis there could be quite a bit of variance yeah or here you get because the the downside of using a delay function is well the delay so what if you could have the immediacy of like acting immediately but you understand that the delay will be used for this fairness and reconciliation i think this would be so on layer one i think it will the gas cost would really kill it today but on layer two this can be easily done right um right right right um i mean maybe a potential other way to address delay with time locks is to have some sort of optimistic happy path where you you reveal the time lock ahead of time as in before it kind of expires and so in the happy case you have near zero delay but in the in in the worst case uh where things go wrong then things are ordered uh using cryptography so i thought there was a question um so i see here um that klaus from vega brought this up so klaus from vega if you want to work on this you know on layer two uh using cairo please you know dm us uh me uh let's get this thing uh rolling i think this is uh again on layer one it would be very gas costly but on layer two i think this would work marvelously well um this kind of thing and we can make it happen uh i saw there was another wouldn't veto incentivized spam tina is asking i'm not sure why why would the video incentivize spam oh like time locks or like if i i can time lock spam i guess um yeah so you could you know you could have a collateral that would be slashed or something if you do if you do that stuff i i confess that my preference is uh you know this immediacy plus a reconciliation later on it's also just one vdf and you get you know instant gratification and then near instant reconciliation i'd like to see okay i'm not sure are there any more questions because i think my time is up i don't think there's any more questions tina is there a break between part one and part two um so uh there's a panel uh that we skipped uh that we kind of went into uh discussion while waiting for um ali so um we can bring that on um or we can kind of skip to uh the uh part two and then have the panel towards the end so up to you guys i apologize i have to jump off to my family event but uh thanks so much for having me and i apologize for running a few minutes late uh bye guys thanks eddie bye

Automatic transcript — names and jargon may be misspelled.