首頁

什麼是全鏈遊戲的「AMM 時刻」？

CaptainZ

閱讀本文需 21 分鐘

滴答鏈是全鏈遊戲的AMM時刻，透過設計一個適合區塊鏈的ticking機制來提高效率。

原文作者：CaptainZ

當我們描述某個產品、技術或創新在特定行業中產生的革命性影響，喜歡說這是該行業的“iPhone 時刻”。因為這是基於 2007 年 Apple 發布 iPhone 後，它對整個手機和行動運算產業的深遠影響。

在 DeFi 產業，我們稱之為「AMM 時刻」。因為 AMM 模型在 DeFi 領域中起到了關鍵的作用，特別是在提高市場流動性方面，直接促成了 2021 年多頭市場的到來。那麼，什麼是全鏈遊戲的「AMM 時刻」呢？我們在本文一探究竟。

一AMM 在DeFi 中的重要角色

DeFi 是區塊鏈技術和金融領域的結合，也就是把金融規則寫入智慧合約，從而實現去中心化，隱私化和自動化。既然是金融領域，那麼各種項目最關鍵的又是什麼呢？顯然是「流動性」。例如三大業務模式，借貸，交易和支付（穩定幣業務），如果沒有流動性，三個業務是無法持續展開的。

1. 借貸：流動性是藉貸業務的核心。銀行和其他金融機構依賴短期的存款和其他資金來源來提供長期的貸款。如果金融機構無法確保足夠的流動性，它們可能無法滿足客戶的貸款需求，或者在需要償還短期債務時可能會面臨困境。流動性風險是金融危機的關鍵因素，當銀行無法獲得足夠的資金來滿足其貸款承諾時，它們可能會崩潰。

2. 交易：在資本市場中，流動性是交易的關鍵。流動性高意味著資產可以迅速而不損失價值地買賣。如果一個市場或資產缺乏流動性，投資者可能會面臨更大的買賣價差，或者在想要出售資產時難以找到買家。這可能會導致價格的劇烈波動和市場的不穩定。

3. 支付（穩定幣）：支付系統（穩定幣）的流動性至關重要。當人們或企業需要轉移資金時，他們依賴高效、可靠的支付系統。如果支付系統（穩定幣）缺乏流動性，可能會導致支付延遲或失敗，從而影響整個經濟的運作。

在 Web3，交易是金融業務的核心，因為借貸和支付都是為了服務交易而存在的（加槓桿和充當交易媒介）。那為什麼會有「AMM 時刻」？這是因為區塊鏈本身的性能限制決定的。

我們知道，中心化金融機構的金融規則是放在自己公司的高效能伺服器上，所以撮合效率極高，而DeFi 是透過把金融規則放在智能合約裡面，犧牲了撮合效率而帶來去中心化和隱私化的優勢。

智能合約做為一種「世界電腦」層的模擬，效能相對來說極為低。在最初的 DeFi 專案中，不管是藉貸還是交易所，撮合方式都是基於傳統金融的訂單薄模式。在這種模式下，DeFi 在 CeFi 面前毫無還手之力，直到 AMM 的出現。

如何使用超低效能的「世界電腦」來大幅提升流動性的撮合效率？ AMM 模型的解決方案是使用資金池和演算法來自動匹配。具體玩法已經有很多文章可以介紹，這裡不再展開討論。在優點方面我們現在已經知道：

1. 無需傳統做市商：在傳統的金融市場中，做市商通常需要為買賣訂單提供報價，以確保市場的流動性。而 AMM 模型允許流動性提供者存入資金到一個智能合約中，該合約自動根據預定的演算法調整價格和執行交易，從而無需傳統的做市商介入。

2. 流動性池：AMM 模型中的流動性池為交易者提供了一個始終可用的交易對手方。流動性提供者可以存入資金到這些池中，並獲得交易費用作為回報，從而激勵更多的人參與並提高市場流動性。

3. 降低交易摩擦：由於AMM 的自動化特性，交易者可以隨時進行交易，無需等待傳統的買賣訂單匹配，從而降低了交易摩擦。

4. 推動DeFi 創新：AMM 模式為DeFi 領域帶來了許多新的創新，如流動性挖礦、雙幣流動性池等。這些創新進一步推動了 DeFi 的發展和普及。

AMM 機制的創新居然促使 DeFi 的流動性撮合效率可以和 CeFi 相媲美，並最終帶來了 DeFi Summer。

二遊戲和區塊鏈的本質矛盾是什麼

現在全鏈遊戲來到了和DeFi 同樣的時刻：在一台極低效能的「世界電腦」上面如何運行一個遊戲？這需要深入分析遊戲和區塊鏈的本質矛盾是什麼。

我曾經寫過一篇文章《全鏈遊戲引擎架構ARC 和ECS 有什麼區別？》，在裡面介紹過遊戲循環的概念，並且指出傳統遊戲是基於循環的（loop-based）。

傳統的遊戲是基於循環（loop-based）的，因為它們的核心運作機制是遊戲循環。遊戲循環是一個不斷重複的過程，通常包含處理使用者輸入、更新遊戲狀態和渲染遊戲世界這幾個步驟。這個循環在遊戲運行期間持續進行，通常每秒運行數十次到數百次，以保持遊戲世界的流暢性。在這種架構中，遊戲系統（如實體引擎、AI 系統等）在每個循環中檢查和處理它們關心的遊戲實體和組件。

然而，區塊鏈的架構是基於推送（push-based）的。區塊鏈是一個分散的資料庫，它透過網路中的節點共享和儲存資訊。當一個節點產生一個新的交易（如轉帳、合約呼叫等）時，這個交易會被推送到網路中，其他的節點收到這個交易後會驗證它並將它添加到區塊鏈中。這是一個被動的過程，節點不會主動去尋找新的交易，而是等待網路中的其他節點發送新的交易。因此，區塊鏈的架構稱為是基於推送的。

其實這段話已經回答了上面的問題。 遊戲架構一般是 loop-based，而區塊鏈架構是 push-based，這就是遊戲和區塊鏈的本質矛盾。那如何解決這個矛盾？可以說，只要解決了這個矛盾，就迎來了全鏈遊戲的「AMM 時刻」。

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

每款遊戲都包含一系列獲取用戶輸入, 更新遊戲狀態, 處理 AI, 播放音樂和音效以及顯示遊戲的順序。這個順序透過遊戲循環來處理。我們暫時不詳細討論上述任何任務, 而是將注意力集中在遊戲循環本身，所以可以將任務簡化為僅更新和顯示遊戲兩個函數。以下是遊戲循環最簡單形式的範例程式碼:

bool game_is_running = true;

while( game_is_running ) {

update_game();

display_game();

}

先介紹三個名詞：

Tick

Tick 是game loop 的同義詞（擬聲詞），1 tick = 1 game loop

FPS

FPS 是每秒影格數(Frames Per Second) 的縮寫。在上述實現的上下文中, 它是每秒呼叫 display_game() 的次數。

遊戲速度

遊戲速度是每秒更新遊戲狀態的次數, 或換句話說, 每秒呼叫update_game() 的次數。

總結一下，Tick/Game Loop 是遊戲的基本週期，決定了遊戲邏輯如何更新。 FPS 是每秒渲染的幀數，決定了遊戲的視覺流暢性。遊戲速度是遊戲邏輯如何進展，通常與 tick 速率相等。在理想情況下，tick 速率、FPS 和遊戲速度應該都是相等的，這意味著每次邏輯更新後都會有對應的渲染。但在實際情況中，這三者可能會有所不同，特別是在性能受限或有其他技術限制的情況下。

三全鏈遊戲的核心挑戰

有了上面的理解，我們現在可以討論全鏈遊戲中的核心挑戰了。

1. 遊戲循環與區塊鏈的不匹配：傳統的遊戲是基於遊戲循環（game loop）的，這意味著遊戲的狀態在每個tick 或幀中都會更新。但是，區塊鏈是基於事件驅動的，只有當有新的交易或操作時才會觸發狀態的更新。這種基本的不匹配確實使得在全鏈遊戲中實現傳統的遊戲循環變得複雜。

2. 延遲與即時性：區塊鏈的交易確認時間可能會導致遊戲的反應延遲，這對於需要快速回應的遊戲（如動作遊戲或競技遊戲）來說是一個問題。一個有效的 ticking 機制需要考慮這種延遲，並盡量減少對遊戲體驗的影響。

3. 資源限制與運算成本：每次更新區塊鏈的狀態都需要消耗運算資源，並可能產生費用。在全鏈遊戲中，頻繁的狀態更新可能會導致高昂的費用。因此，需要一個高效的 ticking 機制來平衡遊戲的流暢性和成本。

如果能夠開發出一個適應區塊鏈特性的新的ticking 機製或遊戲循環模型，這確實會是一個「AMM 時刻」。這可能需要結合傳統的遊戲開發技術和區塊鏈的特性，創造出一個全新的遊戲框架。

那麼是否所有的遊戲類型都是 loop-based 嗎？雖然大多數遊戲類型確實是基於循環的，然而，也存在一些「push-based」的遊戲，這些遊戲不需要持續的、即時的狀態更新。例如，回合製策略遊戲、棋類遊戲或某些卡牌遊戲。在這些遊戲中，狀態只在玩家採取行動時更新，這與區塊鏈的事件驅動模型更為相似。因此，對於全鏈遊戲來說，確實可以考慮先開發那些更符合「push-based」模型的遊戲，這樣可以更自然地適應區塊鏈的特性。

四滴答鍊就是全鏈遊戲的AMM 時刻

Argus 的創辦人Scott 也表達過同樣的看法：

遊戲在一個循環驅動的運行時操作（loop-driven runtime）。即使沒有使用者輸入，狀態轉換也會繼續發生。火繼續燃燒，水繼續流動，作物繼續生長，日夜的循環繼續。

那麼要如何設計一個適合區塊鏈的 ticking 機制呢？ @therealbytes 給了答案。我曾經翻譯過他的那篇經典文章《Let's run on-chain decentralized exchanges the way we run prediction markets》，在那篇經典的文章中，第一次引入了著名的恆定乘積公式“A * B = k”。

（一個有趣的點：那時候沒有DeFi 的叫法，只是叫On-chain decentralized exchange，如同現在我們稱全鏈遊戲叫On-chain game）

在這篇文章中，therealbytes 應該是第一個提出了利用鏈本身的預編譯來實現ticking：Ticking-Optimism 修改了rollup 節點，創建了一個「滴答交易」（tick transaction），運作方式與「存款交易」相同，但不是設定L1 屬性，而是在預先部署到位址0x42000000000000000000000000000000000000A0 的合約中呼叫tick () 函數。這個合約可以透過設定其目標變數來呼叫另一個合約。

把 Ticking 函數內建到鏈的節點，在 loop 效率方面是一個巨大的提升。這一點完全可以類比 DeFi 產業中，AMM 模型對比 Orderbook 模型在撮合效率上的巨大提升。究竟有多巨大呢？資料可以參考我翻譯的另一篇文章《為「數字神明」記時》：

為了充分測試鏈本身的極限，他用兩種方式實現了遊戲：一種是作為一個在鏈上運行的Solidity 智能合約，另一種是作為鏈本身的預編譯。 Solidity 實現在達到每個區塊兩次更新的70x70 網格後讓CPU 達到極限（1 個區塊/ 秒，或大約10k 個細胞/ 秒），而自訂預編譯引擎的鏈在使用大約6%的CPU（約130k 個細胞/ 秒）時，達到了相同速率的256x256 網格。

五小結

如果說，AMM 模型保證了金融系統在低性能的區塊鏈上也可以有很高的撮合效率和流動性，那麼，滴答鏈（Ticking Chain）是保證了遊戲系統在低性能的區塊鏈上也可以有很高的循環（loop）效率和流暢性。

上面介紹的只是 therealbytes 的概念驗證，而實際上已經有全鏈遊戲引擎開始使用這種滴答鏈的模式了。第一個開源的滴答鏈引擎是@0xcurio，他們使用的正是具有預編譯ticking 函數的OPStack 來搭建layer2，第二個開源的滴答鏈引擎是@ArgusLabs_，他們使用的是Polaris 來構建具有預編譯ticking 函數的layer2。我相信未來還會有更多的滴答鏈出現。

上面的表格是對金融和遊戲領域在區塊鏈方面的應用做的對比，可以看到兩者確實有極大的相似性。 DeFi 在開始使用的 Orderbook 模型，是一種主動式的撮合系統（Matching system），改為 AMM 之後，就變成了被動式地自動撮合系統。類似的，全鏈遊戲在開始使用的是常規的「lazy update」和「manual ticking」來進行主動式的遊戲循環，改為預先編譯的滴答鏈之後，就變成了被動式的自動遊戲循環。 AMM 提高了金融的流動性，滴答鏈提高的是遊戲的流暢性。