Pessimistic Concurrency Control

Pessimistic concurrency control involves locking resources to prevent conflicts between multiple concurrent transactions. This approach assumes that conflicts are likely to occur and tries to prevent them from happening.

Pros:

• Provides strong consistency guarantees

• Prevents conflicts before they occur, reducing the likelihood of rollbacks

• Suitable for systems with high contention and low throughput

Cons:

• Can lead to blocking and reduced concurrency if there are many conflicts

• Can lead to deadlock if locks are not released properly

• Can reduce system performance if locks are held for a long time.

In blockchain environments, pre-declaring resources can pose challenges due to the inherent difficulty in accurately predicting which states will be accessed during transaction execution. Consequently, resource declarations often need to be coarse-grained, potentially limiting concurrency in many scenarios.

Monad

Monad's execution model is classified as optimistic concurrency control (OCC).

Monad executes transactions in parallel using optimistic execution, where transactions start before earlier ones complete, potentially causing incorrect execution if data dependencies are not met. The system tracks inputs and re-executes transactions if conflicts are detected.

Optimistic execution allows for efficiency by not repeating certain steps unnecessarily. Scheduling attempts to predict dependencies to avoid re-executions, and further optimization opportunities are being explored.

For more details, visit the Monad documentation on parallel execution.

EIP 648

The Ethereum proposal EIP 648 introduced a new transaction type that allows transactions in the EVM to be processed in parallel. Transactions contain a list of address prefixes that represent the range of all addresses with that prefix, and any access to addresses outside this range will fail. This proposal incentivizes easy parallelization of transactions and is maximally backwards compatible with old-style transactions.

The proposal EIP 2930 adds a transaction type which contains an access list, a list of addresses and storage keys that the transaction plans to access. Accesses outside the list are possible but become more expensive.

Issues

In both Solana and EIP 648, the account lists provide coarse-grained concurrency control at the account level meaning that only transactions accessing different accounts can be processed in parallel without conflicts. Transactions that access the same account, even if they access different states within that account, are subject to serial execution to prevent potential conflicts and ensure state consistency.

However, both Solana and Fuel’s concurrency control mechanisms do not support intra-contract parallelization, meaning that transactions calling the same contract must be processed sequentially to ensure data consistency and prevent conflicts.

It is a common pattern that when a popular decentralized application (dApp) is released, a large portion of the transactions on the blockchain are related to that application. It can attract a significant number of users and generate a high volume of transactions. It is obvious that a blockchain must be capable of parallelizing concurrent calls to the same smart contract