Vault Rotation at Genesis

[kylezs]

Wanted to spec out what the chain genesis looks like, as it's an important component of vault rotation - we need to get to our first multisig vault, before we can rotate out of it.

Here's how I imagine it going:

1. We generate a keypair (no multisig process required)
2. We put the pubkey in the contract genesis - deploy the contract
3. We put the pubkey in the chainspec genesis config (the CFE knows which key to sign with, this way)
4. We put the priv key in our (single) genesis validator's (let's call her Alice) keystore
5. We setup X validator nodes, and stake them to the contract - not including Alice.
6. We start Alice
7. Alice runs the standard validator procedure:
   1. Gathers witnesses from the staking contract - we've already setup and staked the nodes here
   2. At block R, we being the rotation - like this: https://swimlanes.io/d/8jCqcT2k - except the EthSignTxRequest doesn't require a multsig procedure, since there is only one node
   3. We broadcast this signed tx, and once this tx on the contract has gone through, Alice registers this by submitting a vault_rotation_response()
      • 1/1 consensus is reached
   4. NewEpoch event is emitted
8. All nodes register this NewEpoch event, and start acting as validators. First vault rotation complete.

[morelazers]

SGTM

[kylezs]

@msgmaxim how would the signing work in a single node ceremony like this? Does it change the code path at all or does something need to change if we want to construct the sig, with the contract acceptable challenge etc. ?

[msgmaxim]

I think @j4m1ef0rd tried running a single party ceremony and it didn't work. I might be able to look into why and whether it is easy to change, but I also think adding a special case for a single party singing isn't a bad solution: it is a very special case that doesn't require p2p, key reconstruction, nonce negotiation etc...

[j4m1ef0rd]

The problem was in VerifiableSS::<P>::evaluate_polynomial, maybe because of the sample_polynomial is not valid with only one point. But i couldn't get debugging to work, so i didn't look deeper into it.

[dandanlen]

Sounds fine but would it not be simpler to use a valid multisig based on the genesis validators from the beginning?

[msgmaxim]

I see two approaches here (without creating multisig by hand).

1. Add a special case (either on SC or CFE) to handle single-node signing requests by performing a regular schnorr signing (similar to what @j4m1ef0rd did for testing signatures against the contract). We already have helper functions that can do essentially that.

2. Make sure that the signing "ceremony" works for a single party (I'm not sure it will tbh) and just use that.

[kylezs]

Yeah, 1 is what I was thinking.

[morelazers]

Please submit a branch plan @kylezs and we can continue the discussion on that issue.

[kylezs]

I still think there's a bit of disagreement - when to use discussions vs issues in this case?

[morelazers]

Yes so let's have a tangential discussion about issues vs discussions on this discussion 🙄

Please make an issue denoting the plan for the proposed change to support 1-node key/sig gen for cleanliness. We will debate the implementation plan there.

The purpose of opening this discussion was to collect feedback about a chain genesis process unless I am mistaken, which I think we all agree on in principle. Any further dispute from me pertains to the assumptions and code changes required to implement the proposed genesis process.