Move vs Solidity - NFTango's game

Author: Overmind_xyz

The best way to learn a new language is to translate from the familiar. After the NFTango mission, we translated it to Solidity.

Replicating the use case of the NFT platform and the implementation of internal functions, 1 Move contract becomes 3 Solidity contracts. While this does not necessarily indicate that Move is more efficient than Solidity, it is a very different approach to how these languages store and process data on the blockchain. This article shows code snippets that highlight points of comparison, but you can find the full code for Move and Solidity here.

contract structure

NFToken.sol just calls the ERC721 implementation in OpenZeppelin. This serves as the NFT that will be cast and used to test our NFTango platform.This is not required in Move as Move treats NFTs as objects, a resource in Move terms, that can be created in a single line of code, with the casting and transfer controlled by the functionality and defined module functions. Solidity is contract oriented, in order to simulate NFTs we need to use already deployed contracts or create our own NFT contracts, which is the better option because we can control the contracts. Move is resource oriented, the token.move module is treated as an object with some functionality rather than a standard implemented in a contract. This difference represents the mindset shift needed when learning Move from a Soldity background.

Solidity is contract-centric. move is resource-centric, focusing on the ownership and secure transfer of those resources.

The NFTango.sol contract defines the structure of the NFTangoStore object, as well as a number of assertions and getter/setter functions.The NFTangoManager contract is responsible for the creation and game logic. Essentially, an NFTango.sol contract encapsulates an object and exposes methods to manipulate the state of the object, while the NFTangoManager is the control center. Think of NFTango contracts as Move resources and Manager contracts as Move resource accounts and modules.

Resources and resource accounts

Technically, we could move the NFTangoStore object directly into the NFTangoManager.sol contract, and then we could drop the entire NFTango.sol contract. In fact, the Move contract already has everything together, so why are we separating it in Solidity?

Taking a look at the init_game function in the Move contract, we see that three things happen in order to start the game:

• We create resource accounts by hashing random seed phrases and the address of the game creator (the signer).
• The creator of the game pays NFT to the feature.
• This function generates the NFTangoStore resource from the NFT token data, moves the NFT into the resource account, and moves the NFTangoStore source under the address of the game creator.

When a second player joins the game, they do so by looking up the NFTangoStore resource under the game creator's address. The NFTangoStore manages the game state of each creator, while the resource account handles the NFT.This is a very common framework setup in Move - user addresses store their respective state, while the resource account handles the interaction.

In Solidity's Contract Center world, contracts can also be generated programmatically. These types of contracts are called Factories or Managers. so we have an NFTangoManager contract that generates an NFTango game each time init_game is called. Nevertheless, we can still maintain a mapping of addresses to NFTangoStore objects in the Manager contract, so why encapsulate NFTangoStore objects in an NFTango contract? In short, we want to simulate a Move resource account, even if it's an imperfect simulation.

In Move, resources are defined in a module. This module will contain the fields of the structure, the capabilities that the structure has, and the functions associated with the structure. All these are combined together to form a resource. On the other hand, resource accounts are able to hold, manage and transfer these resources. Note that the NFT data is stored in the NFTangoStore object, but is actually moved to the resource account. In Manager, we maintain the mapping of the game creator address to the NFTango.sol object, because Solidity doesn't store things in the way that x resource stores things under y address, but in the form of the overall state under the management contract.

Second, if we try to have NFTango.sol control NFT transfers, we need to add a feature to NFTangoManager.sol that allows users to pay for NFTango.sol contracts. Players in this game still recognize the manager contract to control their NFTs, not the NFTango.sol contract. Similarly, when paying the winning player, the NFTango contract must approve the manager contract for the transfer to take place. In short, the power is ultimately in the hands of the manager contract. Mobile resource accounts are able to handle NFTs more independently because we can store the account's signature capabilities as values in the NFTangoStore and more easily initiate transfers in the name of the resource account. We'll dive into this in Part 2 - Ownership and Capabilities.

global storage
The above operational differences also hint at the differences in how Move and Solidity access their global data. Without delving into the Merkle tree and root hash, Solidity stores everything via contract addresses. the NFTangoManager stores all existing NFTango contracts, which in turn store individual game state. In Move, the NFTangoStore is created and immediately moved under the game creator address to keep track of individual game states. The centralized vs. decentralized approach to storage means that access to global variables means that many of the new features in Move have access to global data.

The assert_nftango_store_exists function is a good illustration of the different storage philosophies.

In the nftango.move file

assert!(exists(account_address), error::invalid_state(ERROR_NFTANGO_STORE_DOES_NOT_EXIST));;

In the NFTangoManager.sol file

require(address(Games[creator]) ! = address(0), CODE_1).

As shown in the figure, the NFTangoStore resources are stored in the global store, and we can check their existence directly by calling "exists" and entering the address of a specific user. In Solidity, checking for the existence of an NFTango contract is not as easy, and is tracked through a centralized mapping in the NFTangoManager contract. In fact, Solidity tends to initialize everything to zero, rather than allowing the existence of empty state.

Finally, there's an added benefit when throwing errors in Move; Move has an error library that packages error codes into error categories, much like HTTP errors are sorted by hundredths - 400s for client errors, 500s for server errors.

General ......
Solidity is centered around contracts. Moving things from a package to a resource and moving them to a different user or resource account.Solidity centralizes asset transfers and interactions into declarative contracts, while asset interactions in Move are handled by type capabilities, global stores, and resource accounts.