design: how to ensure all valid updates are relayed to the Replica

[anna-carroll]

• If Replica is Failed, updates not accepted
• We need all the proper updates to be relayed before rotating updater
  • Currently not possible to relay updates from old updater after we rotate to a new updater
  • We could manually set confirmAt — which events would that break off-chain?
  • governance action Update -- emits Update event?
• If we allow continuing to relay updates (rather than failing Replica) to facilitate relaying "good" updates, A truly malicious updater could keep submitting improper updates to the Replica while we try to clean up; we want a finite mess to clean up
  • Only way to block a truly malicious updater is rotating them

[yourbuddyconner]

@ltchang2019 submit comments here if you got any

[luketchang]

Can we add another variant to State like State.Recovery? In this state, notFailed modifier would allow actions during State.Recovery but only with say the governor or recovery manager as msg.sender?

On double update, steps might look like:

1. Fail the home
2. Replicas go to Recovery mode
3. Rotate updater on the home
4. Erase bad roots on replicas
5. Relay good updates to replicas, calling from the governor or recoveryManager address
6. Rotate updater on replicas

We might not even need failed state tbh. Having default be that notFailed can only be bypassed in failed state when called by owner/governor/recoveryManager might be better.