Motoko (1-pager)
1. Objective
The objective of this proposal is to gain community approval on DFINITY’s plans to extend and maintain Motoko as an attractive and feasible option for canister smart contract development on the IC.
2. Background
Motoko was conceived at a time when language options for development on the IC were few and had very sharp edges. While launching a new language is fraught with risk, it was felt that the available languages and compilers targeting WebAssembly were either too unsafe or too impractical, forgoing memory safety or requiring manual construction of asynchronous code. The situation has improved and Rust is now a viable option, but Motoko arguably still provides the least friction and most safety when authoring IC canisters.
Nevertheless, the challenges of supporting a new language and ecosystem are considerable, requiring heavy investment in:
-
Compiler technology
-
Runtime system (e.g. robust and scalable memory management, serialization etc.)
-
Libraries
-
Tooling (e.g. IDE support, debuggers, profilers, you name ‘em)
-
Documentation
3. Why this is important
The adoption of any new technology, including the IC, requires an easy on-ramp. Technology that is hard to use will struggle to thrive.
Motoko, with its relative ease of use and static enforcement of IC constraints provides a gentle introduction to the IC. However, in order to scale to industrial applications, Motoko and its toolchain will require significant research and development to deliver increased performance, scalability and productivity.
4. Topics under this project
Development of Motoko and its toolchain is a broad endeavour, covering both research and engineering. Our roadmap includes some of the commitments listed below.
Our ability to adhere to these mid- and long-term commitments will depend on resourcing and other developments. These commitment include:
-
Improved scalability of the garbage collector, most likely by adopting an incremental, generational collector.
-
Gaining and maintaining parity with newer IC features such as heartbeat messages and the new 128bit cycles API.
-
Improved scalability of stable variable serialization including reduced memory consumption and improved robustness (e.g. to stack overflow).
-
Opt-in, direct access to stable memory for scenarios unsuited to stable variables.
-
Language enhancements, such as better abstraction facilities for asynchronous code, generics with shared type, error propagation syntax, object composition/modification syntax, and other quality-of-life improvements.
-
Tooling improvements: more flexible package management, enhanced IDE support.
Improved logging and debugging support when and as supported by the IC.
- Library development, expanding existing libraries (e.g. Iter.mo, Char.mo) and adding new ones (e.g. Time.mo)
5. Key milestones
-
Scalability: Provide access to most of 4GB Wasm memory for heap and large stable variable data, without compromising ability to upgrade.
-
Language: Support efficient and safe abstraction of asynchronous code.
-
Parity: Expose all (reasonable) IC System APIs in suitable safe and natural abstractions.
-
Ecosystem: Offer a wide selection of commonly requested libraries.
6. Discussion Leads
Andreas Rossberg and Claudio Russo
7. Why the DFINITY Foundation should make this a long-running R&D project
Motoko showcases the facilities of the IC and Candid in a coherent, seamless design unobscured by the library or macro-based encodings required to integrate third party languages.
Although not the only choice of language, most external projects to date have chosen Motoko as their development language. The Foundation has an interest and a responsibility to maintain and grow the value of these external investments.
8. Skills and Expertise necessary to accomplish this
Type theory, concurrency theory, language design and implementation (compilation), memory management/garbage collection, documentation, library design.
9. Open Research questions
- The cost model of the IC is more abstract than typical hardware. Traditional compilers optimize for speed, or, occasionally code and memory size. Optimizing
for IC cycle consumption and Wasm page use requires atypical design choices.
-
The IC is a distributed computing system using asynchronous communication. Motoko’s actor model addresses some of the challenges of programming such a system, but still lacks good support for ensuring concurrency correctness, abstracting over asynchronous code, distributed transactions and other forms of actor coordination all of which are open research questions.
-
The IC currently provides a traditional form of access control based on caller identity, a simple form of stack inspection. This approach has known limitations which others have proposed are better addressed by capability based systems. Adding capabilities based security to both the IC and Motoko is an open, long-term research problem.
-
Multi-canister upgrade. Motoko supports actor classes, allowing programmatic installation of networks of actors, but (like the IC in general) has no good support for how to programmatically and safely upgrade installed instances.
10. Examples where community can integrate into project
Motoko and its tooling are developed in the open. We welcome and encourage feedback, suggestions and contributions from the community, particularly in the development of libraries which are sorely needed. Notable examples include a fully-fledged Time library and various cryptographic libraries normally expected on blockchain platforms.
Similarly, documentation is an open-ended project, and contributions from the community, e.g., tutorials, could help to improve the discoverability and understandability of Motoko features and its integration with the platform.
11. What we are asking the community
-
Review comments, ask questions, give feedback
-
Vote accept or reject on NNS Motion