Published in


Overview of Move Programming Language

  1. Scarcity — In terms of blockchain technology, this is nothing but, avoiding double-spending attacks and also the creation of assets be restricted.
  2. Access Control — Maintain ownership information and privileges on the digital assets according to the ownership.
  • No type system enforced by default for digital assets. Ex: Bitcoin/Ether.
  • A single scarce asset is represented in the whole language like Ether. Any custom assets like ERC20 tokens, need to be checked for safety properties specified by the programmer building the tokens.
  • Access control policies are also embedded in the language semantics. No easy way to extend this to custom assets.
  • Specifically with Bitcoin — Cannot define custom data types or procedures. Bitcoin script is not Turing complete.
  • First-class resources — In Move, any custom asset can be declared as a resource type, making it safe and access controlled by default. Similar to smart contracts in Ethereum, Move has modules, which are code blocks containing resources, other types and procedures. A strong level of data abstraction is enforced by way of these two main components. Resources are transparent within modules and are opaque to invocations external to the modules. An important characteristic of a resource is — a resource can never be copied or implicitly discarded, only moved between storage location. Below is an example module declaration:
Snippet representing module and resource relationship (
  • Flexibility — Each Libra transaction will include a transaction script. Transaction scripts are used to make calls and invoke procedures in a module. It is a single main procedure that can contain customizable transactions and arbitrary code. A single script can invoke multiple procedures. Until now, the design goals make Move look very similar to object-oriented programming languages. This can be attributed to an identical relationship between modules/resources/procedures -> classes/objects/methods.
  • Safety — To enforce safety in this language three main components have to be investigated — types, resources and memory. In general two approaches seemed to be common, either compile-time checking or runtime checking at the assembly level. With Move, a new approach has evolved which is a median between the above two approaches, i.e., typed bytecode which is at a higher level than assembly and lower-level than source language. A Bytecode Verifier, checks for safety properties on-chain before the modules are published. Once verified, Bytecode Interpreter executes the code. This is very similar to the process used with JVM (Java Virtual Machine) and CLR (Common Language Runtime).
  • Verifiability — Even though Move enables on-chain verification of all the safety properties. This is not ideal for a highly utilized blockchain. Hence, off-chain static verification tools are also supported by Move which will reduce the complexity of on-chain verification. Under this assumption, there are three design decisions considered: No dynamic dispatch (avoid complex call graph construction and call site can be statically determined), Limited mutability (Usage of reference types similar to C++, which allows at most one mutable reference at a point), Modularity (modules can be isolated for functional verification).
  1. Types — Supports primitive types like boolean, address (256-bit), unsigned integer (64-bit) and fixed size byte arrays.
  2. Struct — Two types: kind(resource) and unrestricted(general structures).
  3. Procedures — Methods that can be public or internal. By default, module dependency is acyclic, which avoids the re-entrancy attacks.
  4. Bytecode Verifier — The critical component which checks for safety properties before modules get published. All Move programs have to pass through the verifier before getting deployed on the network. There are multiple phases in the process of verification: control graph construction, stack balance checking (ensuring the size of the stack is not modified after all the operations), type checking, kind or resource checking, reference checking and linking with the global state (checking declarations match their usage).
  5. Bytecode Interpreter — After verification is done, the programs are passed through an interpreter for execution. This flow is very similar to JVM and CLR as mentioned before and traditional programmers can relate to this process. Execution of programs is metered similar to Ethereum using “gas” parameter. This will warrant any infinite loop executions.
  6. Move Virtual Machine — The process of VM is similar to any other blockchain. This has been covered in detail as in another technical paper as mentioned. But to sum it up, blocks contain multiple transactions and each transaction is executed to create a transaction effect. The transaction effect is used to generate an updated global state. This creates a separation between effects and state transitions.
  1. Using Move to implement accounts, Libra coin, Libra reserve management, Validation management, transaction fee management, cold wallets, etc.,
  2. Additional object-oriented programming language features like polymorphism, collections and events, etc.,
  3. A source language for Move.
  4. Logical specification for the language and automated formal verification tools.
  5. Third party module publishing support other than Libra users (this would pave way for extensive use cases).

Get Best Software Deals Directly In Your Inbox



Coinmonks ( is a non-profit Crypto Educational Publication. Follow us on Twitter @coinmonks and Our other project —, Email  —

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Keerthi Nelaturu

PhD Candidate at University of Toronto. Want to learn and write about everything in Computer Science. Photographer.