Skip to content

rfc: propose PDP offer invocation #76

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.

Sign up for GitHub

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

Open
alanshaw wants to merge 1 commit into
base: main
Choose a base branch
from
Open

rfc: propose PDP offer invocation #76

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 21 additions & 0 deletions rfc/pdp-offer.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
# RFC: PDP offer

Today we refer to data via two different hashes - a hash generated by the client (what we refer to as blob hash), and a hash generated by storage nodes as a requirement to identify data when interacting with the PDP contract. The client hash is typically sha2-256 multihash and the other is a piece multihash ([fr32-sha256-trunc254-padbintree](https://github.com/filecoin-project/FIPs/blob/master/FRCs/frc-0069.md)).

There is implicit trust that the piece multihash generated by the storage node addresses the same underlying data as the blob multihash. The only way to verify the two hashes are related is to perform the hash computation, which involves reading the data.
Copy link
Copy Markdown
Member Author

@alanshaw alanshaw Nov 17, 2025

Choose a reason for hiding this comment

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

The only way to verify the two hashes are related

To my knowledge. Something something ZK circuit?


An external party looking to validate a piece multihash being added to PDP would need to perform this check, in addition to asserting that the corresponding blob hash was indeed requested to be stored by the service (and accepted). Reading the data and performing the two hash computations would be time consuming and costly, so ideally an alternative can be found.
Copy link
Copy Markdown
Member Author

@alanshaw alanshaw Nov 17, 2025

Choose a reason for hiding this comment

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

An external party looking to validate a piece multihash being added to PDP would need to perform this check

I'm refering to the signing service here btw if it wasn't obvious.


There is however, another party that can verify the equality relationship between the two hashes _without_ performing additional data transfer or computation - the client. The client already generates both the blob multihash and piece multihash, since it uses the piece multihash in a different invocation, that offers the piece into the pipeline for aggregation into long term Filecoin storage deals (`filecoin/offer`).

This RFC proposes using the client generated data as a means to verify the relationship between the two hashes.

To do this, we propose adding two additional capabilities `space/blob/pdp/offer` and `pdp/offer`. The `space/blob/pdp/offer` invocation is sent by the client to the **upload service** and signals that the blob should be added to PDP on any node that it is stored. Note: this includes all nodes replicating the data, including nodes that may replicate the data in the future. Like the `filecoin/offer` invocation, it includes the piece hash as well as the blob hash.
Copy link
Copy Markdown
Member Author

@alanshaw alanshaw Nov 17, 2025

Choose a reason for hiding this comment

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

I did consider invoking directly on the storage node, but the client actually doesn't know where to send the invocation (the URL) and also we need to authorize the upload service to make these invocations in the replication flow.


Once authorized, the upload service will invoke `pdp/offer` on the storage node nominated to store the blob on behalf of the space. Like the `space/blob/pdp/offer` invocation, the `pdp/offer` invocation will include both hashes, providing the node with a externally signed "proof" that the two hashes are equivalent.
Copy link
Copy Markdown
Member Author

@alanshaw alanshaw Nov 17, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

"proof"

...because it's not proof, just an attestation of the fact (albeit not an attestation in the sense of the attestation delegations we use for did:mailto!).


The `pdp/offer` invocation will be sent immediately after the `blob/accept` invocation. In the context of the replication protocol it will be sent to the replica node immediately after it delivers the `blob/replica/transfer` receipt.

Finally, the `pdp/offer` invocation can be stored and used by the storage node as a proof when adding roots to PDP.

A dedicated invocation for PDP inclusion nicely separates it from the blob protocol, and in the short term will reduce some complexity in the code (fewer conditionals for PDP vs not), however most importantly, it provides a means of "proving" the relationship between the two hashes by passing a signed attestation to the fact via an invocation from the client.