You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
minEpochDuration - is a guarantied time for which validator stakes are locked since election, so we can be sure that we can slash them. safetyDuration - some delay which we reserve for slashing execution.
This is necessary to be sure that old era validators stake is still locked and can be slashed.
Actually if we wanna to keep the same block producer even after timeout (block producer from old era, but multisigature from current era), then we should take it in account and max validationDelay is
Problem to Solve
There can be cases when block commitments from old era can be committed only in new era. This can be because of several cases:
Possible Solution
Introduce
validationDelay
for which in intervalcommitments from old era can be validated by old era validators.
Note that maximal value which
validationDelay
can be isminEpochDuration
- is a guarantied time for which validator stakes are locked since election, so we can be sure that we can slash them.safetyDuration
- some delay which we reserve for slashing execution.This is necessary to be sure that old era validators stake is still locked and can be slashed.
Actually if we wanna to keep the same block producer even after timeout (block producer from old era, but multisigature from current era), then we should take it in account and max
validationDelay
isguarantyCommitmentDuration
- time for which we guarantee that block would be committed.Notes
No response
The text was updated successfully, but these errors were encountered: