# Searching for EVM Parallelism - Ben Jones - Speakers: [Ben Jones](https://streameth.org/speakers/ben-jones) - Channel: [ETHGlobal](https://streameth.org/ethglobal) - Date: 2021-10-09 - Duration: 11:00 - Topics: Ethereum, Ben Jones, Optimism, ETHGlobal, EVM Parallelism - Watch: https://streameth.org/watch/yt-4FknO8ooqhE - YouTube: https://www.youtube.com/watch?v=4FknO8ooqhE ## Description Ben Jones of Optimism talk about state access in relation to EVM parallelism. ---------------------------------------------------- Follow us: https://twitter.com/ETHGlobal​ Check us out: https://ethglobal.co​ Email us at: hello@ethglobal.co ## Transcript all right hello everyone i am ben and i am a co-founder of optimism we're building optimistic ethereum uh layer 2 scaling solution for making your evm more beautiful and fun and fast and cheap so today i'm going to be talking about uh some old things and some new things and their intersection so we have this enticing title searching for edm parallelism but where i want to start is just talking a little bit about mev and how we're thinking about it on l2 and especially how it's been in the last year uh because about a year ago uh oh i guess a year and a half ago now uh we put out this post called mev auction um which basically talked about how in protocols generally not just on l2 although l2 is particularly suited for implementing it we really can separate out the role of transaction inclusion and transaction ordering and break those into two separate rules and there's some fun stuff we can do with that especially if we auction off the right to ordering those transactions um and we call these mev auctions so i just want to reflect for a minute on where we're at with that a year and a half in and there's an elephant in the room that relates to this which is flashbots so i think this chart is way out of date we're way above sixty percent uh hash right now running flashbacks if i'm not right if i'm if i'm not wrong um and this is a question that comes up a lot people look at that post that we put out and say okay that's an auction for mev how does that compare does it relate does it contrast does it complement with flashbots auction because now we have 60 plus of the hash rate running mev death and basically running auctions for mev uh so that's a really great question and the cool thing about it is that they are totally complementary so i just want to talk a little bit about that to set the stage cool so the mev auctions that we were talking about and this flashback auctions are not the same thing and they're actually complementary so the analogous property uh that these mev auctions where you're in the protocol selling off the rights to ordering within the protocol is actually similar to leader selection or like proof of work or proof of stake and you can think about the sequencer that is being a position auctioned off in mev auctions is actually a the equivalent to the proof of work or the proof of stake that's determining the block proposer for the protocol so this is an important note obviously we have mev auctions in some effect taking place with flashbots right now but this did not require a fork of the l1 it didn't it didn't require a change of protocol we still have miners that are finalizing and assembling these blocks and continuing the chain and yet we still somehow have these auctions going on as well so what does that mean why is that and really the answer is that we're just further separating concerns so whereas before on l1 we had miners and the pools that were both uh progressing the consensus of the protocol and determining the ordering we actually still have that ordering being upheld by the miners but where flashbacks comes into play is that we now have a secondary market for reselling that ordering and that's really what flashbots is doing um and i think this is an important note because uh it's a separation of concerns where now we have miners that able are able to do their specific thing that they're good at which is compete on providing network security and they're able to outsource the searching for the mev extraction and what is the correct order to make uh to annex to external parties and flashbots is there providing that auction that sits in the middle um and of course right this is an order so a a market so in fact there's a bunch of people that are participating in this market not just one big yellow circle so i added some more yellow circles oh yeah so what do we expect this to look like on l2 right is is it is it a matter of these med auctions replacing one part of this or something else the answer is something else what we can imagine on layer two is that we have l1 that is determining the uh inclusion of transactions we have an in protocol on l1 effectively a sale of who is allowed to order transactions um through an mev auction but there's no reason and in fact now that we see the popularity of flashbots we actually think it's very very likely that we will still see resale of ordering rights on layer two um so we still would can expect to see a secondary order uh a secondary market for ordering and it actually is complementary to these two things they both come they both come into play so it's not a matter of whoops it's not a matter of replacing some part of this it's putting something in the middle and extending it extending it okay so that's why i want to say oh and then also by selling it off within the protocol we can redirect those funds to all sorts of lovely projects and research and development that's for another talk okay let me do a time check oh we're doing great on time good good so okay that's a bit of an aside and update on our thinking about uh mev on l2 now i want to talk a little bit about some new stuff on how we're realizing we can use this given the fact that it seems very very possible that we'll have these both of these markets layered on top of each other okay so we're going to start with the digression into a very old problem now i guess old for the crypto space which is parallelizability i guess the problem statement really is the evm is darn slow and one of the reasons it's so slow is because you have to run it in serial you can only run it on a single thread so uh we have here from from metallic an eip that's wow fully four years old at this point um talking about maybe we can parallelize these things and uh think by things i mean transactions and spoiler alert that is still an open pr um so we're not there yet although we are getting closer right so one of our recent forks we had access lists which could set the stage for parallelism but hasn't quite done that yet because they're optional but it's worth noting okay so why are we four years in and not having parallelized edm yet the answer is basically about is basically about state access and the and what happens when you say that transactions can or can't be parallelized so to very quickly summarize right if we have two transactions and they do not touch the same state then they are parallelizable if they do touch the same state then they are not parallelizable okay so this is pretty obvious if they touch the same state then you're required to know what modification the first made to the state before you could know the result of the second okay so that's a very simple definition of parallelism and the reason that we haven't seen these things is because in the current evm design any smart contract at any time can talk to any other of these money legos right this is like a huge feature of the evm is that we can just jump around and call any contract and everything's very interoperable and lovely but it does come with a problem for parallelism because it means that you can't know if two transactions are parallelizable until you have run them both because it could be the last very last thing that one transaction does is to call out to another piece of state uh that intersects with the access list for a previous transaction okay um so just to just to maybe state this in even more simple way like there's a there's more complex things you can do with gas metering but we could just try to parallelize the evm right now we could say okay consider a block we're going to introduce a new block validity rule which is that no transactions can touch the same state within the same block this is maybe not maybe not the best way to do it but it's very simple to imagine right if there are txi and txj such that they're not parallelizable meaning their state intersects then the block is invalid so why haven't we done this yet if we have such a simple construction that will let us increase the throughput of our edm can we do this the answer is we could sort of but it's not so clear and in particular there's two there's two separate things and one is okay and the other is not from the perspective of a verifier so someone who's taking the chain and checking that it's valid there's no problem with this condition this is a very simple condition to check and you just as a part of your processing you output you look at the result you say did these things intersect uh yes they did therefore it's not parallelizable and it's an invalid block the problem comes from block production because block producers don't know whether or not two transactions are going to intersect without running them and they have to choose them somehow so how do the block producers choose a valid block it's often considered a dos vector so i want to quickly call out jeff coleman i i think this presentation is public if not i'll link it after um for a great little little thread on this but just a quick uh a quick chunk of this is that you can really think of there being a first run of a transaction and a second run and the first run is what happens when you're producing the block and the second run is what happens when someone is verifying an already produced block and these two things are different okay so this problem of how does the miner how does the block producer figure out whether or not it can put these two transactions will they be parallel this is the problem that we have right now okay but i now have a question for you and especially if you're in the flashbots community does this problem statement sound familiar to you the problem that you don't know whether a transaction is valid until you've run it well i will tell you that this should be a problem that you're familiar with because it is exactly what we see in flashbots so i took this from some of the docs um on flashbots right flashbots what is fundamentally doing it's letting you pay the miners at the end of a transaction so literally i mean at any point in time but literally in the example that that is like the first one i found on github the very last thing that happens in this in this um flashbots execution is the transfer to the coinbase so this is the exact same problem statement that we have for valid bundles and flashbots and valid blocks in a parallel block validity condition it is impossible to know beforehand but you can know after and it's not then that part is no problem so i'm running i'm running a little short on time so maybe we'll have some more time back for you too tina but the thing that i just want to conclude with is that this is awesome because we are not yet seeing flashbacks collapse due to dos i think there's concerns but what's very exciting is that y'all are working on it so this is a message to all of the folks that are out there um working on flashbacks and and keeping this alive you are actually going to increase the throughput of our chain more than you even realized and that is incredibly exciting so that is my 15-minute talk thanks y'all