Original author: Snownad Danny

Original compilation: Deep Chao TechFlow

Monad Labs CEO and Co-Founder Keone Hon and Developer Relations Engineer Kevin G joined 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. He previously worked as a quantitative analyst at Jump Trading, focusing on the field of high-frequency trading (HFT);

James Hunsaker is co-founder and chief technology officer of Monad;

Kevin G is a core developer at Solana Labs. He previously worked at Apple and focused on the local system engineering design of Airpods.

Why choose Monad? In an environment where L2 and other scaling solutions are so popular, why would you want to retrofit EVM?

Keone：

When we first started a few years ago, a lot of people asked us, Why not build an L2? Our answer then was the same as it is now: We thought someone needed 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 IO, Monad is able to better utilize hardware and achieve a more efficient and decentralized system.

Over time, it became increasingly apparent that many of the bottlenecks in the Ethereum Virtual Machine could be solved and optimized with the right team of engineers. Back in 2020, when Monads were first conceptualized, there weren’t many teams focused on these optimizations, especially compared to the effort 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 scale adoption and support more complex applications.

Significantly improving the performance of the EVM is indeed an interesting and challenging problem. Im glad our team started working on this project at that time. It is 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 field.

Not every development team is able to solve the fundamental problems of the protocol and come up with a high-performance solution. Not only are these optimizations exciting, they are also ambitious.

How did you select the team that could handle this challenge?

Keone：

I just feel incredibly lucky to have an amazing group of engineering, growth, marketing, community building, and business development talent here at Monad Labs. There are about 25 of us, trying to keep a super lean team so we can focus on the problems that need to be solved.

Over time, our team will continue to 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 overall system performance. Sometimes you need to drill down to the kernel level to get the optimizations you need. Ultimately, the blockchain is actually a database in itself.

Some beloved Monad characters cement their place in community lore

Why should builders come and see Monad?

Keone：

A key advantage lies in the potential of Monads, which may be able to facilitate broad composability beyond Ethereums existing limitations 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. Were excited to leverage the wealth of research and tooling that is paving the way for EVM to thrive and enable developers to build higher-performing, scalable applications in an environment they already know and trust.

What is Monads strategic positioning within the broader Layer 1 solutions space?

Keone：

The ultimate goal is to create a more scalable and cost-effective platform for building diverse applications, removing limitations that hinder composability in the existing blockchain ecosystem.

In the context of Ethereum’s original design: the purpose was to enable builders to create anything within its ecosystem. Monads are an accelerated development of this concept, freed from limitations that have existed for over a decade. We can use the analogy of the transition from gas-powered cars to electric cars, marking a paradigm shift in what is possible when new technology is introduced.

Consider the practical challenges faced by Ethereum developers, such as gas limits. Without these restrictions, there would be many more applications and features on Ethereum that would be disabled due to excessive fees. One of the main goals of Monad is to free existing EVM applications from their current Gas limitations.

Monad also leverages the rich existing code and products in the EVM ecosystem, giving ambitious builders a platform to truly build dApps that are not possible elsewhere.

Overall, the focus of Monads is 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 scaling to a wider user base.

What type of application would you most like to see on Monad?

Keone：

For me, there are two areas I’m most excited to see happen – decentralized finance (DeFi) and consumer-facing applications.

DeFi

Any application that allows ordinary people to manage their personal finances in a decentralized way. Of course, applications like currency markets, decentralized exchanges, derivatives, oracles with high accuracy and scale. This is a vertical that Im very excited about.

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

One of the reasons we love Solana is that its a great technology. Although its lack of EVM compatibility can make the development experience a bit tricky, Solana has come a long way since James and I worked on it in 2021.

consumer applications

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

I will be more willing to interact with apps, services, and content if I know all my data is in my wallet; this is because the wallet is cryptographically secure.

What aspects of the EVM excite you most about the Monad route?

Keone：

For me, the key is building something that ultimately helps the most developers scale their applications. Ultimately, Monad is a developer platform. It’s important to go where developers are and solve their real pressing problems. I think pure EVM compatibility is part of the solution to these problems, but there will be others in the future that essentially make it easier and cheaper to support more cryptographic features.

Ultimately, this is just about solving the problems that prevent developers from building apps that rank #1 in the iOS store. For me, I feel that EVM is the best place to achieve this goal.

Surprisingly, no one really focuses on the execution stack. This was a very natural area of ​​work given our teams previous background and the urgency we felt in solving this problem.

Monads provide a path to true product scale for the EVM and the Ethereum communitys ideals.

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

Cooperation is indeed important. Our team realizes 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 still many people who have invested in research on Ethereum, focusing on issues such as MEV minimization, governance and cryptography. So I think its also important to follow standards, where the work we do is composable with other peoples work.

Kevin G：

The EVM is the center for so much applied cryptography research, building applications, and developing better security practices. Its great to be in a standard position and help push the entire field forward.

Because of this, we can focus deeply on extending the base layer (which is what we do well) while leveraging the research community’s expertise in this area. Additionally, we dont have to re-build all the developer tools that have been developed for EVM.

What is the biggest challenge when working as a Builder in an EVM environment?

Keone：

I think there are several. Attracting funding is quite challenging for builders right now; the investor community is very US skewed. Its really hard for international builders to get funding.

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

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

A Monad community member displays his new mural in Türkiye

What are the overlooked advantages of building crypto products?

Keone：

It’s amazing how powerful the crypto community is. If youre building a traditional tech startup, lets say you have no followers on Twitter, you can post updates and no one will care. No one is eager to try your product. You have to go out of your way to get people to try it for free.

In the crypto space, we have such a strong community (the community is actually part of the core), which is actually a huge advantage to other areas of technology and a reason why crypto will ultimately succeed. Its really just about leveraging the strengths and minimizing the weaknesses and then we can scale as an industry.

In November 2023, the community produced an early ecosystem map for Monad

As an industry, blockchain is just beginning to mature. Over time, blockchains will become more performant (and by then, I dont expect 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 techniques. This will ultimately push the space forward, allowing higher performance applications to be built. We will continue to push the limits of what is possible with blockchain and introduce additional infrastructure to support new implementations.

There is a lot of discussion on crypto Twitter about TPS as a general trading and voting trading indicator. 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 the chain: not just voting transactions. For Monads, we will not include voting in any TPS presentation.

Generally speaking, there is a lot of confusion about what should count as a real transaction. Many teams use different metrics to count transactions. The field right now is very inconsistent in how performance is advertised. For example, some people count one trade as one order. So if there is a single smart contract call that executes several sub-instructions, others will count it as ~10 transactions, which is actually incorrect.

All you can really measure is the number of transactions that go through the system. If at any given moment the system is not at full capacity, the actual observable TPS will be much lower. So theres a lot of confusion here as well.

I think the real solution is to have repeatable benchmarks in a GitHub repository. Each team is expected to contribute to this repository and push out a complete script that defines the process of deploying many different servers around the world. The script was then able to send a large number of transactions to various nodes in the system and actually reproduce a 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 process of scientific research, where you publish not only 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 what we intend to do.

Original link