-
Notifications
You must be signed in to change notification settings - Fork 15
Design sponge API #1
Comments
My main concern over having a generic input type is that it may make the trait itself unusable in a general setting. I am not fully familiar with Rust semantics, so correct me if I'm wrong: Generic input types (as is in the current design) would restrict the trait itself from being used in a general setting. ie. The user would not be able to take as argument a generic FiatShamirSponge type and properly use the trait because they would need to know what input type to use. So, they would need to have a specific implementation in mind to use the trait. One possible middle ground is to introduce two new traits that only take in byte-based and field-based inputs respectively. |
The latter should not be an issue, as long you bound whatever you feed into the sponge with a (we might need to have a different trait than |
I suppose this works in the case where random oracle inputs can be generically passed around. If users have non-generic inputs instead, would the trait still be restricted in general use cases? |
Yeah, you can still do, for example, Maybe a better API would be to instead have something like: pub trait FiatShamirSponge<F: Field> {
fn absorb(&mut self, input: impl Absorbable<F, S>);
fn squeeze(&mut self) -> F {
self.squeeze_with_size(ChallengeSize::Full)
}
fn squeeze_with_size(&mut self, size: ChallengeSize) -> F;
}
pub trait Absorbable<F: Field, S: FiatShamirSponge<F>> {
fn absorb_with_sponge(&self, sponge: &mut S);
} |
We have a slightly specialized interface for nonnative and native. This one is specialized in that it supports a nonnative field.
There are two things specialized in this design:
|
One thing that we need to do is sample elements from outside given subgroups; is there an easy way to do that in this API? Or do we just assume the probability of that is negligible? |
Ah, yes. In our implementation, It would still have randomness sufficient for some applications, but its distribution is uneven in the whole field. (We dropped the highest bit.) |
Initial implementation is done in #2 , so closing this . |
Design issue for a sponge trait that should be used across all projects that rely on the FS transform.
Tentative API:
Things to note:
Is the foregoing API sufficient for usecases like Fractal? I think it suffices for the Marlin compiler, and for poly-commit and accumulation-scheme challenge generation.
Prior work:
The text was updated successfully, but these errors were encountered: