11 min read
Monad in Detail
Developers have been working to find scaling solutions for blockchains since their inception, and new solutions pop up periodically across various chains. Transactions per second (TPS) come to mind when settling on a critical metric to gauge scalability success when comparing solutions against each other, so read on to find some comparisons that might surprise you.
Regarding Web3 innovation, decentralized applications (dApps) are the answer to centralized services. However, dApps need an inexpensive infrastructure to operate and attract mass adoption. To put things in perspective, in 2022, the total daily global credit card transactions averaged 1.86 billion. That breaks down to an average of 21,510 TPS. A quick glance reveals that Ethereum only averages around 13 TPS, highlighting how far this industry has to go to win global adoption.
Monad is one such blockchain that improves Ethereum Virtual Machine (EVM) compatible blockchain performance while pioneering innovation. The former team from Jump Trading (a big player in traditional finance) founded the tech startup Monad Labs. It raised $19 million in seed funding led by crypto VC firm Dragonfly Capital and 70 other investors.
We have enjoyed exploring Monad’s unique no-frills approach before. We shall now take a closer look at its working. This article will examine the unique, innovative qualities driving this new blockchain to improve scalability issues that Layer 1 chains like Ethereum face.
Monad is an EVM-compatible Layer-1 blockchain. From a performance standpoint, it offers 10,000 TPS of throughput, one-second block times, and one-second finality. That's quite a step up from Ethereum's 13 TPS. But Ethereum was the first blockchain to enable programmable smart contracts meaningfully, and Monad is like Ethereum in that it features blocks and linear ordering of transactions within each block.
Furthermore, Monad is EVM-compatible, so users won't notice a difference when migrating. From a user's perspective, Monad behaves like Ethereum. Wallets like Metamask and block explorers like Etherscan all work the same. As far as developers are concerned, since Monad is bytecode compatible, they can take dApps built for Ethereum and easily port them to Monad without code changes.
Two critical components of a smart contract blockchain are the virtual machine (VM) and the consensus mechanism. The consensus mechanism allows a global network of nodes to reach an agreement on the state of the network. The VM executes the application code and updates the global account balances.
Execution is a prerequisite to consensus in Ethereum. Hence, the leader node must execute all the transactions in a proposed block before sharing the proposal, and validator nodes must execute the transactions before responding with their vote. In this model, execution happens twice, thus squeezing the time budget to leave enough time for consensus.
Like Ethereum, Monad is a proof-of-stake (PoS) blockchain maintained by a decentralized set of validators and nodes. In most blockchain networks, such as Ethereum, reaching consensus and executing transactions are processes that happen in sequence. Consensus ensures all nodes agree on the transaction order, maintaining the network's integrity. Execution involves verifying and applying transactions to update the blockchain's state. This sequence guarantees that only valid transactions are included but can slow down the network as it scales.
Monad introduces a novel approach by separating the consensus on transaction order from their execution. This means nodes agree on the order of transactions without executing them first, aiming to improve scalability by speeding up the consensus process. This decoupling allows Monad to process more transactions efficiently, assuming the network's final state is implicitly agreed upon once the order is set, even if the transactions haven't been executed yet.
The leader node proposes an ordering of transactions without knowing what the resultant state root is. Further, validator nodes vote on block validity without knowing if all the block's transactions execute without reverting. The question is, why would Monad do this? Well, this feature is a cornerstone of Monad's design, allowing it to unlock speed constraints to help its blockchain scale to millions of users.
The critical insight here is that the true state is already determined after obtaining an official ordering of transactions. So, even though execution is required to unveil the truth, the truth is already out there. Monad takes advantage of this insight and removes the requirement that nodes must execute before consensus occurs.
However, this model does raise some objections. What happens if a node is malicious or makes a mistake and doesn't execute the transactions specified in consensus?
Monad would argue that when a user submits a transaction, they will see the transaction's official order after a single block. The only potential for reordering of transactions would be a malicious action from a supermajority of the network.
Determining a transaction's execution outcome (success or failure and the balances afterwards) lags finality by one second or less on full nodes. So, users who need to know a transaction's outcome quickly (like high-frequency traders) can run a full node. Others who need to query a transaction's outcome without running a full node can run a light client to query a full node for balances.
To sum up, Ethereum strictly enforces state machine replication. Once nodes come to a consensus, the supermajority agrees on the official ordering of transactions and the state that results from that ordering. However, this rigid strictness comes at the cost of limited throughput. Monad seeks to loosen that belt of strictness, making its finality much quicker than Ethereum's.
All EVM chains have the same weakness—sequential execution. Did you know that the EVM can only execute one transaction at a time? Because sequential execution is simple, it's a good starting point for blockchains but also inefficient in the long term.
Developers discovered this bottleneck and have tried fixing it with parallel execution. This concept is based on the fact that if two transactions are independent, then these transactions can be parallelized. And that is what Monad is doing. The team is building a high-performance, EVM-compatible Layer 1 blockchain that enables parallel execution.
Hence, we know that Monad executes transactions in parallel. However, it only enables parallel execution for transactions that lack common dependencies. Some cases of transaction dependencies are more evident than others. For example, a basic token transfer between two parties only affects those two addresses. However, multiple transactions that interact with the same smart contract cannot be executed in parallel because they can change the state.
So, blocks and the transactions within are still linearly ordered. But Monad singles out transactions within that ordering that can be executed in parallel as long as they don't disrupt the outcome. This type of execution allows Monad to process transactions efficiently without disrupting developers who originally coded their dApps for Ethereum.
At first glance, it might look entirely different from the execution semantics on Ethereum. But that's not the case. Monad and Ethereum’s blocks are the same—a linearly ordered set of transactions. Even the result of executing the transactions in a block is the same. Regardless of what happens under the hood, the result for the user is that a series of transactions act as if they'd been executed sequentially, only much quicker.
Monad also employs optimistic execution. This means that transactions will begin executing in the block before prior transactions have been completed. Sometimes, this can result in incorrect execution. Consider these two transactions in this order in the block:
Transaction 1
Account A receives a transfer from account B.
Transaction 2
Account A makes a transfer to Account C.
So, Transactions 1 and 2 read and update the balance of account A. But by running these transactions in parallel, Transaction 2 starts running before Transaction 1 finishes. In this case, the balance it reads for account A may differ if these transactions ran sequentially. Hence, we could get an incorrect execution.
Optimistic execution solves this potential problem by tracking the inputs used while executing Transaction 2. It then compares these inputs to Transaction 1's outputs. If they differ, it's clear that Transaction 2 used incorrect data while executing. Therefore, it needs to be executed again with the correct data. In other words, although Monad executes parallel transactions, it merges the updated state for each transaction sequentially to check the data.
Monad makes exceptional performance possible by introducing not only parallel execution but also superscalar pipelining. Pipelined architecture is its core difference from most blockchains. Pipelining uses a staggered approach to carry out each process rather than sequentially.
Superscalar pipelining involves putting work into stages and executing the stages in parallel. An analogy its website uses is the laundry process. A purely sequential strategy would include completing the entire process (washing, drying, folding, and storing) on the first wash load before starting on the second load. However, a pipelined strategy would entail putting the second load in the washer immediately after removing the first load to put it into the dryer.
Monad uses pipelining to overcome bottlenecks in transaction processing, state storage, and distributed consensus. Thus, it uses parallel execution and pipelining while keeping blocks and transactions within each block linearly ordered.
Monad achieves parallel execution and pipelining with the following innovative features:
A high-performance consensus mechanism.
Custom database for storing blockchain state.
This unique feature of the Monad blockchain decouples execution from consensus.
The team often explores the distinction between the Monad blockchain and Layer 2 Rollups, particularly regarding the decision not to transform Monad into a Rollup. This choice hinges on several factors, with a focus on optimizing for different strengths.
Layer 1 blockchains, like Monad, and Layer 2 Rollups serve distinct functions within the blockchain ecosystem. Layer 1s are foundational, hosting smart contracts and accounts, and employing consensus mechanisms to maintain synchrony across nodes, ensuring a unified transaction order.
Rollups, on the other hand, operate atop these Layer 1 blockchains to enhance scalability and efficiency. They batch transactions into a single submission, reducing the load on the main chain by handling transactions off-chain and periodically committing state changes back to Layer 1. This process involves the use of cryptographic proofs to ensure the integrity of transaction execution, with ZK-Rollups using validity proofs and Optimistic Rollups relying on a challenge period to verify transactions.
Rollups are designed to leverage the security and decentralization of their underlying Layer 1 blockchain while providing a more scalable solution for dApp developers and users. They achieve this by committing compressed transaction data and Merkle roots to a Layer 1 blockchain, ensuring data availability and the ability to reconstruct the state independently.
The choice for Monad not to become a Rollup, centres on its architectural and design priorities. Monad is built with a focus on decentralization and a pipelined architecture that enhances its native processing capabilities. This approach is aimed at maintaining a high degree of decentralization and censorship resistance, core principles of the Monad team's vision for blockchain technology.
Moreover, Monad's unique architectural decisions, such as its custom storage backend, are designed to optimize its performance and scalability as a standalone Layer 1 blockchain. These features are intended to ensure that Monad nodes operate with exceptional efficiency, supporting the network's scalability and responsiveness.
In summary, the decision for Monad to remain a Layer 1 blockchain instead of adopting a Rollup structure is driven by its strategic focus on decentralization, performance, and scalability. This approach allows Monad to contribute to the blockchain ecosystem in its unique way, complementing the role of Layer 2 Rollups in enhancing the overall scalability and efficiency of blockchain applications.
Monad has redesigned the EVM execution system for non-overlapping transactions to run in parallel. The team also reconfigured the integration system for the blockchain's execution layer to run parallel to consensus.
From there, Monad layers have more optimization improvements through parallel execution, deferred execution, a high-performance consensus mechanism, and the fully custom Monad Database. As for pipelining, it already exists in non-EVM blockchains like Sui, Solana, and Aptos, but Monad is making it available in an EVM-compatible way.
Ethereum still rules the roost in Layer 1 market share. Still, new competition like Solana, Cardano, and Avalanche (dubbed "Ethereum Killers") continue to rise to challenge its processing time, fees, and scalability. Monad, with its team's experience in TradFi, is looking for opportunities to build a Layer 1 that can attract the attention of more traditional financial institutions.
Luganodes is a world-class, Swiss-operated, non-custodial blockchain infrastructure provider that has rapidly gained recognition in the industry for offering institutional-grade services. It was born out of the Lugano Plan B Program, an initiative driven by Tether and the City of Lugano. Luganodes maintains an exceptional 99.9% uptime with round-the-clock monitoring by SRE experts. With support for 45+ PoS networks, it ranks among the top validators on Polygon, Polkadot, Sui, and Tron. Luganodes prioritizes security and compliance, holding the distinction of being one of the first staking providers to adhere to all SOC 2 Type II, GDPR, and ISO 27001 standards as well as offering Chainproof insurance to institutional clients.