Ethereum processes transactions sequentially - one at a time. It is such a great idea because it ensures state consistency and correctness but it also means:

• Lower throughput.

• Bottlenecks during high demand.

• Great for security, but not for scalability.

Imagine this, you are in a store, and you want to get Meat & Seafood, now you have to queue or stay on the line and the cashier has to attend to you one after the other.

Assuming there are hundreds of people on the line at that time, you're at the last line, and it may take a while before its your turn, the same as how it takes Ethereum forever to process your transactions during high demand.

Monad introduces a process of processing transactions called the - PARALLEL EXECUTION

Parallel Execution means transactions are executed in parallel, i.e., multiple transactions are executed simultaneously without interfering.

OPTIMISTIC EXECUTION makes this possible - ( a transaction can start executing before waiting for the earlier transaction to complete in the block)

Now, occasionally there may be some conflicts/bottlenecks between these transactions, which can happen in a situation such as when 2 people are trying to update the same account balance simultaneously.

Here’s a simple explanation:

You have two transactions:

• Transaction 1: Adds $100 to Account A (e.g., a transfer from Account B).

• Transaction 2: Reads the balance of Account A and sends some money (e.g., $50) to Account C.

Remember these two are happening at the same time, now, let's compare how this will happen on ETHEREUM and MONAD.

If the transactions are happening sequentially ( One after the other ) i.e

ON ETHEREUM:

• First, Transaction 1 updates Account A’s balance. Let’s say Account A originally had $200. After Transaction 1, Account A now has $300.

• Then, Transaction 2 reads this updated balance of $300 and deducts $50, leaving $250.

The result is correct because Transaction 2 works with the most up-to-date balance.

if the transactions are executing in parallel ( Multiple at the same time ) i.e

ON MONAD:

• Transaction 1 starts adding $100 to Account A.

• Meanwhile, Transaction 2 reads Account A’s balance before Transaction 1 has finished. So, Transaction 2 sees the old balance of $200, not the updated balance of $300.

• Transaction 2 deducts $50 based on the outdated $200 balance and updates Account A to $150.

• Then, Transaction 1 finishes its update and adds $100 to Account A, bringing it to $250.

This results in an incorrect state because Transaction 2 didn’t account for the $100 addition from Transaction 1.

The final balance should have been $250 after both transactions, but the system got there incorrectly, and there’s a potential for errors in related operations.

Why This Happens:

Both transactions are trying to read and update the same data (Account A’s balance) at the same time. The system didn’t wait for Transaction 1 to finish before allowing Transaction 2 to act.

(I will want you to take enough time to go back to that explanation I made to fully understand)

How Optimistic Execution Fixes It

Optimistic execution assumes that transactions running in parallel will not conflict. However, to ensure correctness, it uses a check-and-correct mechanism:

• Track Inputs and Outputs:

While running Transaction 2, Monad keeps track of the data it uses (like the balance it reads from Account A). It also tracks what Transaction 1 updates (the balance of Account A after adding $100).

• Compare After Execution:

When both transactions finish, Monad compares the inputs of Transaction 2 used with the outputs of Transaction 1.

In this case, Transaction 2 used Account A's balance of $200, but Transaction 1 changed it to $300.

• Detect Conflict:

If the inputs of Transaction 2 (e.g., balance = $200) don’t match the final outputs of Transaction 1 (e.g., balance = $300), Monad detects a conflict.

This means Transaction 2 ran with incorrect data.

• Re-Execute Transaction 2:

Monad re-runs Transaction 2, this time with the correct data (balance = $300).

Now Transaction 2 can send $50 from the correct updated balance.

• Sequential Merging for Accuracy:

Even though Monad executes transactions in parallel to save time, it still merges the final results sequentially. This means:

After Transaction 1 finishes updating Account A, its result is applied first.

Then, Transaction 2's result is applied, but only after verifying it used the correct data.

This sequential merging ensures that even though transactions are executed simultaneously, their final states follow the correct order, just like they would in a sequential system.

This approach from monad ( Parallel Execution ) ensures the chain's Scalability ( Speed, low cost, and usability ), transaction consistency, and correctness.

Ethereum's sequential transaction processing ensures state consistency and security but struggles with scalability, leading to lower throughput and bottlenecks during peak demand.

Monad addresses these challenges by introducing Parallel Execution through Optimistic Execution, enabling multiple transactions to be processed simultaneously.

While this approach significantly improves scalability and speed, it requires careful handling of potential conflicts when transactions interact with the same data.

Monad achieves this by tracking inputs and outputs, detecting conflicts, and re-executing transactions if necessary, all while merging results sequentially to maintain correctness.

By combining the benefits of parallel processing with robust conflict resolution, Monad offers a scalable, efficient, and secure solution for blockchain transactions, paving the way for a more usable and high-performance decentralized ecosystem.