Table of Contents
1. Introduction
2. Navigating the Chaotic Era of Move
3. Aptos’ New Token Model
3-1. Move: Resource Model
3-2 Transition to the Object Model
3-3. The Digital Asset Standard
4. The Significance and Future Direction of Standardization
5. Closing Thoughts
1. Introduction
Are the strongest survivors those who adapt to change? In the ever-evolving landscape of blockchain, many Ethereum Virtual Machine (EVM) killers have faded into obscurity, yielding space to the prevalent term “Layer 2” in the Ethereum ecosystem. Amid this transition, one team stands out for taking a different path—Aptos. Why did Aptos diverge from the established EVM development, abandoning a robust developer community, and why did they introduce Move, a new language? Move emerged as a solution to prevalent issues in existing smart contract languages:
1. Lack of cross-platform compatibility.
2. Insufficient security in existing smart contract languages.
3. Inadequate speed in the execution layer of smart contract languages.
4. Immaturity in the language ecosystem.
5. Poor development and user experience.
Move isn’t merely about protocol compatibility and business logic; it fundamentally tackles these issues. Cairo, for instance, efficiently handles zero-knowledge proofs, while platforms like Solana and Cosmos support Sealevel and CosmWasm to implement protocol-appropriate smart contracts. In contrast, Move is designed to be protocol-agnostic, aiming to become the next generation smart contract language, with mass adoption at its core. Aptos, the driving force behind Move’s development, has recently unveiled an exciting announcement. As an enthusiast captivated by the ideals embedded in this new language, I’ve been closely monitoring its progress and eagerly anticipate the innovations it brings to the blockchain landscape.
This report offers an insight into the present state of Move and the digital asset standard that Aptos has established. We will delve into the rationale behind Aptos setting these standards, their implications, and provide our perspective on the potential future developments.
2. Navigating the Chaotic Era of Move
Aptos and Sui stand as prominent protocols leveraging Move, yet their implementation of Move is independently managed. In practice, each protocol forks the original MoveVM and tailors it to its specific needs. Consequently, the Move standard library is presented differently in the development of contracts within each chain. In particular, While Aptos uses the full definition of the Move language, and is in the process of extending Move further, Sui lacks the concept of global storage. This divergence raises concerns about potential fragmentation within the Move community, particularly if Sui aims to establish itself as the next smart contract language beyond Solidity.
In response to this challenge, Aptos introduced standards for Digital Assets and Fungible Assets in August, outlined in AIP-10 and AIP-11. While example code had been provided earlier to demonstrate how Move could issue coins, the term “standard” had not been explicitly employed. This deliberate release of standards can be interpreted as a strategic move by developers to provide clear direction for the evolving language, addressing the critical need for standardization in the Move ecosystem.
3. Aptos’ New Token Model
3-1. Move: Resource Model
Move adopts a distinctive approach known as the resource model. In this model, a resource stands as a top-level object securely stored in a designated account on the blockchain. Unlike the Ethereum Virtual Machine’s (EVM) pursuit of “account-based state management,” Move opts for a revolutionary “resource-based state management.” In this paradigm, resources transcend mere data; they are entities residing within a user’s account, and exclusive rights to modify their values are vested solely in the user who owns the respective resource.
A simpler way to describe how EVM and Move work is that in the EVM, state management operates by tracking transactions between users through ledger-based number swaps, whereas Move involves users transferring their own tokens. The diagram below illustrates how state storage differs between MoveVM and EVM.
Source: Certik
Resources hold a unique characteristic: they cannot be copied or deleted without the explicit permission of the account in which they are stored. This emphasis on ownership and integrity positions resources as ideal representations for valuable assets such as coins and NFTs. While the resource model may introduce complexity, it significantly contributes to limiting usability issues and minimizing the potential for bugs within contracts.
3-2. Transition to the Object Model
Given Move’s reliance on the resource model tailored for managing assets in smart contracts, it inherently prioritizes stability. However, this emphasis on stability comes at the cost of encountering certain usability challenges.
Primarily, managing all user information within a Move contract proves challenging. In Move, data is stored as a user’s resource, introducing complexity when attempting to handle comprehensive data management. For instance, when issuing an NFT, tracking the ownership of that NFT among users becomes a continuous task, complicating the process of identifying the specific user to whom it was transferred. Additionally, Move addresses “events” like deposits, withdrawals, and token issuance in an account-based, rather than data-driven, manner, leading to potential issues. The counterfeit Aptos token deposit on Upbit on September 24 was a consequence of these structural challenges. The disruption seems to have occurred when Upbit’s automatic wallet system incorrectly read code and labeled scam token as the same as the legitimate APT tokens.
Source: Definalist
Move faced difficulties in recursively composing resources and managing resources inefficiently. In response to these challenges, Aptos introduced “Move Objects” in AIP-10. This innovative approach establishes a globally accessible data model that transcends the limitations inherent in resources traditionally confined to a single account. In the previous resource model, creating or saving a new resource necessitated a signature from the associated account. However, in the Object model, this signature requirement is eliminated, replaced with an account address. Aptos’ adoption of AIP-10 introduces new capabilities, enhancing the efficiency of resource operations and ownership management. The Object model brings forth several key changes:
1. Accessibility of data: Not always accessible → Ensure accessibility using OwnerRef
2. Type of data: Data of differing types can be stored to a single data structure via any→ Having an explicit object store
3. Scalability of data: Transferring logic is limited to the APIs provided in the respective modules → Each ref that has store ability can be placed into any module and stored anywhere
4. Efficiency of data: Requires loading resources, adding unnecessary cost overheads → No longer requires loading individual resources
The original resource-based data model in Aptos focused on storage within Move, offering flexibility to accommodate any value stored on the chain. However, this flexibility came with clear drawbacks, some of which are being addressed by the transition to the Object model. The Object model’s specifications are actively under discussion in the community and are designed to be flexible, allowing for seamless integration of new features. With the successful adoption of the Object model, Aptos is presenting a proposal to establish a new digital asset standard using Move smart contracts.
3-3. The Digital Asset Standard
Aptos introduces a comprehensive digital asset standard categorized into two primary types: fungible assets (FA) and non-fungible digital assets (DA), as outlined in AIP-11. This standard leverages objects to effectively represent assets.
For fungible assets (FAs), the standard incorporates features commonly associated with fungible tokens, achieved by embedding Move’s resources within an Object. Two key object types are associated with FAs:
Object<Metadata>: Contains metadata information such as the name, symbol, and unit of the FAObject<FungibleStore>: Holds information about the store managing the FA
Source: Aptos
The diagram illustrates the relationships between objects within an FA. For instance, it demonstrates that if Alice creates metadata using her USDC token information, she can utilize this data to generate a FungibleStore, facilitating the storage of various tokens she owns. Unlike the resource model, which utilizes generic types to differentiate coins, FAs use metadata to identify coins in a more versatile manner. Each FungibleStore holds metadata information, simplifying processes such as combination, division, or transfer of FAs that share the same type of coin. While fungible assets align with ERC-20 standards, non-fungible digital assets (DAs) encompass attributes defined in ERC-721 and ERC-1155. These attributes include the name, description, URI, and supply of the NFT. The migration of NFT assets from EVM-based chains to Aptos signals a commitment to interface compatibility with Ethereum NFTs. Innovative ideas have emerged to enhance NFT management, enabling greater customization using Object, facilitating combinatorial approaches for forming new configurations by combining NFTs, and employing parallelism for heightened scalability. By offering comprehensive interfaces throughout the token life cycle out of the box, Aptos supports a no-code solution for application development. For example, an interface for creating a collection of NFTs could be designed as follows.
public entry fun create_collection(creator: &signer) {
let collection_constructor_ref = &collection::create_unlimited_collection(
creator,
"My Collection Description",
"My Collection",
royalty,
"<https://mycollection.com>",
);
let mutator_ref = collection::get_mutator_ref(collection_constructor_ref);
// Store the mutator ref somewhere safe
}
By incorporating MutatorRef during the creation of a collection, Aptos introduces a powerful mechanism ensuring that only authorized entities can modify NFT information securely. This surpasses the limitations of the Resource model, where only the owner can alter the resource value, transitioning to the Object model’s flexibility. In the Object model, anyone can modify the value, granted they have contractual authorization with the appropriate reference. The introduction of the Aptos Digital Asset Standard significantly enhances the usability of the Move language.
4. The Significance and Future Direction of Standardization
Ironically, the primary challenge for non-EVM chains lies in achieving compatibility with EVMs. As the majority of smart contract-based assets currently adhere to ERC-20 standards, achieving this compatibility is crucial for non-EVM chains to gain prominence. Standards like CosmWasm’s CW-20 and Move’s Digital Asset Standard have emerged to address this challenge. Another hurdle is the comparatively smaller size of the community in non-EVM chains. Mastering a new contract language and comprehending its intricacies pose challenges for even experienced developers. The popularity of a language or platform significantly influences the relevance of developers’ efforts. This dynamic often results in the oversight of many EVM alternatives unless they prove their sustainability in the market.
Aptos’ initiative to establish standards transcends mere community growth; it is a survival strategy. The creation of a contract standard for digital assets not only streamlines the complexity associated with a new language (Move) but also reduces the entry barriers for developers by minimizing learning costs. However, amidst this pursuit, it is crucial to uphold the “secure smart contracts” philosophy that Move endeavors to deliver. With Aptos leading the charge in the Move community, we eagerly anticipate the evolutionary path that lies ahead.
5. Closing Thoughts
I have been particularly engaged in ongoing development within the Non-EVM sector, working with platforms like CosmWasm and Move. Based on my experience, the Non-EVM sector undergoes rapid changes, marked by breaking alterations with each update. This dynamic necessitates constant learning and swift adaptation from developers, placing the responsibility on them to stay abreast of evolving trends. Although there are instances when the comparatively stable and prevalent EVM sector appears desirable, the limitations of EVM are apparent concerning the assurance of secure and efficient smart contract development for the widespread apdoption of Web3.
With the recent surge in Bitcoin prices, Solana’s strength stands out prominently. Currently, Solana represents the most advanced state among Non-EVM ecosystems and is entering a period of stability. The Move ecosystem is at a formative stage, reminiscent of Solana in its early days, with Move standards gradually taking shape. This presents an opportune moment to participate in the early Move ecosystem, and we recommend learning Move for those:
1. Individuals seeking to contribute to the early Move community
2. Individuals interested in participating in development within the Non-EVM sector
3. Individuals aspiring to spearhead the widespread adoption of Web3 through the implementation of secure and efficient smart contracts
Much like the diverse array of programming languages suited to different contexts, we advocate for the development of smart contracts in new languages tailored to specific situations. The evolving narrative will reveal whether Move can surpass Solidity and emerge as a new powerhouse.
Original Link