How Blockchains Execute Transactions: Sequential, Parallel, and Object-Centric Scalability Models in 2026

Key Takeaways

Blockchain scalability ultimately depends on how the execution layer handles state contention when transactions touch the same data. Five architectures define the 2026 landscape.

• Execution model choice sets the throughput ceiling. Sequential chains like Ethereum top out near 15 TPS. Parallel designs reach thousands.
• Solana uses upfront access declarations in every transaction, allowing the Sealevel runtime to dispatch non-conflicting transactions across multiple cores.
• Aptos Block-STM runs transactions optimistically and re-executes any whose reads were invalidated by earlier transactions in the same block.
• Sui treats assets as objects with explicit owners. Owned-object transactions bypass full consensus and finalize in under a second.
• Monad preserves EVM compatibility while adding speculative parallel execution, so Solidity contracts run unmodified at higher throughput.
• Validator hardware scales with the execution model. Ethereum runs on consumer machines. Solana and Monad require datacenter-class servers.

Blockchain scalability ultimately depends on how the execution layer handles state contention when transactions touch the same data. Five architectures define the 2026 landscape.

• Sequential execution on Ethereum
• Upfront parallel on Solana
• Optimistic parallel on Aptos
• Object-centric on Sui
• Speculative parallel EVM on Monad

Blockchain Scalability in a Nutshell

First, let’s take a general look at the ways scalability is handled under different philosophies.

Model	Chain	Parallelism Strategy	Peak Throughput	Developer Model	Validator Profile
Sequential	Ethereum	None (serial EVM)	~15 TPS	Natural composability, no access lists	Consumer hardware
Upfront parallel	Solana	Transactions declare account access in advance	Several thousand TPS sustained	Rust with explicit account references	High core count, NVMe, fast network
Optimistic parallel	Aptos	Block-STM with speculative execution	Tens of thousands of TPS in disjoint benchmarks	Move, feels serial to the developer	Many cores, extra memory for multi-version store
Object-centric	Sui	Owned vs shared objects, bypass consensus for owned	Sub-second finality on owned-object transactions	Move with object ownership semantics	Moderate, scales with shared-object traffic
Speculative EVM	Monad	Optimistic concurrency on EVM bytecode	Targeted at thousands of TPS	Solidity, unchanged from Ethereum	High core count, fast storage

Why Execution Order Matters

State contention is the central problem every blockchain must solve. Two transactions that touch the same account cannot both execute as if the other did not exist.

The system must pick an order and enforce it deterministically across every validator.

Consider three transactions in a block:

• T1 transfers USDC from Alice to Bob
• T2 transfers a different stablecoin between unrelated accounts
• T3 swaps ETH for USDC on a DEX where Alice just sent her tokens

T1 and T2 touch disjoint states and can run simultaneously. T1 and T3 both read or write Alice’s USDC balance, so their ordering changes the outcome.

The execution layer must produce the same result on every node from the same ordered input.

How the node gets there is an implementation choice. Some designs serialize everything. Others extract parallelism wherever they can prove it is possible.

Three factors complicate the choice:

• Contracts can call other contracts, so read and write sets are not always knowable in advance
• Storage layouts built for one execution model are often inefficient for another
• Consensus layers have their own latency budgets, and time spent executing a block is time the network cannot spend propagating the next one

The rest of this article walks through how five production systems resolve these tensions.

Sequential Execution (Ethereum)

Ethereum caps at around 15 transactions per second because it processes each transaction serially within a single EVM instance. The payoff for this bottleneck is the simplest and most composable developer environment in the industry.

Validators take the ordered list of transactions in a block, apply each one to the global state, and produce a new state root. One transaction at a time, no concurrency, no speculation.

Every opcode runs with a fully materialized view of the prior state. Developers writing in Solidity do not need to worry about race conditions because none exist at the execution layer.

Any contract can call any other contract and observe the effects of any transaction earlier in the same block. This property underpins much of what DeFi has built since 2015.

The EVM gas limit caps are set to ~30 million gas per 12-second block, resulting in a throughput ceiling near 15 TPS on Ethereum mainnet.

The throughput ceiling is determined by the gas model. The EVM caps work per block at around 30 million gas, and that work must complete within a 12-second slot.

Gas meters computation so blocks finish in time, and it prices state access so storage cannot be consumed for free. Because every opcode runs serially, gas accounting is straightforward.

For how validators participate in this process, see our Ethereum staking guide.

Ethereum’s scaling strategy has moved away from base-layer execution speed and toward rollups. Layer 2 systems inherit the sequential EVM semantics but move execution off-chain, posting compressed state transitions back to the mainnet.

The sequential model on L1 persists because it is the most conservative foundation for settlement.

Upfront Parallelism (Solana)

Solana trades developer flexibility for raw throughput. Every transaction must declare, in its header, the full list of accounts it will read or write.

The Sealevel runtime uses these declarations to dispatch non-conflicting transactions across available CPU cores.

The scheduler inspects access lists when a block producer assembles a block. Two transactions that do not overlap in writable accounts execute simultaneously. Two transactions that both write to the same pool execute in sequence.

A modern validator with dozens of cores can often process hundreds of transactions in the time it takes Ethereum to process one.

The design places the burden of correctness on the developer and the compiler. A transaction that fails to declare an account it actually accesses will abort.

Programs on Solana, therefore, use a more restrictive data model than EVM contracts, with explicit passing of account references rather than arbitrary cross-contract calls.

The resulting programming model sits closer to a systems language than to Solidity, which is one reason Solana adopted Rust as its primary contract language. See our Solana staking overview for details on validators.

Solana mainnet has sustained several thousand TPS in production, orders of magnitude above serial EVM chains.

The cost appears elsewhere. The hardware requirements for the validator sit among the highest in the industry.

Running Sealevel at full speed requires:

• Many CPU cores
• Fast NVMe storage
• High-bandwidth networking

State growth is aggressive, and rent mechanics exist to bound storage costs.

Upfront parallelism works best when transactions genuinely touch disjoint state, as in payments and NFT mints.

It degrades when many transactions contend for the same hot account, such as a popular AMM pool during high-volume trading. In those cases, the scheduler serializes contending transactions, and parallelism gains collapse for that portion of the workload.

Optimistic Parallelism (Aptos Block-STM)

Block-STM delivers parallelism without requiring developers to provide access lists. The runtime executes transactions in parallel speculatively, tracks read and write sets as they occur, detects conflicts, and re-executes any transaction whose reads were invalidated.

Developers write code as if execution were serial, and the runtime automatically extracts parallelism.

The algorithm assigns each transaction an index matching its position in the block. Worker threads execute transactions against a multi-version data structure that stores multiple historical values per storage key.

When a transaction reads a key, it reads the latest version written by a transaction with a lower index. If a later transaction discovers that a lower-indexed transaction wrote a different value to a key it had already read, the higher-indexed transaction aborts and reruns.

The process repeats until the block reaches a stable, fully validated state.

A block full of independent transfers parallelizes almost perfectly. A block with heavy contention on a single hot contract incurs re-execution overhead, though it never produces an incorrect result.

For details on Aptos validator operations, see our Aptos staking page.

Block-STM originated in research on the Diem project and has since been refined in production. Measured throughput on Aptos depends heavily on workload composition.

Benchmarks with disjoint state have reported tens of thousands of transactions per second on well-provisioned hardware. Benchmarks with heavy contention show lower numbers, though still well above what a serial execution model would achieve on the same workload.

The design trades predictability for ease of development. A Solana developer can reason statically about whether two transactions will conflict.

An Aptos developer accepts that the runtime may perform speculative work that is discarded under contention.

Validators provide for the worst case, since re-execution consumes real CPU cycles. Memory usage also increases because the multi-version store maintains multiple copies of contended storage slots during execution.

Object-Centric Parallelism (Sui)

Sui avoids state contention entirely for most user activity by reframing assets as objects with explicit owners. Peer-to-peer transfers finalize in under a second because they never touch the full consensus protocol.

Instead of accounts holding balances, Sui represents every asset as an object with a unique identifier and an owner:

• A coin is an object
• An NFT is an object
• A shared liquidity pool is an object

The execution engine uses object ownership to determine which transactions can run without coordination.

Two kinds of objects exist. Owned objects belong to a single address and can only be modified by transactions signed by that owner. Shared objects have no single owner and can be touched by multiple parties.

The distinction matters at the consensus layer. A transaction that touches only owned objects does not need total ordering across the network, because no two independent owners can produce conflicting transactions against the same object.

These transactions finalize through a simpler causal broadcast protocol, bypassing the full consensus path.

On Sui, peer-to-peer transfers finalize in under 1 second because owned-object transactions bypass the full consensus protocol entirely.

Only transactions involving shared objects, such as swaps on a DEX or governance votes, require full consensus ordering. Our Sui staking documentation covers how validators participate in both paths.

The object model reshapes contract development. Move, the language Sui uses treats objects as first-class values with move semantics. An object cannot be copied silently.

Transferring an NFT means moving the object from the sender’s storage to the recipient’s, rather than decrementing one counter and incrementing another.

The result sits closer to how physical assets behave than to the ledger model used by account-based chains.

Scalability in Sui comes from the fact that the common case, owned-object transactions, does not consume consensus bandwidth. Shared-object transactions fall back to the full protocol, with throughput characteristics closer to other parallel systems.

The bet is that most user activity touches only owned objects:

• Token transfers
• NFT mints
• Similar simple operations

The cost is developer complexity. Building a DeFi protocol on Sui requires careful consideration of which state must be shared and which can be owned, as this choice affects both latency and composability.

Tooling, debugging, and mental models differ across EVM chains, slowing the migration of existing applications.

Speculative Parallel EVM (Monad)

Monad brings parallel execution to the existing EVM ecosystem without requiring developers to change their code. A contract that runs on Ethereum runs on Monad with identical semantics.

The parallelism happens inside the runtime, hidden from the application layer.

The approach combines several techniques:

• Monad pipelines consensus and execution, so a new block can begin executing while the next is still being agreed upon
• It uses optimistic concurrency, similar in spirit to Block-STM, executing transactions in parallel and detecting conflicts through read and write set tracking
• It backs this runtime with MonadDB, a purpose-built database designed for the access patterns of parallel EVM execution rather than those of a single-threaded interpreter

The value is ecosystem preservation. The following all work without modification:

• EVM tooling
• Solidity
• Hardhat
• Foundry
• MetaMask
• Years of audited contract code

A team that has shipped a protocol on Ethereum can redeploy on Monad and inherit the parallelism gains without rewriting anything. This matters because a large fraction of industry-developed knowledge is EVM-specific.

The challenge is that EVM semantics were not designed with parallelism in mind. Contracts freely call other contracts, read storage slots whose addresses are computed from runtime inputs, and emit logs in an order that external systems depend on.

A speculative executor has to either guess correctly often enough to beat serial execution, or fall back cleanly when it guesses wrong.

Monad’s published benchmarks suggest the approach works well for typical workloads, though performance under adversarial conditions will depend on how well the scheduler predicts access patterns in practice.

Monad’s design also pushes storage and networking requirements upward. Parallel execution at EVM scale generates more state transitions per second than a serial chain, increasing the amount of data that validators must persist and propagate.

The validator profile sits closer to Solana’s than to Ethereum’s, with high core counts and fast storage as the baseline requirement.

What This Means for Validators

The execution model choice determines the validator hardware, and the range across current architectures is wide. Ethereum validators can run on consumer machines. Solana and Monad require datacenter-class servers.

Operating across all five chains means maintaining distinct infrastructure profiles for each.

Ethereum sets a low CPU ceiling because the sequential EVM cannot use more than one core at a time. A modern consumer CPU with 32 GB of memory and a 1 TB SSD handles the workload with room to spare.

The binding constraint is network latency, not compute.

Solana sits at the other extreme. Sealevel parallelism benefits from many cores, and the high transaction rate produces high disk and network load.

Real operators run dual-socket servers with NVMe arrays and multi-gigabit uplinks. Sui and Aptos fall between these poles, with the specific profile depending on whether workload contention keeps the parallel engine busy or forces frequent re-execution.

Monad aligns more closely with Solana because its underlying throughput goals are similar.

These differences affect decentralization in practical ways. Lower hardware requirements mean more independent operators can participate without subsidy, which tends to produce geographically distributed validator sets.

Higher requirements concentrate validation in successful infrastructure providers. The trade-off resists a simple ranking, because decentralization is only useful if the network can actually handle the load users put on it.

Everstake operates validators across all five of these architectures. Running a single cohesive operation across models with such different demands requires:

• Separate runbooks
• Separate monitoring stacks
• Separate upgrade procedures for each chain

The engineering work required to support Ethereum, Solana, Aptos, Sui, and Monad in production is substantial. It gives us visibility into how each model behaves under real conditions rather than benchmarked ones.

FAQ

Is parallel execution always faster than sequential?

No. Parallel execution adds overhead for scheduling, conflict detection, and sometimes re-execution. For blocks with high contention on a single hot contract, the gains can be small or negative.

Parallel models perform best when transaction workloads are diverse enough that most transactions touch disjoint state.

Does Ethereum plan to add parallel execution?

The primary scaling strategy remains rollups. Ethereum’s roadmap has explored various forms of parallelism at the L1 level, though L2 systems provide the main path forward.

L2s can adopt any execution model internally while settling on a sequential L1 base layer. Several L2s and alt-L1s are essentially parallel-EVM designs with different consensus and data availability choices.

How does Block-STM compare to database optimistic concurrency control?

The ideas are closely related. Both execute operations speculatively and validate read sets before committing.

Block-STM adapts the approach to the specific constraints of blockchain execution, where transactions have a fixed order from consensus, and the result must be deterministic across all validators.

What happens on Sui if a shared object sees heavy contention?

Latency rises to match other fully ordered chains. Transactions touching a heavily contended shared object are serialized through consensus.

The object model advantage applies only to owned-object transactions. Application developers on Sui design around this by keeping hot paths in owned-object territory where possible.

Is Monad a Layer 2 or a Layer 1?

Monad is a Layer 1 blockchain with its own consensus protocol and validator set. It is EVM-compatible at the execution layer, meaning Solidity contracts can be deployed without modification.

It does not settle on Ethereum or inherit Ethereum’s security.

Why do some chains report much higher TPS than others?

TPS numbers depend heavily on the benchmark. Simple transfers parallelize well and produce large numbers. Contended DeFi workloads produce much lower numbers on the same hardware.

Comparing headline TPS across chains without specifying workload composition is rarely informative.

Which execution model is best for DeFi?

There is no universal answer. Sequential EVM provides strong composability and the deepest tooling. Parallel models offer higher throughput at the cost of either developer constraints or runtime unpredictability.

Many protocols now deploy across multiple chains to give users a choice.

Do execution models affect validator rewards?

Indirectly. Different models produce different fee markets and different MEV dynamics.

Chains with high parallelism and low contention tend to have lower fee volatility, while heavily contended chains produce fee spikes during busy periods.

Validator economics depend on the mix of:

• Base issuance
• Priority fees
• MEV capture on each specific chain

Disclaimer:

This guide is provided for informational purposes only and does not constitute legal, financial, tax, or investment advice. The information contained herein reflects the state of applicable regulations and market practices as of the date of publication and is subject to change without notice. Readers should not rely on this material as a substitute for independent professional advice tailored to their specific circumstances.

Institutions should consult qualified legal and compliance counsel before making any decisions relating to staking arrangements, custody models, or regulatory status.