New Meta-related Public Chains from the Perspective of the Move Language

[CoinEx]

In July 2022, driven by capital investors, multiple new Meta-related public chains gradually entered our eyes. Backed by strong teams, outstanding underlying technologies, as well as exceptional transaction throughput, these chains have been favored by top capital investors and obtained high valuations despite bearish market conditions. For instance, Aptos raised $350 million, Sui received $236 million, and Linera raised $6 million in a seed round led by a16z.

In today’s public chain race, Meta-related public chains headed by Aptos and Sui are competing against Layer 1 and Layer 2 public chains such as Ethereum. To solve the blockchain trilemma, these chains seek to enable security and ease of use while speeding up transactions through parallelization using Move, a unique programming language developed by Meta. Today, we will start from the Move language, reintroduce Aptos and Sui, and explain their popularity with capital investors.

The Move language

Origin

Move, originally developed by Facebook (now Meta), is a smart contract programming language for the Libra chain (now Diem). It is designed to be a platform-agnostic language to enable common libraries, tooling, and developer communities across different blockchains with vastly different data and execution models. After Libra ran aground, the developers of Move have explored different directions:

· Sui made improvements to Move by imposing additional restrictions on codes written in Move;

· Aptos used Move to explore high-performance parallel execution;

· Starkcoin engaged in a fractal scaling from Layer 2 to Layer 3.

The origins of Move largely arise from the renowned issues in existing blockchain programming languages.


from pontem.network/
Figure 1: Development of Smart Contract Languages

As shown in Figure 1, blockchain programming languages have kept evolving. In the early days, BTC used Script, which is an extremely lightweight programming language, and also a great multi-signature solution. Despite that, Script is Turing-incomplete, which means that it fails to implement complex logic. Therefore, the appearance of Solidity enables the execution of smart contracts, which made up for Script’s lack of Turing completeness. Moreover, Solidity and javascript are very similar in use, which minimized the learning cost: Dapp developers don’t need to learn how blockchains are run, and they just need to write codes in Solidity and have them deployed on EVM. Finally, a functioning smart contract or Dapp will be generated after miners pack and put the codes on the blockchain.

Most existing Layer 1 alternatives are built on EVM and developed in Solidity. However, such public chains also suffer from certain tech defects, which include Ethereum’s scaling problem and Solidity’s memory insecurity. This has prompted the appearance of other alternatives. For instance, Solana addresses the problem of Solidity’s memory insecurity using Rust, which is a complied programming language that allows developers to check the security of the language and program during the compilation process. In addition, considering the need for ecosystem development, Rust has been around for a long time, and many developers have already adopted the language. As it uses Rust, these developers are all set to develop applications on Solana and package the chain through the POH consensus algorithm. This enables them to complete the validation process and finally make up for the defects of the EVM chain.

That being said, Solana also brings plenty of new problems. For instance, the chain made a compromise on decentralization, and it is run by nodes in a centralized manner. This also means that the network is not as stable as Ethereum. Solana made the compromise because its users are more price-sensitive, with weaker demand for stability. Apart from that, as the Rust language requires a high learning cost, most developers still choose to use Solidity. Rust also failed to attract developers to the crypto space as Solana expected. Instead, it has become a barrier, and many developers are reluctant to spend time learning Rust.

This has triggered the appearance of Move. Before developers start to work, the Move language already packed protocols, assets, and NFT standards into modules, with Rust as the bottom layer. That is to say, developers no longer need to study the underlying logic of Rust, and they can get started after learning the different modules of the language. Move combines Rust’s stability and security with Solidity’s ease of use, allowing developers to work at a fast pace while ensuring the security performance of their projects.

Despite its many advantages, Move, like any other technology, is not perfect. As a new programming language, Move is now only maintained by members of the Mysten Labs. In addition, developers still run into troubles when using Move, and the performance of the language must be verified during future tech development.

Features

In Aptos’ developer documentation, Move is introduced as follows:

“Move emphasizes scarcity and access control. An asset in Move can be represented by or stored within resource. Scarcity is enforced by default as structs cannot be duplicated. Only structs that have explicitly been defined at the bytecode layer as copy can be duplicated.”

Scarcity is set for the built-in data types of Move, such as addresses, signatures, and assets. In particular, asset values cannot be arbitrarily copied or modified. In a regular programming language, such figures are represented by common numerical types that allow for arbitrary addition and subtraction. Assets in such languages are therefore never “scarce”. In addition, Solidity does not feature Move’s well-packed modules, which is why it remains inferior to Move in terms of the support for scarcity.

“Access control comes from both the notion of accounts as well as module access privileges. A module in Move may either be a library or a program that can create, store, or transfer assets. Move ensures that only public module functions may be accessed by other modules. Unless a struct has a public constructor, it can only be constructed within the module that defines it. Similarly, fields within a struct can only be accessed and mutated within its module or via public accessors and setters.”

In other words, Move isolates the different modules and imposes more rigorous restrictions. This isolation is reflected at the code execution level rather than the code level. For example, Module X cannot call the transfer function of Asset (the object) in Module Y, forcing them to stay isolated.

Scarcity and access control make blockchain programming safer and easier: Operations such as processing transfers that previously required much care of developers are simplified by Move. For example, previously, when User A transfers $100 to User B, developers must subtract $100 from User A’s account and add $100 to User B’s account (the actual operation is far more complicated), and the accounts would not be balanced if an error occurred in the process. However, with Move, developers can simply create an Account type and call the transfer function, and transaction logic such as insufficient balance is readily available. Simply put, Move packs different functions into modules and prohibit developers from disassembling and executing the functions by themselves. This avoids many bugs that arise from handwritten codes and enables secure, easy programming. Of course, this approach has also, more or less, sacrificed the flexibility of programming.

In Move, a transaction’s sender is represented by a signer, a verified owner of a specific account. The signer has the highest level of permission in Move and is the only entity capable of adding resources to an account. Moreover, a module developer can require that a signer be present to access resources or modify assets stored within an account. The language in itself is very simple, with such general concepts as structures, integers, and addresses. However, it does not have blockchain-specific concepts, such as accounts, transactions, time, cryptography, etc. We can therefore see that under such a framework, the Move-based new public chains have chosen a path that differs from other public chains, which allows them to offer unique features.

Comparison to other languages

Figure 2: A Comparison Between Move and Other Languages


Source: https://aptos.dev/guides/move-guides/move-on-aptos

Here, we will compare Move, Solidity, and Solana’s SeaLevel in five aspects:

I. In terms of data storage, Move stores data within the owner’s account. In other words, with Move, owners have full control over their data, and their accounts are used as the basic storage space; SeaLevel stores data within the owner’s account associated with a program, and the program constitutes the specific basic storage space; Solidity stores date within the account associated with a smart contract, and the smart contract represents the basic storage space.

II. Regarding parallelization, Move is capable of inferring parallelization at runtime; Sealevel requires specifying within the transaction all accounts and programs accessed, which constitutes conditional parallelization; Solidity does not support parallelization.

Ⅲ.With respect to transaction security, Move relies on sequence numbers (native data types supported by Move); SeaLevel adopts transaction uniqueness plus remembering transactions; Solidity uses nonces to simulate sequence numbers (all conventional languages generate temporary nonces to reach a consensus).

Ⅳ. When it comes to type safety, Move uses module structs and generics (scarcity and access control); similar to regular programming languages, SeaLevel relies on program structs; Solidity adopts smart contract types, and access is controlled in the unit of contracts, which creates certain operational difficulties. Plus, not all logic is contract. In comparison, Move uses accounts and modules as the unit, which is much more intuitive.

Ⅴ. As for function calling, Move features static dispatch not on generics, and SeaLevel also uses static dispatch. Solidity, on the other hand, adopts dynamic dispatch because it is a V8-engine-enabled modification based on Javascript and inherits all the features of this dynamic language. Dynamic dispatch is often seen as more flexible but less secure.

The above analysis shows that Move is static and ensures that resources are saved and will not be duplicated or accidentally destroyed. Compared to other languages, Move is superior in terms of security, speed, and ease of use.

Aptos and Sui

Having learned the features of Move, let’s now turn to Aptos and Sui, two new public chains. Equipped with Move, they have each proposed a new solution to tackle the blockchain trilemma.

Aptos
Team

Avery Ching, co-founder and CTO of Aptos, worked as the chief software engineer at Meta for over a decade. He is also the former head of technology at Novi, a crypto wallet project of Meta. Further, most of the developers and researchers in the Aptos team, including Alden Hu and Dahlia Malkhi, were involved in the development of Diem and Novi. Recently, Austin, the former head of marketing at Solana, announced that he will join Aptos next month as Director of Ecosystem.

Investment:


Performance: The Aptos blockchain is capable of processing over 10,000 transactions per second. Ideally, Aptos will be able to handle 160,000 transactions per second in the future.

Features:

I. The Block-STM parallelization engine: Aptos designed an efficient, multi-threaded, in-memory parallel execution engine. It is built to manage all conflicts internally and adapt to workloads automatically.

II. The BFT consensus protocol: From the original hotstuff consensus, Aptos’ diemBFT has witnessed four iterations. Recently, Aptos added an active pacemaker that used timeouts to synchronize validators much more quickly than waiting for increasing timeouts. With this addition, blocks are committed in as few as two network round-trips, making sub-second finality the common case. Moreover, Aptos introduced a reputation system that resolves unresponsive validators by checking on-chain data and automatically changing leader rotation.

Ⅲ. State sync: Effective state synchronization is essential in high-throughput, low-latency systems. Aptos leverages the authenticated ledger history and certified state proofs offered by the validators, full nodes, and other replicators to provide a flexible and configurable synchronization protocol. Specifically, participants in the network can choose different synchronization strategies to optimize their use cases and requirements.

Progress:

· In March, Aptos activated its testnet, which features over 20,000 validator nodes;

· In late June, Aptos launched a $200 million ecosystem grant program, covering six categories: developer tooling, SDKs, libraries, documentation, guides, and tutorials. The grant will be mainly used for tools and frameworks for development, governance, DeFi, and NFTs; core protocol contributions: token standards, libraries, protocol upgrades, etc.; open source & public goods; education initiatives; applications. Today, there are well over 100 projects built on the network. At the current stage, many teams have engaged in development and deployment on the testnet, including the ultra-parallel CLOB protocol Econia, the Move-powered multi-signature wallet Hive, the AMM-based trading app Pontem Network, etc.

· Mainnet to be launched in September.

Sui
Team

Mysten Labs was founded by four former engineers at Meta platforms. The founders of the project, including Evan Cheng, Adeniyi Abiodun, Sam Blackshear, George Danezis, and Kostas Kryptos, were all involved in Novi and Diem at Meta.

Investment:


Performance: As of March 19, an unoptimized single-worker Sui validator running on an 8-core M1 Macbook Pro can execute and commit 120,000 token transfer transactions per second (TPS). Throughput scales linearly with the number of cores, and the same machine processes 25,000 TPS in a single core configuration.

Features:

Transaction Parallelization: Sui divides transactions into two types: simple transactions (independent transactions) and complex transactions (transactions with dependencies).

Simple transactions are those that do not have causal relations with each other. Generally, users just want to send an asset to a recipient, and the only data required is the sender’s address. In addition, these transactions do not have complex interdependencies with other, arbitrary parts of the blockchain state. Simple transactions rely on Byzantine Consistent Broadcast to reach consensus.

Complex transactions involve dependencies with shared objects and use an optimized version of the Byzantine Fault Tolerant (BFT) protocol as their consensus. Sui requires explicit representation of transaction affiliations to enable parallel processing. Complex transactions are stored as confirmed transactions through Narwhal, a mempool protocol that broadcasts transactions to reach a consensus while maintaining data availability. In addition, Tusk (an asynchronous consensus protocol) is responsible for ordering transactions. Tusk employs shared randomness to allow each node to determine the total order of transactions without any extra communication. The consensus subsystem also scales, as it can sequence more transactions by adding more machines to each validator.

Figure 3: Outline of interactions to commit a transaction


Source: https://github.com/MystenLabs/sui/blob/main/doc/paper/sui.pdf

The above figure shows the interaction between the client and Sui Authorities when executing a transaction:

a. A user with a private key creates and signs a user transaction to mutate objects they own, or shared objects, within Sui. In this step, the user’s signature keys are not needed, and the process is performed by the user client or a gateway on behalf of the user.

b. The user transaction is sent to the Sui authorities, each of which checks it for validity, signs it upon success, and returns the signed transaction to the client. The client collects the responses from a quorum of authorities to form a transaction certificate.

c. The transaction certificate is then sent back to all authorities, and if the transaction involves shared objects, it is also sent to a Byzantine protocol operated by the Sui authorities. Authorities wait for the protocol to sequence it in relation to other shared object transactions, and then execute the transaction and summarize its effects into a signed effects response.

d. Once a quorum of authorities has executed the certificate, its effects are final.

Sui uses an object model and leverages Move’s strong ownership model, which allows transactions to explicitly depend on multiple elements under their sender’s control. By requiring that dependencies be explicit, Sui applies a “multi-lane” approach to transaction validation, making sure those independent transaction flows can progress without impediment from the others.

Source: https://github.com/MystenLabs/sui/blob/main/doc/paper/sui.pdf

The above figure shows the interaction between the client and Sui Authorities when executing a transaction:

a. A user with a private key creates and signs a user transaction to mutate objects they own, or shared objects, within Sui. In this step, the user’s signature keys are not needed, and the process is performed by the user client or a gateway on behalf of the user.

b. The user transaction is sent to the Sui authorities, each of which checks it for validity, signs it upon success, and returns the signed transaction to the client. The client collects the responses from a quorum of authorities to form a transaction certificate.

c. The transaction certificate is then sent back to all authorities, and if the transaction involves shared objects, it is also sent to a Byzantine protocol operated by the Sui authorities. Authorities wait for the protocol to sequence it in relation to other shared object transactions, and then execute the transaction and summarize its effects into a signed effects response.

d. Once a quorum of authorities has executed the certificate, its effects are final.

Sui uses an object model and leverages Move’s strong ownership model, which allows transactions to explicitly depend on multiple elements under their sender’s control. By requiring that dependencies be explicit, Sui applies a “multi-lane” approach to transaction validation, making sure those independent transaction flows can progress without impediment from the others.

Gas market design: Sui runs in epochs. During every epoch (24 hours), validators set changes. At that time, the new epoch’s validators vote on a reference gas price for the entire epoch. The protocol provides incentives for validators to maintain transaction fees close to the reference price throughout the entire epoch. Validators can add more computing power proportionally to increases in network demand so that prices remain close to the reference price.

State inflation: When a user submits data to Sui, they must pay both gas fees and fees to the storage fund. This fund covers the actual cost of validators storing the user’s data. Validators are paid through the storage fund as the network matures and the cost of storage rises. Additionally, once a user no longer needs to store that data, he can delete it and receive a rebate from the storage fund.


Figure 4: Sui’s Gas-pricing Mechanism

Source: https://docs.sui.io/learn/tokenomics

A unique feature in the design of Sui is that storage fees are paid separately from transaction execution. In principle, storage costs are denominated in off-chain dollars for storing arbitrary on-chain data. It is exogenously determined through governance polls. However, from the user’s point of view, they do not differentiate the fees paid. When users submit on-chain data, they pay both gas and storage fees. The storage portion of the fee is deposited into the storage fund, which is used to subsidize future storage costs that increase as the network grows and matures. Moreover, users can delete on-chain data in lieu of storage fee rebates, and they do so for economic optimality.

Future development

In the next stage, Sui will strive to enable developers to define and build:

1. On-chain DeFi and TradFi primitives: enabling real-time, low latency on-chain trading;

2. Reward and loyalty programs: deploying mass airdrops that reach millions of people through low-cost transactions;

3. Complex games and business logic: implementing on-chain logic transparently, extending the functionality of assets, and delivering value beyond pure scarcity;

4. Asset tokenization services: making ownership of everything from property deeds through collectibles to medical and educational records perform seamlessly at scale;

5. Decentralized social media networks: empowering creator-owned media, posts, likes, and networks with privacy and interoperability in mind.

Comparison between Aptos and Sui

Similarities:

1. Although both projects use Move as the native programming language, Sui introduced some modifications to Move, most notably the ownership API, which makes it a cleaner, clearer representation of IMO’s blockchain design.

2. Both projects confirm blocks in a multi-threaded, paralleled manner, and add state sync to improve data availability.

3. Both rely on Block-STM-based parallel transaction execution and consensus, rather than the sequential execution of ordered transactions and blocks like other Layer 1 projects.

Differences:


Hardware requirements:


The above figure shows that the Sui is less demanding in terms of hardware, and most nodes can also meet the requirements of Aptos. In addition, both projects allow nodes to linearly scale their devices to adapt to the transaction needs in different states.

Conclusion

In today’s public chain race, chains that focus on tech solutions are increasingly less competitive, and Aptos and Sui were also questioned when they were first launched. Some doubt that developing chains with Move is nothing but a hype campaign doomed to fail. However, after learning more about this new language, we have noticed that Move is far superior to other languages in terms of both security and ease of use. It enhances the security performance at the level of the underlying language, uses parallelization to achieve high throughput and scalability, and enables greater decentralization through dynamic node adjustments. In addition, its ease of use also gives developers an opportunity to choose a different programming language. Today, a growing number of developers are adopting Move as the preferred language.

Furthermore, one must consider the advantages of Aptos and Sui. In addition to enhanced security and high throughput, the two projects offer other unique advantages. Aptos and Sui are designed to build experiences that cater to the next billion users in Web 3. Existing public chains are still far from reaching the goal of carrying more real-world users and assets in terms of both transaction speed and throughput. This is true even in the more efficient Layer 2 world, where collecting an airdrop can create network congestion across the entire Layer 2. The roadmaps of Aptos and Sui show us that they have clear positioning and do not intend to simply copy projects on other public chains. For example, Sui will dive into areas that require security and high throughput, such as games, social networking, asset tokenization services, etc. As they gradually narrow the distance between blockchain and the real world, Aptos and Sui will bring more users and hot money to the space and finally allow us to embrace a prosperous Web 3 world.

Every progress in public chain technologies brings exciting innovations. We look forward to seeing more futuristic discoveries on Aptos and Sui.

About ViaBTC Capital
ViaBTC Capital, a wholly-owned investment brand under ViaBTC Group, focuses on investment in Web 3.0, Layer 2 and DApps combining DeFi, NFT or DAO elements.

Relying on ViaBTC Group’s cutting-edge views, solid capabilities and comprehensive resources, ViaBTC Capital aims to become one of the preferred capital for start-ups and creative implementation in the blockchain world.