Might a game like RuneScape soon run onchain?

We all aspire for an autonomous world free of corruption, malice, and contempt; a world that is persistent, everlasting, and autonomous.

How do we achieve this? Just like in the blockchain trilemma, there will always be a level of compromise required in these endeavours.

Autonomous Worlds (AWs) face the same trilemma. AWs need the capability to scale to millions of concurrent players, this is a hard problem to solve.

Rollups partially solve the trilemma by converting it into a dilemma, thanks to inheriting the security of the settlement layer—as long as there are Layer 1 (L1) native assets and permissionless exits.

With an optimistic rollup, you need to choose between scalability and security, which is why some rollup approaches compromise on security by using alternative data availability (alt DA) or plasma DA to achieve scalability. However, with a ZK Rollup, you can prove the integrity of the state with minimal trust assumptions, aiming to address all three challenges: scalability, security, and decentralization. Zk is the endgame.

Donkey Kong with integrity - from onchain to provable and back

Onchain games promise us freedom of expression and sovereignty over our information. They possess these properties because they run on a blockchain verified by consensus. Provable games, using zk proofs, allow for the verification of game state and computations without large consensus schemes. Written in languages like Cairo, Noir or running RISC-Zero, these games can operate independently on an isolated zkVM like a browser, with verifiable outputs ensuring truthful execution. This broadens our possibilities in the onchain gaming industry.

An illustrative example is a game like Donkey Kong. Currently, to have your high score recognized on the leaderboard, you must play on a certified machine to prevent cheating, while recording your gameplay. However, if Donkey Kong were a provable game, players could compete in isolation. Achieving a high score would simply require submitting a proof to the Donkey Kong organization for verification. This method allows players to establish themselves as the King of Kong from the comfort of their home, without the need to record their gameplay!

Running complete games within isolated zkVMs is currently challenging. To address this, the Dojo ecosystem is working to streamline the process by minimizing complexity. Teams like Tonk are advancing in the provable game arena, with a notable achievement being the running of Doom on a zkVM, heralding "Provable Doom." As proving costs decrease and new provers, such as Stwo, become available, the potential for designing provable games and applications widens.

We don't necessarily need to operate our provable games within an isolated zkVM to benefit from their provable attributes. Instead, we can run our games on mini-StarkNet networks with a minimal number of participants and still achieve guaranteed security.

It's important to note that the approach isn't binary. For instance, you could operate an onchain game on an EVM and then layer a Cairo-based game on top, enhancing the core game while broadening its capabilities.

Why bother with provable games?

Imagine if the world of RuneScape suddenly shut down, erasing everyone's game stats forever. There would be some furious gamers. This scenario is bound to occur at some point when the developers decide to close the servers. Can we do better? Can we make a world as rich, diverse and intense as RuneScape that is free from this every happening?

This challenge is what the entire onchain gaming scene is currently striving to resolve: creating a world that is persistent, everlasting, and autonomous. Numerous teams are exploring various approaches, which is exactly the kind of innovation and experimentation needed.

A lot of innovation is being invested in onchain games, but our focus is on exploring the provable game technology tree 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 to write this after the legendary Skystrife chad Kooshobas speech at Eth Istanbul

Provable Goblins

Let’s build a world where we can prove that goblins exist and let’s use RuneScape as an example, we'll focus on the game's initial zone, Lumbridge, and its surroundings to explore:

• Lumbridge Castle
• Woody Forests
• Goblins
• Inventory Items

For provable Goblins we need to:

• Simulate dynamic movements of goblins and creatures for a lively game world.
• Enable real-time inventory updates when players pick up items.
• Track and save player progression globally for consistent gameplay.
• Design mechanics to prevent exploitation, ensuring game integrity.
• Support scalability for millions of concurrent players.

Scaling Modern Traditional Games

Traditional game development depends on centralized servers for essential functions like progression, NPC behavior, player state management, item control, and rule enforcement. To scale, more servers are added, and the game state is divided (sharding), allowing for separate instances of game areas for different groups of players. Although an effective scaling solution, this centralization means developers have ultimate control, including the ability to shut down servers. This is why the onchain gaming industry was created - to be able to have a trustless RuneScape…

The Traditional Blockchain Way

When attempting to replicate the functionality of a centralized server using a traditional blockchain approach, while it's theoretically feasible, it becomes impractical and nearly impossible to scale beyond a few thousand concurrent users due to several limitations:

Validation of Transactions

Transactions, or player actions, must be verified and processed by multiple nodes across the network. While this method ensures security by replicating the processing and using consensus to make it harder to compromise the system, it also introduces a significant bottleneck in terms of transaction processing speed - ie TPS. Now, this of course can be side stepped by using a single central sequencer (like pretty much every L2) however - more trust assumptions.

Transations Per Second

The TPS limit on a blockchain VM restricts a game's ability to process player actions. As the number of players and their actions exceed the blockchain's TPS capacity, a backlog forms, leading to spikes in fees and a deteriorating player experience. This effectively caps the number of concurrent players that a single blockchain sequencer can manage. To overcome these limitations, Ethereum focused on a rollup-centric roadmap, moving execution to the rollup layer.

Operating our world on a rollup can significantly enhance scalability, but without zk Proofs, we still depend on large consensus mechanisms or broad potentially flaky trust assumptions, which introduce risks. Thus, zk is considered the ultimate solution for scaling, although it has not been fully realized yet.

Trust assumption of ZK layers compared to OP layers. ZK assumption remains strong with a low level of participation, allowing for mini zk rollups to exist.

A Provable Way - Using Recursive Proofs and multiple layers

The objective for any blockchain is to enable users to have absolute trust in their actions. This principle is often forgotten in the industry; if we are not aiming to create trustless systems, then what is the point of our efforts? We might as well rely on central servers, which excel at their functions.

In our RuneScape world, we will be focusing on recursive scaling, pioneered using STARKs. Tarrence has written an in-depth piece on this topic, highlighting the significance of recursive proofs in maintaining minimal trust assumptions on Layer 2, Layer 3.

In our world, we can leverage recursive proofs to scale and shard the world while ensuring that the goblin anyone defeats is indeed a goblin.

A crude diagram:

Lets break this down.

L1 Ethereum

We settle the final state here, so anyone can reconstruct the L2 if they choose. This is what every true rollup does.

L2 Starknet

We settle the L3 state here, so anyone can reconstruct the L3 if they choose. This is where we maintain a state of the whole world.

L3 Realms World or Other L3

The high performance execution layer supporting global state for players. We save the Lumbridge Shards final state here. This allows new shards to be created quickly when needed restoring players balances.

Ephemeral Lumbridge Shards

"Ephemeral" means temporary, emphasizing the importance of efficiently and securely managing each player's game state—a concern paramount for all players. By adopting chain sharding to limit 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 with a crucial enhancement: the utilization of zk proofs to ensure the integrity of state changes. This allows us to horizontally scale to thousands of shards, without sacraficing any performance for the player.

Applying this method to RuneScape

Just like the concept of horizontal scaling in traditional game servers, we're applying a similar strategy here. By dividing the game world into numerous smaller shards, we enable the system to scale and accommodate millions of concurrent users effectively.

The key difference between traditional game servers and this approach is that players maintain complete control over their game state, ensuring greater autonomy and security. Every bit of state can be reconstructed!

Lets walk it in the example:

When players arrive in Lumbridge, they are allocated to an ephemeral chain that has capacity, facilitating interactions with up to 29 other players while ensuring high performance through fast and low cost transactions. Now deeper:

• Forests, with resources like wood

With this ephemeral chain, players' movements can be tracked as they travel to the forest, enforcing a level of movement physics, we do this with the cheap computing power that this shard enables. They can then proceed to chop wood, adding it to their balance and advancing their player.

• Goblins and other low-level monsters

Goblins could be effectively simulated by a built-in game tick on the sequencer. When the game ticks, the sequencer advances the state and their location until a user comes along and they are slain. We could take a significant amount of the shards bandwidth on this if we choose, since we are limiting the amount of players, we can maximise NPC movements.

• Various items scattered around or dropped by monsters

Items can be picked up and stored in a player's balance. When the player ends their session, these items will be saved to the global state. These values are not ephemeral and are saved to the L3 for usage in the next session.

Ending the Session

At the conclusion of their game session, players' states are preserved in a global state by transitioning back to L3, setting the stage for their next zone or session. This is then verified on StarkNet L2, and subsequently verified on L1, effectively establishing a provably fair RuneScape. Now, the next step is to actualize this vision…

The whole stack we are building is open source - join the dojo discord or contribute to the core directly.

What about Bridging between these layers? Won’t this be a nightmare for players.

Yes, bridging is problematic at the moment. However, there is a clear solution to this issue that is already being utilized in the Starknet ecosystem and will soon be made available on other Layer 2s. These are called Storage Proofs. Yes, I am embedding my own tweet. Part 2 will discuss this.

https://twitter.com/lordOfAFew/status/1762796441494520267

Why recursive Proofs and ephemeral Chains over other methods?

To clarify, this is the approach that Dojo, Cartridge, and the Realms ecosystem are adopting to scale the world we envision. It's important to note that this isn't the only method, and exploring a variety of approaches is beneficial. Some of the brightest minds I know are also addressing the most challenging issues in this space, and their work is definitely worth checking out.

• Lattice - OP Plasma with Redstone allows for very cheap txs.
• Playmint - Unique Optimistic Engine for fast gameplay
• PoP - Bespoke EVM sharding
• Argus - Custom EVM game shards
• Curio - Modified EVM server approach

A time to return to Runescape

Creating a free and open RuneScape capable of supporting millions of concurrent players is no small task. However, the collective intelligence and creativity of the onchain gaming industry are formidable forces. Therefore, it's reasonable to anticipate the emergence of games like this and others within the next 12-24 months. It's time to return to RuneScape, or perhaps more aptly, to welcome the dawn of RealmScape. ;)

Find me:

Twitter: @lordofafew

Telegram: @lordofafew

Realms Discord: https://discord.gg/realmsworld

Dojo discord: https://discord.gg/dojoengine