penaltyPercent to scale with each violation

[arjunhassard]

Add logic to TACoApplication.sol such that the penaltyPercent parameter increases with every violation committed by a given staker.

To make it as simple as possible in the first version:

• All incomplete DKG rituals are treated as equal violations regardless of the reason or context. In future versions there could be varying punishment/severity for:
  • Incomplete DKGs due to being offline vs. not running an up-to-date version vs. other known failures
  • Incomplete DKGs where more than one node is affected and/or there is correlation (e.g. cloud provider goes down). Note this could lead to more severe punishments to encourage diverse infrastructure.
  • Incomplete DKGs that indicate malicious behavior
  • Incomplete handover DKGs during deauth periods.
• penaltyDuration should be a constant
  • e.g. 1 month of reduced rewards for all violations
• A violation that occurs during an already penalized reward period simply restarts the 1 month clock from the day the violation is logged (but with increased severity). In other words, committing a violation before a previous punishment has ended does not lead to any special outcomes, like summing penaltyPercents.
• A staker's violation count resets after a universal fixed duration (e.g. 24 months) from their first violation, after which point a fresh violation would result in the least severe penaltyPercent.

Hypothetical initial parameters:

• First incomplete DKG violation leads to a 25% reduction in rewards for a month.
• The second leads to a 50%
• Third to a 75%,
• Fourth (& fifth, sixth...nth) to a 100% reduction.

Depending on resultant behavior, we can consider increasing penaltyDuration for violations beyond the fourth. The rationale for avoiding this in the first version is that we don't want extended periods where nodes are earning nothing, as that may encourage them to exit the network.

Comment from @manumonti: About the penalty duration increasing beyond the fourth: I think we should consider setting its max value to the deauthorization delay (183 days) or less. If this reset duration is much higher than the deauth delay, the [reoffending] operators with 100% of the penalty will be incentivized to just remove the operator from the network and set up a new one with a different staking provider address to avoid the penalty. And this can lead to an unstable network with cohorts with unreachable nodes.

[arjunhassard]

From discussion with @vzotova:

• To minimize number of stored variables/state (two new fields to track and reset the state of an individual staker's history), the penaltyPercent could revert back to the default severity as soon as a penaltyDuration has elapsed.
  • Note that the penaltyDuration would still restart from day one with each recorded violation.
  • Hence there would be no concept of 'parole', the penaltyPercent would only increase for successive violations while the staker is already being punished.

New ideas based on discussion:

• To tune the disincentive, this simplification could also involve a longer (invariable) penaltyDuration, coupled with a smaller default/minimum penaltyPercent.
  • Initial parameters could be:
    • penaltyDuration: 3 months
    • first violation (default/minimum)penaltyPercent: 20%
    • second violation penaltyPercent: 40%
    • third violation penaltyPercent: 60%
    • fourth violation penaltyPercent: 80%
    • fifth violation and above penaltyPercent: 100%
  • Rationale: eras of infrequent DKG rituals – i.e. when there are rare opportunities to catch non-available/non-updating nodes – coupled with the possibility of evading punishment simply by not being sampled into a cohort (more likely if the node population continues to grow) – could lead to repeat offenders not having their punishment ratcheted up at all, despite contributing to consecutive DKG incompletions. In other words, the absence of a parole system fails to incentivize fixing the problem or updating their nodes, because the rewards withheld remains at manageable percentage.
• Stakers who fail to complete a DKG ritual multiple times within one fixed period (e.g. 1 day or 1 week) could be offered a reprieve from ratcheted punishment, given the (potential) misfortune of being non-available at a moment when there happens to be a flurry of rituals @theref

Further work:

• Further investigation needed into the possibility of malicious sabotaging of other nodes' DKG participation, as means of increasing one's control of token supply.
  • Note that malicious DOS is less incentivized by reward withholding, particularly because the stable yield mechanism means that one's yield is not affected by the forgoing of yield by other participants.
• Further investigation needed into correlated failures and increased punitiveness, as a way of incentivizing the diversification of underlying infrastructure – servers and web3 providers in particular.