-
Notifications
You must be signed in to change notification settings - Fork 2.1k
[commitee] add seal-committee crate with grpc and helper funcs #376
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
Conversation
Introduces a new seal-committee crate that provides helper utilities for: - gRPC communication with Sui nodes - Move type definitions for committee-related structures - Utility functions for working with committee data This crate serves as shared infrastructure for committee-related operations.
crates/seal-committee/src/utils.rs
Outdated
| /// Keys file structure for JSON/ | ||
| #[derive(Serialize, Deserialize)] | ||
| pub struct KeysFile { | ||
| #[serde( |
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.
since we control the format, why not use the existing ser/deser of all the types here (or add them where needed)?
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.
yeah we can just use the move byte literal, moving to the other pr
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.
ah i remember the problem. the move byte deserleriazer is using x"0x... not a convention hex. its not compatible to use it for serde_json for file ser/de for enc_sk, enc_pk, signing_sk, signing_pk. its the most ergonomic if we just use hex for json. the x0x string is whats returned from grpc, so it had to be handled with its own deserializer (just for enc_pk and signing_pk).
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.
KeysFile only uses fastcrypto types, how is that related to move byte deserleriazer?
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.
why not use the existing ser/deser of all the types here
oh i have an existing deserialization i added for move byte literals in seal-committee. this comment is unrelated then.
so i checked the fastcrypto ser/deser its in base64 - its slightly awkward because all move calls takes hex for vec instead. i think our options are
-
use base64 to write, and covert it base64 -> hex in python script when exporting to env vars
-
just store the hex (with custom ser/deser) like i do now
i find 2) is a bit cleaner since its all in rust. wdyt?
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.
base64_to_hex() {
echo -n "$1" | base64 -d 2>/dev/null | xxd -p -c 256 | sed 's/^/0x/'
}
ENC_PK_B64=$(jq -r '.enc_pk' .dkg.key)
SIGNING_PK_B64=$(jq -r '.signing_pk' .dkg.key)
export DKG_ENC_PK=$(base64_to_hex "$ENC_PK_B64")
export DKG_SIGNING_PK=$(base64_to_hex "$SIGNING_PK_B64")
separated from #354
Description
Describe the changes or additions included in this PR.
Test plan
How did you test the new or updated feature?