savo.la

2019-12-05

Introduction to Gate

Background

The Gate project is the latest in a line of portable execution state experiments. It was preceded by Concrete (a custom Python implementation) and Tap (partial program state replication for CPython). In comparison, Gate is programming language agnostic and much more advanced.

Development of Gate began in 2015, motivated by the announcement of WebAssembly (wasm). The choice of program format was a fundamental problem, and wasm provided an excellent solution for that: it's general, portable and standard. Gate includes wag, a wasm compiler built to meet Gate's special requirements.

Portable execution state

In short, it's about migration of running programs between computers. Virtual machines and other checkpoint/restore solutions have been doing that for a long time, but the portable part imposes additional requirements: the host systems might not be similar, and the environments might be even more varied. Also, with Gate, the unit can be very small: it works one process at a time.

Core challenges:

Wasm helps with program code and memory contents. The remaining problem is the suspension and restoration of a running program, including a consistent and portable snapshot of stack variables.

While a program's internal state can be shipped around as a self-contained module and loaded by a self-sufficient runtime, external resource state restoration is more involved. The details depend on the resource type and the environment. In the simplest case, the host doesn't support the resource type, and the resource remains suspended while the program lives in that environment. In some cases it might be appropriate to tell the program that the resource was lost, and the program should try to reacquire it. In the best-case scenario, the resource can be reallocated behind the scenes so that the program doesn't notice anything.

Untrusted code

Portability requires clearly defined interfaces. They can be leveraged as security boundaries to support safe execution of untrusted programs. Gate is designed to handle remote code execution requests from unknown or anonymous sources.

Execution environment hardening and resource management are the obvious challenges. Gate programs have a tiny runtime ABI surface, which means that the execution environment can employ a very short system call whitelist. All interaction happens through a single IPC channel, which means that the execution environment doesn't need to contain anything, only isolate the processes from all resources.

—

Use cases

The following sections discuss some potential applications of this technology.

Self-sufficient data files

This idea was an early source of inspiration: solve document authoring issues by moving the editing functionality inside the document file. You'll no longer have to worry about which office suites and file formats are compatible!

The program-in-a-data-file obviously needs some kind of access to a display and input devices, but that interface can be a lot simpler and standardized than a file format specification. In that sense it's similar to a web app; from that point of view, this is a portable alternative to a document stored in a cloud app.

Upgrading the editing functionality would probably mean exporting and importing the data. Since the old data file is a program, it's a protocol: the old file is interrogated by the new program version.

Migration and replication in heterogeneous environment

A document-program (described in the previous section) would be explicitly copied by users between computers, including mobile devices, workstations and servers. But an application's internal architecture could also directly take advantage of the seamless portability of execution state, and migrate itself or parts of itself between different types of hosts. A mobile app could continue running on a cloud server when the user closes its UI. A service could move to a bigger server when it needs more memory—or be suspended when its quota runs out.

A fork-like programming construct could be used to create remote child processes.

Bring your own controller

A network protocol could be defined in terms of sending and receiving programs. A client program executed on a server can access local APIs instead of repeatedly making requests over the network. Like GraphQL but Turing complete. If your request-program seems to hang, connect to its debug interface to investigate!

Things get interesting if the client can leave a detached agent program running on the server. The agent could be preparing a response over a longer period of time, to be delivered when the client reconnects. Or it could represent the client in peer communications while the client is disconnected. It could be used to animate objects in a game world.

This use case doesn't actually require state portability; it is primarily based on resource abstraction and safe execution of untrusted code. But state portability might allow a long-lived agent to inhabit a distributed virtual world.

Serverless computing (function-as-a-service) is somewhat related to this—especially some newer technologies that have lower overhead. However, the fundamental difference is that FaaS providers run their customers' programs which go on to serve end-user requests, while Gate is designed to serve end-user requests which are programs.

—

Project status

Gate's core runtime component implements the portable execution state and safe execution features. It supports Linux (including Android) on x86-64 and ARM64 processors.

A server component implements high-level invocation, suspension, resuming, snapshotting and restoring, with an HTTP API. Programs can be uploaded directly or looked up via IPFS. Proper resource usage limits are still work-in-progress.

The list of available services is short, and user program APIs still need work.

Anyway, Gate is now open at gate.computer!

Timo Savola