jakiro
Author: Luo Benben, CTO of Tabi Chain
Introduction:Since the birth of Axie and Stepn in the previous cycle, Gamefi and full -chain games have always been one of the hotspots of the blockchain industry. This new game model is above the blockchain technology, which is ownership and value of player assets and values.In terms of transfer and the economic system, rules, and community governance in the game, it has brought a unique experience that traditional game platforms have never achieved.Although these visions sound beautiful, they are facing a problem that has never been solved:
The playability of the chain tour is generally not high, and the fun is insufficient, which is more inclined to the financial speculation. After the speculation returns decline, the user scale will shrink rapidlyEssence
Obviously, this runs counter to the development model of traditional games.The smooth development of traditional games often rely on the fun of the game mechanism, which can attract a large number of users. At the same time, the developers of the game can build a good profit path. It may also expand a series of peripherals and IPs due to their own influence.EssenceIt can be said that the entire system that has been successfully operated is positive. Players can experience the fun of the game, and often can also obtain certain economic benefits in the game and outside the game.
In contrast,The current chain tour is more based on pure returns to attract playersEssenceIn addition to weak playability, web3 games also face old -fashioned issues such as high use thresholds and cumbersome interaction processes.
What is the root of all this?Different people have different opinions.The Tabichain team believes that an important factor affecting the web3 game is an excellent traditional game developer difficult to enter the web3 ecosystem because of technology and learning costs.For those who do not understand the development of the game or software, from Web2 to Web3, it is just a narrative and environment, but the actual situation is much worse than expected.
Then we shouldHow to achieve through technology to create a more friendly environment for traditional game developers or related manufacturers?In the following, we will comprehensively analyze the problems faced by Web3 games and corresponding solutions from multiple aspects to explain how the future web3 game industry should be technically more suitable for traditional game practitioners.
The technical reasons that hinder traditional game developers enter the web3 ecology
In the previous article, we have briefly mentioned that the high technology and the high learning costs are the core factor that hinders traditional game practitioners entering the web3 ecology.
1. The difference betweenweb3 application and traditional software structure
The blockchain and the application (DAPPS) are essentially different from the traditional software architecture. It requires developers to have a new knowledge system, such as the working principle, consensus agreement, and smart contract programming model of the blockchain.Traditional game developers need to spend a lot of time to learn Solidity or other smart contract languages, and need to understand EVM working methods.
In addition, traditional game logic is usually executed on a centralized server, which can flexibly handle complex game status and high -frequency interaction.Run the game logic on the blockchain requires high simplification or reconstructionBecause each operation must be released in a distributed network, and then the chain is on, which is seriously limited by the performance and cost of the blockchain.
2.智能合约的设计限制
EVM虽然满足图灵完备，理论上可以表达任意逻辑，但其特性非常不利于游戏开发，例如：
-
Lack of timer.All the operations on the Ethereum chain must be triggered by the EOA account.In order to achieve the effect similar to the timer, developers need to deploy an additional service to maintain an EOA account and event list to manually trigger the timing task.Due to the delay in the chain, these timing tasks cannot be completed on time.
>
-
There is no callback and other mechanisms, and do not support multi -threading and asynchronous.Because Solidity is designed for the development of Ethereum smart contracts, its execution environment is significantly different from the traditional runtime environment.The operation of EVM is transactional. Each function call needs to be fully executed in one transaction without existing the concept of “asynchronous” in the traditional sense.This means that a function call in Solidity starts until the end of the end. It is atomic and cannot be interrupted by other transactions.
-
There is no ability to quote external data.Although there is a prophetic machine like ChainLink, whether it is from the perspective of integration or data calling, its ease of use and direct HTTPS request can obtain data calls.Burded and dependence.
-
Expansion and performance restrictions.The game logic must be simplified or decomposed into multiple simple transactions to prevent the GAS fee of a single transaction from being too high or exceeding the maximum limit, which limits the realization of complex interaction and function.
3. Limit the data storage and call
-
The storage space of smart contracts is expensive and has limited design, which is not suitable for storing a large amount of game data.
-
It may need to use event logs to indirectly track the game status, and the grabbing of the event may not be unstable.How to refresh the game status and other issues often require players or game operators to trigger manually.
-
The account data structure adopted by EVM has caused their data indexing ability to be poorEssenceWhen you check the data of a certain account, you can only understand the balance of its ETH or chain-primary token, but what ERC-20 assets and balances of each asset it have, cannot be directly known.The same is true for NFT.This information is encapsulated in the exclusive contracts of each asset, not stored in the user’s own account.
>
We can see from tools such as EtherScan and other tools, what kind of information such as Token and their balances, etc. These are indexed from peripheral tools such as blockchain browsers.Only all block data or listening to the chain can collect all data on the chain.
Web3 developers usually integrated third -party data providers such as Etherscan, NFTSCAN, The Graph, and even pay for their API Key.In addition, these third -party services are the essence of databases under the chain, and there may be stagnation, errors, exceeding the call limit, and service failure.
Let’s compare the differences between the two of the game’s own database and the data storage method in the blockchain. The difference between the two is obvious.The data structure of most games is completely customized by itself. It has good expression and indexing ability, and does not need to rely on any third -party services.
>
4. The difficulty of integrating with existing game assets
Existing game assets (such as props and characters) are usually not created and managed on the blockchain.Moving these assets to the blockchain, generally converting universal but long -tailed data types into standard NFT or Token, which involves complex migration and integration work, will affect the existing game economy system.
5. Upgrade, patch and disaster prevention
On Ethereum, once the smart contract is deployed, the code is immutable, which makes the upgrade and repair programs more complicated than traditional software.Developers often use proxy contracts or version models to bypass this limit, but this increases the complexity of the overall structure. The proxy contract needs to be extra careful when using it, so as not to cause data damage to the storage slot conflict.In addition, the risk of disclosure of management authority is also severe.
The code upgrade of traditional games is not so complicated in the technical structure.The only possible that may need to be restrained is the centralized upgrade authority,This can be implemented instead of smart contracts through DAO and other methods.
In addition, traditional games often perform database snapshots or backups.This may not be important, but if there is a major bug when you encounter an upgrade, you can roll back the data quickly, and this is basically the night chain.Even if the data of certain games is rolled back by the reconstruction of the contract, how to migrate the data and status of the old contract to the new contract is still complicated.
6. Ecological splitting and user experience issues
Different public chains and VM, their smart contract language, architecture, data structure, etc. are very different.In Web2, game developers will choose the front -end engine of cross -platform such as Unity, which can achieve a set of codes slightly adapted and runs in different environments such as iPhone, Android, desktop end.There is no cross -platform problem.
In web3, this is basically extravagant hopes. Moving to a different chain or VM means that the overall reconstruction of the project must pay huge costs, not to mentionIs it from a technical perspective or ecological perspective.
At the level of user experience, the blockchain is interconnected and its complex. The previous concept of abstract account abstraction was emerging to solve the problem of web3 user experience. I won’t go into details here.
After listing the above 6 major arguments, let’s summarize: The developers of Web2 to Web3 are facing a huge adaptation threshold. If they are the top developers in Web2, there is no need to abandon the career in the web2 at all.Expand some businesses that do not know if they can succeed.
It can be said,Most of the top game developers have not entered Web3, to some extent, this makes most of the web3 games bid to financial speculation without particularly high playability and funEssence
There is also the same nature of the user’s side. A series of web3 games that hinder the conversion rate of user conversion, which causes Web2 huge user groups to experience the existence of web3 games without willingness to experience.
Is there a INFRA -level project that can solve the above problems?TABI CHAIN may be one of the projects that are very close to the ultimate solution of the web3 game. The core concept is the “omnipable execution layer”: Developers do not need to care about the differences between various VMs or operating environments, and directly develop or transplant games that they are familiar with or even can be customized.
In addition, Tabi Chain also has the characteristics of modular consensus and safety layers. Everything is modular and customized to meet the needs of different games and applications.
Almighty execution layer: according to the needs of developers to select the execution environment
Let’s recall what the essence of the blockchain is.Some people may say that it is a decentralized non -tampering ledger.But if it is closer to the essence of technology, it should be said that the verified permanent state synchronization of the state machine in a distributed network is synchronized.
That is, the blockchain is actually maintaining a state -recognized state machine and its operating status:
-
Each input is certain, recorded in each block;
-
The status conversion function is certain, which is specifically manifested as VM or running in the blockchain client;
-
The output of the state is also certain, and it is also recorded in each block;
Therefore, in the consensus system of a chain, there may not be only one execution layer (such as only EVM), no matter how much,As long as this chain can verify the state of multiple execution layers on it and let each game run in its own environment, we can solve the various problems we mentioned aboveEssence
>
In Tabi, each game or DAPP can build its own independent service.All services submit their own blocks to the consensus system of the chain; the Supervisor Nodes contains all services/vm in runtime/vm to check the status of the service block.
existThe core of Tabi’s all -around execution layer can be regarded as a VM with polymorphism, so it is called Polymorphism VM.
>
For existing blockchain VM, Polymorphism VM needs to include the VM into its own operating environment and provide the corresponding interface call method.The concept of “includes” has two specific implementation here:
Share world state:Similar to Ethermint, it provides support for EVM on COSMOS.But EVM is just a surface layer, focusing on user interaction, contract operations, etc., so that all user -side operations seem to be implemented on EVM.But the final results and data of these operations are still stored in other COSMOS modules.So this EVM compatibility is essentially the mapping of the bottom data.
Therefore, this mapping relationship can also be extended to other VMs. For example, Ethermint can add another layer of SVM module. This layer of SVM and EVM actually correspond to the underlying data.
>
This is similar to using VMware on PC to start a Windows virtual machine. VMware can not only access the virtual hard drive inside the virtual machine, but also access the physical computer hard disk.If you start a Mac virtual machine at this time, it can also mount the data in the physical disk in the same way.In this way, many virtual machines share the resources and status of the same world.
>
The Main Services of Tabi Chain will use this form of world state sharing.Therefore, as long as there is adaptation to the corresponding VM, the DAPP developed based on the VM can choose to be directly deployed on the Main Service rather than another service.
Independent world status:Due to the different needs of different applications and games, some games have customized operations, and all VM unifiedly include in the Polymorphism VM via “Share World Status” method. It is not suitable for all situations.Therefore, the independent world state is also needed. This implementation method is relatively simple, and it is also the most in line with the Service, which is completely opposed to data.
But no matter what form, it must be verified by Supervisor Nodes, that is, Polymorphism VM contains all the implementation methods VM or Runtime.
Web2 game transplantation case
Polymorphism VM is highly customized, especially for Web2 developers, they can use their familiar language and framework to transplant any business logic to Polymorphism VM.
Assuming that Minecraft wants to transplant to TABI, the general process is:
-
Slightly modify the Minecraft service side code (Java, other languages), move the data that needs to be on the chain into a database (or one group), and put all functions that may cause the DB to change (that is, the state conversion function)Also selected.
-
Packing the database and these functions as a jar package can be understood as a executable program for Java.Finally, plus JRE is the operating environment of Java.This is loaded into the Polymorphism VM as a whole, and all its data will eventually chain.
-
It will run other back -end logic (such as teams, chats, etc.) that will not be run on the server.
-
Start a service in Tabi Chain and notify the Polymorphism VM in Supervisor Nodes to load the same JRE.
-
World database (World DB)Contains all user data that needs to be recorded in the blockchain.These data should be valuable and important, so a structure similar to blockchain is required to ensure its availability.Therefore, not all data needs to be recorded on the blockchain.For example, in the game, users’ chat content is generally not important and can be discarded, so it does not need to be placed on the blockchain.
-
It can express a complete world state.In many scenarios, such as in the game, this expression does not necessarily mean a high -level traceability -a simple accumulator is enough, which means that the data structure like Merkel tree is not always necessary to always be necessaryof.However, no matter what data structure is used to represent the state of the world, it is important that the world status of the world database can be expressed as abstract.
-
Any function that can cause changes in the world database is calledStatus conversion functionAnd should be encapsulated during the state conversion.Any modification of the World Database in addition to running should be regarded as illegal and rejected.
-
The input and output interface should be in line with the designs of the Input Interpreter and Block Proposer.This is relatively simple, and I do n’t make a detailed explanation here.
-
UID: Represents a unique user, it can be a public key or other identifiers.
-
NONCE: Used to prevent override attacks.
-
Extra data field: Any type of data.
>
So far all the processes are over.
For developers, these changes are completed under the original Java language and framework.The same is true for any other development games.For users, the game’s interaction has not changed significantly.Obviously, this way of transplanting web2 games is very fast and efficient, and it may become the basic paradigm of the web3 game Mass Adoption.
Game STR status conversion function details
The above example is the general process of web2 game transplantation.We also need to learn more about details.This time we use a common rather than a specific game example to display the details that will involve in the running layer.
Basically, the operating environment of a customized game can be regarded as a state machine that creates a game on the blockchain, which is called State Transition Runtime in TABI.
>
STR can integrate into Polymorphism VM by binary or module.
In a similar blockchain system, we need to ensure the transparency of the input, the open visibility of the state conversion, and the expression ability of the global state.In order to meet these needs, we need to build the following characteristics:
The following organizational structure is an essential content in the STR.Tabi will provide a SDK default to facilitate developers to make this run.
Worldd db
In practice, games or applications are likely to use more than one database, and these databases may be different types.Let us assume that specific games use relational databases and key -value databases at the same time.
The following is an example of a simple relationship database:
>
This is a simple key value database:
>
Status conversion function
This is a simple state conversion function.When this function receives the user’s input, it simply multiply it by 5 and modify the data in the relational database.
>
World state accumulator
We can build a very simple hash tiredness to represent the state of the world:
A_S + 1 = Hash (A_S + Hash (query))
Through this structure, it can ensure that after any modification of the World Database, there will always be a only and determined state to correspond to that modification operation.
It should be noted that this means that this method must be implemented in each state conversion function.This requirement can be forced to implement by using modifiers, interfaces, hooks or other logic unique to the language.Because different languages have different characteristics, no specific details are discussed here.
The update process of key -value database (KVDB) is the same.
Random number
There should be no random numbers in any state conversion function, otherwise different results will cause different results during verification, and the consistency is guided.The random number should be included in the system input parameters.
Summarize
Through the above two examples, we can find that Tabi Chain’s all -around execution layer provides great flexibility for game developers in a modular way.Because we cannot discuss all the details here, the above core content is sufficient to demonstrate the solution of the Tabi Chain is very practical and novel.
Under the original web3 system, the works developed on different chains and VMs basically do not have transplantability; web2 games want to enter Web3, which is basically equal to rewriting, and it is a very strange language and environment that developers are very unfamiliar.Limitation of understanding.
In TABI, developers use the original language, development platform, and engine. You only need to make simple adaptation and modification like calling SDK, and he can bring his works into the blockchain world.The improvement of this efficiency and the decrease in complexity are index levels.
We look forward to its singularity for the Mass Adoption of the web3 game, attract Web2’s excellent game developers, and bring Web3 with real entertainment value and playability.
