For the past decade, sequential execution has been Ethereum's core design principle for ensuring consistency and security. However, as DeFi, stablecoins, Layer 2 solutions, and on-chain finance have continued to scale, this execution model has begun to reveal performance bottlenecks. Meanwhile, next-generation blockchains like Solana, Sui, and Aptos have made parallel execution a core architectural feature, consistently pushing network throughput higher. In this competitive landscape, Ethereum is now undertaking a systematic upgrade of its underlying execution logic through Glamsterdam.
From a blockchain technology evolution standpoint, parallel execution means more than just a higher TPS. It represents a fundamental redesign of Ethereum's state management, transaction scheduling, and resource allocation. If these upgrades are gradually implemented, Ethereum's Layer 1 could evolve from a traditional smart contract platform into a large-scale open settlement network that underpins global digital assets and on-chain financial activity.
Why Has Ethereum Always Used Sequential Execution?
Since Ethereum's inception, sequential execution has been a cornerstone of network operation. In this model, transactions within a block must be processed one by one in a fixed order — the next transaction cannot begin until the previous one finishes. Nodes follow the exact same execution sequence, ensuring everyone arrives at a consistent final state.
The primary advantage of this design is its simplicity and security. No matter how complex the transaction logic, all nodes execute in the same order, eliminating state conflicts or inconsistent results. Ethereum's smart contract ecosystem has run stably for the past decade precisely because of this conservative yet reliable execution model.
However, sequential execution also imposes a natural ceiling on network performance.
Even when many transactions in a block are independent, nodes still cannot process them concurrently — they must execute one after another. This design was not a major issue when the ecosystem was smaller, but as on-chain transaction volumes have surged, performance bottlenecks have become increasingly pronounced.
What Bottlenecks Does Sequential Execution Face?
In recent years, the Ethereum network has undergone dramatic changes. Stablecoin transfer volumes have expanded massively, on-chain lending protocols have matured, DEX trading volumes have repeatedly hit new highs, and the number of Layer 2 networks has grown steadily. More and more complex applications now depend on Ethereum as their final settlement layer. Yet the main chain's execution capacity has lagged far behind the pace of ecosystem growth.
The problem manifests in three key areas:
-
Underutilized CPU Resources: Modern servers typically have multiple cores, but under sequential execution, nodes often use only a single thread to process transactions, leaving substantial computational power idle.
-
Transaction Congestion Drives Up Fees: When many transactions enter the network simultaneously, limited execution capacity forces users to pay higher Gas Fees to secure priority inclusion.
-
Constrained Layer 1 Scalability: Even if the Gas Limit is increased in the future, as long as execution remains sequential, overall performance improvements will be limited.
As a result, the Ethereum community has begun to ask: Can we execute non-conflicting transactions simultaneously while preserving security? This is precisely the question that Glamsterdam's parallel execution roadmap aims to answer.
Block Access Lists: The Key Infrastructure for Glamsterdam's Parallel Execution
To achieve parallel execution, Ethereum first needs to know which transactions access which state and which transactions are conflict-free. To solve this problem, Glamsterdam introduces the Block Access Lists (BAL) design.
Simply put, Block Access Lists require transactions to declare in advance:
- Which accounts will be accessed;
- Which Storage Slots will be read;
- Which state will be modified;
- Which data needs to be written on-chain.
With this information, nodes can analyze potential conflicts between transactions before execution begins.
Consider a simple example. Transaction A is a user swapping ETH for USDC; Transaction B is a user minting an NFT. Since these two transactions access different state, the system can determine they can execute simultaneously. However, if two transactions modify the same lending pool or the same account balance, the system will still fall back on sequential execution to avoid state errors.
Block Access Lists do not completely overhaul Ethereum's execution model. Instead, they enable as many transactions as possible to be processed in parallel while maintaining security.
How Does Ethereum Transition from Sequential to Parallel Execution?
Ethereum's path to parallel execution is not a single, one-time change.
Glamsterdam is more like a collection of infrastructure upgrades that gradually equip the network with parallel capabilities by optimizing transaction execution step by step.
-
Introducing Block Access Lists: By requiring transactions to declare their state access range in advance, the system can identify non-conflicting transactions and schedule them for concurrent execution.
-
Optimizing Transaction Scheduling: Nodes dynamically assign execution order based on the state each transaction accesses, allowing multiple CPU cores to work simultaneously rather than processing one transaction at a time as before.
-
State Management Upgrades: With the advancement of Verkle Tree, Stateless Ethereum, and other technologies, the efficiency of state data reading is expected to improve, providing better underlying support for parallel execution.
This incremental upgrade approach is one of the biggest differentiators between Ethereum and other high-performance blockchains.
Ethereum has not dismantled its previous architecture; instead, it is gradually improving performance on top of its existing security model.
What Changes Will Parallel Execution Bring to Ethereum?
For the entire ecosystem, parallel execution means far more than just a higher TPS number. Network throughput is expected to improve significantly: whereas a block could previously only process transactions sequentially, now multiple transactions can run simultaneously, naturally boosting overall execution efficiency.
The trading experience may also be further optimized: as network resource utilization increases, congestion is likely to decrease, and the Gas Fees users pay may become more stable.
For DeFi, parallel execution is equally transformative.
For example:
- DEXes can handle more trades;
- Lending protocols can complete liquidations faster;
- Stablecoin settlement efficiency improves;
- On-chain derivatives trading latency decreases.
For Layer 2 solutions, a higher-performing Layer 1 also means:
- Reduced Rollup submission costs;
- Faster settlement speed;
- Lower user transaction fees;
- Enhanced Layer 2 scaling capabilities.
As more real-world assets (RWA) and institutional capital move on-chain, a high-performance yet secure Layer 1 will become critical infrastructure for the entire ecosystem's growth.
Parallel execution is not a new concept. Solana adopted the Sealevel architecture early on to enable concurrent transaction execution; Sui uses an object model to improve state concurrency; Aptos supports parallel transactions through Block-STM.
So why is Ethereum only now moving toward parallel execution? The answer lies in Ethereum's primary commitment to security and decentralization. It boasts the world's largest node network, the most diverse client ecosystem, and the biggest on-chain asset base. Any change to its underlying architecture must carefully balance compatibility and network stability.
Therefore, Ethereum has chosen an incremental path. Rather than chasing extreme TPS, it is gradually improving network efficiency while preserving openness, decentralization, and security. Although this approach is slower, it also means lower upgrade risk and full compatibility with the existing DeFi and Layer 2 ecosystems.
After Parallel Execution, What's Next for Ethereum?
Glamsterdam is not the final stop for Ethereum's underlying architecture upgrades.
In the coming years, the Ethereum community is pursuing several long-term directions, including:
- Stateless Ethereum;
- Verkle Tree;
- Native Account Abstraction;
- More mature Parallel EVM;
- More efficient data storage structures;
- Quantum-safe cryptography research.
These upgrades all converge on a common long-term goal: to transform Ethereum from a smart contract platform into a global open financial and digital asset infrastructure.
In this journey, parallel execution is not the finish line — it is a critical component of the next-generation Ethereum architecture. As Layer 1 performance continues to improve, Ethereum is well-positioned to balance security, openness, and scalability, supporting an on-chain economy of unprecedented scale.
Summary
From sequential to parallel execution, Glamsterdam is driving a deep architectural upgrade for Ethereum. Through Block Access Lists, state access optimization, and more mature concurrent execution mechanisms in the future, Ethereum aims to improve Layer 1 performance and resource utilization while maintaining decentralization and security.
Rather than simply chasing TPS, Ethereum focuses on long-term sustainable development. Parallel execution not only means faster network speed but also a comprehensive overhaul of underlying resource management, state access logic, and ecosystem scalability. As further infrastructure matures, Glamsterdam may well become a pivotal turning point in Ethereum's evolution toward the next generation of open financial networks.
