Asynchronous Execution in Practice

Transcript

Hello. Greetings. I'm about to blow your mind, I hope. Uh and maybe change how you look at blockchain for performance. Uh but before we get started, uh I want to meet you guys. And so the first part, I have some questions. And so just raise your hand if it's true. Uh who has sent a blockchain transaction? All right. Who has sent a blockchain transaction on a fast blockchain that's less than a second block time? All right. Who has heard of asynchronous or delayed execution?

All right. So I get to talk uh convince half of you, maybe. All right. And who has authored an EIP or commented on one? Cool. And who knows what percentage of the 12-second block time on Ethereum is the target budget for actually executing the block? All right. Let's hear some answers. Actual execution couple of milliseconds. Yes. Yeah, that's pretty much. All right. So about me. Uh my name is Daniel Von Fange. I'm a senior protocol engineer at Monad, a fast L1 blockchain.

For 5 years before that, I was a security-focused smart contract engineer uh building uh three different nine-figure TLV DeFi products, as well as a whole bunch of smaller ones. Um and I started working in Ethereum Christmas of 2017. Uh so most of my perspective is from somebody who's been using uh blockchain for a long time. All right. How can you get an order of magnitude performance improvement? You know, 20% is great. How do you get 10 times?

That's what we're going to talk about today. Uh this is a diagram of what happens inside a the 12 seconds of an Ethereum block. And I got this from Maria's post on Eth Research. So thank you for that. And there's three things that need to happen inside a block that you can kind of simplify all this stuff down to and really kind of apply to basically any blockchain. You have sending the block out, distributing it. Then you have executing it, doing the work.

And then you have agreeing on what happened. And so this kind of simplifies down this. Now, if we look at it like this, this is a more realistic distribution of how it looks inside of an Ethereum block. And as you said, it's several hundred milliseconds. Uh I heard it like a target of a hundred milliseconds up to a max of a second, although I think a half a second is kind of a more realistic max. But the basic thing is that little bar is what is actually doing the work that we're all here for uh at least if you're in executing transactions land.

And this is for ants. This is a very tiny tiny portion of the actual time that's going on. And so if you saw this in a profiler, if you were trying to optimize some software, you would not be happy and you would go do something about it. So we're going to talk about how to fix that, but we're going to kind of go over some quick high-level blockchain concepts first. So you have a transaction. It's basically instructions for something to happen. It doesn't mean that it will happen, but you want it to happen. So Kevin pay Jane 15.

You have state. Kevin has a hundred, Jane has a hundred. This is kind of a fixed view of the world. Execution goes through and it takes transactions and applies them one at a time, basically, to state. Uh again, some of these may fail. And then at the end, you have a new state. Finally, you have consensus that means everybody agrees on everything. And so these are the fundamentals. And on Ethereum, it happens kind of in this fashion where you build, distribute, execute, agree. Now one reason why this is slow is you can't agree until you execute.

And you can't execute until you got the block. And you don't have the block until somebody builds it. And so this is an enforced serialization thing. But there's nothing in the universe that says that it has to be this way. That's a choice to be this way. It's not a requirement to be this way. So let's jump to something another view of this same thing. Let's say you want to sync up a view of the blockchain to a local node or something. One way you can do this is by replaying transactions. So let's say you go and you download all the trans all the blocks with all the transactions,

and then you go through and you execute them. You would have the current state. Uh now this is actually not as efficient as it could be, even though this would be tremendously faster than uh how fast things get executed live following. So a more efficient way is to download the blocks, but as you're downloading the blocks, as soon as you download a block, you go ahead and execute it. And then you download next block, execute it. And so you just have one process downloading blocks, another process executing. And if you squint hard, this is an ultra-performance blockchain we're looking at right now.

Um now this is obviously there's no agreement. It's missing stuff. But there's a core concept here that can give you extreme performance. And so let's take this same core concept and move it into uh a blockchain design. So you get a block. Well, as soon as you get the block, you execute it. And then you also start your agreement process in parallel to it. And you can actually make this execution happen you even have more time for execution because the reality is you don't actually need to finish execution until the next block is here. And you're

ready to go on to the next execution. So what you actually have here is you have two lanes. And now execution can use 100% of wall clock time. Which compared to using 1%, 2% is an obviously dramatic difference. Uh if you're getting really fancy with this, you can even let a burst go a little bit farther. Uh and so you can actually have a block that runs a little extra long. Uh you can't do this forever, obviously, but you can do it uh just to to handle block bursts.

All right. So it's amazing to have 100% of wall clock time able to be used for execution. What does this take? Well, you must be able to build and validate a block without executing it. And although this may sound weird or strange, there's actually nothing that prevents you from doing this. Uh a block is just a list of transactions uh essentially. And you can make a list of transactions. You can verify that the list of transactions looks good and uh that it was sent by the correct person who should have done it without having executed it.

Now, why is this tricky? The first thing is gas. Uh if you just let people say, "Hey, I'll pay for this block." And then they don't have the money for it, then you don't get paid. An attacker could just repeat that, fill up a blocks with nothing, and your chain is dust. Now, for EOA accounts, this is actually very simple to deal with because anytime an EOA account spends money, it appears in a transaction. And so it either appears as gas or it appears as value. And so you can very easily look at future or transactions that you haven't executed yet, kind of that intermediate set, and see that they aren't actually going to have money to

pay for this and just not include their transaction. The second tricky part is gas used. Um in Ethereum, you set a max gas. And this then gets adjusted down based on what you actually use. But with asynchronous execution, somebody's taking up your block gas with transactions. And if they only use, you know, if they request 10 million, only use 20,000, and do this a whole bunch of times, you've again back into that DOS situation.

So the simple solution to this is just to charge the entire thing that they request ever reserved as the amount that they pay. And this actually works out in practice. I kind of wondered how that would actually work. Um and people actually get much better about estimating it when they pay the entire amount. Uh I think they're twice as close to the actual gas used on Monad versus base Ethereum. Um so in practice, this one doesn't really matter that much. And there's room maybe for some rebates or something for a small percentage of it.

The last one is 7702. And this is where it gets really tricky because a 7702 account delegates code, acts like a smart contract, and can be called from deep inside a transaction. You have no visibility of it from the block level. And so it would be easy for somebody to queue up a whole big list of transactions. And like the first one of that thing actually spends all their money, and then you're in a DOS situation. So the way Monad handles this is we have reserved gas for accounts that have a 7702 delegation. And basically, you take 10 Mon, which is like 25 cents or something, um and you say you can't spend that from inside a contract call.

It can only be spent by the transaction level for gas. And that way it's safe to queue up transactions for that account because you know that they'll never be able to make the account unable to pay for them. All right, EIP compatibility. Um This is not actually past EIPs. This is talking about future EIPs. Um we have block access lists coming and a block access list takes uh and sends alongside the block a list of or with the block a list of every storage that was read and every storage that was written as well as the values that were written uh with it. Now, this does legitimately make uh execution

faster. Reading from disk is a core constraint for execution. Um at the cost of storage stuff or networks stuff. However, it's not compatible with asynchronous execution just because if you have never executed the block when you send it and built it, then you can't include a list of everything that it touches. And if you are agreeing on it before you've executed it, you can't uh check that it's true and you know, vote for things that are only valid.

Uh on the other hand, you know, in a choice between block access list or asynchronous execution, block access list maybe gets you a 2x performance on a non-parallel uh executing environment, but double your network usage. Whereas asynchronous execution does not affect your network usage and gets you like a 10x speedup. So, I have a clear favorite here. Uh the next one is frame transactions. Frame transactions are an upcoming uh thing that's not implemented yet, but makes smart contracts able to authorize transactions.

And basically when your transaction runs, it actually calls a smart contract code that it can then read storage slots from the uh storage and make a decision whether to allow that transaction or not. Adding to this, frame transactions also if it's not approved inside the frame inside that execution, it is invalid to even be included in the block. It's a uh it's a bad block that gets completely rejected if any frame transaction inside doesn't approve itself. Uh and so this is obviously incredibly incompatible with asynchronous execution.

Uh All right. On to user impact. Uh one thing that I was concerned about at first is delayed view of what's happening. In practice, as soon as that you've received a block and it's been executed, you can see what happened in the block. There's no real difference uh from a user point of view. Uh nonces felt a little bit squirrely, but actually it's the same thing as Ethereum. Uh you know, you send transactions out there and you don't actually know what has landed until it actually uh takes place.

Um and actually because the nonce incrementing itself is actually happening in part of the transaction, not even the execution, uh this is not an issue. The reserved balances, yes, these are a squirrely part. Uh and I don't like it, but it's kind of the only way to handle 7702s. And lastly, it's just really, really, really fast. It opens up oceans of performance uh capabilities and that's the that is the user impact, basically.

So, in conclusion, when you can have this, why would you want that? And that's it. I'm open for questions. >> [applause] >> Uh anyone have a question, please? Yes. Yes, I was hoping for lots of questions. Yes, thanks. Uh how does this interact with DK rollups like or DK real-time proving?

I'm not really sure if you have anything Mosin, but uh it's for Ethereum style transactions, it doesn't affect much. Yeah, and if you're just distributing data and agreeing on the data, you're not really doing that execution phase anyway. Another question? No? Yes. Uh so, what is the plan when frame transactions and uh block access list land?

Will you like off from being completely Ethereum compatible? I'm not the absolute authority on that, but my guess is yes. Um yeah. What else? No? Thank you for the presentation. >> [applause]