Introduction to architecture | Optimism Summit 🔴✨ The Future of Ethereum - Joshua Gutow

foreign [Applause] [Music] Josh welcome thank you so much for being here I'll let you take it away awesome let's see I got my slides up okay slides up cool awesome hello everyone my name is Joshua uh and I'm going to be talking about introduction to architecture this is actually a little less uh architecture in terms of buildings and cool shapes in the sky but this is going to be about software architecture uh and then more specifically bedrocks architecture and as Carl was talking about the various components of the op stack this is going to really highlight uh how Bedrock the system fits together and all the different pieces there cool so the introduction ah so today I'm going to be talking about what even is optimism better Carl's talked on that but I'll expand on that a little bit more um I'm going to give an overview of the system both have kind of like the components and also the actors so we have a bunch of different pieces but some of them uh do different things then we'll go through the roll-up node which is one of the components the sequencer and the voucher and then the proposer fault proof challenge agent so that's all the stuff that enables withdrawals uh we'll go through a couple data flows um and then go through some kind of final implementation notes at end so what even is optimism Bedrock uh Bedrock is a network upgrade to reduce fees and increase implementation Simplicity uh so kind of go through a little bit word by word because it's a big complex sentence with a lot uh underneath of it so Network upgrade um so Bedrock is going to be kind of a point in time release uh the thing we'll have like we have our current system I will have the Bedrock release and then we'll have more releases in the future uh so it's not it's the network is still optimism and this is just the network upgrade and as part of a network upgrade we'll be keeping all of the history with optimism Network this is just one more step in improving the user experience and specifically the biggest change to the user experience experience is going to be reduced fees uh and then the non-changes to the user experience are going to be increased implementation Simplicity this is something that most users won't uh see but really improves the performance proves the reliability enables a lot of other things down the line how do we even we get there Bedrock achieves this by redesigning the role of architecture so a lot of the things uh from the previous system um kind of are getting modified and then we're drawing a lot of like new uh lines between different components inside the system and really making sure that everything fits together on a way we're happy with and also in a way that kind of enables different components to be swapped in swapped out how components can be tested by themselves and making sure that everything fits together very neatly so now we get into the fun part which is the architecture so we're going to go through the system overview so here's kind of the discrete components you have a roll-up node this is op node and then there's the execution engine op GIF we put op in front of everything because why not uh the Batcher is the op Batcher the proposers proposer and then we don't have a challenge agent and the fault proof is canon so if you know the no big gap um are kind of the things that produce blocks in uh that's like your full node on ethereum op Batcher submits all two transactions.1 um then the proposer submits output routes um and this is what enables with trolls and then we talked a little bit about Canon and we'll and have talked more about canon in the past uh but that is the Fault proof system and the challenge agent is just a simple uh agent that interacts with the fault brick system cool so those are different code bases and components how do they translate to the actors so the actor is someone running so you can run a multiple code base lots of times so verifiers that's a full node um so there's going to be a lot of those that's just like running your full node on ethereum and that's to do that you need your op node which is like a consensus client um as well as your op give which is your execution client um then you have the sequencer which is a full node that is Mining and so it produces blocks and then it also gossips them out and does a couple small things but under the hood it's very similar uh to the verifiers and then you have your Batcher which is an actor that just Maps straight back to the code base uh same with your proposer and then your challenge agents as well the sequencer and verifiers actually have to map to a couple code bases because they're more complex things so giant diagram type um so this is going through how all of these uh actors interact so if you want to kind of deposit into the system we'll just follow that execution flow so the user sends a deposit transaction to layer one um and then the sequencer reads the deposit sequencer also then gets transactions uh kind of separately then it creates the new blocks sequences them the Batcher then picks and that's kind of how you get deposits now once you have your L2 transactions included a user sends them to the verifier they get to the sequencer you create your blocks The Bachelor submits the batches now then the verifier reads both the posit and the batches and then it derives a chain that matches the sequencer and so that's kind of the transaction flow there's a lot of moving Parts here but that's kind of what it is and we'll go through some of these flows on a little more depth later on and then when you're doing output proposals uh the output proposal reads the state route from the verifier and then just submits it uh to L1 and that's the opiate proposer and then the challenge agent would interact uh would kind of use the verifier again looking at the state route and comparing it against what got submitted on L1 and so it's reading between the verifier and one those are again all the like uh system actors and how they interact so time to dig deep into the roll-up node so it does several things reset from L1 has both deposits and batches uh as Kyle mentioned it uses the L2 the engine API uh to talk uh to kind of the execution client op give there's a P2P Network I'll talk a bit more about that later um and then just as an implementation uh it's a ways simpler than the current L2 get implementation it's a lot closer to Upstream uh it's a lot easier to work with so the diagram so this is basically all of the components uh that you need uh to run a replica or a sequencer uh just in a note on opt-in a full node on optimism Network ah so on the ethereum side you have your consensus client uh and your execution client they talk to each other you use an engine API um and then your op node which mirrors the consensus client uh uses just your standard Json RPC so it does stuff like gets blocks gets transactions gets transaction receipts I just kind of essentially reading in um the chain data from L1 and then it talks to the L2 execution API L2 execution engine for through a very slightly modified engine API it's very similar but I'll talk through a couple of modifications there and then the op GIF or L2 GIF is a small diff on top of GIF it's actually a little larger than 500 lines right now but not really that much more um and so that's a lot easier to work with and keep uh the opgf up to date with Upstream so we can bring in a lot of those improvements a lot faster than if we had done a lot more modifications to that and so this is a single node so now what happens when you have multiple of these nodes uh so this is where every node is talking to almost every other node so the vertical lines there basically Maps back to the previous diagram and the two or sorry horizontal lines map back to the previous diagram and so the top line and the bottom line are two different sets of nodes so on the left here uh you have different consensus uh clients for ethereum talking to each other through the beacon train uh then L1 clients on ethereum have a sync protocol they have a transaction pool and then on the L2 side uh we gossip out L2 blocks for the op node and then we actually use a lot of the same uh sync mechanisms transaction pools all that uh when uh L2 execution engines are talking to each other so getting into the details of this engine API which is what connects the op node to opgf um it has two extensions and these extensions are to some of the uh payload attributes or like Fields so we have two more Fields when we're calling Fork twist update but the rest of it's basically the same and the engine API is actually really simple there's four calls one of which we don't use at all because we don't have a transition so it's just not relevant onto the new payload uh call is it just insert a new block into the execution layer simple uh Fork Choice updates a little more complex because it does two things at once uh it sets a head block including kind of safe and finalized blocks um and it also if you give it an optional parameter it starts the block building process and it returns back kind of a reference to that in-flight block and if you want to get that in-flight block that it's building you just get call get payload um so and that's basically it and this is pretty standard API it's specified by ethereum um and it makes it really easy to include new execution clients uh op Aragon that's not that much work to pour it over a thousand line diff um and then eventually we only have one roll-up node right now but it wouldn't be that hard to create a new roll-up node that spoke this API and and worked with any execution uh engine so deposits and batches um so we've briefly spoken about deposits as kind of a way to get money into L2 these are going to be a lot faster now because we're reading them a lot closer to the chain tip um but they also serve another purpose um and the sequencer basically cannot delay deposits uh outside of a certain range it has to eventually include them if you're interested in more details about the specifics of how this works I give a talk at HCC uh that does a really deep dive into bedrock and goes through all this and why this is true um but the net result of this is that um the chain advances even if the sequencer doesn't want it to um and then this enables sensorship resistance and then if you never had a sequencer again you could still unwind the chain through deposits so deposits also do a lot more than just mint money on L2 they're fully featured transactions so anything you can do with a normal transaction you can do with a deposit um and so typically you actually wouldn't use deposits that much to do this because um deposits just get included on L1 uh kind of one transaction at a time and actually have some State execution on L1 versus a kind of direct L2 transaction uh when we batch those we take a bunch of those we compress them and then we just shove it in call data of L1 so direct L2 transactions tend to be cheaper and that's kind of the typical flow but if you need to deposits are always there okay P2P um so here we kind of described how sequencers gossip cell blocks and so the feature that's enabled here is that if you're just a replica in the network and you're subscribing uh to these unsafe blocks or blocks that have the sequencer has just created your view of the network is incredibly up to date and so you can opt to choose to insert these blocks um now as part of kind of inserting these blocks we don't actually Mark these as fully safe um because there's no guarantee that the block that you received will kind of get submitted to L1 um so we prefer in the roll-up node Whatever Gets submitted to L1 over what the sequencer says um and kind of as a result of this uh it's a very minimal trust assumption to insert these blocks and stay up to sync with the tip of the chain um they have a really good user experience without actually sacrificing trust and this is kind of a similar thing to the liveness thing aliveness and ethereum where you have a head block which could reorb but then you have your safe block which is assumed not to reorg and then you have your finalized block which will never reord um and so we have uh We've brought over the same kind of terminology and same usage of the engine API to Mark blocks as safe which are very likely to not reorg finalize which will never reorg and then your head block which you've got from the sequencer which is likely to be included but it could change um and that's kind of the whole P2P subsystem uh and then as a part of the result of getting these uh blocks as they're distributed uh it's really easy to hook into a Snapseed uh it's not yet implemented because you can just re-execute all the blocks uh but that's something where this architecture of splitting out uh the execution engine from the consensus uh layer that's something that's really easy to do and something we will be doing in the future cool so we've covered the roll-up node on talked about opgath and the op node how they interact and how different nodes interact with each other on the network and now we're going to talk about the sequencer and the Batcher to concern the batch so what's here is basically talking about the sequence search a normal node essentially it runs a mining process uh and then it's like just like ethereum how every full node has mining code in it there's all like every rope node will also have mining code in it um and there's just one specific one that can run and then the Batcher is a pretty simple code base just takes all two blocks transforms them to the data that you expect uh does compression that's how you get low fees and then just submits them onto L1 uh easy peasy ah and then having that be so easy it was basically like small modular architecture that's a theme here um so now the proposer fault proofs and challenge agents so this is a group of uh kind of three which will be at least three different code bases and a couple different agents but uh what's here is this is everything that's required to enable withdrawals um so the proposer is kind of the entry point into withdrawals so it reads state from L2 and then puts it on to L1 and then after if you put it onto L1 and no one says this is invalid it's then assumed to be valid that's the optimistic part of our role um and that uh kind of validity then enables withdrawals um and if it oh sorry uh and if it's not valid uh then you go through the challenge game and the fault proof so it's not yet live uh uh see some Canon talks that North swaps given uh for more information about this um but the fault proof is what secures the bridge this is the how you say someone submits something that's invalid as a proposer the thought proof is what marks it as invalid um and it we time bound how long you have to say hey this is invalid so you can actually eventually withdraw actually eventually withdraw um and but it still needs some amount of time for the finalization period uh to basically uh have enough time that no one can censor the chain for long enough um with this withdrawal period so if it's like a 10 second finalization period you could censor the chain um and then get any fake output through with a week you can't uh censor the chain for a week and then if there's ever an invalid output proposal it will be caught uh uh and then so the actual fault proof game uh is super fun and exciting and I'll nerd out a little bit over it so the entire thing is called Canon and it has its whole own sub architecture uh it's like a lot of interesting things in there um but it's an interactive proof game over our myths execution Chase so like everything here it's a lot summarized into a short sentence um so the interactive proof game is kind of this binary search like thing uh so you start out with some code you execute the code and you can imagine the code is like executing an instruction like an ad a subtraction a load from memory um and so what we do is we have kind of an on-chain version of this and then your two off chain components the two often people uh both run their execution Chase execution your Challenger and your Defender so the defender is the person that submitted the output proposal and your Challenger is the person that says no this is invalid um and at each you run the execution trace and you agree on the start and disagree on the end um and then you can kind of merkelize the State uh do some funky things in there and then basically run a binary search over like okay we agree at this step we disagree at this step and then you can finally narrow it down to a single instruction execution uh and then execute that single instruction on chain uh it's super fun super interesting uh and then actually enables you to kind of bulletproof really complex things really easily so anything that's deterministic and compiles to nips can be fault proven so the whole derivation process is going to get imported to Canon uh all of the evm is going to get imported to Canon and we'll kind of go through the fault proof any compression we do again just straight through uh so we don't have to deal with like loading up tablet we can load in the Raw data um that the roll-up node uses which is again just transactions and blocks and so those are really easy to kind of load up on chain and prove that hey this is actually the block hash on chain uh and so that's basically uh all of that ah super fun super interesting uh not yet live but we're working a bunch on that okay uh getting back here okay so that's how we secure the system uh so I'm gonna go through uh some data flows in the system uh you'll see how kind of different things interact and maybe I'll make it a little more concrete so I will talk through the deposit uh L2 transactions and we'll also go through withdrawals in a little more detail so the deposit you send a transaction to a contract and the key thing is that the contract does some computation make sure you pay your fees make sure you lock up your eth and then in the midst uh the event and that event is what we're looking for on the LT node that's the authorization that yes you locked up yes all of this is valid uh then the world node reads uh the event um creates a special transaction type on L2 and then we insert these transactions at the start of the block and then eventually that deposit gets executed on L2 there's a couple more details in there around like gas accounting but not quite relevant for this talk so then if you're submitting uh direct to L2 transaction uh you send out your transaction it gets to the sequencer and then the sequencer has its a set of transactions and kind of its local mempool and then it creates a block based on that then once the sequencer has created its uh block um the Batcher says hey there's a new block we need to go submit it to L1 um so then it takes it combines it with a bunch of other blocks does some data transformation compresses it all just a little more like data slicing and then puts it on L1 and then then the roll-up nodes read all the call debit look for transactions to a specific address checked authorization on those transactions um and then reassemble uh the blocks from that submitted data and then you have voila your transaction on L2 cool so withdrawals so withdrawals are a little more complex uh because you have to manually kind of do the communication across the layers so to initiate your withdrawal uh you send a transaction to L2 um to the withdrawal contract and so the withdrawal contract does several things um it basically creates a commitment to how much you're withdrawing um then uh Burns how much if you said you withdrawal and that's event to make it easy to index and uh track it uh and then it also touches some L2 State uh based on kind of the commitment uh to the withdrawal and this touching is really important because we'll use that later to verify that you actually burnt your funds on L2 and can kind of withdraw them from the optimism part on L1 so after you do this uh then you have to wait around for the proposer uh to see okay I've got this new output root let's go have the proposer submitted on L1 you have to go through the challenge period uh to say that no one's making a fake uh withdrawal and then finally you can execute your withdrawal on L1 and so what you're doing there is verifying the withdrawal contract or the optimism portal on L1 when you're doing withdrawal is verifying that you have a valid proof uh of your kind of commitment to your withdrawal so like you have a withdrawals it says I want 10 each back and says hey you actually did have uh an event or a state on L2 that shows that the only way the state could have been true is that if you would actually burnt uh 10 each on L2 so that's like the proof system there um it's basically the overview there's a couple more details about assembling all of the proofs uh but that's kind of Highly mid-level overview not fully high level so we have a couple data flows let's talk about how it's all assembled so we've been talking about a bunch of different components and there's a lot of small modular code bases so the opinode is about 15 000 lines of code the op Gaff it's about an extra thousand lines of code on top of normal GIF and we find that's kind of what it takes to get another execution engine on to optimism uh they'll be Badger and the proposer around 2000 lines of code uh as we kind of get those more production ready I'll grow a little bit but it's likely to remain under five thousand uh the contracts around the portal uh two contracts all that's around 10 000 lines of code but that's with all of our tests and supporting code so none of these are giant uh hairy code bases that are all intertangled they're all kind of off in our own little world they have clean API boundaries between them um and they're a lot easy to work with easy to upgrade and so that's one of been one of the big pushes uh with this new architecture uh so if you're interested and kind of looking at the code learning more about it uh all of our code is in the optimism mono repo we have the opioid code base the op Badger code base the opp proposer those are just top level folders uh if you want to look at the Bedrock contracts it's in packages contracts Bedrock self-explanatory um and then we have specifications for how the entire system should work inside the specs folder cool so in summary edruck is a network upgrade to reduce fees and increase implementation Simplicity and we basically talked through all of the architecture that enables this ah so this was introduction to bedrocks architecture again I'm Joshua good tote I'm in Twitter triangle sphere and if you're interested on working with optimism or all sorts of positions there but in particular we have positions to work on Bedrock so if this is exciting to you uh we're hiring at jobs at optimism.io cool that's it for me have a good day everyone