What should the termination penalty be? #724
Replies: 1 comment 1 reply
-
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. |
Beta Was this translation helpful? Give feedback.
-
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:
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.
Beta Was this translation helpful? Give feedback.
All reactions