Bankless - Mega ETH vs Monad | Super Fast Ethereum
Episode Date: August 21, 2024Today we're talking EVM, specifically how Mega ETH and Monad are planning to make Ethereum SUPER fast. We answer: 1 - Which is faster, more decentralized, and more censorship-resistant? 2 - How did Mo...nad and MegaETH build large communities before even launching a testnet, let alone a mainnet? 3 - What are their thoughts on criticism that building with the EVM is like building on quicksand? Could this eat at Solana's value proposition? ------ 🌊 KELP | Deposit ETH with Gain today https://kelpdao.xyz/gain/?utm_source=Bankless ------ BANKLESS SPONSOR TOOLS: 🐙KRAKEN | MOST-TRUSTED CRYPTO EXCHANGE https://k.xyz/bankless-pod-q2 🦄UNISWAP | BROWSER EXTENSION https://bankless.cc/uniswap ⚖️ ARBITRUM | SCALING ETHEREUM https://bankless.cc/Arbitrum 🛞MANTLE | MODULAR LAYER 2 NETWORK https://bankless.cc/Mantle 🌐 OBOL | STAKE ON DVs, SCALE ETHEREUM https://bankless.cc/obol 🗣️TOKU | CRYPTO EMPLOYMENT https://bankless.cc/toku ------ ✨ Mint the episode on Zora ✨https://zora.co/collect/zora:0x0c294913a7596b427add7dcbd6d7bbfc7338d53f/54?referrer=0x077Fe9e96Aa9b20Bd36F1C6290f54F8717C5674E ------ TIMESTAMPS 00:00:00 Start 00:05:48 Intro To Monad 00:11:47 How Does Monad Fit Into Ethereum? 00:14:08 What is Mega ETH? 00:18:31 Similarites and Differences 00:21:38 Architectual Impact 00:28:58 Decentralization - Monad 00:34:56 Decentralization - Mega 00:39:43 Who's More Decentralized? 00:49:27 In Summary 00:57:24 Software Effeciency 01:06:50 Monolithic vs Modular 01:15:11 Community 01:28:37 Why Choose The EVM? 01:33:07 When Mainnet? ------ RESOURCES Lei Yang: https://x.com/yangl1996 Keone Hon: https://x.com/keoneHD ------ Not financial or tax advice. See our investment disclosures here: https://www.bankless.com/disclosures
Transcript
Discussion (0)
Welcome to Bankless, where we explore the frontier of internet money and internet finance.
And today on Bankless, we are exploring the frontier of the Ethereum virtual machine from two different architectures.
Two different blockchains are on the show today.
Monad representing the Layer 1 camp and Mega-Eath representing the Layer 2 camp.
Both are using the EVM and really turning the EVM up to 11 to see how far it can go,
but with very different paths to actually getting there.
on this episode we compare and contrast each of these respective blockchains with the respective founders of each of the respective blockchain.
So some of the topics that we talk about, which one is faster, which one is more decentralized,
which one is more censorship resistant, all of the technical properties that we enjoy talking about in the blockchain world.
Also, how did both Monad and Mega-Eath attract such large communities ahead of actually shipping a test net?
That's right, not a main net, a test net.
And then also, what do they think about Anatolese claim that building with these?
the EVM is building through quicksand.
What do they think about that?
And why, of all EVMs, do they choose to build on the EVM?
All of these and other topics as well.
Before we get into the episode, though,
a message from our friends and sponsors over at Kelpdao,
which just introduced Gain a new product to help you maximize your rewards on your ETH.
You can deposit ETH, R.S.Eth, or other LSTs into gain to access rewards
from multiple layer two networks, restaking platforms, and other DFI opportunities.
And for those who enjoy the Pendle games,
they're already live on Pendle, Balancer, and more.
But that's not all.
If you deposit into the gain vault, you also don't give up your liquidity.
You receive a G. ETH from Kelp to unlock multi-chain defy strategies.
There is a link in the show notes to getting started today.
Ryan, what do you think about this episode?
Yeah, I think it's a relevant topic.
You know, this discussion of, you know, whether Ethereum is going to find its way,
how it holds up to things that maybe the SVM, the Salana community is kind of kicking out, right,
with the fire dancer client.
And I think the super fast EVM, super fast Ethereum approach that both of these
respective teams are trying to build is kind of like one answer to that.
In particular, the most interesting part of the discussion was over this like decentralization
word, like which approach is more decentralized.
And of course, we all know that decentralization is just a means to an end.
It's about security.
It's about settlement assurances.
It's about censorship resistance.
But they've both taken a different.
architecture to that. One is a layer one, the other is a layer two. And so this was maybe the most
contentious part of this discussion when we asked the question of, okay, which approach is going
to lead to more decentralization? One element I feel like we didn't discuss, which is worth
more investigation is the concept of economic security as it relates to this. There's a lot of time
spent on kind of technical requirements to run a node in this conversation of,
what is a full node. We didn't talk as much about distribution of stake. And I think that's maybe
a follow-up conversation. Anyway, lots jam-packed in here. One disclaimer before we get in,
both David and I hold angel investments in Monad and nothing in Mega-Eath. There's always a link to
all disclosures at bankless.com slash disclosures. All right, guys, we're getting it right into the
episode. But before we do, we want to thank our friends over at Cracken. If you want a super fast
trading experience, go open a Cracken account and get started. If you want a crypto trading experience
backed by world-class security and award-winning support teams, then head over to Cracken, one of the
longest standing and most secure crypto platforms in the world. Cracken is on a journey to build a more
accessible, inclusive, and fair financial system, making it simple and secure for everyone,
everywhere to trade crypto. Cracken's intuitive trading tools are designed to grow with you,
empowering you to make your first or your hundredth trade in just a few clicks. And there's an award-winning
client support team available 24-7 to help you along the way, along with a whole range of educational
guides, articles, and videos. With products and features like Cracken Pro and Cracken NFT Marketplace and a
seamless app to bring it all together, it's really the perfect place to get your complete
crypto experience. So check out the simple, secure, and powerful way for everyone to trade
crypto, whether you're a complete beginner or a seasoned pro. Go to crackin.com slash banklists
to see what crypto can be. Not investment advice, crypto trading involves risk of loss.
The Uniswap Extension is here. The self-custody wallet.
created by the most trusted team in Defi, Uniswap Labs, designed to make swapping feel effortless.
This extension lives in your browser's sidebar, letting you swap, sign transactions, and send or receive crypto without ever losing your place on the internet.
Plus, with human readable transaction messages, you'll always know exactly what you're signing.
Navigate a multi-chain world effortlessly with support for 11 chains like Ethereum mainnet, base, arbitrum, and optimism.
No more chain switching or token importing. All your assets are right where you need them to be.
The Uniswap extension is designed to level up your swapping experience with other Uniswap Labs products as well.
Easily onboard to the extension using the Uniswob mobile wallet to begin managing your assets across platforms
and take advantage of smooth, seamless synergies with the Uniswap web app.
So go and download the Uniswap extension today by clicking the link in the show notes.
Just another way Uniswap is helping you swap smarter.
Launching a token?
Don't let complex legal and tax issues slow you down.
Toku provides specialized support to optimize your launch and ensure that you as a founder and your team and your investors
get the most tax-efficient outcomes.
The Toku team understands the crypto space inside and out
and will ensure your token launch is fully compliant
while maximizing tax efficiency.
Toku can connect you with the best attorneys if you need them
to make sure that you have the best advice
and Toku can help to optimize your taxes
so you pay the least possible amount of taxes
while still maintaining legal compliance.
With Toku's guidance, you can concentrate on building your company
while Toku handles the logistics.
Token launches don't have to be complicated.
Talk to Toku today to get a free initial token valuation.
Bankless Nation, super excited to introduce you
to Keone Hahn, the founder and CEO of Monad Labs, the creators of the Monad chain.
Keone, welcome to Bankless.
Hey, thank you so much for having me.
And we also have Lei Yang, the founder and CTO over at Mega-Eath.
Lay, also, welcome to Bankless.
Happy to be here.
Okay, so two brand new high-performance chains coming onto the scene,
both leveraging and juicing up the EVM to, I think, really see how far we can take the EVM.
different ways of actually using the EVM that I don't think we've seen be used in the Ethereum ecosystem or its layer 2s ever before.
And so this is kind of a new frontier for this tech stack that we call the EVM that I think we all want to explore a little bit here on the podcast today.
Let's go and take some time to introduce your guys' respective projects and really one of the key aspects, the key features of your guys' respective projects as it relates to the EVM.
I think Mega-Eath was, excuse me, I think Monad was founded.
first. So that means we'll start with Keone and then we'll go in with MegaEath second.
Keone, explain to us Monad and what is doing differently in the space of blockchains.
Yeah, thank you for having me. My name is Keoney Hahn, co-founder and CEO at Monad Labs.
We're building Monad, which is a reimagining of Ethereum from the ground up by redesigning both
execution and consensus layers to introduce four major improvements.
improvements and more generally deliver a really high-performance version of Ethereum,
offering over 10,000 transactions per second of throughput.
And Monad is doing that by introducing a completely new database that's built from scratch
called MonadDB by introducing optimistic parallel execution so that many transactions can be
executed in parallel by introducing asynchronous execution, where consensus and
execution, kind of run in separate swim lanes to massively raise the budget for execution.
And lastly, through Monad BFT, which is a really performant consensus mechanism that allows
hundreds of nodes that are fully globally distributed to stay in sync with each other.
So overall, it's an effort to go really low level and apply systems engineering techniques
to build a really performant reimagining of Ethereum.
One thing I want to bring up Keone about the way Monad works is I think there was a lot of excitement about Monad after the Solana virtual machine, Solana, and the parallelization of the SVM got everyone excited about parallelization.
And then there was like some technical pushback from very smart people who said it's actually not paralyzed execution.
That is really the bottleneck.
It's paralyzed read access of a database to which Keone of Monad said, well, we've also paid.
paralyzed our database too. And then everyone was like, wow, that's pretty sick. Can you kind of walk us
through that part of an architecture of a blockchain? Why is parallelization of a virtual
machine cool? But then also like how does it boil down to needing to have parallel read access to a
database, which you guys also have? Yeah, it's a great question. I think people kind of intuitively
understand that parallel execution is of some benefit because our modern computers clearly
have many processors and are running many tasks in parallel. I have hundreds of browsers tabs open.
It's kind of a bad habit, actually, but I have a whole bunch of different browser tabs,
Spotify, Discord, all these things going on in parallel.
And it's a little bit crazy right now that Ethereum and other EVM blockchains all are single-threaded and execute completely serially.
So parallel execution is the aspect of utilizing multiple threads or multiple processors on the host to run many pieces of work in parallel.
And that's one of the improvements that ultimately can unlock performance.
But when you do the benchmarking and when you look at what the real costs are, actually the single biggest bottleneck for execution is not that CPU time.
It's not like doing math or, you know, like executing individual instructions.
The actual biggest bottleneck is state access because every smart contract depends on some residual state that's associated with that contract.
For example, when you're making a uniswap swap, you need.
the balances of the two assets in the pool, say it's UniV2, you need to be able to look those up
in order to actually execute the swap and figure out what the new balances are. And that requires
reading some data from disk. So the biggest bottleneck for execution actually is state access,
and only parallelizing the computation without also parallelizing
reads to the database would be only a small improvement relative to the much bigger improvement
that could be made by also allowing the database to be parallel readable.
And that's exactly what our team has done with MonadDB, which is a completely from scratch
database that specifically optimized for the problem of storing the Ethereum-merkel tree
data really efficiently on disk.
It's been a big endeavor to build this database.
everyone always, you know, the common computer science advice is don't write your own database
because it's a big undertaking. But in this particular case, it's really needed and really impactful
because we have high value state, aka Ethereum state, we need to be able to access it as fast as
possible. Keone, one last question for you before we delay and the mega-eathe side of things.
And this goes to kind of the word choice you were using and the phrasing you're using of
you're talking about bringing this to Ethereum, this technology to Ethereum.
And so, like, my question to you is, like, what sense is that true and what sense is that not true?
So certainly you are bringing this to the EVM, let's say, which is a virtual machine that Ethereum uses.
But correct me if I'm wrong, Monad still plans to kind of launch its own alternative layer one.
So we maybe call that an alt-layer-1 in common parlance, not as a layer two.
and this gets to maybe one of the distinctions and differences.
So in what sense are you bringing this to Ethereum?
What sense are you not bringing this to Ethereum?
So you're not actually expanding Ethereum as a layer two.
You're not doing this in Maynet.
You're not doing this as an alternative chain to Ethereum.
Is that correct?
That's correct.
Monad is a vanguard environment for proving out the capabilities
of these different architectural improvements
that our team thinks ultimately are really needed
in Ethereum L1 as well.
I think at the end of the day,
the discourse around layer ones and layer twos
is one that's evolved over time.
And while when we first started in 2022,
there was very, very strong feeling of like,
layer twos that all interact with the theory
in the same way, utilizing Ethereum both for state commitments and for data availability.
You know, these are very, there's like this one pattern of how layer two interact with
Ethereum.
Now in 2024, that spectrum of sort of how layer two's interact with Ethereum and to what
extent they're utilizing the services of Ethereum directly has evolved as well.
And our team's belief is that there are many different ways to be contributing to Ethereum
overall, and by focusing on a completely orthogonal direction of Ethereum scaling research that we think
is really needed and wasn't being explored, we can also make a significant improvement,
a significant contribution to the Ethereum ecosystem overall.
Okay, Lay, it's your turn.
So let's talk about Mega-Eath, and same question you.
Could you just tell us, what's the project about?
And like, why are you here?
Why is Mega-Eath here?
Yeah, of course.
So, yeah, again, my name is Leigham, and I'm a CTO and co-founder of Mega-Eath.
So just graduated with my PhD from MIT, worked for six years on blockchain consensus,
and published a bunch of papers on security, performance, network aspects of blockchain.
So, and now building Meghaith.
So Mega-Eth is a performance-optimized blockchain with full Ethereum compatibility.
And I guess the key kind of differentiation here is,
is that we are kind of unapologetically performance-oriented,
and we're single-mindedly performance-oriented,
and how that materializes, right?
So first we choose to be an Ethereum layer two,
and the reason is really that we think it's kind of the only optimal architecture
for performance engineering,
and we are really exploiting the architecture of being a layer two
by building what we call the first real-time blockchain.
So in other words, up to more than 100,000 transactions per second,
real Ethereum transactions, not just payments,
a block time of 1 to 10 milliseconds.
So that's what we want to kind of achieve is really for DAPs to be kind of as responsive
and as feature and logic reach as your normal VAP2 applications,
while also giving all the users the same benefit that they expect from a DAP,
that is correctness of execution, freedom of censorship, etc.
Right?
So a few kind of detailed technical optimizations.
So first, being a layer two allows us something called note specialization
in the sense that in mega-eith, we try to cut down the redundancy of execution as much as possible,
to the degree that there's only one active sequencer at any given point
working on executing every single chain action.
And all the other nodes, while they subscribe to the state updates,
while they try to keep up to date with the current blockchain status,
they do not need to execute all of the transactions.
And basically, that allows us to really jack up the performance
and jack up the hardware configuration of the sequencer,
which is executing all the transactions,
and also maintaining the hardware requirement of the full nodes
who are only interested in getting the current state.
And on the sequencer side, we have a few optimizations,
including a new data structure that is feature-wise being the same as the Mercco-Patricia tree,
but being much more efficient in terms of utilizing the actual hardware like SSDs and memory.
We are going to compile in real-time the Ethereum smart contracts from bytecodes
down to native assembly codes, down to native instructions.
And we are also paralyzing the execution of the eBM.
So, yeah, these are some highlights.
And yeah, and we call the end product a real-time blockchain.
Lay, I'm curious that you heard Keone's description of Monad, right?
So I'm curious your perspective on kind of similarities and differences, right?
And maybe for kind of the layman who's sort of approaching this,
the layman, let's call them a crypto-native. So obviously a similarity that probably stuck out is you're both
looking to scale the EVM and parallelize execution. So that's ding-d-ding, that's a similarity. Okay. And then a
difference that I think we've heard from both these projects is Megheath is using the layer two architecture.
So it's settling to Ethereum. It's using Ethereum for data availability, I would imagine. So is that, is that correct?
Actually, that's not correct.
So we settle down to, I mean, we use eigen layer as the data very big layer, but also we settle down to Ethereum.
But also, a small nuance here is that we are not, I mean, pushing, I mean, paralyization as kind of the flagship feature or the flagship optimization.
We value single-threaded performance as much as paralyzation.
Ah, okay.
Well, then why don't you put it in your words?
So what are the similarities and differences between the projects and your words?
I think you summarized the similarities very well.
The same focus on performance and trying to kind of bring in the next generation of apps
by giving them abundance of resources.
But I think the difference here first, as I mentioned,
kind of a different angle, I would say, towards parallelization.
Because we...
So my heart take is that actually if you want to build, say,
If you want, say, 100 copies of uniswap, there's enough block space in EVM and the Ethereum ecosystem for you to do that.
But what we actually need is brand new applications.
And for these applications, our belief is that you have to get to a degree of really high single-threaded performance,
because that is the actual performance that a single individual application can use at the same time.
So, yeah.
So in other words, we're kind of really pushing.
the frontier of single-threaded performance.
The kind of the optimizations I mentioned,
like the new data structure,
the JIT compilation of smart contracts,
and also this in-memory computation technique
that I didn't mention,
they are all for single-threaded performance.
While parallelization,
we viewed it as kind of a second step
to push for after we got to a high enough
single-threated performance
to enable brand new applications,
although engineering and operation-wise,
we're doing the two at the same time.
Another is, I would say,
kind of a sharp focus on performance.
We build a layer two by choice
because we believe that it's the only optimal architecture
for performance that enables you
to really eliminate as much redundancy
in terms of execution, in terms of consensus
in the blockchain as possible.
So I think that's a key difference that I'm to highlight.
Keone, was there anything that Lay just said that sparked anything in you?
I think one thing to mention is that Monad's goal and these individual architectural improvements that Monad is working on are designed to get the maximum performance out of the minimal hardware requirements.
I think it's really important from the perspective of decentralization that anyone be able to run a node with commodity hardware.
and in order for that to be possible, we need to make software improvements that get more performance out of the hardware rather than strictly relying on really high hardware requirements.
So I think that fundamentally the two projects are probably just very different in the outset from the initial premise, which is like in Monad, we're just really focused on getting the most performance out of hardware so that anyone can run a full node and have access to all of this state.
and keep up with the network and not have to trust,
but instead just verify directly.
There's something really interesting about having both of you guys on in the same podcast,
which is why we wanted to do this podcast,
where you guys have the same goals, which is a very fast EVM.
But the way that you guys have gotten there are almost polar opposites towards each other,
whereas Mega-Eath is going for the layer two single sequencer
or very low number of sequencer routes.
And Monad is going for a layer one blockchain with a very wide distributor, a validator set.
And then technically speaking under the hood, you guys have architecture to match these end desires.
I'm wondering, since the end goal, it's the same, which is having a very fast EVM,
does, do you think that the apps that will manifest on each one of your guys' respective blockchains will also kind of be the same?
or do you think each one will kind of have an ecosystem that will emerge differently because of the underlying architecture?
I guess the question is, how does the underlying architecture, how do you think it will impact the application landscape that comes to be built on top of each respective blockchain?
Or maybe it does not do that.
Lay, let's start with you.
Okay, so I think it would be very different because, I mean, first we are, as I mentioned, we're single-mindedly focused on performance.
So that actually allows us to reach a much lower latency,
and I would say higher throughput as well for our system.
And I really want to highlight the latency part
because exactly, as you mentioned,
we use a single sequencer at the same time.
So the sequencer can just execute the transactions
in a stream fashion,
and it really minimizes the kind of the weight time
and this block packaging time for transactions to get their feedback.
In other words, we expect the transactions.
the kind of the turnaround for an transaction from its arriving at the sequencer to it being
executed and packaged and the state being updated is one millisecond.
So I would say to me, at least from my background of consensus research, this is not possible
for any system where a consensus algorithm sits in the critical path of the system.
Because for a consensus argument to really function, a message has to travel at least across
all of the nodes. And if they're globally distributed, then it means that it has to fly around the
world. Although at almost light speed, it still takes several hundred milliseconds. And even,
not to mention that, usually you need at these two or three rounds of messaging to do that. So that
goes to maybe six to seven hundred milliseconds. And that is your minimum latency for a layer one or
even a layer two with kind of a decentralized sequencer using a consensus-based approach. So
This low latency, I think, would be really useful for some applications.
For example, imagine like on-chain Minecraft, right?
You do not want your avatar to kind of take a 600,
six-minute, sorry, 600 millisecond weights before it can take the next move.
And for really high-frequency trading, I think it would be very interesting
because actually the market makers and the traders can actually choose to co-locate with our sequencer.
So these kind of real-time applications, I think, would be our unique ecosystem projects.
Yeah. Keone, same question to you, yeah.
Oh, yeah.
Wondering about the decentralized Minecraft situation, because that's only going to be low latency
if you happen to be close to where the sequencer is.
Yes, of course.
So I would like to distinguish two parameters.
One is the tick time or the block time.
In other words, the fidelity or the resolution of the movements.
Like every one millisecond a movement can happen.
But for the user to actually get feedback, of course, we are not really breaking physics here.
So the user has to kind of the action has to travel from the keyboard of the user to the sequencer back to the user's display.
However, that is already happening with any kind of online, I mean, MMO, RPG games.
So actually that part of latency is fine.
What really matters is if you bring in consensus into a critical path, you have this three-round, I mean, three messages around the globe situation, and that's 600-plus milliseconds, which is much higher than the typical latency, I mean, the raw network latency from the user to a centralized sequencer.
Keone, what's your attitude or belief about the way that the application ecosystem will come to be born on top of Monad?
Is there any differences or any things that you guys are focusing on specifically?
I think the beauty of the EVM is that it is really this dominant standard that has incredible network effects.
There are so many libraries that are built for the EVM, there's so many applications, there's a lot of applied cryptography research, all being done in the context of the EVM.
And so being fully bytecode EVM equivalent, Monad offers developers who are already building with
the EVM, the best of both worlds between performance and portability. And Monad continues to do that
while preserving decentralization, which I think, yeah, fundamentally will just be like,
you know, a bit of a crossroads between Monad and Mega-Eath in the sense that our team just
thinks it's really important to have decentralized block production from the perspective
of censorship resistance and, you know, all these other properties that
the crypto community has grown to cherish and deeply value, it's really important to preserve
that full consensus, even if, you know, there is an overhead from consensus that lay, as you
said, is literally inevitable due to speed of light, unless we can find a way to speed up the
speed of light. Maybe said differently, Keone, if I'm understanding you correctly, you're kind of
saying that there is like a certain level of responsibility that one has when one builds a layer
one because of the ethos of crypto that comes alongside with it. So like what's the point of building
a layer one if you don't have censorship resistance? What's the point of being building a layer one
if you can't like meaningfully decentralize your validator set? And so in addition to having some of
the very strong architecture improvements from the Monad EVM and the Monad DB, you also have to do kind of like
you have to do all the things that are required in order to call yourself like a legitimate
blockchain effort, which is like all the things that we value as like the crypto industry.
Is that kind of what you're saying?
Yeah, that's right.
It's, you know, it really comes from the social layer as well that's enforcing these values.
Decentralization is important from a hardware requirements perspective, from a number of nodes,
participating in consensus perspective, you know, from a stakeweight distribution. So these are all
properties that have to be evaluated for any network. And beyond that, there also needs to be a
really strong social layer that reinforces those values. Can we get into that? Maybe that's a good
jumping off topic. I was going to ask another question, but since you brought it up,
the D-word decentralization, this is sort of a sacred word in crypto. And
I imagine Lay would be saying something similar. A, the reason we're deploying as a layer two is
because of this word decentralization and censorship resistance. So can you kind of like maybe
start by talking about the monad position with respect to decentralization? Because I think this
will be sort of counterintuitive to an Ethereum audience. It's just like, hey, if you're going to
try to maximize decentralization, why wouldn't you be a layer two rather than a layer one? And
it appears like you are arguing the opposite, right?
So I think for a typical, like Ethereum, their perspective is that, okay, Ethereum has had
many years of tested, blindy effect, decentralization.
Like, that's the thing that it's best at, right?
It's like not very good as an execution environment.
You know, 10 to 15 transactions per second kind of sucks at a lot of things.
But one thing it gets right is almost near Bitcoin level or maybe even better than Bitcoin.
I said it.
Decentralization properties.
right? And so why forsake all of that and move to a layer one? Yet you were saying your design choices
in Monad are optimizing for decentralization. So maybe first talk about how you view the word
decentralization and why the architecture kind of like promotes that for Monad and then I'd love to get
laid away in as well. Sure thing. I think the first thing to point out is that for any
for any choice of sort of network parameters, there's, you know, we should strive to get the maximum performance from that.
So if we have a network with 10,000 nodes that are fully globally distributed, where the hardware requirement is, you know, a particular level of requirement, I think in the case of Ethereum, it's the,
and it's a bit of a meme, but I'll say it anyway.
You have to be able to run it on a Raspberry Pi.
So like certain hardware requirements, certain number of nodes,
then we should strive to get the maximum performance out of that requirement.
And if, you know, the requirement is a little bit higher,
but still like very reasonable.
So in the case of Monad, 32 gigs of RAM, a 2 terabyte SSD,
100 megabits of bandwidth,
and a pretty cheap CPU, we should try to get as much performance out of that level of hardware and that network setup.
Oh, sorry, I forgot to also say a number of nodes.
So two to 300 nodes participating in consensus that are fully globally distributed.
For that parameter set, like, we should try to get the most performance out of that.
And by the way, is that hypothetical or is that the exact number set?
basically this specification.
So basically is that, that's kind of like a consumer grid laptop.
Like, you know, like MacBook Pro, sort of what you described.
And like sort of a, you know, broadband, typical broadband consumer internet connection is sort of the hardware requirement.
And then 200 to 300 nodes.
Yeah, it's a laptop you could get at Costco.
Okay.
And you think that this is, and is this decentralized enough or is it as decentralized as Ethereum?
or how would you even kind of like have that like conversation or would you include other actors in the in the space as well?
Because of course it's not just the nodes, the validators, there are there actors with respect to how a block is created, block builders at such.
There's an entire supply chain around this.
Anyway, how like would you say that Monad's design parameters are going to be more decentralized than Ethereum or, yeah, how would you even have that conversation?
Right. So I think the thing that I was getting at is for a given set of parameters, we should strive to get the most performance out of that setup as possible. And the only way you can get maximum performance is through software improvements. So the improvements that our team is pioneering within Monad with this particular configuration, some of those improvements will make an improvement to a different setup that, you know, more like,
it theory mel1 right now where there are 10,000 nodes. It's like literally a different number of nodes,
and the hardware requirement is a little bit different. It's still a benefit to have this new database.
Like the new database isn't designed for a specific SSD size. Like it works for any SSD size.
So at the end of the day, it's really just about getting max performance with very reasonable hardware
requirements. And so my point is that if you constrain the network to like only having one node,
really, then, and you don't constrain the hardware requirements at all, or you allow really
high RAM, like there are going to be potentially some different performance characteristics that
you could get from that, maybe even just for free, just from like not having to go to SSD,
like keeping all of the state in memory. So at the end of the
day it is like no matter what the job of the team that's doing the engineering work should be to get
the maximum performance out of any kind of hardware setup. But like everyone always chooses one
particular sort of starting point for the hardware and then gets the most out of it. And our view is
that this is a really good anchor point where the hardware is still very reasonable and we can get
a lot of performance out of it. Lay, what's your take on the D-WR decentralization? What's
let's Mega-Eth's position on it, either similar or in contrast to what we were just hearing.
Of course.
So I would like to first address this kind of performance per hardware unit, if I may, point.
So of course, Mega-Eth is also working to maximize the performance per hardware unit
or per per gigabyte of RAM per CPU core per, per gigahertz of CPU frequency, right?
So, but also, so basically all of our optimizations can be, can be kind of neglected if we can just jack up the hardware configuration to the infinity, right?
But unfortunately, there is no such hardware that has an infinite number of CPU cores and infinite amount of memory.
Actually, it's, so actually, it's also the limitation of even the latest generation, the top, the top of the line server hardware that requires us to also do,
hard engineering work to really maximize the efficiency.
The word, that's the word it should be the efficiency,
the kind of the performance per unit,
like compilation, like in the new data structure, right?
So back to decentralization.
So the point here is that actually we also have lightweight nodes.
So our full node has 8 to 6 gigabyte of memory,
terabytes of SSD, but not the server grade,
just the consumer grade,
4 to 8 cores of CPU.
So it's kind of relatively the same order of magnitude of configuration,
like Ethereum execution nodes and the S-Moddunate nodes.
But the key difference, the reason, I mean,
the real highlight here is that the sequencer has to shoulder most of the work
by executing all of the transactions,
but BN layer 2 allows us to,
kind of maintain the hardware requirement for the full nodes who are interested in getting
the latest states, the entire native states.
So that actually boosts decentralization by being a layer two.
And also have verifier nodes who literally can run off and raspberry pipe, no storage,
and just obtains the states needed for verification and also the transactions needed
for verification from a network on the fly.
and just kind of verify the blockchain at kind of bite size, right?
So actually, so we value decentralization a lot,
and note specialization is our answer to kind of,
I mean, Q&A's observation that, yes,
if you require everyone to use really beefy hardware,
then there's no decentralization to start with
because no one can afford a server and no one wants a server humming.
I literally have a server next to my desk, and it's noisy as hell when I do an upgrade,
or when I do I reboot, reboot, and no one wants that at their home.
So we are really conscious about that, and no specialization is our answer.
Wait, wait, is note specialization just basically L1 and L2?
Is that kind of like...
No, no, no.
So it's basically you have different kinds of nodes of different hardware configuration doing different job
within and layer two system.
So you have sequencer executing all the transactions.
You have full nodes subscribing to the state updates,
and you have verifiers who statelessly verify the chain state.
But on the topic of decentralization,
so although we are really conscious about it
by really minimizing the hardware configuration
for full nodes and verify nodes,
we actually believe that decentralization is just means to an end.
What you want is, I would say,
correctness of execution, you want finality, you want censorship tolerance. I don't think
anyone, I mean, most important people coming from VAP2 to look for something called
decentralization when they enter the crypto space. I think what they want is assurance of
correctness. They want to not to trust any single entity to run their important applications.
And decentralization, as we saw, which worked really well for layer ones, is that you're
just one mean to an end. And now that a layer one has been built, which is Ethereum,
with really as much decentralization as one can ask, I would say. We think it's time to move on.
So Ethereum has done the decentralization part for us. And now it's time for us to really
optimize for performance piggybacking on the decentralization that Ethereum has achieved.
Do we get to have one of those back-and-forth conversations of like, you know, let's not use the word
decentralization, but let's use it as a proxy for all of the properties you just mentioned,
which is like censorship resistance, settlement assurances, all of these things, right?
It's like we understand decentralization is just a means to the end. But I think what listeners
want to know is, okay, which of your super fast performant EVMs are more decentralized?
So is it mega-eath or is it mod-ad? I, you know, what's your answer to that, Lay? And then we'll go
to Keone.
Also, how do we even think about that?
How do we even understand that question?
Yeah, very good point.
Very good point.
So we can try a few different angles, like hardware configuration, which I mentioned.
The full nodes and the verifiers from mega-eith are on the same magnitude of, same order
of magnitude of hardware configuration as Ethereum and the modan nodes that is for full-nodes,
mega-eith.
And verifiers literally rest of your pie grade and just downloads the eith.
information of the wire as needed.
So that is hardware configurations, right?
So I mean, the takeaway is that you do not need anything that is beefier than your existing
Ethereum execution nodes to download the latest and also maintain the latest megaeth state.
In terms of the number of nodes, yeah, go ahead.
Sorry, sorry, it was just you keep calling them full nodes, but I mean, are they
Like, is that an abusive terminology at all?
Because I think pretty much everyone else in the blockchain space uses full node to mean a node that executes all the transactions, like verifies the correctness of the outcome of those transactions.
And I think what you're referring to when you say full node is like something kind of different.
Yeah, I can answer that question.
So if you go to, say, Ethereum's website and there's instructions for syncing up a full node,
and actually the default option is, I forgot it's called SnapSync or Fast Sync.
I think they change the terminology a lot.
But basically, the default is one that just downloads the latest snapshot of the state,
and such a node does not really verify the transactions before kind of start to serve you the state,
which is downloaded, right?
because the logic study just downloads the latest copy of the state and then starts working.
And then probably it will optionally verify the backlog, but it may not do so.
So my point or our understanding, I think it's important that we bring this up,
but our understanding of a full node is one that maintains and keeps track of the latest blockchain state.
Yeah, so that's our understanding.
And of course, the terminology is upward debate.
And it would be great if the industry can agree on the same set of terminologies.
We've been arguing on what's a full node since the Bitcoin versus the theory.
It's where I started.
I'll ever be fully answered.
Keone, how would you define, how does your idea of a full node differ from Lays?
Yeah, why'd you bring that up?
What's your thinking there?
Yeah, well, I mean, I think if you are running a,
a node of some sort and it's not, you know, it has to trust a centralized party, then it's not very good, right?
Like the whole point of blockchain is that we don't have to trust. We could just verify.
And so that's, you know, whether we call it a full node or not. I mean, I'm calling out the
use of the terminology full node in the sense that like it's being compared to like other things.
But I think what we really care about is, you know, if I'm a, you know, a small business owner and I'm accepting payments and, you know, someone sends me a payment and I let, you know, the person like walk out of the store with like, I don't know, a laptop or a diamond ring or a Tesla or something, like I need to be able to know that that payment actually went through.
And so the whole premise in my mind of blockchain is that, you know, that small business owner could actually literally just run a node.
And when they see that payment, they verify that it actually happened.
And they know that they're not just trusting like a single centralized intermediary.
So that's really the nature of my question.
I guess I don't care whether you're calling it full note or not, really.
But I really care about the question of knowing for sure rather than just having to trust your single centralized sequencer.
Yep. So I think you mentioned that don't trust verify, right? So if I may, I want to kind of append the following to it. So basically, don't trust verify. But even better, let someone else verify it for you, which is the case of roll-ups, both optimistic and ZK roll-ups. So in the particular case that you mentioned, right, I'm the seller of a laptop. Someone paid me on mega-eath, say, $5,000. And I'm deciding whether I should hand over.
the laptop. So the thing here is the sequencer, the single sequencer, yes, at the moment,
we are trusting the single sequencer to correctly order the transaction and to execute the
transaction. But the important thing here is that the single sequencer is under kind of a social and
economic contract. So I think the debate is really about crypto economic security. So imagine that,
Because the thing is that if the sequencer ever cheats in the sense of retracting,
I mean, excluding the transaction or just giving me an incorrect balance update,
every piece of information that the sequencer told me when I was deciding whether to hand over the laptop
was signed by the sequencer.
And if the sequencer did any shenan here, this is kind of a proof that we'll get the sequencer slashed.
So yes, the sequencer may lie to me, but the sequencer has to probably lose
if that is worth maybe a thousand Teslas or a thousand laptops, which is kind of not worth it,
right?
I mean, yeah, I think this really boils down to crypto economic security.
And, I mean, being a project in the Ethereum ecosystem, I myself got from, so I started working,
I started my research in blockchain from proof.
of work. I think it's beautiful. But then I got to know kind of proof of stake and a
cryptonomic security mode, more importantly, day by day, and I think it really, it really works.
New projects are coming online to the Mantle Layer 2 every single week. Why is this happening?
Maybe it's because Mantle has been on the frontier of Layer 2 design architecture since it
first started building Mantle DA powered by technology from EigenDA. Maybe it's because users are coming
onto the mantle layer 2 to capture some of the highest yields available in Defy and to automatically receive
the points and tokens being accrued by the $3 billion
Mantle Treasury in the Mantle reward station.
Maybe it's because the Mantle team is one of the most
helpful teams to build with, giving you grants,
liquidity support, and venture partners
to help bootstrap your Mantle application.
Maybe it's all of these reasons all put together.
So if you're a dev and you want to build
on one of the best foundations in crypto,
or your user looking to claim some ownership
on Mantle's Defi apps, click the link in the show notes,
so getting started with Mantle.
The Obol Collective is up and running
and is maybe one of the most important collectives
that you've never heard of.
OBLE is bringing distributed validators, or DVs,
to the Ethereum staking stack.
Distributed validators allow multiple parties of people
running multiple nodes to create a single virtual
Ethereum validator.
Together, this makes participating in Ethereum consensus
more accessible, more affordable, and more inclusive.
It is a strict improvement to the Ethereum staking tech stack.
With collaboration from Lido, Etherfi, EigenLayer,
and 50 other entities and thousands of individuals,
the Obal Collective is working to scale
and decentralize Ethereum using DEPA.
And now you can get involved, introducing the OBLE contributions program.
Visit OBLE.org slash bankless to stake on DVs, either through a partner staking protocol
or at home.
Earn access to future governance and ownership in OBLE while contributing to retroactive
funding for projects that are actively decentralizing Ethereum.
This is your opportunity to secure inclusion in one of the most important projects
working to scale Ethereum's foundation for future growth.
Visit obel.org slash bankless to get started.
That's OBO.O.L.org slash bankless.
Arbitrum is the leading Ethereum scaling solution that is home to hundreds of decentralized applications.
Arbitrum's technology allows you to interact with Ethereum at scale with low fees and faster transactions.
Arbitrum has the leading defy ecosystem, strong infrastructure options, flourishing NFTs, and is quickly
becoming the web-free gaming hub.
Explore the ecosystem at portal.arbitrum.com.
Are you looking to permissionlessly launch your own Arbitrum orbit chain?
Arbitrum orbit allows anyone to utilize Arbitrum's secure scaling technology to build your own
orbit chain, giving you access to interoperable, customizable permissions with dedicated throughput.
Whether you are a developer, an enterprise, or a user, Arbitrum orbit lets you take your project
to new heights. All of these technologies leverage the security and decentralization of
Ethereum. Experience Web3 development the way it was always meant to be, secure, fast, cheap, and
friction-free. Visit arbitram.io and get your journey started in one of the largest Ethereum
communities. Can I try and summarize the bit of conversation that we've been up to so far, just
so I can make sure that I'm kind of keeping up with the issues.
And I agree with you, Keone, like my definition of a full node,
and I think the consensus definition of a full node in Ethereum land, at least,
is that, like, I am a listener of the blockchain.
I'm keeping a copy of the ledger,
but I'm also doing my duty of verifying the validity of incoming transactions
and incoming blocks.
And so sometimes maybe a block comes to me and it's invalid,
and I reject it, and I start listening for a different block coming from someone else.
and I don't actually just automatically accept that invalid block.
I actually do my role of making sure that I'm adding only valid blocks with only valid
transactions to the blockchain.
And this is how, if everyone is doing this role, this is how blockchain's preserve decentralization
while also having correctness.
And so what you're saying is that if you're just listening to a trusted source of these
blocks, a single centralized sequencer, that actually is less of a role of what a full
node does because if you're just automatically trusting the validity of these blocks as a full node,
that makes you like less of a full mode. I think that was the point of contention that you brought up.
And then Lays response is like, well, if the sequencer is signing transactions and there's
an economic bond that would result in the sequencer getting slashed a very large amount,
then we are perhaps not the same full node as I was describing earlier, but there is a large
amount of economic security here, and that's our new trust assumption.
Has that's been the conversation so far?
Yep.
And yeah, exactly.
And I would say, I think the type of note that you mentioned is kind of a combo of a full
node and also a validator in Ethereum terminology, because usually people don't expect a full
node to really sign, I mean, mine blocks.
You have to be also staking.
In other words, if a node does not stake, should it be called a full node?
I think so.
So I think kind of the type of the type of note that you mentioned is kind of something that's much more than a full known.
Sorry, so just to verify, you said when, or lay, you said that when, or if the sequencer were to, like, post an invalid state route.
Like, is there, like, how would they get slashed?
Right.
So it's basically standard optimistic and ZK proofs.
So the way it works is that the sequencer, by posting the state updates,
kind of accountable proof that the sequencing has set something like this,
which is incorrect, right?
So later, these transactions, the block,
they are going to be posted to eigenDA and the state route posted to Ethereum.
And for optimistic proof, there are usually seven days for verifiers,
which I meant, the vegetable price, to come and re-execute those transactions.
So importantly, people in mega-eith, they do re-execute transactions.
The important thing is that an individual node does not need to re-execute every transaction.
So this makes them lightweight.
But again, people re-execute every single transaction collectively.
So if they find anything that is incorrect, they submit something called a fraud proof
or an optimistic proof to.
to the Ethereum smart contract, which slashes the sequencer automatically.
And in the case of the ZK proof, it's even simpler.
Basically, the sequencer is responsible for kind of proving the state transitions in real time
before in the future, before even it posts the state updates.
So, yeah, that's how we verify the state routes.
I mean, also, nothing exotic here.
This is all standard layer two fair.
Yeah, exactly, exactly.
Yeah.
Yeah, this is not anything different about MegaEath.
This is just layer 2 101.
Yeah, if I miscommunicated, I'm sorry.
But as I mentioned in the beginning, it's just standard OPE and ZK roll-ups.
But just to verify, those are two different mechanisms.
So which, have you guys decided which one you're going to use?
Yeah, we're using optimistic proofs for now.
Yeah, because we believe that the ZK proof is not kind of efficient enough as of this point for our level of
throughput. Oh, I see. Okay, but you were just mentioning ZK as like a future maybe possibility.
Yeah, exactly. I was trying to kind of just introduce the kind of validity proofs on a high level.
Okay, yeah, that makes sense. But then for the optimistic, like for other people to verify,
they'd also have to have a lot of RAM. And that is incorrect because I think I mentioned repeatedly
that the verifier only needs to be as beefy as a Raspberry Pi. So the secret sauce here is something called
stateless verification. So again, disclaimer, we didn't come up with this idea. So it roots from
Ethereum's stateless client discussion, I think, a few years ago. But we are basically adapting
the technology. Keone, I'm curious your take on this. So it's this line of discussion around
full notes and everything we just talked about started with the prompt, the prompt of,
okay, Le, who's more decentralized? And again, we're using that.
as a proxy for many things, censorship resistance, all of these features that make blockchain special.
So I want to turn that same question to you. How do you think about that question? Like,
which is more decentralized? What's the path to getting there? For me, decentralization means
that anyone can run a full node. And by full node, I mean a node that has access to all the state
and that executes all the transactions.
So Monad is pioneering these different architectural improvements
so that anyone could, without raising their hardware requirements,
very much run a node and keep up with the tip of the chain,
execute all the transactions, and have access to the full state.
I think that's really important to decentralization.
I think that there are other architectures,
which trade like some aspects of decentralization and censorship resistance for, you know, being able to move execution off of the layer one.
And that's interesting.
I think there's a lot of merit there.
But I think from the perspective of having a system with, I mentioned before, a couple hundred nodes participating in consensus,
But even more than that, like thousands or tens of thousands of full nodes that have access to that full state, it's just really important that node requirements be reasonable.
And then downstream, that also has an effect on kind of the economics of the blockchain.
I know this is kind of a hot topic, but in blockchains where the hardware requirements are really substantial, it means that the cost to run a node is quite high, which then,
it has a centralizing effect as well.
And, you know, we see that with some other high performance blockchains that have really high
hardware requirements, that it's just not economical for a small staker to actually run a node
because it would just be too expensive if it's like $10,000 a year or something to run a node.
So I think that efficiency, you know, efficiency matters and efficiency has knock-on effects.
And it's just really important to have really high software efficiency
so that we can have the most decentralized network possible.
Going back to something that you said about Monad Keone,
about software efficiency is that just like one transaction
should cost the least amount of just like total compute
from all of the nodes around the world as possible.
And I think that's kind of like where you're spawning efficiency from.
Can you talk about those like knock on effects?
Like if you are optimizing for reducing the total compute cost of planet Earth
to run the Monad blockchain, what does Monad get out of that?
that. What's the juice that you can squeeze from that feature?
So just to mention one thing, like, I think it's, I think it was actually Lay that was saying
that, like, efficiency means, like, the least amount of compute expended to do something.
But, you know, like, that's, that comes from, like, having one sequencer that does it.
So, yeah, like, in the Monad network, if one reduced the number of nodes participating in
consensus, there would be less, I guess, like in some sense, electricity expended for that.
But that's not, that's not totally like the metric that our team is optimizing for.
Like, we just want per unit of verification, like per full node, that cost to be as low as
possible.
So that then it is as cheap as possible to run a full note and keep up with this entire global
state that's progressing through time.
So just wanted to clarify that.
Sure.
Maybe I'm missing something about the way Mega-Eath runs.
I'm going to make an assumption here and, yay, like, shake your head violently if I'm wrong.
But like since the whole idea about like Mega-Eath is that it goes really, really fast.
Like we're centralizing all the compute.
We're centraling all the resources in order to have like this real-time server that like people ping and it goes really, really fast.
And then in contrast to that, Monad is like a layer one blockchain with consensus.
and like individual like hopefully solo stakers.
And because of that architecture, like in full nodes,
people who aren't staking but are still listening to the blockchain can keep up with
the monad blockchain because, you know,
the stakers have to be meaningfully decentralized and that means you have to reduce
the hardware requirements from these stakers.
Is your claim, Keone, that like because of like the more centralized sequencer
that that Mega-Eat has, that like it has like a lesser claim on decentralization,
and censorship resistance in comparison to monad?
Is like a statement that you would agree with?
Yeah, that's a statement I agree with.
Because of, and my logic is sound there, right?
Like, because you guys have individual solo-stakers,
you can therefore also have individual full nodes,
and then you have, like, kind of the complete blockchain stack
to preserve, like, decentralization,
incredible neutrality and censorship resistance.
Yep.
Yeah.
Le, how would you respond to that?
So I think it's important to,
realize that we anchor our kind of finality, the correctness, and censorship resistance on
Ethereum. So instead of hundreds of nodes, there are 10th of thousands of nodes that are
kind of backing that powering the censorship tolerance guarantees. So by that definition, by the
particular definition that you stated, I would say mega-if is more decentralized. So I'm personally,
I'm against kind of comparing decentralization of two products, like without really clearing
defining it, but in the way that you defined it, in terms of the number of nodes that
provides the final guarantee of finality, correctness, and censorship tolerance, then I think
it is objectively true that mega-eve is more decentralized.
Okay, cool.
Because again, we're kind of cheating here, right?
Because we built on Ethereum, but that's exactly, there's a conscious choice.
Keone, do you have a response to this?
I mean, this entire podcast quite clearly was just to bait you guys in the question of arguing
over who's more decentralized.
Let's just like put that right out there.
what would you say? What's kind of the monad claim on decentralization? How would you dispute
what was just said there? I think it's important to be progressing toward, well, yeah, maybe just
to take a step back, you know, in Ethereum L1 land, there's discussion right now about, you know,
what improvements can we make to Ethereum itself to raise
the execution throughput of Ethereum from 15 transactions per second,
you know,
aka 1.5 million gas per second to something higher.
And it's frustrating when there's the gas spikes on L1.
And yeah, I just think that ultimately
Ethereum, like, it's of merit for Ethereum to become more performant.
It's of merit to introduce software improvements that make Ethereum more powerful.
And so that's sort of like the most fundamental guiding principle in how our team was designing Monad was to make individual architectural improvements that might actually be something that could slot into Ethereum L1 itself.
So I think that, you know, if we're going to sort of fall back on like, well, it, it uses Ethereum for some elements.
And not for DA also, by the way, but like using Ethereum for like settlement.
Like I guess I would say all layer twos kind of can make that same claim of like we are quote unquote more decentralized as a Monad because we're all like using Ethereum directly for.
settlement. And I would just say, like, on the opposite side of the diagram, it's just like,
you know, Monad is trying to introduce tech that makes Ethereum more performant without
requiring more hardware, which I think is good. And then second of all, it's just that,
that kind of is like a more uniquely differentiated. That is a uniquely differentiated direction that
I hope will be helpful to the overall effort to improve the impact of decentralized systems.
Yeah, I think we can definitely agree that we're all contributing tech to the Ethereum ecosystem.
But I think one small point, I think in terms of overall hardware consumption,
so if we define the overall hardware kind of consumption of two chains as kind of the number of,
the amount of dollars that you need to buy servers and nodes,
to kind of let the system produce blocks correctly, right?
Then for Mega-Eaf is, so for Mega-Eaf is one sequencer,
and for Monad, it's several hundred of the full-notes.
So I'm personally not sure if it's more kind of expensive to operate
and to purchase one, like, beefy sequencer,
probably thousands of dollars versus hundreds of like Funos,
I mean, Costco laptops.
So just one small point.
But overall, yeah, definitely.
Yeah, I mean, that's kind of a,
puzzling line of argument for me, though, because, you know, if the monad network were only
two nodes instead of hundreds, then it would be lower cost. And from that perspective, from that
metric, it would. Yeah, exactly. But then the censorship tolerance and the finality, the correctness
of execution of such a hypothetical and monot system will be lingering on, we'll be leaning on
these two monot nodes, while for mega-eith, it's still,
10th of thousands of Ethereum nodes.
I think that's kind of an important difference.
But I think you mentioned something that's very important,
which is all layer two's,
all Ethereum layer twos can claim so,
which we definitely agree.
And again,
we build that layer two by choice, yes.
One thing I wanted to ask about actually,
because you keep mentioning censorship tolerance,
and you're choosing your words pretty carefully,
which I think is interesting,
because you didn't say censorship resistance,
you said censorship tolerance.
Is there a difference there?
Oh, so I, yeah, I usually use the two words interchangeably.
I think the key difference here is whether you want like real-time censorship tolerance
or you want like eventual or, I mean, censorship tolerance with a bounded latency.
So by, so MAGA-If is offering the kind of censorship tolerance with a bounded latency
by allowing those to post their kind of censored transactions,
directly to Ethereum, which guarantees inclusion and then forces the layer, I mean, forces the
sequencer to include it in the layer two blocks.
But also for, but also there's, yeah, but also there is repercussion for the sequencer if
the sequencer fails to, to include a transaction, right, because of the same economic security.
So I would say it's kind of a combo of, I mean, hard, I mean, hard, delayed censorship
of tolerance and also crypto-economic security.
Right.
So this is like the sort of standard OPEC stack.
Yeah, yeah.
Yeah, it's not mega-eat technology.
Yeah, it's just, I mean, layer two.
Yeah.
Cool.
I just, I guess I have kind of a comment or a take just sort of getting to the conversation
so far.
And this is just like much higher level than what we've been discussing.
But it seems to me in being sort of an observer of the Ethereum ecosystem for a while,
It seems to me that both of these projects at some level are kind of an innovation reaction
to Solana at some level to kind of what a high throughput SVM looks like.
And Keone, you may say, hey, no, Monad preceded Solana in terms of thinking about this
and, you know, if that's the case like point taken.
But I think that's part of the narrative attraction to it.
It's like Ethereum really hasn't done very much innovation with respect to its virtual machine since inception.
Like the Ethereum Foundation has not been focused there. It's been focused on other things.
And so now both of your projects are like innovating the EVM and building new things and new possibilities from the EVM.
And maybe, Keone, you would say, like, hey, I'm like redesigning the entire database.
So modad even more so than mega-Eath at this point.
And I think that's all good for Ethereum.
It also strikes me that like maybe Keone, the Monad approach is more the monolithic integrated type of approach, which is just like, let's put all kind of the state and everything in kind of the full stack, you know, same area, right?
So we're not kind of, you know, moving execution and settlement and data availability across kind of multiple layers here with multiple dependencies.
just all put it in one spot. So you are like bullish EVM and also of the monolithic religion, let's say, or integrated religion. If we want to, like, better framing of that. Whereas mega-eth is also bullish EVM, but of the modular religion and like you like this idea of layer two's and keeping the decentralization properties of Ethereum or maybe the eth alignment, let's let's call it.
So is that a fair characterization of your two projects and where you come?
Like both are innovating on the EVM, both good for the progress of Ethereum, especially
to the extent that you were doing this in an open source way and giving us the code in a way
that others can access it as well.
But Keone, your approach with Monad is more on the monolithic integrated, whereas Meghaeith
is kind of modular.
I'm just trying to pin down religions here, you know, because in crypto we like to talk about
architectural religions.
Joni, what's your reaction to that?
Yeah, I would say that Monad is a full-stack approach,
where all layers of the stack are being optimized and harmonized.
Ethereum itself is a full stack.
Like, Ethereum is amazing.
There's this VM, there's consensus.
It serves as a data availability layer for other,
other blockchains.
And I think when ultimately trying to make improvements to Ethereum,
you would have to think about how all those pieces fit together.
And that's kind of like the thing that our team is tackling right now.
You were talking about Solana.
So I think one thing that's interesting is Monad is one of the four innovations in Monad
is asynchronous execution.
the easiest way of which to describe it is by remembering the movie limitless where the premise of the movie is like the aphorism that you only use 10% of your brain.
Like what if you could take a pill and use 100% of your brain?
Like think about how smart you'd be and how easy life would be for you.
And in the movie there's a guy who takes the pill.
And of course, things are great and then they become terrible because, you know, there's a question.
There's all you run too fast. Yeah, exactly. Fly too close to the sun. And that's a helpful analogy
because in existing blockchains where consensus and execution are interleaved, which is how Ethereum works
and how almost every blockchain works, the budget for execution is actually quite small because
consensus takes up most of that time. And consensus is expensive because nodes are on opposite
sides of the world, if it's a well-formulated blockchain, they're on opposite sides of the world,
or they're completely globally distributed. So consensus takes up most of that block time. And so
execution is actually only a small fraction of that block time. In particular, in Ethereum,
there's 12-second block times, but the budget for execution is actually only 100 milliseconds,
which is 1% of the block time, which is like a crazy dilating effect. So with asynchronous execution,
Monad moves execution out of the hot path of consensus and runs it in kind of a separate swim lane, very slightly lagged relative to consensus.
And that means that the entire block time can be allocated to execution.
So this is a massive actually budget increase for execution.
It's just coming from this different software architecture.
So, you know, our team has been talking about this concept for quite some time now.
recently I've seen other blockchains, including Solana, talk about, you know, kind of embrace, like,
the idea of asynchronous execution and talk about ways to integrate that within these other
blockchains as well. So I think it's just, that's only feasible if you're designing an entire
system where consensus and execution are both considered. The way that they fit together is
considered, and we optimize this full stack. So I think that that's, um, you know,
Yeah, for sure, like Monad is aligned with the idea of trying to optimize the full system to deliver the most performance possible.
You're going to confuse a lot of people when you ship the Monad product for all the narrative shillers out there because I'm not sure whether you're the Ethereum killer or the Salana killer that, you know, we have to have a killer.
If we're launching an Alt Layer 1 or else, you know, we can't get the narrative off the ground.
But, you know, centralization killer.
There you go.
There you go.
Lay, what's your reaction to kind of like my framing of this, which is like you're both EVM?
megables and your project takes the modular approach versus moda taking kind of the integrated
monolithic approach yep EVM megables we are there to enable new applications and what
our our product design as we saw is just single-mindedly optimized for that which is
kind of allowing for better performance in terms of throughput in terms of low latency real-time
this, right? We, I, I, I don't remember kind of mona, I mean, modular versus monolithic,
the discussion coming up even once in our kind of scoping, our design discussions back in the
days. So I think at the end of the day, I totally agree with you that, yes, we are on a track
of a modular approach, but I would say we're not guided by the discussion, the, the, the,
kind of religious debates between monolithic and modular.
It's really just because we build a layer two.
And yeah, so yeah, that's my conclusion.
And I guess in terms of the kind of engineering approach,
like we are performance,
we are kind of, I would say if Monad is like a full stack approach,
we are kind of a focused approach on performance.
And we're willing to kind of make
sometimes controversial and
interesting design decisions.
But yeah, here we are.
So if you're not willing to pick a religion,
are you willing to pick a killer?
You're an ETH killer or you're a Salon a killer?
Well, centralization killer,
definitely not ETH killer.
And yeah, I cannot say more.
Guys, one thing that's, I think, pretty interesting
about each of you guys' respective blockchains
is the magnitude of the community that has risen around each one.
Despite, I think, both of you not having a test net, raise your hand if you have a test net.
No one.
You have an internal.
We have an internal one, but nothing.
Internal test net.
Okay.
So incoming soon, TM.
It's actually pretty amazing that the brands that you guys have elevated for yourselves
has attracted builders.
So there's already people building on Monad.
There's already deals going around of people building on Monad.
Same thing with Mega-Eath.
There's this thing called a Mega Mafia.
Mega-Eath has this hat that every single person wants in Ethereum.
I wonder just how, what's it like to do community management, business development for an EVM chain?
Because there are roughly, I don't know, 30, 40, 50 EVM chains that are out there.
Yet somehow these two ecosystems that we have on the podcast today have done a very good job of actually
building a community and started building a community builders as well.
I'm wondering like, what's your guys' trick?
How did you guys do this?
What was the strategy for getting this done?
Keone, do you want to start?
I think we both have hats that you guys are about to show us.
Yeah, show us your stuff.
It's the merch.
Oh, okay.
Oh, the Melandac.
I want a Melandac.
Yeah, he's awesome.
He's sitting on Keone's shoulder right now.
It's a purple stuffed animal for you podcast listeners.
I can't see this.
Yeah. I'm actually in a hat factory here. I'm in a hat storage room, but I wanted to show you this Molandak. Yeah, the community, the Monarch community is honestly incredible. It's just the result of amazing individuals who have, who are really passionate about crypto, really passionate about defy, follow along with the lore and the memes and the fun of crypto Twitter every day.
many of whom were not, actually pretty much all of whom were not, like, famous on crypto Twitter or anything like that,
but are just people who have been following along and found a home in the Monad community
and found opportunities to contribute to take on leadership opportunities in terms of organizing initiatives,
contribute their art, contribute.
I don't know, we have a lot of fun initiatives going on, like the Monad Run Club,
which initially was seeking to run 10,000 kilometers collectively and hit that pretty quickly.
So now they're doing, I think, 80,000, which is like the circumference of the earth.
I probably got those numbers wrong, sorry.
Or Mon Lingo, which is an effort to learn a new language.
So people are doing Duolingo together.
There's just a lot of incredible energy, and it's all just driven by individuals.
So I think it's similar to, it's really consistent with the ethos of crypto, where,
Individuals matter and everyone can make a difference.
And also, you know, it's an environment of opportunity, both for application builders, as well
as for folks that have just been, are really switched on and really following along.
How do you keep them engaged when only so many of them are actually like playing around with the,
it's an internal Monad test net?
So like, what are they doing in there?
Like, they're going on runs together, which is kind of sick.
but what about just like, I don't know, more like crypto-native stuff?
Yeah, we've, I mean, it's evolved over time.
Initially, it was really just people hanging out, commiserating during the bear market.
I think that a lot of things are path-dependent, but it was pretty rough back there.
And a lot of our really OG members were just people who were scrolling the timeline
and decided to take shelter, if you will, from the negativity.
And over time, that's evolved into more specific initiatives.
But there are folks in our community who are getting job opportunities in the Monad ecosystem.
For builders, it's amazing because they can, you know, meet really talented community managers or marketers
or people who just have really good instincts for, you know, putting some wind in the sales of the project from a community or marketing perspective.
So overall, I think it's just a very nascent, but growing and, you know, environment with a lot of opportunity.
So inside, if you are a consumer of Monad lore, you'll notice that there's not just a Molandak.
There's a few other animals as well.
There's a Molan fish, another of other creatures that I don't know how they work.
Where does this lore about the Monad animals come from?
Yeah, that's actually a great question, great anecdote.
When we first started opening up the community, Bill Monday, our community lead,
and I spent a lot of time brainstorming, like trying to come up with the right mascot.
And so I have this notion page now of prospective mascots,
and all of the ideas are really bad.
Like, every next one is worse than the previous one.
And I think, you know, what it really, because we were thinking about it too hard.
We were like, okay, Monad is really fast.
So like, what's the thing that's fast?
Okay, like a cheetah or a car or something.
Anyway, the point is we were absolutely mid-curving it.
And at the end of the day, the creatures that have ended up becoming like
unofficial Monad mascots are all just community driven.
you know, a person just uploads an image and then that one through community curation,
like floats to the top just through people reusing it. There's no formal voting process or
anything like that. It's all just, you know, which things kind of stick in people's heads and end up
recurring. And now there's a super deep lore with Melandak and Mokad and Salmonad and Mojaki.
Yeah, I'll send you the photo later, but he's really cute, really funny.
really hopeless, I would say.
And he has a whole lore around him.
Like he's, yeah, he doesn't have a house.
Like all the other animals have houses.
But Salmanad doesn't have a house.
Salmanad doesn't have a house.
Yeah, I guess because he's migratory.
But actually just because he always kind of gets the short end of the stick in Monad lore.
Sorry, buddy.
There's Mooch, who's a fly.
He's French.
He was created by the French Nads.
shout out French Nads.
There's Spider-Mond, who's a spider created by the Turk Nads.
He's creepy but funny.
Anyway, yeah, there's just so much depth to, and it's just really fun.
Like, at the end of the day, if you're not, if you're in crypto and you're not having fun, then something is wrong.
Something's wrong, yeah.
And of course, the Monag community is called the Nads as well.
Lay, tell us about the mega-ethypher paris.
brand. How did you guys start this?
Yeah. So, yeah, we actually see a kind of an astonishing growth of our community because we
literally just came out of stealth, I mean, less than half a year ago. So our thrust,
our kind of our brand is called Mega Mafia. It's our kind of flagship builders program,
incubation program. So what we look for is those 0 to 1 applications that are only possible on
on Megaheith, a real-time blockchain, right?
And so, I mean, what we're looking for are the people,
are the kind of the founders who, I think actually the kind of our cohort,
I think they share kind of a common personality.
So they were drawn into crypto by,
they probably read something on the internet saying that,
kind of promising them that, hey, you can build this,
you can build that decentralized and trustless application
on crypto, they came to crypto, realized that, hey, it's a lie. There's not enough resource.
There's not enough infra to build what I wanted to do. However, so we are kind of offering them,
we're kind of telling them that, hey, there's a new kind of wave of infra in particular
mega-eath that you should try to kind of redo what you, what actually initially brought you
into crypto, the initial dream, the initial chase again right now. So that's how we got to
most of our builders.
So we have, like I mentioned, on-chain Minecraft,
we have on-chain VPN, which is infinitely scalable,
and we have, of course, the usual defy applications,
desks, probe decks, but based on other books,
but not on the AMMs, we have real-time prediction markets,
we have real-time game shows, et cetera.
So I think I'm basically varying the MegaM,
mafia t-shirt.
So, yeah, this is kind of our centerpiece of our community.
And now they were talking about rabbits, the mega-eith bunny.
So if Mona is kind of mid-curving it, then we're really kind of left-curbing in it.
Because we pick bunny really just because, yeah, I'm holding a jelly cat.
It's not a mega-eat jelly cat.
It's just a generic jelly cat.
I just like to hold it.
So, yeah, so we pick bunny really just because I love bunny.
So I was having my first chat with our co-founder and CBO Shuiyahu in Denver.
So she said, hey, we need to pick some animal.
We need to pick a mascot.
And I said, hey, I go to feed the bunnies on MIT campus almost every other night.
And I really love bunnies.
And she basically said, that's it.
And that's why we pick bunnies.
I think it worked well.
not by community choice, but I think our community love bunnies.
But I think our single rule for Discord management is that if you eat bunnies,
you're banned forever.
But other than that, I think, yeah, I think it's been going well.
So we are seeing more and more people who are kind of really interested in the tech.
So probably some listener may already saw our tick.
talk, I mean, our short format videos basically explaining kind of, I would say, common
misconceptions and interesting and lesser known tidbits in the crypto industry and in crypto
research, just break it down into kind of bite-sized pieces for our audience. I think that's
been going well. Yeah, we do serious performance engineering, so we are also publishing a series
of long-format tweets and also upcoming blog posts with kind of rigorous and more technical content
for those more techy people.
Yeah, but I would say we just want applications.
So that's kind of the centerpiece of our community building effort.
We want people to rethink what is possible now on crypto with a real-time blockchain.
Lay, does, is mega an acronym?
Like in the mega-Eath?
Does that, I heard a remember that it stands for Make Ethereum Great again.
Is that right?
It does stand for Make Ethereum Great again.
But interestingly, we realize it, I mean, almost a year, I think, into the inception of the company.
Okay.
Oh, you did.
You went with Mega Ead first and then you realized.
Yeah.
Yeah, yeah, exactly.
It's actually one of our genius investors.
It's a, yeah.
It's just a coincidence.
You could always do the red caps if you want to go in that direction, although that
me may already be taken by someone else.
Yeah, we do have red caps.
So it's right on the, on the kind of, I'm handing it on my door so that I can wear it whenever
I go out home.
Yeah.
And the, how many mega Eats are there?
Because I was told there were 50.
Yes, there are 50.
But I shamelessly took three.
So there are three at my door.
And also, I think.
two red hats.
How many unallocated hats are there?
I think these three, so one for me, and the other two are the only unallocated hats.
That's my counting.
But yeah, ask Shuiy.
High FD, high flow, I guess.
May I have one?
We'll talk after.
Yeah, ask our hats are Shuiya.
Okay.
I already did.
She said no.
Oh, then then, then unfortunately.
Sadly.
Sad.
I'm not allowed to tap into the reserve.
Okay.
One last question I have for you guys.
Recently on a podcast we did with Justin Drake and Anatoly from Solana,
Anatoly was talking some shit about the EVM.
He was saying that it's just like building through quicksand.
And while it's possible to like rebuild the EVM architecture to make it easier for builders,
it's still really hard.
And that's one of his like kind of big.
are scenarios for Ethereum. I'm wondering if you guys can give your takes. Both of you guys have
chosen the EVM. Why did you choose the EVM? What do your guys takes about the future role that
the EVM has in the industry? I remember in 2021 there was a chant going around in the Ethereum
crowd that like the EVM is at the center of all things because, you know, even Ethereum killers
were using the EVM like Phantom, Avalanche, like, et cetera, like five other chains that I've
forgotten about because they've disappeared into history.
just whatever your overall takes about, like, building on the EVM, like, why commit to the EVM?
What do you guys think about it?
Where does it go from here?
Keone, you want to start?
Yeah, I think the EVM is actually a perfectly fine bytecode standard.
There are some minor things that are a little bit quirky, like the size of the individual storage slots, 32 bytes is pretty big.
But I think fundamentally it's a perfectly reasonable, very very very.
expressive standard and we have high-level languages like solidity or viper or huff that are really
powerful. So I think a lot of the hate is really misdirected or just uninformed or just there for
hot takes. And it's a great standard that can get better over time through continued improvements
and support for new pre-compiles or op codes. Like it's an evolving standard.
But there's actually nothing wrong with it at all.
And that combined with the network effects of so many application developers
that have already built apps for EVM, so many libraries,
so much applied cryptography research, that it's just a no-brainer, really.
Lay, your thoughts?
Yeah, I pretty much agree.
There's nothing that is fundamentally wrong with EVM.
So interestingly, we had a Italic at one of our events in ECC.
So it was kind of oriented for students.
And so one of the students asked Vitalik, hey, what's your, I mean, name, kind of, I think, three regrets of the technical choices of Ethereum.
I think Vitalik didn't really mention EVM.
I mean, he, I think he did mention that he would not start the slippery slope of pre-compiles, but nothing that is fundamentally wrong with EBM.
And we definitely agree with him because, and also, I kind of think.
realize that as an engineer and as a researcher,
I think there's always the urge to kind of burn down everything
and that start from scratch, clean slate,
but there's always, as Kearney mentioned, right,
there's always all those ecosystem tools, libraries,
research builders, most importantly, people, right?
And they are already accustomed to EVM.
There's a reason that Intel doesn't really come up
with a new ISA instructions standard every five years.
There are reasons because there are reasons.
kind of accumulation of capital of know-how into a particular tech ecosystem.
So nothing that is fundamentally wrong with EVM and 100% EVM will keep flourished.
Okay, but now I'm dying to know what were Vitalik's two other regrets?
You said pre-compiles is one.
What are the other two?
I must know.
I honestly forgot.
Oh, no.
Lost to history.
We'll have to ask.
It's preferable.
I think someone picked it.
I think someone taped it.
Yeah.
All right, guys, this has been great.
Keone, one last
just like logistics question.
What's the future of
everything that Monad has built
and their open source nature?
You got the Monad EVM,
the MonadDB.
Will these things eventually become open source?
That's our plan.
Any sort of like timeline?
Or is that just like something you guys
will think about later?
Well, we'll think about it
certainly as time goes on.
And certainly before main net,
the code will be, you know, completely open for people to read and verify.
It's really important from an audit and safety perspectives.
So, yeah, no worries there.
Okay, wait, wait, I can't believe we gotten this far in the episode.
We haven't asked the question, when men net?
Because usually we don't do these conversations.
Well, there's just test nets.
We usually wait to May net.
We broke the bankless rule because this is such an important conversation
because you guys are, like, building this parallelized EVM.
thing, or I should say
high-performance EVM thing.
So now let's ask the question.
So when main net?
Gione, when is Monad
coming to Mainnet?
Our team is
working really hard on it.
Can't give an exact date.
My cheeky answer will be
when Melandak
comes out of this
hat closet and doesn't see a shadow.
Okay.
Is that happening in February?
Is that what we celebrate?
All right.
Lay,
you. When may not for Meggy?
Yeah, we have been pretty open.
So end of the year slash early next year.
Cool.
End of the year slash early next year.
Some new blockchains to play with coming your way, Bankless Nation.
Keone, Lay, this has been just fantastic.
I've learned quite a lot on this episode.
So thank you guys for spending the time with us.
I hope the Bankless Nation has learned a lot because I certainly have.
It's been such a pleasure.
Yeah.
Thank you for having me.
Thank you.
Bankless Nation.
You guys know the deal.
Crypto is risky.
main new main nets will also be risky when they arrive but nonetheless we are headed west this is
the frontier it's not for everyone but we are glad you are with us on the bankless journey thanks a lot
