Optimism Bedrock: Upgraded optimistic rollups architecture

Transcript

hello everyone hey my name is joshua gutu this is optimism's bedrock workshop that's me can find me on twitter what we're going to be talking about today is an overview of optimism bedrock from a very high level uh down into a pretty technical level so cover quite a large gamut uh feel free to ask as many questions as you want in the middle and i'll pause for that um and then at the end we'll have some opportunity for q a as well as getting people running replicas on a very early devnet so kind of we're still like early stages but this uh bedrock's a thing

kind of excited to start showing it off a bit more yep so what is it uh why are we doing it do a high level overdue view with going through some flows go into some more nitty-gritty details uh talk about some of the changes from our current system and then we'll get people up and running on our devnet so if i had to do a one sentence summary betarock is a redesign of the optimism roll up to utilize canon and increase reliability this is a very succinct summary of a lot of work but we'll kind of break this apart so the first part of this

is canon and kind of why redesigning it so a colleague nicola laurent talked about canon earlier today but at a high level canon is a new fault proof engine or a new optimistic fault-proof engine it's very generic actually so if you have some statelessness plus some pre-image-based system you take that you compile it to mips and then you can run it on an on-chain interactive mips game um so to basically update your node you just write your software recompile it to both your normal like x86 or arm then also compile it to mips upload it on chain

and you're good to go you've just upgraded your fault proof engine our current system we have a custom geth implementation and then we have a set of contracts that exactly matches that implementation so every time we want to upgrade it we have to go through upgrade both of those make sure they're exactly in sync and that's something that's very very difficult and takes a lot of work so almost by going more generic with canon we make it a lot easier to upgrade things and so this is really what bedrock is built around is targeting cannon um and doing all the things that can and makes easier and then

on the kind of roll-up side uh there's a bunch of things uh like we'll have snap sync enabled uh i don't know right now with optimisms it's a little bit hard to get up replicas running and there's not really a concept of the tx pool but that's going to be introduced um we're reusing geth so right now we have a heavily modified uh gef client is our execution engine we're bringing that diff down to about a thousand lines of code um so it's going to be much smaller much easier to work with and then we're staying much closer to gath and ethereum changes so that's basically the one centered summary why we're doing

that and kind of some of the benefits we think so then diving in a little bit uh to the different components of the system so at a high level a roll up is just putting data on l1 and executing it on l2 and then the rollup does this in two parts it has deposits which is basically deposits uh into l2 it's basically the canonical bridge or the native bridge uh into optimism and then we have these concept of batches which are all the transactions sent directly to l2 so this is your typical transaction it's going to be much cheaper than an l1 transaction it's what you usually do

and then you have your rollup notes this is something very new uh your roll-up node talks to an execution engine basically geth the the ethereum engine api um so now you have your roll up node which acts a lot like an e2 consensus client and then you have an execution client on the side um and so you've now kind of split up the two roles of the software and that turns out to have a lot of benefits and then you also have the roll up nodes kind of the consensus client parts actually talking to each other and that gives us some benefits as well um and of course significantly simpler so got all these kind of nice things and

like simple overview so this is kind of diagram uh high level how the different components talk to each other so you have your ethereum l1 on this side this is going to host merge right now it's just yes but you also have a consensus client that instructs the execution client what are the canonical blogs where should i go to then the op node just talks to your l1 client it basically reads block bodies and then transforms data from the block bodies into l2 blocks and then it sends the l2 blocks over to our l2

execution engine which does all of the actual transaction processing and then there's kind of another similar diagram showing how optimism the new architecture actually really mirrors the eth2 architecture something we're very excited about because it's going to make kind of the operational side of things a lot easier cool so the roll-up node is really the heart of the system but then there's some other actors kind of in the broader system that are all really important so we have sequencers and role and verifiers those are both actually roll

up nodes uh just the difference is the sequencer is the roll up node responsible for producing blocks and verifiers just verify that the blocks that the sequencer is producing are accurate then we have the batcher which takes l2 blocks and submits the transactions on to l1 this is kind of the thing that creates the data availability then we have a proposer this is the component that enables withdrawals so what it does is it looks at the l2 state route submits it to l1 and then after it has been on l1 for a period of a week and there hasn't been a challenge to it um that's when you're

able to do withdrawals from the native optimism brooch and that's the optimistic part um we just post the output and assume it's correct until someone says no it's not correct um and then the last uh component of this is the challenge agent this is the part of the system that says no the output you submitted to l1 is not correct here's what i think it should be and then you run through the interactive game to kind of figure out who's actually correct there so this is kind of the last component of the system that's not yet live but we have sequencers we have verifiers we have badgers we have proposers all kind of up and running right now so

this is just that those words in a diagram form and with labels everywhere so again sequencers and verifiers are the same piece of software but the batcher and the proposer aren't sequencers of verifiers talk to each other they also read data from l1 um then the batcher again looks from the sequencer reads the new blocks submits to l1 which then the verifier picks up the data that the batcher has submitted and that's kind of how that works uh you can actually submit two verifiers or the sequencer there's just going to be a

mempool and that's how transactions are going to be gossipped around some peer-to-peer blogs um and then when you're doing withdrawals on the end you read from a verifier this is kind of the canonical state and then you submit it back to l1 so very high level diagram of like how everything fits together yes i can repeat the question as well yeah yep okay so if i understood correctly there is kind of the optimistic node and then the guess or these are the same software um so in this diagram the sequencer and the

verifier is the combination of your it's kind of your roll-up node which is your roll-up node client uh as well as the l2 execution f client okay yes okay so every actor is running both actually yes okay thank you yeah yeah so yeah yeah yeah like yeah for sequencer verifier you need to have the l2 execution engine as well as the consensus client which is kind of the op node is kind of what we're calling it internally or any kind of code and that comprises of the rollup node and then for l1 you can actually get away with just like an eth provider so um

you could yeah you could use just like an infra provider actually for that because you're just reading block bodies cool yep got one question can i try and clarify this as we go along because this is complex and it's going to get even more complex okay so going to walk through some of the data flows of the system um kind of try and get an idea of like if you're interacting with the system what's actually going on here um so deposit as it kind of said this is how you move money into optimism

um this is kind of how yeah you get your eth into optimism this is also just like an arbitrary message passing system so this is actually basically a bridge and we have a canonical erc 20 and erc 721 bridges on top of this which eventually do use this mechanism so you basically just send a transaction to an l1 contract the contract emits event an event and then the l2 node reads the event and basically constructs a block uh or constructs a block that has transaction based on the event and then you kind of like execute it

and so the event just basically has all the normal fields of a transaction plus a special one called a mint which mints ethereum on l2 and then the deposit contract or the optimism portal contract holds the eth until you withdraw it at a later point that's kind of the flow into the system so then if you want to just execute a transaction on l2 you send it normally except to an optimism endpoint instead of like your typical l1 endpoint gets gossiped around just like l1 and then the sequencer mines it pretty

similar to l1 um and then to see it fl show up on a replica on your like exchange anyone that's being careful um the the batcher creates a batch based on the block gets submitted to l1 and then a verifier reads the batch and reconstructs the block so i'm going to flow from l2 back to l1 at least for transaction execution um and then this last uh flow is what you want is the withdrawals flow uh so here what you do is you send it to a special contract on l2 um and if you're withdrawing eath it

destroys the eath and then emits event saying kinda i have destroyed this eath and it also records the fact that you did what you did in l2 state and then when you go to kind of execute the withdrawal on l1 um you can create a proof um against the l2 state they did what you did and said like get that uh submits it um and then you pass the

challenge period without defaults and finally you can execute it um so that's this flow and i'll open up to questions on any of these the sequencer orders transactions by latency right now or does it do it by it's by latency right now and with the mempool will that remain the same or do you think you order by fee uh it will not be the same um the transactions will be ordered uh by tip um the deposits are actually ordered differently they're still ordered by

latency and we'll kind of go through how deposits are kind of like forced to be included but yes your typical l2 transaction is now much more similar to ethereum and based on tip not latency thanks um how can you pay for l2 gas using deposited transactions yeah so we'll go through that but it's done on l1 um so there's a gas market on l1 for deposits and that's actually separate from the l2 gas market okay but how do you know how you know the gas price on l2 on l1 uh

you don't okay um we'll we'll talk about a little bit more but it's basically an arbitrage opportunity if you want to use it can the sequencer also be the the butcher or the proposer because i i thought before the presentation that the sequencer was the one publishing on l1 and apparently is not um so logically the rules are separate they're also separate binaries but it is kind of like they're all trusted together right now um kind of long-term road map with canon eyes will first be able to decentralize the proposer and then the

batcher um but yes they're kind of like as a trust assumption they're essentially the same right now in the back uh in terms of the igb it should be uh uh it should be a sequencer or proposer important it should be the same as what yeah i mean uh if uh in terms of imdb and the front runner should be uh in this context this is uh proposer or is a sequencer uh the actor that can extract meb oh okay sorry i'm having a hard time understanding you okay i think you were asking

where the mev is distracted yeah so for the imuv i mean uh it is the sequencer and people like the segments of this transactions where is the uh proposer and to control all of those yeah so the sequencer is the actor that extracts mev the sequencer sequences transaction that's where the name comes from good question cool so we're basically going to walk through these flows in just a little bit more detail um so yeah so these are kind of all the details of the deposit contract um there's some like

random little tidbits um you can now just uh send eth to the contract and it'll get moved over um to l2 we're going to set up an ens domain for this so it's going to be very exciting you just could now like any wallet transfer over i mean we like that because we like uh people bridging over um the other thing is deposits are going to be much more live than they currently are a couple reasons for that but right now if you deposit eth into l2 you could be waiting i don't know 20 to 50 blocks for it to show up we expect that to drop down to a couple blocks

and then there's some other things where even if the sequencer goes offline your deposit will eventually get through and then you can because you can do arbitrary computation with deposits just a transaction you can basically have a way where the sequencer even though it's a single actor can't actually censor you um see yeah and as gas um as deposit gas is bought on l1 for l2 we explicitly do not have refunds um so that's a little bit of a tricky thing but that's how you keep the gas markets working cool and so yeah this was about the

question that you had where you basically just have two 15 59 like fee markets on l2 it's just the exact same one as ethereum um on l1 it has some slight differences but it does the same thing of you have a target uh you have a maximum gas and if it's above the target you raise the price until it lowers um it is also set up so this is where deposits are ordered by the contract and they're currently ordered by the first deposit in the contract becomes the first deposit of the block so it's the same order as they're executed on l1 that gets brought over to l2 so if there's a sudden spike of demand it

basically devolves back to pga on l1 rather than using the 1559 style mechanism but that's also what 1559 does yeah and then deposits are also executed before any l2 transaction on the l2 blocks oh yeah last thing still paying the l2 gas fee via a fee burn so you basically have to do a conversion from l1 gas to l1 eth to the gas price for l2 gas and then calculate kind of how much l2 gas you

bought so a little bit complex but from an end user perspective you just send a transaction to the deposit contract and it should just work and so at the end of that entire process you have admitted an event on the contract has kind of held the eth for you and so then on the sequencer you have l2 blocks and then they actually refer back to l1 blocks all the diagrams showing this um and then there's multiple l2 blocks per l1 block um because the l2 block time right now is probably gonna be two seconds so significantly faster than the l1 block time um and then so as each l2

block points back to an l1 block the very first block in that epoch is the block that must have deposits from that l1 block so skip ahead um so block one here has to include all the deposits from this l1 block and this is kind of the force inclusion mechanism we'll explain why the l2 chain must progress even though the sequencer's down but that's kind of how they get there so like here's block here um yeah here we go um block two no deposits in it uh but block three has all of the deposits that were included in this l1 block and so on and so on cool

yeah and so then getting into the first piece of kind of first mechanism where we enforce liveness is that the l1 origin um can't be very old relative to the timestamp of the l2 block um and so that just says if like because deposits have to be included you can't you can't just say i'm going to keep building on this block forever and just ignore deposits you eventually must use this l1 origin and all the deposits in that block

um yeah let's see other things yeah and just construct blocks from the l2 mempool like you have and then we have an l1 data availability fee and so we just kind of that's basically the same as it's now where we look at the l1 base fee look at how many bytes your transaction has i'll look at the zeros versus the ones or zeros versus non-zeros in that it's basically the formula that ethereum uses to charge it and then do some like a little bit of like uh constant overhead plus a modifier and so that's basically the same so you have your normal-like burn

normal minor tip and then an l1 fee which is unique to l2s and unique to optimism and then on the verifier side you read deposits just like the sequencer you read batches as well and then you construct the payload um actually the sequence also just doesn't even submit the deposited transactions because they're just already on chain uh construct it and so then here's the second mechanism then forces liveness we have the concept of the sequencing window and basically if uh the batcher has not submitted a batch in a specific amount of time you just

construct an empty batch to replace it uh so this is a liveness mechanism that says you can't ever get more than this out of date and then you just the kind of the window is from the l1 origin inside and that's for any specific l2 block so you actually get overlapping windows and sidenote you can actually you don't actually have to wait for the end of the sequencing window when you do this so if the batcher is live alive and it's behaving well you can stay very close to the kind of head of the chain yeah and so then the sequencing window um

so for blocks one and two uh this l1 origin is block one so the sequencing window is one two and three and so the badge could be submitted at any in any one of these blocks um and then if it's there's a badge for like block in black in block four that references one or two it's just thrown out and ignored same thing for three and four you only reference those two yeah and so that's kind of the sequencer just goes offline after the sequencing window is up uh you can just create these cool then the last uh thing here

is the sequencer is obviously producing blocks uh before they are batch submitted to l1 so this is where we draw a distinction between safe blocks which is just an l2 block that's fully derived from l1 and unsafe blocks which are just not fully derived from l1 and so then we basically have a process that compares um the unsafe blocks versus the safeblocks because we gossip the unsafe blocks around and the sequencer also checks against kind of what the batcher's done and what it's doing so it just handles so you basically end up with a

possibility for l2 reworks but you always favor what's happening on one versus what the sequencer is saying um it's the same logic so now the last component of diagram are these red blocks uh those are noted as unsafe blocks because uh say the l1 chain tip is four here there's no block five so you can't have waited a full sequencing window to have passed so maybe there's something in block five that modifies it so here the sequencer would have created these blocks and then would have gossiped them out uh to the rest of the network and then the network could have optimistically just put them in and then once you get block five

you'll be able to verify uh once you get l1 block 5 you'll be able to verify l2 block 5 and l2 block 6 and confirm that they're either the same in which case you just mark them as safe or if they're not the same you just reorg that portion of the chain yeah and so that's kind of how it's the high level overview of the chain and kind of how everything flows together pause for questions if anyone has any window after your transaction is

enqueued by the sequencer and before it's bundled when it's in that unsafe interval does that mean the ordering can change or like what guarantees do transactions have when they're in that intermediate phase before they've actually been included in a bundle on layer one um it's the guarantees is kind of the trust assumptions of the bachelor and the sequencer deposits get guaranteed that they'll be included in a very similar block but l2 transactions and i personally don't think of them as fully finalized until they're on l1 but also if it's like in there it's pretty similar to like a zero conf depth

on ethereum it's like it's probably going to get finalized uh but maybe there's a small chance it gets reorg i had a gas question sorry i know they're going to be lots of these so when you send messages from layer 1 to layer 2 you specify the l2 gas limit yes um so this is not for deposits this is for messaging right um but that doesn't get refunded or does it so when you're messaging from like calling a function on a contract on layer two from layer one yeah so that is a deposit oh it's seen as this okay and it uses the exact same mechanism as deposits okay and the refunds work in the same way no it works as the same way as deposits and remember

deposits don't get refunded on l2 right so let's say i want to make a complicated function call on layer 2 that spends like 5 million gas but maybe it spends 100 000 in some other case i must spend five million every time there's like no way to know like there's no way to get that like difference between my limits and what's spent back yes um the way you would do it is you'd basically need to do like a forwarding call on l2 um we we've thought about some designs of like having an additional gas provided on l2 but the user experience of having kind of the user experience of having refundable gas without breaking

a lot of things is very difficult and you'll always have to do something complex similar to this of like having a relayer on l2 so that's probably the best approach um you get credited based on the amount of eth you spent kind of doing some updates it's not a fixed amount cool thank you so this sequence windows size it's it's always constant or based on what you

decide this um going to be pretty constant maybe we'll have a method for updating it through governance or something but that's kind of how you expect it to update so what would happen if like the sequencer doesn't publish within this window so then you just create empty uh batches so you still have deposits but you don't have any l2 transactions so you can basically do everything you need to through deposits so even if the sequencer is fully down you can still progress the l2 chain

okay it's like the things that are on l1 get applied on l2 immediately okay cool well yep the question slides um see i've got this slide in here if people are really interested in really my new shay um but this is just kind of like how batches are like actually submitted to l1 so it's just like the time stamp the l1 origin and the transaction list without deposits we do a fair amount of work to really reduce the amount of data we post to l1 as well

as kind of post as much data per l1 transaction as possible and that's all about reducing the gas that it costs us um to submit uh the batched transactions and that means we can pass those savings on to our users so we do stuff like compression yeah like splitting stuff up um yeah and then of course because everything has to have a timeout there's more timeouts and just sanity limits there high level and then here's unfortunately pretty complex diagram um that i have to know uh because i have to go implement this uh

mostly implemented but yeah so it's just kind of like the data gets all squashed together and like maximally efficiently stored on l1 and then split back up onto l2 and then you can find this diagram and our specifications because everything is specified to an exacting level of detail yep um more questions can you talk a little bit about how the batcher will be decentralized if there needs to be some kind of leader election process because i imagine you don't want multiple posting the same data yeah so the batcher kind of the roadmap for decentralized

decentralization is probably going to be the proposer first because that's the easiest then the batcher and sequence are probably somewhere in together um so that's not we don't have a concrete plan for that um we're kind of thinking on it if you can authenticate the batch data from the blocks then you can do it in a pretty permissionless way maybe there's a leader election maybe there's like an auction that's something that's like definitely not fully clear yet thanks well so here's basically

a list of differences from the current system we're just going to go from this system into optimism bedrock uh it's gonna kind of system will just stop at one kind of geth node and switch over to another um so we'll have like actually a fixed l2 block time right now we mine a transaction every time you send us one or we make a block every cent every time you send us a transaction getting rid of some l1 smart contracts just have a much simpler batch submission format we're not reading anything um we're not actually acting on any of the data we're submitting to l1 and this is something that makes the migration to 484 really easily easy because we're

just posting data somewhere yeah we have l2 reorgs um they're not going to be that common but if there's a deep l1 reorg they'll definitely exist or if like the batcher goes down it could happen the whole kind of consensus using the e2 architecture means we're going to have snap sync and if anyone's ever actually operated um a geth node snap sync is a godsend uh and then because of like just recompiling stuff we'll be able to stay up to date with ethereum hardworks right now it's a huge amount of work to get anything upgraded yep peer-to-peer network

and then these mechanisms kind of mean a much faster deposit inclusion as well as nowhere near as much deposit reordering cool so if you want to learn more about this all the code is an optimism on a repo we have packages for the op node which is the roll up node the op batcher and the op proposer as well as the specs some of the diagrams you'll notice are the same and then as we start rolling this out kind of more publicly we'll have like an upgrade guide and higher level documentation uh this is still kind of in the development stage we're getting done with a lot of design and

like starting to get devnets up on kind of this summer fall are getting partners kind of testing the very first version so you get to actually join a very early devnet if you're interested but can also take some questions before we jump into getting a node up and running slide you spoke about two second block times can you talk about the limits per block and like how that works because now like each transaction is like a block implicitly because they're not bundled together but if they have like discrete timestamps like how does the limits on that work and is that does

that mimic like layer one and how does the pricing on that work just yeah can you comment on the implications that that has of a fixed l2 block time yeah yeah uh so it just means that also means we're moving over to an l1 type system where multiple transactions per block okay but that block the limitations on that like is that like a 1559 style system oh like the number of transactions in there yes that's exactly 1559. right um the final parameters in terms of gas limit gas target and upgrade speed aren't quite set yet but as a preview we'll probably have um we'll be a couple multiples over

ethereum in terms of like sustained throughput and then we'll actually probably have a pretty high max limit to enable an occasional large transaction because two seconds versus 12 seconds if you have even twice the gas of ethereum you're still a third of the maximum block size cool okay thanks hi uh i would like to ask about when we we executed the transactions for example i remember here is a fraud proof period right like seven days

and if there is a transaction that is detected there default and we want to execute all the following transactions i want to know if the transaction order will be executed as previously right um so this is probably another difference um where so it's a kind of philosophical thing um the kind of bridge from l2 to l1 is really about enabling that off ramp and kind of having like a native uh bridge that basically mirrors the

incoming message passaging um so the way i see it is that if there's ever a fault and the output there it's not so much that like a bad transaction was included and executed it's more that um you the propos the output proposer basically faked a transaction that says i have all the money now um and then even if the sequencer did spat submit this transaction but it wasn't kind of properly authenticated and it's not actually a valid state transition all the verifiers would reject that transaction as well

um so those would kind of be like the two checks you have it so your local node would not just like uh send all of the money away uh it'd be a divergence between a replica and what's proposed on l1 and if there's the divergence there then it's about bringing the bridge back in line okay thank you so then can kind of get into a little more

workshoppy component um so all the caveats on this is that the very unstable network it'll disappear in a bit um but those are kind of like early stages of getting everything up and running and kind of got some scripts for people to get up and kind of showing like how easy it is to get on um so there's a github repo um which is basically just a docker compose thing um i've set up a girly l1 rpc provider uh and kind of just help people go through this or like answer more questions also have some time back if you're not interested in this so this actually isn't my computer

a little hard for me to go through kind of showing you uh but i can kind of walk through it on my own laptop people are interested right anyway so that's basically it for me optimism bedrock we're also hiring that's it you