How to use OPStack to build the clock cycle of a full-chain game?
Using OPStack to build a full-chain game clock cycle
Generally speaking, games are loop-based systems. The game loop is a repetitive process that typically includes handling user input, updating the game state, and rendering the game world. This loop continues throughout the duration of the game, usually running tens to hundreds of times per second to maintain smooth gameplay.
However, blockchain architecture is push-based. Blockchain is a distributed database that shares and stores information among nodes in a network. When a node generates a new transaction (such as a transfer or contract invocation), the transaction is pushed to the network, and other nodes receive and validate it before adding it to the blockchain. This is a passive process, where nodes do not actively search for new transactions but rather wait for them to be pushed by other nodes in the network. Therefore, blockchain architecture is referred to as push-based.
Therefore, implementing a loop-based system with a clock cycle in a fully on-chain game becomes very important. After all, in the so-called “autonomous world,” we want certain NPCs or virtual environments to evolve automatically over time, rather than passively evolving based on transactions pushed to the blockchain.
@therealbytes has developed a proof-of-concept ticking chain based on the OP Stack. It runs an automated ticking implementation of Conway’s Game of Life. Let’s delve into how he achieved this.
For the sake of simplicity in translation, we will translate “tick” as “滴答,” meaning “clock cycle.”
- The Golden Key to the Whole-chain Game Arcade Account
- Reflecting on the Bybit compensation incident, what kind of financi...
- An In-depth Analysis of LianGuairadigm, the Top Cryptocurrency Vent...
Ticking-Optimism is a proof-of-concept implementation of a “ticking blockchain” based on the Optimism Bedrock rollup architecture.
In the ticking chain, there is a special smart contract called the “ticking contract,” which is automatically invoked by the protocol for every block. This allows other smart contracts to be triggered automatically at specific times or intervals without the need for users to send transactions.
How it works
Optimism’s new modular rollup architecture, Optimism Bedrock, introduces a new transaction type called a “deposit transaction.” Unlike regular transactions, deposit transactions:
– Come from Layer 1 blocks.
– Do not require signature verification.
– Purchase gas on L1 for L2, so L2 gas is non-refundable.
In the original Bedrock, deposit transactions are used for two things:
– Executing transactions directly sent to L1.
– Setting L1 properties (number, timestamp, hash, etc.) for pre-deployed L2 contracts in each block.
In the latter case, the transaction is created by the rollup node. It doesn’t pay 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 similarly but instead of setting L1 properties, it calls the tick() function in a contract deployed at address 0x42000000000000000000000000000000000000A0. This contract can call another contract by setting its target variable.
Motivation
To illustrate the power of Tick-tock Chain, imagine a game on a blockchain where multiple non-player characters (NPCs) move on a map. Without Tick-tock 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 the chain when the user sends transactions to interact with them. Then, the contract calculates the new positions of NPCs based on their last chain update and the number of blocks passed since then.
– Manual ticking. We define an update function that sets the positions of each NPC on the map and have an external account call it periodically.
With Tick-tock Chain, the solution is similar to manual ticking, but the Tick-tock contract automatically calls the update function instead of manual invocation.
The advantages of using “automatic ticking” with Tick-tock Chain instead of manual ticking are:
– Updates are guaranteed by the protocol.
– Updates are executed before all transactions in a block and cannot be front-run because it is part of the protocol itself.
– Update transactions do not participate in the regular gas market.
However, automatic ticking requires a customized blockchain. If the update rate is the same, both manual and automatic ticking have the same computational resource requirements for nodes. On the other hand, lazy updating is usually cheaper because it involves smaller and fewer updates on the chain.
In addition, as the state that needs to be updated grows, the computational cost of tick transactions also increases. This puts additional pressure on developers to design their applications in a way that ensures costs never exceed what the chain can support.
Despite these drawbacks, automatic ticking is more suitable than lazy updating for certain types of applications.
1. State is always explicitly on-chain and up-to-date
Tick-tock allows smart contracts to access a dynamic state with a constant cost that updates using open-form expressions.
The state (in the example above, the positions of NPCs) can always be read on-chain with a constant and relatively low gas cost. However, the cost of computing the current state increases significantly when the number of blocks passed since the last update increases.
If we are updating the position of an entity moving at a constant rate, we can calculate where it should be in any given block from its last set position and the number of blocks passed since the update. The cost of this operation does not increase with the number of blocks between updates.
On the other hand, if the state we are updating is something like Conway’s Game of Life (or a three-body gravity simulation), the cost of updating grows linearly with the number of steps since the last update. This is a problem as it can grow beyond what users are willing to pay or what the chain can support.
2. Different roles for clients
With lazy updating, the update logic needs to be implemented in both the smart contract and the client. With Tick-tock Chain, it only needs to be implemented on the blockchain, and the client can simply react to on-chain events.
3. Simpler and easier code review
Lazy updates cause developers to scatter their update logic across many functions and smart contracts, with each function triggered only when certain transactions are executed. In contrast, ticking methods only require one update function that is guaranteed to be triggered periodically. The latter makes it easier to maintain consistency and integrity of the state.
In addition, every time a new lazy update state is added (e.g., a new type of NPC), all update functions may need to be modified to accommodate it. This makes the codebase more complex and prone to issues.
4. Users do not pay for update costs
The cost of lazy updates often varies greatly, and users can structure their transactions to shift most of the burden of updates onto others. With ticking, the costs of all operations are relatively stable and less susceptible to MEV attacks.
Conway’s Game of Life Demo
I have built a ticking chain demo that runs an interactive version of Conway’s Game of Life. The chain has been modified, including the cellular automata logic in the execution engine, to make it more efficient and allow for larger game boards than what can be achieved with smart contract bytecode implementation.
Source code for the demo: https://github.com/therealbytes/ticking-conway
Demo video: https://www.youtube.com/watch?v=za12aa5FS6E&list=PL_97Yn8lCzTI_P_4vO1HEXA9k6gF6lawF&index=11
