Substrate Move System Pallet (part 1)
- Team Name: Eiger
- Payment Address: Fiat 14.04.2023, 16:50 UTC+3
- Level: 3
Project Overview 📄​
This application is a response to the Move Smart Contract Pallet RFP.
Overview​
Some terminology first:
-
Substrate Move System Pallet - A Substrate system pallet that can be used as a building block for substrate-based chains, it exposes interfaces to interact with the Move virtual machine.
-
Substrate Move - A Move language fork that is Substrate compatible.
Objectives:
- The goal is to provide a Substrate system pallet that allows to deploy and interact with Smart Contracts written in the Move language, by providing a Move Virtual Machine (MoveVM) as a pallet.
- We plan on exploring a fork of the Move language, so it’s adjusted to work with the Substrate ecosystem, as well as developing a Substrate system pallet that allows the execution of Move smart contracts.
- The project directly improves the growth potential of the Substrate based ecosystem by providing support for one of the most modern smart contract programming languages and VM types out there - Move.
- We are interested in creating this project because we are firm believers in the modular vision of web3, and only by collaborative efforts on improving and unifying the technology between different chains and the languages, will we get better products as an outcome.
Goal - Level up the growth possibilities of the Substrate ecosystem by providing a way to develop and execute Move smart contracts on Substrate.
This is the first phase of a 3-phase development program:
- In-Depth Exploration and Assessment of MoveVM and Substrate Integration
- MoveVM compatibility work and Subtrate Pallet development
- Finalising the Substrate-Compatible MoveVM
Project Details​
Prior work
We are basing the core architecture and many of the design decisions on the Pontem networks developed system pallet for Move VM. They had maintained their own fork of the Diems Move language, which was used as the base execution layer for their version. Both of these repositories have not been maintained for a very long time already.
♻️ We aren't seeking to maintain any of the existing codebase; rather, we aim for a full revival through a new greenfield project. Our rationale for this stems from the substantial advancements made in the Rust, Substrate, and Move ecosystems since Pontem’s latest commits from over a year ago. We believe that handling potential code rot due to the passage of time might be more labor-intensive than starting afresh and drawing upon existing projects for more current guidelines.
Documentation of core components, architecture
-
Substrate Move:
The first part of the project will be a MoveVM fork, as some major changes will need to be made to the codebase for it to be substrate compatible. For example:
no_std
compatibility: Making it lightweight and suitable for use in Substrate runtimes.wasm32
 target compatibility: Adapting all the VM’s different components to work efficiently and securely on the wasm32 target architecture.
We plan on creating and maintaining the fork in a manner that would allow us and the community to easily follow and track changes from the upstream, thus making the maintenance and change tracking to be much simpler.
At the time of writing this application, we suspect that this will be needed because this is what also Pontem had to do to support it in their version. This will be further researched and assessed during the first milestone.
-
Move VM system pallet:
The second part of the project will be a Substrate virtual machine pallet in Substrate. This is a modular component that is needed to integrate a specific new VM into a Substrate runtime. It will serve as a bridge between the runtime and the Move VM, managing resources and translating data or actions between the two environments.
API specifications
As a minimum, we plan on providing all of the RPC calls that the Pontem crate did. As the team progresses with the implementation, we might add or remove RPC calls as we best see fit.
Move language has a concept of “gas” for executing contracts, whereas Polkadot uses “Weights”. Each Move transaction invocation requires providing a gas limit for execution, and it’s necessary to be able to transform the values between weight and gas:
mvm_gasToWeight
mvm_weightToGas
Estimating gas for different operations:
mvm_estimateGasPublish
mvm_estimateGasExecute
Working with the primitives of the Move language:
mvm_getResource
mvm_getModuleABI
mvm_getModule
Tech stack
We plan on using Rust for developing the system pallets and using existing Move language smart contracts for end-to-end testing of the whole workflow.
Notes
Because the Move language requires a fork to work with Substrate chains, and modifications to the address size, there might be incompatibilities with deploying existing Move Smart Contracts from other chains that make use of the address properties size, as well as the compiled ABI and bytecode for those contracts might be invalid. To deploy on our MoveVM system pallet, the forked toolchain must be used to re-compile all smart contracts. The address size of Move language is configurable via a feature switch with 32-bits being one of the options.
Ecosystem Fit​
Move is a smart contract programming language that emphasizes access control and scarcity, offering some unique advantages over other popular VMs in blockchain ecosystems.
The importance of bringing the MoveVM to Polkadot was recognized over two years ago when Pontem Network started working on a Move virtual machine pallet to execute Move smart contracts on Substrate-based chains. Although they discontinued the project and haven't updated the codebase for over a year, the W3F still keeps this RFP, which serves as evidence that porting the MoveVM is crucial for the future of the Polkadot network.
We concur with this perspective and have actually been actively researching the MoveVM - exactly with a similar idea of helping port it over to other chains.