CaptainZ

CaptainZ

Prompt Engineer. Focusing on AI, ZKP and Onchain Game. 每周一篇严肃/深度长文。专注于AI,零知识证明,全链游戏,还有心理学。
twitter

Dojo: Why do we need to do verifiable on-chain gaming?

Can large MMORPG games run on the blockchain?#

We all long for a self-governing world without corruption, malice, and contempt; a world that is persistent, eternal, and autonomous.

How can we achieve this? Just like in the blockchain trilemma, these efforts always require some level of compromise.

blockchain-trilemma

Autonomous Worlds (AWs) face the same trilemma problem. AWs need to be able to scale to millions of concurrent players, which is a challenging problem to solve.

Rollups solve this by transforming the trilemma into a dilemma, thanks to the security inherited from the settlement layer - as long as there are Layer 1 (L1) native assets and permissionless exit mechanisms.

With Optimistic rollup, you have to make a trade-off between scalability and security, which is why some rollup methods compromise on security when achieving scalability by using alternative data availability (alt DA) or plasma DA. However, with 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 ultimate solution.

What are Provable Games?#

Blockchain games promise us freedom of expression and sovereignty over our information. They possess these attributes because they run on a blockchain that is verified through consensus. Provable Games using zk proofs allow for the verification of game state and computation without the need for a large consensus scheme. Games written in languages like Cairo, Noir, or running RISC-Zero can run independently on a browser-like isolated zkVM, and the verifiable output ensures true execution. This expands the possibilities in the blockchain gaming industry.

A representative example is a game like Donkey Kong (similar to the game Mario Brothers). Currently, to authenticate your high score on the leaderboard, you have to play the game on an authenticated machine to prevent cheating while recording your gameplay. However, if Donkey Kong were a provable game, players could compete in an isolated environment. Achieving a high score would only require submitting proof of the game for verification. This approach allows players to establish their position as the king of Donkey Kong from the comfort of their own homes, without having to record the gameplay!

Running complete games in an isolated zkVM currently faces challenges. To address this, the Dojo ecosystem is working to simplify the process and reduce complexity. Teams like Tonk have made progress in the field of provable games, with a notable achievement being the running of Doom on zkVM. With the decreasing cost of proofs and the emergence of new provers like Stwo, the potential to design provable games and applications is expanding.

We don't have to run our provable games in an isolated zkVM. Instead, we can run our games on a mini-StarkNet network with minimal participants while still ensuring security.

It is worth noting that this approach is not an either-or situation. For example, you can run a blockchain game on an EVM and then overlay a Cairo-based game on top of it to enhance the core game while expanding its functionality.

Why do we need provable games?#

Imagine if the world of RuneScape (an open-world MMORPG game) suddenly shut down, permanently erasing everyone's game data. There would be some very angry players. This situation is bound to happen when developers decide to shut down servers. Can we do better? Can we create a rich, diverse, and immersive world like RuneScape without letting this happen?

This challenge is what the entire blockchain gaming scene is currently striving to solve: creating a world that is permanent, eternal, and autonomous. Many teams are exploring various methods, and this is the type of innovation and experimentation that is needed.

Many innovations are being put into blockchain games, but our focus is on exploring the provable game tech 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.

lumbridge

(Inspired by Skystrife Chad Kooshoba's speech at the Ethereum Istanbul conference)

Provable "Goblins"#

Let's build a world with goblins and take RuneScape as an example. We will focus on the starting area of the game, Lumbridge, and its surrounding environment:

  • Lumbridge Castle
  • Dense Forest
  • Goblins
  • Inventory Items

For provable goblins, we need:

  • Simulate the dynamic movement of goblins and creatures to bring the game world to life.
  • Real-time updates to the inventory when players pick up items.
  • Global tracking and saving of player progress to maintain a consistent gaming experience.
  • Design mechanisms to prevent exploitation and ensure game integrity.
  • Scalability to support millions of concurrent players.

Web2 Game Scaling#

Traditional game development relies on central servers for core functions such as progress management, NPC behavior, player state management, item control, and rule enforcement. To scale, more servers are added, and the game state is divided (sharded), allowing different player groups to have different instances of the game area. While this is an effective scaling solution, this centralization means that developers have ultimate control, including the ability to shut down servers. This is why the blockchain gaming industry was created - to have a trustless RuneScape...

trad-server

Traditional Blockchain Approach#

When attempting to replicate the functionality of a central server using traditional blockchain methods, it becomes impractical and nearly impossible to scale to thousands of concurrent users due to several limitations:

Transaction Verification

Transactions or player actions must be verified and processed by multiple nodes in the network. While this approach ensures security by replicating the processing and using consensus to make the system more difficult to attack, it also introduces a significant bottleneck in transaction processing speed, i.e., TPS. Of course, this can be circumvented by using a single central sequencer (like almost all Layer 2 technologies), but this requires more trust assumptions.

Transactions Per Second (TPS)

The TPS limit on the blockchain VM affects the ability to process player actions in the game. As the number of players and their actions exceeds the TPS capacity of the blockchain, a backlog forms, resulting in increased fees and a deteriorating player experience. This effectively limits the number of concurrent players a single blockchain sequencer can handle. To overcome these limitations, Ethereum is focusing on a rollup-centric roadmap, moving execution to the rollup layer.

Running the game world on a rollup significantly improves scalability, but without zk proofs, we still rely on large consensus mechanisms or extensive and potentially unstable trust assumptions, introducing risks. Therefore, while zk is considered the ultimate solution for scalability, it is not fully realized yet.

op-zk-sec

(Comparison of trust assumptions between OP layer and ZK layer. ZK assumptions remain strong even at low participation, allowing for the existence of mini zk rollups)

A Provable Approach - Using Recursive Proofs and Multilayer Architecture#

The goal of any blockchain is to give users absolute trust in their actions. This principle is often forgotten in the industry; what is the point of our efforts if our goal is not to create trustless systems? We don't need to rely on central servers, which excel in their functionality.

In our RuneScape world, we will focus on using recursive proofs pioneered by STARKs. Tarrence wrote an in-depth article on this topic, emphasizing the importance of recursive proofs in maintaining minimal trust assumptions for Layer 2 and Layer 3.

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

A simple diagram:

shards

Architecture Analysis#

L1 Ethereum

Here, we establish the final state, so anyone can reconstruct L2 if they choose to. This is what every true rollup does.

L2 Starknet

Here, we establish the state of L3, so anyone can reconstruct L3 if they choose to. This is where we maintain the overall world state.

L3 Realms World or other L3

This is a high-performance execution layer that supports global player state. We save the final state of the Lumbridge shard here. This allows for quick creation of new shards and restoration of player balances when needed.

Transient Lumbridge Shard

"Transient" means temporary, emphasizing the importance of efficient and secure management of each player's game state - the most important concern for all players. By adopting chain sharding and limiting each shard to a maximum of 30 players - a theoretical number that may be higher but serves as a manageable example - we reflect the structure of traditional servers but with a key 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

Just like the horizontal scaling concept in traditional game servers, we adopt a similar strategy here. By dividing the game world into many smaller shards, we enable the system to scale efficiently 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 point of state can be reconstructed!

An Example#

When players arrive at Lumbridge, they are assigned to a transient chain with a capacity that allows them to interact with up to 29 other players while ensuring high performance through fast and low-cost transactions. Now let's dive deeper:

Forest with resources like wood

With this transient chain, we can track player movement to the forest, execute a certain level of physics for movement, and utilize the computational power provided by this shard. They can then continue to chop wood, add it to their balance, and progress their player.

Goblins and other low-level monsters

Goblins can be effectively simulated using an internal game clock on the sequencer. When the game clock ticks, the sequencer advances the state and their positions until a user comes and kills them. If we choose, we can use a significant amount of shard bandwidth for this, as we limit the number of players and maximize the movement of NPCs.

Various items scattered or dropped by monsters

Items can be picked up and stored in the player's inventory. When the player ends their session, these items are saved to the global state. These values are not transient but saved to L3 for use in the next session.

Ending the game

At the end of the game session, the player's state is preserved by reverting to L3, establishing a global state for their next area or session. It is then verified on StarkNet L2 and subsequently on L1, effectively creating a provably fair RuneScape.

Q&A#

The entire stack we are building is open-source - join the Dojo Discord or contribute directly to the core.

Question 1: What about bridging between these layers? Wouldn't that be a nightmare for players?

Yes, currently bridging does present challenges. However, there is a clear solution being used in the Starknet ecosystem and will soon be available on other Layer 2s. These are called storage proofs. Yes, I'm embedding my tweet. Part 2 will discuss this.

Question 2: Why choose recursive proofs and transient chains over other methods?

To clarify, this is the approach adopted by the Dojo, Cartridge, and Realms ecosystems to scale the imagined world. And this is not the only approach; exploring various methods is beneficial. Some of the smartest people I know are also tackling the most challenging problems in this field, and their work is definitely worth looking into.

Lattice - OP Plasma combined with Redstone for extremely cheap transactions.

Playmint - Unique optimistic engine for fast gameplay.

PoP - Specialized EVM sharding.

Argus - Custom EVM game sharding.

Curio - Modified EVM server approach.

Creating a free and open RuneScape that can support millions of concurrent players is no easy task. However, the collective wisdom and creativity of the blockchain gaming industry are powerful forces. Therefore, it is reasonable to expect games like this to emerge in the next 12-24 months. It's time to return to RuneScape, or more appropriately, it's time to welcome the dawn of RealmScape.

Original article by @lordofafew

Translated and edited by @hicaptainz

Follow me for web3 gaming without getting lost.

Original article link: https://loaf.coffee/posts/provable-goblins

Loading...
Ownership of this post data is guaranteed by blockchain and smart contracts to the creator alone.