TSS migration and key re-sharing

[kingpinXD]

Context

Immediate Goal: We need to establish a safe, efficient, and easily testable mechanism for updating the observer set with minimal operational overhead. Long Term Goal: We need to establish a safe and secure method for TSS key rotation. Not only for modifications ot observer set but also as a routine procedure to improve security.

Option 1: TSS Migration

• The TSS migration is a 4-step process with details documented in the playbooks: https://www.notion.so/zetachain/Protocol-Playbooks-4eb0fb36fcff4fd09f1ed56f102e2ef0?pvs=4

Pros

• The migration procedure is already implemented in the ZetaCore logic, and we have an end-to-end test for it.
• The step-by-step process allows us to evaluate each step and roll back if something goes wrong. The generation of a new TSS key is well-tested.

Cons

• The procedure has many moving parts, especially in step 3. This step involves migrating funds from the old TSS to the new and requires a separate CMD cctx for each chain: https://www.notion.so/zetachain/TSS-migration-3-4-Migrate-TSS-funds-270070cf1fdb41209528e8846128c742?pvs=4
• The End result is a new TSS address, which might need to be updated in configurations and contracts. This could introduce operational overhead that we haven't accounted for.
• Step 3, the fund migration process, is only defined for EVM and BTC chains. This would need to be expanded for all other network types. (Solana, Sui etc)

Option 2: TSS Key Reshare

• TSS key reshare is a mechanism available in the tss-lib, which allows us to update the participant keys which maintaining the same secret. https://github.com/zeta-chain/tss-lib/blob/2e6b438bd9019c5918a6b180ed0cefea534d1da1/ecdsa/resharing/local_party.go#L67-L76

Pros

• We should be able to retain the TSS address and thus won't need to update contracts and configurations. However, this needs to be tested to verify.
• The process itself is simpler; the implementation would be similar to the keygen process. This would likely require changes only in zetaclientd.

Cons

• The go-tss library does not use the re-sharing protocol, so it would have to be implemented from scratch. However, the tss-lib provides the necessary functions, so the implementation itself should not be too complicated. Since this change is critical to the security of the protocol, it would need an audit.

Additional Considerations

• We should also consider our planned transition to BLS, which might require a migration. If so, it might make sense to streamline and further test the migration process to ensure a smooth transition , so that by the time BLS rolls out our migration process is well tested

[kingpinXD]

@CryptoFewka @lumtis @brewmaster012

Overall if we need the migration to happen , for the moving to BLS , I think sticking to the existing migration setup and adding in the new chains might be the best way forward , I can add tasks for the implementation and testing.

Solana migration seems to be straightforward, will need to look a bit more into SUI

[kingpinXD]

For now, I am working on improving /streamlining the migration process, instead of key sharing.

in my opinions that feels like the better way to move forward for now , ill ass some tasks for it

cc @lumtis @CryptoFewka