Over the past two years, it has become clear that increasing TPS alone no longer solves blockchain scalability. The critical bottleneck increasingly shifts from the consensus layer to the execution layer, where transactions compete for shared state and create conflicts in parallel processing.
Recent research conducted in 2025 reinforces this change. THE NEMO (2025) shows that even high-speed networks face performance degradation caused by write conflicts, and that parallelism without conflict management mechanisms does not translate into real scalability. Effective Parallel execution of blockchain transactions leveraging contention specifications (2025) demonstrates that significant throughput gains are only achieved when read/write sets are explicitly defined and controlled at the transaction level.
In practice, this means that blockchain scalability depends less on consensus and much more on the execution architecture – from state design and access optimization to workload scheduling and conflict resolution during peak load. These emerging trends, constraints and technical responses in high-load environments have been discussed by Alexander KalankhojaevSenior Responsible Engineer at Raiku.
1. Why is the blockchain scalability debate shifting from network speed to deeper questions of execution architecture?
High network throughput has long been a basic requirement across many industries – from streaming to large-scale distributed computing – and blockchains directly benefit from these advancements. There are blockchain-specific attempts to push networking further, such as DoubleZerowhich builds an efficient physical network for validators. However, such approaches are expensive, operationally complex, and difficult to scale globally.
If the term “network” is understood at the application layer – consensus algorithms and P2P communication – this space is also relatively mature. It has been evolving for decades and continues to improve, but mainly through incremental optimization. A recent example is the Alpenglow consensus work done by Solana, which shows that significant gains are still possible, even if they are no longer transformative in terms of scalability.
The execution, on the other hand, remains relatively young. The first blockchains were designed around strictly serial transaction processing, without any assumption of parallelism. Newer systems, such as Solanawere built with parallel execution as a fundamental principle. Despite this, many execution layer algorithms have proven to be suboptimal in practice and have been redesigned several times. Parallelism also introduces new constraints: state conflicts, hot counts, conflicts, scheduling complexity, and synchronization overhead.
As a result, scalability is increasingly determined by the execution architecture: state layout, access patterns, transaction scheduling, and conflict resolution, rather than raw network speed.
2. Which aspects of the execution layer have the greatest impact on user experience: latency, overhead, or predictability?
These three elements shape the user experience, but under peak load the deciding factor is predictability – the ability of the system to produce clear and consistent results. Above all, users want to know whether a transaction will be included within a scheduled timeframe or rejected according to well-defined rules.
Predictability answers the user’s main question: “Will my transaction execute or will it start to fail: get stuck, conflict, or be repeatedly repriced?” » In case of congestion, uncertainty is seen as more damaging than moderately higher fees.
Latency is essential for trading, gaming, and responsive interfaces, but average latency is a weak signal in itself. What matters is the final latency: when blocks are congested, a small subset of transactions can experience extreme delays, degrading the UX even if average performance seems acceptable.
Fees are the most visible cost, but users are often willing to pay more when transaction inclusion is reliable and execution results are stable and repeatable.
Ultimately, conflicts at the execution layer—competition for hot states, read/write conflicts, and inefficient scheduling—are what transform a blockchain from “fast in benchmarks” to “chaotic in peak demand.”
3. Are we entering a new competitive race – not for TPS, but for delivery models and state management approaches?
TPS in blockchains remains largely a marketing measure. In isolated, controlled environments, it is possible to demonstrate almost any level of throughput, making TPS figures unrepresentative of real-world performance.
As systems operate under increasing load, the focus shifts from nominal TPS to more meaningful metrics, such as effective throughput under state conflict and system behavior under peak demand. These metrics better capture a network’s performance under production conditions rather than laboratory benchmarks.
The real competition between blockchains today is therefore defined by the architecture of the execution layers, in particular:
- what degree of parallelism the system can maintain once conflicts are resolved;
- how predictably and gracefully it deteriorates as conflicts over the people’s state intensify;
- what guarantees it offers to users and developers: fairness, determinism and transparent rules for including transactions.
It is in these properties that true scalability becomes visible, not in the key TPS numbers.
4. What architectural decisions regarding state design help not only increase performance, but also maintain stability under extreme loads?
Several architectural choices systematically improve both throughput and system stability:
- State Sharing and Partitioning: Reduces hot spots by design, so that the load is distributed across state-independent segments.
- Minimize shared world state – avoiding “one meter that everyone touches” schemes, which inevitably become bottlenecks in conflict.
- Deterministic conflict management: Predictable order or deterministic attempts reduce chaotic behavior when conflicts arise.
- Scheduling adapted to the workload: prioritize transactions that unlock others; the more downstream work a transaction allows, the higher its priority. This approach is clearly visible in Firedancer.
- Limited runtime and backpressure mechanisms — protecting both the system and users from cascading failures in the event of overload.
This list is far from exhaustive. Execution layer architecture and state design remain rapidly evolving areas, continually producing new ideas and solutions as blockchains are pushed to the limits of the real world.
5. How is responsibility for scalability transferred between protocol-level design and application-level engineering?
Responsibility is increasingly shared. Application builders no longer focus only on surface-level business logic or security. Modern protocols expose primitives and tools designed for safe and scalable execution, but their effective use requires a deeper understanding of how the system actually works.
Application engineers must now reason about the protocol at a lower level: what execution guarantees it provides, how state is accessed, and how conflicts are handled. This represents a significant shift in responsibility. Scalability can no longer be seen as something that the protocol “solves” on its own. Poor state design cannot be parallelized, and applications that ignore access patterns will become bottlenecks on even the most advanced execution engines.
6. Which execution models are most likely to set industry-wide standards in the next phase of Web3?
Parallel execution is no longer optional: modern hardware makes it a necessity rather than an optimization. Among emerging approaches, the most promising models are those based on explicit read/write sets or on declared conflict specifications.
By requiring transactions to indicate what they are reading, writing, or potentially conflicting with, the system gains advanced visibility into runtime dependencies. This enables deterministic scheduling, avoids unnecessary executions, and preserves stable throughput even in the event of high conflicts. The tradeoff is that more responsibility is shifted to application developers, which is why we’ll likely see new abstractions and tools emerge to make these models safer and easier to use without exposing all the low-level details.
7. Could a redefined execution layer reshape blockchain economics – from fee markets to transaction prioritization to validator incentives?
Yes, and it is already starting to happen. As execution becomes more deterministic and conflict-sensitive, it affects not only performance but also the economic structure of blockchains, including transaction prioritization and MEV mining.
With insight into conflicts and execution impact, validators are no longer forced to prioritize transactions based solely on fees. Instead, they can prioritize transactions that reduce contention or unlock more parallelism, thereby maximizing total throughput and revenue. On the user side, fees increasingly reflect not only compute usage, but also the cost of contention – effectively paying for access to a rare or hot state.
In this sense, the execution architecture becomes an economic primitive, influencing who is included, what users pay, and how fairness is defined at the system level.
