FIP-0098: Simplify termination fee calculation to a fixed percentage of initial pledge

[Schwartz10]

Computing the collateral value for a miner actor is critical for making economically secure defi protocols on filecoin; however, computing the collateral value correctly is hard on its own, and impossible in a small time frame and/or from inside the FEVM. The variance in termination fees relative to initial pledge for different miners on the network vary so significantly that DeFi protocols cannot safely use heuristics to estimate miner collateral values.

This FIP intends to significantly simplify the termination fee calculation by using a fixed "percentage-of-pledge" method. The termination fee for any given sector is calculated as a fixed percentage of the initial pledge held by that sector.

Discussion

[anorth]

This first review contains a mix of editorial and technical/peer review.

[rvagg]

Echoing Alex above, this is the only part that gives a rationale for choosing 6% but it doesn't provide a means to verify. Is there a source for this we can either point to or call out? Can I, as a reader, verify this claim somehow?

[Schwartz10]

Yeah thanks for calling this out - see here #1079 (comment)

[Schwartz10]

@anorth @rvagg agree with both of you that we need more data / verification around the TERM_PENALTY_PLEDGE_PERCENTAGE variable.

GLIF had built a tool in this PR https://github.com/glifio/go-pools/pull/84/files that estimates the termination fee for an amount of FIL pledged in sectors. We can update this tool and collect some data. Anyone is welcome to use it too, but its currently hardcoded to a specific timestamp when we were testing.

Give us a little bit of time and we'll collect the necessary data to properly set TERM_PENALTY_PLEDGE_PERCENTAGE. The rest of the review comments have been resolved in 40cf2c2

[Schwartz10]

Thanks to the help of @rvagg and @jimpick for collecting data for this FIP.

A few different data points have been collected:

1. @rvagg exported the full, raw SectorOnChainInfo. Copying and pasting from this slack thread -

ok, here’s the full SectorOnChainInfo, without the CIDs in it: https://filvagg.s3.amazonaws.com/soci.csv.zst
7.1Gb compressed, 63G uncompressed
you could pull it and only store a subset using something like:

curl -s https://filvagg.s3.amazonaws.com/soci.csv.zst | zstdcat | awk -F, 'NR==1; NR>1 && $6 > 4000000 && rand() <= 0.01' > soci-part.csv

^ that would keep the header line and only entries whose expiration epoch is > 4000000 and a random sample of 1/100 of those (as an example).

no termination fee calculations or anything in here, just raw data

2. @jimpick used GLIF's sector terminator code to create this tool - https://github.com/glifio/simplify-terminations-fip-data, which produced this csv https://gist.github.com/jimpick/ee8d35fc40841fb9c611b6a3743816aa. I've copied this CSV into google sheets and added another column with the term penalty % of initial pledge here.

Some stats that I calculated about the termination penalty % of pledge based on the CSV:

Average: 18.9%
Median: 11.2%
Min: 1.9%
Max: 184%

It's not obvious to me that we should use aggregate statistics based on the current state of the network to arrive at the correct % for this fip, but it's quite helpful information to have to inform the decision.

3. @jimpick wrapped the StateMinerInitialPledgeForSector (method here) to create another cli tool for computing the termination penalty % of initial pledge for new sectors (or sectors at a specific height). That tool can be found here https://github.com/glifio/simplify-terminations-fip-data/blob/main/cmd/penalty-on-pledge.go.

According to the data Jim last computed, it looks like the new sector onboarding has a termination penalty % of pledge around 1.8%, which seems far too low. This will change presumably with the introduction of FIP81 economics.

[anorth]

I agree we shouldn't base the constant fee on average/mean/min/max of existing miners nor sectors. We should use approximately the current value, so that the introduction of the change doesn't affect the economics of new sectors much.

I too am skeptical of 1.8% being the current value, based on my own sector observations from some months ago (~8%). Perhaps Jim could check the logic there? I also have a calculator (approximate) for it in https://docs.google.com/spreadsheets/d/1Z9Tjf_sMWU9nsnEpghHWCazSicSPREkWOENxi3yzZEM/edit?gid=0#gid=0, but need up to date network numbers to compute the present value

Update: My calculator gives 8.8%. It's using a slightly simplified calculation, but let's compare with the value calculated from Go code (which might have an error in inputs) and the value observed in sectors recently committed.

[anorth]

Updated analysis on the raw sector data from @rvagg : #1036 (comment)

[jimpick]

I converted the termination fee calculation from the rust code to a Google Sheets spreadsheet...

(except for smooth::extrapolated_cam_sum_of_ratio() ... I just copied the values)

https://docs.google.com/spreadsheets/d/1-kT9IWEtFfNGkr8SxqqIWgYkumNCRDRakORDLx33J5s/edit?usp=sharing

I selected a recent sector and used the sector info + the power and reward actor values.

I didn't update the spreadsheet on the left side ... I put them on the same sheet so we can try to make the numbers agree.

[jimpick]

I agree we shouldn't base the constant fee on average/mean/min/max of existing miners nor sectors. We should use approximately the current value, so that the introduction of the change doesn't affect the economics of new sectors much.

I too am skeptical of 1.8% being the current value, based on my own sector observations from some months ago (~8%). Perhaps Jim could check the logic there? I also have a calculator (approximate) for it in https://docs.google.com/spreadsheets/d/1Z9Tjf_sMWU9nsnEpghHWCazSicSPREkWOENxi3yzZEM/edit?gid=0#gid=0, but need up to date network numbers to compute the present value

Update: My calculator gives 8.8%. It's using a slightly simplified calculation, but let's compare with the value calculated from Go code (which might have an error in inputs) and the value observed in sectors recently committed.

Looking at the values in the spreadsheet and comparing to what I see with a real live sector (see my modified spreadsheet I posted), the first thing I notice is that the "Network Raw Power" for 2024-11-20 is 10.7EiB on the spreadsheet, but it should be ~4.4EiB. The other numbers look off too. I'm wondering if those values are from a different date?

[jimpick]

I notice in the spreadsheet that the formula for "Termination Fee Simplified (FIL+ Sector)" in cell C28 is:

=(70+20)*2880 * $B$10*C$15/$B$7

That seems to imply that it's not for terminating a sector immediately after it was added to the network, since it's using 90 days, not 20 days. So that's the main source of the discrepancy. If I change it to just 20 days, and I correct the Network QAP, Circulating Supply and Epoch reward, the numbers are pretty close.

[anorth]

That seems to imply that it's not for terminating a sector immediately after it was added to the network, since it's using 90 days, not 20 days. So that's the main source of the discrepancy. If I change it to just 20 days, and I correct the Network QAP, Circulating Supply and Epoch reward, the numbers are pretty close.

Right, that makes sense. Thanks for digging into it. And indeed I had intended to model the steady state termination fee (the ramp is another undesirable feature IMO).

Since the new formulation will apply to all sectors, most of which will be "old", I think it should aim for parity with the steady state (90 days) value, not the just-onboarded value. This will be disadvantageous to SPs intending to onboard and then shortly remove sectors, but I don't think pandering to them is a goal.

[Schwartz10]

Hey @anorth i have updated the FIP to reflect the 8.5% termination penalty %. I also added @jimpick as an author as he's helped with the analysis

[anorth]

Great, thanks @Schwartz10 , I think this is about ready to merge.

Please take # FIP-0098 and update the headers, title, and index page. This will then be good to merge in my view.

[lanzafame]

Just adding here the directly impacted spec.filecoin.io sections:
section-systems.filecoin_mining.sector.sector-faults
section-algorithms.cryptoecon.initial-parameter-recommendation

[Schwartz10]

All set @anorth ! Let me know if any other changes are required