鏈上遊戲中的「AMM 時刻」

當我們描述一個產品、技術或創新在特定行業中所產生的革命性影響時，我們經常將其稱為該行業的「iPhone 時刻」。這個類比源於蘋果在 2007 年推出的 iPhone 對整個手機和計算機行業的深遠影響。

在 DeFi 世界中，這一變革時期被稱為「AMM 時刻」，因為 AMM 模型在 DeFi 領域中發揮了關鍵作用，特別是在增強市場流動性方面，這直接導致了 2021 年的牛市。那么，鏈上遊戲的「AMM 時刻」是什麼呢？讓我們在文章中深入探討這一問題。

AMM 在 DeFi 中的重要性#

DeFi，即區塊鏈技術與金融的整合，將金融規則編碼到智能合約中，從而實現去中心化、隱私和自動化。那么，這些金融平台的關鍵組成部分是什麼？顯然是「流動性」。例如，三種主要的商業模式 —— 借貸、交易和支付（穩定幣）—— 都在很大程度上依賴於流動性以實現持續增長。

借貸：流動性是借貸運作的核心。傳統銀行和金融機構依賴短期存款和其他來源來提供長期貸款。流動性不足可能導致這些機構在滿足貸款請求或償還短期債務時面臨困難。流動性風險在金融危機中發揮了重要作用 —— 當銀行無法獲得足夠資金履行其承諾時，便會倒閉。

交易：在資本市場中，流動性至關重要。高流動性表明資產可以迅速買賣而不會產生顯著損失。低流動性可能導致更大的買賣差價或在出售資產時難以找到買家。這可能導致價格劇烈波動和市場不穩定。

支付（穩定幣）：支付系統的流動性，特別是涉及穩定幣的系統，至關重要。個人和企業在轉移資金時依賴高效可靠的支付系統。這些系統中的流動性不足可能導致支付延遲或失敗，妨礙整體經濟運行。

在 Web3 環境中，交易成為金融運作的核心，因為借貸和支付主要是為了促進交易（利用和充當交易媒介）。但為什麼會出現「AMM 時刻」？這在很大程度上是由於區塊鏈固有的性能限制。

傳統的集中式金融機構依賴高性能伺服器來存放其金融規則，以確保頂級的匹配效率。相比之下，DeFi 將這些規則嵌入智能合約中，犧牲了匹配效率以換取去中心化和隱私的好處。

鑒於智能合約的性能相對較差，被描述為一種「世界計算機」層，最初的 DeFi 項目（無論是借貸平台還是交易所）都基於傳統的訂單簿模型進行匹配。在這種背景下，DeFi 在 AMM 出現之前無法與 CeFi 抗衡。

如何利用這種「世界計算機」的有限性能來大幅提升流動性匹配效率？AMM 模型的解決方案利用流動性池和算法進行自動配對。雖然具體細節在文獻中有廣泛討論，這裡不再深入，但其好處包括：

消除傳統市場做市商：在傳統金融中，市場做市商通常提供買賣訂單的報價以確保市場流動性。AMM 模型允許流動性提供者將資金存入智能合約，然後根據預定算法自動調整價格並執行交易，從而消除了對傳統市場做市商的需求。

流動性池：在 AMM 模型中，流動性池為交易者提供了一個始終可用的對手方。流動性提供者可以將資金存入這些池中，並獲得交易費用作為回報，從而鼓勵更多參與者，進一步增強市場流動性。

減少交易摩擦：得益於 AMM 的自動化，交易可以隨時執行，消除了等待傳統買賣訂單匹配的時間，從而減少了交易摩擦。

促進 DeFi 創新：AMM 模型為 DeFi 領域引入了許多創新，包括流動性挖礦和雙代幣流動性池。這些創新進一步加速了 DeFi 的增長和採用。

AMM 的創新機制顯著提高了 DeFi 的流動性匹配效率，使其與 CeFi 具備競爭力。這一突破導致了被稱為 DeFi 夏季的迅猛增長。

遊戲與區塊鏈之間的根本衝突是什麼？#

鏈上遊戲現在正處於一個類似於 DeFi 的時刻：一個遊戲如何在低性能的「世界計算機」上運行？為了解答這個問題，我們需要深入分析遊戲與區塊鏈之間的內在矛盾。

我曾寫過一篇文章，標題為「鏈上遊戲引擎架構 ARC 和 ECS 之間的區別是什麼？」在其中，我討論了遊戲循環的概念，強調傳統遊戲是基於循環的。

傳統遊戲基於循環模型運作，因為其核心機制是遊戲循環。這個循環是一個重複的過程，通常涉及處理用戶輸入、更新遊戲狀態和渲染遊戲世界。循環在遊戲運行期間持續進行，通常每秒執行數十到數百次，以確保遊戲世界的流暢性。在這個結構中，遊戲系統（如物理引擎、AI 系統等）在每次循環中檢查和處理它們關心的遊戲實體和組件。

相比之下，區塊鏈的架構是基於推送的。區塊鏈是一個分佈式數據庫，在網絡中的節點之間共享和存儲信息。當一個節點生成一個新交易（例如，轉賬、合約調用）時，這個交易會被推送到網絡中。其他節點在接收到這個交易後，會對其進行驗證並將其添加到區塊鏈中。這是一個被動過程；節點不會主動尋找新交易，而是等待網絡中的其他節點發送它們。因此，區塊鏈的架構被稱為基於推送的。

這一澄清基本上回答了我們最初的問題。遊戲架構通常是基於循環的，而區塊鏈架構是基於推送的，這標誌著遊戲與區塊鏈之間的內在矛盾。那么，我們如何解決這一差異呢？有人可能會爭辯說，一旦這一矛盾得到解決，我們將見證鏈上遊戲的「AMM 時刻」。

為了深入探討，讓我們看看遊戲是如何實現遊戲循環的。

每個遊戲都包含一系列捕捉用戶輸入、更新遊戲狀態、處理 AI、播放音樂和音效以及渲染遊戲視覺的過程。這一系列過程由遊戲循環管理。在不深入探討上述每個任務的具體細節的情況下，我們將重點放在遊戲循環本身。為了簡化，這些任務可以簡化為僅更新和顯示遊戲。這裡是一個基本的遊戲循環形式的示例：

bool game_is_running = true; 

while( game_is_running ) {
    update_game();
    display_game();
}

讓我們引入三個術語：

Tick：
遊戲循環的同義詞。1 tick = 1 個遊戲循環。

FPS（每秒幀數）：
在上述實現的上下文中，它指的是每秒調用display_game()的次數。

遊戲速度：
這表示每秒更新遊戲狀態的頻率，或者換句話說，update_game()被調用的頻率。

總結來說，Tick / 遊戲循環是遊戲的基本循環，決定了遊戲邏輯的更新方式。FPS 決定了遊戲的視覺流暢性，表示每秒渲染的幀數。遊戲速度決定了遊戲邏輯的進展，通常與 tick 速率相匹配。理想情況下，tick 速率、FPS 和遊戲速度應該相等，這意味著每次邏輯更新都有相應的渲染。然而，在現實中，它們可能會有所不同，特別是在性能限制或其他技術限制下。

鏈上遊戲的核心挑戰#

在建立了上述理解後，我們現在可以深入探討鏈上遊戲面臨的核心挑戰。

遊戲循環與區塊鏈的不匹配：
傳統遊戲基於遊戲循環運作，這意味著遊戲狀態在每個 tick 或幀中更新。然而，區塊鏈是事件驅動的，僅在發生新交易或操作時更新狀態。這一根本的不匹配確實使得在鏈上遊戲中實現傳統遊戲循環變得複雜。
延遲和實時要求：區塊鏈中的交易確認時間可能會導致遊戲反應的延遲，這對於需要快速反應的遊戲（如動作或競技遊戲）來說是個問題。一個高效的 tick 機制需要考慮到這一延遲，最小化其對遊戲體驗的影響。
資源限制和計算成本：每次更新區塊鏈狀態都會消耗計算資源，並可能產生費用。在鏈上遊戲中頻繁的狀態更新可能導致高昂的成本。因此，需要一個高效的 tick 機制來平衡遊戲流暢性和開支。

如果我們能夠開發出一種適合區塊鏈特性的新的 tick 機制或遊戲循環模型，那確實將代表一個「AMM 時刻」。這可能需要將傳統遊戲開發技術與區塊鏈的獨特特徵相結合，從而誕生一個創新的遊戲框架。

但並不是每個遊戲類型都是基於循環的？雖然大多數遊戲確實是基於循環的，但也存在一些「基於推送」的遊戲，它們不需要不斷的實時狀態更新。例如回合制策略遊戲、傳統棋盤遊戲或某些卡牌遊戲。在這些遊戲中，狀態僅在玩家進行操作時更新，更加符合區塊鏈的事件驅動模型。因此，對於鏈上遊戲，值得考慮開發那些自然符合「基於推送」模型的遊戲，因為它們將更順利地適應區塊鏈的特性。

Ticking Chain：鏈上遊戲的 AMM 時刻#

Argus 的創始人 Scott 表達了類似的看法：

遊戲在循環驅動的運行時中運行。即使在沒有用戶輸入的情況下，狀態轉換仍然持續。火焰繼續燃燒，水流不斷，作物持續生長，日夜循環不息。

那么，如何設計一個適合區塊鏈的 tick 機制呢？@therealbytes 在他的文章《呈現 tick-optimism》中提供了答案。它對如何使用智能合約和預編譯合約構建 tick 系統進行了全面的解釋。這讓人想起 Vitalik 的經典論文，該論文將 AMM 概念引入 DEX，標題為《讓我們以運行預測市場的方式運行鏈上去中心化交易所》。那篇論文首次引入了著名的常數乘積公式「A * B = k」。

（有趣的是：當時並沒有「DeFi」這個術語；它被稱為鏈上去中心化交易所，就像我們現在稱之為鏈上遊戲一樣。）

在他的論文中，therealbytes 可能是第一個提出利用鏈的固有預編譯來實現 tick 的。Ticking-Optimism 修改了 rollup 節點以創建一個「tick 交易」。它的運作類似於「存款交易」，但不是設置 L1 屬性，而是調用預先部署到地址 0x42000000000000000000000000000000000000A0 的合約中的 tick () 函數。這個合約可以通過設置其目標變量來調用另一個合約。

將 Ticking 功能嵌入鏈的節點中顯著提高了循環效率。這可以與 AMM 模型相對於訂單簿模型在 DeFi 中的顯著效率飛躍進行類比。你問這有多重要？數據可以參考另一篇文章《為數字之神計時》。

為了充分測試鏈本身的極限，他以兩種方式實現了遊戲：作為在鏈上運行的 Solidity 智能合約，以及作為鏈本身的預編譯。Solidity 實現達到 70x70 網格時，CPU 達到最大，並以每個區塊兩次更新（1 區塊 / 秒，或約 10k 單元 / 秒）的速度運行，而具有自定義預編譯引擎的鏈在相同速率下達到 256x256 網格，使用約 6% 的 CPU（約 130k 單元 / 秒）。

結論#

如果 AMM 模型確保金融系統即使在低性能區塊鏈上也能實現高匹配效率和流動性，那麼 Ticking Chain 則保證了遊戲系統也能在這些鏈上實現高循環效率和流暢性。

以上僅是 therealbytes 的一個概念驗證，但實際上，已經有完全鏈上遊戲引擎採用這一 Ticking Chain 模型。第一個開源的 Ticking Chain 引擎來自 @0xcurio，它利用 OPStack 的預編譯 tick 功能建立了其 layer2。第二個來自 @ArgusLabs_，使用 Polaris 建立了一個具有預編譯 tick 功能的 layer2。我相信未來會出現更多的 Ticking Chains。

Snip20230828_56

上表比較了區塊鏈在金融和遊戲領域的應用，突顯了它們之間的巨大相似性。DeFi 最初使用訂單簿模型，這是一種主動匹配系統。在轉向 AMM 後，它演變為一種被動、自動的匹配系統。同樣，鏈上遊戲最初採用了傳統的「懶惰更新」和「手動 tick」來實現主動遊戲循環。在轉向預編譯的 Ticking Chain 後，它們轉變為被動、自動的遊戲循環。AMM 增強了金融的流動性，而 Ticking Chain 則改善了遊戲的流暢性。