Rollup is the best existing solution for scaling high-throughput applications, especially fully on-chain games.

Written by: Mohamed Fouda

Translated by: DeepTech TechFlow

The Rollup application is emerging as the clear winner for scaling a specific set of Ethereum applications. These applications benefit from permissionless and strong ownership guarantees, but do not require all application users to interact simultaneously. Fully on-chain games are the best example. On-chain games benefit from strong ownership of game assets, allowing for anonymous participation and anonymous modification of the game. However, most games do not require all players to interact simultaneously. Other applications that can benefit from the Rollup application extension strategy include NFT markets, perpetual exchanges, and on-chain AI reasoning.

The Rollup application has already become the preferred implementation for many of these use cases. However, the standard Rollup implementation, namely EVMRollup, still has significant scalability limitations. They may achieve a throughput of approximately 100 transactions per second. For some 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 (exceeding 1000). This article focuses on methods for extending the Rollup application to cover tens 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 the Rollup application. However, this simplicity comes at the cost of composability, making it suitable only for a small subset of applications, such as single-player games.

Horizontal scalability simply means deploying multiple Rollup applications (Optimistic or ZK) and deploying the same smart contract on all Rollups. The application's frontend 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 frontend, 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, who handle all the infrastructure work related to spinning up and managing these Rollups, this approach can be easily adopted by game developers.

However, the multi-Rollup extension method 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 can create 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 mitigated with Account Abstraction (AA) solutions, such as EIP 4337 and embedded wallets like Privy and 0xPass.

Another challenge is managing player states during the transition between Rollups. In certain cases, such as capacity reduction, the application may need to merge multiple Rollup instances into a single instance to save resources. In this scenario, the states of all active players need to be migrated to the new instance. Current bridging solutions, especially zk bridges, can play a crucial role in addressing this issue. With these solutions, a player's game state can be bridged to a new Rollup instance while maintaining a 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 method for extending the Rollup application, more suitable 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 during the game, but the final result of the game is more crucial as it affects the asset balances of each player. Therefore, storing the results in a shared persistent layer is important.

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

ZK state channels move game interactions off-chain. Therefore, the activities and transactions in the game do not count towards the throughput of the Rollup application. Using this method, the Rollup application can scale massively to support thousands of concurrent players. The transactions on the Rollup application will only involve verifying the generated ZKPs and state update transactions, with a scaling factor of 100-1000 times. Multiple 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 advanced 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 with limited resources.

One modification to mitigate this issue is to designate one of the participants in the zk state channel as a temporary sequencer. This sequencer will receive transactions from each player and generate the corresponding ZKPs, which are then shared with all channel participants. This modification can be considered a temporary ZK L3 for settling with the Rollup application. 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 issues related to the execution environment within zk state channels and how to optimize recursive proofs. The current efficiency of the zkEVM environment is not high, and most do not currently support proof recursion. Alternatives include lightweight zkVMs, or even using specialized zk circuits if the number of possible player actions is limited.

Changing the Execution Environment

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

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

Extending EVM Functionality through Precompiled Contracts

First, Rollup maintains EVM compatibility and addresses some throughput limitations through precompiled addresses. The idea here is simple. Precompiling involves moving computationally intensive EVM operations down 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, reducing gas costs by 100 times. The precompilation of the Rollup environment is typically referred to as EVM+. Examples of this approach 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 achieve private card dealing and display. The development of these dedicated precompilations is often 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 method for improving 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 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 in high-level languages (such as Rust or C). The drawback is that interoperability with existing Solidity contracts is often lost. However, compatibility with the EVM can still be achieved. For example, Aributrum's stylus uses a coprocessor to make Stylus contracts compatible with the EVM. This design makes Stylus closer to an EVM+ architecture rather than a non-EVM one.

Hybrid Execution Environments

The third method, particularly favored by FOG, combines the best features of the first two methods. This approach combines EVM compatibility with a dedicated non-EVM execution environment. 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, a dedicated non-EVM game engine achieves high throughput that the EVM cannot meet.

Examples of this method are 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. Game Shard is also designed to allow horizontal scaling to adjust the total Rollup throughput as needed. 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 preceding discussion, the focus was on increasing Rollup transaction throughput, which is a primary aspect of extending the application Rollup. Other topics related to this increased throughput include data availability (DA), decentralized sequencers, and settlement speed. For high-throughput application Rollups, data availability is the most urgent among these issues.

The throughput of a single application Rollup may exceed 10,000 transactions per second. It is not feasible to use Ethereum as the data availability layer for these transactions. Firstly, the average cost of publishing simple L2 ETH transfer data on L1 can exceed $0.1. These costs are too high for most application Rollups. More importantly, Ethereum's L1 cannot support more than approximately 8,000 transactions per second for Rollups that utilize L1 for data availability.

Application Rollups will primarily rely on external DA solutions. Celestia and EigenDA are currently positioned as the most viable choices 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, providing a viable solution 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 and settlement fees on Ethereum L1. Settlement fees are crucial for application Rollups because they tie the security of the Rollup to the security of Ethereum. DA guarantees are less important in the context of transaction values far smaller than those of these networks in the FOG background. Additionally, Celestia and EigenDA promise low fees because these networks are just starting, and initial utilization rates will be low. When these DA networks achieve high utilization, DA fees may also become excessively high. In my view, application Rollups should use a simple Data Availability Committee (DAC) to prove the availability of Rollup data.

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

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。