Monad: The EVM-Compatible 10,000 TPS L1 Blockchain - Keone Hon. Ep. 578

Transcript

that was really the core idea was to make the evm execution a lot more performant and then build a consensus mechanism that could keep up with that really high execution throughput um in order to maintain a really high degree of decentralization and full decentralized block production I think salana is processing somewhere between 2 and 3,000 transactions per second you know whereas monad is supporting over 10,000 transactions per second and then also salana is using Rel ly High Hardware requirements I believe the requirement is 256 gigs of RAM right now whereas monad requires nodes to have 32 gigs of RAM welcome to episenter the show which talks about the Technologies

projects and people driving decentralization and the blockchain revolution I'm Brian Crane and today I'm speaking with Kon hon who is the co-founder and CEO at monad Labs monad is one of the most ambitious and uh interesting new layer ones coming up uh expected to launch next year so I'm really excited to get into the details of that with K now uh before we get into it we just want to uh share a few things from our sponsors this week if you're looking to stake your crypto with confidence look no further than course one more than 150,000 delegators including institutions like

bitgo Penta capital and Ledger trust corus one with their assets they support over 50 blockchains and are lead leaders in governance or networks like Cosmos ensuring your stake is responsibly managed thanks to their Advanced me research you can also enjoy the highest staking rewards you can stake directly from your preferred wallet set up a white label note restake your assets on Iona or symbiotic or use the SDK for multi-chain staking in your app learn more at chorus. one and start staking today this episode is proudly brought to by nosis a collective dedicated to advancing a decentralized future nosis leads Innovation with circles nosis pay and metri reshaping open Banking and money with hashy and nosis VPN they're

building a more resilient privacy focused internet if you're looking for an L1 to launch your project nosis chain offers the same development environment as ethereum with lower transaction fees it's supported by over 200,000 validators making nois chain a reliable and Incredibly neutral foundation for your applications nois Dow drives nosis governance where every voice matters join the nosis community in the nosis Dow Forum today Deploy on the evm compatible nosis chain or secure the network with just one gno and affordable Hardware start your decentralization journey today at nosis

doio cool well thanks so much for coming on K uh it's it's really great to have you on yeah thank you for having me Brian so I I like to start by kind of asking people about um how their crypto Journey began like how did you first become interested in crypto yeah um so I'm I'm 35 I've been working for um like 13 14 years at this point um the first 10 years of of my career were spent in high frequency trading working as a Quant um so I traded in a number of traditional markets mostly on the Futures side um these are really um high volume like

very liquid markets like S&P 500 futures or 10e treasury note futures or crude oil futures um building performant trading systems that trade in these um really efficient markets um generating very very small um statistical profits over a long period of time um and over for some period of time our team started to trade crypto initially just sort of like um without a lot of understanding about um the underlying assets that we were trading but crypto is really interesting from a trading perspective because there's so many different assets um like there's so many different coins

themselves but then a lot of different Perpetual Futures and um deliverable Futures and uh many different exchanges so there's a lot of interesting correlation structure across the space um and that was initially what got me and and my trading team at Jump trading involved in crypto but then at the same time I was also um just like getting really um into crypto Twitter and enjoying all the narratives all the memes all the characters um in in 2020 and 2021 um so that was sort of the introduction of the space and then uh my team ended up merging into the crypto team at Jump trading in mid 2021 and

started working on salana defi for for a little bit of time then then that point I was fully professionally in crypto um prior to starting monad at the beginning of 22 right so you basically first started trading you know just on centralized venues and then also started doing more like onchain stuff um yeah we we were uh from a trading perspective um yeah I was more focused on the centralized side um I mean in a personal capacity I was trying out different dexes and um uh yeah buying nfts and yeah getting ruged done on coins uh you know on Meme coins in

2020 2021 um aside from Dogecoin which which did really well but yeah it was mostly on the in the professional capacity more on the centralized side I'm curious is sort of from all your knowledge you had about uh you know how markets work on in the traditional markets work and then when he kind of came to crypto what were the things that you know just seemed most weird to you or like most surprising I think two things that come to mind the first is just the general inefficiency of the markets and the typical spreads that um you end up paying as as a retail tra um like in the traditional

markets of course depends on the liquidity of the asset but um for you know most normal futures or most normal equities people will end up paying single digigit basis points um in in spread and and in slippage like spread and slippage combined um like their execution price is never more than you know like one or two cents different from um whatever the mid point of the market is um and this is for Equity that's trading at $100 or $200 or more so single digit basis points um and then if you go to the defi space it's you know the default is like a 30 bip um fee

and then in addition like when you trade there's like some impact and then when you price him like some slippage and then you end up getting sandwich attacked um you know it's just like it's very common for people to end up paying like 50 basis points or 1% or 2% in slippage um so it's just you know like two orders of magnitude more than you would in in the centralized space so that's the first thing and then the second thing is um just the fact that when a transaction is submitted um it's in a pending state in most blockchains therefore um it's subject to the actual discretion of the uh the block producer in terms of the ordering um which has an

effect on the execution price as well and then tell me what what's the origin story of mad is that what you did after jump yeah um so I met uh James hunsaker um who's co-founder and CTO here at monad labs in 2014 when we were both a jump on the same trading team uh and we've been working together ever since then we both left jump uh at the very beginning of 2022 um and then started uh monad shortly after that along with the third co-founder and what was the what was sort of the vision

that uh like you know the thing that cost you say okay this is the thing I want to work on yeah I think well with any startup you really need an idea and an idea of also how that idea fits into um the broader landscape of um of of the space that you're working in and and a clear problem that it's solving um for us prior to starting monad when we were jump trading for about six months we were mostly working on salana Defi and at that time in 2021 um we could see that there were a lot of advantages to building on salana because um you know Salon was offering like 500

to a th000 um real TPS of throughput so much much more throughput than ethereum um ethereum was about 10 TPS um and also much more throughput than any of the rollups which were you know also in the like 10 to 30 TPS range um much more throughput than other evm layer ones which are also in the like 10 to 100 TPS of throughput range um so there were a lot of advantages to salana but at the same time uh builders for building in salana had to build with a completely different bite code standard they couldn't reuse any of the work that they'd um done if they'd built for the evm already they couldn't use any of the um really rich array of tooling and libraries and so on um and we just

realized that we could give developers The Best of Both Worlds and give them both performance and portability focusing very heavily on optimizing all parts of the evm stack um and that was really the core idea was to make the evm execution a lot more performant and then build a consensus mechanism that could keep up with that really high execution throughput um in order to maintain a really high degree of decentralization and then full decentralized block production so I'm curious because I feel like this evm discussion you know has been a very longstanding discussion where you know some people will be like oh evm is is fine and then a lot of people be like oh it's kind of like this

you know odd thing that was created early on and just because it was the first it you know has so much uh so much adoption do you feel like is the m like how do you feel like comparing the evm with other VMS do you feel like using the evm is pro the the biggest Advantage is just existing develop EOS system tooling contracts exist or are there other kind of pros and cons versus other VMS right I think that um well so evm is the the just to State it very uh explicitly evm is the low-level bite code standard uh but then typically

developers are building in solidity um or occasionally in Viper or Huff or other um frontend languages and that that highle language gets compiled down to evm um but it is really true that um almost all capital on chain is in the evm right now um like over 90% of all tvl on chain is in evm daps um additionally there's a ton of existing libraries and tooling um almost all the applied cryptography research is being done in the context of the evm as well like people don't really think about that part but um you know very much on the on the research side and um a lot of zero knowledge research is being done um

ultimately to interface with the evm B code standard as well so it's really like for develop um they would probably prefer to build for the evm um given all these Network effects and the fact that by building for the evm they're not tied to like a you know one ecosystem or a very small um subset of ecosystems they can really deploy their their work almost anywhere in the future so it's really just future proofing um the work that they've done in addition to having access to all of the existing libraries and tooling do you think this is something that like kind of network effect is going to just continue compounding and

grow bigger in the future or do you feel other things like you know slana VM or like move VM or any of these others have a real shot at at some point taking over um I think the future is very fluid it really depends on um the path of least resistance for developers and our team thinks that the work that we're doing to make the evm a lot more performant so that then developers are really not forced to choose between performance and portability um will have an impact on how people think about like what VM to build for you're right that in the current regime at this very

moment um developers might be moving over to salana because um they feel that that's where they'll get the best performance and also because there's a lot of excitement around the salon ecosystem right now uh but that all just can change uh with the introduction of new technology so when it comes to scaling so moving all the bottlenecks and making sort of the evm way performant what are the things that you guys did to achieve that yeah there are um at least four different major areas of optimization or four different um new architectures that have been introduced produced in

addition to just more generally um optimizing so first of all modad is completely from scratch um so all parts of the stack are are built from scratch for performance in C++ and rust and then we've introduced several new architectural improvements um which I can describe sort of briefly I think the main way to think about it is that there's execution improvements there's consensus improvements and then there's improvements in how how consensus and execution interact with each other um so the first two improvements that I want to mention are both related to execution the third one is related to consensus and the fourth one is related to how consensus and execution interact um so

on the execution side um the two things that we've the two major things that we've done are um introducing a new datab base and introducing optimistic parallel execution and the reason why these two things are both needed in order to make execution a lot more performant um is because well first of all um to talk a little bit about the job of execution um so like in ethereum there's a block it has a whole bunch of individual transactions um that are supposed to be run sequentially in order to get to the end result um and initially you might think that there's no way to parallel process because the true state of the

world is the state of the world um assuming that all those transactions are run one after another so for example if um I start with 200 usdc in my account and then the first transaction is me sending 150 usdc to you and then the second transaction is me sending 100 usdc to my brother so you know the first transaction when it gets executed it'll take my balance from 200 to 50 and then the second transaction when it runs will take my balance from 50 to still 5050 because that transaction will fail because it was trying to send 100 but I don't have 100 anymore um and so I think this is an example that shows you that

you kind of do have to execute the transactions at least in some sense serially because you need to have done that first transaction where I was sending you 150 before we can actually get the correct result of the second transaction if we ran them in parallel just totally naively um we would think that both of them succeeded so there's a notion in which um sequential execution is needed but um in monad we introduce optimistic parallel execution to do a bunch of work in parallel but then do the right amount of bookkeeping um so that we're keeping track of inputs and outputs I.E um storage slots um both the values that were read in from a storage

slot and then the values that are um written to a storage slot and although we do a bunch of work in parallel we do bookkeeping and then commit those pending results in the original serial order and reexecute any unexpected uh results where the inputs have since changed and so in that particular example we do those two pieces in parallel we would get pending results for both of those two transactions um and then the second pending result we would then invalidate and reexecute because we would realize that it was done wrongly the first time okay because I think some other chains they were like first try to check like okay what contracts does it touch and then if it doesn't touch this contracts then you

say okay you can paralyze it but in your case you you just execute it and then you see afterwards what it touches and then you kind of like roll things back almost or yeah that's uh that's exactly right although I wouldn't call it rolling it back necessarily because nothing is really been committed yet but but yeah that that's that's a good uh characterization though that um a lot of blockchains that do parallel execution um require explicit uh dependency specification so Salon is a good example of this where when you submit a transaction you have to say the exact pieces of state that that

transaction is going to touch um and indicate which ones are going to be read and which ones are going to be written to um aka the read write locks and then that information is used as an input to the salana schedule to make decisions about how to parallelize work and if you misspecify one of the dependencies like if the transaction tries to go out of bounds and touch a piece of state that wasn't specified ahead of time then it just automatically fails um so that's sort of a more um uh explicitly defined model for transactions and I think you would think that it might allow for more performance because you have all the dependencies up front um but in practice

what we found is that you can get a lot of performance from this pure optimistic approach where you just assume that everything is okay that you know you're just reading dependencies on the fly but then you put the results in a pending State and you commit them serially and reexecute if you need to maybe we can come back to this later but you know one question I'm very curious about is the whole question of like me PBS because that I think maybe relates to this as well but maybe let's go through the um the you mentioned four things so let's go through the other ones first oh yeah sure so I was telling you about um I guess one of two major improvements that are improving

execution um so I told you about the first one already which is optimistic parallel execution um the second one related to execution is this new database that we've built called monad DB um and so the thing to know about uh this particular topic is ethereum store St all of its state in a Merkel tree um and the benefit of storing all the state in the Merkel tree is that the Merkel tree has a Merkel root um which is essentially a check sum over all of that state um and in that way a commitment to all of that state so like if you and I are both running full nodes and we both um have the same Merkel route at the top of our tree then we both know that

literally every single piece of state is exactly the same on both of our machines so we don't have to go like state by state and compare all of them we can just compare the Merkel Roots it's a very efficient way of um ensuring that we're on the same page um and the Merkel tree is um you know a successively hashed tree where um every parent is a hash of all of its children and then you just kind of like propagate that all the way up to the root of the the tree and the thing to know about existing systems is that this Merkel tree structure is generally embedded inside another database um for go ethereum it's level DB or Pebble DB um in Aragon and WTH um

it mdbx which is another uh database but any in any event like all of these ethereum clients they use a different database as the actual store for all this Merkel tree data um and it creates a lot of indirection because each of those databases themselves have another tree under the hood um that's being used to define how state is or how um data is being stored on disk so when you want to navigate from the route all the way to one of the leaves in the Merkel tree each time you visit a node you're actually triggering another look up into another tree um and so it's just really inefficient to like go navigate from the root of a Merkel tree down to any particular node because each node that

you visit is going to trigger a an entire look up into another tree so with monb we um apologies for a long explanation there but for monad DB we're actually storing the Merkel Tree natively on desk so there's an exact mapping between how the tree is laid out the Merkel tree is laid out and um the you know the locations on dis the pages um and then in addition to that there's also a lot of other optimizations like um introducing asynchronous iio support so that many pieces of State can be read at the same time um bypassing the kernel a bunch of other optimizations but what you really get is a much more efficient lookup system and also one that can support um effectively parallel reads

which then interacts really well with the optimistic parallel execution because in optimistic parallel execution you are running many transactions Each of which is at some point um encountering s stores and S loads um and triggering database lookups and so while all these databased hups are being triggered in parallel um by running all these transactions in parallel the the dis is also able to service a lot of those requests in parallel and start um you know serving serving State back to each of those transactions okay so basically what you're saying is like this's kind of this ethereum has this like Tre structure defined where you know um the the data the state is hashed

and then you have a a root hash and then that's implemented on top of other three structures which depend on the different database basis so you have sort of the three on three which then makes it deficient whereas you guys just have basically used the underlying tree structure off the database to just store everything so you kind of get rid of one layer of uh complexity there yeah that's exactly right and that's super important because all of this data is living on SSD um and the mental model that you should have about an SSD is that it supports a lot of um a lot of work being done in a lot of

lookups being done in parallel so like a good SSD is um a million or more iops uh IO operations per second um but the latency of each one of those lookups is somewhere between 40 and 100 microseconds so you could think of it as like a bottle that has a really wide bottleneck and you want to be able to stick a whole bunch of straws into the bottle at the same time and you know like put all the straws in your mouth and suck a whole bunch of uh juice out of the out of the jar all at the same time um but there's the straws are long like there's a long amount of latency to look up any single piece of storage so in the context of um that nested tree structure that we were talking about

where you know you're going to end up having to go back and forth with the disc a whole bunch of times just to get uh one piece of state and when you can reduce the number of back and forth um sub substantially you can get a lot more throughput out of the system and so that is primarily an our advantage also because I can imagine there's different advantages of this right like so one is that when you execute a lot of transactions you can just do it faster because I maybe it also makes like running a node more efficient you know if it's just like a normal node where you look up the state that doesn't that's not like a validator or yeah that's right the database is um is just how all the state for any

node whether it's a a full node or a like a non-v validating full node or a validating full node either way um they're still going to need to respond to RPC calls and execute transactions or go look up pieces of state and all of those are accelerated by having a better State back end cool so we have the this optimistic parallel execution you have the new database and then what are the what's the next one right so the two other areas that I mentioned are on the consensus side and on the interaction between consensus and execution um so to mention the consensus part first um we

have a new consensus mechanism called monad bft um which is pipelined two-phase Hot Stuff um so hot stuff is a um a consensus mechanism that has linear communication complexity that means that um as the number of nodes in the network increases uh the amount of overall number of messages that need to be sent um increases linearly with the number of nodes um as opposed to other consensus mechanisms like um uh tender AKA comma bft where it it's quadratic like um you know it's the square of the the number of nodes in the network um

because in tender it's all to all communication whereas in hot stuff it's generally one to many many to one communication okay so what's what's the kind of number of validators that you expect that munad can scale to um we expect a couple of hundred uh validators participating in consensus on day one of monad mainnet um and then we have a slightly longer term road map to um get that to the thousand but um with the current consensus me mechanism implementation um the it can support somewhere between two and 300 validators participating in

consensus okay because that's kind of similar to I mean okay t m chains maybe is more like I would say sort of up to 200 I think is probably the most that people run what about their block time right um so monad bft in monad is being configured with a 1second block time um as I said two to 200 or more validators participating in consensus um and the other thing I forgot to mention is that monad bft has single slot finality um which we think is really important because um you know there's it affects the the bridging time like if you're

trying to bridge off of monad to another blockchain um then typically um well the bridge really should wait until the chain is finalized before relaying a message to any other chain um and in ethereum where you have uh somewhere like 12 to 18 minute finality that means it just takes a super long time to um get your assets off of assets off of ethereum to another blockchain single slot finality really helps a lot with um faster bridging and faster settlement times what are your thoughts on the comparison of this versus the salana consensus which is you know this proof of History bft like

consensus I think Salata has Tower bft um which is not single slot finality I think that the some of the benefits right now of tower bft are um support for a higher number of uh validators participating in consensus I think they have somewhere between two and 3,000 validators right now um which is actually quite impressive like I know that the the meme on Twitter at least in the a couple years ago like people would always say that salana is really centralized and there are some aspects in which um I would say that that that could be true um for example the high Ram requirements of running a Solon node

but on the other hand from a pure consensus perspective um it is impressive that salana has uh 2,000 plus validators participating in consensus um but that does come at a cost and the cost is really finality is like not single slot it it takes some time I think in practice they say like after 32 um slots you can consider it to be finalized uh but it's it's a little bit probabilistic even there as well um at 32 slots in salana 32 times 400 milliseconds is um uh what is it like 12.8 seconds yeah and I mean one big difference with son I guess that's not

consensus related no but it's that there's no Merkel uh proofs now yeah yeah that's another uh example where salana removed the merization um which I I think has an impact on bridging has an impact on the ability to run a light client um in salana they say that the the light client is like a node that submits a transaction that um creates a yeah a transaction that generates a proof but it actually has to be included in the blockchain in order to um generate like that that proof so it's kind of it's not really a light client in the same way that um when people typically talk about

light clients and uh from the light client perspective those are how do the light clients work for monad um so I think on on day one we will not have an light client implemented but um it it definitely could be implemented in the future with the uh consensus mechanism that exists and um yeah there's there's no impediment per se because there is uh there is a Merkel route and there is like all the other things that you need Okay cool so that was consensus and then let's go to the last one monad implements something that we

call asynchronous execution um and the way to understand that is sort of best understood by sort of uh just want to mention some numbers here so ethereum has 12C block times um but the actual uh rough time budget for execution is only about 100 milliseconds uh which is you know if you do the math like less than 1% of the block time um and so that's that's really interesting that the budget for execution is so small like such a small fraction of the block time in ethereum or in other blockchains and the reason for this is the fact that execution and consensus are interleaved with each

other um so typically in blockchains um the you know what'll end up happening is the leader ends up um choosing a list of transactions and then executing all of them generating the Merkel rout of the resultant state tree um and then sending that as a block proposal to everyone else um then everyone else re can you repeat that uh can you repeat that how they inter Leed yeah um so in most blockchains execution and consensus are interleaved execution is the single node problem of you know given a list of transactions what's the end State and then consensus is a distributed system problem of nodes talking to each other over a network um

the nodes if they're globally distributed which they should be then um that means around the world communication um which can take hundreds of milliseconds there might be multiple rounds of communication so I think all in all what you can see is that consensus ends up taking the vast majority of the block time and execution ends up being squeezed into a very small fraction of that block time because of the inter leavess of exec ution in consensus yeah yeah but for example that's something where salana is also much more because if their system there's much more execution right right so with Sal they're also exploring the idea of asynchronous

execution um toly has uh written about this a couple times on Twitter uh which has been really interesting for us to see but um yeah monad has been uh you know since day one asynchronous execution has been a big part of the overall design and asynchronous execution means decoupling those two problems of consensus and execution from each other um asynchronous execution is the idea of moving execution out of the hot path of consensus into I guess what I would call a separate swim Lane um that is slightly lagging consensus so it's what what ends up happening is as soon as the nodes in

the network uh come to consensus about an official ordering of transactions um then two things happen in parallel one is they can start consensus in over the next block and the other thing is they can all each independently execute that list of transactions that they've just agreed upon um and so when you move the execution out of the hot path of consensus into the separate swim Lane you can massively raise the budget of execution and use the full block time as opposed to only a small fraction of it ah so first the network agrees on just the order of all the transactions and how they're being executed re reaches consensus on that and then the execution

happens that's right yeah okay okay very interesting so that also means for example if you're now a proposer or like you don't really have like there's no nothing really you can no discretion you can apply I guess um that's that's a good question so as a proposer you still can apply discretion um and we think that in practice the proposers uh definitely would apply discretion because that allows them to um you know more optimally choose the

set of transactions that um that will end up paying fees um you were asking earlier about how me will end up working and um we do think that there will probably be some sort of mechanism for um Network participants to submit ordering preferences to the block proposer um in some way and attach a tip alongside that um so then that tip revenue is additional revenue for the proposers because the proposers are the proposes are the ones that come up with the ordering of transactions correct yeah and then that gets consensus on and then the execution

part is kind of that is basically predefined correct that's exactly right so um I think you said it better than than I did um the first time which is when you think about a blockchain a blockchain is really just a bunch of blocks um that are in sequential order um and then in each block a list of transactions which are also in sequential order um so if you sort of like uh let the blocks themselves Fade Into um into the distance for a second you just literally have like a long long long list of transactions that are all canonically ordered and if um everyone or like Brian if you and I are both

running nodes and we both have exactly the same list of transactions starting from Genesis then we should have the same exact state of the world because we're both applying the same transactions one by one by one by one by one and each time making the exact same state transition and getting the same um state of the world the same oral route um so the ordering of the transactions purely determines the execution it purely determines like what the correct state is yeah basically like the only reason why we have Merkel Roots is so that we can check each other's work and make sure that um you know neither of our computers like got hit by cosmic rays and and made a computational

error it's like just to make sure that we're we're doing the same thing okay so but it also means now if I'm the proposer uh I you know I get all these transactions and now I can come up with a list like an order of these transactions so then there is potentially a lot of value right in changing this order you know um accepting different orders putting in your own transactions like all that kind of stuff yeah that's that's right so and and this is really just true of any any blockchain but um yeah almost every blockchain is

leader based um so there's rotating leader uh and then when it's uh your turn as the leader you uh sort of have the privilege of being able to choose from various pending transactions that are in the M Pool and assembling the next block I.E assembling the next ordering of the next set of transactions that get enshrined into the history of the blockchain um of course you need to choose valid transactions um so that everyone else like uh verifies them and accepts them and votes in your block um but you have discretion over what the ordering is and what I'm saying is that that choice about the ordering

is all determined during consensus so you as the block proposer you choose an ordering you send it to everyone everyone looks at it checks that all the transactions are valid um does some other validity checks which I can talk about in a second and then votes yes and then once uh you know super majority of the network like super majority stake weight has voted yes now that list of transactions is now enshrined in the history of the blockchain um but that can be done actually before execution of that list of transactions happens um and so that's exactly what's happening in asynchronous execution is having the nodes all agree on the official ordering and then once they've agreed upon it then they can do two things in parallel

which are like start working on consensus see the next list of transactions but then in parallel go execute the things they all just agreed upon so I'm curious now if you do think that where this is going to is that we also going to have a sort of proposal Builder separation where uh as a as a proposer I'm going to basically you know plug into some Builder or some other entity that you know applies a lot of like intelligence uh to basically give me an order that sort of produces the highest value I mean highest value for for that builder then and um because that

presumably uh there's there's a lot of value right in in determining that order um is that where you expect things to go um yeah I think so so the the question of how the ordering is chosen is sort of orthogonal from all the other stuff that mentioned um like in the story I was telling you about how the proposer just chooses an ordering and then messages to everyone they all agree upon it now the order is enshrined and now everyone can go execute and parallel to consensus in the next block that entire story um just kind of blackbox the decision of the proposer of how he

or she chose that ordering and to your point just now like that decision could be made by uh Outsourcing that decision to like uh a third- party Network that is um you know like a a proposer Builder um like a PBS type thing in ethereum where there's a system for people to be able to submit um bundles to the builders have the builders build a block um have the block be submitted to a relay which um conducts a private auction from different building ERS to choose the ordering that offers the best um overall amount of overall amount of

Revenue before presenting um some op like the best option to the proposer and having the proposer choose that and ens Shrine it all of that still like kind of work could work the same way um I don't know the like it's it's sort of out of protocol um so we'll see how it develops over time um but yeah I think you could think of the ordering Choice as being orthogonal to the other considerations of how consensus and execution end up working but like by default when Moet launches you know proposer and Builder would be basically the same and then uh so it's not like enshrined proposer Builder separation and then someone may

come and say hey we're going to create a modified client that separates out the proposer or like or plugs in some kind of Builder mechanism that that's right yeah the the default mechanism for Block building is uh priority gas auction um so choosing the ordering of transactions based on descending gas bid I know like I think PBS is something that's uh fairly you know controversial uh I actually remember we did a interview with italic at the ECC and ask him the question hey how do you you know do you feel it was the right

decision and he was like I'm not really sure if this PVS separation was the right decision do you feel like is this a desirable end State the kind this kind of separation or um because in the end right there is potentially that a lot of value ends up kind of being extracted by I mean in ethereum's case right we now have uh I think really just two two Builders who very are completely dominant like how how do you want this ecosystem to evolve do you hope that there's going to be a lot of Builders who compete or or you sort of say like don't really care it's uh it's up to the market to figure this out or like how do

you want to see this evolve right yeah it's definitely a complex topic I think that you know one thing that I hope um we can accomplish through whatever the um the ultimate block building uh whatever uh block building mechanism becomes sort of the the dominant one I hope that it involves a lot of Builders um ideally it would be possible for the proposers themselves to just run the software themselves and build an optimal block um that way it's it's much more decentralized in terms of that um the thing that you were

mentioning like ultimately the set of agents that are um sequencing transactions we want that number to be as high as possible I think in terms of the the value capture um in ethereum right now the proposers are capturing a lot of the value um because although there aren't that many entities that have a high market share on the in the Builder space due to competitive forces they do have to up to um give up most of the value that is in that block to the proposer so it is still very beneficial to the proposer Network which um you know then is sort of Revenue maximizing

for the proposers um which is then good for all um token holders because anyone can you know has the ability to stake and thus um you know sort of get the returns of a proposer or at least most of them um there's also the part about how um over time we're seeing more value get captured by applications through uh yeah mechanisms where the the builder needs to rebate um some of the value to the application itself and you know then when the revenue flows back to the application um that can be good because either it makes um The Proposition of building an app

more attractive which I think um you know a lot of us in the space would agree is like a good thing to happen um because then it'll just encourage more um ambitious apps to get built um or potentially the revenue although originally going back to the app then could flow back to um either LPS of that particular DUI protocol or maybe a rebate to the to the taker to end user um so I think those are all different uh things that can evolve over time um but yeah I think to your original question like we we do I think it is objectively better for um there to

be more actors that are ultimately choosing the ordering of transactions um for the purposes of uh censorship resistance and decentralization okay cool fantastic so now I think we coming to the the fourth thing you mentioned oh um actually I think I uh you know I've uh gone all the way out the plank because I've given uh the first two things were um both execution related then the third third one is consensus and then the fourth was the separation between consensus and execution oh the asynchronous yeah yeah okay okay yeah yeah yeah okay yeah optimistic par new database the consensus and then

asynchronous execution cool so where do we end up with this like what is the the kind of um throughput that it's achievable here yeah I think the cool thing about these different uh technologies that we're introducing is that they all stack on top of each other um so it's like you know it's always exciting when you get um a bunch of coupons in the mail and then you know one is like 50% off one is 25% off but they actually stack on top of each other because then you really have a magnifying effect um so as I was mentioning before asynchronous execution on its own is a massive unlock because

you know in existing inle systems only a very small fraction of the block time can be used for execution whereas um by uh decoupling the two uh basically the full block time and expectation could be allocated to execution so we can pack a lot more um you know literal just like you can pack in the full block time as opposed to only a small fraction um as execution time and then if in addition to that you have parallel execution um so we can do a lot more work in parallel and then we can also have a more performant State database we can respond much more efficiently to all these um s loads and

s store requests that are happening in parallel um and we have a more performing consensus mechanism that can keep up with this entire system of execution that's fast um then we can really really see massive gains the other analogy I want to mention is that in asynchronous execution um like I it reminds me a lot of the the movie Limitless where there's this um which is sort of based on the premise that um you only use 10% of your brain what if you could use 100% of your brain like imagine how superpowered you be um and of course that's like a little bit misleading because I think that 10% Like the denominator has a lot of um

gray matter like supportive tissue or something in there but it's not really true that you can go from 10% to 100% but it's a nice fantasy to think about and in this movie there's this guy who takes a pill that allows him to go to use 100% of his brain and he's he's just immediately superpowered um and he's doing awesome and then of course there's like a narrative where you know by being so powerful he gets in a lot of trouble and then he's able to somehow work out of it um so asynchronous execution is like that where you're going from using only a small portion of the block time to using the full block time um and then when you stack this on top of these other improvements we can really get significant um significant throughput so now back to your the question you're

actually asking um so monad is supporting over 10K TPS um replaying existing ethereum history so this is not 10,000 transfers or 10,000 erc20 transfers this is 10,000 real transactions um from the distribution of recent ethereum blocks per second um which ends up being about a billion transactions per day um or about one billion gas per second um which actually is is kind of funny like now on Twitter a lot of people talking about this goal of Giga gas throughput or billion gas per second um which is the throughput that we're able to achieve on

monad uh by stacking these different technology improvements while running on reasonable Hardware requirements um which I think is another thing to point out because a lot of the goals of getting to Giga gas throughput are assuming that um you're running a you know centralized L2 where there's one server and that one server has like a massive amount of ram um and you know it's like kind of a super computer that doesn't really work um with the principles of decentralization like we want to have a fully decentralized Network um where the nodes are literally globally distributed with the full overhead of consensus we want anyone to be able to run a node like it shouldn't

be expensive to run one of these nodes so if you can get to a giga gas um of throughput but you have to have a massive like um you know a Terri of Ram or more like people are talking about having like machines that have 10 terabytes of ram just like crazy crazy machines in order to get that throughput but with monad we're getting that throughput while using commodity Hardware like a server that costs um ,000 doll a year to run okay okay and so can you just contrast this with salana today how how does it compare um I think is processing

somewhere between 2 and 3,000 transactions per second um of of real non- voting transactions and um you know whereas monad is uh supporting over 10,000 transactions per second so it's like you know um 3 to 5x the throughput right now um and then also salana is using relatively High Hardware requirements I believe the requirement is 256 gigs of Ram right now um whereas monad uh requires nodes to have 32 gigs of RAM how do you imagine this is going to evolve in the future do you think you can scale that a lot more or is this

sort of are you hitting the limits here with these improvements um I think there's the capacity for another like two to 5x um of of throughput improvements um the real constraint is the on the networking side um so monad uh wants nodes to have um 100 megabit bandwidth and you know the throughput is um up to a certain point is sort of linear on the consensus side with the amount of bandwidth that's allocated um so but it's like not we we don't think it's

reasonable for a decentralized Network to require um gigabit bandwidth for example um like there's just sort of like a physical limitation um to the overall um throughput that's imposed by the networking okay okay so basically bandwith becomes like the main bottleneck and then that's something where okay if you if you go up with bandwith requirements it just means that you have to start compromising decentralization to some extent or to other extent it just becomes harder to run around this I mean I think in salana Solana's case right that that is a real challenge I mean we've had uh various times in the past

you know data centers would uh basically say hey you're getting you know it's getting dsed because it's getting so much traffic so I think finding like data centers that support like Sal valid is not it's not so easy right yeah I think that well I think the the more the most important thing to focus on is like the fact that there is um like for salana or monad there is a um you know commitment to having a fully geographically decentralized validator set having hundreds or thousands of nodes participating in consensus um like a lot of the more recent narrative has been

around like just like very very Central setups where there's a single sequencer um like if in that situation there's no consensus at all and so if there's no consensus then that whole thing about the bandwidth like doesn't become a consideration because the node doesn't have to talk to anyone else like it literally is just the one super node that all the requests are flowing to um and all of the um uh yeah all of the RPC calls are are going to or maybe going to like a slave or something but you know something in the same data center so I think that's the the single biggest thing and that is ultimately what the constraint will be

is the um the networking limitations um to support a fully geographically distributed decentralized Network um but I think it is very important and then I think from that point onward then um monad would perhaps pursue a horizontal scaling strategy where um there's several instances of monat that each are very computationally dense like each over or each delivering over 10K TPS of throughput um and then you know when that 10K gets saturated by whatever set of apps that are there then maybe there's like another monad instance that's also highly decentralized has nodes all the way all around the world

um that has a more specific like different um different Focus as well right that we come sort of a sharding like design but I mean fortunately 10K TPS is is quite a bit right so should probably has some time yeah you want to Shard at you want to Shard when you've uh reached the limits of what um you know the hardware can really support um like I think that it doesn't make sense to Shard like if each Network could only support 100 TPS and then you need to have 100 shards in order to get to 10K TPS that's not very good but if one Shard itself is 10K TPS and then you set up 100 to get to a million TPS that

seems much more um justifiable to me yeah and I mean it sounds like previously you were sort of referring a bit to like Mega Eve right which is the other project that's trying to Super scale uh evm but doing it with this kind of super computer centralized approach to me it seems very obvious that's like a massive compromise right on on in the end what we're trying to do here right they're having like decentralized networks but yeah I mean I guess they do you think but Mega let's say mega e will at the expense of decentralization then probably be able to to to process even much more than

Monet or like what are your thoughts on on like Mega Eve as a comparison yeah I think there's there's a um a number of different projects that are trying to build like high performance l2s um taking advantage of the the fact that there's no consensus overhead and um you know you can run that one note on a on a really big box U I think another example is is Rise L2 is is also doing this um I think radio is also doing this there um I mean you could argue the hyper liquid itself is also kind of doing this um because um the nodes are all in Tokyo like the no in order to run

a node you kind of have to have it in this one geography High Ram requirements on the nodes so yeah I think there's a there's a number of different projects that are all trying to trade decentralization for performance um and I mean if you think about it like just your expectation should be that um there could be more performance if you cut out all of the decentralization aspects and all of the overhead of consensus and so on I think Mt actually has a pretty uh funny take on this where um he talks about how l2s really should be like a lot higher TPS than Zana because they're all running

single centralized sequencers and you can add all of their throughputs together so the fact that like right now salana has higher throughput than all the l2s combined when the l2s like have this massive advantage of centralization is actually pretty crazy um so yeah I think that they different designs like there's there's definitely um some trade-offs being made but the goal of monad is to um offer really high performance while having a very high degree of decentralization as well at the at the layer one level and we think that that's quite important um that's you know that's why we're all here is to to help build new technology that helps decentralization to have a greater impact and decentralizing STS

have a greater impact so I'm curious about the developer experience here is it basically just going to be hey I'm I'm developing just like for ethereum and pry much the same but the difference is just faster block times more through for cheaper transactions or are there differences when it comes to developer experience as well on day one of main net the focus is really just pure um evm equivalence so that any you could take any application built for ethereum and redeploy it on monad without any changes you don't even need to recompile it um we are thinking about some additional quality of life

improvements for developers um those are things like raising the um the the bite code size limit from 24 kilobytes to um 48 or or maybe even more than that um it's things like adding support for new pre-compiled for example there's um a number of different uh cryptographic functions that uh frequently come up that currently have to get implemented um in solidity and are very expensive to do so um but if there's a native implementation then that should just kind of be baked into the um the node code and you should just be able to call it with a pre-compile um so we're we're working on some of those

and they will either be included in monad mainnet or if not right at mainnet at some point a little bit later on um we're also looking at the account abstraction space uh quite a bit and thinking about well first of all following along with the existing um eips that are contemplating different ways to um ultimately get to Native account abstraction um I think EIP 772 uh is getting a lot of traction um so this is the EIP that would sort of allow any EA way to um effectively become a uh smart contract account as well by having a

pointer in its code slot to point to another smart contract like another address um where code lives um so we're we're looking into that and again it'll either be included in mainnet or probably sometime shortly thereafter um but yeah at the end of the day from a developer experience um developers can expect um a fully evm equivalent experience so that they don't have to change anything but in addition um our team is evaluating ways to make um life easier for developers it's actually easier to develop on monad rather than on ethereum cool I'm curious on like a very different topic you know there's a lot

of competition around l1s and you know building community and sort of getting M chair is not easy I think you guys have done a fantastic job there and it feels like there's already a lot of like interest in Moon ad people building on moon ad uh what have you guys done in that front that has had the biggest impact yeah I think everything is is very synergistic um in the sense that um I think there's there's a lot of people in the the crypto space that are really passionate about um the ideals of the space and excited about seeing the success of new new decentralized apps and excited about trying new things and

giving feedback um and also that spend you know frankly like spend a lot of time on crypto Twitter every day and um follow along with a lot of the storylines I think what um our team has done well is just creating a welcoming home for uh many people that share these common interests and especially during the you know bare Market of 2022 2023 um just having a um creating this welcoming environment where everyone was kind of um a little bit down in the the dumps from um all the negative news and sent and so on around crypto but still very passionate um and a lot of people sort of ended up joining the monad

community and making a ton of friends and contributing in different ways which then um really has a a flywheel effect of um now we're at the point where um artists that are creating um new art involving the the animals which were created by members of the community um or like just leaning into all the memes and and jokes and fun um then have a massive audience for their art which then is very um just encouraging to them and gives them more of a reason to create more art which then creates more enjoyable experiences for everyone else which then um you know it's it's very very positive some and

then you know last also very positive for Builders who are building a Mana because then they immediately get some moral support from people who are cheering for them to be successful and trying out the beta versions of their products and giving feedback and becoming community members and yeah I just think that there's um it's really just about um the fact that um for various reasons the community is attracted a lot of people are very long-term oriented and care a lot about the space and have enjoyed making friends and then getting to go to meetups around the world to um to meet up with their friends that

they've been hanging out with a lot in person in real life um one last anecdote that I'll mention is um so around Devcon we hosted the moned madness pitch competition um this is the second iteration of something that U we're hoping will become like very much a fixture of what we do uh but it's uh it was a competition for 25 teams to present in front of a panel of um you know really leading investors in the space um we had people from Paradigm Electric Capital um panta Anoka uh OSG um and then anyway the point those were the judges and then a bunch of

other investors were in attendance in the audience um but we had um anyway so there was like these teams got to go on a giant stage um Pitch their their project compete for $500,000 worth of prizes um get the attention of Judges so that um they could attract money in their next fund raise and then also got over 400 people to attend in person a thousand people attending on the live stream and then kind of around this we had over 150 people fly from other countries um mostly in the Asia area but we people traveling from as far away as um as Greece and Turkey and so on all

the way flying to Thailand just to go attend the community Meetup and spend the week like hanging out with their friends that they've met online so yeah I think in short there's just an incredible amount of energy and excitement in the monad community and then that has translated into um benefits for Builders as well which then U makes the ecosystem stronger which then uh pulls more people in and hopefully pulls a lot of people and that have never uh known anything about crypto in the past as well the maybe final question so the what are the timelines here like when do you expect uh mainnet to launch um we're expecting mainnet to launch uh sometime early next year um no

exact date at the very moment but uh the team is working really hard on this and um I think in in particular we're expecting to launch uh the test net imminently in 2025 cool well thank you so much K that was really great I really enjoyed getting into the details here and I feel like there's a lot of like very smart and interesting and reasonable decisions that you guys have made that I think can can end up in a in a really powerful blockchain so thank you so much for coming on it was a great pleasure yeah thank you for having me Brian it's really nice chatting with you