Filecoin nv17 technical scope proposal

Last edited
Aug 12, 2022 12:09 AM

This is a plan for implementation of a bunch of network changes that the PL Lotus and Cryptonet teams propose for nv17. Without a concrete plan, we have been lacking ability to make decisions about what to prioritise and when to target completion.

Items below are still subject to network governance process, which will ultimately decide on the upgrade scope. However, most items are dominated by changes to built-in actors or the FVM, so require little effort from node implementation teams.

Preparing for FVM M2

A chief constraint of scope for this upgrade is to get out of the way to provide space for FVM M2-EVM to have a space to deploy in a network upgrade in late 2022. I have assumed this is a reasonable possibility for that team.

If FVM-M2 is not projected to be ready for a 2022 upgrade, then there is a good opportunity to get more into nv17 (as the only remaining upgrade in 2022). In particular, we could pull the programmable storage market architecture into scope, which would greatly expand the scope of user-programmed storage-related actors/contracts after M2.


The list below only includes items subject to network governance (i.e. FIPs). However, some of the items also enshrine a calling convention for native actors, which would otherwise be only an FRC. So setting on FRC-0042 is an implicit pre-requisite to those items.


Proposed in-scope

Beneficiary address (FIP-0029)

Value: High

Actors effort: Small (implemented, needs tests) – IPFSForce

Node effort: Small (just UI)

High leverage in supporting off-chain lending markets (and with FVM, on-chain too)

Fixed pre-commit deposit (FIP-0034, discuss)

Value: High (restores security)

Actors effort: Small (implemented, needs migration) – @Kuba Sztandera (w/ @Aayush Rajasekaran)

Node effort: Small (migration)

FIP approved and implemented.

Forward-compatibility shim for pre-commit (FIP-0041, discuss)

Value: Medium

Actors effort: Small (implemented, needs tests) – @Kuba Sztandera

Node effort: Small

A very small change, the main value is getting it in before we force SPs to change their operations with the full programmable storage architecture.

Decouple FIL+ from markets (FIP-XXXX, discuss)

Value: High

Actors effort: Large (4-6 weeks, possible migration) – @Alex North @Wyatt Daviau

Node effort: Small

Critical pre-req for user-programmed storage markets (including bounties, data DAOs, etc).

Critical pre-req for FIL+ deal extension.

Supports long-term FIL+ commitments independent of markets. Supports FIL+ longer than sector life. Provides upgrade path in case of PoRep bug. Simplifies QA power (unblocks update-able sector storage).

PoRep security policy, proof expiration (FIP-XXXX, discuss)

Value: High

Actors effort: Medium (analysis, and implementation) – @Kuba Sztandera

Node effort: None

Both a governance action (requires technical analysis) and implementation of a mechanism. Pre-requisite (in my opinion) for FIP-0036.

Sector duration multiplier (FIP-0036, discuss)

Value: High

Actors effort: Medium – ???

Node effort: Low

Stabilise storage commitments and token flows. Governance approval not yet clear.

Standard message authentication (FIP-XXXX, discuss)

Value: High

Actors effort: Small – @Aayush Rajasekaran

Node effort: None

Supports user-programmable actors/contracts as clients of the built-in market. Enshrines FIP-0042. It’s possible to defer this to nv18 without great loss.

This replaces FIP-0035.

Optimize FVM gas costs for large messages

Value: Medium?

Actors effort: Medium ??? – @Steven Allen

Node effort: None (likely)

Initial work is analysis of high gas for large sector recoveries, which is affecting some SP operations. If we discover a worthwhile problem/opportunity to ease the pain, we’ll try to ship it soon. May not require a FIP if it’s not a functional change.

Possibly in-scope

A network upgrade makes sense without the items below, but we may wish to pull them into scope either (a) to realise their value sooner, or (b) to reduce the scope remaining for subsequent upgrades, such as the ones enabling FVM user-programmable actors/contracts.

Re-architecture for programmable markets (FIP-XXXX, discuss)

Value: High (allows user-programmed markets, bounties, repair actors, storage DAOs etc)

Actors effort: Large (3-5 weeks)

Node effort: Medium

Would enable development of new markets as soon as user-programmability is live. Changes the parameters to PoRep, so changes SP operations. Would be most attractive if we can find a two-stage upgrade where we add the new way now, then remove the old way later.

This must come after separating FIL+ from markets, so represents the “long pole” if brought into scope.

Could be deferred to FVM M2, but is a major change we might not want to land simultaneously. Could be brought into scope now to avoid complexity around FVM M2 upgrade, or risk being deferred even further.

Define exported methods for built-in actors (FIP-XXXX, discuss)

Value: Medium

Actors effort: Medium (2-3 weeks)

Node effort: Low???

Only needed for FVM-M2, could be deferred to launch at the same time. Could be brought into scope to reduce scope of subsequent upgrade.

Remove unwanted actor code

Value: Low

Actors effort: Medium (1-2 weeks)

Node effort: None

Needed for FVM M2 actors to interact with built-ins.

Signature domain separation (FIP-XXXX, discuss)

Value: Medium

Actors effort: Low

Node effort: Medium

Guard against future errors or deception. Needs clearer motivation. Could be deferred to FVM M2 or beyond.

Deferred to subsequent upgrades

Account abstraction (discuss)

Value: High

Actors effort: Small

Node effort: Large

Primarily driven by FVM-EVM

Remove DeleteActor

Value: Low

Actors effort: Small

Node effort: None

Only needed for predictable actor addresses (or if EVM shim calls it)

Predictable actor addresses - CREATE2 (discuss)

Value: Low

Actors effort: Small

Node effort: Small

Only relevant for FVM M2-native (or if needed for FVM M2-EVM)

New syscalls

Value: Medium

Actors effort: None

Node effort: Medium

New environment and capabilities for user actors