FIP-0065 Ignore deal collateral in circulating supply (was: Preparing deal collateral for flexible data onboarding)

[anorth]

The Filecoin network currently implements a mandatory data assurance penalty in the form of provider deal collateral held by the built-in market actor. This deal collateral is burnt if a provider fails to activate a published deal or terminates a sector holding deal data before it completes. The built-in market actor specifies a minimum deal collateral amount, calculated as CircSupply * 1% * DealSize / max(NetworkRawPower, BaselinePower). Since the built-in market actor is currently the only permitted way to onboard data to a sector, this amounts to a network policy.

Doing deals with the built-in market actor is expensive in gas, and limited by its simple functionality. Without expanding on the motivation here (see #241), we would like to make the built-in market not mandatory and support direct use of FIL+ allocations (for the common simple case of FIL+ with no client payments) and other contracts as cheaper or more flexible markets.

For a 32GiB FIL+ verified deal, the deal collateral is 0.0083FIL (using April 2023 numbers). This is equal to about 2.7 days of expected block rewards for the associated power, while the sector termination fee is 90 days worth. The collateral amount is about 0.4% of the sector’s initial pledge. (The penalty is proportionally much higher for non-FIL+ data, but if we retain it I will propose normalizing it by QAP)

Part 1 – network-enforced data termination penalty

A pre-requisite for more efficient and flexible data onboarding is deciding what to do with this currently-mandatory data assurance penalty. I see two clear options.

1. Decide that an extra 3% penalty for sectors with data is not worth enforcing at a network level. The sector termination penalty already includes sufficient mandatory data assurance. Allow opting out of the built-in market actor without implementing any additional data assurance penalties
2. Implement a data termination penalty in the miner actor, where it can apply the extra 3% to all data regardless of how it is onboarded. Use a similar formula as deal collateral, but charge it as an addition to sector termination penalty, in proportion to the amount of data in the sector.

I have expanded on a design for a data termination penalty, but this is only worth developing further if we decide as a network that mandatory data assurance is something the network should enforce.

Given the relatively small amount of this minimum penalty, and the ability for arbitrary collateral and penalty terms to be implemented in smart contracts, I don’t see a strong justification for retaining it. But are there good justifications?

Part 2 – built-in market product features

Regardless of whether we implement a mandatory deal assurance in the miner actor, the built-in market will become optional, and we need to decide what to do with its existing deal collateral mechanism. The built-in market will likely remain the primary on-chain market for some time, as alternatives take time to develop and grow.

Note that a miner-enforced data termination penalty would not cover the possibility of a storage provider publishing a deal but then failing to activate it, which is currently covered by deal collateral.

Here there are many options, including:

1. Leave the built-in market as is, including minimum deal collateral.
2. Keep market deal collateral but reduce minimum amount to zero
3. Change market deal collateral to cover publication→activation only, with current minimum
4. Change market deal collateral to cover publication→activation only, with no minimum
5. Remove market deal collateral functionality altogether

These options have implications for effort and usage:

• If the minimum is set to zero, clients and providers can chose a minimum cost/complexity option. This saves SPs from posting collateral and clients from computing an acceptable amount (but marginally reduces disincentives to early termination). How many parties would chose this?
• If the functionality is removed or limited to the publication→activation gap, clients can’t set a higher termination penalty than the sector+data termination penalty implemented by the network. How many clients chose higher amounts today?
• If we retain minimum collateral requirements for the full duration and implement a network termination penalty, we might end up with more pledge costs and risks to SP than we want.
• If minimum penalty is zero and it’s easier to use zero collateral than another amount, SPs might have influence to force all deals to use zero collateral, potentially to the detriment of storage reliability. The built-in market will set standards, even as it becomes optional.
• Making less change is less effort, but might leave more protocol complexity in place for everyone in the future.

What’s a good-enough trade-off here? In all cases, in time we can expect parties that don't like the built-in market's rules could use an alternative smart contract market, once they are developed.

We all want to get to more efficient and flexible data onboarding. This is just one decision to unblock the path to get there.

[tmellan]

Thanks for sharing @anorth. On part 1 you mention:

the ability for arbitrary collateral and penalty terms to be implemented in smart contracts, I don’t see a strong justification for retaining it

When this market scenario is strongly developed, I could broadly agree, but I don’t think this is the case right now. Until this happens, it could be better to maintain the status quo (effectively option 2). Two reasons for this:

• Filecoin is a data storage network, and its value proposition is securely and reliably storing data. While removing the fee may be useful later, maintaining it has value at this early stage in the network to allow us to get to that place, especially at a time when terminations as a proportion of power have been increasing.
• Keeping the status quo can give us more flexibility, should we think about differentiating CC and deals further. For example decreasing sector termination fees while increasing the deal termination fee. This could make it easier and lower risk for CC power to join or leave, while maintaining or increasing data reliability.

[anorth]

We can quantify the "value" of retaining a data termination penalty: it's 3% of whatever value the sector termination fee is providing. I can't believe this adds up to any significant incentive effect. I can't see how it's worth any effort vs just dropping it.

The data termination penalty construction I proposed could be added at any time. The inputs are all on-chain with no plans to remove them. If we were to do work like splitting the termination fee into a sector part and data part, the engineering would be no easier or harder if a data termination penalty did/n't already exist. I am optimistic about that direction, but it need not have any influence here. It's not a good engineering approach to keep complexity in the protocol in case we need it later (we already have too much of that).

[anorth]

Note that if we chose option 1 for the built-in market, then it will continue to be the case that market contracts implement deal collateral, until strong development results in alternatives that may or may not.

[kaitlin-beegle]

Can you help me explain why an SP wouldn't activate a deal?

[anorth]

Maybe they accept more deals than they can seal, and then choose the "best" ones to actually follow through on. Or if a smart contract offers bounty-type deals (no specific SP) they could deny any other SP the ability to take a deal.

Accepting (via PublishStorageDeals) is pretty expensive today so it's not super likely. But that depends on the value involved, and could change.

[jennijuju]

I would feel especially inclined to include a proposal like this if the proposal ends up specifying a reduction/elimination of the penalty.

@kaitlin-beegle you mentioned above here - and i am wondering your thoughts on what's the justification behind/how to balance the tradeoff - a proposal might reduce the storage guarantee for data clients when there is "a reduction/elimination of the penalty".

[kaitlin-beegle]

Hello! Sorry I missed the ping on this @jennijuju.

In general, my opinion atm comes from a place of practicality more than principle. Given current challenges in the FIPs process, I do not believe we should stoke a debate around payment and fee models until we get more robust governance processes in place. We know this will not happen in time for nv21, though it is my hope that we have community support for new mechanisms to support FIPs going into nv22.

So, my current preference is not about the policy per se, and more about timing and prioritization.

[anorth]

I started drafting a FIP to spec this out, and realised that if we chose option 1 for each of parts 1 and 2, the there is almost no protocol change necessary – merely a decision to unblock future protocol improvements that will support committing data into sectors without necessarily using a built-in market deal. Maximally simple implementation!

I will draft a FIP anyway, to (1) formalise this as something that future FIPs can reference and depend on, and (2) remove the market's locked amounts from the circulating supply calculation, as they will be increasingly irrelevant.

[anorth]

A first draft of a FIP describing options (1) and (1) is at #726

[steven004]

I fully support and appreciate proposal #726 as it aligns with our core-protocol direction of simplicity and providing greater flexibility for ecosystem development.

Furthermore, I would like to add my two points:

1. The proposal effectively removes the dependency on the built-in Market Actor at a minimal cost. As we continue to decouple the core protocol from the built-in Market Actor (further efforts still required), we can eventually remove its privilege as a mandatory path for real data storage. This would allow us to elevate the Market Actor from the core to user-space.

2. The calculation of circulating supply itself may not be entirely accurate, particularly as the ecosystem grows more complex with the deployment of more and more smart contracts. Accurately determining the circulating supply in a complex system can be challenging due to tokens being locked in both core and user-space actors, as well as the potential loss of tokens due to private key loss could not be counted either. As a result, the collateral mechanism, which currently relies on CircSupply, may require future adjustments later.

[anorth]

I have merged the first draft of FIP-0065: Ignore built-in market locked balance in circulating supply calculation.

[anorth]

Copying a comment from @jennijuju from PR review:

This FIP's motivation and impact depends on many hypothetical future protocol changes, that may or may not be accepted by the Filecoin community. The idea of this proposal is reasonable and concrete enough to be landed as a draft, however, when this FIP can be moved to Last Call/Acceptance is worth discussing. some quick options:

1. treat this FIP as an independent FIP.
2. treat this FIP as a dependency of future "directly commit data to sector" proposals and bound the FIPs acceptance. (stay Draft until then).
3. treat this FIP as an independent FIP now for acceptance(not finalization) & and allow revision to Deferred or Reverted when contentions raised in then future.

@kaitlin-beegle I think this is gap in the current governance process and would love to hear our feedback.

[anorth]

I believe this proposal is sufficiently motivated on its own as a simplification to the protocol, even if a small one.

I also do not think that the FIP process should prevent progression if the FIlecoin community are supportive. The proposal should go through the stages, and can be rejected, or possibly deferred, if there are specific technical or practical objections. Core devs can then debate when to implement it, but have the support of the community to so so when practical

[AxCortesCubero]

Sorry if it is a stupid question, but could I have some clarity on what exactly is on "Last Call" here? I see the discussion actually have several options and different ideas, I can't tell which one is on last call to be accepted in the next days?

Is it simply to ignore the amount that is locked in deal collateral, in calculations involving circulating supply in future calculations, such as all the consensus pledge, and minimum deal collateral itself? So the result of this would be overall slightly higher pledges, since the effective circulating supply would be higher, right? So the question for right now is if we are all ok with slightly higher pledges?

[AxCortesCubero]

Ok sorry, I just read the actual FIP now, and it seems yes what I described is the case. So this would represent a slight increase in consensus pledge and deal collateral.

[AxCortesCubero]

In the short term, ok what is locked in deal collaterals is a small amount, so it doesn't matter that much, would only be a slight increase in collateral (yet to be determined, how slight is slight, it sure might not feel slight to someone who has to pay these collaterals).

In the longer term it could get problematic, when the total amount of deal collateral locked is not "negligible" but a substantial amount, then in a catastrophic extreme scenario, there might not exist enough FIL to seal new sectors. This might be an unlikely enough scenario to not worry about, but I would like to get a better idea of how unlikely and unproblematic we're talking about

[anorth]

I don't think clients and markets will be able to demand that much collateral if tokens are so rare that they aren't even available for pledge. Note that with #730 parties don't have to use the built-in market, which is part of why its privileged treatment is unwarranted. (Other markets might also hold other assets as collateral, if this becomes a problem).

[ZenGround0]

Implementation here: filecoin-project/lotus#11976