From: thepipeline_xyz
Monad is a blockchain designed as a redesign from scratch, looking similar to Ethereum in shape, providing a full EVM L1 equivalent experience [00:00:22]. While often known as a “parallel EVM,” it encompasses much more [00:00:15].
Monad from a Developer Perspective
For developers, Monad is a fully EVM-equivalent L1 blockchain [00:01:50]. It allows developers to easily port over any existing contracts and tap into the existing EVM research and network effect [00:01:53].
Key features for developers include:
- High Performance: Aims for 10,000 transactions per second (TPS), referring to real historical Ethereum transactions, not just transfers [00:00:39]. This is achieved by running Ethereum state through the blockchain [00:00:49].
- Single Block Times and Single Slot Finality: Provides developers with rapid transaction finality [00:00:58].
- Full EVM RPC Compatibility: Anything developers are used to working with, such as wallets and indexers, works out of the box [00:01:02].
Monad from a User Perspective
From a user’s perspective, Monad serves as a platform where Ethereum applications can find a home and realize the vision of a “world computer” [00:01:18].
Key benefits for users include:
- High Performance and Low Cost: Transactions are very inexpensive, costing hundreds of a cent for a Uniswap V2 transaction [00:01:30].
- Decentralization: Monad maintains decentralization with hundreds of nodes participating in consensus globally [00:01:36].
- Reasonable Hardware Requirements: This decentralization is achieved while maintaining reasonable hardware requirements for nodes [00:01:41].
How Monad Achieves its Goals
Monad addresses fundamental constraints in distributed systems by designing software that maximizes the utility of commodity hardware while preserving decentralization [00:04:00].
Blockchain Bottlenecks and Traditional Approaches
Four fundamental constraints in a blockchain are:
- Network Bandwidth: Internet overhead [00:02:24].
- CPU Throughput: Speed of computer cores [00:02:28].
- State Access: Database and historical state of the chain [00:02:32].
- State Growth: Current accounts and their balances [00:02:38].
Before Monad, many blockchains achieved properties by taking shortcuts, such as:
- Requiring very high internet connections (e.g., 1 GB or 10 GB vs. Monad’s target of 100 megabits per second for a consumer full node) [00:02:56].
- Placing all nodes close together to reduce latency [00:03:22].
- Increasing RAM requirements, making nodes very expensive [00:03:39].
Monad’s New Software Architecture
Monad employs a new software architecture that is a full redesign, retaining only the EVM bytecode (instructions for how the EVM interprets code) [00:04:32]. This architecture includes:
- A fully rebuilt consensus [00:04:45].
- A fully rebuilt execution engine [00:04:47].
- Implemented parallel execution [00:04:49].
- A custom state database called Monad DB [00:04:51].
Asynchronous Execution
Most blockchains today use “interleaved execution,” where execution and consensus are done in tandem within a block time [00:05:16]. For example, in Ethereum, execution might take 1% of the 12-second block time, with consensus taking significantly longer due to global node communication [00:05:35].
Monad realizes that with a deterministic state machine like the EVM, where the ordering and data of transactions are known, execution can be pulled out of the current block and done in tandem with the next block [00:06:24]. This means:
- The current block is ordered while the previous block is being executed [00:07:20].
- Nodes come to consensus on transaction ordering prior to execution [00:08:52].
- They work on two blocks in parallel [00:08:57].
- Execution can take up the entire block time, not constrained by consensus time [00:08:11].
This approach greatly expands the “gas budget,” leading to higher throughput and lower fees [00:08:32]. Finality in Monad occurs at consensus time; a full node can run transactions locally as soon as consensus is reached for immediate state updates [00:09:48].
Parallel Execution
Parallel execution in Monad transforms a single processing lane into multiple lanes, leveraging modern multi-core CPUs [00:10:17]. While traditional blockchains execute transactions linearly and serially, Monad maintains the consensus-given ordering but executes everything in parallel to get results quicker, then commits them in the original order [00:10:59].
Monad uses optimistic parallel execution (also known as Software Transactional Memory or Optimistic Concurrency Control) [00:11:13]:
- Start with a synced view of the world [00:11:28].
- Assume everything can run in parallel and generate pending results [00:11:30].
- Walk through the pending results in order, attempting to commit them [00:11:37].
- If a pending result relied on a previous one that changed, re-execute it with the new state [00:11:43].
The overhead of re-execution is low because the state is cached, and fetching state from the database is the most time-consuming part, not the execution itself [00:13:23]. This model eliminates the need for access lists, reducing bandwidth overhead and providing a familiar EVM interface with parallel backend performance [00:13:59].
Monad DB (Custom State Database)
Monad DB is a custom state database that makes Monad’s parallel execution truly possible [00:14:27]. It feeds the parallel execution engine by allowing parallel state access [00:14:58].
The core challenge Monad DB addresses relates to how Ethereum stores state:
- Ethereum uses a Merkel Patricia Trie (MPT) for state, which allows for succinct verification of transactions and state [00:16:32].
- Other Ethereum clients typically use off-the-shelf backend databases (like B-trees or LSM trees) to store this MPT, which are not themselves MPTs [00:16:44].
- This creates a “tree traversal within a tree traversal” problem: when traversing the logical MPT, the system has to perform multiple lookups (16 to 32 times more overhead) in the physical, non-MPT backend database [00:19:12].
Monad DB is a full rebuild of a database where the Merkel Patricia Trie is the actual way data is stored on disk [00:19:42]. This removes the entire “tree indirection,” resulting in 16 to 32 times fewer lookups per tree traversal [00:19:50].
Combined with asynchronous I/O (using IO_Uring kernel technology), Monad DB can issue many parallel requests to the database, ensuring that the parallel execution engine is constantly saturated with data [00:20:19]. This parallel state access, alongside parallel execution, is the “secret sauce” behind Monad’s performance [00:21:16].