![keoneHD's tweet photo. How Monad Works
Summary / Network Parameters
- Monad is EVM bytecode-equivalent (you can redeploy bytecode without recompilation)
- Cancun fork (TSTORE, TLOAD, MCOPY) is supported
- Opcode to gas units mapping is same as Ethereum (e.g. ADD is 4)
- RPC conforms to geth's RPC interface
- Blocks are every 500 ms
- Finality occurs in 1 second; finality of block N occurs at the proposal of block N+2
- Block gas limit in testnet is 150 million gas, i.e. gas rate is 300 million gas/s. This will increase over time
- 100-200 validators expected in consensus
- on Day 1 of testnet, Monad will have about 55 globally-distributed validators
Frugality / Impact on Decentralization
The driving goal of Monad is to have better software algorithms for consensus and execution, offering high performance while preserving decentralization
These algorithms deliver high performance while relying on nodes with relatively modest hardware:
- 32 GB of RAM
- 2x 2 TB SSDs
- 100 Mbps of bandwidth
- a 16-core 4.5 GHz processor like the AMD Ryzen 7950X
You can assemble this machine for about $1500
These algorithms deliver high performance while maintaining a fully-globally-distributed validator set and stake weight distribution
There isn’t a reliance on a supermajority in one geographic region - one would think this is an obvious expectation but many “high-performance” L1s actually derive their performance from having a supermajority of stake weight in close proximity
Node
Monad node has 3 components:
- monad-bft [consensus]
- monad-execution [execution + state]
- monad-rpc [handling user reads/writes]
- Network is 100-200 voting nodes (we’ll call them “validators” for the rest of this doc)
- Non-voting full nodes listen to network traffic
- All nodes execute all transactions and have full state
Consensus Mechanism
Overall consensus mechanism is MonadBFT.
MonadBFT has linear communication complexity which allows it to scale to far more nodes than quadratic-complexity algorithms like CometBFT
In the happy path, it follows the pattern of “one-to-many-to-one” or “fan out, fan in”:
- Leader (Alice) broadcasts a signed block proposal to all other nodes (fan out), who acknowledge its validity by sending a signed attestation the next leader Bob (fan in).
- Bob aggregates the attestations into a “Quorum Certificate” (QC)
- Attestation signatures use the BLS signature scheme for ease of aggregation
- Bob broadcasts the QC to all the nodes, who attest to receiving it by sending a message to the 3rd leader (Charlie) who aggregates the attestations into a QC-on-QC
- Charlie sends the QC-on-QC to everyone. Upon receiving the QC-on-QC, everyone knows that Alice’s block has been finalized
In the above story, Bob and Charlie are only sending out QCs or QCs-on-QCs, but in reality the proposals are pipelined:
- Bob’s message contains both the QC for Alice’s block and also the contents of a new block.
- Charlie’s message contains the QC for Bob’s block (which is a QC-on-QC for Alice’s block) and also contains the transactions for a new block
When validators send an attestation for Bob’s message they are attesting to both the validity of Bob’s block and the validity of the QC
This pipelining raises the throughput of the network since every slot a new block gets produced.
The below diagram shows how MonadBFT reaches consensus. Pipelining is tracked at the top:
See the docs for a fuller description. Obvious questions addressed there are:
- How the network handles the unhappy path where Bob doesn’t get enough a supermajority of attestations
- How the above mechanism results in nodes being sure that the block has been finalized once they have received the QC-on-QC
RaptorCast
MonadBFT requires the leader to directly send blocks to every validator
However, blocks may be quite large: 10,000 transactions/s * 200 bytes/tx = 2 MB/s. Sending directly to 200 validators would require 400 MB/s (3.2 Gbps).
We don’t want validators to have to have such high upload bandwidth
RaptorCast is a specialized messaging protocol which solves this problem
In RaptorCast, a block is erasure-coded to produce a bunch of smaller chunks
In erasure coding, the total size of all of the chunks is greater than the original data (by a multiplicative factor) but the original data can be restored using (almost) any combination of chunks whose total size matches the original data’s size
For example, a 1000 kb block erasure-coded with a multiplicative factor of 3 might produce 150 20kb chunks, but (roughly) any 50 of the chunks can reassemble the original message
RaptorCast uses a variant of Raptor codes as the encoding mechanism
In RaptorCast, each chunk is sent to one validator who is tasked with sending the chunk to every other validator in the network
That is, each chunk follows a two-level broadcast tree where the leader is the root, one other validator is at the first level, and all other validators are on the second level
Validators are assigned chunks prorata to their stake weight
Here's a diagram showing the RaptorCast protocol: each validator serves as a first-hop recipient for a range of chunks, and broadcasts those chunks to every other validator:
Raptorcast properties:
- Using the two-level broadcast tree ensures that message delivery occurs within 2x the longest hop
- Upload bandwidth for the leader is limited to the block size times the replication factor (roughly 2)
- Since chunks are assigned pro-rata to stake weight, and BFT assumes no more than 33% of stake is malicious, at most 33% of chunks could fail to reach their recipients. With a replication factor of 2x, nodes can reconstruct the original block despite a maximum 33% loss.
Transaction Lifecycle
- User submits pending transaction to RPC node
- RPC node sends pending transaction to next 3 leaders based on the leader schedule
- Pending transaction gets added to those leaders’ local mempools
- Leader adds transaction to their block as they see fit [default: they order by descending fee-per-gas-unit, i.e. Priority Gas Auction]
- Leader proposes block, which is confirmed by the network as mentioned above
Note: directly forwarding to upcoming leaders (as opposed to flood forwarding to all nodes) greatly reduces traffic. Flood forwarding would take up the entire bandwidth
Note: in the future, a behavior is being considered where leaders forward pending transactions (that they weren’t able to include in their block) to the next leader
Leader Election
- Leaders in the current testnet are permissioned. Staking will be added shortly
- An epoch occurs roughly once per day. Validator stake weights are locked in one epoch ahead (i.e. any changes for epoch N+1 must be registered prior to the start of epoch N)
- At the start of each epoch, each validator computes the leader schedule based on running a deterministic pseudorandom function on the stake weights. Since the function is deterministic everyone arrives at the same leader schedule
Asynchronous Execution
Monad pipelines consensus and execution, moving execution out of the hot path of consensus into a separate swim lane and allowing execution to utilize the full block time.
- Consensus is reached prior to execution
- Leader & validators check transaction validity (valid signature; valid nonce; submitter can pay for the data cost of the transaction being transmitted), but are not required to execute the transactions prior to voting.
- After a block is finalized, it is executed; meanwhile consensus is already proceeding on subsequent blocks
This is in contrast to most blockchains, which have interleaved execution.
One way to understand the impact of asynchronous execution is to recognize that, in interleaved execution, the execution budget is necessarily a small fraction of the block time since in interleaved execution, the leader must execute the transactions before proposing the block, and validators must execute before responding
For a 500 ms block time, almost all of the time will be budgeted for multiple rounds of cross-globe communication, leaving only a small fraction of the time for execution
The below diagram contrasts interleaved execution with asynchronous execution. Blue rectangles correspond to time spent on execution while orange rectangles correspond to time spent on consensus.
The budget for execution is much larger in async execution.
Delayed merkle root
Due to async execution, Monad block proposals don’t include the merkle root of the state trie, since that would require execution to have already completed.
All nodes should stay in sync because they’re all starting from the same point and doing the same work.
But it’d be nice to be sure! As a precaution, proposals in Monad also include a delayed merkle root from D blocks ago, allowing nodes to detect if they have diverged. D is a systemwide parameter, currently set to 3.
If any of the validators makes a computation error (cosmic rays?) when computing the state root at block N, it will realize that it possibly erred by block N+D (since the delayed merkle root for N contained in that block differs from its local view).
The validator then needs to wait until N+D+2 to see if 2/3 of the stake weight finalizes the block proposal at N+D (in which case the local node made an error) or if the block gets rejected (in which case the leader made the error).
Block stages
Assume that a validator has just received block N. We say that:
- Block N is ‘proposed’
- Block N-1 is ‘voted’
- Block N-2 is ‘finalized’ (because block N carries the QC-on-QC of block N-2)
- Block N-2-D is ‘verified’ (because block N-2 carries the merkle root post the transactions in block N-2-D, and block N-2 is the last block that has been finalized)
Note that unlike Ethereum, only one block at height N is proposed and voted on, avoiding retroactive block reorganization due to competing forks
Speculative execution
Although only block N-2 is ‘finalized’ and can officially be executed, nodes have a strong suspicion that the lists of transactions in block N-1 and block N are likely to become the finalized lists
Therefore, nodes speculatively execute the transactions included in each new proposed block, storing a pointer to the state trie post those transactions. In the event that a block ends up not being finalized, the pointer is discarded, undoing the execution
Speculative execution allows nodes to (likely) have the most up-to-date state, which helps users simulate transactions correctly
Optimistic parallel execution
Like in Ethereum, blocks are linearly ordered, as are transactions. That means that the true state of the world is the state arrived at by executing all transactions one after another
In Monad, transactions are executed optimistically in parallel to generate pending results. A pending result contains the list of storage slots that were read (SLOADed) and written (SSTOREd) during the course of that execution. We refer to these slots as “inputs” and “outputs”
Pending results are committed serially, checking that each pending result’s inputs are still valid, and re-executing if an input has been invalidated. This serial commitment ensures that the result is the same as if the transactions were executed serially
Here's an example of how Optimistic Parallel Execution works:
Assume that prior to the start of a block, the following are the USDC balances:
- Alice: 1000 USDC
- Bob: 0 USDC
- Charlie: 400 USD
(Note also that each of these balances corresponds to 1 storage slot, since each is 1 key-value pair in a mapping in the USDC contract.)
Two transactions appear as transaction 0 and 1 in the block:
- Transaction 0: Alice sends 100 USDC to Bob
- Transaction 1: Alice sends 100 USDC to Charlie
Then optimistic parallel execution will produce two pending results:
- PendingResult0:
* Inputs: Alice = 1000 USDC, Bob = 0 USDC
* Outputs: Alice = 900 USDC; Bob = 100 USDC
- PendingResult 1:
* Inputs: Alice = 1000 USDC; Charlie = 400 USDC
* Outputs: Alice = 900 USDC, Charlie = 500 USDC
When we go to commit these pending results:
- PendingResult 0 is committed successfully, changing the official state to Alice = 900, Bob = 100, Charlie = 400
- PendingResult 1 cannot be committed because now one of the inputs conflicts (Alice was assumed to have 1000, but actually has 900)
So transaction 1 is re-executed
Final result:
- Alice: 800 USDC
- Bob: 100 USDC
- Charlie: 500 USDC
Note that in optimistic parallel execution, every transaction gets executed at most twice - once optimistically, and (at most) once when it is being committed
Re-execution is typically cheap because storage slots are usually in cache. It is only when re-execution triggers a different codepath (requiring a different slot) that execution has to read a storage slot from SSD
MonadDb
As in Ethereum, state is stored in a merkle trie. There is a custom database, MonadDb, which stores merkle trie data natively
This differs from existing clients [which embed the merkle trie inside of a commodity database which itself uses a tree structure]
MonadDb is a significant optimization because it eliminates a level of indirection, reduces the number of pages read from SSD in order to perform one lookup, allows for async I/O, and allows the filesystem to be bypassed
State access [SLOAD and SSTORE] is the biggest bottleneck for execution, and MonadDb is a significant unlock for state access because:
- it reduces the number of iops to read or write one value
- it makes recomputing the merkle root a lot faster
- and it supports many parallel reads which the parallel execution system can take advantage of
Synergies between optimistic parallel execution and MonadDb
Optimistic parallel execution can be thought of as surfacing many storage slot dependencies – all of the inputs and outputs of the pending results – in parallel and pulling them into the cache
Even in the worst case where every pending result’s inputs are invalidated and the transaction has to be re-executed, optimistic parallel execution is still extremely useful by “running ahead” of the serial commitment and pulling many storage slots from SSD
This makes optimistic parallel execution and MonadDb work really well together, because MonadDb provides fast asynchronous state lookups while optimistic parallel execution cues up many parallel reads from SSD
Bootstrapping a node (Statesync/Blocksync)
High throughput means a long transaction history which makes replaying from genesis challenging
Most node operators will prefer to initialize their nodes by copying over recent state from other nodes and only replaying the last mile. This is what statesync accomplishes
In statesync, a synchronizing node (“client”) provides their current view’s version and a target version and asks other nodes (“servers”) to help it progress from the current view to the target version
MonadDb has versioning on each node in the trie. Servers use this version information to identify which trie components need to be sent
Nodes can also request blocks from their peers in a protocol called blocksync. This is used if a block is missed (not enough chunks arrived), as well as when executing the “last mile” after statesync completes (since more blocks will have come in since the start of statesync)
Thanks for reading and be sure to check out the docs](https://pbs.twimg.com/media/GkDKUriXYAA91Hy.jpg)
![keoneHD's tweet photo. How Monad Works
Summary / Network Parameters
- Monad is EVM bytecode-equivalent (you can redeploy bytecode without recompilation)
- Cancun fork (TSTORE, TLOAD, MCOPY) is supported
- Opcode to gas units mapping is same as Ethereum (e.g. ADD is 4)
- RPC conforms to geth's RPC interface
- Blocks are every 500 ms
- Finality occurs in 1 second; finality of block N occurs at the proposal of block N+2
- Block gas limit in testnet is 150 million gas, i.e. gas rate is 300 million gas/s. This will increase over time
- 100-200 validators expected in consensus
- on Day 1 of testnet, Monad will have about 55 globally-distributed validators
Frugality / Impact on Decentralization
The driving goal of Monad is to have better software algorithms for consensus and execution, offering high performance while preserving decentralization
These algorithms deliver high performance while relying on nodes with relatively modest hardware:
- 32 GB of RAM
- 2x 2 TB SSDs
- 100 Mbps of bandwidth
- a 16-core 4.5 GHz processor like the AMD Ryzen 7950X
You can assemble this machine for about $1500
These algorithms deliver high performance while maintaining a fully-globally-distributed validator set and stake weight distribution
There isn’t a reliance on a supermajority in one geographic region - one would think this is an obvious expectation but many “high-performance” L1s actually derive their performance from having a supermajority of stake weight in close proximity
Node
Monad node has 3 components:
- monad-bft [consensus]
- monad-execution [execution + state]
- monad-rpc [handling user reads/writes]
- Network is 100-200 voting nodes (we’ll call them “validators” for the rest of this doc)
- Non-voting full nodes listen to network traffic
- All nodes execute all transactions and have full state
Consensus Mechanism
Overall consensus mechanism is MonadBFT.
MonadBFT has linear communication complexity which allows it to scale to far more nodes than quadratic-complexity algorithms like CometBFT
In the happy path, it follows the pattern of “one-to-many-to-one” or “fan out, fan in”:
- Leader (Alice) broadcasts a signed block proposal to all other nodes (fan out), who acknowledge its validity by sending a signed attestation the next leader Bob (fan in).
- Bob aggregates the attestations into a “Quorum Certificate” (QC)
- Attestation signatures use the BLS signature scheme for ease of aggregation
- Bob broadcasts the QC to all the nodes, who attest to receiving it by sending a message to the 3rd leader (Charlie) who aggregates the attestations into a QC-on-QC
- Charlie sends the QC-on-QC to everyone. Upon receiving the QC-on-QC, everyone knows that Alice’s block has been finalized
In the above story, Bob and Charlie are only sending out QCs or QCs-on-QCs, but in reality the proposals are pipelined:
- Bob’s message contains both the QC for Alice’s block and also the contents of a new block.
- Charlie’s message contains the QC for Bob’s block (which is a QC-on-QC for Alice’s block) and also contains the transactions for a new block
When validators send an attestation for Bob’s message they are attesting to both the validity of Bob’s block and the validity of the QC
This pipelining raises the throughput of the network since every slot a new block gets produced.
The below diagram shows how MonadBFT reaches consensus. Pipelining is tracked at the top:
See the docs for a fuller description. Obvious questions addressed there are:
- How the network handles the unhappy path where Bob doesn’t get enough a supermajority of attestations
- How the above mechanism results in nodes being sure that the block has been finalized once they have received the QC-on-QC
RaptorCast
MonadBFT requires the leader to directly send blocks to every validator
However, blocks may be quite large: 10,000 transactions/s * 200 bytes/tx = 2 MB/s. Sending directly to 200 validators would require 400 MB/s (3.2 Gbps).
We don’t want validators to have to have such high upload bandwidth
RaptorCast is a specialized messaging protocol which solves this problem
In RaptorCast, a block is erasure-coded to produce a bunch of smaller chunks
In erasure coding, the total size of all of the chunks is greater than the original data (by a multiplicative factor) but the original data can be restored using (almost) any combination of chunks whose total size matches the original data’s size
For example, a 1000 kb block erasure-coded with a multiplicative factor of 3 might produce 150 20kb chunks, but (roughly) any 50 of the chunks can reassemble the original message
RaptorCast uses a variant of Raptor codes as the encoding mechanism
In RaptorCast, each chunk is sent to one validator who is tasked with sending the chunk to every other validator in the network
That is, each chunk follows a two-level broadcast tree where the leader is the root, one other validator is at the first level, and all other validators are on the second level
Validators are assigned chunks prorata to their stake weight
Here's a diagram showing the RaptorCast protocol: each validator serves as a first-hop recipient for a range of chunks, and broadcasts those chunks to every other validator:
Raptorcast properties:
- Using the two-level broadcast tree ensures that message delivery occurs within 2x the longest hop
- Upload bandwidth for the leader is limited to the block size times the replication factor (roughly 2)
- Since chunks are assigned pro-rata to stake weight, and BFT assumes no more than 33% of stake is malicious, at most 33% of chunks could fail to reach their recipients. With a replication factor of 2x, nodes can reconstruct the original block despite a maximum 33% loss.
Transaction Lifecycle
- User submits pending transaction to RPC node
- RPC node sends pending transaction to next 3 leaders based on the leader schedule
- Pending transaction gets added to those leaders’ local mempools
- Leader adds transaction to their block as they see fit [default: they order by descending fee-per-gas-unit, i.e. Priority Gas Auction]
- Leader proposes block, which is confirmed by the network as mentioned above
Note: directly forwarding to upcoming leaders (as opposed to flood forwarding to all nodes) greatly reduces traffic. Flood forwarding would take up the entire bandwidth
Note: in the future, a behavior is being considered where leaders forward pending transactions (that they weren’t able to include in their block) to the next leader
Leader Election
- Leaders in the current testnet are permissioned. Staking will be added shortly
- An epoch occurs roughly once per day. Validator stake weights are locked in one epoch ahead (i.e. any changes for epoch N+1 must be registered prior to the start of epoch N)
- At the start of each epoch, each validator computes the leader schedule based on running a deterministic pseudorandom function on the stake weights. Since the function is deterministic everyone arrives at the same leader schedule
Asynchronous Execution
Monad pipelines consensus and execution, moving execution out of the hot path of consensus into a separate swim lane and allowing execution to utilize the full block time.
- Consensus is reached prior to execution
- Leader & validators check transaction validity (valid signature; valid nonce; submitter can pay for the data cost of the transaction being transmitted), but are not required to execute the transactions prior to voting.
- After a block is finalized, it is executed; meanwhile consensus is already proceeding on subsequent blocks
This is in contrast to most blockchains, which have interleaved execution.
One way to understand the impact of asynchronous execution is to recognize that, in interleaved execution, the execution budget is necessarily a small fraction of the block time since in interleaved execution, the leader must execute the transactions before proposing the block, and validators must execute before responding
For a 500 ms block time, almost all of the time will be budgeted for multiple rounds of cross-globe communication, leaving only a small fraction of the time for execution
The below diagram contrasts interleaved execution with asynchronous execution. Blue rectangles correspond to time spent on execution while orange rectangles correspond to time spent on consensus.
The budget for execution is much larger in async execution.
Delayed merkle root
Due to async execution, Monad block proposals don’t include the merkle root of the state trie, since that would require execution to have already completed.
All nodes should stay in sync because they’re all starting from the same point and doing the same work.
But it’d be nice to be sure! As a precaution, proposals in Monad also include a delayed merkle root from D blocks ago, allowing nodes to detect if they have diverged. D is a systemwide parameter, currently set to 3.
If any of the validators makes a computation error (cosmic rays?) when computing the state root at block N, it will realize that it possibly erred by block N+D (since the delayed merkle root for N contained in that block differs from its local view).
The validator then needs to wait until N+D+2 to see if 2/3 of the stake weight finalizes the block proposal at N+D (in which case the local node made an error) or if the block gets rejected (in which case the leader made the error).
Block stages
Assume that a validator has just received block N. We say that:
- Block N is ‘proposed’
- Block N-1 is ‘voted’
- Block N-2 is ‘finalized’ (because block N carries the QC-on-QC of block N-2)
- Block N-2-D is ‘verified’ (because block N-2 carries the merkle root post the transactions in block N-2-D, and block N-2 is the last block that has been finalized)
Note that unlike Ethereum, only one block at height N is proposed and voted on, avoiding retroactive block reorganization due to competing forks
Speculative execution
Although only block N-2 is ‘finalized’ and can officially be executed, nodes have a strong suspicion that the lists of transactions in block N-1 and block N are likely to become the finalized lists
Therefore, nodes speculatively execute the transactions included in each new proposed block, storing a pointer to the state trie post those transactions. In the event that a block ends up not being finalized, the pointer is discarded, undoing the execution
Speculative execution allows nodes to (likely) have the most up-to-date state, which helps users simulate transactions correctly
Optimistic parallel execution
Like in Ethereum, blocks are linearly ordered, as are transactions. That means that the true state of the world is the state arrived at by executing all transactions one after another
In Monad, transactions are executed optimistically in parallel to generate pending results. A pending result contains the list of storage slots that were read (SLOADed) and written (SSTOREd) during the course of that execution. We refer to these slots as “inputs” and “outputs”
Pending results are committed serially, checking that each pending result’s inputs are still valid, and re-executing if an input has been invalidated. This serial commitment ensures that the result is the same as if the transactions were executed serially
Here's an example of how Optimistic Parallel Execution works:
Assume that prior to the start of a block, the following are the USDC balances:
- Alice: 1000 USDC
- Bob: 0 USDC
- Charlie: 400 USD
(Note also that each of these balances corresponds to 1 storage slot, since each is 1 key-value pair in a mapping in the USDC contract.)
Two transactions appear as transaction 0 and 1 in the block:
- Transaction 0: Alice sends 100 USDC to Bob
- Transaction 1: Alice sends 100 USDC to Charlie
Then optimistic parallel execution will produce two pending results:
- PendingResult0:
* Inputs: Alice = 1000 USDC, Bob = 0 USDC
* Outputs: Alice = 900 USDC; Bob = 100 USDC
- PendingResult 1:
* Inputs: Alice = 1000 USDC; Charlie = 400 USDC
* Outputs: Alice = 900 USDC, Charlie = 500 USDC
When we go to commit these pending results:
- PendingResult 0 is committed successfully, changing the official state to Alice = 900, Bob = 100, Charlie = 400
- PendingResult 1 cannot be committed because now one of the inputs conflicts (Alice was assumed to have 1000, but actually has 900)
So transaction 1 is re-executed
Final result:
- Alice: 800 USDC
- Bob: 100 USDC
- Charlie: 500 USDC
Note that in optimistic parallel execution, every transaction gets executed at most twice - once optimistically, and (at most) once when it is being committed
Re-execution is typically cheap because storage slots are usually in cache. It is only when re-execution triggers a different codepath (requiring a different slot) that execution has to read a storage slot from SSD
MonadDb
As in Ethereum, state is stored in a merkle trie. There is a custom database, MonadDb, which stores merkle trie data natively
This differs from existing clients [which embed the merkle trie inside of a commodity database which itself uses a tree structure]
MonadDb is a significant optimization because it eliminates a level of indirection, reduces the number of pages read from SSD in order to perform one lookup, allows for async I/O, and allows the filesystem to be bypassed
State access [SLOAD and SSTORE] is the biggest bottleneck for execution, and MonadDb is a significant unlock for state access because:
- it reduces the number of iops to read or write one value
- it makes recomputing the merkle root a lot faster
- and it supports many parallel reads which the parallel execution system can take advantage of
Synergies between optimistic parallel execution and MonadDb
Optimistic parallel execution can be thought of as surfacing many storage slot dependencies – all of the inputs and outputs of the pending results – in parallel and pulling them into the cache
Even in the worst case where every pending result’s inputs are invalidated and the transaction has to be re-executed, optimistic parallel execution is still extremely useful by “running ahead” of the serial commitment and pulling many storage slots from SSD
This makes optimistic parallel execution and MonadDb work really well together, because MonadDb provides fast asynchronous state lookups while optimistic parallel execution cues up many parallel reads from SSD
Bootstrapping a node (Statesync/Blocksync)
High throughput means a long transaction history which makes replaying from genesis challenging
Most node operators will prefer to initialize their nodes by copying over recent state from other nodes and only replaying the last mile. This is what statesync accomplishes
In statesync, a synchronizing node (“client”) provides their current view’s version and a target version and asks other nodes (“servers”) to help it progress from the current view to the target version
MonadDb has versioning on each node in the trie. Servers use this version information to identify which trie components need to be sent
Nodes can also request blocks from their peers in a protocol called blocksync. This is used if a block is missed (not enough chunks arrived), as well as when executing the “last mile” after statesync completes (since more blocks will have come in since the start of statesync)
Thanks for reading and be sure to check out the docs](https://pbs.twimg.com/media/GkDJwUcXMAEPk43.png)
![keoneHD's tweet photo. How Monad Works
Summary / Network Parameters
- Monad is EVM bytecode-equivalent (you can redeploy bytecode without recompilation)
- Cancun fork (TSTORE, TLOAD, MCOPY) is supported
- Opcode to gas units mapping is same as Ethereum (e.g. ADD is 4)
- RPC conforms to geth's RPC interface
- Blocks are every 500 ms
- Finality occurs in 1 second; finality of block N occurs at the proposal of block N+2
- Block gas limit in testnet is 150 million gas, i.e. gas rate is 300 million gas/s. This will increase over time
- 100-200 validators expected in consensus
- on Day 1 of testnet, Monad will have about 55 globally-distributed validators
Frugality / Impact on Decentralization
The driving goal of Monad is to have better software algorithms for consensus and execution, offering high performance while preserving decentralization
These algorithms deliver high performance while relying on nodes with relatively modest hardware:
- 32 GB of RAM
- 2x 2 TB SSDs
- 100 Mbps of bandwidth
- a 16-core 4.5 GHz processor like the AMD Ryzen 7950X
You can assemble this machine for about $1500
These algorithms deliver high performance while maintaining a fully-globally-distributed validator set and stake weight distribution
There isn’t a reliance on a supermajority in one geographic region - one would think this is an obvious expectation but many “high-performance” L1s actually derive their performance from having a supermajority of stake weight in close proximity
Node
Monad node has 3 components:
- monad-bft [consensus]
- monad-execution [execution + state]
- monad-rpc [handling user reads/writes]
- Network is 100-200 voting nodes (we’ll call them “validators” for the rest of this doc)
- Non-voting full nodes listen to network traffic
- All nodes execute all transactions and have full state
Consensus Mechanism
Overall consensus mechanism is MonadBFT.
MonadBFT has linear communication complexity which allows it to scale to far more nodes than quadratic-complexity algorithms like CometBFT
In the happy path, it follows the pattern of “one-to-many-to-one” or “fan out, fan in”:
- Leader (Alice) broadcasts a signed block proposal to all other nodes (fan out), who acknowledge its validity by sending a signed attestation the next leader Bob (fan in).
- Bob aggregates the attestations into a “Quorum Certificate” (QC)
- Attestation signatures use the BLS signature scheme for ease of aggregation
- Bob broadcasts the QC to all the nodes, who attest to receiving it by sending a message to the 3rd leader (Charlie) who aggregates the attestations into a QC-on-QC
- Charlie sends the QC-on-QC to everyone. Upon receiving the QC-on-QC, everyone knows that Alice’s block has been finalized
In the above story, Bob and Charlie are only sending out QCs or QCs-on-QCs, but in reality the proposals are pipelined:
- Bob’s message contains both the QC for Alice’s block and also the contents of a new block.
- Charlie’s message contains the QC for Bob’s block (which is a QC-on-QC for Alice’s block) and also contains the transactions for a new block
When validators send an attestation for Bob’s message they are attesting to both the validity of Bob’s block and the validity of the QC
This pipelining raises the throughput of the network since every slot a new block gets produced.
The below diagram shows how MonadBFT reaches consensus. Pipelining is tracked at the top:
See the docs for a fuller description. Obvious questions addressed there are:
- How the network handles the unhappy path where Bob doesn’t get enough a supermajority of attestations
- How the above mechanism results in nodes being sure that the block has been finalized once they have received the QC-on-QC
RaptorCast
MonadBFT requires the leader to directly send blocks to every validator
However, blocks may be quite large: 10,000 transactions/s * 200 bytes/tx = 2 MB/s. Sending directly to 200 validators would require 400 MB/s (3.2 Gbps).
We don’t want validators to have to have such high upload bandwidth
RaptorCast is a specialized messaging protocol which solves this problem
In RaptorCast, a block is erasure-coded to produce a bunch of smaller chunks
In erasure coding, the total size of all of the chunks is greater than the original data (by a multiplicative factor) but the original data can be restored using (almost) any combination of chunks whose total size matches the original data’s size
For example, a 1000 kb block erasure-coded with a multiplicative factor of 3 might produce 150 20kb chunks, but (roughly) any 50 of the chunks can reassemble the original message
RaptorCast uses a variant of Raptor codes as the encoding mechanism
In RaptorCast, each chunk is sent to one validator who is tasked with sending the chunk to every other validator in the network
That is, each chunk follows a two-level broadcast tree where the leader is the root, one other validator is at the first level, and all other validators are on the second level
Validators are assigned chunks prorata to their stake weight
Here's a diagram showing the RaptorCast protocol: each validator serves as a first-hop recipient for a range of chunks, and broadcasts those chunks to every other validator:
Raptorcast properties:
- Using the two-level broadcast tree ensures that message delivery occurs within 2x the longest hop
- Upload bandwidth for the leader is limited to the block size times the replication factor (roughly 2)
- Since chunks are assigned pro-rata to stake weight, and BFT assumes no more than 33% of stake is malicious, at most 33% of chunks could fail to reach their recipients. With a replication factor of 2x, nodes can reconstruct the original block despite a maximum 33% loss.
Transaction Lifecycle
- User submits pending transaction to RPC node
- RPC node sends pending transaction to next 3 leaders based on the leader schedule
- Pending transaction gets added to those leaders’ local mempools
- Leader adds transaction to their block as they see fit [default: they order by descending fee-per-gas-unit, i.e. Priority Gas Auction]
- Leader proposes block, which is confirmed by the network as mentioned above
Note: directly forwarding to upcoming leaders (as opposed to flood forwarding to all nodes) greatly reduces traffic. Flood forwarding would take up the entire bandwidth
Note: in the future, a behavior is being considered where leaders forward pending transactions (that they weren’t able to include in their block) to the next leader
Leader Election
- Leaders in the current testnet are permissioned. Staking will be added shortly
- An epoch occurs roughly once per day. Validator stake weights are locked in one epoch ahead (i.e. any changes for epoch N+1 must be registered prior to the start of epoch N)
- At the start of each epoch, each validator computes the leader schedule based on running a deterministic pseudorandom function on the stake weights. Since the function is deterministic everyone arrives at the same leader schedule
Asynchronous Execution
Monad pipelines consensus and execution, moving execution out of the hot path of consensus into a separate swim lane and allowing execution to utilize the full block time.
- Consensus is reached prior to execution
- Leader & validators check transaction validity (valid signature; valid nonce; submitter can pay for the data cost of the transaction being transmitted), but are not required to execute the transactions prior to voting.
- After a block is finalized, it is executed; meanwhile consensus is already proceeding on subsequent blocks
This is in contrast to most blockchains, which have interleaved execution.
One way to understand the impact of asynchronous execution is to recognize that, in interleaved execution, the execution budget is necessarily a small fraction of the block time since in interleaved execution, the leader must execute the transactions before proposing the block, and validators must execute before responding
For a 500 ms block time, almost all of the time will be budgeted for multiple rounds of cross-globe communication, leaving only a small fraction of the time for execution
The below diagram contrasts interleaved execution with asynchronous execution. Blue rectangles correspond to time spent on execution while orange rectangles correspond to time spent on consensus.
The budget for execution is much larger in async execution.
Delayed merkle root
Due to async execution, Monad block proposals don’t include the merkle root of the state trie, since that would require execution to have already completed.
All nodes should stay in sync because they’re all starting from the same point and doing the same work.
But it’d be nice to be sure! As a precaution, proposals in Monad also include a delayed merkle root from D blocks ago, allowing nodes to detect if they have diverged. D is a systemwide parameter, currently set to 3.
If any of the validators makes a computation error (cosmic rays?) when computing the state root at block N, it will realize that it possibly erred by block N+D (since the delayed merkle root for N contained in that block differs from its local view).
The validator then needs to wait until N+D+2 to see if 2/3 of the stake weight finalizes the block proposal at N+D (in which case the local node made an error) or if the block gets rejected (in which case the leader made the error).
Block stages
Assume that a validator has just received block N. We say that:
- Block N is ‘proposed’
- Block N-1 is ‘voted’
- Block N-2 is ‘finalized’ (because block N carries the QC-on-QC of block N-2)
- Block N-2-D is ‘verified’ (because block N-2 carries the merkle root post the transactions in block N-2-D, and block N-2 is the last block that has been finalized)
Note that unlike Ethereum, only one block at height N is proposed and voted on, avoiding retroactive block reorganization due to competing forks
Speculative execution
Although only block N-2 is ‘finalized’ and can officially be executed, nodes have a strong suspicion that the lists of transactions in block N-1 and block N are likely to become the finalized lists
Therefore, nodes speculatively execute the transactions included in each new proposed block, storing a pointer to the state trie post those transactions. In the event that a block ends up not being finalized, the pointer is discarded, undoing the execution
Speculative execution allows nodes to (likely) have the most up-to-date state, which helps users simulate transactions correctly
Optimistic parallel execution
Like in Ethereum, blocks are linearly ordered, as are transactions. That means that the true state of the world is the state arrived at by executing all transactions one after another
In Monad, transactions are executed optimistically in parallel to generate pending results. A pending result contains the list of storage slots that were read (SLOADed) and written (SSTOREd) during the course of that execution. We refer to these slots as “inputs” and “outputs”
Pending results are committed serially, checking that each pending result’s inputs are still valid, and re-executing if an input has been invalidated. This serial commitment ensures that the result is the same as if the transactions were executed serially
Here's an example of how Optimistic Parallel Execution works:
Assume that prior to the start of a block, the following are the USDC balances:
- Alice: 1000 USDC
- Bob: 0 USDC
- Charlie: 400 USD
(Note also that each of these balances corresponds to 1 storage slot, since each is 1 key-value pair in a mapping in the USDC contract.)
Two transactions appear as transaction 0 and 1 in the block:
- Transaction 0: Alice sends 100 USDC to Bob
- Transaction 1: Alice sends 100 USDC to Charlie
Then optimistic parallel execution will produce two pending results:
- PendingResult0:
* Inputs: Alice = 1000 USDC, Bob = 0 USDC
* Outputs: Alice = 900 USDC; Bob = 100 USDC
- PendingResult 1:
* Inputs: Alice = 1000 USDC; Charlie = 400 USDC
* Outputs: Alice = 900 USDC, Charlie = 500 USDC
When we go to commit these pending results:
- PendingResult 0 is committed successfully, changing the official state to Alice = 900, Bob = 100, Charlie = 400
- PendingResult 1 cannot be committed because now one of the inputs conflicts (Alice was assumed to have 1000, but actually has 900)
So transaction 1 is re-executed
Final result:
- Alice: 800 USDC
- Bob: 100 USDC
- Charlie: 500 USDC
Note that in optimistic parallel execution, every transaction gets executed at most twice - once optimistically, and (at most) once when it is being committed
Re-execution is typically cheap because storage slots are usually in cache. It is only when re-execution triggers a different codepath (requiring a different slot) that execution has to read a storage slot from SSD
MonadDb
As in Ethereum, state is stored in a merkle trie. There is a custom database, MonadDb, which stores merkle trie data natively
This differs from existing clients [which embed the merkle trie inside of a commodity database which itself uses a tree structure]
MonadDb is a significant optimization because it eliminates a level of indirection, reduces the number of pages read from SSD in order to perform one lookup, allows for async I/O, and allows the filesystem to be bypassed
State access [SLOAD and SSTORE] is the biggest bottleneck for execution, and MonadDb is a significant unlock for state access because:
- it reduces the number of iops to read or write one value
- it makes recomputing the merkle root a lot faster
- and it supports many parallel reads which the parallel execution system can take advantage of
Synergies between optimistic parallel execution and MonadDb
Optimistic parallel execution can be thought of as surfacing many storage slot dependencies – all of the inputs and outputs of the pending results – in parallel and pulling them into the cache
Even in the worst case where every pending result’s inputs are invalidated and the transaction has to be re-executed, optimistic parallel execution is still extremely useful by “running ahead” of the serial commitment and pulling many storage slots from SSD
This makes optimistic parallel execution and MonadDb work really well together, because MonadDb provides fast asynchronous state lookups while optimistic parallel execution cues up many parallel reads from SSD
Bootstrapping a node (Statesync/Blocksync)
High throughput means a long transaction history which makes replaying from genesis challenging
Most node operators will prefer to initialize their nodes by copying over recent state from other nodes and only replaying the last mile. This is what statesync accomplishes
In statesync, a synchronizing node (“client”) provides their current view’s version and a target version and asks other nodes (“servers”) to help it progress from the current view to the target version
MonadDb has versioning on each node in the trie. Servers use this version information to identify which trie components need to be sent
Nodes can also request blocks from their peers in a protocol called blocksync. This is used if a block is missed (not enough chunks arrived), as well as when executing the “last mile” after statesync completes (since more blocks will have come in since the start of statesync)
Thanks for reading and be sure to check out the docs](https://pbs.twimg.com/media/GkDI-oeWoAA03yZ.jpg)
Olivia
Online
NFA
@RyzenJess
Joined May 2023
24 Following
31 Followers
19 Posts
@qlusyu 3.5+ an
@lexssanara avail kak?
Monad execution client is now open source (link below).
This is the result of thousands of hours of effort by the team at @category_xyz.
Enjoy
The full Monad client is now open source.
Who to follow
Brainrot Labs
@Brainrot_Labs
your daily dose of digital schizophrenia
AI girls • memes • crypto • chaos
draper goren blockchain
@DGBventures
the parent company ../
Stack 💸 
@StackItAi
Protected BTC & ETH treasuries for founders & AI agents. Borrow without liquidation. Built for MCP, REST & x402.
👇🏽 3 Steps to Multiply Your Crypto Gains
How Monad Works
Summary / Network Parameters
- Monad is EVM bytecode-equivalent (you can redeploy bytecode without recompilation)
- Cancun fork (TSTORE, TLOAD, MCOPY) is supported
- Opcode to gas units mapping is same as Ethereum (e.g. ADD is 4)
- RPC conforms to geth's RPC interface
- Blocks are every 500 ms
- Finality occurs in 1 second; finality of block N occurs at the proposal of block N+2
- Block gas limit in testnet is 150 million gas, i.e. gas rate is 300 million gas/s. This will increase over time
- 100-200 validators expected in consensus
- on Day 1 of testnet, Monad will have about 55 globally-distributed validators
Frugality / Impact on Decentralization
The driving goal of Monad is to have better software algorithms for consensus and execution, offering high performance while preserving decentralization
These algorithms deliver high performance while relying on nodes with relatively modest hardware:
- 32 GB of RAM
- 2x 2 TB SSDs
- 100 Mbps of bandwidth
- a 16-core 4.5 GHz processor like the AMD Ryzen 7950X
You can assemble this machine for about $1500
These algorithms deliver high performance while maintaining a fully-globally-distributed validator set and stake weight distribution
There isn’t a reliance on a supermajority in one geographic region - one would think this is an obvious expectation but many “high-performance” L1s actually derive their performance from having a supermajority of stake weight in close proximity
Node
Monad node has 3 components:
- monad-bft [consensus]
- monad-execution [execution + state]
- monad-rpc [handling user reads/writes]
- Network is 100-200 voting nodes (we’ll call them “validators” for the rest of this doc)
- Non-voting full nodes listen to network traffic
- All nodes execute all transactions and have full state
Consensus Mechanism
Overall consensus mechanism is MonadBFT.
MonadBFT has linear communication complexity which allows it to scale to far more nodes than quadratic-complexity algorithms like CometBFT
In the happy path, it follows the pattern of “one-to-many-to-one” or “fan out, fan in”:
- Leader (Alice) broadcasts a signed block proposal to all other nodes (fan out), who acknowledge its validity by sending a signed attestation the next leader Bob (fan in).
- Bob aggregates the attestations into a “Quorum Certificate” (QC)
- Attestation signatures use the BLS signature scheme for ease of aggregation
- Bob broadcasts the QC to all the nodes, who attest to receiving it by sending a message to the 3rd leader (Charlie) who aggregates the attestations into a QC-on-QC
- Charlie sends the QC-on-QC to everyone. Upon receiving the QC-on-QC, everyone knows that Alice’s block has been finalized
In the above story, Bob and Charlie are only sending out QCs or QCs-on-QCs, but in reality the proposals are pipelined:
- Bob’s message contains both the QC for Alice’s block and also the contents of a new block.
- Charlie’s message contains the QC for Bob’s block (which is a QC-on-QC for Alice’s block) and also contains the transactions for a new block
When validators send an attestation for Bob’s message they are attesting to both the validity of Bob’s block and the validity of the QC
This pipelining raises the throughput of the network since every slot a new block gets produced.
The below diagram shows how MonadBFT reaches consensus. Pipelining is tracked at the top:
See the docs for a fuller description. Obvious questions addressed there are:
- How the network handles the unhappy path where Bob doesn’t get enough a supermajority of attestations
- How the above mechanism results in nodes being sure that the block has been finalized once they have received the QC-on-QC
RaptorCast
MonadBFT requires the leader to directly send blocks to every validator
However, blocks may be quite large: 10,000 transactions/s * 200 bytes/tx = 2 MB/s. Sending directly to 200 validators would require 400 MB/s (3.2 Gbps).
We don’t want validators to have to have such high upload bandwidth
RaptorCast is a specialized messaging protocol which solves this problem
In RaptorCast, a block is erasure-coded to produce a bunch of smaller chunks
In erasure coding, the total size of all of the chunks is greater than the original data (by a multiplicative factor) but the original data can be restored using (almost) any combination of chunks whose total size matches the original data’s size
For example, a 1000 kb block erasure-coded with a multiplicative factor of 3 might produce 150 20kb chunks, but (roughly) any 50 of the chunks can reassemble the original message
RaptorCast uses a variant of Raptor codes as the encoding mechanism
In RaptorCast, each chunk is sent to one validator who is tasked with sending the chunk to every other validator in the network
That is, each chunk follows a two-level broadcast tree where the leader is the root, one other validator is at the first level, and all other validators are on the second level
Validators are assigned chunks prorata to their stake weight
Here's a diagram showing the RaptorCast protocol: each validator serves as a first-hop recipient for a range of chunks, and broadcasts those chunks to every other validator:
Raptorcast properties:
- Using the two-level broadcast tree ensures that message delivery occurs within 2x the longest hop
- Upload bandwidth for the leader is limited to the block size times the replication factor (roughly 2)
- Since chunks are assigned pro-rata to stake weight, and BFT assumes no more than 33% of stake is malicious, at most 33% of chunks could fail to reach their recipients. With a replication factor of 2x, nodes can reconstruct the original block despite a maximum 33% loss.
Transaction Lifecycle
- User submits pending transaction to RPC node
- RPC node sends pending transaction to next 3 leaders based on the leader schedule
- Pending transaction gets added to those leaders’ local mempools
- Leader adds transaction to their block as they see fit [default: they order by descending fee-per-gas-unit, i.e. Priority Gas Auction]
- Leader proposes block, which is confirmed by the network as mentioned above
Note: directly forwarding to upcoming leaders (as opposed to flood forwarding to all nodes) greatly reduces traffic. Flood forwarding would take up the entire bandwidth
Note: in the future, a behavior is being considered where leaders forward pending transactions (that they weren’t able to include in their block) to the next leader
Leader Election
- Leaders in the current testnet are permissioned. Staking will be added shortly
- An epoch occurs roughly once per day. Validator stake weights are locked in one epoch ahead (i.e. any changes for epoch N+1 must be registered prior to the start of epoch N)
- At the start of each epoch, each validator computes the leader schedule based on running a deterministic pseudorandom function on the stake weights. Since the function is deterministic everyone arrives at the same leader schedule
Asynchronous Execution
Monad pipelines consensus and execution, moving execution out of the hot path of consensus into a separate swim lane and allowing execution to utilize the full block time.
- Consensus is reached prior to execution
- Leader & validators check transaction validity (valid signature; valid nonce; submitter can pay for the data cost of the transaction being transmitted), but are not required to execute the transactions prior to voting.
- After a block is finalized, it is executed; meanwhile consensus is already proceeding on subsequent blocks
This is in contrast to most blockchains, which have interleaved execution.
One way to understand the impact of asynchronous execution is to recognize that, in interleaved execution, the execution budget is necessarily a small fraction of the block time since in interleaved execution, the leader must execute the transactions before proposing the block, and validators must execute before responding
For a 500 ms block time, almost all of the time will be budgeted for multiple rounds of cross-globe communication, leaving only a small fraction of the time for execution
The below diagram contrasts interleaved execution with asynchronous execution. Blue rectangles correspond to time spent on execution while orange rectangles correspond to time spent on consensus.
The budget for execution is much larger in async execution.
Delayed merkle root
Due to async execution, Monad block proposals don’t include the merkle root of the state trie, since that would require execution to have already completed.
All nodes should stay in sync because they’re all starting from the same point and doing the same work.
But it’d be nice to be sure! As a precaution, proposals in Monad also include a delayed merkle root from D blocks ago, allowing nodes to detect if they have diverged. D is a systemwide parameter, currently set to 3.
If any of the validators makes a computation error (cosmic rays?) when computing the state root at block N, it will realize that it possibly erred by block N+D (since the delayed merkle root for N contained in that block differs from its local view).
The validator then needs to wait until N+D+2 to see if 2/3 of the stake weight finalizes the block proposal at N+D (in which case the local node made an error) or if the block gets rejected (in which case the leader made the error).
Block stages
Assume that a validator has just received block N. We say that:
- Block N is ‘proposed’
- Block N-1 is ‘voted’
- Block N-2 is ‘finalized’ (because block N carries the QC-on-QC of block N-2)
- Block N-2-D is ‘verified’ (because block N-2 carries the merkle root post the transactions in block N-2-D, and block N-2 is the last block that has been finalized)
Note that unlike Ethereum, only one block at height N is proposed and voted on, avoiding retroactive block reorganization due to competing forks
Speculative execution
Although only block N-2 is ‘finalized’ and can officially be executed, nodes have a strong suspicion that the lists of transactions in block N-1 and block N are likely to become the finalized lists
Therefore, nodes speculatively execute the transactions included in each new proposed block, storing a pointer to the state trie post those transactions. In the event that a block ends up not being finalized, the pointer is discarded, undoing the execution
Speculative execution allows nodes to (likely) have the most up-to-date state, which helps users simulate transactions correctly
Optimistic parallel execution
Like in Ethereum, blocks are linearly ordered, as are transactions. That means that the true state of the world is the state arrived at by executing all transactions one after another
In Monad, transactions are executed optimistically in parallel to generate pending results. A pending result contains the list of storage slots that were read (SLOADed) and written (SSTOREd) during the course of that execution. We refer to these slots as “inputs” and “outputs”
Pending results are committed serially, checking that each pending result’s inputs are still valid, and re-executing if an input has been invalidated. This serial commitment ensures that the result is the same as if the transactions were executed serially
Here's an example of how Optimistic Parallel Execution works:
Assume that prior to the start of a block, the following are the USDC balances:
- Alice: 1000 USDC
- Bob: 0 USDC
- Charlie: 400 USD
(Note also that each of these balances corresponds to 1 storage slot, since each is 1 key-value pair in a mapping in the USDC contract.)
Two transactions appear as transaction 0 and 1 in the block:
- Transaction 0: Alice sends 100 USDC to Bob
- Transaction 1: Alice sends 100 USDC to Charlie
Then optimistic parallel execution will produce two pending results:
- PendingResult0:
* Inputs: Alice = 1000 USDC, Bob = 0 USDC
* Outputs: Alice = 900 USDC; Bob = 100 USDC
- PendingResult 1:
* Inputs: Alice = 1000 USDC; Charlie = 400 USDC
* Outputs: Alice = 900 USDC, Charlie = 500 USDC
When we go to commit these pending results:
- PendingResult 0 is committed successfully, changing the official state to Alice = 900, Bob = 100, Charlie = 400
- PendingResult 1 cannot be committed because now one of the inputs conflicts (Alice was assumed to have 1000, but actually has 900)
So transaction 1 is re-executed
Final result:
- Alice: 800 USDC
- Bob: 100 USDC
- Charlie: 500 USDC
Note that in optimistic parallel execution, every transaction gets executed at most twice - once optimistically, and (at most) once when it is being committed
Re-execution is typically cheap because storage slots are usually in cache. It is only when re-execution triggers a different codepath (requiring a different slot) that execution has to read a storage slot from SSD
MonadDb
As in Ethereum, state is stored in a merkle trie. There is a custom database, MonadDb, which stores merkle trie data natively
This differs from existing clients [which embed the merkle trie inside of a commodity database which itself uses a tree structure]
MonadDb is a significant optimization because it eliminates a level of indirection, reduces the number of pages read from SSD in order to perform one lookup, allows for async I/O, and allows the filesystem to be bypassed
State access [SLOAD and SSTORE] is the biggest bottleneck for execution, and MonadDb is a significant unlock for state access because:
- it reduces the number of iops to read or write one value
- it makes recomputing the merkle root a lot faster
- and it supports many parallel reads which the parallel execution system can take advantage of
Synergies between optimistic parallel execution and MonadDb
Optimistic parallel execution can be thought of as surfacing many storage slot dependencies – all of the inputs and outputs of the pending results – in parallel and pulling them into the cache
Even in the worst case where every pending result’s inputs are invalidated and the transaction has to be re-executed, optimistic parallel execution is still extremely useful by “running ahead” of the serial commitment and pulling many storage slots from SSD
This makes optimistic parallel execution and MonadDb work really well together, because MonadDb provides fast asynchronous state lookups while optimistic parallel execution cues up many parallel reads from SSD
Bootstrapping a node (Statesync/Blocksync)
High throughput means a long transaction history which makes replaying from genesis challenging
Most node operators will prefer to initialize their nodes by copying over recent state from other nodes and only replaying the last mile. This is what statesync accomplishes
In statesync, a synchronizing node (“client”) provides their current view’s version and a target version and asks other nodes (“servers”) to help it progress from the current view to the target version
MonadDb has versioning on each node in the trie. Servers use this version information to identify which trie components need to be sent
Nodes can also request blocks from their peers in a protocol called blocksync. This is used if a block is missed (not enough chunks arrived), as well as when executing the “last mile” after statesync completes (since more blocks will have come in since the start of statesync)
Thanks for reading and be sure to check out the docs
![keoneHD's tweet photo. How Monad Works
Summary / Network Parameters
- Monad is EVM bytecode-equivalent (you can redeploy bytecode without recompilation)
- Cancun fork (TSTORE, TLOAD, MCOPY) is supported
- Opcode to gas units mapping is same as Ethereum (e.g. ADD is 4)
- RPC conforms to geth's RPC interface
- Blocks are every 500 ms
- Finality occurs in 1 second; finality of block N occurs at the proposal of block N+2
- Block gas limit in testnet is 150 million gas, i.e. gas rate is 300 million gas/s. This will increase over time
- 100-200 validators expected in consensus
- on Day 1 of testnet, Monad will have about 55 globally-distributed validators
Frugality / Impact on Decentralization
The driving goal of Monad is to have better software algorithms for consensus and execution, offering high performance while preserving decentralization
These algorithms deliver high performance while relying on nodes with relatively modest hardware:
- 32 GB of RAM
- 2x 2 TB SSDs
- 100 Mbps of bandwidth
- a 16-core 4.5 GHz processor like the AMD Ryzen 7950X
You can assemble this machine for about $1500
These algorithms deliver high performance while maintaining a fully-globally-distributed validator set and stake weight distribution
There isn’t a reliance on a supermajority in one geographic region - one would think this is an obvious expectation but many “high-performance” L1s actually derive their performance from having a supermajority of stake weight in close proximity
Node
Monad node has 3 components:
- monad-bft [consensus]
- monad-execution [execution + state]
- monad-rpc [handling user reads/writes]
- Network is 100-200 voting nodes (we’ll call them “validators” for the rest of this doc)
- Non-voting full nodes listen to network traffic
- All nodes execute all transactions and have full state
Consensus Mechanism
Overall consensus mechanism is MonadBFT.
MonadBFT has linear communication complexity which allows it to scale to far more nodes than quadratic-complexity algorithms like CometBFT
In the happy path, it follows the pattern of “one-to-many-to-one” or “fan out, fan in”:
- Leader (Alice) broadcasts a signed block proposal to all other nodes (fan out), who acknowledge its validity by sending a signed attestation the next leader Bob (fan in).
- Bob aggregates the attestations into a “Quorum Certificate” (QC)
- Attestation signatures use the BLS signature scheme for ease of aggregation
- Bob broadcasts the QC to all the nodes, who attest to receiving it by sending a message to the 3rd leader (Charlie) who aggregates the attestations into a QC-on-QC
- Charlie sends the QC-on-QC to everyone. Upon receiving the QC-on-QC, everyone knows that Alice’s block has been finalized
In the above story, Bob and Charlie are only sending out QCs or QCs-on-QCs, but in reality the proposals are pipelined:
- Bob’s message contains both the QC for Alice’s block and also the contents of a new block.
- Charlie’s message contains the QC for Bob’s block (which is a QC-on-QC for Alice’s block) and also contains the transactions for a new block
When validators send an attestation for Bob’s message they are attesting to both the validity of Bob’s block and the validity of the QC
This pipelining raises the throughput of the network since every slot a new block gets produced.
The below diagram shows how MonadBFT reaches consensus. Pipelining is tracked at the top:
See the docs for a fuller description. Obvious questions addressed there are:
- How the network handles the unhappy path where Bob doesn’t get enough a supermajority of attestations
- How the above mechanism results in nodes being sure that the block has been finalized once they have received the QC-on-QC
RaptorCast
MonadBFT requires the leader to directly send blocks to every validator
However, blocks may be quite large: 10,000 transactions/s * 200 bytes/tx = 2 MB/s. Sending directly to 200 validators would require 400 MB/s (3.2 Gbps).
We don’t want validators to have to have such high upload bandwidth
RaptorCast is a specialized messaging protocol which solves this problem
In RaptorCast, a block is erasure-coded to produce a bunch of smaller chunks
In erasure coding, the total size of all of the chunks is greater than the original data (by a multiplicative factor) but the original data can be restored using (almost) any combination of chunks whose total size matches the original data’s size
For example, a 1000 kb block erasure-coded with a multiplicative factor of 3 might produce 150 20kb chunks, but (roughly) any 50 of the chunks can reassemble the original message
RaptorCast uses a variant of Raptor codes as the encoding mechanism
In RaptorCast, each chunk is sent to one validator who is tasked with sending the chunk to every other validator in the network
That is, each chunk follows a two-level broadcast tree where the leader is the root, one other validator is at the first level, and all other validators are on the second level
Validators are assigned chunks prorata to their stake weight
Here's a diagram showing the RaptorCast protocol: each validator serves as a first-hop recipient for a range of chunks, and broadcasts those chunks to every other validator:
Raptorcast properties:
- Using the two-level broadcast tree ensures that message delivery occurs within 2x the longest hop
- Upload bandwidth for the leader is limited to the block size times the replication factor (roughly 2)
- Since chunks are assigned pro-rata to stake weight, and BFT assumes no more than 33% of stake is malicious, at most 33% of chunks could fail to reach their recipients. With a replication factor of 2x, nodes can reconstruct the original block despite a maximum 33% loss.
Transaction Lifecycle
- User submits pending transaction to RPC node
- RPC node sends pending transaction to next 3 leaders based on the leader schedule
- Pending transaction gets added to those leaders’ local mempools
- Leader adds transaction to their block as they see fit [default: they order by descending fee-per-gas-unit, i.e. Priority Gas Auction]
- Leader proposes block, which is confirmed by the network as mentioned above
Note: directly forwarding to upcoming leaders (as opposed to flood forwarding to all nodes) greatly reduces traffic. Flood forwarding would take up the entire bandwidth
Note: in the future, a behavior is being considered where leaders forward pending transactions (that they weren’t able to include in their block) to the next leader
Leader Election
- Leaders in the current testnet are permissioned. Staking will be added shortly
- An epoch occurs roughly once per day. Validator stake weights are locked in one epoch ahead (i.e. any changes for epoch N+1 must be registered prior to the start of epoch N)
- At the start of each epoch, each validator computes the leader schedule based on running a deterministic pseudorandom function on the stake weights. Since the function is deterministic everyone arrives at the same leader schedule
Asynchronous Execution
Monad pipelines consensus and execution, moving execution out of the hot path of consensus into a separate swim lane and allowing execution to utilize the full block time.
- Consensus is reached prior to execution
- Leader & validators check transaction validity (valid signature; valid nonce; submitter can pay for the data cost of the transaction being transmitted), but are not required to execute the transactions prior to voting.
- After a block is finalized, it is executed; meanwhile consensus is already proceeding on subsequent blocks
This is in contrast to most blockchains, which have interleaved execution.
One way to understand the impact of asynchronous execution is to recognize that, in interleaved execution, the execution budget is necessarily a small fraction of the block time since in interleaved execution, the leader must execute the transactions before proposing the block, and validators must execute before responding
For a 500 ms block time, almost all of the time will be budgeted for multiple rounds of cross-globe communication, leaving only a small fraction of the time for execution
The below diagram contrasts interleaved execution with asynchronous execution. Blue rectangles correspond to time spent on execution while orange rectangles correspond to time spent on consensus.
The budget for execution is much larger in async execution.
Delayed merkle root
Due to async execution, Monad block proposals don’t include the merkle root of the state trie, since that would require execution to have already completed.
All nodes should stay in sync because they’re all starting from the same point and doing the same work.
But it’d be nice to be sure! As a precaution, proposals in Monad also include a delayed merkle root from D blocks ago, allowing nodes to detect if they have diverged. D is a systemwide parameter, currently set to 3.
If any of the validators makes a computation error (cosmic rays?) when computing the state root at block N, it will realize that it possibly erred by block N+D (since the delayed merkle root for N contained in that block differs from its local view).
The validator then needs to wait until N+D+2 to see if 2/3 of the stake weight finalizes the block proposal at N+D (in which case the local node made an error) or if the block gets rejected (in which case the leader made the error).
Block stages
Assume that a validator has just received block N. We say that:
- Block N is ‘proposed’
- Block N-1 is ‘voted’
- Block N-2 is ‘finalized’ (because block N carries the QC-on-QC of block N-2)
- Block N-2-D is ‘verified’ (because block N-2 carries the merkle root post the transactions in block N-2-D, and block N-2 is the last block that has been finalized)
Note that unlike Ethereum, only one block at height N is proposed and voted on, avoiding retroactive block reorganization due to competing forks
Speculative execution
Although only block N-2 is ‘finalized’ and can officially be executed, nodes have a strong suspicion that the lists of transactions in block N-1 and block N are likely to become the finalized lists
Therefore, nodes speculatively execute the transactions included in each new proposed block, storing a pointer to the state trie post those transactions. In the event that a block ends up not being finalized, the pointer is discarded, undoing the execution
Speculative execution allows nodes to (likely) have the most up-to-date state, which helps users simulate transactions correctly
Optimistic parallel execution
Like in Ethereum, blocks are linearly ordered, as are transactions. That means that the true state of the world is the state arrived at by executing all transactions one after another
In Monad, transactions are executed optimistically in parallel to generate pending results. A pending result contains the list of storage slots that were read (SLOADed) and written (SSTOREd) during the course of that execution. We refer to these slots as “inputs” and “outputs”
Pending results are committed serially, checking that each pending result’s inputs are still valid, and re-executing if an input has been invalidated. This serial commitment ensures that the result is the same as if the transactions were executed serially
Here's an example of how Optimistic Parallel Execution works:
Assume that prior to the start of a block, the following are the USDC balances:
- Alice: 1000 USDC
- Bob: 0 USDC
- Charlie: 400 USD
(Note also that each of these balances corresponds to 1 storage slot, since each is 1 key-value pair in a mapping in the USDC contract.)
Two transactions appear as transaction 0 and 1 in the block:
- Transaction 0: Alice sends 100 USDC to Bob
- Transaction 1: Alice sends 100 USDC to Charlie
Then optimistic parallel execution will produce two pending results:
- PendingResult0:
* Inputs: Alice = 1000 USDC, Bob = 0 USDC
* Outputs: Alice = 900 USDC; Bob = 100 USDC
- PendingResult 1:
* Inputs: Alice = 1000 USDC; Charlie = 400 USDC
* Outputs: Alice = 900 USDC, Charlie = 500 USDC
When we go to commit these pending results:
- PendingResult 0 is committed successfully, changing the official state to Alice = 900, Bob = 100, Charlie = 400
- PendingResult 1 cannot be committed because now one of the inputs conflicts (Alice was assumed to have 1000, but actually has 900)
So transaction 1 is re-executed
Final result:
- Alice: 800 USDC
- Bob: 100 USDC
- Charlie: 500 USDC
Note that in optimistic parallel execution, every transaction gets executed at most twice - once optimistically, and (at most) once when it is being committed
Re-execution is typically cheap because storage slots are usually in cache. It is only when re-execution triggers a different codepath (requiring a different slot) that execution has to read a storage slot from SSD
MonadDb
As in Ethereum, state is stored in a merkle trie. There is a custom database, MonadDb, which stores merkle trie data natively
This differs from existing clients [which embed the merkle trie inside of a commodity database which itself uses a tree structure]
MonadDb is a significant optimization because it eliminates a level of indirection, reduces the number of pages read from SSD in order to perform one lookup, allows for async I/O, and allows the filesystem to be bypassed
State access [SLOAD and SSTORE] is the biggest bottleneck for execution, and MonadDb is a significant unlock for state access because:
- it reduces the number of iops to read or write one value
- it makes recomputing the merkle root a lot faster
- and it supports many parallel reads which the parallel execution system can take advantage of
Synergies between optimistic parallel execution and MonadDb
Optimistic parallel execution can be thought of as surfacing many storage slot dependencies – all of the inputs and outputs of the pending results – in parallel and pulling them into the cache
Even in the worst case where every pending result’s inputs are invalidated and the transaction has to be re-executed, optimistic parallel execution is still extremely useful by “running ahead” of the serial commitment and pulling many storage slots from SSD
This makes optimistic parallel execution and MonadDb work really well together, because MonadDb provides fast asynchronous state lookups while optimistic parallel execution cues up many parallel reads from SSD
Bootstrapping a node (Statesync/Blocksync)
High throughput means a long transaction history which makes replaying from genesis challenging
Most node operators will prefer to initialize their nodes by copying over recent state from other nodes and only replaying the last mile. This is what statesync accomplishes
In statesync, a synchronizing node (“client”) provides their current view’s version and a target version and asks other nodes (“servers”) to help it progress from the current view to the target version
MonadDb has versioning on each node in the trie. Servers use this version information to identify which trie components need to be sent
Nodes can also request blocks from their peers in a protocol called blocksync. This is used if a block is missed (not enough chunks arrived), as well as when executing the “last mile” after statesync completes (since more blocks will have come in since the start of statesync)
Thanks for reading and be sure to check out the docs](https://pbs.twimg.com/media/GkDM1jcWgAAHL1j.png)
testnet loading:
▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░ 99.8%
see you on monday
@monad_dev nads follow devs💜
testnet loading:
▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░ 99%
.▬▬▬▬▬▬.◙.▬▬▬▬▬▬.
═▂▄▄▓▄▄▂
◢◤ █▀▀████▄▄▄▄◢◤
█▄ █ █▄ ███▀▀▀▀▀▀▀
◥█████◤
══╩══╩═
╬═╬
╬═╬
╬═╬
╬═╬ just dropped down to say
╬═╬
╬═╬ notifications on :)
╬═╬
╬═╬ ☻/
╬═╬ /▌
╬═╬ / \
Introducing Wave 2 of the mentors for evm/accathon!
2 Days left to apply: https://t.co/9otUzFze9h
Built from scratch. Not forked. By world class engineers. Laser focused on performance. Fundamental belief in decentralization. Appreciation for fun. Crypto native. Community first. Ecosystem driven. Long term vision. No shortcuts.
Excited to unveil Monad to the world.
Why Monad is Built Different
1. Incredibly kind, funny, supportive community that grows together and sets the culture of Monad
2. Ecosystem of ambitious, talented builders building real apps for adoption at scale, uniquely enabled by Monad
3. Emerging NFT ecosystem with deep lore and exceptional talent
4. Completely new execution system (MonadDb + parallel execution + compiler stuff), built for performance and reasonable RAM reqs
5. Completely new consensus mechanism + networking layer (MonadBFT + RaptorCast + others), built to carry 10k+ tps of transaction data (2MB+/s) while maintaining reasonable bandwidth reqs
6. Research! Async execution (now being evaluated by Ethereum!) and other new architectures
7. Decentralization + performance enabled by technology. True globally-distributed decentralized network for permissionlessness & censorship-resistance. True shared global state on hundreds of nodes participating in consensus. 10k+ tps. Reasonable hardware reqs. It's legitimately just a really cool system!
8. A Foundation built to support builders and real adoption. Monad Madness, Mach 2, evm/accathon, Project Jumpstart are a few recent examples of our proof of work
There's a lot under the hood from the past 3 years of work. An epic journey is ahead - we are just getting started 💜
Introducing Monad Madness Hong Kong, the pitch competition for Greater China’s most innovative builders. Join us this April for:
- $2M HKD prize pool
- Access to top-tier VCs
- Mandarin-native competition
集结大中华区创新力量，四月相约香港!
https://t.co/pqQ9ozZMaV
1/ Centralized control of networks has consequence — Big Tech, Big Banks, and Big AI control public discourse, financial access, and even information.
Decentralization eliminates control, but it needs to be incentivized. Here's how. 👇
Introducing evm/accathon, the inaugural Monad hackathon for builders shaping the future of the EVM.
Starting on Feb 24th, the event will have both online and IRL elements:
• 2 days live hackerhouse at ETHDenver
• 2 weeks online hackathon sprint
• Over $100K in prizes
Details below 👇
Monad Testnet:
February __, 2025
Set your reminders for the Ambassadors & Grants Program AMA.💙🧡
🗓️ Thursday, 3rd August, 12:30 ET
📍Space: https://t.co/JiLU9rOD3b
Introducing Phase 1 of the Arbitrum Foundation Grants.🎉💙🧡
✨https://t.co/1j0YziKQ73✨
📰https://t.co/6V7mBxcPHL
🧵👇
Last Seen Users on Sotwe
WANIMAL | Official
Seen from United States
fantasy sex
Seen from Turkey
alpha 777
Seen from United Arab Emirates
Sex Adresi
Seen from Turkey
Serkan27
Seen from Turkey
wasim
Seen from Singapore
local Gay pathans 🍆🍑
Seen from Pakistan
Bull Sıkıcı
Seen from France
Anal sexs porno
Seen from Turkey
BirBeyEfendi.
Seen from Switzerland
Most Popular Users
Elon Musk
@elonmusk
240.7M followers
Barack Obama
@barackobama
119.2M followers
Donald J. Trump
@realdonaldtrump
111.7M followers
Cristiano Ronaldo
@cristiano
110.7M followers
Narendra Modi
@narendramodi
107M followers
Rihanna
@rihanna
97.7M followers
NASA
@nasa
92.2M followers
Justin Bieber
@justinbieber
90.9M followers
KATY PERRY
@katyperry
87.7M followers
Taylor Swift
@taylorswift13
81.6M followers
Lady Gaga
@ladygaga
73.1M followers
Virat Kohli
@imvkohli
70M followers
Kim Kardashian
@kimkardashian
69.8M followers
YouTube
@youtube
68.7M followers
Bill Gates
@billgates
63.9M followers
Neymar Jr
@neymarjr
62.7M followers
The Ellen Show
@theellenshow
62.4M followers
CNN
@cnn
61.9M followers
X
@x
60.8M followers
Selena Gomez
@selenagomez
60.8M followers