This is clearly at odds with the development model of traditional games. Successful traditional games attract many users through engaging game mechanics, allowing developers to build profitable paths and potentially expand into related merchandise and IPs. These games operate in a positive cycle where players enjoy the game and often gain economic benefits both inside and outside the game.

In contrast, current blockchain games mainly attract players through financial returns. Besides their low playability, Web3 games also face long standing issues like high entry barriers and cumbersome interaction processes.

What is the root cause of these problems? Opinions vary. The TabiChain team believes a significant factor is that talented traditional game developers struggle to enter the Web3 ecosystem due to technical and learning barriers. For those unfamiliar with game or software development, transitioning from Web2 to Web3 might seem like just a narrative and environment shift, but the reality is much harsher.

So, how can we create a more welcoming environment for traditional game developers or related companies through technology? In the following sections, we will thoroughly analyze the challenges faced by Web3 games and their solutions, explaining how the future Web3 gaming industry can be technically tailored to better suit traditional game developers.

Technical Reasons Hindering Traditional Game Developers from Entering the Web3 Ecosystem

In the previous article, we briefly mentioned that unfriendly technology and high learning costs are the core factors that prevent traditional game practitioners from entering the web3 ecosystem. The so-called unfriendly technology and high learning costs can be expanded to the following points:

1. The difference between web3 applications and traditional software structures

Blockchain and the applications on it (dApps) are fundamentally different from traditional software architecture and require developers to have a new knowledge system, such as the working principle of blockchain, consensus protocols, smart contract programming models, etc. Traditional game developers need to spend a lot of time learning Solidity or other smart contract languages ​​and need to understand how the EVM works.

Moreover, traditional game logic is usually executed on a centralized server, which can flexibly handle complex game states and high-frequency interactions.Running game logic on the blockchain requires a high degree of simplification or refactoring, because each operation must be published to the distributed network for execution and then uploaded to the chain, which is severely limited by the performance and cost of the blockchain.

1. Design limitations of smart contracts

Although EVM is Turing complete and can theoretically express arbitrary logic, its characteristics are very unfavorable for game development, such as:

• Lack of timer.All operations on the Ethereum chain must be manually triggered by the EOA account. In order to achieve an effect similar to a timer, developers need to deploy an additional service and maintain an EOA account and event list to manually trigger scheduled tasks. Due to the delay issue on the chain, these scheduled tasks cannot be guaranteed to be completed on time.

• There is no callback and other mechanisms, and it does not support multi-threading and asynchronous.Because Solidity is designed for Ethereum smart contract development, its execution environment is significantly different from traditional runtime environments. The operation of EVM is transactional, and each function call needs to be completely executed in a transaction. There is no concept of “asynchronous” in the traditional sense. This means that a function call in Solidity is atomic from start to finish and cannot be interrupted by other transactions.
• There is no ability to reference external data.Although there are oracles like Chainlink, whether from an integration perspective or a data call perspective, its ease of use is vastly different from directly obtaining data calls through https requests, and this allows developers to add additional integrations. Burden and dependence.
• Scalability and performance limitations.Game logic must be simplified or broken down into multiple simple transactions to avoid the gas fee of a single transaction becoming too high or exceeding the maximum limit, which limits the implementation of complex interactions and functions.

1. Limitations on data storage and retrieval

• Smart contracts have expensive storage space and limited design, making them unsuitable for storing large amounts of game data.
• Event logs may be needed to indirectly track game status, and event capture may not be stable. Issues such as when to refresh the game state often require players or game operators to manually trigger it.
• The account data structure adopted by EVM results in poor data indexing capabilities.. When you query the data of an account, you can only know the balance of its ETH or chain-native token, but which ERC-20 assets it owns and the balance of each asset cannot be directly known. The same is true for NFT. This information is encapsulated in the exclusive contract of each asset, rather than being stored under the user’s own account.

We can see what kind of token and balance information a certain address has from tools such as Etherscan. These are indexed by peripheral tools such as blockchain browsers, and the latter needs to build a dedicated huge database and crawl it completely. Only by collecting all block data or monitoring events on the chain can all data on the chain be summarized.

Web3 developers usually have to integrate third-party data providers such as Etherscan, NFTscan, The Graph, etc., and even pay for their API KEY. In addition, these third-party services are essentially off-chain databases, which may cause delays, errors, exceeding call limits, service unavailability and other failures.

Let’s compare the differences between the database form of most games and the data storage methods in the blockchain. The difference between the two is obvious. The data structure of most games is completely customized by itself, has good expression and indexing capabilities, and does not need to rely on any third-party services.

1. Challenges in integrating existing game assets with blockchain

Existing game assets (such as props and characters) are typically not created and managed on the blockchain. Migrating these assets to the blockchain usually involves converting common but long-tail data types into standard NFTs or Tokens, which involves complex migration and integration work and will affect the existing game economic system.

1. Upgrades, patches and disaster prevention

On Ethereum, once a smart contract is deployed, the code is immutable, making upgrades and patches more complex than traditional software. Developers often use proxy contracts or versioning patterns to circumvent this limitation, but this increases the complexity of the overall structure. Proxy contracts need to be used with special care to avoid data corruption caused by storage slot conflicts. In addition, the risk of administrative rights leakage is also serious.

The code upgrade of traditional games is not so complicated in terms of technical structure.The only thing that may need to be restricted is the centralized upgrade authority.This can be achieved through methods such as DAO rather than relying on smart contracts.

Moreover, traditional games often take database snapshots or backups. This may not be very important usually, but if you encounter a major bug in the upgrade, you can quickly roll back the data, which is basically a fantasy on the blockchain. Even if some game data is rolled back by rebuilding the contract, how to migrate the data and status of the old contract to the new contract is still complicated.

1. Ecological fragmentation and user experience issues

Different public chains and VMs have completely different smart contract languages, architectures, data structures, etc. In Web2, game developers will choose cross-platform front-end engines such as Unity, which can make a set of codes slightly adapted to run in different environments such as iPhone, Android, and desktop. Since the back-end does not run on the user terminal, There are no cross-platform issues.

In Web3, this is basically a luxury. Migrating to a different chain or VM means reconstructing the entire project and incurring huge costs. What’s more, developers who are new to Web3 have no experience at all to choose an ecosystem that suits them. Is it from a technical perspective or an ecological perspective?

At the user experience level, blockchain interactions are extremely complex. The account abstraction concept that was so popular before emerged precisely to solve web3 user experience problems, so I won’t go into details here.

After listing the above 6 major arguments, let us summarize: developers from web2 to web3 face a huge adaptation threshold. If they are top developers in web2, there is no need to abandon their career in web2 and go to a stranger like web3. In this environment, we are developing some businesses that we don’t know whether they can be successful or not.

It can be said,Most of the top game developers have not entered Web3. To some extent, this makes most Web3 games biased towards financial speculation rather than having particularly high playability and fun.

Obstacles of the same nature also exist on the user side. Web3 games have a series of operation steps that hinder user conversion rates, resulting in a huge user group of Web2 who are not willing to experience or even completely unaware of the existence of Web3 games.

Is there an infra-level project that can solve the above problems? Tabi Chain may be a project very close to one of the ultimate solutions for Web3 games. Its core concept is the “Omni Execution Layer”: Developers no longer need to care about the differences between various VMs or operating environments. They can directly use their familiar or even customizable operating environments to directly develop or port games.

In addition, Tabi Chain also has modular consensus, security layer and other features. Everything is modular and customizable to meet the needs of different games and applications.

Omni-Execution Layer: Selecting the Execution Environment Based on Developer Needs

Let’s revisit the fundamental concept of blockchain. While some might describe it as a decentralized, immutable ledger, it is more accurately defined as the verifiable synchronization of a state machine’s permanent state within a distributed network.

In essence, the blockchain maintains a universally accepted state machine and its operational status:

• Each input is deterministic, recorded in every block;
• The state transition function is deterministic, represented by the VM or runtime within the blockchain client;
• The output state is also deterministic, recorded in every block;

Thus, a blockchain’s consensus system does not need to be limited to a single execution layer (such as only EVM). Regardless of the number of execution layers, as long as the chain can verify the states across multiple layers, allowing each game to operate in its own environment, we can address the various issues previously discussed.

In Tabi, each game or dApp can build its own independent Service. All Services submit their own generated blocks to the chain’s consensus system; Supervisor Nodes include the runtime/VM in all Services to verify the status of service blocks. existThe core of Tabi’s all-round execution layer can be regarded as a VM with polymorphic capabilities, so it is called Polymorphism VM.

For existing blockchain VMs, a Polymorphism VM needs to integrate these VMs within its runtime environment and provide the necessary interface calling methods. The concept of “integration” here can be implemented in two ways:

Shared World State: Similar to Ethermint, which supports EVM on Cosmos. The EVM acts as a surface layer, focusing on user interactions and contract operations, making all user-side activities appear to be executed on the EVM. However, the final outcomes and data of these operations are stored in other Cosmos modules. Thus, this EVM compatibility is essentially a mapping of the underlying data.

This mapping relationship can be extended to other VMs as well. For example, Ethermint can incorporate an additional SVM module layer, where both the SVM and EVM correspond to the same underlying data.

This is akin to using VMWare on a PC to run a Windows virtual machine. VMWare can access both the virtual machine’s virtual hard drive and the physical computer’s hard drive. If you then start a Mac virtual machine, it can mount the data from the physical disk in the same manner. This setup effectively enables multiple virtual machines to share the resources and state of the same environment.

Tabi Chain’s Main Service will use a shared world state approach. This means that as long as the corresponding VM is adapted, dApps developed for that VM can be deployed directly on the Main Service without needing to create a separate service.

Independent World State: Different applications and games have unique requirements, and some games use custom runtimes. Therefore, a universal approach of integrating all VMs through a “shared world state” in the Polymorphism VM is not suitable for every case. An independent world state is also necessary, as it is simpler to implement and ideal for services with entirely separate data.

Regardless of the approach used, it must be verifiable by Supervisor Nodes. This means that the Polymorphism VM must include all VMs or runtimes used by the various implementation methods.

Web2 Game Porting Example

The Polymorphism VM is highly customizable, making it particularly beneficial for Web2 developers. They can use familiar languages and frameworks to port any business logic to the Polymorphism VM.

Suppose Minecraft wants to port to Tabi. The general process would be as follows:

1. Modify the Server Code: Slightly modify the Minecraft server code (Java or any other language), moving the data that needs to be on-chain to a database (or a set of databases). Identify and select all functions that might alter this database (i.e., state transition functions).
2. Package the Components: Package this database and these functions into a JAR file, which is an executable program in Java. Include the JRE (Java Runtime Environment) in this package. This entire package is then loaded into the Polymorphism VM, ensuring all data is on-chain.
3. Run Off-Chain Logic: Run other backend logic that doesn’t need to be on-chain (such as team formation, chat, etc.) on off-chain servers.
4. Start a Service: Initiate a Service in Tabi Chain and notify the Supervisor Nodes’ Polymorphism VM to load the same JRE.
   

With this, the entire process is complete.

For developers, these modifications are made within the existing Java language and framework. The same concept applies to games developed using any other method. For users, the game interaction remains largely unchanged. Clearly, this method of porting Web2 games is very fast and efficient, potentially becoming the foundational model for the mass adoption of Web3 games.

Details of the Game STR (State Transition Runtime) Functions

The previous example provided a general overview of porting a Web2 game. To gain a deeper understanding, we need to delve into more details. This time, we will use a general example instead of a specific game to illustrate the details involved in the runtime of the Omni-Execution Layer.

Essentially, customizing a game’s runtime environment can be viewed as creating the game’s state machine on the blockchain, referred to as the State Transition Runtime (STR) in Tabi.

The above example is the general process of Web2 game porting. We still need to know more about the details. This time we use a general example rather than a specific game example to show the details involved in the runtime in the omnipotent execution layer.

Basically, customizing a game’s running environment can be regarded as creating a state machine for a certain game on the blockchain, which is called State Transition Runtime in Tabi.

STR can be integrated into Polymorphism VM in the form of binary or module.

In a blockchain-like system, we need to ensure transparency of inputs, public visibility of state transitions, and expressiveness of global state. To meet these requirements, we need to build a runtime with the following features:

1. World DBContains all user data within the application that needs to be recorded on the blockchain. This data should be valuable and important, so a blockchain-like structure is needed to ensure its availability. Therefore, not all data needs to be recorded on the blockchain. For example, in games, the user’s chat content is generally not important and is disposable, so there is no need to put it on the blockchain.
2. It can express the complete state of the world. In many scenarios, such as in games, this expression does not necessarily imply a high degree of traceability - a simple accumulator will suffice, which means that a data structure like a Merkle tree is not always necessary. However, no matter what data structure is used to represent the world state, it is crucial that the world state of the world database can be expressed in summary form.
3. Any function that can cause changes to the world database is called state transition function, and should be encapsulated in the state transition runtime. Any modification to the world database outside of runtime should be considered illegal and rejected.
4. Input and output interfaces should conform to the design of Input Interpreter and Block Proposer. This is relatively simple and will not be explained in detail here.

The following organizational structures are essential elements of this STR. Tabi will provide an SDK by default to facilitate developers to create the runtime.

World DB

In practice, a game or application will most likely use more than one database, and these databases may be of different types. Let’s assume that a particular game uses both a relational database and a key-value database.

The following is a simple relational database example:

1. UID: Represents a unique user, which can be a public key or other identifier.
2. Nonce: used to prevent replay attacks.
3. Extra data fields: any type of data.

This is a simple key-value database:

State Transition Function

This is a simple state transition function. When this function receives input from the user, it simply multiplies it by 5 and modifies the data in the relational database.

World State Accumulator

We can construct a simple hash accumulator to represent the world state:

A_s+1 = hash(A_s + hash(query))

This method ensures that after any modification to the world database, there will always be a unique and definite state corresponding to that modification.

It’s important to note that every state transition function must implement this method. This requirement can be enforced using modifiers, interfaces, hooks, or other language-specific mechanisms. Due to the different characteristics of various programming languages, we will not delve into specific details here.

The update process for a key-value database (KVDB) follows the same principle.

Random Numbers

State transition functions should not include random numbers, as this would cause different results when validated by different verifiers, breaking consistency. Random numbers should be included as part of the system input parameters.

Summarize

From the above examples, we can see that Tabi Chain’s Omni-Execution Layer provides game developers with significant flexibility through a modular approach. Due to space constraints, we cannot discuss all the details here, but the core points mentioned are enough to demonstrate that Tabi Chain’s solution is both practical and innovative.

In the current Web3 ecosystem, works developed on different chains and VMs generally lack portability. For Web2 games to transition to Web3, it often means rewriting the game in unfamiliar languages and environments, facing various incomprehensible restrictions.

With Tabi, developers can use their original language, development platform, and engine. They only need to make simple adaptations and modifications, similar to calling an SDK, to bring their projects into the blockchain world. This results in exponential improvements in efficiency and reductions in complexity.

We hope Tabi Chain can become a catalyst for the mass adoption of Web3 games, attracting talented Web2 game developers and bringing truly entertaining and playable games to the Web3 space.

Disclaimer：

1. This article is reprinted from [极客 Web3]. All copyrights belong to the original author [罗奔奔]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.