Critical Overview of ULTRA

Article credited to Dexaran and provided by EOS GO

Recently, I reviewed one of the upcoming projects based on EOSIO - Ultra (UOS). Ultra is positioned as "the blockchain for the game development industry". I also participated in a discussion with the developers.

I think that some uncertainty should be dispelled and some points related to this project clarified.

What are blockchain games?

Traditionally, multiplayer games are client-server applications. This approach introduces the following problems:

• (1) Servers are centralized and they are the fault point of the game structure. Servers are prone to censorship and multiple types of attacks. Any party that has access to the game servers have an ability to affect/modify everything in-game objects and the whole system is based on "gentleman agreement" that these parties will not hurt players interests.

• (2) Servers have zero auditability and transparency. Since it is not known what is going on at the game servers in most cases it opens opportunities for fraud and unverifiable cheating and bug exploiting.

• (3) Servers are prone to downtime. Since game servers are the central point of the game’s workflow, all players will be affected if there are some server-side issues.

• (4) Distribution issues. Client-server games usually need a third party to manage the distribution, anti-cheating, player account management. (This is not always the issue and some large companies can deal with it on their own)

• (5) Server maintenance. Maintaining a server for games is a separate task. It should be noted that this task is simplified by smart contracts since the entire upkeep of the "server" game logic can be programmed in the logic of the smart contract itself.

Some blockchain-based application development platforms offer the possibility to develop smart-contracts - decentralized applications that run exactly as programmed within the blockchain ecosystem. Smart-contracts can replace centralized game servers in theory.

Those games whose server logic is fully implemented in smart contracts are not affected by the above mentioned problems. (1) In some cases smart-contract developers still have the ability to modify the smart-contract but this cannot be done unnoticed. There will be a record of smart-contract modification attempt written in blockchain. If some party that shouldn't have access to the smart-contract will attempt to modify it then it will be known and transparently available for verification. (2) The workflow of smart-contract is transparent and verifiable. The input of each player is known at any moment of time. If some player will cheat or exploit an in-game bug then it will be reviewable. (3) Smart-contracts rely on the underlying platform capabilities to run them without any downtime. If the smart-contract development platform is capable of running contracts smoothly then smart-contracts are no longer prone to downtime. (4) Smart-contracts are publicly available for anyone. The smart-contract development platform is a distribution platform at the same moment. (5) In Ethereum smart-contract are paid upon creation. After that they are intended to run eternally. In EOS smart-contract can implement its upkeep in its internal logic.

Blockchain games are typically referenced as DAPPs but not all the games that use this cool words "blockchain" or "EOS" are DAPPs in fact. It should be noted that those games or applications that still have some critical part of their logic implemented in off-chain have no advantages of decentralized applications.

Example: Imagine a casino implemented in smart-contracts. If you can sign up, log in, deposit/withdraw funds, exchange it into casino tokens and play via the smart-contract but the results of each game are determined by the Random Number Generator (RNG) that is implemented in off-chain layer then you can never know if the game was fair or not. You can't verify if the RNG is generating truly random numbers or it is settlet so that you have less chances to win than expected. You can't verify if the RNG part was modified right before you played. This negates all the advantages of having other parts of logic implemented on-chain.

EOSIO is not suitable for building and running most types of games

Despite all the advantages of decentralization and smart contracts, they also have disadvantages that seriously complicate the development of fully decentralized on-chain games.

The most important shortcomings of EOS and its smart-contracts are:

• On-chain source of entropy. This makes it almost impossible to implement a Random Number Generator in EOS contracts. Most games require randomness in one form or another. This is one of the most important problems of EOS when talking about on-chain games and gambling applications.

• Privacy. It is almost impossible to hide data in EOS smart-contracts. This is a huge problem for most games. In games, information about the state of the game world is a kind of valuable resource. Many games would lose an important component if all players knew everything about the state of the game world at any given time. (For example the "exploration" component of 4X games would be disposed completely) NOTE: some could argue that privacy is contrary to verifiability and transparency. In case of on-chain games eternal privacy is not required. The data should be hidden for as long as it is relevant and valuable. This means that the game data can be hidden during the game session and then disclosed upon completion of the session. This will ensure both verifiability and hiding valuable data for as long as it is valuable at the same time.

• Continuous processes. In EOS it is impossible to make contract update its state automatically at certain moment of time or schedule some actions in the future. Deferred transactions were used to make contract perform an action at the future point of time, however deferred transactions are now deprecated. This makes it problematic to deal with regularly-scheduled maintenance tasks when developing a smart-contract game. In most cases the game must update its state regularly.

• Performance. This looks like this is the least of the EOS problems but it is worth mentioning that performance of a typical game server is still out of reach for any smart-contracts. Developing an on-chain smart-contract game is much more expensive compared to implementing the game logic in "game server" layer.

• Resource management and UX. It should be noted that DAPP developers have to worry about resource management and how their users will struggle with it. NOTE: DAPPs can't pay for their users resources. Only centralized apps can. ONLY_BILL_FIRST_AUTHORIZED requires co-signing of a transaction which requires a server layer which renders application a standard client+server app. Read the explanation here.

This can be concluded that EOS is not suitable for running completely on-chain games but developing a client+smart contract+server applications make no sense since these have no advantages of "decentralized" while all the disadvantages and short-comings of smart-contracts persist.

There are applications on EOS that masquarade as 'd'Apps but still have a critically important part of their logic implemented at the server part. In fact the only feature this application need from EOS is payment system. They could better end using EOS as the payment system and marketing tool and extracting all the application logic into servers. From security, transparency, auditability, verifiability, censorship resistance, downtime probability and distribution point of view most of this applications would not change in case of implementing their logic on servers if they already have some critical part implemented there.

If these applications only use the payment system feature of EOS then the applications could also use Bitcoin or XRP for the same task. However, this will not make them "Bitcoin-based applications." Following the same logic using some features of EOS in an application does not make this application "built on EOS".

Many of these applications do not rely on EOS and only pioneer integrating their applications with smart-contracts for the sake of having progressive words "EOS" and "blockchain" in their marketing campaign or easier monetization and fundrising.

Built-in monetization. This is the brightest unarguable advantage of EOS as a development platform nowadays.

Source: The impact of recent EOS proposals on the long term utility

This is not necessarily a bad thing but this has no practical reasons from technical point of view. In case of this applications they do not leverage any advantages of EOS contracts.

It should be noted that there are no better solutions in the smart-contract industry. When evaluating several projects, it must be borne in mind that EOS is currently closest to meet the requirements for becoming a decentralized software development and distribution platform.

Ultra: blockchain for the game industry

Here I will point out some facts about Ultra that should be taken into account.

1. Ultra is mostly an ecosystem deployment platform but not a game development platform

Ultra is based on EOSIO and it inherits most of EOSIO shortcomings. In theoretically, it is possible to create decentralized applications or on-chain games on Ultra smart contracts, but not for all types of games and applications. Most applications that cannot be built on EOS cannot also be built on Ultra.

We would love for Ultra to become a part of a gamer’s lifestyle. A place where they can chat with friends, buy games, generate money or rewards, as well as engage with their favorite influencers and game developers.

Source: The Ultra Blockchain Network is Built for The Video Game Industry

Source: Ultra telegram channel

Ultra is intended to be a distribution platform, game industry ecosystem platform and cross-game value exchange protocol.

As a project Ultra can solve one problem for the game industry: it can merge and connect ecosystems of different games by establishing an inter-game interaction protocol. Currently, there is not even a single service or set of rules that govern the process of managing in-game objects. There is also no set of rules that grant third party services the ability to manage some in-game objects on their owner's behalf.

2. Ultra resolves the problem of EOSIO: Random Number Generation

Source: Ultra telegram channel

According to the above displayed message from Ultra telegram, the developers of the project promised that they had solved the problem of generating random numbers.

It should be noted that Ultra technical whitepaper is not presented and there are no source codes to verify as Ultra is not an open-source platform. The implementation details are not known at the moment.

RNG is an essential part of most types of DAPPs. The inability to use truly random numbers is also a security vulnerability and leads to various hacks such as EOSPlay hack.

Random Number Generator (if implemented properly) is one of the decisive advantages to consider Ultra for multiple kinds of DAPPs.

3. Non Fungible Tokens (NFTs)

Non-fungible tokens are not an unique feature of Ultra. This kind of tokens was widely adopted with ERC 721 on Ethereum.

However, the developers of Ultra are sure that it is this function of the platform that will bring useful innovations to the gaming industry. NFTs can be used to prove someone's ownership of something. In case of Ultra NFTs will be used to prove player's ownership of some game, account, in-game object or any other part of the game industry that can be tokenized.

The most important fact about NFTs is that they are at the same time the protocol for managing this game objects. NFTs will enable players to not only own game objects but also manage, transfer, sell, buy or use them in any other way. As NFTs are standardized and their APIs are known third party developers will get the ability to build applications that interact with someone else's game objects. For example third party marketplaces. At the other hand game developers can implement any logic of NFT behavior. In theory it is possible to collect fees from each NFT exchange thus establishing a new cash flow for the game development team.

Example: Imagine that a player has a cool weapon skin in Counter Strike and he wants to exchange it for a high level character in World Of Warcraft. These are two different games developed by two different teams that have almost no relations with each other. Currently a player will be forced to seek for some unofficial marketplaces or search forums offering his deal. Reliability of this exchange is low.

The solution: If both games would have their "in-game goods" tokenized as NFTs then it would be incredibly easy to exchange them without any risk of fraud. For the game development companies this would also resolve the issue of data integrity when transferring the ownership of in-game goods to the third party markets without any risk of goods being duplicated or faked. Transfers of game object ownership will be auditable and verifiable for the game company which enables them to implement any kinds of fundraising based on the utility of the NFTs backed by the virtual goods in their games.

This should be noted that NFTs do not introduce any security layer as it was mentioned in multiple articles. If a player can exploit a bug to level up his character quickly then he can still do it and tokenize the characters to sell them at the NFT marketplaces. Managing NFTs pose some specific risks in the same way as managing any crypto assets. Smart-contracts are prone to hackers attacks. Accounts holding NFTs can be compromised if users will not pay attention to security of their keys. Moreover smart-contract developers may retain a certain degree of control over their NFT contracts which enables them to modify the code (and behavior of any NFT) at any time.

4. Resource model on Ultra: congestion mode modification

Source: Ultra telegram channel

Ultra is intended to retain the congestion mechanic which means that most kinds of interactions between smart-contracts and users could be cheaper when the network is uncongested. The problem of congestion mode on EOS was its recovery time. Congestion mechanic looks reasonable for me since there is no benefit in assuming that the network is always operating at full load because this assumption is plainly wrong. It is very unlikely that all EOS holders will utilize the full potential bandwidth offered by their EOS every day for years ahead.

Personally, it seems to me that the congestion of the network takes too long to recover and resume its normal state. To increase the cost of a similar attack, the state of the network and the congestion should resolve faster.

Source: EOS network congestion by DDOS analysis

One critical detail of congestion mechanic is how the network is pushed into 'congested' state and how it is transferred back to its 'normal' mode. According to the response in Ultra telegram the network should transit from one state to another seamlessly which can be an effective solution in theory.

According to the response from Ultra telegram on UOS, the CPU capacity will be used at 100% at all times, even when reaching network congestion.

This platform design feature looks good on paper. However the implementation details are not known yet since there are no source codes to review. If the system really works as intended, then this will mean that it has a number of significant specialized advantages which make it more suitable for its niche.

Conclusion

Ultra is a specialized project built on EOSIO software that is intended to solve a number of problems of the game industry by defining virtual objects management protocols and standards and establishing a platform and an ecosystem for cross-game interactions.

From technical point of view the project is capable of accomplishing its primary goals in theory.

The project has a number of planned EOSIO protocol modifications that would make it more suitable for its tasks but the exact implementation details are not known until the public launch of Ultra mainnet.

---

EOS GO is funded by Polar.io and powered by YOU. Join the community and begin contributing to the movement by adding eos go to your name and joining the EOS GO telegram group.