Analysis of the Full Chain Game Core MUD Engine and World Engine

Author: Solaire, YBB Capital

In the past, building a practical DApp on the blockchain has never been an easy task due to the limitations of the blockchain’s linked list structure. But even with these limitations, explorers have never stopped moving forward. With the birth of the famous constant product formula “x * y = k,” Uniswap, with just a few hundred lines of code, has completely changed the narrative of DeFi in the crypto world. If a simple DApp can achieve such heights with the developer’s ingenuity, what about more complex DApps? For example, building a game or a social platform entirely on the blockchain? This may have been a crazy idea in the past, but in the era of Rollups opening up scalability, this possibility is becoming subtle.

DeFi has brought billions of dollars in TVL to the crypto world. How can more complex DApps be realized? Will they lead crypto to new heights once again? Perhaps the answer lies in the early-stage development of fully on-chain games. This article will analyze fully on-chain games from four aspects: the history of fully on-chain games, the current definition of fully on-chain games, the implementation of creating and operating fully on-chain games, and the significance of fully on-chain games for the future of crypto.

The Origin and Development of Fully On-Chain Games

The history of fully on-chain games can be traced back ten years ago when Mikhail Sindeyev forked Namecoin and built the world’s first blockchain game, “Huntercoin.” “Huntercoin” started as an experimental prototype in 2013 and quickly gained a group of online enthusiasts, receiving support from many famous members of bitcointalk.org. With the passion of tech enthusiasts for video games, the most popular “Huntercoin” post received over 380,000 views. Unfortunately, Mikhail Sindeyev suffered a stroke and passed away in February 2014, and the development of “Huntercoin” was also in trouble. The token HUC almost became worthless in 2015. Although the first attempt at fully on-chain games was not successful, fortunately, the story of fully on-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 all the rules and logic are written into smart contracts, making every action a fully on-chain transaction in the game. The core part of the game’s content uses ZK-Snarks (zero-knowledge proofs) technology to create a fog of war and reproduce the definition of the dark forest law from the novel “The Three-Body Problem” (once a civilization is discovered, it will inevitably be attacked by other civilizations).

For example, when players want to take action, influenced by the law of the dark forest, they cannot expose their coordinates but need to move from planet A to planet B. They need to submit the coordinates of A and B as proof that this is valid. However, the block information on Ethereum is completely transparent. “Dark Forest” achieves information hiding in the following way: players choose the star they want to leave and the destination star, and these two positions are private information of the players. The hash value of the positions of the star to leave and the destination star is calculated, and then these two hash values are submitted to the blockchain. In this stage, players make a commitment (Commit phase). Due to the one-way nature of the hash function, these submitted hash values cannot be used to determine the actual positions of the player’s planets. The next phase is the verification (Reveal phase). In this phase, players generate and submit a zero-knowledge proof to prove that their actions are valid. This proof can be verified by anyone but will not disclose any information about the player’s planet positions.

In this way, the first fully chain game that hides information on the transparent Ethereum was born. This crazy and highly imaginative experiment quickly caused a sensation in the entire crypto community, and Vitalik (the founder of Ethereum) even directly retweeted and praised this game on Twitter.

However, after the release of “Dark Forest” and the influx of more than 10,000 players, the difficulties also started to emerge. Ethereum’s performance was not sufficient to support the operation of this complex application. On the day the game went online, the entire blockchain was clogged, and trillions of gas were spent. And because the game was based on the library and architectural design of DeFi applications, later optimizations only served to alleviate the pain without solving the problem.

Inspired by this experiment’s prospects for ZK-Snarks and reflections on the difficulties of fully chain games, the game’s founder, Brian Gu, created 0xLianGuaiRC as a research institute for ZK-Snarks to promote the development of zero-knowledge proofs. Another branch of 0xLianGuaiRC, Lattice, is responsible for designing and maintaining the MUD fully chain game engine. The other founder, SCOTT SUNARTO, began developing a specialized shard Rollup framework for fully chain game operations called the World Engine.

Zero-knowledge proofs are already widely used and well-known today. What we will discuss next are the MUD engine and the World Engine, which are about creation and operation. But before that, we need to understand the definition and new cognitive approach to fully chain games by the driver (0xLianGuaiRC).

Autonomous Worlds

Based on the viewpoints in the collection of cryptographic game papers by 0xLianGuaiRC, “Autonomous Worlds,” fully chain games need to adhere to at least five standards:

l Data sourced from the blockchain: The blockchain is not only an auxiliary storage for data, nor is it just a “mirror” of data stored on proprietary servers. All meaningful data can be accessed on the blockchain, not just data related to asset ownership. This allows games to fully leverage the advantages of programmable blockchains – transparent data storage and permissionless interoperability;

l Logic and rules implemented through smart contracts: For example, battles in games are conducted on the chain, not just ownership;

l The development of the game follows the principles of an open ecosystem: Game contracts and accessible game clients are open source. Third-party developers can achieve complete redeployment, customization, and 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-consistent) community;

l The game is permanently stored on the chain: This point is closely related to the above three points because the litmus test for determining whether a game is a native cryptographic game is: Can the game still be played if the client provided by the core developers disappears tomorrow? The answer is often yes, if (and only if) the game data storage is permissionless, if game logic can be executed without permission, and if the community can interact with the core smart contracts without relying on interfaces provided by the core team;

In games, valuable things can be exchanged with what we consider valuable: blockchain provides a local application interface for the concept of value itself, and digital assets can be interoperable with other assets we care about by default. This not only reflects the depth and significance of games, but also helps enhance the depth and significance of games, connecting the game world with the “real” world.

Full-chain games built on this standard can also be seen as a blockchain-based underlying world, or Autonomous Worlds.

So what is a world? A world does not only refer to the real world, the carrier of a world can be a novel, a movie, a game, a poem, or even a legal system. But in these worlds, the framework and rules are established and conveyed to us by a central authority (author, developer, or group). The degree of autonomy in these worlds also varies, for example, in the well-known open-world game Minecraft, players have high autonomy and can create their own world through the construction of different blocks and rule modifications. On the other hand, worlds with lower autonomy may be found in novels, such as Harry Potter, where the magical world we see is based on the rules and framework created by J.K. Rowling.

If we consider blockchain as the foundation of a world, it unequivocally preserves the collection of all node entities in its state. In addition, they formally define the introduction rules using computer code. Having a world with the underlying blockchain allows its inhabitants to participate in consensus. They operate a computer network and reach consensus each time a new entity is introduced.

From the perspective of a 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 or not, and believing in the state root of a world is equivalent to believing in the world itself. 0x411842e02a67ab1ab6d3722949263f06bca-20c62e03a99812bcd15dce6daf26e is the state root of Ethereum, a world with the underlying blockchain, at 07:30:10 PM UTC on July 21, 2022. When computing this state root, all entities in the Ethereum world are taken into account. It represents the entire content of the world at that specific time;

Blockchain state transition function: Every blockchain defines a state transition function. It can be seen as a clear introduction rule. It defines how the previous state of the “world” – the collection of virtual entities – introduces new virtual entities through the input of humans and machines. For example, in the case of Bitcoin, the state transition function defines how balances are spent and transferred between addresses.

Therefore, considering full-chain games as worlds with blockchain as the underlying layer, this decentralized world has infinite autonomy and can also be called an autonomous world.

The Dilemma of Creation

In the early exploration of new design processes for blockchain games, developers were often influenced by the limitations of traditional DApp architecture and libraries used to build DeFi applications. “Dark Forest” and other early blockchain games were built using the architecture and libraries that were the default choice at the time for building blockchain games.

The early patterns in creating blockchain games can be summarized as follows:

– 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 Diamond LianGuaittern is used to solve this (the diamond pattern is a way to solve the problem of multiple inheritance in Solidity smart contracts);

– Writing multiple data structures: Each entity (such as soldiers and planets 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 blockchain. For example, the getPlanets() function may return a list of all planets;

– Events: Each data structure contains an event, which is a specific function in the smart contract that allows the application to synchronize or update its state when a new block is added to the blockchain. For example, an event may be triggered when a new planet is created, and the application will listen to this event and update its displayed list of planets.

Building blockchain games using this pattern is very painful. Although optimizations can be made to alleviate the pain, we all understand that this approach is still far from using a truly general-purpose engine.

The Creator of Worlds – MUD Engine

The birth of the MUD Engine came from the reflection of open-minded individuals on past and existing problems. MUD is a framework for building complex Ethereum applications. It provides conventions for organizing data and logic, and abstracts away low-level complexities, allowing developers to focus on the functionality of their applications. It standardizes the way data is stored on the blockchain. With this standardized data model, MUD can provide all the network code needed to synchronize contracts and client states.

The latest version of MUD is equipped with five components:

Store: An on-chain database;
World: An entry point framework that brings standardized access control, upgrades, and modules;
Tools: Super-fast development tools based on Foundry;
Client data storage: Can magically reflect on-chain state;
MODE: A Postgres database that allows SQL queries.

EVM Compatibility and High Flexibility

MUD’s versatility extends beyond the Ethereum mainnet. As long as the language is supported, MUD can seamlessly operate on any EVM-compatible blockchain, whether it’s Polygon, Arbitrum, Optimism, or Gnosis Chain.

Furthermore, while MUD is the preferred framework in the Autonomous Worlds and blockchain gaming communities, its applications go far beyond that. At the same time, MUD offers great flexibility and does not force developers to be restricted by specific data models. In short, any functionality that can be achieved through Solidity mappings and arrays can be easily accomplished in MUD. And in terms of data availability, MUD applications deployed on the mainnet or Rollups can rival traditional Ethereum applications such as ENS and Uniswap.

Core Concept

MUD, as a highly collaborative library and tool designed for complex on-chain applications, revolves around three core concepts:

l All on-chain states are stored in the MUD on-chain database, Store: Store is an embedded EVM database, similar to the SQLite database. It has the concepts of tables, columns, and rows. Using Store, data can be managed in a more structured way without relying on storage methods provided by the Solidity compiler. Furthermore, it supports creating tables at runtime and allows registering hooks to automatically create indexed views, bringing more flexibility;

l Logic is stateless and partitioned across different contracts through custom permissions: “World” serves as an entry point, coordinating the access of different smart contracts to “Store”. When a “World” is deployed, it will create a corresponding “Store”, and each table in the “Store” is registered under a specific namespace. When functionalities (such as the logic of transferring 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 utilize the “World Store” for data read and write. Due to this design, these “systems” can be reused across different “Worlds” as long as they are deployed on the same chain;

l No need for indexers or subgraphs, and frontend can stay in sync: When using Store (as well as the extended World), on-chain data is automatically introspected, and any changes are broadcasted through standard events. By using the “MODE” node, the on-chain state is transformed into an SQL database in real-time, maintaining the latest state with millisecond-level latency. In addition, MUD provides a series of query tools, such as MUD QDSL and GraphQL, making frontend synchronization simpler. For React developers, MUD also provides dedicated Hooks that allow automatic binding and updating of component states.

Breaking Free

With these three core concepts in mind, let’s take a look at how MUD breaks free from the shackles of complex applications, using past challenges as an example.

l 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;

l Data structure: Unlike traditional Solidity storage methods, MUD’s “Store” provides concepts similar to tables, columns, and rows in SQLite, allowing for more structured storage and management of data. Each entity (such as soldiers or planets in a game) can have its own table, and each table can have multiple columns to store different attributes of the entity;

l Getters functions: With MUD’s structured data storage in the “Store”, retrieving data becomes simpler and more intuitive. Developers can use SQL-like query languages to retrieve data without the need to write dedicated getters functions. For example, to retrieve all planets, developers can simply query the planets table without having to write a getPlanets() function;

Event: MUD provides automatic introspection, which means that any data changes will be automatically recognized by the system and trigger corresponding events. Applications can listen to these events to synchronize or update their state without manually defining events for each data structure.

Above is a partial explanation of the usage of basic building blocks and components of MUD, and MUD can also build more complex scenarios and applications.

World Engine, the Running World

The operation of a full-chain game has always been a huge challenge for Ethereum. With the rapid development of Rollups and the upcoming upgrade of Cancun, the cost will be greatly reduced and the speed will be greatly improved in the future. The full-chain game is ready to go, but the current mainstream Rollups are basically designed for transactions and not specifically tailored for full-chain games.

Argus’s core product, World Engine, is a sharding architecture Rollup specifically designed for full-chain games. Since there is no public testing yet, we will analyze World Engine from the project’s blog and presentations.

What kind of Rollup does a full-chain game need?

– High throughput and high TPS: faster transaction processing, lower latency, and better scalability;

– Scalable reading and writing: Most Layer2 designs require a large amount of writing to achieve high concurrency processing, but games also need to read to obtain player positions, so reading is equally important;

– Horizontally scalable chain: Horizontal scalability refers to increasing the system’s processing capacity by adding more nodes and resources to meet the growing demand. This can avoid the Noisy Neighbor problem (the activity of one application or entity may have a negative impact on other applications or entities, resulting in resource contention and performance issues);

– Flexibility and customization: Flexibility and customization, easy to modify the state machine to fit game design. This includes having a game loop and making it self-executing, and so on;

– Tick rate: Ticks are atomic units of game time, and games need a higher tick rate or more blocks per second to reduce latency.

Sharding Architecture

To achieve the above goals, the team reviewed the situation at the turn of the 21st century and the late 1990s, and was inspired by the emergence of online games like MMOs. Early online games, given the limited server and network technology at the time, needed to find a way to support interactions among a large number of players. “Sharding” is one solution, where the core idea is to distribute players to different servers or “shards,” with each shard independently hosting a portion of the players, game maps, and data.

For example, Ultima Online, an early MMORPG, implemented the concept of sharding on its servers. Different shards in the game represented different virtual worlds, with each shard able to accommodate a certain number of players. The benefits of doing this include:

Scalability: By distributing players to different shards, the game can more easily scale to accommodate more players;
Reduced load: Sharding can reduce the number of players and amount of data on a single server, thereby reducing the server’s load and improving performance;
Avoiding congestion: Sharding can reduce congestion of players in the same area, providing a smoother gaming experience;
Geographical optimization: By assigning players to nearby shards, network latency can be reduced and game response speed can be improved.

So how does this concept apply to World Engine? Unlike many previous shard sorters, the design of “World Engine” is more tailored to specific needs. Its optimization focuses on throughput and runtime. In order to ensure efficient tick rates (i.e., update frequency per second) and block time, it is synchronous by default. The goal of the design is to ensure that transactions are processed quickly to maintain efficient gameplay or system performance. It uses a partial sorting approach rather than requiring total sorting of all transactions. This means that not every transaction needs to occur after all other transactions. This reduces the burden of sorting, better meeting the needs of high throughput and fast block time.

There are two key components here, EVM Base Shard and a Game Shard. The EVM Shard is a pure 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 has a bring-your-own-implementation interface, so we can customize this shard according to our preferences. The built shard is injected into the base shard. We just need to implement a standard interface, just like the familiar Cosmos, which has an IBC interface. Basically, we can integrate this into a similar specification and bring our own 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, which is a data-oriented architecture. This allows parallelization of the game and improves the throughput of game calculations. It has a configurable tick rate, with a maximum of 20 ticks per second. For the blockchain here, that means 20 blocks per second. It is also self-indexed, without the need for external indexers.

In addition, shards can be geolocated to reduce latency. For example, the game may have sorters in the United States, and Asian players may have to wait for a delay of 300 milliseconds for transactions to reach the sorter. This is a huge problem in games because 300 milliseconds is a long time. If you try to play an FPS game with a delay of 200 milliseconds, it’s basically like playing a PowerPoint.

Conclusion: Thoughts on Full-Chain Gaming

Full-chain gaming has always been a relatively niche direction in the Asian crypto community. However, with the launch of Starknet’s game engine Dojo, as well as the development demonstration of the OP Stack concept verification-based Tictalk chain, discussions about full-chain gaming 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 gaming.

Through exploration of its history and technology, we can see that Rollup and DApps still have a high ceiling. From a broader perspective, with the improvement of infrastructure, not only games, but also the construction and implementation of various complex ideas will be carried out through MUD and integrated with more complex Rollup solutions. The new paradigm of blockchain may start with full-chain gaming.

There are many expandable contents about the whole-chain game, such as the development of Starknet driven by the whole-chain game ecosystem derived from Loot, or the implementation of state synchronization and the application of ESC architecture. I have placed the relevant reading links in the table below. Interested friends can read and understand.

References

1. Original: Modular Summit Day 1 (Galois Stage) Translation: World Engine: A Shard Rollup Framework Designed for Whole-Chain Games

2. Lattice History

3. MUD Development Documentation

4. AUTONOMOUS WORLDS

Like what you're reading? Subscribe to our top stories.

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

GameFiLayerLootOptimism

Gambling Chain