-
Notifications
You must be signed in to change notification settings - Fork 25
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
Slightly less compact gate #968
Slightly less compact gate #968
Conversation
Did you mean 8 elements here? GateId is an array, 8 elements bring us to 112 bytes on stack which is not bad at all, but there seem to be a natural limit of how deep we can go with steps. It is probably easily detectable and we can abort at that point, but it does look like #961 approach has more headroom because of compile-time inspection of step hierarchy? |
} | ||
} | ||
|
||
impl Display for Compact { | ||
fn fmt(&self, f: &mut Formatter<'_>) -> std::fmt::Result { | ||
write!(f, "{}", self.as_ref()) | ||
f.write_str(hex::encode(&self.id).as_str()) |
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.
is it possible to go from compact to descriptive in this implementation? compact identifiers do not carry a lot of information on their own. IIRC gates are used in HTTP layer, using base64 over hex is probably going to be hard/cryptic especially when we start working on MPC spec
Another take on compact gate.
Similar to descriptive gate, this constructs a gate identifier as a concatenation of step IDs. Instead of character strings, it uses byte strings just long enough to encode the number of variants for each Step type. For OPRF IPA, the length required to encode our gate IDs in this format is 8 bytes (not including the length of the ID). It could be made somewhat shorter by using nibbles or bits instead of bytes.
Like #961, this implementation requires that each step has only a single child step type. There isn't a dedicated mechanism here to enforce that, but I think there ought to be. I did find one instance where it was not the case (substeps of
ipa_prf::Step
) because it resulted in a PRSS index conflict. That was easy enough to resolve by promoting the PRFKeyGen step upwards.By my performance measurements, this is the same speed as compact gate, if I eliminate as_ref / to_string calls for gate IDs. (While making these performance measurements, I discovered that some of the slowness of our metrics is not inherent in submitting a metric, but rather a result of using metric labels that are not known at compile time. Currently compact gate implements as_ref / to_string by returning a static string built into the binary. For this implementation, I return a hex encoding of the byte string ID.)
An advantage of a hierarchical gate ID encoding is that it's much easier to describe and capture the set of defined values in a standard.