Application Rollup Technology Explained: The Key to Mainstream Adoption of High-Throughput Apps
TechFlow Selected TechFlow Selected
Application Rollup Technology Explained: The Key to Mainstream Adoption of High-Throughput Apps
Rollup is the best existing solution for scaling high-throughput applications, especially fully on-chain games.
Navigating Web3 tides with focused insightsAuthor: Mohamed Fouda
Translation: TechFlow
App-specific rollups are emerging as the clear winner for scaling a specific set of Ethereum applications. These applications benefit from permissionless access and strong ownership guarantees but do not require simultaneous interaction among all users. Fully on-chain games are the best example. On-chain games benefit from strong ownership of in-game assets, allow anonymous participation, and support permissionless modification of game logic. Nevertheless, most games do not require all players to interact simultaneously. Other applications that could benefit from app-specific rollup scaling include NFT marketplaces, perpetual exchanges, and on-chain AI inference.
App-specific rollups have already become the preferred implementation for many of these use cases. However, standard rollup implementations—such as EVMRollup—still face significant scalability limitations. They may achieve throughput of around 100 transactions per second. For certain on-chain games, this throughput might be sufficient depending on the game type. But most games require higher throughput to support large numbers of concurrent players (over 1,000). This article focuses on methods for scaling app-specific rollups to support hundreds of thousands of concurrent participants. For each approach, I discuss suitable application/game types and their associated challenges.
Horizontal Scaling
Horizontal scalability is the simplest method for scaling app-specific rollups. However, this simplicity comes at the cost of composability, making it suitable only for a narrow set of applications—such as single-player games.
Horizontal scalability simply means deploying multiple app-specific rollups (Optimistic or ZK) and deploying identical smart contracts across all rollups. The application's frontend seamlessly directs users to one of these rollups based on capacity, location, or specific application preferences. Alt Layer recently demonstrated this concept by launching a scalable 2048 FOCG game. In the game’s frontend, users can choose which rollup to join based on their geographic location. Due to its simplicity and the availability of rollup-as-a-service providers like Caldera—which handle all infrastructure tasks related to spinning up and managing these rollups—this method can be easily adopted by game developers.
However, the multi-rollup scaling approach has several issues. The first is network switching between rollups. Current wallets, such as MetaMask, require manual approval to connect to a new network—that is, a new rollup instance. This creates difficulty and confusion for players, who must manually connect to multiple "networks" to play the same game. Fortunately, account abstraction (AA) solutions can eliminate this complexity—for example, EIP-4337 and embedded wallets like Privy and 0xPass.
Another challenge is managing player state during transitions between rollups. In some cases, such as when capacity drops, an application may need to merge multiple rollup instances into a single one to save resources. In such scenarios, the active states of all players must be migrated to the new instance. Current bridging solutions—especially zk bridges—can play a critical role in addressing this issue. Using these solutions, a player’s game state can be bridged to a new rollup instance while maintaining validity proofs over that state. However, latency from existing bridge solutions may not be optimal for gaming use cases.
ZK State Channels
Another approach better suited for multiplayer games—such as poker—is ZK state channels. In these games, player interactions occur among a small group (e.g., 2–10 players). Gameplay among these players matters only during the session. However, the final outcome of the game is more important because it affects each player’s asset balance. Therefore, storing the result in a shared, persistent layer is crucial.
In this case, the app-specific rollup serves as the shared information layer where game results are stored and where game assets reside. For each game on the rollup, a ZK state channel can be initiated to serve that particular match. During gameplay, each player generates transactions and creates ZKPs proving they followed the game rules. Proofs of interactions with other players are aggregated using recursive proofs built upon the previous proof. When the game ends, the final ZKP is submitted to the app rollup to prove the validity of both gameplay and the final outcome. The resulting state changes update the players’ states on the app rollup.
ZK state channels move game interactions off-chain. As a result, in-game actions and transactions do not count toward the app rollup’s throughput. With this method, app rollups can scale massively to support thousands of concurrent players. Transactions on the app rollup consist only of verifying generated ZKPs and processing state updates—offering a scaling factor of 100–1,000x. Several teams, including Ontropy, have been developing this technology.
One drawback of this approach is that players must run game logic on their own devices and generate ZKPs. Typically, these proofs are lightweight, and with advanced proving systems like Halo2, generation can take just a few seconds. However, this may still degrade the experience for players on resource-constrained devices.
One modification to mitigate this issue is to designate one of the zk state channel participants as a temporary sequencer. This sequencer receives each player’s transactions, generates the corresponding ZKPs, and shares them with all channel participants. This modified setup can be viewed as a short-lived ZK L3 that settles into the app rollup. The Cartridge team implemented this architecture by designing a dedicated sequencer called Katana.
The zk state channel approach holds great potential. However, several open questions remain regarding the execution environment within zk state channels and how to optimize recursive proofs. Current zkEVM environments are inefficient, and most do not currently support recursive proving. Alternatives include lightweight zkVMs or even specialized zk circuits if the number of possible player actions is limited.
Changing the Execution Environment
A third method for scaling app-specific rollups is changing the rollup’s execution environment. Despite the maturity and richness of EVM development tools, they are ill-suited for high-performance applications such as games. Additionally, the EVM’s single-threaded execution model and storage design lead to lower throughput, which can be improved.
The main advantage of this approach is that increasing rollup throughput does not require sacrificing composability or limiting the range of use cases. As long as the execution environment achieves the required throughput, this method can support any Web3 application. This makes it the only viable solution for applications requiring access to shared state—such as AMMs, lending protocols, and other DeFi applications.
Extending EVM Capabilities via Precompiles
First, the rollup maintains EVM compatibility while overcoming some of its throughput limitations through precompiled contracts. The idea is simple: precompiles push computationally intensive EVM operations down to the node level. An operation requiring hundreds or thousands of EVM opcodes and consuming over 100k gas can be reduced to a single operation with gas costs lowered by up to 100x. Precompiles that extend the rollup environment are often referred to as EVM+. Examples include supporting on-chain privacy and more efficient signature schemes such as BLS signatures. For instance, the zkHoldem poker game uses custom FHE and zk operations to enable private card dealing and revealing. Development of these specialized precompiles is typically a joint effort between app rollup developers and RaaS providers responsible for deploying and maintaining the rollup infrastructure.
Using Non-EVM Execution Environments
Another way to improve the rollup execution environment is to move away from the EVM. This approach is gaining popularity among new developers in the Ethereum ecosystem and those who believe Solidity is not ideal for building complex applications.
Today, we see app-specific rollups running on WASM, SVM, Cairo, and even Linux runtimes. Most of these approaches allow developers to write smart contracts using high-level languages like Rust or C. The downside is often a loss of interoperability with existing Solidity contracts. However, EVM compatibility can still be achieved. For example, Arbitrum’s Stylus uses a coprocessor design to make Stylus contracts compatible with the EVM. This design makes Stylus closer to an EVM+ architecture than a fully non-EVM system.
Hybrid Execution Environments
A third approach—particularly favored by FOG—is combining the best aspects of the previous two methods. This hybrid approach integrates EVM compatibility with a dedicated non-EVM execution environment. The non-EVM environment focuses on high-performance execution of core game primitives, while game asset management—such as in-game NFT trading—is handled by standard Solidity contracts.
This approach benefits from EVM compatibility, ensuring alignment with the broader developer ecosystem and existing products. It also enables permissionless composability—developers can modify and extend game logic by adding EVM/Solidity smart contracts. At the same time, the dedicated non-EVM game engine achieves throughput unattainable with the EVM alone.
Examples of this approach include Argus’s World Engine and Curio’s Keystone. World Engine separates game logic execution into a distinct layer called the Game Shard, which runs atop an EVM-compatible layer. The Game Shard is also designed to allow horizontal scaling, enabling adjustment of total rollup throughput based on demand. Similarly, Curio’s Keystone architecture bundles a high-throughput game engine with the EVM as the rollup’s execution environment. The key challenge here is achieving seamless interoperability between the EVM engine and the game engine.
Data Availability Considerations
The preceding discussion focused on increasing rollup transaction throughput—the primary aspect of scaling app-specific rollups. Other topics related to this increased throughput include data availability (DA), sequencer decentralization, and settlement speed. Among these, data availability is the most pressing issue for high-throughput app rollups.
An individual app rollup may achieve throughput exceeding 10,000 transactions per second. Using Ethereum as the data availability layer for these transactions is impractical. First, the average cost of publishing simple L2 ETH transfer data on L1 can exceed $0.10—prohibitively expensive for most app rollups. More importantly, Ethereum’s L1 cannot currently support more than approximately 8,000 transactions per second for rollups relying on it for data availability.
App-specific rollups will primarily rely on external DA solutions. Celestia and EigenDA are currently positioned as the most viable options. For example, Eclipse plans to use Celestia as the data availability layer for its high-throughput SVM-based base rollup. Argus and high-throughput game engines also plan to initially use Celestia. Similarly, EigenDA promises data throughput of up to 10MB per second, offering a feasible solution for multiple app rollups.
However, the main drawback of integrating Celestia or EigenDA is economic value leakage. App rollups must pay fees to the DA layer as well as settlement fees on Ethereum L1. Settlement fees are critical for app rollups, as they tie the rollup’s security to Ethereum’s security. DA guarantees are less critical in the context of FOG, where transaction values are much smaller than those on these networks. Moreover, Celestia and EigenDA promise low fees due to low initial utilization as these networks are just launching. However, once these DA networks reach high utilization, DA fees may also become prohibitively high. In my view, app-specific rollups should use a simple Data Availability Committee (DAC) to attest to the availability of rollup data.
In conclusion, I believe app-specific rollups represent the best existing solution for scaling high-throughput applications—especially fully on-chain games. Scaling these rollups is key to achieving mainstream adoption beyond native crypto users.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
Alliance
