Introducing the Filecoin Virtual Machine

[raulk]

Following a few months of incubation, the EngRes team at Protocol Labs recently open sourced the reference implementation for the FVM (ref-fvm), released the FVM website, and launched the FVM Foundry and the Early Builders programme.

Now, we are ready to formally propose to the Filecoin community the introduction of the Filecoin Virtual Machine into the protocol specifications.

The FVM replaces the current non-programmable virtual machine, and serves as the foundation for a re-engineered Wasm-based execution layer that enables on-chain user-programmability on the Filecoin network.

This discussion accompanies the fundamental FVM FIP submission. The intention of that FIP is to act as baseline specification of the FVM design. It is accompanied by a reference implementation: ref-fvm. This FIP will be followed by two other FIPs to:

1. propose an atomic execution layer switch to a non-programmable version of the FVM, and
2. a rearchitecture of the gas model to pave the way for user-programmability

Here's a copy of the FIP's abstract to seed this discussion:

We specify the Filecoin Virtual Machine (FVM), a IPLD-ready Wasm-based execution layer capable of running arbitrary user-provided code. The FVM replaces the existing non-programmable execution layer.

The logic of native actors (the equivalent of smart contracts in Filecoin) is deployed as Wasm bytecode. Foreign actors targeting non-Filecoin runtimes such as the Ethereum Virtual Machine are also supported through runtime emulation.

We provide a reference architecture for the FVM, and explain its various components: (a) Machine, (b) Call Manager, (c) Invocation Container, (e) Syscalls, and (f) Externs. We define the contract that actor code must adhere to, the catalogue of available syscalls, the mechanics of IPLD state manipulation, and further technical details.

This FIP introduces the technical foundations of the FVM. It will be accompanied by two subsequent FIPs. They will respectively propose: (1) an atomic switch from the current VM to a non-programmable version of the FVM, and (2) a new gas model adequate for on-chain user-programmability.

Please use this thread to hold general discussion/debate on the overall approach and strategy proposed. Post review comments on the FIP itself to comment on specific points.

[anorth]

I made some comments that spawned discussion on the FIP document PR, that should really have been made here. Linking to a few to make them a little more discoverable. Please continue those discussion here rather than in the soon-to-be-merged PR.

• on standardizing the invocation parameter semantics for interoperability, IDLs etc.
• on IPLD encoding within actors while the VM decodes to validate links 1 2, 3