Original author: @therealbytes @_yonada
Translation: @hiCaptainZ
Original article link: https://world.mirror.xyz/fL3IMnsOPMqQ_Td1pPEd_kYYNdWu0NW7aBDb_CwfarA
As creators of the virtual world, our goal is to create an environment that is both engaging and deeply immersive for users. This requires us to strike a balance between designing a digital physics that allows for complexity and emergent behaviors, 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 time in this world. 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 world's past, regardless of what transactions the block contains. This is known as synchronous time, or the "tick" phenomenon. This approach makes the world more engaging for users as they can see the real-time consequences of their actions. Additionally, it leads to longer times in the world, keeping the world continuously updated and facilitating the emergence of interesting behaviors.
However, this approach also has its drawbacks. Larger time spans typically 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 must be initiated by transactions from external users.
This difficulty becomes apparent when you imagine something seemingly simple: a game on the chain with non-player characters (NPCs). On the mainnet Ethereum, 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. But this may be unreliable as you cannot guarantee that the external account won't be outbid for gas fees in the block where the update should be called. The time structure of your game would drift as a result (take the example of the giveBirth() function in the original CryptoKitties; as gas fees on-chain increased, Axiom Zen actually had to 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 ticking."
Custom rollups give us more flexibility to add "ticking" functionality on-chain without the need for external accounts, and the advancement of synchronous time is guaranteed by the protocol. We call this approach "automatic ticking." Automatic ticking can be achieved by writing a "ticking contract" that is called by the protocol itself, rather than by an external account.
For example, @therealbytes developed a proof-of-concept ticking chain based on OP Stack, which runs an automatic ticking implementation of Conway's Game of Life (you can find a video demonstration of it here). Bytes used a modified system transaction to automatically call the ticking cellular automaton simulation contract. To stress test the limits of the chain itself, he implemented the game in two ways: as a Solidity smart contract running on-chain, and as a precompiled engine of the chain. The Solidity implementation reached the limit of the CPU after 70x70 grid updates per block (1 block/second, or approximately 10k cells/second), while the chain with the custom precompiled engine reached the same rate on a 256x256 grid using about 6% of the CPU (approximately 130k cells/second).
In the last sentence of the last paragraph, the keyword is "reaching the limit." The ticking chain adds an additional layer of complexity: with each block added, more states need to be touched by transactions simulating the game. Eventually, rollup nodes will be limited by the original computation (CPU, disk IO, etc.). The only solution here is to have higher-capacity nodes.
An alternative to "synchronous time" is "asynchronous time." In 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 don't involve timers fall into a similar category. Implementing asynchronous time on-chain is easier as it is the model that blockchains are designed to support. However, it also sacrifices some of the features that could make the world more interesting, such as NPCs that move automatically.
An early version of the concept game WildWood by @notdavidhuang and cha0sg0d illustrates this sacrifice. In this game, two players must defend their base from aggressive NPCs. In the early versions of the game, NPC movement was only triggered when the players themselves moved—a somewhat unrealistic implementation of asynchronous time. After adding ticking, NPC movement was introduced, but another problem remained. The chain ticks once per second, which means if a player moves more than once per second, the game has to use optimistic rollup updates to broadcast the player's position on the map. However, your teammate won't automatically see your client, which means there will be a delay in player position updates. To overcome this issue, the team utilized a MUD relay service, a peer-to-peer network for broadcasting local clients to the entire chain. Voila, the transition from asynchronous to synchronous time was achieved.
Closed and Open Forms of Laws#
World builders also have to decide whether their virtual world follows a closed form of expression or an open form of expression. Closed forms of expression have a fixed number of operations. On the other hand, open forms (or recursive) of expression have a number of operations that grow with the growth of given variables. Under open forms of expression, the future state of the world can only be computed by repeatedly applying the world's laws to known states. Complex, vibrant environments like Dwarf Fortress typically fall into this category. On the other hand, closed forms of expression allow for the computation of any future state from past states and the time that has elapsed between them (assuming no future user actions change the state), such as resource extraction rates in Age of Empires II.
Open forms can make virtual worlds more interesting as they are unpredictable, much like the real world. Predicting future states of the world requires increasing amounts of time and computational resources (a good example is the Conway's Game of Life implemented on-chain: you can't compute arbitrary future states as you need to run the game over time). Additionally, unexpected macro behaviors can emerge from simple micro interactions. In worlds governed by closed forms, these emergent behaviors typically only happen externally, through user actions (which themselves act 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 diminish the potential interest of the world, but they also make it more computationally efficient. Closed forms can be used in conjunction with synchronous or asynchronous time. When implemented on a blockchain, they have a significant advantage over open forms when time is synchronous. Since the cost of any length of time is constant, the world can be designed to only update its on-chain state when users send transactions, but it is set to the state after the elapsed time since the last update.
The Scope of Time and Form#
Consider the standard method of dynamic on-chain dynamics, a method called "lazy updating." In lazy updating, the start and end of player-initiated actions are marked, but the time in between is simulated rather than directly computed. For example, a player plants an apple tree in the first block and harvests apples in the 10th block. Lazy updating logic can be written to allow the player to harvest one apple per time unit, for a total of 9 apples. This is entirely possible for update logic with closed-form functions (like one apple per block), but it fails if agricultural logic varies based on inputs between player actions. If, for example, a rainstorm increases the growth rate of apples in the 5th block, and a locust plague nearly destroys the crop in the 7th block, then it becomes impossible to effectively compute how many apples the player can harvest in the 10th block without truly applying all the events that have occurred (you won't have enough computational power to catch up with the new state). Nonetheless, lazy updating is still useful for inexpensive computation of certain organisms (like plants with fixed growth rates), but it falls short for a complete toolbox of a dynamic world.
In the real world, time is everywhere, a one-way flow, and the universe may be infinite (though with some complexities of relativity). However, in the virtual world, this is not necessarily the case.
First, the virtual world may be explicitly finite. Interesting possibilities typically increase with size—more things happen in a world composed of two billion galaxies than in a world composed of two atoms—but the cost of computation also increases. Both of these relationships are closely related to the two trade-offs mentioned earlier: the flow of time and the physical form.
Second, time does not have to flow everywhere in the 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 areas without activity. The downside of this approach is twofold: it can make the world appear inconsistent and lacking in completeness, which limits the design space for world rules and puts pressure on world builders to avoid confusing users; and it also limits the propagation of causality within the world, as behaviors in one region may not have consequences in distant regions frozen in time. The size of the area to which 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.
To create an interesting and engaging virtual world, it is necessary to carefully balance computational efficiency and interest. 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 area to which physical laws are applied is another important decision. By making these choices thoughtfully, world builders can not only manage the computational burden of the world while maintaining interest, but also provide a highly fertile foundation for innovation for other developers.