Reduce the window in which endorsements are counted #1288
Labels
🤝 consensus
Tickets that the fine folks over at ouroboros-consensus want to keep track of
priority high
At the moment, new protocol versions take effect at the first epoch boundary after the last required endorsement of the corresponding proposal has become stable.
Talking in terms of a hard fork (aka update of the major version number of the protocol), this means that there is basically no window at all between "we are now certain of the point of the hard fork" (that is, the last endorsement has become stable) and it actually happening (which could be the very next slot). This makes it very difficult indeed for
ouroboros-consensus
to make any kinds of statements about the future. In particular,consensus
assumes that as long as the hard fork point is not yet known, there is a "safe zone" in which we are guaranteed no hard fork will take place and so we are justified in doing things like slot-to-time or slot-to-epoch translations in that period (remember that the hard fork can change both theSlotLength
and theEpochSize
, so such conversions cannot be done for slots arbitrarily far into the future). However, as things stand, the ledger can basically switch from 'we're not sure yet when it will take place" to "it will take place in the the next slot" with no safe zone at all, which means that the safe zone assumed byconsensus
can extend much too far into the future:What should happen instead is that not only should the last endorsement be stable, we should have an additional period of stability before the hard fork is allowed to kick in. Put another way, the proposal must be "stably endorsed"
2k
slots before end of epoch.This should be a relatively minor change to the rules. If the change is not compatible with the existing chain, we could insist on this longer period only for bumps in the major version, which would not be unreasonable anyway.
The text was updated successfully, but these errors were encountered: