@Deleted User@Deleted User @Deleted User

WIP: Looking for a better name

A way of proving persistent space which Implicitly proving access to data encoded into sectors

Quick Links

📊 Motivation

One key feature Filecoin should enable is efficient retrievals. A key insight from the growing data-owner base of filecoin, is that this efficiency is of utmost importance. This holds both for the clients themselves and for SPs who are faced with difficult choices on how to optimize their hardware for the most common use-case.

In essence, given the way our sealing process is designed today, the easiest way to ensure such a feature is via asking providers to arrange reliable access to the clear data. One key question is how to assure clients that, once they hand their data to an SP, this reliable access to their data is continuously maintained.

We propose to do so via Proof of Access, which is implicitly provided every time a WindowPost and a WinningPost is posted on-chain.

🗺️ How to get there

There are two ways we can get Proof of Access

In this doc, we describe the scenario of re-using existing circuits.

🚀 Impact on Filecoin

Why Proof of Access in Filecoin?

Unique features of Proof of Access vs status quo

Filecoin improvements

For a more detailed description of the above, please see Fil-PoA: Filecoin Proof of Access - 🌈 Outcomes

🔥 Current Risks

📦 Fil-PoA Protocol

With Fil-PoA (Filecoin Proof of Access) we want to introduce a change in the way PoRep are produced and verified in order to make efficient retrieval of filecoin data possible and easy to implement.

We do so by

• Slightly augmenting the way PoRep is computed
• Entangle Proof of Access with consensus
• Give periodical guarantee of Proof of Access (via existing PoST schedule)

🏗️ Overview

Today, at PoRep step, SPs prove that the replica was built correctly in a probabilistic way.

• For CC sectors, this means that the SectorKey is well formed
• For sector with deals, this means that Replica = SectorKey + Data is well formed

Note that we have a unique commitment CommR onchain for each sector in the network, which in case of CC sectors “degenerate” in a commitment to SectorKey

At WindowPost, SP need to prove that they are still storing all the replicas in a given partition, while at WinningPost they got challenged on a randomly selected sector for which they need to prove they are actually storing the replicated format.

We propose to slightly modify the flow above for sectors with data in the following way:

Porep Step

In addition to the current CommR commitment flow, for each sector with data, an SP should add on chain

• A proof that SectorKey is correctly built

WindowPoSt

Each sector in a proven partition should answer challenges against both CommR (Replica) and CommK (SectorKey)

fund

WinningPoSt

A challenged sector should answer challenges against both CommR (Replica) and CommK (SectorKey)

🌈 Outcomes

Efficient retrieval provably enabled

Proving both Replica and SectorKey implicitly proves access to a copy of clear data, encoded into the sector, while allowing an SP to not double the amount of space needed to answer challenges. Indeed:

• An SP can share a copy of the clear data and persistently store an encoded version of it.
• When challenged, he derives SectorKey = Replica - Data and answers the challenges
• Even if an SP decides to store both Replica and SectorKey and does not access the data, Data can be easily derived as Data = Replica - SectorKey

A unique proof entangling Proof of Access to the data to Consensus

Given now PoRep, WindowPost and WinningPost all consist of two components, failing any of the two would invalidate the whole proving step. This means that not (implicitly) proving data access would result into the same countermeasures which today are in place for the current PoRep, WindowPost and WinningPost respectively

Enabling SnapDeals for Sector Natively with Deals

Today SnapDeals can not be applied to sector which are natively with Deals, since in order to do so, we miss a commitment to SectorKey onchain required to check against when proving the SnapDeals step. This limitation would be totally removed by introducing a proof and a commitment to SectorKey for all sectors (for existing sectors natively sealed with deals, this might require re-computing the SectorKey).

(Optional) Equalizing proving cost of CC Sectors and Sector with Deals

If we introduce Fil-PoA for sectors with deals only, one drawback is that sectors with deals will have a 2x proving overhead compared with CC sectors. We could re-balance this by requiring CC sectors to be snapped with a pre-determined set of non-neutral elements (non- 0x00 ) . On one hand, this would make CC sectors also more expensive to prove but, on the other hand, we would minimize the operational difference between CC and Data sectors, thus reducing the expense an SP would need to pass on to a client.

🎯 Workplan (TBD)

📗 Other Docs

📈 Progress so far

👥 People