Dialogue with Monad Co-founder Keone: The Innovative Path to Optimizing EVM

Author: Snownad & Danny

Compiled by: Deep Tide TechFlow

Keone Hon, CEO and co-founder of Monad Labs, and Kevin G, Developer Relations Engineer, participated in the third episode of The Pipeline podcast to discuss the work of the Monad Labs team over the past two years.

Guest Introduction:

Keone is the CEO and co-founder of Monad Labs, previously a quantitative analyst at Jump Trading, focusing on high-frequency trading (HFT);

James Hunsaker is the co-founder and CTO of Monad;

Kevin G is a core developer at Solana Labs, previously working at Apple, focusing on the native system engineering design of AirPods.

Why choose Monad? In an environment where L2 and other scaling solutions are so popular, why transform EVM?

Keone:

A few years ago when we started, many people asked us, "Why not build an L2?" Our answer then is the same as now: we believe someone needs to focus on improving the performance of the EVM execution stack. By introducing optimizations such as parallel execution, custom state databases, pipelined execution, and support for asynchronous I/O, Monad can better leverage hardware to achieve a more efficient and decentralized system.

Over time, it has become increasingly clear that many bottlenecks in the Ethereum Virtual Machine can be addressed and optimized by the right engineering team. Back in 2020, when Monad was first conceptualized, there weren't many teams focusing on these optimizations, especially compared to the efforts put into other infrastructures (like rollups, zero-knowledge proofs, or data availability).

As the dominant standard for smart contracts, EVM chains have the most TVL, the largest developer and research networks, and an incredible community that has stood the test of time (and multiple bear markets). This makes optimization even more important as we aim to expand adoption and support more complex applications.

"Significantly improving EVM performance is indeed an interesting and challenging problem. I'm glad our team started working on this project back then. It excites me greatly, and I look forward to showcasing 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 area.

Not every development team can tackle the fundamental issues of the protocol and propose high-performance solutions. These optimizations are not only exciting but also ambitious.

How did you select a team capable of meeting this challenge?

Keone:

I just feel very fortunate to have an amazing group of talent in engineering, growth, marketing, community building, and business development at Monad Labs. We have about 25 people, trying to keep the team super lean so we can focus on the problems that need solving.

Over time, our team will continue to grow to support the scale and adoption we are trying to achieve. This will certainly require broader skills and additional manpower.

Most engineering teams have extensive experience in building high-performance, low-latency systems. A common pattern in developing truly high-performance foundational systems is that you need to have an understanding of the performance of the entire system. Sometimes you need to dive down to the kernel level to get the optimizations you need. Ultimately, a blockchain is essentially a database.

Some beloved Monad roles have solidified their status in community lore.

Why should builders take a look at Monad?

Keone:

A key advantage is Monad's potential to facilitate broad composability, surpassing the existing limitations of Ethereum and even outperforming higher-performance systems like 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 a wealth of research and tools that have paved the way for the flourishing of EVM and enable developers to build higher-performance, scalable applications in an environment they already understand 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 and cost-effective platform for building diverse applications, eliminating the limitations that hinder composability in the existing blockchain ecosystem.

In the context of Ethereum's original design: the aim was to enable builders to create anything within its ecosystem. Monad is an accelerated evolution of this concept, breaking free from the constraints that have existed for over a decade. We can use the transition from gasoline cars to electric vehicles as an analogy, marking a paradigm shift in what can be achieved when new technologies are introduced.

Considering the real challenges Ethereum developers face, such as gas limits. Without these limits, there would be more applications and functionalities on Ethereum, but they are disabled due to high costs. One of Monad's primary goals is to liberate existing EVM applications from the current gas constraints.

Monad also leverages the rich existing code and products in the EVM ecosystem, providing an ambitious platform for builders to truly create dApps that would be impossible elsewhere.

Overall, Monad's focus is on the collective nature of the crypto community. The current phase is an experimental period during 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 broader user base.

What type of applications do you most hope to see on Monad?

Keone:

For me, I most hope to see two areas—decentralized finance (DeFi) and consumer-facing applications.

DeFi

Any application that allows ordinary people to manage personal finances in a decentralized way. Of course, applications like money markets, decentralized exchanges, derivatives, high-precision and high-scale oracles, etc. This is a vertical I am very excited about.

Before Monad, I was part of the Jump crypto team. Jump is very interested and excited about the Solana ecosystem because it makes sense. If fees are just a fraction of a cent and you can scale to millions of users, then you can essentially replace what the existing leaders are doing. Centralized exchanges charge very high fees for data.

One of the reasons we like Solana is that it is a fantastic technology. Although it lacks EVM compatibility, which can make the development experience a bit tricky, Solana has made significant progress since James and I committed to developing it in 2021.

Consumer Applications

I am also very excited about consumer-facing applications on Monad. For example, sports betting, casinos, social applications—basically anything that makes sense as a mobile application on a phone.

If I know all my data is in my wallet, I would be more willing to interact with applications, services, and content; this is because wallets are cryptographically secure.

What aspects of EVM make you most interested in the Monad roadmap?

Keone:

For me, the key is building something that will ultimately help the most developers scale their applications. At the end of the day, Monad is a developer platform. It is crucial to go where developers are and address their truly pressing issues. I think pure EVM compatibility is part of solving these issues, but there will be other issues in the future that essentially make supporting more crypto features easier and cheaper.

Ultimately, it is just about solving the problems that hinder developers from building the top-ranked applications in the iOS store. For me, I feel that EVM is the best place to achieve this goal.

It is surprising that no one is really focused on the execution stack. Given our team's previous background and the urgency we feel to solve this problem, it is a very natural area of work.

Monad provides a true path to achieving product scale for the ideals of the EVM and Ethereum community.

"Ultimately, Monad is a very cool combination where we can have a Solana-like user experience on EVM. Then, developers can choose where they want to build based on the needs of the system."

Collaboration is indeed important. Our team realizes that we do not have all the answers to the problems. We are experts. We know a lot about building high-performance parallel systems, Byzantine fault-tolerant consensus, and other very specific issues. But many others have invested energy in research on Ethereum, focusing on issues like MEV minimization, governance, and cryptography. So I think it is also important to follow standards and where our work can be composable with the work of others.

Kevin G:

EVM is at the center of so much application cryptography research, building applications, and developing better security practices. Being in a standard position and helping to push the entire field forward is very nice.

Because of this, we can deeply focus on scaling the foundational layer (which is our expertise) while leveraging the expertise of the research community in this area. Additionally, we do not have to rebuild all the developer tools that have already been developed for EVM.

What is the biggest challenge of being a builder in the EVM environment?

Keone:

I think there are several. For builders, attracting funding is quite challenging right now; the investor community is very U.S.-centric. It is really hard for international builders to secure funding.

Additionally, from a security perspective, building dApps is challenging. There are a lot of black hat hackers constantly looking for vulnerabilities and opportunities to attack. This makes the environment very adversarial. We need better security practices, including gas optimization.

By significantly reducing gas costs, Monad eliminates a huge dilemma faced by developers; whether to include additional defensive assertions (which consume more gas).

A Monad community member showcases his new mural in Turkey.

What overlooked advantages are there in building crypto products?

Keone:

The strength of the crypto community is astounding. If you are building a traditional tech startup, assuming your Twitter has no followers, you can post updates, but no one will care. No one is rushing to try your product. You have to jump through hoops to get people to try it for free.

In the crypto space, we have such a strong community (the community is actually a core part) that it is a significant advantage over other tech fields and one of the reasons crypto will ultimately succeed. It is really just about leveraging strengths and minimizing 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 high-performance (by then, I do not want Monad to be different from other blockchains just because of its performance).

Other systems will make additional improvements, and there will be cross-pollination of ideas or technologies. This will ultimately push the space forward, enabling the construction of higher-performance applications. We will continue to push the limits of what blockchain can do and introduce other infrastructure to support new implementations.

There is a lot of discussion on crypto Twitter about TPS as a general metric for transactions and voting transactions. When is TPS a valuable metric?

Keone:

Regarding the general measurement of TPS, we believe it should only count real transactions, i.e., smart contract interactions and transfers that occur on-chain: not just voting transactions. For Monad, we will not include voting in any TPS showcase.

In general, there is a lot of confusion about what should count as a real transaction. Many teams use different metrics to count transactions. The field is currently very ununified in how it promotes performance. For example, some people count a single transaction as one instruction. So if there is a single smart contract call that executes several sub-instructions, others might count it as about 10 transactions, which is actually incorrect.

What you can really measure is just the number of transactions 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 launch a complete script that defines the process of deploying many different servers around the world. Then, the script can send a large number of transactions to various nodes in the system and actually reproduce a complete transaction throughput test.

This is something our team plans to introduce, at least for Monad, but hopefully also applicable to other competitive benchmarks. This is similar to the normal scientific research process where you not only publish your results but also the process you used to generate those results. This way, third parties can re-experiment and reproduce these benchmarks. This is very important to us and is something we intend to do.