Submitted by ChristiansWhoHack
https://github.com/code-423n4/2023-11-zetachain/blob/b237708ed5e86f12c4bddabddfd42f001e81941a/repos/node/x/observer/keeper/hooks.go#L92
The process for changing the TSS address happens as follows:
If a single observer gets slashed for any reason, the chain will be halted until steps 2-6 are manually done. Within the endblocker, we can see the code that will disable inbound CCTXs and restart the keygen process if the observer count is mismatched. This happens within the BeginBlocker process of the observer module.
The count changes only when slashing occurs. The slashing happens automatically using the StakingHooks. Within the hook BeforeValidatorSlashed(), it checks to see if the user is underneath the specified threshold. If thats true, then they will be removed.
From the code above, it is clear that an observer going off line from slashing will restart the keygen process and halt the chain. This may happen on accident, such as the server going down from a power outage, or on purpose from a malicious validator.
Considering this requires all TSS voters to perform operations (currently 11 on Ethereum) and the administrator, there are a lot of points of failure here. If this happens, I would guess it would take 12 hours to get everything back into a working state. For a fairly common occurrence, this is a large amount of downtime.
One strategy would to simply remove the observer and keep moving on until a pre-determined date. Since the threshold for all of the keys is 2 out of 3, everyone would keep functioning normally until the change was made.
An additional strategy would be to automate this entire process. However, many of these operations are super sensitive, such as migrating admin keys. So, this may be intentional.
lumtis (ZetaChain) confirmed
