Monad Labs CEO and Co-Founder Keone Hon and Developer Relations Engineer Kevin G join us for the third episode of The Pipeline Podcast to discuss what the Monad Labs team has been working on for the past two years.
Guest introduction:
Keone is the CEO and co-founder of Monad Labs. Previously, he worked as a quantitative analyst at Jump Trading, focusing on high-frequency trading (HFT);
James Hunsaker is co-founder and CTO of Monad.
Kevin G is a core developer at Solana Labs and previously worked at Apple, focusing on local system engineering design for Airpods.
Why Monad? Why did you revamp the EVM when L2 and other scaling solutions are so popular?
Keone：
When we first started a few years ago, many people asked us, "Why don't you build an L2?" Our answer then is the same as it is now: we think someone needs to focus on improving the performance of the EVM execution stack. By introducing optimizations such as parallel execution, a custom state database, pipelined execution, and support for asynchronous IO, Monad is able to better utilize hardware and enable more efficient and decentralized systems.
Over time, it became increasingly clear that many of the bottlenecks in the Ethereum Virtual Machine could be addressed and optimized with the right team of engineers. Back in 2020, when Monad was first conceptualized, there weren’t many teams focusing on these optimizations, especially compared to the effort being put into other infrastructure like rollups, zero-knowledge proofs, or data availability.
As the dominant standard for smart contracts, the EVM chain has the most TVL, the largest developer and research network, and an incredible community that has withstood the test of time (and multiple bear markets). This makes optimization even more important as we look to expand adoption and support more complex applications.
“Making a big improvement in EVM performance is indeed an interesting and challenging problem. I’m glad our team started working on this project when it did. It’s very exciting and I look forward to showing it to the world in the coming months.”
EVM performance meets scalability on Monad
Kevin G：
A lot of what Monad is doing is applying best practices from computer science to blockchain networks. This is possible because the team has such a deep background in this space.
Not every development team is able to solve the fundamental problems of the protocol and come up with performant solutions. These optimizations are not only exciting, they are also ambitious.
How did you select the team that would take on this challenge?
Keone：
I just feel extremely lucky to have an amazing group of engineering, growth, marketing, community building, and business development talent here at Monad Labs. We are about 25 people and try to keep it super lean so we can focus on the problems that need to be solved.
Over time, our team will grow to support the scale and adoption we are trying to achieve. This will definitely require a wider range of skills and additional manpower.
Most engineering teams have extensive experience building high-performance, low-latency systems. A common pattern in developing truly high-performance base-layer systems is that you need to have some understanding of the performance of the entire system. Sometimes you need to drill down to the kernel level to get the optimizations you need. Ultimately, the blockchain is actually a database itself.
Some beloved Monad characters have cemented their place in community lore
Why should builders look at Monads?
Keone：
A key advantage lies in the potential of monads, which may be able to facilitate extensive composability beyond the current limitations of Ethereum and even better than higher-performance systems such as Solana.
Because Monad is compatible with EVM bytecode and RPC, the learning curve for engineers is much lower than in many other environments. We are excited to leverage the extensive research and tooling that has paved the way for the EVM to flourish and enable developers to build more performant, scalable applications in an environment they already know and trust.
What is Monad’s strategic positioning in the broader Layer 1 solutions space?
Keone：
The ultimate goal is to create a more scalable, cost-effective platform for building diverse applications, removing limitations in the existing blockchain ecosystem that hinder composability.
In the context of Ethereum’s original design: the goal was to enable builders to create anything within its ecosystem. Monads are an accelerated evolution of this concept, freeing from the limitations that have existed for over a decade. We can use the transition from gas-powered cars to electric cars as an analogy, marking a paradigm shift in what is possible when new technology is introduced.
Considering the practical challenges faced by Ethereum developers, such as Gas limits. Without these limits, there would be many more applications and features on Ethereum that are disabled because of high fees. One of the main goals of Monad is to free existing EVM applications from the current Gas limits.
Monad also leverages the wealth of existing code and products in the EVM ecosystem, providing a platform for ambitious builders to truly be able to build dApps that wouldn’t be possible elsewhere.
Overall, Monad is focused on the collective nature of the crypto community. The current phase is an experimental period in which crypto enthusiasts are building applications for decentralized personal finance. Monad aims to make these applications more cost-effective, unlocking their true potential and expanding to a wider user base.
What types of applications would you most like to see with Monads?
Keone：
For me, there are two areas I’m most excited to see — decentralized finance (DeFi) and consumer-facing applications.
DeFi
Any application that enables regular people to manage their personal finances in a decentralized way. Certainly, applications like money markets, decentralized exchanges, derivatives, high-precision and high-scale oracles. This is a vertical that I'm very excited about.
Prior to Monad, I was part of the crypto team at Jump. Jump is very interested and excited about the Solana ecosystem because it makes sense. If fees are fractions of a penny and you can scale to millions of users, you can actually essentially displace what the incumbent incumbents do. Centralized exchanges charge very high fees for data.
One of the reasons we like Solana is that it’s an awesome technology. While its lack of EVM compatibility can make the development experience a bit tricky, Solana has come a long way since James and I started working on it in 2021.
Consumer Applications
I'm also really excited about the consumer facing applications on Monad. For example, sports betting, casinos, social, basically anything that makes sense as a mobile app on a phone.
I would be more willing to interact with apps, services, and content if I knew all my data was in my wallet; this is because the wallet is cryptographically secure.
What aspects of the EVM make you most interested in going the monad route?
Keone：
For me, it's all about building something that will ultimately help the most developers scale their applications. At the end of the day, Monad is a developer platform. It's important to go where the developers are and solve their really pressing problems. I think pure EVM compatibility is part of the solution to those problems, but there will be others in the future that essentially make it easier and cheaper to support more crypto features.
At the end of the day, this is all about solving the problems that are preventing developers from building apps that rank#1on the iOS store. To me, I feel like the EVM is the best place to do that.
Surprisingly, no one really focused on the execution stack. Given our team's previous background, and the urgency we felt in solving this problem, this was a very natural area to work on.
Monad provides a path to truly achieve production scale for the EVM and the Ethereum community’s ideals.
“The bottom line is that Monad is a really cool combination where we can have a Solana-like user experience on the EVM. Developers can then choose where they want to build based on the needs of the system.”
Collaboration is really important. Our team realizes that we don't have all the answers. We are experts. We know a lot about building high-performance parallel systems, Byzantine fault-tolerant consensus, and other very specific problems. But there are a lot of people working on Ethereum research, focusing on things like MEV minimization, governance, and cryptography. So I think it's also important to follow standards, where the work we do is composable with the work of others.
Kevin G：
The EVM is at the center of so much applied cryptography research, building applications, and developing better security practices. It’s great to be in a position of standards and help move the whole field 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 this area. Additionally, we don’t have to re-build all the developer tools that have already been developed for the EVM.
What is the biggest challenge when working as a Builder in an EVM environment?
Keone：
I think there are several. For builders, it's pretty challenging to attract funding right now; the investor community is very skewed toward the U.S. For international builders, it's really hard to get funding.
Additionally, building dApps is challenging from a security perspective. There are a large number of black hat hackers who are constantly looking for vulnerabilities and opportunities to attack. This makes the environment very adversarial. We need better security practices, including gas optimization.
By drastically reducing gas costs, Monads eliminate a huge decision developers face; whether to include additional defensive assertions (which cost more gas).
A Monad community member shows off his new mural in Türkiye
Building Crypto Products: What are the Overlooked Advantages?
Keone：
It's amazing how strong the crypto community is. If you're building a traditional tech startup, let's say you have no followers on Twitter, you can post updates but no one will care. No one is eager to try your product. You have to go through a lot of trouble to get people to try it for free.
In crypto, we have such a strong community (the community is actually part of the core), which is actually a huge advantage over other areas of tech and a reason why crypto will ultimately succeed. It's really just about leveraging the strengths and minimizing the weaknesses, and then we can scale as an industry.
In November 2023, the community created an early ecosystem map for Monad.
As an industry, blockchain is just beginning to mature. Over time, blockchains will become more performant (by then, I don't expect Monad to be different from other blockchains simply because of its performance).
Other systems will make additional improvements, and there will be a cross-pollination of ideas or technologies. This will ultimately drive the space forward and enable higher performance applications to be built. We will continue to push the limits of what is possible with blockchain and introduce other infrastructure to support new implementations.
There has been a lot of discussion on crypto Twitter about TPS as a metric for transactions in general and voting transactions. When is TPS a valuable metric?
Keone：
Regarding the general measurement of TPS, we believe that it should only count real transactions, i.e. smart contract interactions and transfers that occur on-chain: not just voting transactions. For Monad, we do not include voting in any TPS display.
In general, there is a lot of confusion about what should count as a real transaction. Many teams use different metrics to count transactions. Right now the space is very uncoordinated on how to advertise performance. For example, some people count one transaction as one instruction. So if there is a single smart contract call that executes several sub-instructions, others will count it as about 10 transactions, which is actually incorrect.
All 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 will be much lower. So there is a lot of confusion here as well.
I think the real solution is to have reproducible benchmarks in a GitHub repository. Every team should contribute to this repository and push out a complete script that defines the process of deploying many different servers around the world. The script should then be able to send a large number of transactions to various nodes in the system and actually reproduce the full transaction throughput test.
This is something our team plans to introduce, at least for Monad, but hopefully for other competitive benchmarks as well. This is similar to the normal scientific research process where you publish not only your results but also the process you used to generate those results. That way, third parties can re-experiment and reproduce those benchmarks. This is very important to us and something we intend to do.