In this week's interview Dan and Sam are joined by James Huntsaker, co-founder of Monad, a rising L1 project focused on optimizing and scaling the Ethereum Virtual Machine (EVM). The conversation delves deep into Monad's technical architecture, its challenges, and how it differentiates itself in an increasingly competitive L2 and L1 landscape. Find out how Monad utilizes hardware to its full potential, its roadmap, and how it aims to enable truly scalable, secure EVM based applications. 
- -
Follow James Hunsaker: https://twitter.com/_jhunsaker
Follow Sam: https://twitter.com/swmartin19
Follow Dan: https://twitter.com/smyyguy
Follow Blockworks Research: https://twitter.com/blockworksres

Subscribe on YouTube: https://bit.ly/3foDS38
Subscribe on Apple: https://apple.co/3SNhUEt
Subscribe on Spotify: https://spoti.fi/3NlP1hA

Get top market insights and the latest in crypto news. Subscribe to Blockworks Daily Newsletter: https://blockworks.co/newsletter/
- -
Hexens is the premier cybersecurity provider in web3 with an essential focus on blockchain technologies. Always exceeding clients’ expectations, Hexens is a trusted security partner of the most prominent web3 projects like Polygon & zkEVM, 1inch, Lido, Nubank, TON, Risc0, EigenLayer, Mantle, Celo and more.
https://hexens.io/
- -
Timestamps:
(00:00) Introduction
(02:58) Monad's Key Design Difference
(08:25) “Hexens Ad’
(09:29) Monad Parallel Execution Design
(15:27) Monad BFT and Consensus Mechanism
(25:01) Monad DB - Database Structure
(32:34) Managing State Bloat
(37:48) Monad Client C++ and Rust Decision
(43:39) Are L2s Necessary?
(46:20) Transaction Fees
(48:43) Enabling Next Gen Apps
- -
Resources:
Resource Docs
https://docs.monad.xyz/

- -
Check out Blockworks Research today! Research, data, governance, tokenomics, and models – now, all in one place

Blockworks Research: https://www.blockworksresearch.com/
Free Daily Newsletter: https://blockworks.co/newsletter
- -
Disclaimer: Nothing said on 0xResearch is a recommendation to buy or sell securities or tokens. This podcast is for informational purposes only, and any views expressed by anyone on the show are solely our opinions, not financial advice. Dan, Sam, and our guests may hold positions in the companies, funds, or projects discussed.

If the L1 can handle all the transactions, why would you have an L2?

Like you're just introducing pain for no gain.

Monad also wants to do some innovations and some extensions on chain that really opens up and allows you to build new sorts of applications and that sort of thing.

But for us, for vZero, it's just pure performance.

It doesn't mean that performance is Monad's only, you know, target innovation.

It's just kind of like if you don't have the performance, you can't really.

Everything else is kind of a nonstarter, right?

Like if you can't support a large number of users of the chain, then why innovate in other areas?

Welcome back to another episode of ZeroX Research.

Before we dive into today's episode, I want to give a quick shout out to our sponsor, Hexens, 1 of the most hardcore security teams in web 3, pioneering in ZK and novel cryptography.

Hexens is trusted by tier 1 projects like Polygon, including the work on their new ZK AVM, Mantle, Risk 0, Lido, 1 Inch, NewBank, and more.

You'll hear about them a little bit later in the show.

And we have an awesome interview lined up with James Huntsaker, the co-founder of Monad.

So I want to start the conversation just around, I guess, there's been a lot of effort in scaling the EVM, whether it be L1s, roll-ups, sidechains, etc.

How is Monad different than these other solutions?

You know, I think like early forks of Ethereum, A lot of them more minor sort of tweaks on the consensus, like Avalanche had a different consensus mechanism.

The execution side was usually just a copy of Geth, the Go Ethereum client that was imported.

And you know, there have been many different iterations of Ethereum clients in different languages, but they are all just basically re-implementations of the same design.

So I think where Monad differs is actually, you know, we're building something that's fundamentally different in design than the previous iterations.

On the, as far as like rollups and stuff, you know, there's a bunch of trade-offs that made with rollups and there's still a lot of work to do there.

There's issues with composability with rollups.

You want to, yeah, apps running on 1 rollup and you want to use something to compose it with something that's running on a different rollup.

So, you know, I think rollups are a fine technology but there's still a lot of unsolved problems there that I think it's probably years of research and effort that needs to really make it like a good user experience and properly decentralized.

Do you mind diving into some of like the primary differences between, you know, VEVM in terms of like Ethereum's design versus your guys' optimized version of it?

Obviously, what we're trying to do is utilize the full power of the machine.

We're targeting lower end machines as well, but we wanted like you all the cores on the machine we want to use the utilize the performance of You know the latest SSD drives.

I think You know, I think a recent number is like $200 to buy a really nice NVMe SSD drive.

So, and those things really, like the performance is really great.

A few hundred thousand operations per second, the bandwidth is huge, you know, gigabytes of data can be transferred to those per second.

Even as a consumer, you have access to this like really powerful hardware.

And the existing, like Ethereum is single threaded, like it's, I'm talking about the execution side of single threaded, and there's obviously other things going on like RPC and that sort of stuff.

But you know, it's not, just not utilizing like the power of the hardware.

And that's what, That's what Mona is really focused on doing.

Our specialty from trading was to build like really super optimal 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 we're just taking that and porting that knowledge into the blockchain space by trying to build monad and just extract as much power as we can 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 idea of parallel execution really, and the idea is they'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 why that's pretty important to scalability?

Yeah, so, you know, a block is a linearly ordered set of transactions, right?

Like transaction 1, transaction 2, transaction 3, 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.

That's all these transactions applied to the previous state.

Most, many transactions don't actually interact with each other.

Like the block, 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.

Those things don't have anything to do with each other.

So even though that they're linearly ordered, the order doesn't matter, right?

Like whether your transaction was before mine in the block or mine was before yours has is of no consequence to the actual outcome.

And so, you know, in like mathematical terms, you know, There's things like partial order, total order.

Like 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 is 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 on these transactions.

And that partial order is really like a graph and then you're trying to execute that graph and arrive at the same result.

Mona's 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 say, okay, do these 2 transactions conflict?

If they conflict, then we know that, oh, we made a mistake because 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 it with your transfer included.

You know, 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 if 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 the ordering matters.

Of course, there's other situations where the ordering doesn't matter.

You know, you go to, you go to a restaurant for dinner and you pay, you know, your utility bill, like the, the order that the bank puts those on your bank statement doesn't matter.

Like the result is the same, assuming you had enough money for both.

So, 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?

We got to speed up because we executed these 2 transactions in parallel.

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 the order actually did matter.

As we explore today's blockchain landscape, let's take a moment to recognize them as a premier cybersecurity provider in Web3.

Hexens is trusted by tier 1 projects like Polygon, including a security review on their new Polygon ZK EVM, Mantle, Risk 0, Lido, OneInch, NewBank, and more.

Get a deep dive into your technology stack with the most comprehensive analysis and cybersecurity consulting.

Hexens 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 2 pen tests.

Yeah, there's been nearly $7 billion of total value hacked in crypto's nascent 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 Hexens.

Don't forget to mention 0xResearch for a free Web2 pen test with your partnership and reach out to Hexens at hexens.io.

Find them in the links in the show notes or reach out to them at permissionless.

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 Solana does parallel execution?

So Solana knows ahead of time what transactions will conflict.

So Ethereum has this, but nobody uses it.

I don't think, didn't use it for a while.

I'm not sure the current state, but Ethereum access lists are not required.

There was some, you would get some discount to, there 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 upfront because you're putting this access list in the transaction.

The transaction is bigger, but hopefully the discount that you got, you know, on the other side would outweigh that.

And you would basically get rewarded, you would get a discount for specifying this.

So we don't have the information that Solana 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 improved.

But in the case it doesn't work, do you end up with a slower result or 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 Solana, right?

If every, if you had a block on a Solana block full of transactions that all access the exact same state, then Solana wouldn't be able to execute them in parallel either.

So yeah, the worst case for any parallel system is that all the transactions are dependent upon each other and you have no choice but to execute them sequentially.

So an optimistic execution, the worst case would be the sequential time.

You may execute transactions, but you have to throw away the result.

You've spent a lot of time computing things that get discarded, but it's not like you did that in lieu of doing productive work.

The transactions are always considered sequentially, emerged sequentially.

And so when you re-execute the transaction the second time, it's 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 gonna succeed.

And so you can just think of like, you know, 1 core is always doing sequentially and then all the other cores are like trying to do stuff optimistically.

And I think you gave some great example, like real world examples of when sequence matters.

And just bring that back to blockchain, like, you know, buying an NFT on OpenSea doesn't touch the same state as, say, trading, making a trade through Uniswap.

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 1 and Ethereum 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 Uniswap 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 not that many things going on on-chain and a lot of state overlap?

Yeah, so I don't have any numbers for you right now.

If you replay early Ethereum history without even parallel execution, you can do like 50,000 transactions a second, right?

So, You know, I think people like to quote number of transactions per second a lot on on marketing and stuff.

But they'll usually be quoting like transfers or something like this.

So yeah, you know, even a single threaded, very early Ethereum history, you can execute 50k transactions per second, but they're all just basic transfers.

Like people at that at that time, people were just transferring ETH around to each other.

There were no really like smart contract uses.

And then obviously, with time, you know, over the years, there were more and more smart contracts, people started doing more more on chain sort of activity.

And, you know, the the dynamic, the the make the makeup of the transactions changed as the years went on.

And so, I don't have an overall number for you like what today, but, you know, we do 1 of our main testing 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.

And I have 1 more question on the parallel execution front, because 1 thing that just gets a little hairy for me is the definition of touching the same state.

So it makes sense why trades need to be sequential through a Uniswap pool.

But what if there were 2 Uniswap pools that both used, you know, USDC as the quote asset and 2 random coins on either end that were different.

Like does the fact that they both touched the USDC contract make them touching the same state or is it different than

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.

So your balance in like an ERC-20 is basically an entry in a dictionary that says Dan has this much, right?

And so if you're doing the transfer, or interacting with another smart contract, those are different states, even though they're the same account.

So yeah, I think that's 1 popular misconception is that we can't parallelize within accounts.

We can certainly parallelize transactions within the same account.

I'm curious about, like, 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 client by default or sorry, the client by default of Monad basically order based on that gas auction whoever paid the most, the least.

Is that like standard or how does this differ from like Solana's localized fee markets?

I just want a little bit more color on that.

So I think it's standard behavior, right?

That you the people who are willing to pay more for a transaction should get their transaction done first.

Yeah, I think the localized fee market thing is interesting for sure.

So just to step back for a second, the most expensive parts of executing a blockchain, like executing transactions, is cryptographic functions like hashes, those are very expensive.

Elliptical curve functions are very expensive.

I think like a signature recovery is 70 microseconds.

You know, that's a long, that's actually a long time, right?

And you know, on a decently fast CPU, that's a lot of work, right?

So, And then the other part of what makes a blockchain slow is state access.

Disk turnaround can be, you know, hundreds of like a median latency from a disk where you can be like hundreds of microseconds.

So those are very expensive relative to the other sort of computation what's going on, which is like, okay, I want to add a balance or I want to like transfer this NFT to somebody else like those.

That's extremely cheap computation, right?

Compared to the cryptography functions and the state access.

So I think, you know, on the 1 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 disk.

So, we don't have all this fee sort of stuff figured out completely yet.

But if you're going to access something that I'm going to access, like we're both going to trade on the same Uniswap pool or something, we probably actually want to make that to an extent cheaper than if you and I traded on different Uniswap pools, because those are 2 different reads from the disk.

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 parallelize anything.

But it's definitely a trade-off between the performance of parallelizing across CPUs, but also the caching sort of behavior that actually happens on the node, right?

And we want to an extent, incentivize people to use the same state.

Right, okay, that makes a ton of sense here.

And I want to talk a bit about Monad BFT and this new consensus mechanism you're bringing.

So What are like the, I guess, the core offerings?

I believe I saw 1 second block times, including single slot finality.

What's the, what's the core thesis behind that?

So, you know, we, we started with hot stuff.

Hot stuff is just pipeline sort of consensus algorithm, right?

Where, you know, normally you would go through these rounds and each leader would lead each round and then would lead multiple rounds and 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 were like introduced pipelining basically, where 1 leader proposes at the same time, he's also handling the voting for a previous proposal.

We incorporated DMVFT innovations, Jolteon.

There's a lot of papers out there with different innovations.

And so, you know, we're just using the latest of all that, all those innovations.

Our distribution mechanism, you know, we're heavily optimizing the gossip layer, the P2P, the mempool, looking at the broadcast, you know, trees for the proposals.

So, you know, it's just basically taking the best of what the latest sort of research is out there and assembling it into something that's, you know, very performant.

Innovation-wise, on our side, you know, we have a couple of things where maybe we do some sort of probabilistic sort of assembly, which results in less data transmission.

Obviously, the less data you have to transmit, the more efficient it's going to be.

There's compression, there's sort of probabilistic sort of compression that can happen.

So, you know, we're working on all that stuff, but yeah, it's just the latest of BFT research.

And I also saw on the doc, so we already talked about parallel execution, but I also saw deferred execution 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 market.

But do you mind elaborating here just so it's a little bit more clear for honestly myself?

So, you know, in So, you know, in blockchains so far, the leader would execute all the transactions that are going to put in a block and they would arrive at a new Merkle route for that, which is the basically how you cryptographically prove what the state is, right?

And they would arrive at a new Merkle route for that, which is basically how you cryptographically prove what the state is, right?

And they would arrive at a new Merkle route, and they would include that in the proposal.

And then the voters, they would receive the proposal, they would execute the transactions that are in the proposal.

They would calculate their Merkle route and they would check that against what the leader computed.

And if it didn't match, they would vote no, right?

So 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 the leader doesn't need to include the new Merkle route.

That doesn't mean, I think some people will infer that that means that the leader didn't execute at the same time it was creating the block.

It probably did, right, especially with MEV sort of opportunities or that sort of thing.

You know, the leader probably did execute the transactions and knows the ordering.

So it's the, you know, 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 doing consensus for the next round, you can be executing the previous round, the previous proposal.

And then at some point, which is TBD, in terms of like timing, they will include that Merkle root on chain and then people can agree on that or whether it's correct or not.

But execution should be deterministic, right?

Like there's no probabilistic sort of behavior happening on chain.

Everything, You should be able to look at a set of transactions and a state and calculate what the new state is.

And we should always come to the same agreement on that.

If we don't, then there's probably a coding error somewhere, somebody made a mistake.

So it shouldn't be the case that you ever really disagree on what the result of executing a set of transactions is.

So because the proposal doesn't include this, it doesn't preclude you from calculating as fast as you want.

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.

See all 0xResearch transcripts on Youtube

Monad: Unleashing Parallel Execution on the EVM