You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
@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?
@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.
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 #461
The text was updated successfully, but these errors were encountered: