In this tutorial, we will build a super simple name registry and compare Move and Solidity languages. We will go over how these languages deal with asset management storage and asset management.

I've briefly worked with Move before and found it very enjoyable. It looks very familiar and intuitive, especially after working with Rust. Now with the launch of Movement testnet, Move is more relevant than ever before, so I decided to dig into it again.

What we will create

Before diving into code, let's clarify what we're building. A Name Registry is a smart contract that allows users to register a unique username linked to their blockchain address. Think of it as a decentralized username system. Key functionalities include:

• Registering a unique name (for a small fee)

• Updating the registered name

• Unregistering the name

• Ensuring each name is unique

• Emitting events for actions taken (for convenient tracking)

Part 1: Building the Name Registry in Solidity

First, let's create the registry contract in Solidity.

To start, let's define the registration fee, mapping of addresses to names and vice versa for a fast lookup. In Solidity storage is managed by contracts, so we have to track and update name owners in a data structure inside the contract.

Let's also define events for tracking purposes.

To register a name, the user will need to send a transaction with a value equal to or bigger to the fee we defined:

In this function we check if name is unique, make sure the address doesn't already own a name, check fee amount and also in case the user sent more ether than is required, we refund it.

To record the name we update both mappings and then emit an event.

To update a name, we will need to check, if the new name is taken already and update both mappings:

Finally, to deregister the name, we need to delete the entry from both mappings.

We also have a helper function to check if a name is taken or not:

To sum up, we need to carefully consider updating the mappings and keep track of name ownership ourselves.

Part 2: Building the Name Registry in Aptos Move

Now let's implement the same functionality in Aptos variant of move.

First, we need to declare a module:

Note that the module will be stored under the deployer's address instead of being deployed to a new address like in Solidity. We've also imported some standard library modules and defined errors and other constants.

Now, let's define a data structure similar to a mapping in Solidity. We will use this table to store names for fast lookup of owners and uniqueness, but it will not define the ownership of the name. Note that this is not an optimal solution for production.

This resource will be stored under the module address.

To actually assign ownership, we'll use another resource called Record.

It is a struct which we defined and annotated as a resource. It will be created and stored under the address of the user unlike in our Solidity project.

We'll also define events for the convenience of tracking:

We'll also create a private init_module function which acts like a constructor in Move.

It will create the Registry resource and transfer it to the module creator account.

Now, let's create the register function:

In this function, we verify that the name is not taken and that user hasn't registered a name yet.

Instead of checking the message value, we verify that user has sufficient balance to pay the fee:

Then we withdraw the fee amount from the user:

This way, we don't need to care about refunding excess fee. The we create a record, move it to user's account and add the name to the table. Then we emit an event.

Updating a name is fairly similar.

We ensure that the new name is unique, borrow the record from user's address, update the name and the registry table. Finally, we emit an event.

To deregister a name, we need to remove it from user's address with move_from and update the registry table:

Similarities

Despite the different languages and paradigms, both implementations share several similarities:

• Both contracts allow users to register, update, and unregister unique usernames linked to their addresses.

• Both ensure that each username is unique across the registry.

• Events are emitted for each key action, aiding in tracking and integration with off-chain systems.

• Users must pay a registration fee, serving as a deterrent against spam and providing potential funding for maintenance.

• Both implementations prevent a user from registering multiple usernames.

• Use of mappings (Solidity) and tables (Move) to associate usernames with addresses.

Differences

The differences between Solidity and Aptos Move are more pronounced due to their underlying philosophies:

• Syntax and Language Design:

  • Solidity: C++ and JavaScript-like syntax, familiar to many developers.

  • Move: Rust-inspired syntax, emphasizing safety and explicitness.

• Storage Management:

  • Solidity: Storage is managed within the contract; developers must update mappings carefully.

  • Move: Uses resources stored at specific addresses; ownership is represented more intuitively.

• Module vs. Contract Deployment:

  • Solidity: Contracts are deployed to new addresses.

  • Move: Modules are stored under the deployer's address, promoting modularity.

• Fee Handling:

  • Solidity: Uses msg.value and requires manual refunding of excess fees.

  • Move: Transfers only the required fee, eliminating excess payment concerns.

• Ownership Representation:

  • Solidity: Ownership tracked through mappings within the contract.

  • Move: Ownership is represented by resources stored under user accounts.

• Error Handling:

  • Solidity: Uses require with error messages.

  • Move: Uses assert! with error codes, encouraging standardized error handling.

Takeaways

Building a Name Registry in both Solidity and Aptos Move offers valuable insights into how different languages approach the same problem. Solidity provides a familiar and straightforward path but requires careful attention to security. Aptos Move introduces a paradigm that enforces safety and correctness, potentially reducing vulnerabilities.

Full code for both projects is available here: