Detailed Explanation of Application Rollup Technology: The Key to High Throughput Apps Going Mainstream

Written by: Mohamed Fouda

Original Title: 《How to Scale App-Rollups》

Compiled by: Deep Tide TechFlow

Application Rollups are becoming the clear winners in scaling a specific set of Ethereum applications. These applications benefit from permissionless access and strong ownership guarantees, but do not require all application users to interact simultaneously. On-chain games are the best example. On-chain games benefit from strong ownership of game assets, allowing for anonymous participation and modifications to the game. Nevertheless, most games do not require all players to interact at the same time. Other applications that can benefit from the scaling strategy of application Rollups include NFT marketplaces, perpetual exchanges, and on-chain AI reasoning.

Application Rollups have already become the preferred implementation for many of these use cases. However, standard Rollup implementations, namely EVMRollup, still have significant scalability limitations. They may achieve a throughput of around 100 transactions per second. For certain on-chain games, this throughput may be sufficient, depending on the type of game. However, most games require higher throughput to support a large number of concurrent players (over 1000). This article focuses on methods for scaling application Rollups to cover hundreds of thousands of concurrent participants. For each method, I will discuss the appropriate application/game types and the challenges they face.

Horizontal Scaling

Horizontal scalability is the simplest way to scale application Rollups. However, this simplicity comes at the cost of composability, making them suitable only for a small subset of applications, such as single-player games.

Horizontal scalability means simply deploying multiple application Rollups (Optimistic or ZK) and deploying the same smart contracts across all Rollups. The front end of the application seamlessly guides users to one of the Rollups based on capacity, location, or specific application options. Alt Layer recently demonstrated this concept by launching a scalable 2048 FOCG game. In the game's front end, users can choose which Rollup to join based on their geographical location. Due to its simplicity and the availability of Rollup-as-a-Service providers like Caldera, which handle all the infrastructure work related to spinning up and managing these Rollups, this approach can be easily adopted by game developers.

Nevertheless, the multi-Rollup scaling approach has some issues. The first issue is Rollup network switching. Current wallets, such as Metamask, require manual approval to connect to a new network, i.e., a Rollup instance. This creates a difficult and confusing user experience for players, as they need to manually connect to multiple "networks" to play the same game. Fortunately, this complexity can be alleviated with account abstraction (AA) solutions, such as EIP 4337 and embedded wallets like Privy and 0xPass.

Another challenge is managing player states during transitions between Rollups. In some cases, such as capacity drops, the application may need to merge multiple Rollup instances into a single instance to save resources. In this case, the states of all active players need to be migrated to the new instance. Current bridging solutions, particularly zk bridges, can play a key role in addressing this issue. With these solutions, players' game states can be bridged to a new Rollup instance while maintaining proof of the validity of that state. However, the latency of existing bridging solutions may not be optimal for gaming use cases.

ZK State Channels

Another application Rollup scaling method more suited for multiplayer games (e.g., poker) is ZK state channels. In these games, player interactions occur among a small number of players, such as 2-10 people. The gameplay between these players is only important while the game is in progress. However, the final outcome of the game is more important, as it affects each player's asset balance. Therefore, it is crucial to store the results in a shared persistent layer.

In this case, the application Rollup represents a shared information layer where game results are stored, and game assets also exist. For each game on the Rollup, a ZK state channel can be initiated to serve that game. During gameplay, each player generates transactions and creates ZKPs to prove they followed the game rules. Proofs of interactions from other players use recursive proof aggregation of the previous proofs. When the game ends, the final ZKP is submitted to the application Rollup to prove the validity of the gameplay and the final outcome. The state changes generated by the game alter the player states on the application Rollup.

ZK state channels move game interactions off-chain. Therefore, activities and transactions in the game do not count towards the throughput of the application Rollup. Using this method, application Rollups can scale massively, supporting thousands of concurrent players. The transactions on the application Rollup will simply be validating the generated ZKPs and state update transactions, with a scaling factor of 100-1000 times. Several teams, including Ontropy, have been developing this technology.

One drawback of this method is that it requires players to run the game logic and generate ZKPs on their own devices. Typically, these proofs are lightweight, and with cutting-edge proof systems like Halo2, the proofs can be completed in just a few seconds. However, this may still lead to a degraded experience for players on resource-constrained devices.

One way to mitigate this issue is to designate one of the ZK state channel participants as a temporary sequencer. This sequencer will receive each player's transactions and generate the corresponding ZKPs, sharing the ZKPs with all channel participants. This modification can be seen as a temporary ZK L3 settling to the application Rollup. The Cartridge team has implemented this architecture by designing a dedicated sequencer called Katana.

The ZK state channel method has tremendous potential. However, there are several open questions related to the execution environment within ZK state channels and how to optimize recursive proofs. The current zkEVM environments are not very efficient, and most do not currently support proof recursion. Alternatives include lightweight zkVMs or even using specialized zk circuits to handle player interactions if the number of possible actions for players is limited.

Changing the Execution Environment

The third method for scaling application Rollups is to change the execution environment of the Rollup. Despite the maturity and richness of EVM development tools, they are not suitable for high-performance applications like games. Additionally, the single-threaded execution and storage model of the EVM can lead to reduced throughput, which can be improved.

The main advantage of this method is that increasing Rollup throughput does not require sacrificing composability or limiting the number of use cases. As long as the execution environment can achieve the throughput required by the application, this method can be used for any Web 3 application. This makes them the only viable solution for applications that need access to shared state, such as AMMs, lending protocols, and other DeFi applications.

Expanding EVM Functionality through Precompilation

First, the Rollup remains EVM-compatible and addresses some of the throughput limitations through precompiled addresses. The idea here is simple. Precompilation involves offloading compute-intensive EVM operations to the node level. An operation that requires hundreds or thousands of EVM opcodes and consumes over 100,000 Gas can be simplified to a single operation, reducing the Gas cost by 100 times. The precompilation that expands the Rollup environment is often referred to as EVM+. Examples of this method include supporting on-chain privacy and more efficient signature schemes, such as BLS signatures. For instance, the zkHoldem poker game uses dedicated FHE and zk operations to implement private card dealing and revealing. The development of these specialized precompilations is typically a collaborative effort between application Rollup developers and Raas providers managing the deployment and maintenance of application 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 becoming increasingly popular among new developers in the Ethereum ecosystem and those who believe Solidity is not the best language for developing complex applications.

Today, we have Rollup applications running on WASM, SVM, Cairo, and even Linux runtimes. Most of these methods allow developers to write smart contracts in high-level languages (like Rust or C). The downside is that interoperability with existing Solidity contracts is often lost. However, compatibility with the EVM can still be created. For example, Arbitrum's stylus uses co-processors to make Stylus contracts EVM-compatible. This design brings Stylus closer to an EVM+ architecture rather than a non-EVM one.

Hybrid Execution Environments

The third method, particularly favored by FOG, is to combine the best features of the first two methods. This approach combines EVM compatibility with dedicated non-EVM execution environments. The non-EVM environment focuses on high-performance execution of core game primitives. Game asset management, such as in-game NFT transactions, can be handled by standard Solidity contracts.

The advantage of this method is that EVM compatibility ensures consistency with a larger developer ecosystem and existing products. It also allows for permissionless composability. Developers can modify and extend game logic by adding EVM/Solidity smart contracts. Meanwhile, dedicated non-EVM game engines achieve high throughput that the EVM cannot meet.

Examples of this method include Argus's World Engine and Curio's Keystone. World Engine separates the execution of game logic into a separate layer called Game Shard, which runs on top of the EVM-compatible layer. The Game Shard is also designed to allow horizontal scaling to adjust the total Rollup throughput based on demand. Similarly, Curio's Keystone architecture bundles a high-throughput game engine with the EVM as the Rollup execution environment. The challenge here is to achieve seamless interoperability between the EVM engine and the game engine.

Data Availability Considerations

In the previous discussions, the focus was on increasing Rollup transaction throughput, which is a primary aspect of scaling application Rollups. Other topics related to this increased throughput include data availability (DA), sequencer decentralization, and settlement speed. For high-throughput application Rollups, data availability is the most pressing of these issues.

The throughput of a single application Rollup could exceed 10,000 transactions per second. Using Ethereum as the data availability layer for these transactions is not feasible. First, the average cost of posting simple L2 ETH transfer data on L1 can exceed $0.10. These costs are too high for most application Rollups. More importantly, Ethereum's L1 currently cannot support more than about 8,000 transactions per second for Rollups leveraging L1 for data availability.

Application Rollups will primarily rely on external DA solutions. Celestia and EigenDA are currently positioned as the most viable options for application Rollups. For example, Eclipse plans to use Celestia as the data availability layer for its high-throughput SVM-based Rollup. Argus and high-throughput game engines also plan to initially use Celestia. Similarly, EigenDA promises data throughput of up to 10MB per second, which could also provide viable solutions for multiple application Rollups.

However, the main drawback of integrating Celestia or EigenDA is economic value leakage. Application Rollups must pay fees for the DA layer, as well as settlement fees on Ethereum L1. Settlement fees are critical for application Rollups as they tie the security of the Rollup to the security of Ethereum. DA guarantees are less important in a FOG context where the transaction value is far less than that of these networks. Additionally, Celestia and EigenDA promise low fees because these networks are just starting up, and initial utilization will be low. When these DA networks achieve high utilization, DA fees may also become excessive. In my view, application Rollups should use a simple Data Availability Committee (DAC) to prove the availability of Rollup data.

In conclusion, I believe application Rollups are the best existing solution for scaling high-throughput applications, especially fully on-chain games. Scaling these application Rollups is key to achieving mainstream adoption beyond native crypto users.