From: thepipeline_xyz
Monad is a blockchain designed as a “full scratch redesign” of an EVM L1 equivalent blockchain that looks similar to Ethereum in shape [00:00:22]. It aims to provide a high-performance system for Ethereum applications [00:01:21], while maintaining full EVM RPC compatibility [00:01:02]. This means developers can port over existing contracts and tap into the EVM ecosystem [00:01:53].
High-Performance Metrics
Monad targets significant performance improvements over existing EVM chains:
- Transactions Per Second (TPS): 10,000 real historical Ethereum transactions per second (not just transfers) [00:00:39].
- Block Times: Single block times [00:00:58].
- Finality: Single slot finality [00:01:00].
- Transaction Costs: Hundreds of a cent for a Uniswap V2 transaction [00:01:30].
- Decentralization: Achieved by supporting hundreds of nodes globally with reasonable hardware requirements [00:01:36].
Addressing Blockchain Bottlenecks
Monad’s design addresses four fundamental constraints in distributed blockchain systems [00:02:12]:
- Network Bandwidth: The internet overhead for nodes [00:02:24]. Monad targets 100 megabits per second for a consumer full node, compared to 1 GB or 10 GB connections used by other blockchains [00:03:01].
- CPU Throughput: How fast the computer cores can run [00:02:28].
- State Access: The speed of accessing the database and historical state of the chain [00:02:33].
- State Growth: The ability to quickly pull up current accounts and their balances [00:02:38].
Many existing blockchains take shortcuts by increasing bandwidth requirements, placing nodes close together, or increasing RAM requirements, which makes nodes expensive and reduces decentralization [00:02:56]. Monad’s goal is to maximize performance from commodity hardware while preserving decentralization through a new software architecture [00:04:02].
New Software Architecture
Monad features a full redesign of its architecture, keeping only the EVM bytecode instructions [00:04:32]. Key components of this architecture include:
- Rebuilt Consensus (not detailed in this discussion) [00:04:56]
- Rebuilt Execution Engine [00:04:45]
- Parallel Execution [00:04:49]
- Custom State Database (Monad DB) [00:04:51]
Asynchronous Execution (Pipelining)
Traditional blockchains often use “interleaved execution,” where execution and consensus happen in tandem within a single block time [00:05:22]. For example, in Ethereum, execution might take 1% of the 12-second block time, with consensus taking significantly longer due to global network latency [00:05:35].
Monad’s “asynchronous execution” stems from the realization that execution can be decoupled from consensus [00:06:24]. Because the EVM is a deterministic state machine, if the ordering and data of transactions are known, the results will always be the same [00:06:37]. This allows Monad to pull execution out of the current block and perform it in tandem with the next block [00:07:07]. Essentially, Monad orders the current block while executing the previous block [00:07:20].
This approach means that consensus and execution operate on different sides of the block production process [00:07:32]. Monad comes to consensus on the data and its order, and then executes it afterward, in parallel with coming to consensus on the next block’s ordering [00:07:40]. This allows Monad to expand the execution budget, leading to higher throughput and lower fees [00:08:29].
Nodes come to consensus on transaction ordering prior to execution [00:08:52]. While nodes have a delayed view of the state, finality is achieved at consensus time because the deterministic nature of the EVM ensures that if the order and data are known, the outcome is final [00:09:48].
Parallel Execution
Parallel execution transforms a single processing lane into multiple lanes, leveraging modern computers’ multi-core CPUs [00:10:32]. While transactions are linearly ordered by consensus, Monad executes them in parallel and commits the results in their original order [00:10:59].
Monad uses “optimistic parallel execution,” also known as Software Transactional Memory or Optimistic Concurrency Control (OCC) [00:11:13]. The process is as follows:
- Start with a synced view of the world and assume all transactions can run in parallel [00:11:28].
- Generate a batch of pending results [00:11:33].
- Walk through the pending results in order, attempting to commit them [00:11:39].
- If a pending result relied on a previous one that was modified (a conflict), re-execute that transaction with the new state [00:11:43].
Due to the serial commitment process, no transaction needs to be re-executed more than once [00:13:16]. The overhead of re-execution is low because the most time-consuming part of a transaction is calling up the state from the database, not the execution itself [00:13:23]. State is cached, making re-execution light [00:13:50].
A benefit of this model is that developers do not need to deal with access lists, which simplifies development and reduces bandwidth overhead [00:13:59]. This provides a familiar EVM interface while maintaining backend performance [00:14:14].
Monad DB
Monad DB is Monad’s custom state database that enables parallel execution by providing parallel state access [00:14:29]. It ensures that the parallel execution engine remains saturated by providing asynchronous I/O, allowing many requests to the database in parallel [00:15:01].
Modern hard drives (SSDs) offer high bandwidth and millions of I/O operations per second, making it crucial to saturate this memory bandwidth [00:15:42].
Ethereum stores its state in a Merkle Patricia Trie (MPT), which enables succinct verification of transactions and state [00:16:32]. This allows checking a root hash to verify all data under it, without downloading and re-executing entire blocks [00:17:21]. However, most Ethereum clients use off-the-shelf databases (like B-trees or LSM trees) to store this MPT structure [00:16:45]. This creates a “tree traversal within a tree traversal” problem: logically traversing the MPT requires multiple lookups within the backend database, incurring 16 to 32 times more overhead [00:19:10].
Monad DB is a full rebuild of a database where the Merkle Patricia Trie is the native way data is stored on disk [00:19:42]. This removes the indirection, leading to 16 to 32 times fewer lookups per traversal of the state tree [00:20:10]. Combined with asynchronous I/O using kernel technology like IOU_ring, Monad DB can spawn many parallel lookups to feed the parallel execution engine efficiently [00:20:19]. This parallel state access, alongside parallel execution, is the “secret sauce” behind Monad’s performance [00:21:12].