zkSessions: Why Sequencers are the Future - Mark Tyneway (Optimism)

Transcript

next up we have mark tyneway from optimism pbc talking about why sequencers are the future take away mark cool thank you yeah so um like anna said my name is mark and i'm here to talk about sequencers and why i believe sequencers are the future so um yeah i work for optimism pbc and we are working on optimistic roll-up and part of our architecture is based on a sequencer so uh real quick just what is a roll-up um everyone here probably knows what a roll-up is but basically it's a a method to increase increased stateful blockchain throughput and throughput because you know

scalability versus throughput you know you got to be on point with your words um some interesting things is that it decouples the execution from the the consensus right it allows us to build systems where we can just come to consensus over the data and then we can kind of uh change the execution model and um users can opt in whether or not they want to perform the execution or not um so basically validating a roll-up means that you have to basically validate all of l1 and the roll-up if you choose to opt-in to executing that role up and if there's a roll-up state that you don't care about you don't need to execute it um so it gives this nice

property of users being able to opt into what they want to basically verify the state of or get the state of and it allows us to like make alternative run times without major changes to layer one which is cool because um you know the evm is great for some things and maybe there's an alternative runtime that is better for other things so what is a sequencer so it's basically this off chain entity that users can send transactions to and um basically this sequencer will then take those transactions and batch them up and send them to layer one

and the sequencer is responsible for the ordering of the transactions and um the design space for what a sequencer is is very large so in particular um the optimism sequencer um is responsible for receiving the transactions from the users and then it takes the the transactions themselves the actual uh data and submits them to one smart contract on layer one called the canonical transaction chain which is just uh basically you can think of it as like a list of transactions and then it also takes the state routes um and it basically publishes all the the corresponding

state routes to a different contract called the state commitment chain and basically you have um these two lists that correspond with each other and where for each transaction in the canonical transaction chain there's a corresponding state route and this is the post state route so after the execution of the transaction in the state commitment chain and um just a shout out to georgios he he actually wrote this i i took it from his awesome post you can see the the link research.paradigm.xyz slash optimism um that's like a really good resource if you're interested in like the low-level details

of the system cool so uh any questions not none um actually thank you yesin i hope i'm saying name right uh for sharing all those links um yes so all of the links you've just mentioned there's actually somebody who's sharing those in the chat as well but no questions yet awesome cool yeah thank you all right so um i think this mental model really helps when thinking about sequencers so basically a sequencer is a service provider and the contracts on layer one are the service level agreement and

users can send the transaction send transactions directly to the sequencer and it's really the contracts on layer one that the sequencer must they must play by the rules of the contracts on layer one and um because you could imagine that the that sending transactions directly to the sequencer like the sequencer could in theory like front run your transactions and such so you really need to use some game theory and kind of design the um the the contracts on l1 to prevent things from happening like that and um so you can see i made this little emoji diagram and we have users who

send they can send transactions to the sequencer which maintains like a layer two chain and then uh from the crystal ball that is the sequencer and then um sorry if it's getting loud there's just a garbage truck driving by right now i was about to type so this this time around there's no fire alarms but there's a massive garbage truck yeah i'm gonna i'm just gonna step inside real quick all right cool all right sorry about that everyone i think everyone's so used to it in this community so no problem at all yeah all right so um just going over this diagram we have like the sequencer who then

you know submits the transactions to the l1 contract so we have ethereum up here on the left and um basically the users they can run a verifier um which basically will kind of sync the contracts and play all the transactions and it lets them submit a fraud proof so this is kind of like a high level overview of like a good mental model for a sequencer so basically why use a sequencer so basically we just need there's this concept of ordering transactions right and there has to be some way to um come to consensus over the ordering of

transactions right so right here i just pasted it in a snippet of of geth right where you can see um at the bottom of the code it says you know if the header.time is less than or equal to the parent.time it returns an error so this is basically the consensus rule in ethereum that shows that time must increase um from block to block and um here's here's another snippet from guth and um this just shows the way that um you can see kind of in the middle um we're iterating over the blocks transactions and we're basically executing them one by one so this is just going to show that there that like

ordering is very very important in blockchains um so there's massive financial incentives to influence the ordering of these transactions and there will always be super users that have a high ordering preference right and basically what we're observing today is that when the super users compete then it results in in the regular users losing and it's really the miners that are winning right so through priority gas auctions and out-of-band transactions um if people aren't familiar like a priority gas auction is just when um say there's some sort of transaction that you can send

to the chain um that will be profitable and uh somebody else sees your transaction in the mempool then basically they will submit a transaction with a higher gas price and it's kind of this back and forth thing where um you end up with a ton of transactions just like spamming the mempool pushing up the the gas price for all users and as these like um you know the sharks are competing for the profits and they end up losing profits themselves because um the they're just like willing to push the gas price up as much as possible so they still make a little bit of profit their profit gets cut out and it ends up going to the miners instead

so um and then people start like considering oh maybe out-of-band transactions are the the solution um so that other people can't like learn what exactly um the uh the the transactions uh basically it keeps your transaction secret and then it kind of devolves into the system where the super users um have special relationships with the miners and it becomes less kind of meritocratic and less open and it becomes uh it becomes the mirror kind of like the current system um so a lot of this work was kind of pioneered by flash boys and uh flashbots is currently working on some really

interesting stuff and like there's also this other project keeper now that's kind of working on this and um so basically using a sequencer it kind of opens up the design space around transaction ordering and um it allows us to iteratively design mechanisms without needing to change the consensus rules themselves around the ordering of transactions because we can now put rules about the transaction ordering into smart contracts themselves and we can iterate on these smart contracts over time and find something that is better for the ecosystem any questions

um skyheart is ordering happening on a separate consensus layer yeah that's that's a good question so um in in the optimism implementation there is no separate consensus layer for the ordering of transactions um basically you send transactions directly to the sequencer and the sequencer can choose the ordering of the transactions that are batch submitted to layer one and um basically it sounds a little crazy but we just need this series of checks and balances where the layer one contracts are basically the service level agreement um and the you you have to just

make the kind of game theory um design it in the layer one contracts to prevent the sequencer from ever wanting to act poorly there's another there's sort of a up here how will it help with reordering on l1 on an on l1 level help with ordering so um reordering was actually the question from jacob yeah i guess um this isn't necessarily like a solution for l1 today and um there are other projects like flashbots and keeper dial that are kind

of working on like l1 right now um but this is kind of just looking at l2 and kind of as we move to um eth2 when it kind of becomes more amorphous and um like like l1 is less of a thing and it's more like all roll-ups kind of on e2 cool there's one last thing what do you mean i can code transaction ordering at the smart contract level without changing consensus rules and then the other question is can i do this now yeah so you can't do this now necessarily on l1 but this is kind of the system that we're designing here

optimism is um in kind of the the l1 contracts that make up the roll-up um the idea is that um the way that they're designed the users get certain guarantees about how the uh the the transactions that are sent directly to the sequencer uh they get certain guarantees about how those transactions will end up getting uh submitted to layer one and um over time we're looking to kind of improve the uh iterate on kind of the the game theory that is built into the system so that we can have really good guarantees um for the users when they send transactions directly to the sequencer

so all of that mechanism design would happen in smart contracts on l1 there are two more questions but i'm wondering if do you want to keep going and we come back to them in a minute yeah sure okay cool so um this is basically one of the main kind of ideas that we've been working on and this is uh carl came up with this it's an incredible idea it kind of just like it really opened up the design space for me and it's basically um it allows the the basic idea is that you separate the concept of ordering the transactions from the concept of selecting the next set of transactions to come to consensus

over so basically what this would allow is for a system where the sequencer auctions off the right to order the next set of transactions and um because mev is always going to be a thing um we can design systems that kind of take that into account and basically if the sequencer is auctioning off the right to order the next set of transactions then the sequencer can like charge a tax on that or charge some sort of fee and that fee could be then used and repurposed towards uh funding open source development or it could be used to fund uh you know the development of the

sequencer and or it could be used in kind of like bitcoin like uh grant like a git coin like grant system um so another another possibility um so this is just like a picture of like a transaction that's been waiting for six days like it's kind of really annoying when whenever this happens to me um it's really like we can improve on the user experience of using blockchains quite a bit so kind of the idea here is that the sequencer accepts transactions instantly and gives you a receipt back instantly right so if we could build into layer

one um the ability to basically submit fraud proof based on this receipt that the sequencer gives back to you because the sequencer can give back to a receipt that commits to um submitting the transaction batch submitting the transaction to layer one in a particular way so the simplest form of this would be the sequencer would say okay i commit to um batch submitting this uh transaction to layer one within five minutes and basically if your transaction is not batch submitted within five minutes the user would be able to um you know submit a fraud proof and the sequencer would get slashed um

so this is just like a way to kind of in layer one uh design uh a system that allows for instant confirmations um when you send transactions directly to the sequencer any questions actually and just fbi we are almost at time for this session and then there is going to be the panel but we'll keep going until you're first you're finished with this talk um i'm trying to think going back lassa had asked what would happen if everyone is well behaved for a longer period of time but slashers are nothing in this period would it make sense to have slashers basically yeah yeah you

always need um a bond with an optimistic roll-up um it doesn't really make sense to not have a bond because if there was a time when you didn't have a bond then like the system would be not secure during that time um so we do have some smart contracts in our repository that manage the bonds and if you're curious about how it works definitely go check out on github it's github.com ethereum dash optimism contracts one more there's actually a lot of questions so i would say like we'll we'll i'll ask answer keep going and then it sounds like you might just want to keep having a conversation with some of

these folks after and gather so skye asked if a miner does not like what he gets from the sequencer why should he mine it oh that's a good question so there is this whole idea around miners basically basically censoring transactions so if i understand this question correctly um it's on the topic of when the sequencer wants to submit a batch of transactions to layer one and the miners on layer one um are censoring it and

this is why the basically the the window the fraud proof window is so large for at least optimism's optimistic roll-up and this is a topic that people are like very opinionated opinionated on and there's like a lot of kind of back and forth um but basically there is an assumption that miners will not censor and basically it kind of becomes um users need to uh the so the sequencer will basically up its gas price and assuming that the network is decentralized enough eventually one of the censoring miners should defect

and include the transaction but this is definitely the type of conversation that goes back and forth because it's very in-depth and there's a lot of like little gadgets do you want to keep going yeah yeah i'll keep going okay cool so this is kind of my vision of what a sequencer could be in the future and so it's like the sequencer is a service provider right so the sequencer wants to provide the best user experience right which is instant transaction confirmation um in like additional services that like the user would like right where like there's like key management and different like regulatory and tax

tools because like doing taxes is so annoying so like imagine like if if you were all the transactions that you sent to the sequencer like the sequence the company that's behind the sequencer can just help you out with all those things and then it kind of becomes this organization that um makes like this vertical integration of the blockchain internet experience where they can you know make open source tooling like web3 providers there could be like a login system kyc they can start to provide search or other like existing kind of internet things that are that are used and um this is really like in the in the long term where i see the concept of a sequencer going okay so i'll start to go a little bit

more quickly because i don't want to go over too much but what about a malicious sequencer so the sequencer can choose to censor calls to contracts on l2 so what this means is we need to be able to send transactions permissionlessly that impact the l2 state so what this means is in the optimism system we can send transactions from l1 to l2 so this basically means you get the l1 guarantees to be able to modify state and l2 and this is done through this in q function and then there's this append cue batch function um i won't go into too much detail about how they work under the hood

and if you're curious like come check come hang out in our discord and uh we can answer more questions there um okay so then there's this problem of sequencer front running right so the l2 contracts um basically when you send transactions directly to l2 the sequencer can technically front run any of your transactions that you send to l2 so we need to design uh we we need to give primitives to like prevent this from happening right and like um one primitive is um you can basically in in l2 you have this l1 message sender concept so you can kind of put this little modifier on your code that is deployed

to l2 the optimism l2 and you can basically prevent an l2 transaction like like like a transaction the sequencer created um because this will basically only allow transactions that come from l1 um and so if the sequencer did want to front run you then they would have to participate in a priority gas auction on layer 1 to modify the l2 state so another thing that the sequencer can do is they can sell your consumer data right um so the solution to this is the the sequencer's information

should be highly available um so that there isn't like an asymmetry in um the the sequencer or like the sequencers friends um learning the information before everyone else does because they would be able to act on that um so we're trying to design the system in a way where it's really easy to kind of make the the all of the data available even before it has been uh batch submitted to l1 [Music] um so something that could like really help to prevent sequencers from becoming too powerful is a competitive ecosystem of sequencers

where users can opt in to the particular sequencers that provide the best services and this kind of creates an ecosystem where the sequencers continue to innovate over time and users have options so it's really important that um you know the sequencers that choose to have like a in open governance that users can you know go there and kind of vote and participate in the governance of that sequencer and also it's important for for users to be able to easily exit to a different sequencer so that it's really important to kind of develop like standard interfaces and kind of um you know common tooling that can be used across sequencers

so uh yeah this this is basically that in my talk and just have like a little like philosophy blurb at the end sure and uh this is basically just about how um you know i think it's important to build systems that act as a balance against the growing wealth inequality and uh basically i like i think that the world as a whole is a happier place when there's less less wealth inequality and this is because um you know we do know that money does improve a person's happiness but there's a diminishing return on happiness with more money so therefore if we can build systems where money is spread more equally across people then we can make the world a happier place

that's a really nice way to end that talk thank you so much mark by the way there's a lot of questions still in the chat um but we actually do have to hop over to the other session now and the panel maybe i don't know if you want to take a moment to maybe answer some of them in the chat and then you join us over there as well and to the to the folks who want to switch over we actually are going to go to reception or to the sessions and you'll see now there should be like a different button to go in i'm gonna head over there now mark you're actually welcome to also stay on this i think this just keeps going until you sign out cool yeah yeah and then once all the questions are gone

then i'll uh pop out and then sounds good hopefully the mammals are going on yeah and also if i accidentally shut down the entire thing then i apologize in advance but maybe everyone can talk to you after and gather i hope you'll head over there too after cool awesome yeah thank you cool all right i'm going to scroll up on these questions okay so i will answer the kind of there is a question around the sequencer um and the sequencer does run on layer two the sequencer is kind of responsible for maintaining liveliness of the entire system the l2 system marcel i'm looking for your question how could a user prove that their transaction was withheld

okay um so basically let's say that you submit a transaction to layer two and the sequencer receives it then the sequencer executes your transaction and they give you back a receipt and then they can commit that they will submit this transaction to layer one within five minutes if they wanted to and um the in this receipt that they give you back they would basically tell you what index um in the canonical transaction chain of transactions um that your transaction would be

placed in so the way the fraud proof would work is you would it would basically look at the canonical transaction chain and it would see that there's nothing at that particular index and then you'd be able to prove fraud on the promise that the sequencer gave you what if the sequencer won't x okay yeah that's a great question so um if the sequencer um doesn't execute in the first place then basically that will increase the latency right so there's always a trade-off where if you are sending transactions to the sequencer and the the longer the latency is um that's kind of like worse user

experience so there's kind of got to be like this like threshold of when the acceptable amount of time that a sequencer can basically run an mev solver in the background before they give back like a receipt right because a receipt contains like the state route so once the once the sequencer gives you back your receipt like you can't really um the sequencer can't really go back on it so um assuming that there's like an ecosystem of of sequencers um there will be a sequencer that steps up that does like less mev solving

and users will migrate to that one because um it's providing a better user experience in the same way where people that did google searches um those like every extra like you know 100 milliseconds um that you know it took like longer for a google search to return there are much less users so it's really like this competing ecosystem of sequencers that's really important and right now like we just have one sequencer and we're running the sequencer and like we are a public benefit corporation so like we have no intention

to um you know extract mev and kind of you know play those games um we just need to like figure out how to basically bootstrap this whole system of of competing sequencers cool yeah no problem um thank you for for watching and definitely um if you want to say hi just like pop into our discord we usually are hanging out there you can find our discord on optimism.io like on the bottom there should be like some social links cool yeah and thank you for your time i

appreciate you all watching