Author: Solaire, YBB Capital

Introduction

In the past, due to the limitations of the blockchain’s table structure, building a practical DApp on-chain has not been a simple task. But even with this limitation, explorers have never stopped moving forward, and with the birth of the famous constant product pool formula “x * y = k”, Uniswap, in just a few hundred lines of code, led DeFi to revolutionize the Crypto narrative. Simple DApps can reach such heights with developer ingenuity, but what about complex DApp applications? Like building games or social platforms entirely on the chain? This may have been a crazy idea in the past, but today with Rollups opening up scalability, the possibilities are starting to become subtle.

DeFi had brought hundreds of billions of dollars in TVL to Crypto, how does a complexity-multiplying DApp accomplish that? Will it lead Crypto to a new height again? Perhaps the full chain game in the early stage of development can give us the answer. The content of this article will be from the history of the full chain game, the current definition of the full chain game, the realization of the full chain game creation and operation, and the significance of the full chain game to the future of Crypto, the four parts of the full chain game for a dissection of the full chain game.

Origins and Development of Fully On-Chain Games

The history of full-chain gaming goes back 10 years 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 an avid online following, supported by many prominent bitcointalk.org members. With a tech enthusiast’s love of video games, the most popular Huntercoin posts received over 380,000 views. Sadly however Mikhail Sindeyev passed away from a stroke in February 2014 and the development of Huntercoin fell on hard times, the token HUC went to almost zero in 2015 and although the first attempt at a full chain game didn’t work out, thankfully the story of the full chain game continues.

In 2020 Gubsheep (Brian Gu), Alan Luo, and SCOTT SUNARTO , inspired by the novel “Three Bodies: the Dark Forest”, developed a MMORTS space conquest game of the same name called “Dark Forest”. The game is built on top of Ether and writes all the rules and logic into smart contracts, i.e. every move is an on-chain transaction in a chain-wide game. The core part of the game content uses ZK-Snarks (Zero Knowledge Proof) technology to create the fog of war to reproduce the definition of the Dark Forest Laws in the Trinity novels (once a cosmic civilization is discovered, it will inevitably be struck by other cosmic civilizations).

For example, when a player wants to take an action, due to the laws of Dark Forest, the player cannot reveal their coordinates but has to move from Planet A to Planet B. They need to submit the coordinates of both A and B to prove that this is valid, but while Ether’s block information is completely transparent, Dark Forest goes about hiding the information in the following way. The player chooses the planet to leave and the destination planet, and the locations of these two planets are private information to the player. A hash of the location of the planet to leave and the destination planet is calculated, and the two hashes are then submitted to the blockchain. In this phase, the player submits a commitment (Commit phase), and due to the unidirectional nature of the hash function, these submitted hashes cannot be used to determine the player’s actual planet location. And the next phase is verification (**Reveal phase),** where players generate and submit a zero-knowledge proof that their actions are valid. This proof can be verified by anyone, but does not reveal any information about the player’s planet location.

In this way, the first full-chain game to do hidden information on the information-transparent Ether was born, a crazy and extremely thoughtful experiment that quickly caused a sensation throughout the Crypto community, with Vtalik (founder of Ether) even retweeting and praising the game directly on Twitter.

But as over 10,000 players flocked to Dark Forest after its debut, the dilemma began to emerge that Ether’s performance was not enough to support the operation of such a complex application. The game directly clogged up the entire blockchain on the day of its launch, with trillions of dollars of Gas being spent. And since the game was designed based on the library and architecture of the DeFi application, later optimization would only ease the pain and not solve the problem.

Inspired by this experiment on the future of ZK-Snarks and the dilemma of full-chain games, Brian Gu, the game’s founder, created 0xPARC as the research institute of ZK-Snarks to promote the development of zero-knowledge proofs, while Lattice, another branch of 0xPARC, is responsible for designing and maintaining the full-chain game engine, MUD. another founder, SCOTT SUNARTO, started to develop the World Engine, a sharded rollup framework for running full-chain games. SCOTT SUNARTO started to develop the World Engine, a sharded Rollup framework specialized for running full-chain games.

Zero-knowledge proofs have started to be widely used and known by all of you today, and we are going to discuss mainly the latter two, MUD Engine and World Engine, i.e. Create and Run. But before we do that we need to understand the Driver’s (0xPARC) definition and new way of perceiving full chain games.

Autonomous Worlds

Based on the ideas in the 0xPARC crypto-gaming paper collection Autonomous Worlds, full-chain games need to follow at least five criteria:

· Data from the blockchain: The blockchain is not just a secondary storage for data or a “mirror” of data stored in proprietary servers. All meaningful data is accessible on the blockchain, not just data such as asset ownership. In this way, games can take full advantage of the programmable blockchain — transparent data storage that is interoperable without permissions;

· Logic and rules are implemented through smart contracts: For example, in-game combat, not just ownership, takes place on the chain;

· The development of the game follows open ecological principles: the game contract and accessible game client are open source. Third-party developers can customize or even fork their own game experiences through plugins, third-party clients, and interoperable smart contracts that enable complete redeployment. This in turn enables game developers to leverage the creative output of the entire (incentive aligned) community;

· The game is permanently stored on the chain:This point is closely related to the three points above, because the litmus test of whether a game is crypto-native is:If the client provided by the core developers disappeared tomorrow, would the game still be playable? 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 contract without relying on the interface provided by the core team;

· Games are interoperable with things we consider valuable: the blockchain provides a native application program interface to the concept of value itself, and digital assets are by default interoperable with other assets we care about. This both reflects and helps to enhance the depth and significance of the game, and connects the game world to the “real” world.

Full-chain games built under this criterion can also be viewed as being based on the blockchain as a lower tier world, or Autonomous Worlds.

So what is the world? Worlds do not only refer to the real world; they can be carried by novels, movies, games, poems, or even legal systems. But in all of these worlds it is the center (the author, the developer, or the group) that sets the framework and rules and then communicates them to us. The degree of autonomy in these worlds also varies, for example, in [Minecraft] ( [My World] ), a very well known open-world game, players have a very high degree of autonomy, and by building different cubes, and modifying the rules, players can create worlds that are only theirs. Whereas worlds with less autonomy may be fictional worlds, such as [Harry-Potter], the magical world we see is all based on rules and frameworks created by JK Rowling.

If blockchains are taken as the substrate of the world, blockchains unambiguously preserve the set of all node entities in their state. In addition, they formally define the rules of introduction in computer code. Worlds with a blockchain substrate allow their inhabitants to participate in consensus. They run a network of computers that agree on each time a new entity is introduced.

From the world’s perspective, there are two blockchain concepts that need to be defined:.

1. Blockchain Root of State: The root of state is a compression of all entities in the world. With a state root, one can determine whether any entity is virtual or not, and believing in the state root of a world is the same as believing in the world itself.0x411842e02a67ab1ab6d3722949263f06bca-20c62e03a99812bcd15dce6daf26e Yes Jul 21, 2022 07:30:. Ether at 10PM UTC — the state root of a world with a blockchain underpinning. All entities in the Ether world are taken into account when calculating this state root. It represents the entirety of that world at that particular time.

2. Blockchain state transition functions:Each blockchain defines a state transition function. It can be thought of as an explicitly introduced rule. It defines how a previous state of the “world” — a collection of virtual entities — can be introduced into a new virtual entity through human and machine input. In the case of Bitcoin, the state transition function defines how balances are spent and transferred between addresses.

So if you think of the full-chain game as a world with the blockchain as the underlying layer, then this decentralized world has infinitely more autonomy, and can also be called an autonomous world.

The Creative Dilemma

During early explorations of new designs for full-chain games, developers were repeatedly impacted by the limitations of traditional DApp architectures and libraries used to build DeFi apps. Dark Forest and other early builds of full-chain games at the time had to follow the architectures and libraries used to build DeFi apps, and these architectures became the default choice for building full-chain games at the time.

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 may lead to data inconsistency or other problems. Sometimes Diamond Pattern is used to solve this (Diamond Pattern is a solution to the problem of multiple inheritance in Solidity smart contracts);

· Write multiple data structures: each entity (e.g. soldiers, planets, etc. in the game) has its own data structure and type;

· Write Getters function: this is a function that returns bulk elements for a data structure to get the initial state or data from a chain. For example, the getPlanets() function might return a list of all planets;

· Events: Each data structure contains an event, which is a specific feature in the smart contract that allows the app to synchronize or update the state of new blocks as they are added to the chain. For example, an event may be triggered when a new planet is created, and the app will listen to this event and update its displayed list of planets.

Building full-chain games through this model is painful, and while optimizations can be continually made to alleviate the pain, we all understand that this build is still a far cry from building with a true general-purpose engine.

Creator of Worlds — MUD Engine

The MUD engine was born out of openers thinking about the past as well as existing problems.MUD is a framework for building ethereum applications for complex applications.MUD provides conventions for organizing data and logic and abstracts away low-level complexity so that developers can focus on the functionality of the application.MUD is a framework for building ethereum applications for complex applications.MUD is a framework for building ethereum applications for complex applications. It standardizes how data is stored on the chain. With this standard data model, MUD can provide all the network code to synchronize contracts and client state.The latest version of MUD currently comes with five components:

· Store: an on-chain database;

· World: a point-of-entry framework that brings standardized access control, upgrades, and modules;

· Tools: Ultra-fast development tools based on Foundry;

· Client-side data storage: can magically reflect the state of the chain;

· MODE: A Postgres database that can be queried using SQL.

EVM full compatibility, very high degree of freedom

The versatility of MUDs doesn’t stop at the main EtherNet, as long as the language is supported, MUDs can operate seamlessly on any EVM-compatible chain, whether it’s Polygon, Arbitrum, Optimism or Gnosis Chain.

Furthermore, while MUD is the framework of choice in the Autonomous Worlds and on-chain gaming communities, its applications go far beyond that. At the same time, MUDs offer a great deal of freedom and do not force developers to be limited to a specific data model. In short, any functionality that can be realized with Solidity maps and arrays can easily be done in a MUD. And in terms of data availability, whether MUD applications are deployed on the mainnet or Rollups, they are comparable to traditional Ethernet applications such as ENS and Uniswap.

Core idea

The core idea of MUD as a set of highly collaborative libraries and tools designed for complex applications in the chain revolves around three points:

· All chained state is stored in the MUD chained database Store: Store is an embedded EVM database similar to a SQLite database with the concept of tables, columns and rows. Using Store allows for more structured data management and does not rely on the storage methods provided by the Solidity compiler. Moreover, it supports table creation at runtime and allows registering hooks to automatically create indexed views for more flexibility;

· The logic is stateless and partitioned across contracts with customized permissions: the “World” acts as an entry point to coordinate access to the “Store” by different smart contracts. When a World is deployed, it creates a Store, and each table in the Store is registered under a specific namespace. Each table in the Store is registered under a specific namespace. When functionality (such as logic for transferring money between addresses) is added to the World, it is also registered under a namespace and is called a System. These “systems” are actually smart contracts, but unlike traditional smart contracts, they are stateless and do not hold data directly. Instead, they utilize a “World Store” to read and write data. Because of this design, these “systems” can be reused across different “Worlds” as long as they are deployed on the same chain;

· No indexers or subgraphs are needed and the front-end stays synchronized: When using Store (and by extension World), the chained data is automatically introspected (Introspection, self-checking) and any changes are broadcast via standard events. The state of the chain is kept up-to-date (with milliseconds latency) by translating it to the SQL database in real-time via the “MODE” node. Additionally, MUD provides a range of querying tools such as MUD QDSL and GraphQL, making front-end synchronization even simpler. For React developers, MUD also provides specialized hooks that allow automatic binding and updating of component state.

Break through the yoke

With the three core ideas we then look at past dilemmas as an example of how MUDs can break the chains of complex applications.

· When different contracts touch the same state: Centralized management of on-chain state by using the “World” and “Store” structures. All smart contracts (referred to as “systems” in the 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 inconsistencies or conflicts. MUDs provide fine-grained access to data through namespaces and paths. Different “systems” can have different permissions, ensuring that only authorized “systems” can modify specific data or state;

· Data structure: Unlike traditional Solidity storage methods, the MUD’s “Store” provides a SQLite-like concept of tables, columns, and rows, allowing for a more structured approach to storing and managing data. Each type of entity (e.g. soldiers, planets, etc. in the game) can have its own table, and each table can have multiple columns to store different properties of that entity;

· Getters Functions: Getting data is easier and more intuitive because of the structured data storage provided by the MUD’s “Store”. Instead of writing specialized getters, developers can use SQL-like query language to get data. For example, to get all the planets, a developer can simply query the planets table instead of writing a getPlanets() function;

· Events: MUDs provide automatic introspection, which means that any data changes are automatically recognized by the system and trigger the appropriate events. Applications can listen to these events to synchronize or update their state without having to manually define events for each data structure.

The above is the basic building blocks of the MUD, part of the use of the component description, of course, the MUD can also build more complex scenarios and applications.

Run the world, World Engine

Running full-chain games has always been a huge challenge for Ether, and with the rapid development of Rollups and the approaching Cancun upgrade, costs have dropped dramatically and speeds have increased dramatically in the future. Full chain games are ready to go, but the current mainstream Rollups are basically designed for transactions, and there are no Rollups that are really tailored for full chain games.

World Engine, the core product of Argus, is a sharding architecture Rollup, which is really built for full-chain gaming. Since there is no public test yet, we will analyze World Engine from the project’s blogs and presentations.

What kind of Rollup is needed for full chain games

· High Throughput & High TPS: Faster transaction processing, lower latency, better scalability;

· Extended Reads and Writes: Most Layer2s are designed to do a lot of writes for high concurrency processing, but the game requires reads to get the player’s position, so reads are just as important as writes;

· Horizontal Scalability Chain: Horizontal scalability refers to increasing the processing power of a system by adding more nodes and resources to accommodate growing demand. This avoids the Noisy Neighbor problem (where the activities of one application or entity may negatively impact other applications or entities, leading to resource contention and performance problems);

· Flexibility and Customization: Flexibility and customizability to facilitate modifying the state machine to make it designed for games. This includes having a game loop, making it self-executing, etc;

· Tick rate: Ticks are atomic units of game time, games that want low enough latency need a higher tick rate or more blocks per second to reduce latency.

Segmented Architecture

To accomplish these goals, the team looked back to the early 21st century and the late 1990s and was inspired by the fact that online games like MMOs were just emerging. Early online games needed to find a way to support large numbers of players interacting with relatively limited server and network technology. One such solution was “sharding”, the core idea of which was to distribute players across servers or “shards”, each of which could independently host a portion of the players, game maps, and data.

For example, Ultima Online was an early MMORPG that implemented the concept of sharding on the server. Different slices of the game represent different virtual worlds, and each slice can hold a certain number of players. The benefits of this include:

· Scalability: by distributing players to different splits, the game can more easily scale to accommodate more players;

· Reduced Load: Segmentation reduces the number of players and the amount of data on a single server, which reduces the load on the server and improves performance;

· Avoiding congestion: Segmentation reduces congestion for players in the same area, providing a smoother gaming experience;

· Geolocation Optimization: By assigning players to nearby slices, network latency can be reduced and game responsiveness can be improved.

So how do you bring this concept to the World Engine? Unlike many slice-and-dice sequencers of the past, the World Engine is designed to be more tailored to specific needs. It is optimized for both throughput and runtime. It is synchronized by default to ensure efficient “tick rate” (i.e., updates per second) and block times. The design goal is to ensure that transactions are processed quickly to maintain an efficient gaming experience or system performance. A partial sort is used in the sorting method, rather than mandating a total sort of all transactions. This means that it is not required that every transaction must occur after all other transactions. This reduces the burden of sorting and thus better meets the demands of high throughput and fast block times.

There are two key components here, the EVM Base Shard and a Game Shard, the EVM Shard is the pure EVM chain, and the real secret weapon is the Game Shard, which is essentially a mini blockchain designed as a high performance server. 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 that we can customize the shard to our liking. The shard is built and injected into the base shard. Just implement a standard set of interfaces, like the familiar Cosmos, which has an IBC interface. We can basically integrate this into a similar specification to bring our own slice to the World Engine stack.

Cardinal is the first game slice implementation of the World Engine. It uses the Entity-Component-System (ECS) game architecture, a data-oriented architecture. This allows for parallelizing the game and increasing the throughput of game computations. It has a configurable “tick rate” of up to 20 ticks per second, which for this blockchain is 20 blocks per second. It is also self-indexing and does not require an external indexer.

And the sharding can also be geo-located to minimize latency. For example, the game might have sequencers in the US, and then the Asian player has to wait 300 milliseconds of latency for the transaction to reach the sequencer. This is a huge problem in games because 300 milliseconds is a long time. Trying to play an FPS game with a 200 ms delay is, basically, playing PPT.

Conclusion: Reflections on the Fully On-Chain Games

Full chain game has been a relatively cold direction in the Asian crypto circle, but with the launch of Dojo, Starknet’s game engine, and the development demo of OP Stack proof-of-concept-based ticker chain, the discussion about full chain game gradually started to heat up. And the scope of the discussion in this article is the ecosystem derived from Dark Forest, which is also the most powerful ecosystem of full-chain games at present.

By exploring its history and technology, we can find that Rollup as well as DApp still has an extremely high upper limit, and with a more far-reaching perspective, as the infrastructure is upgraded, not only games but the construction and realization of all kinds of complex ideas will be carried out through MUDs and merged and interacted with on more advanced Rollup solutions, and the new paradigm of blockchain may start from full-chain gaming.

There’s a lot more to expand on about full-chain gaming, such as the full-chain gaming ecosystem derived from Loot that drove the development of Starknet, or the implementation of state synchronization and the use of ESC architecture. I’ve listed the relevant reading links below. Those interested can check them out for more information.

About YBB

YBB is a web3 fund dedicating itself to identify Web3-defining projects with a vision to create a better online habitat for all internet residents. Founded by a group of blockchain believers who have been actively participated in this industry since 2013, YBB is always willing to help early-stage projects to evolve from 0 to 1.We value innovation, self-driven passion, and user-oriented products while recognizing the potential of cryptos and blockchain applications.

Website | Twi: @YBBCapital

References:

1: Modular Summit Day 1 (Galois Stage)

2: Lattice History

3: MUD Development Documentation

4: AUTONOMOUS WORLDS

Related reading:

1.Keeping time for the “digital gods”.

2.An article reviewing the history of the development of the full chain of games

3.How to Build a Clock Cycle for Full Chain Games with OPStack

4.The future of on-chain gaming: ‘The promise of MUD ECS engine’

5.Overview of MUDs, which support the construction of autonomous worlds, and major game projects using MUDs, such as OP Craft and Sky Strife

6.Why is the full chain game on the rise and what is its appeal?