Monad: Accelerating Ethereum With Superscalar Pipelining | Eunice Giarta - Monad

[Music] hey everyone oh I can hear myself um hey everyone hope everyone is having a great Monday afternoon my name is Unice Garda and I am co-founder and COO of monad labs and today we're here to talk about accelerating the evm with super scaler pipelining firstly maybe we should quickly Define what is super scaler pipelining so to do so I have an example here this example is a series of tasks associated with doing laundry we're all familiar with that this is doing laundry without pipelining let's say that for whatever reason you have accumulated just a ton of laundry you're doing your Linens you're doing colors you're doing whites the naive way of doing laundry would be to do them all uh to do the full task for each load before starting the next so that would obviously take a really long time like if I did colors first and then moved it from the washer to the dryer then folded then put it away before then starting on the whites this little example here shows that I would spend most of my night just doing laundry we don't want to do that we want to think smarter so this is pipelining and the context of laundry so here I'm going to start on my colors at 600 p.m. going to take about an hour at 7 I move my colors to the washer sorry to the dryer now the washer is free so I have a free resource to use and I can then start loading my whites and that's what I do and so suddenly a task that would otherwise have taken several hours and my entire evening is done in a much more efficient manner super scaler pipelining effectively is uh efficient scheduling of your available resources all right so what does this mean in the context of manad I'm going to talk about two optimizations that um manad employs the first one is asynchronous execution and the second is parallel execution um yeah all right so first one asynchronous execution so a little bit of background today most blockchains have interleaved execution what does that mean it means that for every block both execution and consensus need to happen before the ne before a block can be finalized and before the next block can begin so consensus however is really expensive like you have nodes distributed across the world and you've got messages that need to be sent from one node to the next it just takes a really fraking long time which means that execution since it needs to fit within the bounds of a given block um only has a fraction of the block time to complete so let's take an example ethereum ethereum has a 12-sec block time this little block here will be our 12 seconds within that 12 seconds only a 100 milliseconds is actually dedicated to execution today that is a tiny budget just barely 1% which means everything else is dedicated to consensus what we're trying to do um I'm sorry more examples of interleaved execution here so here are our series of blocks with both execution and consensus execution the darker color consensus the lighter color um and here is how uh blocks are completed Over time however with asynchronous execution which is what manad does we separate out consensus from execution so that con blocks are no longer excuse me consensus is no longer a limit for the ability to execute transactions How We Do asynchronous execution is by deferring the execution so a block is finalized with consensus and execution happens independently so here's the series of uh blocks with just consensus and then execution that happens in a deferred manner the reason why this can exist is because the ordering of State sorry The Ordering of transactions is canonical as soon as blocks are produced and consensus is confirmed so in the uh well here's our pipelined look where now we can allocate consensus whenever consensus is available not taking into consideration execution and vice versa now it may not really look like that much of a difference here but what we now have is a greater opportunity to fill block space with execution in its entirety so that basically means much more execution bandwidth per block so more room for more transactions per block all right so in summary noes come to consensus um prior to execution um and execution will run in a deferred fashion so execution for Block one happens while consensus happens on block two um couple of notes here since it is a little bit different than the way other blocks um sorry other blockchains uh create blocks but we have thought about ways in which there is a delayed Merkel route to confirm the uh State executed across all nodes um as well as something called a um and now I'm blanking on it um we have a a way we have a form to uh prevent spam transactions as well Carriage cost I believe is what it's called all right now part two oh I'm already at part two I think I'm going really fast here I'll slow down a little um all right so the second one is parallel execution so today as we had already discussed transactions are linearly ordered um and they are also serially executed so there is a canonical and um prescribed ordering for all the transactions within the block one comes before two which comes before three so on and so forth um which is fine but it as we had noted it's a little bit inefficient so the goal is can we do this faster what is it or what is this can we get to the end State the eventual end state of execution um as if we were executing serially Faster by doing work smarter and not harder the way that manad does this is through parallel execution uh which is what it's a simple algorithm that has a lot of fancy terms um one example is OCC optimistic concurrency control another one you may have heard is STM software transactional memory um complicated terms but it all boils down to just doing the intuitive thing just really using my corsers over there um doing the intuitive thing which is to do things naively and optimistically so essentially we're going to try to execute as many transactions as we can at the very same time and what we do is we check the assumed inputs and the outputs of these transactions prior to confirming them and updating State um by doing this we can check to make sure the transactions and the results are valid and also reschedule transactions in the case of conflicts um and then yes eventually committing back to State okay so this here is a very basic visual of transactions um we're going to zoom into oh and for the sake of illustration these lines right here will denote some uh dependencies so we'll see here that the first transaction in this array of transactions uh is a dependency for the third um and you know a few others down the stack here basically this happens when what when the same smart contract is called across different transactions or the same account balances oops sorry okay so we're just going to zoom in working backward we're just going to zoom into the first five here um so we have transactions one 2 three four five the way that serial execution handles this is by scheduling them all uh sequentially right like the first one needs to be fully executed before the second one before the third fourth and fifth so it's not the most efficient as we know because this is exactly the same as doing a full load of laundry um before going on to the next laundry pile that you have in paral yeah in parallel execution um we'll discuss the intuitive algo here it really depends on the number of resources that you have available to execute transactions for this example we're just going to assume we have three different resources available to transact and again the goal is to um execute and shove in as many transactions as we can at the same time so here we're going to do so in order because again we're maintaining the linearity of transactions and executing transactions 1 two and three all at the same time ac across these three resources that we have and as each of these transactions complete um right now we have transaction three that completed we will add the pending results to a a Quee um to then be committed to eventual State uh um all right so in this example we have transaction three that uh completed first so we have that uh pending result and you can see here is there a pointer oh you can't see it um you can see then that the next available transaction is slotted in the resource that is available so T4 is then starting to be executed on that um open resource and uh so now we have you know pending results for each of these as they come available and scheduling that happens for um outstanding transactions for when these resources are available okay great so we're going to zoom in now on the pending results that we were talking about because again we're doing things very naively so we can't just blindly start committing um transactions in the case that there are conflicts so here's an illustration you recall in our example that transaction 3 is dependent on the results of TR transaction one so um what we did previously is schedule all of the work at the same time and so we're recording the um presumed inputs of all of these transactions along with the expected outputs of these transactions um all right so we don't really care about two three two four and five because they have no conflict they'll be able to be um merged and committed to State appropriately but anyway um let's say that I am the you know committed Q commit Q so I'm taking a look first at the pending results of number one confirming that the inputs match what I have in committed state so right here I start with a th000 usdc in my account and um I plan to send 100 usdc to Alice who starts with zero so what I do is make sure that my assumed inputs match what exists great they do I can go ahead and Commit This and update committed State the second transaction fine because again um there are no collisions here now we get to the pending result of the third one again recall that we um optimistically executed it and so our inputs our assumed inputs are now actually out of date because our committed state has been updated by the output of transaction one so I can't commit this because then it would you know throw the real execution State out of whack so what I can do is send this wrong way is send this for rescheduling so we'll go back to our queue here and now I going to be rescheduling transaction 3 to the next available resource which is the middle one right there you'll notice though that the time that it takes to reexecute transaction 3 is much smaller than the original one why well it's because we already have all of the memory required cached we've already been working with it recently and therefore it's very easily accessible um and what I mean by this is memory that you have to fetch from SSD or a hard drive is multiples more than fetching something that's immediately in memory and in Ram so anyway quick re-execution great so so now we have a revised input and a revised output does it match yes and now we have updated the state um and that is my example okay so I'm not sure what this slide was for but anyway some takeaways here um again parallel execution is to optimistically attempt to execute as many transactions as possible across all the open resources it produces a lot of pending results as a result of inputs and outputs and what we're trying to do is confirm the data that the input data for a transaction that is up for uh commitment matches what is available um or what is already committed to State before finalizing if there is a conflict easy we just reschedule um immediately and reschedules are generally cheap because data is cached and available um this is a simple and a compatible way of boosting the number of transactions that can be executed at any given time no access lists are required which means completely Backward Compatible and uh I think that pretty much wraps it up so super scalar pipelining the the two things that we highlighted today uh within execution are asynchronous execution and parallel execution um I hope you guys enjoyed and let me know if you have any questions more than Happ I don't know if this is like a There's an opportunity for a Q&A session but happy to do so as well um give me a follow on X or Twitter if you'd like along with our main account um and a quick um Community artwork featuring uh Keon's pfp there for accelerating the evm thanks so much everyone