-
Notifications
You must be signed in to change notification settings - Fork 316
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
Add opaque porep_id as public input and use when constructing replica_id #1144
Conversation
It's ok to be opaque, but it's important the at verification time, the chain correctly verifies the correct porep-id. Does this live in CompoundProof? |
It is a public input. It can be derived from the |
Perfect. Future review of integration of proofs into Filecoin should catch this. I will make a note. |
Just a quick note: this PR does not directly address issue "20. FeistelKeys, Seed_D should be specific to a particular Proof of Replication e.g. H(RegisteredProofID || random nonce)", but only "21. ReplicaID should contain the RegisteredProofID". Correct? |
No, it address both. See the second commit: 5cb4331. |
Reading more closely, it does handle the DRG part, but not the Feistel keys. I will add. |
9475c62
to
e620225
Compare
@nicola Updated with Feistel keys and DSTs. |
e620225
to
c269e8b
Compare
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.
Perfect, it seems that this PR has correctly replaced the previous seed with the porepID
c269e8b
to
d7e2793
Compare
FYI, @cryptonemo: this change is going to require work in |
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.
fiiine
9f1c86b
9f1c86b
to
30f5f0d
Compare
This PR adds a new 32-byte public input,
porep_id
, to SDR. This value is used to constructreplica_id
, the drg seed, and the Feistel keys. As a public input, it must be supplied (with identical value) by both prover and verifier. The intention at the protocol level is that proofs consumers should pass a value derived from theRegisteredProof
— since it is guaranteed to distinguish all extant PoReps. However, from the perspective of therust-fil-proofs
theporep_id
is treated as opaque and is required only to be used consistently. If consumers choose to duplicateporep_id
s, they take responsibility for the possibility thatreplica_id
or DRG graph might be reused between the set of concrete proofs the duplicated id is used to create. If the Filecoin spec is modified to require a distinctporep_id
for every distinct concrete type, such usage will violate the protocol.UPDATE: now supports Feistel keys
porep_id
is a PublicParamderive_porep_domain_seed
, which also takes domain separation tag.