FIP Proposal: Alter sector upgrade behavour to make an upgraded sector's power consistent with a newly sealed sector about fips

[nicola]

I will look into this, thank you for taking the time writing this concern.

While I think what you are pointing out is important, it may be still not rational to upgrade using the current protocol..

My overall goal with a future protocol upgrade is to try to solve the issue at the root: support sector updates without resealing. Nonetheless, I am in support of this type of change!

[neondragon]

To be clear, what I am intending to enable is the following lifecycle:

• A miner pledges a CC sector to the network.
• The miner decides to upgrade the CC sector with deal(s).
• The upgraded sector is allowed a 'downgrade epoch' on, or after the epoch on which the longest deal in the sector expires.
• The sector is treated as two parts, the upgraded portion, and the downgraded portion.
• The collateral requirement, DealWeight, and VerifiedPower of the upgraded portion is calculated as if it were a newly sealed sector that expires on the downgrade epoch.
• On the downgrade epoch, excess collateral is returned from the sector to the miner available balance, and the sector's collateral along with its power returns to that of a CC sector.
• The downgraded sector becomes eligible to be upgraded again (to make full use of available pledged space)
• The downgraded sector's expiration date is at least the same as the originally pledged CC sector, so that there is no mechanism to receive a CC sector's collateral back early.

I believe allowing an upgraded sector the opportunity to provide the same storage power for the same duration as a newly sealed sector ensures that miners will not need to consider this potential disadvantage and can more confidently pledge capacity knowing it can be made full use of.

As the network has locked the CC (or downgraded) sector's pledge collateral, and mandates that it be proved for its full remaining lifespan, I believe this improvement would also allow more effective use of this available resource by ensuring that sectors without active deals are always eligible to be (re)upgraded to contain deals.

[arajasek]

I don’t fully understand the nuance here, but this miiight make a lot of sense? @zixuanzh @ZenGround0 can either of you weigh in?

[ZenGround0]

The problem is clear and I would like to see it solved.

The proposed solution looks pretty good. Prove committing a cc sector could schedule a cron event to handle processing the downgrade epoch. In terms of mechanism design I think this is strictly better for sector quality estimation. But then scaling might be a bit tricky. Downgrading is similar to termination in that it needs access to sector infos, unlike on-time expiration, so it should be handled similarly. Proposal along these lines: make downgrading a user initiated action that can only succeed once the downgrade epoch has passed.

Assuming no scaling issues it is unambiguously good for the system to have more accurate power estimations. It is less clear if the proposed adjustments of pledge are in line with the desired mechanism design. It is unclear to me if IPBase term should be reduced with a corresponding drop in power. @zixuanzh is the expert here and can speak to that. One complication unaddressed is the potential for circulating supply and hence LockTarget term to go up after the downgrade epoch making the new IP greater. But with a user initiated downgrade it's easy to expect the incoming balance to carry enough balance to cover pledge changes and abort in the case of insufficient funds.

--edit--
I forgot which way the incentives point. Miners will likely not initiate a downgrade because this will reduce power. Potentially this changes if the pledge change aspects of the proposal stay but probably we don't want to go there. We should do automatic downgrading and handle scaling in the same way early terminations are handled.

[ribasushi]

I think doing this will open an abuse avenue, where folks who originally did a bunch of 540 day CC, can have a change-of-heart at month 1 out of the 18 months, create a number of self-dealt 6 month sectors, replace the existing CC with them, and have an exit at month 7, instead of what they originally pledged to the network

@zixuanzh and @nicola would have to chime in whether this is an actual concern or not (creating these new 6-month sectors is not free, so maybe the incentive simply isn't there...)

[kaitlin-beegle]

Hey @nicola! It's been some time, but it seems like this concern would still be relevant. Did you ever have a chance to look into this proposal?

Also tagging @zixuanzh again since there appear to be some concerns related to incentive design.

[kaitlin-beegle]

This is being closed; the primary issue context will be addressed in the upcoming Snap Deals enhancement.