Movement Labs

Movement Labs is building a modular framework to build and deploy Move-based infrastructure, applications, and blockchains in any distributed environment. The docs below are for our first product: M1.

What is M1?

M1 is a community-first Layer 1 incubated by Ava Labs providing the highest possible TPS through Move, instant finality, native day-zero access to mass liquidity, and modular customizations. Move builders are currently forced to decide between monolithic, low-liquidity, and centralized chains. M1 enables builders to natively tap into large liquidity providers like BenQi and GMX through Avalanche Warp Messaging. M1 is also 100% compatible with any existing Aptos Move code (Sui Move coming) which means any Aptos protocol can simultaneously launch on Avalanche and inherit the liquidity and tooling for no extra cost. Move protocols can also expect to have interoperability and tap into the liquidity of traditionally-EVM protocols.

What Is Avalanche?

Avalanche is an open-source platform for building decentralized applications in one interoperable, decentralized, and highly scalable ecosystem. Powered by a uniquely powerful consensus mechanism, Avalanche is the first ecosystem designed to accommodate the scale of global finance, with near-instant transaction finality.

What Is a Subnet?

A Subnet is a sovereign network which defines its own rules regarding its membership and token economics. It is composed of a dynamic subset of Avalanche validators working together to achieve consensus on the state of one or more blockchains. Each blockchain is validated by exactly one Subnet, while a Subnet can validate many blockchains.

Avalanche's Primary Network is a special Subnet running three blockchains:

• The Platform Chain (P-Chain)

• The Contract Chain (C-Chain)

• The Exchange Chain (X-Chain)

Advantages

Independent Networks

• Subnets use virtual machines to specify their own execution logic, determine their own fee regime, maintain their own state, facilitate their own networking, and provide their own security.

• Each Subnet's performance is isolated from other Subnets in the ecosystem, so increased usage on one Subnet won't affect another.

• Subnets can have their own token economics with their own native tokens, fee markets, and incentives determined by the Subnet deployer.

• One Subnet can host multiple blockchains with customized virtual machines.

Native Interoperability

• Avalanche Warp Messaging enables native cross-Subnet communication and allows Virtual Machine (VM) developers to implement arbitrary communication protocols between any two Subnets.

Accommodate Application-Specific Requirements

Different blockchain-based applications may require validators to have certain properties such as large amounts of RAM or CPU power.

• A Subnet could require that validators meet certain hardware requirements so that the application doesn’t suffer from low performance due to slow validators.

Launch a Network Designed With Compliance In Mind

Avalanche’s Subnet architecture makes regulatory compliance manageable. As mentioned above, a Subnet may require validators to meet a set of requirements.

Some examples of requirements the creators of a Subnet may choose include:

• Validators must be located in a given country.

• Validators must pass a KYC/AML checks.

• Validators must hold a certain license.

Control The Privacy of On-Chain Data

Subnets are ideal for organizations interested in keeping their information private.

• Institutions conscious of their stakeholders' privacy can create a private Subnet where the contents of the blockchains would be visible only to a set of pre-approved validators. Define this at creation with a single parameter.

Validator Sovereignty

In a heterogeneous network of blockchains, some validators will not want to validate certain blockchains because they simply have no interest in those blockchains.

• The Subnet model enables validators to concern themselves only with blockchain networks they choose to participate in. This greatly reduces the computational burden on validators.

What is Move?

Move is a safe and secure programming language for Web3 that emphasizes scarcity and access control. Any assets in Move can be represented by or stored within resource. Scarcity is enforced by default as structs cannot be accidentally duplicated or dropped. Only structs that have explicitly been defined at the bytecode layer as copy can be duplicated and drop can be dropped, respectively.

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 that or via public accessors and setters. Furthermore, structs defined with key can be stored and read from global storage only within the module defines it. Structs with store can be stored within another store or key struct inside or outside the module that defines that struct.

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 into an account. In addition, a module developer can require that a signer be present to access resources or modify assets stored within an account.

Comparison to other VMs

	Aptos / Move	Solana / SeaLevel	EVM	Sui / Move
Data storage	Stored at a global address or within the owner's account	Stored within the owner's account associated with a program	Stored within the account associated with a smart contract	Stored at a global address
Parallelization	Capable of inferring parallelization at runtime within Aptos	Requires specifying all data accessed	Currently serial nothing in production	Requires specifying all data accessed
Transaction safety	Sequence number	Transaction uniqueness	nonces, similar to sequence numbers	Transaction uniqueness
Type safety	Module structs and generics	Program structs	Contract types	Module structs and generics
Function calling	Static dispatch	Static dispatch	Dynamic dispatch	Static dispatch
Authenticated Storage	Yes	No	Yes	No
Object accessibility	Guaranteed to be globally accessible	Not applicable	Not applicable	Can be hidden

Move features

Each deployment of the MoveVM has the ability to extend the core MoveVM with additional features via an adapter layer. Furthermore, MoveVM has a framework to support standard operations much like a computer has an operating system.

The Aptos Move adapter features include:

• Move Objects that offer an extensible programming model for globally access to heterogeneous set of resources stored at a single address on-chain.

• Resource accounts that offer programmable accounts on-chain, which can be useful for DAOs (decentralized autonomous organizations), shared accounts, or building complex applications on-chain.

• Tables for storing key, value data within an account at scale

• Parallelism via Block-STM that enables concurrent execution of transactions without any input from the user