From: thepipeline_xyz
Monad is a blockchain platform described as a “full scratch redesign” [00:22:22] of the Ethereum Virtual Machine (EVM) architecture [00:30:17]. While maintaining full EVM RPC compatibility [01:02:12], allowing existing wallets and indexers to function seamlessly [01:07:35], Monad aims to significantly improve performance [00:38:23].
Performance and User Experience
Monad targets 10,000 transactions per second (TPS) [00:39:18], specifically meaning “real historical Ethereum transactions” [00:45:07], not merely simple transfers [00:43:53]. It offers single block times and single slot finality [00:58:32], and transaction costs are anticipated to be “hundreds of a cent for Uniswap V2 transaction” [01:30:46]. For developers, Monad is a “fully EVM equivalent L1” [01:50:35], making it possible to port existing contracts and leverage the EVM ecosystem [01:53:30].
Despite its high performance goals, Monad aims to maintain decentralization with “hundreds of nodes participating in consensus around the globe” [01:38:09], while keeping hardware requirements reasonable [01:42:37] [04:11:06]. This contrasts with other blockchains that achieve performance by requiring faster internet connections (e.g., 1 GB or 10 GB vs. Monad’s 100 Mbps target for a full node) [03:00:23] [03:08:48], placing nodes close together to reduce latency [03:23:42], or requiring significant RAM [03:39:07].
Core Technical Innovations
Monad’s performance is achieved through a new software architecture [04:20:00], rebuilding consensus, its execution engine, implementing parallel execution, and a custom state database called Monad DB [04:32:00]. The only component retained from standard EVM is the bytecode [04:37:34].
Asynchronous Execution
Most blockchains today, including Ethereum, use “interleaved execution” [05:20:00], where execution and consensus occur in tandem within a block time [05:29:05]. In Ethereum’s 12-second block time [05:35:05], execution takes only about 1% of the time, with consensus taking the majority due to global communication latency [05:46:04].
Monad employs “asynchronous execution” [06:20:00], which stems from the realization that execution can be pulled out of the current block’s consensus process [06:28:00]. Since the EVM is a deterministic state machine and the ordering and data of transactions are known [06:37:00], the execution results are predictable [06:45:00].
This means Monad orders the current block while simultaneously executing the previous block [07:15:00]. This separation allows consensus and execution to run on different timelines, effectively expanding the execution budget and gas budget [08:29:00], leading to higher throughput and lower fees [08:36:00]. Finality is achieved at consensus time because the transaction order and data are final [09:48:00].
Parallel Execution
Traditional blockchains linearly order and serially execute transactions [10:46:00]. Monad leverages modern multi-core hardware by implementing “optimistic parallel execution” [11:13:00], also known as software transactional memory (STM) or optimistic concurrency control (OCC) [11:17:00].
This method assumes all transactions can run in parallel, generates pending results, and then commits them in order [11:28:00]. If a transaction relied on a state change from a previous, conflicting transaction, it is re-executed with the updated state [11:43:00]. Because the most time-consuming part of transaction processing is fetching state from the database, not execution itself [13:25:00], the overhead of re-execution is minimal as the state is already cached [13:50:00]. This approach eliminates the need for developers to deal with “access lists,” simplifying the development experience while maintaining high performance [13:59:00].
Monad DB
Monad DB is a custom state database crucial for enabling parallel execution [14:29:00]. It allows for “parallel state access” [15:04:00], addressing the bottleneck where the system would otherwise wait for state dependencies to be pulled from the database for each transaction [15:10:00]. Monad DB uses “asynchronous IO” [15:25:00], allowing multiple requests to the database in parallel [15:27:00], ensuring the system’s compute resources are saturated [16:09:00].
Merkle Patricia Tries and Database Structure
Ethereum stores its state in a “Merkle Patricia Try” (MPT) [16:32:00]. This structure is fundamental to Ethereum’s philosophy of “succinct verification of transactions and state” [17:21:00], allowing users to quickly verify a block’s integrity by checking its root hash without downloading and re-executing the entire block [17:26:00].
However, traditional Ethereum clients (like Geth) use off-the-shelf databases (e.g., B-trees or LSM trees) to store the MPT [16:48:00]. This creates an inefficiency: when traversing the logical MPT, the underlying database must perform “tree traversal within a tree traversal” [19:20:00], requiring 16 to 32 times more lookups per traversal [19:36:00].
Monad DB is a full rebuild of a database where the Merkle Patricia Try is the native way data is stored on disk [19:42:00]. By removing this “tree indirection” [19:50:00], Monad DB makes state access significantly more efficient [20:10:00]. Combined with asynchronous IO (using kernel technology like IOUring) [20:58:00], this allows parallel state access to feed the parallel execution engine [21:10:00], which is the “secret sauce” for effective parallel execution [21:19:00].