Understanding L2: Ordering and Execution

foreign [Music] hello everyone thank you for coming or uh for staying those of you who stay at past Patrick's talk I understand I don't have his Celebrity Status um but um yeah I will be talking about uh sequencers Layer Two sequencers and uh more generally the principles of ordering and execution um it'll be sort of a survey of the design space um there we go um cool so the stuff that we'll be covering um stuff we'll be covering I'll start with sort of an introduction into sort of the motivation and design rationale of kind of what sequencers are and why we even have them to begin with on Layer Two um we'll talk about the current state of sequencers in the layer 2 World um basically that they're centralized but they'll be a little more to say than just that um and then focus on ways we can sort of improve this state of affairs um trust minimizing them decentralizing them sort of limiting sequencers power uh in various other ways and then if there's time we'll sort of wax theoretical about uh how these Concepts could apply to layer one to what extent they do to what extent they don't um but we'll see how things go um so oh yeah hi that's me uh my name is Daniel um I'm uh I'm I do engineering and Tech research at off-chain Labs we're the team behind arbitrum the layer two that uh hopefully you know um and uh yeah I won't be focusing on Arboretum but there'll be a bit of like you know Arboretum perspective arbitrum bias um so okay um um to get into the subject of sequencers I think sort of the fastest way to understand why we have them is to think about why we even have layer twos to begin with um sort of what we want from layer twos right so the Baseline starting point for what a layer two is is we're trying to scale ethereum while not introducing new trust assumption so inheriting security from ethereum that's our starting point the scaling part is we want to improve the status quo of what ethereum is like to use in in some other ways um there's all sorts of ways it could potentially be improved at Layer Two but notably we want it to be cheaper because when layer one gets congested it gets expensive um and we would also like it to be faster because when layer one gets congested it becomes slow um so when I do Layer Two which is sort of do all of those things um what we've sort of seen um in the layer two space I pace around so I have to get used to not leaving the mic um forgive me um what we've seen in the layer two space is that um basically when we're talking about Layer Two in the context of ethereum we're talking about Roll-Ups that's the design that's dominated and um and that's in large part I think because of the ux um the sort of transition in ux If you're sort of used to using ethereum used to layer one it's actually just very similar you can use a lot of the same tools it feels very similar but um the key um the kind of key trick that Roll-Ups use as layer twos is they require that you publish transaction data on layer one itself and by doing so in a roundabout way that I won't get into um that is sort of how we're doing that's how we're able to claim that these things are trustlers that they inherit L1 security so be a layer two magic um we can sort of enforce the safety of the layer 2 Tran of the layer 2 Chain after data is published but essentially all we're doing is publishing data as far as layer one is concerned so all of the other work that goes into processing a transaction validating it updating the state that happens in a separate environment we're not using layer 1 resources so we can make things cheaper so long story short by publishing data on layer one we get trustlessness we need that yeah we get cheaper transactions meaning that that the other thing we said we wanted or top of the list of things we wanted was fast transactions right so do rollups give you fast transactions um it turns out is um is kind of a loaded question right so if you if you've used any Roll-Ups you've probably noticed it's faster than using layer one but it sort of depends what we mean by fast transactions and even right here with what's on this slide we can see we're gonna we have a bit of a contradiction here right by fast we mean faster than layer one but what I said is that the requirement of Roll-Ups is that we post data on layer one you can't go faster than layer one by posting data on layer one because that's a circular problem um or perhaps the Triangular problem um I'll I'll be honest the slide probably isn't necessary but I really wanted to include a trilemma somehow so this is a new trilemma um I don't expect it to catch on but this is another way of thinking about um the sort of situation we're in with Roll-Ups right um we have this nice feature of open participation that's kind of directly Downstream from the fact that we publish data on layer one um um so we can have trustlessness but that means we can't quite have fast finality we can only have two of these things there's other L2 designs called channels which give us fast finality and trustlessness but those the ux is very different they don't have the flexibility of Roll-Ups and so on so we kind of have to decide where in the design space we're going to live um and in fact by the way if you those of us um the arbitrary emojis in the crowd um who've uh followed our first test net release it was actually um you know it had no notion of fast transactions it was entirely like that diagonal line the one that says roll ups right and as we put that out one of the questions we kept getting was okay it's Layer Two are we gonna get fast transactions and we kind of just said no that's not really possible but there was clearly demand for it right so we kind of reached this this point this kind of Middle Ground settlement where we said okay what if we can provide a fast path that's trusted but it's optional um and we were not the first layer two team to come up with this or do this by any means um pretty much all I'll do is do this we in fact we were actually came around to this idea later um and the idea here is um you you can imagine so you have a situation where there's some party a user can trust them The Trusted party says I promise to include your transaction later and then hopefully later it does um that's basically what it comes down to the sort of version of this that doesn't work the naive solution is you let a user trust whoever they want whomever they want um so if the user just decides I trust this random party that party promises to include their transaction even if the party is trustworthy this doesn't quite work because that party can't really predict the future and even if it thinks it will include your transaction in a given order someone else kind of might get there first so when even to have a trusted solution like this you need to sort of enshrine uh you have to enshrine a party within the protocol give it this special permissioned privilege and that's kind of what the sequencer is um so the sequencer in other words is is literally this party that we give the ability to directly post transactions into L2 everyone else kind of has to wait so the sequencer has this narrow short-term view of what will happen on L2 therefore it can give trusted uh trusted kind of soft confirmation transactions we call them um so just sort of recap that for those who just saw Patrick's talk this is a bit redundant so I'll go quickly um but um when we introduce a sequencer the sort of life cycle of a transaction looks something like this the normal in the sort of normal State of Affairs the user kind of gives their transaction off to the sequencer the sequencer immediately gives This Promise totally trusted that says I will include your transaction later at some point later in the case of arbitrum usually every few minutes It'll post a batch of transactions on chain and at that point the sequencer is kind of out of the picture once it's on chain we're in full roll-up mode full trusted mode it's committed to this particular ordering and as far as a user is concerned your transaction is as finalized as a layer one transaction right because all of the data is available there anybody can execute it anybody can see what the final state will be the actual explicit um explicit uh claim or commitment to what that final State actually is happens later and the sequencer is not involved and that's that third step there um the validator asserts the state but there's no rush to do that that's really just so that we can communicate back to layer one and process withdrawals but from the layer if you're just interacting on Layer Two once your data is on chain um you're done so that gives us this way that we can get this nice fast uh low latency fast transaction path trusted if you want to but it's optional and that's very important so just to drill that point home because you should be suspicious when I start saying it's optional um what does it mean that using the sequencer is optional well if in the sort of normal case the system's working well um if the sequencer gives you this fast promise you can just ignore it and say screw you I don't care what you say I'm going to wait for you to post on chain so it takes another few minutes and then you get the full sort of trustless finality in the unhappy case where the sequencer just goes Rogue and isn't even answering anything there is still a way that you can do anything you want on arbitrum there's this sort of alternative path basically long story short it's a lot slower I think Patrick talked about this well I'm gonna stop talking about him but um it's on my mind um but um yeah the point is the system can work in a sort of slower way and a slightly more inconvenient way it can work without the sequencer entirely so it's entirely uh optional and that's why we can still call this thing a layer two and and and sleep at night um so I've just been talking about the sequencer like it's my friend or something um but you know what actually is it and basically you know it we just Define the sequencer as what as this entity that can give these fast promises that has all the properties that I had but you might ask you know how does it decide which transactions to include uh who controls it in what order of these transactions go um and so on and you know basically the design space for what the sequencer is is pretty open it could it could be anything right it's going to be controlled by some smart contract you could swap in whatever sort of mechanism uh you can think of with the one caveat that because the whole point is to get fast transactions whatever mechanism we use can involve interacting with layer one because that just defeats the whole purpose um at least the way I see it the way we see it other people would describe it differently um but uh yeah it could be all sorts of things so um the current state of affairs of what sequencers actually are in Layer Two as far as I can tell I think at least predominantly most of the layer two is most of most of the major ones um is that they're centralized somebody did something Fancy on a layer two that I don't know about you can yell at me afterwards I apologize but generally speaking sequencers are centralized that's the status quo and you know um we get asked about this a lot it's probably the most frequent question that has to do with like you know Progressive decentralization and decentralization roadmap is like when are you decentralizing to see and it's it's not a bad question it's a good question it's a good thing to ask about but um I think often it comes from a bit of a misunderstanding so this kind of there's kind of two things to say to this um this issue of centralized sequencers and the first thing is it might not be as bad as it initially appears specifically centralized sequencers um I'm suddenly nervous someone's gonna like screenshot this slide if you're going to screenshot this slide screenshot the next one too that's all I ask okay because the next one is very important I'm not claiming centralization are fine but the first half of the answer is um the power that a sequencer had is very uh limited and circumscribed right it can't for example simply steal money from the system um and it can't lock up users funds forever um so so um other parts of the system are sort of more important even a centralized sequencer arguably could you know you could you could argue that an L2 could just have a centralized sequencer for good that wouldn't be the end of the world um and the other thing that's worth saying here is that you know again on just about every L2 certainly arbitrum included in the current state of affairs they all sort of have more fundamentally centralized Parts even if we said hey we decentralized the sequencer if we didn't take care of those other things it sort of doesn't really give you anything you can read more about that on our docs or l2b um but um you know we don't want to we don't want to mislead by emphasizing one thing and not another so those other things contract upgrade ability the power validators have those are the things that you you know if you want to spam our Discord about something those are the more important things don't spend more Discord you know what I mean um okay important follow-up obviously having a centralized sequencer is not ideal um looking at the time I'm going to try to speed up a little so um what can a what can a decent what can a centralized sequencer do that's bad well even if it's honest um honest mistakes happen right so even an honest sequencer could have downtime because of infrastructure failures and server issues and that's bad because it sort of slows the whole system down it's very inconvenient um I'm gonna skip over one thing in there um the juicier stuff is what if the sequencer is actually malicious it just turns evil what can it do well um it can equivocate in other words it can make one of these promises and then not make good on it later it can make inconsistent promises to different users right these fast transactions are trusted it can violate that trust it can't censor you technically but it can temporarily censor you right so if it stops processing your transaction you'll be able to get it through eventually and we like emphasizing that fact but the also important fact is there is a short window of time that you'll have to just wait and that also could suck right um being unable to transact for some number of hours might be a real problem the sequencer can do that to you um and then finally the kind of elephant in the room here is Emmy V okay so um all I want to say here there's plenty of other talks about mov people who you know have more and more interesting things to say about it maybe than I do um I'm not an expert I don't even know what the m stands for it's unclear at this point it was minor now it's maximum uh I learned when I was procrastinating this this is called an orphan initialism if it stops meaning anything um tangent um but um when we talk about Mev we're talking about the power you get when you have the power of ordering transactions particularly the power to order them in such a way that benefits you the order to extract value from them and what I would say is this whole architecture of introducing a sequencer um has this side effect that the sequencer has control over transaction ordering which means if it's economically interested it might use this to extract value whether this is a you know a bad thing we need to fix or an opportunity to take advantage of is sort of a philosophical debate but we can say this is the case with sequencers right we have this power we need to at least think about it and uh yeah the way we think about it is is in terms of sort of minimizing it so um I'm going to sort of run through some of the um some of the strategies that can be used to sort of improve this bad situation of centralized sequencers and they'll all involve improving kind of one of these one of these four things that maybe equivocation blah blah um Okay so the simplest thing that we can add to sequencers to make them better a little bit um is the sort of crypto economic penalties we can require sequencers to be staked and we can say now if they particularly equivocate basically when they give these off-chain promises they'll be signed so think of a sign promise and then users can use that to prove that they equivocated and if they equivocate we can just slash the sequencer so um that's cool this helps with the equivocation problem not the other problems and in fact this could be applied even to centralized sequencers just as easily really any sequencer mechanism this could and probably should be applied um a thing to note here is all we can really do in this case is punish the sequencer we can't sort of rectify the situation for users uh and that's because if the sequencer is equivocating you know each of these claims are sort of internally consistent um they're just inconsistent with each other so it's not really clear which one is the more valid one to take um you know either way if we simply took one we'd be screwing over the other user unfairly um but all we really can prove is that the sequencer did something wrong so okay we have this like provable cost to equification for the sequence something um in terms of particularly the media problem um shout out to shutter here who's working on this uh this strategy I probably should have put their logo bigger or something um but there's this idea of threshold encryption so um and sort of using threshold encryption to to minimize the Mev that a sequencer can abstract uh can extract and um the idea here is when a user instead of Simply passing their transactions onto the sequencer directly they'll be the step will they pass it in this encrypted form um and they encrypt it there's sort of this network they call them Keepers which is kind of cute um they do this distributed key Generation Um so you encrypt your transactions give it to the sequencer the sequencer commits to an ordering blindly it doesn't know the content of the transactions commits to it off Chan right and then only after it commits to them do we sort of reveal the contents of it so now the sequencer can't easily extract value because it doesn't know what it's looking at um so this is cool um and um there's you know some added levels uh I mean so like some potential concerns let's say um the the parties that are in charge of this distributed key generation the idea is you distribute it so that they can't easily collude but if they do collude they could for example reveal the contents of the transactions the sequencer before you want to also if they sort of don't reveal keys in time things like that there's certain ways that they can delay um delay things further and remember this was kind of all about improving latency so we do want to take latency concerns seriously even in the sort of normal case when you're doing the threshold encryption stuff there's rounds of communication that are required so it's inevitably going to add some latency um so that's that's one uh concern in our eyes but yeah cool stuff um so I mean these two techniques so far again you could apply these to a centralized sequencer we haven't really talked about decentralizing it just limiting its power now let's get to um some ideas for more properly decentralizing it um so one design space let's say is that of Mev auctions as it's known um proposed by uh some of the folks at optimism along with a few others some years ago um I'm not claiming but I'm gonna describe it sort of in the abstract I'm not claiming this is their plan or anything like that just sort of talking about the design space so the idea here is you can imagine at any given time um we can point to who the sequencer is it's still one specific party even a centralized party but every so often over time we hold an auction and you can buy the right to become the same okay um and and so in that sense it becomes you know in the big picture permissionless now why would you want to be a sequencer seems like a thankless job the answer is by being a sequencer you have you have the power and the ability to profit by extracting it by extracting nav so this this design kind of leans into the Mev thing and kind of says yeah let's take let's take advantage of this and use Med as a revenue Source again that's sort of a um philosophical distinction or an ideological one even in terms of how I want to handle it um I think important in the mental model for these is that these auctions kind of have to be infrequent uh it's not as though you know it's not as though these potential sequencers are sitting looking at transactions seeing ways to extract value from particular transactions and then bidding on the rights to order them it's more like they're bidding on their future potential for ordering they're taking a bet on their own Mev powers in the future um they can't really be frequent for a few reasons these these auctions you can't have frequent sequencer turnover the main reason being that we sort of at any given point have to know who the sequencer is so that it can give these fast transactions right um otherwise again it sort of defeats the whole purpose so imagine on the order of maybe hours maybe days I don't know uh we hold these auctions um so um I'll talk about why you know myself I'll just speak for myself but generally I'll set that you know at off-chan labs are sort of resistant to this design space um if you know if it depends because it depends on the ability to order transactions and extract Mev this is sort of inherently at odds with the other thing that we want sequencers to do which is give low latency simply because if you're you know you need some time to figure out the optimal order of transactions to extract value from them so there's some tension there in practice maybe that won't matter maybe they only need a few extra seconds but um It's not nothing right um and again the way the way I kind of see it latency is is the name of the game with sequencer so so that's one thing um because these auctions sort of have to be infrequent like I said and they're you know you have this temporary centralization there's some concerns about you know some random party coming in and censoring transactions griefing them right it's sort of the double-edged sort of decentralization in this case right you open it up to any party but that means any party can come in and sort of not do not do what they're supposed to and things like not including transactions is a hard thing to prove it's hard thing to punish because of like data availability problems and stuff um the other practical the thing of the thing that we would probably expect is that you know there'll be a single party that just keeps winning the auction again and again um simply because you know some you know whoever sort of best optimizes for this uh you know there will be some party who does that right so it's open but but you might get a sort of practical centralization um but again the sort of uh the bigger thing is is this question of are we really comfortable with leaning into the idea of extracting NBC or introducing new parties that have this Mev power versus minimizing it um so real I'll try to just get this in before I stop and we're almost done but I want to talk a bit about sort of where our heads at at off-chain Labs um in terms of decentralizing the sequencer so the model here these this sort of fair ordering model is we replace the sort of single party sequencer with um a fixed Federation or Committee of sequencers and these uh in order to give a receipt they have to come to consensus a sort of sort of like a bft style consensus um but um it has this special property which is the ordering of transactions is sort of enforced within the consensus itself so unlike you know a lot of bft leader selection algorithms where there's a leaders chosen in that party kind of has full control over what to propose um in this case that control is distributed and we we enforce Fair ordering what we mean by Fair ordering it's a little hard to formalize but it's something like you know you have transaction A and B and if a super majority of sequencers kind of witnessed transaction a coming before transaction B then as long as the super majority is honest that will also be the result so um and um yeah some nice research has been done some nice progress has been made into sort of improving the style of algorithm uh the initial ones were just practically required a lot of network level communication so they weren't usable but the latest this thing called CMS is kind of the um a nice breakthrough uh which makes it viable um so this does introduce an honesty assumption they have a fixed set of parties where we're assuming an honest super majority um again any sequence or solution is going to have some centralization in it it can't truly be open um but that is a definite downside the more interesting downside here and this is some of the pushback that we got um has to do with okay we've taken power away from sequencers but now if you're a power user who's trying to extract nav what sort of what role does this create for you and what are you capable of doing uh um so just because okay so we have Fair ordering there's still this question of what exactly is the ordering that we're enforcing and initially we were thinking fifo first in first out right the order that the sequencer sees them is the order that they that they sort of give the receipts and publish transactions which is what which is what the centralized sequencer does now if you trust me um the um the issue here is now you can imagine a power user who sees an Arbitrage opportunity or something if they want to get there first now they're incentivized to have like direct Network level access to the sequencers like literally set up servers geographically close to the sequencers and have fancy Hardware so they can communicate clearly which is which is sort of all exogenous to the system it's it's not really something we want to incentivize it's it's sort of benefiting users in this weird way and probably a pull towards centralization because someone will optimize that best so um we can do better so um this idea the top of the slide is cut off but very recently we got this proposal from some of the folks at um at flashbots particularly Shin AKA I guess sexy son is how you pronounce it um but the idea here is we have a sort of hybrid ordering policy so we can keep our Fair ordering algorithm but we don't enforce the fairness at the transaction level we enforce it in these sort of chunks of time we can imagine discrete intervals of like half a second um I think that's the rapid up music um anyway this is a really interesting topic it's all very new and fresh so I recommend if you're a researcher or interested person this is a good place to start in terms of fair sequencing um I have more to say about L1 but you can find me later um thank you all for listening