From 19fe468dbce007ed4821e01c7d185622823d35ad Mon Sep 17 00:00:00 2001 From: Greg Fitzgerald Date: Fri, 12 Jul 2019 21:12:55 -0600 Subject: [PATCH] Add design proposal to embed Libra's Move (#5067) * Add design proposal to embed Libra's Move * Apply review feedback * Pipeline VM -> the runtime * defines -> define --- book/src/SUMMARY.md | 1 + book/src/embedding-move.md | 66 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 67 insertions(+) create mode 100644 book/src/embedding-move.md diff --git a/book/src/SUMMARY.md b/book/src/SUMMARY.md index 681a9c4fbe..ca487e80fa 100644 --- a/book/src/SUMMARY.md +++ b/book/src/SUMMARY.md @@ -58,6 +58,7 @@ - [Credit-only Accounts](credit-only-credit-debit-accounts.md) - [Validator](validator-proposal.md) - [Simple Payment and State Verification](simple-payment-and-state-verification.md) + - [Embedding the Move Langauge](embedding-move.md) - [Implemented Design Proposals](implemented-proposals.md) - [Blocktree](blocktree.md) diff --git a/book/src/embedding-move.md b/book/src/embedding-move.md new file mode 100644 index 0000000000..a289615fa7 --- /dev/null +++ b/book/src/embedding-move.md @@ -0,0 +1,66 @@ +# Embedding the Move Language + +## Problem + +Solana enables developers to write on-chain programs in general purpose +programming languages such as C or Rust, but those programs contain +Solana-specific mechanisms. For example, there isn't another chain that asks +developers to create a Rust module with a `process_instruction(KeyedAccounts)` +function. Whenever practical, Solana should offer dApp developers more portable +options. + +Until just recently, no popular blockchain offered a language that could expose +the value of Solana's massively parallel [runtime](runtime.md). Solidity +contracts, for example, do not separate references to shared data from contract +code, and therefore need to be executed serially to ensure deterministic +behavior. In practice we see that the most aggressively optimized EVM-based +blockchains all seem to peak out around 1,200 TPS - a small fraction of what +Solana can do. The Libra project, on the other hand, designed an on-chain +programming language called Move that is more suitable for parallel execution. +Like Solana's runtime, Move programs depend on accounts for all shared state. + +The biggest design difference between Solana's runtime and Libra's Move VM is +how they manage safe invocations between modules. Solana took an operating +systems approach and Libra took the domain-specific language approach. In the +runtime, a module must trap back into the runtime to ensure the caller's module +did not write to data owned by the callee. Likewise, when the callee completes, +it must again trap back to the runtime to ensure the callee did not write to +data owned by the caller. Move, on the other hand, includes an advanced type +system that allows these checks to be run by its bytecode verifier. Because +Move bytecode can be verified, the cost of verification is paid just once, at +the time the module is loaded on-chain. In the runtime, the cost is paid each +time a transaction crosses between modules. The difference is similar in spirit +to the difference between a dynamically-typed language like Python versus a +statically-typed language like Java. Solana's runtime allows dApps to be +written in general purpose programming languages, but that comes with the cost +of runtime checks when jumping between programs. + +This proposal attempts to define a way to embed the Move VM such that: + +* cross-module invocations within Move do not require the runtime's + cross-program runtime checks +* Move programs can leverage functionality in other Solana programs and vice + versa +* Solana's runtime parallelism is exposed to batches of Move and non-Move + transactions + +## Proposed Solution + +### Move VM as a Solana loader + +The Move VM shall be embedded as a Solana loader under the identifier +`MOVE_PROGRAM_ID`, so that Move modules can be marked as `executable` with the +VM as its `owner`. This will allow modules to load module dependencies, as well +as allow for parallel execution of Move scripts. + +All data accounts owned by Move modules must set their owners to the loader, +`MOVE_PROGRAM_ID`. Since Move modules encapsulate their account data in the +same way Solana programs encapsulate theirs, the Move module owner should be +embedded in the account data. The runtime will grant write access to the Move +VM, and Move grants access to the module accounts. + +### Interacting with Solana programs + +To invoke instructions in non-Move programs, Solana would need to extend the +Move VM with a `process_instruction()` system call. It would work the same as +`process_instruction()` Rust BPF programs.