Building a Virtual World How to Use Blockchain Technology to Record Time for Digital Gods?

Using Blockchain to Record Time for Digital Gods in a Virtual World

Original Article: https://world.mirror.xyz/fL3IMnsOPMqQ_Td1pPEd_kYYNdWu0NW7aBDb_CwfarA

Translation: Justin @captainz

As creators of the virtual world, our goal is to create an environment that is interesting and deeply engaging for users. This requires us to find a balance between designing a digital physics that allows for complexity and unexpected behaviors to emerge, and ensuring that the existing infrastructure can support these behaviors. To do this, we need to consider three main dimensions of digital physics: time, the form of its laws, and the scope to which these laws apply.

Time

We refer to the passage of time in the virtual world as the application of the world’s laws to itself. Each discrete application is a “moment” in the flow of world time. One way to design time in the world is to have it progress continuously with external time. In a blockchain-based virtual world, each block corresponds to a certain number of moments in the past of the world, regardless of what transactions the block contains. This is known as synchronized time, or the “tick-tock” phenomenon. This approach makes the world more interesting for users as they can see the real-time results of their actions. Additionally, it leads to longer periods of time in the world, allowing for the emergence of interesting behaviors.

• Bitcoin Technology Revival? A Comprehensive Review of the Ordinals Series Protocols
• Reasons for the decline of ICP Independent technology and sparse ecosystem
• How will the metaverse truly land? Futureverse raises $54 million to focus on digital infrastructure

However, this approach also has its drawbacks. Larger time frames often require more computational resources, which may quickly exceed the capacity of the chain or servers. Implementing this system on a regular blockchain can also be challenging as all changes on the chain need to be initiated by transactions from external users.

This difficulty becomes apparent when considering something seemingly simple, like non-player characters (NPCs) in a blockchain-based game. On the main Ethereum network, you could define an update function that sets the positions of each NPC on the game map and have an external account call it periodically to update their positions. However, this may not be reliable as you cannot guarantee that the external account will not be outbid due to gas fees in the block where the update should be called. The time structure in your game would drift as a result (as exemplified by the giveBirth() function in the original CryptoKitties; with the increase in on-chain gas fees, Axiom Zen had to actually increase the reward for calling the giveBirth function to ensure that the transaction for the birth of a new NFT is called within 256 blocks after the user breeds the Kitty). We refer to this approach of using external accounts as “manual tick-tock”.

Custom rollups give us more flexibility to add “tick-tock” functionality on-chain without the need for external accounts, and the progression of synchronized time is ensured by the protocol. We refer to this approach as “automatic tick-tock”. Automatic tick-tock can be implemented by writing a “tick-tock contract” that is called by the protocol itself, rather than by an external account.

For example, @therealbytes has developed a proof-of-concept tick-tock chain based on OP Stack, which runs an automatic tick-tock implementation of Conway’s Game of Life (you can find a video demonstration of this here). Bytes uses a modified system transaction to automatically call a tick-tock cellular automaton simulation contract. To fully test the limits of the chain itself, he implemented the game in two ways: as a Solidity smart contract running on the chain, and as a pre-compiled engine of the chain. The Solidity implementation maxed out the CPU at a rate of 1 block/second, or about 10k cells/second, after reaching a 70×70 grid with two updates per block. Meanwhile, the custom pre-compiled engine of the chain reached the same rate with a 256×256 grid using about 6% of the CPU, or about 130k cells/second.

In the last sentence of the last paragraph, the keyword is “reaching the limit”. TickChain adds an additional level of complexity: with each added block, more states need to be touched by transactions that simulate gameplay. Eventually, rollup nodes will be limited by the original computation (CPU, disk IO, etc.). The only solution here is to use higher-capacity nodes.

The alternative to “synchronous time” is “asynchronous time”. Under this scheme, the passage of time in the world does not necessarily progress when external time advances. Instead, time typically moves forward when certain events (usually user actions) occur. Traditional board games that do not involve timers fall into a similar category. Implementing asynchronous time on the chain is easier because it is a model that the blockchain is designed to support. However, it also sacrifices some features that could make the world more interesting (such as automatically moving NPCs).

A early version of the concept validation game WildWood, by @notdavidhuang and cha0sg0d, revealed this sacrifice. In this game, two players must defend their base from aggressive NPCs. In the early version of the game, NPC movement was only triggered when the player moved themselves – this was an unrealistic implementation of asynchronous time. After adding TickChain, NPC movement occurred, but another problem still existed. The chain ticked once per second, which meant that if a player moved more than once per second, the game had to use optimistic rollup updates to broadcast the player’s position on the map. However, your teammate would not automatically see your client, which meant there would be a delay in player position updates. To overcome this issue, the team utilized a MUD relay service, a peer-to-peer network used to broadcast local clients to the entire chain. And voila, the transition from asynchronous time to synchronous time was achieved.

The Laws of Closed and Open Forms

World builders must also decide whether their virtual world follows a closed form expression or an open form expression. A closed form expression has a fixed number of operations. However, the number of operations in an open form (or recursive) expression grows with the growth of the given variables. Under an open form expression, the future state of the world can only be calculated by repeatedly applying the laws of the world to known states. Complex, vivid environments, like Dwarf Fortress, usually fall into this category. On the other hand, a closed form expression allows for the calculation of any future state based on past states and the elapsed time between them (assuming no future user actions change the state), such as the resource extraction rate in Age of Empires II.

Open forms can make virtual worlds more interesting because, like the real world, they are unpredictable. Predicting the future state of the world requires more and more time and computational resources (the Conway’s Game of Life implemented on-chain is a good example: you cannot calculate any future state because you need to run the game in time steps). Additionally, unexpected macro behavior can emerge from simple micro interactions. In a world governed by closed forms, these emergent behaviors usually only occur externally, through user actions (which themselves are like open forms), rather than within the physical world itself.

The trade-off between open and closed forms involves a balance similar to that of time. Closed forms may reduce the potential interest of the world, but they also make it more computationally efficient. Closed forms can be used with either synchronous or asynchronous time. When implemented on a blockchain, they have significant advantages over open forms when it comes to time synchronization. Because the cost of any length of time is constant, the world can be designed to update the on-chain state only when users send transactions, but it is set to the state after the elapsed time since the last update.

Scope of Time and Form

Consider the standard method of dynamic on-chain updates, a method called “lazy update.” In lazy update, the start and end of a player’s action are initiated, but the time in between is simulated rather than computed directly. For example, a player plants an apple tree in the first block and harvests the apples in the tenth block. Lazy update logic can be written to allow the player to harvest one apple per time unit, for a total of nine apples. This is entirely feasible for update logic with closed-form functions, such as one apple per block, but it fails if the agricultural logic varies based on inputs between player actions. If, in the fifth block, a heavy rain increases the apple’s growth rate, and in the seventh block, a locust plague nearly destroys the crops, the number of apples the player can harvest in the tenth block cannot be effectively calculated unless all events that have occurred are truly applied (you won’t have enough computational power to catch up with the new state). Nevertheless, lazy update is still very useful for inexpensive calculations of certain entities, such as plants with fixed growth rates, but it is still insufficient for a complete toolbox in a dynamic world.

In the real world, time is everywhere, flowing continuously, and the universe may be infinite (although there are complexities in relativity). However, in virtual worlds, this is not necessarily the case.

First, virtual worlds can be clearly finite. Interesting possibilities usually increase with size – there are more things happening in a world composed of two billion galaxies than in a world composed of two atoms – but computational costs also increase. Both of these relationships are closely related to the two trade-offs mentioned earlier: the flow of time and physical form.

Second, time does not have to flow everywhere in a virtual world. The world can be divided into discrete regions with different rates of time flow to reduce the computational burden of the world. For example, more complex and expensive physical rules can be used in areas with user activity, while simpler physical rules can be used in inactive areas. The drawback of this approach is twofold: it may make the world inconsistent and lacking in completeness, which limits the design space of world rules and puts pressure on world builders to avoid confusing users; at the same time, it also restricts the propagation of causality within the world, freezing the space between two regions in time if the behavior in one region cannot have consequences in a distant region. The size of the area where physical rules are applied is an important design consideration that will affect the resources the world needs and the level of interest it can achieve.

In order to create an interesting and attractive virtual world, it is necessary to carefully balance computational efficiency and fun. This includes deciding what type of time to use (synchronous or asynchronous) and evaluating the form of the physical laws that govern the world. The size of the region where the physical laws apply is another important decision. By making these choices carefully, world builders can not only maintain the computational burden of the world in a manageable way, but also provide a highly fertile foundation for innovation for other developers.

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