作者：羅奔奔，CTO of Tabi Chain
導語：自上一輪週期中Axie和StepN橫空出世以來，Gamefi和全鏈遊戲始終是區塊鏈行業的熱點之一，這一全新的遊戲模式在區塊鏈技術之上，在玩家資產所有權、價值轉移與遊戲內經濟體系、規則透明化及社群治理方面，帶來了傳統遊戲平台從未實現的獨特體驗。這些願景聽起來雖然美好，卻面臨著一個始終沒有解決的問題：
鏈遊的可玩性普遍不高，趣味性不足，更偏向金融投機，在投機回報下降後，用戶規模會迅速萎縮。
顯然這與傳統遊戲的發展模式背道而馳。傳統遊戲的順利發展，往往是靠著遊戲機制的趣味性，能吸引到大量用戶，同時遊戲的開發者可以建立起良好的盈利路徑，還可能因自身的影響力拓展出一系列的周邊與IP 。可以說，那些成功運作下來的傳統遊戲，其整個系統是正循環的，玩家可以體驗到遊戲的樂趣，往往也可以在遊戲內和遊戲外獲得一定的經濟利益。
相較之下，目前的鏈遊則是靠著單純的回報率吸引玩家。除了可玩性弱以外，Web3遊戲還面臨使用門檻高、互動流程繁瑣等老生常談的問題。
這一切的根源是什麼？不同的人有不同的看法。 TabiChain團隊認為，影響Web3遊戲的一個重要因素，是優秀的傳統遊戲開發者因為技術和學習成本問題，難以進入Web3生態。對於那些不了解遊戲或軟體開發的人來說，從Web2到Web3只是換了一種敘事和環境而已，但實際情況遠比想像中惡劣的多。
那我們該如何透過科技實現，為傳統的遊戲開發者或相關廠商，締造更友善的環境？下文中，我們將從多個方面，對Web3遊戲面臨的問題，及對應的解決方案進行全面解析，為大家闡述未來的Web3遊戲業該如何在技術上更適配傳統遊戲從業者。
阻礙傳統遊戲開發者進入Web3生態的技術原因
在前文中，我們曾簡單提到，技術不友善以及學習成本的高昂，是阻礙傳統遊戲從業者進入web3生態的核心因素，所謂的技術不友善和學習成本高昂，可以展開為以下幾點：
1.web3應用與傳統軟體結構的不同
區塊鏈和其上的應用（dApps）與傳統軟體架構有著本質不同，要求開發者俱備全新的知識體系，如區塊鏈的工作原理、共識協議、智慧合約程式設計模型等。傳統的遊戲開發者需要花費大量時間學習Solidity或其他智能合約語言，需要理解EVM的工作方式。
而且，傳統的遊戲邏輯通常在中心化的伺服器上執行，可以靈活處理複雜的遊戲狀態和高頻互動。在區塊鏈上運行遊戲邏輯則需要高度簡化或重構，因為每個操作都要發佈到分散式網路中執行，然後再上鏈，這受到區塊鏈性能和成本的嚴重限制。
2.智能合約的設計限制
EVM雖然滿足圖靈完備，理論上可以表達任意邏輯，但其特性非常不利於遊戲開發，例如：
-
缺乏定時器。以太坊鏈上的所有操作，必須由EOA帳戶手動觸發。為了實現類似定時器的效果，開發者需要額外部署一個服務，維護一個EOA帳戶以及事件列表，來手動觸發定時任務。由於上鍊的延時問題，這些定時任務還不能保證準時完成。
-
沒有回調等機制，不支援多執行緒和非同步。由於Solidity是為以太坊智能合約開發而設計的，因此它的執行環境與傳統的運行時環境有顯著的不同。 EVM的操作是事務性的，每次函數呼叫都需在一個事務中完全執行，而不存在傳統意義上的「非同步」概念。這意味著在Solidity中一次函數呼叫開始直到結束，都是原子性的，不能被其他事務中斷。
-
沒有引用外部資料的能力。雖然有類似Chainlink這種預言機，但不論是從集成角度還是數據調用角度看，其易用性與直接通過https請求來獲取數據調用有天壤之別，並且這又讓開發者增加了額外的集成負擔和依賴。
-
擴展性和效能限制。遊戲邏輯必須被簡化或分解成多個簡單的交易，以避免單一交易的gas費變得過高或超出最大限制，這限制了複雜互動和功能的實現。
3.資料儲存與呼叫的限制
-
智能合約的儲存空間昂貴且設計有限，不適合儲存大量遊戲資料。
-
可能需要用事件日誌間接追蹤遊戲狀態，而事件的抓取可能並不穩定。諸如何時刷新遊戲狀態等問題，常常需要玩家或遊戲運營方手動觸發。
-
EVM採用的帳戶資料結構，導致其資料索引能力很差。當你查詢某個帳戶的資料時，你只能了解其ETH或鏈原生Token的餘額，但其擁有哪些ERC-20資產、每種資產的餘額是多少，無法直接獲知。對於NFT也是一樣的道理。這些資訊都封裝在每種資產的專屬合約中，而不是在使用者自己的帳戶下儲存。
我們能夠從Etherscan等工具中看到某個地址具有何種token及其餘額等信息，這些都是由區塊鏈瀏覽器等周邊工具索引而來，而後者要建立專屬的龐大數據庫，完整爬取所有的區塊資料或監聽鏈上事件，才能將鏈上的全部資料彙總歸集。
Web3開發者通常要整合類似Etherscan，NFTscan，The Graph等第三方資料提供方，甚至要為其API KEY付費。此外，這些第三方服務本質都是鏈下的資料庫，可能出現遲滯、出錯、超過呼叫限制、服務不可用等故障。
讓我們來比較一下，大多數遊戲本身的資料庫形態與區塊鏈中資料儲存方式的差異，兩者的不同是顯而易見的。大多數遊戲的資料結構完全由自己定制，有良好的表達和索引能力，不需要依賴任何第三方服務。
4.與現有遊戲資產整合的困難
現有的遊戲資產（例如道具和角色）通常不是在區塊鏈上創建和管理的。將這些資產遷移到區塊鏈上，通常將通用但長尾的資料類型轉換成標準的NFT或Token，這涉及複雜的遷移和整合工作，會影響現有的遊戲經濟系統。
5.升級、補丁與防災
在以太坊上，智慧合約一旦部署後，程式碼就是不可變的，這使得升級和修補程式比傳統軟體更為複雜。開發者經常使用代理合約或版本化模式來繞過此限制，但這增加了整體結構的複雜度，代理合約在使用時需要格外小心，以免儲存槽衝突導致資料損壞。另外，管理權限外洩風險也很嚴峻。
傳統遊戲的程式碼升級在技術構造上沒這麼複雜，唯一可能需要約束的是中心化的升級權限，這可以透過DAO等方式實現而非依賴智能合約。
並且，傳統遊戲時常會進行資料庫的快照或備份。這在平常可能不是很重要，但若遇到升級有重大bug時，可以迅速回滾數據，而這在區塊鏈上基本上是天方夜譚。即使透過重建合約的方式來對某些遊戲的資料進行回滾，如何把舊約的資料和狀態遷移到新合約，仍然很複雜。
6.生態割裂與使用者體驗問題
不同的公鍊和VM，其智慧合約語言、架構、資料結構等是迥異的。在Web2中，遊戲開發者會選擇Unity等跨平台的前端引擎，可以做到一套程式碼稍加適配運行在iPhone、Android、桌面端等不同環境；後端由於不運行在用戶終端上，所以不存在跨平台問題。
而在Web3中這基本上是奢望，遷移至一個不同的鍊或VM，意味著專案整體的重構，要付出巨大成本，更何況初入Web3的開發者完全沒有經驗去選擇適合自己的生態，不論是從技術角度還是生態角度。
而在使用者體驗層面，區塊鏈互動及其複雜，先前盛極一時的帳戶抽象概念，正是為了解決web3用戶體驗問題而湧現，在此不做過多贅述。
羅列完上述6大論點，我們總結一下：web2 to web3的開發者面臨著巨大的適應門檻，如果他們是web2中的頂尖開發者，完全沒必要拋棄web2中的事業不做，去web3這麼一個陌生的環境裡拓展一些不知道能不能成功的事業。
可以說，頂尖的遊戲開發者大多沒有進入Web3，某種程度上，這使得Web3遊戲大多偏向金融投機，而不具備特別高的可玩性和樂趣。
用戶面也存在著同樣性質的障礙，Web3遊戲一系列阻礙用戶轉換率的操作步驟，導致Web2龐大的用戶群沒有意願體驗甚至完全不知道Web3遊戲的存在。
有沒有一種infra等級的專案能夠解決上述問題呢？ Tabi Chain可能是非常接近Web3遊戲終極解決方案之一的項目，其核心概念是「全能執行層」（Omni Execution Layer）：開發者無需再關心各種VM或運行環境的區別，直接使用自己熟悉的、甚至是可以自訂的運作環境，直接開發或移植的遊戲。
除此之外，Tabi Chain還擁有模組化的共識、安全層等特性，一切都是模組化和可客製化的，以滿足不同遊戲和應用的需求。
全能執行層：依照開發者需求來選擇執行環境
讓我們來回想一下，區塊鏈的本質是什麼。有人可能會說是去中心化的不可竄改的帳本。但如果更接近技術本質來說，應該說是：狀態機在分散式網路中的可驗證的永久狀態同步。
也即，區塊鏈實際上是在維護一個全網公認的狀態機和其運作的狀態：
-
每一次輸入都是確定的，被記錄在每個區塊中；
-
狀態轉換函數是確定的，具體表現為區塊鏈客戶端中的VM或運行時；
-
狀態的輸出也是確定的，也被記錄在每個區塊中；
因此，一個鏈的共識體系中，並不一定只能存在一種執行層（如只有EVM），不論多寡，只要這條鏈能驗證其上多個執行層的狀態，讓每個遊戲都運行在在自己的環境中，就可以解決我們上面所說的種種問題。
在Tabi中，每個遊戲或dApp可以建立自己獨立的一個Service。所有Service將各自產生的區塊提交至鏈的共識系統內；Supervisor Nodes中包含了所有Service中的執行時間/VM，來校驗service區塊的狀態。
在Tabi的全能執行層的核心可以看做一個具有多態性能力的VM，因此叫做Polymorphism VM。
對於已有的區塊鏈VM而言，Polymorphism VM需要將該VM囊括入自身的運作環境中，並提供對應的介面呼叫方法。 「囊括」這個概念在這裡有兩種具體的實現：
共享世界狀態：類似Ethermint，在Cosmos上提供了對EVM的支援。但EVM只是一個表層，專注於使用者互動、合約操作等，讓所有的使用者側的操作看起來是在EVM上實現的。但這些操作最終的結果和數據，還是會儲存在其他Cosmos模組中。所以這種EVM相容性其本質是最底層資料的映射。
因此這種映射關係，也可以拓展到其他VM上，例如Ethermint可以再加一層SVM的模組，這層SVM和EVM其實對應的都是一份底層資料。
這就類似於在PC上使用VMWare來啟動一台Windows虛擬機，VMWare不僅可以存取虛擬機內部的虛擬硬碟，也可以存取實體電腦的硬碟。如果此時再啟動一台Mac的虛擬機，它也可以用同樣的方式來掛載實體磁碟中的資料。這樣其實就實現了多台虛擬機器對同一個世界的資源與狀態的共享。
Tabi Chain的Main Service的將採用這種世界狀態共享的形式。因此只要有對應VM的適配，基於該VM開發的dApp可以選擇直接部署在Main Service上而非另起一個service。
獨立世界狀態：由於不同應用和遊戲的需求迥異，有些遊戲有自訂的運行時，將所有VM大一統地透過「共享世界狀態」的方式囊括進Polymorphism VM中並不適合所有情形。因此獨立的世界狀態也是需要的，這種實作方式相對簡單，對資料完全對立的Service而言也是最契合的。
但不論採用何種形式，都必須能被Supervisor Nodes進行驗證，也即Polymorphism VM中包含了所有實作方式的VM或Runtime。
Web2遊戲移植案例
Polymorphism VM具有高度的可自訂性，特別是對於Web2開發者來說，他們可以使用自己熟悉的語言和框架，將任何業務邏輯移植到Polymorphism VM上。
假設Minecraft現在想要移植到Tabi，大致的流程是：
-
稍微修改Minecraft服務端程式碼（Java，其他語言同理），將需要上鍊的資料移到一個資料庫（或一組）中，並將所有可能導致該DB發生變化的函數（也即狀態轉換函數）也挑選出來。
-
將該資料庫和這些函數，打包為一個JAR包，可以理解為Java的一種可執行程式。最後再加上JRE也即Java的運作環境。這一整體加載入Polymorphism VM中，最終其所有資料都會上鍊。
-
將其他與上鍊無關的後端邏輯（如組隊、聊天等）將運行在鏈下伺服器中。
-
在Tabi Chain中啟動一個Service，並通知Supervisor Nodes中的Polymorphism VM載入相同的JRE。
至此所有的流程就結束了。
對開發者而言這些改動是在原有的Java語言和框架下完成的。對於任何其他開發方式的遊戲也是同樣的道理。對使用者而言遊戲的互動也沒有明顯的改變。顯然，這種移植Web2遊戲的方式非常迅速且高效，有可能成為Web3遊戲mass adoption的基礎範式。
遊戲STR狀態轉換函數細節
上述例子是Web2遊戲移植的大致流程。我們還需要對細節了解更多。這次我們用通用的而非具體某個遊戲的例子來展示，全能執行層中的運行時會涉及到的細節。
基本上，客製化一個遊戲的運作環境可以被視為在區塊鏈上創造某個遊戲的狀態機，在Tabi中叫做State Transition Runtime。
STR可以透過以binary或module的形式整合入Polymorphism VM。
在類似區塊鏈的系統中，我們需要確保輸入的透明度、狀態轉換的公開可見性以及全局狀態的表達能力。為了滿足這些需求，我們需要建置具有以下特性的執行時間：
-
世界資料庫（World DB）包含應用程式內需要記錄在區塊鏈上的所有用戶資料。這些數據應該是有價值和重要的，因此需要一種類似區塊鏈的結構來確保其可用性。因此，並非所有數據都需要記錄在區塊鏈上。例如，在遊戲中，使用者的聊天內容一般並不重要是可丟棄的，因此不需要放在區塊鏈上。
-
它能夠表達完整的世界狀態。在許多場景中，例如在遊戲中，這種表達不一定意味著高度的可追蹤性——一個簡單的累加器就足夠了，這意味著像默克爾樹這樣的資料結構並不總是必需的。然而，無論使用什麼樣的資料結構來代表世界狀態，至關重要的是世界資料庫的世界狀態可以以摘要形式表達。
-
任何可以引起世界資料庫變化的功能稱為狀態轉換函數，並且應該封裝在狀態轉換運行時中。任何在運行時之外對世界資料庫的修改都應該被視為非法並拒絕。
-
輸入和輸出介面應該符合Input Interpreter和Block Proposer的設計。這一點相對簡單，在這裡不做詳細說明。
下列組織架構是該STR中不可或缺的一些內容。 Tabi預設會提供一個SDK來方便開發者製作該運行時。
World DB
在實踐中，遊戲或應用程式很可能會使用不只一個資料庫，而這些資料庫可能是不同的類型。讓我們假設特定的遊戲同時使用了關係型資料庫和鍵值型資料庫。
以下是一個簡單的關係型資料庫的範例：
-
UID：代表一個唯一的用戶，它可以是公鑰或其他識別碼。
-
Nonce：用於預防重播攻擊。
-
額外資料欄位：任意類型的資料。
這是一個簡單的鍵值資料庫：
狀態轉換函數
這是一個簡單的狀態轉換函數。當這個函數接收到使用者的輸入時，它簡單地將其乘以5並修改關係型資料庫中的資料。
世界狀態累加器
我們可以建立一個非常簡單的哈希累加器來表示世界狀態：
A_s+1 = hash(A_s + hash(query))
透過這樣的構造，可以確保在對世界資料庫進行任何修改之後，總會有一個唯一且確定的狀態與那次修改操作對應。
需要注意的是，這意味著每個狀態轉換函數都必須實作這個方法。這個要求可以透過使用修飾符、介面、鉤子或其他使用的語言特有的邏輯來強制實施。由於不同的語言有不同的特點，這裡不討論具體細節。
鍵值資料庫（KVDB）的更新過程也是相同的。
隨機數
任何狀態轉換函數中不應出現隨機數，否則會導致不同的驗證者驗證時產生不同的結果，而導破壞一致性。隨機數字應該被納入系統輸入參數之中。
總結
透過上面的兩個例子我們可以發現，Tabi Chain的全能執行層，以模組化的方式為遊戲開發者提供了極大的靈活性。由於篇幅所限我們無法在此將所有細節展開討論，但上述核心內容已經足夠論證Tabi Chain的解決方案是非常實用且新奇的。
在原有的Web3體系下，不同鏈、VM上開發的作品基本上不具備可移植性；Web2遊戲想要進入Web3基本上等於重寫，並且是用開發者非常陌生的語言與環境，並且受到各種難以理解的限制。
在Tabi中，開發者使用原有的語言、開發平台、引擎，只需要像呼叫SDK一樣做簡單的適配與修改，就可以將自己的作品帶入區塊鏈世界中。這種效率的提升與複雜度的降低都是指數級的。
我們期待其能為Web3遊戲的mass adoption的奇點，吸引到Web2優秀的遊戲開發者，為Web3帶來具有真正娛樂價值和可玩性的遊戲。
