 Okay, I know it's pretty early now. So we appreciate that you get up early and come to this talk So my name is Peter and I'm gonna talk about our work that we did at the Shanghai blockchain research Institute And what we did was we investigated how hard it would be to execute transactions in parallel on the EVM as you might know the EVM is Designed in a sequential manner. Usually you execute all transactions in a block one by one So the question is can we paralyze that what we found and what I want to talk about today is Two challenges that we identified and the first of those is transaction dependencies you're probably all familiar with How Ethereum works basically we have a global share state, which is the state tree Theoretically a transaction could access any point any entry in the state tree That is whether it can access a slot or not. That's defined by the contract code so for instance if you have two transactions from two different accounts and Both of them call the same contract and that's contract reads or writes the same entry Then these transactions will have a conflict or a dependency On Ethereum, this is not a problem now because we execute transactions sequentially But if you paralyze them then this will become a problem because you cannot concurrently execute such transactions. So we did some Evaluations basically what we did is we collected some storage traces for a few hundred thousands of blocks from you know historical data on Ethereum and we did some simulations with some OCC scheduler and what we found is that the theoretical maximum speedup is as little as four times So even if you have eight threads or sixteen threads at least on the VM level if you don't consider storage You cannot do much much better than four times and that's kind of an underwhelming result So some examples some simple examples of these dependencies for instance if you have two transactions to the same ERC 20 token if they send from the same sender or to the same receiver then they will conflict on the Balances mapping or if you have two transactions swapping tokens and uni swap Swapping the same token pair then both of them will modify the reserve variables So that's also another kind of conflict or if two transactions are minting an NFT Then for instance they can conflict on total supply if the contract is keeping track of that We identified this and this is an issue I think this severely limits the parallelizability of EVM transactions as they are today And we have some suggestions how we could improve this this kind of early just some ideas to to throw in there The first idea is to use a sharded counter. So from the examples before you saw that many of these conflicts are conflicts on a single storage slot, which is like an integer or some counter and Yeah, two transactions read and write the same slot So the idea would be to shard it into multiple slots. So one int is represented by three five seven slots And then we could route transactions based on some heuristic to different slots Let's say we take the last byte of the hash of the sender address so two transactions from different senders would probably With a higher probability, they would modify different slots in the contract and the second idea that we came up with is Lazy add opcodes. So for in this example, we have a very simple function. That's just incrementing a counter But when you compile it to EVM bytecode what you have is a storage load operation Then you do something with that value and you store it back. So to concurrent transactions We'll have a conflict on this like concurrent storage load storage store operations and You know, we cannot parallelize them The idea here is to maybe introduce a new kind of semantics for addition lazy add or commutative add and that would be evaluated lazily so these transactions can execute in Parallel and then we basically batch those two updates together into a single update at the end and that could be Executed at the end of the block for instance. The second challenge that we identified is that of determinism. So as you might know in parallel execution, there's You know, there's a lot of non-determinism and we can make sure that two transactions have the same result or two executions But there are other types of non-determinism for instance here We have two executions of three times three different transactions. Let's say transaction two Depends on transaction one. So in this case on node a one and two are executed concurrently So two has to abort and be re-executed because there's an update that it could not see and on node B They're executed sequentially. So node transaction two can commit directly Our idea is that if we have parallel execution at some point We have to introduce some incentives because if you can trigger some abort that kind of opens up The door for some denial of service attacks And if we do associate some incentives with abort then to these two executions in the example They will yield a difference final state. So that is gonna be an issue two nodes will diverge So for this we kind of came up with a new scheduling framework called Optimistic concurrency control with deterministic aborts and the idea is very simple instead of Deciding these aborts commit decisions during runtime you make this decision prior to running the transactions in a deterministic way so the these decisions will be Deterministically, you know the same on all nodes and this way even if you attach incentives to these decisions The final states that different nodes will arrive on will be the same So this is the OCCDA framework. I just summarized kind of the takeaway from this talk So it's pretty hard to get Paralysation done on the EVM because it was not designed with this in mind But I think it's gonna be worth it For instance, if you manage to scale a theorem on layer one or layer two with a higher transaction load Paralexecution will have a very big impact on the overall Yeah, efficiency of the system. So if you're interested in this, you know, research direction I would encourage you to you know, read up on it think about it and we actually have a Publication about this topic. So if you're interested in a much detailed discussion about the ideas that I talked about here You can go ahead and scan the QR code and read the preprint that kind of concludes my talk today. Thank you very much for coming Thank you very much Peter. We have time for one quick question I was wondering what your thoughts are on Parallelizing just balance transfers Which are much simpler Still contract stuff just like Ethereum balance transfers like certain transaction types are radically simpler than Contract execution and I wonder if you had any thoughts on that Yeah, that's a good question. So here we only considered Contract storage conflicts, but actually there are different kind of conflicts, you know Another part of the state trees the account with the nonce and the balance So, yeah, simple transfers are expected to be much easier to paralyze and even with contracts with access lists You get much more information That you can use to paralyze But I'm not sure the majority of transactions. I think our contract calls So I'm not sure about the impact of this, but I think that's certainly something to look into Thanks again. Okay. Thank you very much Peter and applause for Peter, please