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

fix: remove challenge seed from NI-PoRep SnarkPack transcript #1755

Merged
merged 2 commits into from
May 15, 2024

Conversation

DrPeterVanNostrand
Copy link
Contributor

Alternative to #1754. This PR proposes that any PoRep challenge seed(s) (provided as API arguments) not be included in NI-PoRep's SnarkPack transcript, as opposed to using a constant value for NI-PoRep's challenge seed.

Imho, merging of either PR should be held off until a decision is made during the NI-PoRep audit.

Copy link
Contributor

@vmx vmx left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not hashing the seed at all makes sense (instead of hashing some fixed value.

I think it would make sense to add a comment to the entry point of the sealing at https://github.com/filecoin-project/rust-fil-proofs/pull/1755/files#diff-7360cc04999e8c2b4559e9d4b8bf83afaeaeb2be3e07314287b00fcc6b81d380L348 to note that for the Non-Interactive PoRep the seed is not used and that it can be any arbitrary value.

Would it make sense to refactor the hash calculation into its own function, so that it's again clearer that it does exactly the same thing for proving as well as for verification?

hasher.update(seed);
hasher.update(comm_r);
if porep_config.feature_enabled(ApiFeature::NonInteractivePoRep) {
for comm_r in comm_rs.iter() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think for Non-interactive PoRep, it's always only a single comm_r only. Should we even be stricter here and just hash that value, instead of looping through all (I know it's the same outcome, but it might be clearer to the reader).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I wasn't totally sure what to do here. The way that it's currently written leaves open the possibility of aggregating multiple NI-PoReps into a single SnarkPack proof, however I don't know if that behavior should be allowed.

@cryptonemo
Copy link
Collaborator

cryptonemo commented May 13, 2024

Would it make sense to refactor the hash calculation into its own function, so that it's again clearer that it does exactly the same thing for proving as well as for verification?

It used to be a separate function and review feedback implied it wasn't needed to be a separate function. Also, no, it's pretty clear as it is.

@DrPeterVanNostrand
Copy link
Contributor Author

I think it would make sense to add a comment to the entry point of the sealing

Yup, sounds like a good idea. I'll add it.

Comment on lines +355 to +356
// Note: when using NI-PoRep the PoRep challenge generation seed is ignored, thus any value can
// be passed in here for `seed`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a note (feel free to ignore). I know we don't really use API docs here (their building is even broken). Though it could make sense to put it into the top of the function (or another note there) as a doc comment, in case we ever properly generate those.

@DrPeterVanNostrand DrPeterVanNostrand merged commit 19e5089 into master May 15, 2024
32 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: ✅ Done
Development

Successfully merging this pull request may close these issues.

3 participants