Keysplitter

[Zacholme7]

Issue Addressed

#32

Proposed Changes

This pr introduces our own key splitter tool with two supported modes.

1. Manual mode. This is the same as the ssv keysplitter. All information must be manually input.
2. Onchain mode. This will perform a quick sync of the chain on relevant events to index all of the owner nonces and the public keys of all of the operators. It will then use this information for keysplitting, making the UX a bit better.

[dknopik]

Found two small issues: version needs to be v1.2.1, and operator keys need to be in BEGIN RSA PUBLIC KEY instead of BEGIN PUBLIC KEY ;(

[dknopik]

We need to increment the nonce by one. I'd return Result<Option<u64>, DatabaseError> from get_nonce_for_owner and use .map_or(0, |nonce| nonce + 1) at the call site.

[dknopik]

The key shares need to be hex-encoded before encryption (idk why)

[Zacholme7]

@dknopik

1. I thought we were only going to support PKCS8. The parse_rsa function is transforming the already incorrect keys into PKCS8.
2. Ah thanks. I didnt know if I should copy their version or just start at our own version.
   3)I think this is a tricky situation. Right now it will not increment the nonce at the callsite but when the log is emitted onchain the nonce will be incremented from that. If we incremented it at the call site then it will result in a double increment. But if someone splits multiple shares in one go then the nonce will be wrong. I think this behavior can be addresses with bulk keysplitting support which should be another PR.
3. So we need to serialize the keyshare, hex encode it, and then encrypt it? And then we shouldnt hex encode it on output?

Edit on 3: I understand that now thanks

[dknopik]

What do you think about naming the "anchor" subcommand e.g. "node" instead? Invoking anchor anchor is awkward

[Zacholme7]

Marked as draft till we figure out situation with SSV UI key formatting.

[Zacholme7]

Mentioned webapp, supporting mixed format for now.