Luca Disclamier: everything below is (Preliminary) Work in Progress
Abstraction
We can abstract the ultimate goal of MT translation proof as the need to have a publicly verifiable proof that two vector commitments open to the same input vector.
Getting back to Filecoin
We have the following scenario:
- We have some input data D
- We have a first commitment Comm1
- We have a second commitment Comm2
Concretely, we can think of Comm1 as an IPFS CID and to Comm2 as a CommP
Question: How do one knows that both Comm1 and Comm2 are commitment to the same (original) D?
One possible answer could be to open the two commitments in a Snark and prove that they open to the same (expected) vector D.
Unfortunately, our commitments are based on Sha256, which makes unpractical to deal with multiple openings.
Merkle Tree Translation Proof and Proofs of Wrong Merkle Tree Translation
At high level (see here for more details) we could deal with this issue by having a combination of two proofs:
- An interactive proof of Merkle Tree translation (probabilistic checks on different random openings of both Comm1 and Comm2). Note that this step would not be onchain, given that one has to check all the vanilla Proofs (MT paths in case of MT) which can not be proven into a snark
- A non interactive proof of Wrong Merkle Tree translation: at a latter time, anyone retrieving D can challenge the author of either Comm1 or Comm2, claiming that there is some position that does not open to D. This challenge could be resolved on-chain, by the SP posting a (singe) proof that translation was performed correctly at the given position (i.e. a single MT path in case of commitments done via MT).
What's Wrong?
In our case dealing with MT translation proof if problematic, since MT translation proof can not be onchain and are not publicly verifiable.
Idea: A Client based “Oracle” to deal with data preparation
The idea here is to overcome the risk of having a mismatch between CommP and IPFS cid by asking the Client to provide the CommP himself.
This way we
- avoid the need of MT translation proof and Wrong MT translation proof and related issues (see )
- Avoid building an Oracle that would either perform the “translation” or resolve disputed (see related section)
In essence, we are proposing to have the Clients being theirselves oracle for the CommP and IPFS cid “equivalence” wrt the committed data