How to use OPStack to build the clock cycle of the full chain game?

Author: Gametaverse

In general, games are loop-based. A game loop is an iterative process that typically consists of processing user input, updating game state, and rendering the game world. This loop continues while the game is running, typically running tens to hundreds of times per second to keep the game world flowing.

However, the architecture of the blockchain is push-based. Blockchain is a distributed database that shares and stores information through nodes in the network. When a node generates a new transaction (such as transfer, contract call, etc.), the transaction will be pushed to the network, and other nodes will verify it and add it to the blockchain after receiving the transaction. This is a passive process, nodes will not actively search for new transactions, but wait for other nodes in the network to send new transactions. Therefore, the architecture of the blockchain is said to be push-based.

Therefore, it is very important to implement a cycle system with clock cycles in the full-chain game. After all, in the so-called "autonomous world", we all hope that some NPCs or virtual environments can automatically evolve over time, instead of passively evolving following transaction inputs pushed to the blockchain.

@therealbytes developed a proof-of-concept tick chain (chain with clock cycles) based on the OP Stack, which runs an automatic tick-tick implementation of Conway's Game of Life, let's see how he implemented it.

To keep the translation simple, we literally translate tick into "tick", which means "cycle clock cycle".

Ticking-Optimism is a proof-of-concept implementation of the "Ticking Blockchain" based on the Optimism Bedrock rollup architecture.

In the tick chain, there is a special smart contract called "tick contract", and each block will be automatically called by the protocol. This allows other smart contracts to automatically trigger at specific times or intervals without requiring users to send transactions.

How to achieve

Optimism's new modular rollup architecture, Optimism Bedrock, introduces a new transaction type called a "Deposit Transaction". Unlike regular transactions, deposit transactions:

• Blocks from Layer 1.

• No signature verification required.

• Purchase L2 gas on L1, so L2 gas is non-refundable.

In the original Bedrock, deposit transactions were used for two things:

• Execute transactions sent directly to L1.

• Set L1 properties (number, timestamp, hash, etc.) for pre-deployed L2 contracts in each block.

In the latter case, transactions are created by rollup nodes. It does not pay for gas, and the gas used is not deducted from the gas pool.

Ticking-Optimism modifies the rollup node and also creates a "tick transaction" that works the same way, but instead of setting the L1 property, it calls the tick() function in the contract pre-deployed to address 0x42000000000000000000000000000000000000A0. This contract can call another contract by setting its target variable.

Motivation

To illustrate the power of tickchains, imagine a game on the blockchain where multiple NPCs (non-player characters) move around the map. Without a tick chain, we have two main design approaches:

• Lazy updating. On the client side, NPCs appear to move continuously, but their positions are only updated on-chain when users send transactions to interact with them. The contract then calculates the NPC's new location based on its last on-chain update and the number of blocks that have passed since then.

• Manual ticking. We define an update function that sets the position of each NPC on the map, and have an external account call it periodically.

With a tickchain, the solution is similar to manual ticking, but the tick contract calls the update function automatically instead of manually.

The advantages of using the "auto-tick" of the tick chain instead of manual ticks are:

• Updates are guaranteed by agreement.

• The update will be performed before all transactions in the block and cannot be fronted as it is part of the protocol itself.

• Update transactions do not participate in the regular gas market.

However, automatic ticks require a custom blockchain. If the update rate is the same, manual and automatic ticking require the same computing resources on the node. Lazy updates, on the other hand, are usually cheaper because on-chain updates are smaller and less frequent.

Additionally, the computational cost of tick transactions increases as the state that needs to be updated grows. This puts additional pressure on developers to design their applications such that costs never exceed what the chain can support.

Despite these huge drawbacks, automatic ticks are better suited than lazy updates for certain types of applications.

1. State is always explicitly on-chain and up-to-date

Ticks enable smart contracts to access, at constant cost, a dynamic state that is updated using open-form expressions.

The state (in the example above, the NPC's location) is always readable on-chain at a constant, relatively low gas cost. But the cost of calculating the current state will increase with the number of blocks since the last update, and the gas cost will increase more.

If we are updating the position of an entity moving at a constant velocity, we can calculate where it should be in any given chunk from its last set position and the number of chunks since the update. The cost of this operation does not grow with the number of blocks between updates.

On the other hand, if the state we update is something like Conway's Game of Life (or a three-gravity simulation), the cost of updating grows linearly with the number of steps since the last update. This is a problem because it can grow beyond what users are willing to pay or what the chain can support.

2. Different functions of clients

With lazy updates, the update logic needs to be implemented in both the smart contract and the client. With ticking, it only needs to be implemented on the blockchain, and clients can simply react to on-chain events.

3. The code is simpler and easier to review

Lazy updates allow developers to spread their update logic across many functions and smart contracts, with each function only being triggered when certain transactions are executed. In contrast, the tick-tick approach requires only an update function that is guaranteed to fire periodically. The latter makes it easier to maintain state consistency and integrity.

Also, every time a new lazy update state is added (for example, a new type of NPC), all update functions may need to be modified to account for it. This makes the code base more complex and prone to problems.

4. Users do not pay the update cost

The cost of lazy updates often varies widely, and users can craft their transactions so that most of the burden of updates falls on others. With ticks, the cost of all operations is relatively stable and not vulnerable to MEV attacks.

Conway's Game of Life Demo

I built a tickchain demo that runs an interactive version of Conway's Game of Life. The chain has been modified to include cellular automaton logic in the execution engine, making it more efficient, allowing for a larger game board than could be implemented as smart contract bytecode.

The source code of the demo:

Demo video: