From: thepipeline_xyz
Monad’s Performance Claims
Monad aims to deliver a blockchain with high performance, featuring 10,000 transactions per second (TPS), full 100% EVM compatibility, sub-cent gas fees, and hardware requirements similar to Ethereum itself [00:00:57]. These engineering feats have been considered impossible by many crypto participants [00:01:19].
Leveraging Modern Hardware
The foundation of Monad’s performance lies in effectively utilizing modern hardware [00:01:31]. Recent advancements in SSD drives and PCI Express (PCIe 4 and 5) offer impressive bandwidth, storage capacity, and low latency [00:01:31].
However, simply having powerful hardware is not enough. The key is to build software specifically designed to take advantage of these capabilities [00:01:53]. Relying on out-of-the-box database or file system software introduces significant algorithmic overhead and complexity, as these general-purpose tools are not optimized for specialized, high-performance use cases [00:02:00].
Specialized Software Development
Inspired by high-frequency trading (HFT) environments, Monad’s approach involves building everything from scratch at a very low level [00:03:00]. This means not relying on the operating system for core functionalities and deeply understanding how hardware behaves [00:03:00]. Different SSD drives, for example, exhibit varying behaviors, requiring extensive benchmarking and tuning to optimize performance [00:03:21]. This process is a massive undertaking, often consuming days or even weeks of engineering time to diagnose and resolve performance issues [00:03:43]. Nevertheless, achieving even a 10% increase in TPS makes the effort worthwhile [00:04:09].
Understanding EVM Usage Patterns
Optimizing an EVM-compatible blockchain also requires a deep understanding of how users interact with the EVM, including common patterns of ERC20 contracts and Uniswap [00:04:40]. This involves analyzing:
- Transaction patterns: How transactions access state and are scheduled [00:04:57].
- Autocorrelation: The likelihood of an account being used again soon if it has been used recently [00:05:10].
- Statistical Analysis: Determining the relevant time window for such patterns [00:05:24].
By analyzing these patterns, data structures can be arranged to capitalize on this information, rather than treating all data as uniformly accessed [00:05:41]. For instance, the majority of state accesses often involve a relatively small number of accounts [00:05:55]. This approach of continuous analytics and software refinement leads to ongoing improvement [00:06:04].
Development Stages: Devnet to Testnet
Monad’s development progresses through distinct stages, currently in a “devnet” phase with 10,000 TPS running internally [00:06:23]. The next macro step is launching a “testnet” [00:06:31].
- Devnet: An internal deployment where the software can be “a little rough around the edges” and boxes might require special, manual configuration [00:06:45].
- Testnet: Requires polishing the software into a product that external users can download, run, and support without needing developer intervention [00:07:11].
This transition involves streamlining processes and eliminating the need for manual communication between development and deployment teams [00:07:33]. Simultaneously, a significant portion of the team remains focused on continuous performance optimization, a process that is expected to continue for many years [00:07:51].
Why Layer 1 over Layer 2?
Monad’s decision to launch as a Layer 1 (L1) rather than a Layer 2 (L2) is based on several factors:
- Bandwidth Constraints: Existing data availability solutions for L2s often lack the necessary bandwidth. Monad’s first version targets a 100 megabit connection, translating to about 8 usable megabytes per second of data [00:08:50]. Current L2 data availability is not close to this, which would constrain Monad’s ability to utilize hardware fully [00:09:13].
- Complexity: Building a decentralized L2 involves significant complexity with many design trade-offs that can affect user experience (UX) or other aspects [00:09:29]. By building all internal components of Monad themselves in a somewhat modular fashion, they can avoid much of this complexity [00:09:50].
- Control and Performance: Being an L1 provides full control over the system, ensuring the necessary performance levels are met [00:10:40]. Launching as an L1 also simplifies decentralization and improves UX [00:10:48].
Competitive Advantage and Ground-Up Development
Monad’s competitive advantage stems from its team’s experience in HFT, which involves building low-latency systems [00:11:51]. Upon evaluating existing L1s (and later L2s), the team found that many had made different trade-offs or copied components, rather than building from the ground up [00:12:02]. Building from scratch provides more control and allows for the creation of a faster system when combined with specialized expertise [00:12:35].
Biggest Technical Challenge: The Database
The most significant technical challenge encountered during Monad’s development has been the database [00:13:12]. Unlike HFT systems, which typically operate in memory without touching disk for long periods [00:13:14], blockchain states can be tens to hundreds of gigabytes, necessitating disk storage [00:13:33].
This required the team to learn about new technologies they were not personally familiar with, including SSD internal architecture and state-of-the-art storage solutions [00:13:43]. Extensive experimentation and benchmarking of open-source databases like RocksDB, LevelDB, and LMDB were necessary to understand their limitations [00:14:09]. In contrast, the VM and transaction execution aspects were closer to their HFT background, making them easier to develop [00:14:27].
Unlocking New Use Cases
The Monad team is most excited about seeing new applications built on their high-performance blockchain [00:16:42]. The hope is that application teams will leverage Monad’s performance to build applications that were previously not feasible [00:16:53]. This validation of their work will also lead to learning opportunities through collaboration with application developers [00:17:06].
High performance in a blockchain not only allows for more users but also enables greater complexity within transactions and applications themselves [00:19:07]. This means an application per user can do more work than on a less performant chain [00:19:17]. The goal is to open up new application possibilities and use cases, allowing developers to build innovative solutions that ultimately benefit the user experience through speed, low fees, reliability, and the ability to land transactions [00:17:22] [00:19:39].