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 from 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 taken up most of our time in the past year. However, you will soon realize that the timeline of this story goes far beyond this timeframe.
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 due to the slow speed of blockchain technology. Despite this skepticism, 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, which was 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 fully on-chain games remained high. After Dark Forest, we saw an increase in investors, founders, builders, and hackers who were building on top of the Dark Forest legacy. Companies like Lattice and Primordium developed easier frameworks and games for full-chain game development. 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 run effectively. This made us question 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 crucial realization: we took blockchain architecture for granted. Despite the various L1 and L2 solutions, they all look very similar. They all claim to have better consensus mechanisms, faster VMs, better fraud proofs, and faster ZK proofs. However, these claims often lack supporting benchmarks. All these efforts are to create another DEX or mint another NFT, which can be deployed on any other chain.
We decided to look at blockchain architecture from a different perspective. We questioned the classic 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 chose a different path. We decided to build the best blockchain for a specific user group: game developers and players. We understood that games have significant differences from typical applications. For example, social media platforms like Twitter operate in an event-driven runtime, similar to blockchain. A user triggers an event, such as posting a tweet, which leads to a state transition.
On the other hand, games operate in a loop-driven runtime. State transitions continue to occur even without user input. Fire continues to burn, water continues to flow, crops continue to grow, and the day-night cycle continues. This fundamental difference made us rethink how to build a better blockchain for games.
The key point to understand here is that state transitions in web 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. The game engine is specifically built to support this loop-driven runtime.
In a loop-driven runtime, game processes are called "ticks," which are atomic units of time. Each game loop is executed in one 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 responsive. 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 unit of time where state transitions occur. If a tick or block feels slow, it can negatively impact the gaming experience.
We believe that games are fundamentally loop-driven because many game state transitions are not triggered by external inputs. For example, the 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 user, should the game first heal the user or inflict damage? With traditional ordering, you cannot predict or control which state transition is applied first, leading to issues in the game loop.
Through 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 line 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 a single computer and is limited by physical computing. Therefore, we need a new strategy to control transactions.
Traditional game servers, especially performance-intensive MMOs, use the concept of sharding. Sharding is a tool, not a prescription for how to build your game. For example, in location-based sharding, a Cartesian coordinate can be divided into four quadrants. 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 approach involves using a concept called multi-sharding, which is familiar to those who have played MMO games. In such games, when a player logs in, they are presented with multiple servers to choose from. It is a similar construct where there are different states or game worlds that players can choose to join.
With loop-driven runtime and horizontal scalability, we also aim to achieve excellent composability. However, achieving this in a roll-up may seem unrealistic. That's why we created World Engine. We realized that standard roll-ups cannot operate according to our expectations, so we took matters into our own hands and built the solution we needed. It's like the 1990s when 3D game engines were not readily available, and developers had to build them themselves.
World Engine is divided into two key parts. The first part is the core, which consists of two key elements: the EVM Base Shard, a sharded hybrid execution layer and sorter, and the 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 a ZK Cloud verifier 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 for atomic composability, we believe atomic composability is overrated, especially in the context of games. Therefore, we are fully asynchronous and eliminate 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, an EVM module compatible with Cosmos SDK, which allows us to customize the EVM to a greater extent than other solutions.
Running on top of the EVM Base Shard sorter is the Game Shard, a high-performance mini blockchain designed for game servers. The 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 set of standard 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 prioritized making the entity-component system a first-class citizen in our construction. This means that each 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 indexers. You can read quickly on the blockchain without dealing with the eventual consistency issues of indexers. Additionally, you can write your code in Go without struggling with restrictive smart contract languages.
Thanks to our abstraction layer, shards are essentially agnostic, so you can build other shard constructs, such as a solid game shard to complement your cardinal game shard. You can also build an NFT minting shard 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 shard runtime as reliable as possible and avoiding any delays. We no longer rely on cryptographic economic constructions.
Each shard can have different DA batch compression strategies. You can geolocate shards to reduce game latency. You can also run game shards as independent game servers, so you don't have to worry about deploying roll-ups on day one.
We have built various games on top of the game shard, such as a clone of Agar.io, which was traditionally impossible. 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, make a hybrid, or build your own game shards. It's like Kubernetes for full-chain games, a mix-and-match Lego for your games.
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 games.
In conclusion, let's build cooler roll-ups. We are currently in a renaissance of roll-ups. Roll-ups allow us to scale blockchains and leverage the security of the underlying L1. However, we still live in a concept of roll-up architecture that is very EVM-centric. This is just the starting point, not the endpoint. Our goal is to build 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