Monad: Unleashing Parallel Execution on the EVM

Transcript

if the L1 can handle all the transactions why would you have an L2 that doesn't really make sense to me like you're just introducing pain for No Gain moned also wants to do some Innovations and some extensions on chain um that really opens up and allows you to build new new sorts of applications and that that sort of thing but for us for vzero It's Just Pure Performance it doesn't mean that performance is monads only you know targeted Innovation um it's just kind of like if you don't have the performance you can really everything else is kind of a non-starter right like if you can't support a large number of users of the chain then why why innovate in other areas doesn't even make sense what's up everyone welcome back to another episode of zerx research before

we dive into today's episode I want to give a quick shout out to our sponsor hexin one of the most hardcore security teams in web 3 pioneering in ZK and novel cryptography hexin is trusted by tier one projects like polygon including their work on their new ZK AVM mantle risk zero Lia 1in newbank and more you'll hear about them a little bit later in the show but today is September 28th and we have an awesome interview lined up with James Hunt Saker the co-founder of monad James thanks for coming on thank you for having me so I want to start the conversation just uh around I guess there's been a lot of effort in scaling the evm whether it be all l1s rollups side chains Etc uh how is monad different than these other

Solutions you know I think like early um Forks of ethereum um a lot of them were um minor sort of tweaks on the consensus um like Avalanche had um you know like a different consensus mechanism um the execution side was usually just a copy of um G the go ethereum client that was imported um so there wasn't much uh effort put there and then you know there have been many different iterations of ethereum clients in different languages but um they are all just basically re-implementations of the same design so I think what where maned defers is actually you know we're building

something that's um fundamentally different in design than than the previous iterations um on the as far as like Roll-Ups and stuff you know there's a bunch of tradeoffs that made with rollups um and there's still a lot of work to do there uh right now most rollups are centralized um they're not decentralized right they have a single sequencer um there's issues with um composability with rollups you want to you apps running on one rollup and you want to use some compose it with something that's running on a different rollup that's really hard to do so you know I think rollups are a fine uh technology but there's still a lot of unsolved problems there that I think it's probably years of research and and

effort that needs to to really make it like a good user experience and properly decentralized do you mind diving into some of like the the primary differences between you know the evm in terms of like ethereum's design versus your guys's optimized version of it obviously what we're trying to do is is utilize the full power of the machine um we're not you know we're targeting lower Ender lower-end machines as well but we want to like use all the cores on the machine we want to use the utilize the um performance of uh you know the latest SSD drives um I think um you know I think a recent number is like

$200 to buy a really nice like mvme SSD drive so um and those things really like the performance is really great um few few hundred thousand um operations per second uh the bandwidth is huge you know gigabytes of of data can be transferred to those per second even as a consumer you got have access to this like really powerful hardware and the existing like Co ethereum it's single threaded like it's a it's um I'm I'm talk talking about the execution side is single threaded you know there's obviously other things going on like the RPC and that that sort of stuff but um you know it's not just not utilizing like the power of the hardware um and that's what that's what mana's really

focused on doing our specialty um from Trading was to to build like really super optimal um software that really like utilizes the full power of the hardware and so that's kind of like we're just taking that you know we've been doing that for a long time so just taking that import porting that knowledge into the blockchain space by trying to build Mona and just just extract as much power as we can out of the out of the CPU and the memory and the SSD drives and that sort of stuff and just really speed it up all right so I think this kind of gets to the the idea of parallel execution really and the idea is there're just using multiple cores that the computer has even like very very basic consumer laptops have multiple cores they can do multiple things at the same time and the

evm is very sequential so can you talk a bit about what parallel execution means in the context of a blockchain and and why that's pretty important to scalability yeah so um you know a block is a linearly ordered set of transactions right like transaction one transaction two transaction three and each transaction is basically mapping the previous state to a new state and then you know once you string all these transactions together at the end of a block you have a whole new state um that was you know that's all these transactions applied to the previous state um most many transactions don't actually interact

with each other like the the block the the blockchain state is a bunch of different accounts like you know maybe you're transferring money to Sam I'm transferring money to somebody else th those things don't have anything to do with each other um so even though that they're linearly ordered uh the order doesn't doesn't matter right like whether your transaction was before mine in the block or mine was before yours has is of no consequence um to the out actual outcome and so um you know in in like mathematical terms you know there there's things called like partial order total order like the the transactions are really partially ordered they're not really totally ordered but we totally order them just because that's what

people are used to that's what they put in the block as a linearly ordered set of transactions so you know optimistic execution or parallel execution is trying to basically untangle that like go back from a total order to a partial order um on these transactions and that's partial order is really like a graph and then you you're trying to execute that graph um and and arrive at the same result Mona design is basically at its fundamental base it's just very naive optimistic execution like I run my transaction I run your transaction and we say we check and we we say okay do these two transactions conflict if they conflict then we then we know that oh we made a mistake

because um you know you let's say you were transferring money to me and then I was transferring money to somebody else and I didn't have enough balance for the second transfer but I did with your transfer included and obviously the ordering matters you know it's like it's like the bank at the end of the day you know your paycheck has to come in and then your mortgage payment goes out sort of thing and your paycheck wasn't in there if something happened your mortgage payment would bounce so it's that's you know those sorts of situations where um the ordering matters of course there's other situations where the ordering doesn't matter you know you go to you go to restaurant for dinner um and you pay um you know utility bill like the order that the bank puts those

on your um bank statement doesn't matter like the result is the same assuming you had enough money for both um so um you know monad is trying to optimistic execution is just trying to try different things it's basically the optimistic part is like you're naive you're dumb and you try different things and then you check oh did what I try actually work and if it worked well that's great we got a speed up because we executed these two transactions in parallel um if it didn't work then we got to go back and like fix up fix up what we did right so we have to maybe have to rerun a transaction that that we detected that um the order actually did matter I want to give a quick shout out to hexin as we explore today's blockchain landscape let's take a moment

to recognize them as a premier cyber security provider in web 3 hexin is trusted by tier one projects like polygon including a Security review on their new polygon ZK evm mantle risk zero Lio 1 in newbank and more get a deep dive into your technology stack with the most comprehensive analysis and cyber security Consulting hexin not only uses widely known methodologies and flows but discovers and introduces new ones on a day-to-day basis with over $55 billion secured they cover everything from smart contracts to blockchain to web to pentests yeah there's been nearly 7 billion of total value hacked in crypto's nent history so it's safe to say your team has a lot on the line don't skimp out take your security

seriously and reach out to hexans don't forget to mention zerox research for a free web2 pen test with your partnership and reach out to hexon at hex.io find them in the links in the show notes or reach out to them at permission list they'll be at Booth 832 uh but without further Ado let's get back to today's episode and so on the optimistic execution side is that build slightly different than the way like salana does parallel execution or is it kind of the same concept um salana has access list so salana knows ahead of time um what transactions will conflict so ethereum has this um but nobody uses it I don't think didn't use it for a

while I'm I'm not sure the current state but ethereum access lists are not required ired um there was some you would get some discount to um in theory you would get some discount to specify I'm going to load I'm going to access this account and you pay a little bit more up front because you're putting this access list in the transaction the transaction's bigger but hopefully the discount that you got um you know on the other side would outweigh that and you would you would basically get rewarded you get a discount for specifying this but um with salana that's required with etherum it's not required so we don't have the information um that salana has when it executes a block right okay so that's why you kind of have to assume like all right let's try to execute these in parallel and if

it works it works that's great we we improved but in the case it doesn't work do you end up with a a slower result or you is the worst case scenario just doing them sequentially anyways yeah I mean the worst case scenario is doing it sequentially and that could happen that could happen even on salana right if if every if you had a block on a salon block full of transactions that all access the exact same state then then salana wouldn't be able to execute them in parallel either um so yeah the worst case for any parallel system is that all the transactions are dependent upon each other and you and you you have no choice but to execute them sequentially so an optimistic um execution the worst case it would be the sequential time you may execute transactions but th you you have to

throw away the result you haven't wasted you haven't wasted time you've wasted electricity right you you you spent a lot of time Computing things that get discarded but it's not like it's not like you did that in lie of doing productive work you always are um the transactions are always considered sequentially andem merg sequentially and so um when you when you re-execute the transaction the second time it's guaranteed to Su guaranteed to succeed because at that point for you to check that there's a conflict you already have executed all the previous transactions in the block up to that point and so if you go to execute again it's definitely going to succeed and so so you can just think of like you know one core is always doing sequentially and then all

the other cores are like trying to do stuff optimistically okay okay that that makes a ton of sense and I think you gave some great examp like real world examples of when uh sequence matters and just bring that back to blockchain like you know buying an nft on openc doesn't touch the same state as say trading making a trade through Unis swap um and I'm just curious like has anyone done any good research around like let's say you could have paralyzed the evm from day one and ethereum was was had this ability like what percentage of blocks or transactions within blocks could actually be done in parallel because you know if we look at what's happening on chain today it's mostly just trades through Unis Swap and a lot of the time it's like everybody's just trading the same exact meme coin so like I'm curious

like how like what is the total level of optimization that could really exist given the fact that there's like not that many things going on on chain and a lot of State overlap yeah so um I don't have any numbers for you right now now uh We've we've looked at this obviously it varies over time if you replay early ethereum history without even parallel um execution you can do like 50,000 transactions a second right because it's all transfers um so you know I think people like to quote number of transactions per second a lot on on marketing and stuff but they'll quot they usually be quoting like transfers or something like this so yeah you know even a single-threaded um very early ethereum history you can execute 50k trans per a

second but they're all just basic transfers like people at that at that time people were just transferring ether round to each other um there were no really like smart contract usage and then obviously with time you know over the years there were more and more smart contracts people started doing more more onchain sort of activity um and you know the the the dynamic the the M the makeup of the transactions changed with as the years went on and so um I don't have an overall number for you like what today um but you know we do one of our main testing um methods that we use is we replay ethereum history so we just start at the beginning and just replay it and

just see how fast can we replay it no that that makes that makes sense and I have one more question on the uh parallel execution front because one thing that just gets a little hairy for me is like the definition of touching the same state so like it's very you know makes sense why trades are need to be sequential through a Unis swap pool but what if like you know there were two uni swap pools that both used you know usdc as the quote asset and two random coins on either end that were different like does the fact that they both touch the usdc contract make them touching the same state or is it is it different than that uh so just touching the same contract is not enough to say you're touching the same state you actually have to be touching the same storage

okay so your balance in like an erc20 is basically an entry in a dictionary you know that says Dan has this much right James has this much and so if you're doing a transfer um or interacting with another smart contract uh it you know those are different those are different state even though they're the same account so yeah I think that's I think that's one popular misconception is that we can't paralyze within accounts we can certainly paralyze transactions within the same account I'm curious about like uh I guess the ordering of transactions as they're executed in a parallel fashion so it sounds like based on your docs

which by the way you guys released the other day and we can link to in the show notes but you guys are going to do a priority gas auction and have the consensus uh client by default um or sorry the client by default of of monad basically order based on you know that gas auction whoever paid the most the least is that is that like standard or you know how does this differ from like salon's localized fee Market I just want a little bit more color on that yeah so um I think it's standard Behavior right that you the people who are willing to pay more for um a transaction should get their transaction done first right it's a it's a market um the uh yeah I I think the localized fee

Market thing is um interesting for sure um but there's there's kind of a flip side to this um you you know so just to step back for a second the most expensive parts of executing a blockchain like executing transactions is um cryptographic functions like hashes those are very expensive elliptical curve um functions are very expensive um I think like a signature recovery is 70 microsc you know that's a long that's actually a long time right that's 70,000 Nan seconds and you know on a on a decently fast CPU that's a lot of that's a lot of work right so um and and then the other part of what makes a blockchain slow is State access reading

from dis is very slow disk turnaround can be you know hundreds hundreds of uh like a median latency from a disc read can be like hundreds of micros seconds so those are very expensive relative to the other sort of computation what's going on was is like okay I want to add a balance or I want to like transfer this nft to somebody else like those that's that's extremely cheap computation right compared to the cryptography functions in the state access so um I think you know on on the one hand for parallel execution you may say okay we want to incentivize people to not access the same state but it's probably actually the opposite right we want to incentivize to an extent people

to access the same state because the same state is the same dis and disc reads are very expensive so um you know we don't we don't have all this um this fee sort of stuff figured out completely yet like we're still we're still you know thinking about these things but um if if you're if you're going to access something that I'm going to access like we're both going to trade on the same uni swap pool or something we probably actually want to make that to an extent cheaper than if you and I traded on different Unis swap pools because those are two different two different reads um from the dis and that's just more work that's just more latency that gets added in so obviously if you do too much of that if everybody does the same

exact State then you can't paralyze anything but it's definitely a trade-off between um um you know the the performance of of paral paralyzing across CPUs but also uh the caching sort of behavior that actually happens on the node right and we want to we want to to an extent ctiv Vise people to use the same state right okay that makes a ton of sense here and I I want to talk a bit about monad bft and and this uh new con con ensus mechanism you're bringing so uh what are like the I guess the core offerings I believe I saw one second block times including single slot finality uh so how are you guys achieving that what's the uh what's the core thesis behind that yeah so you know

we we started with hot stuff Um um hot stuff is just pipeline sort of um consensus algorithm right where uh you know normally you would go through these rounds and each leader would lead each round and then would lead multiple rounds and a voting and then the thing would be approved and you would be done and that that block would be you know done and then so the hot stuff and these other sort of Innovations where like introduced pipelining basically where you know one leader proposes at the same time he's also you know handling the voting for a previous proposal and so um you we Inc we started with hot stuff we incorporated you know dmft Innovations um jilon there's just there's a lot of papers out there with

different Innovations um Innovations and so you know we're just using the latest of all that um all those Innovations uh our our distribution mechanism you know we're heavily optimizing the the gossip layer the P2P the the men poool um looking in the broadcast you know trees for um the proposals so you know it's just it's just basically taking the best of of what the latest sort of research is out there and and assembling it into something that's you know very performant um Innovation wise uh on our side you know we have a couple things where maybe we do some sort of like probalistic sort of assembly which is um results in less data transmission obviously the the less

data you have to transmit the more efficient it's going to be so um you know there's compression there's sort of optimis sort of like probalistic sort of compression that can happen um so you know we're working on all that stuff but um yeah it's just the latest of of of BF research okay thanks and I also saw on the doc so we already talked about parallel execution but I also saw deferred execution in there and you guys Define that as pipelining between consensus and execution to significantly increase the execution budget that might have been already touched on when I asked you about kind of like the gas View Market but do you mind elaborating here just so it's a little bit more clear for for honestly myself yeah sure so um you know in in blockchain so far

um the leader would execute Ute all the transactions they're going to put in the block and they would arrive at a new Merkel route for that which is the basically how you cryptographically prove what the state is right it's Merkel tree and they would arrive in a new Merkel route and they would include that in the proposal and then the um the voters they would receive the proposal they would execute the transactions that are in The Proposal they would calculate their M route and they would check that against um what the leader computed and and if it matches they would vote Yes and if it didn't match they would vote no right so um again it's not that's a sequential sort of sequence of events that's happening and what we're

proposing is that we run these things in parallel so um the leader doesn't need to include the new Merkel route that doesn't mean um I think some people will infer that that means that the leader didn't execute at the same time it was created in the block it probably did right especially with me sort of opportunities or that sort of thing you know the leader probably did execute the transactions and knows the ordering um and but it it's not including that so it's the you know the the overlap buys you more time to basically pipeline execution and consensus and so you can use more cores on the machine so while you're while you're doing consensus for the next round you can be executing the previous round the pre the previous

proposal and then at some point um which is TBD you know in terms of like timing um they will include that that Merkle rout in on chain and then they people can agree on that or whether it's whether it's correct or not but um execution should be deterministic right like there there's no problemistic sort of behavior happening on on chain everything you know you should be able to look at a set of transactions and a and a state and calculate what the new state is and we should always come to the same agreement on that if if we don't then there's probably a coding error somewhere somebody made a mistake so um execution should be

deterministic so it shouldn't it shouldn't be the case that you ever really disagree on what the result of executing a set of transactions is um so because the proposal doesn't include this it doesn't it doesn't preclude you from calculating like as fast as you want you know if you have a really high-end machine you're a trading firm like an hft trading firm and you want to know what the latest state is from The Proposal of course you can calculate it as fast as you want um if you're if you're doing meev of course you want to use a big powerful machine and and throw a ton of hardware at it and you can calculate all the different possibilities for how you can make money off that block so you know it doesn't it doesn't stop anybody from executing as fast as they want but it

just means that we're not really um coming to consensus on the the new state route for just a short window of time um it also sort of allows bursty Behavior you know you might you might create a block that takes more than a second to execute right um or you may create you know and then at some point they have to they have to catch up but you know they can't run the execution can't um you know Trail consensus and just keep building up you know we like okay now now we're an hour behind it's not like that so there's some mechanisms in play to to stop that but um yeah it it it doesn't it's up it just gives you more budget and allows you to do things

in parallel awesome I appreciate you kind of tying a bow on that concept for me it's definitely like a hard thing to graas so I appreciate you explaining it to me like I'm five but uh how does uh monad BD fit into this um I was curious how is it different than you know the the popular clients on ethereum uh do you mean Monet DB yeah sorry about that yeah yeah yeah so you know they um there's two main generic sort of key value stores that most clients use um some use uh B tree databases um the most popular B tree database is called lmdb um I think it's lightning well it's lightning something lightning memory map database or something like that very popular data uh

key value store I'll say database and key value store interchangeably they're not we're not talking about SQL databases we're talking about key value Stores um so uh some use that uh Aragon uses mdbx which is a fork of lmdb um and then some use uh LSM databases uh um key value stores like level DB or rocksdb so these these databases have their own structure B tree is a computer science data structure LSM log structure merry is a computer science data structure and um that's you know that's how they implement it on disk um there's a number of other issues with

implementation like they're not fully asynchronous they don't leverage the latest Linux kernel innovations that sort of thing but that's kind of a SE thing um and then in ethereum we have uh Patricia Merkel trees so Patricia Merkel tree is just a a data structure of its own that you can cryptographically verify and prove things and so what the situation we end up in is we're trying to take this one data structure and and shoehorn it into another data structure and that becomes very inefficient um and so the usage of I think I think Guth uses to level DB you know the way that they navigate gate um the patri Merkel tree it's just a lot of dis access a lot

of lookups a lot of work that's that's happening there and it's it's just very inefficient and it's um frankly just a waste of the power of like I said earlier SSD drives are really powerful these days you know you can get a really cheap SSD drive that has a lot of you know Hardware capability and and that that capability is all lost that power is all lost with these these other these other databases and and that design so knowing that we kind of okay we we engaged and okay we have to build our own database um we did tons of benchmarking even over months and investigation and running all sorts of simulations and um you know just this was this was a huge effort actually um I

know in like a lot of the docs it's like one line okay mon DB but it's actually a huge undertaking right it's there's not very many databases in the world and it's it's really hard to build it and there's probably like a couple hundred people in the world that work on like key value stores right like Roxy I think is maintained you know there's Facebook has one Google Google Crea levelb Facebook I think made roxb apologies if I'm messing this up but um you know these are big companies um it's it's just a really huge undertaking to kind of create this sort of thing but you know we felt that we had to because that's the only way um there's um that we're going to get the performance that we need so uh and then on the back side of that like I said once you start that

undertaking then you got to make sure that you're using the latest Linux kernel Technologies make sure you're fully leveraging the power of the SSD so that's where asynchronous IO comes in on Linux that's called iur ring um so there's a lot of in kernel stuff lowlevel sort of Kernel and and Hardware sort of stuff that goes into this um thinking to really like speed it up but um yeah it's it's a big part of mon execution as the database um as I mentioned before you know like the two major expenses of execution are you know cryptographic functions and and dis access so this is this is half of that basically okay so it does sound like a lot of this as a whole is really a huge

undertaking is taking the evm and and building off of it uh and and really focusing on efficiency and like basically taking some of the leading ideas and and innovating on those and then putting them all in not only at the execution layer but also with consensus as well um so I'm curious to kind of get your take from more I guess more of like a a business sense in some ways is what was the idea around doing this and like building your own separate L1 as opposed to doing something that say like eclipse is doing where they just took the spvm and sat it on top of ethereum as an L2 um so that way they still had this really improved execution environment over to the traditional evm so like what what was the like did that ever cross your mind of like hey let's just focus

on the EV um just the execution environment for now and maybe we address the consensus later and launch as an L2 was that ever like a part of the discussion well you know if if you're going to have a lot of transactions there's going to be a lot of data like there's a lot of data a lot of transactions and so um we did look at uh you know we did look at data availabilities uh Solutions um uh it just we just are going to generate too much data like we're targeting right now 100 megabit per second um connection that's you know could be you know 8 megabytes or something and per second you're going to generate eight megabytes of data per

second that's a huge amount of data that compared to what these Data avilas Solutions are supporting right now um I I think I agree with um Anatoli you know he says okay if if there ever is a solution that that's great then salana will convert to an L2 you know like um if yeah if we're not you know we're not opposed to that it's just like there's nothing available that can support what we want to do do and if there ever was then yeah we would consider it but um you know we we did look at celesy we did look at other sort of um well I mean ethereum is kind of a non-star because ethereum really slow right like ethereum block times are slow and and the amount of data that you can post on ethereum is very very slow and

it's also going to be expensive you know I on some of these busy weekends I've gone and traded on optimism or arbitrum you know on on some of the exchanges on the l2s and the fees the fees Skyrocket on the L 2's as well um because the economics right it's tied to so the F sky rocket on ethereum they sky rocket on the L2 and so that's also something we we kind of wanted to avoid but yeah if there ever is an opportunity for if there's a great solution out there that can that can handle a lot of data um we'd definitely be be open to that but it just doesn't exist right now so just to put that number um like8 megabits per sec per second megab megabytes per second into perspective like what does a

salana roughly generate uh per second if you know off the top of your head I question yeah I don't know off the top of my head um what they're what they're putting through I mean salana salana right now is underutilized um you know the the average number of transactions per second at any given moment is still pretty significantly under what it's capable of so um it's been a while since I've kind of seen like a spike and you know Salon sort of activity um but yeah I don't I don't know I don't know the theoretical number of what salana can do but I I have seen in practice it can do a decent number of transactions as well do you for see State bloat like becoming a problem because as you mentioned this is going to be a very data intensive

chain so like how how are you guys going to circumvent that and you know do you expect node requirements to increase over time um yeah State loo is State loo obviously is a big thing um I think mon DB addresses some of that to an extent like we can handle a much larger State local state um there's honestly the most worrying thing is like synchronization so you know you bring up a new node you want a sync um just like salana you can't replay from the beginning of of of history of monad because you just there's just no way you could catch up right you would need a supercomputer or something um so you have to sync to some sort of state from another node if that state is hundreds of gigabytes that's a that's a heck of a

lot of data to download and and and in the meantime the chain is running the background is continuing to generate new States so um yeah it's state growth is definitely an issue um I'm not worried about it from right now from a node requirement perspective or like how much is on dis I'm more worried about algorithmically like how do we sync State across nodes and how do we how do we deal with this large object you know over the network less worried about it on the on the actual SSD drive um there are some I I think even ethereum has put out some proposals on on dealing with State growth um I personally would like to see you know archiving happen as sort

of a solution where kind of like just state is deterministically pruned from the tree but it can be restored later so you know I I have a big contract or something and I haven't touched it in a while we just kind of purge it out of the tree but it's not lost you can still um you can a transaction that restores the state and then you would prove that that's that's a valid State and so that's kind of like an archiving solution I would like to see that first before we um you know maybe go to storage rent or that sort of thing where you know you kind of forcing people it just seems like less intrusive to um keep stuff around but keep it

archived as as opposed to like actually deleting it um you know that's not that's just not a good user experience you know you you haven't logged into Google photos for a year and all your photos are gone like that's not a good that's not a good experience for the user so um you know but if Google said okay well you haven't logged into Google for a while we're going to Archive your photos and if you want them back you have to pay off you know a little fee and we're going to go out to the warehouse and get the tape drive and bring it back in and restore your photos that that seems more reasonable to me so um yeah it's it's an interesting problem and a lot of people have proposals and yeah we we'll be looking at that but for for for version zero of monad it's not

really I'm not not a concern right now is there any uh compatibility with like existing evm contracts today like can I just pick up a contract I deployed on eth mained and then bring it over to manad and or would I have any issues doing that no issues no so we replay our our whole test like I mentioned our testing is um replaying ethereum history so everything is currently active on ethereum should run run on onead and um we also run the ethereum test Suites and all that sort of stuff on onead code as well so yeah should be should be identical and was that like some of the core reasoning behind using the evm and optimizing it as opposed to taking just a blank slate and kind of building your

own execution environment yeah yeah I mean we did look at wasm early on but you know there is so wum is somewhat Source compatible like you can compile um solidity to wum um but you know we just felt it like um I think honestly I think people make too much of a big deal about the VMS of these things like they're all pretty standard like I remember doing Java VM back in the day you know so it's like they're all pretty very similar um there may be some slight architectural things that are different underneath but um evm is kind of weird like it has 32 by word sizes and this sort of stuff but besides

a little bit of these like weird things it's it's just a standard stack based VM and there have been a lot of VMS in history and there's nothing there's nothing fancy or different about it besides you know these kind of little quirky sort of things so um there's no really good reason to run away from the ethereum VM it's it's a fine VM um so going that route yeah then we then we're fully bite code compatible you know how would I replay ethereum history if I if I did a wasum VM I wouldn't be able to you know so there's it's yeah it just made sense to just stick with what's there it works it's it's fine there's nothing wrong with it

um yeah so as a question from a guy with zero coding knowledge for the most part I'm in like Elementary School for a squel in Python so I saw that the manad client is written in Rust and C++ like why first of all and then second of all and again this is coming from a not super technical guy but is there any challenges with getting a bite code compatible evm uh execution environment when you have your client written in these other languages um so so first as to the why like um you know if you want performance if you work at a high frequency trading firm you're going to write your software in C++ like that's just that's just the way it is see your C+ plus right there's

no other language um well now now Russ is coming along but people in my experience people don't use rust and finance at least not yet so um you know there's no other there's no other language that's going to give you that level of performance not go you know go has um garbage collection memory memory allocation it's just not as fast it's it's it's quirky language as well um obviously Python and these sorts of things are not are non-starters they're not fast languages so um yeah it's just you know what's available like what's what's what are fast languages it's basically C C++ and now now Russ has come along but um and then that's and frankly that's just like our expertise you know if

there was another fast language that we didn't know then you know that that'd be a different thing but it's like that's our expertise we've been writing C++ code for a long time um the team knows it very well so um it just doesn't make sense to try to to use a different language um in terms of related to the evm no I mean there's been C++ there are C++ implementations of the evm um on under the Aragon architecture you know Aragon's in in go but there was um there is selorm which is written in C++ there is um um that's still actively maintained and developed there is uh there was a rust um thing you know I think Paradigm has that um W client

that's in Rust um and then yeah historically there there have been other C++ liation so yeah the implementation language is doesn't have um any bearing on um how you know what implementing the ethereum VM that's a totally separate thing okay thanks that's super helpful and then just doubling down on Dan's question like okay like if I have Unis swap deployed on the you know ethereum is it really easy to just copy paste go on to manad um is there any scenario in which that is not the case because I've seen a lot of you know ZK avms different l2s claim ethereum compatibility but it's really not quite as out of the box as they kind of advertise it to be um I'm not aware of any compatibility

differences like I said we we literally replay ethereum history to see how fast we can execute so you know if somebody had deployed something on ethereum that wasn't compatible with monad you know that would fail that that exercise would fail right so um maybe somebody has a smart contract somewhere that's not deployed on ethereum and hasn't been used it's not I don't I mean I don't know yeah but it's as far as We Know or 100% compatible and then on like a percentage basis when you replay that history how much faster are you um yeah like I said it varies by it varies by his by history so early on like I said you can do 50,000

transactions per second on a single core mon is probably not making no not making much of a difference there right um um but yeah I don't have I don't have the latest numbers I mean it it's it's also kind of funky because blocks are small right so we're really targeting 10,000 transactions per second or maybe even more and we're that's one block right so our our block time is one second so our blocks will be about 10,000 transactions or more and um ethereum blocks are 200 transactions or something 250 can't remember so it's it's not really totally and you know you're trying to calculate the Merkel route after the state right so like after each block you

have to calculate the new Merle route and so when you're replaying ethereum like you're calculating the new Merle route after 250 transactions whereas you know for monads anticipated usage you would be calculating a new merco route after 10,000 transactions so there's there's some things that are kind of like not fully aligned in terms of making like a fair um performance comparison but um yeah we'll do more work on that eventually some point we'll we'll publish some numbers we'll just say okay we we play like like I said the historical stuff's not that interesting so you know we'll publish some numbers we'll say we replayed ethereum from block 15 million to 16 million it took this long that sort of thing um I know a popular metric that people like to post on Twitter and stuff is like sync time or that sort of thing but that again

that's that's syncing from the beginning of ethereum um different transaction makeup those numbers aren't really fair comparisons and um even the Aragon architecture it doesn't compute um it it uses a staged what they call stage sync and it doesn't compute the Merle route until the very end after after you've executed X number of blocks so it's not really these numbers that people use um thr around I'm sure you guys are aware of this right like marketing crypto marketing numbers are kind of you know baloney half the time what no way so yeah so the you know these these kind of things don't make sense so yeah at some point we need to produce like a rigorous like open source comparison and it needs to be on recent data on ethereum and you

know how F can each client sort of Replay these numbers and then and then we'll it'll just be open and it kind of like untampered like source of Truth on performance but um yeah I don't don't have the numbers for you right now is the bet in the long term that kind of similar to the salon a bet Hardware is going to improve and therefore manad throughput will improve as Hardware you know improvements accelerate or do you see a world where maybe rollups do live on manad or is that just like rollups aren't it it right right now I mean if if the L1 can handle all the transactions why would you have an L2 that doesn't really make sense to me like you're just introducing pay for no gain right so um we'd have to see maybe

somebody else has something that I don't understand at the use case for an L2 I I think you know one thing that one one case that actually is mentioned is um on an L2 you can you can introduce let's say Primitives in the computation that are not on the L1 already so that would that is an actual that's an actual like real reason to do an L2 um it has nothing to do with performance right so um those sorts of cases I would have to look at on a case-by Case basis and say like okay that does that really make sense does it not make sense you know Monet also wants to do some Innovations and some extensions on chain um that really opens up and allows you to build new new sorts

of applications and that that sort of thing but for us for VZ It's Just Pure Performance it doesn't mean that performance is monads only you know targeted Innovation um it's just kind of like if you don't have the performance you can't really everything else is kind of a non-starter right like if you can't support a large number of users of the chain then why why innovate in other areas it doesn't even make sense so um you know we have to have we have to start with a good fundamental base of a high performance system and then we can come and we can innovate and we can add new features and new ways to write write software for onchain and all that sort of stuff that really allows like app teams to build you know great apps that people want to use but um that that's going to come in

later version so um I would have to see those sort of like L2 use cases like if somebody says oh I really want an L2 on monad well I would like to have a conversation with him and understand like what what's missing from monad that you need in L2 um and and we would you know that that would be an interesting thing to to talk about and maybe that maybe what's missing is that something that can be added to Mona directly and and they don't need to go through the L2 route because as I said it's not it's not a good experience for composability and and those other sort of things yeah maybe like something around like privacy or kyc comes to mind but we haven't really seen that on ethereum yet either so uh I liked your point as well is about like additional computation that'd

be pretty cool um but I want to I think you mentioned this earlier that you're still you know this is still kind of in the development phase more so uh but I want to talk a bit about transaction fees so with a lot of the high throughput chains you're getting super low fees that's kind of like one of the the features is you can um run different types of transactions that wouldn't make any sense on ethereum so different types of trading techniques for example is that what we can expect from an not as well yeah so I think um the more expensive part of the transaction is really like getting the data around um so again we don't have the fees worked out but I think the fees are going to be more about how big is a transaction how you know how much does it state does it

touch that sort of thing like um less so than the I'm not I'm not sure that the gas fees that are currently modeled on ethereum are really reflecting the the the the total picture of the cost of execution so um we have to evaluate that but you know the thing that the thing is just getting data around right like sending it from here to Singapore and to London and all over the place and and the uh the band cost the network costs that's that's a big chunk of it um so I I think you know preliminarily like I think the gas fee should reflect that more than um you know I I did an expensive computation like that that's probably not not a big of a deal

cost-wise to the blockchain we want to incentivize like good computation right like we you know um a point I make often is like blockchain apps are very simple you know think of how much code um you know we're using this website now to to stream this right think of how much code is in that website versus like the fanciest onchain program you know the orders the magnitude of difference in in in the number of codes so um I think also part of adoption is people building real apps that people want to use and and to do that you have to be able to support a significant amount of computation and a significant sort of features and that's I think that stuff will come later but um you know this is not it's not meant to be like you know

programs running programs that people can write in third grade sort of thing um you know these they're supposed to be really building like good stuff here so um we really want to you know make sure that Monet is in place to execute those um execute that software and and and build apps that people really want to use so I want I want to I want to hammer down there because we've seen a large number of high through Pains come to life in the of of late right so obviously salana apos suie say they're starting to be this like a lot of people are starting to think in that same vein so like what are some of these applications that could exist and and and like I guess right now my my issue is all we're seeing is like things that

were built on ethereum forked over to these new locations and it's like okay well great now it's like a slightly better version of something that already existed so how do we incentive how's manad going to really incentivize organic adoption of like these new ideas of like hey we have this new technology where new things can actually be built so so let's build those things if I had a great idea for an app I'd probably build it um but that's not my specialty right I'm I'm a I'm a low agency uh high frequency Trader here so um you know I think our expertise is in trading obviously that's our background um you know ke and I ran hft uh trading team for a long time at Jump um so you know I think we understand that part well and

so um you know we will um we can basically help push the frontier of onchain that sort of um that area that discipline but in terms of like consumer apps or social apps or that sort of stuff um you know I I personally don't that's not my expertise I personally don't know that but yeah we have to we have to work with app teams and I think um I think you know from my experience that um there's not a lot of collaboration with the with the core chains um with sorry with the change in the app team so I think from from a different perspective I would like monad to be you

know collaborating with app teams and helping them design Implement their software in a way that's that's high performant and um really un if I can help understand their problems and then I can help them resolve those problems and that's going to make them more successful so um I I I do heavily see this as like a collaboration um you know an example is like the Microsoft Office team has access to the Microsoft Windows team at Microsoft right and that allows them to do a lot of things and and there's been a lot of changes to Windows that allows office you know to advance and so um that's kind of an old example I wish I could think of a more recent example but you know this having access

to the to the people that are building the technology underneath you is I think a very valuable thing and um we would like to collaborate with app teams and will like help enable them to to build real applications that are you know they're going to have um that are going to be desired by users I absolutely love that approach it's pretty funny actually because I I feel like I talked to so many infra people and it's funny how much they don't really know about what's going on at the DAP air so to hear that you're hoping to you know Foster some collaboration between the two teams I think is actually a really solid recipe for success but I do want to jump over a little bit to I guess uh manad BD and actually BD this time um in terms of like Bridge Integrations how are people

going to get over there once it's live if you even know yet um what daps have you talked to from the ethereum world that are interested in porting over um and honestly what's the general timeline on what you guys are doing um yeah so for bridging um you know there's there's obviously a number of different options um number of different projects out there um you know we're talking to them I'm not so much on the BD side of things my head isn't C++ code all day um so yeah I can't you know I can't provide the latest and greatest uh updates on where we're at with BD um technical wise though I think a bridge we have to have some sort of canonical Bridge that's um that's doing uh you know that's integrated with ethereum um I would like

to do something that's very secure um but then you know the other other Bridges other projects will come in and and have their you know bridged assets and all that that sort of thing um but we need some sort of like basic level uh very secure uh bridge at the at the base level um but yeah we we're obviously talking all those teams I'm not in most of those meetings because like I said I'm I'm always coding and and running simulations and and and that sort of thing so I'm not a good person to to answer about those but yeah we we have signed most of our our Partnerships that you've seen um you can just you know we announce them on Twitter or whatever and and they're announced and there's obviously tons of conversations going on

um behind the scenes the BD team is very active always meeting with people um all day every day it's just constant meeting so um so yeah there there's going to be some there's going to be a lot of good projects online and I'm pretty confident of that um but yeah I can't share any specifics right now taking you back into the code then uh what are the biggest challenges that you face and what are like the the last hurdles that you're like all right if we can solve this this is going to be the best blockchain that exists yeah I mean you know it's it's easy to write something um it's easy to write software right like you know and um you know you can write an application for

the desktop or you can write a web page and if it goes down it's fine like no one no one's you know maybe somebody's upset they lose their work or something you know or you know Expedia goes down you can't book a flight for the next five minutes you know something H they bring it back up and like okay now I can book my flight like these sorts of things with blockchain that's not really an option right like um so there's there's reliability in terms of it it can't go down so you know that's a that's a big piece of engineering to just make sure it shouldn't go down and then there's um hacking obviously so you know do are we messing up somewhere can is some somebody going to read the monad implementation and say oh if I send these certain instructions in this

transaction I can destroy the system or I can transfer money to myself for that sort of thing so um it's definitely you don't have the same level of um you know luxuries that you have with normal applications where like okay it goes down I'll just restart it that sort of thing with the blockchain it's it's it's very you have to be very deliberate about everything you do very careful super rigorous um and yeah that's that's what keeps me up at night like the performance problems they don't keep me up at night because um you know I'm confident we can always solve those sorts of issues um but you know somebody hacking or somebody being able to do a service attack or something like that on

Monet is what is what really keeps me up well I think that's a good spot to close it up unless Dan you had any other questions jump in but uh James it's been a pleasure to speak with you it's awesome to hear someone who's like really on the technical side of things and can teach me things so I learned a lot um do you mind sharing people uh I guess where they can find you to learn more about manad oh yeah our website is manad doxyz so m o axyz awesome thanks a ton James it's been a pleasure man cheers [Music] w