Alex NorthBrief context
See FIP discussion introducing this at https://github.com/filecoin-project/FIPs/discussions/401.
- The built-in actors API was not designed with untrusted callers in mind
- It will be extremely hard to change any exported API in the future without breaking user actors/contracts
- Indefinite compatibility requirements on a legacy or poorly-conceived interface could present a very significant restriction on future improvements to Filecoin’s protocol and capabilities.
The rough proposal is
- Create a new public API for built-in actors to expose to user actors and off-chain calls.
- Probably use FRC-0042 convention
- Abstract over internal state shape as much as possible
- Limit scope initially to maximise flexibility for change in the future; expand scope later
- Restrict the existing methods to internal-only, reject any call from a non-built-in
- We can continue to evolve these methods in future upgrades
This sheet is a list of all the built-in actors with:
- Their current API, and notes about whether each existing method is appropriate for export
- Notes about what additional API could/should be provided.
This is a bottom-up approach, and should be taken in combination with a top-down use-case-driven approach to determining what will provide the most value.
Notes
Deals & markets
Actors wanting to do/inspect deals should mostly interact with the built-in market actor, not the miner. The built-in market currently has a privileged position. In the future, new market actors will be possible.
Market actors will generally operate on events pushed to them by the miner actor rather than querying miner state. Do no expect rich miner state query methods.
Miner sectors
The schema of miner sector storage is likely to change very much in the future. It is the key state for Filecoin’s fundamental functionality, and we need scope to change it. Examples of the kind of change that could happen (mostly motivated by scale):
- Project Neutron proposed lumping sectors together into super-sectors and removing almost all sector-specific data
- In-development ideas move most sector state off-chain into miner-specific ZK-proof-friendly aggregates, with only summaries and proofs of transition posted on chain.
- Proof scheduling (deadlines, partitions etc) could change significantly if new proof algorithms change sector sizes or security properties.
Anything to do with QA power may be subject to change long term if we separate rewards for proven storage from rewards for staking. This might be worth risking though - we could replace QA Power values with Raw Byte power values.
Questions
- What to do for methods intended to be called top-level, usually by miner operators (accounts, multisig)?
- Could be nice to re-export them so that non-exported are strictly private
- Export allows future multi-sigs to call them
- Increases scope, not very helpful yet