Smart Contracts vs Centralized Backend

Post Material after WASM conference 2022

Intro

In this article, I want to overview the usage of smart contracts as the alternative for a centralized backend in general-purpose applications (and particularly in gaming).

An important note here — I’ll talk about the smart contracts as a particular case of the decentralized architecture, but in most cases given info will be also applicable for the other solutions, e.g. blockchains with built-in custom logic.

So, we will start with the application architecture. Traditionally it can be divided into two significant parts — frontend (or client) and backend. It should be mentioned here to underline that the client’s purpose is to show the convenient interface, stunning pictures, and so on, but the backend is fully responsible for all application logic and data. And this is the reason why we should maximally care about how it is working and who owns all data and control.

So what problems centralized backend is causing? Here is the set of the most typical ones:

• User has no direct control
  In centralized systems, controlling authority has root control of users’ assets and behavior. New backend code can be deployed without notifying the users, a database could be read/rewritten, and so on. Users always should trust the organization without having the possibility to verify it.
• Single point of failure
  A centralized backend always had a server where it’s running, whose failure will lead to the failure of the whole system. Obviously, some approaches are trying to solve this, but centralized system design always has this problem, so can be sensitive to various types of attacks.
• Privacy of your data
  This point is the particular instance of the first point — control. As your data is in full control of the organization nobody could guarantee its privacy. It can be compromised, or even the organization can decide to make something you’re not expecting with this data.

Smart contracts as a solution

After we’ve defined the problems, we can look at the smart contract and decentralized architecture as the solution to solve these problems. Let’s consider the value that it can bring vs a centralized backend:

• User always keeps his control (vs organization keeps control)
  Unlike centralized systems, where the controlling authority has root control of users’ assets and behavior, blockchain allows every user to be truly in full control. The user fully controls wallet balance, transactions, and any other actions — no authority can put any restrictions on the above.
• Permissionless and open (vs closed and should be trusted)
  All your activity on a blockchain is bonded only with your wallet address. No documents or any other verification of your real identity. And at the same time everything in the system is open — starting from the source code and up to transactions history, so you can personally verify everything in this space.
• Unstoppable (vs single point of failure)
  Thanks to the decentralized architecture, the blockchain does not have a server which failure will lead to the failure of the whole system. Such systems are much more sustainable and share the responsibility of maintaining the system between its users — persons who have the most interest in keeping it stable

But like any other solution, the usage of smart contracts also has its cons and pitfalls.

• Every decision point should be automated or replaced by DAO
  Actually, for users, it’s not a con, but it’s required much more work on the development side, new approaches in a system design, and additional attention from the user’s side — to maintain the system. But mostly, this point is here because the ecosystem is young and it’s up to builders (like the Asylum team, where we’re developing the ecosystem for games) to develop it and create useful tools and approaches to the make ecosystem better.
• Scalability
  One of the main problems of blockchains that we have for now is scalability. High transaction fees, high latency — all this stuff makes smart contracts not suitable for many use cases. But looking at how much attention and efforts are now focused on this problem I think we can hope for it to be solved soon.
• “Intellectual rights”
  As the code of smart contracts is open — you can not feel it as your property because it has no protection from being cloned and deployed by someone else. Due to this point, smart contracts can be not suitable for some organizations that rely on proprietary software.

And after such an overview, I want to take a quick look at the possible scenarios for smart contract usage. Obviously, we will skip the DeFi scenarios here because they are the primary purpose of smart contracts.

• Marketplaces
  One of the good examples is where we can use a decentralized backend. And here I am talking not only about NFT marketplaces but also about the ones with real-world assets. Not a lot of transactions — so fees and latency are not so important, but the importance of control for your assets and actions is high.
• Government services
  Here we are discovering the need for an unstoppable and open system, where every action is clear and no possibility of cheating. And here the fees and latency are also not so important due to the low number of transactions.
• Gaming
  Gaming is always about modeling some virtual world with some rules, so its sustainability, absence of the godlike admins, fair p2p interactions, and other features of decentralizations are making this world more and more attractive for users to play. We will focus on it onward.
• General-purpose apps
  Besides the mentioned scenarios smart contracts can also be a good solution in many other cases, mostly in apps that require fair and clear processes in it.

Decentralized backend in gaming

As it was said gaming is one of the areas where a transition to decentralized architecture is very suitable. As it is about creating worlds — we are talking about the life-like experience, and in real life, we see that democracy and freedom are the principles most valued in a healthy society.

And after we considered the cons of centralized architecture in general, let’s see what effects it can bring to the gaming:

• No real Assets ownership
  Digital assets bought or earned via gameplay cannot be normally exchanged on secondary markets for real-world money — while there currently exists some under-the-desk reselling of items in some MMORPGs, like World of Warcraft, it is a risky practice that tends to go against End-Users License Agreements and leads to inglorious bans.
• No direct game control
  Vitalik Buterin, says in his bio that he “realized what horrors centralized services can bring” after Blizzard removed the damage component from his beloved warlock’s Siphon Life spell. Soon after that, he decided to quit the game.
  It’s a good example of when the absence of control of the game (like deciding what features should be added/removed, what changes are acceptable) is demotivating players to play it.
• Possible unfair gameplay
  This is a story about unfair (or unclear) pay-to-win that is appearing from time to time in many multiplayer games. As an example, a lot of players report unfair matchmaking processes in games, when if you donated more money to the game — you will be matched with a less skilled opponent, which gives you a preliminarily advantage.

So let’s get down to the usage of smart contracts in gaming, where firstly I would like to underline a few examples of how it shouldn’t be designed.

• “Centralized” code approaches
  Some games, already written on-chain, still have centralized control models. For example, there are admins (hardcoded accounts) who could make the changes to the gameplay processes. It breaks the trustless value, so it’s obviously a bad design for such systems. The obvious solution to avoid this — is to use DAO for decisions that will affect the whole game.

• Conjunction with a centralized node
  There are also a lot of cases where developers are creating nice contracts, for example, for in-game NFTs, but also writing the common backend node that is conditionally minting these NFTs (like items drop, or crafting). In addition to being related to the previous point (broken trustless), it also brokes the benefits of fault tolerance because the centralized node could be attacked and shut down or even compromised
• Non-critical computations
  Here is the obvious point, about that not everything in games’ backend logic is critical, so not everything should be written decentralized. If there is a way to bring some computation off-chain to improve user experience without breaking the principles — it’s a good idea to do it.

Finally, elaborating on the last point, I would like to share my thoughts about the balance between using centralized and decentralized approaches in games.

First of all, should be mentioned in-game assets ownership and management, that is definitely should live on-chain, but, obviously, not storage of these assets, that is okay to be off-chain to reduce the load. For this purpose could be used decentralized storages that can incentivize players to store assets to support the game. Btw, usage of NFTs for in-game items may give games much more than just true ownership. We, at the Asylum, are now working on the standard for NFT items that will allow cross-game NFTs usage, so obtaining the NFT sword in one game you will be able to use it in other similar games, extending its value and exploring more possibilities for gameplay.

As a next important point, we should consider governance, which can be both a part of the gameplay and a control point for players to decide (approve) the vector of game development and new changes. This space needs much more research work because for now there are not a lot of fully player-owned games, but by exploring the possibilities of DAO we will build much better worlds as they will reflect the players’ decisions and desires. As an initial point, we can propose on-chain versioning of every game update — client and backend — and give DAO the possibility to choose the version to keep it as a live game.

A more complicated question is about where to keep a gameplay logic — it relies highly on the peculiarities of every specific case and also on scaling possibilities of the chosen chain. As an example — the gameplay of the card game, like hearthstone, can be placed on-chain, as it has a step-by-step process and is not super demanding to transaction time. The other case is the gameplay of the shooter, like CS:GO, that obviously cannot be placed on-chain. But the blockchain gaming ecosystem is now exploring the possibilities of secure off-chain solutions for latency-demanding backends, like TEE.

And the last point — player identity, that can be moved to the blockchain as an Avatar, along with all related info, achievements, and so on, the similar way as the in-game assets.

Finalizing everything told above, the gaming can be the primary area that needs decentralization, and if you’re interested in what significant benefits it can bring — you should check out the Asylum project, which is built to ease the integration, bring the control to Players, and freedom to Creators and finally — unite all games into a single Metaverse!