charon combine should have --no-verify flag

[gsora]

🎯 Problem to be solved

In #2300 @sugh01 tried combining cluster keys whose lock file has been modified without re-generating the lock hash, hence invalid for charon run unless executed with --no-verify.

🛠️ Proposed solution

• Core team consensus on the proposed solution

Implement the same --no-verify logic in charon combine as charon run, so that a cluster lock with wrong lock hash can still be combined.

At the moment combine checks that all the lock files yield the same SHA256 hash.

The logic must change: if --no-verify is specified, combine must check that all the validator public keys and its associated key shares are the same in all lock files involved, rather than checking the cluster lock hash.

🧪 Tests

• Tested by new automated unit/integration/smoke tests
• Manually tested with the cluster lock and key files specified in Error when combining keys of Cluster with version 1.4 #2300

✅ Acceptance criteria

Given a user with a non-verifiable cluster lock, resulted from out-of-band modifications after the DKG process
When the user tries to recombine the validator private keys with the combine command
And the user specifies --no-verify as combine parameter
And the validator public keys and shares are the same in all the specified cluster locks
Then combine combines the validator keys specified in the cluster lock successfully

[xenowits]

@gsora not sure if we should allow users to combine keys if their cluster locks are malformed?

[gsora]

@xenowits #2300 is a great example: the cluster lock was modified because the withdrawal address was wrong, but since users needed the cluster to work it was executed with --no-verify.

Now that combine is available the users might want to reconstruct the validator key, create a new cluster with them but this time with the correct withdrawal data.

Without --no-verify on combine this operation is impossible: one would need the lock file state that yielded the original config hash, which might be hard to obtain.

Also the fact that config hash doesn't match doesn't imply a malformed cluster lock: in this case, while the config hash was different, the cluster lock was well-formed and worked fine with charon run --no-verify.

This is why combine must check that all the validator public keys and shares are the same in lock file set, regardless if the config hash matches: you can't recombine if your lock and my lock don't agree on the validator list, but you can if they're the same even if config hash doesn't match and you specified --no-verify on the CLI.