Alex NorthThis 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.
FRCs
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.
Background
- Proposed in-scope
- Beneficiary address (FIP-0029)
- Fixed pre-commit deposit (FIP-0034, discuss)
- Forward-compatibility shim for pre-commit (FIP-0041, discuss)
- Decouple FIL+ from markets (FIP-XXXX, discuss)
- PoRep security policy, proof expiration (FIP-XXXX, discuss)
- Sector duration multiplier (FIP-0036, discuss)
- Standard message authentication (FIP-XXXX, discuss)
- Optimize FVM gas costs for large messages
- Possibly in-scope
- Re-architecture for programmable markets (FIP-XXXX, discuss)
- Define exported methods for built-in actors (FIP-XXXX, discuss)
- Remove unwanted actor code
- Signature domain separation (FIP-XXXX, discuss)
- Deferred to subsequent upgrades
- Account abstraction (discuss)
- Remove DeleteActor
- Predictable actor addresses - CREATE2 (discuss)
- New syscalls
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) – @Kubuxu (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) – @Kubuxu
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) – @Kubuxu
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