Analysis of the Full-Chain Game Core: MUD Engine and World Engine
Viewing the entire chain game as a world based on blockchain, this decentralized world possesses infinite autonomy, which can also be referred to as an autonomous world.Author*: ** Solaire, YBB Capital Researcher*
In the past, due to the limitations of the blockchain's linked list structure, building a practical DApp on-chain has never been an easy task. However, despite these limitations, explorers have never stopped moving forward. With the birth of the famous constant product pool formula "x * y = k," Uniswap, with just a few hundred lines of code, led DeFi to completely change the narrative of Crypto. If simple DApps can achieve such heights through the ingenuity of developers, what about complex DApp applications? For instance, building a game or social platform entirely on-chain? This may have seemed like a crazy idea in the past, but with Rollups opening up scalability today, this possibility is starting to become subtle.
DeFi has brought hundreds of billions of dollars in TVL to Crypto; how can complex DApps be realized? Will they lead Crypto to a new height once again? Perhaps the emerging full-chain games in their early development can provide us with answers. This article will analyze full-chain games through four parts: the history of full-chain games, the current definition of full-chain games, the methods of creation and operation of full-chain games, and the significance of full-chain games for the future of Crypto.
The Origin and Development of Full-Chain Games
The history of full-chain games can be traced back ten years, when Mikhail Sindeyev forked Namecoin and built the world's first blockchain game, "Huntercoin." "Huntercoin" began as an experimental prototype in 2013 and quickly developed a group of online enthusiasts, gaining support from many notable members of bitcointalk.org. With the love of technology enthusiasts for video games, the most popular Huntercoin post garnered over 380,000 views. Unfortunately, Mikhail Sindeyev passed away from a stroke in February 2014, and the development of "Huntercoin" fell into difficulties, with the token HUC nearly reaching zero in 2015. Although the first attempt at full-chain games did not succeed, fortunately, the story of full-chain games continues.
In 2020, Gubsheep (Brian Gu), Alan Luo, and SCOTT SUNARTO, inspired by the novel "The Three-Body Problem: The Dark Forest," developed a MMORTS space conquest game called "Dark Forest." The game is built on Ethereum and writes all rules and logic into smart contracts, meaning every action is an on-chain transaction in a full-chain game. The core part of the game content utilizes ZK-Snarks (zero-knowledge proofs) technology to create a fog of war that reproduces the definition of the dark forest law from the Three-Body Problem novel (once a certain cosmic civilization is discovered, it will inevitably be attacked by other cosmic civilizations).
For example, when a player wants to take action, influenced by the dark forest law, they cannot expose their coordinates but must move from planet A to planet B. They need to submit the coordinates of A and B to prove this is valid, but Ethereum's block information is completely transparent. "Dark Forest" achieves information hiding in the following way. Players choose the planet they want to leave and the destination planet; the positions of these two planets are private information for the players. They calculate the hash values of the positions of the departing and destination planets and then submit these hash values to the blockchain. At this stage, players submit a commitment (Commit phase). Due to the one-way nature of hash functions, these submitted hash values cannot be used to determine the actual planetary position of the player. The next phase is the verification (Reveal phase), where players generate and submit a zero-knowledge proof to demonstrate that their actions are valid. This proof can be verified by anyone but does not reveal any information about the player's planetary position.
Thus, the first full-chain game that hides information on the transparent Ethereum was born. This crazy yet imaginative experiment quickly caused a stir in the entire Crypto community, with Vitalik (the founder of Ethereum) even retweeting and praising the game on Twitter.
However, after the launch of "Dark Forest," difficulties began to emerge with the influx of over 10,000 players, as Ethereum's performance was insufficient to support the operation of such a complex application. The game directly clogged the entire blockchain on its launch day, with trillions of Gas being spent. Moreover, since the game was designed based on the libraries and architecture of DeFi applications, later optimizations only alleviated the pain without solving the problem.
Inspired by the prospects of ZK-Snarks and reflecting on the challenges of full-chain games, game founder Brian Gu established 0xPARC as a research institute for ZK-Snarks to promote the development of zero-knowledge proofs. Another branch of 0xPARC, Lattice, is responsible for designing and maintaining the full-chain game engine MUD. Another founder, SCOTT SUNARTO, began developing a shard Rollup framework specifically for running full-chain games—World Engine.
Zero-knowledge proofs have begun to be widely used today and are well-known to many. The main focus of our discussion will be on the latter two, the MUD engine and World Engine, which are about creation and operation. But before that, we need to understand the definition and new cognitive approach to full-chain games by the drivers (0xPARC).
Autonomous Worlds
Based on the views in the 0xPARC collection of cryptographic game papers "Autonomous Worlds," full-chain games must adhere to at least five standards:
- Data sourced from the blockchain: The blockchain is not just an auxiliary storage for data, nor merely a "mirror" of data stored on proprietary servers. All meaningful data can be accessed on the blockchain, not just data like asset ownership. This allows the game to fully leverage the advantages of programmable blockchains—transparent data storage and permissionless interoperability;
- Logic and rules implemented through smart contracts: For example, battles in the game, not just ownership, are conducted on-chain;
- Game development follows open ecosystem principles: Game contracts and accessible game clients are open source. Third-party developers can achieve complete redeployment, customization, or even forking of their game experience through plugins, third-party clients, and interoperable smart contracts. This, in turn, enables game developers to leverage the creative output of the entire (incentive-aligned) community;
- Games permanently reside on-chain: This point is closely related to the above three, as the litmus test for determining whether a game is a crypto-native game is: If the client provided by the core developers disappears tomorrow, can the game still be played? The answer is often affirmative, if (and only if) the game data storage is permissionless, if the game logic can be executed permissionlessly, and if the community can interact with the core smart contracts without relying on interfaces provided by the core team;
- Games can interoperate with things we consider valuable: The blockchain provides a local application interface for the concept of value itself, allowing digital assets to interoperate with other assets we care about by default. This reflects the depth and significance of the game and helps enhance the depth and significance of the game, linking the game world with the "real" world.
Full-chain games built based on these standards can also be viewed as worlds based on blockchain, or Autonomous Worlds.
So what is a world? A world does not only refer to the real world; its carriers can be novels, movies, games, poetry, or even legal systems. However, in these worlds, the framework and rules are set by a center (author, developer, or community) and then conveyed to us. The degree of autonomy in these worlds varies. For example, in the very well-known open-world game Minecraft, players have a high degree of autonomy. By building with different blocks and modifying rules, players can create worlds that belong solely to them. In contrast, a world with lower autonomy might be a novel world, such as Harry Potter, where the magical world we see is based on the rules and framework created by J.K. Rowling.
If we take the blockchain as the foundation of the world, it unequivocally preserves the collection of all node entities in its state. Furthermore, they formally define the introduced rules with computer code. A world built on the blockchain allows its residents to participate in consensus. They operate a computer network that reaches consensus each time a new entity is introduced.
From the perspective of the world, there are two blockchain concepts that need to be defined:
- Blockchain state root: The state root is a compression of all entities in the world. With the state root, people can determine whether any entity is virtual. Believing in a world's state root is equivalent to believing in the world itself. 0x411842e02a67ab1ab6d3722949263f06bca-20c62e03a99812bcd15dce6daf26e is the state root of Ethereum as of July 21, 2022, 07:30:10 PM UTC—a world with a blockchain foundation. When calculating this state root, all entities in the Ethereum world are considered. It represents everything in that world at that specific time;
- Blockchain state transition function: Each blockchain defines a state transition function. It can be viewed as a clear introduction rule. It defines how the previous state of the "world"—the collection of virtual entities—introduces new virtual entities through inputs from people and machines. In the case of Bitcoin, the state transition function defines how balances are consumed and transferred between addresses.
Therefore, viewing full-chain games as worlds based on the blockchain means that this decentralized world possesses infinite autonomy, which can also be referred to as autonomous worlds.
The Dilemma of Creation
In the early exploration of new designs for full-chain games, developers were repeatedly influenced by the limitations of traditional DApp architectures and the libraries used to build DeFi applications. "Dark Forest" and other early full-chain games had to follow the architectures and libraries used for building DeFi applications at that time, which became the default choice for building full-chain games.
The early patterns in creating full-chain games can be summarized in four points:
- When different contracts touch the same state: Multiple smart contracts may modify the same data or state, which can lead to data inconsistency or other issues. Sometimes the Diamond Pattern is used to solve this (the Diamond Pattern is a method for resolving multiple inheritance issues in Solidity smart contracts);
- Writing multiple data structures: Each entity (such as soldiers, planets, etc., in the game) has its own data structure and type;
- Writing Getters functions: These are functions that return batches of elements from the data structure, used to retrieve initial states or data from the chain. For example, the getPlanets() function might return a list of all planets;
- Events: Each data structure contains an event, which is a specific function in the smart contract that allows applications to synchronize or update their state when a new block is added to the chain. For example, when a new planet is created, an event might be triggered, and the application would listen for this event and update its displayed list of planets.
Building full-chain games through this pattern is very painful. Although optimizations can be continuously made to alleviate the pain, we all understand that this construction method is still far from using a truly universal engine.
The Creator of Worlds—MUD Engine
The birth of the MUD engine comes from the thoughts of developers regarding past and existing problems. MUD is a framework for building complex applications on Ethereum. MUD provides conventions for organizing data and logic and abstracts low-level complexity, allowing developers to focus on the functionality of the application. It standardizes the way on-chain data is stored. With this standard data model, MUD can provide all network code to synchronize contract and client states.
The latest version of MUD currently comes equipped with five components:
- Store: An on-chain database;
- World: An entry point framework that brings standardized access control, upgrades, and modules;
- Tools: Ultra-fast development tools based on Foundry;
- Client data storage: Can magically reflect on-chain states;
- MODE: A Postgres database that can use SQL queries.
EVM Compatibility and High Flexibility
The versatility of MUD is not limited to the Ethereum mainnet; as long as the language is supported, MUD can operate seamlessly on any EVM-compatible chain, whether it is Polygon, Arbitrum, Optimism, or Gnosis Chain.
Moreover, while MUD is the preferred framework in Autonomous Worlds and the on-chain gaming community, its applications extend far beyond that. At the same time, MUD offers great flexibility, not forcing developers to be constrained by a specific data model. In short, any functionality that can be implemented through Solidity mappings and arrays can be easily accomplished in MUD. Regarding data availability, whether deployed on the mainnet or Rollups, MUD applications can rival traditional Ethereum applications like ENS and Uniswap.
Core Ideas
As a highly collaborative library and toolset designed for complex on-chain applications, the core ideas of MUD revolve around three points:
- All on-chain states are stored in the MUD on-chain database Store: Store is an embedded EVM database, similar to an SQLite database, which has the concepts of tables, columns, and rows. Using Store allows for more structured data management without relying on the storage methods provided by the Solidity compiler. Additionally, it supports creating tables at runtime and allows registering hooks to automatically create indexed views, bringing more flexibility;
- Logic is stateless and partitioned across different contracts through custom permissions: "World" acts as an entry point, coordinating different smart contracts' access to the "Store." When a "World" is deployed, it immediately creates a "Store," and each table in the "Store" is registered under a specific namespace. When functionalities (like the logic for transferring balances between addresses) are added to the "World," they are also registered under the namespace and referred to as "systems." These "systems" are essentially smart contracts, but unlike traditional smart contracts, they are stateless and do not directly hold data. Instead, they read and write data using the "World Store." Due to this design, as long as they are deployed on the same chain, these "systems" can be reused across different "Worlds";
- No need for indexers or subgraphs; the frontend can remain synchronized: When using Store (and the extended World), on-chain data undergoes automatic introspection, meaning any changes are broadcasted through standard events. Through the "MODE" node, the on-chain state is converted into an SQL database in real-time, keeping the latest state (with millisecond-level latency). Additionally, MUD provides a range of query tools, such as MUD QDSL and GraphQL, simplifying frontend synchronization. For React developers, MUD also offers dedicated Hooks that allow for automatic binding and updating of component states.
Breaking the Chains
Through the three core ideas, let's revisit the past dilemmas and see how MUD breaks the chains of complex applications.
- When different contracts touch the same state: By using the "World" and "Store" structure to centrally manage on-chain states. All smart contracts (referred to as "systems" in MUD) access and modify data in the "Store" through the "World." This ensures that all state modifications go through a centralized entry point, reducing the risk of data inconsistency or conflicts. Through namespaces and paths, MUD provides fine-grained access control to data. Different "systems" can have different permissions, ensuring that only authorized "systems" can modify specific data or states;
- Data structures: Unlike traditional Solidity storage methods, MUD's "Store" provides a table, column, and row concept similar to SQLite, allowing for more structured storage and management of data. Each entity (such as soldiers, planets, etc., in the game) can have its own table, and each table can have multiple columns to store different attributes of that entity;
- Getters functions: Since MUD's "Store" provides structured data storage, retrieving data becomes simpler and more intuitive. Developers can use SQL-like query languages to obtain data without needing to write dedicated getters functions. For example, to get all planets, developers can simply query the planets table without needing to write a getPlanets() function;
- Events: MUD provides automatic introspection, meaning any data changes are automatically recognized by the system and trigger corresponding events. Applications can listen for these events to synchronize or update their states without needing to manually define events for each data structure.
The above is a partial explanation of the basic building blocks and components of MUD, which can also be used to construct more complex scenarios and applications.
Running the World, World Engine
Running full-chain games has always been a significant challenge for Ethereum. With the rapid development of Rollups and the approach of the Cancun upgrade, costs will significantly decrease, and speeds will increase. Full-chain games are poised to take off, but the current mainstream Rollups are primarily designed for transactions and have not been tailored specifically for full-chain games.
The core product of Argus, World Engine, is a shard architecture Rollup specifically designed for full-chain games. As there is currently no public testing, we will analyze World Engine from the project's blog and presentations.
What Kind of Rollup Do Full-Chain Games Need?
- High throughput and high TPS: Faster transaction processing, lower latency, and better scalability;
- Extended read/write: Most Layer 2 solutions are designed for high concurrent processing with a focus on extensive writing, but games require reading to obtain player positions, so both read and write are equally important;
- Horizontally scalable chains: Horizontal scalability refers to increasing the system's processing capacity by adding more nodes and resources to meet growing demands. This can avoid the Noisy Neighbor problem (the activity of one application or entity may negatively impact others, leading to resource contention and performance issues);
- Flexibility and customization: Flexibility and customizability to easily modify the state machine to suit game design. This includes having a game loop that executes itself, etc.;
- Tick rate: Ticks are the atomic units of time in games. To achieve sufficiently low latency, games require a higher Tick rate or more blocks per second to reduce latency.
Shard Architecture
To achieve the above goals, the team reviewed the early 21st century and late 1990s, drawing inspiration from the emergence of online games like MMOs. Early online games needed to find ways to support large player interactions with relatively limited server and network technology. "Sharding" is one such solution, where the core idea is to distribute players across different servers or "shards," with each shard independently hosting a portion of players, game maps, and data.
For example, Ultima Online is an early MMORPG that implemented the sharding concept on its servers. Different shards in the game represent different virtual worlds, with each shard accommodating a certain number of players. The benefits of this approach include:
- Scalability: By distributing players across different shards, the game can more easily scale to accommodate more players;
- Reduced load: Sharding can decrease the number of players and data on a single server, thereby reducing server load and improving performance;
- Avoiding congestion: Sharding can reduce player congestion in the same area, providing a smoother gaming experience;
- Geographical optimization: By assigning players to nearby shards, network latency can be reduced, improving game response speed.
So how can this concept be brought into World Engine? Unlike many past sharding sorters, the design of "World Engine" is better suited to specific needs. Its optimization direction includes throughput and runtime. To ensure a high "Tick rate" (i.e., the frequency of updates per second) and block time, it defaults to synchronous operation. The design goal is to ensure transactions are processed quickly to maintain efficient gaming experiences or system performance. The sorting method employs partial sorting rather than requiring a total ordering of all transactions. This means that not every transaction must occur after all other transactions. This can reduce the sorting burden, better meeting the demands for high throughput and fast block times.
There are two key components here: EVM Base Shard (EVM shard) and a Game Shard (game shard). The EVM shard is purely an EVM chain. The real secret weapon is the game shard, which is essentially a mini-blockchain designed as a high-performance game server. World Engine features a bring-your-own-implementation interface, allowing us to customize this shard according to our preferences. The constructed shard is injected into the base shard. It only requires implementing a standard interface, similar to the IBC interface we are familiar with in Cosmos. We can essentially integrate this into a similar specification, bringing our shard into the World Engine stack.
Cardinal is the first game shard implementation of World Engine. It uses the Entity-Component-System (ECS) game architecture, a data-oriented architecture. This allows for the parallelization of games and increases the throughput of game computations. It has a configurable "Tick rate," with a maximum of 20 ticks per second. For the blockchain here, that means 20 blocks per second. Additionally, it is self-indexing, requiring no external indexers.
Moreover, shards can also be geographically located to reduce latency. For instance, if the game has a sorter in the United States, Asian players might have to wait 300 milliseconds of latency for their transactions to reach the sorter. This is a significant issue in gaming, as 300 milliseconds is a long time. If you try to play an FPS game with 200 milliseconds of latency, it essentially feels like playing a PowerPoint presentation.
Conclusion: Reflections on Full-Chain Games
Full-chain games have been a relatively niche direction within the Asian crypto circle, but with the launch of Starknet's game engine Dojo and the development demonstrations of proof-of-concept tick chains based on the OP Stack, discussions about full-chain games are gradually heating up. The scope of this article discusses the ecosystem derived from "Dark Forest," which is currently the most powerful ecosystem for full-chain games.
Through the exploration of its history and technology, we can see that Rollups and DApps still possess a high ceiling. Looking from a broader perspective, with the improvement of infrastructure, not only games but also the construction and realization of various complex ideas will be achieved through MUD, integrating interactions on more complex Rollup solutions. The new paradigm of blockchain may begin with full-chain games.
There are many expandable topics regarding full-chain games, such as how the full-chain game ecosystem derived from Loot has propelled the development of Starknet, or the implementation of state synchronization and the application of the ECS architecture. I have provided links to related readings in the table below for those interested.
References
Original text: Modular Summit Day 1 (Galois Stage)
Translated text: World Engine: A Shard Rollup Framework Designed for Full-Chain Games
Related Readings
1. Timing for "Digital Deities"
2. A Review of the Development History of Full-Chain Games
3. How to Use OPStack to Build the Clock Cycle of Full-Chain Games
4. The Future of On-Chain Gaming: 'The Promise of MUD ECS Engine'
