Filecoin Core Devs Meeting 32 Agenda

[jennijuju]

Filecoin Core Devs Meeting 32 Agenda

• Meeting Date & Time: Thursday, December 2nd @ 16:00 UTC
• Meeting will be recorded.

Agenda

• Discussing updates, hurdles, questions, and challenges from Filecoin implementations:
  • Lotus
  • Forest
  • Fuhon
  • Venus
    • Small miner reward pooling
• Updates from Filecoin Foundation
  • Review of new FIPs workflow
• Q&A

[jennijuju]

I invited @dirkmc from Bedrock-ignite team to give a quick overview of boost, a market implementation!

[jennijuju]

also inviting @raulk to give some updates on fvm!

[jennijuju]

Snap deal updates @arajasek "

open question to chain safe - have they started to look at the fip and planning on implementing the rust actor of snap deal?

[raulk]

Excited to be participating. Here is what I'll be going through today.

Materials

• Introducing the Filecoin Virtual Machine talk @ Orbit
• Equivalent blogpost.
• Technical documentation.
  • FVM architecture: https://github.com/filecoin-project/fvm-project/blob/main/01-architecture.md
  • EVM <> FVM mapping: EVM <> FVM mapping fvm-specs#39

FVM key characteristics

• Polyglot WASM-based runtime environment for on-chain computation over the state tree.
• Strong and native primitives for efficient IPLD state access and manipulation.
• Actors are deployed as WASM bundles on chain
  • Code is decoupled from actors
  • Two-step deployment process:
    1. Install the actor through InitActor#LoadCode(bytecode) -> CID
    2. Instantiate the actor through InitActor#Exec(CID, constructor_params...) -> Address)
• State tree now stores code too, possibly in a separate subtree.
• Built-in actors deployed as WASM bundles on chain, and mapped to static inline CIDs.
• Support for foreign runtimes, where the first foreign runtime we support is the EVM through https://github.com/bluealloy/revm/ or https://github.com/rust-blockchain/evm.
  • EVM foreign runtime is just another actor whose WASM bytecode is deployed on-chain.
  • EVM smart contracts are instantiations of that actor, supplying the EVM bytecode as a constructor parameter.
• Native actors can be written in any programming language that can target WASM. In practice, you probably want to build in Rust or other low-level languages that don't drag along runtime overhead (e.g. GC, JIT, etc).

Roadmap

FVM and SDK reference implementations

• Protocol Labs is developing candidate reference implementations of the FVM and SDK.
• FVM reference implementation is written in Rust,
  • Interacting with non-Rust nodes (e.g. Lotus, Venus, Fuhon) through inbound and outbound FFI.
    • Read about boundaries in the technical architecture.
  • We are keeping the interactions as lightweight and minimal as possible, to avoid death by a thousand cuts in terms of performance as we traverse language boundaries.
• Thanks to the Forest implementation => various parts are based on it! \o/
• First and reference SDK is also built in Rust, integrated with the canonical actors through a Runtime => SDK shim.
• Repo is currently private, but plan to publish it by end of next week if all goes well.

Canonical built-in actors

With the FVM having formalized bytecode (WASM), and built-in actors being deployed as WASM bytecode, we depart from the model of replicated native actor implementations in different languages, and can converge towards a single canonical built-in actors codebase producing WASM bytecode.

There are two actors implementations currently: Go and Rust. This presented a dichotomy: Go actors secure mainnet, but Go carries over the runtime overhead to WASM producing code bloat and reduced performance; conversely, Rust actors don't secure the mainnet yet, but the Rust toolchain is fantastically equipped to produce concise WASM outputs with little to zero overhead ([no_std]) and with ample degree of customization of low-level elements (e.g. allocator). The Rust WASM ecosystem is also orders of magnitude more developed than the Go one.

We looked at using TinyGo as a solution to produce succint WASM code from Go actors, but its limitations were not encouraging.

Therefore, we believe the right choice is to promote the Rust actors into the canonical actors, investing heavily in their robustness, performance, and security (audits!). We'd like to propose to extract the Rust actors into a separate codebase, where all implementor teams collaborate on.

FIP submission

We expect to submit an FVM FIP in January, so that there's enough time to discuss/evaluate/implement before the network upgrade for the deployment of Phase 1 (entire network runs built-in actors on FVM + gas model changes to prepare the system for user programmability).

How does this affect Filecoin implementations

• Start integrating the FVM into your node implementations in January 2022.
• Deprecate your native actors.