Original Author: Solaire, YBB Capital
In the past, building a practical DApp on the blockchain with its linked list structure was not an easy task. However, despite these limitations, explorers 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, has completely changed the narrative of DeFi in the crypto space. If a simple DApp can reach such heights with the ingenuity of developers, what about more complex DApp applications? For example, building games or social platforms entirely on the blockchain. This may have seemed like a crazy idea in the past, but with Rollups opening up scalability, this possibility is starting to become subtle.
DeFi has brought billions of dollars in TVL to the crypto space. How can complex DApps be implemented? Will they lead crypto to new heights again? Perhaps the answer lies in fully on-chain games in their early stages of development. This article will analyze the history of full-chain games, the current definition of full-chain games, the implementation methods for creating and running full-chain games, and the significance of full-chain games for the future of crypto.
Origin and Development of Full-Chain Games
The history of full-chain games can be traced back to 10 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 developed a group of online enthusiasts, receiving support from many famous members of bitcointalk.org. With the love of video games from technology enthusiasts, the most popular "Huntercoin" post received over 380,000 views. However, unfortunately, Mikhail Sindeyev suffered a stroke in February 2014 and passed away, leading to the development of "Huntercoin" being in a difficult situation. The token HUC almost became worthless in 2015. Although the first attempt at a full-chain game was not successful, fortunately, the story of full-chain games continues.
2020 Gubsheep (Brian Gu), Alan Luo, 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 rules and logic are written into smart contracts, making each action a fully on-chain transaction in the game. The core part of the game content uses ZK-Snarks (zero-knowledge proofs) technology to create a war fog to reproduce the definition of the dark forest law in the novel "The Three-Body Problem" (once a cosmic civilization is discovered, it will inevitably be attacked by other cosmic civilizations).
For example, when players want to take action, they are influenced by the dark forest law and cannot expose their coordinates. Instead, they need to move from Planet A to Planet B. They need to submit the coordinates of Planet A and B as proof of their validity. However, Ethereum's block information is completely transparent. "Dark Forest" achieves information hiding through the following steps. Players choose the planet they want to leave and the destination planet, the positions of these two planets are private information for the player. The hash value of the positions is calculated and then submitted to the blockchain. At this stage, players will make a commitment (Commit stage). Due to the one-way nature of the hash function, these submitted hash values cannot be used to determine the actual planet positions of the players. The next stage is verification (Reveal stage), during which players generate and submit a zero-knowledge proof to prove the validity of their actions. This proof can be verified by anyone but will not reveal any information about the players' planet positions.
In this way, the first fully on-chain game that achieves information hiding on the transparent Ethereum is born. This crazy and highly imaginative experiment quickly caused a sensation in the entire crypto community, and Vtalik (founder of Ethereum) even directly retweeted and praised the game on Twitter.
However, after the launch of "Dark Forest" and the influx of over 10,000 players, the challenges started to appear. Ethereum's performance was insufficient to support the operation of such a complex application. On the day the game went online, the entire blockchain was congested, with trillions of gas being spent. And since the game is based on the libraries and architectural design of DeFi applications, later optimizations would only alleviate the pain without solving the problem.
Inspired by the experiment's prospect on ZK-Snarks and the consideration of the dilemma in the whole-chain game, game founder Brian Gu created 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 MUD, the game engine for the whole-chain game. Another co-founder, SCOTT SUNARTO, started developing the World Engine, a dedicated sharding Rollup framework for running the whole-chain game.
Zero-knowledge proofs are now widely used and well-known today. We will mainly discuss the MUD engine and the World Engine, that is, the creation and operation. But before that, we need to understand the definition and new cognitive approach to the whole-chain game by the driving force (0xPARC).
Autonomous Worlds
Based on the viewpoints in the 0xPARC's encrypted game paper collection "Autonomous Worlds," the whole-chain game needs to follow at least five standards:
l Data sourced from the blockchain: The blockchain is not only auxiliary storage for data and not just a "mirror" of data stored on proprietary servers. All meaningful data can be accessed on the blockchain, not only data like 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 Game development follows the open ecology principle: Game contracts and accessible game clients are open source. Third-party developers can achieve a complete redeployment, customization, or even fork their own 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 Games permanently reside on the chain: This point is closely related to the above three points because the touchstone to determine whether a game is a native encrypted 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 the 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;
l Game can communicate with things we consider valuable: The blockchain provides a local application interface for the concept of value itself, and digital assets can interoperate with other assets of interest to us by default. This not only reflects the depth and significance of the game, but also helps enhance the depth and significance of the game, linking the game world to the "real" world.
The all-chain game built on this standard can also be seen as a blockchain-based underlying world, or Autonomous Worlds.
So what is a world? The world does not necessarily refer to the real world, and the carrier of the world can be a novel, movie, game, poem, or even a legal system. However, in these worlds, the framework and rules are formulated by a center (author, developer, or group) and then conveyed to us. The degree of autonomy in these worlds is also different. For example, in the well-known open-world game "Minecraft," players have a high degree of autonomy and can create their own world through building with different blocks and modifying rules. On the other hand, a world with lower autonomy may 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 consider the blockchain as the foundation of the world, the blockchain unequivocally preserves the collection of all node entities in its state. In addition, they formally define the introduced rules with computer code. The world with the underlying blockchain allows its residents to participate in consensus. They operate a computer network and reach consensus each time a new entity is introduced.
From the perspective of the world, there are two blockchain concepts that need to be defined:
l Blockchain state root: The state root is a compression of all entities in the world.
With a state root, people can determine if any entity is virtual, and believing in the state root of a world is equivalent to believing in the world itself. 0x411842e02a67ab1ab6d3722949263f06bca-20c62e03a99812bcd15dce6daf26e is the state root of the Ethereum world at 07:30:10 PM UTC on July 21, 2022 – a world with the underlying blockchain. When calculating this state root, all entities of the Ethereum world are taken into account. It represents the entire content of that world at that particular time;
l Blockchain state transition function: Every blockchain defines a state transition function.
It can be seen as an explicit introduction rule. It defines how the previous state of the "world"—the collection of virtual entities—is transformed into a new collection of virtual entities through the input of humans and machines. In the case of Bitcoin, the state transition function defines how balances are spent and transferred between addresses.
Therefore, considering the whole chain game as a blockchain-based world, this decentralized world has infinite autonomy and can also be called an autonomous world.
Creation Dilemma
In the early exploration of new designs for whole chain games, developers were repeatedly influenced by the limitations of traditional DApp architecture and libraries used to build DeFi applications. "Dark Forest" and other early whole chain games were built on architectures and libraries that had to be followed at the time for building DeFi applications, which became the default choice for building whole chain games at the time.
Four patterns can summarize the early creation of whole chain games:
l When different contracts touch the same state: Multiple smart contracts may modify the same data or state, which may lead to data inconsistency or other issues. Sometimes the Diamond Pattern is used to solve this (the diamond pattern is a method to solve multiple inheritance issues in Solidity smart contracts);
l Writing multiple data structures: Each entity (such as soldiers, planets, etc.) has its own data structure and type;
l Writing Getters functions: These are functions that return batch elements of a data structure, used to obtain initial state or data from the chain. For example, the getPlanets() function may return a list of all planets;
l 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 chain. For example, an event may be triggered when a new planet is created, and the application listens to this event and updates its displayed list of planets.
Building a whole chain game using this pattern is very painful, although optimizations can be continuously made to alleviate the pain, but we all understand that this way of building is still far from using a true universal engine.
World Creator - MUD Engine
The birth of the MUD engine comes from the developers' reflections on past and existing problems. MUD is a framework for building complex applications on the Ethereum platform. MUD provides conventions for organizing data and logic, abstracting away low-level complexities, allowing developers to focus on the functionality of their applications. It standardizes the way on-chain data is stored. 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:
l Store: an on-chain database;
l World: an entry point framework that brings standardized access control, upgrades, and modules;
l tools: super-fast development tools based on Foundry;
l Client data storage: magically reflects the on-chain state;
l MODE: a Postgres database that allows the use of SQL queries.
EVM compatibility and high flexibility
MUD is not limited to the Ethereum mainnet in terms of versatility. As long as the language is supported, MUD can seamlessly operate on any EVM compatible chain, whether it's Polygon, Arbitrum, Optimism, or Gnosis Chain.
In addition, although MUD is the preferred framework in Autonomous Worlds and on-chain gaming communities, its applications go beyond that. At the same time, MUD offers great flexibility and does not force developers to be constrained by specific data models. In short, any functionality that can be implemented through Solidity mappings and arrays can be easily accomplished in MUD. And in terms of data availability, MUD applications deployed on both the mainnet and Rollups can rival traditional Ethereum applications, such as ENS and Uniswap.
Core Principles
As a highly synergistic library and toolset designed for complex on-chain applications, MUD revolves around three core principles:
All on-chain states are stored in the MUD on-chain database Store: Store is an embedded EVM database, similar to SQLite database, which has the concept of tables, columns, and rows. Using Store, data can be managed in a more structured way, without relying on storage methods provided by Solidity compiler. Also, it supports creating tables at runtime and allows registering hooks to automatically create indexed views, bringing more flexibility;
The logic is stateless and partitions across different contracts through custom permissions: "World" acts as an entry point, coordinating the access to "Store" from different smart contracts. When a "World" is deployed, it creates a "Store" which registers tables under a specific namespace. When functionalities (such as logic for transferring between addresses) are added to "World", they are registered under the namespace and are referred to as "systems". These "systems" are actually smart contracts but unlike traditional smart contracts, they are stateless and do not directly hold data. They read and write data using "World Store". Due to this design, these "systems" can be reused across different "Worlds" as long as they are deployed on the same chain;
No indexer or subgraph is required, and the front-end 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. Through the "MODE" node, the on-chain state is transformed to an SQL database in real-time, keeping the most up-to-date state (with millisecond-level latency). In addition, MUD provides a series of query tools such as MUD QDSL and GraphQL, making front-end synchronization easier. For React developers, MUD also offers dedicated Hooks to enable automatic binding and updating of component states.
Breaking the Shackles
By three core ideas, let's take the past dilemma as an example to see how MUD breaks the shackles 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 "Store" through "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 and planets in the game) can have its own table, and each table can have multiple columns to store different attributes of that entity;
l Getters Functions: With MUD's structured data storage, retrieving data becomes simpler and more intuitive. Developers can use SQL-like query languages to retrieve data, without the need to write specific getters functions. For example, to retrieve all planets, developers can simply query the planets table, without the need to write a getPlanets() function;
l Events: MUD provides automatic introspection, which means that any data changes will be automatically recognized by the system and trigger the corresponding events. Applications can listen to these events to synchronize or update their states, without the need to manually define events for each data structure.
The above are some usage instructions for the basic building blocks and components of MUD. MUD can also build more complex scenarios and applications.
Running the World, World Engine
The operation of blockchain games has always been a huge challenge for Ethereum. With the rapid development of Rollups and the upcoming upgrade of Kanchen, the cost will decrease significantly and the speed will increase significantly. Blockchain games are ready to take off, but the mainstream Rollups currently available are mainly designed for trading and have not been tailored specifically for blockchain games.
Argus's core product, World Engine, is a sharding architecture Rollup specifically designed for blockchain games. Since public testing is not yet available, we will analyze World Engine from the project's blog and presentations.
What Kind of Rollup Does Blockchain Games Need
l High Throughput and High TPS: Faster transaction processing, lower latency, better scalability;
l Read-Write Scalability: Most Layer 2 solutions are designed to handle a large number of writes for high concurrency, but games also need to read to obtain player positions, so both reading and writing are equally important;
l Scalable Chain: Scalability refers to increasing the processing capacity of a system by adding more nodes and resources to accommodate growing demands. This can avoid Noisy Neighbor problems (where the activity of one application or entity may negatively impact other applications or entities, leading to resource contention and performance issues);
l Flexibility and customization: Flexibility and customization make it convenient to modify state machines for game design. This includes having a game loop for self-execution, and so on;
l Tick rate: Ticks are atomic units of time in a game. To achieve low latency, a game requires a higher Tick rate or more blocks per second to reduce delays.
Sharding Architecture
To achieve the above goals, the team reviewed the situation at the beginning of the 21st century and the late 1990s when online games like MMOs were just emerging. In the early stages of online games, which had limited server and network technologies, a way needed to be found to support interactions among a large number of players. "Sharding" is one such solution, with the core idea of distributing players across different servers or "shards" where each shard can independently host a portion of 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, each capable of accommodating a certain number of players. The benefits of this approach include:
l Scalability: By distributing players across different shards, the game can more easily scale to accommodate more players;
l Load reduction: Sharding helps reduce the number of players and data on a single server, thereby reducing server load and improving performance;
l Congestion avoidance: Sharding can alleviate congestion issues among players in the same area, providing a smoother gaming experience;
l Geographical optimization: By assigning players to nearby shards, network latency can be reduced and game responsiveness 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 requirements with a focus on throughput and runtime. It is optimized to ensure a high Tick rate (i.e., updates per second) and block time. By default, it operates synchronously. The design goal is to ensure that transactions are processed quickly for efficient gameplay and system performance. It adopts a partial sorting approach for ordering, rather than requiring total sorting of all transactions. This means that not every transaction needs to occur after every other transaction. This reduces the burden of sorting and better satisfies the requirements of high throughput and fast block time.
There are two key components here, EVM Base Shard and a Game Shard. The EVM Base Shard is a pure EVM chain, while 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, allowing customization of this shard according to our preferences. The constructed shard is injected into the base shard. Only a standard interface needs to be implemented, similar to Cosmos which has an IBC interface. Essentially, 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, a data-oriented architecture that allows parallelization of the game and improves the throughput of game computations. It has a configurable "Tick rate" with a maximum of 20 ticks per second. For the blockchain here, that would be 20 blocks per second. Additionally, it is self-indexing, without the need for external indexers.
Furthermore, shards can also be geolocated to reduce latency. For example, there might be a sorter in the United States for the game, and Asian players have to wait for a 300 millisecond delay 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 200 millisecond delay, it's basically like playing a PowerPoint presentation.
Conclusion: Thoughts on Full Chain Games
Full chain games have always been a relatively niche direction in the Asian crypto community, but with the release of Starknet's game engine Dojo and the development demo of the OP Stack concept-validated Tictalk chain, discussions about full chain games are gradually heating up. The scope of this article is the ecosystem derived from "Dark Forest," which is currently the most powerful ecosystem for full chain games.
Through exploration of its history and technology, we can see that Rollup and DApps still have great potential. From a broader perspective, with the improvement of infrastructure, not only games but also the construction and realization of various complex ideas will be carried out through MUD and integrated with more complex Rollup solutions. The new paradigm of blockchain may start from full chain games.
About all-chain games, there is a lot of expandable content, such as the development of Starknet driven by the all-chain game ecosystem derived from Loot, or the implementation of state synchronization and the application of the ESC architecture. I have placed the relevant reading links in the table below, and interested friends can read and understand.
References
1. Original: Modular Summit Day 1 (Galois Stage) Translation: World Engine: Rollup framework designed for all-chain games
3. MUD Development Documentation
Related Readings
1. Counting Time for "Digital Deities"
2. A Review of the History of All-Chain Game Development
3. How to use OPStack to build the clock cycle of all-chain games
4. 'The promise of MUD ECS engine': the future of on-chain gaming
