Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FIPTBD: Simplify termination fee calculation to a fixed percentage of initial pledge #1079

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

Schwartz10
Copy link

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

Copy link
Member

@anorth anorth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

FIPS/fip-draft_term_fee.md Outdated Show resolved Hide resolved
FIPS/fip-draft_term_fee.md Outdated Show resolved Hide resolved
FIPS/fip-draft_term_fee.md Outdated Show resolved Hide resolved
FIPS/fip-draft_term_fee.md Show resolved Hide resolved
FIPS/fip-draft_term_fee.md Outdated Show resolved Hide resolved
FIPS/fip-draft_term_fee.md Outdated Show resolved Hide resolved
FIPS/fip-draft_term_fee.md Show resolved Hide resolved
- Computing block rewards is still a non-trivial task, and most likely requires more/new solidity FEVM precompiles

The current design is the simplest and most predictable approach to accomplishing the end goal.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This design rational section needs a good rationale for the 6% proposal. Can you demonstrate what the current effective % is by showing the calculation for a new sector using recent network state?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See comment here #1079 (comment)


<!--All FIPs must contain a section that discusses the incentive implications/considerations relative to the proposed change. Include information that might be important for incentive discussion. A discussion on how the proposed change will incentivize reliable and useful storage is required. FIP submissions missing the "Incentive Considerations" section will be rejected. An FIP cannot proceed to status "Final" without a Incentive Considerations discussion deemed sufficient by the reviewers.-->

It is important that Storage Providers are incentivized to honor their commitments to the network - this prevents major network volatility. It makes sense to maintain a disincentive for breaking commitments to the network, but this FIP doesn't change the incentive to provide useful storage to the network, it makes it somewhat easier.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This section needs to clearly call out that the termination fee for sectors committed a long time ago will immediately decrease, significantly (but only to match the fee:pledge ratio of new sectors). This will increase the incentive for some providers with high-pledge sectors to terminate and re-onboard to gain more power for the same amount of pledge (but more hardware).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a straightforward way to grab some basic data about this so we can attach a sense of scale to the incentive problem you're outlining @anorth ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here's some data anorth collected in the discussion #1036 (reply in thread)

FIPS/fip-draft_term_fee.md Show resolved Hide resolved
FIPS/fip-draft_term_fee.md Outdated Show resolved Hide resolved

1. As Filecoin matures, the average Storage Provider will likely be accepting paid deals in some form according to an SLA in addition to the SLA guaranteed by PoRep. These additional SLAs can/will enforce their own termination clauses, which should provide adequate motivation and verification to achieve a good experience for the average storage client.
2. It seems appropriate to charge an exit fee for breaking a commitment to the network, but we also do not want to charge a capture fee. Storage Providers who do not wish to use Filecoin anymore shouldn't have prohibitively high expenses for leaving the network early - ultimately for the network, burning some of this SPs tokens through sector terminations is better than 18 months of selling.
3. The 6% proposed termination penalty percentage is what the network is currently charging (on average) for terminations.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Author

@Schwartz10 Schwartz10 Oct 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@Schwartz10
Copy link
Author

@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

README.md Outdated Show resolved Hide resolved
Co-authored-by: Jorge M. Soares <[email protected]>
@Schwartz10
Copy link
Author

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

  1. @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.

  1. @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
Copy link
Member

anorth commented Nov 20, 2024

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
Copy link
Member

anorth commented Nov 21, 2024

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

@jimpick
Copy link

jimpick commented Nov 21, 2024

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
Copy link

jimpick commented Nov 22, 2024

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
Copy link

jimpick commented Nov 22, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants