<aside> 👨‍🚀 The goal of this document is to highlight the different avenues one could take to allow verifiable computing over client data stored in Filecoin.

</aside>

📋 TLDR

Goal: enable verifiable computation over data stored on Filecoin

Problem: Current commitment to data are not amenable to verifiable computation

Solutions: 3 different types

• Change filecoin / IPFS types (best but very difficult)
• Use another different commitment:
  • And trust users (easy but no guarantees)
  • OR prove both commitment relate to same data (difficult with some guarantees)

🚨 Core Problem

CommD is not at all SNARK friendly, e.g. we can’t run any verifiable computation over it efficiently.

Therefore, we want a new PieceCID/CommD which is SNARK friendly. The following sections each explores a different path to get there.

🌐 Single Commitment Vision

<aside> 👉 There is a single commD commitment used for both storage in Filecoin (as in now) but also verifiable computation over the data and IPFS.

</aside>

Currently, computing over a SHA-256 PieceCID is very expensive for computation so we need to have another way to commit to a pieceCID.

Pros:

• 👍 One can know if the FIL PieceCID that he wants to compute over is effectively stored in Filecoin
  • Both commitment represents exactly the same data, with complete assurance

Cons:

• Retrieving a PieceCID is not ideal for clients using IPFS
• Not backward compatible for Filecoin storage proof
• Potential new commitment does not meet user-friendly practical requirement
• Suffers in case we upgrade PieceCID commitment scheme
• Binds us potentially to specific proof scheme or curve (ok)