Author: Zeke, researcher at YBB Capital, Translated by: 0xjs@Golden Finance
Preface
The market has become increasingly stagnant as of late, causing many of the OGs in the space to begin questioning the purpose of the industry.
I want to share some personal thoughts on this. I have always believed that many grand visions of the past have been "debunked" because they were not logically coherent from the beginning. Non-financial Dapps often try to cover up their shortcomings by emphasizing the value of decentralization. But the reality is that they ask me to trust their multi-signature wallets and single-node servers instead of Google, Twitter, or YouTube, claiming that they are secure enough. Many visions are not debunked; they just have never been truly tested. I still believe that even if these visions are not as grand as originally imagined, they are still important - they just need a strong foundation to support them. At the very least, they should provide a decentralized or Web2-equivalent experience.
Take TON and Solana as examples, which were once underestimated but are now gradually catching up with industry leaders in all aspects. Application-enabled blockchains require innovation, which drives the industry forward in every cycle. Today, we will explore a long-overlooked blockchain - a Move-based blockchain.
1、Move
The Move programming language was originally developed for Meta's abandoned project Diem (originally called Libra). Diem aims to create a more stable and regulated stablecoin as the basis for Meta's metaverse vision. However, the project has faced strong opposition and relentless pressure from regulators around the world. Regulators are concerned that Diem's scale, combined with Facebook's massive user base, could pose a threat to financial stability, monetary policy, and data privacy. Under pressure, especially from the Biden administration, Meta ultimately had to abandon the Diem project.
Fortunately, the core of Diem has not been completely abandoned. Various factions that split from the original team continued to explore and develop Move, and later evolved into the Move twins we are familiar with: Sui and Aptos. In addition, there are some emerging projects, such as Linera (a Rust blockchain inspired by Move) and the recently promoted Movement.
So, why did a project that was cut in half leave such a far-reaching impact? As a programming language developed by a top Web2 company for blockchain, Move is quite complex. Its design fully considers the performance and security issues of existing blockchain programming languages, especially Solidity. Its design goal is to create a type system tailored for asset management and access control. I will briefly summarize its advantages into three points:
Safety: The Move language's first design principle is safety. It uses static type checking and resource management to prevent common security vulnerabilities, such as overflow errors and reentrancy attacks. Compared to other language virtual machines, Move supports a variety of safety features, as shown in the Nansen comparison chart below.
Composability: Move supports modularity and composability, allowing developers to easily create and combine different smart contracts to build more complex applications.
Performance: The Move language’s virtual machine is optimized (supporting parallelism, memory management, and compiler optimizations), enabling it to efficiently execute smart contracts, thereby increasing transaction speed and throughput.
In a market flooded with modular EVM blockchains, Move represents a bold experiment. While the above points may seem familiar in descriptions of other blockchain projects, I strongly recommend that you experience them yourself to fully grasp the practical benefits of these features.
2、On
2.1 Architecture
As one of the Geminis, Sui has been subject to criticism since its launch, especially regarding airdrops and token distribution methods. However, putting aside these issues and focusing on the project itself, Sui has proven to be excellent in both performance and user experience, especially in gaming. This success is largely due to its innovative architecture, which has been refined for mainstream adoption. Here is a brief overview of Sui's architectural innovations:
Object storage model: This component is the core of Sui's improvement to Move. The object storage model treats data as independent objects, each with a unique identifier. Unlike traditional database systems, the object storage model has no fixed data structure and can store various types of data, such as text, images, videos, and audio. This model allows parallel execution and horizontal expansion (adding nodes to expand storage capacity), and Sui's design is based on this model.
Causal Ordering: Ensures that transactions are executed in the order consistent with their causal relationships, avoiding data conflicts and inconsistencies. This feature enables Sui to handle a large number of concurrent transactions while maintaining data consistency.
Narwhal and Bullshark consensus engines: Sui uses Narwhal and Bullshark as its consensus engines. Narwhal is responsible for transaction ordering and validation. It works by maintaining a local transaction pool, ordering transactions based on causality, and broadcasting them to ensure that all nodes have the same valid transaction order. After receiving the ordered transaction list from Narwhal, Bullshark votes on the list and uses Byzantine Fault Tolerance (BFT) consensus to ensure that all nodes agree on the transaction order.
Sui Move: Sui extends the Move language by adding new features, such as support for NFTs, asset management, and data storage.
Sui Framework: Sui provides a comprehensive framework to help developers quickly build and deploy applications. The framework includes various tools and libraries, such as Sui Wallet, Sui SDK, and Sui CLI.
Sui's architectural design enables it to handle a large number of concurrent transactions while maintaining high speed, low fees and security. In addition, the Sui Move language and Sui framework provide developers with powerful tools to build secure, scalable and user-friendly applications.
2.2 Consensus
The Sui blockchain uses a consensus mechanism called Mysticeti, a Byzantine Fault Tolerance (BFT)-based consensus designed to optimize for low latency and high throughput.
Mysticeti allows multiple validators to propose blocks in parallel, maximizing network bandwidth and resisting censorship. In addition, the protocol only requires three rounds of messaging to commit blocks from a directed acyclic graph (DAG), meeting the minimum theoretical requirements and parallel to pBFT. The commit rule allows for parallel voting and block leader certification, further reducing median and tail latency. It can also tolerate unavailable leaders without significantly increasing commit latency.
Prior to the Sui mainnet launch, Mysticeti conducted three months of testing on a testnet, achieving significant results, including an 80% reduction in latency. The Sui network can now handle tens of thousands of transactions per second with end-to-end latency well below one second.
The Sui blockchain also uses a specific type of proof-of-stake consensus, Delegated Proof-of-Stake (DPoS). When complex transactions involving shared objects occur, Sui uses the Narwhal and Bullshark consensus engines to sort these transactions. Compared to other BFT consensus mechanisms used by blockchains, Sui's consensus has the following advantages and disadvantages:
advantage:
Low latency and high throughput: The Mysticeti protocol significantly reduces consensus latency and increases network throughput by proposing blocks in parallel and optimizing the message delivery process. This enables the Sui blockchain to process tens of thousands of transactions per second with end-to-end latency well below one second.
Anti-censorship: Mysticeti allows multiple validators to propose blocks in parallel, thereby enhancing the network's ability to resist censorship.
Tolerance of unavailable leaders: Commit rules allow tolerance of unavailable leaders (the system automatically elects a new leader when a leader node fails) without significantly increasing commit latency.
shortcoming:
Complexity: The design of the Mysticeti protocol is relatively complex and requires a deeper technical understanding to fully grasp its operating mechanism.
Security: Although the Mysticeti protocol performs well on the test network, its security needs to be further verified in actual applications.
Scalability: The scalability of the Mysticeti protocol still needs further observation to ensure that it can adapt to the growing network size and transaction volume in the future.
2.3 Account Abstraction
Sui's account abstraction model is a mechanism that allows users to manage accounts and transactions in a simpler and more secure way. It abstracts the account and transaction logic from the underlying blockchain protocol, thereby achieving a higher level of account management and transaction processing.
In Sui's account abstraction model, accounts are no longer simple public-private key pairs, but objects with richer properties and behaviors. Each account has a unique identifier, called an account ID, which is associated with the account's public and private key pairs.
The key components of Sui's account abstraction model include:
1. Account object: The basic unit of account in Sui. Each account object has a unique Account ID and contains the attributes and behaviors of the account.
2. Account Data: The core component of the account object, including basic account information such as account ID, public key, and private key pair.
3. Transaction context: The basic unit of transaction in Sui. It includes transaction related information such as transaction ID, account ID and transaction data.
4. Account logic: A collection of behaviors and rules that define how an account processes transactions and manages its state.
Sui's account abstraction model processes transactions through the following steps:
1. Transaction creation: The user creates a transaction and sends it to the Sui network.
2. Transaction verification: The Sui network verifies the validity and integrity of the transaction.
3. Account Lookup: Sui network looks up the corresponding account object based on the Account ID in the transaction.
4. Account logic execution: The Sui network executes account logic to process transactions and update account status.
5. Transaction confirmation: The Sui network confirms the transaction results and records them on the blockchain.
In simple terms, Sui’s account abstraction model is an innovative mechanism that simplifies account management and transaction processing, making applications more user-friendly.
2.4 Games
If a blockchain wants to stand out, it must have a solid foundation. I said before that Move is a bold attempt for two reasons:
First, in an era dominated by the concept of modularity, native blockchains based on Move (such as Move Gemini) represent one of the last attempts at Layer 1, essentially going against the trend. But the recent rise of various heterogeneous chains may prove that modularity is not the only answer.
Second, deciding to rebuild a blockchain with a new programming language is like trying to create a new operating system to compete with iOS and Android in today’s mobile market — an endeavor that is bound to be challenging. Whether Move-based blockchains can become as big as Solana in the coming years will largely depend on the path they choose to take. For Sui, the answer to this challenge is games.
Games are one of the key entry points for Web3, but most blockchains don’t support games very well. This is because blockchains are primarily designed for finance, and their decentralized architectures are inherently inefficient and unsuitable for games. Sui, however, is different. Its model is a great fit for DeFi applications and non-financial applications, including games. As mentioned earlier, in Sui, everything is treated as an object. In a game or application with layered, complex assets, Sui allows an object to own other objects (assets can own assets). For example, in a hero role game, a hero might own an inventory containing other digital assets belonging to that character. Sui can accurately model these data hierarchies in a way that other blockchains cannot, allowing developers to build applications without having to work around the fundamental limitations of the chain.
In addition, Sui is also actively cooperating with traditional Web2 giants. Last year, he reached cooperation with three of the four major game giants in South Korea (Netmarble, NHN, and NCSoft). This year, he cooperated with TikTok to develop blockchain games and SocialFi projects, bringing traditional giants into Web2
3、Apartments
Aptos is another Layer 1 blockchain based on the Move language, also focused on building high-performance, scalable Web3 infrastructure. Its architectural design has many similarities with Sui, but also demonstrates some unique features.
3.1 Architecture
Modular design: Aptos adopts a modular architecture, developers can independently develop and upgrade different modules, improving development speed and flexibility.
Parallel Execution Engine (Block-STM): Unlike other blockchains that require data dependencies to be declared in advance, Aptos’ parallel execution engine can process transactions in parallel without knowing the data location in advance, thereby increasing throughput and reducing latency.
Pipelined transaction processing: Aptos divides transaction processing into multiple stages, such as propagation, metadata sorting, and batch storage. These stages are executed in parallel using a pipelined approach, thereby maximizing throughput and minimizing latency.
Move Programming Language: Aptos uses the Move programming language. Unlike Sui's innovation, Aptos focuses more on improving it, such as standardizing the language, introducing more powerful function support, and custom functions.
Flexible state synchronization: This allows nodes to choose different state synchronization strategies, such as syncing the full history or only syncing the latest state, increasing the flexibility of nodes.
AptosBFT consensus mechanism: AptosBFT is the Byzantine Fault Tolerant (BFT) consensus mechanism used by Aptos, which improves throughput and reduces latency by optimizing communication and synchronization between validators. Compared with Sui, it can be seen as an improved version of DiemBFT, with certain improvements in efficiency and crash recovery, so it will only be briefly mentioned here.
Aptos' architecture is designed to handle a large number of concurrent transactions while maintaining high speed, low fees, and security. In addition, the Move language and Aptos framework provide developers with powerful tools to build secure, scalable, and user-friendly applications.
3.2 Block-STM
Here, we will elaborate on Aptos' core innovation, the parallel execution engine Block-STM:
The core principles of Block-STM:
Preset order execution: Block-STM relies on a preset order of transactions within a block, and all transactions must be executed in this order to ensure the consistency of the final state.
Optimistic concurrency control: Block-STM optimistically executes transactions in parallel, assuming that conflicts will not occur. Optimistic concurrency control is based on the assumption that "conflicts rarely occur", allowing transactions to access and modify data without locking. It assumes that the probability of multiple transactions conflicting at the same time is low, so modifications can proceed, and conflicts (if any) are checked before the final commit.
Multi-version data structure: To support optimistic concurrency control, Block-STM uses a multi-version data structure to store data. Each write operation creates a new data version, and a read operation accesses the corresponding data version.
Verification and Retry: After executing a transaction, Block-STM verifies that the version of the data read is still valid. If the verification fails, indicating a conflict, the transaction is marked as invalid and re-executed.
Cooperative Scheduling: Block-STM uses a cooperative scheduler to coordinate the execution and verification tasks of various threads to maximize parallelism.
Block-STM workflow:
Transaction grouping: Transactions within a block are grouped and assigned to different threads for parallel execution.
Optimistic execution: Each thread optimistically executes the transactions assigned to it and records the read-write sets of each transaction.
Validation: Once a thread has completed execution of a transaction, it verifies that the version of the data in the read set is still valid.
Retry: If validation fails, indicating a conflict, the transaction is marked invalid and re-executed.
Submit: Once all transactions are verified, the results will be written to the blockchain state, completing the transaction submission.
Advantages of Block-STM:
High Throughput: By leveraging optimistic concurrency control and cooperative scheduling, Block-STM can fully utilize the performance of multi-core processors and achieve high throughput.
Low latency: Since transactions can be executed in parallel, Block-STM significantly reduces transaction confirmation time.
Security: Block-STM’s preset sequential execution and verification mechanism ensures the consistency and security of the final state.
Simply put, Block-STM is an efficient parallel transaction execution engine that combines optimistic concurrency control, multi-version data structures, and cooperative scheduling techniques to maximize blockchain throughput while ensuring security and correctness.
3.3 Account Abstraction
Unlike Sui's more direct account abstraction, Aptos supports a more limited level of abstraction and lacks specific predefined standards. Its account abstraction capabilities are mainly reflected in the following aspects:
Modular account management: Accounts are defined and managed using Move modules, and developers can create custom modules to implement different account types and functions.
Flexible key management: allows users to use different keys to perform different operations on their accounts, such as using one key to sign transactions and another key for account management.
Programmable transaction verification: Developers can define custom transaction verification logic within the Move module, such as multi-signature and spending restrictions, to meet different application scenarios.
3.4 Cooperation with Microsoft
Unlike Sui, which is more focused on game development, Aptos does not have a specific development goal, but instead bills itself as the most production-friendly blockchain. It is worth mentioning that Aptos is working with Microsoft to integrate Microsoft's artificial intelligence technology into the blockchain. Their first collaborative product, Aptos Assistant, has been released on the official website, a generative artificial intelligence assistant built on the Aptos network. More artificial intelligence products are expected to be released in the coming months.
4. Move Ecosystem
Although Sui has performed well recently, compared with EVM chains and heterogeneous chains such as Solana and Ton, the rise of the Move ecosystem still needs time to adjust. Although Sui and Aptos have obvious star effects and continuous technological breakthroughs, the overall scale and activity of the Move ecosystem still lag behind mature ecosystems. The number of developers, application types, and user scale all need time to adjust. From external cooperation to operation, both projects show a strong Web2 thinking and lack some Web3 genes. Various cooperation projects are also relatively cold in the industry.
However, considering the potential of the Move ecosystem, there are still many areas worth exploring. Some developers have already noticed the future value of Move. As mentioned in the introduction, there are already projects that bring Move into the ETH Layer 2 ecosystem, and the Move ecosystem is likely to shine in the ETH Layer 2 field in the future. The current focus should be on how to make the Move ecosystem the focus.
