導語：自上一輪週期中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，大致的流程爲：

1. 略微修改Minecraft服務端代碼（Java，其他語言同理），將需要上鏈的數據移動到一個數據庫（或一組）中，並將所有可能導致該DB發生變化的函數（也即狀態轉換函數）也挑選出來。
2. 將該數據庫和這些函數，打包爲一個JAR包，可以理解爲Java的一種可執行程序。最後再加上JRE也即Java的運行環境。這一整體加載入Polymorphism VM中，最終其所有數據都會上鏈。
3. 將其他與上鏈無關的後端邏輯（如組隊、聊天等）將運行在鏈下服務器中。
4. 在Tabi Chain中啓動一個Service，並通知Supervisor Nodes中的Polymorphism VM加載相同的JRE。

至此所有的流程就結束了。

對開發者而言這些改動是在原有的Java語言和框架下完成的。對於任何其他開發方式的遊戲也是同樣的道理。對用戶而言遊戲的交互也沒有明顯的改變。顯然，這種移植Web2遊戲的方式非常迅速和高效，有可能成爲Web3遊戲mass adoption的基礎範式。

遊戲STR狀態轉換函數細節

上述例子是Web2遊戲移植的大致流程。我們還需要對細節了解更多。這次我們用通用的而非具體某個遊戲的例子來展示，全能執行層中的運行時會涉及到的細節。

基本上，定制一個遊戲的運行環境可以被視爲在區塊鏈上創建某個遊戲的狀態機，在Tabi中叫做State Transition Runtime。

STR可以通過以binary或module的形式集成入Polymorphism VM。

在類似區塊鏈的系統中，我們需要確保輸入的透明度、狀態轉換的公開可見性以及全局狀態的表達能力。爲了滿足這些需求，我們需要構建具有以下特性的運行時：

1. 世界數據庫（World DB）包含應用內需要記錄在區塊鏈上的所有用戶數據。這些數據應該是有價值和重要的，因此需要一種類似區塊鏈的結構來確保其可用性。因此，並非所有數據都需要記錄在區塊鏈上。例如，在遊戲中，用戶的聊天內容一般並不重要是可丟棄的，因此不需要放在區塊鏈上。
2. 它能夠表達完整的世界狀態。在許多場景中，比如在遊戲中，這種表達不一定意味着高度的可跟蹤性——一個簡單的累加器就足夠了，這意味着像默克爾樹這樣的數據結構並不總是必需的。然而，無論使用什麼樣的數據結構來代表世界狀態，至關重要的是世界數據庫的世界狀態可以以摘要形式表達。
3. 任何可以引起世界數據庫變化的功能被稱爲狀態轉換函數，並應該封裝在狀態轉換運行時中。任何在運行時之外對世界數據庫的修改都應該被視爲非法並拒絕。
4. 輸入和輸出接口應該符合Input Interpreter和Block Proposer的設計。這一點相對簡單，在這裏不做詳細說明。

下列組織結構是該STR中必不可少的一些內容。Tabi默認會提供一個SDK來方便開發者制作該運行時。

World DB

在實踐中，遊戲或應用程序很可能會使用不止一個數據庫，而這些數據庫可能是不同的類型。讓我們假設特定的遊戲同時使用了關係型數據庫和鍵值型數據庫。

以下是一個簡單的關係型數據庫的例子：

1. UID：代表一個唯一的用戶，它可以是公鑰或其他標識符。
2. Nonce：用於預防重放攻擊。
3. 額外數據字段：任意類型的數據。

這是一個簡單的鍵值數據庫：

狀態轉換函數

這是一個簡單的狀態轉換函數。當這個函數接收到用戶的輸入時，它簡單地將其乘以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帶來有真正娛樂價值和可玩性的遊戲。

聲明：

1. 本文轉載自[極客 Web3]，著作權歸屬原作者[羅奔奔]，如對轉載有異議，請聯系Gate Learn團隊，團隊會根據相關流程盡速處理。
2. 免責聲明：本文所表達的觀點和意見僅代表作者個人觀點，不構成任何投資建議。
3. 文章其他語言版本由Gate Learn團隊翻譯， 在未提及Gate.io的情況下不得復制、傳播或抄襲經翻譯文章。