Optimistic parallel execution: run them together, replay the ones that collided

On a conventional chain, the machine that agrees the order of transactions is also the machine that runs them, and it runs them one after another. The next block cannot start until both jobs are done. Monad pulls those jobs apart. Consensus keeps its own clock. Execution of the block just agreed is still running while the next proposal is already in flight. That is asynchronous execution. It is the reason a 300 millisecond block is not also a 300 millisecond budget for every contract call in it.

Optimistic, then honest

Inside a block, transactions are executed optimistically in parallel. “Optimistic” means the scheduler does not know, ahead of time, that two calls will write the same storage slot. If they do, one result is thrown out and the transaction is run again after the earlier one. The result the chain commits is still a serial result. Parallelism is a way of getting to that serial result faster when most transactions do not touch each other, which is the ordinary case on a payments and swaps chain and a poor assumption on a chain doing one giant shared-object auction.

Developers do not annotate their contracts with a conflict set. The bytecode is EVM bytecode, including the Cancun family of opcodes such as transient storage. Tooling that speaks geth’s RPC keeps working. That compatibility is the whole point of refusing a new virtual machine. It is also the constraint: the scheduler has to discover conflicts by running the code, not by reading a label the author attached.

Parallel execution that changes the result is a different computer. Monad’s claim is that it does not.

Where it will not save you

A contract that funnels every user through one storage slot will replay. A bot that lands twenty transactions against the same pool in one block will replay. The gas they pay is the gas of the committed path, but the wall-clock win shrinks as the conflict rate rises. Anyone selling “parallel, so your loop is free” has not read the scheduler. The useful question for an application is how often two of its own transactions write the same word. If the answer is “almost every block”, the application is already serial, and Monad will treat it that way.

Two payments, and one pool

Two transfers that touch different accounts do not contend. Run in either order, or run together and merged, they leave the same balances. Two swaps against one pool do contend, because both want to write the same reserves. The scheduler keeps one result and runs the other transaction again, after the first write. The block that gets a hash has a single order. Parallel execution is a way of reaching that order sooner when most of the block is the first kind of work. It is not a promise that your swap observed an untouched pool.

The execution budget is longer than the slot

Consensus does not wait for the state to be written before it moves to the next proposal. The time a node has to finish the transactions, including the ones it must replay, is therefore not the 300 milliseconds of the slot they were ordered in. That lag is the room the executor spends. It is also a trap for indexers. A process that has the latest header is looking at the clock the voters share. Balances catch up on the other clock. “Latest block” and “latest state” are neighbours. They are not the same query.