# Reflections on Building Monad + Predictions for the Future of L1 Scaling | Keone Hon - Monad - Channel: [Ethereum Denver](https://streameth.org/ethereum-denver) - Date: 2026-03-09 - Duration: 20:05 - Topics: ETHDenver, Crypto, Web3, Blockchain, Event, Conference, ETHDenver 2025, ETHDenver 2024, Bitcoin, Ethereum - Watch: https://streameth.org/watch/yt-ViZnuKJozdg - YouTube: https://www.youtube.com/watch?v=ViZnuKJozdg ## Description Monad is a next-generation, Ethereum-compatible chain delivering 10,000. TPS, sub-second finality, low fees, and scalable decentralization. All in one. ## Transcript All right, welcome back. Our next speaker is Kone Han, co-founder and general manager at Monad Foundation. He'll be covering his reflections on building Monad and his predictions for the future of L1 scaling. Please welcome Kion. >> Hello. So great to be here. I'll be covering two major topics. The first is reflecting on some of the major improvements that went into Monad and some of the major efforts to deliver really high performance layer 1. And then in the second part of this talk, I will try to use that reflection to make some predictions about how Ethereum L1 scaling will go over the next couple of years. Um, and some of the things that I'm excited about, first of all, just to give a quick overview of Monad. Uh, Monad is a really high performance EVM layer 1. Launched the mainet. The mainet of Monad launched about 3 months ago. And since then, uh, Monad has seen about 150 million transactions over those three months. um with $450 million of stable coin market cap and about $250 million of DeFi TVL so far. Um and we're just getting started. This talk is going to be about some of the technology behind Monad, some of the insights. Um and really I think the main takeaway that if if nothing else, what I would like you to take away is that L1 scaling is not only a cryptography problem. It's not only a consensus theory problem, but it's also a systems engineering problem. And many different systems engineering innovations have gone into getting us to where we are. And I'm really excited about the future um as we continue to push forward. So, four major innovations. The first is the bottleneck is IO. It's not computation. Um storage architecture matters much more than uh raw CPU output. um because the CPU is far overpowered relative to the cost of of doing storage reads. Um the second insight is that we can deliver parallel execution without changing any of the EVM semantics without changing solidity at all. So that exactly the same smart contracts can be reused. The third insight is that pipelining is really a multiplier. pipelining evidences itself through many different parts of Monad um throughout the stack which we'll talk about in greater depth here and then lastly EVM equivalence ultimately is non-negotiable um it's incredibly important and it it's what pushes us forward okay starting first with IO instead of CPU so I think a common misconception is that EVM execution is slow because of some fundamental issues with the VM or like the overhead of um executing inside of a virtual machine. Uh that the op the op codes that are chosen are not efficient and that we could get better performance by switching to a different VM. U but the reality is that the EVM is actually a great standard. It's really powerful. Um it's only the storage access that delivers a lot of the real bottlenecks that exists right now. Um, and with existing clients, the access pattern for storage involves a lot of random accesses throughout the disk. It's not optimized at all. And that really dominates the cost of execution. So, we need two major improvements in storage in order to deliver in order to address this huge problem. Um, and they're both needed actually. It's not just one by itself that can deliver the performance gains. These two improvements are a new database that's optimized for the Ethereum Merkel tree that's optimized um for the specific format of how data is stored in Ethereum. Um and we call that database monad DB. We'll talk a little bit more of that in a second. And then the second unlock is that we also need asynchronous IO. Um so we need to basically run many fibers in parallel to initiate many reads from the SSD in parallel. Um and we do that by using an asynchronous IO framework um for the Linux uh for Linux computers called IO ring. Okay. So first of all monad DB. So this is sort of um just to go back to the overall talk um we have four major bullet points and this is bullet point 1a um so monad db has a bunch of different improvements um it first of all is a db that's optimized for storing the ethereum merkel tree and what that means is that compared to other um instances of an ethereum state storage where there's a layer of indirection coming from um using rox db or level DB or some other generic key value store. Monad DB is a DB specifically architected for the Ethereum Merkel tree. Um when you're traversing a Merkel tree, uh when there's it's stored using another key value store, there's a whole bunch of other metadata that ends up getting stored in order to manage that navigation. Um, for example, when you visit one node in the tree, um, there's some information that tells you where to go find the next node, where to find the next node, and so on. Um, and then when you're recomputing Merkel root hash, uh, Merkel roots of the tree, um, you need to like go and visit a bunch of nodes in order to look up their hashes because those are inputs ultimately into the root. And so, Monad DB sort of optimizes for all of these common patterns by storing a little bit more data. Um, and also by very thoughtfully storing nodes that are related to each other, very close to each other so that when we're reading, we incur far fewer IO hits to the SSD than uh others. And then the second improvement, so this is sort of section 1B of improvements is IO ring. IOU Ring is a framework um for the uh Linux operating system that allows for asynchronous reads from an SSD or from a storage device. Um and it basically has two ring buffers that um store requests to the data and that store the responses from um the SSD um the submission Q and the completion Q. And so it's a really optimized framework um that allows you to initiate many different requests to the database in parallel um which is appropriate in this case in this workload um because in Ethereum or in monad you have a block with a whole bunch of transactions and every single transaction is incurring a bunch of slo op codes that uh correspond to going to the disk and retrieving some piece of data. Um so basically what ends up happening is when executing a whole bunch of transactions for a monad block each transaction gets assigned a fiber and that um within the course of execution of that fiber uh the the op codes are being replayed whenever we en encounter an slo op code that means go ask the SSD for that data um and then it's going to take a while for that to process but in parallel many other fibers are executing many other transactions and going and asking for their data as well. Um, in reflecting on this effort, this was a very heavy lift. There was a lot of effort and a lot of redirections that went into this. Um, because uh, I ring a pretty low-level interface and uh, although it's well documented, not all the functionality works exactly the way you would expect. Um and also some of the ultimately best practices end up being different than what is theoretical. So as one example um our team believed that uh you know 1,024 fibers was the right number of fibers to initiate in parallel to do,024 reads. Um but it has turned out through empirical testing that it was more like 128 fibers that end up being right um to go because more than that uh basically the SSD ends up being a bottleneck. I'm just going to keep going quickly because I want to just keep dumping insights. Um so insight number two is that we can deliver parallel EVM without changing any of the EVM semantics. Um and we do this through a method that is similar to sort of standard CS techniques. um optimistic concurrency control. Um and really what it is is a very simple intuition. We should simply attempt to try to execute many transactions in parallel and keep track of all the inputs and keep track of all of the outputs of that transaction. When I say input, I mean a storage slot that was read in. And when I say output, I mean a storage slot that was written. Um so just to give a very simple example um when we're processing block N transaction one might read storage slot A and write storage slot B and we're going to assign that to fiber number one. And then transaction two uh when we execute it turns out that it read storage slot C and it wrote storage slot D. Um and the execution of that is on some other fiber and then transaction. So basically like when we're executing we're actually executing many transactions in parallel all assigned to different fibers and then just seeing what the result is like what storage slots were read in and out and resolving conflicts if they come. So in this example uh what I started to say was that transaction 3 is a conflict because it reads storage slot B but storage slot B was written by transaction one which was running in parallel. So when we commit the results of these transactions, we commit the result of transaction one and two without any issues, but transaction three um is going to just require re-execution. Not a big deal. Not all conflicts are actually real conflicts. Um so this is actually kind of the cutting edge of um where the Monet execution system is right now. I'll just give you a very simple example. If you have a transaction that ends up uh the the consequence of it is that a particular storage slot increments by 50 and then there's another transaction in which the consequence of that storage slot increments that storage slot by 100 um then these two transactions although they do touch the same piece of state um and although there are serial dependencies they're actually reversible um they actually do not affect each other and so sort the next cutting edge version of Monad will be to be smart about that and to realize when there are serial dependencies that aren't true dependencies um and be willing to tolerate when they were executed in the wrong order. Um so this is kind of a work in progress but we call this the relaxed merge um innovation. It's a PR in um the Monad repo right now that's being reviewed and discussed. there's a lot of corner cases. Um, but things like this can further accelerate execution. The third insight I want to talk about is pipelining. So, pipelining more generally is the idea of doing work in stages and doing work from uh doing multiple workloads in parallel just advancing them along the stages logically. Um the example that I like to use is the example of doing laundry where you put one load of laundry in the washer and then when that's done you move it to the dryer and at the in parallel you can put a second load of laundry in the washer and run those in parallel. So monad exhibits pipelining between consensus and execution in the sense that consensus completes on a particular block and all the nodes in the network come to agreement about that block. So the official ordering of transactions is determined and then as soon as that is done, execution is lagging right behind it to go execute the transactions in that block. So by separating par uh execution and consensus, we can actually massively raise the budget for execution because execution no longer needs to be interled within um consensus time. So in the top here I've shown in Ethereum where we have interled execution and consensus the budget for execution aka the pink rectangle is only a small fraction of the block time. But in monad there's just consensus that's constantly producing blocks and as soon as those blocks are produced then each node can execute those in parallel. Um and similarly there's many other examples of pipelining throughout the monad system. um we see pipelining in the sense that asynchronous IO is actually running many many many uh transactions in parallel and there's pipelining between the CPU the computation and going and retrieving uh data from SSD. Um we also see pipelining within the consensus mechanism itself um because the consensus mechanism monet uh basically pipelines multiple stages of consensus and piggybacks them on top of each other. So in particular, Monet BFT is a three round consensus mechanism. Um so that means that there's three rounds of communication between all the nodes, but the second round of communication um about a particular block can be piggybacked on top of the first round of communication from the next block. And so that already raises the throughput of the system by a factor of three. Um and really what it does is it means that we can have fast block times. So that instead of requiring the uh block time the sort of like uh worst case roundtrip time around the world times three being the block time instead we can have it just be the worst case roundtrip time around the world is the block time. So that's how we end up with 400 millisecond blocks. Um and then lastly final insight is that EVM exec EVM equivalence is truly non-negotiable. Um it's just really important given the ecosystem of tooling, the ecosystem of libraries and applications that developers can redeploy their code without any changes. Um to be completely precise and complete about what EVM equivalence means in Monad, um we have made some slight changes to the cost of a couple of op codes to reflect the fact that it is truly much more expensive to read state um in particular to read cold state um from the SSD. And so there's a relative repricing that's needed. More generally, there's a theme that we see which is that um the Ethereum op code prices are all numbers that were that were set in stone many years ago and that get updated every so often as the relative cost of different resources change and we believe that these need to continue to be changed in fact um which is something I'll be talking about in about 2 minutes. All right. So, I'm just going to talk very briefly about a couple of predictions that I see for the future of EVM L1 scaling. We all know that Ethereum leadership is really excited about scaling Ethereum L1, raising throughput, raising gas limits, lowering block times, achieving fast finality. Um and all of these things are needed in order for Ethereum to continue to grow and to continue to be the root of trust for um all kinds of uh financial transactions and asset issuance and um the rest of the world coming on chain and we have sort of several different changes that need to happen in order for that to become reality. The first is that state management is the next frontier. Um there's a Vitalic discussion um on the ETH research forum from about two weeks ago um really delving into this problem and offering some possible directions that have been explored while realizing that these directions actually are um all quite challenging and are all going to have be of major disruption to developers. And one thing I want to offer here is that actually several improvements that exist here in Monad are things that can immediately improve Ethereum um are being shown in real life and can immediately make an impact. The second insight is that I think hardware design will become standard. Um I'm going to move fast through these. The third is that the EVM will continue to dominate smart contracts. Um and lastly that application design will change. Okay, so real quickly on state access, um, again, Vitalik wrote about how state growth is a giant problem. Um, and this is fair because Ethereum state is about 250 gigabytes of data right now. And the reality is that if you want to bring a billion people on chain or you want the number of Ethereum DAUs to go from 500K to 50 million or 500 million, there's just inherently going to be a lot more state. And one problem with the Ethereum Merkel tree um in old implementations is that as this Merkel tree gets bigger, it also gets more expensive to access any of the pieces of state in there. It's like if you were building a town and the town had 10 houses, then you get to every house very quickly. But when the town multiplies and becomes 100,000 houses, now the process of navigating to any one of those houses is much much slower. And so that's the problem with the existing Merkel tree implementations. Um so using a fast database like Monad DB which is optimized for the Ethereum Merkel tree can immediately deliver performance improvements. Lastly, state access is still mispriced. Um, and state creation is even more mispriced than that. So, for context, every op code has a certain cost. And the cost of creating a new storage slot is one of the most expensive out there. Um, but right now, although there's a high cost to create a new piece of storage, the refund for clearing that piece of storage is actually only a small fraction of that original cost. So that means that state creation, the state market is actually mispriced and there's no incentive for people who create state to destroy it. So this actually needs to be redone in my opinion. And um rebates for clearing state need to become 99% plus of the cost of originally creating that state so that users are incentivized and so the application developers are incentivized to properly clean up the state that they create. That's really the only way to rationally grow state substantially and usage substantially. All right, I think I'm kind of running out of time here. So, thank you everyone so much. Um, again, I think the EVM, it has a very bright future ahead. It will continue to dominate smart contract standards. Right now, it's over 85% of all TVL and crypto. And I think it'll continue to be there or higher. Um, but what we need is improvements to the EVM at both the execution side and the consensus side in order to um allow the EVM to really take its true form. Um, thank you very much.