Skip to content
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

Conversation

andyleiserson
Copy link
Collaborator

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.

@akoshelev
Copy link
Collaborator

For OPRF IPA, the length required to encode our gate IDs in this format is 8 bytes

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())
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants