FIP-0045 First draft of FIP for decoupling FIL+ from markets #432
Conversation
anorth
changed the title
| the initial pledge for the new sector is calculated using the network conditions at the time. | ||
| The pledge requirement for the old sector is not decreased, | ||
| but any subsequent penalty is calculated using the current (reduced) power. | ||
|
|
There was a problem hiding this comment.
I think this point is very important to fully clarify. I would expect that an additional piece of collateral needs to be placed at the time when SP starts earning 10X, when the claim is sealed. But this is not really specified here.
If QAP can change throughout the lifetime of a sector then I would imagine the collateral also changes, increases when the QAP increases?
If collateral will work in this "not smeared over sector lifetime" way, this has a potentially very large economic impact to the network that we would need to evaluate.
The idea is economically, collateral from sectors can be viewed as a "loan" to the network, freeze these funds, which is good for the rest of the network, for a period of time. The point is that the terms of these loans are changing (and perhaps maybe rightfully so, this may be right thing to do) but it strictly resuts in a "bad deal" for the rest of the network. If you loan me 10 dollars that I have to pay back in one year, it is not the same as if you loan me 5 dollars that I have to pay you back in 2 years. The second loan is a more valuable one for which I should pay you back more interest.
Currently collateral works in the second "smeared way", which economically speaking is "better for the network" than the new version.
There was a problem hiding this comment.
I would expect that an additional piece of collateral needs to be placed at the time when SP starts earning 10X
I meant to imply this with "the initial pledge for the new sector is calculated using the network conditions at the time". The new sector pledge accounts for its FIL+ contents. I can clarify in the body.
the terms of these loans are changing
They can only change in a way that is "good for the network". The amount can only increase, and the term can only be extended. Could you state a concrete scenario that you're worried about?
There was a problem hiding this comment.
I meant to imply this with "the initial pledge for the new sector is calculated using the network conditions at the time". The new sector pledge accounts for its FIL+ contents. I can clarify in the body.
Ok yes I think this can be more explicitly specified. Let's say I seal a 1 year sector, and I make a 6 month claim on it, which starts on the second half. So I place 1X pledge at the beginning of the sector, then when the claim starts halfway through the sector, I need to deposit the remaining 9X of the pledge (roughly but not exactly because this would be based on current network conditions, different from 6 months ago) before I start earning 10X reward. Is this how it works?
There was a problem hiding this comment.
They can only change in a way that is "good for the network". The amount can only increase, and the term can only be extended. Could you state a concrete scenario that you're worried about?
Let's take the same example, 1 year sector, with 6 month claim on its second half. Currently the network would have 5.5X locked for 1 year duration. With this proposal the network would have 1X locked for 6 months, and 10X locked for 6 months. Financially the first loan is "better".
There was a problem hiding this comment.
Another possible issue I am thinking is the maximum term mechanism can introduce an incentive for sealing shorter sectors. If a client offers an SP an allocation with 6 month max term, and the SP now has to put it in a sector. Currently the SP can seal that in a new sector and might as well seal it in a longer 1 year sector or whatever. Specially if Duration multiplier passes, they would seal it in the longest sector they can, so they can multiply their multipliers together and earn more.
with this proposed version, they only have the options of a) add it to a sector they have that only has 6months or less left, or b) seal a new 6 month sector.
All FIL+ will be added to sectors that are exactly the right size, while otherwise SP's could have sealed longer sectors (which aligns more with the sectors as containers idea).
I appreciate the point, I think this is an elegant solution to simplifying the QAP calculation, and I generally prefer this current proposal to some of the previous iterations like FIL+ forever. Just figuring out still what may be the compromises and if they are worth it.
There was a problem hiding this comment.
Let's take the same example, 1 year sector, with 6 month claim on its second half. Currently the network would have 5.5X locked for 1 year duration. With this proposal the network would have 1X locked for 6 months, and 10X locked for 6 months. Financially the first loan is "better".
Thanks for the example. I understand the point but think the example is not representative of real behaviour. Given a deal that doesn't start until six months in the future, the network doesn't get to choose between these cases even today. An SP would just wait and put the 6-month deal is a 6-month sector when it was actually due to start. (I'm ignoring the idea of "storage futures", which would be better implemented higher level than concrete sectors).
the maximum term mechanism can introduce an incentive for sealing shorter sectors. If a client offers an SP an allocation with 6 month max term, and the SP now has to put it in a sector. Currently the SP can seal that in a new sector and might as well seal it in a longer 1 year sector or whatever
I concur that there is potential incentive for some sectors to have short commitments, up to the client demand for low term maximums (i.e. clients that want their data unincentivised after some period, for some reason). An SP doesn't have to take such a deal though – if they can get better return on a long commitment sans-deal, they should take it. So I'm actually a little more worried that short deals will find a scarce supply and have to pay, because SDM pays miners to prefer long ones.
Note that the incentive to short sector already exists because of the spread-out QA power. Up to sealing costs, a rational SP picks the shortest sector duration for their deals so their payout and risk of penalty is as short as possible. So all up I don't think this will exert any significant pressure on sector commitment duration.
|
|
||
| The `UseBytes` method is removed. | ||
| To create an allocation, a verified client transfers data cap tokens to the verified registry actor. | ||
| The transfer must be accompanied by one or more `Allocation` records which specify |
There was a problem hiding this comment.
when an allocation is claimed - does the token get to be transferred from the verifreg -> datacap token contract under the miner actor's balance?
FIPS/fip-0045.md
Outdated
| - Discuss how market delegate means no external API changes | ||
| - Discuss mechanisms for conditional allocations, negatively priced deals | ||
| - Market method for fetching allocation ids for deals (needed?) | ||
| - Spec hook/method for a different client extending the claim by spending data cap (needed?). |
There was a problem hiding this comment.
This seems nice and can be something that DP folks like @dkkapur would be interested for programs like EG.
however, is there any soon-to-land use case exists to support this feature to a high priority that must land in nv17? If not, I’d suggest add it to future enhancement and defer to a later fip.
There was a problem hiding this comment.
The SDM proposal could cause a high priority need for it.
| minimum and maximum. An allocation's minimum term must be at least as large as its maximum term. | ||
|
|
||
| Due to the implementation of term enforcement (details below), clients should leave a large buffer | ||
| between the minimum and maximum term to make the allocation practical for a provider. |
There was a problem hiding this comment.
What should be the buffer? Should it be enforced in the logic?
There was a problem hiding this comment.
Clients can pick. I guess we could chose a minimum but it would only be for practicality, not correctness.
FIPS/fip-0045.md
Outdated
| Each sector hosting a range of an allocation gains power individually. | ||
| All ranges from a single allocation must be claimed by the same provider. | ||
| If a sector hosting one range of an allocation is lost, | ||
| the provider will pay the usual termination penalty but can re-seal the range into a new sector |
There was a problem hiding this comment.
I am not sure what this means. As an example, let's imagine that we have claim for storing a deal for 2 years. The sector is sealed and the SP starts getting rewards. After one year, the sector is terminated and the termination fee is paid. What happens to the claim? Can the SP seal another 2-year sector with the same claim? Or do we consider that one year of data cap was already spent?
There was a problem hiding this comment.
When it was first sealed, the claim got a TermStart epoch. It's valid only until TermStart + TermMaximum. So the new sector must have a scheduled expiration before that. So yes, we basically consider that one year of the allocation was already used.
|
|
||
| The record of a claim may be removed by the provider after it has been completed. | ||
|
|
||
| The maximum term for a claim may be increased by the client which originally made the allocation, |
There was a problem hiding this comment.
Is this possible for a claim related to data already sealed in a sector? If yes, does the SP need to change the list of sectors of this claim?
There was a problem hiding this comment.
No (we lack the technique today to prove inclusion of some data in an already-sealed sector).
There was a problem hiding this comment.
If I understand this correctly, does this mean that sectors with deals sealed before this FIP is introduced won't be able to extend?
There was a problem hiding this comment.
Sorry, I misread your original question.
Yes, the term for a claim may be extended – all claims are already sealed in a sector. But this doesn't imply any change to the sector.
|
|
||
| The actual term for a claim ends the epoch that the sector containing the data expires, | ||
| or that data is replaced. | ||
| The term cannot end during a sector's lifetime, except by explicit replacement of data. |
There was a problem hiding this comment.
To clarify, does this mean that a claim with a max term of 1 year cannot be stored in a 2-year sector?
There was a problem hiding this comment.
Also, if we have a claim with a min term of 1 year, we cannot store it in a 6 months sector, right?
anorth
requested review from
momack2,
arajasek and
kaitlin-beegle
as code owners
|
@jennijuju I've added a lot of the missing content here. While not final, I think this PR is now ready to merge as a draft. @ZenGround0 and I can then collaborate on improvements as implementation progresses. |
There was a problem hiding this comment.
Thank you for the detailed and well-written FIP. This is a complex change, and understanding it is a lot easier thanks to the FIP.
I do worry that certain aspects of this are overengineered, but I don't yet have anything in mind that I'd suggest simplifying. For now, some notes and questions.
FIPS/fip-0045.md
Outdated
| The new sector’s committed lifespan is still constrained to fit within the claim’s term. | ||
|
|
||
| #### Sector extension | ||
| A provider cannot extend the scheduled expiration for a sector past the maximum term |
There was a problem hiding this comment.
I'm having a hard time understanding this paragraph. We say that a provider cannot extend the scheduled expiration for a sector past the maximum term of any piece of verified data that it holds, but it sounds like a provider can do so (under the circumstances listed in the subsequent paragraph), but will automatically lose the power boost for the extended period if they do so.
Is that correct?
There was a problem hiding this comment.
Well, yes, because it stops holding (kinda, once we can resnap) that piece of data. I'll try to reword.
| // The verified client which allocated the data cap. | ||
| Client: Address | ||
| // The provider (miner actor) which may claim the allocation. | ||
| Provider: Address |
There was a problem hiding this comment.
So this is interesting, and a non-trivial deviation from the FilPlus process today. Today the "verification" process is:
- Steps are taken for verifiers (notaries) to be authorized -- irrelevant / unchanged by this proposal
- Notaries give some DataCap to Verified Clients, who can spend it on any data, with any SP as they see fit.
- VCs negotiate deals with SPs. SPs validate the deal offer by checking that the VC has enough DataCap for the deal.
- Data is transferred to the SP.
- The DataCap gets "used" when the SP publishes the storage deal*. Note that the SP could get misled by a VC whose DataCap changes between the validation of the offer in Step 2, and the actual publication of the deal in Step 4.
With this FIP, the process becomes:
- Steps are taken for verifiers (notaries) to be authorized -- irrelevant / unchanged by this proposal
- Notaries give some DataCap (tokens) to Verified Clients, who can spend it on any data, with any SP as they see fit.
- VCs negotiate deals with SPs. SPs validate the deal offer by checking that the VC has enough DataCap for the deal.
3?) VC publishes the Claim, with the matching SP. The SP waits for this publication
4?) Data is transferred to the SP.
5?) The DataCap gets "used" when the SP publishes the storage deal*.
At the very least, this leads to changes in the validation processes on the SP side. Additionally, it's not clear to me in what order these steps "should" be performed -- that's not consenus-critical, but I'm interested in whether the FIP authors have an idea in their minds.
I'm concerned about the various ways both VCs and SPs could get misled by this. Is the idea for VCs to only publish claims with very short Expirations, so that they don't have their DataCap locked for a long period by an uncooperative SP? Is the idea for SPs to receive all the data before the VC actually publishes the Claim, leaving them vulnerable to having their time and resources wasted by malicious VCs who have no intent of actually publishing a Claim?
I suspect time and discussion has already gone into these questions, so feel free to point me to the appropriate place.
*I might be wrong about the precise details of this.
There was a problem hiding this comment.
as discussed offline, 3&4 happen within 5!
|
@anorth could you please specify, what happens when the sector is early terminated?
did the claimed got removed then datacap got burned? |
There is no change from behaviour today. Datacap was already burned. The claim is not removed until the provider does so explicitly. |
|
|
||
| The verified registry can support re-commitment of the same data | ||
| (even though the built-in storage market actor does not support resumption of a terminated deal). | ||
| If a claim’s maximum term has not been reached when a sector terminates, |
There was a problem hiding this comment.
I don't understand how this would work. Is the verified registry notified when a sector fulfilling a claim expires? Or is the idea that a Claim can be re-claimed if the Sector in the original Claim has expired?
There was a problem hiding this comment.
No the registry is not notified when a sector expires. The miner actor is still trusted to enforce the appropriate penalties etc.
But a claim can be re-claimed if the original sector has expired. Here again the miner actor will be trusted to only do this when the original sector has gone. It's quite likely that the user-facing method to do this won't be landed as part of this nv17, but it's automatically encompassed in the follow-on designs.
maybe i missed it - but i cant seem to find when the token is burned in this fip yet. Upon a claim? |
| - Spec methods for sector migration on miner, market, and verifreg actors | ||
| - Spec change to SectorOnChainInfo to distinguish migrated sectors | ||
| - Confirm policy for built-in market actor's default term maximum | ||
| - Market method for fetching allocation/claim ids for deals (needed?) |
There was a problem hiding this comment.
ah.. we will need this for client implementation, when extend a sector, we need to be able to get the term max of all data in the deals of that sector
There was a problem hiding this comment.
You can do state inspection. This method will eventually be needed for operators to migrate off that though.
|
@anorth i believe two things are missing
|
|
Thanks I've added notes about the upgrade migration, including datacap balances. I'm not yet confident about the best way to handle pending deals, so have added TODO. |
|
I think this FIP still needs a couple of iterations before it can be considered last call ready. However, it has enough information for the first draft of an FIP and has enough community interest to consider the idea for filecoin network. |
This is a first draft of the FIP for the proposal discussed in #313