Skip to main content

Execution Environments

MOI’s context-aware compute engine is designed to offer multiple execution environments. They are as follows:

PISA​

PISA is the Ethereum Virtual Machine (EVM) based execution environment built into JUG and supports the execution of EVM bytecode compiled down from supported languages such as Solidity. The opensource EVM jump-table and stack machine are plugged into JUG and will be able to run the participant’s logic on top of it.

MERU​

WebAssembly (Wasm) is a standard developed by the World Wide Web Consortium (W3C) to deploy code in any browser. Its high performant nature and ability to run code at near-native speeds while still being platform independent make it a prime candidate for a decentralized compute environment.

Wasm allows code written in languages such as C/C++, Rust, TypeScript, and Go to be compiled down to Wasm bytecode and then be executed in sandboxed stack machine allowing for a memory safe and platform-independent runtime. Wasm’s divergence from purely web-centric use cases towards serverside use cases powered by Emscripten and WASI has enabled a series of Wasm runtimes such as Wasmtime (Bytecode Alliance) and Wasmer.

MERU is the WebAssembly (Wasm) based execution environment for JUG and supports the execution of Wasm bytecode compiled down from several higher-level languages such as Rust, AssemblyScript, and Golang. The Wasm Virtual Machine will be an abstraction around the wasmer-go runtime and the Wasm bytecode will be compiled using the Singlepass compiler during runtime.

Wasmer​

Wasmer is a universal Wasm runtime with support to embed it in multiple languages and compile with multiple compilers. It has implementations in Rust, Golang, C/C++, Python, etc. JUG uses the Go implementation because of the ability to natively integrate with the rest of the engine. This choice also allows us to avoid multiple layers of abstraction that will impact performance.

The avoidable layer of abstraction is the bindings required to work with an execution environment written in a different language such as Rust. The currently unavoidable abstraction is the glue code required to pass higher-levelstructures into a Wasm execution environment. The WebAssembly Interface Types (WIT) proposal is currently under development but until such a time when it has a stable implementation, we need a system for passing these higher-level types. The current implementation is designed to use Protocol Buffers as an encoding format because of its ability to serialize efficiently and be language agnostic. The structures are serialized as Protocol Buffers and written to Linear Memory.

Linear Memory​

Linear memory is a memory addressing technique in which memory is placed or organized in a single continuous address space. Hence memory allocation and deallocation happen at the time of execution of a function or an instruction. It is also called Heap Allocation as we use the heap-based memory management techniques usually found in most Operating Systems.

HANOI​

HANOI is a conceptual execution environment for parallelized network compute and will achieve truly decentralized compute by distributing the flow of logic itself. This may be achieved by a network level “bytecode” where opcodes represent a set of compute interaction between the nodes on the compute cluster. HANOI will extend the Krama Multi-Party Compute (KMPC) protocol and leverage it to perform logical and arithmetic operations on data at a network level. This will ensure that none of the participants will have access to the full input data during the computation.

HANOI aims to be a General-Purpose Multiparty Compute framework by implementing logical and arithmetic instructions as network interactions and leveraging this base functionality for higher-level computations. Let us use the Tower of Hanoi Analogy to understand the need for multi-party compute:

Tower of Hanoi problem

Figure: Tower of Hanoi problem

The game Tower of Hanoi is a logical puzzle with 3 stacks of discs of varying sizes. The goal is to align the discs onto a single stack in an increasing order of size.

The nodes in a HANOI compute cluster may be thought of like the stack towers and the discs as the input data. Each move of the disc then represents a compute interaction in the cluster. The nodes will work together to perform a series of interactions that are pre-determined at compile time to fulfill the sequential and parallel flow of computation. A completed computation is represented by the end state of the puzzle. A stack of disks is ordered by size.

Other Potential Execution Environments​

Some of the other potential execution environments that have been considered and may be implemented in the future are a JVM-based and ELF-BPF-based environment, allowing existing Linux and Java running hardware to re-purpose their resources to serving MOI.