Currently FROST library is complete for 2 round signatures with a dealer/aggregator setup.
This proposal is only considering that specific features, additions and upgrades will need to be made when DKG is implemented.
Assuming all participants have a FROST library available we need to define message structures in a way that data can be exchanged between participants. The proposal is a collection of data types so each side can do all the actions needed for a real life situation.
## Definitions
-`dealer`
-`aggergator`
-`signer`
-`nonce`
-`commitment`
-
## Guide-level explanation
We propose a message separated in 2 parts, a header and a payload:
```rust
struct Message {
header: Header,
payload: Payload,
}
```
`Header` will look as follows:
```rust
struct Header {
msg_type: MsgType,
version: MsgVersion,
sender: Participant,
receiver: Participant,
}
```
While `Payload` will be defined as:
```rust
enum Payload {
DealerBroadcast(MsgDealerBroadcast),
Commitments(MsgCommitments),
SigningPackage(MsgSigningPackage),
SignatureShare(MsgSignatureShare),
FinalSignature(MsgFinalSignature),
}
```
All the messages and new types will be defined in a new file `src/frost/messages.rs`
## Reference-level explanation
Here we explore in detail the header types and all the message payloads.
### Header
Fields of the header define new types. Proposed implementation for them is as follows:
Validation is implemented to each new data type as needed. This will ensure the creation of valid messages before they are send and right after they are received. We create a trait for this as follows:
Each message struct needs to serialize to bytes representation before it is sent through the wire and must deserialize to the same struct (round trip) on the receiver side. We use `serde` and macro derivations (`Serialize` and `Deserialize`) to automatically implement where possible.
This will require deriving serde in several types defined in `frost.rs`.
Manual implementation of serialization/deserialization will be located at a new mod `src/frost/serialize.rs`.
`Commitment` is a wrapper of `jubjub::ExtendedPoint` and this is a structure with 5 `jubjub::Fq`s as defined in https://github.com/zkcrypto/jubjub/blob/main/src/lib.rs#L128-L134
Each `Fq` needed to form a `jubjub::ExtendedPoint` are `Scalar`s of `bls12_381` crate. Scalar here is `[u64; 4]` as documented in https://github.com/zkcrypto/bls12_381/blob/main/src/scalar.rs#L16
`Payload`s also use some types that are defined in the `redjubjub` crate. Here we describe them from a serialization point of view.
#### `VerificationKey<SpendAuth>`
Defined in `verification_key.rs` it consist of 1 `ExtendedPoint` and 1 `VerificationKeyBytes` which is also defined in the same file and consist of 1 `[u8; 32]`.
#### `Signature<SpendAuth>`
Defined in `signature.rs` consist of 2 `[u8; 32]` arrays.