Dida Chain The ‘AMM Moment’ of Full-chain Gaming

Dida Chain The 'AMM Moment' in Full-Chain Gaming.

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 plays a crucial role in the DeFi field, especially in improving market liquidity, directly contributing to the bull market in 2021. So, what is the “AMM moment” for blockchain games? Let’s explore in this article.

1. The Importance of AMM in DeFi

DeFi combines blockchain technology with the financial sector, which means incorporating financial rules into smart contracts to achieve decentralization, privacy, and automation. Since it is related to the financial sector, what is most crucial for various projects? Clearly, it is “liquidity.” For example, the three major business models – lending, trading, and payment (stablecoin business) – cannot be sustained without liquidity.

1. 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 customer loan demands 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.
2. Trading: In the capital market, liquidity is key to trading. High liquidity means 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.
3. Payment (stablecoin): Liquidity is crucial for payment systems (stablecoins). When individuals or businesses need to transfer funds, they rely on efficient and reliable payment systems. If a payment system (stablecoin) lacks liquidity, it may result in payment delays or failures, impacting the overall functioning of the economy.

In Web3, trading is the core of financial transactions because lending and payment exist to serve trading (leveraging and acting as a medium of exchange). So why is there an “AMM moment”? This is because it is determined by the inherent performance limitations of blockchain.

• Exploring THORChain’s lending module Revealing the hidden impact of Terra LUNA.
• Interpreting the Road to Web3 Gold Mining in the Central African Republic
• Quick look at the Jackson Hole annual meeting Powell maintains possibility of raising interest rates, Lagarde says rates will be kept at necessary high levels to control inflation.

We know that centralized financial institutions have their financial rules on high-performance servers, so their matching efficiency is extremely high. On the other hand, DeFi sacrifices matching efficiency for the advantages of decentralization and privacy by putting financial rules into smart contracts.

Smart contracts, as a simulation of the “world computer” layer, have relatively poor performance. In the initial DeFi projects, whether it is lending or exchanges, the matching is based on the traditional financial order book model. In this model, DeFi is powerless against CeFi until the emergence of AMM.

How to use the ultra-low-performance “world computer” to greatly improve the efficiency of liquidity matching? The solution of the AMM model is to use a liquidity pool and algorithms for automatic matching. There have been many articles introducing the specific gameplay, so we will not discuss it further here. As for the advantages, we now know:

1. 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 according to a predetermined algorithm, eliminating the need for traditional market makers.
2. Liquidity pool: The liquidity pool in the AMM model provides traders with a constantly available counterparty. Liquidity providers can deposit funds into these pools and receive transaction fees as rewards, thereby incentivizing more people to participate and increasing market liquidity.
3. Reduced transaction friction: Due to the automation of AMM, traders can trade at any time without waiting for traditional matching of buy and sell orders, reducing transaction friction.
4. Driving DeFi innovation: The AMM model has brought many new innovations to the DeFi field, such as liquidity mining and dual token liquidity pools. These innovations further promote the development and popularization of DeFi.

The innovation of the AMM mechanism has actually enabled the liquidity matching efficiency of DeFi to be comparable to CeFi, ultimately leading to DeFi Summer.

II. What is the fundamental contradiction between games and blockchain?

Now, full-chain games have come to the same moment as DeFi: how to run a game on an extremely low-performance “world computer”? This requires a deep analysis of the fundamental contradiction between games and blockchain.

I once wrote an article titled “What is the difference between the full-chain game engine architecture ARC and ECS?”, 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 process that continuously repeats, usually including handling user input, updating game state, and rendering the game world. This loop continues to run during the game to maintain the smoothness of the game world, usually running dozens to hundreds of times per second. In this architecture, game systems (such as physics engines, AI systems, etc.) check and process the game entities and components they care about in each loop.

However, the architecture of blockchain 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 a contract call), this transaction is pushed to the network, and other nodes receive and verify it 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 them. Therefore, the architecture of blockchain is referred to as push-based.

In fact, this paragraph has already answered the previous question. The architecture of games is generally loop-based, while the architecture of blockchain is push-based, which is the fundamental contradiction between games and blockchain. So how to solve this contradiction? It can be said that as long as this contradiction is resolved, the “AMM moment” of full-chain games will be ushered in.

For a deeper discussion, let’s take a look at how games implement game loops.

Each game includes a sequence of obtaining user inputs, updating game states, handling AI, playing music and sound effects, and displaying the game. This sequence is handled through the game loop. We won’t discuss any of the above tasks in detail for now, but focus on the game loop itself, so the tasks can be simplified to just two functions: updating the game and displaying the game. Here is an example code for 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 a synonym for game loop, 1 tick = 1 game loop

FPS

FPS stands for Frames Per Second. In the context of the above implementation, 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 updates. FPS is the number of frames rendered per second, determining the visual smoothness of the game. Game speed is how the game logic progresses and is usually equal to the tick rate. Ideally, the tick rate, FPS, and game speed should all be equal, which means there is a corresponding rendering after each logic update. However, in reality, these three may differ, especially in cases where performance is limited or there are other technical restrictions.

Three, the core challenges of full-chain games

With the understanding above, we can now discuss the core challenges in full-chain games.

1. Mismatch between game loop and blockchain: Traditional games are based on game loops, which means the game state is updated in each tick or frame. However, blockchain is event-driven and only triggers state updates when there are new transactions or operations. This fundamental mismatch indeed makes it complex to implement traditional game loops in full-chain games.

2. Delay and Real-time: The transaction confirmation time of blockchain may cause response delay 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 delay and minimize its impact on the gaming experience.

3. Resource Limitations and Computational Costs: Updating the state of the blockchain consumes computational resources and may incur costs. In a full-chain game, frequent state updates may result in high costs. Therefore, an efficient ticking mechanism is needed to balance game smoothness and cost.

If a new ticking mechanism or game loop model that adapts to blockchain characteristics can be developed, it would indeed be an “AMM moment”. This may require combining traditional game development technologies with blockchain characteristics to create a brand-new game framework.

So, are all game types loop-based? While most game types are indeed loop-based, there are also “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 action, which is more similar to the event-driven model of blockchain. Therefore, for full-chain games, it is indeed possible to consider developing games that better fit the “push-based” model first, so as to naturally adapt to the characteristics of blockchain.

IV. TickChain is the AMM moment of full-chain games

Scott, the founder of Argus, has expressed a similar view:

Games operate in a loop-driven runtime. Even without user input, state transitions continue to occur. Fire continues to burn, water continues to flow, crops continue to grow, and day and night cycle continues.

So, how can we design a ticking mechanism suitable for blockchain? @therealbytes has provided an answer. I have translated his classic article “How to Build Clock Cycles for Full-Chain Games Using OPStack” before, which provides detailed explanations on how to construct a ticking system using smart contracts and precompiled contracts. However, unfortunately, due to its technical nature, this article has the lowest number of views among all of my articles. Similar to Vitalik’s classic article “Let’s run on-chain decentralized exchanges the way we run prediction markets,” which introduced the famous constant product formula “A * B = k” for the first time.

(An interesting point: at that time, there was no term “DeFi,” it was simply called On-chain decentralized exchange, just like how we now refer to full-chain games as On-chain games)

In this article, therealbytes should be the first to propose using the precompiled contracts of the chain itself to achieve ticking: Ticking-Optimism modified the rollup node and created a “tick transaction,” which 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 the address 0x42000000000000000000000000000000000000A0. This contract can call another contract by setting its target variable.

Embedding the Ticking function into the nodes of the blockchain is a huge improvement in terms of loop efficiency. This can be completely compared to the significant improvement in matching efficiency between the AMM model and the Orderbook model in the DeFi industry. How significant is it? You can refer to the data in another article I translated, “Timing for the “Digital God”.”

In order to fully test the limits of the blockchain itself, he implemented the game in two ways: one as a Solidity smart contract running on the chain, and the other as a pre-compile of the chain itself. The Solidity implementation reached its limit when it updated a 70×70 grid twice per block, pushing the CPU to its limit (1 block/second, or approximately 10k cells/second). The chain with the custom pre-compiled engine reached the same rate with a 256×256 grid at approximately 6% CPU usage (approximately 130k cells/second).

Summary

If the AMM model ensures high matching efficiency and liquidity for financial systems on low-performance blockchains, then the Ticking Chain guarantees high loop efficiency and smoothness for game systems on low-performance blockchains.

The above is just a proof of concept by therealbytes, but there are already full-chain game engines that have started using this Ticking Chain model in practice. The first open-source Ticking Chain engine is @0xcurio, which uses the OPStack with the pre-compiled ticking function to build layer2. The second open-source Ticking Chain engine is @ArgusLabs_, which uses Polaris to build layer2 with the pre-compiled ticking function. I believe there will be more Ticking Chains in the future.

The table above compares the applications of blockchain in the financial and gaming fields, and it can be seen that there are indeed great similarities between the two. DeFi initially used the Orderbook model, which is an active matching system, but after switching to AMM, it became a passive automatic matching system. Similarly, full-chain games initially used “lazy update” and “manual ticking” for active game loops, but after switching to pre-compiled Ticking Chain, it became a passive automatic game loop. AMM improves financial liquidity, while Ticking Chain improves game smoothness.

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