So it's because of monad DB that this memory is actually so low? Yeah.

Correct. Yeah. Because when you're trying to have very performant execution, you run into the bottleneck of state access. And so the two kind of paths to alleviate that. One would be to jack up the RAM requirements so that more state is in cash. And then the other way is by doing all the work to build monad DB to make that SSD like the data that's living on SSD much more accessible. And are

you going to do what Solana did and make it so that validators don't have to know the full state so that new validators don't have to replay and catch up basically. I think that's my understanding of how it works. I think.

Yeah, you're talking about state sync. That's correct. Okay. I

have a follow up question on this. I'm curious actually to. And it's another one of the major differences between the Solana implementation and the monad implementation I'm curious to get your take on. So it was something that you were touching on before of the most of the bottlenecks kind of fundamentally here stem from the fact of Ethereum the way that we store the state. It's like you have it in a Merkle tree and you stick it in this database. And today in practice like most of those databases like actually just like not built to be doing this like super efficiently of like looking up to the Merkle tree changing etc. So one solution to that is what monad is doing. And what like I think some of the work on like avalanche firewood is like similar to that as well like okay let's just like optimize the database and make it for like looking up and changing this Merkle tree. Another solution to that or approach to it is what Solana does which is completely different of kind of just saying like right script like let's just like let's rip out the Merkle tree and like we get rid of that and we just don't keep Merkleized in the state. And there are like some very different trade-offs of that of like it makes it more difficult to build like clients and stuff like that. But it does also just kind of avoid a lot of these bottlenecks around like working around the Merkle tree and like needing to build the database for it. I'm just curious like how you guys think about this trade-offs compared to like what monad is doing and like do you like what do you see as kind of the trade-offs in there like what do you think is the right or wrong approach or like when does it make sense?

I'm a big fan of SSDs and a big fan of Merkle trees. So I think that the Merkle tree is actually a very useful data structure for creating a commitment to all of the state in a very abbreviated way and that it enables a lot of other things like roll-ups where you know the roll-up is posting the state Merkle root back to L1 or bridges where the bridge is communicating Merkle root from one side to the other side and then that's a commitment to all of the state there. I think it's a really powerful construct and I'm not really very eager to throw it away especially given that you know we have this solution that gives the best of both worlds in terms of offering performant access and offering full Merkle tree support but I could understand why like in the past maybe it might have made sense to avoid this amount of work to build this database to alleviate the bottleneck. To

me it sounds like perhaps the biggest unlock here innovation is the Monad DB. Do you see a world where other teams even at the original one like moves from pebble I think you mentioned to Monad DB and unlock like a big improvement? Yeah I think

it's possible. The other thing that Ethereum definitely does want to move to and this is kind of I would say like almost like the third approach instead of like optimize for the Merkle tree get rid of the Merkle tree or just use a different type of state tree and this is kind of I haven't looked at closely but I believe the approach that like Megaeth is going and also to some extent like what Ethereum kind of plans to do in the future is just like to swap at some point from Merkle trees to Merkle trees as just a more efficient form of having the state and unlock statelessness as well. I'm curious like how you kind of view that trade off and like what your plans might be for that over time. Particularly if Ethereum does decide to progress and go towards Merkle trees.

Yeah I think that Merkle trees are actually quite a nice data structure because they allow they can actually be updated very efficiently if if done with a good algorithm you can update large parts of the Merkle tree in parallel. I actually think that Merkle trees are sort of going in the wrong direction from a performance perspective. So if yeah I think that I understand the goal which is to sort of make it so that validators can be stateless so that basically when nodes are validating the network in Ethereum they could vote without actually having access to all the state and then they would just ask other nodes for vertical proofs of the balances of various taking accounts and so on so that they can have all the information that they need in order to vote. To me that feels like it's very much going in the direction of like being able to support like nodes that can validate without while having like very minimal requirements. So it's kind of like going down the I can understand the vision of like right now there's about 10,000 nodes in Ethereum that are participating in consensus and if you want to like go from 10,000 to like 100,000 or a million or something then maybe it's the case that like node 200,000 to node a million are not going to be able to like store all the state so that they can participate as a validator. I think that it is still very much it's like a huge change to like the operation of the node though just to support this like 200,000, 200,000 validator at a time when Ethereum is also talking about how there's like sort of quote unquote too many validators. Now they're not saying there's too many nodes there's too many validators and there's like a lot of open discussions going on about just like how the huge number of validators actually creates other overhead on the system like it means that the signatures become huge because there's a million signatures and like things like that. So I guess I'm not sure that like it's or in the very least like it's branch there's basically a branch that's happening and where one campus saying like yeah we want to be able to support the 200,000 validator who doesn't have to have all the state and we'll go through all this stuff to like introduce vertical trees so that the witness size for like this these other nodes being able to request witnesses to attest to like these balances of these other validator accounts. It's like a whole lot of work to do that and then the other camp which I would say the Monad team is much more in is like how do we make fundamentally like the execution of the internals of Ethereum much much much more efficient so that we can raise the throughput of the system and you know still with like a very decentralized node set and very reasonable hardware requirements so on get way more performance out of this system but you know inherently that does mean making decisions that do prioritize perform and execution and I would say Merkle trees are much closer to being able to support perform and execution so therefore they're like pretty incompatible with the idea of like the vertical tree and that direction. Keone

what do you think of the recent idea to raise the gas limit on Ethereum I think it's from a couple months ago for some metallic commentary on it as well.

Yeah I think it's a good idea I think that it would alleviate to a certain extent some of the costs the extreme nature of some of the costs and I think this is just a personal opinion right like everyone literally every single person in the Ethereum community has different opinion about it but for me like it you know right now it's kind of true that like Ethereum block times are 12 seconds but execution budget is a gas limit which is chosen to correspond to like 100 milliseconds or so worth of execution time there's only 1% of the total block time so that's crazy because it means that there's this like shrinking factor of 100 acts of execution throughput because of that like gas limit that's being imposed and for a 12 second block time like you could definitely imagine that budget going from 100 milliseconds to 200 milliseconds without really like having a significant effect on the overall stability of the network. Yeah I'm

gonna pull us out of the weeds for a second here there's this like a inherent friction in L1 in L1s and honestly outside of crypto in general just like in

protocols which you which is

that one day you start a protocol and you innovate on it and you do everything differently and you figure out all these optimizations and then if it gets big enough eventually there's actually pressure there becomes pressure to not change things and to basically you need to ossify the system and as that happens you have to like slow down the rate of innovation and I just be curious about like how you think about that as it relates to monad when that will happen like what how do you think about that in general?

Yeah it's a good question I mean it's obviously a trade-off. Solana is a good example because I think they do ship improvements pretty frequently but then that creates more risk of outages and so like the recent outage that was like a month ago or so you know that was like a new feature that got added and then so yeah Solana is like very much on the extreme end of the spectrum of trying to ship many features as fast as possible and sometimes it leads to like liveness failures and that you know contributes to negative sentiment about the the blockchain and the its ability to serve as financial rails for the rest of the world so I mean I would say it's like it's a trade-off but obviously there's a way to do a lot of both but that just comes from more effort like more rigorous testing more test net environments that are running in parallel to main net that are a complete replica of how main net looks like I think on Solana main net the real TPS is like you know a thousand or so transactions per second whereas the dev net is like 70 transactions of usage per second so there's still more that could be done to like make that dev environment more similar to the production environment but it just requires work it requires cycles human cycles and sometimes when you're trying to go really fast you're devoting more you know more to speed like to the the engines at the back of the rocket ship versus the ones that are like steering it and keeping it safe so I don't know I mean the only answer is just to work harder and to but to be very rigorous and to have rigorous practices with respect to like rollouts and rollbacks there are some I think some learnings there that are very

concrete.