World Engine A sharding Rollup framework designed for full-chain games

World Engine A sharding Rollup framework for full-chain games.

Original Author: Scott Sunarto (@smsunarto)

Translation and Editing: Justin (@hicaptainz)

Scott attended the Modular Summit last week, and the following content is the latest progress report of Argus. The interesting part is that World Engine can actually be used in conjunction with MUD.

Hello everyone, thank you for attending today’s summit. I’m here to discuss a project that has occupied most of our time in the past year. However, you will soon realize that the timeline of this story goes far beyond this timeframe.

• The inevitable outcome of Non-EVM public chains? Analyzing the reasons for the decline of ICP from multiple perspectives
• Latest developments in the Curve incident Has the crisis been resolved? Does the founder have to sell coins and pay off debts?
• OP Research Sociology Experiment of Currency and Global Citizens

Before co-founding Argus, I was one of the creators of Dark Forest, the first fully on-chain game on Ethereum that uses ZK-SNARKs. The birth of Dark Forest was driven by a simple question: Can we create a game where every action is an on-chain transaction? In 2020, this was a radical proposition. Many people doubted the feasibility of a fully on-chain game because of the slow speed of blockchain technology. Despite this doubt, our curiosity drove us to develop Dark Forest.

Dark Forest is a space exploration game where thousands of players battle and expand their empires on-chain. In the first week of its release, we had over 10,000 players and spent trillions of gas on the Ethereum testnet. This high level of activity eventually forced us to move from the testnet to a sidechain. However, even the sidechain, praised for its scalability, proved to be insufficient. We quickly filled up the entire block space, driving up gas costs and rendering the sidechain practically unusable.

Despite these limitations, the enthusiasm for full-chain games remained high. After Dark Forest, we saw a surge in investors, founders, builders, and hackers building on top of the legacy of Dark Forest. Companies like Lattice and Primordium developed easier full-chain game development frameworks and full-chain games. We also saw developments in ecosystems outside of the EVM, such as Dojo on Starknet.

The limitations of existing blockchain technology stem from the fact that we share the chain with others. If another game like Dark Forest exists on the same chain, the chain cannot operate effectively. This made us start questioning whether we should abandon the concept of full-chain games. However, we decided to explore how to build better full-chain games.

We embarked on a journey starting from a critical realization: we took blockchain architecture for granted. Despite the various L1 and L2 solutions, they all look similar. They all claim to have better consensus mechanisms, faster VMs, better fraud proofs, and faster ZK proofs. However, these claims often lack benchmark support. All these efforts are aimed at creating another DEX or minting another NFT, which can be deployed on any other chain.

We decided to look at blockchain architecture from a different perspective. We questioned the classical blockchain architecture that seemed to mimic Bitcoin or Ethereum. We realized that other blockchains, whether L1 or L2, are trying to build a blockchain for everyone without considering specific use cases or user roles.

We have chosen a different path. We have decided to build the best blockchain for a specific user group: game developers and players. We understand that games are significantly different from typical applications. For example, social media platforms like Twitter operate on an event-driven runtime, similar to blockchain. Users trigger an event, such as posting a tweet, which leads to a state transition.

On the other hand, games operate on a loop-driven runtime. Even without user input, state transitions continue to occur. Fire keeps burning, water keeps flowing, crops keep growing, and day and night cycles continue. This fundamental difference has made us rethink how to build a better blockchain for games.

The key point to understand here is that state transitions in network applications, such as smart contracts, do not require user input. For example, in Uniswap, if a user wants to trade Token A and Token B, they submit a transaction and the trade is executed. This process is event-driven.

However, we soon realized that the event-driven nature of traditional blockchains is not compatible with running game state machines. Therefore, we explored the loop-driven runtime used in games. Game engines are specifically built to support this loop-driven runtime.

In a loop-driven runtime, game processes are called “ticks,” which are the atomic units of time. Each game loop executes within a tick. The higher the tick rate, the smoother the game feels. For example, modern games like Counter-Strike or Valorant have high tick rates, making them feel more fluid. In contrast, older games often feel sluggish due to lower tick rates.

In the context of blockchain, these ticks can be compared to blocks, which are the single units of time where state transitions occur. If a tick or block feels slow, it can have a negative impact on the gaming experience.

We believe that games are fundamentally loop-driven because many game state transitions are not triggered by external inputs. For example, gravity in a game does not depend on the user pressing a button; it exists regardless of user input.

Deterministic transaction ordering is also crucial. For example, if you want to inflict damage on a player, should the game first restore the player’s health or inflict damage first? With traditional ordering, you cannot predict or control which state transition will be applied first, leading to issues in the game loop.

Through a loop-driven blockchain, we maintain composability, which is why we want to use blockchain as the runtime for games. This approach allows for real-time gameplay and blurs the boundaries between blockchain and traditional game servers. It also enables the development of more complex games than before.

However, to build a scalable game server blockchain, we need horizontal scalability. Games are not played on a single server; they are distributed across many servers. A roll-up runs on one computer and is limited by physical computation. Therefore, we need a new strategy to control transactions.

Traditional game servers, especially those for performance-intensive large-scale multiplayer online games (MMOs), use the concept of sharding. Sharding is a tool, not a recipe for how to build your game. For example, in a location-based sharding, a Cartesian coordinate can be divided into four charts. When a player moves from one shard to another, a message is sent to the other shard and the player is teleported there.

The second method involves using a concept called multi-sharding, which is familiar to anyone who has played MMO games. In such games, when players log in, they are provided with multiple servers to choose from. This is a similar construct, where there are different states or game worlds that players can choose to join.

Through loop-driven runtime and horizontal scalability, we also hope to achieve excellent composability. However, achieving this in roll-ups may seem beyond reality. That’s why we created World Engine. We realized that standard roll-ups couldn’t perform as we expected, so we took matters into our own hands and built the solution we needed. It’s like in the 1990s when 3D game engines weren’t readily available and developers had to build them themselves.

World Engine is divided into two key parts. The first part is the core, consisting of two key elements: EVM Base Shard, a sharded hybrid execution layer and sorter, and Game Shard, a high-performance game engine with an execution layer. In addition, there are peripheral components such as transaction relays and network code for client-server communication, as well as ZK Cloud Prover for ZK games like Dark Forest.

The core of World Engine is designed around our sorter. While other sorters, such as shared sequence reconstruction, optimize atomic composability, we believe atomic composability is overrated, especially in the context of games. Therefore, we are fully asynchronous, eliminating the need for locks in the EVM Base Shard runtime.

We have a global EVM chain where players can deploy smart contracts to interact with the game, create markets, and DEXes. We built this on top of Polaris, a Cosmos SDK-compatible EVM module that allows us to customize the EVM to a greater extent than other solutions.

Running on top of the EVM Base Shard sorter is Game Shard, a high-performance mini blockchain designed as a high-performance game server. Game Shard is designed to be agnostic to the state machine and VM. We built an abstraction layer similar to Cosmos SDK EBCI, allowing you to customize your shards or build your own shards by implementing a standard set of interfaces.

We also built the first game shard implementation to provide an example. We used an ECS entity component system, a common feature in game engines, and our construction prioritizes treating the entity component system as a first-class citizen. This means that every object or primitive of the state machine itself is treated as an entity. The system also has a configurable tick rate, allowing you to customize the speed of your game.

The best part is that you don’t need to rely on an indexer. You can read quickly from the blockchain without dealing with the eventual consistency issues of an indexer. Additionally, you can write your code in Go without struggling with restrictive smart contract languages.

Because of our abstraction layer, sharding is essentially seamless, so you can build other sharding constructions, such as a solid game shard to complement your cardinal game shard. You can also build a minting shard for NFTs with custom rules, a game identity shard using NFTs to represent your game identity and allow trading of game identities. We don’t use locks, so we don’t have to block the main thread, making the game shards run as reliably as possible, avoiding any delays. We no longer need to rely on cryptographic economic constructions.

Each shard can have a different DA batch compression strategy. You can geolocate shards to reduce game latency. You can also run game shards as separate game servers, so you don’t have to worry about deploying a roll-up on day one.

We have built various games on top of game shards, such as a clone of Agar.io, which was traditionally not possible. We also use a hybrid model where you can use existing game engine frameworks on solidity and combine them with World Engine. The future is up to you. You can use our cardinal stack to make a hybrid or build your own game shards. It’s like Kubernetes for full-chain gaming, a mix and match Lego for your game.

World Engine is now open source on our GitHub, and we welcome new contributors. If you’re interested in building your first World Engine game, we will be hosting a workshop later today. Tomorrow, we will also host a game panel and a lecture on full-chain gaming.

In summary, let’s build cooler roll-ups. We are currently in a renaissance period for roll-ups. Roll-ups allow us to scale the blockchain and leverage the security of the underlying L1. However, we still live in a very EVM-centric concept of roll-up architecture. This is just the beginning, not the end. Our goal is to create user- and application-centric roll-up constructions. Thank you for listening.

English version link:

https://captainz.xlog.app/World-Engine-Sharded-Rollup-Framework-for-Onchain-Game

We will continue to update Blocking; if you have any questions or suggestions, please contact us!