On the Move — A Critical Analysis of Aptos

Web3.com VenturesOct 25, 2022

On the Move — A Critical Analysis of Aptos

Web3.com Ventures Original Research Analysis

0xFishylosopher

Image Source: https://medium.com/aptoslabs/entering-the-next-phase-of-the-aptos-journey-with-added-funding-and-new-partners-d4daa03dd17c

Introduction

With Aptos’ recent mainnet launch and its token launch on Binance and other major centralized exchanges, there’s no better time to write an exploratory analysis of this long-hailed project. The orphaned child of Meta’s attempts at creating the Libra cryptocurrency, Aptos carries on Libra’s ideal of being the blockchain that will onboard the next million users in crypto.

The over-arching focus of Aptos is to deliver a scaleable, safe, and reliable blockchain [1]. To do so, Aptos relies on a new smart-contract language, Move, ostensibly a “safer” language than the current “gold standard” of Ethereum’s Solidity. Of course, Aptos is not the first L1 blockchain that markets itself as a “scaleable, safe and reliable.” Other chains, most notably Solana, have also tried to use this as their slogan in their past, with mixed success [2]. In this essay, I will endeavor to start from the basic attributes of the Move language, analyze Aptos’ technical fundamentals in the context of other similar projects, and deliver a critical assessment on the potential and limitations of this hot new chain.

Move Language

You can’t do an analysis of Aptos without an analysis of the Move Language. Indeed, this is arguably where most of Aptos’ potential comes from. Move was originally developed by Meta’s Libra Team (now named Diem) to provide a paradigmatically different smart contract programming model compared to other smart contract languages; instead of adopting a transaction-based approach, Move adopts a resource-based approach to defining smart contract models [3].

So what does all of this mean? Starting with Bitcoin, the vast majority of notable blockchains have adopted a “transaction-first” approach, where each entry in a blockchain’s block is a transaction (say between Alice and Bob). A transaction is a relative object; for there to be a transaction, there needs to be an Alice and a Bob address in existence. To ensure that Alice is not “double spending” a coin in a transaction-first approach, we need to check that there is no conflict with all other transactions, a hassle that inevitably slows transactions down.

On the other hand, Move’s “resource-based” approach is dramatically different. Instead of recording lines of A to B transactions, Move records the object (or resource) changing hands and merely updates attributes accordingly. Importantly, resources are atomic entities — a resource X existing does not depend on any other resource existing, unlike in the case of transactions, where a transaction T depends on two prior agents, A and B’s existence. Thus, having a resource-based approach allows for a much more atomic, independent structure optimized for parallel execution.

Rough sketch of Transaction-Based vs. Resource-Based Approaches. Source: Original Content

”Resources” in Move are essentially objects that have certain attributes. In technical jargon, they are implemented structs (i.e. a container data structure) [4]. At this point, people with Ethereum programming backgrounds may raise a question: Solidity also has structs, as well as other data structures. What makes the structs in Move special? I believe that the most important difference is that while structs in Solidity have a relatively peripheral part in the language (being mostly used for clarity), structs are the basis of everything in Move. Moreover, Move’s structs have different “abilities,” including “copy”, “drop”, “store”, and “key,” which define if an object is duplicable, storable, deletable etc [5]. This sort of struct notation is completely different from Solidity, or indeed the vast majority of common programming languages (eg. C/C++). However, these different “abilities” are deeply intuitive. Some things you can “copy,” like a coin or token. Some things you can “drop,” or throw away. Other things, like a unique digital asset, might not be able to be copied. Now consider the following official definition of a “resource” on Move:

“We often refer to struct values as resources if they cannot be copied and cannot be dropped.” — Structs and Resources, Move Language Documentation [4]

So “resources” are essentially unique “structs” that will always be there for you. How romantic.

Move’s complete redefinition of a “struct” allows it to use one data structure to succinctly define tokens, NFTs, smart contracts, and other digital assets in a clean, modular approach [6]. This is something that Ethereum’s EVM simply cannot compare; anyone with some experience developing using the EVM knows how frustrating it is to deal with structs (and nested structs) in Solidity.

Crucially, Move’s resource based approach underwrites its security guarantees. As Move’s whitepaper mentions, in many programs there is the indirect representation of assets, which means scarcity and access control is not scalable. For example, while Ether’s scarcity is hardcoded and protected by the EVM, other ERC-20 tokens “do not inherit these protections, they must be careful not to introduce bugs that allow duplication, reuse, or loss of assets,” [4]. Consider the classic reentrancy attack. This is something that has long plagued EVM projects, often causing them to lose millions and millions of dollars [7]. Because of Move’s resource-based approach, the reentrancy attack is impossible on Move. Thus, the barrier to entry coding Move is arguably a lot more accessible than the EVM — a crucial factor for mass adoption.

Aptos — Technical Principles

Arguably the Aptos’ biggest accomplishment is simply putting Move as a language onto the market. ****Indeed, much of Aptos’ design is taken directly from the Diem (Libra) blockchain developed by Meta. Recall that Aptos is a chain that has an emphasis on scalability and security. There are two main technical implementations used to achieve this. The first is in its consensus layer, namely the AptosBFT consensus mechanism. The second is its execution layer, or the Block-STM execution engine. Let’s examine these in order.

First, AptosBFT is a Byzantine Fault-Tolerant consensus mechanism, which essentially means that it can continue to guarantee security so long as no more than 1/3 of the nodes on the network are malicious actors [8]. This is a standard practice: Bitcoin’s Proof of Work, Ethereum’s Proof-of-Stake etc. are all Byzantine Fault-Tolerant. So how does AptosBFT actually implement its consensus mechanism? Like all other Proof-of-Stake chains, Aptos relies on “staked” validator nodes. It implements a variant of the HotStuff consensus algorithm, a modern PoS algorithm that offers a much cleaner communication protocol between nodes compared to earlier models (eg. pBFT) by having nodes communicate with a “rotating leader” rather than with every other node [9]. While AptosBFT introduces several optimizations on top of HotStuff, most notably a “key rotation mechanism” (to enhance security) and a reduction in overhead (to enhance scalability), there are no major structural change to HotStuff’s PoS design [10].

HotStuff consensus model: https://hackernoon.com/hotstuff-the-consensus-protocol-behind-safestake-and-facebooks-librabft

On the other hand, the Block-STM parallel execution engine is a far more original design, and arguably the project’s primary technical breakthrough [11]. Recall that resources are atomic — the changing hands of a certain resource X does not depend on any other resource. By grouping transactions into blocks (like lego pieces), we can leverage a massive parallelism in executing resource transactions, gaining a 20x increase in computation speed compared with Ethereum [11].

But how does this compare to Solana and other parallel execution engines? Solana’s primary innovation was to hardcode all of its smart contracts dependencies in order to allow it to conduct parallel executions. With all the dependencies known in advance, the Solana execution engine can then lock up the necessary dependencies before runtime. On the other hand, Aptos manages dependencies on the fly, first running all the transactions “optimistically,” and in the case of failure, re-running those specific transactions that have failed [12].

Comparison of the Execution Engines of Ethereum, Solana, and Aptos. Source: Original Content

Let’s use a simple analogy to explain the above. Ethereum is a one-lane road where all the cars must travel in a single line behind one another, whereas both Solana and Aptos are four-lane expressways. This obviously speeds things up. But the question is, how do the cars travel on the expressway? In the case of Solana, each car is essentially assigned a specific lane, and will always drive along the lane. This is very fast and efficient in the best-case scenario, but if the assignment process goes wrong you have a very bad worst-case scenario. On the other hand, in the case of Aptos, the cars are first assigned some lanes, but if this doesn’t work, then the cars are allowed to swerve into other lanes to prevent accidents. Therefore, even though Aptos may not run as fast as Solana in the best-case scenario, it is more reliable than Solana, and has a better worse-case scenario [13].

Evaluation — Potential and Limitations

Aptos’ is currently the first and only major Move-based L1 chain that has launched a mainnet. As such, Aptos’ mainnet release is an incredibly symbolic event; the money and media attention that Aptos has attracted is not necessarily commensurate with its inherent technical innovation.

As mentioned above, the primary technical innovation that Aptos itself has made is in its Block-STM parallel execution engine. Most of the other technical aspects, including its consensus mechanism and use of the Move language, are marginally improved legacy products inherited from Meta [14]. Regarding the Block-STM parallel execution engine, it is unclear whether this will cause a qualitative difference between the user-experience on Aptos versus the user-experience on Solana; if the user-experience is the same, the user won’t care how it is implemented on the technical level.

As with any infrastructure project, Aptos’ long-run success is dependent on what projects choose to build on it. Currently, the projects in its ecosystem, such as the Liquidswap DEX, Topaz NFT marketplace, and Aptos Names domain service, while necessary products in any blockchain ecosystem, are not unique enough to Aptos’ design [15]. These projects are like the grocery store, a school, and a hospital in a small village. While necessary to the village’s functioning, they don’t give the village any unique character that is not found in any other village.

Looking back in time, part of Solana’s success may be attributed to projects such as StepN that were actually able to leverage Solana’s advantage of parallelism. These GameFi and SocialFi projects often involve large amounts of parallel data that are relatively isolated. Thus, these applications are uniquely suited to parallel execution engines, such as Aptos and Solana, while also able to bring a large consumer base and high transaction volume. Indeed, at one point, StepN alone accounted for around ~20% of Solana’s fee-paying users [16].

Thus, for Aptos to succeed as an infrastructure project, there needs to be a unique array of projects that greatly take advantage of Aptos’ parallel execution engine, projects that couldn’t be done on Ethereum or even Solana. With Aptos’ novel Block-STM design, these could potentially take shape in the form of a new class of SocialFi projects where users interact in small cliques (like group chats). Because these groups can be fluid and dynamic, while also somewhat independent of one another, they are much more suited to Aptos’ parallel execution engine than Solana’s or Ethereum’s. But of course, this is just an abstract speculation.

Nonetheless, Aptos’ mainnet launch is still an incredibly important and symbolic event in the crypto world. It represents the culmination of years’ of Meta engineers’ efforts in bringing to life a qualitatively different paradigm for solving Ethereum’s bottleneck of scalability. Move’s unique language features mean that there inevitably will be DApps that are far better to be implemented on Move rather than on Solidity or other smart contract languages. But will those projects necessarily be implemented in the Aptos ecosystem? No one knows. Aptos may enjoy some first-mover advantages of being able to bring Move into production and tying its name with the Move language. But at the same time, it may well suffer from a MySpace-like fate of being the first-mover.

At least one thing is certain: Aptos may be the market’s first experiment with Move, but it certainly will not be the last [17].