After months of developing Smart Contracts in Rust within an increasingly quiet ecosystem, I decided to step out of my comfort zone to diversify my skills and knowledge. That’s how I discovered Aptos and Sui thanks to the general excitement of the successive fundraisings.
Following the exploration of the tech behind these two blockchains, I’m now learning how to program Smart Contracts on them. So, with this post, I’m launching a series of articles about Move and the programming models derived from the language, to share with you my discoveries, my tips, my mistakes and my code.
This first article is an overview of the language, we won’t touch the keyboard until the next one. Without further ado, let’s move!
Origins
Move was originally developed at Facebook for its Diem blockchain. It is based on Rust, a language widely used in the Web3 for its safety, speed and quality which powers a large number of smart contracts on Solana, Near, Elrond or the late Terra among others.
Fortunately, Move didn’t die with Diem as it was designed as a platform-agnostic language to enable common libraries, tooling, and developer communities across different blockchains (Sui, Aptos, Starcoin…).
For Move’s creator Sam Blackshear, a big part of Move’s mission is to reduce smart contract language fragmentation by ending the status quo of one language per blockchain and to enable innovation via trying out different, platform-specific styles of integrating Move into a chain. The hope is that the platforms can try very different ideas while reusing the same VM, prover, tooling, libraries, etc.
In future articles I will mainly experiment with Aptos and Sui, note that these platforms created different programming models and therefore Move is not used in the same way.
The Next Mainstream Language
Move could be the next mainstream language for smart contracts replacing Solidity, it even aims to become the “Javascript of Web3”. Let’s see why.
Today, the most popular language among blockchain developers is undoubtedly Solidity. Initially proposed for Ethereum in 2014, the language has become popular on a multitude of Ethereum Virtual Machine (EVM) compatible blockchains (BNB Chain, Fantom, Polygon, Avalanche, Cardano…). On the latter, smart contracts are executed in an environment similar to Ethereum, thus simplifying the task of Solidity developers and encouraging the adoption of the language.
As an early blockchain language, Solidity was designed to implement basic programming language concepts using elementary data types (e.g., array of bytes, string) and data structures (such as hashmaps) with the ability to build on top of these types. However, with advances in distributed ledger technology, it has become clear that the primary purpose of smart contract languages is to perform operations with numerical assets, and that the primary quality of these languages is security and verifiability (which is an additional layer of security).
Moreover, unlike Javascript, EVM is inherently platform-specific. We can’t use it without inheriting many of the design decisions that make Ethereum difficult to scale at the base layer: account model, tx format, etc. This is why Solidity can’t be Web3 Javascript, because it would mean that future chains will need to look a lot like Ethereum.
To learn more about the critical points that led to the creation of the language, read the Problem Statement by Sam Blackshear.
It is from these reflections that Move was built, with 4 objectives in mind: first-class assets, flexibility, safety, and verifiability. Like Rust, it’s memory-safe — it prevents dangling references, provides referential transparency for immutable references, and prevents memory leaks. All these properties reduce the attack surface area of Move code. Move also has a formal verifier called the Move Prover. This automated tool allows developers to verify that their code executes exactly as they intended. It is fast and reliable, allowing developers to run it routinely and launch tests in minutes.
The main new feature of the language is the Resource which is a special type that can never be copied or discarded, it can only be moved in the storage. With these safety guarantees, programmers can implement custom safe digital assets but also write better logic for wrapping assets and defining access control policies. Despite these protections, Resources work as ordinary values. They can be stored in data structures, be passed in as arguments and returned by functions. This intuitive design makes programming around digital assets easier (dynamic NFTs, Play to Earn…).
To Go Further
To dive deeper in the Move Language, read the Move Book by the Move Core Team or the one by Damir Shamanaev, the Original Move Paper and explore Awesome Move’s github where you will find many resources. You can also discover the language via this video plus this one by Aptos Ceo or this podcast, and get an overview from an Auditor’s perspective.
If you are a Blockchain Developer and have previous experience on Solana, take the time to read this incredibly complete article by Krešimir Klas detailing Move and comparing Solana/Rust and Sui/Move. And if you have already little knowledge on Move you might want to check this article comparing Core Move with Sui Move. Finally check this page comparing Move and Solidity, this series of articles about why building with Sui Move by Ethos Wallet, as well as Sui and Aptos documentation.
