全鏈遊戲內核剖析：MUD引擎與World Engine

YBB Capital ｜2023-08-10 18:23

以更遠大的視角看，隨著基建設施的提升，不僅僅是遊戲而是各種複雜想法的構建與實現都會通過MUD進行，並在更複雜的Rollup方案上融合交互，區塊鏈的新範式也許會從全鏈遊戲開始。

作者: Solaire, YBB Capital

過去由於區塊鍊鍊表結構的限制，在鏈上構建一個實用的DApp一直不是件簡單的事情。但即便受此限制，探索者們也從未停下過前進的步伐，隨著”x * y = k”這段著名的恆定乘積池公式誕生於世，短短數百行代碼的Uniswap引領DeFi徹底改變了Crypto的敘事。簡單的DApp在開發者的巧思下尚能達到如此高度，那麼複雜的DApp應用呢？比如把遊戲或者社交平台完全搭建在鏈上？這在過去可能是一個瘋狂的想法，但在Rollups打開可擴展性的今天，這種可能性開始變得微妙。

DeFi曾給Crypto帶來了數千億美元的TVL，複雜性倍增的DApp如何實現？會引領Crypto再次走上一個新的高度嗎？或許處在發展初期的全鏈遊戲能給我們答案。本文的內容將從全鏈遊戲的歷史、全鏈遊戲目前的定義、全鏈遊戲創造與運行的實現方式以及全鏈遊戲對Crypto未來的意義，這四個部分對全鏈遊戲進行一次剖析。

全鏈遊戲的起源與發展

全鏈遊戲的歷史可以追溯到10年之前，Mikhail Sindeyev分叉Namecoin 並構建了世界上第一個區塊鏈遊戲《Huntercoin》。《Huntercoin》於2013 年作為一個實驗原型開始，並迅速發展了一批在線狂熱追隨者，得到了許多著名的bitcointalk.org成員的支持。憑藉科技愛好者對視頻遊戲的熱愛，最受歡迎的Huntercoin帖子獲得了超過380,000 次的瀏覽。然而遺憾的是Mikhail Sindeyev在2014年2月中風去世了，《Huntercoin》的開發也陷入困境，代幣HUC在2015年幾乎歸零，雖然全鏈遊戲的第一次嘗試並沒有成功，但慶幸的是全鏈遊戲的故事仍在繼續。

2020年Gubsheep（Brian Gu）、Alan Luo、SCOTT SUNARTO ，受到小說《三體：黑暗森林》的啟發，開發了一款同名MMORTS太空征服遊戲《Dark Forest》。遊戲建立在以太坊之上，並將所有規則、邏輯寫入到智能合約，即每一步動作都是一筆鏈上交易的全鏈遊戲。遊戲內容的核心部分則利用了ZK-Snarks（零知識證明）技術去製作戰爭迷霧以復現三體小說中黑暗森林法則的定義（一旦某個宇宙文明被發現，就必然遭到其他宇宙文明的打擊）。

全鏈遊戲內核剖析：MUD引擎與World Engine

比如當玩家想要採取行動時，受到黑暗森林的法則影響，玩家不能暴露自己的坐標，卻要從A星球移動到B星球，他們需要提交A跟B的坐標以證明這是有效的，但以太坊的區塊信息是完全透明的，《Dark Forest》則通過以下方式去實現信息隱藏。玩家選擇要離開的星球和目的地星球，這兩個星球的位置是玩家的私有信息。計算要離開的星球和目的地星球的位置的哈希值，然後將這兩個哈希值提交到區塊鏈。在這個階段，玩家會提交一個承諾（Commit階段），由於哈希函數的單向性，這些提交的哈希值不能用來確定玩家的實際行星位置。而下一個階段是驗證（Reveal階段），在此階段，玩家生成並提交一個零知識證明，證明他們的行動是有效的。這個證明可以被任何人驗證，但不會透露任何關於玩家星球位置的信息。

如此，第一個在信息透明的以太坊上做到隱藏信息的全鏈遊戲就誕生了，這個瘋狂又極富想法的實驗，很快在整個Crypto圈子裡引起了轟動，Vtalik（以太坊創始人）甚至在Twitter直接轉發並稱讚了這個遊戲。

但《Dark Forest》首發後隨著超過10000名玩家的湧入，困境也開始顯現，以太坊的性能不足以支撐這種複雜應用的運行。遊戲上線當天直接堵爆了整個區塊鏈，數万億的Gas被花費。並且由於遊戲是基於DeFi應用的庫和架構設計的，後期再進行優化也只是減緩痛苦並不解決問題。

受到這場實驗對ZK-Snarks前景的啟發以及對全鏈遊戲困境的思考，遊戲創始人Brian Gu創建了0xPARC作為ZK-Snarks的研究院，以推動零知識證明的發展，而0xPARC的另外一個分支Lattice則負責設計維護全鏈遊戲引擎MUD。另一位創始人SCOTT SUNARTO則開始研發全鏈遊戲運行專用的分片Rollup框架——World Engine。

零知識證明在今天已經開始了廣泛運用，並被各位所熟知，我們接下來討論的主要是後兩者，MUD引擎與World Engine，即創造與運行。但在此之前我們需要了解驅動者（0xPARC）對全鏈遊戲的定義與新的認知方式。

Autonomous Worlds

基於0xPARC加密遊戲論文合集《Autonomous Worlds》中的觀點，全鏈遊戲至少需要遵循五個標準：

l數據來源於區塊鏈：區塊鏈不僅僅是數據的輔助存儲，也不僅僅是存儲在專有服務器中數據的"鏡像"。所有有意義的數據都可以在區塊鏈上訪問，而不僅僅是資產所有權等數據。這樣，遊戲就能充分利用可編程區塊鏈的優勢——透明的數據存儲，可無權限互操作；

l邏輯和規則通過智能合約實現：例如，遊戲中的戰鬥，而不僅僅是所有權，都是在鏈上進行的；

l遊戲的開發遵循開放生態原則：遊戲合約和可訪問的遊戲客戶端都是開源的。第三方開發者可以通過插件、第三方客戶端、互操作智能合約，實現完全重新部署，定制甚至分叉自己的遊戲體驗。這反過來又使遊戲開發者能夠利用整個(激勵一致)社區的創造性產出；

l遊戲永久存於鏈上：這一點與上述三點密切相關，因為檢驗一款遊戲是否是加密原生遊戲的試金石是:如果明天核心開發者提供的客戶端消失了，遊戲還能玩嗎?答案往往是肯定的，如果(也只有當)遊戲數據存儲是無權限的，如果遊戲邏輯可以無權限執行，如果社區可以與核心智能合約交互而不依賴於核心團隊提供的接口；

l遊戲可與我們認為有價值的事物互通：區塊鍊為價值概念本身提供了一個本地應用程序接口，數字資產默認情況下可與我們關心的其他資產互操作。這既反映了遊戲的深度和意義，也有助於提升遊戲的深度和意義，並將游戲世界與"真實"世界聯繫起來。

基於這個標準下構建的全鏈遊戲也可將其看為基於區塊鍊為低層的世界，或者說Autonomous Worlds（自主世界）。

那麼何謂世界？世界並非只能指代現實世界，世界的載體可以是小說、電影、遊戲、詩歌甚至法律體系。但在這些世界裡都是由中心（作者、開發者或者群體）制定框架與規則再傳達給我們。這些世界裡自主性的程度也是不一樣的，比如開放世界遊戲裡非常知名的《Minecraft》（《我的世界》） ，玩家擁有極高的自主性，通過對不同方塊的搭建，以及規則修改，玩家可以創造只屬於他們的世界。而自主性較低的世界可能是小說世界，比如《Harry·Potter》 ，我們看到的這個魔法世界都是基於JK羅琳所創造的規則和框架。

如果把區塊鏈作為世界的基底，區塊鏈毫不含糊地保存了其狀態下所有節點實體的集合。此外，它們還用計算機代碼正式定義了引入規則。擁有區塊鏈底層的世界可以讓其居民參與共識。它們運行一個計算機網絡，在每次引入新的實體時達成一致。

從世界的角度來看，有兩個區塊鏈概念需要定義:

l區塊鏈狀態根:狀態根是對世界中所有實體的壓縮。有了狀態根，人們就可以確定任何實體是否是虛擬的，相信一個世界的狀態根就等於相信世界本身。 0x411842e02a67ab1ab6d3722949263f06bca-20c62e03a99812bcd15dce6daf26e 是2022 年7 月21 日07:30:10PM UTC 時的以太坊——一個擁有區塊鏈底層的世界的狀態根。在計算這個狀態根時，以太坊世界的所有實體都被考慮在內。它代表了該世界在該特定時間內的全部內容；

l區塊鏈狀態轉換函數:每個區塊鏈都定義了一個狀態轉換函數。它可以被視為一個明確的引入規則。它定義了"世界"的前一個狀態——虛擬實體的集合——如何通過人和機器的輸入引入新的虛擬實體。就比特幣而言，狀態轉換函數定義了余額如何在地址之間消費和轉移。

所以把全鏈遊戲看作以區塊鍊為底層的世界，則這個去中心化世界擁有無限大的自主性，也可以稱之為自主世界。

創造的困境

在早期探索全鏈遊戲的新設計過程中，開發者多次受到傳統DApp 架構和用於構建DeFi 應用的庫的局限性的影響。《Dark Forest》和其他早期的全鏈遊戲構建在當時不得不遵循用於構建DeFi 應用的架構和庫，這些架構成為了當時構建全鏈遊戲的默認選擇。

早期在創造全鏈遊戲方面的模式可總結為四點：

l當不同合約觸及相同狀態：多個智能合約可能會修改同一個數據或狀態，這可能會導致數據不一致或其他問題。有時使用Diamond Pattern去解決（鑽石模式是一種解決Solidity智能合約中多重繼承問題的方法）；

l編寫多種數據結構：每種實體（如游戲中的士兵、行星等）都有其自己的數據結構和類型；

l編寫Getters函數：此為數據結構返回批量元素的函數，用於從鏈上獲取初始狀態或數據。例如，getPlanets()函數可能會返回所有行星的列表；

l事件：每個數據結構都包含一個事件，這是智能合約中的特定功能，允許應用在新塊被添加到鏈上時同步或更新其狀態。例如，當一個新的行星被創建時，可能會觸發一個事件，應用會監聽這個事件並更新其顯示的行星列表。

通過這種模式構建全鏈遊戲非常痛苦，雖然可以不斷進行優化以減緩痛苦，但我們都明白這種構建方式還是與使用真正的通用引擎構建相差甚遠。

世界的創造者——MUD引擎

全鏈遊戲內核剖析：MUD引擎與World Engine

MUD引擎的誕生來自於開放者們對過去以及現有問題的思考，MUD是一個構建複雜應用的以太坊應用程序的框架。 MUD 提供了一些組織數據和邏輯的約定，並抽象了低級複雜性，使開發者可以專注於應用程序的功能。它標準化了鏈上數據的存儲方式。有了這種標準數據模型，MUD 可以提供所有網絡代碼來同步合約和客戶端狀態。

MUD最新版本目前配備了五個組件：

Store：一個鏈上數據庫；
World：一個入口點框架，帶來標準化的訪問控制、升級和模塊；
tools：基於Foundry的超快速開發工具；
客戶端數據存儲：可以神奇地反映鏈上狀態；
MODE：可以使用SQL查詢的Postgres數據庫。

EVM完全兼容性，極高的自由度

MUD的通用性並不止於以太坊主網，只要語言支持，MUD可以無縫地運作在任何EVM兼容的鏈上，無論是Polygon、Arbitrum、Optimism還是Gnosis Chain。

此外，儘管MUD在Autonomous Worlds（自主世界）和鏈上游戲社區中是首選框架，但它的應用遠不止於此。與此同時，MUD提供了極大的自由度，不強迫開發者受限於特定的數據模型。簡而言之，任何可以通過Solidity映射和數組實現的功能，都可以輕鬆地在MUD中完成。而在數據可用性上，無論是在主網還是Rollups上部署的MUD應用，它們都可以與ENS和Uniswap等傳統以太坊應用程序相媲美。

核心思想

MUD作為一套為鏈上複雜應用設計的高度協同的庫和工具，其核心思想圍繞三點：

l所有鏈上狀態均保存在MUD鏈上數據庫Store中：Store是一個嵌入式EVM數據庫，類似於SQLite 數據庫，它具有表、列和行的概念。使用Store 可以更加結構化地管理數據，並且不需要依賴Solidity 編譯器提供的存儲方法。並且，它支持在運行時創建表，並允許註冊掛鉤以自動創建索引視圖，從而帶來更多靈活性；

l邏輯是無狀態的，並且通過自定義權限跨不同合約進行分區："World" 充當一個入口點，協調不同的智能合約對"Store" 的訪問。當一個“World”被部署時，它會隨即創建一個“Store”，每個在“Store”中的表都是在一個特定的命名空間下被註冊的。當功能（比如地址之間轉賬的邏輯）被添加到“World”時也在命名空間下註冊，並被稱為“系統”。這些“系統”實際上是智能合約，但與傳統的智能合約不同的是，它們是無狀態的，不直接持有數據。而是利用“World Store”進行數據的讀取和寫入。由於這種設計，只要部署在同一條鏈上，這些“系統”可以在不同的“World”之間重複使用；

l不需要索引器或子圖，前端也可保持同步：當使用Store（以及擴展的World）時，鏈上數據自動內省（Introspection，自我檢查），任何改變都通過標準事件進行廣播。通過"MODE" 節點，實時地將鏈上狀態轉換為SQL 數據庫，從而保持最新狀態（毫秒級延遲）。此外，MUD 提供了一系列查詢工具，如MUD QDSL 和GraphQL，使得前端同步變得更加簡化。對於React 開發者，MUD 還提供了專門的Hooks，允許自動綁定和更新組件狀態。

突破枷鎖

通過三點核心思想我們再以過去的困境為例，看看MUD是如何打破複雜應用的枷鎖的。

l當不同合約觸及相同狀態：通過使用"World" 和"Store" 結構來集中管理鏈上狀態。所有的智能合約（在MUD 中稱為“系統”）都通過"World" 來訪問和修改"Store" 中的數據。這確保了所有的狀態修改都經過一個集中的入口點，從而減少了數據不一致或衝突的風險。通過命名空間和路徑，MUD 提供了對數據的細粒度訪問控制。不同的“系統”可以有不同的權限，從而確保只有授權的“系統”可以修改特定的數據或狀態；

l數據結構：與傳統的Solidity 存儲方法不同，MUD 的"Store" 提供了類似於SQLite 的表、列和行的概念，從而可以更加結構化地存儲和管理數據。每種實體（如游戲中的士兵、行星等）都可以有其自己的表，每個表可以有多個列來存儲該實體的不同屬性；

lGetters函數：由於MUD 的"Store" 提供了結構化的數據存儲，獲取數據變得更加簡單和直觀。開發者可以使用SQL-like 的查詢語言來獲取數據，而不需要編寫專門的getters 函數。例如，要獲取所有的行星，開發者可以簡單地查詢行星表，而不需要編寫一個getPlanets() 函數；

l事件：MUD 提供了自動內省功能，這意味著任何數據更改都會自動被系統識別並觸發相應的事件。應用可以監聽這些事件來同步或更新其狀態，而不需要為每種數據結構手動定義事件。

以上是對MUD基本構建塊，組件的部分使用方式說明，MUD還可以構建更複雜的場景與應用。

運行世界，World Engine

全鏈遊戲的運行對於以太坊來說一直是個巨大的挑戰，隨著Rollups的快速發展，以及坎昆升級的臨近，成本大幅下降，速度大幅提高的將來。全鏈遊戲已經蓄勢待發，但目前的主流Rollups基本是為交易設計的，並沒有真正為全鏈遊戲所量身打造的Rollup。

而Argus旗下的核心產品World Engine則是真正為了全鏈遊戲所打造的分片架構Rollup，由於目前還沒有公開測試，我們將從項目的博客與演講中分析World Engine。

全鏈遊戲需要怎樣的Rollup

l高吞吐量與高TPS：更快的交易處理，更低的延遲，更好的可擴展性；

l擴展讀寫：大多數Layer2為了高並發處理，都設計成進行大量寫入，但遊戲需要讀取以獲得玩家位置，所以讀與寫同樣重要；

l水平可擴展的鏈：水平可擴展性是指通過添加更多的節點和資源來增加系統的處理能力，以適應不斷增長的需求。這樣可以避免Noisy Neighbor 問題（一個應用或實體的活動可能對其他應用或實體產生負面影響，導致資源爭用和性能問題）；

l靈活與定制：靈活性與可定制性，方便修改狀態機，使其為遊戲設計。這包括有一個遊戲循環，使其自我執行等等；

lTick rate：Ticks是遊戲時間中的原子單位，遊戲想要足夠低的延遲需要更高的Tick rate或者每秒更多的區塊以降低延遲。

分片架構

為了實現上述目標，團隊回顧了21 世紀初和20 世紀90 年代末並受到啟發，像MMOs 這樣的在線遊戲剛剛興起的情況。早期的在線遊戲在服務器和網絡技術相對有限的情況下，需要找到一種方式來支持大量玩家的互動。 "分片"就是其中一種解決方案，它的核心思想是將玩家分佈到不同的服務器或“分片”上，每個分片可以獨立地託管一部分玩家、遊戲地圖和數據。

例如，Ultima Online 是一個早期的MMORPG，它在服務器上實現了分片概念。遊戲中的不同分片代表了不同的虛擬世界，每個分片可以容納一定數量的玩家。這樣做的好處包括：

擴展性：通過將玩家分佈到不同的分片，遊戲可以更輕鬆地擴展以適應更多玩家的加入；
減少負載：分片可以減少單個服務器上的玩家數量和數據量，從而降低服務器的負載，提高性能；
避免擁堵：分片可以減少玩家在同一區域的擁堵情況，提供更流暢的遊戲體驗；
地理位置優化：通過將玩家分配到就近的分片，可以減少網絡延遲，提高遊戲響應速度。

那麼如何把這個概念帶入World Engine？與過去的許多分片排序器不同，"World Engine" 的設計更適合特定的需求。它的優化方向包括吞吐量和運行時間。為了確保高效的"Tick rate"（即每秒更新頻率）和區塊時間，它默認是同步的。設計的目標是確保交易被迅速處理，以保持高效的遊戲體驗或系統性能。在排序方式上採用的是部分排序的方式，而不是強制要求對所有交易進行總排序。這意味著並不要求每個交易都必須在所有其他交易之後發生。這可以減少排序的負擔，從而更好地滿足高吞吐量和快速區塊時間的需求。

這裡有兩個關鍵組成部分，EVM Base Shard（EVM分片）與一個Game Shard（遊戲分片），EVM分片就是存粹的EVM鏈。而真正的秘密武器是遊戲分片，它本質上是一個設計成高性能遊戲服務器的迷你區塊鏈。 World Engine具有一個bring-your-own-implementation 接口，這樣我們可以根據我們的喜好定制這個分片。構建的分片，注入到基礎分片中。只需要實現一套標準的接口，就像我們熟悉的Cosmos，Cosmos 有一個IBC 接口。我們基本上可以將這個整合成一個類似的規範，將自己的分片帶到World Engine 堆棧中。

Cardinal 是World Engine 的第一個遊戲分片實現。它使用Entity-Component-System (ECS)遊戲架構，一個具有面向數據的架構。這允許並行化遊戲，並提高遊戲計算的吞吐量。它有一個可配置的”Tick rate“，最高可達每秒20 次Tick。對於這裡的區塊鏈來說，那就是每秒20 個區塊。另外它還是自我索引的，無需外部索引器。

並且分片還可以通過地理定位，以減少延遲。比如，遊戲可能有在美國的排序器，然後亞洲玩家必須等待300 毫秒的延遲，才能讓transaction 到達排序器。這在遊戲中是一個巨大的問題，因為300 毫秒是很長的時間。如果試圖玩一個有200 毫秒延遲的FPS 遊戲，那基本上就是，在玩PPT了。