Thanks for the quick response @berestovskyy
The proposal scope needed to switch on/off a feature flag shouldn’t need to cover altering anything and everything about the GuestOS. A lower nakamoto coefficient is much easier to justify and accept for proposals that have smaller scope
I think it’s the scope of the needed proposals (election and deployment) that’s an issue during disaster recovery, where time is of the essence and a fix needs executing as fast as possible (but without sacrificing unnecessarily on governance security).
At the moment DFINITY rely on having sufficient voting power to force a replica version into the registry in order to recover from disasters promptly. I don’t think this will or should always be the case in the future. This relates to a recent discussion regarding subnet recovery.
But for how long? Following this approach shouldn’t we still be electing LSTM-disabled copies of every replica version. Wouldn’t the number of proposals needed quickly explode (with numerous combinations of on/off feature compilations). Note that in the hotfix discussed in the thread that I linked to, if memory serves, the LSMT feature had already been enabled on all subnets (and this is the only reason an LSTM-disabled replica was no longer being proposed and elected each week).
Thanks @berestovskyy, this info is much appreciated 