Monad Architecture & Benchmarks | Eunice Giarta & Keone Hon - Monad Labs

hi everyone welcome back to the build Hub stage uh next up we have the co-founders of monad foundation Keon and Unice um they're going to give an exciting conversation on the architecture and performance of monad as well as talking about layer one Innovations please come up to the stage I'm gonna hand the mic over to you guys here you go thank you Jane good morning East Denver and good morning to everyone who's joining us on the live stream we're super excited to be here today and to tell you a little bit more about some of the new um Innovations and uh features of the recent test net launch of the monad blockchain so without further Ado we're first going to see as an actual live view of the network right now um K can you give this a quick read refresh ah I see now we've switched over to the live view here and actually if you want to follow along you can you can go ahead and navigate to gaman ads.com you can see that in the upper left corner GM NAD ds.com so what you can see here is the fully distributed Network right now there are 57 validators distributed throughout the entire world with the expectation of having over 100 by the time mayet is launched um other stats to include here uh there are it's a 500 millisecond block time and 1 second for finality there is 150 million gas per block which translates to 300 million gas per second um the expectation is that that also increases up to 1 billion gas per second by the time maintenant launches as well so feel free to follow along here we're going to do something fun and check back in with the live site in just a moment but firstly we want to go through a quick exercise of um actually pushing the limits of that 300 million gas per second so what we have here is a slightly modified version of the standard Foundry smart contract contract um what it usually comes with is the increment function what we've done here is added a few additional functions that are just really not performant because why would someone necessarily need to count one by one by one by one a really big number well we're going to try that we're going to waste a little bit of gas on the network and see how that pans out we're going to first zoom in to increment manyu here oh sorry my bad I should have explained a little bit more uh first zoom into increment many here which um you know we'll pass into this function a ridiculously large number for the on track to increment from zero all the way to this really large number inefficient yes what else is inefficient well we have Push many here which is pushing um which is adding to an array it's extremely memory inefficient and again if we pass it a really big number it's expanding the size of this array not great I wouldn't recommend it for your normal standard development practices but we're going to do it for the case of again pushing uh pushing the bounds of this 300 million gas per second all right cool so yeah what we demo what we're showing here is actually a very inefficient smart contract um but the goal is just to demonstrate the really high gas capabilities of monad um so we have a very simple demo that um calls that uh counter doou um calling increment Manny with an input of 400,000 um this costs 141 million gas um and as you could see from the screenshot here this um landed in the next block and then ended up taking about 1 second um from start to finish um there's a link to the um Explorer which I think I'll actually take the liberty of uh going to oh maybe not okay let's do this live actually um okay so um this is a again a very simple demo this code is live um we'll share the link to the GitHub repo so you can try it yourself um but yeah this is basically just calling that um increment man function with an input of 400,000 gas needed 141 million and it landed um it looks like a couple of blocks later and it took a total of 3 seconds from start to finish to do that Loop um and then we can actually check it out on the Explorer um and yeah you can see that this transaction it's super inefficient 141 million gas um Landing in that block and and utilizing most of the capacity of that block uh we'll do the same thing with pushman that Unice introduced in a second this is a very expensive uh call because it's allocating storage um for those of you who are familiar with the evm go uh gas costs you know that every slot that is consed consumed like every new slot that's consumed cost 20,000 gas um so it's going to be really expensive to run this with a large input here we're allocating 6,500 new storage slots um it ends up taking about 146 million gas and once again we'll try that so just a reminder 146 million gas is effectively taking up most of that block space since each block um has capacity of 150 million gas right now sorry I forgot the name of my input um yeah so 146 million lands in that block and we could check that one out on the Explorer as well but it'll look pretty similar all right so what we showed you was something live but we we' really like is for you to be able to try this yourself um so we've put up a really simple demo at m-speed test. verel doapp um password Denver 2025 um and this is just a simple UI that allows you to submit those kinds of transactions um if you go there you'll see this and you'll see you can choose um maybe we'll just do a little audience uh input actually so do you want to do increment many or push many what push many I'm push many okay great and what do you want the input to be a th000 okay um and we'll just do like five copies of this okay so it landed those five transactions and if we just look at one of them on the Block Explorer we see a transaction that took up 22 million gas um which which is more than the target of one full ethereum block so it took 22 million gas and it landed really fast um and you know the same is true for all these other transactions as well so yeah you can play with this yourself and then the other thing we want to point out is that we've open sourced this repo it took like an hour to builds it's not like a um a huge amount of like new code to check out but you can try it out and you can try submitting really expensive trans actions to the monad network as well so github.com sladd developers speeed test and then lastly you're going to need some test net tokens in order to chew up a lot of gas you can use that form link um to to go ahead and and test them to get some tokens oh yes uh I don't think there's a password actually yeah all right so the next thing we want to do is um is do another go ahead I'll narr while is handling this coordinating with our engineer engineering team live right now to do a real life speed test we're going to really push the TPS um up to some of its capacity um so once that gets going we should be able to see the TPS start uh amping up and skyrocketing if you are on this block explor one fun fact is that if you click on block time right here you can actually toggle the parameters a little bit to um get a rolling average for how that TPS is calculated as well as how quickly the the TPS is updating on the UI itself um so let's well here we see it the TPS is definitely starting to climb here so this test here is um intended to max out at around it was supposed to last 10 seconds and max out at around 2,000 transactions per second I don't think we quite saw that on the screen here but it definitely did um oh well I guess we're starting to hit slightly larger numbers as well in any case um this is a proof and action this is literally the network uh as it exists right now with all of these distri red validators contributing to the network all right so feel free to follow along on your devices on gon ads.

com um and just you know all of this you can check out on the Block Explorer as well and dig into what's going on uh all this is live on the live test net all right um next we want to share just a tiny bit about how this is possible we're so excited to be um sharing with you about monad and a new really fast evm that we think will make it a lot easier for developers to build really powerful applications that really scale to hundreds of millions of users and offer really cheap transactions how do we get that um how do we get that we get that through a number of different technology optimizations that our team has been working on over the past three years um and in particular we get that um through three sort of major areas Improvement um which are fast consensus asynchronous execution and fast evm execution and we're going to talk just a tiny bit about what that means and why we need all of these pieces in order to deliver this really fast evm with high performance distributed consensus so first of all with respect to fast consensus um what we want to point out is that from a lot of research that our team has done and um investigating different consensus options we found that hot stuff like protocols with linear communication that is to say the leader communicating directly to all the other leaders who then communicate directly back to the next leader that form of consensus um ends up being the most performant and the most able to scale to a large network of validators um in addition we need efficient block propagation um so specifically in that one to many to one story the one to many part is very expensive because that leader is um sending a really big block that has a lot of transactions and having to message that directly to all of the other nodes so we need a really efficient algorithm that allows that leader to send that really big block efficiently to all the other nodes um and we accomplish that through eras your coding as well as implementing a broadcast tree which we'll talk about in a second here um the second thing to point out is that consensus needs to happen before execution so we need to move execution out of the hot path of consensus into a separate work stream um that's very slightly lagging consensus and we'll explain why that's really important to unlocking really high performance and then lastly um and I'm mentioning this because we're probably not going to have time to talk about it in this talk today but really fast evm execution on its own comes from having a really performant data store um that natively stores the ethereum mle tree data on disk um that combined with really efficient execution that runs many transactions in parallel and can take advantage of the parallel access of this fast data store um so when you stack all these different improvements together that's how we get that really fast evm environment um that we just demoed to you right before this all right so um I'll give a real lightning talk um about fast consensus um so in monad bft which is the consens mechanism by which we get fully globally distributed consensus so we get that amazing map um that currently has 57 validators fully globally distributed um with the expectation of over 100 um at the time of mainnet this comes from utilizing this fan out fan in approach um so as you can see from this diagram um in this story we have three leaders three consecutive leaders Alice Bob and Charlie um and the way that a block ends up getting produced in monad is is um the leader Alice uh chooses an ordering of transactions and sends that block with all those transactions out to all of the other validators who are shown in blue um and then all those validators evaluate the validity of that block before sending um a vote Yes or No to the next validator Bob so that's the fan out and fan back in um sort of mechanism that's going on there and then Bob his job is to oh his job is actually two things but we'll talk about what the first thing first um his job is to aggregate the votes that all those other validators sent um into something called a quorum certificate which is an attestation of um the validity of that previous block uh that Alice produced um on the part of all of those other validators so Bob produces a quorum certificate um which is proof to anyone who can see it that all those other validators signed off on this block and then Bob sends the quum certificate out to everyone else once again Fanning out um and so then at that point we then land at the point where uh the second row of blue uh sort of vertical lines where all the validators are once again um thank you once again um getting that getting the QC and and evaluating and voting on it before sending it to Charlie and then lastly Charlie produces a QC about the previous QC which we call a QC on QC and messages that out and then at that point all of the nodes um now know that Alice's block has been accepted by the network and is enshrined um so that was just kind of a highlevel summary of how the bft consensus Works um this allows manad to scale to hundreds of nodes participating directly in consensus as leaders and voters um and then lastly we get some additional performance by pipelining the qc's together with block proposals so I've we've kind of extended the previous image just to include one more uh validator who we'll call I think David um and so there's just one more step here but what you can see actually is that at every stage of the process so when Alice produces a block she sends out that block with the list of transactions when Bob sends out a QC he's he also sends out a new block with a new set of transactions as well and so every single tick of the consensus there's a new block that's being produced and this pipelining increases the overall throughput of the system okay so one other thing we're going to share about really briefly is an algorithm we call Raptor cast uh Raptor cast is an efficient mechanism for allowing in the story Alice who's sending out a really big block that has uh 5,000 or 10,000 transactions in it um and sending that big block out efficiently to all these other nodes communicating almost directly um some really quick math is that if you have a block that has 10,000 transactions in it and each block each transaction is 200 bytes um that's going to be a 2 megabyte block and if you need Alice to send that um 2 megabyte chunk to every single validator multiply that by the number of validators in the network that's a huge amount of upload bandwidth um which would be really bad because we can't have validators have to have insanely High upload bandwidth um so how do we solve this problem we solve it through an algorithm called Raptor cast which basically introduces a two-l broadcast tree um where the block is eraser cated into a bunch of smaller chunks um in eraser coding you introduce some uh repetition so that uh you can take any subset of the chunks um that roughly corresponds to the size of the original block and reproduce the block from that so chunk the Block in a bunch of smaller chunks and then for each chunk um send it through a two-level broadcast tree where one validator acts as um the first hopp recipient and then broadcast to all the other validators in the node um so I like to think of this as um you know like the idea of sending a a message uh broadcasting a message into the Sun and then having the energy of the sun super broadcast that out to everywhere else in the universe um if you or a Sci-Fi fan you might know what I'm talking about here so we have this broadcast mechanism where we're sending each chunk to one validator in the rest of the network and then that one validator is responsible for propagating it to everyone else um and uh lastly just to note The Waiting of chunks the assignment of chunks to First hop recipients is weighted by the stake weight um so this produces bft uh this produces Byzantine fall tolerance because um as long as uh super majority of the network is behaving properly they'll act as proper first hop recipients and propagate um the blocks to the or the chunks to the rest of the network all right so um we're just going to yeah good yeah I was going to say I don't think we have enough time to walk through asynchronous execution this time around as we have 51 seconds left however there's a lot of material online already um actually a talk from last East Denver um among other types of uh educational material to learn about that yeah so uh thank you so much for having us here um once again you can check out um gaman ads.com to see the network live um you can check out testnet manxyz to check out um a ton of amazing applications that are already on the Mona testet one week in um and you could check out those resources that we shared earlier to try it out yourself thank you guys so much we're excited for fast evm thank you