Why should we make on-chain games verifiable?
TechFlow Selected TechFlow Selected
Why should we make on-chain games verifiable?
Can large-scale MMORPG games run on the blockchain?
Navigating Web3 tides with focused insightsAuthor: @lordofafew
Translated by: @hicaptainz
We all desire an autonomous world free from corruption, malice, and contempt—a persistent, eternal, and self-governing world.
How can we achieve this? Just like in the blockchain trilemma, these efforts always require some degree of compromise.
Autonomous Worlds (AWs) face a similar impossible trilemma. AWs need to scale to millions of concurrent players—an incredibly difficult challenge.
Rollups solve this by partially transforming the trilemma into a dilemma, thanks to inheriting security from the settlement layer—as long as there is a Layer 1 (L1) native asset and a permissionless exit mechanism.
With optimistic rollups, you must choose between scalability and security, which is why some rollup approaches compromise on security when achieving scalability via alternative data availability (alt DA) or plasma DA. However, with ZK Rollups, you can prove state integrity under minimal trust assumptions, aiming to solve all three challenges: scalability, security, and decentralization. ZK is the ultimate solution.
What Are Provable Games?
On-chain games promise us freedom of expression and sovereignty over our data. They possess these properties because they run on blockchains secured by consensus validation. Provable Games using zk proofs allow game states and computations to be verified without relying on large consensus schemes. Games written in languages like Cairo or Noir, or running on RISC-Zero, can operate independently on standalone zkVMs resembling browsers, where verifiable outputs ensure genuine execution. This expands the possibilities within the on-chain gaming industry.
A representative example is a game like Donkey Kong (similar to Super Mario). Currently, to authenticate your high score on the leaderboard, you must play on certified machines to prevent cheating while recording gameplay. However, if Donkey Kong were a provable game, players could compete in isolated environments. Achieving a high score would simply require submitting a proof to the game for verification. This method allows players to establish themselves as the King of Donkey Kong from the comfort of their homes—without needing to record gameplay!
Running full games inside isolated zkVMs currently faces technical challenges. To address this, the Dojo ecosystem is working to streamline the process and reduce complexity. Teams like Tonk are making progress in the field of provable games, notably achieving running Doom on a zkVM. As proof costs decrease and new provers like Stwo emerge, the potential for designing provable games and applications continues to grow.
We don't necessarily have to run our provable games within isolated zkVMs. Instead, we can run our games on mini-StarkNet networks with minimal participants, still ensuring security.
Importantly, this approach isn't mutually exclusive. For instance, you could run an on-chain game on an EVM and then overlay a Cairo-based game on top, enhancing the core game while expanding its functionality.
Why Build Provable Games?
Imagine if the world of RuneScape—an MMORPG open-world game—suddenly shut down, permanently erasing everyone's game data. There would be many furious players. This scenario will inevitably happen when developers decide to shut down servers. Can we do better? Can we create a world as rich, diverse, and immersive as RuneScape without allowing such closures?
This very challenge is what the entire on-chain gaming space is currently striving to solve: creating a permanently existing, immutable, and autonomous world. Many teams are exploring various methods—exactly the kind of innovation and experimentation needed.
While many innovations are being invested into on-chain games, our focus lies in exploring the technology tree of provable games using Cairo and Starknet VM. This article aims to translate some provable game concepts into a practical example inspired by the legendary game RuneScape.
(Inspired by Skystrife chad Kooshoba’s talk at the Ethereum Istanbul Conference)
The Provable "Goblins"
Let’s build a world populated by goblins, taking RuneScape as inspiration. We’ll focus on the starting area, Lumbridge and its surroundings, to explore:
-
Lumbridge Castle
-
Dense Forests
-
Goblins
-
Inventory Items
For provable goblins, we need:
-
Simulate dynamic movements of goblins and creatures to bring life to the game world.
-
Update inventory in real time when players pick up items.
-
Globally track and save player progress to maintain a consistent gaming experience.
-
Design mechanisms to prevent exploits and ensure game integrity.
-
Scalability to support millions of concurrent players.
Web2 Game Scaling Approach
Traditional game development relies on centralized servers for core functions such as progress tracking, NPC behavior, player state management, item control, and rule enforcement. To scale, more servers are added, and game states are partitioned (sharded), allowing different instances for different player groups. While effective for scaling, this centralization means developers retain ultimate control—including the ability to shut down servers. This is precisely why the on-chain gaming industry was created—to enable a trustless RuneScape…
Traditional Blockchain Approach
Attempting to replicate centralized server functionality using traditional blockchain methods is theoretically feasible but practically impractical due to several limitations, making it nearly impossible to scale beyond a few thousand concurrent users:
Transaction Validation
Transactions or player actions must be validated and processed by multiple nodes in the network. While this ensures security by replicating processing and using consensus to make system tampering harder, it introduces a major bottleneck in transaction processing speed—TPS. Of course, this can be circumvented using a single centralized sequencer (as nearly all Layer 2 solutions do), but that requires stronger trust assumptions.
Transactions Per Second
The TPS limit on blockchain VMs affects the game’s ability to process player actions. As player numbers and actions exceed the blockchain’s TPS capacity, backlogs form, causing fee spikes and degraded user experience. This effectively limits the number of concurrent players a single blockchain sequencer can manage. To overcome these constraints, Ethereum has focused on a rollup-centric roadmap, moving execution to rollup layers.
Running game worlds on rollups can significantly improve scalability, but without zk proofs, we still rely on large consensus mechanisms or extensive—and potentially unstable—trust assumptions, introducing risk. Thus, although zk is considered the ultimate scaling solution, it has not yet been fully realized.
(Trust assumptions comparison: OP-layer vs ZK-layer. ZK maintains strong security even with low participation, enabling mini-zk-rollups)
A Provable Approach – Using Recursive Proofs and Multi-Layer Architecture
The goal of any blockchain is to give users absolute confidence in their actions. This principle is often forgotten in the industry; if we're not building trustless systems, what's the point of our efforts? We might as well rely on centralized servers, which excel at their function.
In our RuneScape world, we will focus on recursive scaling pioneered by STARKs. Tarrence wrote an in-depth article on this topic, emphasizing the importance of recursive proofs in maintaining minimal trust assumptions across Layer 2, Layer 3, and beyond.
In our world, we can use recursive proofs to scale and shard the world while ensuring that any goblin defeated by a player is indeed a legitimate goblin.
A simple illustration:
Architecture Analysis
L1 Ethereum
We finalize state here, so anyone can reconstruct L2 if desired. This is what every true rollup does.
L2 Starknet
We finalize L3 state here, so anyone can reconstruct L3 if desired. This is where we maintain the overall world state.
L3 Realms World or Other L3
A high-performance execution layer supporting global player state. We store the final state of the Lumbridge shard here. This enables rapid creation of new shards when needed and recovery of player balances.
Ephemeral Lumbridge Shards
"Ephemeral" means temporary, emphasizing efficient and secure management of each player's game state—the top priority for all players. By adopting chain sharding and limiting each shard to a maximum of 30 players—a theoretical number that could be higher but serves as a manageable example—we mirror the structure of traditional servers but with a critical enhancement: using zk proofs to ensure the integrity of state changes. This allows us to horizontally scale to thousands of shards without sacrificing player performance.
Applying This Approach to RuneScape
Similar to the concept of horizontal scaling in traditional game servers, we adopt a comparable strategy here. By dividing the game world into many smaller shards, we enable the system to efficiently scale and accommodate millions of concurrent users.
The key difference between traditional game servers and this approach is that players have full control over their game state, ensuring greater autonomy and security. Every bit of state can be reconstructed!
An Example
When a player arrives in Lumbridge, they are assigned to an ephemeral chain with capacity, allowing interaction with up to 29 other players while ensuring high performance through fast, low-cost transactions. Now let’s dive deeper:
Forest with resources like wood
With this ephemeral chain, tracking player movement into the forest and implementing basic physics for movement becomes feasible, leveraging the shard’s low-cost computational power. Players can then proceed to chop wood, add it to their balance, and advance their progress.
Goblins and other low-level monsters
Goblins can be efficiently simulated using a built-in game clock on the sequencer. As the game clock ticks, the sequencer advances their state and positions until a player arrives and defeats them. If desired, we can utilize significant sharding bandwidth here—since we limit player count, we can maximize NPC movement.
Various scattered items or drops from monsters
Items can be picked up and stored in the player’s balance. When the player ends their session, these items are saved into the global state. These values are not ephemeral—they are persisted in L3 for use in the next session.
Ending the Game Session
At the end of a game session, the player’s state is rolled back into a global state on L3, setting the stage for their next area or session. It is then verified on StarkNet L2, followed by verification on L1, effectively establishing a provably fair RuneScape.
Q&A
Our entire stack is open-source—join the Dojo Discord or contribute directly to the core.
Question 1: What about bridging between these layers? Won’t that be a nightmare for players?
Yes, bridging is currently problematic. However, a clear solution already exists within the Starknet ecosystem and will soon be available on other Layer 2s. These are called proofs of storage. Yes, I’m embedding my tweet. Part two will cover this.
Question 2: Why use recursive proofs and ephemeral chains instead of other methods?
To clarify, this is the approach adopted by the Dojo, Cartridge, and Realms ecosystems to scale our imagined world. It’s not the only method, and exploring alternatives is beneficial. Some of the smartest people I know are tackling the toughest challenges in this space—definitely worth checking out.
Lattice - OP Plasma combined with Redstone for ultra-cheap transactions.
Playmint - Unique optimistic engine for fast gameplay.
PoP - Specialized EVM sharding.
Argus - Custom EVM game shards.
Curio - Modified EVM server approach.
Creating a free, open RuneScape capable of supporting millions of concurrent players is no easy feat. Yet, the collective intelligence and creativity of the on-chain gaming industry are powerful forces. Therefore, expecting games like this to emerge within the next 12–24 months is reasonable. It’s time to return to RuneScape—or rather, welcome the dawn of RealmScape.
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
