What is parallel execution?
Running transactions at the same time when they touch different state, rather than one after another in list order.
Not yet verifiedHow we verify
3 min read
In this entry
Running transactions at the same time when they touch different state, rather than one after another in list order.
Most blockchains process a block by executing its transactions strictly in order, one at a time, because each may depend on the result of the last. That is simple and correct and it wastes every core but one. Parallel execution is the attempt to use the rest.
The term appears in chain marketing constantly, usually attached to a throughput figure. What the figure omits is that the gain depends entirely on the workload, and workloads in crypto are frequently the opposite of parallelizable.
How it works
Two approaches dominate.
Declared access. Transactions state in advance which accounts they will read and write. The scheduler can then group non-overlapping transactions and run them together with no risk of conflict. Solana works this way (source: the Solana documentation), and its account model exists largely to make this possible.
Optimistic execution. Transactions run in parallel without declarations, while the runtime tracks what each one touched. Any pair that conflicts is detected afterward, and one is re-executed in order. This requires no changes from developers but wastes work when conflicts are common.
Sui takes a third path, treating objects rather than accounts as the unit of ownership, so transactions touching only objects you own can skip full consensus ordering entirely.
The limitation is the same in every case. The gain shows up only when activity is spread across many accounts. A thousand transactions all trading the same pool still serialize, because every one of them reads and writes the same state.
That also changes how congestion feels. Contention is per account rather than global, so one heavily traded market can price out its own users without slowing unrelated activity, which is a different experience from a chain where a popular mint makes everything expensive at once.
Example
Illustrative comparison of two blocks of 1,000 transactions on a chain with 8 execution threads.
| Block contents | Conflicts | Effective speedup |
|---|---|---|
| 1,000 transfers between 1,000 distinct account pairs | None | Close to the thread count |
| 1,000 swaps against one liquidity pool | Every transaction | None, execution is serial |
| A realistic mix | Some | Somewhere between |
The headline number a chain publishes is measured on the first row. The experience during a popular launch is the second.
Why it matters when you buy
Treat throughput figures as workload-dependent, which is why RampAtlas measures chain throughput from recent blocks rather than quoting design maximums. Those measurements, with the window and method stated, are on the chain rankings. For a buyer the practical consequence is that a chain can be fast and still be congested for the specific activity you care about, which shows up as failed transactions or high priority fees during a busy event.
Related terms
- program — Solana's term for a contract
- pda — the account model this depends on
- compute unit — how work is metered per transaction
- priority fee — what contention makes you pay
- evm — the sequential execution environment
- move language — the language behind Sui's object model
Questions
Does parallel execution make transactions cheaper?
Indirectly, by raising capacity when activity is spread out. It does nothing for contention on a single hot account, which is where fees actually spike.
Why do transactions still fail on fast chains?
Because failure during congestion is usually about contention for one piece of state, or about a priority fee too low to win a place, rather than about the chain's total capacity.
Can Ethereum do this?
Ethereum's execution is sequential today, and proposals for parallel execution with access lists have been discussed for years. Some layer 2s and alternative clients experiment with it.