Closed ChaoticTempest closed 1 month ago
success
success
Pusher: @ChaoticTempest, Action: pull_request
, Working Directory: `, Workflow:
Terraform Feature Env`
URL: https://mpc-recovery-leader-dev-565-7tk2cmmtcq-ue.a.run.app
Can we add a script to infra/scripts that partners can run easily so I could point them to it?
when we decrypt a message we are fetching the sign_pk from contract state(code), so we need to change contract state's sign_pk's to reflect this. How do we plan to change contract state? Can we add code for it? Also we'd expect down time before all partners change their node and we push the change to the contract.
@ppca so how I imagine this would work is that the partners would actually still use their account sk in the mean time, while newer nodes that join the network will have their separate sign secret key. This way we have minimal changes for now, and there's no restriction anyways where a node cannot use their account secret key to sign. This just allows the ability for a separate sign secret key to be provided. The partner network is testnet anyways, so it'll be fine.
Can we add a script to infra/scripts that partners can run easily so I could point them to it?
Was looking for an easy way to do this, but doesn't seem quite feasible in the format that our keys are required to be in. We might have to have a separate rust project where nodes can compile and run to generate all these keys
@ChaoticTempest @ppca we definitely can use NEAR CLI for ED25519 key generation. Why should we ask partners to do that with tests?
@ChaoticTempest @ppca I agree that current partners can use the same key for signing messages and interactions with NEAR Blockchain. Ideally, they can use the same key for signing messages, but rotate and update their NEAR Key. But that is not necessary, since it's still on testnet. MAinnet partners will have 2 separate keys anyway.
So for testnet, existing partners can run with what they have, no need to add new sign key, while new joining partners will generate a separate sign key. For mainnet, we will require that all partners start off with separate sign key.
This plan sounds good to me, but then the PR actually requires the MPC_RECOVERY_SIGN_SK to be present once we push the code changes to testnet partners. We could ask partners to do gcloud compute instances update-container multichain-dev-0 --container-env MPC_RECOVERY_SIGN_SK={near_private_key}
to add the env var to their node. Do we need to convert their near private key to any certain format tho?
I could test above process on dev network first. Btw, if this PR merges before dev nodes update their env vars, dev network might be down for a while because our dev nodes now redeploys on every PR merge. BUt should be fine. as long as we fix it before we push changes to partner testnet.
btw, do we still need account_sk then?
@ChaoticTempest @ppca we definitely can use NEAR CLI for ED25519 key generation. Why should we ask partners to do that with tests?
That will work for me as long as the near cli command can output the exact command we need.
btw, do we still need account_sk then?
Not sure what you mean. Each node still needs to interact with NEAR Blockchain, so the key is still required.
@ppca made changes to this PR so that the terraform should only check if the resource is present then set the env for it, which thereby defaults to using the account secret key if it's the sign secret key is not supplied. Can you also check if my terraform code is correct here?
success
success
Pusher: @ChaoticTempest, Action: pull_request
, Working Directory: `, Workflow:
Terraform Feature Env (Destroy)`
This introduces a separate signing key for messages to be sent over the wire for protocols like triple, presignature and signature generation. @ppca this also adds in
multichain-sign-sk-*
to terraform so this introduces a new key needed to be added by partner nodes. This key can be generated via: