When we describe the revolutionary impact of a product, technology, or innovation in a specific industry, we like to say it's the "iPhone moment" of that industry. This is based on the profound impact that Apple's release of the iPhone in 2007 had on the entire mobile phone and mobile computing industry.
In the DeFi industry, we refer to it as the "AMM moment". This is because the AMM model has played a crucial role in the DeFi space, particularly in improving market liquidity, directly leading to the bull market of 2021. So, what is the "AMM moment" for blockchain games? Let's explore in this article.
1 The Important Role of AMM in DeFi#
DeFi combines blockchain technology with the financial sector, incorporating financial rules into smart contracts to achieve decentralization, privacy, and automation. Since it is in the financial sector, what is most crucial for various projects is "liquidity". For example, the three major business models, lending, trading, and payments (stablecoins), cannot be sustained without liquidity.
Lending: Liquidity is the core of lending business. Banks and other financial institutions rely on short-term deposits and other sources of funds to provide long-term loans. If financial institutions cannot ensure sufficient liquidity, they may not be able to meet the loan needs of their customers or may face difficulties in repaying short-term debt. Liquidity risk is a key factor in financial crises, as banks may collapse when they cannot obtain sufficient funds to fulfill their loan commitments.
Trading: Liquidity is crucial in capital markets. High liquidity means that assets can be bought and sold quickly without losing value. If a market or asset lacks liquidity, investors may face larger bid-ask spreads or have difficulty finding buyers when they want to sell assets. This can lead to significant price fluctuations and market instability.
Payments (Stablecoins): Liquidity is essential for payment systems. When individuals or businesses need to transfer funds, they rely on efficient and reliable payment systems. If payment systems lack liquidity, it may result in payment delays or failures, affecting the functioning of the entire economy.
In Web3, transactions are at the core of financial operations, as lending and payments exist to serve transactions (leveraging and acting as a medium of exchange). So why is there an "AMM moment"? This is because the inherent performance limitations of blockchain determine it.
We know that the financial rules of centralized financial institutions are placed on their own high-performance servers, so the matching efficiency is extremely high. DeFi, on the other hand, sacrifices matching efficiency for decentralization and privacy advantages by placing financial rules in smart contracts.
Smart contracts, as a simulation of a "world computer" layer, have relatively low performance. In the initial DeFi projects, whether it is lending or exchanges, the matching was based on the traditional financial order book model. In this model, DeFi had no chance against CeFi until the emergence of AMM.
How to use the low-performance "world computer" to greatly improve the matching efficiency of liquidity? The solution provided by the AMM model is to use liquidity pools and algorithms for automatic matching. There have been many articles explaining the specific gameplay, so we won't go into detail here. In terms of advantages, we now know:
No need for traditional market makers: In traditional financial markets, market makers usually need to provide quotes for buy and sell orders to ensure market liquidity. The AMM model allows liquidity providers to deposit funds into a smart contract, which automatically adjusts prices and executes transactions based on a predetermined algorithm, eliminating the need for traditional market makers.
Liquidity pools: Liquidity pools in the AMM model provide traders with a constantly available counterparty. Liquidity providers can deposit funds into these pools and receive transaction fees as rewards, incentivizing more people to participate and increasing market liquidity.
Reduced trading friction: Due to the automation of AMM, traders can trade at any time without waiting for traditional buy and sell order matching, reducing trading friction.
Driving DeFi innovation: The AMM model has brought many new innovations to the DeFi space, such as liquidity mining and dual-token liquidity pools. These innovations further drive the development and popularization of DeFi.
The innovation of the AMM mechanism has enabled the matching efficiency of DeFi's liquidity to be comparable to CeFi, ultimately leading to DeFi Summer.
2 The Fundamental Contradiction Between Games and Blockchain#
Now, blockchain games are facing the same moment as DeFi: how to run a game on a low-performance "world computer"? This requires a deep analysis of the fundamental contradiction between games and blockchain.
I have written an article titled "What is the difference between the ARC and ECS architectures in blockchain games?" in which I introduced the concept of game loops and pointed out that traditional games are loop-based.
Traditional games are loop-based because their core mechanism is the game loop. The game loop is a repetitive process that typically includes handling user input, updating game state, and rendering the game world. This loop continues throughout the game runtime, usually running tens to hundreds of times per second to maintain the smoothness of the game world. In this architecture, game systems such as physics engines and AI systems check and process the game entities and components they care about in each loop.
However, blockchain architecture is push-based. Blockchain is a distributed database that shares and stores information among nodes in the network. When a node generates a new transaction, such as a transfer or contract call, the transaction is pushed to the network, and other nodes in the network receive and verify the transaction before adding it to the blockchain. This is a passive process where nodes do not actively search for new transactions but wait for other nodes in the network to send new transactions. Therefore, the architecture of blockchain is called push-based.
In fact, this paragraph has already answered the previous question. Game architecture is generally loop-based, while blockchain architecture is push-based, which is the fundamental contradiction between games and blockchain. So how can we solve this contradiction? It can be said that as long as this contradiction is resolved, it will usher in the "AMM moment" of blockchain games.
To delve deeper into the discussion, let's take a look at how games implement game loops.
Every game consists of a sequence of acquiring user input, updating game state, handling AI, playing music and sound effects, and displaying the game. This sequence is handled through the game loop. For the purpose of this discussion, we will focus solely on the game loop itself and simplify the tasks to only updating and displaying the game. Here is an example code of the simplest form of a game loop:
bool game_is_running = true;
while (game_is_running) {
update_game();
display_game();
}
Let's introduce three terms:
Tick: Tick is synonymous with the game loop, 1 tick = 1 game loop.
FPS: FPS stands for Frames Per Second. In the context of the implementation above, it is the number of times display_game() is called per second.
Game Speed: Game speed is the number of times the game state is updated per second, or in other words, the number of times update_game() is called per second.
In summary, Tick/Game Loop is the basic cycle of the game, determining how the game logic is updated. FPS is the number of frames rendered per second, determining the visual smoothness of the game. Game speed is how the game logic progresses, usually equal to the tick rate. Ideally, the tick rate, FPS, and game speed should all be equal, meaning there is a corresponding render after each logic update. However, in practice, these three may differ, especially in cases of performance limitations or other technical constraints.
3 The Core Challenges of Blockchain Games#
With the understanding above, we can now discuss the core challenges of blockchain games.
Mismatch between game loop and blockchain: Traditional games are based on the game loop, which means the game state is updated in every tick or frame. However, blockchain is event-driven, and the state is only updated when there are new transactions or operations. This fundamental mismatch does make it complex to implement traditional game loops in blockchain games.
Latency and Real-time: The confirmation time of blockchain transactions can cause response latency in games, which is a problem for games that require quick response, such as action games or competitive games. An effective ticking mechanism needs to consider this latency and minimize its impact on the gaming experience.
Resource Constraints and Computational Costs: Updating the state of the blockchain consumes computational resources and may incur costs. In blockchain games, frequent state updates can result in high costs. Therefore, an efficient ticking mechanism is needed to balance game smoothness and costs.
If a new ticking mechanism or game loop model that adapts to the characteristics of blockchain can be developed, it would indeed be an "AMM moment" for blockchain games. This may require a combination of traditional game development techniques and the characteristics of blockchain to create a new game framework.
Does this mean that all game types are loop-based? While most game types are indeed loop-based, there are also some "push-based" games that do not require continuous, real-time state updates. For example, turn-based strategy games, board games, or certain card games. In these games, the state is only updated when players take actions, which is more similar to the event-driven model of blockchain. Therefore, for blockchain games, it is indeed possible to consider developing games that align more naturally with the "push-based" model, which can better adapt to the characteristics of blockchain.
4 Ticking Chain is the AMM Moment for Blockchain Games#
Scott, the founder of Argus, has expressed a similar view:
Games operate on a loop-driven runtime. Even without user input, state transitions continue to occur. Fire keeps burning, water keeps flowing, crops keep growing, and the cycle of day and night continues.
So how can we design a ticking mechanism suitable for blockchain? @therealbytes provides the answer. I have translated his classic article "How to Build a Clock Cycle for On-Chain Games Using OPStack" before, in which he explains in great detail how to use smart contracts and precompiled contracts to construct a ticking system. Unfortunately, due to its technical nature, this article has the lowest number of views among all my articles. Similar to Vitalik's classic article on introducing AMM in DEX, "Let's run on-chain decentralized exchanges the way we run prediction markets", which introduced the famous constant product formula "A * B = k".
In this article, therealbytes proposed using the precompiled ticking function of the OPStack to achieve ticking optimization. Ticking-Optimism modified the rollup node and created a "tick transaction" that works the same way as a "deposit transaction" but instead of setting L1 attributes, it calls the tick() function in a contract pre-deployed to address 0x42000000000000000000000000000000000000A0. This contract can invoke another contract by setting its target variable.
By embedding the ticking function into the node of the chain, it greatly improves the efficiency of the loop. This can be compared to the AMM model's significant improvement in matching efficiency compared to the order book model in the DeFi industry. How significant is it? The data can be found in another article I translated, "Keeping Time for the 'Digital Gods'":
To fully test the limits of the chain itself, he implemented the game in two ways: one as a Solidity smart contract running on-chain, and the other as a precompiled contract of the chain. The Solidity implementation reached the CPU limit (1 block/second, or approximately 10k cells/second) after reaching a 70x70 grid with updates twice per block, while the custom precompiled engine reached the same rate with a 256x256 grid at approximately 6% CPU usage (approximately 130k cells/second).
5 Conclusion#
If we say that the AMM model ensures that the financial system can have high matching efficiency and liquidity on a low-performance blockchain, then the Ticking Chain ensures that the game system can have high loop efficiency and smoothness on a low-performance blockchain.
The above introduction was only a proof of concept by therealbytes, but in practice, there are already blockchain game engines starting to use this ticking mechanism. The first open-source Ticking Chain engine is developed by @0xcurio, which uses the OPStack with precompiled ticking functions to build layer2. The second open-source Ticking Chain engine is developed by @ArgusLabs_, which uses Polaris to construct layer2 with precompiled ticking functions. I believe there will be more Ticking Chains in the future.
The table above compares the applications of blockchain in the financial and gaming industries, showing that there is indeed a great similarity between the two. DeFi initially used the Orderbook model, which is an active matching system, and after adopting the AMM model, it became a passive automatic matching system. Similarly, in blockchain games, the initial approach was "lazy update" and "manual ticking" for active game loops, but after the introduction of precompiled Ticking Chains, it became a passive automatic game loop. AMM improves financial liquidity, while Ticking Chain improves game smoothness.