Design VM - Glow-Lang/glow GitHub Wiki

How best to design a VM for Glow?

We want a VM that we will use for both consensus-side and client-side software. Or rather, the two will have a common core, plus specific extensions for capabilities present in one but not the other (e.g. clients can use off-chain communication, sign, etc.; only the consensus can do withdrawal transfers).

The VM will be suitable for purely off-chain interactions, such as the protocol to negotiate on-chain parameters (interaction variables, fees, collaterals, timeouts). This in itself may already involve off-chain RNG generation (as in coinflip) for nonces, or auctions for determining who will post which messages and get conceded what fee by the other one.

Ideally, the consensus algorithm for the state channel support will itself be a reflective implementation of the VM in terms of expressed in terms of a lower-level implementation of the VM that uses a mix of off-chain communication plus direct-style consensus.

Also, we will implement the client-side VM interpreter in such a way that we persist continuations and any external communication uses 2 phase commit so you can't send anything before the continuation that sends is committed. Then, we will implement a subset of Scheme and/or a superset of Glow on top of that VM. We could call that persistent Scheme gloss.

We need to provide a guarantee that continuations as persisted in the database they will keep working as Gambit, Gerbil and Glow are upgraded. This means we probably can't rely on Gambit's builtin VM frame capture and migration.