tlsnotary / tlsn

Rust implementation of the TLSNotary protocol
https://tlsnotary.org
259 stars 69 forks source link

[feature request] allow for disclosure of response digests #566

Open sunny-g opened 4 weeks ago

sunny-g commented 4 weeks ago

The selective disclosure of subsets of an HTTP response is very useful when the responses contain structured data, but when they are otherwise non-human readable or simply just binary data (images, PDFs, protobufs, etc), it would be very convenient to provide an option for hashing the data and instead disclosing just its digest.

As that computation would (probably) have to run within the prover, perhaps Poseidon is a sane default?

Likely depends on fixing https://github.com/tlsnotary/tlsn/issues/461

themighty1 commented 3 weeks ago

@sunny-g , could you give some more details how the digest will be used?

Currently the API allows the prover to create a salted hash commitment to arbitrary data. (although under the hood it is not exactly a standard blake3 hash of the data). The produced hash commitment can then be verified efficiently.

Are you looking for something that can be efficiently verified on the blockchain?

sunny-g commented 2 weeks ago

@themighty1 in the use case I'm thinking about, the digest of the raw response body could be used as a content-addressable identifier (CID), and the response body could then be disseminated over IPFS or another content-addressable store. So an indexing server could host the verifiable proofs and could point users to decentralized stores to fetch the underlying content.

Does that make sense? I've played tlsn a bit locally, but must have missed part where the salted hash commitments are generated - I'll look into it and see if that satisfies my needs.