# Movement Labs ## 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](https://docs.avax.network/learn/avalanche/avalanche-consensus), 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](https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-10.md) 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](https://github.com/aptos-labs/aptos-core/blob/main/aptos-move/framework/aptos-stdlib/sources/table.move) for storing key, value data within an account at scale * Parallelism via [Block-STM](https://medium.com/aptoslabs/block-stm-how-we-execute-over-160k-transactions-per-second-on-the-aptos-blockchain-3b003657e4ba) that enables concurrent execution of transactions without any input from the user