What should the termination penalty be?

[arajasek]

Preliminary note: This discussion is NOT intended to discuss changes to the termination penalty structure such as #712 and #691. This is intended to discuss what the spec is TODAY, and confirm that the implementation we have today is correct.

Termination penalties are a critical component of the Filecoin cryptoeconomic spec today. They help safeguard the security of the Filecoin network, while also providing a ceiling on the amount of risk a SP takes on by participating in the Filecoin economy. A survey of termination penalties can be found in a recent article by BlockScience here.

The Filecoin protocol has evolved since its mainnet launch in October, 2020. The termination penalty math itself, however, has not materially changed. This might have led to deviations between the calculations that are live today, and the intended spec. I would like to clear this up, and make sure we are 🟢.

In particular, the current math appears to be based on an assumption that the QA power (and thus values like the expected day reward) can only change once in a sector's lifetime. This is not true -- a sector's power can change as a result of:

• the sector being ProveReplicaUpdated to include verified deals
• the sector being extended (leading to either dropped claims, or re-adjusting of legacy QAP)

As a result, a sector's QA Power can undergo multiple changes in a 140-day period. It's not clear to me what the termination penalty should be in such cases. A spec would be really helpful here -- we can then check and correct the implementation as needed.

If this is too vague a question, I'm happy to add more details, but will need some help motivating the conversation. I think we can slowly bridge the gap between higher-level definitions and the actual code.

[anorth]

In my opinion, the implementation we have today is correct, more or less by definition (assuming the function of the code matches the intention expressed by the in-code documentation, naming etc, i.e. no hidden bugs). It's how the network behaves and thus how participants expect it to behave.

As you point out, the 2020 specification does not take into account the variations in QAP that were made possible by subsequent protocol changes including FIP-0019 and FIP-0045, or hypotheticals like duration multipliers. I don't think it makes sense to ask what the intention of the spec would have been in such situations, especially while constraining it to the chain state available. There is no evidence of consideration for such complications. The code changes implemented since have done a reasonable job propagating the mechanism into these new possibilities, but the construction is fundamentally unable to account for something like the rewards earned by the sector across multiple variations in power (of course, it only accounts for expected rewards in any case), despite being quite complicated.

I do agree a spec could be useful in drawing the compromises and inadequacies to light. But the way to find one would be to reverse it out of the code. The code is the only place that someone has considered all the possibilities.

What should the termination penalty be inevitably invites discussion of the purpose and technical constraints, i.e. #691. There's certainly room for improvement.

Note: I do not agree with the statements in your opening paragraph beginning "Termination penalties are a critical component ...", but that is an issue for #691 and not your main point here.

[arajasek]

I don't necessarily disagree with the majority of this. It has certainly been the case that anytime the protocol has evolved, FIP authors have reworked termination penalties in whatever way seemed most reasonable, and most aligned with original intent.

I guess my concern is that something may be lost in that process, though. My discomfort is that I (personally) don't necessarily know what the definition of "correct" for calculating termination penalties is. Thus, even though I think the changes we've made are reasonable, I worry that we are violating some property these penalties should have.

Historically, changes to this value has been something of an afterthought as we've worked on wider protocol changes. We've moved quickly to land on "what seems reasonable", and continue to do so (eg. see relatively short discussion on changes being considered for nv21 here). It makes me uncomfortable that the subject-matter experts here (the CryptoEconLab, other cryptoeconomists) are not in the loop (and potentially wholly unaware) of these changes.