Why Monad? Super-Optimizing The EVM With CEO Keone Hon
Keone Hon, CEO and Co-founder of Monad Labs, and Kevin G, Developer Relations Engineer, joined the third episode of The Pipeline Podcast to discuss what the Monad Labs team has been working on for the past two years. Why rebuild the EVM from scratch? Read on to find out. 👇
Guest Background:
Keone previously worked at Jump Trading in the high-frequency (HFT) space as a quant. This is where he met and first worked alongside Monad co-founder and CTO, James Hunsaker. Most recently, Kevin G worked at Solana Labs as a core developer (and previously at Apple, focusing on local systems engineering design for Airpods).
Q&A
Why Monad? Why did you want to revamp the EVM in a climate where L2s and other scaling solutions are so popular?
Keone:
A few years back when we first started, a lot of people asked us, “why not build an L2?” Our answer then was the same then as it is now: we think someone needs to focus on making the EVM execution stack a lot more performant. By introducing optimizations like parallel execution, a custom state database, pipelined execution and support for asynchronous IO, Monad will be able to better leverage hardware for a much more performant and decentralized system.
Over time, it’s become clear that the many bottlenecks in the Ethereum Virtual Machine could be addressed and optimized by the right team of engineers. Back in 2020, when Monad was first conceptualized, there weren’t many teams focusing on these optimizations, especially when you compare that to the effort put into other infrastructure (rollups, zero-knowledge proofs or data availability).
As the dominant standard for smart contracts, EVM chains have (by far) the majority of TVL, the largest developer and research networks, and an incredible community that has withstood the tests of time (and multiple bear markets). This makes optimization even more important as we look to scale towards larger adoption and support more complex applications.
“It’s really an interesting and challenging problem to make the EVM a lot more performant. I’m glad that our team started on this when we did. It makes me really excited to show it to the world in the coming months.”
Kevin G:
A lot of the things that Monad is doing are computer science best practices applied to a blockchain network. This is possible because the team has such a deep background in this field.
Not every dev team can work on solving a protocol’s fundamental problems and come up with a highly performant solution. Not only are these optimizations exciting; they’re ambitious in nature. This has never been done before.
What’s your approach to curating a team that is up to this challenge?
Keone:
I just feel really lucky to have an amazing group of folks on the engineering front, as well as on the growth, marketing, community building, and business development fronts here at Monad Labs. We’re about 25 people strong, trying to stay super lean to remain incredibly laser-focused on the problems that need to get solved.
As time goes on, our team will grow in order to support the scale and adoption we are trying to reach. This will definitely require a broader set of skills and additional manpower.
Most of the engineering team has a lot of experience building high performance, low latency systems. A common pattern in developing really performant base layer systems is you need expertise over the performance of the entire system. Sometimes you need to delve into kernel level to get the optimizations that you need. And ultimately, the blockchain is actually a database itself.
Why should a builder to come check out Monad?
Keone:
A key advantage lies in Monad’s potential to foster extensive composability, surpassing the existing limitations on Ethereum, and even more performant systems like Solana.
Because Monad is EVM bytecode and RPC compatible, the learning curve for engineers is much lower than in many other environments. We’re grateful and excited to leverage the extensive amount of research and tooling that’s paved the way for the EVM to flourish, and to leverage that in a way that enables devs to build more performant, scalable applications in an environment they already know and trust.
What’s the strategic positioning of Monad in the broader landscape of Layer 1 solutions?
Keone:
The ultimate goal is to create a more scalable and cost-effective platform for building diverse applications, eliminating constraints that have hindered composability in existing blockchain ecosystems.
In the context of Ethereum’s original design: the intent was to enable builders to create anything within its ecosystem. Monad is an acceleration of that concept, breaking free from constraints that have persisted for over a decade. The transition from gas-powered cars to electric cars serves as an analogy, signifying a paradigm shift in what becomes achievable when new tech is introduced.
Consider the practical challenges faced by Ethereum developers due to gas limitations. Many more applications and features would be possible on Ethereum, but are disabled due to prohibitive fees. One of Monad’s primary objectives is to liberate existing EVM apps from the constraints of current gas limitations.
Monad also taps into the wealth of existing code and products within the EVM ecosystem, providing a platform for ambitious builders to truly build dApps that aren’t possible elsewhere.
Overall, Monad’s emphasis is on the collective nature of the crypto community. This current phase is a period of experimentation, in which crypto enthusiasts are building applications for decentralized personal finance. Monad aims to make these applications more cost-effective, unlocking their true potential to scale to a broader user base.
What type of applications are you most excited to see on Monad?
Keone:
There are two areas for me — decentralized finance (DeFi) and consumer-facing applications.
DeFi
Anything that enables normal people to manage their personal finances in a decentralized manner. Certainly applications like money markets, decentralized exchanges, derivatives, oracles at high fidelity and high scale. That’s one vertical that I’m really excited about.
Prior to Monad, I was part of the crypto team at Jump. Jump was deeply involved in and excited about the Solana ecosystem because it just made sense. If fees are fractions of a cent and you could scale to millions of users, then you could actually have financial products that basically take the place of what existing incumbents currently do. Centralized exchanges charge really high fees for data.
One of the things that we loved about Solana was that it’s really awesome tech. Even though it lacks EVM compatibility, which can make the dev experience tricky, Solana’s come a long way since 2021, when James and I were working on it.
Consumer Apps:
I’m also really excited about consumer facing applications on Monad. For example, sports betting, casinos, social; basically anything that makes sense to do on your phone as a mobile app.
If I knew that all my data was in my wallet, I’d be more comfortable interacting with apps, services, and content; this is because the wallet is cryptographically secure. For example, a shopping app that puts into context an individual’s personal experiences and preferences (on-chain) is very meaningful for the UX of shopping.
What is it about the EVM that made you most excited to pursue the Monad route?
For me, it’s about building things that can ultimately help the highest number of developers scale their apps. At the end of the day, Monad is a developer platform. It’s really important to go where the developers are and solve problems that are really pressing to them. I think that the pure EVM compatibility is part of solving those problems, but there are other problems further down the road, essentially making support for more cryptographic functions a lot easier and a lot cheaper.
At the end of the day, it’s just about solving problems that are blocking developers from building apps that get to number one on the iOS store. And for me, I felt that EVM was the place to do it.
It was kind of surprising that there were not really people that were focusing on the execution stack. It’s just a very natural place to go work given our team’s previous background, and then also given how urgently we felt the problem needed solving.
Monad presents this path where the ideals of the EVM and the Ethereum community have a chance to actually reach product scale.
“Ultimately, Monad is this really cool combination where we can have these Solana-like user experiences on the EVM. And then it will really just be the developers’ choice to where they want to build, based on the needs of their system.”
Collaboration is really important. Our team is aware of the fact that we don’t know the answers to everything. We are specialists. We know a lot about building high-performance parallel systems, Byzantine Fault Tolerance Consensus and other very specific problems. But there’s a lot of other people that have put in effort on Ethereum’s research side, focusing on problems like MEV minimization, governance and cryptography. So I think it’s also important to go where the standard is, where the work that you do is composable with the work of others.
Kevin G:
EVM is the nexus of so much applied cryptography research, so much effort building apps, so much effort developing better security practices. It’s really good to be where the standard is and help push the whole space forward.
Because of this, we can focus deeply on scaling the base layer — which is what we are good at — while leveraging the research community’s expertise in the field. Additionally, we don’t have to rebuild all the developer tooling that’s already been made available for the EVM.
What is the biggest challenge of enabling builders in an EVM environment?
Keone:
I think there are a couple. It’s quite challenging right now for builders to attract funding; the investor community is very biased toward the US. For international builders, it’s really tough to get funding.
Also, building a dApp is challenging from a security perspective. There’s a ton of black hat hackers that are constantly probing for vulnerabilities and looking for an opening. This makes it a very adversarial environment. We need better security practices, including gas optimization.
By reducing gas costs substantially, Monad eliminates a huge trade-off for developers; whether or not to include additional defensive assertions (which costs more gas).
An Overlooked Advantage of Building Crypto Products
Keone:
It is amazing that the crypto community is so strong. If you’re building a traditional tech startup, your Twitter would have no followers. You can post updates and no one would care. There would be no one that’s eager to go try out your product. You’d have to pull teeth just to get people to try it out for free.
In crypto, the fact that we have such a strong community (that community is really a core part of the ethos), is actually a huge advantage over the rest of the tech space AND a reason why crypto will ultimately be successful. It’s really just about leveraging the advantages and minimizing the disadvantages; then we can scale as an industry.
As an industry, blockchain is just starting to mature. Over time, blockchains will get more performant (to the point that I won’t expect Monad to be unique from other blockchains solely because of its performance).
Other systems will make additional improvements and there will be cross-pollination of ideas, or cross-pollination of technology. This ultimately moves the space forward and enables more performant apps to be built. We’re going to keep pushing the limits of what’s possible with blockchains and introducing other infrastructural support for new implementations.
There’s a lot of discussion on crypto Twitter regarding TPS as a metric in general and voting transactions. When is TPS a valuable metric?
Keone:
Regarding the general measurement of TPS, we think it should be just counting the real transactions, the smart contract interactions and the transfers that are happening on-chain: not just voting transactions. For Monad, we won’t include votes in any TPS showcase.
In general, there is a lot of confusion as to what should count as a true transaction. Many teams use different metrics for counting transactions. It’s a very non-uniform space right now in terms of how different teams advertise performance. For example, some count a transaction as an instruction. So if there’s a single smart contract invocation that does several sub-instructions underneath it, others would count that as ~10 transactions, and that’s not really correct.
The only thing you can really measure is the number of transactions going through the system. If at any given moment, the system is not at full capacity, then the actual observable TPS is much lower. So there’s a lot of confusion there as well.
I think the true solution is to have reproducible benchmarks within a GitHub repo. Each team should contribute to this repo and push a full script that defines the deployment of many different servers around the world. Then, the script would be able to send a whole bunch of transactions to various nodes in the system and actually reproduce a full transaction throughput test.
That’s something that our team is planning on introducing, at least for Monad, but hopefully for other competitive benchmarks as well. This is similar to normal scientific research processes where you have to not only publish your results, but also publish the procedure that you use to generate those results. This way, third parties can replay the experiment and reproduce these benchmarks. That’s really important to us and it is something that we intend on doing.
If you made it to the end, thanks for reading! If you learned something new, please consider sharing this article on Twitter and commenting your feedback below. Follow The Pipeline for all Monad News and updates, and we’ll see you soon. Gmonad 💜
