Dapp Rollup Technology Interpretation: How to Make High-throughput APP Go Mainstream?

Written by Mohamed Fouda Compiled by TechFlow

! [Dapp Rollup Technology Interpretation: How to Make High-throughput APP Go Mainstream?] ](https://img-cdn.gateio.im/webp-social/moments-40baef27dd-88d783732e-dd1a6f-69ad2a.webp)

The application Rollup is emerging as a clear winner in scaling a specific set of Ethereum applications. These applications benefit from permissionless and strong ownership guarantees, but do not require simultaneous interaction between all application users. Fully on-chain games are the best example. On-chain games benefit from strong ownership of game assets, allowing anonymous participation in the game and allowing anonymous modification of the game. Still, most games don't require all players to interact at the same time. Other applications that can benefit from the app's Rollup scaling strategy include NFT marketplaces, perpetual exchanges, and on-chain AI inference.

! [Dapp Rollup Technology Interpretation: How to Make High-throughput APP Go Mainstream?] ](https://img-cdn.gateio.im/webp-social/moments-40baef27dd-8695df8aec-dd1a6f-69ad2a.webp)

Application rollup is already the preferred implementation for many of these use cases. However, the standard Rollup implementation, EVMRollup, still has important scalability limitations. They may reach a throughput of about 100 transactions per second. This throughput may be sufficient for some on-chain games, 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 how the application rollup scales to reach hundreds of thousands of concurrent participants. For each approach, I discuss the appropriate type of application/game and the challenges it faces.

Scale horizontally

Horizontal scalability is the easiest way to scale your application rollup. However, this simplicity comes at the expense of composability, which makes them suitable for only 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 contract on all rollups. The front end of the application seamlessly directs the user 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. At the front end of the game, users can choose which Rollup to join based on their geographic location. Due to its simplicity and availability of rollup-as-a-service providers like Caldera, which handle all the infrastructure work associated with spinning and managing these rollups, this approach can be easily adopted by game developers.

! [Dapp Rollup Technology Interpretation: How to Make High-throughput APP Go Mainstream?] ](https://img-cdn.gateio.im/webp-social/moments-40baef27dd-6e522fe107-dd1a6f-69ad2a.webp)

Still, there are some problems with the multi-rollup extension approach. The first problem is the Rollup network switch. Current wallets, such as Metamask, require manual approval to connect to a new network, the Rollup instance. This creates a difficult and confusing user experience for players, as players need to manually connect to multiple "networks" to play the same game. Fortunately, this complexity can be erased with an Account Abstraction (AA) solution. Examples include EIP 4337 and embedded wallets such as Privy and 0xPass.

Another challenge is managing the player's state during transitions between rollups. In some cases, such as capacity drops, an application may need to consolidate multiple Rollup instances into a single instance to conserve resources. In this case, the state of all active players needs to be migrated to the new instance. Current bridging solutions, especially ZK bridges, can play a key role in solving this problem. Using these solutions, you can bridge a player's game state 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 status channel

Another application rollup extension that is more suitable for multiplayer games, such as poker, is the ZK state channel. In these games, player interaction occurs between a small number of players, such as 2-10 people. The gameplay between these players is only important while the game is going on. However, the final outcome of the game is more important as it affects each player's asset balance. Therefore, it is important to store the results in a shared persistence layer.

In this case, the application rollup represents a shared information layer, where game results are stored and where game assets also exist. For each game on Rollup, you can start a ZK state channel to serve the game. During gameplay, each player generates transactions and creates ZKP, proving that they followed the rules of the game. Proofs of other player interactions aggregate the previous proof using recursive proofs. When the game ends, the final ZKP is submitted to the application Rollup to prove the validity of the gameplay and the final result. The state change produced by the game changes the player state on the application Rollup.

! [Dapp Rollup Technology Interpretation: How to Make High-throughput APP Go Mainstream?] ](https://img.jinse.cn/7119915_watermarknone.png)

The ZK state channel moves game interactions off-chain. Therefore, in-game activity and transactions do not count towards the throughput of the application rollup. Using this approach, the application Rollup can scale massively to support thousands of concurrent players. The transaction for the application rollup will only validate the generated ZKP and status update transactions with a scaling factor of 100-1000x. Several teams, including Ontropy, have been developing the technology.

One drawback of this approach is that it requires players to run game logic on their own devices and generate ZKPs. Often these proofs are lightweight and can be completed in seconds with cutting-edge proof systems such as Halo2. However, this can still lead to a reduced player experience for devices with limited resources.

One of the ways to mitigate this issue is to designate one of the zk state channel participants as a temporary sequencer. The sequencer will receive each player's transaction and generate the corresponding ZKP, sharing the ZKP with all channel participants. This modification can be thought of as a short-lived ZK L3 settlement to the application Rollup. The Cartridge team implemented this architecture by designing a dedicated sequencer called Katana.

The zk state channel approach has great potential. However, there are several open issues related to the execution environment within the zk state channel and how to optimize the recursive proof. Current zkEVM environments are not efficient, and most currently do not support proof recursion. Alternatives include lightweight zkVM, or even use specialized zk circuits to handle player interaction if the player has a limited number of possible moves.

Change the execution environment

A third way to extend the application rollup is to change the Rollup's execution environment. Despite their maturity and abundance of EVM development tools, they are not suitable for high-performance applications such as gaming. In addition, the EVM's single-threaded execution and storage model results in reduced throughput, which can be improved through improvements.

The main advantage of this approach is that increasing Rollup throughput does not require sacrificing composability or limiting the number of use cases. This approach can be used for any Web 3 application as long as the execution environment can achieve the throughput required by the 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.

Extending EVM functionality with precompilation

First, Rollup keeps EVM compliant and passes some limits on precompiled address throughput. The idea here is simple. Precompilation is the downward movement of compute-intensive EVM operations to the node level. An operation that requires hundreds or thousands of EVM opcodes and consumes 100,000+ gas can be simplified to a single operation with a 100x reduction in gas costs. Precompilation that extends the Rollup environment is often referred to as EVM+. Examples of this approach include support for on-chain privacy and support for more efficient signature schemes such as BLS signatures. For example, zkHoldem poker uses dedicated FHE and zk operations to enable private card dealing and presentation. The development of these specialized precompilations is typically a joint effort between the application rollup developer and the Raas provider who manages the deployment and maintenance of the application rollup infrastructure.

Using a non-EVM execution environment

Another way to improve the Rollup execution environment is to get rid of the EVM. This approach is gaining popularity among new developers in the Ethereum ecosystem, as well as among developers who believe that 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 using high-level languages such as Rust or C. The downside is that interoperability with existing Solidity contracts is often lost. However, compatibility with EVM can still be created. For example, Aributrum's stylus uses a coprocessor to make the Stylus contract EVM compatible. This design brings Stylus closer to the EVM+ architecture than to non-EVM.

! [Dapp Rollup Technology Interpretation: How to Make High-throughput APP Go Mainstream?] ](https://img.jinse.cn/7119916_watermarknone.png)

Mixed Execution Environment

The third approach, which is particularly popular with FOGs, is the best feature that combines the first two. This approach combines EVM compatibility with a dedicated non-EVM execution environment. Non-EVM environments focus 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 approach is that EVM compatibility ensures alignment with the larger developer ecosystem and existing products. It also allows for permissionless composability. Developers can modify and extend the game logic by adding EVM/Solidity smart contracts. At the same time, purpose-built, non-EVM game engines achieve high throughput that EVM cannot.

Examples of this approach are Argus' 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. Game Shard is also designed to allow horizontal scaling to adjust total rollup throughput based on demand. Similarly, Curio's Keystone architecture bundles a high-throughput game engine with an EVM as a Rollup execution environment. The challenge here is to achieve seamless interoperability between EVM engines and game engines.

! [Dapp Rollup Technology Interpretation: How to Make High-throughput APP Go Mainstream?] ](https://img-cdn.gateio.im/webp-social/moments-40baef27dd-acc39c7ebc-dd1a6f-69ad2a.webp)

Data availability considerations

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

A single application Rollup can have a throughput of more than 10,000 transactions per second. It is impossible to use Ethereum as the data availability layer for these transactions. First, the average cost of publishing simple L2 ETH transfer data on L2 can exceed $0.1. These costs are too high for most application rollups. What's more, Ethereum's L1 can't currently support rollups that take advantage of L1 for data availability with about 8,000 transactions per second.

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

However, the main disadvantage of integrating Celestia or EigneDA is economic value leakage. Application rollups must pay fees for the DA layer, as well as settlement fees on Ethereum L1. The settlement fee is key to the application Rollup because it ties the security of Rollup to the security of Ethereum. DA guarantees are less important in the context of FOG where the transaction value is much smaller than these networks. In addition, Celestia and EigenDA promise low fees because these networks are just up and utilization will be low initially. When these DA networks achieve high utilization, DA charges can also become prohibitive. In my opinion, the application rollup should use a simple Data Availability Board (DAC) to prove the availability of the rollup data.

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