Worker/Control Addresses and potential implications for enabling lending markets on FIL

[jnthnvctr]

Hi all,

This discussion is a follow on to the initial proposal from @steven004 here: #253

To motivate the specific use case I'm thinking of and where I think we may need some additional design. If we imagine a DAO lends to an SP, I can imagine two scenarios where (depending on how control over the sectors is set up) we may have undesirable outcomes.

• If SPs retain the right to terminate sectors, it's possible that lending rates from DAOs are unfavorable - as the DAO will have to price risk under the assumption the SP may just let failing sectors continue to fault (since its the lender's capital at risk).
• If lenders retain the right to terminate sectors, it's possible that they unfavorably decide to terminate sectors of SPs (whether that be from a desire to influence power on the network, a pre-mature fear that an SP may not recover from faults, etc).

In both scenarios, this also puts a third party (the client's of Filecoin) at additional risk.

In this case, it might be desirable to have a smart contract be able to take control of enforcing terminations - to ensure neither side can adversely affect the other. I'm less familiar with the specifics of the actors / set up of things - so I'll just describe what I'm thinking of at a high level, and hopefully it maps! Based on my understanding of how many of the centralized lending offerings work, this might be the flow a smart contract would enable:

• SP is required to put up X days worth of "slashing insurance" (note - it's possible that this is capital from the SP that's directly locked, or capital that's being paid for by a willing third party e.g. an insurance fund).
• In the event of a fault, the capital from the SP (or willing third party) is depleted first until their portion is drained.
• Once the SPs portion is depleted, the sectors are terminated and investor capital is returned.

In this way, investors can't early terminate a sector to protect themselves and SPs maintain skin in the game.

Of course, there's probably a bunch of slight variations that might make sense here:

• One might imagine that investors might offer different rates depending on the amount of coverage the miner is offering (tuning risk vs. reward).
• As mentioned, there might be a desire for a third party to backstop as insurance (and the SP might offer that insurance fund a stream of regular payments). Also, like any insurance program you might imagine some more bespoke set ups for selecting and re-selling selling risk.

As a side benefit, being able to enforce these terminations (and ensure programmatically there is sufficient coverage) - you might imagine it becomes easier for lenders to price the risk theyre incurring and incentivize more active participation at more favorable rates.

One open q I have here is around the operational side of this:

• Ideally we need a way to also ensure that whoever controls the mining actor can't just update the control actor to circumvent this enforcement (I think this goes for the beneficiary as well)

cc folks who've expressed interest in this @anorth @steven004 @jennijuju

[kaitlin-beegle]

Thanks, @jnthnvctr! Flagged this proposal in this week's Governance Update :)

[anorth]

I think this is one case of a slightly more general request for access control capabilities on worker addresses. I'm aware that some miner operators would like their "hot" control addresses to be unable to terminate sectors so that that sensitive operation can't be carried out by a rogue insider or in case their key is compromised. Once we go there, it's probably best to apply ACLs to all mutation operations.

As @jnthnvctr points out, that raises the question of access control over the ACLs. For borrowing, there's a wrinkle that a beneficiary, who also has termination rights wants assurance that those access rights can't be removed.

Once the SPs portion is depleted, the sectors are terminated and investor capital is returned

Note that termination fees can be pretty significant, so for a miner that was fully capitalized by loan, only a little investor capital may remain. I was wrong.

[steven004]

I am thinking of an alternative perspective on this matter. The issue at hand revolves around the potential for significant penalties in the event of faults leading to extensive slashing. This is why investors require sector termination control to mitigate the risk.

Could we address this problem by implementing a capped penalty for sectors? In the current implementation, a sector is automatically removed from the chain state and incurs a termination fee if it remains faulty for 42 consecutive days. However, if the faults do not persist for that duration before recovery, it may result in excessive slashing throughout the sector's lifecycle when more faults occur later, which may not be reasonable and adds complexity.

Proposal:

Introduce a capped penalty for sectors, encompassing fault slashing and termination fees. For example, it could be set at 90-day block rewards.

This approach resembles a general service contract where a boundary for penalties for being out of service needs to be defined. In this case:

• The storage provider enters into a contract with the Filecoin network to offer power through a specific service, ensuring consensus and acting as a data container.
• The storage provider earns block rewards proportionally when the SP maintains power well.
• The storage provider incurs penalties to the network in the event of sector faults, capped at a maximum of 90-day block rewards.
• Once the penalty reaches the capped penalty, the power is permanently removed.
• Anytime the SP has the ability to terminate a sector, and the maximum termination fee should not exceed the capped penalty minus the accumulated fault slashing fee already paid by that sector.

An alternative option (maybe for future):

No termination fee or slashing, keeping it simple, as I mentioned in #691 comment
However, a question arises regarding the data storage service agreement. Who would be willing to store data in Filecoin if sectors could be terminated without any penalty?

This option may not be feasible until we transition market, deal, and data handling to the upper layer, with operational services in place. By that time, we hope to achieve a data service level agreement of deal between the client and storage provider at the in user contracts without impacting consensus.

[steven004]

@jnthnvctr @anorth @jennijuju , hope to get your comments on this.
And, do you think we should have another discussion thread to get more comments, or this is not a good idea?

[Fatman13]

No termination fee

+1 to remove termination fees to solve all the complexity it brings to SPs and defi. The collateral can still be locked as suggested by Zen.

[anorth]

Yes it's probably worth a new discussion.

It would be helpful context to provide the current numbers for the fees involved. I am hearing a sense of them being "too much", but how much are they and what might be more reasonable?

Edit: -> #712