Direct FIL+ is a label for changes to the Filecoin built-in actors, and the components that interact with them, to enable gas-cheap data onboarding, including Filecoin Plus. The built-in storage market actor is bypassed, and the verified registry’s on-chain allocation/claim record suffices to represent a simple “deal”. Direct data onboarding can’t handle client payments (yet), but most deals today have no on-chain payment anyway.

After the initial Direct FIL+ changes, subsequent, smaller changes will be possible to support scalable FIL+ allocations (single transaction covering multiple sectors) and flexibility for other kinds of data applications.

See also:

Judging by analysis of some batched deal and onboarding messages from mainnet, the potential gas savings for Direct FIL+ onboarding, as compared with a built-in market verified deal, are:

If participants do choose to use a built-in market deal (e.g. for a client payment) but take advantage of the new APIs, deals will not need to be specified or checked at pre-commit. The PreCommitSectorBatch gas reduction will benefit these parties too.

Note that the reduction in total gas costs is accompanied by a change in the parties paying them. Instead of the SP paying for PublishStorageDeals, the client pays for creating a datacap allocation (~15% of the PSD cost). Additional mechanisms could be added so that the SP pays this cost, if needed.

The first-order impacts of this are reduced SP onboarding costs and reduced variability in those costs, improving total returns. Reduced gas use for onboarding reduces competition for chain bandwidth, likely leading to a reduction in base fee and transaction costs for other parties.

Second-order effects of reduced gas usage and base fee include reduced base fee burn rate (which accounts for ~12.5% of net circulating supply outflows) in the near term. Reduced onboarding costs may induce more onboarding (locking pledge accounts for the other 87.5% of supply outflows) and user demand for other transactions, more likely over a longer term.

A verified client going direct can immediately specify a 5-year maximum term. The storage provider can only up-front commit a sector for 1.5 years (3.5 years after FIP-0052), but if the client has allowed it, they will be able to extend the sector out to the 5-year maximum while retaining full QAP with no further client interaction.

The changes also enable the onboarding of data without a FIL+ allocation or any deal with the built-in market. Details of the data onboarded are still committed to the blockchain (in message history) but without any facility for on-chain client payments. Direct data onboarding without FIL+ will be even cheaper in gas than using FIL+, and possibly cheap enough for some SPs to break even on paid-for data storage.

The changes will involve the creation and use of new methods in the built-in miner actor for sector onboarding. These will parallel the existing ones, but accept new parameters. The existing methods and flows will continue to work and behave as they have in the past, with minimal breaking changes. Participants can continue using these methods while the downstream changes to support Direct FIL+ are maturing, but will not be able to take advantage of the benefits until switching to new flows.

The new onboarding methods will also be capable of supporting existing flows, so the old methods may eventually be deprecated to reduce code complexity. Such deprecation would require an additional FIP and is not imminent.

Work required by PL Lotus and Boost teams is sketched in the work outline below. Other node implementations and deal-making services would require similar adaptations to take advantage of the new flows.

Other downstream impacts include TODO:

This table outlines the data that is committed to and observable on the blockchain.

The state data for a storage application smart contract depends on what that application implements. Much of the essential data is observable in any case from the messages submitted to confirm data storage, even where no smart contract is used.

Rough efforts: 🐁 = small, 🐕 = medium, 🐎 = large, 🐘 = huge.

An overall easy change once we decide the product needs. No immediate user impact, but a pre-requisite to subsequent changes. FIP draft, discussion.

Effort:

New onboarding APIs support claiming FIL+ allocations without built-in market deals, and more efficient activation when deals are used. This is a more involved change with some outstanding technical design. The outcome is simple FIL+ deals avoid built-in market → cheaper gas, 5y term

Old flows will continue to work, so immediately required changes are few. But some coordination between teams is required to realise the value in end-to-end flows. Effort:

Support FIL+ allocations and claims for multiple sectors within a single transaction and ~constant costs. The outcome is FIL+ accounting has near-constant cost regardless of size, resulting in further reduced costs for FIL+ onboarding. See FIP discussion #708.

Key efforts are a cryptographic vector commitment scheme, actors changes to verified registry allocation/claim state, and metadata for batch allocations/claims tracked by off-chain participants.

Smart contracts can receive synchronous on-chain notifications of data commitments into sectors. The outcome is user-programmed contracts can implement markets and other applications without off-chain oracles or monitors for activation.

The effort depend on how much groundwork we front-load into initial Direct FIL+ changes. A key challenge is security of invoking untrusted code during onboarding.

Allow SPs to store sector unsealed CID in chain state, where it can be inspected by smart contracts.

SPs can prove that data has been removed from a sector. (There are tricky product impacts here, this requires more than just the technical means to prove deletion).