-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Frost messages #83
Frost messages #83
Conversation
<h3 id="org3b224f7"><span class="section-number-3">3.1</span> Key Generation with DKG</h3> | ||
<div class="outline-text-3" id="text-3-1"> | ||
<p> | ||
These messages are sent during the Distributed Key Generation (DKG). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't include this in this commit as the DKG hasn't yet been implemented.
@@ -99,6 +177,8 @@ pub struct GroupCommitment(jubjub::ExtendedPoint); | |||
/// | |||
/// To derive a FROST keypair, the receiver of the [`SharePackage`] *must* call | |||
/// .into(), which under the hood also performs validation. | |||
#[derive(PartialEq)] | |||
#[cfg_attr(feature = "serde", derive(serde::Serialize, serde::Deserialize))] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would think about whether having an 'external' data type and an 'internal' data type will make maintaining this implementation easier in the future. I believe this is what Zebra does- @dconnolly @teor2345 can give good guidance on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Zebra has three layers of types in its messages:
- external message protocol based on Bitcoin
zebra_network::protocol::external
- internal translation of those messages into a request-response protocol
zebra_network::protocol::internal
- Zcash types based on the chain spec
zebra_chain
The external and internal messages are wrappers for the chain types.
Since FROST isn't inheriting a badly-specified legacy network protocol, you could have a much simpler design:
- message header struct
- message types enum containing internal types
And then the serialization layer can deal with:
- applying and removing headers
- any logic around version compatibility
struct Header {
version: u16
..
}
enum Message {
Share {
package: SharePackage
}
Sign {
..
}
..
}
Replaced by #85 |
For now, only the
SharePackage
struct is ready to be serialized by Serde. This is the main struct used in the key generation with trusted dealer.