Closed avahowell closed 4 months ago
Removed the latter two points in the original list to "promote" them into the top-level tracking issue #2070
Requires #1934 as a place to put the new code.
Deprioritized in order to move on the IBC front, still in-progress
Something I have noticed while doing an unbonding delay rework is that since epoch duration is dynamic, subject to events triggering epoch-changes, if we want the unbonding mechanism to coincide with "a long enough period of time for penalties to be applied to a stack of delegated stake" we need to make that unbonding period a function of time.
x-ref: #3694
To elaborate on the point above, since an active validator can trigger early epoch changes it can attempt to evade slashing by accelerating the effective unbonding period to attempt to evade byzantine slashing.
Discussed in sprint planning today. We've decided not to implement this for v1, so updating the labels to v2 accordingly.
This needs to be done as part of V1, it's crucial for security.
We could defer specific things like the synchrony check (not sure if we should do that at all) but we need our mechanisms to be independent of the epoch length, as we recently painfully discovered with swap claims
@hdevalence what part needs to be done for V1? I suggested we bump it down because we decided to not add the BFT time synchrony check, and the unbonding mechanism we discussed has been implemented
The part we need to do for V1 is "Change to time-based mechanisms", in other words if we want to do stuff later we need to move it out of this scope (and have a story of why it's not necessary for the change)
It's pretty confusing to call this "time-based mechanisms" if what we want to do is make sure that the protocol is equipped to deal with dynamic epochs...
Closed as complete
The final step of #2070 is to repair the mechanism design to account for the dynamic epoch changes, moving to time-based mechanisms.