When we describe the revolutionary impact a product, technology, or innovation has had in a specific industry, we often refer to it as that industry's "iPhone moment". This analogy is drawn from the profound influence that the iPhone, introduced by Apple in 2007, had on the entire mobile phone and computing industry.
In the DeFi world, this transformational period is called the "AMM moment", given the pivotal role the AMM model has played in the DeFi sector, especially in enhancing market liquidity, which directly led to the bull market of 2021. So, what is the "AMM moment" for on-chain gaming? Let's delve into this in the article.
The Significance of AMM in DeFi#
DeFi, the integration of blockchain technology and finance, encodes financial rules into smart contracts, thereby achieving decentralization, privacy, and automation. So, what's the crucial component for these financial platforms? Clearly, it's "liquidity." For instance, three major business models—lending, trading, and payment (stablecoin)—all rely heavily on liquidity for sustained growth.
Lending: Liquidity sits at the heart of lending operations. Traditional banks and financial institutions lean on short-term deposits and other sources to offer long-term loans. Insufficient liquidity could lead these institutions to face difficulties in fulfilling loan requests or repaying short-term debts. Liquidity risks played a significant role in financial crises—banks collapsing when they couldn’t secure enough funds to honor their commitments.
Trading: In capital markets, liquidity is paramount. High liquidity indicates assets can be bought or sold swiftly without notable losses. Low liquidity can lead to larger bid-ask spreads or difficulties finding buyers when selling an asset. This can result in sharp price fluctuations and market instability.
Payments (Stablecoin): The liquidity of payment systems, especially those involving stablecoins, is critical. Individuals and businesses depend on efficient and reliable payment systems when transferring funds. A liquidity deficit in these systems might lead to payment delays or failures, hampering the economy's overall function.
In the Web3 environment, trading becomes central to financial operations since lending and payment exist primarily to facilitate trading (leveraging and acting as trading mediums). But why did the "AMM moment" come into being? It’s largely due to the inherent performance constraints of blockchains.
Traditional centralized finance institutions rely on high-performance servers to house their financial rules, ensuring top-tier matching efficiency. In contrast, DeFi embeds these rules into smart contracts, sacrificing matching efficiency for the benefits of decentralization and privacy.
Given the relatively inferior performance of smart contracts, described as a sort of "world computer" layer, initial DeFi projects (whether lending platforms or exchanges) based their matching on the traditional orderbook model. Against this backdrop, DeFi stood helpless against CeFi until the advent of AMMs.
How can one harness the limited performance of this "world computer" to drastically enhance liquidity matching efficiency? The AMM model's solution leverages liquidity pools and algorithms for automatic pairing. While the specifics are extensively covered in literature and won't be delved into here, its benefits include:
Eliminating Traditional Market Makers: In conventional finance, market makers typically provide quotes for buy/sell orders to ensure market liquidity. The AMM model permits liquidity providers to deposit funds into a smart contract, which then autonomously adjusts prices and executes trades based on a predetermined algorithm, obviating the need for traditional market makers.
Liquidity Pools: Within the AMM model, liquidity pools offer traders a consistently available counterparty. Liquidity providers can deposit funds into these pools, earning transaction fees in return, encouraging more participants and thereby enhancing market liquidity.
Reduced Trading Friction: Thanks to AMM’s automation, trades can be executed any time, eliminating the wait for traditional buy/sell order matches, subsequently reducing trading friction.
Spurring DeFi Innovation: The AMM model introduced numerous innovations to the DeFi sector, including liquidity mining and dual-token liquidity pools. These innovations further accelerated the growth and adoption of DeFi.
AMM's innovative mechanism has remarkably enhanced DeFi's liquidity matching efficiency, making it competitive with CeFi. This breakthrough led to the meteoric rise known as DeFi Summer.
What is the Fundamental Conflict between Gaming and Blockchain?#
On-chain gaming is now at a moment reminiscent of DeFi: how can a game operate on a low-performance "world computer"? To answer this, we need to deeply analyze the intrinsic contradiction between gaming and blockchain.
I once wrote an article titled "What's the Difference Between On-chain Game Engine Architectures ARC and ECS?" Within it, I discussed the concept of the game loop, emphasizing that traditional games are loop-based.
Traditional games operate on a loop-based model because their core mechanism is the game loop. This loop is a recurring process that typically involves handling user input, updating the game state, and rendering the game world. The loop continues throughout the game's runtime, often executing dozens to hundreds of times per second to ensure the smoothness of the game world. In this structure, game systems (like physics engines, AI systems, etc.) check and process game entities and components they're concerned with during each loop.
In contrast, the architecture of blockchain is push-based. A blockchain is a distributed database, sharing and storing information across nodes in the network. When a node generates a new transaction (e.g., transfers, contract calls), this transaction is pushed out to the network. Other nodes, upon receiving this transaction, validate it and add it to the blockchain. This is a passive process; nodes don't actively search for new transactions but wait for other nodes in the network to send them. Hence, the architecture of the blockchain is termed push-based.
This clarification essentially answers our initial question. Game architecture is typically loop-based, while blockchain architecture is push-based, marking the inherent contradiction between gaming and blockchain. So, how can we resolve this discrepancy? One might argue that once this contradiction is addressed, we'll witness the "AMM moment" for on-chain gaming.
To dive deeper, let's see how games implement the game loop.
Every game entails a sequence of capturing user input, updating game states, processing AI, playing music and sound effects, and rendering the game visuals. This sequence is managed by the game loop. Without delving into the specifics of each of the above tasks, we'll focus on the game loop itself. For simplicity, the tasks can be reduced to just updating and displaying the game. Here's an example of a basic form of a game loop:
bool game_is_running = true;
while( game_is_running ) {
update_game();
display_game();
}
Let's introduce three terms:
Tick:
A synonym for game loop. 1 tick = 1 game loop.
FPS (Frames Per Second):
In the context of the aforementioned implementation, it refers to how many times display_game() is called per second.
Game Speed:
This signifies how often the game state is updated per second or, in other words, how frequently update_game() is called.
In summary, the Tick/Game Loop is the fundamental cycle of a game, dictating how game logic updates. FPS determines the visual smoothness of the game, representing the frames rendered per second. Game Speed dictates the progression of game logic, often matching the tick rate. Ideally, tick rate, FPS, and game speed should all be equal, meaning each logical update has a corresponding render. However, in reality, they might differ, especially under performance constraints or other technical limitations.
The Core Challenges of On-chain Gaming#
With the understanding established above, we can now delve into the core challenges faced by on-chain gaming.
-
Mismatch of Game Loop and Blockchain:
Traditional games operate based on a game loop, meaning the game's state updates in every tick or frame. However, blockchains are event-driven and only update states when a new transaction or operation occurs. This fundamental mismatch indeed complicates implementing the conventional game loop in on-chain games. -
Latency and Real-time Requirements: The transaction confirmation time in blockchains can induce lag in the game's response, which is problematic for games demanding swift reactions, such as action or competitive games. An efficient ticking mechanism needs to account for this latency, minimizing its impact on the gaming experience.
-
Resource Limitations and Computational Costs: Every update to the blockchain state consumes computational resources and might incur a fee. Frequent state updates in on-chain games can lead to exorbitant costs. Thus, an efficient ticking mechanism is needed to balance game fluidity and expenses.
If we can develop a new ticking mechanism or game loop model suited to blockchain characteristics, it would indeed represent an "AMM moment". This might necessitate blending traditional game development techniques with the unique features of blockchain, giving birth to an innovative gaming framework.
But is every game genre loop-based? While a majority of games indeed operate on a loop, there exist "push-based" games that don't require constant, real-time state updates. Examples include turn-based strategy games, traditional board games, or certain card games. In these games, states update only when a player makes a move, aligning more closely with the event-driven model of blockchains. Consequently, for on-chain gaming, it's worth considering the development of games that naturally align with the "push-based" model, as they would more seamlessly adapt to blockchain attributes.
Ticking Chain: The AMM Moment of On-chain Gaming#
Argus's founder, Scott, echoed a similar sentiment:
Games operate in a loop-driven runtime. Even in the absence of user input, state transitions persist. Fire continues to burn, water keeps flowing, crops keep growing, and the cycle of day and night endures.
So, how can one design a ticking mechanism apt for blockchains? @therealbytes provided the answer in his article titled "Presenting ticking-optimism". It offers a comprehensive explanation on the construction of a ticking system using smart contracts and precompiled contracts. This is reminiscent of Vitalik's classic paper introducing the AMM concept to DEX titled "Let's run on-chain decentralized exchanges the way we run prediction markets". That paper was the first to introduce the famed constant product formula "A * B = k".
(An interesting tidbit: There was no term 'DeFi' back then; it was referred to as on-chain decentralized exchange, just as we now call it on-chain game.)
In his paper, therealbytes is likely the first to propose the utilization of chain's inherent precompilations to achieve ticking. Ticking-Optimism modifies the rollup node to create a "tick transaction". It operates similarly to a "deposit transaction" but instead of setting L1 attributes, it invokes the tick() function in a contract pre-deployed to address 0x42000000000000000000000000000000000000A0. This contract can call another contract by setting its target variable.
Embedding the Ticking function into the chain's nodes presents a massive improvement in loop efficiency. This can be analogized with the significant efficiency leap of the AMM model over the Orderbook model in DeFi. How significant, you ask? Data can be referenced from another article titled "Timekeeping For Digital Gods".
To fully test the limits of the chain itself, he implemented the game in two ways: as a Solidity smart contract running onchain, and as a precompile in the chain itself. The Solidity implementation maxed out the CPU after reaching a 70x70 grid at two updates per block (1 block/second, or ~10k cells/second), while the chain with a custom precompile engine maxed out at a 256x256 grid at the same rate using ~6% of the CPU (~130k cells/second).
Conclusion#
If the AMM model ensures that financial systems can achieve high matching efficiency and liquidity even on low-performance blockchains, then the Ticking Chain guarantees that gaming systems can also achieve high loop efficiency and smoothness on these chains.
The above is just a proof of concept by therealbytes, but in reality, there are already fully on chain game engines adopting this Ticking Chain model. The first open-source Ticking Chain engine was from @0xcurio, which utilized the precompiled ticking function of OPStack to build its layer2. The second was from @ArgusLabs_, employing Polaris to establish a layer2 with a precompiled ticking function. I believe more Ticking Chains will emerge in the future.
The table above compares the applications of blockchain in both the financial and gaming sectors, highlighting their vast similarities. DeFi began using the Orderbook model, an active matching system. After transitioning to AMM, it evolved into a passive, automatic matching system. Similarly, on-chain games initially employed conventional "lazy update" and "manual ticking" for an active game loop. After transitioning to the precompiled Ticking Chain, they shifted to a passive, automatic game loop. While AMM enhances the liquidity of finance, the Ticking Chain improves the smoothness of games.