Comments (5)
Ideally I think we would like to abstract it behind a single RescuePrime
additional type in the HashFunction
enum. In crypto/src/hash/
, we could then have a single pub struct RescuePrime<B: StarkField>(PhantomData<B>);
defined, in addition to the existing sha3 and blake3 hash functions, which relies internally on the concrete implementation of Rescue for the given field.
This would require implementing a Rescue instantiation (of same conjectured security) for each existing field in math/src/field
(currently f128 missing) but would then allow for an easier abstraction on the prover / verifier side. However I think we would still need a generic implementation, which without #![feature(specialization)]
is not allowed. I don't know of a way to deal with this on the stable channel.
from winterfell.
One thing I'm wonder is whether we should make hash function a generic parameter for prover/verifier. This way, users of the library would be able to provide any hash function implementations which comply with ElementHasher
interface.
I think on the prover side this shouldn't be too difficult to do. But the verifier side might be more challenging (depending on how sophisticated we want to make it).
from winterfell.
A few more thoughts on this.
On the prover side, there are a couple of options:
We could add something like HashFn
associated type to the Prover
trait:
type HashFn: ElementHasher<BaseField = Self::BaseField>;
Another option is to make Prover
trait generic:
trait Foo<H: ElementHasher<BaseField = Self::BaseField>>
I probably prefer the former approach as I think it would be more flexible - but open to suggestions.
On the verifier side, we'll need to update the signature of the verify()
function to look something like this:
pub fn verify<AIR: Air, H: ElementHasher<BaseField = AIR::BaseField>>(
proof: StarkProof,
pub_inputs: AIR::PublicInputs,
) -> Result<(), VerifierError>
The above would mean that if we specified hash function incorrectly for a given proof, proof verification will fail. We might want to return a meaningful error message for this - but I'm not sure yet what's the best option for detecting this error.
In general, we'll also need to remove HashFunction
enum and update the proof struct accordingly (i.e., the proof won't track which hash function was used to generate it - or at least not via this enum).
from winterfell.
Out of the two options above, I'd also prefer the first one. Although I did appreciate the customization left to the user to specify the targeted hash function. Also removing the Hash function from the proof options would require changes or fixing assumptions on the hash functions supported when evaluating the security level, as this is a method of the Air trait.
from winterfell.
Closed by #111
from winterfell.
Related Issues (20)
- `f64` field: `BaseElement` should not be convertible from `u64` or `u128` without error HOT 1
- Add serialization/deserialization for `usize` type HOT 1
- Accomodating more expressive transition constraints HOT 3
- `TraceTable::with_meta()` should be marked `unsafe`
- Suggestion: Remove outdated griffin hash implementation HOT 1
- Generalize auxiliary trace building logic HOT 2
- Simplify 2-d matrix types
- Generalize `TransitionConstraints` and `BoundaryConstraints` HOT 1
- Consider using the standard benchmark harness instead of criterion HOT 1
- DEEP polynomial with Lagrange kernel HOT 1
- `Deserializable` should have an associated type error
- `Proof::security_leve()` should take into account auxiliary proof
- `group_vector_elements` panics during account code compilation HOT 2
- Verify GKR proof in `Trace::validate()`
- FFT-based division to improve DEEP composition polynomial computation
- GKR-LogUp: additional required API changes HOT 3
- Add `Sync` as a required trait for `ElementHasher`.
- Make a `DomainLength` trait for `VectorCommitment::Proof` and `VectorCommitment::MultiProof`
- Add `Item` associated type to `VectorCommitment`
- Refactor LogUp-GKR
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from winterfell.